Pop-up de confirmation – RAP – Fiori Elements

Lors de la création/modification d’un business object, nous souhaitons contrôler si des champs sont manquants/semblent incohérents ou peuvent bloquer la suite du processus. Mais parfois, nous souhaitons seulement aviser l’utilisateur et demander sa confirmation sans pour autant remonter une erreur. Pour cela, nous utilisons une popup de confirmation, et nous allons voir comment configurer cela simplement en ABAP RAP et Fiori Elements.

Notre objectif ici va donc être le suivant : Nous allons ajouter une validation au sein du Business Object précédemment créé qui va vérifier que les champs Text ou Text2 ne sont pas vides. Si les 2 sont vides, la validation permettra de renvoyer un message de demande de confirmation auprès de l’utilisateur.

Le code est disponible sur notre Gitlab.

I. Les différentes documentations

En regardant la documentation, nous voyons déjà qu’il existe 2 types de messages pour remonter des informations à l’utilisateur :

• Transition message :

Moment de vie : uniquement valable pendant l’exécution de la requête.
Portée : lié à l’action en cours (la “transition” entre états), pas au Business Object lui-même.
Exemple dans la documentation : Un UPDATE sur une entité, mais elle est lockée par un autre utilisateur. Dans ce cas, le message « Business Object is locked by user &1 » est un transition message.

• State message :

Moment de vie : lié à l’état actuel d’une instance du Business Object.
Portée : reflète une incohérence (validation) dans les valeurs ou un changement d’état (détermination) du Business Object.
Exemple dans la documentation : Le CustomerID renseigné n’est pas maintenu dans la table des Customers. Alors il faut dans ce cas remonter un State message
Caractéristiques :
– Persiste tant que la condition est vraie (exemple : tant que le customer n’est pas modifié).
– Sont typiquement déclenchés dans les validations (checks) ou determinations (ajustements).

Ensuite, au regard de cette deuxième documentation, il est possible de faire en sorte qu’une popup de confirmation soit créée si le code retour de l’appel HTTP est le suivant : 412 « Precondition Failed ». En effet, dans la documentation, il est indiqué : « For SAP Fiori elements, the 412 message indicates that there are warnings that block the processing of the action, but users can still be trigger the action if they choose to ignore the warnings and continue. »

Par rapport à ces documentations, nous devons donc créer un state message (car le contrôle est une validation sur une instance de notre entité). Et cette validation doit retourner un message de type warning (pas une erreur) qui déclenche un code retour HTTP 412 qui pourra être interprété par le framework Fiori Elements.

Point d’attention :

Il est noté dans la dernière documentation que le message renvoyé côté backend doit être un transition message et non un state message

En effet, nous pouvons lire ici que « Only transition messages are transported in the error response. The messages may be bound or unbound. ».
Cependant, dans notre cas, le framework RAP fait bien en sorte d’envoyer un transition message via la réponse OData, même si côté RAP, le message est un State message. Nous verrons par ailleurs, en testant via un transition message en RAP, que le comportement est différent et ne correspond pas à ce qui est attendu.

II. Développement

Nous commençons par ajouter la validation dans le Behavior Definition :

Comme nous sommes en mode Draft, nous ajoutons également la validation dans l’action Prepare pour que cette dernière soit effectuée. Pour rappel, l’action Prepare garantit la cohérence de l’instance de Draft en appelant les validations et les déterminations lors de l’enregistrement qui sont spécifiées pour l’action Prepare dans le Behavior Definition.

Ensuite, nous ajoutons la validation :

  METHOD validation.

    READ ENTITIES OF zr_crt_test IN LOCAL MODE
  ENTITY zrcrttest
  ALL FIELDS
  WITH CORRESPONDING #( keys )
  RESULT DATA(results_read).

    LOOP AT results_read INTO DATA(read).
   APPEND VALUE #( %tky = read-%tky
                %state_area = if_abap_behv=>state_area_all ) TO reported-zrcrttest.
    IF read-Text IS INITIAL AND read-Text2 IS INITIAL.
     APPEND VALUE #( %tky = read-%tky
                      %msg = NEW zside_effect_message(
                                 textid = zside_effect_message=>missing_value
                                 severity = if_abap_behv_message=>severity-warning )
                      %state_area = 'WARNING'
                      %element-text  = if_abap_behv=>mk-on
                      %element-text2    = if_abap_behv=>mk-on
                    ) TO reported-zrcrttest.

   ENDIF.
    ENDLOOP.

  ENDMETHOD.

