ALE Programmierleitfaden (BCMIDALEPRO)

ALE-Programmierleitfaden
HELP.BCMIDALEPRO
Release 4.6C
ALE-Programmierleitfaden SAP AG
Copyright
© Copyright 2001 SAP AG. Alle Rechte vorbehalten.
Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem
Zweck und in welcher Form
auch immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP AG nicht gestattet. In
dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert
werden.
Die von SAP AG oder deren Vertriebsfirmen angebotenen Software-Produkte können Software-
Komponenten auch anderer Software-Hersteller enthalten.
® ® ® ® ® ® ®
Microsoft , WINDOWS , NT , EXCEL , Word , PowerPoint und SQL Server sind eingetragene
Marken der
Microsoft Corporation.
® ® ® ® ® ® ® ® ®
IBM , DB2 , OS/2 , DB2/6000 , Parallel Sysplex , MVS/ESA , RS/6000 , AIX , S/390 ,
® ® ®
AS/400 , OS/390 und OS/400 sind eingetragene Marken der IBM Corporation.
®
ORACLE ist eine eingetragene Marke der ORACLE Corporation.
® ® TM
INFORMIX -OnLine for SAP und Informix Dynamic Server sind eingetragene Marken der
Informix Software Incorporated.
® ® ® ®
UNIX , X/Open , OSF/1 und Motif sind eingetragene Marken der Open Group.
®
HTML, DHTML, XML, XHTML sind Marken oder eingetragene Marken des W3C , World Wide
Web Consortium,
Massachusetts Institute of Technology.
®
JAVA ist eine eingetragene Marke der Sun Microsystems, Inc.
®
JAVASCRIPT ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet unter der
Lizenz der von Netscape entwickelten und implementierten Technologie.
SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow,
SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo und mySAP.com
sind Marken oder eingetragene Marken der SAP AG in Deutschland und vielen anderen Ländern
weltweit. Alle anderen Produkte sind Marken oder eingetragene Marken der jeweiligen Firmen.
2 April 2001
SAP AG ALE-Programmierleitfaden
Symbole
Symbol Bedeutung
Achtung
Beispiel
Hinweis
Empfehlung
Syntax
April 2001 3
Inhalt
ALE-Programmierleitfaden ................................................................................ 7
Verteilung über BAPIs implementieren........................................................................................ 8
Ablauf der Verteilung über BAPIs...............................................................................................10
Eigene BAPIs implementieren ....................................................................................................17
Daten filtern................................................................................................................................... 19
Schnittstelle reduzieren............................................................................................................. 22
Filterobjekttypen definieren und zuordnen................................................................................ 25
BAPI-Parameter filtern .............................................................................................................. 27
Hierarchien zwischen BAPI-Parametern definieren.................................................................. 29
BAPI-ALE-Schnittstelle pflegen .................................................................................................. 32
Empfänger für ein BAPI ermitteln...............................................................................................39
Filterobjekte eines BAPIs abfragen........................................................................................... 41
Empfänger für asynchrone BAPIs ermitteln.............................................................................. 42
Eigene Filterobjekte über Business Add-Ins ermitteln......................................................... 44
Beispielprogramme mit asynchronem BAPI-Aufruf ............................................................. 47
Empfänger für synchrone BAPIs ermitteln................................................................................ 53
Beispielprogramme mit synchronem BAPI-Aufruf ............................................................... 55
Einzigen Empfänger für synchrone BAPIs ermitteln ................................................................. 58
BAPIs für interaktive Verbuchung entwickeln .......................................................................... 59
IDocs einer BAPI-ALE-Schnittstelle erweitern .......................................................................... 60
Verteilung über Nachrichtentypen implementieren.................................................................. 61
Ablauf der Verteilung über Nachrichtentypen........................................................................... 62
Ausgangsverarbeitung implementieren .................................................................................... 66
Entwicklung eines Funktionsbausteins zur ALE-Ausgangsverarbeitung.................................. 67
Grundlagen .......................................................................................................................... 68
Abfrage des Verteilungsmodells .......................................................................................... 69
Aufbau des Kontrollsatzes ................................................................................................... 70
Aufbau der Datensätze ........................................................................................................ 71
Konvertierung von Währungsbeträgen........................................................................... 72
Ersetzen von SAP-Codes durch ISO-Codes .................................................................. 73
Linksbündiges Füllen von IDoc-Feldern ......................................................................... 74
Aufruf von MASTER_IDOC_DISTRIBUTE .......................................................................... 75
Exceptions und Export-Parameter von master_idoc_distribute ..................................... 76
Beispiel für die IDoc-Erzeugung .......................................................................................... 77
Beispielprogramm für die IDoc-Erzeugung..................................................................... 78
Verwendung des Coding-Beispiels................................................................................. 84
Einstellung der ALE-Ausgangsverabeitung .............................................................................. 85
ALE-Objektypen definieren .................................................................................................. 86
Objekttyp für die Ausgangsverknüpfung dem Nachrichtentyp zuorden .............................. 87
Anwendungsobjekttyp für die Ausgangsverknüpfung dem Nachrichtentyp zuordnen ........ 88
Ausgang über die Nachrichtensteuerung.................................................................................. 89
Eingangsverarbeitung implementieren...................................................................................... 90
Funktionsbaustein im Eingang .................................................................................................. 91
4 April 2001
Einbettung eines Funktionsbausteins in die ALE-Eingangsverarbeitung ............................ 92

Datenkonsistenz................................................................................................................... 93
Gewährleistung der Datenkonsistenz............................................................................. 94
Serialisierung .................................................................................................................. 95
Verarbeitung eines einzelnen IDocs .................................................................................... 96
Namenskonvention ......................................................................................................... 97
Die Schnittstelle des Funktionsbausteins ....................................................................... 98
Import-Parameter............................................................................................................ 99
IDoc Verarbeitung......................................................................................................... 100
Export-Parameter ......................................................................................................... 101
Exportparameter des eingehenden Funktionsbausteins......................................... 102
Exportparameter bei erfolgreicher IDoc-Verarbeitung ............................................ 103
Exportparameter bei fehlerhafter IDoc-Verarbeitung .............................................. 104
Beispiel für die IDoc-Verarbeitung................................................................................ 105
Beispielprogramm für die IDoc-Verarbeitung .......................................................... 106
Serialisierung über Nachrichtentypen................................................................................ 119
Beispielprogramm für die Serialisierung....................................................................... 120
Customer-Exits .................................................................................................................. 126
Beispielprogramm für einen Customer-Exit.................................................................. 127
Massenverarbeitung .......................................................................................................... 134
Import-Parameter.......................................................................................................... 135
Export-Parameter ......................................................................................................... 136
Erfolgreicher Eingang für alle IDocs........................................................................ 137
Fehlerhafter Eingang eines IDocs ........................................................................... 139
Beispielprogram für die IDoc-Massenverarbeitung ...................................................... 141
Call Transaction einsetzen................................................................................................. 146
ALE-fähige Transaktionen ............................................................................................ 147
Call Transaction erfolgreich .......................................................................................... 149
Call Transaction scheitert ............................................................................................. 151
Import-Parameter bei CALL TRANSACTION............................................................... 152
Export-Parameter bei CALL TRANSACTION............................................................... 153
Eingang erfolgreich.................................................................................................. 154
Eingang fehlerhaft ................................................................................................... 155
ALE-Einstellungen................................................................................................................... 156
Attribute des Funktionsbausteins deklarieren.................................................................... 157
Registrieren des Funktionsbausteins im Eingang.............................................................. 158
Eingangs-Vorgangscode anlegen...................................................................................... 159
Eingangsverarbeitung über SAP-Workflow............................................................................. 160
Workitem ............................................................................................................................ 161
Workflow ............................................................................................................................ 162
IDOCXAMPLE als Referenz für IDOC_PACKET ......................................................... 163
IDPKXAMPLE als Referenz für IDOC_PACKET.......................................................... 164
Erweiterte Workflow-Programmierung .................................................................................... 165
Setzen des Parameters ..................................................................................................... 166
Das Ereignis inputErrorOccurred.................................................................................. 167
April 2001 5
Das Ereignis inputFinished ........................................................................................... 169

Auslösen des Anwendungsereignisses nach erfolgreicher IDoc-Verarbeitung................. 170
Einsetzen des Parameters No_of_retries .......................................................................... 172
Stammdatenverteilung............................................................................................................... 173
Definition der Nachricht............................................................................................................. 174
Ausgangsverarbeitung in der Stammdatenverteilung ........................................................... 175
Stammdaten über das SMD Tool verteilen ............................................................................. 176
Stammdaten direkt senden ..................................................................................................... 181
Eingangsverarbeitung der Stammdaten .................................................................................. 182
Anbindung von Fremdsystemen .............................................................................................. 183
Übersetzungsprogramme für die Anbindung.......................................................................... 185
Programmtechnische Realisierung.......................................................................................... 187
TCP/IP-Einstellungen.............................................................................................................. 188
Senden von IDocs an ein Fremdsystem ................................................................................. 189
Senden von IDocs vom Fremdsystem an SAP....................................................................... 191
Verwaltung von Transaktionsidentifikatoren (TID) .................................................................. 193
Integration von Dialogschnittstellen ........................................................................................ 195
Aufruf mit Referenz auf logisches System .............................................................................. 198
Aufruf ohne Referenz auf das logische System...................................................................... 200
Serialisierung von Nachrichten ................................................................................................ 202
Serialisierung über Objekttypen ............................................................................................... 203
Serialisierung über Nachrichtentypen ..................................................................................... 205
Serialisierung auf IDoc-Ebene ..................................................................................................206
Automatische Tests ................................................................................................................... 207
Beispielszenario zur Stammdatenverteilung........................................................................... 208
Test vorbereiten ......................................................................................................................... 209
Testablauf entwickeln ................................................................................................................ 210
Fehlerbehandlung ...................................................................................................................... 212
Anzulegende Objekte, Ereignisse und Aufgaben ................................................................... 214
Objekttypen und Ereignisse...................................................................................................... 217
IDoc-Objekttyp IDOCXAMPLE anlegen.................................................................................. 218
IDoc-Paketobjekttyp IDPKXAMPLE anlegen .......................................................................... 220
Standardaufgabe anlegen ......................................................................................................... 221
Eingangsmethode pflegen ........................................................................................................224
Konsistenz der Eingangs-Fehlerbehandlung prüfen.............................................................. 225
6 April 2001
Einsatzmöglichkeiten
Sie können die ALE-Geschäftsprozesse der Standardauslieferung durch eigene Szenarien
ergänzen.
Zu diesem Zweck werden zwei Programmiermodelle unterstützt, die sich durch die Art der
versendeten Nachricht unterscheiden:
· Verteilung über BAPIs [Seite 8]: Dieses Verfahren wird ab R/3-Release 4.0A unterstützt und
ist die Grundlage für zukünftige Entwicklungen.
· Verteilung über Nachrichtentypen [Seite 61] Dieses Programmiermodell liegt den ALE-
Entwicklungen von R/3-Release 3.x zugrunde.
Entwickler von Desktop-Anwendungen können darüber hinaus ALE-

++
Geschäftsprozesse mit Hilfe der IDoc Class Library [Extern] für C realisieren.
Mandantenkopie: Logische Systemnamen in Belegkopfdaten

Beim Kopieren von Mandanten müssen logische Systeme, sofern solche zu einem
Mandanten definiert wurden, in den Kopfdaten der kopierten Belege umgesetzt
werden, damit diese Belege in dem neuen Mandanten wiedergefunden werden.
Einzelheiten zur Umsetzung finden Sie im Einführungsleitfaden unter Basis,
Middleware, Verteilung (ALE), Logisches System in Anwendungstabellen umsetzen.
Empfehlung:
Um eine solche Umsetzung zu vermeiden, sollten Anwendungsentwickler dafür
sorgen, dass bei der Erstellung von Belegen das Feld mit dem logischen Namen
nicht gefüllt wird (Wert SPACE). Ein nicht gefülltes Feld wird beim Lesen mit dem
logischen System des aktuellen Mandanten gleichgesetzt.
Bei Statistikauswertungen von Belegen muss geprüft werden, ob dieses Feld das
logische System des aktuellen Mandanten oder den Wert SPACE enthält.
Nur wenn diese beiden Bedingungen zutreffen, werden Belege als dem aktuellen
Mandanten zugehörig betrachtet und in die Statistikauswertung einbezogen.
April 2001 7
Verteilung über BAPIs implementieren

Aufgrund der Integration von BAPIs und ALE können Sie die Entwicklung eigener ALE-
Geschäftsprozesse für die Verteilung betriebswirtschaftlicher Prozesse implementieren.
BAPIs sind Methoden eines SAP Business-Objekts. Sie sind im Business Object Repository
(BOR) definiert und unterliegen strengen Designvorschriften. BAPIs sind im R/3-System als
RFC-fähige Funktionsbausteine implementiert.
Einzelheiten zu BAPIs finden Sie im BAPI-Benutzerhandbuch [Extern] und im BAPI-
Programmierleitfaden [Extern].
Ab Release 4.5A können auch BAPIs definiert werden, die außerhalb des R/3-Systems
implementiert sind, jedoch vom R/3-System aus ("outbound") aufgerufen werden können.
Weitere Einzelheiten dazu finden Sie im BAPI-Programmierleitfaden unter BAPIs für den
Outbound-Fall [Extern] und im BAPI-Benutzerhandbuch unter BAPIs an SAP-Interfacetypen
[Extern].
ALE bietet ein vollständiges Programmiermodell für den Einsatz von BAPIs. Es unterstützt
folgende Methodenaufrufe:
· Synchrone Methodenaufrufe
In ALE-Verteilungsszenarien können auch synchrone Schnittstellen genutzt werden.
Dabei handelt es sich entweder um BAPIs oder Dialogmethoden [Seite 195].
Im ALE-Customizing können Sie festlegen, welche RFC-Destination für einen
synchronen Methodenaufruf verwendet werden soll.
· Asynchrone Methodenaufrufe
Werden BAPIs asynchron ausgeführt, können die ALE-Fehlerbehandlung und das ALE-
Audit genutzt werden.
Soll die Verteilung über einen asynchronen BAPI-Aufruf erfolgen, so kann die dafür
erforderliche BAPI-ALE-Schnittstelle für den Ausgang und Eingang automatisch
generiert werden. Die ABAP-Entwicklung eines ALE-Geschäftsprozesses beschränkt
sich dadurch im wesentlichen auf das Programmieren eines BAPIs.
Durch den objektorientierten Ansatz ergeben sich folgende Vorteile:
- nur eine Schnittstelle, die durch die Anwendung zu warten ist
- automatische Generierung der BAPI-ALE-Schnittstelle vermeidet Programmierfehler
Ablauf
Wenn Sie bei der Implementierung eines ALE-Geschäftsprozesses keines der von SAP
bereitgestellten BAPIs erweitern oder eigene BAPIs erstellen, müssen Sie lediglich folgende
Schritte ausführen:
· Daten filtern [Seite 19]
· Empfänger für ein BAPI ermitteln [Seite 39]
Wenn Sie hingegen BAPIs erweitern oder eigene BAPIs erstellen, müssen Sie die
nachfolgenden Schritte ausführen:
· Eigene BAPIs implementieren [Seite 17]
8 April 2001
· Daten filtern [Seite 19]

· BAPI-ALE-Schnittstelle pflegen [Seite 32]
· Empfänger für ein BAPI ermitteln [Seite 39]
Anwendungsprogramme müssen einen Funktionsbaustein für die Empfängerermittlung
und einen generierten Anwendungsfunktionsbaustein der BAPI-ALE-Schnittstelle
aufrufen.
Die Qualität der ALE-Schicht und der ALE-Geschäftsprozesse können Sie durch automatische
Tests [Seite 207] verifizieren.
Siehe auch:
BAPIs für interaktive Verbuchung entwickeln [Seite 59]
IDocs einer BAPI-IDoc-Schnittstelle erweitern [Seite 60]
April 2001 9
Ablauf der Verteilung über BAPIs

BAPIs können von einer Anwendung synchron oder asynchron aufgerufen werden. ALE-
Funktionen wie die Pflege der BAPIs im Verteilungsmodell und die Empfängerermittlung stehen
in beiden Fällen zur Verfügung.
Beachten Sie, daß synchron aufgerufene BAPIs nur zum Lesen von externen Daten benutzt
werden sollten, um Datenbank-Inkonsistenzen durch Übertragungsfehler zu vermeiden.
Die Anwendung ruft im externen System synchron ein BAPI zum Anlegen eines FI-
Belegs. Der Beleg wird korrekt angelegt, doch es kommt während der Ausführung
des BAPIs zu einem Netzwerkausfall. Der Anwendung wird eine Fehlermeldung
zurückgegeben, die sie veranlaßt, den FI-Beleg erneut anzulegen. Es kommt zur
Duplizierung von Belegen im gerufenen System.
Ein Anwendungsprogramm kann durch aufwendiges Prüfen der Daten im externen System die
Funktionalität eines 2-Phasen-Commit realisieren. Eine einfachere Lösung ist der asynchrone
Aufruf eines BAPIs, da die Datenkonsistenz aufgrund der Fehlerbehandlung [Seite 212]
sichergestellt ist.
Ein BAPI sollte als asynchrone Schnittstelle implementiert werden, wenn eines der folgenden
Kriterien zutrifft:
· Konsistente Datenbankänderungen in beiden Systemen
Daten müssen sowohl auf dem lokalen System als auch auf einem entfernten System
konsistent fortgeschrieben werden.
· Lockerung der Ankopplung
Eine Implementation als synchrone Schnittstelle würde eine zu enge Kopplung zwischen
dem Client- und dem Server-System darstellen. Bei Ausfall der Verbindung könnte das
Client-System nicht mehr vernünftig arbeiten.
· Performance-Belastung
Es handelt sich um eine häufig verwendete Schnittstelle bzw. um eine Schnittstelle mit
großem Datenvolumen. Eine synchrone Schnittstelle kommt in dieser Situation aus
Performance-Gründen nicht in Frage.
Wenn Sie BAPIs als asynchrone Schnittstelle implementieren möchten, müssen Sie für ein
existierendes BAPI eine BAPI-ALE-Schnittstelle generieren. Weitere Einzelheiten zur
Generierung einer BAPI-ALE-Schnittstelle finden Sie unter BAPI-ALE-Schnittstelle generieren
[Seite 32].
Die Verteilung von Daten über BAPIs ist nachfolgend grafisch dargestellt und erläutert.
10 April 2001
Anwendung ALE-Schicht Kommunikations- ALE-Schicht Anwendung

Schicht
- Empfänger ermitteln
- Generierten Funktions- Verteilungs-
baustein aufrufen modell
IDoc Segmentfilterung
Datenfilterung Feldumsetzung
Generierter Generierter
Funktionsbaustein Funktionsbaustein
auf Ausgangsseite auf Eingangsseite
BAPI ® IDoc tRFC Übergabe-
Umwandlung oder IDoc ® BAPI
steuerung
EDI Umwandlung
Segmentfilterung
Serialisierung
Feldumsetzung BAPI-
IDoc Funktions-
Versionswandlung baustein
aufrufen
IDoc Daten und

IDoc-Status
aktualisieren IDoc-Status
Verknüpfung Versende- ermitteln
Datenbank steuerung Datenbank
Auf der Ausgangs- und Eingangsseite werden jeweils die Anwendungsschicht und die ALE-
Schicht durchlaufen. Die Kommunikationsschicht sorgt für die Datenübertragung per
transaktionalem Remote Function Call (tRFC) oder EDI-Dateischnittstelle.
Der Ablauf läßt sich in folgende Teilphasen untergliedern.
1. Ausgangsverarbeitung
· Empfängerermittlung
· Aufruf des generierten Ausgangsfunktionsbausteins
· Umwandlung des BAPI-Aufrufs in ein IDoc
· Segmentfilterung
· Feldumsetzung
· IDoc-Versionswandlung
· Versendesteuerung
2. Versenden des IDocs
In der Kommunikationsschicht werden IDocs über den transaktionalen Remote Function Call
(tRFC) oder über andere Dateischnittstellen (z.B. für EDI) versendet.
Der tRFC garantiert dabei, daß die Daten genau einmal übertragen werden.
3. Eingangsverarbeitung
· Segmentfilterung
· Feldumsetzung
· Übergabesteuerung
April 2001 11
· Umwandlung des IDocs in einen BAPI-Aufruf

· Aufruf des BAPI-Funktionsbausteins
· IDoc-Status ermitteln
· Buchen der Anwendungsdaten und des IDoc-Status
· Fehlerbehandlung
Nachfolgend sind die Teilphasen der Ausgangs- und Eingangsverarbeitung beschrieben.
Ausgangsverarbeitung
Auf der Ausgangsseite wird in der Anwendungsschicht nach der Ermittlung der
Empfänger aus dem Verteilungsmodell der Ausgangsfunktionsbaustein aufgerufen, der
aus einem BAPI als Teil der BAPI-ALE-Schnittstelle generiert wurde (siehe auch
Beispielprogramme mit asynchronem BAPI-Aufruf [Seite 47]). In der ALE-Schicht wird
das zugehörige IDoc mit den gefilterten Daten aus dem BAPI-Aufruf gefüllt.
Über die Versendesteuerung wird die Datenübertragung zeitlich und mengenmäßig
gesteuert.
Im einzelnen setzt sich die Ausgangsverarbeitung aus den nachfolgend beschriebenen
Teilschritten zusammen.
Empfängerermittlung
Analog zum synchronen Aufruf eines BAPIs werden im Verteilungsmodell die
potentiellen Empfänger eines BAPI-Aufrufs definiert.
Vor dem Aufruf eines BAPIs bzw. einer generierten BAPI-ALE-Schnittstelle müssen
deren Empfänger ermittelt werden. Bei der Empfängerermittlung wird geprüft, ob die
Filterobjekte die vorgegebenen Bedingungen erfüllen, und es werden die erlaubten
Empfänger zurückgegeben.
Ist die Verteilung der Daten zusätzlich an Bedingungen geknüpft, werden diese
Abhängigkeiten zwischen BAPIs oder zwischen BAPIs und Nachrichtentypen als
Empfängerfilter definiert.
Für jeden dieser Empfängerfilter wurde vor der Pflege des Verteilungsmodells zunächst
ein Filterobjekt angelegt, dessen Wert zur Laufzeit darüber entscheidet, ob die
Bedingung erfüllt ist oder nicht.
Weitere Einzelheiten finden Sie unter Empfänger für ein BAPI ermitteln [Seite 39].
Aufruf des generierten Ausgangsfunktionsbausteins

Sind die Empfänger ermittelt, muß differenziert werden, ob die Empfänger lokal oder
remote sind. Für lokale Empfänger kann das BAPI direkt aufgerufen werden. Für
remote-Aufrufe wird dagegen der generierte ALE-Ausgangsfunktionsbaustein
ausgeführt und somit die Verarbeitung an die ALE-Schicht weitergeleitet. Diesem
Funktionsbaustein werden die Daten für den BAPI-Aufruf und die Liste der erlaubten
logischen Empfängersysteme mitgegeben.
Hinweis für die Programmierung:
Nach dem Aufruf des generierten Funktionsbausteins muß das
Anwendungsprogramm den Befehl COMMIT WORK enthalten. Der normale
Datenbank-Commit am Transaktionsende reicht nicht aus. Der COMMIT WORK
12 April 2001
muß nicht sofort nach dem Aufruf, sondern kann auch in höheren Aufrufebenen oder
nach mehreren Aufrufen des Funktionsbausteins erfolgen.
Die erzeugten IDocs sind bis zum Ende der aufrufenden Transaktion gesperrt. Um
sie vorher zu entsperren, können Sie einen der folgenden Funktionsbausteine
aufrufen:
DEQUEUE_ALL gibt alle Sperrobjekte frei
EDI_DOCUMENT_DEQUEUE_LATER gibt einzelne IDocs frei, deren Nummern dem
Funktionsbaustein als Parameterwerte übergeben werden.
Datenfilterung
Für die Filterung stehen zwei Filterdienste zur Verfügung: die an Bedingungen geknüpfte
Parameterfilterung und die bedingungslose Schnittstellenreduzierung.
· Wenn bei der Schnittstellenreduktion vollständige Parameter ausgeblendet wurden,
dann werden diese nicht in das IDoc übernommen. Sollen dagegen bei strukturierten
Parametern nur einzelne Felder nicht übernommen werden, erscheinen trotzdem die
vollständigen Parameter im IDoc.
· Bei der Parameterfilterung herausgefilterte Tabellenzeilen werden nicht in das IDoc
übernommen.
Weitere Einzelheiten finden Sie unter Daten filtern [Extern].
Umwandlung des BAPI-Aufrufs in ein IDoc

Ist die Datenfilterung abgeschlossen, wird vom Ausgangsfunktionsbaustein aus dem
BAPI-Aufruf ein IDoc mit den zu übertragenden Daten erzeugt.
Segmentfilterung
Nachdem das IDoc aufgebaut worden ist, kann eine zusätzliche Filterung der IDoc-
Segmente vorgenommen werden. Diese Filterung wird allerdings bei BAPIs nur in den
seltensten Fällen verwendet.
Einzelheiten dazu finden Sie im R/3-Einführungsleitfaden über folgenden Pfad:
Basis
Application Link Enabling
Geschäftsprozesse modellieren und implementieren
Verteilung von Stammdatenverteilung einstellen
Umfang der zu verteilenden Daten festlegen
Nachrichten reduzieren
Feldumsetzung
Empfängerspezifische Feldumsetzungen können Sie im R/3-Einführungsleitfaden
definieren:
Basis
Datenumsetzung zwischen Sender und Empfänger einstellen
Es können allgemeine Regeln festgelegt werden, auf die man sich bei konkreten
Feldumsetzungen beziehen kann. Diese Funktion ist wichtig für die Konversion des
April 2001 13
Feldformats beim Datenaustausch zwischen R/2- und R/3-Systemen. In diesem Fall wird
beispielsweise das Feld Werk von 2 auf 4 Stellen erweitert.
Technisch erfolgt die Umsetzung mit Hilfe allgemeiner Umsetzungswerkzeuge aus dem
EIS-Bereich (Executive Information System).
IDoc-Versionswandlung
Damit die korrekte Funktion von ALE zwischen R/3-Systemen unterschiedlicher
Releasestände gewährleistet ist, kann eine Konversion von IDoc-Formaten durchgeführt
werden, um Nachrichtentypen unterschiedlicher Release-Stände anzupassen.
Ist die Versionswandlung abgeschlossen, werden die IDocs auf der Datenbank abgelegt
und die Versendesteuerung gestartet, die entscheidet, welche dieser IDocs sofort
versendet werden.
Bei der Änderung bestehender Nachrichtentypen hält sich die SAP-Entwicklung an
folgende Regeln:
· Felder können einem Segmenttyp angehängt werden;
· Segmente können hinzugefügt werden;
Im ALE-Customizing wird zu jedem Empfänger festgehalten, welche Version eines
Nachrichtentyps dort verwendet wird. Auf der Ausgangsseite wird das IDoc in der
korrekten Version erzeugt.
Versendesteuerung
Zeitliche Steuerung:
· Die IDocs können sofort oder per Hintergrundverarbeitung versandt werden. Diese
Einstellungen werden in der Partnervereinbarung vorgenommen.
· Erfolgt die Versendung per Hintergrundverarbeitung, muß ein Job eingeplant
werden. Der Ausführungsrhythmus ist frei wählbar.
Mengensteuerung:
· IDocs können gebündelt in Paketen versendet werden. Die Paketgröße wird im ALE-
Customizing partnerspezifisch vereinbart:
Basis
Partnervereinbarung und Verarbeitungszeitpunkt einstellen
Partnervereinbarung manuell pflegen
oder: Partnervereinbarung generieren
Diese Einstellung ist nur wirksam, wenn Sie die Verarbeitung der IDocs im
Hintergrund einplanen.
Eingangsverarbeitung
Auf der Empfängerseite übernimmt die ALE-Schicht die Eingangsverarbeitung.
14 April 2001
Auf der Anwendungsseite wird bei der Ausführung des generierten

Eingangsfunktionsbausteins der BAPI-Aufruf aus dem IDoc erzeugt, der BAPI-
Funktionsbaustein aufgerufen und der IDoc-Status ermittelt.
Nachdem die Verarbeitung des BAPIs bzw. des gesamten Pakets abgeschlossen
worden ist, werden die Statussätze aller IDocs sowie die von erfolgreich
abgeschlossenen BAPIs erzeugten Anwendungsdaten zusammen verbucht.
Im einzelnen setzt sich die Eingangsverarbeitung aus den nachfolgend beschriebenen
Teilschritten zusammen.
Segmentfilterung
Auf der Eingangsseite kann analog zur Ausgangsverarbeitung eine Filterung von IDoc-
Segmenten vorgenommen werden. Diese Filterung auf der Eingangsseite wird bei BAPIs
ebenfalls nur in den seltensten Fällen verwendet.
Feldumsetzung
Ebenfalls wie bei der Ausgangsverarbeitung ist es möglich, Feldumsetzungen
durchzuführen, wenn sich die Formate eines Feldes im Empfänger- und Sendesystem
unterscheiden.
Nachdem die Feldumsetzung stattgefunden hat wird das IDoc auf der Datenbank
gespeichert und die weitere Verarbeitung an die Übergabesteuerung übergeben.
Übergabesteuerung
In der Übergabesteuerung wird entschieden, wann die BAPIs in der Anwendung
aufgerufen werden sollen. Dies kann entweder sofort nach dem Eintreffen des IDocs
oder zeitgesteuert per Hintergrundverarbeitung erfolgen.
Werden mehrere voneinander abhängige Objekte verteilt, kann während der
Übergabesteuerung die Serialisierung genutzt werden. Durch eine serialisierte
Verteilung von Nachrichten wird eine bestimmte Reihenfolge bei der Erzeugung,
Versendung und Verbuchung der entsprechenden IDocs eingehalten. Dadurch werden
Fehler bei der Eingangsverarbeitung der IDocs vermieden.
Bei der Verwendung von BAPIs kann ausschließlich die Objektserialisierung genutzt
werden, die sicherstellt, daß die Reihenfolge der Nachrichten bezüglich eines
bestimmten Objektes auf der Empfängerseite immer gewahrt bleibt.
Weitere Einzelheiten zur Objektserialisierung finden Sie im ALE-Customizing:
Basis
Verteilung von Stammdaten konfigurieren
Serialisierung der Daten beim Senden und Empfangen einstellen
Serialisierung über Objekttypen
Wenn der Zeitpunkt zur Verarbeitung des BAPIs gekommen ist, wird der generierte
Eingangsfunktionsbaustein aufgerufen.
Umwandlung des IDocs in einen BAPI-Aufruf

Bei der Erzeugung des BAPI-Aufrufs werden sämtliche Daten aus den Segmenten des
IDocs in die zugehörigen Parameter des BAPI-Funktionsbausteins geschrieben. Ist für
das BAPI eine Schnittstellenreduzierung definiert worden, werden die ausgeblendeten
Felder nicht mit den IDoc-Daten gefüllt.
April 2001 15
Aufruf des BAPI-Funktionsbausteins

Anschließend wird der BAPI-Funktionsbaustein synchron mit den gefüllten Parametern
ausgeführt. Da das BAPI kein COMMIT-WORK-Kommando absetzt, werden die von ihm
angelegten, modifizierten oder gelöschten Anwendungsdaten noch nicht in die
Datenbank übernommen.
IDoc-Statusermittlung
Ist die Ausführung des Funktionsbausteins abgeschlossen, wird im
Eingangsfunktionsbaustein in Abhängigkeit vom Ergebnis des Aufrufs der IDoc-Status
ermittelt.
Buchen der Anwendungsdaten und des IDoc-Status

Wenn jedes IDoc bzw. BAPI einzeln verarbeitet wird, werden die Daten sofort auf die
Datenbank geschrieben.
Wenn allerdings mehrere IDocs innerhalb eines Pakets verarbeitet werden, sind
folgende Situationen denkbar:
· Die Anwendungsdaten der erfolgreich abgeschlossenen BAPIs werden zusammen
mit den Statussätzen aller IDocs verbucht, sofern kein BAPI-Aufruf innerhalb des
Pakets abgebrochen wurde.
· Sobald allerdings ein BAPI-Aufruf innerhalb des Pakets abgebrochen wurde, wird
der Status des zugehörigen IDocs als fehlerhaft betrachtet. Anwendungsdaten
werden nicht verbucht. Anschließend wird für alle BAPI-Aufrufe, die zuvor erfolgreich
beendet wurden, die Eingangsverarbeitung erneut durchlaufen. Tritt bei diesem Lauf
kein Abbruch mehr auf, werden die Anwendungsdaten der erfolgreich
abgeschlossenen BAPIs zusammen mit den Statussätzen aller IDocs verbucht. Beim
Auftreten weiterer Abbrüche wird dieser Vorgang wiederholt.
Hinweis: Die Paketverarbeitung wird nur durchgeführt, wenn keine Serialisierung
stattfindet.
Fehlerbehandlung
Für die ALE-Fehlerbehandlung können Sie den SAP-Workflow verwenden:
· Die Verbuchung des fehlerverursachenden IDocs bzw. der BAPI-Daten wird
abgebrochen.
· Ein Ereignis wird ausgelöst. Dieses Ereignis stößt eine Fehler-Aufgabe (Workitem)
an.
· Sobald die Daten des BAPIs bzw. IDocs erfolgreich verbucht worden sind, wird ein
Ereignis ausgelöst, das die Fehler-Aufgabe beendet. Damit verschwindet die
Aufgabe aus dem Eingangssystem.
Weitere Einzelheiten finden Sie unter Fehlerbehandlung [Seite 212].
16 April 2001
Eigene BAPIs implementieren

SAP liefert eine große Zahl von BAPIs aus. Wenn Sie eigene BAPIs implementieren möchten,
müssen Sie Ihren eigenen Namensraum verwenden.
Vorgehensweise
Sie haben folgende Alternativen:
· Sie entwickeln ein eigenes BAPI im Kundennamensraum.
· Sie modifizieren ein BAPI der Standardauslieferung:
1. Kopieren und modifizieren Sie den zum originalen BAPI gehörenden Funktionsbaustein.
2. Legen Sie im Business Object Repository zum Objekttyp Ihres BAPIs einen Sub-
Objekttyp im Kundennamensraum an (Werkzeuge ® Business Framework ® BAPI-
Entwicklung ® Business Object Builder).
Beim Anlegen eines Sub-Objektyps werden die Methoden des Business-Objekts an
den Subtyp vererbt.
3. Setzen Sie den Status des Objekttyps auf Implementiert (Bearbeiten ® Freigabestatus
ändern ® Objekttyp).
4. Sie können die Methoden des Subtyps ändern, löschen oder durch eigene Methoden
ergänzen.
Einzelheiten zum Anlegen neuer BAPIs und zum Erweitern vorhandener BAPIs erfahren Sie im
BAPI-Programmierleitfaden unter dem Thema Modifikationen und Eigenentwicklungen von
Kunden [Extern]
Hinweise für asynchrone BAPIs

Wenn Sie mit Ihrem BAPI einen asynchronen ALE-Geschäftsprozeß implementieren möchten,
müssen Sie aus dem BAPI eine BAPI-ALE-Schnittstelle pflegen [Seite 32].
Beim Implementieren eines BAPIs als asynchrone Schnittstelle sollten Sie neben den
allgemeinen Richtlinen für die Programmierung von Methoden auch die folgenden Punkte
beachten:
· Im BAPI darf kein Commit-Work-Kommando abgesetzt werden.
· Der Return-Parameter des BAPIs muss die Bezugsstruktur BAPIRET2 verwenden.
· Alle Export-Parameter der Methode mit Ausnahme des Return-Parameters werden
ignoriert und nicht in das generierte IDoc aufgenommen.
· Statussätze protokollieren BAPI-Rückgabewerte
Nach Aufruf des Funktionsbausteins, der im gerufenen System für die Umsetzung des
IDocs in den entsprechenden BAPI-Aufruf zuständig ist, werden für das IDoc Statussätze
geschrieben, in denen die vom Return-Parameter zurückgegebenen Meldungen
protokolliert werden.
Wenn in mindestens einem übergebenen Eintrag des Return-Parameters das Feld Type
mit A (Abbruch) oder E (Fehler) gefüllt ist, hat dies folgende Auswirkungen:
April 2001 17
· Type A:
Es wird für alle Statussätze des IDocs der Status 51 (Fehler, Anwendungsbeleg nicht
gebucht) geschrieben, nachdem ein ROLLBACK WORK durchgeführt wurde.
· Type E:
Es wird für alle Statussätze des IDocs der Status 51 (Fehler, Anwendungsbeleg nicht
gebucht) geschrieben und ein COMMIT WORK durchgeführt.
Andernfalls wird der Status 53 (Anwendungsbeleg gebucht) geschrieben und ein
COMMIT WORK durchgeführt.
18 April 2001
Daten filtern
Daten filtern
Für die asynchronen BAPI-Aufrufe über die BAPI-ALE-Schnittstelle stehen Ihnen zwei
Filterdienste zur Verfügung:
· Schnittstellenreduzierung:
Wenn Sie die BAPI-Schnittstelle reduzieren, müssen Sie keine Filterobjekttypen
definieren.
Die BAPI-Reduzierung ist bedingungslos, d.h. es handelt sich um eine Projektion der
BAPI-Schnittstelle.
Das BAPI, dessen Schnittstelle reduziert werden können soll, muß vom BAPI-Entwickler
über entsprechende Parameterarten als reduzierbar angelegt werden.
Dabei werden optionale BAPI-Parameter und/oder -Felder über das Verteilungsmodell
für die Datenübermittlung ausgeschaltet.
Sie können auf zwei Arten eine Schnittstelle reduzieren [Seite 22]:
· Feldweise (über Ankreuzleisten)
· Vollständig
· Parameterfilterung
Dazu werden der Business-Objektmethode einer Verbindung Filterobjekttypen [Extern]
zugeordnet. Die zulässigen Filterobjektwerte müssen im Verteilungsmodell definiert
werden.
Die BAPI-Parameterfilterung ist an Bedingungen geknüpft, also inhaltsabhängig: Zeilen
in Tabellenparametern eines asynchron aufgerufenen BAPIs werden abhängig von
Werten in den Zeilen (oder abhängiger Zeilen) zum Empfänger übermittelt.
Mit Filtern definieren Sie Bedingungen in Form von Parameterwerten, die von BAPIs
erfüllt werden müssen, um von der ALE-Ausgangsverarbeitung verteilt zu werden.
Bei der Parameterfilterung wird die Datenmenge der Tabellen eines BAPIs bestimmt.
Zwischen den Parametern der Tabellen eines BAPIs können auch
Hierarchiebeziehungen definiert werden..
Eine Verteilung über Klassen [Extern] wird ebenfalls unterstützt.
Einzelheiten finden Sie unter BAPI-Parameter filtern [Seite 27].
BAPI-Filterung ist der Begriff für die (wahlweise) gemeinsame Verwendung der beiden
Filterdienste der BAPI-Schnittstelle. Eine BAPI-Filterung wird nur als Service in der Ausgangs-
verarbeitung realisiert.
Voraussetzungen für die Verwendung der Filterdienste

Nachfolgend sind die Voraussetzungen aufgeführt, die von der BAPI-Schnittstelle erfüllt sein
müssen, damit die ALE-Filterdienste verwendet werden können.
Das BAPI kann folgende Parameterarten haben:
April 2001 19
Daten filtern
Feldweise Vollständige Parameter-

Reduzierung Filterung filterung
1. Unstrukturiert ohne Ankreuzleiste.
2. Unstrukturiert mit Ankreuzfeld. X
3. Einzeilig strukturiert ohne Ankreuzleiste.
4. Einzeilig strukturiert mit Ankreuzleiste. X
5. Mehrzeilig strukturiert ohne Ankreuzleiste. X X
6. Mehrzeilig strukturiert mit Ankreuzleiste. X X X
7. Mehrzeilig unstrukturiert ohne X

Ankreuzleiste.
8. Mehrzeilig unstrukturiert mit Ankreuzleiste.
Anmerkung: Die mit X versehenen Felder erfüllen die Voraussetzungen.
Erläuterung zur obigen Matrix:
1. Ein unstrukturierter Parameter ohne Ankreuzleiste ist z.B. ein Schlüsselfeld des BAPIs (z.B.
der Parameter Material in Methoden zum Business Objekt Material).
Diese Parameterart kann nicht reduziert werden.
2. Gibt es zu einem unstrukturierten Parameter mit Namen P einen unstrukturierten
Ankreuzparameter mit Namen PX und Datenelement BAPIUPDATE, so ist der Parameter P
reduzierbar.
Die Reduzierung erfolgt durch Setzen des Wertes von P und des Ankreuzparameters PX auf
LEER.
3. Ein einzeiliger, strukturierter Parameter ohne Ankreuzleiste ist nicht reduzierbar.
4. Ein einzeiliger, strukturierter Parameter P mit Struktur S und zugehöriger Ankreuzleiste PX
mit Struktur SX ist feldweise reduzierbar, wenn folgendes zutrifftt:
· S und SX haben die gleiche Anzahl von Feldern, die in Namen und Reihenfolge identisch
sind.
· Das FUNCTION-Feld, sowie Schlüsselfelder in S und SX haben jeweils das selbe
Datenelement.
· Alle anderen Felder in SX haben das Datenelement BAPIUPDATE.
Das FUNCTION Feld in P, sowie die Schlüsselfelder müssen als Mußfelder gekennzeichnet
werden. Alle anderen Felder können wahlweise als Mußfelder gekennzeichnet werden.
Mußfelder sind nicht reduzierbar. Die Reduzierung für nicht-Mußfelder erfolgt durch Setzen
des Feldwertes und des korrespondierenden Ankreuzfeldes auf LEER.
5. Mehrzeilig strukturierte Parameter (Tabellenparameter) ohne Ankreuzleiste sind nicht
feldweise reduzierbar. Parameterfilterung und vollständige Filterung sind möglich.
20 April 2001
Daten filtern
Ist die Hierarchie gepflegt und existieren in der Hierarchie abhängige Tabellen, so werden
Sätze der abhängigen Tabellen mitgefiltert.
6. Ein mehrzeiliger, strukturierter Parameter P mit Ankreuzleiste PX ist feldweise reduzierbar,
vollständig filterbar und Parameterfilterung ist möglich.
· Für die feldweise Reduzierung gelten die Voraussetzungen unter 4.
· Die Ankreuzleiste PX muß in der Hierarchie direkt unter P mit identischen Schlüsselfeldern
stehen, damit bei der Parameterfilterung die korrespondierenden Zeilen aus P und PX
gefiltert werden.
· Ist die Hierarchie gepflegt und existieren in der Hierarchie abhängige Tabellen, so werden
Sätze der abhängigen Tabellen mitgefiltert.
7. Ein mehrzeiliger, unstrukturierter Parameter kann nur vollständig gefiltert werden und darf
nicht in eine Hierarchie aufgenommen werden.
Parameterfilterung ist nicht erlaubt.
8. Für einen mehrzeiligen, unstrukturierten Parameter mit Ankreuzleiste kann keine Filterung
durchgeführt werden.
April 2001 21
Schnittstelle reduzieren
Schnittstelle reduzieren
Verwendung
Die Integration von BAPIs und ALE hat zum Ziel, daß zukünftige ALE-Geschäftsprozesse BAPIs
als Schnittstellen verwenden können.
BAPI-Reduzierungen werden besonders in ALE-Geschäftsprozessen erforderlich, in denen
Stammdaten asynchron repliziert werden:
· Ein Teil der BAPI-Parameter wird, obwohl beim Aufruf angegeben, beim Empfänger nicht
benötigt.
· Genaue Kontrolle, welche Daten in Fremdsysteme (nicht R/3 und/oder zwischen
Geschäftspartnern) übertragen werden (z.B. durch ausblenden von Feldern).
· Bestimmte Daten dürfen beim Empfänger nicht überschrieben werden.
BAPI-Reduzierungen sind jedoch auch überall einsetzbar, wo asynchrone BAPI-Aufrufe genutzt
werden.
Beim asynchronen Aufruf eines BAPIs über die BAPI-ALE-Schnittstelle sollen nur die Parameter
der BAPI-Schnittstelle übermittelt werden, die für den Empfänger relevant sind. BAPI-
Reduzierungen können Sie im ALE-Verteilungsmodell im Rahmen der empfängerabhängigen
Filterung einstellen. Für Reduzierungen können Sie Vorlagen anlegen.
Material-Stammdaten werden von einem Referenzsystem auf ein Vertriebssystem

repliziert. Da in dem Vertriebssystem nur ein Teil der zum Material erfaßten Daten
benötigt werden, wird eine Reduzierung der Schnittstelle des BAPIs
Material.SaveReplica definiert, in dem nur vertriebsrelevante Parameter
vorhanden sind. Im Verteilungsmodell wird dann eingestellt, daß mit
Material.SaveReplica nur vertriebsrelevante Daten zum Vertriebssystem
kommuniziert werden.
Die BAPI-Filterung (Parameterfilterung und Reduzierung) können Sie beim Pflegen des
Verteilungsmodells vornehmen. Die Reduzierungs- und Filterinformationen sind als Bestandteil
der ALE-Customizing-Daten im Verteilungsmodell enthalten.
Die BAPI-Filterung muss beim Generieren der BAPI-ALE-Schnittstelle explizit aktiviert werden.
Die Reduzierung des eigentlichen (asynchronen) BAPI-Aufrufs erfolgt als Service in der ALE-
Schicht.
Der Reduzierungsdienst fragt die Filtereinstellungen des Verteilungsmodells zur Laufzeit ab.
Die Anwendungsentwicklung erhält die Möglichkeit, für einen Empfänger oder eine Liste von
Empfängern vor dem Aufruf der BAPI-ALE-Schnittstelle die Liste der zu füllenden Parameter
abzufragen, um die Lesezugriffe auf die Datenbank so gering wie möglich zu halten. (Der Aufruf
kann wahlweise stattfinden und beeinflußt nicht das Ergebnis der Filterung.)
Für jedes Sender-Empfänger-Paar können Sie nur eine Reduzierung eines BAPIs einstellen.
22 April 2001
Voraussetzungen
Voraussetzungen
Die Grunddaten der BAPI-Reduzierung werden vom BAPI-Entwickler nach der Freigabe des
BAPIs und vor der Generierung der BAPI-ALE-Schnittstelle gepflegt. Sofern eine
Parameterhierarchie verwendet werden soll, muß diese ebenfalls vorher festgelegt werden.
Das BAPI muß vom BAPI-Entwickler über entsprechende Parameterarten als reduzierbar
angelegt werden. Muß-Parameter und –Felder müssen festgelegt werden.
Eine Matrix mit den Voraussetzungen für die Verwendung der Filterdienste finden Sie unter
Daten filtern [Extern].
Vollständig reduzierbare Parameter

Das vollständige Reduzieren von Parametern eines BAPIs ist nur für Tabellenparameter möglich.
Eine vollständig reduzierte Tabelle ist beim Empfänger leer.
Für einen vollständig reduzierbaren Tabellenparameter T1 mit Ankreuzleiste gelten folgende
Voraussetzungen:
Tabellenparameter Struktur
T1 Q1
T1X Q1X
T1X ist ein Ankreuzparameter.
Feldweise reduzierbare Parameter

Die Reduzierung auf Feldebene wird durch Umsetzung der obligatorischen Ankreuzfelder eines
BAPIs und Initialisierung der entsprechenden Felder im Datenparameter erreicht. Die
Ankreuzleisten müssen den Datenparametern über Namens- und Strukturkonventionen
zugeordnet sein.
Für einen feldweise reduzierbaren Parameter P1 gelten folgende Voraussetzungen:
Tabellenparameter Struktur
P1 S1
P1X S1X
Die Strukturen S1 und S1X müssen die gleiche Anzahl von Feldern haben, wobei die Namen der
Felder in beiden Parametern identisch und in gleicher Reihenfolge sein müssen.
Wenn P1 ein FUNCTION-Feld oder Schlüsselfelder hat, so hat das FUNCTION-Feld in S1 und
S1X und jeweils die Schlüsselfelder das selbe Datenelement. Alle weiteren Felder der
Ankreuzleiste verwenden das Datenelement BAPIUPDATE.
Vorgehensweise
BAPI-Reduzierungen müssen wie folgt durchgeführt werden:
1. Erstellen Sie ein reduzierbares BAPI, das die obigen Voraussetzungen erfüllt.
2. Vor dem Generieren der BAPI-ALE-Schnittstelle müssen Sie die Datenfilterung explizit
aktivieren (Option Datenfilterung erlaubt).
Die Filterung können Sie im Verteilungsmodell über das Customizing unter Verteilung (ALE) ®
Geschäftsprozesse modellieren und implementieren ® Verteilungsmodell pflegen einstellen.
April 2001 23
Voraussetzungen
Ergebnis
Die generierte BAPI-ALE-Schnittstelle ermöglicht die BAPI-Filterung als Service in der
Ausgangsverarbeitung.
24 April 2001
Filterobjekttypen definieren und zuordnen

Manchen BAPIs Ihrer SAP-Anwendungen sind bereits Filterobjekttypen [Extern] für die
Empfänger- und Datenfilterung zugeordnet.
Sie können auch eigene Filterobjekttypen definieren und dann einem BAPI bzw. einem BAPI-
Parameter zuordnen.
Ablauf
Um Filterobjekttypen für BAPIs einzurichten, müssen Sie folgende Schritte ausführen:
· Filterobjekttypen definieren
Wählen Sie dazu im SAP-Menü Werkzeuge ® ALE ® Entwicklung und dann BAPI-
Schnittstelle.
Sie können Filterobjekttypen über die Datenfilterung oder Empfängerermittlung anlegen:
Wählen Sie dann Filterobjekttyp pflegen (Transaktion BD95, Tabelle TBD11).
Legen Sie den Namen des Filterobjekttyps fest und hinterlegen Sie eine Referenz auf ein
Tabellenfeld. Der Verweis auf ein Tabellenfeld wird benötigt, um die Dokumentation aus
dem Datenelement zu ziehen und eine Wertehilfe für den Kunden bei der Pflege des
Verteilungsmodells anbieten zu können. Daher muß für das Tabellenfeld der
Fremdschlüssel gepflegt sein.
Für den Namen des Filterobjekttyps sind folgende Konventionen zu beachten
- Release 3.0/3.1: Domänenname (Beispiel: KOKRS für den Kostenrechnungskreis)
- Release 4.0: Default-Feldname für das Datenelement (Beispiel: COMP_CODE für
den Buchungskreis)
Kontrollieren Sie, ob unter der Domäne und dem Default-Feldnamen des
Datenelements für das gewünschte Objekt bereits ein Eintrag vorhanden ist. Falls
nicht, muß ein neues Filterobjekt angelegt werden. In der Regel wird das Filterobjekt
auch in der Schnittstelle des BAPIs als Feld in der Übergabestruktur auftauchen, z.B.
bapiachead-comp_code.
In diesem Fall sollte das Filterobjekt wie folgt angelegt werden:
ALE-Objekttyp: Feldname in der BAPI-Struktur, z.B. comp_code
Tabellenname: Name der BAPI-Struktur, z.B. bapiachead
Feldname: Feldname in der BAPI-Struktur, z.B. comp_code
· Filterobjekttypen einem BAPI zuordnen
Wählen Sie dazu im SAP-Menü Werkzeuge ® ALE ® Entwicklung und dann BAPI-
Schnittstelle.
Sie können einmem BAPI Filterobjekte für die Empfängerermittlung und die
Datenfilterung zuordnen.
In der jeweiligen Sicht auf die Tabelle TBD16 werden die für eine Objekt-Methode
zugelassenen Filterobjekttypen gepflegt:
- Empfängerermittlung:
April 2001 25
Wählen Sie Filterobjekttyp einem BAPI zuordnen.

Sie können folgende Einträge pflegen:
Objekttyp (aus Tabelle TOJTB),
Methode,
Filterobjekttyp (aus Tabelle TBD11)
Beachten Sie, dass Sie bei der Empfängerermittlung ein Business Add-In
implementieren müssen, um Werte Ihre selbstdefinierten Filterobjekttyps zu ermitteln
(siehe Eigene Filterobjekte über Business Add-Ins ermitteln [Seite 44]).
- Datenfilterung:
Wählen Sie Filterobjekttyp einem Parameter zuordnen.
Sie können folgende Einträge pflegen:
Objekttyp (aus Tabelle TOJTB),
Methode,
Filterobjekttyp (aus Tabelle TBD11)
Parameter
Feldname
Nehmen Sie die erforderlichen Einträge vor, um ein Filterobjekt einer Objekt-
Methode für die Empfängerermittlung oder Parameterfilterung zuzuordnen.
26 April 2001
BAPI-Parameter filtern
Verwendung
Die Parameterfilterung ermöglicht es, über Filterobjekte im ALE-Verteilungmodell den Umfang
der zu replizierenden Datenmenge in der Schnittstelle eines BAPIs zu steuern.
Die Parameterfilterung bezieht sich auf die Tabellenparameter eines BAPIs. Dabei werden die
Zeilen der BAPI-Tabellenparameter herausgefiltert, die den definierten Verteilungsbedingungen
nicht entsprechen. Die herausgefilterten Tabellenzeilen werden nicht repliziert.
Bsp.: Das logische System Q4VCLNT800 ist der BAPI-Server für das BAPI
RetailMaterial.Clone. Zu diesem System sollen durch die Parameterfilterung nur die
Werksdaten vom Werk 001 eines Materials repliziert werden.
Voraussetzungen
Die Voraussetzung für diese Filterung ist, dass dem entsprechenden BAPI Ihrer SAP-
Anwendungen ein Filterobjekttyp [Extern] zugeordnet ist. Für manche BAPIs wurden durch SAP
bereits Filterobjekttypen definiert und diesen zugeordnet. Sie können auch eigene
Filterobjekttypen definieren und einem BAPI zuordnen [Seite 25].
Die zulässigen Filterobjektwerte müssen Sie im Verteilungsmodell definieren. Einzelheiten dazu
erfahren Sie im R/3-Einführungsleitfaden unter Basis ® Application Link Enabling (ALE) ®
Geschäftsprozesse modellieren und implementieren ® Verteilungsmodell pflegen.
Die BAPI-Parameterfilterung ist vorerst nur für die Verteilung von Stammdaten über asynchron
aufgerufene BAPIs relevant. Deshalb ist das notwendige ALE-Customizing für die
Parameterfilterung nur für asynchron aufgerufene BAPIs mit einer ALE-IDoc Schnittstelle
zulässig.
Eine Parameterfilterung für die Verteilung von Bewegungsdaten über asynchrone BAPIs ist
zulässig, aber in den meisten Fällen nicht sinnvoll.
Die BAPI-Parameterfilterung für asynchrone BAPIs ist grundsätzlich optional. Sie müssen diese
explizit über ein Ankreuzfeld aktivieren, wenn Sie die BAPI-IDoc-Schnittstelle generieren [Seite
32]. Andernfalls wird kein Programmcode in der BAPI-IDoc-Schnittstelle generiert.
Falls eine BAPI-IDoc-Schnittstelle ohne Parameterfilterung generiert wurde, können Sie
nachträglich keine Parameterfilterung im ALE-Customizing einstellen.
Funktionsumfang
Die Parameterfilterung erfolgt dynamisch zur Laufzeit anhand der aktuellen Daten in den BAPI-
Tabellenparametern und den Verteilungsbedingungen im ALE-Verteilungsmodell:
· Lesen der definierten Parameter-Filterobjekte im Verteilungsmodell
· Lesen der Schnittstellendefinition des BAPIs
· Lesen der Tabellen-Feldwerte eines Tabelleneintrages für die zugehörigen Filterobjekte
· Verteilungsbedingung mit den gelesenen Filterobjektwerten vergleichen und Wert des
logischen Ausdrucks bestimmen
· Tabelleneintrag löschen
April 2001 27
· Hierarchisch abhängige BAPI-Parameter untersuchen und ggf. abhängige Tabelleneinträge

löschen
· Für synchrone BAPIs: enstprechenden Funktionsbaustein aufrufen und gefilterte Parameter
übergeben
· Für asynchrone BAPIs: die generierte BAPI-ALE-Schnittstelle aufrufen und gefilterte
Parameter übergeben
Die BAPI-Parameterfilterung kann zusätzlich eine hierarchische Abhängigkeit zwischen den
BAPI-Tabellenparametern berücksichtigen (siehe Hierarchien zwischen BAPI-Parametern
definieren [Seite 29]). Solche hierarchischen Abhängigkeiten müssen Sie vor der Generierung
der BAPI-ALE-Schnittstelle des BAPIs festlegen. Die festgelegte Hierarchie wird während der
Generierung ausgewertet und in den Code der Schnittstelle eingebunden. Folglich macht jede
nachträgliche Änderung der Hierarchie eine Nachgenerierung der BAPI-ALE-Schnittstelle
erforderlich.
Nach der Freigabe des generierten IDoc-Typs kann die festgelegte Hierarchie des asynchron
aufrufbaren BAPIs aus Kompatibilitätsgründen nicht mehr verändert werden.
28 April 2001
Hierarchien zwischen BAPI-Parametern definieren

Verwendung
Wenn Sie eigene ALE-Geschäftsprozesse entwickeln, kann es erforderlich sein, dass Sie für die
Parameterfilterung hierarchische Abhängigkeiten zwischen BAPI-Tabellenparametern definieren
müssen.
Solche Abhängigkeiten werden über Feldreferenzen zwischen den Parametern der Tabellen
eines BAPIs definiert.
Die Parameterfilterung für die Bestimmung der Datenmenge und damit auch die Definition von
Abhängigkeiten ist nur für die Verteilung von Stammdaten über asynchron aufgerufene BAPIs
relevant und zulässig.
Ein BAPI für Material-Stammdaten enthält u.a. die Tabellen für Werksdaten und
zugehörige Lagerdaten. Die Tabelle für Werksdaten referenziert auf die Tabelle für
Lagerdaten über das Schlüsselfeld WERKS. Es existiert eine hierarchische
Abhängigkeit zwischen den Werks- und Lagerdaten, d.h. wenn das Werk 001 zu
einem Material aufgrund der Parameterfilterung nicht repliziert werden soll, dann
werden auch die Lagerdaten zu dem Werk 001 nicht repliziert.
Voraussetzungen
Sie nutzen die BAPI-Parameterfilterung zur Steuerung des Umfangs der Datenmenge in der
Schnittstelle eines BAPIs.
Vorgehensweise
Solche hierarchischen Abhängigkeiten können Sie in der ALE-Entwicklung über BAPI ®
Datenfilterung ® Hierarchie der Tabellenparameter pflegen definieren.
Geben Sie den Objekttyp und die Methode des BAPIs ein. Über die Eingabehilfe können Sie
sich die vorhandenen BOR-Objekttypen und die zugehörigen Methoden anzeigen und eine
Auswahl vornehmen.
Im Menü Hierarchie gibt es folgende Bearbeitungsaktivitäten für die Hierarchieerstellung:
· Anlegen
· Ändern
· Anzeigen
· Löschen
Hierarchie anlegen
Es wird geprüft, ob eine Hierarchie für das BAPI bereits existiert. Anschließend wird geprüft, ob
bereits eine ALE-IDOC Schnittstelle generiert wurde und ob das zugehörige IDOC bereits
freigegeben wurde.
Wenn das IDOC bereits freigegeben wurde, muß davon ausgegangen werden, daß die
generierte Schnittstelle bereits zum Kunden ausgeliefert wurde und somit aus
Kompatibilitätsgründen zu einem bestehenden BAPI keine Hierarchie angelegt bzw. geändert
April 2001 29
werden kann. In diesem Fall müssen Sie ein neues BAPI anlegen. Eine entsprechende
Fehlermeldung wird angezeigt. Existiert die ALE-Schnittstelle bereits, aber das IDOC ist noch
nicht freigegeben, so werden Sie darauf hingewiesen, daß eine Nachgenerierung notwendig ist.
Im Folgebild wird ein grafischer Hierarchiebaum angezeigt. Einzelheiten dazu finden Sie unter
Grafische Hierarchieanzeige bearbeiten weiter unten.
Hierarchie ändern
Es erfolgen die gleichen Prüfungen wie beim Anlegen. Im Folgebild gibt es die gleichen
Bearbeitungsaktivitäten wie beim Anlegen
Hierarchie anzeigen
Es erfolgen die gleichen Prüfungen wie beim Anlegen. Im Folgebild können keine Änderungen
an der Hierarchie vorgenommen werden.
Um die Feldreferenzen zwischen den Tabellen anzusehen, führen Sie einen Doppelklick auf der
Elterntabelle aus. Die Elterntabelle wird automatisch in das folgende Einblendfenster
übernommen. Über die Eingabehilfe können Sie eine der möglichen Kindtabellen auswählen.
Über die Drucktaste Feldreferenzen können Sie sich die Feldreferenzen anzeigen.
Hierarchie löschen
Es erfolgen die gleichen Prüfungen wie beim Anlegen. Nach einer Sicherheitsabfrage wird die
Hierarchie zu dem BAPI gelöscht.
Grafische Hierarchieanzeige bearbeiten

In der grafischen Hierarchieanzeige entspricht der Wurzelknoten dem Funktionsbaustein zu dem
BAPI. Der Wurzelknoten dient nur zur Anzeige und wird nicht gesichert. Er kann auch nicht
geändert werden.
Die grafische Anzeige können Sie wie folgt bearbeiten:
· Tabellenparameter hinzufügen
· Tabellenparameter löschen
· Feldreferenzen zwischen Eltern- und Kindtabelle pflegen
· Hierarchie sichern
Eltern-Tabellen, die direkt unter dem Wurzelknoten eingefügt werden und keine Kindtabellen
besitzen, werden nicht gesichert. Falls nur derartige Elterntabellen angelegt werden, so existiert
keine Hierarchie und folglich wird auch keine Hierarchie gesichert.
Tabellenparameter hinzufügen
Positionieren Sie den Cursor auf einen Knoten der Hierarchiedarstellung und wählen Sie
Bearbeiten ® Tabellenparameter hinzufügen.
Wenn Sie den Cursor auf den Wurzelknoten positionieren, können Sie über die Eingabehilfe eine
Eltern-Tabelle der obersten Ebene auswählen.
Wenn eine Tabelle über dem markierten Knoten existiert, wird diese in das folgende
Einblendfenser automatisch übernommen, und Sie können zu dieser Tabelle eine Kind-Tabelle
hinzufügen.
30 April 2001
Grundsätzlich kann eine Tabelle nur einmal in der Hierarchie existieren. über die Eingabehilfe
können Sie sich die verfügbaren Tabellen anzeigen.
Im Einblendfenster können Sie sich über die Drucktaste Feldreferenzen die gemeinsamen Felder
der Eltern- und Kindtabelle anzeigen, über die Feldreferenzen definiert werden können. Durch
Markieren können Sie die Felder auswählen, für die eine Feldreferenz definiert werden soll. Falls
keine Feldreferenzen zwischen den beiden Tabellen existieren, so wird ein Fehlermeldung
ausgegeben.
Tabellenparameter löschen
Um eine Tabelle zu löschen, positioniert Sie den Cursor auf den entsprechenden Knoten der
Hierarchiedarstellung mit dem Tabellennamen der Kind-Tabelle. Bestätigen Sie die
Sicherheitsabfrage. Grundsätzlich werden alle weiteren Kind-Tabellen der zu löschenden Tabelle
ebenfalls gelöscht.
Feldreferenzen zwischen Eltern- und Kindtabellen pflegen

Positionieren Sie den Cursor auf den Knoten einer Kind-Tabelle und wählen Sie Bearbeiten ®
Tabellenparameter ® Feldreferenzen ändern oder die Drucktaste Feldreferenz mit der
Änderungsikone.
Das folgende Einblendfenster enthält den Elternparameter und, sofern eine Referenz bereits
existiert, auch den Kindparameter.
Beim Anlegen können Sie über die Eingabehilfe die zugehörige Kindtabelle auswählen.
Über die Drucktaste Feldreferenzen können Sie sich die gemeinsamen Felder anzeigen. Es
werden nur Feldreferenzen auf Felder angezeigt, die namensgleich in Eltern- und Kind-Tabellen
vorkommen.
Durch Markieren können Sie Referenzen zwischen Feldern definieren. Bereits definierte
Feldreferenzen sind bereits markiert.
Hierarchie sichern
Um eine Hierarchie zu sichern, wählen Sie Hierarchie ® Sichern.
Beim Sichern wird ein Transportauftrag abgefragt, da die zugehörige Customizing-Tabelle an das
Korrektur- und Transportsystem angeschlossen ist.
Die Hierarchie wird nicht gesichert, wenn ein Fehler beim Datenbankzugriff auftritt. Eine
entsprechende Fehlermeldungen wird ausgegeben.
April 2001 31
BAPI-ALE-Schnittstelle pflegen
Das R/3-System enthält in der Standardauslieferung eine große Anzahl von Business-Objekten
und BAPIs. Dazu gehören auch BAPI-ALE-Schnittstellen, die aus BAPIs generiert wurden und
den asynchronen BAPI-Aufruf in ALE-Geschäftsprozessen ermöglichen.
Sie können Ihre eigene BAPIs in Ihrem Namensraum entwickeln und entsprechende BAPI-ALE-
Schnittstellen generieren.
Dabei werden zu einem BAPI folgende Objekte generiert:
· Nachrichtentyp
· IDoc-Typ einschließlich der Segmente
· Funktionsbaustein, der auf der Ausgangsseite aufgerufen wird
(Er baut aus den BAPI-Daten das IDoc auf und versendet es.)
· Funktionsbaustein, der auf der Eingangsseite mit den IDoc-Daten das BAPI aufruft
Der Unterschied zu manuell gepflegten Nachrichtentypen besteht darin, daß der
Funktionsbaustein zur Auswertung der Änderungszeiger kein IDoc aufbaut, sondern die
entsprechenden BAPI-Strukturen füllt, die Empfängerermittlung durchführt und den generierten
ALE-Funktionsbaustein aufruft.
Die generierten Nachrichtentypen, IDoc-Typen und Funktionsbausteine können auch für die
Stammdatenverteilung über das SMD-Tool verwendet werden.
Voraussetzungen
Als Grundvoraussetzung gilt das Vorhandensein eines BAPIs:
· Sie haben ein eigenes BAPI im Kundennamensraum entwickelt.
· Sie haben ein BAPI der Standardauslieferung modifiziert.
Die BAPI-ALE-Schnittstelle wird dann für den Subtyp und eine ihm zugeordnete Methode im
Kundennamensraum erzeugt.
Einzelheiten dazu finden Sie unter Eigene BAPIs implementieren [Seite 17].
Unabhängig davon, ob zu einem BAPI von SAP eine BAPI-ALE-Schnittstelle mit

einem neuen Release ausgeliefert wurde oder nicht, funktioniert eine von Ihnen
daraus generierte Schnittstelle weiter wie im alten Release-Stand. Sie können die
alte Schnittstelle nachgenerieren, um eventuell neu eingefügte Parameter
anzupassen, sofern SAP zum neuen Release keine Schnittstelle ausgeliefert hat.
Wenn SAP eine BAPI-ALE-Schnittstelle zu einem BAPI ausliefert, für das Sie bereits
eine Schnittstelle generiert haben, dann sollten Sie diese neue Schnittstelle
verwenden und Ihre selbst generierte löschen. Die alte Schnittstelle können Sie zwar
noch verwenden, aber im alten Release-Stand. Ein Nachgenerieren der alten
Schnittstelle kann dazu führen, daß manche generierten Objekte wie z.B. Segmente
von SAP-Objekten überschrieben werden, wenn die Schnittstelle in Ihrem BAPI-
Funktionsbaustein die BAPI-Strukturen referenziert, die aber SAP gehören.
Wenn Sie hierarchische Abhängigkeiten zwischen den BAPI-Tabellenparametern
berücksichtigen möchten, dann müssen Sie als eine weitere Voraussetzung diese
32 April 2001
Hierarchiepflege vor der Generierung der BAPI-ALE-Schnittstelle durchführen (siehe Hierarchien

zwischen BAPI-Parametern definieren [Seite 29]). Die festgelegte Hierarchie wird während der
Generierung ausgewertet und in den Code der Schnittstelle eingebunden. Folglich macht jede
nachträgliche Änderung der Hierarchie eine Nachgenerierung der BAPI-ALE-Schnittstelle
erforderlich.
Nach der Freigabe des generierten IDoc-Typs kann die festgelegte Hierarchie des asynchron
aufrufbaren BAPIs aus Kompatibilitätsgründen nicht mehr verändert werden.
Beachten Sie auch die Hinweise auf verwandte ALE-Themen am Ende dieses Abschnitts. Sie
finden dort Informationen zur Datenfilterung, Serialisierung von Nachrichten und zu weiteren
Themen.
Vorgehensweise
Wählen Sie in der ALE-Entwicklung den Pfad BAPI ® ALE-Schnittstelle pflegen.
Beachten Sie, dass in Kundensystemen alle Objektnamen mit Y oder Z oder einem eigenen
Präfix beginnen müssen.
Verfahren Sie dann wie folgt:
1. Geben Sie das Ihrer Schnittstelle zugrundeliegende Business-Objekt (Objekttyp) und die
Methode ein.
2. Wählen Sie im Menü Schnittstelle eine der Optionen, um eine Schnittstelle zu pflegen,
anzuzeigen, zu prüfen oder zu löschen:
· Schnittstelle anlegen
Voraussetzung: Für dieses BAPI wurde noch keine Schnittstelle generiert oder eine
bereits erzeugt Schnittstelle wurde über die Option Löschen gelöscht.
Die Namen für die zu generierenden Objekte werden vorgeschlagen. Sie können diese
ändern.
1. Geben Sie einen Namen für den Nachrichtentyp an.
Es erscheint ein Dialogfenster.
Die vorgeschlagenen Namen werden nach folgender Konvention vergeben:
Nachrichtentyp: Betriebswirtschaftlicher Begriff
Beispiel: MYTEST
Bestätigen Sie Ihre Eingabe.
2. Im nachfolgenden Dialogfenster können Sie folgende Angaben vornehmen:
IDoc-Typ: <Nachrichtentyp>01
Beispiel: MYTEST01
Funktionsbaustein im Ausgang: ALE_<OBJECT>_<METHOD>
Beispiel:
ALE_EXAMPLE_TEST
Funktionsbaustein im Eingang: IDOC_INPUT_<Nachrichtentyp>
Beispiel:
IDOC_INPUT_MYTEST
Die vorgeschlagene Entwicklungsklasse und die Funktionsgruppe sind die, zu denen
der BAPI-Funktionsbaustein gehört. Sie sollten bei Ihrer eigenen
April 2001 33
Schnittstellengenerierung eigene Entwicklungsklassen und Funktionsgruppen

verwenden.
Folgende Optionen stehen Ihnen zur Verfügung:
· Datenfilterung erlaubt
Wenn Sie eine Filterung durchführen möchten, dann müssen Sie im
Dialogfenster beim Anlegen oder Ändern die Option Datenfilterung erlaubt
wählen. Bei BAP-ALE-Schnittstellen, die von SAP generiert werden, ist diese
Option in der Regel gewählt. Beachten Sie dazu auch die Hinweise unten.
· Aufruf in Update Task
Wenn die Datenbankänderungen durch Methoden über die Verbuchung
durchgeführt werden, dann muss dieses Kennzeichen gewählt werden.
· Paketverarbeitung erlaubt
Wenn Sie eine Paketverarbeitung von IDocs zulassen möchten, müssen Sie
diese Option wählen. Das zugehörige BAPI muss paketverarbeitungsfähig sein.
Die Paketgröße stellen Sie im ALE-Customizing ein.
Sie können nur den Nachrichtentyp (Muß-Feld) und den IDoc-Typ (Muß-Feld), oder
nur einen der Funktionsbausteine (Kann-Felder) generieren, indem Sie das Feld, für
das kein Objekt generiert werden soll, leer übergeben.
3. Bestätigen Sie Ihre Eingaben.
Es erscheint das Dialogfenster Segmentname eingeben.
4. Geben Sie einen Segmentnamen ein.
Der vorgeschlagene Segmenttyp ist abgeleitet aus Nachrichtentyp bzw. BAPI-
Strukturen:
- E1<Nachrichtentyp> für einzelne Felder als Kopfsegment
Beispiel: E1MYTEST, bzw.
- E1BP_XX... für Parameter der Struktur BAPI_XX...
Beispiel: E1BP_HUGO für
BAPI_HUGO
Sollte ein Segment mehr als 1000-Bytes Daten enthalten, werden automatisch
Kindersegmente darunter generiert. Die Namen der Kindersegmente werden mit
Ziffer 1, 2,... nach dem ursprünglichen Segment erweitert vergeben, sofern die Länge
der Namen weniger als 27-stellig ist.
· Schnittstelle ändern
Voraussetzung: Zu diesem BAPI wurden bereits Objekte angelegt.
Wählen sie Ändern, um nach einer Änderung des BAPIs die Objekte einer bereits
existierenden ALE-Schnittstelle erneut zu generieren. Der IDoc-Typ und die IDoc-
Segmente werden neu generiert, wenn sich die Schnittstellenstrukturen der Objekt-
Methode geändert haben. Die Funktionsbausteine werden nur dann neu generiert, wenn
sich der IDoc-Typ oder eines der Segmente geändert haben.
Ähnlich wie beim Anlegen erscheint beim Ändern ein Dialogfenster. In diesem
Dialogfenster werden die Objekte angezeigt, die bereits im System vorhanden sind. Sie
sind nicht eingabebereit.
34 April 2001
Falls ein Feld leer ist, können Sie das entsprechende Objekt generieren.
· Schnittstelle anzeigen
Voraussetzung: Zu diesem BAPI sind bereits Objekte vorhanden.
Es werden alle existierenden Objekte zu diesem BAPI angezeigt. Damit erhalten Sie
einen Überblick über den Zusammenhang zwischen BAPI-Methode und IDoc-
Nachrichtentyp.
· Schnittstelle löschen
Die Funktionsbausteine werden in jedem Fall gelöscht, sofern sie im System vorhanden
sind.
Die IDoc-Struktur wird gelöscht, wenn sie noch nicht freigegeben ist.
Die IDoc-Segmente werden nur dann gelöscht, wenn sie nicht freigegeben sind und nicht
in anderen IDocs verwendet werden.
Zum Schluß wird der Nachrichtentyp gelöscht, wenn er keine Zuordnung mehr zum Idoc-
Typ hat.
· Schnittstelle prüfen
Es werden alle Objekte bezüglich dieses BAPIs darauf geprüft, ob sie bereits im System
vorhanden sind. Es wird auch geprüft, ob Objekte (IDoc-Typ und Segmente) bereits
freigegeben sind.
Der Status der Freigabe für Objekte kann geändert werden (siehe Freigabe setzen und
Freigabe aufheben unter Hinweise unten).
5. Sie können die Schnittstelle freigeben.
Entwickler können den Status der Freigabe von IDoctyp und Segmenten ändern (über
Bearbeiten ® Freigabe setzen oder Freigabe aufheben).
Dafür sind die Berechtigungen S_IDCDFT_AL+ und S_IDCDFT_ALL des
Berechtigungsobjekts S_IDOCDEFT erforderlich.
Die Voraussetzung für die Freigabe ist, daß das BAPI bereits freigegeben ist. Bei der
Freigabe wird zunächst geprüft, ob die generierte Schnittstelle unter der BAPI-Methode
den aktuellen Status hat. Wenn nicht, wird abgefragt, ob die Schnittstelle neu generiert
werden soll. Es wird ermittelt, welche Segmente und welcher IDoc-Typ für die Freigabe
relevant sind. Für noch nicht freigegebene Objekte wird dann der neue Status
eingesetzt.
Die Freigabe kann jederzeit zurückgenommen werden. Diese Aktion ist an das
Transportwesen angeschlossen.
Die generierten Funktionsbausteine werden nicht freigegeben.
Ergebnis
Auf dem Ausgabebildschirm werden die bearbeiteten Objekte mit ihrem Status angezeigt. Alle
Änderungen werden in Transportaufträgen erfaßt.
April 2001 35
Hinweise
Beachten Sie auch die folgenden Hinweise:
· Namensraumerweiterung
Ab 4.5A ist die Namensraumerweiterung auch bei Kunden und Partnern unterstüzt.
· Filterung für die Datenauswahl

Die Verteilung von Daten kann an Bedingungen geknüpft sein, die im Verteilungsmodell
als Filter definiert werden.
Wenn Sie eine Filterung durchführen möchten, dann müssen Sie im Dialogfenster beim
Anlegen oder Ändern die Option Datenfilterung erlaubt wählen.
Weitere Einzelheiten dazu erfahren Sie unter Daten filtern [Extern].
Die Voraussetzung für eine funktionelle und betriebswirtschaftlich sinnvolle Filterung von
BAPI-Parametern ist das Bestehen von hierarchischen Abhängigkeiten zwischen den
Tabellenparametern des BAPIs. Dazu müssen diese Abhängigkeiten vor der
Generierung der Schnittstelle definiert werden. Wählen Sie dazu BAPI-Schnittstelle ®
Datenfilterung ® Hierarchie der Tabellenparameter pflegen. Beachten Sie, dass
Änderungen von Abhängigkeiten kompatibel sein müssen, da sich andernfalls die
Filterung anders verhält. Mehr zu diesem Thema finden Sie unter Hierarchien zwischen
BAPI-Parametern definieren [Seite 29].
· Serialisierung
Der Funktionsbaustein auf der Ausgangsseite hat einen optionalen Parameter
SERIAL_ID (Referenz auf die Kanalnummer). Dieser Eingabeparameter steuert die
Zuordnung von Nachrichten zu Objektkanälen. In einem Objektkanal werden alle
Nachrichten im Zielsystem in der gleichen Reihenfolge bearbeitet, wie sie im
Quellsystem entstanden sind. Ein Objektkanal wird durch einen Schlüssel aus dem
Objekttyp des BAPIs und der Kanalnummer identifiziert.
Mehr zu diesem Thema finden Sie unter Serialisierung über Objekttypen [Extern].
· Verknüpfungen
Die Verknüpfung im ALE beantwortet folgende Fragen:
- Auf der Ausgangsseite:
Aus welchem Anwendungsobjekt wurde das IDoc aufgebaut?
Die Voraussetzung ist, daß die Anwendung den Parameter
APPLICATION_OBJECTS im Funktionsbaustein auf der Ausgangsseite richtig
ausgefüllt hat.
- Auf der Eingangsseite:
Aus welchem Ausgangs-IDoc wurde das Eingangs-IDoc erzeugt, und welches
Anwendungsobjekt wurde aus diesem Eingangs-IDoc erzeugt?
Die Voraussetzung ist, daß für die BAPI-Methode ein Schlüssel im Business Object
Repository (BOR) definiert wurde und dieser Schlüssel im BAPI-Funktionsbaustein
im Exporting- oder Importing-Parameter enthalten ist. Dieser Schlüssel kann aus
mehreren Schlüsselfeldern zusammengesetzt sein. Existieren keine Schlüsselfelder
36 April 2001
im BOR, dann kann bei der entsprechenden Abfrage eine Verknüpfung mit einem
anderem Objekt angegeben werden.
· Dokumentation zu generierten Funktionsbausteinen

Es wurde auch Dokumentation zu generierten Funktionsbausteinen (Ausgang/Eingang)
erfaßt. Diese Dokumentation können Sie innerhalb der Schnittstelle aufrufen. Dort wird
beschrieben, welche Bedeutungen die Parameter haben und mit welchen Werten sie
vesorgt werden.
· BAPI-Rückgabeparameter und IDoc-Status

Sofern der Rückgabeparameter (Return-Parameter) von der Anwendung ausgefüllt ist,
wird der IDoc-Status und die dazugehörige Information aus dem Parameter in das IDoc
aufgenommen. Meldungstypen bestimmen den IDoc-Status.
Ist der Return-Parameter ein EXPORTING-Parameter, so wird ein einziger IDoc-
Statussatz geschrieben:
Meldungstyp A: Status 51 (Anwendungsbeleg nicht gebucht, mit DB-
Rollback)
Meldungstyp E: Status 51 (Anwendungsbeleg nicht gebucht, kein
DB-Rollback)
Meldungstyp W, I, S: Status 53 (Anwendungsbeleg gebucht)
Ist der Return-Parameter ein TABLES-Parameter, so können mehrere IDoc-Statussätze
geschrieben werden, je nach den Meldungstypen in der Tabelle:
Meldungstyp A: Status 51 (Anwendungsbeleg nicht gebucht, mit DB-
Rollback)
(Für Meldungstyp S ergibt sich kein Status)
Meldungstyp E: Status 51 (Anwendungsbeleg nicht gebucht, kein
DB-Rollback)
(Für Meldungstyp S ergibt sich kein Status)
Kein Meldungstyp A oder E: Status 53 (Anwendungsbeleg gebucht)
Die IDoc-Status-Sätze werden in derselben Reihenfolge geschrieben wie die Meldungen
im Return-Parameter.
Wurde der Return-Parameter nicht ausgefüllt, bedeutet dies, daß das BAPI erfolgreich
durch das IDoc aufgerufen ist. In diesem Fall wird von der ALE-Schicht ein IDoc-
Statussatz mit Status 53 (Anwendungsbeleg gebucht) geschrieben.
Im Fehlerfall wird nur die erste Meldung aus dem Return-Parameter in den Text der
zugehörigen Fehler-Aufgabe (Workitem) übernommen.
· Beschränkungen bezüglich der Schnittstellengenerierung

- Bei gleicher Bezugsstruktur von Parametern im BAPI-Funktionsbaustein
(IMPORTING und/oder TABLES) sollte die Generierungsfunktion nicht eingesetzt
werden. In dieser Situation ist die Abbildung von IDoc-Segment zu Parameter nicht
eindeutig. Daher sind die Parameter im IDoc-Eingang nicht identifizierbar.
- Bei einer Datenmenge von mehr als 1000 Bytes im Bezugsfeld zu einem Parameter
oder in einem Feld in der Bezugsstruktur können Sie die Generierungsfunktion nicht
April 2001 37
einsetzen, da nur ein Segment mit einer Datenmenge von maximal 1000-Bytes
geladen werden kann.
38 April 2001
Empfänger für ein BAPI ermitteln

Verwendung
Die Verteilung von Daten durch eine Objekt-Methode kann an Bedingungen geknüpft sein, die im
Verteilungsmodell über Filter festgelegt werden (über den R/3-Einführungsleitfaden: Basis ®
Application Link Enabling (ALE) ® Geschäftsprozesse modellieren und implementieren ®
Verteilungsmodell pflegen).
Die Voraussetzung dafür ist, dass dem entsprechenden BAPI Ihrer SAP-Anwendung ein
Filterobjekttyp zugeordnet ist. Für manche BAPIs wurden durch SAP bereits Filterobjekttypen
definiert und diesen zugeordnet. Sie können auch eigene Filterobjekttypen definieren und einem
BAPI zuordnen [Seite 25].
Vor dem Aufruf eines BAPIs bzw. einer generierten BAPI-ALE-Schnittstelle müssen deren
Empfänger ermittelt werden. Bei der Empfängerermittlung wird geprüft, ob die Filterobjekte die
vorgegebenen Bedingungen erfüllen und die erlaubten Empfänger zurückgegeben.
Im ALE-Verteilungsmodell können folgende Abhängigkeiten abgebildet werden:
· zwischen einem BAPI und einem Nachrichtentyp
· zwischen BAPIs
Solche Abhängigkeiten müssen von Seiten der Anwendung in einem Funktionsbaustein
implementiert werden. In der ALE-Entwicklung muss der Funktionsbaustein dem entsprechenden
Objekttyp zugeordnet werden (über Abhängigkeiten ® Funktionsbaustein für abhängiges
Business-Objekt pflegen).
Falls eine Abhängigkeit im ALE-Verteilungsmodell als eine Bedingung definiert ist, so wird der
Empfänger des referenzierten BAPIs bzw. Nachrichtentyps bestimmt.
Beispiel einer Abhängigkeit eines BAPIs von einem Nachrichtentyp:

Die Verteilung von Organisationsadressen wurde in die Objektpflege zum
Lieferanten integriert. Über ALE werden diese Adressdaten dann zusammen mit den
Objektdaten verteilt. Die Adressdaten stehen in Abhängigkeit zu den Objektdaten
und werden mittels BAPI verteilt. Die Objektdaten werden über den Nachrichtentyp
CREMAS verteilt.
Es existiert also eine Abhängigkeit zwischen einem BAPI und einem Nachrichtentyp.
Im Verteilungsmodell ist dem BAPI zur Verteilung von Organisationsadressen
(AddressOrg.SaveReplica) ein aktiver Empfängerfilter zugewiesen. Über das Attribut
abhängige Verteilung in der Filteranzeige wurde die Abhängigkeit aktiviert.
Aufgrund der Empfängerermittlung werden die Objektdaten mit den BAPI-
Adressdaten nur dann verteilt, wenn die Filterbedingung für CREMAS erfüllt sind.
ALE stellt Ihnen für die Empfängerermittlung mit der Funktionsgruppe BDAPI eine Reihe von
Funktionsbausteinen zur Verfügung.
Funktionsumfang
Die Funktionsbausteine der Funktionsgruppe BDAPI haben folgenden Funktionsumfang:
April 2001 39
Funktionsbaustein Funktionsumfang
ALE_BAPI_GET_FILTEROBJECTS Filterobjekte eines BAPIs abfragen [Seite 41]
ALE_ASYNC_BAPI_GET_RECEIVER Empfänger für asynchrone BAPIs ermitteln [Seite 42]
ALE_SYNC_BAPI_GET_RECEIVER Empfänger für synchrone BAPIs ermitteln [Seite 53]
ALE_BAPI_GET_UNIQUE_RECEIVE Einzigen Empfänger für synchrone BAPIs ermitteln
R [Seite 58]
Folgende Beispielprogramme stehen Ihnen für die Empfängerermittlung zur

Verfügung:
· Beispielprogramme mit asynchronem BAPI-Aufruf [Seite 47]
· Beispielprogramme mit synchronem BAPI-Aufruf [Seite 55]
40 April 2001
Filterobjekte eines BAPIs abfragen
Filterobjekte eines BAPIs abfragen

Verwendung
Bei der Empfängerermittlung müssen die für ein BAPI relevanten Filterobjekte übergeben
werden. Wenn zum Zeitpunkt der Empfängerermittlung die im Verteilungsmodell gepflegten
Filterobjekte nicht bekannt sind, können diese mit dem Funktionsbaustein
ALE_BAPI_GET_FILTEROBJECTS abgefragt werden.
Beim Aufruf von ALE_BAPI_GET_FILTEROBJECTS werden das Business-Objekt, die Methode
und eine Tabelle mit Namen logischer Empängersysteme übergeben. Wird das BAPI nicht im
Verteilungsmodell gefunden oder sind keine Filterobjekte im Verteilungsmodell gepflegt, so wird
eine leere Tabelle FILTEROBJECTS zurückgegeben.
Werte zu selbst definierten Filterobjekttypen können Sie nur über definierte Business Add-Ins
ermitteln, die von Ihnen implementiert werden müssen.
Bei Abhängigkeiten wird in jedem Fall der Objekttyp zurückgegeben, über den das abhängige
ALE-Verteilungsobjekt auf das referenziete ALE-Verteilungsobjekt verweist. Die Anwendung muß
zu diesem Objekttyp die Objektkennung der aktuellen Objektausprägung kennen.
Input Parameter:
Parameter Bezugsfeld/Bezugsstruktur Beschreibung
OBJECT BDI_BAPI-OBJECT BOR-Objekt des BAPIs
METHOD BDI_BAPI-METHOD BOR-Methode des BAPIs
RECEIVER_INPUT BDI_LOGSYS Logische Empfängersysteme als
Vorgabewert
Output Parameter:
Parameter Bezugsfeld/ Bezugsstruktur Beschreibung
FILTEROBJECTS BDI_FLTTYP Filterobjekte und -werte
Exceptions
Parameter Beschreibung
ERROR_IN_ALE_CUSTOMIZING Fehler im ALE-Customizing
April 2001 41
Empfänger für asynchrone BAPIs ermitteln

Verwendung
Der Funktionsbaustein ALE_ASYNC_BAPI_GET_RECEIVER wird von dem
Anwendungsprogramm zur Ermittlung der Empfänger eines asynchronen BAPIs aufgerufen.
Dabei werden die folgenden Mechanismen wirksam:
· Falls eine Abhängigkeit für ein BAPI im ALE-Verteilungsmodell als eine Bedingung definiert
ist, so wird der Empfänger des referenzierten BAPIs bzw. Nachrichtentyps bestimmt. Dazu
muß das Anwendungsprogramm der Empfängerermittlung die Objekt-ID (z.B. 01815) als
Filterobjekt-Wert übergeben.
Der Funktionsbaustein ALE_ASYNC_BAPI_GET_RECEIVER ermittelt über die Objekt-ID die
aktuellen Filterobjekt-Werte des Objektes, über das das abhängige BAPI auf ein anderes
BAPI bzw. anderen Nachrichtentyps referenziert. Dazu muss die Anwendung einen
Funktionsbaustein zur Verfügung stellen, der das Lesen der Objekt-Daten ermöglicht. Der
Name des Funktionsbausteins muss in einer ALE-Customizing Tabelle hinterlegt werden, auf
die die Empfängerermittlung zur Laufzeit zugreift (Tabelle TBD18).
· Werden keine Empfänger ermittelt oder wird das BAPI nicht im ALE-Verteilungsmodell
gefunden, so wird eine leere Tabelle für die Empfänger zurückgegeben.
· Falls die übergebenen Filterobjekttypen und -werte nicht zu einer vollständigen und
fehlerfreien Empfängerermittlung ausreichen, werden Fehlernachricht und Ausnahme
zurückgegeben (ERROR_IN_FILTEROBJECTS).
· Treten Inkonsistenzen im Verteilungsmodell aufgrund fehlendem bzw. fehlerhaftem
Customizing auf, werden Fehlernachricht und Ausnahme zurückgegeben
(ERROR_IN_ALE_CUSTOMIZING).
Input Parameter:
RECEIVER_INPUT, optional BDI_LOGSYS Logische Empfängersysteme
als Vorgabewert
FILTEROBJECT_VALUES BDI_FOBJ Filterobjekte und -werte
Output Parameter:
RECEIVERS BDI_LOGSYS Empfängersysteme des BAPIs
Exceptions
ERROR_IN_FILTEROBJECTS Filterobjekte sind fehlerhaft oder unvollständig
42 April 2001
April 2001 43
Eigene Filterobjekte über Business Add-Ins ermitteln

Sie erfahren, wie Business Add-Ins von SAP definiert sind und wie Sie ein Business Add-In
implementieren, um Ihre selbst definierten Filterobjekte bei der Empfängerermittlung abzufragen.
Verwendung
Diese Beschreibung gilt nur für die Empfängerermittlung mit Business Add-Ins.
Sie ist nur für solche BAPIs relevant, für die ALE-Schnittstellen vorhanden sind und für die
Business Add-Ins implementiert werden sollen.
Als Standard liefert die SAP-Anwendung für die Empfängerermittlung eine Reihe von
Filterobjekttypen, die mit den von Ihnen zugeordneten Werten zur Laufzeit ausgewertet werden
(z.B. Filterobjekt Werk 0001, 0002). Die voreingestellten Werte können Sie ergänzen.
Wenn Sie jedoch für die Abbildung Ihrer eigenen Geschäftsprozesse andere Filterobjekttypen
verwenden möchten, um den asynchronen BAPI-Aufruf unter erweiterten Bedingungen
durchzuführen, benötigen Sie dafür von SAP definierte Business Add-Ins, die Sie implementieren
und aktivieren müssen. Business Add-Ins sind von SAP-Programmierern definierte Stellen im
Quellcode, an denen Sie Ihren Code einfügen können, ohne das Originalobjekt zu modifizieren.
Welche Ihrer SAP-Anwendungen Business Add-Ins enthalten, erfahren Sie in Ihrer
Anwendungsdokumentation.
Voraussetzungen
Folgende Voraussetzungen müssen erfüllt sein:
· Ihre SAP-Anwendungen enthalten Business Add-Ins, die von SAP definiert wurden (über
Werkzeuge ® ABAP Workbench ® Hilfsmittel ® Business Add-Ins ® Definition, siehe auch
das Beispiel Aufbau eines Business Add-Ins in einer Form-Routine unten).
· Sie haben im ALE-Entwicklungsumfeld einen Filterobjekttyp für die Empfängerermittlung
definiert, z.B. FILTER, und dem entsprechenden BAPI zugeordnet (über das SAP-Menü:
Werkzeuge ® ALE ® ALE-Entwicklung ® Empfängerermittlung).
· Sie haben das Business Add-In implementiert und aktiviert (über das SAP-Menü: Werkzeuge
® ABAP Workbench ® Hilfsmittel ® Business Add-Ins ® Implementierung).
· Sie haben im Verteilungsmodell ein Filterobjekt mit bestimmten Bedingungen unter der
Sender-Empfänger-Beziehung gepflegt (über den R/3-Einführungsleitfaden: Basis ®
Application Link Enabling (ALE)).
Beispiel:
Sender
Empfänger
BUSOBJECT.METHOD
Filtergruppe
FILTER
1010
44 April 2001
Aufbau eines Business Add-Ins in einer Form-Routine

Die Empfängerermittlung für ein BAPI (BUSOBJECT.METHOD) kann in SAP-Anwendungen
durch SAP-Entwickler beispielsweise mit einer Form-Routine (z.B.
BUSOBJECT_METHOD_RECEIVERS) nach folgendem Ablauf aufgebaut werden:
Schnittstelle:
TABLES receivers STRUCTURE bdi_logsys
USING object TYPE swo_objtyp
method TYPE swo_method
parameters LIKE ...
return_info LIKE syst.
In diesem Beispiel enthalten die Parameter parameters alle für die Empfängerermittlung
notwendigen Filterobjektwerte der Anwendung. Sie sind anwendungsabhängig.
Der Parameter receivers enthält als vorgegebenen Wert die gewünschten Empfänger (oder
Initialwert), und als Rückgabewert die ermittelten Empfänger.
Variablen-Definition:
t_filter_object_type TYPE bdi_flttyp_tab
t_filter_object_value TYPE bdi_fobj_tab
receivers_output LIKE bdi_logsys OCCURS 0 WITH
HEADER LINE
Im Code einer SAP-Anwendung werden folgende Schritte durchgeführt. Es handelt sich um die
gleichen Schritte wie bei der Ermittlung der von SAP definierten Filterobjekttypen mit dem
Zusatzschritt (Schritt 3) für die Ermittlung Ihrer selbst definierten Filterobjekte.
1) Filterobjekttyp für das BAPI mit dem Funktionsbaustein ALE_BAPI_GET_FILTEROBJECTS

abfragen:
EXPORTING
object = busobject
method = method
TABLES
receiver_input = receivers
filterobjects = t_filter_object_type
EXCEPTIONS
error_in_ale_customizing
2) Den von SAP ausgelieferten Filterobjekttypen in der Struktur t_filter_object_type die
aktuellen Werte der Anwendung in Parametern parameters zuweisen.
3) Das definierte Business Add-In aufrufen, um die von Kunden definierten Filterobjekttypen in
der Ablauflogik der Anwendung auszuwerten:
EXPORTING
object = busobject
method = method
parameters = ...
filterobjtype = t_filter_object_type
CHANGING
filterobjvalue = t_filter_object_value
April 2001 45
4) Die Empfänger für den asynchronen BAPI-Aufruf mit dem Baustein

ALE_ASYNC_BAPI_GET_RECEIVER ermitteln:
EXPORTING
object = busobject
method = method
TABLES
receivers_output = receivers_output
filterobject_values = t_filter_object_value
EXCEPTIONS
error_in_filterobjects
error_in_ale_customizing
receivers[] = receivers_output[]
(Den Programmcode dieses Beispiels finden Sie unter Beispielprogramme mit asynchronem
BAPI-Aufruf [Seite 47], Empfängerermittlung mit Business Add-In)
Vorgehensweise
Implementieren Sie die Objekt-Methode für das Business Add-In unter Verwendung Ihres selbst
definierten Filterobjekttyps.
Ergebnis
Die Empfänger für den asynchronen BAPI-Aufruf wurden anhand der vorgegebenen Filterobjekte
ermittelt.
46 April 2001
Beispielprogramme mit asynchronem BAPI-Aufruf

Die folgenden Beispielprogramme erläutern Ihnen die Empfängerermittlung mit asynchronem
BAPI-Aufruf.
· Filterobjekttypen sind zur Laufzeit nicht bekannt
· Empfängerermittlung mit Business Add-In
· Filterobjekttypen sind zur Laufzeit bekannt
Die Verwendung der Funktion ALE_BAPI_GET_FILTEROBJECTS ist optional und

muß nur dann erfolgen, wenn die Filterobjekttypen der Anwendung zur Laufzeit nicht
bekannt sind.
Nach dem Aufruf des Ausgangs-Funktionsbausteins der generierten BAPI-ALE-

Schnittstelle muß im Programmkontext ein COMMIT WORK erfolgen. Ein
Datenbankcommit am Transaktionsende reicht nicht aus. Falls kein COMMIT WORK
abgesetzt wird, wird das IDoc erzeugt und hat den richtigen Status, es wird aber
nicht versendet.
Die erzeugten IDocs sind bis zum Ende der aufrufenden Transaktion gesperrt. Um
sie vorher zu entsperren, können Sie einen der folgenden Funktionsbausteine
aufrufen:
DEQUEUE_ALL gibt alle Sperrobjekte frei
EDI_DOCUMENT_DEQUEUE_LATER gibt einzelne IDocs frei, deren Nummern dem
Funktionsbaustein als Parameterwerte übergeben werden.
Filterobjekttypen sind zur Laufzeit nicht bekannt

* data declaration
data: filterobj_values like bdi_fobj occurs 0,

filterobj_types like bdi_fobjtype occurs 0,
bapi_logsys like bdi_logsys occurs 0.
constants:
c_objtype_plant type c value ‘WERKS’,
c_objtype_langu type c value ‘SPRAS’.
* get filterobjects from ALE distribution model
call function ‘ALE_BAPI_GET_FILTEROBJECTS’

exporting
object = ‘BUS1001’
method = ‘REPLICATEDATA’
tables
filterobjects = filterobj_types
exceptions
April 2001 47
error_in_ale_customizing = 1.
* fill filterobject values into table
loop at filterobj_types.
case filterobj_values-objtype.
when c_objtype_plant.
filterobj_values-objtype = c_objtype_plant.
filterobj_values-objvalue = ‘0002’.
when c_objtype_langu.
filterobj_values-objtype = c_objtype_langu.
filterobj_values-objvalue = ‘D’.
when others.
endcase.
append filterobj_values.
endloop.
* get receiver from ALE distribution model
call function ‘ALE_ASYNC_BAPI_GET_RECEIVER’

exporting
method = ‘REPLICATEDATA’
tables
receivers = bapi_logsys
filterobject_values = filterobj_values
exceptions
error_in_filterobjects = 1
* call generated ALE interface function module
if sy-subrc <> 0.
if not bapi_logsys[] is initial.
call function ‘ALE_MATERIAL_REPLICATE_DATA’
tables
...
commit work.
endif.
endif.
Empfängerermittlung mit Business Add-In

Von SAP implementierte Form-Routine
*-------------------------------------------------------------------
* FORM ALE_BFA_TEST_RECEIVERS
*-------------------------------------------------------------------
FORM ale_bfa_test_receivers TABLES receivers STRUCTURE bdi_logsys
USING object TYPE swo_objtyp
method TYPE swo_method
48 April 2001
key1 LIKE tbbfatest-key1

key2 LIKE tbbfatest-key2
return_info LIKE syst.
* key1 and key2 are parameters regarding receiver determination

* 2 filter object types were defined by SAP:
* TEST_KEY1
* TEST_KEY2
* variables definition
DATA: w_filter_object_type TYPE bdi_flttyp,
t_filter_object_type TYPE bdi_flttyp_tab,
w_filter_object_value TYPE bdi_fobj,
t_filter_object_value TYPE bdi_fobj_tab,
receivers_output LIKE bdi_logsys OCCURS 0 WITH HEADER LINE.
CLASS: cl_ex_customer_filter DEFINITION LOAD.

DATA: my_exit TYPE REF TO if_ex_customer_filter.
*> Step 1) get filter object types for a BAPI

CALL FUNCTION 'ALE_BAPI_GET_FILTEROBJECTS'
EXPORTING
object = object
method = method
TABLES
filterobjects = t_filter_object_type
EXCEPTIONS
error_in_ale_customizing = 1
OTHERS = 2.
IF sy-subrc <> 0.
return_info = syst.
EXIT.
ENDIF.
*> Step 2) evaluate SAP filter objects

LOOP AT t_filter_object_type INTO w_filter_object_type.
CASE w_filter_object_type-objtype.
* evaluate delivered filter objects
WHEN 'TEST_KEY1'.
MOVE-CORRESPONDING w_filter_object_type
TO w_filter_object_value.
w_filter_object_value-objvalue = key1.
APPEND w_filter_object_value TO t_filter_object_value.
April 2001 49
WHEN 'TEST_KEY2'.
MOVE-CORRESPONDING w_filter_object_type
TO w_filter_object_value.
w_filter_object_value-objvalue = key2.
APPEND w_filter_object_value TO t_filter_object_value.
* customers defined filter objects
WHEN OTHERS.
ENDCASE.
ENDLOOP.
*> Step 3) evaluate customer-defined filter objects

CREATE OBJECT my_exit TYPE cl_ex_customer_filter.
CALL METHOD my_exit->filtering
EXPORTING
object = object
method = method
key1 = key1
key2 = key2
filterobjtype = t_filter_object_type
CHANGING
filterobjvalue = t_filter_object_value.
*> Step 4) determine receivers for all filter objects

CALL FUNCTION 'ALE_ASYNC_BAPI_GET_RECEIVER'
EXPORTING
object = object
method = method
TABLES
receivers = receivers_output
filterobject_values = t_filter_object_value
EXCEPTIONS
error_in_ale_customizing = 2
OTHERS = 3.
IF sy-subrc <> 0.
return_info = syst.
EXIT.
ENDIF.
receivers[] = receivers_output[].
ENDFORM.
50 April 2001
Durch Kunden implementierte Methode

* The following method was implemented by a customer with
* Business Add-In
* 1 filter object type was defined by customer:
* ZTEST_KEYS
METHOD if_ex_customer_filter~filtering.
* ...
DATA: w_filterobjtype TYPE bdi_flttyp,
w_filterobjvalue TYPE bdi_fobj.
LOOP AT filterobjtype INTO w_filterobjtype.

CASE w_filterobjtype-objtype.
WHEN 'ZTEST_KEYS'.
MOVE-CORRESPONDING w_filterobjtype TO w_filterobjvalue.
w_filterobjvalue-objvalue+0(3) = key1.
w_filterobjvalue-objvalue+3(3) = key2.
APPEND w_filterobjvalue TO filterobjvalue.
WHEN OTHERS.
ENDCASE.
ENDLOOP.
ENDMETHOD.
Filterobjekttypen sind zur Laufzeit bekannt

* data declaration

bapi_logsys like bdi_logsys occurs 0.
filterobj_values-objtype = ‘KKBER’.
call function ‘ALE_ASYNC_BAPI_GET_RECEIVER’

exporting
method = ‘REPLICATESTATUS’
tables
filterobject_values = filterobj_values
exceptions
April 2001 51
* call generated ALE interface function module
if sy-subrc <> 0.
if not bapi_logsys[] is initial.
call function ‘ALE_DEBITOR_CREDITACC_REPLICATESTATUS’
tables
...
commit work.
endif.
endif.
52 April 2001
Empfänger für synchrone BAPIs ermitteln

Verwendung
Der Funktionsbaustein ALE_SYNC_BAPI_GET_RECEIVER wird vom Anwendungsprogramm
zur Ermittlung der Empfänger eines synchronen BAPIs aufgerufen.
· Falls keine Empfänger ermittelt werden oder das BAPI nicht im Verteilungsmodell gefunden
wird, so wird eine leere Tabelle für die Empfänger zurückgegeben.
· Falls eine Abhängigkeit für ein BAPI im ALE-Verteilungsmodell als eine Bedingung definiert
ist, so wird der Empfänger des referenzierten BAPIs bzw. Nachrichtentyps bestimmt. Dazu
muß die Anwendung der Empfängerermittlung die Objekt-ID (z.B. 01815) als Filterobjekt-
Wert übergeben.
Die Empfängerermittlung liest nun selbst über die Objekt-ID die aktuellen Filterobjekt-
Werte des Objektes nach, über das das abhängige BAPI auf ein anderes BAPI bzw.
anderen Nachrichtentyps referenziert. Dazu stellt die Anwendung einen
Funktionsbaustein zur Verfügung, der das Lesen der Objekt-Daten ermöglicht. Der
Name des Funktionsbausteins wird in einer ALE-Customizing Tabelle hinterlegt, auf die
die Empfängerermittlung zur Laufzeit zugreift (Tabelle TBD18).
Neben dem logischen System wird auch die RFC-Destination zurückgegeben.
· Falls die RFC-Destination zu einem logischen Empfängersystem nicht gepflegt ist, werden
Fehlernachricht und eine Ausnahme zurückgegeben
(NO_RFC_DESTINATION_MAINTAINED).
Input Parameter
RECEIVER_INPUT BDI_LOGSYS Logische Empfängersysteme als
Vorgabewert
Output Parameter
RECEIVERS BDI_LOGSYS Empfängersysteme des BAPIs und RFC-
Destination
April 2001 53
Exceptions
NO_RFC_DESTINATION_MAINTAINED RFC Destination zum logischen System fehlt
54 April 2001
Beispielprogramme mit synchronem BAPI-Aufruf

Die folgenden Beispielprogramme erläutern Ihnen die Empfängerermittlung mit synchronem
BAPI-Aufruf.
Die Verwendung des Funktionsbausteins ALE_BAPI_GET_FILTEROBJECTS ist

optional und muß nur dann erfolgen, wenn die Filterobjekttypen zur Laufzeit nicht
bekannt sind.
Durch den synchronen RFC wird ein Datenbankcommit abgesetzt, d. h.

Datenbankänderungen, die vor dem RFC gemacht wurden, können nicht mehr
zurückgerollt werden.
Filterobjekttypen sind zur Laufzeit nicht bekannt

* data declaration

bapi_server like bdbapidest occurs 0.
constants:
c_objtype_plant type c value ‘WERKS’,
c_objtype_langu type c value ‘SPRAS’.
* get filterobjects from ALE distribution model
call function ‘ALE_BAPI_GET_FILTEROBJECTS’

exporting
method = ‘GETDETAIL’
tables
filterobjects = filterobj_types
exceptions
loop at filterobj_types.
case filterobj_values-objtype.
when c_objtype_plant.
filterobj_values-objtype = c_objtype_plant.
when c_objtype_langu.
filterobj_values-objtype = c_objtype_langu.
filterobj_values-objvalue = ‘D’.
when others.
April 2001 55
endcase.
endloop.
call function ‘ALE_SYNC_BAPI_GET_RECEIVER’

exporting
method = ‘GETDETAIL’
tables
receivers = bapi_server
filterobjects_values = filterobj_values
exceptions
* call synchronous BAPI locally/remotely
if sy-subrc = 0.
if not bapi_server[] is initial.
loop at bapi_server.
call function ‘BAPI_MATERIAL_GET_DETAIL’
destination bapi_server-rfc_dest
...
endloop.
else.
call function ‘BAPI_MATERIAL_GET_DETAIL’
...
endif.
endif.
Filterobjekttypen sind zur Laufzeit bekannt

* data declaration

bapi_server like bdibapidest occurs 0.
filterobj_values-objtype = ‘KKBER’.
call function ‘ALE_SYNC_BAPI_GET_RECEIVER’

exporting
56 April 2001
method = ‘GETSTATUS’
tables
receivers = bapi_server
filterobjects_values = filterobj_values
exceptions
* call synchronous BAPI locally/remotely
if sy-subrc <> 0.
if not bapi_server[] is initial.
loop at bapi_server.
call function ‘BAPI_DEBITOR_CREDITACC_GETSTATUS’
destination bapi_server-rfc_dest
...
endloop.
else.
call function ‘BAPI_DEBITOR_CREDITACC_GETSTATUS’
...
endif.
endif.
April 2001 57
Einzigen Empfänger für synchrone BAPIs ermitteln
Einzigen Empfänger für synchrone BAPIs ermitteln

Der Funktionsbaustein ALE_BAPI_GET_UNIQUE_RECEIVER wird vom Anwendungsprogramm
zur Ermittlung genau eines Empfängers für ein synchrones BAPI aufgerufen.
· Falls kein Empfänger ermittelt oder das BAPI nicht im Verteilungsmodell gefunden wird, so
wird eine leere Struktur für den Empfänger zurückgegeben.
· Falls mehr als ein Empfänger des BAPIs ermittelt wird, werden Fehlernachricht und
Ausnahme zurückgegeben.
· Falls die RFC-Destination zu einem logischen Empfängersystem nicht gepflegt ist, werden
Fehlernachricht und eine Ausnahme zurückgegeben
(NO_RFC_DESTINATION_MAINTAINED).
Input Parameter
Parameter Bezugsfeld Beschreibung
Output Parameter
Parameter Bezugsfeld Beschreibung
RECEIVER BDBAPIDEST Empfängersystem des BAPIs
Exceptions
NOT_UNIQUE_RECEIVER Es gibt mehrere Empfängersysteme für das BAPI
NO_RFC_DESTINATION_MAINTAINED RFC Destination zum logischen System fehlt
58 April 2001
BAPIs für interaktive Verbuchung entwickeln
BAPIs für interaktive Verbuchung entwickeln

Voraussetzungen
Die ALE-Eingangsverarbeitung unterstützt IDoc-Eingangsfunktionsbausteine, die ein CALL
TRANSACTION ausführen. Dadurch kann ein IDoc interaktiv verbucht werden, indem Sie die
Bildschirmbilder der Dialogtransaktion anzeigen.
Die aus standardmäßigen BAPIs generierten BAPI-ALE-Schnittstellen bieten diese Möglichkeit
nicht, da diese BAPIs keine Dialogoberfläche besitzen. Wenn Sie eine BAPI-ALE-Schnittstelle
mit einem CALL TRANSACTION auf eine Dialogtransaktion benötigen, können Sie ein eigenes
BAPI entwickeln, das für die ALE-Fehlerbehandlung die Bilder der Dialogtransaktion zeigt.
Einzelheiten zu Erweiterungen erfahren Sie im BAPI-Programmierleitfaden unter dem Thema
Weiterentwicklung durch Kunden [Extern].
Vorgehensweise
Die ALE-Schicht setzt im globalen Speicher einen Parameter, der im Programm-Code des BAPIs
wie folgt abgefragt werden kann:
Data: pi_input_method like bdwfap_par-inputmethd.

...
Import pi_input_method from memory id 'ALE_INPUT_METHOD'.
...
Der Parameter pi_input_method kann folgende Werte annehmen:

Wert Bedeutung
" " (initial) Verarbeitung ohne Dialog
"E" Dynpro nur anzeigen, wenn ein Fehler darin auftrat
"A" Zeige alle Dynpros
April 2001 59
IDocs einer BAPI-ALE-Schnittstelle erweitern
IDocs einer BAPI-ALE-Schnittstelle erweitern

Voraussetzungen
Das IDoc-Erweiterungskonzept geht davon aus, daß Customer-Exits in dem Teil des ABAP-
Codes vorhanden sind, in dem das IDoc aufgebaut bzw. gelesen wird. Im Falle einer generierten
BAPI-ALE-Schnittstelle enthält dieser Code keine Customer-Exits.
Einzelheiten zu Erweiterungen erfahren Sie im BAPI-Programmierleitfaden unter dem Thema
Weiterentwicklung durch Kunden [Extern].
Vorgehensweise
Kundenerweiterungen der von BAPIs generierten BAPI-ALE-Schnittstellen müssen
folgendermaßen gehandhabt werden:
1. Kopieren und modifizieren Sie den zum originalen BAPI gehörenden Funktionsbaustein.
2. Legen sie ein kundeneigenes BAPI im BOR an, indem Sie einen Sub-Objekttyp im
Kundennamensraum anlegen.
Beim Anlegen eines Sub-Objektyps werden die Methoden des Business-Objekts an den
Subtyp vererbt. Sie können die Methoden des Subtyps ändern, löschen oder durch
eigene Methoden ergänzen.
3. Generieren Sie eine kundeneigene BAPI-ALE-Schnittstelle aus diesem neuen BAPI.
Um das erweiterte IDoc im Ausgang zu erzeugen, muß die Anwendung einen Customer-Exit an
der Aufrufstelle vorsehen.
60 April 2001
Verteilung über Nachrichtentypen implementieren
Verteilung über Nachrichtentypen implementieren

Einsatzmöglichkeiten
In Release 3.x werden betriebswirtschaftliche Funktionen und Prozesse über Nachrichtentypen
verteilt. Ein Nachrichtentyp steht für eine betriebswirtschaftliche Funktion. Zu einem
Nachrichtentyp gehört der IDoc-Typ als technische Struktur der zu kommunizierenden Nachricht.
Das Programmiermodell "Verteilung über Nachrichtentypen" umfaßt die Definition von
Nachrichten- und IDoc-Typen und das Erstellen von ABAP-Code zur Ausgangs- und
Eingangsverarbeitung von IDocs.
Ablauf
Definition von Nachrichten- und IDoc-Typen:
· Neue IDoc-Typen definieren [Extern]
Wenn Sie für die Verteilung von Stammdaten Erweiterungen zu einem Nachrichtentyp
anlegen möchten, müssen Sie für jede Erweiterung auch einen weiteren Nachrichtentyp
anlegen.
Die ALE-Schnittstelle lässt es nicht zu, für unterschiedliche IDoc-Typen bei gleichem
Nachrichtentyp unterschiedliche Segmentdaten aufzubauen.
Erstellen von ABAP-Code:
· Ausgangsverarbeitung [Seite 66]
· Eingangsverarbeitung [Seite 90]
Hinweise zu anderen ALE-Funktionen finden Sie unter den folgenden Themen
· Stammdatenverteilung [Seite 173]
· Kommunikation mit Nicht-R/3-Systemen [Extern]
April 2001 61
Ablauf der Verteilung über Nachrichtentypen

Beim Einsatz von Nachrichtentypen zur asynchronen Datenübertragung im Rahmen von ALE
läuft allgemein folgender Prozeß ab:
Anwendung ALE-Schicht Kommunikations- ALE-Schicht Anwendung

Schicht
Nachricht Verteilungs-
erzeugen?
modell
Stamm-IDoc Stamm Empfänger-

erzeugen ermittlung IDoc
IDoc
Segment- Segment-
filterung filterung
tRFC
Feld-
oder Feld-
umsetzung EDI umsetzung
Versions- Übergabe-
wandlung steuerung IDoc
IDoc
IDoc
verarbeiten
IDoc Serialisierung
Versende- IDoc-Status Anwendungs-

Datenbank Verknüpfung Datenbank beleg buchen
steuerung gleichzeitig
aktualisieren
Bei der Ausgangsverarbeitung wird durch einen Funktionsbaustein der Anwendung ein Stamm-
IDoc aufgebaut und an die ALE-Schicht weitergeleitet.
In der ALE-Schicht durchläuft es folgende Schritte:
· Empfängerermittlung, falls nicht bereits durch die Anwendung erfolgt
· Datenselektion
· Segmentfilterung
· Feldumsetzung
· Versionswandlung
· Versendesteuerung
Das aufbereitete IDoc wird an die Kommunikationsschicht übergeben und von dort über per
transaktionalen Remote Function Call (RFC) oder über Dateischnittstelllen (z.B. für EDI) an das
gerufene System (Server) geschickt.
Bei einem Fehler in der ALE-Schicht wird das fehlerhafte IDoc gesichert und eine Workflow-
Aufgabe erzeugt, mit deren Hilfe der ALE-Administrator den Fehler bearbeiten kann.
62 April 2001
Einzelheiten zur Programmierung finden Sie unter Ausgangsverarbeitung implementieren [Seite

66].
Die einzelnen Schritte sind nachfolgend erläutert.
Empfängerermittlung:
Ein IDoc hat analog zu einem Brief einen Absender und einen Empfänger. Wenn der
Empfänger nicht durch die Anwendung eingetragen wurde, ermittelt die ALE-Schicht
anhand des Verteilungsmodells den oder die Interessenten für diese Nachricht.
Aus dem Modell kann die ALE-Schicht entnehmen, ob und wieviele verteilte Systeme die
Nachricht erhalten sollen. Es können kein, ein oder mehrere Empfänger ermittelt werden.
Für jedes der ermittelten verteilten Systeme werden die Daten, die laut Filterobjekte im
Verteilungsmodell festgelegt sind, aus dem Master-IDoc selektiert. Mit diesen Daten wird
ein IDoc gefüllt, in das der Interessent als Empfänger eingetragen wird.
Segmentfilterung:
Vor dem Versenden können in diesem Verarbeitungsschritt einzelne Segmente aus dem
IDoc entfernt werden. Zu unterdrückende Segmente können Sie im ALE-Customizing
über folgenden Pfad festlegen:
ALE-Geschäftsprozessen modellieren und implementieren
Verteilung von Stammdatenverteilung konfigurieren
Umfang der zu verteilenden Daten einstellen
IDoc-Segmente filtern
Die Einstellung erfolgt abhängig vom sendenden und empfangenden logischen R/3-
System.
Feldumsetzung:
Empfängerspezifische Feldumsetzungen können Sie im ALE-Customizing definieren:
Datenumsetzen zwischen Sender und Empfänger einstellen
Feldumsetzungen beziehen kann. Die Regeln werden pro IDoc-Segment angelegt und je
Segmentfeld definiert. Diese Funktion ist wichtig für die Konversion des Feldformats
beim Datenaustausch zwischen R/2- und R/3-Systemen. In diesem Fall wird
IDoc-Versionswandlung:
SAP gewährleistet die korrekte Funktion von ALE zwischen R/3-Systemen
unterschiedlicher Release-Stände. Zur Anpassung der Nachrichtentypen verschiedener
R/3-Releasestände kann in diesem Verarbeitungsschritt eine Konversion der IDoc-
Formate erfolgen.
Bei der Änderung bestehender Nachrichtentypen hält sich die SAP-Entwicklung an
folgende Regeln:
· Felder können einem Segmenttyp angehängt werden.
· Segmente können hinzugefügt werden.
April 2001 63
Im ALE-Customizing wird zu jedem Empfänger festgehalten, welche Version eines

Nachrichtentyps dort verwendet wird. Im Ausgang wird das Communication-IDoc in der
korrekten Version erzeugt.
Versendesteuerung
In der Versendesteuerung wird der Versand nach Zeitpunkt und Menge gesteuert.
Zeitliche Steuerung:
Die IDocs können sofort oder per Hintergrundverarbeitung versandt werden. Diese
Einstellungen werden in der Partnervereinbarung vorgenommen.
Erfolgt die Versendung per Hintergrundverarbeitung, muß ein Job eingeplant
werden. Der Ausführungs-Rhythmus ist frei wählbar.
Mengensteuerung:
IDocs können gebündelt in Paketen versendet werden. Die Paketgröße wird im ALE-
Customizing wie folgt partnerspezifisch vereinbart:
® Partnervereinbarung und Verarbeitungszeitpunkt einstellen
® Partnervereinbarungen manuell pflegen
Diese Einstellung ist nur wirksam, wenn die IDocs im Hintergrund verarbeitet
werden.
In der ALE-Schicht durchläuft das ankommende IDoc folgende Schritte:
· Segmentfilterung
· Feldumsetzung
· Übergabesteuerung
· Serialisierung
Einzelheiten zur Programmierung finden Sie unter Eingangsverarbeitung implementieren [Seite
90].
Die einzelnen Schritte sind nachfolgend erläutert.
Segmentfilterung
Im Eingang können Sie eine Filterung von IDoc-Segmenten vornehmen.
Diese Funktion in der Eingangsverarbeitung gleicht im Prinzip der der
Ausgangsverarbeitung.
Feldumsetzung
Empfängerspezifische Feldumsetzungen können Sie im ALE-Customizing definieren:
Datenumsetzen zwischen Sender und Empfänger einstellen
Feldumsetzungen beziehen kann. Die Regeln werden pro IDoc-Segment angelegt und je
64 April 2001
Segmentfeld definiert. Diese Funktion ist wichtig für die Konversion des Feldformats
beim Datenaustausch zwischen R/2- und R/3-Systemen. In diesem Fall wird
Bei reduzierbaren Nachrichtentypen werden Feldwerte im empfangenden R/3-

System nicht überschrieben, wenn im entsprechenden IDoc-Feld das Zeichen "/"
steht.
Übergabesteuerung
Wurden die IDocs auf der Datenbank abgelegt, können sie von der entsprechenden
Anwendung gebucht werden.
Die Übergabe an die Anwendung kann sofort nach Eintreffen der IDocs oder
zeitgesteuert per Hintergrundverarbeitung erfolgen.
IDocs können auf drei Arten verbucht werden:
· Ein Funktionsbaustein wird direkt aufgerufen:
Die eingehenden IDocs werden direktes gebucht. Nur im Fehlerfall wird ein Fehler-
Workflow gestartet.
· Ein SAP Business Workflow wird gestartet. Ein Workflow ist die Abfolge von
Schritten zur Buchung eines IDocs.
Es werden keine Workflows für ALE ausgeliefert.
· Ein Workitem wird gestartet:
Start eines einzigen Schrittes zur Einbuchung eines IDocs.
Standardmäßig werden von ALE in der Eingangsverarbeitung die ausgelieferten
Funktionsbausteine aufgerufen. Informationen über die SAP Business Workflow-Alternativen
finden Sie unter Eingangsverarbeitung über SAP-Workflow [Seite 160].
Zur Behandlung von Störungen in der IDoc-Verarbeitung können Sie im SAP-Workflow zu
benachrichtigende Personen festlegen. Dies kann für jeden Nachrichtentyp getrennt
April 2001 65
Ausgangsverarbeitung implementieren
Ausgangsverarbeitung implementieren
In diesem Abschnitt werden die zum Versand eines IDocs erforderlichen Entwicklungsschritte
beschrieben. Es wird vorausgesetzt, daß die IDoc-Struktur und der Nachrichtentyp bereits
angelegt und miteinander verknüpft sind.
Siehe auch:
· Entwicklung eines Funktionsbausteins zur ALE-Ausgangsverarbeitung [Seite 67]
· Einstellung der ALE-Ausgangsverabeitung [Seite 85]
· Ausgang über die Nachrichtensteuerung [Seite 89]
66 April 2001
Entwicklung eines Funktionsbausteins zur ALE-Ausgangsverarbeitung
Entwicklung eines Funktionsbausteins zur ALE-

In diesem Abschnitt wird ein Funktonsbaustein beschrieben, der aus einem Anwendungsobjekt
ein IDoc erstellt und die ALE-Ausgangsverarbeitung aufruft.
Siehe auch:
Grundlagen [Seite 68]
Abfrage des Verteilungsmodells [Seite 69]
Aufbau des Kontrollsatzes [Seite 70]
Aufbau der Datensätze [Seite 71]
Aufruf von master_idoc_distribute [Seite 75]
Coding-Beispiel [Seite 77]
April 2001 67
Grundlagen
Grundlagen
Ein IDoc besteht aus einem Kontrollsatz der Struktur edidc und einem oder mehreren
Datensätzen der Struktur edidd. Der Kontrollsatz ist eine Art Briefumschlag. In ihm stehen
Sender und Empfänger des IDocs sowie Informationen zur Art der Nachricht. Die Datensätze
enthalten die Nutzdaten des IDocs als unformatierte Zeichenketten.
Um ein IDoc an die ALE-Schicht übergeben zu können, muß eine Feldleiste der Struktur edidc
und eine interne Tabelle der Struktur edidd aufgebaut werden. Mit diesen wird dann der
Funktionsbaustein MASTER_IDOC_DISTRIBUTE aufgerufen. Der Baustein übernimmt das
Abspeichern auf die Datenbank und falls notwendig den Anstoß des Versandes.
Alle ALE-Nachrichtenflüsse sind im ALE Verteilungsmodell abgelegt. Das Verteilungsmodell ist
die zentrale steuernde Instanz für ALE. Die Anwendung kann bereits vor dem Erstellen des
IDocs das Verteilungsmodell abfragen. Das ist sinnvoll, wenn die Tatsache, daß ein IDoc erstellt
wird, auf die Anwendung Einfluß nimmt. Da man sich das Aufbauen der internen Tabelle für das
IDoc sparen kann, wenn im Verteilungmodell kein Nachrichtenfluß gepflegt ist, kann dies auch
die Performance verbessern.
Die ALE-Schicht fragt auf jeden Fall das Verteilungsmodell ab. Wenn der Empfänger nicht von
der Anwendung mitgegeben wird, werden alle Empfänger ermittelt und für jeden ein IDoc erstellt.
Wenn der Empfänger von der Anwendung mitgegeben wird, wird gegen das Verteilungsmodell
geprüft, ob er laut Verteilungsmodell berechtigt ist. Aufgrund der Filtereinstellungen im
Verteilungsmodell können in der ALE-Schicht auch Teile des IDocs weggeschnitten werden.
68 April 2001
Abfrage des Verteilungsmodells
Abfrage des Verteilungsmodells

Die Abfrage des Verteilungsmodells ist optional.
Das ALE-Verteilungsmodell kann über folgende Funktionsbausteine abgefragt werden:
· ALE_MODEL_DETERMINE_IF_TO_SEND
Dieser Funktionsbaustein wird mit dem Nachrichtentyp und optional mit dem logischen
Empfangssystem aufgerufen, falls es bereits in der Anwendung bekannt ist.
Im ALE-Verteilungsmodell wird kontrolliert, ob für die Eingabeparameter ein
Nachrichtenfluß gepflegt ist.
· Wenn nein, wird der Export-Parameter idoc_must_be_send auf initial gesetzt,
· wenn ja, wird ein "X" zurückgegeben.
Filterobjekte, die möglicherweise im Verteilungsmodell diesen Nachrichtenfluß regeln,
werden nicht ausgewertet. Wenn der Funktionsbaustein ein "X" zurückgibt, muß ein IDoc
erstellt werden, ansonsten nicht.
· ALE_MODEL_INFO_GET
Dieser Funktionsbaustein steht für komplexere Abfragen an das ALE-Verteilungsmodell
zur Verfügung. Er wird mit dem zu versendenden Nachrichtentyp aufgerufen. Zurück
erhält man eine Tabelle mit allen Interessenten für diesen Nachrichtentyp und den
zugehörigen Filterobjekten. Beachten Sie, daß sich zu einem Empfänger mehrere
Einträge in der zurückgegebenen Tabelle befinden können. Wenn keine Einträge im
Verteilungsmodell vorhanden sind, wird die Ausnahme no_model_info_found
ausgegeben. Bei Auftreten dieser Ausnahme muß also kein IDoc erstellt werden.
Ansonsten besteht prinzipiell Bedarf, ein IDoc aufzubauen. Das empfangende logische
System finden Sie im Feld rcvsystem eines Tabelleneintrages.
Das endgültige Ergebnis, ob der Empfänger ein IDoc bekommt und wie es aussieht, steht
allerdings erst nach Auswerten aller Filterobjekte für einen Nachrichtenfluß im Verteilungsmodell
fest. Dies geschieht in der ALE-Schicht.
April 2001 69
Aufbau des Kontrollsatzes
Aufbau des Kontrollsatzes

Der Kontrollsatz besteht aus einer Feldleiste der Struktur edidc. Nachfolgend eine Liste aller
Felder, die an dieser Stelle von Interesse sind. Alle übrigen Felder sind initial zu lassen.
Feldliste des Kontrollsatzes
Feld Bedeutung Bemerkung

mestyp Logischer Nachrichtentyp. Gibt die Mußfeld
betriebswirtschaftliche Bedeutung der
Nachricht wieder.
idoctp Basisstruktur des IDocs. Identifiziert das Mußfeld
Formular, das diese Nachricht verwendet.
cimtyp Kundenerweiterungsstruktur. Wenn der Mußfeld, wenn
Kunde eine Basisstruktur der SAP erweitert Kundenerweiterung vorliegt.
muß er einen Namen für seine Ansonsten initial.
Erweiterungsstruktur vergeben.
rcvprt Partnerart des Empfängers, für ALE "LS" Kannfeld. Siehe unten.
für logisches System
rcvprn Partnernummer des Empfängers, für ALE Kannfeld. Siehe unten.
das logische System
rcvpfc Partnerrolle des Empfängers, für ALE im Kannfeld. Siehe unten.
Regelfall initial.
Wenn das empfangende System aus dem Verteilungsmodell ermittelt wurde, kann es in das Feld
rcvprn geschrieben werden. Dann muß das Feld rcvprt mit "LS" für logisches System gefüllt
werden. Falls notwendig, kann die Partnerrolle in das Feld rcvpfc geschrieben werden. Im
Regelfall wird die Partnerrolle aber nicht für ALE verwendet. Wichtig ist, daß entweder rcvprt und
rcvprn beide frei bleiben oder beide gefüllt werden. Wenn rcvprt und rcvprn initial übergeben
werden, läuft die Empfängerermitllung vollständig in der ALE-Schicht ab
70 April 2001
Aufbau der Datensätze
Aufbau der Datensätze

Die Datensätze eines IDocs werden in einer internen Tabelle der Struktur edidd aufgebaut. Von
Interesse sind hier die folgenden Felder.
Wichtige Tabellenfelder zum Aufbau von IDoc Datensätzen
Feld Bedeutung
segnam Segmenttyp des IDoc-Datensatz
sdata 1000 Bytes langes Characterfeld für die Nutzdaten
Die übrigen Felder in edidd sind initial zu lassen.

In der IDoc-Struktur sind alle Segmenttypen und ihre Reihenfolge aufgeführt. Gemäß dieser
Reihenfolge werden die Datensätze aus den Anwendungsdaten aufgebaut und an die interne
Tabelle angehängt.
Für jeden Segmenttyp der IDoc-Struktur gibt es eine gleichnamige DDIC-Struktur. Eine Feldleiste
mit dieser Struktur wird für den Aufbau eines Datensatzes genutzt. Die Anwendungsdaten
werden in die Feldleiste gemappt. Der Segmenttyp wird in das Feld segnam geschrieben und die
Feldleiste in das sdata-Feld. Dieser Datensatz wird dann an die interne Tabelle der Struktur
edidd angehängt..
Beim Aufbau des IDoc-Datensatzes sind die folgenden Designrichtlinien zu beachten:
· Konvertierung von Währungsbeträgen [Seite 72]
· Ersetzen von SAP-Codes durch ISO-Codes [Seite 73]
· Linksbündiges Füllen von IDoc-Feldern [Seite 74]
April 2001 71
Konvertierung von Währungsbeträgen
Konvertierung von Währungsbeträgen

Währungsbeträge müssen vom SAP-internen Format auf ein extern verständliches Format
umgesetzt werden. SAP-intern werden alle Währungsbeträge mit zwei Nachkommastellen
abgespeichert. Bei Währungen, die eine ander Anzahl von Nachkommastellen haben, ist eine
Konvertierung der Währungsbeträge notwendig. Für diese Konvertierung kann der
Funktionsbaustein currency_amount_sap_to_idoc verwendet werden, der einen
Währungsbetrag IDoc-gerecht konvertiert.
Wir empfehlen, das Coding in einer Unterroutine
<Segment-Typ>_currency_sap_to_idoc zu kapseln.
72 April 2001
Ersetzen von SAP-Codes durch ISO-Codes
Ersetzen von SAP-Codes durch ISO-Codes

Für Länderschlüssel, Währungsschlüssel, Mengeneinheiten und Versandvorschriften gibt es
ISO-Codes. Laut einer SAP-Design-Richtlinie sind für den Aufbau eines IDocs ISO-Codes zu
verwenden, falls vorhanden. Beim Aufbau des IDocs müssen die SAP-Codes durch ISO-Codes
ersetzt werden. Hierzu kann man die folgenden Funktionsbausteine verwenden.
Funktionsbausteine zur Konvertierung von SAP-Codes

Domäne Funktionsbaustein
Währungsschlüssel currency_code_sap_to_iso
Länderschlüssel country_code_sap-to_iso
Mengeneinheiten unit_of_measure_sap_to_iso
Versandvorschriften sap_to_iso_package_type_code
Wir empfehlen, das Coding in einer Unterroutine <Segment-Typ>_codes_sap_to_iso zu kapseln.
April 2001 73
Linksbündiges Füllen von IDoc-Feldern
Linksbündiges Füllen von IDoc-Feldern

Alle Felder müssen linksbündig gefüllt sein. Bei Character-Feldern geschieht dies automatisch.
Wenn das Ursprungsfeld der Anwendung ein Nicht-Character-Feldern ist, muß ein condense auf
das entsprechende Feld im IDoc-Segment ausgeführt werden. Die Felder, für die ein condense
erfolgen muß, kann man aus der Dokumentationsstruktur zu einem Segmenttyp ermitteln. Der
Name der Dokumentationsstruktur beginnt statt "E1" bzw. "Z1" mit "E3" bzw. "Z3" und ist
ansonsten gleich. Diese Struktur enthält die gleichen Felder wie die "E1"- bzw. "Z1"-Struktur. Hier
findet man aber die Original-Datenelemente und -Domänen der Anwendung. Alle Felder, die
einen Datentyp ungleich char, cuky, clnt, accp, numc, dats, tims oder unit haben, brauchen einen
condense.
Wir empfehlen, das Coding in einer Unterroutine <Segment-Typ>_condense zu kapseln.
Das linksbündige Setzen sollte nach der Konvertierung der Währungsbeträge und ISO-Codes
erfolgen
74 April 2001
Aufruf von master_idoc_distribute
Aufruf von MASTER_IDOC_DISTRIBUTE

Nach dem Aufruf von MASTER_IDOC_DISTRIBUTE muß ein COMMIT WORK abgesetzt
werden, der normale Datenbank-Commit am Transaktionsende reicht nicht aus. Der COMMIT
WORK muß nicht sofort nach dem Aufruf erfolgen, er kann auch in höheren Aufrufebenen
abgesetzt werden oder nach mehreren Aufrufen von MASTER_IDOC_DISTRIBUTE erfolgen..
Beachten Sie, dass die erzeugten IDocs noch bis zum Ende der aufrufenden Transaktion
gesperrt sind. Um sie vorher zu entsperren, können Sie einen der beiden folgenden
Funktionsbausteine aufrufen:
· DEQUEUE_ALL gibt alle Sperrobjekte frei
· EDI_DOCUMENT_DEQUEUE_LATER gibt als Parameter übergebene IDocs frei
Falls der Anwendungsbeleg über den Verbucher erstellt wird, muß auch der Aufruf von
MASTER_IDOC_DISTRIBUTE im Verbucher (in update task) erfolgen, falls nicht bereits auf
einer höher liegenden Ebene ein Verbuchungsaufruf erfolgt ist.
Siehe auch:
Exceptions und Export-Parameter von MASTER_IDOC_DISTRIBUTE [Seite 76]
April 2001 75
Exceptions und Export-Parameter von master_idoc_distribute
Exceptions und Export-Parameter von

master_idoc_distribute
Über den Tabellen-Parameter communication_idoc_control gibt der Baustein die Kontrollsätze
der IDocs zurück, die auf der Datenbank angelegt wurden. Man kann z. B. über die Felder
docnum und status die IDoc-Nummer und den aktuellen Status erfahren. Im allgemeinen ist
diese Tabelle für die rufende Anwendung nicht von Interesse.
Wenn der Empfänger des IDocs im Kontrollsatz beim Aufruf von master_idoc_distribute mit
übergeben wurde, er aber laut Verteilungsmodell dieses IDoc nicht empfangen darf, wird die
Exception error_in_idoc_control mit einer entsprechenden Fehlermeldung ausgegeben.
Wenn kein Empfänger im Kontrollsatz mitgegeben wurde und ALE keinen Empfänger im
Verteilungsmodell findet, wird keine Exception ausgeworfen. Wenn man auf diesen Fall
reagieren will, muß man die Rückgabe-Tabelle communication_idoc_control abfragen. Ist diese
Tabelle leer, wurde kein IDoc erzeugt.
Dieses unterschiedliche Verhalten bei initialem und nicht initialem Empfänger ist historisch
bedingt. Der initiale Empfänger ist der Standardfall für die Stammdatenreplikation, wo es nicht
weiter interessiert, ob tatsächlich ein IDoc angelegt wurde. Der vorgegebene Empfänger ist der
Standard für das Versenden von Bewegungsdaten, wo das Nichterstellen eines IDocs als Fehler
interpretiert wird.
Liste aller Exceptions und deren Auftreten
Exception Auftreten
error_in_idoc_control Kein oder falscher Nachrichtentyp angegeben.
Kein oder falscher IDoc-Typ angegeben.
Kein IDoc erzeugt, obwohl Empfänger durch
Anwendung vorgegeben.
error_in_idoc_data Keine Datensätze übergeben
error_writing_idoc_status Technische Probleme beim Schreiben der Status-
Sätze.
sending_logical_system_unknown Das eigene logische System konnte nicht ermittelt
werden.
76 April 2001
Beispiel für die IDoc-Erzeugung
Beispiel für die IDoc-Erzeugung

Im Beispielprogramm für die IDoc-Erzugung [Seite 78] wird ein IDoc des Nachrichtentyps
XAMPLE und des IDoc-Typs XAMPLE01 aufgebaut. Als Quelle für die Anwendungsdaten dienen
die Parameter APPL_HEADER und APPL_ITEM.
Siehe auch:
· Coding Beispiel [Seite 105] aus der Eingangsverarbeitung
· Verwendung des Coding-Beispiels [Seite 84]
April 2001 77
Beispielprogramm für die IDoc-Erzeugung
FUNCTION MASTER_IDOC_CREATE_XAMPLE.
*"---------------------------------------------------------------------
*" Lokale Schnittstelle:
*" IMPORTING
*" VALUE(APPL_HEADER) LIKE XHEAD STRUCTURE XHEAD
*" TABLES
*" APPL_ITEM STRUCTURE XITEM
*"---------------------------------------------------------------------
* variables of general interest

DATA:
* control record for the IDoc
IDOC_CONTROL LIKE EDIDC,
* data records for the IDoc
T_IDOC_DATA LIKE EDIDD OCCURS 0 WITH HEADER LINE,
* table for the IDocs created by MASTER_IDOC_CONTROL
T_COMM_CONTROL LIKE EDIDC OCCURS 0 WITH HEADER LINE,
* partner type for logical system
C_PARTNER_TYPE_LOGICAL_SYSTEM LIKE EDIDC-RCVPRT,
* help variable for the check if an IDoc has to be created
H_CREATE_IDOC.
* variables specific for this example

DATA:
* field strings with IDoc segment structure
E1XHEAD LIKE E1XHEAD,
E1XITEM LIKE E1XITEM,
* data to be put to the control record
C_MESSAGE_TYPE LIKE EDIDC-MESTYP VALUE 'XAMPLE',
C_BASE_IDOC_TYPE LIKE EDIDC-IDOCTP VALUE 'XAMPLE01',
* segment types to be put to the data record table
C_HEADER_SEGTYP LIKE EDIDD-SEGNAM VALUE 'E1XHEAD',
C_ITEM_SEGTYP LIKE EDIDD-SEGNAM VALUE 'E1XITEM'.
* check if an IDoc has to be created, read the distribution model

CALL FUNCTION 'ALE_MODEL_DETERMINE_IF_TO_SEND'
EXPORTING
MESSAGE_TYPE = C_MESSAGE_TYPE
* SENDING_SYSTEM = ' '
* RECEIVING_SYSTEM = ' '
* VALIDDATE = SY-DATUM
IMPORTING
IDOC_MUST_BE_SENT = H_CREATE_IDOC.
* exceptions
* own_system_not_defined = 1
* others = 2.
IF H_CREATE_IDOC IS INITIAL.
* no message flow maintained in the model, nothing to do
78 April 2001
EXIT.
ENDIF.
* put the application header record to the IDoc

MOVE-CORRESPONDING APPL_HEADER TO E1XHEAD.
* convert SAP codes to ISO codes

PERFORM E1XHEAD_CODES_SAP_TO_ISO
USING
APPL_HEADER
CHANGING
E1XHEAD.
* append record to IDoc data table

T_IDOC_DATA-SEGNAM = C_HEADER_SEGTYP.
T_IDOC_DATA-SDATA = E1XHEAD.
APPEND T_IDOC_DATA.
LOOP AT APPL_ITEM.
* put the application item record to the IDoc segment
MOVE-CORRESPONDING APPL_ITEM TO E1XITEM.
* convert currency amounts from SAP internal to neutral format

PERFORM E1XITEM_CURRENCY_SAP_TO_IDOC
USING
APPL_HEADER-CURRENCY
CHANGING
E1XITEM.
* convert SAP codes to ISO codes

PERFORM E1XITEM_CODES_SAP_TO_ISO
USING
APPL_ITEM
CHANGING
E1XITEM.
* left justify all non character fields

PERFORM E1XITEM_CONDENSE
CHANGING
E1XITEM.
* append record to IDoc data table

T_IDOC_DATA-SEGNAM = C_ITEM_SEGTYP.
T_IDOC_DATA-SDATA = E1XITEM.
APPEND T_IDOC_DATA.
ENDLOOP.
CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'

* in update task "if application document is posted in update task
EXPORTING
MASTER_IDOC_CONTROL = IDOC_CONTROL
TABLES
COMMUNICATION_IDOC_CONTROL = T_COMM_CONTROL
April 2001 79
MASTER_IDOC_DATA = T_IDOC_DATA.
* exceptions
* error_in_idoc_control = 1
* error_writing_idoc_status = 2
* error_in_idoc_data = 3
* sending_logical_system_unknown = 4
* others = 5.
* A commit work has to be done. It could also be done in the calling

* application.
COMMIT WORK.
READ TABLE T_COMM_CONTROL INDEX 1.

IF SY-SUBRC <> 0.
* no IDoc was created, you can react here, if neccessary
ENDIF.
ENDFUNCTION.
*&---------------------------------------------------------------------
*
*& Form E1XITEM_CONDENSE
*&---------------------------------------------------------------------
*
* text
*
*----------------------------------------------------------------------
*
* --> p1 text
* <-- p2 text
*----------------------------------------------------------------------
*
FORM E1XITEM_CONDENSE
CHANGING
IDOC_SEGMENT LIKE E1XITEM.
* left justify all non character fields

CONDENSE: IDOC_SEGMENT-QUANTITY,
IDOC_SEGMENT-VALUE.
ENDFORM. " E1XITEM_CONDENSE

*&---------------------------------------------------------------------
*
*& Form E1XITEM_CURRENCY_SAP_TO_IDOC
*&---------------------------------------------------------------------
*
* text
*
*----------------------------------------------------------------------
*
* --> p1 text
* <-- p2 text
*----------------------------------------------------------------------
80 April 2001
*
FORM E1XITEM_CURRENCY_SAP_TO_IDOC
USING
CURRENCY_CODE LIKE TCURC-WAERS
CHANGING
CALL FUNCTION 'CURRENCY_AMOUNT_SAP_TO_IDOC'

EXPORTING
CURRENCY = CURRENCY_CODE
SAP_AMOUNT = IDOC_SEGMENT-VALUE
IMPORTING
IDOC_AMOUNT = IDOC_SEGMENT-VALUE.
* exceptions
* others = 1.
ENDFORM. " E1XITEM_CURRENCY_SAP_TO_IDOC

*&---------------------------------------------------------------------
*
*& Form E1XHEAD_CODES_SAP_TO_ISO
*&---------------------------------------------------------------------
*
* text
*
*----------------------------------------------------------------------
*
* --> p1 text
* <-- p2 text
*----------------------------------------------------------------------
*
FORM E1XHEAD_CODES_SAP_TO_ISO
USING
APPL_DATA LIKE XHEAD
CHANGING
IDOC_SEGMENT LIKE E1XHEAD.
* convert a currency code from SAP code to ISO code

IF NOT APPL_DATA-CURRENCY IS INITIAL.
CALL FUNCTION 'CURRENCY_CODE_SAP_TO_ISO'
EXPORTING
SAP_CODE = APPL_DATA-CURRENCY
IMPORTING
ISO_CODE = IDOC_SEGMENT-CURRENCY.
* exceptions
* not_found = 1
* others = 2.
ELSE.
IDOC_SEGMENT-CURRENCY = APPL_DATA-CURRENCY.
ENDIF.
* convert a country from SAP code to ISO code

IF NOT APPL_DATA-COUNTRY IS INITIAL.
CALL FUNCTION 'COUNTRY_CODE_SAP_TO_ISO'
April 2001 81
EXPORTING
SAP_CODE = APPL_DATA-COUNTRY
IMPORTING
ISO_CODE = IDOC_SEGMENT-COUNTRY.
* exceptions
* not_found = 1
* others = 2.
ELSE.
IDOC_SEGMENT-COUNTRY = APPL_DATA-COUNTRY.
ENDIF.
ENDFORM. " E1XHEAD_CODES_SAP_TO_ISO

*&---------------------------------------------------------------------
*
*& Form E1XITEM_CODES_SAP_TO_ISO
*&---------------------------------------------------------------------
*
* text
*
*----------------------------------------------------------------------
*
* --> p1 text
* <-- p2 text
*----------------------------------------------------------------------
*
FORM E1XITEM_CODES_SAP_TO_ISO
USING
APPL_DATA LIKE XITEM
CHANGING
* convert a unit of measure from SAP code to ISO code

IF NOT APPL_DATA-UNIT IS INITIAL.
CALL FUNCTION 'UNIT_OF_MEASURE_SAP_TO_ISO'
EXPORTING
SAP_CODE = APPL_DATA-UNIT
IMPORTING
ISO_CODE = IDOC_SEGMENT-UNIT.
* exceptions
* not_found = 1
* no_iso_code = 2
* others = 3.
ELSE.
IDOC_SEGMENT-UNIT = APPL_DATA-UNIT.
ENDIF.
* convert a package type from SAP code to ISO code

IF NOT APPL_DATA-SHIP_INST IS INITIAL.
CALL FUNCTION 'SAP_TO_ISO_PACKAGE_TYPE_CODE'
EXPORTING
SAP_CODE = APPL_DATA-SHIP_INST
IMPORTING
ISO_CODE = IDOC_SEGMENT-SHIP_INST.
82 April 2001
* exceptions
* not_found = 1
* others = 2.
ELSE.
IDOC_SEGMENT-SHIP_INST = APPL_DATA-SHIP_INST.
ENDIF.
ENDFORM. " E1XITEM_CODES_SAP_TO_ISO
April 2001 83
Verwendung des Coding-Beispiels
Verwendung des Coding-Beispiels

· Eigenen Funktionsbaustein anlegen. Vorschlag: master_idoc_create_<Nachrichtentyp>. In
der Schnittstelle sind die Beispiel-Parameter appl_head und appl_item sind durch die
eigenen Anwendungsdaten, aus denen das IDoc erstellt werden soll, zu ersetzen.
· Variablendefinition: Die erste data-Anweisung kann übernommen werden. Die zweite data-
Anweisung muß an das eigene IDoc angepaßt werden.
· Der Block, in dem das Verteilungsmodell gelesen wird, kann übernommen oder sogar noch
erweitert werden, falls gewünscht. In diesem Beispiel wurde der Baustein
ale_model_determine_if_to_send verwendet.
· Für alle IDoc-Segmenttypen mit Währungsbeträgen kann die Form-Routine
e1xitem_currency_sap_to_idoc als Vorlage verwendet werden, um eine eigene
Konvertierungsroutine zu schreiben. Vorschlag für den Namen:
<Segmenttyp>_currency_sap_to_idoc.
· Für alle IDoc-Segmenttypen mit Feldern, für die ISO-Codes existieren, kann die Form-
Routine e1xitem_codes_sap_to_iso als Vorlage verwendet werden, um eine eigene
Konvertierungsroutine zu schreiben. Vorschlag für den Namen:
<Segmenttyp>_codes_sap_to_iso.
· Für alle IDoc-Segmenttypen mit linksbündig zu setzenden Feldern, kann die Form-Routine
e1xhead_condense als Vorlage verwendet werden, um eine eigene Routine zu schreiben.
Vorschlag für den Namen: <Segmenttyp>_condense. Das linksbündig Setzen sollte nach
den Kovertierungen erfolgen.
· Die Programmteile, in denen aus den Anwendungsdaten das IDoc aufgebaut wird, müssen
an die eigenen Anwendungsstrukturen und die IDoc-Segmente angepaßt werden.
· Falls die Anwendung über den Verbucher geht, muß eventuell master_idoc_distribute auch
in update task aufgerufen werden.
· COMMIT WORK nicht vergessen, wenn auf einer höheren Ebene keiner erfolgt. Der
Datenbank-Commit am Transaktionsende reicht nicht aus.
84 April 2001
Einstellung der ALE-Ausgangsverabeitung
Einstellung der ALE-Ausgangsverabeitung

ALE kann sich bei jedem ausgehenden IDoc das enthaltene Anwendungsobjekt merken. Z.B.
schreibt die ALE-Schicht für ein Materialstamm-IDoc eine Verknüpfung zwischen der
Materialnummer und der IDoc-Nummer fort. Auf die dazu notwendigen Customizing-Schritte wird
hier verwiesen.
In der ALE-Empfängerermittlung läßt sich individuell für jeden Empfänger einstellen, in welchen
Fällen er ein IDoc erhält oder nicht. Z. B. kann man für den Materialstammsatz festlegen, daß ein
Empfänger nur Materialien einer gewissen Materialart erhält.
Dazu müssen Sie die Verteilungskriterien, die Filterobjekte [Extern], wie nachfolgend
beschrieben festlegen:
· ALE-Objektypen definieren [Seite 86]
· Objekttyp für die Ausgangsverknüpfung dem Nachrichtentyp zuorden [Seite 87]
· Anwendungsobjekttyp für die Ausgangsverknüpfung dem Nachrichtentyp zuordnen [Seite 88]
Die Funktionen zur Einstellung der ALE-Ausgangsverarbeitung finden Sie im

Bereichsmenü ALE-Entwicklung. Um dorthin zu gelangen, wählen Sie Werkzeuge ®
ALE ® Entwicklung.
April 2001 85
ALE-Objektypen definieren
ALE-Objektypen definieren
Die Voraussetzung sowohl für die Verknüpfung zu einem Anwendungsobjekt als auch für das
Filtern in der Empfängerermittlung ist das Vorhandensein von entsprechenden ALE-Objekten.
Wenn wie im obigen Beispiel das ausgehende IDoc mit der Materialnummer verknüpft werden
soll, muß die Materialnummer aus dem IDoc-Datenteil gelesen werden. Die ALE-Schicht
übernimmt die IDoc-Daten aber als unformatierte Character-Strings. Deshalb braucht ALE die
Information, aus welchen Nachrichtentyp, welchem Segment und welchen Feldern das ALE-
Objekt "Materialnummer" gelesen werden kann. Das gleiche gilt für das ALE-Objekt "Materialart",
das für die Empfängerermittlung verwendet wird.
Um ALE-Objekte zu definieren, wählen sie in der ALE-Entwicklung IDoc-Schnittstelle ®
Datenfilterung ® Filterobjekttyp pflegen.
86 April 2001
Objekttyp für die Ausgangsverknüpfung dem Nachrichtentyp zuorden
Objekttyp für die Ausgangsverknüpfung dem

Nachrichtentyp zuorden
Um Ihrem Nachrichtentyp das ALE-Objekt zuzuweisen, für das Sie eine Verknüpfung für jedes
ausgehende IDoc haben möchten, wählen sie in der ALE-Entwicklung IDoc ® ALE-Objekte ®
Verknüpfungs- und Serialisierungsobjekte.
April 2001 87
Anwendungsobjekttyp für die Ausgangsverknüpfung dem Nachrichtentyp zuordnen
Anwendungsobjekttyp für die Ausgangsverknüpfung

dem Nachrichtentyp zuordnen
Die Verknüpfung zwischen dem Anwendungsobjekt und dem ausgehendem IDoc wird mit Mitteln
des BOR geschrieben. Dazu ist es notwendig, daß für den Nachrichtentyp der BOR-Objekttyp
angegeben wird. Für die Materialnummer ist dies z. B. BUS1001.
Um diese Funktion auszuführen, wählen sie in der ALE-Entwicklung IDoc ® ALE-Objekte ®
Zuordnen zum Nachrichtentyp.
Ein Teil des ALE-Customizings für die Ausgangsverarbeitung ist partnerunabhängig.

Es gilt für alle Nachrichtenflüsse für einen Nachrichtentyp.
88 April 2001
Ausgang über die Nachrichtensteuerung
Ausgang über die Nachrichtensteuerung

Der Anstoß zum Versend eines IDocs erfolgt in diesem Fall nicht aus der Anwendung heraus,
sondern aus der Nachrichtensteuerung.
Falls ein Anschluß an die Nachrichtensteuerung erfolgen soll, sind verschiedene Punkte bei der
Programmentwicklung und im Customizing zu beachten.
Customizing
· Zusätzlich zu den obigen Einstellungen muß ein Vorgangscode für den Ausgang angelegt
werden. Hinter dem Vorgangscode verbirgt sich der IDoc-erzeugende Funktionsbaustein der
Anwendung.
· Die Sendemedien, die für die Kombination Applikation/Nachrichtentart verwendet werden
können, sind "6" (ohne ALE-Modell, kein Umsetzen des NAST-Empfängers auf das
entsprechende logische System) und "A" (mit ALE-Modell).
· Für das Sendemedium "6" sollte aus der Nachrichtensteuerung die Formroutine
edi_processing(rsnasted) gerufen werden. Für das Sendemedium "A" kann man die
Formroutine ale_processing(rsnasted) verwenden bzw. eine eigene Formroutine schreiben,
die einen Aufruf von master_idoc_distribute absetzt.
Programmierung
· Die Schnittstelle des IDoc-erzeugenden Funktionsbausteins ist vorgegeben. Als Beispiel
betrachte man idoc_output_orders.
· Der Aufruf von master_idoc_distribute fällt weg.
· Es darf kein COMMIT WORK abgesetzt werden!
April 2001 89
Eingangsverarbeitung implementieren
Eingangsverarbeitung implementieren
Dieser Abschnitt beschreibt die Implementation einer ALE-fähigen Schnittstelle für eingehende
IDocs. Es wird vorausgesetzt, daß Nachrichtentypen und IDoc-Typen bereits definiert sind.
Komponenten einer ALE-Schnittstelle für die IDoc-Eingangsverarbeitung

Eine vollständige ALE-Schnittstelle für die Verarbeitung von eingehenden IDocs besteht aus
folgenden Komponenten:
1. ein Funktionsbaustein zur Verarbeitung des eingehenden IDocs. Er wird von der ALE-Schicht
aufgerufen.
2. eine SAP Business Workflow-Aufgabe mit ihren Objekten und Ereignissen für die
Fehlerbehandlung.
3. ALE-Tabelleneinträge ("Einstellungen").
Ablauf der IDoc-Eingangsverarbeitung

1. Die ALE-Schicht liest die Customizing-Einstellungen für den IDoc-Eingang, um festzustellen,
welcher Funktionsbaustein aufgerufen werden soll.
2. Der Funktionsbaustein wird aufgerufen und ihm das zu verarbeitenden IDoc übergeben.
3. Der Funktionsbaustein meldet durch Statusinformationen zurück, ob das IDoc erfolgreich
verarbeitet wurde.
4. Bei erfolgreicher Verarbeitung wird die Kennung des angelegten oder geänderten
Anwendungsbelegs zurückgegeben.
5. Tritt bei der Verarbeitung des IDocs ein Fehler auf, löst die ALE-Schicht das dem IDoc
zugeordnete SAP Business Workflow-Ereignis aus.
Siehe auch:
Funktionsbaustein im Eingang [Seite 91]
ALE-Einstellungen [Seite 156]
Anzulegende Objekte, Ereignisse und Aufgaben [Seite 214]
Eingangsverarbeitung über SAP-Workflow [Seite 160]
Erweiterte Workflow-Programmierung [Seite 165]
90 April 2001
Funktionsbaustein im Eingang
Funktionsbaustein im Eingang
In diesem Abschnitt erfahren Sie, wie Sie den Funktionsbaustein implementieren, der für die
Verarbeitung eingehender IDocs aufgerufen wird.
Zunächst wird beschrieben, welche Gesichtspunkte für die Datenkonsistenz maßgebend sind.
Dann befassen wir uns mit dem einfachsten Verarbeitungsfall, d.h. der Funktionsbaustein im
Eingang verarbeitet ein einzelnes IDoc.
Anschließend wird beschrieben, wie die Serialisierungsfunktion eingesetzt wird und Customer-
Exits hinzugefügt werden.
Danach beschäftigen wir uns mit der Implementierung eines Funktionsbausteins im Eingang, der
mehrere IDoc gleichzeitig verarbeitet ("Massenverarbeitung").
Schließlich erfahren Sie, wie Sie Datenkonsistenz beim Einsatz einer Call Transaction
garantieren.
Siehe auch:
· Einbettung eines Funktionsbausteins in die ALE-Eingangsverarbeitung [Seite 92]
· Datenkonsistenz [Seite 93]
· Verarbeitung eines einzelnen IDocs [Seite 96]
· Serialisierung [Seite 119]
· Customer-Exits [Seite 126]
· Massenverarbeitung [Seite 134]
· Call Transaction einsetzen [Seite 146]
April 2001 91
Einbettung eines Funktionsbausteins in die ALE-Eingangsverarbeitung
Einbettung eines Funktionsbausteins in die ALE-

Aus der folgenden Abbildung können Sie erkennen, wie der Funktionsbaustein in die
Eingangsverarbeitung von ALE eingebettet ist. Diese Darstellung gilt für alle Fälle, es sei denn,
ein eingegangener IDoc wurde erfolgreich mit einer Call Transaction in einer ALE-fähigen
Transaktion verarbeitet.
ALE-Schicht Anwendungs-
funktionsbaustein
IDoc(s) sperren
IDoc(s) lesen
Anwendungsobjekte
Optional:
IDoc-Daten verarbeiten
Anwendungsdaten auf DB
IDoc-Status schreiben
Links schreiben
Optional:
Serialisierungsdaten
Ereignis(se) auslösen
Commit Work
IDoc(s) und
objekte entsperren
Ablauf der Eingangsverarbeitung
92 April 2001
Datenkonsistenz
Datenkonsistenz
Siehe auch:
Gewährleistung der Datenkonsistenz [Seite 94]
Serialisierung [Seite 95]
April 2001 93
Gewährleistung der Datenkonsistenz
Gewährleistung der Datenkonsistenz

Um die Datenkonsistenz bei einem Datenbankfehler zu gewährleisten, müssen die
Anwendungstabellen in der gleichen Logical Unit of Work (LUW) aktualisiert werden wie die
IDoc-Statustabelle. Ansonsten führt ein Datenbankfehler, z.B. "no tablespace", zu den folgenden
Situationen:
· Anwendungstabellen korrekt, Aktualisierung des IDoc-Status gescheitert: der IDoc hat den
Status "bereit für Übergabe an Anwendung" und würde nun noch ein zweites Mal verarbeitet,
obwohl die Daten bereits verarbeitet sind.
Das IDoc enthält Buchungen; doppelte Verarbeitung würde dazu führen, daß für die
gleichen Daten zwei FI-Belege erstellt werden würden
· Die Aktualisierung des IDoc-Status verläuft erfolgreich, jedoch scheitert die

Anwendungsaktualisierung: Das IDoc hat den Status "erfolgreich verarbeitet", jedoch wurden
die Anwendungstabellen nicht aktualisiert. Das IDoc kann nicht erneut verarbeitet werden,
daher erreichen die Daten niemals die Anwendung.
Um sicherzustellen, daß nur eine LUW verwendet wird, darf der Anwendungsfunktionsbaustein
die Daten nicht in der Datenbank festschreiben. Die Daten werden von der ALE-Schicht
festgeschrieben, nachdem die Funktion aufgerufen wurde und die Statussätze des IDocs
aktualisiert worden sind.
Dies ist nicht möglich, wenn die Anwendungsdaten über eine Call Transaction aktualisiert
werden, da jede Call Transaction automatisch mit einem Commit Work abgeschlossen wird. In
diesem Fall muß die Transaktion selbst modifiziert werden (siehe unten).
Ein Call Dialog anstatt einer Call Transaction umgeht zwar einen Commit Work, kann aber nur
eingesetzt werden, wenn der Dialogschritt keine PERFORM ON COMMIT-Anweisungen enthält -
da der Commit über ALE nach Abschluß des Dialogs erfolgt, gehen alle globalen Variablen, die
während des Dialogs gesetzt wurden, verloren. Verwenden Sie daher einen Call Dialog nur mit
äußerster Vorsicht!
Enthalten die IDocs Stammdaten (z.B. Kundendaten), dann erweist sich das Problem als nicht so
akut, da fehlende Daten immer bei Bedarf noch einmal übertragen werden können, und eine
doppelte Verarbeitung eines IDocs führt nicht dazu, daß ein Beleg zweimal erstellt wird.
94 April 2001
Serialisierung
Serialisierung
Falls die richtige Reihenfolge bei der Verarbeitung der eingegangenen IDocs entscheidend ist,
können Sie die ALE-Serialisierungsfunktion einsetzen, um festzustellen, ob ein IDoc
übernommen wurde oder nicht. Die Serialisierungsfunktion wird unten näher beschrieben.
April 2001 95
Verarbeitung eines einzelnen IDocs
Verarbeitung eines einzelnen IDocs

Im folgenden wird beschrieben, wie die Verarbeitung eines einzelnen IDocs abläuft. Zunächst
wird auf die Import-Parameter des Funktionsbausteins eingegangen, anschließend erklärt, wie
der IDoc verarbeitet wird und die Export-Parameter gesetzt werden. Zum Schluß sehen Sie ein
kleines Beispiel für ein Coding.
Siehe auch:
Namenskonvention [Seite 97]
Die Schnittstelle des Funktionsbausteins [Seite 98]
Import-Parameter [Seite 99]
IDoc Verarbeitung [Seite 100]
Export-Parameter [Seite 101]
Coding Beispiel [Seite 105]
96 April 2001
Namenskonvention
Namenskonvention
Wir empfehlen, den Funktionsbaustein für die Verarbeitung eingegangener IDocs mit dem
Nachrichtentyp "MSGTYP" "IDOC_INPUT_MSGTYP" zu nennen; Kunden können
"Z_IDOC_INPUT_MSGTYP" verwenden.
April 2001 97
Die Schnittstelle des Funktionsbausteins
Die Schnittstelle des Funktionsbausteins
Typ Richtung Parameter Referenzfeld/

-struktur
Import --> INPUT_METHOD
--> MASS_PROCESSING
Export <-- IN_UPDATE_TASK
<-- CALL_TRANSACTION_DONE
<-- WORKFLOW_RESULT
<-- APPLICATION_VARIABLE
Tabellen --> IDOC_CONTRL EDIDC
--> IDOC_DATA EDIDD
<-- IDOC_STATUS BDIDOCSTAT
<-- RETURN_VARIABLES BDWFRETVAR
<-- SERIALIZATION_INFO BDI_SER
Ausnahme WRONG_FUNCTION_CALLED
98 April 2001
Import-Parameter
Import-Parameter
Parameter Bedeutung
IDoc_Contrl Diese Tabelle enthält einen Eintrag für den Steuersatz der
IDocs. Der Funktionsbaustein verwendet sie nur für den
Import von Daten. Normalerweise verwendet der Funktions-
Funktionsbaustein im Eingang nur die Felder Docnum (die
IDoc-Nummer) und entweder Mestyp (Nachrichtentyp) oder
IDoctp (Basis-IDoc-Typ).
IDoc_Data Diese Tabelle enthält nur einen Eintrag für jedes Idoc-
Datensegment. Die folgenden Felder sind für den Funktions-
baustein im Eingang relevant:
Docnum die IDoc-Nummer
Segnam der Segmentname
Sdata die Daten des Segments
Input_Method Zeigt an, ob das IDoc im Dialog (z.B. über Call Transaction)
oder nicht verarbeitet werden soll. Mögliche Werte sind:
" " Hintergrund (kein Dialog)
"A" zeigt alle Dynpros
"E" Startet den Dialog an der Stelle im Dynpro, an
dem der Fehler aufgetreten ist
Hinweis: Der Parameter kann die Werte "A" oder "E" nur
annehmen, wenn die ALE-Einstellung für den Funtions-
baustein Dialogverarbeitung unterstützt.
Mass_Processing Wird nicht mehr verwendet (außer bei fortgeschrittener
Workflow-Programmierung). Ist initial, wenn die Methoden
InputForeground oder InputBackground vorgesehen sind,
ansonsten enthält er den Wert "X".
April 2001 99
IDoc Verarbeitung
IDoc Verarbeitung
Der Funktionsbaustein sollte die folgenden Schritte ausführen:
· Prüfen Sie, ob das IDoc den richtigen Nachrichtentyp enthält (Feld Idoc_Contrl-Mestyp). Ist
dies nicht der Fall, lösen Sie die Ausnahme Wrong_Function_Called mit der entsprechenden
Meldung aus.
- Wenn Sie einen Funktionsbaustein im Eingang für Stammdaten implementieren, die vom
Kunden "reduziert" werden können, prüfen Sie nicht den Nachrichtentyp, sondern den
Basis-IDoc-Typ (Feld Idoc_Contrl-Idoctp)
· Initialisieren/aktualisieren Sie alle globalen Variablen bzw. Tabellen. Der Funktionsbaustein
im Eingang kann mehrmals von einem Prozeß aufgerufen werden. Die globalen Variablen
sind daher beim zweiten Mal mit Werten versorgt.
· Konvertieren Sie die Character-Daten in table Idoc_Data in internes Format in internen
Tabellen. Sehen Sie im unten folgenden Beispiel nach, wie Sie dazu vorgehen müssen.
Besondere Beachtung sollten Sie den Feldern schenken, die enthalten:
- Maßeinheiten (ISO-Code im IDoc)
- Währungscodes (ISO-Code im IDoc)
- Ländercodes (ISO-Code im IDoc)
- Versandvorschriften (ISO-Code im IDoc)
- Geldbeträge (Konvertierungsfaktor erforderlich)
- Datums- und Zeitangaben (siehe unten)
Felder mit Datums- und Zeitangaben können bei der Eingangsverarbeitung zu Fehlern führen,
wenn das Feld im IDoc leer ist: wenn in ABAP/4 ein leeres Zeichenfeld in ein Datenfeld
übertragen wird, bleibt das Datenfeld leer, anstatt initial (nur Nullen), d.h., das Datenfeld hat
schließlich einen ungültigen Wert. Die Fehler treten dann bei der nachfolgenden Verarbeitung
auf, sobald das Datenfeld gegen den Initialwert "if DateField is initial..." geprüft wird. Um dies zu
vermeiden, entfernen Sie den Wert im Datenfeld, wenn das IDoc-Feld leer ist, wie im Beispiel-
Coding gezeigt.
Denken Sie daran: der Funktionsbaustein sollte nicht die Daten auf der Datenbank
festschreiben (Commit Work).
Wenn Sie die Wahl haben, aktualisieren Sie die Datenbank nicht mit Call Function
"xxx" In Update Task - dies ist für die ALE-Verarbeitung nicht erforderlich und erhöht
nur die Last der Datenbank
100 April 2001

Export-Parameter
Export-Parameter
Siehe auch:
Exportparameter des eingehenden Funktionsbausteins [Seite 102]
Exportparameter bei erfolgreicher IDoc-Verarbeitung [Seite 103]
Exportparameter bei fehlerhafter IDoc-Verarbeitung [Seite 104]
April 2001 101

Exportparameter des eingehenden Funktionsbausteins
Exportparameter des eingehenden Funktionsbausteins
Parameter Bedeutung
In_Update_Task Flag: Soll die Verbuchungstask die Datenbank aktualisieren?
D.h., aktualisiert Ihr Funktionsbaustein die Datenbank mit Call
Function "xxx" In Update Task?
Call_Transaction_Done Flag: Wurde eine Call Transaction verwendet, die den IDoc-
Status aktualisiert hat?
Workflow_Result Ein Parameter, der kontrolliert, ob Ereignisse ausgelöst
wurden.
Application_Variable Ein optionaler Parameter, der an den Workflow übergeben
wird.
Idoc_Status Eine Tabelle, die einen Satz für jedes verarbeitete IDoc enthält.
Gültige Werte für das Feld Status sind:
"51" Fehler
"53" IDoc erfolgreich verarbeitet
Return_Variables Eine Tabelle, die die Belegnummern des verarbeiteten IDocs
und des Anwendungsobjekts enthält. Diese Nummern werden
für den Workflow (z.B. Fehlerbehandlung) verwendet und um
das IDoc mit dem entsprechenden Anwendungsobjekt zu
verknüpfen.
Serialization_Info Noch nicht relevant - siehe Abschnit zu Serialisierung
102 April 2001

Exportparameter bei erfolgreicher IDoc-Verarbeitung
Exportparameter bei erfolgreicher IDoc-Verarbeitung

In diesem Beispiel wird angenommen, daß das IDoc mit der Nummer 4711 verarbeitet und der
Anwendungsbeleg mit der Nummer 1234 angelegt wurde.
Parameter Wert Beschreibung

In_Update_Task " " Verbuchungstask nicht
"X" verwendet
Verbuchungstask
verwendet
Call_Transaction_ " " (z.B. Initialwert)
Done
Workflow_Result "0"
Application_Varia " " (z.B. Initialwert)
ble
Idoc_Status Die Tabelle muß einen Satz enthalten,
dessen Felder enthalten müssen:
Docnum: 4711
Status:53
Optional können die Felder Msgid etc.
mit der Erfolgs- meldung der
Anwendung gefüllt werden.
Return_Variables Die Tabelle muß die folgenden beiden
Einträge enthalten:
Wf_param Doc_Number
"Processed_IDOCs" 4711
"Appl_Objects" 1234
Falls bei der Verarbeitung des
eingegangenen IDocs
ein Anwendungsobjekt weder erstellt
noch geändert
wurde, können Sie den Eintrag
"Appl_Objects"
weglassen. Ohne Belegnummer ist er
sinnlos.
Serialization_Info Leer
April 2001 103

Exportparameter bei fehlerhafter IDoc-Verarbeitung
Exportparameter bei fehlerhafter IDoc-Verarbeitung

In diesem Beispiel wird angenommen, daß das IDoc mit der Nummer 4711 verarbeitet wird.
Parameter Wert
In_Update_Task " " (z.B. Initialwert) -
Verbuchungstask nicht verwendet
Call_Transaction " " (z.B. Initialwert)
_Done
Workflow_Result "99999"
Application_Vari " "(z.B. Initialwert)
able
Idoc_Status Die Tabelle muß einen Satz
enthalten, deren Felder-
folgende Werte besitzen:
Docnum: 4711
Status: 51
Msgid, Msgno etc. müssen die
Kennung der Fehler-
meldung, Nummer etc. enthalten.
Return_Variable Die Tabelle muß folgenden Eintrag
s haben:
Wf_param Doc_Number
"Error_IDOCs" 4711
Serialization_Inf Leer
o
104 April 2001

Beispiel für die IDoc-Verarbeitung
Beispiel für die IDoc-Verarbeitung

Das Beispielprogramm für die IDoc-Verarbeitung [Seite 106] zeigt, wie der fiktive Nachrichtentyp
XAMPLE, der mit IDocs des Typs XAMPLE01 übermittelt wurde, mit dem
Eingangsfunktionsbaustein IDOC_INPUT_XAMPLE verarbeitet wird. Der IDoc-Typ besitzt das
Kopfsegment E1xhead und beliebig viele Item Segments E1xitem. Die Daten aus dem IDoc
werden in die beiden Datenbanktabellen XHEAD und XITEM geschrieben. XHEAD und XITEM
enthalten die gleichen Feldnamen wie E1xhead und E1xitem. Die folgende Tabelle zeigt die
Feldnamen und die Datentypen:
Feldname in XHEAD Bedeutung Typ in e1xhead Typ in xhead
DOCMNT_NO Belegnummer CHAR NUMC
DATE Datum CHAR DATS
CURRENCY Währung CHAR CUKY
COUNTRY Land CHAR CHAR
Feldname in XITEM Bedeutung Typ in e1xitem Typ in xitem

ITEM_NO Itemnummer CHAR NUMC
MATERIALID Materialnummer CHAR CHAR
DESCRIPT Materialbeschreibung CHAR CHAR
UNIT Maßeinheit CHAR UNIT
QUANTITY Menge CHAR QUAN
VALUE Value CHAR CURR
SHIP_INST Versandvorschriften CHAR UNIT
Den Daten in der Datenbank wird eine neue Belegnummer (Feld DOCMNT_NO) über die
Nummervergabe zugeordnet. DOCMNT_NO wird nicht in der neu angelegten TABELLE XHEAD
abgelegt.
April 2001 105

Beispielprogramm für die IDoc-Verarbeitung
FUNCTION IDOC_INPUT_XAMPLE.
*"---------------------------------------------------------------------
-
*"
*"Lokale Schnittstelle:
*" IMPORTING
*" VALUE(INPUT_METHOD) LIKE BDWFAP_PAR-INPUTMETHD
*" VALUE(MASS_PROCESSING) LIKE BDWFAP_PAR-MASS_PROC
*" EXPORTING
*" VALUE(WORKFLOW_RESULT) LIKE BDWF_PARAM-RESULT
*" VALUE(APPLICATION_VARIABLE) LIKE BDWF_PARAM-APPL_VAR
*" VALUE(IN_UPDATE_TASK) LIKE BDWFAP_PAR-UPDATETASK
*" VALUE(CALL_TRANSACTION_DONE) LIKE BDWFAP_PAR-CALLTRANS
*" TABLES
*" IDOC_CONTRL STRUCTURE EDIDC
*" IDOC_DATA STRUCTURE EDIDD
*" IDOC_STATUS STRUCTURE BDIDOCSTAT
*" RETURN_VARIABLES STRUCTURE BDWFRETVAR
*" SERIALIZATION_INFO STRUCTURE BDI_SER
*" EXCEPTIONS
*" WRONG_FUNCTION_CALLED
*"---------------------------------------------------------------------
-
* ---------------------------------------------------------------------
-
* ---------------------- 05 July 1996 ---------------------------------
-
* ---------------------------------------------------------------------
-
* Example function module for processing inbound IDocs for ALE or EDI.
* This example applies for processing
*
* with - one IDoc at a time
*
* without - serialization
* - customer-exits
* - calling an ALE-enabled transaction
* - mass processing (more than one IDoc at a time)
* -------------------- Naming conventions -----------------------------

-
* Internal tables start with 't_'
* Internal field strings start with 'f_'
* ---------------------------------------------------------------------
-
106 April 2001

* >> The following line must appear in the global part of your
* >> function group:
* include mbdconwf. "Report containing the ALE constants.
* The ALE constants start with 'c_'.
DATA: SUBRC LIKE SY-SUBRC,

OBJECT_NUMBER LIKE XHEAD-DOCMNT_NO.
* Initialize variables
SUBRC = 0.
* Read the IDoc's control record

READ TABLE IDOC_CONTRL INDEX 1.
* Process the IDoc and post the data to the database

PERFORM IDOC_PROCESS_XAMPLE TABLES IDOC_DATA
IDOC_STATUS
USING IDOC_CONTRL
CHANGING OBJECT_NUMBER
SUBRC.
* Fill the ALE export parameters

CLEAR IN_UPDATE_TASK.
CLEAR CALL_TRANSACTION_DONE. "Call Transaction is not used.
IF SUBRC <> 0. "Error occurred
WORKFLOW_RESULT = C_WF_RESULT_ERROR.
RETURN_VARIABLES-WF_PARAM = C_WF_PAR_ERROR_IDOCS.
RETURN_VARIABLES-DOC_NUMBER = IDOC_CONTRL-DOCNUM.
APPEND RETURN_VARIABLES.
ELSE. "IDoc processed successfully
WORKFLOW_RESULT = C_WF_RESULT_OK.
RETURN_VARIABLES-WF_PARAM = C_WF_PAR_PROCESSED_IDOCS.
RETURN_VARIABLES-WF_PARAM = C_WF_PAR_APPL_OBJECTS.
RETURN_VARIABLES-DOC_NUMBER = OBJECT_NUMBER.
ENDIF.
ENDFUNCTION.
*---------------------------------------------------------------------*
* FORM IDOC_PROCESS_XAMPLE *
*---------------------------------------------------------------------*
* This routine creates an application document based on the IDoc's *
* contents. Object_Number contains the new document's number. *
* If an error occurs, subrc is non-zero, t_idoc_status is filled. *
April 2001 107

* Note: if more than one error is detected, t_idoc_status contains *

* more than one status record. *
*---------------------------------------------------------------------*
* --> F_IDOC_CONTRL IDoc control record *
* --> T_IDOC_DATA IDoc data records *
* <-- T_IDOC_STATUS IDoc status records *
* <-- OBJECT_NUMBER Created document's number *
* <-- SUBRC Return code *
*---------------------------------------------------------------------*
FORM IDOC_PROCESS_XAMPLE
TABLES T_IDOC_DATA STRUCTURE EDIDD
T_IDOC_STATUS STRUCTURE BDIDOCSTAT
USING F_IDOC_CONTRL STRUCTURE EDIDC
CHANGING OBJECT_NUMBER LIKE XHEAD-DOCMNT_NO
SUBRC LIKE SY-SUBRC.
* Internal field string for the document header.

DATA: F_XHEAD LIKE XHEAD.
* Internal table for the document items.

DATA: T_XITEM LIKE XITEM OCCURS 0 WITH HEADER LINE.
* Number given to the created document

DATA: DOCUMENT_NUMBER LIKE F_XHEAD-DOCMNT_NO.
* Move the data in the IDoc to the internal structures/tables

* f_xhead and t_xitem.
PERFORM IDOC_INTERPRET TABLES T_IDOC_DATA
T_XITEM
T_IDOC_STATUS
USING F_IDOC_CONTRL
CHANGING F_XHEAD
SUBRC.
* Create the application object if no error occurred so far.

IF SUBRC = 0.
* This fictitious function module creates a new object based on the
* data that was read from the IDoc. The new object's ID is returned
* in the parameter 'document_number'.
* The function module checks that the data is correct, and raises
* an exception if an error is detected.
CALL FUNCTION 'XAMPLE_OBJECT_CREATE'
EXPORTING
XHEAD = F_XHEAD
IMPORTING
DOCUMENT_NUMBER = DOCUMENT_NUMBER
TABLES
XITEM = T_XITEM
EXCEPTIONS
OTHERS = 1.
IF SY-SUBRC <> 0.
108 April 2001

SUBRC = 1.
* Put the error message into 't_idoc_status'
PERFORM STATUS_FILL_SY_ERROR
TABLES T_IDOC_STATUS
USING T_IDOC_DATA
SY
'' "Field name
'idoc_process_xample'. "Form routine
ELSE.
* Fill the remaining export parameters
OBJECT_NUMBER = DOCUMENT_NUMBER. "New document's number
t_idoc_status-docnum = f_idoc_contrl-docnum.
t_idoc_status-status = c_idoc_status_ok.
t_idoc_status-msgty = 'S'.
t_idoc_status-msgid = your_msgid. "Global variable.
t_idoc_status-msgno = msgno_success."Global variable.
t_idoc_status-msgv1 = object_number.
APPEND T_IDOC_STATUS.
ENDIF. "if sy-subrc <> 0.
ENDIF. "if subrc = 0.
ENDFORM.
*---------------------------------------------------------------------*
* FORM IDOC_INTERPRET *
*---------------------------------------------------------------------*
* This routine checks that the correct message type is being used, *
* and then converts and moves the data from the IDoc segments to the *
* internal structure f_xhead and internal table t_xitem. *
* If an error occurs, t_idoc_status is filled an subrc <> 0. *
*---------------------------------------------------------------------*
* --> T_IDOC_STATUS *
* --> T_XITEM *
* --> F_IDOC_DATA *
* --> F_XHEAD *
* --> SUBRC *
*---------------------------------------------------------------------*
FORM IDOC_INTERPRET TABLES T_IDOC_DATA STRUCTURE EDIDD
T_XITEM STRUCTURE XITEM
CHANGING F_XHEAD STRUCTURE XHEAD
* Check that the IDoc contains the correct message type.

* Note: if your message-type is reducible, check field 'idoctp'
* (IDoc type) instead of 'mestyp'.
IF F_IDOC_CONTRL-MESTYP <> 'XAMPLE'.
MESSAGE ID YOUR_MSGID "Global variable
April 2001 109

TYPE 'E'
NUMBER MSGNO_WRONG_FUNCTION "Global variable
WITH F_IDOC_CONTRL-MESTYP "message type
'IDOC_INPUT_XAMPLE' "Your function module.
F_IDOC_CONTRL-SNDPRT "Sender partner type
F_IDOC_CONTRL-SNDPRN "Sender number.
RAISING WRONG_FUNCTION_CALLED.
ENDIF.
* Loop through the IDoc's segments and convert the data from the IDoc
* format to the internal format.
LOOP AT T_IDOC_DATA WHERE DOCNUM = F_IDOC_CONTRL-DOCNUM.
CASE T_IDOC_DATA-SEGNAM.
WHEN 'E1XHEAD'.
PERFORM E1XHEAD_PROCESS TABLES T_IDOC_STATUS
USING T_IDOC_DATA
CHANGING F_XHEAD
SUBRC.
WHEN 'E1XITEM'.
PERFORM E1XITEM_PROCESS TABLES T_XITEM
T_IDOC_STATUS
USING F_XHEAD-CURRENCY
T_IDOC_DATA
CHANGING SUBRC.
ENDCASE.
ENDLOOP.
ENDFORM.
*---------------------------------------------------------------------*
* FORM E1XHEAD_PROCESS *
*---------------------------------------------------------------------*
* This routine fills 'f_xhead' out of segment e1xhead. *
*---------------------------------------------------------------------*
* --> F_IDOC_DATA IDoc segment containing e1xhead fields *
* <-- F_XHEAD Internal structure containing doc. header *
* <-- T_IDOC_STATUS Status fields for error handling *
* <-- SUBRC Return code: non-zero if an error occurred *
*---------------------------------------------------------------------*
FORM E1XHEAD_PROCESS TABLES T_IDOC_STATUS STRUCTURE BDIDOCSTAT
USING F_IDOC_DATA STRUCTURE EDIDD
DATA: F_E1XHEAD LIKE E1XHEAD.
110 April 2001

F_E1XHEAD = F_IDOC_DATA-SDATA.
* Process fields that need conversion from ISO-codes to SAP-codes

PERFORM E1XHEAD_CODES_ISO_TO_SAP
USING F_E1XHEAD
F_IDOC_DATA
CHANGING F_XHEAD
SUBRC.
* Process fields containing dates or times

PERFORM E1XHEAD_DATE_TIME USING F_E1XHEAD
CHANGING F_XHEAD.
ENDFORM. "e1xhead_process
*---------------------------------------------------------------------*
* FORM E1XITEM_PROCESS *
*---------------------------------------------------------------------*
* This routine converts the data in the segment 'e1xitem' for *
* to the format of table 't_xitem' and appends it to the table. *
*---------------------------------------------------------------------*
* --> F_IDOC_DATA IDoc segment *
* <-- T_XITEM Document items to be updated to database *
* <-- T_IDOC_STATUS Status fields filled if an error occurred *
* <-- SUBRC Return code: 0 if all OK *
*---------------------------------------------------------------------*
FORM E1XITEM_PROCESS TABLES T_XITEM STRUCTURE XITEM
USING CURRENCY LIKE XHEAD-CURRENCY
F_IDOC_DATA STRUCTURE EDIDD
CHANGING SUBRC LIKE SY-SUBRC.
DATA: F_E1XITEM LIKE E1XITEM.
F_E1XITEM = F_IDOC_DATA-SDATA.
* Fields of type CHAR, NUMC, QUAN need no conversion.

T_XITEM-ITEM_NO = F_E1XITEM-ITEM_NO.
T_XITEM-MATERIALID = F_E1XITEM-MATERIALID.
T_XITEM-DESCRIPT = F_E1XITEM-DESCRIPT.
T_XITEM-QUANTITY = F_E1XITEM-QUANTITY.
* Process fields that need conversion from ISO-codes to SAP-codes

PERFORM E1XITEM_CODES_ISO_TO_SAP TABLES T_IDOC_STATUS
USING F_E1XITEM
F_IDOC_DATA
CHANGING T_XITEM
April 2001 111

SUBRC.
* Process fields that contain monetary values

PERFORM E1XITEM_VALUE_IDOC_TO_SAP TABLES T_IDOC_STATUS
USING F_E1XITEM
CURRENCY
F_IDOC_DATA
CHANGING T_XITEM
SUBRC.
APPEND T_XITEM.
ENDFORM.
*---------------------------------------------------------------------*
* FORM E1XHEAD_CODES_ISO_TO_SAP *
*---------------------------------------------------------------------*
* Converts ISO-Codes in f_e1xhead to SAP-codes in f_xhead. *
* f_idoc_data, t_idoc_status and subrc are used for error handling. *
*---------------------------------------------------------------------*
FORM E1XHEAD_CODES_ISO_TO_SAP
TABLES T_IDOC_STATUS STRUCTURE BDIDOCSTAT
USING F_E1XHEAD STRUCTURE E1XHEAD
SUBRC.
* f_xhead-currency Type CUKY => convert ISO-Code to SAP-Code.

PERFORM CURRENCY_CODE_ISO_TO_SAP
USING F_E1XHEAD-CURRENCY
F_IDOC_DATA
'CURRENCY'
CHANGING F_XHEAD-CURRENCY
SUBRC.
CHECK SUBRC = 0.
* f_xhead-country Contains a country => convert from ISO to SAP code.

PERFORM COUNTRY_CODE_ISO_TO_SAP
USING F_E1XHEAD-COUNTRY
F_IDOC_DATA
'COUNTRY'
CHANGING F_XHEAD-COUNTRY
SUBRC.
ENDFORM.
*---------------------------------------------------------------------*
* FORM E1XITEM_CODES_ISO_TO_SAP *
*---------------------------------------------------------------------*
* Converts ISO-Codes in f_e1xitem to SAP-codes in f_xitem *
112 April 2001


*---------------------------------------------------------------------*
FORM E1XITEM_CODES_ISO_TO_SAP
USING F_E1XITEM STRUCTURE E1XITEM
CHANGING F_XITEM STRUCTURE XITEM
* f_xitem-unit Type UNIT => convert ISO-Code to SAP-Code.

PERFORM UNIT_OF_MEASURE_ISO_TO_SAP
USING F_E1XITEM-UNIT
F_IDOC_DATA
'unit'
CHANGING F_XITEM-UNIT
SUBRC.
* f_xitem-ship_inst Contains shipping instructions => ISO to SAP code.

PERFORM SHIPPING_INSTRUCT_ISO_TO_SAP
USING F_E1XITEM-SHIP_INST
F_IDOC_DATA
'ship_inst'
CHANGING F_XITEM-SHIP_INST
SUBRC.
ENDFORM.
*---------------------------------------------------------------------*
* FORM E1XITEM_VALUE_IDOC_TO_SAP *
*---------------------------------------------------------------------*
* Converts fields containing monetary values in f_e1xitem to *
* the internal representation in f_xitem. *
*---------------------------------------------------------------------*
FORM E1XITEM_VALUE_IDOC_TO_SAP
USING F_E1XITEM STRUCTURE E1XITEM
CURRENCY LIKE XHEAD-CURRENCY
CHANGING F_XITEM STRUCTURE XITEM
* f_xitem-value Type CURR => convert IDoc amount to internal amount.

* N.B. the currency code used here must be the SAP-internal one, not
* the one contained in the IDoc!
CALL FUNCTION 'CURRENCY_AMOUNT_IDOC_TO_SAP'
EXPORTING
CURRENCY = CURRENCY
IDOC_AMOUNT = F_E1XITEM-VALUE
IMPORTING
April 2001 113

SAP_AMOUNT = F_XITEM-VALUE
EXCEPTIONS
OTHERS = 1.
IF SY-SUBRC <> 0.
SUBRC = 1.
USING F_IDOC_DATA
SY
'value' "Field name
'e1xitem_value_idoc_to_sap'. "Form routine
ENDFORM.
*---------------------------------------------------------------------*
* FORM E1XHEAD_DATE_TIME *
*---------------------------------------------------------------------*
* Moves date and time fields in f_e1xhead to the fields in f_xhead. *
*---------------------------------------------------------------------*
FORM E1XHEAD_DATE_TIME USING F_E1XHEAD STRUCTURE E1XHEAD
CHANGING F_XHEAD STRUCTURE XHEAD.
* f_xhead-date Type DATS => initial value is not 'blank'.

IF E1XHEAD-DATE IS INITIAL.
CLEAR F_XHEAD-DATE.
ELSE.
F_XHEAD-DATE = F_E1XHEAD-DATE.
ENDIF.
ENDFORM.
*---------------------------------------------------------------------*
* FORM CURRENCY_CODE_ISO_TO_SAP *
*---------------------------------------------------------------------*
* Converts ISO currency code 'iso_currency_code' to SAP code in *
* 'sap_currency_code' *
* f_idoc_data, field_name, t_idoc_status and subrc are used for *
* for error handling. *
*---------------------------------------------------------------------*
FORM CURRENCY_CODE_ISO_TO_SAP
USING ISO_CURRENCY_CODE LIKE TCURC-ISOCD
FIELD_NAME LIKE BDIDOCSTAT-SEGFLD
CHANGING SAP_CURRENCY_CODE LIKE TCURC-WAERS
IF ISO_CURRENCY_CODE IS INITIAL.
114 April 2001

CLEAR SAP_CURRENCY_CODE.
ELSE.
CALL FUNCTION 'CURRENCY_CODE_ISO_TO_SAP'
EXPORTING
ISO_CODE = ISO_CURRENCY_CODE
IMPORTING
SAP_CODE = SAP_CURRENCY_CODE
EXCEPTIONS
OTHERS = 1.
IF SY-SUBRC <> 0.
SUBRC = 1.
USING F_IDOC_DATA
SY
FIELD_NAME
'currency_code_iso_to_sap'. "Form routine
ENDIF. "if iso_currency_code is

initial.
ENDFORM.
*---------------------------------------------------------------------*
* FORM COUNTRY_CODE_ISO_TO_SAP *
*---------------------------------------------------------------------*
* Converts ISO country code 'iso_country_code' to SAP code in *
* 'sap_country_code' *
*---------------------------------------------------------------------*
FORM COUNTRY_CODE_ISO_TO_SAP
USING ISO_COUNTRY_CODE LIKE T005-INTCA
CHANGING SAP_COUNTRY_CODE LIKE T005-LAND1
* Only convert if the field is not initial.

IF ISO_COUNTRY_CODE IS INITIAL.
CLEAR SAP_COUNTRY_CODE.
ELSE.
CALL FUNCTION 'COUNTRY_CODE_ISO_TO_SAP'
EXPORTING
ISO_CODE = ISO_COUNTRY_CODE
IMPORTING
SAP_CODE = SAP_COUNTRY_CODE
EXCEPTIONS
April 2001 115

OTHERS = 1.
IF SY-SUBRC <> 0.
SUBRC = 1.
USING F_IDOC_DATA
SY
FIELD_NAME
'country_code_iso_to_sap'. "Form routine
ENDIF. "if iso_country_code is initial.
ENDFORM.
*---------------------------------------------------------------------*
* FORM UNIT_OF_MEASURE_ISO_TO_SAP *
*---------------------------------------------------------------------*
* Converts ISO unit of measure code 'iso_unit_of_measure' to SAP *
* code in 'sap_unit_of_measure'. *
*---------------------------------------------------------------------*
FORM UNIT_OF_MEASURE_ISO_TO_SAP
USING ISO_UNIT_OF_MEASURE LIKE T006-ISOCODE
CHANGING SAP_UNIT_OF_MEASURE LIKE T006-MSEHI
* Only convert the field if it is not empty.

IF ISO_UNIT_OF_MEASURE IS INITIAL.
CLEAR SAP_UNIT_OF_MEASURE.
ELSE.
CALL FUNCTION 'UNIT_OF_MEASURE_ISO_TO_SAP'
EXPORTING
ISO_CODE = ISO_UNIT_OF_MEASURE
IMPORTING
SAP_CODE = SAP_UNIT_OF_MEASURE
EXCEPTIONS
OTHERS = 1.
IF SY-SUBRC <> 0.
SUBRC = 1.
USING F_IDOC_DATA
SY
FIELD_NAME
116 April 2001

'unit_of_measure_iso_to_sap'. "Form routine

ENDIF. "if iso_unit_of_measure_code is initial.
ENDFORM.
*---------------------------------------------------------------------*
* FORM SHIPPING_INSTRUCT_ISO_TO_SAP *
*---------------------------------------------------------------------*
* Converts ISO package code 'iso_package_type' to SAP code for *
* purchasing shipping instructions in 'sap_shipping_instructions'. *
*---------------------------------------------------------------------*
FORM SHIPPING_INSTRUCT_ISO_TO_SAP
USING ISO_PACKAGE_TYPE LIKE T027A-IVERS
CHANGING SAP_SHIPPING_INSTRUCTIONS LIKE T027A-EVERS
* Only convert the field if it is not empty.

IF ISO_PACKAGE_TYPE IS INITIAL.
CLEAR SAP_SHIPPING_INSTRUCTIONS.
ELSE.
CALL FUNCTION 'ISO_TO_SAP_PACKAGE_TYPE_CODE'
EXPORTING
ISO_CODE = ISO_PACKAGE_TYPE
IMPORTING
SAP_CODE = SAP_SHIPPING_INSTRUCTIONS
EXCEPTIONS
OTHERS = 1.
IF SY-SUBRC <> 0.
SUBRC = 1.
USING F_IDOC_DATA
SY
FIELD_NAME
'shipping_instruct_iso_to_sap'. "Form rout.
ENDIF. "if iso_unit_of_measure_code is initial.
ENDFORM.
*---------------------------------------------------------------------*
* FORM STATUS_FILL_SY_ERROR *
April 2001 117

*---------------------------------------------------------------------*
* Fills the structure t_idoc_status with the import parameters *
* plus the relevant sy fields. *
*---------------------------------------------------------------------*
* --> IDOC_NUMBER IDoc number *
* --> SEGNUM Segment number *
* --> SEGFLD Field in segment *
* --> ROUTID Name of routine *
* <-- T_IDOC_STATUS Status fields *
*---------------------------------------------------------------------*
FORM STATUS_FILL_SY_ERROR TABLES T_IDOC_STATUS STRUCTURE BDIDOCSTAT
USING F_IDOC_DATA STRUCTURE EDIDD
VALUE(F_SY) STRUCTURE SY
SEGFLD LIKE BDIDOCSTAT-SEGFLD
ROUTID LIKE BDIDOCSTAT-
ROUTID.
t_idoc_status-docnum = f_idoc_data-docnum.
t_idoc_status-status = c_idoc_status_error.
t_idoc_status-msgty = f_sy-msgty.
t_idoc_status-msgid = f_sy-msgid.
T_IDOC_STATUS-MSGNO = F_SY-MSGNO.
t_idoc_status-msgv1 = f_sy-msgv1.
t_idoc_status-segnum = f_idoc_data-segnum.
t_idoc_status-segfld = segfld.
t_idoc_status-repid = f_sy-repid.
t_idoc_status-routid = routid.
ENDFORM.
118 April 2001

Serialisierung über Nachrichtentypen

Der ALE-Funktionsbaustein SERIALIZATION_CHECK kennzeichnet jedes übernommene IDoc.
Ein übernommenes IDoc ist wie folgt definiert: angenommen, die IDocs A und B enthalten
Informationen über Objekt/Beleg X (z.B. Auftragsnummer 4711). Wenn A vom sendenden R/3-
System vor B angelegt wird, B aber bereits erfolgreich vom empfangenden R/3-System
verarbeitet wurde, dann bezeichnet man A als übernommenes IDoc.
Um die Serialisierung zu nutzen, müssen Sie
· das Serialisierungsobjekt für Ihren Nachrichtentyp definieren - ALE extrahiert die Objekt-
/Belegnummer aus dem Datensegment des IDocs, muß folglich wissen, welches Feld
verwendet werden soll,
· den Funktionsbaustein SERIALIZATION_CHECK am Anfang des Funktionsbausteins im
Eingang aufrufen,
· auf übernommene IDocs je nach Bedarf reagieren,
· sicherstellen, daß die "Export"-Tabelle Serialization_Info des Funktionsbausteins im Eingang
die Serialisierungstabelle aus dem Funktionsbaustein SERIALIZATION_CHECK enthält
(siehe Beispiel unten).
Das Beispielprogramm für die Serialisierung [Seite 120] zeigt das zusätzliche
Coding, das im Funktionsbaustein IDOC_INPUT_XAMPLE erforderlich ist, um
übernommene IDocs zu erkennen und eine entsprechende Fehlermeldung
zurückzugeben. Im Beispiel wird angenommen, daß übernommene IDocs manuell
behandelt werden müssen, d.h., sie können nicht automatisch verarbeitet werden
April 2001 119

Beispielprogramm für die Serialisierung
FUNCTION IDOC_INPUT_XAMPLE2.
*"---------------------------------------------------------------------
-
*"
*" IMPORTING
*" EXPORTING
*" TABLES
*" EXCEPTIONS
*"---------------------------------------------------------------------
-
* ---------------------------------------------------------------------
-
* ---------------------- 05 July 1996 ---------------------------------
-
* ---------------------------------------------------------------------
-
*
* - serialization
*
* without - customer-exits

-
* ---------------------------------------------------------------------
-
120 April 2001


SUBRC = 0.

PERFORM IDOC_PROCESS_XAMPLE2 TABLES IDOC_DATA

SERIALIZATION_INFO
IDOC_STATUS
USING IDOC_CONTRL
SUBRC.
* In this example we assume that 'call function 'xxx' in update task'

is
* not used to update the database.
ENDIF.
ENDFUNCTION.
*---------------------------------------------------------------------*
* FORM IDOC_PROCESS_XAMPLE2 *
April 2001 121

*---------------------------------------------------------------------*
*---------------------------------------------------------------------*
*---------------------------------------------------------------------*
FORM IDOC_PROCESS_XAMPLE2
T_SERIALIZATION_INFO STRUCTURE BDI_SER




PERFORM IDOC_INTERPRET2 TABLES T_IDOC_DATA
T_SERIALIZATION_INFO
T_XITEM
T_IDOC_STATUS
USING F_IDOC_CONTRL
CHANGING F_XHEAD
SUBRC.

IF SUBRC = 0.
EXPORTING
XHEAD = F_XHEAD
IMPORTING
122 April 2001

TABLES
XITEM = T_XITEM
EXCEPTIONS
OTHERS = 1.
IF SY-SUBRC <> 0.
SUBRC = 1.
USING T_IDOC_DATA
SY
'' "Field name
ELSE.
ENDFORM.
*---------------------------------------------------------------------*
* FORM IDOC_INTERPRET2 *
*---------------------------------------------------------------------*
* then checks that the IDoc has not been overtaken (serialization), *
*---------------------------------------------------------------------*
* --> T_XITEM *
* --> F_IDOC_DATA *
* --> F_XHEAD *
* --> SUBRC *
*---------------------------------------------------------------------*
FORM IDOC_INTERPRET2 TABLES T_IDOC_DATA STRUCTURE EDIDD
T_SERIALIZATION_INFO STRUCTURE BDI_SER
April 2001 123


DATA: BEGIN OF T_IDOC_CONTRL OCCURS 1.

INCLUDE STRUCTURE EDIDC.
DATA: END OF T_IDOC_CONTRL.
APPEND F_IDOC_CONTRL TO T_IDOC_CONTRL.


TYPE 'E'
ENDIF.
* >>>>>>>>>>>>> Serialization check (Start)

<<<<<<<<<<<<<<<<<<<<<<<<<<<<
APPEND F_IDOC_CONTRL TO T_IDOC_CONTRL.
CALL FUNCTION 'IDOC_SERIALIZATION_CHECK'

TABLES
IDOC_SERIAL = T_SERIALIZATION_INFO
IDOC_DATA = T_IDOC_DATA
IDOC_CONTROL = T_IDOC_CONTRL
EXCEPTIONS
OTHERS = 1.
IF SY-SUBRC <> 0.
SUBRC = 1.
* Put the error message into 'idoc_status'
USING T_IDOC_DATA
SY
'materialid' "Field name
'e1xitem_process'. "Form routine
EXIT. "Leave the routine.
* Get the serialization info for your IDoc.

READ TABLE T_SERIALIZATION_INFO
124 April 2001

WITH KEY DOCNUM = F_IDOC_CONTRL-DOCNUM.
* Check whether the IDoc has been flagged as having been overtaken.
IF NOT T_SERIALIZATION_INFO-SERFLAG IS INITIAL.
* IDoc has been overtaken: in this example, flag as an error and
quit.
SUBRC = 1.
t_idoc_status-status = c_idoc_status_error.
t_idoc_status-msgty = 'E'.
T_IDOC_STATUS-MSGID = YOUR_MSGID. "Global variable
T_IDOC_STATUS-MSGNO = MSGNO_IDOC_OVERTAKEN. "Global variable
EXIT. "Leave the routine.
ENDIF. "if not t_serialization_info-serflag is initial.
* >>>>>>>>>>>>> Serialization check (End)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
WHEN 'E1XHEAD'.
USING T_IDOC_DATA
CHANGING F_XHEAD
SUBRC.
WHEN 'E1XITEM'.
T_IDOC_STATUS
T_IDOC_DATA
CHANGING SUBRC.
ENDCASE.
ENDLOOP.
ENDFORM.
April 2001 125

Customer-Exits
Customer-Exits
Customer-Exits im Funktionsbaustein im Eingang erlauben dem Benutzer:
· die Verarbeitung der SAP-Segmente zu beeinflussen, z.B. durch Ändern von Feldwerten.
· auf die Kundensegmente zuzugreifen, die sie über das IDoc-Definitionswerkzeug dem SAP-
IDoc hinzugefügt haben.
Die Customer-Exits sollten folgende Kriterien erfüllen:

· Können alle Daten in SAP-Segmenten im IDoc über Customer-Exits gelesen werden?
· Können alle Kundensegmente im IDoc über Customer-Exits gelesen werden?
· Wird ein Customer-Exit jedes Mal gelesen, wenn ein Segment verarbeitet wurde?
· Unterstützt der Customer-Exit Fehlerbehandlung?
· Kann der Exit die Parameter Workflow_Result, Idoc_Status und Return_Variables mit Werten
versorgen?
· Gibt es einen Customer-Exit für die Serialisierung?
· Dies ist sinnvoll, wenn der Funktionsbaustein im Eingang keine Serialisierung unterstützt.
· Wenn der Kunde Felder an SAP-Tabellen angehängt hat, können im Exit leicht auf diese
Felder zugegriffen werden?
· Sind die Exits langlebig? Kunden erwarten, daß die Exits auch in zukünftigen Releases mit
der gleichen Bedeutung aufrufbar sind.
· Kann der Kunde leicht durch die Daten im Exit navigieren? Um beispielsweise festzustellen,
welcher Posten zur Zeit verarbeitet wird, etc.
· Bei Verwendung des gleichen Codings für verschiedene Nachrichtentypen: Kann der Kunde
erkennen, welcher Nachrichtentyp verwendet wird?
Das Beispielprogramm für einen Customer-Exit [Seite 127] dient als Vorlage für die
Implementation eines Customer-Exits.
126 April 2001

Beispielprogramm für einen Customer-Exit
*"---------------------------------------------------------------------
-
*"
*" IMPORTING
*" EXPORTING
*" TABLES
*" EXCEPTIONS
*"---------------------------------------------------------------------
-
* ---------------------------------------------------------------------
-
* --------------------------- 05 July 1996 ----------------------------
-
* ---------------------------------------------------------------------
-
*
* - serialization
* - customer-exits
*
* without - calling an ALE-enabled transaction

-
* ---------------------------------------------------------------------
-
April 2001 127


SUBRC = 0.

* >>>>>>>>>>>>> Customer exit 1 (Start)

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
* This exit gives the customer access to the IDoc's control record,
* the import parameters and allows the customer to do serialization.
CALL CUSTOMER-FUNCTION '001'
EXPORTING
INPUT_METHOD = INPUT_METHOD
MASS_PROCESSING = MASS_PROCESSING
TABLES
IDOC_SERIAL = SERIALIZATION_INFO
IDOC_DATA = IDOC_DATA
IDOC_CONTROL = IDOC_CONTRL
EXCEPTIONS
OTHERS = 1.
IF SY-SUBRC <> 0.
SUBRC = 1.
PERFORM STATUS_FILL_SY_ERROR TABLES IDOC_STATUS
USING IDOC_DATA
SY
' '
'customer-function 001'.
ENDIF.
* >>>>>>>>>>>>> Customer exit 1 (End)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

IDOC_STATUS
USING IDOC_CONTRL
SUBRC.
* In this example we assume that 'call function 'xxx' in update task'

is
* not used to update the database.
128 April 2001

ENDIF.

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
* This exit gives the customer access to the export parameters.
EXPORTING
SUBRC = SUBRC
WORKFLOW_RESULT_IN = WORKFLOW_RESULT
APPLICATION_VARIABLE_IN = APPLICATION_VARIABLE
IN_UPDATE_TASK_IN = IN_UPDATE_TASK
IMPORTING
WORKFLOW_RESULT_OUT = WORKFLOW_RESULT
APPLICATION_VARIABLE_OUT = APPLICATION_VARIABLE
IN_UPDATE_TASK_OUT = IN_UPDATE_TASK
TABLES
RETURN_VARIABLES = RETURN_VARIABLES.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
ENDFUNCTION.
*---------------------------------------------------------------------*
*---------------------------------------------------------------------*
*---------------------------------------------------------------------*
April 2001 129


*---------------------------------------------------------------------*




PERFORM IDOC_INTERPRET3 TABLES T_IDOC_DATA
T_XITEM
T_IDOC_STATUS
USING F_IDOC_CONTRL
CHANGING F_XHEAD
SUBRC.

IF SUBRC = 0.
EXPORTING
XHEAD = F_XHEAD
IMPORTING
TABLES
XITEM = T_XITEM
EXCEPTIONS
OTHERS = 1.
IF SY-SUBRC <> 0.
SUBRC = 1.
USING T_IDOC_DATA
130 April 2001

SY
'' "Field name
ELSE.
ENDFORM.
*---------------------------------------------------------------------*
* FORM IDOC_INTERPRET3 *
*---------------------------------------------------------------------*
* then checks that the IDoc has not been overtaken (serialization), *
*---------------------------------------------------------------------*
* --> T_XITEM *
* --> F_IDOC_DATA *
* --> F_XHEAD *
* --> SUBRC *
*---------------------------------------------------------------------*
FORM IDOC_INTERPRET3 TABLES T_IDOC_DATA STRUCTURE EDIDD


TYPE 'E'
April 2001 131


ENDIF.
WHEN 'E1XHEAD'.
USING T_IDOC_DATA
CHANGING F_XHEAD
SUBRC.
WHEN 'E1XITEM'.
T_IDOC_STATUS
T_IDOC_DATA
CHANGING SUBRC.
ENDCASE.

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
* This exit is called after each SAP segment has been processed, and
* it is called every time a customer segment appears.
EXPORTING
CURRENT_SEGEMENT = T_IDOC_DATA
XHEAD_IN = F_XHEAD
SUBRC_IN = SUBRC
IMPORTING
XHEAD_OUT = F_XHEAD
TABLES
XITEM = T_XITEM
EXCEPTIONS
OTHERS = 1.
IF SY-SUBRC <> 0.
SUBRC = 1.
PERFORM STATUS_FILL_SY_ERROR TABLES T_IDOC_STATUS
USING T_IDOC_DATA
SY
' '
'customer-function 001'.
ENDIF.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
132 April 2001

ENDLOOP.
ENDFORM.
April 2001 133

Massenverarbeitung
Massenverarbeitung
Die gleichzeitige Verarbeitung von mehreren IDocs aus folgenden Gründen den Durchsatz
verbessern:
· es werden mehr als ein IDoc pro Commit Work verarbeitet.
· die Funktion kann so kodiert werden, daß mit einem Aktualisierungsbefehl ("array insert")
mehrere Einträge in einer Tabelle hinzugefügt werden.
Siehe auch:
Import-Parameter [Seite 135]
Export-Parameter [Seite 136]
Beispielprogram für die IDoc-Massenverarbeitung [Seite 141]
134 April 2001

Import-Parameter
Import-Parameter
Die Import-Parameter haben die gleiche Bedeutung wie bei der Verarbeitung eines einzelnen
IDocs. Die Tabelle Idoc_Contrl kann jedoch Steuersätze von mehr als einem IDoc und Idoc_Data
die Datensätze von mehr als einem IDoc enthalten.
April 2001 135

Export-Parameter
Export-Parameter
Die Export-Parameter müssen mit fast den gleichen Werten wie bei der Verarbeitung eines
einzelnen IDoc versorgt werden. Einige der IDocs können erfolgreich verarbeitet werden, andere
hingegen können mit Fehlern behaftet sein.
Das folgende Beispiel verdeutlicht, wie Sie die Export-Parameter füllen müssen. In jedem Fall
werden drei IDocs mit den Nummern 4711, 4712 und 4713 an den Funktionsbaustein im Eingang
übergeben. Im ersten Fall werden alle IDocs erfolgreich verarbeitet und die
Anwendungsbelegnummer 1234, 1235 und 1236 angelegt. Im zweiten Fall werden das erste und
dritte IDoc erfolgreich verarbeitet, während das zweite IDoc einen Fehler verursacht.
Erfolgreicher Eingang für alle IDocs [Seite 137]

Fehlerhafter Eingang eines IDocs [Seite 139]
136 April 2001

Erfolgreicher Eingang für alle IDocs

Wenn alle IDocs erfolgreich verarbeitet wurden, sollten die Export-Parameter gemäß der
folgenden Tabelle versorgt werden.
Werte für Export-Parameter, wenn IDocs im Paket erfolgreich verarbeitet werden. IDoc-
Nummern 4711 - 4713 haben Anwendungsobjektnummern 1234 - 1236 angelegt.
Parameter Wert
verwendet
"X" Verbuchungstask verwendet
Call_Transactio " "
n_Done
Workflow_Resul "0"
t
Application_Vari " " (z.B. Initialwert)
able
Idoc_Status Die Tabelle muß drei Sätze
enthalten, deren Felder wie folgt
gefüllt sind:
Docnum Status
4711 53
4712 53
4713 53
Optional können die Felder Msgid
etc. die Erfolgsmeldung der
Anwendung enthalten.
Return_Variable Die Tabelle muß die folgenden
s sechs Einträge enthalten:
Wf_param Doc_Number
"Appl_Objects" 1234
"Appl_Objects" 1235
"Appl_Objects" 1236
April 2001 137

Wenn bei der Verarbeitung des

eingegangenen IDocs weder ein
Anwendungsobejkt anlegt oder
ändert, können Sie den Eintrag
"Appl_Objects" weglassen - ohne
Belegnummer ist er sinnlos.
Serialization_Inf Leer, wenn Serialisierung nicht
o verwendet wird
138 April 2001

Fehlerhafter Eingang eines IDocs

Verursacht eines der drei IDocs einen Fehler, sollten die Export-Parameter wie folgt versorgt
werden:
Werte für die Export-Parameter, wenn IDocs im Paket verarbeitet werden, wobei lediglich
IDoc-Nr. 4712 fehlerhaft ist. IDoc-Nummern 4711 und 4713 legen
Anwendungsobjektnummern 1234 und 1235 an.
Parameter Wert
Call_Transactio " " (z.B. Initialwert)
n_Done
Workflow_Resul "99999"
t
able
enthalten, deren Felder folgende
Werte haben:
Docnum Status
4711 53
4712 51
4713 53
Die Felder Msgid etc. des
Statussatzes für IDoc 4712 müssen
die Fehlermeldung enthalten.
Return_Variable Die Tabelle muß die folgenden fünf
s Einträge enthalten:
Wf_param Doc_Number
"Appl_Objects" 1234
"Error_IDOCs" 4712
"Appl_Objects" 1235
April 2001 139


Anwendungsobejkt anlegt oder
ändert, können Sie den Eintrag
Serialization_Inf Leer, wenn Serialisierung nicht
o verwendet wird
140 April 2001

Beispielprogram für die IDoc-Massenverarbeitung
*"---------------------------------------------------------------------
-
*"*"Lokale Schnittstelle:
*" IMPORTING
*" EXPORTING
*" TABLES
*" EXCEPTIONS
*"---------------------------------------------------------------------
-
* ---------------------------------------------------------------------
-
* ---------------------- 05 July 1996 ---------------------------------
-
* ---------------------------------------------------------------------
-
*
* with - mass processing (more than one IDoc at a time)
*
* without - serialization
* - customer-exits

-
* ---------------------------------------------------------------------
-
April 2001 141


* Internal table for the document headers.

DATA: T_XHEAD LIKE XHEAD OCCURS 0 WITH HEADER LINE.


SUBRC = 0.
* Fill the ALE export parameters prior to loop through IDocs.

* Loop through the IDocs' control records

LOOP AT IDOC_CONTRL.
* Process the IDoc and check the data; no database updates!

IDOC_STATUS
t_xhead
t_xitem
USING IDOC_CONTRL
SUBRC.
* Fill the ALE export parameters.

ENDIF.
ENDLOOP. "loop at idoc_contrl.
142 April 2001

* Once all IDocs have been processed, insert the application data to
* the database (as long as there is some data to insert).
read table t_xitem index 1.

if sy-subrc = 0. "i.e. at least one entry
* This fictitious function module inserts the data in tables

* t_xhead and t_xitem to the database tables xhead and xitem.
* It has no exceptions, because a failed insert leads to a run-time
* error.
CALL FUNCTION 'XAMPLE_OBJECTS_INSERT_TO_DATABASE'
TABLES
XHEAD = T_XHEAD
XITEM = T_XITEM.
endif. "if sy-subrc = 0.
ENDFUNCTION.
*---------------------------------------------------------------------*
*---------------------------------------------------------------------*
* This routine adds an application document to tables t_xhead and *
* t_xitem based on the IDoc'S contents. *
* Object_Number contains the new document's number. *
*---------------------------------------------------------------------*
* <-- T_XHEAD Application document's header records *
* <-- T_XITEM Application document's line item records *
*---------------------------------------------------------------------*
T_XHEAD STRUCTURE XHEAD
* Internal table string for the document headers.

DATA: F_XHEAD LIKE XHEAD OCCURS 0 WITH HEADER LINE.
* Internal table for one document's items.

DATA: T_ONE_XITEM LIKE XITEM OCCURS 0 WITH HEADER LINE.
April 2001 143


DATA: DOCUMENT_NUMBER LIKE XHEAD-DOCMNT_NO.

PERFORM IDOC_INTERPRET TABLES T_IDOC_DATA
T_ONE_XITEM
T_IDOC_STATUS
USING F_IDOC_CONTRL
CHANGING F_XHEAD
SUBRC.

IF SUBRC = 0.
* This fictitious function module checks the new object based on the
* data that was read from the IDoc.
* If the checks succeed, the new object's ID is returned in the
* parameter 'document_number'.
* If the checks fail, an exception is raised.
* Note: this function must not insert or modify database records!
CALL FUNCTION 'XAMPLE_OBJECT_CHECK'
EXPORTING
XHEAD = F_XHEAD
IMPORTING
TABLES
XITEM = T_ONE_XITEM
EXCEPTIONS
OTHERS = 1.
IF SY-SUBRC <> 0.
SUBRC = 1.
USING T_IDOC_DATA
SY
'' "Field name
ELSE.
append f_xhead to t_xhead.
APPEND LINES OF T_ONE_XITEM TO T_XITEM.
144 April 2001

ENDFORM.
April 2001 145

Call Transaction einsetzen
Call Transaction einsetzen

Im allgemeinen sollten Sie die Datenbank mit Funktionsbausteinen anstatt mit einer Call
Transaction aktualisieren; eine Call Transaction hat erhebliche Auswirkungen auf die
Performance. Der Vorteil einer Call Transaction ist jedoch, daß der Benutzer das IDoc erneut
verarbeiten kann, indem er die Eingabebildschirme der Transaktion durchläuft.
Wenn Sie einen Funktionsbaustein für die oben beschriebene Verarbeitung eines einzelnen
IDocs implementieren, dabei der Funktionsbaustein jedoch eine Call Transaction zur Verbuchung
der Anwendungsdaten verwendet, werden die Anwendungsdaten in einer anderen LUW verbucht
als die, in der die IDoc-Statusdaten verbucht werden - eine Call Transaction schreibt bei
erfolgreicher Ausführung die Daten auf der Datenbank fest. (Siehe auch Eine LUW
gewährleisten.
Um dieses Problem zu lösen, sollten Sie die Transaktion modifizieren, damit sie die IDoc-
Statusdaten aktualisiert, wenn die Anwendungsdaten verbucht werden, d.h., das IDoc erfolgreich
verarbeitet wurde. Hinweis: Die gilt nur für erfolgreich verarbeitete IDocs; Fehler werden wie
oben beschrieben behandelt.
Siehe auch:
ALE-fähige Transaktionen [Seite 147]
Call Transaction erfolgreich [Seite 149]
Call Transaction scheitert [Seite 151]
Import-Parameter bei CALL TRANSACTION [Seite 152]
Export-Parameter bei CALL TRANSACTION [Seite 153]
146 April 2001

ALE-fähige Transaktionen
Eine Transaktion ist “ALE-fähig”, wenn sie die folgenden Kriterien erfüllt:
· Am Anfang des PBO-Modules des ersten Bildes muß sie die IDoc-Nummer aus einer
Memory-Variablen lesen und den ALE-Funktionsbaustein Idoc_Input_Open aufrufen und
ihm die IDoc-Nummer übergeben (Parameter Document_Number).
· Bevor die Daten in der Datenbank aktualisiert werden, muß die Transaktion den ALE-
Funktionsbaustein Idoc_Input_Close aufrufen. Dieser Funktionsbaustein darf nicht aus
einem Funktionsbaustein aufgerufen werden, der in der Verbuchungstask verarbeitet wird,
z.B. "Call Function "xxx" In Update Task". Stattdessen sollte er direkt vor oder nach den
anderen Verbuchungsfunktionsbausteine "xxx". Das liegt daran, daß er auf globale Daten
zurückgreift, die von Idoc_Input_Open geschrieben wurden.
Idoc_Input_Close schreibt den IDoc Status in dem gleichen Verbuchungstask wenn der
Schnittstellenparameter In_Update_Task auf "X" gesetzt wird.
Beispiel Datanbankupdatecoding:
- call function ""UPDATE_APPL_TABLES " in update task tables...
- call function "IDOC_INPUT_CLOSE" exporting...
- commit work.
Die Parameter des Funktionbausteins Idoc_Input_Close muß mit folgenden Werten versorgt
sein:
Werte für Import- und Tabellenparameter des Funktionbausteins Idoc_Input_Close.
Parameter Wert
Workflow_Res "0"
ult
Application_Va " " (z.B. Initialwert)
riable
In_Update_Tas " " Die Transaktion verwendet nicht
k die
Verbuchungstask
"X" Die Transaktion verwendet die
Verbuchungstask
Idoc_Control Inhalt des Export-Parameters
Idoc_Control von Idoc_Input_Open
Idoc_Status Die Tabelle muß einen Satz enthalten,
dessen Felder folgende Werte hat:
Docnum: 4711
Status:53
Optional können die Felder Msgid etc.
die Erfolgsmeldung der Anwendung
enthalten.
April 2001 147

Return_Variabl Die Tabelle muß die folgenden beiden

es Einträge enthalten:
Wf_param Doc_Number
"Appl_Objects" 1234
Anwendungsobjekt angelegt oder
geändert wird, können Sie den Eintrag
Serialization_In Der Inhalt des Tabellenparameters
fo "Serialization_Info" von
Idoc_Input_Open.
148 April 2001

Call Transaction erfolgreich

Der Funktionsbaustein im Eingang, der eine ALE-fähige Transaktion verwendet, muß die IDoc-
Nummer der Memory-Variablen der Transaktion vor Aufruf der Transaktion übergeben.
ALE-Schicht Anwendungs- Transaktion

funktionsbaustein
Kontext 1 Kontext 2
IDoc(s) lesen
IDoc-Daten
Call Transaction-Tabelle
IDoc-Nr. in Memory
IDoc sperren
Optional:
Anwendungsobjekte
Transaktionsdaten
Anwendungsdaten in DB
Links schreiben
Optional:
Serialisierungsdaten
Ereignis(se)
Commit Work
IDoc und
automatisch entsperrt
Eingangsverarbeitung über eine ALE-fähige Transaktion: Transaktion erfolgreich.
· Der Code der Transaktion wird separat von der ALE-Schicht und dem
Funktionsbaustein im Eingang in einem eigenen Kontext verarbeitet.
April 2001 149

· die schattierten Kästen stehen für die ALE-Funktionsbausteine

Idoc_Input_Open (oben) und Idoc_Input_Close (unten).
Wie können Sie herausfinden, ob die Call Transaction erfolgreich

ausgeführt wurde?
Man sollte annehmen, daß die Call Transaction erfolgreich war, wenn nach dem Aufruf "Sy-
Subrc = 0". In einer ALE-Umgebung ist das jedoch nur die eine Seite der Medaille, denn wenn
der Import-Parameter Input_Method den Wert "A" oder "E" annimmt, muß der Funktionsbaustein
im Eingang die Transaktion mit Imode = "A" oder "E" aufrufen ("show all screens" oder "show the
screens starting with the one where the error occurred"). In diesem Fall sieht der Benutzer die
Bilder und kann die Transaktion mit /n im Befehlsfeld abbrechen, was ebenso zu dem Ergenis
"Sy-Subrc = 0" nach dem Aufruf führt! Um verläßlich festzustellen, ob die Call Transaction
erfolgreich war oder nicht, müssen Sie die Nachrichtenkennung (Sy-Msgid) und -nummer (Sy-
Msgno) überprüfen. Beachten Sie bitte, daß einige Transaktionen mehr als eine Erfolgsmeldung
haben.
150 April 2001

Call Transaction scheitert
Call Transaction scheitert

Die folgende Abbildung zeigt das Zusammenspiel von ALE-Schicht, Funktionsbaustein im
Eingang und Transaktion, wenn die Call Transaction fehlschlägt, d.h., wenn "Sy-Subrc" <> 0
oder "Sy-Subrc" = 0 ist und keine Erfolgsmeldung zurückgegeben wird.
Eingangsverarbeitung über eine ALE-fähige Transaktion: Transaktion scheitert.
ALE-Schicht Anwendungs- Transaktion

funktionsbaustein
Kontext 1 Kontext 2
IDoc(s) lesen
IDoc-Daten verarbeiten
Call Transaction-Tabelle
IDoc-Nr. in Memory
IDoc sperren
Optional:
Anwendungsobjekte
Fehlermeldung
IDoc und
automatisch
IDoc(s) sperren
Links schreiben
Optional:
Ereignis(se)
Commit Work
IDoc(s) entsperren
April 2001 151

Import-Parameter bei CALL TRANSACTION
Import-Parameter bei CALL TRANSACTION

Die Import-Parameter haben die gleiche Bedeutung wie bei der Verarbeitung einzelner IDocs.
152 April 2001

Export-Parameter bei CALL TRANSACTION
Export-Parameter bei CALL TRANSACTION

Siehe auch:
Eingang erfolgreich [Seite 154]
Eingang fehlerhaft [Seite 155]
April 2001 153

Eingang erfolgreich
Eingang erfolgreich
War die Call Transaction erfolgreich, müssen die Export-Parameter des Funktionsbausteins im
Eingang wie folgt mit Werten versehen werden:
Werte für die Export-Parameter bei der Verarbeitung eines einzelnen IDoc über eine ALE-
fähige Call Transaction, wobei das IDoc erfolgreich verarbeitet wurde.
Parameter Wert
In_Update_Task " " (z.B. Initialwert)
Call_Transaction_Done "X"
Workflow_Result "0"
Application_Variable " " (z.B. Initialwert)
Idoc_Status Leer
Return_Variables Leer
Serialization_Info Leer
154 April 2001

Eingang fehlerhaft
Eingang fehlerhaft
Ist die Call Transaction gescheitert, müssen die Export-Parameter wie bei der Verarbeitung eines
einzelnen IDocs versorgt werden:
Werte für die Export-Parameter bei der Verarbeitung eines einzelnen IDoc über eine ALE-
fähige Call Transaction, wobei die IDoc-Verarbeitung scheiterte.
Parameter Wert
Call_Transaction " " (z.B. Initialwert)
_Done
Workflow_Result "99999"
Application_Vari " "(z.B. Initialwert)
able
Idoc_Status Die Tabelle muß einen Satz
enthalten, dessen Felder wie folgt
versorgt sein müssen:
Docnum: 4711
Status:51
Msgid, Msgno etc. müssen die
Kennung der Fehlermeldung,
Nummer etc. enthalten.
Return_Variable Die Tabelle muß den folgenden
s Eintrag enthalten:
Wf_param Doc_Number
"Error_IDOCs" 4711
Serialization_Inf Leer
o
April 2001 155

ALE-Einstellungen
ALE-Einstellungen
Um zu gewährleisten, daß der Funktionsbaustein im Eingang über ALE aufgerufen wird, müssen
Sie eine Reihe von Einstellungen (Tabelleneinträge) vornehmen, die im folgenden erläutert
werden. Wählen Sie dazu Werkzeuge ® Business Framework ® ALE ® Entwicklung.
Die folgende Tabelle gibt einen Überblick über die Beziehungen der Einstellungen. Jede Zeile
steht für ein Feld; die Zeile "Fehlerereignis" steht für fünf Felder. Es werden nur die wichtigen
Felder einer Tabelle aufgeführt. Die Spalten stehen für folgende Objekte (fett gedruckte Einträge
stehen für Primärschlüsselfelder):
· die Felder, die von dem Steuersatz eines eingegangenen IDocs gelesen werden
· die sechs IDoc-Felder, die den zu verwendenden Vorgangscode bestimmen
· Attribute für den Vorgangscode
· Attribute für den Funktionsbaustein im Eingang
· die Felder, mit denen geprüft wird, ob der Funktionsbaustein in ALE registriert ist.
Die Beziehungen zwischen den Feldern in einem IDoc-Steuersatz und den Tabellen, die
die ALE-Eingangseinstellungen enthalten
Partner- Vorgangscode- Attribute ALE Funktions-

IDoc
vereinbarung Tabellen Funktions- baustein
Steuersatz
Eingang (Eingang) baustein Registrierung
IDoc-Typ IDoc-Typ
Sendepartn.-Typ Sender-Typ
Sendepartn. Nr. Sender-Nr.
Nachrichten-Typ Nachr.-Typ Nachr.-Typ
Nachr.-Variante Nachr.-Var. Nachr.-Var.
Nachr.-Funktion Nachr.-Funkt. Nachr.-Funkt.
Testflag Fest flag
Vorgangscode Vorgangscode
Vorgangstyp
Fehlerereignis
Anw. Obj.-Typ Anw. Obj. Typ
Eingangsfunkt. Eingangsfunkt. Eingangsfunkt.
Eingangs-Typ
Dialog?
Siehe auch:
· Attribute des Funktionsbausteins deklarieren [Seite 157]
· Registrieren des Funktionsbausteins im Eingang [Seite 158]
· Eingangs-Vorgangscode anlegen [Seite 159]
156 April 2001

Attribute des Funktionsbausteins deklarieren
Attribute des Funktionsbausteins deklarieren

Der Funktionsbaustein im Eingang hat zwei ALE-Attribute: "Dialog möglich?" und "Eingangstyp".
Dialog möglich?
Unterstützt der Funktionsbaustein eine Call Transaction, kann er so programmiert werden, daß
er den Benutzern die Eingangsbilder wie oben beschrieben anzeigt. Dies muß hier bekannt
gemacht werden, da der Benutzer ansonsten nicht die Möglichkeit hat, die Bilder anzuzeigen.
Eingangstyp
Es gibt drei Typen von Funktionsbausteinen im Eingang:
1. Funktionsbausteine, die Massenverarbeitung unterstützen.
2. Funktionsbausteine, die nur die Verarbeitung eines einzelnen IDocs zulassen und keine
ALE-fähigen Transaktionen verwenden.
3. Funktionsbausteine, die nur die Verarbeitung eines einzelnen IDocs zulassen und eine ALE-
fähige Transaktion verwenden.
Für die beiden zuletzt genannten Typen teilt die ALE-Schicht ein eingehendes Paket von IDocs
und ruft den Funktionsbaustein einmal für jedes IDoc auf. Diese beiden Typen müssen von
einander unterschieden werden, da sich die ALE-Verarbeitung vor dem Aufruf in jedem der
beiden Fälle unterscheidet.
Als Beispiel können Sie sich den Funktionsbaustein IDOC_INPUT_MATMAS01

ansehen, der für Materialstammdaten verwendet wird.
April 2001 157

Registrieren des Funktionsbausteins im Eingang
Registrieren des Funktionsbausteins im Eingang

ALE verfolgt, welche Nachrichtentypen, Variante und Funktion, IDoc-Typ und
Anwendungsobjekttypen für einen Funktionsbaustein im Eingang anwendbar sind. Bevor der
Funktionsbaustein im Eingang verwendet werden kann, muß er hier registriert werden.
Wird der Funktionsbaustein zur Verarbeitung von Stammdaten verwendet, ist nur der Eintrag für
den "Referenz"-Nachrichtentyp erforderlich; beim "Referenz"-Nachrichtentyp "Reduziert" werden
die Einträge automatisch erzeugt.
Als Beispiel können Sie sich den Eintrag für den Funktionsbaustein im Eingang
IDOC_INPUT_MATMAS01 und Referenznachrichtenyp MATMAS ansehen, der für
Materialstammdaten verwendet wird.
158 April 2001

Eingangs-Vorgangscode anlegen
Eingangs-Vorgangscode anlegen
Den Eingangs-Vorgangscode können Sie sich als den Namen denken, der die
Verarbeitungsverfahren eines eingehenden IDocs bezeichnet, z.B. die Attribute des
Vorgangscodes. Ein Vorgangscode hat folgende Attribute:
· Verarbeitungstyp (z.B. soll der Funktionsbaustein im Eingang sofort aufgerufen werden
oder sollte ein Workflow oder Workitem gestartet werden?)
- Standard: "ALE, function module called directly"
· Name des Funktionsbausteins im Eingang
· Attribute für die Fehlerverarbeitung (Objekte und Ereignisse; siehe Abschnitt über
Objekte etc. für die Fehlerbehandlung)
· der für ALE-Links verwendete Anwendungsobjektyp
- der vom Funktionsbaustein im Eingang erstellte oder geänderte Objekttyp. Beispiel:
Ein eingehender ORDERS IDoc, der eine Kundenbestellung enthält, erstellt einen
Kundenauftrag im empfangenden R/3-System. Der Anwendungsobjekttyp ist
BUS2032, der Objekttyp für Kundenaufträge im BOR (Business Object Repository).
· das auszulösende Anwendungsereignis (wird im Abschnitt über fortgeschrittene
Techniken erklärt)
- wird normalerweise nicht verwendet.
Als Beispiel sehen Sie sich den Vorgangscode MATM an, der für
Materialstammdaten verwendet wird.
Namenskonvention
Die Namenskonvention für Vorgangscodes besagt, daß die ersten vier Buchstaben des
Nachrichtentyps, auf den er sich bezieht, verwendet werden sollen. Beispiel: MATM für
Nachrichtentyp MATMAS; sollte es zu Überschneidungen kommen, verwenden Sie die ersten
drei Buchstaben und eine Zahl, z.B. MAT1.
In unserem Fall würde der Vorgangscode XAMP heißen.
April 2001 159

Eingangsverarbeitung über SAP-Workflow
Eingangsverarbeitung über SAP-Workflow

In diesem Abschnitt erfahren Sie, wie Sie über den Workflow eingehende IDocs verarbeiten,
anstatt den direkten Eingang über Funktionsaufruf zu verwenden.
Aus Performance-Gründen empfehlen wir den direkten Eingang, da sonst ein Workflow pro IDoc
erzeugt wird.
Der Workflow ist dann sinnvoll, wenn jedes IDoc eines Nachrichtentyps bzw. eines Senders oder
das anschließend von einem IDoc angelegte Anwendungsobjekt manuell verarbeitet werden
müssen. Beispielsweise beim Nachrichtentyp ORDCHG, "sales order change"; ein Firma
entscheidet, daß Änderungen eines Auftrags durch einen Kunden (Sender) vor der Verbuchung
durch eine/n MitarbeiterIn angeschaut werden muß.
Funktionsbausteine im Eingang, die wie oben implementiert wurden, unterstützen die

Eingangsverarbeitung über den Workflow zusätzlich zur Fehlerbehandlung. Es sind
keine Änderungen erforderlich.
Die beiden Unterabschnitte beschreiben die beiden Workflow-Verfahren zur Verarbeitung von
eingehenden IDocs: Workitems und Workflow
Siehe auch:
Workitem [Seite 161]
Workflow [Seite 162]
160 April 2001

Workitem
Workitem
Um einen bestimmten Workitem zu starten, können Sie anstatt eines direkten Funktionsaufrufes
Ihren Eingangsvorgangscode definieren. Das an den Workitem-Container übergebene Objekt ist
das IDoc-Objekt (z.B. ein Objekt des Typs IDOCMATMAS).
Hinweis: Soll ein IDoc-Paket mit mehr als einem IDoc verarbeitet werden, wird nur das erste IDoc
an den Workitem übergeben. Die restlichen IDocs werden nicht verarbeitet.
April 2001 161

Workflow
Workflow
Um einen bestimmten Workflow zu starten, können Sie anstatt eines direkten Funktionsaufrufes
Ihren Eingangsvorgangscode definieren. Der Workflow-Container muß die folgenden beiden
Parameter als Import-Parameter enthalten:
Obligatorischer Import-Parameter für den Workflow-Container
Parametername Typ Multi-line Referenz (Objekttyp/Tabellenfeld)

IDOC_PACKET Objekt Nein IDOCXAMPLE or IDPKXAMPLE
Unprocessed_IDOCs Variable Ja Edidc-Docnum
IDOC_PACKET wird mit einem Objekt des im Workflow-Container definierten Typs gefüllt (d.h.,
ALE liest die Workflow-Container-Definition, um den Typ festzustellen); die Objektkennung ist die
Nummer des ersten IDocs im Paket.
Unprocessed_IDOCs besteht aus einer Liste der IDoc-Nummern im Paket.
Siehe auch:
IDOCXAMPLE als Referenz für IDOC_PACKET [Seite 163]
IDPKXAMPLE als Referenz für IDOC_PACKET [Seite 164]
162 April 2001

IDOCXAMPLE als Referenz für IDOC_PACKET
IDOCXAMPLE als Referenz für IDOC_PACKET

Um die Methoden InputForeground und InputBackground des IDoc-Objekttyps zu verwenden,
müssen Sie Ihren IDoc-Objekttyp (IDOCXAMPLE) als Referenz für IDOC_PACKET verwenden.
Dazu müssen Sie sicherstellen, daß nur ein einzelnes IDoc an ALE übergeben wird, d.h. Pakete
der Größe 1. Die Begründung ist einfach: die Methoden InputForeground und InputBackground
behandeln ein einzelnes IDoc-Objekt, von daher müssen den Datenfluß so definieren, daß sie
das in IDOC_PACKET enthaltene Objekt behandeln kann. Die Methoden verwenden nicht die
Variable Unprocessed_IDOCs, kennen daher nicht die anderen im Paket enthaltenen IDocs.
April 2001 163

IDPKXAMPLE als Referenz für IDOC_PACKET
IDPKXAMPLE als Referenz für IDOC_PACKET

Um die Methoden MassInput oder Display des IDoc-Paketobjekttyps (IDPKXAMPLE) zu
verwenden, müssen Sie IDPKXAMPLE als Referenz für IDOC_PACKET verwenden.
Beide Methoden haben eine Import-Variable Unprocessed_IDOCs, die an die Variable
Unprocessed_IDOCs im Workflow-Container gekoppelt werden muß. Dadurch können alle IDocs
im Paket verarbeitet werden.
Normalerweise ist IDPKXAMPLE nur sinnvoll, wenn Sie auch Ihre eigenen Methoden zur
Verarbeitung des IDoc-Pakets definieren.
164 April 2001

Erweiterte Workflow-Programmierung
Erweiterte Workflow-Programmierung
Siehe auch:
Setzen des Parameters "Result" im Ereignis Container [Seite 166]
Auslösen des Anwendungsereignisses nach erfolgreicher IDoc-Verarbeitung [Seite 170]
Einsetzen des Parameters No_of_retries [Seite 172]
April 2001 165

Setzen des Parameters "Result" im Ereignis Container
Setzen des Parameters "Result" im Ereignis Container

Sowohl inputErrorOccurred als auch inputFinished haben den Parameter "Result" in ihren
Containern. Sie können den Wert wie folgt beeinflussen:
Siehe auch:
Das Ereignis inputErrorOccurred [Seite 167]
Das Ereignis inputFinished [Seite 169]
166 April 2001

Das Ereignis inputErrorOccurred

ALE löst das Ereignis inputErrorOccurred aus, wenn der Import-Parameter Mass_Processing des
Funktionsbausteins im Eingang auf "X" gesetzt ist. In diesem Fall behandelt ALE die
eingehenden IDoc(s) als Paket, selbst wenn es nur ein IDoc enthält.
Da einige IDocs im Paket erfolgreich verarbeitet werden, andere scheitern könnten, kann der
Export-Parameter Workflow_Result nicht zum Setzen des Container-Parameters Result
verwendet werden. Der Parameter hat vielmehr unterschiedliche Werte, je nachdem welche
Parameter in der Tabelle Return_Variables verwendet werden:
Werte für den Parameter Result, wenn Mass_Processing = "X". Beachten Sie, daß Sie für
eine gegebene IDoc-Nummer (im Feld Doc_Number) nur einen der oben genannten Namen
verwenden. Achten Sie auf Groß- und Kleinschreibung
Wf_param Wert von "Result" im Ereignis-Container

"Error_IDOCs" 99999
"Retry_IDOCs" 1
"Continue_IDOCs" 2
Man könnte diese drei Werte wie folgt verwenden: inputErrorOccurred könnte einen Workflow
auslösen, der je nach Wert des Result-Parameters verzweigt:
Möglicher Einsatz der Variablen Result in einem Workflow
Result In Workflow definierte Aktion

1 Versucht IDoc n Minuten später erneut, mit einer neuen Aufgabe, die die
Methode InputBackground verwendet. Damit könnten IDocs erneut versucht
werden, die gescheitert sind, weil eine Anwendung durch einen Benutzer oder
Prozeß vorübergehend gesperrt war.
2 Verarbeitet den IDoc auf andere Art.
99999 Fehlerbehandlung mit der Standard/Kundenaufgabe
Werte für die Export-Parameter für die Verarbeitung von IDoc-Paketen, wenn IDoc 4711
erfolgreich verarbeitet und Anwendungsobjekt mit der Nummer 1234 angelegt wurde; IDoc
4712 hat einen Fehler verursacht, für den der Ereignisparameter Result = 99999 ist; IDoc
4713 hat einen Fehler verursacht, für den Result = 2 ist; IDoc 4714 hat einen Fehler
verursacht, für den Result = 1 ist.
Parameter Wert
April 2001 167

Call_Transactio " " (z.B. Initialwert)

n_Done
Workflow_Resul "99999"
t
able
Idoc_Status Die Tabelle muß vier Sätze
Werte haben müssen:
Docnum Status
4711 53
4712 51
4713 51
4714 51
Die Felder Msgid etc. des
Statussatzes für IDocs 4712, 4713
und 4714 müssen die
Fehlermeldung enthalten.
Return_Variable Die Tabelle muß die folgenden fünf
s Einträge enthalten:
Wf_param Doc_Number
"Appl_Objects" 1234
"Error_IDOCs" 4712
"Continue_IDOCs" 4713
"Retry_IDOCs" 4714
Anwendungsobjekt angelegt oder
geändert wird, können Sie den
Eintrag "Appl_Objects" weglassen -
ohne Belegnummer ist er sinnlos.
Serialization_Inf Leer, falls Serialisierung nicht
o verwendet wird.
168 April 2001

Das Ereignis inputFinished
Das Ereignis inputFinished

ALE löst das Ereignis inputFinished aus, wenn der Import-Parameter Mass_Processing des
Funktionsbausteins im Eingang auf " " (= initial) gesetzt ist.
Wird die Methode InputForeground verwendet, wird das Ereignis nur ausgelöst, wenn das an den
Funktionsbaustein im Eingang übergebene IDoc erfolgreich verarbeitet wurde, d.h. Status 53
erhält oder zum Löschen gekennzeichnet wurde oder bereits verarbeitet wurde und der Benutzer
den Workitem als erledigt gekennzeichnet hat (über das IDoc-Menü).
Auch bei der Methode InputBackground wird das Ereignis immer ausgelöst.
Der Parameter Result erhält den Wert des Export-Parameters Workflow_Result des
Funktionsbausteins im Eingang. Nach Konvention sollen die Werte 0, 1, 2 und 99999 wie beim
Ereignis inputErrorOccurred verwendet werden.
Die folgende Tabelle zeigt die Werte, für die es Konventionen gibt. Andere Werte können bei
Bedarf verwendet werden, beginnend mit 3.
Konventionen für den Wert von "Result" im Container des IDoc-Objektereignisses

inputFinished
Result Bedeutung
0 IDoc erfolgreich verarbeitet
1 IDoc nicht erfolgreich verarbeitet; später erneut versuchen
2 IDoc nicht erfolgreich verarbeitet; anwendungsspezifische Workflow-Aktion sollte
als nächster Schritt gestartet werden.
99997 Set by ALE: IDoc wurde bereits verarbeitet; Workitem als erledigt kennzeichnen
99998 Set by ALE: IDoc zum Löschen gekennzeichnet
99999 IDoc nicht erfolgreich verarbeitet
April 2001 169

Auslösen des Anwendungsereignisses nach erfolgreicher IDoc-Verarbeitung
Auslösen des Anwendungsereignisses nach

erfolgreicher IDoc-Verarbeitung
Innerhalb des Funktionsbausteins im Eingang kann eine beliebige Zahl von Ereignissen durch
Aufruf des Workflow-Funktionsbausteins "create event" ausgelöst werden; damit haben Sie volle
Kontrolle über die Parameter des Ereignisses.
Wenn einfach nur ein Ereignis für Ihr Anwendungsobjekt mit einem einzelnen Result-Parameter
im Container ausgelöst werden soll, kann ALE dies für Sie erledigen. Als Beispiel sei hier der
Nachrichtentyp EDLNOT, Vorgangscode EDLN genannt.
Dazu müssen Sie
· das Feld "application event" für die Eingangsmethode Ihres Vorgangscodes ausfüllen;
· einen Eintrag in der Tabelle Return_Variables des Funktionsbausteins im Eingang
hinzufügen, wobei Wf_Param wie in der folgenden Tabelle gefüllt werden muß, und die
Doc_Number identisch mit Ihrer Anwendungsobjektkennung ist.
· den Parameter Workflow_Result auf einen Wert ungleich 0 setzen. Kunden können
alphanumerische Werte beginnend mit Y oder Z verwenden. Im vorliegenden Beispiel wird
der Wert 3 verwendet.
Auslösen eines Ihrer Anwendungsobjektereignisse durch ALE und Beeinflußung des

Parameterwerts Result im Container.
Wf_Param Doc_Number Parameter Result im Ereignis-Container
"Continue_Objects1" 1234 1
Werte für Export-Parameter für die Verarbeitung von IDoc-Paketen, wobei alle IDocs
erfolgreich verarbeitet worden sind und für jedes erfolgreich verarbeitete IDoc ein
Anwendungsobjektereignis ausgelöst wird. IDoc-Nummern 4711 und 4712 haben die
Anwendungsobjekte 1234 und 1235 angelegt. In beiden Fällen wird der Parameter Result
im Ereignis-Container auf 1 gesetzt.
Parameter Wert
verwendet
"X" Verbuchungstask verwendet
Call_Transactio " "
n_Done
170 April 2001

Auslösen des Anwendungsereignisses nach erfolgreicher IDoc-Verarbeitung
Workflow_Resul "3"
t
able
Werte haben:
Docnum Status
4711 53
4712 53
Optional können die Felder Msgid
etc. die Erfolgsmeldung der
Anwendung enthalten.
Return_Variable Die Tabelle muß die folgenden
s sechs Einträge enthalten:
Wf_param Doc_Number
"Appl_Objects" 1234
"Continue_Objects1" 1234
"Continue_Objects1" 1235
Serialization_Inf Leer, falls keine Serialiserung
o verwendet wird.
April 2001 171

Einsetzen des Parameters No_of_retries
Einsetzen des Parameters No_of_retries

Wenn Sie einen Workflow implementieren möchten, um ein IDoc mehrmals verarbeiten zu
lassen, bevor ein Fehlerbehandlung-Workitem gestartet wird, beispielsweise für Fehler
vorübergehender Natur, d.h. Fehler, die durch eine Objektsperre ausgelöst werden, erlaubt Ihnen
ALE zu verfolgen, wie oft das IDoc verarbeitet wurde. Der Kunde kann die maximale Anzahl der
Versuche individuell einstellen.
Die Methode InputBackground des Objekts IDOCAPPL (und aller Abkömmlinge) hat den Import-
Parameter "no_of_retries", der von ALE auf null gestzt wird, wenn ein IDoc zum ersten Mal
verarbeitet wird. Die Methode verarbeitet diesen Parameter wie folgt:
· Ist er größer als die maximale Anzahl der Versuche wie sie in der Eingangsmethode des
Vorgangscodes definiert ist, wird der Parameter Result im Container des Ereignisses
inputFinished auf "99999" gesetzt.
· Ansonsten wird er um eins hochgezählt und in den Parameter "no_of_retries" im Ereignis
inputFinished geschrieben.
Für diese Funktion müssen Sie für Ihren Workflow einen Parameter "no_of_retries" im Container
definieren, der mit dem Import- und Ereignisparameter "no_of_retries" gekoppelt ist und zum
Schritt InputBackground zurückgeht, es sei denn, der Ereignisparameter Result = "99999".
172 April 2001

Stammdatenverteilung
Stammdatenverteilung
Die Implementierung der Stammdatenverteilung über die asynchrone IDoc-Schnittstelle erfolgt in
drei Schritten:
1. Definition der Nachricht [Seite 174] durch Festlegen des Nachrichtentyps und des IDoc-Typs.
2. Entwicklung des Programms bzw. Funktionsbausteins für die Erstellung des IDocs aus dem
Anwendungsobjekt und Versand des IDocs über die ALE-Schnittstelle
(Ausgangsverarbeitung [Seite 175])
3. Entwicklung des Funktionsbausteins für die IDoc-Verarbeitung auf der Empfangsseite
(Eingangsverarbeitung [Seite 182])
April 2001 173

Definition der Nachricht
Definition der Nachricht

Die allgemeinen Regeln für die Definition einer neuen Nachricht (Nachrichtentyp, IDoc-Typ)
entnehmen Sie der Dokumentation über "Designrichtlinien für IDoc-Typen und IDoc-Segmente".
Berücksichtigen Sie bei der Definition Ihrer neuen Nachricht folgende für die
Stammdatenverteilung spezifische Punkte:
· Definieren Sie den Segmentinhalt und die Segment-Hierarchie im IDoc-Typ entsprechend
der logischen Hierarchie der Daten im Stammdatenobjekt, die meistens mit der Hierarchie
der Datenbanktabellen für das Stammdatenobjekt im SAP-System übereinstimmt.
Der Materialstamm besteht aus den Tabellen MARA, MAKT, MARC und MARD. Die
IDoc-Segmente E1MARAM, E1MAKTM, E1MARCM, E1MARDM im IDoc-Typ
MATMAS02 für den Materialstamm entsprechen inhaltlich weitgehend diesen
Tabellen. Die Hierarchie dieser Segmente im IDoc-Typ MATMAS02 entspricht der
Hierarchie der Datenbanktabellen:
E1MARAM: Master Material allgemeine Daten (MARA)
E1MAKTM: Master Material Kurztexte (MAKT)
E1MARCM: Master Material C-Segment (MARC)
E1MARDM: Master Material Lager/Chargen-Segment (MARD)
· Definieren Sie in jedem IDoc-Segment als erstes Feld das Feld MSGFN mit dem
Datenelement MSGFN. Im Feld MSGFN wird die Information übertragen, ob die Segment-
Daten im Zielsystem anzulegen, zu ändern, zu löschen oder zu aktualisieren sind.
Als Beispiel dient der Aufbau der Segmente E1MARAM, E1MAKTM, E1MARCM und
E1MARDM des Materialstamm IDoc-Typs MATMAS02.
Es wird empfohlen, die IDoc-Segmente in der Form E1xxxxx zu benennen, wobei xxxxx der
Name der entsprechenden Datenbanktabelle ist. Falls der Tabellenname weniger als fünf Stellen
hat, füllen Sie die restlichen Stellen mit dem Buchstaben M auf, beispielsweise E1MARAM für die
Tabelle MARA.
174 April 2001

Ausgangsverarbeitung in der Stammdatenverteilung
Ausgangsverarbeitung in der Stammdatenverteilung

Für die Verteilung von Stammdaten sind zwei Verfahren vorgesehen. In beiden Fällen enthält ein
IDoc nur die Daten eines Stammdatenobjekts.
· Direktes Senden von Stammdatenobjekten
Mit der Funktion kann man explizit das Versenden von Stammdatenobjekten anstoßen.
Die IDocs werden dabei mit kompletten Daten zu Stammdatenobjekten gefüllt.
· Verteilung der Stammdaten über das SMD-Tool (Shared Master Data Tool)
In diesem Fall werden die Änderungen an Stammdatenobjekten im R/3-System zuerst in
Form von sogenannten Änderungszeigern protokolliert. Das Schreiben der
Änderungszeiger ist direkt an die Änderungsbelegschnittstelle angeschlossen.
Anschließend besteht die Möglichkeit, die Änderungszeiger auszuwerten, die IDocs für
die geänderten Stammdatenobjekte aufzubauen und sie zu versenden. Dabei werden
nur die geänderten Daten im IDoc aufgebaut, an ALE-Schicht übergeben und
anschließend an andere Systeme versendet. Auf dem folgenden Diagramm sind die
einzelnen Schritte der Stammdatenverteilung über SMD-Tool abgebildet
Schritte der Stammdatenverteilung über das SMD-Tool
Anwendungs- Änderungsbeleg- ALE-Schicht

buchung dienst
SMD
Customizing
Stammdaten
SMD-Tool
anlegen/ändern
Änderungsbeleg Standard-ALE-
erzeugen ALE-Felder ? Ausgang
Zeiger schreiben
Hintergrund-Job / manuell
IDocs erzeugen M CC
C
Stammdaten Änderungsbelege Änderungszeiger
April 2001 175

Stammdaten über das SMD Tool verteilen

Das Shared Master Data Tool (SMD-Tool) protokolliert Änderungen an Stammdatenobjekten in
der Form von Änderungszeigern. Es ist an die Änderungsbelegschnittstelle angeschlossen. Um
Stammdaten über das SMD-Tool verteilen zu können, müssen beim Ändern, Neuanlegen und
Löschen eines Stammdatenobjekts Änderungsbelege erzeugt werden. Das Stammdatenobjekt
muß an die Änderungsbelegschnittstelle angeschlossen sein.
Änderungszeiger werden zum Ermitteln und Verteilen von Änderungen an Stammdatenobjekten
verwendet.
Das Erzeugen von Änderungszeigern läuft wie folgt ab:
Das Anwendungsprogramm ruft die Änderungsbelegschnittstelle zu einem sogenannten
Änderungsbelegobjekt auf. Hierfür wird ein generierter Funktionsbaustein
xyz_DOCUMENT_WRITE aufgerufen. In seiner Schnittstelle befinden sich für jede Tabelle und
Struktur, für die Deltas als Änderungsbelege ermittelt werden sollen, zwei Parameter - die alten
Sätze und die neuen Sätze. Die Änderungsbelegschnittstelle erzeugt daraus eine Liste von
Änderungen (Tabellenname, Tabellenschlüssel, Feldname, Änderungsart, alter Wert, neuer
Wert).
Im wesentlichen gibt es drei Änderungsarten:
· Insert
Beim Einfügen wird genau ein Satz geschrieben (Tabellenname, Tabellenschlüssel,
Feldname = "KEY", Änderungsart = Insert, Alter Wert = leer, Neuer Wert=leer). Die
Feldwerte werden nicht dokumentiert, da sie auf der Datenbank zu finden sind. Wichtig
ist hierbei, dass in diesem Fall der spezielle Feldname KEY verwendet wird.
· Update
Beim Ändern wird für jedes geänderte Feld ein Satz geschrieben (Tabellenname,
Tabellenschlüssel, Feldname = <Feldname> , Änderungsart = Update, alter Wert = ABC,
neuer Wert=DEF).
Hierbei gibt es noch eine Variante:
In der Definition des Änderungsbelegobjekts kann auch noch bestimmt werden, dass
nicht ein Update-Satz, sondern ein Delete- und ein Insert-Satz geschrieben werden.
Daher ist auch die Änderungsart ein Schlüsselfeld in der CDPOS-Tabelle. Somit können
zu einem Tabellennamen, Tabellenschlüssel und Feldnamen zwei Sätze für Delete und
Insert geschrieben werden.
· Delete
Beim Löschen wird genau ein Satz geschrieben (analog zum Einfügen). In der Definition
des Änderungsbelegobjekts kann auch angegeben werden, dass alle Werte gespeichert
werden, dann gibt es je Feld einen Satz.
Beim Schreiben der Änderungsbelege wird auch die Schnittstelle zum Schreiben von
Änderungszeigern aufgerufen. Hier wird aus der Tabelle TBD62 ermittelt, ob zu Tabellenname,
Tabellenschlüssel, Feldname Sätze mit zu versendenden Nachrichtentypen gefunden werden.
TBD62 besteht aus Tabellenname, Tabellenschlüssel, Feldname, Nachrichtentyp. Für jeden
Nachrichtentyp, der in der Tabelle TBDA2 als aktiv gekennzeichnet ist, wird ein Änderungszeiger
geschrieben. Dabei wird in die Tabelle BDCP ein Satz mit den eigentlichen
Änderungsinformationen und in die Tabelle BDCPS für jeden Nachrichtentyp ein Statussatz
geschrieben.
176 April 2001

Daher müssen Sie in die Tabelle TBD62 alle Felder aufnehmen, deren Änderung das Versenden
einer Nachricht (IDoc) bewirken soll.
Vorgehensweise
Damit das Schreiben der Änderungszeiger über das SMD-Tool für Ihr Stammdatenobjekt aktiviert
werden kann, müssen Sie folgende Schritte ausführen:
· Änderungszeiger pro Nachrichtenyp aktivieren
· Änderungsrelevante Felder für Nachrichtentypen pflegen
· Änderungszeiger generell aktivieren
Darüber hinaus müssen Sie folgende Schritte ausführen:
· Funktionsbaustein für Auswertung der Änderungszeiger implementieren
· ALE-Objekttyp MSGFN definieren und als Filterobjekttyp pflegen
Wenn Sie die Stammdaten über ein asynchrones BAPI verteilen, dann gelten
alle nachfolgend beschriebenen Einstellungen für den generierten Nachrichtentyp
der BAPI-ALE-Schnittstelle.
Änderungszeiger pro Nachrichtenyp aktivieren

Durch einen Eintrag in Tabelle TBDA2 können Sie das Schreiben der Änderungszeiger für ein
bestimmtes Stammdatenobjekt aktivieren bzw. deaktivieren.
Die Pflege der Tabelle TDBA2 erreichen Sie im Customizing über folgenden Pfad:
Basis
Verteilung (ALE)
Replikation von geänderten Daten einrichten
Änderungszeiger pro Nachrichtentyp aktivieren (Transaktion BD50).
Nehmen Sie in der Tabelle TBDA2 einen Eintrag mit dem Nachrichtentyp für Ihr
Stammdatenobjekt auf. Für die Auslieferung zum Kunden soll das Kennzeichen "Aktiv" bei dem
Eintrag nicht gesetzt werden. Falls zu Testzwecken das Schreiben der Änderungszeiger für Ihr
Stammdatenobjekt aktiviert wird, muß im TBDA2-Eintrag für Ihren Nachrichtentyp das
Kennzeichen "Aktiv" gesetzt werden.
Sehen Sie sich als Beispiel den TBDA2-Eintrag für den Nachrichtentyp MATMAS
des Materialstamms an.
Änderungsrelevante Felder für Nachrichtentypen pflegen

In Tabelle TBD62 werden die Änderungsbelegfelder aus dem Änderungsbelegobjekt
beschrieben, deren Protokollierung über die Änderungsbelegschnittstelle zum Schreiben der
Änderungszeiger führen soll.
April 2001 177

Zur Pflege der Tabelle TBD62 wählen Sie in der ALE-Entwicklung BAPI-Schnittstelle
® Änderungswesen ® Änderungsrelevante Felder pflegen (Transaktion BD52).
Definieren Sie in der Tabelle TBD62 für Ihren Nachrichtentyp alle Änderungsbelegfelder, für die
die Änderungszeiger geschrieben werden sollen, damit Sie die entsprechenden Änderungen an
Ihrem Stammdatenobjekt an andere Systeme verteilen können.
Beim Hinzufügen eines Eintrages in eine Tabelle zu Ihrem Stammdatenobjekt wird zur
Protokollierung solcher Änderung das Änderungsbelegfeld mit dem imaginären Feldnamen KEY
benutzt (z.B. MATERIAL MARA KEY bei der Neuanlage eines Materials oder MATERIAL MARC
KEY beim Hinzufügen der Werksdaten zu einem Werk). Solche Einträge müssen Sie auch in die
Tabelle TBD62 aufnehmen, und zwar für alle Tabellen aus dem Änderungsbelegobjekt für Ihr
Stammdatenobjekt.
Das Hinzufügen bzw. Ändern eines Langtextes wird in der Änderungsbelegposition mit einem
Eintrag protokolliert. Dieser besitzt als Tabellenname das Textobjekt und als Feldname einen
Wert, der sich aus der Text-ID und dem Sprachenschlüssel zusammensetzt. Falls Änderungen
an Langtexten zu einem Stammdatenobjekt verteilt werden sollen, müssen solche Einträge in die
Tabelle TBD62 aufgenommen werden. Es ist aber nicht notwendig, dies für jeden möglichen
Sprachenschlüssel zu tun. Es genügt, für die betroffene Text-ID einen Eintrag in die Tabelle
TBD62 aufzunehmen, der als Feldname einen Wert hat, der aus der Text-ID und dem Zeichen *
zusammengesetzt ist (z.B. MATERIAL MATERIAL BEST* für den Einkaufsbestelltext im
Materialstamm).
Sehen Sie sich die TBD62-Einträge für den Nachrichtentyp MATMAS für den
Materialstamm im R/3-System an.
Änderungszeiger generell aktivieren

Zur generellen Aktivierung der Stammdatenverteilung über Änderungszeiger wählen Sie im
Customizing folgenden Pfad:
Basis
Verteilung (ALE)
Replikation von geänderten Daten einrichten
Änderungszeiger generell aktivieren (Transaktion BD61).
Funktionsbaustein für Auswertung der Änderungszeiger implementieren

Bei der Auswertung der Änderungszeiger werden die IDocs für die geänderten
Stammdatenobjekte aufgebaut und versendet. Die Auswertung der Änderungszeiger mit dem
anschließenden Aufbau und Versand der IDocs erfolgt pro Nachrichtentyp (z.B. MATMAS für den
Materialstamm) und wird über einen Funktionsbaustein (z.B.
MASTERIDOC_CREATE_SMD_MATMAS für den Materialstamm) realisiert.
Der Funktionsbaustein ist für jeden Nachrichtentyp zu implementieren. Die Namenskonvention
für den Funktionsbaustein ist MASTERIDOC_CREATE_SMD_xxxxxx, wobei xxxxxx der Name
des Nachrichtentyps ist.
Die folgende Beschreibung der Implementierung des Funktionsbausteins für die
Änderungszeigerauswertung mit dem anschließenden Aufbau und Versand der IDocs können
178 April 2001

Sie am Beispiel des Funktionsbausteins MASTERIDOC_CREATE_SMD_MATMAS für den

Materialstamm nachvollziehen. Sie können aber auch den Funktionsbaustein
MASTERIDOC_CREATE_SMD_MATCOR für den Core Materialstamm als Vorlage für Ihren
Funktionsbaustein nehmen. Der IDoc-Typ MATCOR01 für den Core-Materialstamm besteht
lediglich aus den beiden Segmenten E1MARAC und E1MAKTC und enthält nur die Core-Daten
aus dem Materialstamm. Daher ist der Funktionsbaustein
MASTERIDOC_CREATE_SMD_MATCOR für den Core Materialstamm übersichtlicher und
einfacher gestaltet als der Funktionsbaustein MASTERIDOC_CREATE_SMD_MATMAS für den
kompletten Materialstamm.
Legen Sie also einen Funktionsbaustein für Ihren Nachrichtentyp an. Die Schnittstelle des
Funktionsbausteins ist vorgegeben und besteht aus dem Parameter für den Nachrichtentyp.
Zum Aufruf des Funktionsbausteins wählen Sie im Bildschirm der ALE-

Administration Dienste ® Änderungszeiger ® Auswerten (Transaktion BD21).
Bevor Sie die Transaktion für Ihren Nachrichtentyp starten können, müssen Sie die Zuordnung
vom Nachrichtentyp zum Funktionsbaustein in der Steuertabelle TBDME pflegen. Definieren Sie
für Ihren Nachrichtentyp einen Eintrag in der Tabelle TBDME mit dem Referenznachrichtentyp
gleich Ihrem Nachrichtentyp und ordnen Sie den Funktionsbaustein zu. Als Beispiel können Sie
die Einträge für Nachrichtentyp MATMAS (Master Material) und MATCOR (Core Master Material)
ansehen.
Die Pflege der Tabelle TBDME erreichen Sie im Bildschirm der ALE-Entwicklung
über Stammdaten ® Zusatzdaten zum Nachrichtentyp.
In Ihrem Funktionsbaustein für die Änderungszeigerauswertung mit dem anschließenden Aufbau
und Versand der IDocs müssen Sie folgende Schritte implementieren:
1. Lesen Sie alle noch nicht abgearbeiteten Änderungszeiger für Ihren Nachrichtentyp mittels
des Funktionsbausteins CHANGE_POINTERS_READ.
2. Für jedes geänderte Stammdatenobjekt bauen Sie ein IDoc auf. Füllen Sie im IDoc nur die
Segmente, die laut der Änderungszeiger geändert wurden. Das erste Feld MSGFN in jedem
Segment ist folgendermaßen zu füllen:
009, wenn das Segment hinzugefügt wurde
004, falls Segmentfelder geändert wurden
003, wenn das Segment gelöscht wurde
018, falls Segmentfelder nicht geändert wurden, das Segment aber im IDoc stehen muß,
da hierarchisch untergeordnete Segmente im IDoc versendet werden.
3. Übergeben Sie das IDoc an die ALE-Schicht durch den Aufruf des Funktionsbausteins
MASTER_IDOC_DISTRIBUTE.
4. Die Änderungszeiger für das gerade abgearbeitete Stammdatenobjekt auf "Erledigt" setzen.
Dies geschieht über den Aufruf des Funktionsbausteins
CHANGE_POINTERS_STATUS_WRITE.
5. Setzen Sie den Befehl COMMIT WORK ab und rufen Sie den Funktionsbaustein
DEQUEUE_ALL auf. Aus Performance-Gründen sollte man diesen Schritt nicht nach jedem
IDoc durchführen, sondern z.B. erst nach 50 aufgebaute IDocs.
April 2001 179

ALE-Objekttyp MSGFN definieren und als Filterobjekttyp pflegen

Bei der Empfängerermittlung zu Nachrichtentypen, die nicht durch die BAPI-ALE-Schnittstelle
generiert wurden, kann es vorkommen, daß IDoc-Segmente, die geänderte Daten enthalten,
weggefiltert werden. Es bleiben unter Umständen an den Enden der Segmentketten IDoc-
Segmente übrig, die keine geänderten Daten enthalten und nur aufgrund der Segmenthierarchie
in das IDoc aufgenommen wurden.
Um der ALE-Ausgangsverarbeitung zu ermöglichen, solche hängenden Segmente zu
unterdrücken, muß ihnen beim Aufbau des IDocs im Feld MSGFN den Wert 018 zugewiesen
werden.
Zusätzlich müssen Sie folgende Einstellungen treffen:
· MSGFN muß als ALE-Objekttyp definiert sein. Wählen sie dazu im Menü der ALE-
Entwicklung IDoc-Schnittstelle ® Datenfilterung ® Filterobjekttyp pflegen (Transaktion
BD95). Im allgemeinen ist MSGFN bereits als ALE-Objekt definiert und ihm das Feld MSGFN
der Tabelle BDIPARAM zugeordet.
· MSGFN muß in Tabelle TBD21 als Filterobjekttyp des neuen Nachrichtentyps und der neuen
IDoc-Segmente eingetragen werden. Der vollständige Eintrag in TBD21 besteht aus dem
Namen des Nachrichtentyps unter MESTYP, des Segmenttyps unter SEGTYP und dem
Feldnamen MSGFN unter FLDNAM. Wählen sie dazu im Menü der ALE-Entwicklung IDoc ®
ALE-Objekte ® Zuordnen zum Nachrichtentyp (Transaktion BD59).
Bei der Verteilung von Änderungen mit asynchronen BAPIs sollten Sie aus
Gründen der Kompatibilität das Feld FUNCTION mit dem Datenelement BAPIFN und
den Festwerten INS, DEL, UPD, REF und IGN verwenden. Dadurch kennzeichnen
Sie die Art der Änderung, die mit dem BAPI verteilt wird.
Nehmen Sie das Feld FUNCTION in jeden strukturierten Parameter auf. So ist es
z.B. auch möglich, das Löschen eines Datensatzes zu verteilen.
180 April 2001

Stammdaten direkt senden
Stammdaten direkt senden

Beim direkten Senden wird das Versenden von Stammdatenobjekten explizit angestoßen. Es
werden dabei komplette Daten zu den zu versendenden Stammdatenobjekten mitgeschickt. Die
Funktion wird über ein Programm (z.B. RBDSEMAT für den Materialstamm) angestoßen.
In der ALE-Administration der Stammdatenverteilung finden Sie alle Objekte, für die bereits die
Funktion "Direktes Senden" implementiert ist.
Vorgehensweise
Legen Sie also für Ihr Stammdatenobjekt ein Programm an. Definieren Sie im Programm
Parameter für die Auswahl der zu sendenden Objekte und ein Parameter für das zu versorgende
logische System.
In Ihrem Programm müssen Sie dann folgende Schritte implementieren:
1. Bauen Sie für jedes zu versendende Stammdatenobjekt ein IDoc auf. Füllen Sie im IDoc alle
Daten zum Stammdatenobjekt. Das erste Feld MSGFN in jedem Segment ist mit dem Wert
005 zu versorgen.
2. Übergeben Sie das IDoc an die ALE-Schicht durch den Aufruf des Funktionsbausteins
MASTER_IDOC_DISTRIBUTE.
3. Setzen Sie den Befehl COMMIT WORK ab und rufen Sie den Funktionsbaustein
DEQUEUE_ALL auf. Um eine bessere Performance zu erreichen, sollte dieser Schritt erst
nach mehreren aufgebauten IDocs ausgeführt werden.
April 2001 181

Eingangsverarbeitung der Stammdaten
Eingangsverarbeitung der Stammdaten

Die allgemeine Beschreibung des Einbuchen eines IDocs auf der Empfangsseite finden Sie in
der Dokumentation der Eingangsverarbeitung [Seite 90]. Im Falle der Stammdatenverteilung sind
folgende Besonderheiten zu berücksichtigen:
· Bei der Einbuchung der IDoc-Segmente werten Sie das erste Feld MSGFN in jedem
Segment aus, um die durchzuführende Funktion für das jeweilige Segment zu ermitteln: 009
für Hinzufügen, 004 für Änderung, 003 für Löschung, 018 für unveränderte Daten und 005 für
eine Refresh-Funktion.
Bei den Funktionen 009, 004, 018 und 005 müssen die entsprechenden Daten im
Empfangssystem hinzugefügt (falls die Daten im Empfangssystem noch nicht vorhanden
sind) bzw. geändert werden (wenn die Daten im Empfangssystem bereits existieren).
Bei der Funktion 003 müssen die Daten im Empfangssystem gelöscht werden.
· Bei Stammdaten mit reduzierbaren Nachrichtentypen darf ein Datenbank-Feld nicht geändert
werden, wenn das entsprechende Feld im IDoc-Segment den Inhalt "/" besitzt.
· Bei der Verbuchung von Stammdaten können Stammdatenobjekte mit Hilfe des
Funktionsbausteins CACL_OBJECT_ALLOCATION_MAINT einer Klasse zugeordnet werden.
182 April 2001

Anbindung von Fremdsystemen

ALE kann nicht nur für die Kopplung von SAP-Systemen benutzt werden, sondern bietet auch
eine durchgängige technische Basis für die Anbindung von R/3 an Nicht-SAP-Systeme.
Durch die Benutzung der IDocs als universelle Container von Informationen hat ALE die
verschiedensten Anwendungsschnittstellen auf eine Schnittstelle reduziert, die IDocs aus einem
R/3-System sendet oder auf der Gegenseite IDocs empfängt.
Es gibt von SAP zertifizierte Übersetzungsprogramme (Translators) [Seite 185], die IDoc-
Strukturen in beliebige kundendefinierte Strukturen umsetzen können.
Alternativ dazu können Fremdsysteme selbst mit der RFC-Schnittstelle für das
Senden/Empfangen von IDocs versehen werden.
Bei beiden Konstellationen benötigen Sie die RFC-Bibliothek des RFC Software Development Kit
(RFC-SDK).
Kommunikation eines R/3-Systems mit einem Fremdsystem
R/3-System ALE Kommunikation

.
Stamm-
Anwendung Filterung Komm-
IDoc IDoc
Umsetzung
ALE-Schnittstelle
CALL FUNCTION ‘IDOC_INBOUND_ASYNCHRONOUS’
IN BACKGROUND TASK DESTINATION ...
TABLES IDOC_CONTROL_REC_40=...
IDOC_DATA_REC_40=...
tRFC
Implementierung
RFC
Fremdsystem Bibliothek
Daten Komm-
IDoc
Daten
Übersetzungsprogramm
Kommunikation eines Fremdsystems mit einem R/3-System
April 2001 183

Fremdsystem
Daten Komm.-
IDoc
Daten
Übersetzungs-
programm
tRFC
Implementierung RFC-Bibliothek
RfcRc = RfcIndirectCall( hRfc,

"IDOC_INBOUND_ASYNCHRONOUS",
Exporting, Tables,
TransID );
R/3-System Workflow-Anbindung IDOC_INBOUND_

ASYNCHRONOUS
Anwendungsfunktionen
Anwendungs-
Anwendungs-
Filterung Komm.-
daten Umsetzung IDoc
Ein Beispiel für eine IDoc-Schnittstelle zu Nicht-R/3-Systemen finden Sie in der

Dokumentation Schnittstellen zur mobilen Datenerfassung und
Lagersteuerrechnerkopplung [Extern].
· Die programmtechnische Realisierung finden Sie im ALE-

Programmierleitfaden [Extern].
· Die Anforderungen für die Zertifizierung von Schnittstellen finden Sie im
SAPnet unter http://www.sap.com/csp/scenarios.
Wählen Sie Cross Application, CA-ALE und CA-AMS.
184 April 2001

Übersetzungsprogramme für die Anbindung

Definition
Übersetzungsprogramme (Translators) sind Programme zum ALE-Anschluß von
Fremdsystemen, die von SAP zertifiziert werden müssen.
Verwendung
Übersetzungsprogramme führen typischerweise folgende Funktionen aus:
· Umsetzen der IDocs in beliebige Strukturen von Fremdsystemen/Kundensystemen
· Steuerung der Kommunikation, wie z.B. den Verbindungsaufbau und den -neustart.
Struktur
Zusammenspiel R/3-Translator-Fremdsystem
Anwendung ALE Kommuni- ALE/

kation EDI
Inter-
face
Anwendung Master
IDoc
Komm
Kommunikation
Doc IDoc
IDoc
Translator Nicht-
SAP-
System
ALE/
Workflow EDI
Inter-
Anwendungs face
funktion
Komm
Anwendungs- IDoc
daten
Integration
Übersetzungsprogramme werden von Fremdanbietern angeboten. SAP zertifiziert diese
Programme, um zu gewährleisten, daß die Kommunikation mit dem Fremdsystem über die ALE-
Schnittstelle und den Translator korrekt verläuft.
Die Zertifizierung prüft folgende Kriterien:
· Kann der Translator automatisch Strukturbeschreibungen von IDocs in sein eigenes
Repository übernehmen?
· Kann der Translator ein IDoc vom R/3 übernehmen und die Informationen entsprechend
seiner Repository-Daten interpretieren?
· Ist die Mapping-Funktionalität des Translators hinreichend mächtig?
· Ist der Translator in der Lage, das so erzeugte IDoc an das R/3 zurückzugeben?
Die Zertifizierung selbst nimmt keine Bewertung oder Kontrolle der im Programm angebotenen
Funktionalität vor.
April 2001 185

186 April 2001

Programmtechnische Realisierung
Programmtechnische Realisierung
In diesem Abschnitt erhalten Sie einen Überblick über die technische Realisierung einer
Anbindung.
Die Kommunikation basiert auf der SAP-Schnittstelle Remote Function Call (RFC).
Ab dem Release 3.0 können Daten zwischen R/3-Systemen und externen Programmen sicher
und zuverlässig über den transaktionalen Remote Function Call (tRFC) übertragen werden.
Der gerufene Funktionsbaustein wird im RFC-Server-System genau einmal ausgeführt. Das
entfernte System muß zu dem Zeitpunkt, in dem das RFC-Client-Programm einen tRFC ausführt,
nicht verfügbar sein. Die tRFC-Komponente speichert die gerufene RFC-Funktion zusammen mit
den zugehörigen Daten in der R/3-Datenbank unter einer eindeutigen Transaktionskennung
(TID).
Eine ausführliche Beschreibung zur RFC-Schnittstelle finden Sie in der Dokumentation, Remote
Communications [Extern].
Einzelheiten zu TCP/IP-Einstellungen finden Sie in BC - SAP-Kommunikation: Konfiguration
[Extern].
Der vorliegende Abschnitt gibt Ihnen einen Einblick in die Programmtechnik. Er erhebt keinen
Anspruch auf Vollständigkeit.
Wenn Sie selbst eine Anbindung realisieren möchten, sollten Sie unbedingt die weiterfürhrende
Dokumentation lesen.
April 2001 187

TCP/IP-Einstellungen
TCP/IP-Einstellungen
Als Voraussetzung für die Kommunikation müssen Sie folgende TCP/IP-Einstellungen
vornehmen:
· Damit das R/3-System den Zielrechner findet, müssen die TCP/IP Voraussetzungen
geschaffen sein, insbesondere die IP-Adressen in der jeweiligen Datei hosts bekannt sein.
· Der Name des Gateways und des Dispatchers in die Datei services eingetragen werden, z.B.
sapgw00 und sapdp00.
· Im R/3-System werden standardmäßig IDocs aus der Verbuchung heraus versendet. Daher
muß der TCP/IP-Link auch für die Verbuchungsmaschine erzeugt werden.
· Das SAP-Gateway muß das Recht haben, das externe Programm (RFC-Server) über
Remote Shell zu starten.
Ab Release 3.0C kann im Registriermodus gearbeitet werden. Dabei bleibt die Verbindung
zwischen Fremdsystemprogramm und Gateway offen (siehe Registering Server Programs
with the SAP Gateway [Extern] in The RFC API).
Einzelheiten zu den TCP/IP-Einstellungen finden Sie in der Dokumentation BC - SAP-
Kommunikation: Konfiguration [Extern].
188 April 2001

Senden von IDocs an ein Fremdsystem

Das folgende Schaubild verdeutlicht die Programmablauflogik.
ABAP-Programm
ABAP-Programm
ABAP-Programm
…
…
call
callfunction
function‘IDOC_INBOUND_ASYNCHRONOUS‘
‘IDOC_INBOUND_ASYNCHRONOUS‘ TCP/IP-Verbindungen
TCP/IP-Verbindungen
TCP/IP-Verbindungen
ininbackground (Transaktion SM59)
backgroundtask
task (Transaktion SM59)
destination
destinationSubsystem
Subsystem
tables
tables RFC-Destination
RFC-Destination Subsystem
Subsystem
idoc_control_rec_40
idoc_control_rec_40==header
header
idoc_data
idoc_data_rec_40
_rec_40 ==segment
segment
…… Zielmaschine
Zielmaschine hs1022.wdf.sap-ag.de
hs1022.wdf.sap-ag.de
Programm
Programm /users/d11adm/tmp/wmtestl
/users/d11adm/tmp/wmtestl
Fremdprogramm
Fremdprogramm
wmtestl
wmtestl
rfc_handle
rfc_handle==RfcAccept(...);
RfcAccept(...);
… …
rfc_rc
rfc_rc==RfcInstallFunction(...);
RfcInstallFunction(...);
… … RFC-Library
/ /** RFC-Library
**function IDOC_INBOUND_ASYNCHRONOUS
function IDOC_INBOUND_ASYNCHRONOUS saprfc.h
saprfc.h
**/ / sapitab.h
sapitab.h
static
staticRFC_RC
RFC_RCidoc_
idoc_inbound_
inbound_asynchronous
asynchronous(RFC_HANDLE
(RFC_HANDLErfc_handle
rfc_handle) ) librfc.a
librfc.a/ /librfc.dll
librfc.dll/ /ntlibrfc.lib
ntlibrfc.lib…
…
char
char filenam1
filenam1 == “/users/d11adm/tmp/output1”;
“/users/d11adm/tmp/output1”;
……
…
…
Aus dem R/3 werden IDocs über den Aufruf eines der beiden folgenden Funktionsbausteine mit
einer Destination versendet:
· IDOC_INBOUND_ASYNCHRONOUS
Diesen Funktionsbaustein müssen Sie ab Release 4.0 verwenden. Er verarbeitet IDocs
in Satzarten, die zu 4.x gültig sind. Längere IDoc-Segmentnamen werden damit
unterstützt.
· INBOUND_IDOC_PROCESS
Diesen Funktionsbaustein müssen Sie in Releases vor 4.0 verwenden. Er verarbeitet
IDocs in Satzarten, die zu 3.x gültig waren. Aus Gründen der Abwärtskompatibiltät muss
er auch in 4.x verwendet werden können. Auch externe Programme müssen diesen
Funktionsbaustein unterstützen.
April 2001 189

Der Zusatz IN BACKGROUND TASK beim Funktionsaufruf kennzeichnet den transaktionalen

RFC.
Wie bei synchronen Aufrufen definiert der Parameter DESTINATION über eine Tabelle im R/3
die Zielmaschine und das Zielprogramm mit Pfad (Programmkontext) im fernen System.
Beachten Sie auch das ABAP-Testprogramm SRFCTEST.
Im Fremdsystem muß das in der SM59 gepflegte Zielprogramm existieren, welches seinerseits
eine Funktion mit dem Namen des Funktionsbausteinaufrufs beinhaltet.
Im R/3 werden die Anwendungsdaten in der internen Tabelle der Struktur EDI_DD40 (EDI_DD
vor 4.0) übergeben. Pro IDoc wird zusätzlich ein Kontrollsatz der Struktur EDI_DC40 (EDI_DC
vor 4.0) mit den Verwaltungsdaten des IDocs mitgegeben. Im Beispiel werden diese Daten in
Form von internen Tabellen übergeben.
Weitere Informationen dazu finden Sie in der Dokumentation RFC-Programmierung in ABAP
[Extern].
Beispiele für tRFC-Programme finden Sie im RFC Software Development Kit (RFC-SDK):
· trfctest.c (Client-Programm)
· trfcserv.c (Server-Programm)
Einzelheiten zu den erforderlichen Funktionen finden Sie in der Dokumentation The RFC API
[Extern] oder in der Dokumentation des RFC-SDK.
Diese Programme können Sie als Vorlage für Ihre eigenen Programme verwenden.
Zur Interpretation der Nutzdaten im IDoc brauchen Sie auch die Datenstrukturen der IDocs auf
C-Programmebene. Wenn Sie ein R/3-System zur Verfügung haben, können Sie sich direkt aus
der Transaktion WE60 (Dokumentation zu IDoc-Typen) eine Header-Datei des IDocs
generieren lassen.
190 April 2001

Senden von IDocs vom Fremdsystem an SAP

Das folgende Schaubild verdeutlicht die Programmablauflogik.
Externes
Externes Programm
Programm
(( Client
Client ))
……
/ /**
**Transaktionsverwaltung
TransaktionsverwaltungTIDTID) )
**/ / RFC
RFC -- Library
Library
rfc_rc
rfc_rc==RfcCreateTransID(...)
RfcCreateTransID(...)
… saprfc.h
saprfc.h
… sapitab.h
/ /** sapitab.h
**Aufruf librfc.a
librfc.a/ /librfc.dll
librfc.dll/ /ntlibrfc.lib
ntlibrfc.lib…
Aufrufdes
desFunktionsbausteins
FunktionsbausteinsIDOC_INBOUND_ASYNCHRONOUS
IDOC_INBOUND_ASYNCHRONOUS …
**/ /
rfc_rc
rfc_rc==RfcIndirectCall
RfcIndirectCall(handle,
(handle,
“IDOC_INBOUND_ASYNCHRONOUS”
“IDOC_INBOUND_ASYNCHRONOUS”
Exporting;
Exporting;Tables;TransID);
Tables;TransID);
…
…
SAP
SAP -- Funktionsbaustein
Funktionsbaustein
IDOC_
IDOC_ INBOUND_
INBOUND_ ASYNCHRONOUS
ASYNCHRONOUS::
(( Server
Server ))
Lokale
LokaleSchnittstelle:
Schnittstelle:
TABLES
TABLES
IDOC_CONTROL_REC_40
IDOC_CONTROL_REC_40 STRUCTURE
STRUCTUREEDI_DC40
EDI_DC40
IDOC_DATA _REC_40
IDOC_DATA _REC_40 STRUCTURE
STRUCTUREEDI_DD40
EDI_DD40
Remote
RemoteFunction
FunctionCall
Callunterstützt
unterstützt
Aufgabe:
Aufgabe:
IDOCs
IDOCsverbuchen
verbuchen
Verarbeitung
Verarbeitunganstoßen
anstoßen
Das aufrufende, externe Programm verwendet die folgenden Funktionen des RFC Software
Development Kit (RFC-SDK):
· RfcOpen
Mit diesem Aufruf wird eine RFC-Verbindung zum Server-System aufgebaut. Die
Anmeldung am SAP-System inklusive Servername des SAP-Zielrechners, SAP-Logon,
Benutzer, Kennwort, etc. können Sie im C-Programm oder in der Datei saprfc.ini
definieren.
Nach dem Verbindungsaufbau zum Server-System müssen im Client-Programm die beiden
folgenden Funktionen für den tRFC aufgerufen werden:
· RfcCreateTransID
Mit diesem Aufruf wird die Transaktionskennung (TID) ermittelt, die im Server-System
angelegt wurde.
April 2001 191

· RfcIndirectCall
Mit diesem Aufruf werden die RFC-Daten zusammen mit der TID an das Server-System
übermittelt.
Im Fehlerfall wiederholt das Client-Programm diesen Aufruf.
Dabei muss es mit dem Aufruf RfcCreateTransID die alte TID verwenden. Andernfalls ist
nicht sichergestellt, dass die RFC-Funktion nur ein einziges Mal im R/3-System ausgeführt
wird.
Nach der erfolgreichen Ausführung dieses Aufrufs wird die Transaktion beendet. Das
aufrufende Programm kann dann seine eigene TID-Verwaltung aktualisieren (z.B. den TID-
Eintrag löschen).
Weitere Informationen finden Sie in der Dokumentation The RFC API [Extern] oder in der
Dokumentation des RFC-SDK..
Die Nutzdaten sind in IDoc-Form aufzubereiten und in eine interne Tabelle der Struktur
EDI_DD40 (EDI_DD vor 4.0) zu stellen. Pro IDoc muß auch der Kontrollsatz aufgebaut und in
eine interne Tabelle der Struktur EDI_DC40 (EDI_DC vor 4.0) gestellt werden. Auch die Form
der Datenübergabe ist in der Dokumentation beschrieben.
192 April 2001

Verwaltung von Transaktionsidentifikatoren (TID)

Um die Sicherheit der zu übertragenden Daten zu gewährleisten, muß mit einer eindeutigen
Kennung für einen Kommunikationsvorgang gearbeitet werden. Anhand dieser Kennung kann
das empfangende System entscheiden, ob diese Daten bereits empfangen und bearbeitet
wurden.
Beispielsweise könnte bei der mobilen Erfassung von Wareneingängen während des
Versendens der Daten die Kommunikation zusammenbrechen. Der Bearbeiter würde
nochmals die Daten versenden, um ihre Verbuchung im SAP-System
sicherzustellen. Wenn aber die Daten bereits beim erstmaligen Senden im SAP-
System empfangen und verarbeitet wurden, muß das System dies erkennen können.
Es darf die Daten nicht nochmals verarbeiten.
Aus diesem Beispiel ergibt sich zwangsläufig folgender schematischer Ablauf zwischen Sende-
und Empfangssystem.
Sender
Sender Empfänger
Empfänger
( (Client
Client) ) ( (Server
Server) )
TID
TIDerzeugen
erzeugen//holen
holen
(weltweit
(weltweiteindeutige
eindeutigeNummer)
Nummer)
TID
TIDmit
mitzu
zuübertragenden
übertragenden
Datensätzen
Datensätzensichern
sichern
Call
Callauf
aufden
denServer:
Server: Sichern
Sichernvon
vonDaten
Daten
Übertragen
Übertragenvon
von und
undTID
TID
Daten
Datenund
undTID
TID
Bestätigung
Bestätigung Bestätigung:
Alles
Alleso.k.
o.k. Bestätigung:
nicht
nichto.k. Daten
o.k. Status
Status DatenEmpfangen
Empfangen
fortschreiben
fortschreiben
Nochmals
Nochmals TID
TIDund
undDaten
Daten Prüfung:
Prüfung:TID
TIDschon
schon
versenden
versenden sofort
sofortoder
oder vorhanden
vorhanden//bearbeitet?
bearbeitet?
mit
mitgleicher
gleicher später
späterlöschen
löschen
TID
TID
Ja
Ja Nein
Nein
nichts
nichtstun
tun Daten
Datenverarbeiten
verarbeiten
Status
StatusTID
TID
fortschreiben
fortschreiben
April 2001 193

194 April 2001

Integration von Dialogschnittstellen

Verwendung
Der Datenaustausch in einem Verteilungsszenario findet im wesentlichen ohne
Benutzerinteraktion statt.
In einigen Fällen ist es jedoch sinnvoll, auch Dialogschnittstellen remote aufzurufen. Ein
typisches Beispiel ist das Anzeigen eines Ursprungsbelegs zu einem Beleg, der in einem
anderen System liegt.
Das HR leitet Abrechnungsergebnisse in das Rechnungswesen weiter. Dort werden

entsprechende Belege gebucht. Jeder Beleg im Rechnungswesen referenziert auf
den Ursprungsbeleg im HR. Im integrierten System ist die Beleganzeige im
Rechnungswesen so programmiert, daß man in die Beleganzeige des
Ursprungsbelegs im HR springen kann.
Falls nun HR und Rechnungswesen auf unterschiedlichen Systemen laufen, ist es
nicht sinnvoll, daß das Rechnungswesen die Daten über ein BAPI liest und die
Beleganzeige des HRs noch einmal nachprogrammiert. Statt dessen wird die
Beleganzeige des HR remote aufgerufen.
Dialogschnittstellen werden nicht an Stelle von BAPIs angeboten, sondern zusätzlich zu den
BAPIs. Zu jeder Dialogschnittstelle wird empfohlen, ein entsprechendes BAPI anzubieten, das
die Daten als dunkle Schnittstelle zurückliefert.
Zur Zeit sind Dialogschnittstellen primär für Anzeigefunktionalitäten in R/3-R/3-
Verteilungsszenarien vorgesehen. Dialogmethoden mit Änderungsfunktionalität werden
gegenwärtig nicht unterstützt.
Prinzipiell können Dialogschnittstellen auch von externen Plattformen aus aufgerufen werden.
Vorgehensweise
Der Remote-Aufruf von Dialogfunktionalität erfolgt über den RFC. Per RFC können Bilder
übertragen werden.
Eine Dialogmethode wird durch einen RFC-fähigen Funktionsbaustein implementiert. In diesem
Funktionsbaustein wird dann der Dialog aufgerufen.
Dieser Funktionsbaustein muß die gleichen Qualitätsanforderungen erfüllen wie der
Funktionsbaustein für ein BAPI:
· englische Feld- und Parameternamen
· keine Ausnahmen, sondern einen Rückgabeparameter,
· Dokumentation ist vorhanden
· Die Schnittstelle ist eingefroren.
Der Funktionsbaustein wird im BOR modelliert. Dabei gelten die gleichen Regeln wie für BAPIs
bis auf zwei Ausnahmen:
· Der Funktionsbaustein wird nur intern freigegeben
April 2001 195

· Für die Objektmethode muß das Dialog-Flag gesetzt werden.

Eine Dialogmethode wird wie ein BAPI im BOR als API-Methode angelegt. Dadurch ist
gewährleistet, daß das notwendige Coding im BOR generiert wird und die Dialogmethode auch
über die BOR-Laufzeitumgebung gerufen werden kann. Bei nachträglichen Änderungen an einer
Dialogmethode ist wie bei BAPIs darauf zu achten, daß das BOR-Coding nachgezogen wird.
Eine Dialogmethode muß über die BOR-Laufzeitumgebung aufrufbar sein.
Durch die interne Freigabe wird signalisiert, daß diese Methode für R/3-R/3-Szenarien gedacht
ist. Das API-Flag deutet an, daß diese Methode remote aufrufbar ist. Das Dialog-Flag ist gesetzt,
da es sich um eine Dialogschnittstelle handelt und nicht um eine dunkle Schnittstelle. Das
Dialog-Flag grenzt Dialogmethoden von den BAPIs ab.
· Bei Impelementation einer Objektanzeige ist darauf zu achten, daß man

nicht in den Änderungsmodus springen kann.
· Zur Zeit gibt es technische Probleme, wenn man nicht einen vollständigen
Bildschirm, sondern nur ein Popup remote aufrufen will.
· Wenn mit Reports gearbeitet wird, muß der Befehl submit... and
return verwendet werden. Ein einfaches submit... ist nicht möglich.
Namensgebung für Dialogmethoden

Jeder Objekttyp im BOR verfügt über die Methode Display. In vielen Fällen ist sie aber nicht
implementiert. Falls es es sich bei der zu implementierenden Dialogmethode um eine Anzeige
des Objekts handelt, sollte Display verwendet werden, sofern dies möglich ist.
Wenn Display bereits implentiert ist und sich durch die BAPI-Qualitätsanforderungen
inkompatible Änderungen ergäben, muß eine andere Methode verwendet werden.
Abgesehen von der Display-Methode gilt die Empfehlung, für die Dialogmethoden das Suffix
WithDialog bei der Modellierung im BOR zu verwenden.
Aufruf von Dialogmethoden

Aus einem R/3-System werden Dialogmethoden analog zu den BAPIs per RFC aufgerufen.
Zu unterscheiden sind zwei Arten des Aufrufs.
· Aufruf mit Referenz auf logisches System [Seite 198]
· Aufruf ohne Referenz auf das logische System [Seite 200]
Das logische System muß aus dem Verteilungsmodell ermittelt werden.
Die Beispiele erheben nicht den Anspruch, für alle denkbaren Aufrufsituationen
geeignet zu sein. Gerade für die Fehlerbehandlung kann kein generelles Vorgehen
empfohlen werden, da sie von der jeweiligen Anwendung und der Aufrufsituation
abhängen kann. Bevor Sie einen Aufruf einer Dialogmethode in Ihr Coding einbauen,
sollten Sie sich die Fehlerbehandlung gründlich überlegen.
Wenn z. B. für ein Server-System keine Destination für Dialogaufrufe ermittelt
werden kann, kann dies auch daran liegen, daß dieser Server aus technischen
Gründen oder wegen Sicherheitsbedenken keine Dialogfunktionalität zur Verfügung
196 April 2001

stellt. Diese Situation kann durchaus auch in produktiven Systemen auftreten. Man
kann dies nicht als inkonsistent konfiguriertes System interpretieren.
Weiterhin sollten Sie beachten, daß der RFC-Aufruf implizit einen Datenbank-
Commit absetzt, d. h., die LUW wird beendet. Wenn Sie keine Erfahrung mit RFC-
Aufrufen haben, sollten Sie die Online-Hilfe zum ABAP-Sprachelement call
function mit dem Zusatz destination lesen.
April 2001 197

Aufruf mit Referenz auf logisches System

entsprechende Belege gebucht. Jeder Beleg im Rechnungswesen referenziert auf
den Ursprungsbeleg im HR. Die Referenz enthält auch das logische System, auf
dem der HR-Beleg erzeugt worden ist.
Die zu rufende Methode heißt beispielsweise HRDoc.Display. Die Kennung des Referenzbelegs
im HR steht im Feld BKPF-AWREF und das logische System im Feld BKPF-AWSYS.
Der Aufruf der HR-Beleganzeige aus der Beleganzeige im Rechnungswesen ist wie folgt zu
implementieren:
...
DATA:
HEAD LIKE BKPF,
RETURN LIKE BAPIRET2,
SERVER_DEST LIKE TBLSYSDEST-RFCDEST,
MSG_TXT(80) TYPE C.
...
* get RFC-Destination for remote method call
CALL FUNCTION 'OBJ_METHOD_GET_RFC_DESTINATION'

EXPORTING
OBJECT_TYPE = 'HRDOC'
METHOD = 'DISPLAY'
LOGICAL_SYSTEM = HEAD-AWSYS
IMPORTING
RFC_DESTINATION = SERVER_DEST
EXCEPTIONS
NO_RFC_DESTINATION_MAINTAINED = 1
ERROR_READING_METHOD_PROPS = 2
OTHERS = 3.
IF SY-SUBRC <> 0.
IF SY-SUBRC = 1.
* application specific message saying document can't be displayed
...
ELSE.
* hard error
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
ENDIF.
* call display function. If SERVER_DEST is initial, it's a local

call.
CALL FUNCTION 'BAPI_HRDOC_DISPLAY'
DESTINATION SERVER_DEST
EXPORTING
198 April 2001

DOCUMENT_ID = HEAD-AWREF
IMPORTING
RETURN = RETURN
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG_TXT
SYSTEM_FAILURE = 2 MESSAGE MSG_TXT.
IF SY-SUBRC <> 0.
* handle remote exceptions
MESSAGE E777(B1) WITH
'HRDoc.Display' HEAD-AWSYS HEADER-AWSYS
MSG_TXT(50) MSG_TXT+50(30).
ELSEIF NOT RETURN-TYPE IS INITIAL.
* handle return parameter
...
ENDIF.
Die Nachricht B1 777 ist eine generische Nachricht. Statt dessen kann auch eine
applikationsspezifische Nachrichten verwendet werden.
April 2001 199

Aufruf ohne Referenz auf das logische System

entsprechende Belege gebucht. Das HR hat keine Referenz auf den entstandenen
Beleg im Rechnungswesen.
Die zu rufende Methode heißt beispielsweies ACDoc.Display. Für ACDoc.Display gibt es keine
Filterobjekte. Die Kennung des HR-Belegs steht im Feld HRKPF-DOCNR.
Da das logische System nicht aus dem Kontext bekannt ist, muß das logische Zielsystem aus
dem Verteilungsmodell ermittelt werden.
Der Aufruf der Beleganzeige im Rechnungswesen aus der HR-Beleganzeige ist wie folgt zu
implementieren:
...
DATA:
HEAD LIKE HRKPF,
SERVER LIKE BDBAPIDEST,
RETURN LIKE BAPIRET2,
MSG_TXT(80) TYPE C,
FILTER_VALUES LIKE BDI_FOBJ OCCURS 0 WITH HEADER LINE.
...
* get logical system and RFC-Destination for remote method call
* no filter objects are used

REFRESH FILTER_VALUES.
* get server system from ALE distribution model

CALL FUNCTION 'ALE_BAPI_GET_UNIQUE_RECEIVER'
EXPORTING
OBJECT = 'ACDOC'
METHOD = 'DISPLAY'
IMPORTING
RECEIVER = SERVER
TABLES
FILTEROBJECTS_VALUES = FILTER_VALUES.
EXCEPTIONS
ERROR_IN_FILTEROBJECTS = 1
ERROR_IN_ALE_CUSTOMIZING = 2
NOT_UNIQUE_RECEIVER = 3
NO_RFC_DESTINATION_MAINTAINED = 4
OTHERS = 5.
IF SY-SUBRC <> 0.
IF SY-SUBRC = 4.
* application specific message saying document can't be displayed
...
ELSE.
* hard error
200 April 2001

MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO

WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
ENDIF.
* call display function. If SERVER_DEST is initial, it's a local call.

CALL FUNCTION 'BAPI_ACDOC_DISPLAY'
DESTINATION SERVER-RFCDEST
EXPORTING
DOCUMENT_ID = HEAD-DOCNR
IMPORTING
RETURN = RETURN
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG_TXT
SYSTEM_FAILURE = 2 MESSAGE MSG_TXT.
IF SY-SUBRC <> 0.
* handle remote exceptions
MESSAGE E777(B1) WITH
'HRDoc.Display' HEADER-AWSYS MSG_TXT(50) MSG_TXT+50(30).
ELSEIF NOT RETURN-TYPE IS INITIAL.
* handle return parameter
...
ENDIF.
Dieses Beispiel verwendet keine Filterobjekte. Wenn Filterobjekte für die zu rufende
Objektmethode vorhanden sind, muß die Abfrage des Verteilungsmodells
dementsprechend geändert werden.
April 2001 201

Serialisierung von Nachrichten
Serialisierung von Nachrichten

Verwendung
Serialisierung spielt eine wichtige Rolle bei der Verteilung von voneinander abhängigen
Objekten, insbesonders bei Stammdaten.
Durch eine serialisierte Verteilung von Nachrichten wird eine bestimmte Reihenfolge bei der
Erzeugung, Versendung und Verbuchung der entsprechenden IDocs eingehalten.
Dadurch werden Fehler bei der Eingangsverarbeitung der IDocs vermieden.
Funktionsumfang
Für eine serialisierte Verteilung voneinander abhängiger Nachrichten stehen Ihnen folgende
Möglichkeiten zu Verfügung:
· Serialisierung über Objekttypen [Extern]
· Serialisierung über Nachrichtentypen [Seite 119]
· Serialisierung auf IDoc-Ebene [Seite 206]
(nicht für IDocs von generierten BAPI-ALE-Schnittstellen)
202 April 2001


Verwendung
Serialisierte Nachrichten können unterschiedlicher Art sein (z.B. Anlege-, Änderungs-,
Stornierungsnachricht). Alle betrachteten Nachrichten beziehen sich jedoch auf ein einziges
spezielles Anwendungsobjekt.
Die Nachrichten können sowohl Stamm- als auch Bewegungsdaten enthalten.
Mit der Objektserialisierung wird sichergestellt, daß die Reihenfolge dieser Nachrichten bezüglich
eines bestimmten Objektes auf der Empfängerseite immer gewahrt bleibt, d.h. die
Buchungsreihenfolge auf der Empfängerseite der auf der Senderseite festgelegten Reihenfolge
entspricht.
Voraussetzungen
Die serialisierte Verteilung müssen Sie in beiden Systemen per Customizing aktivieren:
Werkzeuge ® AcceleratedSAP ® Customizing ® Projektbearbeitung
SAP Referenz-IMG
Basis
Application Link Enabling (ALE)
Funktionsumfang
Der zu übertragenden Nachricht (IDoc) wird eine fortlaufende Nummer zugewiesen. Diese wird
im Sender- und im Empfängersystem pro Objekttyp und Objektkanal verwaltet. Ein Objektkanal
enthält eine logische Menge reihenfolgesortierter IDocs und definiert sich über einen Objekttypen
(BOR) und genau eine Kanalnummer, die ein Attribut zu Nachrichten ist. In einem Objektkanal
werden alle Nachrichten im Zielsystem in der gleichen Reihenfolge bearbeitet, wie sie im
Quellsystem entstanden sind. Eine Kanalnummer ist ein Attribut zu Nachrichten. Sie wird über
den Funktionsbaustein ALE_SERIAL_KEY2CHANNEL generiert oder im Anwendungsprogramm
vergeben.
Anhand dieser Nummer werden folgende Situationen erkannt:
· RFC-Übertragungsfehler
· Der Anwendungsbeleg zu einer Nachricht ist noch nicht gebucht (Statuscode 53), obwohl die
nachfolgende Nachricht bereits eingetroffen ist
In beiden Fällen wartet das IDoc im Eingang auf sein Vorgänger-IDoc und erhält zu diesem
Zweck den Statuscode 66. Nachdem das Vorgänger-IDoc gebucht wurde, müssen Sie das IDoc
im Status 66 mit dem Programm RBDAPP01 nachträglich buchen.
Alle Nachrichten, deren Kanalnummer und Objekttyp identisch sind, werden bei der Aktivierung
serialisiert.
April 2001 203

Zu jedem Objektkanal wird der aktuelle Nummernstand vermerkt. Dieser Vorgang wird als
Registratur bezeichnet. Es gibt je eine Registratur im Ausgang und im Eingang. Dort muß die
Serialisierung jeweils aktiviert werden (siehe Voraussetzungen).
Auf der Ausgangsseite (Im Quellsystem)

Auf der Ausgangsseite wird pro Objektkanal (Feld CHNUM) und Kommunikationsbeziehung eine
eindeutige, fortlaufende Nummer verwaltet, die pro erzeugtem IDoc hochzählt (Feld CHCOU).
Der Objektkanal und diese Nummer wird dem IDoc im Feld SERIAL mitgegeben.
Jeder beteiligten Nachricht wird eine für das betreffende Anwendungsobjekt eindeutige
fortlaufende Nummer zugeordnet.
Auf der Eingangsseite (Im Zielsystem)

Auch auf der Eingangsseite wird pro Objektkanal und Kommunikationsbeziehung eine laufende
Nummer verwaltet. Es wird ermittelt, ob ein bestimmtes IDoc an der Reihe ist, oder ob zuvor
andere IDocs gebucht werden müssen. Pro empfangenem Idoc muß die laufende Nummer
genau um 1 niedriger sein. Ansonsten fehlen Idocs, entweder, weil die Übertragung fehlerhaft
war oder weil ein Vorgänger nicht fehlerfrei gebucht werden konnte.
In diesem Fall wird das IDoc in den Status 66 versetzt und muß später mit dem Programm
RBDAPP01 nachgebucht werden.
Die Zuordnung von Objekten zu Nachrichten und Kanälen wird durch die Anwendung
vorgegeben.
Übertragungsfehler (Vertauschen der Reihenfolge) und Buchungsfehler im Eingang (IDoc nicht
buchbar wegen Customizing-Fehlern) können die ursprüngliche Reihenfolge nicht mehr
beeinflussen, da die Serialisierung diese Fehler korrigiert.
204 April 2001


Verwendung
Durch eine serialisierte Verteilung der Nachrichtentypen wird eine bestimmte Reihenfolge bei der
Erzeugung, Versendung und Verbuchung der entsprechenden IDocs eingehalten.
Die Abhängigkeit zwischen Objekten wird auf Nachrichtentyp-Ebene berücksichtigt.
Ein Beispiel ist der Einkaufsinfosatz mit Lieferant und Material. Auf dem
Empfängersystem müssen der Lieferant und das Material vor dem Einkaufsinfosatz
angelegt werden, um einen Verbuchungsfehler zu vermeiden.
Voraussetzungen
Die serialisierte Verteilung der Nachrichtentypen müssen Sie in beiden Systemen per
Customizing aktivieren.
Basis
Verteilung (ALE)
Funktionsumfang
Die serialisierte Verteilung wird nur für die Übertragung von Änderungen der Stammdaten
unterstützt. Die Nachrichtentypen der IDocs werden in der vorgesehenen
Übertragungsreihenfolge in einer Serialisierungsgruppe zusammengefaßt. In genau dieser
festgelegten Reihenfolge erfolgt auch die Verteilung der Stammdaten. Sind alle IDocs der
Serialisierungsgruppe erfolgreich versendet worden, so wird vom Sendesystem eine spezielle
Steuernachricht an die Empfängersysteme versendet. Diese Steuernachricht enthält die
Verbuchungsreihenfolge der IDocs und startet die Eingangsverarbeitung der IDocs auf den
Empfängersystemen.
Die serialisierte Verteilung von Nachrichtentypen stellt keine vollkommen neue Art der
Stammdatenverteilung dar, sondern nutzt bereits vorhandene ALE-Mechanismen der Verteilung
unter Beachtung einer bestimmten Reihenfolge der Nachrichtentypen. Diese Verteilung könnte
auch manuell durch die Ausführung vorhandener ALE-Reports durchgeführt werden. Mittels der
serialisierten Verteilung werden diese Einzelschritte jedoch automatisiert und über Batch-Jobs
einplanbar.
Die Menüoberfläche der Serialisierung gestattet die Auswahl von Selektionskriterien, die den
Ablauf der serialisierten Verteilung bestimmen. Dazu gehören z.B. das Versenden der
Steuernachricht und die Eingangsverarbeitung der IDocs.
April 2001 205

Serialisierung auf IDoc-Ebene
Serialisierung auf IDoc-Ebene

Verwendung
Verzögerungen in der Übertragung von IDocs können bewirken, daß ein IDoc mit Daten eines
Objektes vor einem "älteren" IDoc mit unterschiedlichen Daten des gleichen Objektes eintrifft.
Eine Anwendung kann das ALE-Serialisierung-API nutzen, um die zeitliche Reihenfolge von
IDocs eines Nachrichtentyps zu erkennen und bei Überholungen die Verbuchung alter Daten zu
verhindern.
Es wird Ihnen dringend empfohlen, regelmäßig das Programm RBDSRCLR zur Bereinigung der
Tabelle BDSER (alte Zeitstempel) einzuplanen.
Voraussetzungen
Die Serialisierung auf IDoc-Ebene ist nicht möglich für IDocs von generierten BAPI-IDoc-
Schnittstellen, da der Funktionsbaustein zur Eingangsverarbeitung das ALE-Serialisierungs-API
nicht nutzt.
Funktionsumfang
ALE stellt zwei Funktionsbausteine zur Serialisierung von IDocs bereit, die vom verbuchenden
Funktionsbaustein aufgerufen werden müssen:
· IDOC_SERIALIZATION_CHECK
Zum Prüfen von Zeitstempeln im Serialisierungsfeld des IDoc-Kopfes
· IDOC_SERIAL_POST
Zum Aktualisieren der Serialisierungtabelle.
206 April 2001

Automatische Tests
Automatische Tests
Die Qualität der ALE-Schicht und der ALE-Geschäftsprozesse können Sie durch automatische
Tests verifizieren.
Obwohl manuelle Tests dadurch nicht ersetzt werden können, können Sie zumindest die
grundlegende Funktionalität der ALE-Geschäftsprozesse überprüfen. Dies ist insbesondere für
Upgrade-Tests sinnvoll, die regelmäßig ohne manuellen Aufwand durchgeführt werden sollen.
Auch das notwendige Customizing der logischen Systeme kann automatisiert werden, so daß die
anschließenden manuellen Tests vereinfacht und beschleunigt werden.
Die automatischen Tests werden komplett im R/3 mit Hilfe der CATT-Umgebung entwickelt. Sie
bestehen im wesentlichen aus Testabläufen und Testbausteinen. Einzelheiten dazu finden Sie in
der Dokumentation CA - Computer Aided Test Tool [Extern].
Diese Anleitung betrifft alle Anwendungen, die für ein oder mehrere ALE-Geschäftsprozesse
verantwortlich sind. Grundkentnisse über die Entwicklung von CATT-Bausteinen werden
vorausgesetzt.
Die Testbausteine und Abläufe sollten auf IDES-Daten aufbauen, so daß sie in einem frisch
aufgebautem Testsystem ohne manuelle Eingriffe regelmäßig gestartet werden können.
April 2001 207

Beispielszenario zur Stammdatenverteilung
Beispielszenario zur Stammdatenverteilung

Die Vorgehensweise zur Erstellung eines Testablaufs wird am Beispielszenario der Verteilung
von Stammdaten via ALE erläutert. Das Schema für Bewegungsdaten ist im wesentlichen analog
hierzu, jedoch werden die Abläufe eventuell umfangreicher, da mehrere Nachrichten zwischen
den verschiedenen logischen Systemen fließen.
Aufbau eines ALE-Szenarios

Bei der Verteilung von Stammdaten (Material, Kostenstelle, etc.) wird ein Stammdatum in einem
zentralen R/3-System angelegt bzw. geändert und anschließend in Form eines IDocs an ein
zweites dezentrales System versandt.
Dieses Szenario läßt sich in 4 Schritte unterteilen:
Anwendung
1. Anlegen/Ändern des Stammdatums
2. Erzeugen des IDocs
ALE-Schicht
3. Versenden des IDocs
4. Einbuchen des IDocs
Anwendung
208 April 2001

Test vorbereiten
Test vorbereiten
Bevor durch einen Testablauf ein ALE-Szenario überprüft werden kann, muß das Customizing
der ALE-Schicht durchgeführt werden. Dies sollte durch einen Vorspann-CATT-Ablauf
geschehen, der auf das bestehende IDES-Customizing aufbaut. Dafür steht der Testbaustein
P3013119 zur Verfügung. Dieser Baustein erweitert das Verteilungsmodell und legt
Partnervereinbarungen für die Nachrichtentypen an.
Zusätzlich müssen Sie aus dem System, in dem der Testablauf gestartet wird, RFC-
Verbindungen zum zentralen und dezentralen System anlegen, da beide Systeme während des
Ablaufs angesprungen werden.
Testbaustein P3017940
Der Testbaustein P3017940 besteht selbst wieder aus einer Reihe von Test- und
Funktionsbausteinen:
Sprung ins sendende System

IDocnummer finden: FB GET_IDOCNR_FROM_OBJECT
IDoc versenden: TB P3015649
IDocstatus lesen: FB GET_STATUS_FROM_IDOCNR
IDocstatus umsetzen: TB P3013115
Sprung ins empfangende System

IDconummer finden: FB GET_IDOCNR_FROM_IDOCNR
IDoc einbuchen: TB P3013464
Beispiele
Der Testablauf P3013121 ist ein Beispiel für einen Stammdatenverteilungsprozeß, P3017156 für
einen komplexen Prozeß mit Bewegungsdaten.
In beiden Prozessen wird der Baustein P3017940 eingesetzt.
April 2001 209

Testablauf entwickeln
Testablauf entwickeln
Ein Testablauf besteht aus 3 Abschnitten.
1. Stammdatum anlegen/ändern und IDoc erzeugen
2. Testbaustein P3017940 ausführen
(IDoc versenden, einbuchen und jeweiligen Status prüfen)
3. Stammdatum prüfen, das aus dem IDoc entstandenen ist
Ablaufschema
Der Testablauf eines ALE-Szenarios zur Stammdatenverteilung besteht aus den folgenden
Testbausteinen:
Sendendes System
Erzeugen/ Ändern eines

Stammdatums
Startsystem des CATTs Erzeugen des IDocs
Testablauf ALE-Szenario
Versenden des IDocs
Testbaustein Anwendung Prüfen des IDocstatus
IDoc
Testbaustein P3017940
Empfangendes System
Testbaustein Anwendung
Einbuchen des IDocs
Prüfen des IDocstatus
Prüfen des Stammdatums

...
Für die Schritte der ALE-Schicht steht der Testbaustein P3017940 zur Verfügung, der für alle
Szenarien benutzt werden kann, in denen von der Anwendung Objektverknüpfungen erstellt
werden.
Dieser Testbaustein kann von jedem Testablauf aus lokal gerufen werden. Dabei sollten alle
210 April 2001

Remote-Aufruf eines Testbausteins
Importparameter mit Werten versehen werden.

Informationen zu Verknüpfungen sind in der Tabelle TBD14 hinterlegt.
Um einen Testbaustein in einem anderen System ablaufen zu lassen, müssen Sie im Ablauf
Remote-Aufruf
mit Strg/F2 eine RFC-Destination hinterlegen. Der Testbaustein muß auch im Zielsystem
existieren. Weitere Einzelheiten finden Sie in der Hilfe zu CATT.
April 2001 211

Fehlerbehandlung
Fehlerbehandlung
Die ALE-Fehlerbehandlung bedient sich der SAP Business Workflow-Technologie des R/3-
Systems.Der SAP Business Workflow organisiert und steuert einen Arbeitsprozess, indem
Aufgaben (Workitems) einzelnen Bearbeitern zugeordnet werden. Nach der Erledigung einer
Aufgabe wird der Bearbeiter einer nachfolgenden Aufgabe automatisch über den Eingang eines
Workitems informiert.
SAP Business Workflow ist objektorientiert, die Objekte der ALE-Fehlerbehandlung sind IDocs
und die auf ihnen definierten Methoden und Ereignisse.
Im Fehlerfall wird nur die erste Meldung aus dem Return-Parameter in den Text des
zugehörigen Workitems übernommen.
Ablauf der ALE Fehlerbehandlung
Benutzeraktion R/3 Aktion
Fehler im Eingangsfunktionsbaust.
ALE löst Fehlerereignis aus
inputErrorOccurred
Workitem erscheint im Eingang
Workitem ausführen
IDoc anzeigen für Eingangsverarb.

(IDoc Methode "InputForeground")
Fehler beheben und
wiedervorlegen; oder
IDoc zum Löschen vormerken
ALE löst Endergebnis aus
input Finished
Workitem erledigt
212 April 2001

Fehlerbehandlung
Zur Verdeutlichung der ALE-Fehlerbehandlung dient das Beispiel eines Fehlers in

der Eingangsverarbeitung eines Materialstamm-IDocs. Folgende Schritte laufen
dabei ab:
1. Der Funktionsbaustein im Eingang teilt der ALE-Schicht mit, daß ein Fehler
aufgetreten ist.
2. ALE löst das Ereignis "inputErrorOccurred" des Objekts vom Typ
IDOCMATMAS aus.
3. Dieses Ereignis ist an die Standardaufgabe Nummer 00007947 mit der
Bezeichnung "MATMAS_Eingangsfehler" gekoppelt.
4. Ein Workitem erscheint im Eingang des Benutzers, der Kurztext des
Workitems besteht aus den ersten 50 Zeichen der Fehlermeldung, die im
Statussatz des IDocs enthalten ist.
5. Wenn der Benutzer das Workitem bearbeitet, wird die IDOCMATMAS-
Methode "IDOC.InputForeground" ausgeführt.
Der Benutzer sieht den Statussatz des IDocs und kann den Langtext der
Fehlermeldung ansehen. Konnte der Benutzer den Fehler beheben, kann das
IDoc zur Verbuchung vorgelegt werden. Konnte der Fehler nicht behoben
werden, kann der Benutzer das IDoc zum Löschen kennzeichnen.
6. Wurde das IDoc erfolgreich vorgelegt oder zum Löschen vorgesehen, wird
das IDOCMATMAS-Ereignis "inputFinished" ausgelöst, das das Workitem
abschließt, d.h. anzeigt, daß die Aufagbe erledigt wurde.
April 2001 213

Anzulegende Objekte, Ereignisse und Aufgaben

Die Fehlerbehandlung für einen Nachrichtentyp, in diesem Falle XAMPLE, implementieren
Sie auf folgende Weise:
· Legen Sie im Business Object Repository (BOR) einen neuen Objekttyp IDOCXAMPLE
als Abkömmling des Objekttyps IDOCAPPL an. Kunden sollten den Namen
ZDOCXAMPLE verwenden.
· Legen Sie eine neue Standardaufgabe mit dem Namen "XAMPLE_Error" an.
· Legen Sie Ereigniskopplungen an, die das IDOCXAMPLE-Ereignis inputErrorOccurred
mit Ihrer Standardaufgabe verknüpfen, sowie das Ereignis inputFinished für den
Funktionsbaustein, um das Workitem abzuschließen.
In jedem Fall arbeiten Sie leichter, wenn Sie dazu einen vorhandenen Objekttyp oder eine
Standardaufgabe kopieren.
So stellen Sie eine vollständig ALE-kompatible Schnittstelle bereit:
· Legen Sie einen neuen Objekttyp IDPKXAMPLE als Abkömmling des Objekttyps
IDOCPACKET an. Kunden sollten den Namen ZDPKXAMPLE verwenden.
· Pflegen Sie Ihren Eingangsvorgangscode, um auf die obigen Objekte und Ereignisse
verweisen zu können.
Am Beispiel des Materialstammsatz-IDocs MATMAS wird die Erstellung der oben genannten
Objekte erläutert.
Die Attribute des Objekttyps IDOCMATMAS werden in der Definition der Standardaufgabe
verwendet, damit die Fehlermeldung und die Materialnummer im Workitemtext erscheinen.
Die Methoden und Ereignisse werden wie oben beschrieben eingesetzt.
Objektyp IDOCMATMAS:
Attribute, Methoden und Ereignisse, die für den Funktionsbaustein im Eingang relevant sind.
Name Aus IDOCAPPL Bedeutung

Attribute ShortMessage Ja Die ersten 50 Zeichen der IDoc-
Status-meldung
ApplicationObjectID Ja Kennung des ALE-Link-Objekts
im IDoc
Methode InputForeground Ja Verarbeitet IDoc beginnend mit
Statusanzeige
InputBackground Ja Verarbeitet IDoc ohne Dialog
Ereignis InputErrorOccurred Ja Ausgelöst, wenn direkte
Anwendungsübergabe scheitert;
nicht ausgelöst von den
Methoden InputForeground und
InputBackground
214 April 2001

InputFinished Ja Ausgelöst, wenn IDoc erfolgreich

verarbeitet wurde oder vom
Benutzer IDoc zum Löschen
gekennzeichnet
Beispiel für eine ALE-Fehlerbehandlung.

Die Pfeile verdeutlichen die drei Stadien:
1. Das Ereignis inputErrorOccurred erstellt ein Workitem.
2. Wenn der Benutzer das Workitem ausführt, wird die Methode
InputForeground aktiviert.
3. Wenn das IDoc erfolgreich verarbeitet oder zum Löschen gekennzeichnet
wurde, wird das Ereignis inputFinished ausgelöst, das das Workitem
beendet.
Standardaufgabe
00007946:
1 'MATMAS_Error'
Start-Ereignis Ende-Ereignis
Objektmethode
Objekt: Objekt: Objekt:

IDOCMATMAS IDOCMATMAS IDOCMATMAS
2
Ereignis: Methode: Ereignis:
InputErrorOccurred InputForeground InputFinished
Bevor Sie weiterlesen, sehen Sie sich den Objekttyp IDOCMATMAS im Business
Object Builder und die Standardaufgabe 7947 an.
Sowohl den Business Object Builder als auch die Standardaufgabe erreichen Sie
über den Menüpfad Werkzeuge ® Business Workflow ® Entwicklung und das Menü
Definitionswerkzeuge:
® Business Object Builder
® Aufgaben/Aufgabengruppen
April 2001 215

Einzelheiten hierzu finden Sie in der Hilfe zur Anwendung.
216 April 2001

Objekttypen und Ereignisse
Objekttypen und Ereignisse

Die Namenskonvention für die Objekttypen für Nachrichtentyp XAMPLE lautet IDOCXAMPLE
und IDPKXAMPLE. Diese Objekttypen werden im Business Object Repository erstellt, unter
Objekttyp IDOCAPPL bzw. IDOCPACKET. Die auszuführenden Schritte werden im folgenden
beschrieben.
Beim Anlegen eines Objekttyps fordert Sie das R/3-System auf, den Namen eines ihm
zugeordneten Reports anzugeben. Dieser wird ebenfalls angelegt. Die Reportnamen unterliegen
der üblichen Konvention, d.h. sie sollten im Kundennamensraum liegen und mit den Buchstaben
Y bzw. Z beginnen. Achten Sie darauf, daß Sie für jeden Objekttyp einen anderen Report
verwenden.
Die Objekttypen IDOCAPPL und IDOCPACKET enthalten Dokumentation zu ihren

Methoden und Ereignissen.
Siehe auch:
IDoc-Objekttyp IDOCXAMPLE anlegen [Seite 218]
IDoc-Paketobjekttyp IDPKXAMPLE anlegen [Seite 220]
April 2001 217

IDoc-Objekttyp IDOCXAMPLE anlegen

Zum Business Object Repository gelangt man vom R/3-Einstiegsbildschirm über den
Navigationspfad Werkzeuge ® Business Engineering ® Business Workflow ® Entwicklung und
die Schaltfläche Objektrepository.
In der Hierarchie gehen Sie über Anwendungsübergreifende Komponenten ® IDoc-Schnittstelle
/ Electronic Data Interchange ® IDOC ® IDOCAPPL zum Objekttyp IDOCMATMAS.
Kopieren Sie dann den Objekttyp IDOCMATMAS wie folgt:
1. Klicken Sie auf den Objekttyp IDOCMATMAS und wählen dann Kopieren.
2. Tragen Sie im folgenden Dialogfenster die Bezeichnung für den Objekttyp (z.B.
IDOCXAMPLE) und Ihren Report (z.B. RXAMPLE1) ein und wählen Sie dann Kopieren.
Die Namenskonvention für SAP ist IDOC<Nachrichtentyp>, z.B. IDOCXAMPLE
Die Namenskonvention für Kunden ist ZDOC< Nachrichtentyp > z.B. ZDOCXAMPLE
3. Tragen Sie im folgenden Dialogfenster Ihre Entwicklungsklassse ein.
Bearbeiten Sie den erstellten Objekttyp (z.B. IDOCXAMPLE) wie folgt:

1. Klicken Sie den Objekttyp (z.B. IDOCXAMPLE) an und wählen Sie dann Ändern.
2. Lassen Sie die im folgenden Dialogfenster angebotenen Optionen unverändert; wählen Sie
nur Enter.
3. Wählen Sie Grunddaten und ändern Sie den Kurztext und die Bezeichnung des Objekttyps
nach Ihren Bedürfnissen.
Die Namenskonvention für den Kurztext ist "IDOC <Nachrichtentyp>", z.B. "IDOC
XAMPLE".
Wählen Sie Zurück.
4. Ändern Sie die Beschreibung des Ereignisses inputFinished wie folgt: schauen Sie sich die
Ereignisse des Knotens Ereignisse an; wählen Sie das Ereignis inputFinished über
Doppelklick aus, ändern die Bezeichnung und wählen dann Enter.
5. Ändern Sie den Parameter Appl_Object des Ereignisses wie folgt: wählen Sie Springen ®
Obj. Typ-Komponenten ® Parameter, und wählen dann den Parameter Appl_Object über
Doppelklick aus. Ändern Sie den Objekttyp von BUS1001 zu dem Objekttyp, der von Ihrem
Funktionsbaustein im Eingang verarbeitet wurde. Ändern Sie dann auch den Kurztext und
die Bezeichnung.
Falls es für Ihren Funktionsbaustein im Eingang keinen geeigneten

Anwendungsobjekttyp gibt, löschen Sie den Parameter Appl_Object anstatt ihn zu
ändern. Klicken Sie dazu auf den Parameter Appl_Object und wählen Sie dann
Löschen anstatt den Parameter über Doppelklick auszuwählen.
· Wählen Sie Zurück und sichern Sie den Objekttyp (Objekttyp ® Sichern o. Prüfen).
218 April 2001

· Wählen Sie Generieren, um den Objekttyp zu generieren.

· Geben Sie den Objekttyp wie folgt frei: Kehren Sie zur BOR-Hierarchie zurück und wählen
dann Objekttyp ® Freigeben.
Sie haben die Möglichkeit, einen weiteren Parameter Application_Variable dem Container des
Ereignisses inputFinished hinzuzufügen. Diese Variable enthält die Werte des Export-
Parameters Application_Variable des Funktionsbausteins im Eingang. Als Beispiel sehen Sie
sich den Objekttyp IDOCORDERS an.
April 2001 219

IDoc-Paketobjekttyp IDPKXAMPLE anlegen
IDoc-Paketobjekttyp IDPKXAMPLE anlegen

Gehen Sie in der Hierarchie über Anwendungsübergreifende Komponenten ® IDoc-Schnittstelle
/ Electronic Data Interchange ® IDOCPACKET zum Objekttyp IDPKMATMAS.
Kopieren Sie den Objekttyp IDPKMATMAS wie folgt:
1. Klicken Sie den Objekttyp IDPKMATMAS an, und wählen Sie dann Kopieren.
2. Tragen Sie im folgenden Dialogfenster die Bezeichnung für den Objekttyp (IDPKXAMPLE)
und Ihren Report (RXAMPLE2) ein und wählen Sie dann Kopieren.
Die Namenskonvention für SAP ist IDOC<Nachrichtentyp>, z.B. IDPKXAMPLE
Die Namenskonvention für Kunden ist ZDOC< Nachrichtentyp > z.B. ZDPKXAMPLE
3. Tragen Sie im folgenden Dialogfenster Ihre Entwicklungsklassse ein
Bearbeiten Sie den erstellten Objekttyp (IDPKXAMPLE) wie folgt:

1. Klicken Sie den Objekttyp (IDPKXAMPLE) an, und wählen Sie dann Ändern.
2. Lassen Sie die im folgenden Dialogfenster angebotenen Optionen unverändert, wählen Sie
nur Enter.
3. Wählen Sie Grunddaten und ändern Sie den Kurztext und die Bezeichnung des Objekttyps
nach Ihren Bedürfnissen.
– Die Namenskonvention für den Kurztext ist IDPK<Nachrichtentyp>, z.B. IDPKXAMPLE.
4. Wählen Sie Zurück, und sichern Sie den Objekttyp (Objekttyp ® Sichern o. Prüfen).
5. Wählen Sie Generieren, um den Objekttyp zu generieren.
6. Geben Sie den Objekttyp wie folgt frei: gehen Sie zur BOR-Hierarchie zurück und wählen Sie
Objekttyp ® Freigeben.
220 April 2001

Standardaufgabe anlegen
Zum Anlegen einer neuen Standardaufgabe kopiert man eine bereits bestehende Aufgabe. Als
Beispiel dient hier die Standardaufgabe 7947 "MATMAS_Error".
Vom R/3-Einstiegsbildschirm aus navigieren Sie über die Menüpunkte Werkzeuge ® Business
Workflow ® Entwicklung zum Business Workflow-Entwicklungsbildschirm.
1. Um eine Standardaufgabe anzulegen, wählen Sie Definitionswerkzeuge ® Aufgaben/
Aufgabengruppen ® Kopieren.
2. Geben Sie für den Aufgabentyp TS und für die Aufgabe 7947 ein und wählen Sie dann
Aufgabe ® Kopieren.
3. Tragen Sie im folgenden Dialogfenster Standardaufgabe im Gruppenrahmen
Beschreibung Ihr Objektkürzel (XAMPLE_Error) und Ihre Objektbezeichnung (XAMPLE
input error) ein und klicken Sie auf das Kopiersymbol.
4. Tragen Sie im folgenden Dialogfenster Objektkatalogeintrag anlegen Ihre
Entwicklungsklasse ein und wählen Sie dann Sichern.
5. Merken Sie sich die Nummer der Aufgabe, die Sie erstellt haben (99900000)
Bearbeiten Sie die neue Aufgabe wie folgt:
1. Wählen Sie Definitionswerkzeuge ® Aufgaben/ Aufgabengruppen ® Ändern.
2. Löschen Sie die auslösenden Ereignisse:
– Wählen Sie Auslösende Ereignisse.
– Klicken Sie auf das Ereignis inputErrorOccurred und löschen Sie es über Bearbeiten
® Ereignis löschen.
– Wählen Sie Zurück.
3. Löschen Sie die beendenden Ereignisse:
– Wählen Sie Beendende Ereignisse.
– Klicken Sie auf das Ereignis inputFinished und löschen Sie es über Bearbeiten ®
Ereignis löschen.
4. Ersetzen Sie die Anwendungskomponente HLA0006031 mit der
Anwendungskomponente Ihrer Eingangsverarbeitung.
Dies dient der Dokumentation und zum Suchen von Aufgaben, die für eine gegebene
Anwendungskomponente geeignet sind
5. Ersetzen Sie den Objekttyp IDOCMATMAS mit Ihrem neu angelegten Objekttyp
(IDOCXAMPLE).
6. Fügen Sie das für Ihren Objekttyp gültige auslösenden Ereignisse hinzu:
– Wählen Sie Auslösende Ereignisse.
– Wählen Sie Ereignis einfügen.
April 2001 221

– Geben Sie im folgenden Dialogfenster Ihren Objekttyp (IDOCXAMPLE) ein und

wählen Sie über F4 auf dem Feld Ereignis das Ereignis inputErrorOccurred.
– Wählen Sie Datenfluß-Definition.
– Tragen Sie &_EVT_OBJECT& im Feld _WI_Object_Id ein.
– Tragen Sie &EXCEPTION& im Feld Exception ein.
– Sichern Sie die Eingaben
– Wählen sie Springen ® Ereigniskopplung und betätigen Sie die Schaltfläche
aktivieren.
– Wählen Sie zweimal Zurück.
7. Fügen Sie das für Ihren Objekttyp geltende beendende Ereignis hinzu:
– Wählen Sie Beendende Ereignisse.
– Wählen Sie Ereignis einfügen.
– Geben Sie im folgenden Dialogfenster Ihren Objekttyp (IDOCXAMPLE) ein und
wählen Sie über F4 auf dem Ereignisfeld das Ereignis inputFinished. Wählen Sie
über F4 auf dem Feld Element das Element _WI_OBJECT_ID.
– Wählen Sie Zurück. Hinweis: Die Pflege der Datenfluß-Definition ist für dieses
Ereignis nicht erforderlich.
8. Sichern Sie Ihre Änderungen:
– Wählen Sie Sichern.
Alle Angaben sollten nun korrekt kopiert worden sein. Um sicher zu sein, prüfen Sie die
folgenden drei Einstellungen:
1. Prüfen Sie die Objektanbindung:
– Wählen Sie Datenfluß OM.
– Dem Feld Exception sollte nun &EXCEPTION& zugeordnet sein.
2. Prüfen Sie die Defaultrolle:
– Wählen Sie Defaultrollen.
– Die Standardrolle für den Bearbeiter sollte 134 sein. Damit stellen Sie sicher, daß die
Zahl der Empfänger über die Eingangspartnervereinbarung eingeschränkt wird.
– Wählen Sie Datenflußeditor. Dem Parameter IDocNumber sollte
&_WI_OBJECT_ID& zugeordnet sein.
– Wählen Sie zweimal Zurück.
3. Prüfen Sie den Text des Workitems:
– Wählen Sie Workitemtext...
– Der im folgenden Dialogfenster erscheinende Workitemtext sollte zwei Einträge
haben:
222 April 2001

– &_WI_Object_Id.ShortMessage&: Dieser Eintrag stellt sicher, daß die ersten 50

Zeichen im Workitemtext das IDoc-Attribut "ShortMessage" enthalten, die die ersten
50 Zeichen des Fehlerkurztextes bilden.
– &_WI_Object_Id.ApplicationObjectID&: Dieser Eintrag stellt sicher, daß der restliche
Workitemtext das IDoc-Attribut "ApplicationObjectID" enthält, der sich aus der
Kennung des im IDoc enthaltenen Anwendungsobjekts bildet. Im Falle von MATMAS
ist es die Materialnummer. Das Attribut verwendet das ALE-Verknüpfungsobjekt.
Die Zuordnung eines Bearbeiters zu einem Workitem geschieht über das

Customizing des SAP Business Workflow. Diese Customizing-Funktionen findet man
im Customizing des ALE unter Fehlerbehandlung einstellen ® Org.-Einheiten
anlegen und Standardaufgaben zuordnen.
April 2001 223

Eingangsmethode pflegen
Eingangsmethode pflegen
Die im Abschnitt ALE-Einstellungen unter "Vorgangcodes" erwähnten Ereignisfelder Ihrer
Eingangsmethode können nun gepflegt werden. Wählen Sie dazu IDoc ® Eingang ®
Vorgangscode - Art der Vereinbarung im ALE-Entwicklungsmenü.
Vorgangscodes sind mandentenabhängig. Stellen Sie sicher, daß Sie den richtigen
Mandanten pflegen.
1. Wählen Sie Ihren Vorgangscode XAMP.
2. Tragen Sie in den IDoc-Paketfeldern Ihren Paketobjekttyp IDPKXAMPLE und das Ende-
Ereignis massInputFinished ein.
3. Tragen Sie in den IDoc-Feldern Ihren IDoc-Objekttyp IDOCXAMPLE, das Start-Ereignis
inputErrorOccurred und das Ende-Ereignis inputFinished ein.
4. Tragen Sie im Feld für den Anwendungsobjekttyp den entsprechenden Objekttyp ein, z.B.
BUS1001 für Material.
5. Sichern Sie Ihren Eintrag.
224 April 2001

Konsistenz der Eingangs-Fehlerbehandlung prüfen
Konsistenz der Eingangs-Fehlerbehandlung prüfen

Sie haben nun alle erforderlichen Pflegeaufgaben für die Fehlerbehandlung über Workflow
erledigt. Um sich zu vergewissern, daß alles in Ordnung ist, wählen Sie IDoc ® Eingang ®
Konsistenzprüfung im ALE-Entwicklungsmenü.
Die Zeile mit dem Vorgangscode erscheint weiß, wenn alles korrekt ist; sie erscheint gelb, wenn
alles korrekt ist und Sie keinen Anwendungsobjekttyp verwenden; sie erscheint rot, wenn
mindestens eine Einstellung falsch ist. (Die Farbangaben beziehen sich auf die
Standardfarbeinstellungen).
Um nähere Einzelheiten anzuzeigen, wählen Sie die Zeile mit Ihrem Vorgangscode mit
Doppelklick aus.
Vorgangscodes und Ereignisverknüpfungen sind mandantenabhängig, prüfen Sie

also im richtigen Mandanten.
April 2001 225

ALE Programmierleitfaden (BCMIDALEPRO)

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ALE Programmierleitfaden (BCMIDALEPRO)

Hochgeladen von

Copyright:

Verfügbare Formate

ALE-Programmierleitfaden

© Copyright 2001 SAP AG. Alle Rechte vorbehalten.

Einbettung eines Funktionsbausteins in die ALE-Eingangsverarbeitung ............................ 92

Das Ereignis inputFinished ........................................................................................... 169

Entwickler von Desktop-Anwendungen können darüber hinaus ALE-

Mandantenkopie: Logische Systemnamen in Belegkopfdaten

Verteilung über BAPIs implementieren

· Daten filtern [Seite 19]

Ablauf der Verteilung über BAPIs

Anwendung ALE-Schicht Kommunikations- ALE-Schicht Anwendung

IDoc Daten und

· Umwandlung des IDocs in einen BAPI-Aufruf

Aufruf des generierten Ausgangsfunktionsbausteins

Umwandlung des BAPI-Aufrufs in ein IDoc

Auf der Anwendungsseite wird bei der Ausführung des generierten

Umwandlung des IDocs in einen BAPI-Aufruf

Aufruf des BAPI-Funktionsbausteins

Buchen der Anwendungsdaten und des IDoc-Status

Eigene BAPIs implementieren

Hinweise für asynchrone BAPIs

Voraussetzungen für die Verwendung der Filterdienste

Das BAPI kann folgende Parameterarten haben:

Feldweise Vollständige Parameter-

1. Unstrukturiert ohne Ankreuzleiste.

2. Unstrukturiert mit Ankreuzfeld. X

3. Einzeilig strukturiert ohne Ankreuzleiste.

4. Einzeilig strukturiert mit Ankreuzleiste. X

5. Mehrzeilig strukturiert ohne Ankreuzleiste. X X

6. Mehrzeilig strukturiert mit Ankreuzleiste. X X X

7. Mehrzeilig unstrukturiert ohne X

8. Mehrzeilig unstrukturiert mit Ankreuzleiste.

Anmerkung: Die mit X versehenen Felder erfüllen die Voraussetzungen.

Erläuterung zur obigen Matrix:

Material-Stammdaten werden von einem Referenzsystem auf ein Vertriebssystem

Vollständig reduzierbare Parameter

Feldweise reduzierbare Parameter

Filterobjekttypen definieren und zuordnen

Wählen Sie Filterobjekttyp einem BAPI zuordnen.

· Hierarchisch abhängige BAPI-Parameter untersuchen und ggf. abhängige Tabelleneinträge

Hierarchien zwischen BAPI-Parametern definieren

Grafische Hierarchieanzeige bearbeiten

Feldreferenzen zwischen Eltern- und Kindtabellen pflegen

Unabhängig davon, ob zu einem BAPI von SAP eine BAPI-ALE-Schnittstelle mit

Hierarchiepflege vor der Generierung der BAPI-ALE-Schnittstelle durchführen (siehe Hierarchien

Schnittstellengenerierung eigene Entwicklungsklassen und Funktionsgruppen

· Filterung für die Datenauswahl

· Dokumentation zu generierten Funktionsbausteinen

· BAPI-Rückgabeparameter und IDoc-Status

· Beschränkungen bezüglich der Schnittstellengenerierung

Empfänger für ein BAPI ermitteln

Beispiel einer Abhängigkeit eines BAPIs von einem Nachrichtentyp:

Folgende Beispielprogramme stehen Ihnen für die Empfängerermittlung zur

Filterobjekte eines BAPIs abfragen

Empfänger für asynchrone BAPIs ermitteln

Eigene Filterobjekte über Business Add-Ins ermitteln

Aufbau eines Business Add-Ins in einer Form-Routine

1) Filterobjekttyp für das BAPI mit dem Funktionsbaustein ALE_BAPI_GET_FILTEROBJECTS

4) Die Empfänger für den asynchronen BAPI-Aufruf mit dem Baustein

Beispielprogramme mit asynchronem BAPI-Aufruf

Die Verwendung der Funktion ALE_BAPI_GET_FILTEROBJECTS ist optional und

Nach dem Aufruf des Ausgangs-Funktionsbausteins der generierten BAPI-ALE-

Filterobjekttypen sind zur Laufzeit nicht bekannt

data: filterobj_values like bdi_fobj occurs 0,

* get filterobjects from ALE distribution model