Les documents de modification sont générés par les création, modification et suppression des objets de gestion (commande d'achat, utilisateurs, clients, ...).

Ces documents de modification sont stockés dans les tables CDHDR et CDPOS.

Les documents sont générés parce que certaines tables sont "surveillées".

Prenons l'exemple ci-dessus avec l'objet IDENTITY.

Dans la transaction SCDO, nous pouvons voir quelles sont les tables sous surveillance.

Pourtant, seulement certains champs génèrent un document de modification, pourquoi ?

Allons voir pour la table SUID_CD_ZBVSYS certains des champs qui la compose.

Si nous prenons les composants XUBNAME et RFCRCVSYS.

Sur la tabulation Further Characteristics (Données supplémentaires)

Nous pouvons voir que le flag Change Document n'est pas coché pour XUBNAME ce qui signifie que les changements ne généreront pas de document.

Alors que la composante RFCRCVSYS a ce flag coché, et déclenchera en cas de modification un document de modification.

RFCRCVSYS pourra donc servir pour le déclenchement d'un événement mais pas XUBNAME.

Certains liens existent livrés par SAP, vous pouvez les voir dans la transaction SWEC.

Ici le document de modification EINKBELEG correspond à un document d'achat. Nous pouvons voir qu'il peut être lié avec un ou plusieurs objet de workflow (BUS2012, FREBUS2012,...) ainsi qu'à un ou plusieurs événements pour chaque objet (CHANGED, CREATED,..).

Ensuite, les dernières colonnes indiquent pour quels types de modification l'événement sera déclenchés (Création, Modification ou suppression).

Toutes les modifications ne doivent pas déclencher un workflow, certains doivent être ignorés, d'autres doivent être combinées (deux champs modifiés), d'autres doivent avoir certaines valeurs.

Pour cela sélectionner, la ligne que vous souhaitez restreindre, et cliquez sur la partie gauche sur Restrictions.

Puis cliquez sur le bouton Edit. conditions.

Pour cela sélectionner, la ligne que vous souhaitez restreindre, et cliquez sur la partie gauche sur Restrictions.

Puis cliquez sur le bouton Edit. conditions.

Les champs disponibles pour les comparaisons apparaissent

Vous pouvez vous servir de l'éditeur de condition pour effectuer des comparaisons entre les anciennes valeurs (_old) et nouvelles valeurs de champs (_new).

Vous allez pouvoir les grouper, et les liées avec des opérateurs logiques (OR / AND - Not)

N'oubliez pas que le regroupement des expressions liées par un AND imposera que les deux champs soient présents dans le document de modification.

De temps en temps, le document de modification contient l'objet du workflow mais celui n'est pas l'objet lui même. Or il faut faire correspondre les clés des deux objets.

Pour se faire, SAP permet dans la transaction SWEC l'utilisation de différents modules fonctions du cas :

Pour déterminer le type d'objet le module fonction SWE_CD_TEMPLATE_OBJTYPE_FB_2 sert de modèle.

Pour le nom de l'événement, il faudra prendre SWE_CD_TEMPLATE_EVENT_FB_2.

Pour rechercher certains paramètres et accéder au container, SWE_CD_TEMPLATE_CONTAINER_FB_2.

Si il s'agit de modifier la clé de l'objet alors c'est à partir de la transaction SWED et le module fonction servant de modèle est le SWE_CD_TEMPLATE_OBJKEY_FB_2.

Le système utilise les zones suivantes

• CD_OBJECTCLAS (Objet du Document de modification)

• CD_OBJECTID (La clé du document de modification)

• CD_CHANGENR (Le numéro du document de modification)

En inscrivant comme paramètre de l'événement ces champs ils seront accessibles dans le workflow et permettront un accès complet au document de modification.

En modifiant le business Object dans le business object repository (SWO1), nous pouvons même obtenir les anciennes et nouvelles valeurs d'un champs du document de modification.

Pour cela, il faut créer un attribut de type Database Attribute il faut que la référence au champs soit identique que dans le document de modification. Puis le paramètres de l'événement doit avoir le même nom que l'attribut mais être de type multi-ligne.

Quand l'événement sera instancié, l'index 0001 sera remplie avec l'ancienne valeur, et l'index 0002 avec la nouvelle.

Deux types d'objets sont utilisés aujourd'hui dans les Business Workflows :

• BOR - Business Object (SWO1)

• Classe - ABAP OO (SE24)

Les événements sur document de modification peuvent être lancés sur ces deux types d'objet.

Il existe une procédure assistée pour la mise en place du lien entre les documents de modifications et les événements. Il s'agit de la transaction SWU_EWCD.

Les documents de modification sont générés par le système, ils sont une source importante pour les workflows. Peu d'ABAPEUR connaissent l'existence de la SWEC et de ses possibilités.

Pourtant quand on sait également qu'un workflow peut déclencher un programme, cela pourrait permettre de sauver beaucoup de temps pour réagir suite à une modification.

De plus un workflow réagit tout de suite à un événement et individuellement.

Le workflow peut gérer les erreurs de traitement, les valeurs interdites.

Servez-vous des documents de modification, ils sont déjà dans le système !