Business Workflow : récupérer les workitems en cours

Si vous souhaitez récupérer tous les workitems d’une instance workflow en cours, vous pouvez alors utiliser le module fonction « SAP_WAPI_WORKITEMS_TO_OBJECT ».

Publicités

Business Workflow : terminer une instance workflow

Si vous souhaitez mettre un terme à une instance workflow en cours, vous avez la possibilité de l’annuler à l’aide du module fonction « SWW_WI_ADMIN_CANCEL ».

CALL FUNCTION ‘SWW_WI_ADMIN_CANCEL’
EXPORTING
wi_id = iv_wiid
EXCEPTIONS
update_failed = 1
no_authorization = 2
infeasible_state_transition = 3
OTHERS = 4.

IF sy-subrc EQ 0.
COMMIT WORK.
ENDIF.

Business Workflow : mettre un workflow en attente et le redémarrer via un événement spécifique

Lorsque vous développez un workflow, vous pouvez être amené à vouloir mettre en attente votre workflow pour le redémarrer ultérieurement lors d’un événement particulier (cela est par exemple le cas si vous souhaitez initier un workflow et le mettre immédiatement en attente à la création d’un document pour le redémarrer plus tard (à la validation du document, suivant une action manuelle utilisateur, etc.)).

Entrez en modification sur votre Business Object et créez l’événement permettant le redémarrage du workflow :

Renseignez les informations générales de l’événement :

Procédez à l’implémentation de l’événement :

L’événement est implémenté :

Entrez en modification sur votre workflow et créez votre étape d’attente :

Spécifiez l’élément de conteneur (correspondant généralement à l’objet BOR principal de votre workflow) ainsi que l’événement permettant le redémarrage du workflow) :

L’étape d’attente est ajoutée :

Une fois le workflow démarré, on peut voir que celui-ci est immédiatement en attente :

Nous pouvons vérifier cela via le protocole du workflow :

On récupère la clé du Business Object pour pouvoir le redémarrer :

Relance du workflow (via bapi SWE_EVENT_CREATE) :

Le workflow est relancé :

On peut vérifier cela via le protocole du workflow :

Exemple d’utilisation de la bapi « SWE_EVENT_CREATE »

REPORT  ylaunch_wkf.

PARAMETERS:
p_pernr     TYPE pernr_d,
p_tripno    TYPE reinr.

TYPES:
* Déclaration des types locaux :
BEGIN OF lty_objkey,
pernr     TYPE pernr_d, « Matricule
tripno    TYPE reinr,   « N° déplacement
END OF lty_objkey.

DATA:
* Déclaration des structures locales :
stl_objkey  TYPE lty_objkey,
* Déclaration des variables locales :
lv_objkey   LIKE sweinstcou-objkey.

stl_objkey-pernr = p_pernr.
stl_objkey-tripno = p_tripno.

lv_objkey = stl_objkey.

CALL FUNCTION ‘SWE_EVENT_CREATE’
EXPORTING
objtype = ‘BUS2089’
objkey = lv_objkey
event = ‘TRIPREQUESTED’
* CREATOR = ‘ ‘
* TAKE_WORKITEM_REQUESTER = ‘ ‘
* START_WITH_DELAY = ‘ ‘
* START_RECFB_SYNCHRON = ‘ ‘
* NO_COMMIT_FOR_QUEUE = ‘ ‘
* DEBUG_FLAG = ‘ ‘
* NO_LOGGING = ‘ ‘
* IDENT =
* IMPORTING
* EVENT_ID =
* TABLES
* EVENT_CONTAINER =
EXCEPTIONS
objtype_not_found = 1
OTHERS = 2
.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ELSE.
WRITE ‘Event Triggered’.
ENDIF.
COMMIT WORK.

 

Business Workflow : délégation

Lorsque l’on créé un workflow se basant sur un Business Object, on peut avoir besoin de customiser ce dernier. Pour ce faire, nous allons créer un nouveau Business Object en tant que sous-type du Business Objet d’origine et pour lequel on appliquera une délégation afin que ce nouveau Business Object (customisable à souhait) soit automatiquement utilisé en lieu et place de l’original.

Tout d’abord, dirigez-vous en SWO1, renseigner le nom de votre Business Object d’origine et cliquez sur le bouton « Sous-type » :

Renseignez les informations concernant le Business Object à créer :

Passez le statut de libération du type d’objet à « Implémenté » :

