Table of Contents
Configuration ALE et idocs
Accords d'interchange
Les accords d'interchange ou Partner profiles sont le centre de la configuration ALE. Ils servent à router les idocs entrants et sortants.
Il en existe plusieurs types.
Les accords d'interchange sont stockés dans les tables EDPP1, EDP13 et EDP21.
Les accords peuvent être générés semi automatiquement via la BD64 (distribution model). NB : dans ce cas il faut que les destination RFC respectent le nommage SIDCLNTMDT (ex. : DE1CLNT001).
Logical Systems
Les accords de type système logique sont utilisés pour adresser des partenaires externes (systèmes legacy ou PI/PO). Le système nécessite d'être configuré en BD54 avant que l'accord correspondant ne soit créé.
Détermination de l'accord
Idoc entrant
Un idoc entrant est routé en fonction de certains champs qui doivent correspondre aux inbound parameters d'un accord précis :
| IDoc Field | Partner profile field |
|---|---|
| SNDPRN | Partner No. |
| SNDPRT | Partn. Type |
| SNDPFC | Partner Role |
| MESTYP | Message Type |
| MESCOD | Message code |
| MESFCT | Message function |
| TEST | Test |
Astuces
Interco.
Pour les accords intercompany, lorsqu'il faut que les idocs rebondissent vers le même ECC, il faut que le port soit mappé vers une connexion RFC vide.
Process codes
Les process codes (dans les [in/out]bound parametters) sont dépendant des type d'idoc de base. Il faut donc faire attention de choisir le type d'idoc adéquat, qui n'est pas forcément la dernière version.
Quelques process codes classiques :
| Message type | Process code |
|---|---|
| MATMAS | MATM |
| ORDERS | ORDE |
| COND_A | COND |
| CHRMAS | CHRM |
| CLSMAS | CLSM |
| INVOIC | INVF |
| INVOIC | INVL |
Test
Transactions utiles :
- WE05 : Lister et voir le détail des idocs.
- WE19 : Rejouer des idocs.
Change pointers
Tcodes
- BD50 : Activation de change pointer par rapport à un message type.
- BD61 : Activation globale des change pointers.
- BD21 : Lancer des idocs en fonction des change pointers.
Idocs delta
Les idocs générés en delta notamment à partir de la BD21 sont en mode delta jusqu'à leur structure : ils ne contiennent que les segments qui ont subis des changements (extraits des change pointers via les change docs).
NB: Pour envoyer des idocs complets en mode delta, l'une des méthodes les plus faciles consiste à faire un programme simple qui récupère les ID des objets désirés selon les change docs puis de lancer un programme d'envoi tel que la BD12 par exemple (via un submit).
Change documents
Les change pointers sont tributaire des change documents.
Faire du spé avec les change pointers
Suivre ce tuto.
Modèle de répartition
Transaction BD64. Source
- Créer les systèmes logiques (des 2 côtés)
- Créer les connexions RFC (des 2 côtés)
- En BD 64, créer un nouveau modèle
- Dans le modèle, ajouter des message types
- Générer les accords dans le système
- Distribuer le modèle
- Vérifier les accords générés des 2 côtés
NB: Si la majorité des composants utilisant l'ALE reposent sur les accords d'interchange, ce n'est pas le cas des transactions BD* qui s'appuient sur le modèle de répartition ! (Autrement dit, même si les accords pour MATMAS sont bien présents, une BD20 ne fonctionnera pas sans le modèle de répartition correspondant !)