• Nous précisons évidemment le %tky qui correspond à l’instance en train d’être modifiée
• Nous ajoutons un message de type warning if_abap_behv_message=>severity-warning
• Pour que le message soit un state message, nous précisons le %state_area
• Nous précisons ici %element-text et %element-text2 pour que les champs en questions soient en surbrillance (en orange ) dans l’UI.
• Enfin, et c’est très important, nous ne remplissons QUE le paramètre REPORTED et non FAILED.

A noter : Les states messages doivent être invalidés afin qu’ils ne soient pas ajoutés en continu à une structure REPORTED si la même requête est déclenchée plusieurs fois sur la même instance, ou si le message d’erreur a été corrigé.

Pour cela nous avons ajouté ce bout de code :

   APPEND VALUE #( %tky = read-%tky
                %state_area = if_abap_behv=>state_area_all ) TO reported-zrcrttest.

III. Tests et analyses

Suite à notre développement voici le résultat sur l’UI :

Une Popup apparaît bien demandant la validation à l’utilisateur.

On note qu’effectivement le message retour de l’action Activate est un 412 : Précondition Failed

Et on retrouve le message d’erreur configuré dans le body de réponse :

Après l’affichage du message d’erreur, 2 choix s’offre à l’utilisateur :

• Annuler l’opération : Dans ce cas il retourne sur la page précédente avec les champs en surbrillance :

• Confirmer l’opération : Dans ce cas l’action Activate est relancée

Et l’entité est bien créée :

III. Juste pour tester

• Cas d’un transition message en ABAP RAP

Changeons maintenant le state message créé par un transition message au niveau de la validation :

Comme vu dans la documentation, il suffit d’enlever le champs %state_area = ‘WARNING’

  METHOD validation.

    READ ENTITIES OF zr_crt_test IN LOCAL MODE
  ENTITY zrcrttest
  ALL FIELDS
  WITH CORRESPONDING #( keys )
  RESULT DATA(results_read).

    LOOP AT results_read INTO DATA(read).
   APPEND VALUE #( %tky = read-%tky
                %state_area = if_abap_behv=>state_area_all ) TO reported-zrcrttest.
    IF read-Text IS INITIAL AND read-Text2 IS INITIAL.
     APPEND VALUE #( %tky = read-%tky
                      %msg = NEW zside_effect_message(
                                 textid = zside_effect_message=>missing_value
                                 severity = if_abap_behv_message=>severity-warning )
                      %element-text  = if_abap_behv=>mk-on
                      %element-text2    = if_abap_behv=>mk-on
                    ) TO reported-zrcrttest.

   ENDIF.
    ENDLOOP.

  ENDMETHOD.

avec ce cas nous n’avons désormais plus de popup de validation qui apparaît. Seulement un popup d’information, ce qui n’a pas de sens ici car l’instance est créée sans avoir eu l’accord du user.

On observe également que l’action Activate a retourné un code HTTP 201 et non 412

• Dans le cas où nous ajoutons le paramètre FAILED

  METHOD validation.

    READ ENTITIES OF zr_crt_test IN LOCAL MODE
  ENTITY zrcrttest
  ALL FIELDS
  WITH CORRESPONDING #( keys )
  RESULT DATA(results_read).

    LOOP AT results_read INTO DATA(read).
   APPEND VALUE #( %tky = read-%tky
                %state_area = if_abap_behv=>state_area_all ) TO reported-zrcrttest.
    IF read-Text IS INITIAL AND read-Text2 IS INITIAL.
     APPEND VALUE #( %tky = read-%tky
                      %msg = NEW zside_effect_message(
                                 textid = zside_effect_message=>missing_value
                                 severity = if_abap_behv_message=>severity-warning )
                      %state_area = 'WARNING'
                      %element-text  = if_abap_behv=>mk-on
                      %element-text2    = if_abap_behv=>mk-on
                    ) TO reported-zrcrttest.
                    APPEND VALUE #( %tky = read-%tky  ) TO FAILED-zrcrttest.

   ENDIF.
    ENDLOOP.

  ENDMETHOD.

Alors dans ce cas la popup n’apparaît pas et l’utilisateur ne peut pas sauvegarder l’instance

Le code retour de l’appel HTTP pour l’action Activate est 400 Bad Request.

Conclusion

Nous avons pu voir qu’il est possible via RAP et Fiori Elements de demander l’approbation de l’utilisateur pour effectuer une création / modification d’une entité si une validation retourne un Warning. Pour cela, la création d’un State Message dans la validation est suffisant et le framework s’occupe du reste !