Modules fonction appelés pour le routage technique lors de la réception d'idocs (inbound donc) :
IDOC_INBOUND_ASYNCHRONOUS
pour les transfert immédiatsIDOC_INBOUND_IN_QUEUE
pour les queuesL'extension d'idoc requière les étapes suivantes :
NB : Les définitions des segments et des types peuvent être released ou not released. Dans le cas d'objets déjà released, il faut se demander s'il vaut mieux modifier l'existant ou créer de nouveaux objets (si un segment est utiliser dans de nombreux types d'idoc et qu'il ne doit pas être changé partout, il vaut mieux faire une nouvelle version. Dans le cas contraire, on peut se permettre de modifier la version existante en faisant Edit
> Cancel release
).
NB : Les transaction suivantes sont disponibles dans le menu wedi
> Development
En WE31
, créer ou éditer le segment. Ajouter/enlever/modifier les champs. Sauvegarder. Releaser.
En WE31
, créer ou éditer le type. Ajouter/enlever/modifier les segments. Sauvegarder. Releaser.
Créer le type de message en WE81
si nécessaire. Lier le type de base et l'extension en WE82
.
Une fois toutes les définitions créées et liées, il faut alimenter les champs des nouveaux segments via un user exit.
Exemple sur la fiche client : le user-exit VSV00001
, FM EXIT_SAPLVV01_001
.
Le user-exit est appelé sur chaque segment.
Il faut vérifier le message type et l'idoc type puis le segment. A chaque segment on accède aux data des segments précédents. Pour alimenter un segment spécifique, il faut veiller à l'insérer dans la table représentant l'idoc au bon endroit (c'est-à-dire en respectant notamment la définition de l'idoc en WE30
).
Si l'alimentation de ce segment nécessite des données qui ne sont pas encore présentes au moment d'insérer le segment, il faut tout de même insérer le segment spécifique. Lorsque le segment nécessaire sera disponible, on mettra à jour le segment spécifique (via un field-symbol, par exemple).