Table des matières

1 WORKFLOW....................................................................................................................................5

1.1 PRINCIPE DE FONCTIONNEMENT.............................................................................................................5

1.1.1 Sous-workflows..........................................................................................................................7

1.2 DÉCLENCHEMENT D’UN WORKFLOW.......................................................................................................8

1.3 CONTENEUR PRINCIPAL......................................................................................................................10

1.4 FLUX DE DONNÉES............................................................................................................................10

1.5 PARAMÉTRAGE.................................................................................................................................13

1.5.1 Lien événement/récepteur.......................................................................................................13

1.6 ANALYSE DU PROTOCOLE D’EXÉCUTION.................................................................................................13

1.7 DEBUG ET RESOLUTION DES ERREURS....................................................................................................15

1.7.1 Debug......................................................................................................................................15

1.7.2 Activation et buffer..................................................................................................................15

1.7.3 Cohérence des tâches..............................................................................................................15

2 FOCUS SUR LES ÉVENEMENTS........................................................................................................17

2.1 EVÉNEMENT PRINCIPAL......................................................................................................................17

2.2 SOUS-WORKFLOWS ET ÉVÉNEMENTS LOCAUX.........................................................................................17

2.3 POURQUOI LE SYSTÈME NE SE MÉLANGE PAS ENTRE PLUSIEURS INSTANCES ?................................................18

2.4 TRACE DES ÉVÉNEMENTS....................................................................................................................19

3 JOBS..............................................................................................................................................21

3.1 GESTION DES DÉLAIS..........................................................................................................................21

3.2 GESTION DES CONDITIONS..................................................................................................................21

3.3 NETTOYAGE DES WORKITEMS ORPHELINS...............................................................................................21

4 VOCABULAIRE...............................................................................................................................22

4.1 WORKFLOW....................................................................................................................................22

4.2 INSTANCE DE WORKFLOW...................................................................................................................22

4.3 OBJET BOR.....................................................................................................................................22

4.3.1 Présentation............................................................................................................................22

4.3.2 Délégation d’un objet..............................................................................................................24

4.4 CONTENEUR....................................................................................................................................24

4.5 WORKITEM......................................................................................................................................25

4.6 TÂCHE STANDARD.............................................................................................................................25

5 TRANSACTIONS UTILES..................................................................................................................27

1 Workflow

1.1 Principe de fonctionnement

Ce paragraphe présente une rapide synthèse du déclenchement et du fonctionnement d’un workflow :

Un événement est déclenché lors de certaines actions (par exemple lors de la création d’une commande, lors d’une entrée de marchandises)

L’événement est intercepté par une ou plusieurs définitions de workflow Une instance de cette définition de workflow est créée dans le système et démarre la

cinématique Les acteurs du workflow reçoivent des notifications ou des décisions à prendre Le workflow se termine lorsqu’on atteint la dernière étape ou qu’une des étapes met fin

artificiellement au workflow

La definition d’un workflow est accessible en SWDD

EXEMPLE d’APERÇU GRAPHIQUE

Sauvegarde Evénement « RELEASESTEPCREATED »

généré

Interception par le workflow

Création d’une instance de workflow

1.1.1 Sous-workflows

Un workflow complexe dans sa conception met en œuvre de nombreuses étapes. Pour faciliter sa lisibilité et sa maintenance, certains blocs d’étapes sont groupés en sous-workflows. Ainsi, la colonne vertébrale est le WF principal et il porte l’aspect général du déroulement, et les sous-workflows permettent de détailler les processus plus finement.

Les sous-workflows sont déclenchés par des événements locaux (cf § événements), propres au workflow, pas par des événements extérieurs.

1.2 Déclenchement d’un workflow

Un WF peut être déclenché directement par un programme par exemple Il peut aussi être en attente d’un événement et se déclencher lorsque cet événement est généré.

Lorsque cet événement est généré dans le système, les objets qui l’écoutent sont lancés.

Exemple d’attente d’événement

Un événement est déclenché de la manière suivante :

Lien actif = Cette activation peut être réalisée directement à cet endroit, ou par le paramétrage. Les deux modes s’impactent mutuellement puisqu’ils pointent sur la même table. cf § « paramétrage ».

Flux de données = il s’agit du transfert des paramètres de l’événement vers le WF.

Certains paramètres sont remplis automatiquement par le système (« &_EVT_CREATOR& » et « &_EVT_OBJECT& »), les autres sont spécifiques à l’événement. Le « &RELEASECODE& » a été renseigné dans la fonction ME_REL_EVENT_EKKO

