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 »
Top Related