Le Business Object étant désormais créer, il nous faut maintenant l’assigner en tant que délégué du Business Object d’origine. Pour ce faire, dirigez-vous dans le menu « Options » et sélectionnez « Délégation » :

Passez en mode modification :

Cliquez sur « Nouvelles entrées » :

Assignez enfin votre Business Object fraîchement créé en tant que type de délégation du Business Object d’origine :

C’est tout ! Ainsi, dès lors que le Business Object d’origine sera sollicité, on passera désormais automatiquement par votre Business Object custom et non plus par celui d’origine 😉

Business Workflow : récupération d’un Workitem ID

Une fois un workflow lancé, il est parfois nécessaire de pouvoir avoir accès à son conteneur afin de le lire ou de le modifier. Pour ce faire, nous avons besoin de récupérer le workitem ID.

Le workitem ID peut être récupéré à l’aide de la bapi SAP_WAPI_WORKITEMS_TO_OBJECT via les paramètres suivants :

  • Type d’objet (OBJTYPE)
  • Clé d’objet (OBJKEY)

Les workitems ID correspondant sont retournés dans la table WORKLIST :

Business Workflow : tracer les événements exécutés durant une transaction

Dans un très grand nombre de transactions standards, SAP lance différents évènements d’objets BOR.

C’est par exemple le cas :

  • A la création/modification d’une commande de vente
  • A la création/modification d’un article
  • Etc.

Une fois ces évènements identifiés, libre à vous de les lier à un workflow (standard ou spécifique) afin que ce dernier puisse être démarré dès lors que l’évènement en question aura été lancé.

Identification des évènements lancés durant une transaction

Pour pouvoir identifier de façon certaine le ou les évènements lancés durant l’exécution d’une transaction, il vous faut procéder à une trace d’évènements.

Pour ce faire, lancer la transaction SWELS (Event Trace) et cliquez sur « Activer » :

La popup suivante devrait alors apparaître, validez :

Exécutez ensuite votre transaction pour laquelle vous souhaitez identifier les événements lancés, revenez en SWELS (Event Trace) et désactivez votre trace :

La trace étant maintenant enregistrée, il nous faut l’afficher. Pour ce faire, lancez la transaction SWEL (Afficher trace des évènements) :

On distingue alors les évènements lancés avec leurs objets BOR :

Business Workflow : objets et pièces jointes, attacher un lien vers une transaction

A un workitem peut être attaché un ensemble d’objets et pièces jointes :

Nous allons voir aujourd’hui comment attacher un objet qui, lorsque l’on cliquera dessus, nous renverra vers la transaction de notre choix pour un document donné.

Prenons par exemple la transaction TRIP (création d’une demande de déplacement pour un employé) et disons que dès lors qu’une demande de déplacement est faite par l’employé, son manager doit automatiquement recevoir une demande d’autorisation par le biais d’un workitem. Ce workitem devra permettre d’accéder à la transaction TP04 (Demande de déplacement) pour la demande de déplacement concernée.

L’objet pour lequel on souhaite effectuer un CALL TRANSACTION correspond en fait à un objet BOR. En effet, globalement il suffit d’assigner un objet BOR à la liste des pièces jointes de la tâche pour que celui-ci apparaisse automatiquement à la liste des objets et pièces jointes. Lors du clic sur celui-ci, on passera alors dans la méthode DISPLAY de cet objet BOR, méthode au sein de laquelle on aura implémenté notre CALL TRANSACTION.

Création de l’objet BOR

Vous l’aurez compris, la première étape consiste en la création de notre objet BOR qui nous permettra de gérer le CALL TRANSACTION. Pour rappel nous souhaitons donc pouvoir accéder à la transaction TP04 pour la clé matricule/numéro de demande de déplacement.

Création de l’objet BOR en SWO1 :

Création des zones clés :

Lorsque l’on cliquera sur notre objet lié, la méthode DISPLAY de l’objet BOR est automatiquement exécutée, il convient donc de la surcharger en la sélectionnant puis « Traiter >>> Surdéfinir » :

Implémentez-y votre CALL TRANSACTION :

Faites ensuite un petit test :

Ça fonctionne, votre objet BOR est prêt !

Instanciation de l’objet BOR

Notre objet BOR n’est pas l’objet BOR principal de notre workflow. En effet, cet objet n’a été créé qu’afin de nous permettre de pouvoir gérer notre objet attaché et son CALL TRANSACTION. Il nous faut donc prévoir son instanciation. Nous allons gérer cela par l’intermédiaire d’une classe objet.

Création de la classe objet :