Condition = condition de déclenchement du WF. La réception de l’événement n’est pas suffisante pour déclencher le WF. Si une condition existe, il faut aussi qu’elle soit vérifiée.

1.3 Conteneur principal

Le conteneur principal contient les variables « globales » du workflow. En plus des éléments créés par le standard et non modifiables, d’autres peuvent être ajoutés. Ils apparaissent alors différemment :

1.4 Flux de données

Les flux de données permettent l’échange d’informations entre les conteneurs

des événements du workflow principal des sous-workflows (si besoin, non utilisé ici) des tâches des méthodes

Pour qu’une donnée du WF principal soit utilisable dans une methode, il faut la transmettre d’abord à la tâche, puis à la méthode. Les paramètres peuvent être import/export puisque le WF peut aussi récupérer des valeurs retournées par une méthode.

Evenement->WF

Conteneur de l’événement (accessible dans l’objet BUS2012)

Réception par le workflow

WF<->tâche

Conteneur de tâche (accessible en PFTC)

Les flèches à gauche de l’élément indique le caractère import/export.

Tâche<->méthode

Conteneur de méthode

Lecture/ecriture des paramètres :

1. Un paramètre d’import est lu via

2. Un paramètre d’export est écrit via

1.5 Paramétrage

1.5.1 Lien événement/récepteur

Les événements standards sont générés quoi qu’il arrive. Pour pouvoir les exploiter, il faut activer le lien avec un récepteur. Cette activation peut être réalisée par paramétrage, dans la SWETYPV ou dans le WF

directement au niveau de l’événement. Les deux modes s’impactent mutuellement puisqu’ils pointent sur la même table.

Si ce lien est désactivé, le workflow ne se déclenche pas.

1.6 Analyse du protocole d’exécution

Accéder au protocole du workflow :

L’activation d’un lien événement/workflow definition d’un workflow est réalisée en SWETYPV

Le protocole d’exécution peut être consulté en SWI2_FREQ

1.7 Debug et resolution des erreurs

1.7.1 Debug

Les étapes d’arrière-plan ne peuvent pas être analysées en debug, seulement par l’historique de WF qui donne quelques informations par ses différents onglets :

En revanche, on peut par exemple placer des points d’arrêt dans les tâches d’avant-plan.

1.7.2 Activation et buffer

Les objets doivent être activés convenablement.

o Le WF

o Les objets BOR doivent être générés Le buffer doit être à jour : transaction « SWU_OBUF » qu’on peut lancer manuellement si besoin.

o L’activation d’un workflow en SWDD lance automatiquement l’actualisation du buffer (vrai chez Aelia, mais à vérifier sur d’autres systèmes)

o La génération d’un objet BOR n’actualise pas le buffer, il faut lancer la SWU_OBUF manuellement

1.7.3 Cohérence des tâches

Les tâches ne nécessitent pas d’activation.

Des problèmes peuvent apparaitre lorsqu’on touche à l’objet BOR sans vérifier les tâches qui utilisent ces méthodes.

Exemple

On crée une méthode M1. On crée une tâche T1 qui appelle cette méthode et on utilise cette tâche dans le WF. On supprime ensuite la méthode M1. Le système n’avertit pas qu’une tâche l’utilise, on peut donc valider cette suppression => résultat : à l’exécution le WF plante. Si on revient sur la tâche, un contrôle de syntaxe indique en effet que la méthode utilisée n’existe pas.

2 Focus sur les évenements2.1 Evénement principal

Les événements de workflows sont lancés par le standard dans différentes situations. Ils sont ensuite récupérés ou non par des WF actifs, via le lien événement/récepteur (SWETYPV, cf § dédié). Un même événement pourrait donc être reçu par plusieurs définitions de WF. Si on souhaite utiliser un workflow par type de commande par exemple, on peut ajouter une condition de déclenchement en entete du WF :

2.2 Sous-workflows et événements locaux

Les sous-workflows ne peuvent être lancés que par des évènements locaux. Ces événements doivent d’abord être déclarés en entête du WF principal pour pouvoir être utilisés :

Il faut basculer sur cet onglet puis

L’appel d’un sous-workflow est asynchrone. Contrairement à un « perform », le système n’attend pas la fin du sous-workflow pour continuer le traitement principal. La seule parade pour réaliser ça est de mettre le WF principal en attente d’un événement local, qui sera généré dans le sous-workflow.

