Last edited: 1999-07-18 18:40 +0200
SAP uses the mechanism of releasing to fix the status quo of an Idoc definition for further modifications. This is necessary, because in a partner to partner communication, any modification must be followed on both ends of a communication link. generally, a modification of an already productive IDoc definition should result in the creation of a new version, which shall be identified by a different, proper name. So setting the release flag to true means, that the IDoc definition is final and accepted by all partners as the standard. As for any living entity the assigned name shall reflect the respective version forever. Any derivation or later modification should have an own and distinguished name.
SAP hat einen Mechanismus, um IDocs endgueltig festzuschreiben. Bevor IDocs das erste mal produktiv eingesetzt werden, muessen sie released werden, das ist im Grunde das Setzen eines READ-ONLY Flags. Damit soll verhindert werden, dass die IDocs geaendert werden, wenn sie schon mal im Einsatz waren. Weil fuer IDocs normalerweise zwei Partner gehoeren, dh. sie auf zwei Maschinen definiert werden muessen, muss jede Aenderung auch auf beiden Maschinen nachvollzogen werden. Um dies geordnet ablaufen zu lassen, ist das Vorgehen wie folgt: Anstatt einen freigegebenen (released) IDoc oder Segment-Typen zu aendern, legt man einen neuen, modifizierten IDoc-Typen an, eine sog. Version und sendet kuenftig die Daten mit dem neuem Segmenttyp. Solange die IDocs noch in der Entwicklung sind, sollte man sie auch nicht freigeben. Anders ausgedrueckt, die Freigabe bedeute, dass das IDoc endgueltig entwickelt und getestet ist, und von allen beteiligten EDI-Partner als Standard akzeptiert wurde. Wie jedes lebende Objekt, sollte der einmal gegebene Name das Objekt in seiner bestehenden Version für alle Zeiten bezeichnen. Jede Änderung oder Ableitung sollte deshalb einen eigenen, unterschiedlichen Namen erhalten.
| Changes of IDoc objects must be synchronously followed on sender and receiver side | Remember: The definition of IDoc segments and IDoc types are an agreement between the two completely independent communication partners, the sender and the receiver. Therefore any change in the structure of the IDoc definitions must be communicated and followed on both ends, the sender's one and the receiver's one. A unilateral change would inevitably lead into a misinterpretation on the receiver's side. |
| Releasing sets Idoc definitions on read-only | In order to avoid this delicate situation, SAP provides a functionality to make the IDoc definitions read-only, which is call "Release IDoc Types" and "Release IDoc Segments". These are menu actions of the appropriate maintainance transactions (WE30, WE31). If an IDoc type or segment is released, you will no longer be able to edit them. |
| Centralize the release of IDocs | Releasing and especially undoing the release is normally the task of the EDI administrator, i.e. the person who know the ways, means and agreements between sender and receiver of an IDoc. In order to avoid accidential release, this requires a special authorization profile (Berechtigungsprofil). |
There are two cases, that may occur.
| Put IDoc transmission on hiatus during modification | Case 1: You have simultanous access to all partners and the IDoc communication can be set on hiatus while you change the IDoc Definition. Then you may simply undo the release and edit the IDocs. |
| Create a new version with a different name | Case 2: If you continue the IDoc transmission during the reengineering period, then the solution is also simply and strict: you have to create a new version of the IDoc segments and IDoc type with a new name. When the development has finished, then you customize the inbound and outbound rules on both sender and receiver side. |