Création de la méthode statique d’instanciation de l’objet BOR :

Nous allons ensuite créer une méthode statique chapeau qui appellera notre méthode GET_GENERIC_BOR_INSTANCE et qui sera elle-même appelée dans notre workflow :

Création de la tâche

Nous allons maintenant créer la tâche permettant l’instanciation de l’objet BOR en PFTC :

Dirigez-vous sur l’onglet « Conteneur » et vérifiez que l’objet est bien de type BOR :

Cliquez sur l’icône avec les carrés verts pour effectuer le mapping :

Votre tâche est prête, allez hop on passe au workflow !

Workflow

Entrez en modification sur votre workflow et commencez par créer un nouvel élément dans votre conteneur et correspondant à votre objet BOR spécifique :

Nous allons maintenant créer une nouvelle activité nous permettant d’appeler notre tâche fraichement créée afin de pouvoir instancier notre objet :

Renseignez y votre tâche créée précédemment et cliquez sur « Flux de données (existant) afin d’effectuer le mapping :

Entrez maintenant en modification sur la décision utilisateur afin d’y ajouter l’objet BOR dans la liste des objets liés :

Accédez au flux de données :

Mappez l’objet BOR à l’élément _ATTACH_OBJECTS :

Et voilà, pour le reste ça se fait tout seul, comme on dit y a plus qu’à 😉

Business Workflow : utilisation de classes ABAP

Lorsque l’on définit un Business Workflow, on a la possibilité d’utiliser des classes ABAP au même titre que des objets BOR (Business Object Repository).

La première étape consiste en la création d’une classe ABAP via la transaction SE24 :

Cette classe doit avoir pour interface IF_WORKFLOW (les interfaces BI_OBJECT et BI_PERSISTENT remontent automatiquement) :

Il convient dans un premier temps d’ajouter les attributs suivants :

  • CLASS_NAME : constante privée de type SEOCLSNAME (Nom de type d’objet)
  • POR : attribut protégé de type SIBFLPOR (Référence d’objet persistante locale)
  • DESCRIPTION : attribut privé de type SYST-TITLE (Contenu de la ligne de titre)

On pourra ensuite ajouter les attributs propres à notre besoin, par exemple ici :

  • MATERIAL : attribut public de clé de type MARA-MATNR (Numéro d’article)
  • MATERIAL_TYPE : attribut public de type MARA-MTART (Type d’article)
  • INDUSTRY : attribut public de type MARA-MBRSH (Branche)

Vous remarquerez un certain nombre de méthodes pouvant être implémentées provenant de l’interface BI_PERSISTENT. Nous n’implémenterons pour ce cas que la méthode BI_PERSISTENT~LPOR. Nous créerons ensuite le constructeur ainsi que la méthode CREATE_INSTANCE.

Création de l’instance (lors de l’exécution du workflow) :

Constructeur (assignation des différents attributs) :

Assignation des attributs :

Récupération du Local Persistent Object Reference :

Evénement déclencheur du workflow :

La deuxième étape consiste en la création de la tâche standard workflow via la transaction PFTC :

On fera ainsi référence à la méthode CREATE_INSTANCE de notre classe fraîchement créée :

Après avoir cliqué sur le bouton contenant les deux carrés vert, on pourra alors définir le mapping des paramètres :

La troisième étape consiste en la création du workflow lui-même via la transaction SWDD :

Accéder aux données de bases, onglet « Indépendance de la version (tâche) » puis au sous-onglet « Evénements déclencheurs » afin de définir l’événement déclencheur du workflow ainsi que son mapping. On précisera alors la classe ABAP ainsi que l’événement :

Après avoir cliqué sur le bouton contenant les deux carrés vert, on pourra alors définir le mapping des paramètres :

Créer une nouvelle activité en y précisant l’ID de la tâche créée précédemment puis cliquer sur « Flux de données (existant) :

Après avoir cliqué sur le bouton contenant les deux carrés vert, on pourra alors définir le mapping des paramètres comme ci-dessous :

Double cliquer sur l’ID de la tâche pour entrer en modification afin d’observer le paramétrage de la tâche effectué précédemment en PFTC :

Procéder de la façon suivante pour déclencher l’événement :

Le workflow apparaît ainsi dans la SAP Business Workplace :

Voilà pour le principe de base, je vous laisse maintenant aller un peu plus loin dans la réflexion et jouer avec tout cela pour mieux exploiter le concept de l’utilisation d’une classe objet dans la construction de votre workflow 😉