Exemple

On appelle le sous-workflow de décision dans lequel un valideur doit valider ou refuser (avec saisie des commentaires, erreurs etc…). Sans évènement d’attente, le traitement principal se poursuivrait immédiatement sans attente de réponse. On place donc cet événement d’attente dans le WF principal :

Lorsque le processus de décision est terminé, un événement local « DECISION_PRISE » est généré via cette

étape . Le WF principal peut alors reprendre son cours normal.

On remarque la différence entre événement généré/en attente via l’icône.

2.3 Pourquoi le système ne se mélange pas entre plusieurs instances ?

Si on a 2 commandes en cours de validation, avec 2 instances différentes de WF

Si on réalise une opération sur une des commandes, le système identifie clairement l’instance concernée

grâce à sa clé

Au moment de la génération de l’événement, la clé est transmise de cette manière :

Toutes les instances de WF en cours dans le système, et qui sont attente de cet événement comparent la clé reçu avec leur propre clé pour « savoir si l’événement leur est adressé ». Ainsi, seule l’instance liée à la commande traite l’événement, les autres instances restent en attente.

Par exemple

En modifiant une commande A donnant lieu à une nouvelle stratégie de validation, l’événement « SIGNIFICANTLYCHANGED » est généré. Même s’il existe à cet instant plusieurs instances de workflow dans le système (une pour la commande A et une pour la B), la clé de l’instance permet de l’identifier de manière unique. Ainsi, l’instance de la commande B ne traite pas l’événement reçu.

2.4 Trace des événements

Il est possible d’analyser les événements générés lors d’une sauvegarde :

Activer la trace par la transaction SWELS (avant les opérations sur la commande…)

Afficher les événements après avoir agi sur la commande, transaction SWEL

Activation de la trace : SWELS

Analyse des événements déclenchés : SWEL

3 Jobs3.1 Gestion des délais

Il est possible de définir des heures limites (minimum ou maximum) d'exécution d'un workitem:

L'heure maximale au-delà de laquelle le workitem doit être cloturé quoi qu'il arrive L'heure minimum en-deça de laquelle il ne peut être commencé ...

via ces onglets

La vérification de l'atteinte de ces délais est réalisée périodiquement par le programme RSWWDHEX lancé via le job SWWDHEX. Ce programme analyse tous les WI en cours possédant un délai dans leur définition, et détermine pour chacun si ce délai est dépassé.

Il est possible de lancer ce programme manuellement à n'importe quel moment.

3.2 Gestion des conditions

Il est possible de définir la génération ou la cloture d'un WI, en y ajoutant une condition, via l'onglet

. Dans ce cas, le WI n'est pas créé ou terminé immédiatement. C'est le job SWWCOND qui vérifie périodiquement les WI qui répondent au critère de condition.

On peut aussi lancer manuellement le programme RSWWCOND à la demande.

3.3 Nettoyage des workitems orphelins

Il peut arriver qu'un WF soit cloturé, mais que des WI restent actifs, donc éventuellement visibles dans la workplace des utilisateurs. Ceci peut se produire lorsqu'un utilisateur est en cours de traitement d'un workitem, et qu'une branche du WF ordonne la cloture technique du WF. Dans ce cas, le WI en cours de traitement ne peut pas être cloturé proprement par le système.

Ce problème est réglé par le job de purge SWWERRE, qui supprime les WI appartenant à des WF terminés.

4 Vocabulaire4.1 Workflow

Il s’agit d’une définition de cinématique. Par abus de langage, il s’agit parfois de l’instance d’un workflow.

Une définition de workflow est accessible en (ou PFTC)

4.2 Instance de workflow

Objet réel créé dans le système qui a une existence propre et identifie un objet en particulier (une commande par exemple) via une clé.

4.3 Objet BOR

Objet du Business Object Repository. Exemple : BUS2012

4.3.1 Présentation

Les workflows fonctionnent à partir d’objets du BOR (Business Object Repository), accessibles en SWO1. Ces objets identifient une entité cohérente. L’objet « commande d’achat » est représenté par l’objet « BUS2012 » par exemple.

Un objet fonctionne comme une classe d’instance. Ce n’est qu’une définition de données. Pour l’utiliser, il faut une instance de cet objet. Ici, cette instance est créée lors du déclenchement de l’événement initial. Elle est identifiée de manière unique dans le système par un ID (une instance de workflow est aussi un workitem, qui possède un ID auto généré). La clé de l’instance permet de déterminer l’objet dont on parle. Exemple : une commande d’achat

