Evénement – Document de modification

water-drop1

Les documents de modification

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.

cdhrd_identity

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.

scdo_identity

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.

se11_suid_cd_zbvsys

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.

xubname

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

rfcrcvsys

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

Lien entre l’événement et le document de modification

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

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).

Restreindre les événements à certaines modifications

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.

swec_restrict

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.

swec_restrict1

Les champs disponibles pour les comparaisons apparaissent

swec_restrict2

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.

Objet de Modification et Objet de workflow

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.

Transaction SWEC

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

swec1

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.

Transaction SWED

swed

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.

Plus d’expertise…

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.

Encore plus…

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.

Autres Informations

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.

En conclusion

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 !

 

Publicités

Répondre

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s