Table Entities - scénarios transactionnels

Traitement en cours…

Terminé ! Vous figurez dans la liste.

Oups ! Une erreur s’est produite. Nous n’avons pas pu traiter votre abonnement. Rechargez la page et réessayez.

Introduction

Dans notre dernier article nous avions vu comment les tables entities nous permettraient de simplifier la création de nos CDS en combinant les fonctionnalités des tables classiques DDIC et des CDS en 1 seul objet.

Cependant, nous relevions le fait qu’il était encore impossible de créer des opérations de modification sur ces Business Object via RAP.

Il est désormais possible d’implémenter et de développer des opérations transactionelles en utilisant RAP avec les table entities, et d’appeler cet objet via EML dans des programmes ABAP ou via OData dans des applications Fiori/Web API.
Nous verrons également les limitations que nous avons rencontré lors de nos tests.
Dans cet exemple, nous reprendrons le cas que nous avions développé et visible sur notre GitLab.

Les modifications apportées à ces objets sont également disponibles sur un nouveau repository.

I. Créer les BDEF

Pour rappel, notre exemple représentait les différentes commande reçues par une boulangerie.

Pour cela, nous avons d’abord essayé en utilisant le RAP Generator Object comme vu dans un précédent article, mais il semblerait qu’il ne soit pas encore possible d’effectuer ces créations en automatique pour l’instant.

Nous créons donc manuellement les 2 BDEF qui nous intéressent pour représenter nos commandes et les items associés.

Dans le but de simplifier l’exemple, nous n’ajoutons pas l’association avec la table entity représentant les pâtisseries référencée dans la boulangerie mais nous aborderons ce sujet dans un article prochain évoquant les cross associations désormais disponible en RAP.

managed implementation in class zbp_i_bakery_orders unique;
strict ( 2 );
//with cross associations;

define behavior for ZI_BAKERY_ORDERS //alias <alias_name>
lock master
authorization master ( instance )
//etag master <field_name>
{
  create ( authorization : global );
  update;
  delete;
  field ( readonly ) uuid;
  field ( numbering : managed ) uuid;
  association _bakeryOrdersItems { create; }
}

define behavior for ZI_BAKERY_ORDERS_ITEMS //alias <alias_name>
lock dependent by _bakeryOrders
authorization dependent by _bakeryOrders
//etag master <field_name>
{
  update;
  delete;
  field ( readonly ) uuid, item;
  //, pastryid;
  field ( numbering : managed ) item;
  association _bakeryOrders;

//    association _pastry abbreviation pastry
//  {
//    create;
//    link action link_pastry;
//    unlink action unlink_pastry;
//    inverse function inverse_function;
//     }
}

Ici nous pouvons voir que nous avons les définitions des opérations nécessaires.

Comme chaque ligne de commande est identifié par un UUID unique, nous le générons en automatique via un numbering (managed).

Idem pour le UUID des items (chaque item referencé a un UUID d’une commande à son propre UUID unique).

Également, nous avons activé le create-by-association sur notre composition.

Comme pour n’importe quel autre objet rap managed, il est ensuite possible d’ajouter des validations, determinations, checks d’autorisations, actions, etc…

A noter :

Comme vu dans la documentation : Nous n’avons pas activé le draft sur cet objet RAP, car les tables entities ne supportent pas encore cette fonctionnalité. Cependant il aurait été possible de créer manuellement une table qui aurait été utilisée pour sauvegarder les drafts.
Nous avons du remplacé le type enum dans notre table entity ZC_BAKERY_ORDERS_ITEMS car non supporté.

II. Tests

1. Test EML

Nous avons créé ici un petit cas de test qui montre que suite à la création de cet objet RAP, nous pouvons interagir avec le BO via EML.

CLASS zcl_test_table_entities DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.

    INTERFACES if_oo_adt_classrun .
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.



CLASS zcl_test_table_entities IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.

  DATA lt_test TYPE TABLE FOR CREATE zi_bakery_orders.

    DATA lt_orders TYPE TABLE FOR CREATE zi_bakery_orders.
    DATA lt_items TYPE TABLE FOR CREATE zi_bakery_orders\_bakeryOrdersItems.

    " Create parent order
    lt_orders = VALUE #(
      ( %cid = '1'
        deliveryAddress = '1 rue du test - Lille'
        orderDate = '20251001'
        %control = VALUE #( deliveryAddress = if_abap_behv=>mk-on
                            orderDate = if_abap_behv=>mk-on )
      )
    ).

    " Create child items via association
    lt_items = VALUE #(
      ( %cid_ref = '1'
        %target = VALUE #(
          ( %cid = '1-1'
            quantity = 2
            unit = 'PC'
            amount = 10
            currency = 'EUR'
            pastryid = '1111'
            %control = VALUE #( quantity = if_abap_behv=>mk-on
                                unit = if_abap_behv=>mk-on
                                amount = if_abap_behv=>mk-on
                                currency = if_abap_behv=>mk-on
                                pastryid = if_abap_behv=>mk-on )
          )
        )
      )
    ).

    MODIFY ENTITIES OF zi_bakery_orders
      ENTITY zi_bakery_orders
        CREATE FROM lt_orders
      ENTITY zi_bakery_orders
        CREATE BY \_bakeryOrdersItems
        FROM lt_items
      FAILED DATA(lt_failed)
      REPORTED DATA(lt_reported)
      MAPPED DATA(lt_mapped).

    COMMIT ENTITIES.

  ENDMETHOD.

ENDCLASS.

Via une opération create : nous créons une commande
Via une opération create-by-entity : Nous créons un item à la commande