Idoc
Letzter Autor: induux Redaktion
Die Kommunikation zwischen, von und zu SAP Systemen ist das bekannteste Beispiel der Anwendung des IDoc-Formats. Es ist ein wichtiges Tool um externe Geschäftsprozesse in SAP zu integrieren. Dabei ist jedes IDoc in Form einer Textdatei vorhanden, was asynchrone Transaktionen ohne aktiven Datenbankzugriff ermöglicht.
Aufbau eines IDocs
Ein SAP IDoc besteht aus drei verschiedenen Sätzen:
- Kontrollsatz: Verwaltungsinformationen wie IDoc-Typ, Nachrichtentyp, aktuellen Status, Absender und Empfänger.
- Datensatz: enthält die eigentlichen IDoc-Daten. Ein IDoc speichert nur die für eine bestimmte Transaktion erforderlichen Daten.
- Statussatz: Informationen zu den verschiedenen Phasen, die das IDoc bislang durchlaufen hat.
Arten von IDoc
Inbound und Outbound IDoc
Inbound IDocs, oder auch eingehende IDocs, sind solche die in ein SAP System gelangen. Ein IDoc, welches ein SAP System verlässt wird als Outbound oder ausgehendes IDoc bezeichnet.
Fachliche Arten von IDoc
IDoc unterscheiden sich nach genereller Datenkategorie. Zum Beispiel Themenbereiche, wie Bestellungen oder Rechnungen, sowie spezifischeren Nachrichtentypen.
Wie IDoc in SAP verwendet wird
Ein IDoc kann an jedem Punkt eines Geschäftsprozesses generiert werden. Beispielsweise kann während eines Einlagerungsprozesses ein IDoc generiert werden, das die Datenfelder enthält, die für die Verbuchung eines Material im Lager erforderlich sind.
Nachdem ein Anwender eine SAP-Transaktion durchgeführt hat, werden ein oder mehrere spezifische IDoc in der Datenbank des sendenden Systems generiert. Die IDoc werden an das Empfängersystem gesendet und dort als inbound IDoc verarbeitet.
Unterschiedliche Status von IDoc
Liste der IDoc-Status (tbd)
Herausforderungen im Umgang mit IDoc
Aus Performancesicht ist das IDoc-Format eher ungeeignet um in Geschäftsprozessen schnell zu kommunizieren, dafür aber sehr robust. Im SAP-Umfeld ist die Nutzung von IDoc neben der synchronen BAPI-Schnittstelle somit immer noch absoluter Standard.
In der Kommunikation zwischen SAP Systemen können jedoch vielfach inhaltliche Fehler auftreten. Diese zeigen sich häufig in IDoc, die nicht sauber verarbeitet werden können und somit einen entsprechenden Fehlerstatus erhalten. Nicht immer ist es ohne weiteres möglich die Fehlerquellen so zu beeinflussen, dass sie nicht mehr auftreten. In diesen Fällen müssen müssen IDoc üblicherweise manuell korrigiert und neu verbucht werden, häufig über die Transaktion BD87.
Die typischen Herausforderungen bei der Bearbeitung von IDoc-Fehlern:
- Rechtzeitiges Erkennen fehlerhafter kritischer IDoc: führen zur Unterbrechung des zu Grunde liegenden Geschäftsvorfalls
- Erkennen fehlerhafter IDoc üblicherweise in der SAP Basis: SAP Basis Administratoren fehlt häufig der fachliche Hintergrund um IDoc zu korrigieren, was zu beliebig komplexen Rückmeldemechanismen führen kann und ebenfalls in einer Unterbrechung des Geschäftsvorfalls führt
- Korrektur eines IDoc im SAP GUI: umfangreiche Suche der fehlerhaften Segmente in der IDoc-Struktur
- Menge fehlerhafter IDoc: im Sinne des reinen Arbeitsaufwandes
- Unübliche IDoc-Fehler: im Gegensatz zu "regelmäßigen" IDoc-Fehlern ist die Lösung seltener IDoc-Fehler häufig mit großem Nachforschungsaufwand verbunden
IDoc-Monitoring und IDoc-Management
Für die obigen Herausforderungen gibt es unterschiedliche Lösungsansätze. Da es nicht immer möglich ist Fehlerquellen auszuschließen, müssen sich Unternehmen andere Strategien überlegen.
Ein erster Schritt ist dabei das frühzeitige Erkennen von IDoc mit einem Fehlerstatus, z.B. über
- eigenentwickelte Softwarekomponenten / Z-Programme (Vorteil: unternehmensspezifisch optimiert; Nachteil: Skriptpflege, Abhängigkeit vom Wissen und Können der Entwickler)
- konfigurierte SAP Standardmittel (CCMS), (Vorteil: vorhanden; Nachteil: umfassender Konfigurationsaufwand)
- Drittanbieter-Tools (Vorteil: auf IDoc spezialisierte Standardtools, üblicherweise geringer Konfigurationsaufwand; Nachteil: Lizenz-/Wartungskosten)
Herstellerauswahl für Automatisierungslösungen
Neben der SAP SE selbst (SAP Solution Manager, SAP CCMS, SAP AIF) haben sich inzwischen einige Anbieter mit Automatisierungslösungen unterschiedlicher Reifegrade und Einführungsaufwände im Markt etabliert.
Weitere Anbieter sind:
Libelle
Munich Enterprise
Software
Mögliche Entscheidungskriterien im Rahmen einer Herstellerauswahl lauten:
- Reifegrad der Lösung insgesamt
- Flexibilität der Lösung bei bekannten / unbekannten Fehlern
- Umfang der Automatisierung hinsichtlich Korrektur und Neuverbuchung von IDoc
- Lizenzmodell/-preise
- Implementierungsaufwand
- Wartungsaufwand
IDoc-Transaktionen
Soll tatsächlich noch manuell mit IDoc gearbeitet werden, sind die folgenden Transaktionen hilfreich:
IDoc-Anzeigen / Monitoring
WE02 – Anzeigen IDoc
WE05 – IDoc Listen
WE06 – IDoc Monitoring
WLF_IDOC – IDoc Verarbeitung
BD87 – Statusmonitor ALE Nachrichten
IDoc-Administration
WE20 – Partnervereinbarungen
WE21 – Portbeschreibung
SM58 – Fehlerprotokoll asynchrone RFC
SM59 – RFC Destinationen
IDoc-Suche
WE07 – IDoc Statistik
WE09 – IDoc suchen
WE10 – IDoc suchen
WE11 – IDoc löschen
IDoc-Dokumentation
WE60 – Dokumentation IDoc Typen
WE64 – Dokumentation Nachrichtentypen
IDoc-Entwicklung
WE30 – Entwicklung IDoc Typ
WE31 – Entwicklung IDoc Segment
WE81 – Logische Nachrichtentypen
WE82 – Zuordnung Nachrichten zu IDoc Typ
BD51 – Eingangsfunktionsbausteine pflegen
WE57 – Zuordnung Nachrichten zu Anwendungsobjekt
IDoc-Steuerung
WE47 – Statuspflege
WELI – Statusgruppenpflege
WE24 – Vorschlagswerte Ausgangsparameter
WE27 – Vorschlagswerte Eingangsparameter
WE32 – Entwicklung IDoc Sicht
WE34 – Anzeige von XML IDoc
WE43 – Funktionsbaustein Statussatz Anzeige
WE44 – Partnerarten und Prüfungen
WE55 – Funktionsbaustein Pfadnamen
IDoc-Umsetzregeln
BD62 – Segment
BD79 – Pflege
BD55 – Zwischenbeleg
IDoc-Umschlüsselung
WE70 – Basistypen
WE71 – Erweiterungen
WE72 – IDoc Typen
WE73 – log. Nachrichten