Ginko's Work

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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'' ([[sap:idocs:bd64|distribution model]]). NB : dans ce cas il faut que les destination RFC respectent le nommage ''SID''''CLNT''''MDT'' (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 [[sap:change_documents|change documents]].
==== Faire du spé avec les change pointers ====
Suivre ce [[http://sapignite.com/what-is-change-pointer-in-sap/|tuto]].

===== Modèle de répartition =====
Transaction ''BD64''. [[http://wiki.scn.sap.com/wiki/display/ABAP/7+Steps+For+ALE+Configuration|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 !)//