L’objet standard peut être complété par de nouvelles méthodes. Pour ça, on crée un Z*** par héritage :

Tous les attributs, méthodes et événements sont repris. On peut ensuite en ajouter des nouveaux, ou en remplacer :

Les objets du BOR sont accessibles en SWO1

4.3.2 Délégation d’un objet

Pour indiquer au système qu’il faut utiliser l’objet Z*** à la place du BUS***, on utilise la délégation. Elle se fait par l’écran initial de la SWO1

Après cette opération, tous les accès au BUS2012 sont remplacés par ZBUS2012 :

Exemple : La délégation permet d’avoir accès à la méthode GETLANCMANUEL

qui n’est pourtant pas présente dans le BUS2012, mais dans le ZBUS2012

4.4 Conteneur

Ensemble de variables utilisées pour l’objet concerné. Il existe des conteneurs à tous les niveaux :

Evénement Workflow

Un élément du conteneur de workflow peut être mis à jour en retour d’une tâche via le flux de données (cf § « flux de données ») ou directement par une étape de WF comme celle-ci :

Opération : CPTRELANCES = CPTRELANCES + 1

Tâche Méthode

Les variables qu’ils contiennent peuvent être en import et/ou export, obligatoires ou non.

Dans une méthode, la lecture/ecriture des paramètres se fait de la manière suivante :

o Un paramètre d’import est lu via

o Un paramètre d’export est écrit via

4.5 Workitem

Lors de l’exécution d’un workflow, les étapes présentes dans la définition du WF génèrent des workitems (WI), qui représentent des vraies tâches à effectuer (envoi d’un mail, envoi d’une décision à un utilisateur, opération sur une commande etc…)

Un workitem est identifié par un ID unique. On peut chercher les WI affectés à un utilisateur dans la table SWWWIHEAD.

4.6 Tâche standard

Une tâche permet d’effectuer un traitement dans une étape de workflow. En plus des étapes de condition, branches parallèles etc…, on peut par exemple envoyer un mail, rechercher une information, mettre à jour une donnée. On utilise alors une tâche, gérée via PFTC. Leur nom est ambigü puisqu’on parle de tâche standard même si elles sont spécifiques.

Leur numéro est généré automatiquement et commence par 9*

L’intérêt d’une tâche est d’appeler une méthode d’un objet du BOR. Une tâche comporte un conteneur (variables d’import/export permettant de dialoguer avec le WF qui l’appelle et la méthode qu’elle exécute).

Les tâches sont gérées en PFTC (ou PFTC_DIS/PFTC_CHG/PFTC_INS)

5 Transactions utiles5.1 SWDD   : définition d’un workflow

5.2 SWO1   : objet du BOR

5.3 PFTC   : tâches

5.4 SWDM   : Permet de lister les tâches qui utilisent des méthodes d’un objet du BOR

5.5 SWU_OBUF   : actualisation du buffer

5.6 SWI2_FREQ   : log d’exécution des WF

o Période : indiquer un jour précis ou un intervalleo Décocher « dialogue » et cocher « WF/sous-WF » pour aggrérer l’affichage par type de WF

(sinon toutes les taches sont affichées, c’est assez fouilli)

On peut éventuellement préciser le WF qu’on souhaite afficher en utililisant la zone tache. On peut alors saisir directement l’ID du WF ou le rechercher

Liste des types de WF

Les WF apparaissent par type

Instances de WF actives/terminées/erronées

En double-cliquant sur l’un d’eux, on affiche toutes les instances de WF créées sur la période :

L’affichage est paramétrable évidemment.

En sélectionnant une instance puis , on affiche alors le protocole.

Modification de l’affichage du protocole

L’affichage par défaut est trop simple, mieux vaut l’améliorer avec puis choisir « vue

technique »

5.7 SWELS   : activer la trace d’un WF

o On peut indiquer simplement l’objet à analyser. Tous les événements liés à cet objet seront tracés. C’est la méthode la plus générique.

o Attention, les dates par défaut ne sont pas la date du jour !

5.8 SWEL   : affichage de la trace

5.9 SWEC

5.10 SWETYPV   : activation du WF pour déclenchement sur un événement

Voir le chapitre « lien événement/récepteur »