Integrationstechnologie ALE, BIT300 Col10

Dieses E-Book erklärt Schritt für Schritt, wie Unternehmensprozesse mit der Integrationstechnologie ALE in SAP ERP über Systemgrenzen hinweg verlässlich zusammenarbeiten. Anhand praxisnaher Szenarien wird gezeigt, wie IDocs strukturiert sind, wie sie ausgelöst werden und welche Rollen Verteilungsmodelle und Partnerprofile spielen.

Ein besonderes Augenmerk liegt auf der Stammdatenverteilung am Beispiel des Materialstamms sowie auf EDI-Prozessen rund um die Auftragsabwicklung. Zudem werden synchrone und asynchrone BAPI-Aufrufe eingeordnet, inklusive der Übergabe von Reisekosten in die Finanzbuchhaltung. Abschließend erhalten Leserinnen und Leser Hinweise zur Sicherstellung eines stabilen Betriebs in komplexen Landschaften.

1. BIT300
Integrationstechnologie ALE
.
.
TEILNEHMERHANDBUCH
PRÄSENZSCHULUNG
.
Version der Schulung: 10
Dauer der Schulung: 3 Tag(e)
Dauer e-Book: 13 Stunden 20 Minuten
Materialnummer: 50145343Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

2. SAP-Urheberrechte, Marken und
Haftungsausschlüsse
©2020 SAP SE oder ein SAP-Konzernunternehmen. 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 SE oder ein SAP-Konzernunternehmen nicht gestattet.
SAP und andere in diesem Dokument erwähnte Produkte und Dienstleistungen von SAP sowie die dazugehörigen Logos sind
Marken oder eingetragene Marken der SAP SE (oder von einem SAP-Konzernunternehmen) in Deutschland und verschiedenen
anderen Ländern weltweit.
Weitere Hinweise und Informationen zum Markenrecht finden Sie unter http://global12.sap.com/
corporate-en/legal/copyright/index.epx
Die von SAP SE oder deren Vertriebsfirmen angebotenen Softwareprodukte können Softwarekomponenten auch anderer
Softwarehersteller enthalten.
Produkte können länderspezifische Unterschiede aufweisen.
Diese Materialien wurden unter Umständen maschinell übersetzt und können grammatikalische Fehler oder Ungenauigkeiten
enthalten.
Die vorliegenden Unterlagen werden von der SAP SE oder einem SAP-Konzernunternehmen bereitgestellt und dienen
ausschließlich zu Informations-zwecken. Die SAP SE oder ihre Konzernunternehmen übernehmen keinerlei Haftung oder
Gewährleistung für Fehler oder Unvollständigkeiten in dieser Publikation. Die SAP SE oder ein SAP-Konzernunternehmen steht
lediglich für Produkte und Dienstleistungen nach der Maßgabe ein, die in der Vereinbarung über die jeweiligen Produkte und
Dienstleistungen ausdrücklich geregelt ist. Keine der hierin enthaltenen Informationen ist als zusätzliche Garantie zu
interpretieren.
Insbesondere sind die SAP SE oder ihre Konzernunternehmen in keiner Weise verpflichtet, in dieser Publikation oder einer
zugehörigen Präsentation dargestellte Geschäftsabläufe zu verfolgen oder hierin wiedergegebene Funktionen zu entwickeln oder
zu veröffentlichen. Diese Publikation oder eine zugehörige Präsentation, die Strategie und etwaige künftige Entwicklungen,
Produkte und/oder Plattformen der SAP SE oder ihrer Konzern- unternehmen können von der SAP SE oder ihren Konzernunternehmen jederzeit und ohne Angabe von Gründen unangekündigt geändert werden. Die in dieser Publikation
enthaltenen Informationen stellen keine Zusage, kein Versprechen und keine rechtliche Verpflichtung zur Lieferung von Material,
Code oder Funktionen dar. Sämtliche vorausschauenden Aussagen unterliegen unterschiedlichen Risiken und Unsicherheiten, durch die die tatsächlichen Ergebnisse von den Erwartungen abweichen können. Die vorausschauenden Aussagen geben die Sicht zu dem Zeitpunkt wieder, zu dem sie getätigt wurden. Dem Leser wird empfohlen, diesen Aussagen kein übertriebenes Vertrauen zu schenken und sich bei Kaufentscheidungen nicht auf sie zu stützen.Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

3. Typografische Konventionen
Dieses Handbuch wurde vom Amerikanischen Englisch ins Deutsche übersetzt.
Die folgenden typografischen Konventionen werden in diesem Handbuch verwendet:
Diese Informationen werden in der Präsentation des Schulungsreferenten
angezeigt.
Demonstration
Vorgehensweise
Warnung oder Achtung
Hinweis
Zugehörige oder zusätzliche Informationen
Moderierte Diskussion
Steuerung der Benutzungsoberfläche Beispieltext
Fenstertitel Beispieltext
©Copyright. Alle Rechte vorbehalten. iiiLibrer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

4. ©Copyright. Alle Rechte vorbehalten. ivLibrer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

5. Inhaltsverzeichnis
vi Überblick über die Schulung
1 Kapitel 1:ALE-Grundlagen
3 Lektion: Systemübergreifende Geschäftsprozesse
8 Lektion: Verteilungsmodell
13 Lektion: Grundlegendes ALE-Customizing
21 Lektion: Intermediate Documents
32 Lektion: Synchronisation von Customizing-Einstellungen
38 Kapitel 2:Stammdatenverteilung
39 Lektion: Beispiel: Materialstamm
50 Lektion: Verwenden von Änderungszeigern
53 Lektion: Datenfilterung und Verringern der Datenmenge
66 Kapitel 3:Bewegungsdaten verteilen: Nachrichtensteuerung
67 Lektion: Nachrichtensteuerung und IDoc-Erzeugung
76 Lektion: Beispiel: Bestellungsbearbeitung
82 Kapitel 4:Bewegungsdaten verteilen: BAPIs
83 Lektion: Business-Objekttypen und BAPIs
89 Lektion: Nutzung von BAPIs in ALE
98 Lektion: Beispiel: Reisekostenabrechnung
103 Kapitel 5:Überwachung der Datenverteilung, Fehlerbehandlung und
Archivierung
104 Lektion: IDoc-Statusverwaltung
110 Lektion: Fehleranalyse und -behandlung
120 Lektion: SAP Workflow im ALE-Umfeld
130 Lektion: IDocs archivieren
135 Kapitel 6:Anhang
136 Lektion: Logische Systeme umbenennen
140 Lektion: Wiederherstellung von IDocs nach einem Datenbankfehler
©Copyright. Alle Rechte vorbehalten. vLibrer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

6. Überblick über die Schulung
ZIELGRUPPE
Diese Schulung richtet sich an die folgenden Zielgruppen:
●Anwendungsberater
●Entwicklungsberater
●Datenberater
●Developer IT Adminstrator IT Support
●Super-/Key-/Power-User
●Geschäftsprozessarchitekt
●Geschäftsprozessverantwortlicher/Teamleiter/Power-User
●Entwickler
●Lösungsentwickler
©Copyright. Alle Rechte vorbehalten. viLibrer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

7. KAPITEL 1ALE-Grundlagen
Lektion 1
Systemübergreifende Geschäftsprozesse 3
Lektion 2
Verteilungsmodell 8
Lektion 3
Grundlegendes ALE-Customizing 13
Lektion 4
Intermediate Documents 21
Lektion 5
Synchronisation von Customizing-Einstellungen 32
LERNZIELE
●Beispiele für Geschäftsprozesse in verteilten Systemlandschaften nennen
●Den Unterschied zwischen Application Link Enabling (ALE) und Electronic Data
Interchange (EDI) erklären
●Begriff e wie logisches System oder logischer Systemname, Nachrichtentyp und
Verteilungsmodell erläutern
●Die Funktionsweise des Verteilungsmodells erläutern
●Logische Systemnamen definieren und diese ggf. Mandanten in SAP-Systemen zuordnen
●Die Begriff e IDoc und Basistyp erläutern
●Zuordnung von Nachrichtentypen zu Basistypen festlegen
●Eine Sicht in einem Verteilungsmodell fertigstellen
●Die Funktionsweise von RFC-Destinationen, Ports und Partnervereinbarungen erläutern
●Die Begriff e Basistyp, Master-IDoc und Kommunikations-IDoc und deren Unterschiede
erläutern
©Copyright. Alle Rechte vorbehalten. 1Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

8. ●Die Details für die Basistypen festlegen
●Den Prozess vom Anlegen eines IDocs im Sendersystem bis zur Verarbeitung im
Zielsystem beschreiben
●Methoden zur Anpassung der Customizing-Einstellungen in SAP-Systemlandschaften
beschreiben
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 2Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

9. Kapitel 1
Lektion 1
Systemübergreifende Geschäftsprozesse
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion werden einige Beispiele für die Verwendung von Application Link Enabling
(ALE) vorgestellt.
Unternehmensszenario
International tätige Unternehmen strukturieren ihre Geschäftsabläufe in der Regel mithilfe
mehrerer Mandanten in einem SAP-System, oft auch mit mehreren SAP-Systemen. Häufig
sind diese mit Systemen für bestimmte Anwendungen anderer Anbieter verbunden. Sie
müssen klären, wie die an dieser Systemlandschaft Beteiligten Daten untereinander
austauschen.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Beispiele für Geschäftsprozesse in verteilten Systemlandschaften nennen
●Den Unterschied zwischen Application Link Enabling (ALE) und Electronic Data
Interchange (EDI) erklären
Unternehmensstruktur und Geschäftsprozesse
Oftmals bilden die Zentrale, die Tochterfirmen und die Vertriebsniederlassungen eines
Unternehmens separate, voneinander getrennte Systeme. Jedes Subsystem kommuniziert dabei nicht nur mit den anderen Mitgliedern der Systemgruppe, sondern auch mit Geschäftspartnern wie Kunden, Lieferanten, Banken und Behörden.
Abbildung 1: Das Unternehmen als Ganzes und externe Partner
©Copyright. Alle Rechte vorbehalten. 3Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

10. In der Abbildung „Das Unternehmen als Ganzes und externe Partner“ werden die
Stammdaten für das gesamte Unternehmensnetzwerk ausschließlich in der Zentrale angelegt
und geändert. Neue Stammdaten sowie Änderungen an vorhandenen Daten werden in
regelmäßigen Abständen an die nachgelagerten Systeme für Vertrieb und Produktion
übermittelt. Die zentrale Einkaufsabteilung bestellt bei Lieferanten, der Vertrieb erhält
Aufträge von Kunden und sendet diese an die Produktion. In allen Prozessen muss die
Kommunikation elektronisch erfolgen.
Abbildung 2: Beispiel: Auftragsabwicklung
Der Kunde schickt eine Bestellung an die Vertriebsniederlassung. Im Vertriebssystem werden
anhand der Bestelldaten zuerst ein Auftrag und dann ein (interner) Auftrag angelegt, der
wiederum an das System der Produktion gesendet wird. Im Produktionssystem wird aus
diesen Daten ein Auftrag erzeugt. Je nach den Vereinbarungen zwischen den beiden
Unternehmensbereichen bestätigt das Produktionssystem den Auftrag vom Vertrieb und
kündigt die Lieferung der bestellten Materialmengen an. Die Vertriebsniederlassung kann nun
den Kundenauftrag bestätigen und den Kunden über den Warenversand informieren. Nach
Auslieferung der Ware wird diese von der Produktionsabteilung dem Vertrieb in Rechnung
gestellt. Daraufhin stellt der Vertrieb dem Kunden eine Rechnung für die gelieferte Ware.
Vorbereitende Schritte für die Abbildung von systemübergreifenden Geschäftsprozessen
●Analyse der Organisationsstruktur des Unternehmens und Abbildung der zugehörigen
technischen Systeme: Aus welchen SAP-Systemen oder Mandanten setzt sich die
Systemlandschaft des Unternehmens zusammen? Gibt es eventuell auch SAP-fremde
Systeme?
●
Auflistung der installierten Softwareprodukte in jedem beteiligten System
●Beschreibung der Geschäftsprozesse, die in der Systemlandschaft abgebildet werden müssen
●Aufgliederung dieser Prozesse in einzelne Schritte
●Zuordnung der einzelnen Schritte des Gesamtprozesses zu den beteiligten Systemen oder Geschäftspartnern
Interne Kommunikation: Stammdatenverteilung mit ALE
ALE kann im Unternehmen u.a. für die zentrale Stammdatenverwaltung verwendet werden.
Das Anlegen und Ändern von Stammdaten erfolgt nur in einem der Systeme im
Firmennetzwerk. Die Stammdaten werden dann aus diesem Pflegesystem an die
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 4Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

11. nachgelagerten Systeme verteilt: Die Datensätze werden in elektronischer Form an die
einzelnen Empfänger weitergeleitet. Ein typisches Beispiel hierfür ist die zentrale
Stammdatenverwaltung.
Abbildung 3: Beispiel: Zentrale Materialstammverwaltung
In der Abbildung „Beispiel: Zentrale Materialstammverwaltung“ werden alle Materialstämme
in der Zentrale angelegt und von dort auf die nachgelagerten Systeme von Vertrieb und
Produktion verteilt. Der Vertrieb sollte Materialstammsätze allerdings nur für
Fertigerzeugnisse erhalten, während die Produktion Materialstammdaten für
Fertigerzeugnisse und Rohmaterial empfangen kann. Folglich ist es bei der Konfiguration des
ALE-Szenarios wichtig, auf die Verteilhierarchie zu achten und die Tatsache zu berücksichtigen, dass nicht jeder Empfänger alle Daten erhält. In einem anderen Szenario
sind die Abteilungen im empfangenden System für die Pflege bestimmter Teile eines
Stammsatzes zuständig. In diesem Fall sollte der Stammsatz nicht vollständig übertragen werden, sofern nicht garantiert werden kann, dass lokal geänderte Werte bei der erneuten Übertragung der Datensätze nicht überschrieben werden.
Planung der zentralen Stammdatenverteilung – Fragen
●Welche Stammdaten werden in welchem System verwaltet?
●An welche Systeme müssen die Stammdaten dann verteilt werden?
●Wie oft und wann werden die Daten verteilt?
●Erhalten alle Empfänger sämtliche Daten?
Kommunikation mit externen Partnern: Bestellabwicklung mit EDI
Sie möchten nicht nur innerhalb des Unternehmens elektronisch kommunizieren, sondern
auch mit Ihren Geschäftspartnern. Sie können einen Auftrag im System anlegen und
elektronisch an einen Lieferanten übertragen. Der Lieferant kann Auftrags- und
Versandbestätigungen sowie Rechnungen versenden.
Lektion: Systemübergreifende Geschäftsprozesse
©Copyright. Alle Rechte vorbehalten. 5Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

12. Abbildung 4: Beispiel: Bestellungsbearbeitung
Der Datenaustausch mit externen Partnern (z.B. Geschäftspartnern, Banken oder Behörden)
erfolgt via EDI und nicht über ALE. Ein elektronisches Dokument wird in einem SAP-eigenen
Format von einem SAP-System an ein EDI-Subsystem (Konverter) übermittelt. Das
Subsystem wandelt dieses Dokument in einen EDI-Beleg um und sendet diesen an den
Lieferanten. Das Kapitel „Bewegungsdaten verteilen: Nachrichtensteuerung“ enthält weitere
Informationen zu den Unterschieden zwischen ALE und EDI.
Trennung der Systeme aus rechtlichen Gründen im Personalwesen
Aus datenschutzrechtlichen Gründen wird für das Personalwesen oft ein eigenes System
eingerichtet. In diesem System werden die Personalstammdaten verwaltet, die
Personalabrechnung verarbeitet und andere sensible Daten gespeichert. Ein unbefugter
Zugriff auf diese Daten sollte dadurch verhindert (oder zumindest erschwert) werden, dass
das HR-System von den anderen Systemen im Unternehmensnetzwerk technisch getrennt wird. Weitere mögliche Gründe für ein getrenntes HR-System:
●Unabhängigkeit während technischer Upgrades
●Unabhängigkeit bei der Installation von Support Packages, die personalrechtliche
Änderungen betreffen (sogenannte Legal Change Patches)
●Bessere Performance
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 6Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

13. Abbildung 5: Separates System für das Personalwesen
Die Buchhaltung ist eines der Systeme, das in der Zentrale verwaltet wird und welches für die
Gehaltszahlung oder Reisekostenerstattung ebenfalls Personalstammdaten erfordert. Auch
Kostenstellen und andere Kontierungsobjekte sind in beiden Systemen erforderlich. Deshalb
ist selbst bei einem separaten HR-System eine Stammdatenverteilung sinnvoll. Die
Ergebnisse der Personal- oder Reisekostenabrechnung werden vom HR-System an die
Zentrale übertragen, damit sie dort in der Buchhaltung verbucht werden können.
*Diese moderierte Diskussion wurde aus rein formellen Gründen in die Lektion aufgenommen.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Beispiele für Geschäftsprozesse in verteilten Systemlandschaften nennen
●Den Unterschied zwischen Application Link Enabling (ALE) und Electronic Data
Interchange (EDI) erklären
Lektion: Systemübergreifende Geschäftsprozesse
©Copyright. Alle Rechte vorbehalten. 7Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

14. Kapitel 1
Lektion 2
Verteilungsmodell
ÜBERBLICK ÜBER DIE LEKTION
Das Verteilungsmodell ist die Kernkomponente von Application Link Enabling (ALE), denn es
bestimmt, welches Sendersystem welche Daten an welche Empfänger sendet. Es besteht aus
Zuordnungen logischer Systemnamen und Nachrichtentypen. In dieser Lektion werden diese
drei Begriff e erörtert, und es wird beschrieben, welche Funktion diese in ALE-Szenarien
übernehmen.
Unternehmensszenario
Sie haben Ihre Geschäftsprozesse und die vorhandene Systemlandschaft analysiert. Sie
möchten sich einen Überblick über die Konfiguration eines ALE-Szenarios am Beispiel der
zentralen Stammdatenverwaltung verschaff en.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Begriff e wie logisches System oder logischer Systemname, Nachrichtentyp und
Verteilungsmodell erläutern
●Die Funktionsweise des Verteilungsmodells erläutern
Logischer Systemname
Wenn Sie entschieden haben, welche Teile des Unternehmens Daten über ALE austauschen
sollen, definieren Sie logische Systemnamen für jeden Mandanten in der Systemgruppe und
ggf. auch für alle externen Systeme (sofern noch nicht geschehen).
Abbildung 6: Beispiel für ein abzubildendes Szenario
Der logische Systemname identifiziert den Mandanten eines SAP-Systems oder eines
Fremdsystems in der Systemlandschaft eindeutig. Wenn sich der Name auf einen Mandanten
bezieht, weisen Sie den Namen im nächsten Schritt dem Mandanten zu. Um zu gewährleisten,
dass der logische Systemname eindeutig ist, und um die Zuordnung zu vereinfachen,
©Copyright. Alle Rechte vorbehalten. 8Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

15. empfiehlt SAP die folgende Namenskonvention: <System name>CLNT<Client key> . In der
Abbildung „Logische Systemnamen“ verwendet das SAP-System den Schlüssel G23 sowie
die Mandanten 800, 810 und 811. So erhält z.B. Mandant 800 den logischen Systemnamen
G23CLNT800.
Notiz:
Die Begriff e „logischer Systemname“ und „logisches System“ werden synonym
verwendet.
Abbildung 7: Logische Systemnamen
In manchen Fällen ist es sinnvoll, sich bei logischen Systemnamen nicht an die empfohlene
Namenskonvention zu halten. Die Mandanten für diese Schulung verfügen z.B. über
beschreibende Namen. Der Name des logischen Systems für die Zentrale lautet „CORE“, für
den Vertrieb „SALES“ und für die Produktion „PRODUCTION“. Die Systeme auf diese Weise
zu benennen, bietet sich als Alternative für die SAP-Namenskonvention an, wenn die
Zuordnung von Mandanten zu logischen Systemnamen häufig geändert wird.
Achtung:
Die Änderung eines logischen Systemnamens ist ein bedeutender Eingriff , da
dieser Name in vielen Anwendungstabellen verwendet wird (siehe Lektion
„Grundlegendes ALE-Customizing“ und Anhang „Logische Systeme
umbenennen“.
Nachrichtentyp
Wenn Sie ein ALE-Szenario konfigurieren, müssen Sie nicht nur logische Systemnamen
zuweisen, sondern auch die Arten von Daten angeben, die ausgetauscht werden sollen. Wenn
Sie beispielsweise Materialstämme mit ALE verteilen möchten, müssen Sie die Art der Daten
(Materialstamm) mit dem zugehörigen Nachrichtentyp (MATMAS) benennen.
Lektion: Verteilungsmodell
©Copyright. Alle Rechte vorbehalten. 9Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

16. Nachrichtentypen sind Schlüssel, die mit logischen Systemnamen vergleichbar sind. Sie
geben die Daten an, die zwischen Systemen in ALE- oder EDI-Szenarien ausgetauscht werden
können.
Abbildung 8: Logische Systeme und Nachrichtentypen
Beide Elemente, also der logische Systemname und der Nachrichtentyp, sind im
Verteilungsmodell miteinander verknüpft, damit bestimmt werden kann, welcher Sender
welche Daten an welchen Empfänger sendet. In der Abbildung „Logische Systeme und
Nachrichtentypen“ verteilt die Zentrale (logisches System „CORE“) die Materialstämme
(Nachrichtentyp „MATMAS“) an den Vertrieb (logisches System „SALES“) und an die
Produktion (logisches System „PRODUCTION“).
Notiz:
In einigen ALE-Szenarien werden statt Nachrichtentypen BAPIs (Business
Application Programming Interfaces) verwendet. Wie Sie BAPIs in ALE
verwenden, erfahren Sie im Kapitel „Bewegungsdaten verteilen: BAPIs“.
Verteilungsmodell und Modellsichten
Wenn Daten von einem logischen System an ein anderes logisches System gesendet werden
sollen, geben Sie im Verteilungsmodell an, welcher Nachrichtentyp von welchem logischen
System an welche logischen Systeme übertragen werden soll. Im Verteilungsmodell werden
alle Zuordnungen von Sender, Empfänger und zu übermittelnden Daten gebündelt. Bei der
Einrichtung eines neuen ALE-Szenarios legen Sie normalerweise eine neue Modellsicht für
dieses Szenario im Verteilungsmodell eines der beteiligten Systeme an. In dieser Modellsicht
geben Sie Sender und Empfänger mit ihren logischen Systemnamen an und fügen dann dem
Nachrichtentyp hinzu, der die Art der zu übermittelnden Daten beschreibt.
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 10Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

17. Abbildung 9: Modellsicht in einem Verteilungsmodell
Anschließend müssen Sie die neu angelegte Modellsicht verteilen, das heißt, Sie müssen sie
den übrigen beteiligten Systemen mitteilen. In der Abbildung „Modellsicht in einem
Verteilungsmodell“ wurden die Stammdaten der Modellsicht im logischen System „CORE“
angelegt. Dies betrifft aber auch die logischen Systeme „SALES“ und „PRODUCTION“. Diese
erhalten jeweils eine Kopie der neuen Modellsicht. Sie können eine Modellsicht über ALE unter bestimmten Voraussetzungen (siehe unten) an die Partnersysteme verteilen. Es ist aber auch möglich, eine Modellsicht in andere Systeme zu übertragen.
Abbildung 10: Modellsichten verteilen
Lektion: Verteilungsmodell
©Copyright. Alle Rechte vorbehalten. 11Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

18. Notiz:
Um sicherzustellen, dass die Daten weiterhin konsistent sind, sollten Sie das
Verteilungsmodell zentral in einem logischen System verwalten und dann die
zugehörigen Sichten an die anderen betroffenen logischen Systeme verteilen bzw.
übertragen.
Sie finden das Verteilungsmodell im Einführungsleitfaden (IMG) über folgenden Pfad:SAP
NetWeaver→Application Server→IDoc-Schnittstelle / Application Link Enabling (ALE)→
Geschäftsprozesse modellieren und implementieren→Verteilungsmodell pflegen und Sichten
verteilen.
*Diese moderierte Diskussion wurde aus rein formellen Gründen in die Lektion aufgenommen.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Begriff e wie logisches System oder logischer Systemname, Nachrichtentyp und
Verteilungsmodell erläutern
●Die Funktionsweise des Verteilungsmodells erläutern
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 12Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

19. Kapitel 1
Lektion 3
Grundlegendes ALE-Customizing
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion erhalten Sie eine Einführung in das grundlegende Customizing für
Application Link Enabling (ALE). Sie erfahren außerdem, wo Sie Informationen zu den von
SAP ausgelieferten ALE-Szenarien finden.
Unternehmensszenario
Sie möchten mithilfe von ALE Daten zwischen zwei SAP-Systemen austauschen. Aus diesem
Grund möchten Sie sich einen Überblick über die Customizing-Einstellungen zur Einrichtung
von ALE-Szenarien verschaff en. Sie möchten auch überprüfen, ob es ein ALE-
Standardszenario gibt, das für Ihre Zwecke geeignet wäre.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Logische Systemnamen definieren und diese ggf. Mandanten in SAP-Systemen zuordnen
●Die Begriff e IDoc und Basistyp erläutern
●Zuordnung von Nachrichtentypen zu Basistypen festlegen
●Eine Sicht in einem Verteilungsmodell fertigstellen
●Die Funktionsweise von RFC-Destinationen, Ports und Partnervereinbarungen erläutern
ALE-Customizing im Einführungsleitfaden (IMG)
Sie finden die grundlegenden Customizing-Einstellungen für ein SAP-System im
Einführungsleitfaden (IMG) unterSAP NetWeaver→Application Server→IDoc-
Schnittstelle / Application Link Enabling (ALE). Sie können diesen Abschnitt des
Einführungsleitfadens auch direkt über die TransaktionSALEaufrufen.
Abbildung 11: Transaktion „SALE“
©Copyright. Alle Rechte vorbehalten. 13Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

20. Im AbschnittGeschäftsprozesse modellieren und implementierenfinden Sie eine umfassende
Dokumentation zu den ALE-Szenarien, die Sie in verschiedenen Anwendungen nutzen können
(Vordefinierte ALE-Geschäftsprozesse konfigurieren ). Wenn Sie sich z.B. für die möglichen
Anwendungen von ALE im Personalwesen interessieren, gehen Sie zuGeschäftsprozesse
modellieren und implementieren→Vordefinierte ALE-Geschäftsprozesse konfigurieren →
Personalwirtschaft. Je nach Anwendung finden Sie auch eine Beschreibung des Szenarios
sowie die untergeordneten Schritte, mit denen Sie das Szenario konfigurieren. Es werden
auch die unterstützenden Funktionen aufgeführt, beispielsweise das automatische Customizing oder ein Programm zur Überprüfung der Vollständigkeit und internen Konsistenz Ihrer Einstellungen.
Logische Systemnamen definieren und Mandanten zuordnen
Für jedes System in der Systemlandschaft muss ein logischer Systemname festgelegt
werden. Dieser Name dient zur eindeutigen Identifikation des logischen Systems in der
Systemlandschaft. Dieser Name kann dann einem Mandanten eines SAP-Systems zugeordnet werden.
Abbildung 12: Logische Systeme definieren
Sie können die logischen Systemnamen im Customizing definieren. Wählen Sie im SAP
Referenz-IMG den PfadSAP NetWeaver→Application Server→IDoc-Schnittstelle /
Application Link Enabling (ALE)→Grundeinstellungen→Logische Systeme einrichten→
Logisches System benennen.
Hinweis:
Sie können die Tabelle mit den logischen Systemnamen auch direkt über die
TransaktionBD54aufrufen.
Sie finden die Zuordnung logischer Systemnamen zu Mandanten im Einführungsleitfaden
unterSAP NetWeaver→Application Server→IDoc-Schnittstelle / Application Link Enabling
(ALE)→Grundeinstellungen→Logische Systeme einrichten→Logisches System einem
Mandanten zuordnen.
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 14Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

21. Hinweis:
Sie können diese Tabelle auch direkt über einen Transaktionscode (SCC4)
aufrufen.
Nachrichtentypen und Basistypen
In ALE geben die Nachrichtentypen die Daten an, die zwischen zwei Systemen ausgetauscht
werden sollen. So steht MATMAS z.B. für Materialstämme. Die zu verteilenden
Materialstammdaten werden vom Sender- zum Empfängersystem in Form eines
elektronischen Intermediate Documents (IDoc) übertragen. Dieses IDoc enthält die Daten aus
dem Stammsatz in einem SAP-eigenen Format. Die Struktur des Dokuments ist in einem
Basistyp festgelegt. Der Basistyp definiert die Formatierungsstruktur des Datensatzes, der
übermittelt werden soll. In der Regel ist der Name des IDoc-Basistyps identisch mit dem Namen des Nachrichtentyps, ihm wird allerdings eine Versionsnummer hinzugefügt. Die aktuelle Version des Basistyps für den NachrichtentypMATMASlautet z.B.MATMAS05.
Abbildung 13: Nachrichtentypen und Basistypen
In der TabelleNachrichtentypen und Zuordnung auf IDoc-Typenkönnen Sie herausfinden,
welche Version des Basistyps am besten für den Releasestand Ihres SAP-Systems geeignet
ist. Wählen Sie dazu im Menü „SAP Easy Access“Werkzeuge→ALE→ ALE-Entwicklung→
IDoc→IDoctyp-Entwicklung→IDoctyp zu Nachricht(TransaktionWE82). Einen Überblick
über alle Nachrichtentypen finden Sie unter Werkzeuge→ALE→ ALE-Entwicklung→
Logische Nachrichten(TransaktionWE81).
Notiz:
Die Struktur und die Verwendung von IDocs wird ausführlicher in der Lektion
„Intermediate Documents“ beschrieben.
Modellsichten im Verteilungsmodell anlegen
Im Verteilungsmodell eines logischen Systems geben Sie für jedes Ihrer ALE-Szenarien an,
welches logische System welche Art von Daten an welches Partnersystem übermittelt. Sie
können im Customizing neue Modellsichten anlegen. Gehen Sie im Einführungsleitfaden zu
SAP NetWeaver→Application Server→IDoc-Schnittstelle / Application Link Enabling
(ALE)→Geschäftsprozesse modellieren und implementieren→
Verteilungsmodell pflegen
Lektion: Grundlegendes ALE-Customizing
©Copyright. Alle Rechte vorbehalten. 15Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

22. und Sichten verteilen, oder rufen Sie das Verteilungsmodell direkt über die TransaktionBD64
auf.
Abbildung 14: Pflege des Verteilungsmodells im Einführungsleitfaden
Um eine neue Modellsicht anzulegen, geben Sie die logischen Systemnamen des Senders und
Empfängers sowie einen Nachrichtentyp ein. Sie können logische Systeme für
unterschiedliche Nachrichtentypen und Sender- und Empfängerrollen in derselben
Modellsicht zuordnen.
Abbildung 15: Verteilungsmodell
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 16Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

23. Um die Konsistenz der Daten innerhalb der Systemlandschaft und darüber hinaus zu
gewährleisten, ist es ratsam, die verschiedenen Sichten eines Verteilungsmodells in einem
zentralen System zu verwalten und sie an die Partnersysteme zu verteilen oder zu
transportieren (siehe unten).
RFC-Destinationen und -Ports
In ALE-Szenarien tauschen die beteiligten Systeme Daten via RFC aus. Ein RFC ruft von einem
SAP-System aus einen Funktionsbaustein in einem anderen SAP-System auf. RFCs
ermöglichen den Austausch von Daten zwischen verschiedenen SAP-Systemen oder
zwischen einem SAP-System und einem SAP-fremden System. In SAP-fremden Systemen
werden anstelle von Funktionsbausteinen speziell programmierte Funktionen aufgerufen,
wobei deren Schnittstelle einen Funktionsbaustein simuliert.
Abbildung 16: RFC-Destinationen definieren
Für alle beteiligten Partnersysteme legen Sie für Ihre ALE-Szenarien in jedem System RFC-
Destinationen an. Wählen Sie dazu im ALE-Customizing den PfadIDoc-Schnittstelle /
Application Link Enabling (ALE)→Kommunikation→RFC-Verbindungen anlegen, oder
verwenden Sie die TransaktionSM59. Geben Sie unter den RFC-Destinationen einen Ziel-Host,
IP-Adressen und ggf. die Systemnummer sowie Benutzer- und Anmeldedaten für ein Remote-
Login im Zielsystem an. So enthält die RFC-Destination alle technischen Informationen, die
das aufrufende System benötigt, um den Partner innerhalb des Netzwerks aufzurufen.
Hinweis:
Geben Sie der RFC-Destination den gleichen Namen wie dem logischen
Zielsystem. Das System kann dann später für Sie einige Einstellungen
automatisch vornehmen.
Für die spätere Verwendung von ALE-Szenarien muss der RFC-Verbindung ein Port
zugewiesen werden. Anhand des Ports ermittelt der Sender den Kommunikationskanal für
Lektion: Grundlegendes ALE-Customizing
©Copyright. Alle Rechte vorbehalten. 17Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

24. den Empfänger. Sie können die Ports manuell anlegen, oder – falls das logische Zielsystem
und die RFC-Destination den gleichen Namen haben – das Sendersystem legt diese für Sie
an.
Notiz:
In den SAP-Systemen gibt es verschiedene Arten von Ports. ALE verwendet
immer RFC-Ports. In EDI-Szenarien können Sie zusätzlich zu RFC-Ports auch
Datei-Ports verwenden (siehe Lektion „Intermediate Documents“).
IDocs via tRFC übertragen
Um sicherzustellen, dass die RFC-Funktionen zuverlässig, sicher und unabhängig von der
Verfügbarkeit des RFC-Servers bzw. RFC-Serversystems ausgeführt werden können, wurde
in SAP R/3 3.0 der transaktionale RFC (tRFC) eingeführt. Dadurch wird sichergestellt, dass
der aufgerufene Funktionsbaustein nur genau einmal im RFC-Serversystem ausgeführt wird.
In tRFC-Aufrufen müssen die zu einer RFC-Funktion gehörigen Daten in der SAP-Datenbank
im RFC-Client-System zwischengespeichert werden. Sobald die Bearbeitung abgeschlossen
ist, muss dieser Vorgang dem aufrufenden ABAP-Programm bestätigt werden. Alles Weitere
übernimmt die tRFC-Komponente im SAP-System.
Abbildung 17: Transaktionaler RFC
Da eine Datenbank in einem externen System nicht immer verfügbar ist, wird die Verbindung
mit der tRFC-Schnittstelle so implementiert, dass die Client- oder Serverprogramme eine
Reihe administrativer Funktionen auf Basis der RFC Application Programming Interface (API)
ausführen müssen, um sicherzustellen, dass der Funktionsbaustein nur einmal ausgeführt
wird.
Wenn bei einem synchronen RFC ein Verbindungsfehler auftritt, wiederholt der Client den
Aufruf, ohne zu wissen, ob die Verarbeitung bereits stattgefunden hat. Der tRFC löst dieses
Problem, da tRFC-Aufrufe auch dann übertragen werden können, wenn das Zielsystem nicht
verfügbar ist. In diesen Fällen werden die Daten sicher lokal im Sendersystem gespeichert
und zu einem späteren Zeitpunkt übertragen. In SAP ERP wird zu diesem Zweck die
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 18Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

25. automatische Jobeinplanung verwendet. Der Job startet die entsprechenden
Funktionsbausteine im Zielsystem zu einem späteren Zeitpunkt.
Notiz:
Ein externer tRFC-Client muss die Aufrufe später selbst wiederholen.
Im SAP-System können Sie die folgenden tRFC-Parameter für die relevante Verbindung in der
Tabelle RFCDES (für die Verbindungstypen T, 3, und I über die TransaktionSM59) einrichten:
●Unterdrückung des Batch-Jobs im Falle eines Kommunikationsfehlers (manueller Start
über TransaktionSM58erforderlich)
●Anzahl der Verbindungsversuche
●Intervall (in Minuten) zwischen den Wiederholungsversuchen zur Datenübertragung
Partnervereinbarungen
In ALE-Szenarien überprüfen Anwendungsprogramme das Verteilungsmodell des Systems,
wenn diese aufgerufen werden, um den Empfänger der einzelnen im IDoc-Format
vorbereiteten Nachrichten zu identifizieren. Für die ALE-Szenarien sind
Partnervereinbarungen für jede Kombination aus Empfänger und Nachrichtentyp erforderlich. Diese Vereinbarungen werden auch für die Verarbeitung von eingehenden IDocs benötigt. Für jeden Nachrichtentyp in einem ALE-Szenario gibt es immer eine Ausgangs- und eine Eingangspartnervereinbarung.
Abbildung 18: Partnervereinbarungen
Das Sendersystem liest den Basistyp für den Nachrichtentyp aus der
Ausgangspartnervereinbarung, sodass es ein IDoc mit den zu verteilenden Daten anlegen
kann. Das Sendersystem verwendet den Port, der der Partnervereinbarung zugeordnet ist,
um die RFC-Destination zu suchen, die den Aufruf des Empfängersystems ermöglicht.
Darüber hinaus ermittelt die Partnervereinbarung, ob das IDoc sofort oder zu einem späteren
Zeitpunkt übermittelt wird.
Lektion: Grundlegendes ALE-Customizing
©Copyright. Alle Rechte vorbehalten. 19Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

26. Aus der Eingangspartnervereinbarung liest das Empfängersystem ab, wie und wann die Daten
aus dem eingehenden IDoc an die jeweilige Anwendung übertragen werden sollen. In der
Regel wird ein Vorgangscode verwendet, um einen Funktionsbaustein für die
Eingangsverarbeitung des IDocs zu finden.
Damit eine Modellsicht an alle Partnersysteme verteilt werden kann, muss das Sendersystem Ausgangspartnervereinbarungen für den NachrichtentypSYNCH
für alle betroffenen
Empfängersysteme enthalten. Dieser Nachrichtentyp dient nur zur Ermittlung der RFC- Destination für das Zielsystem. Wenn der Name des logischen Zielsystems und seine RFC- Destination identisch sind, kann das Sendersystem automatisch einen Port mit der entsprechenden RFC-Destination erstellen und die Partnervereinbarungen für die Nachrichtentypen einer Modellsicht generieren. Das Berechtigungsobjekt für die Verteilung der Modellsichten lautetB_ALE_MODL.
Notiz:
In der Lektion „Intermediate Documents“ wird erklärt, wie Ports und
Partnervereinbarungen angelegt und geändert werden.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Logische Systemnamen definieren und diese ggf. Mandanten in SAP-Systemen zuordnen
●Die Begriff e IDoc und Basistyp erläutern
●Zuordnung von Nachrichtentypen zu Basistypen festlegen
●Eine Sicht in einem Verteilungsmodell fertigstellen
●Die Funktionsweise von RFC-Destinationen, Ports und Partnervereinbarungen erläutern
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 20Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

27. Kapitel 1
Lektion 4
Intermediate Documents
ÜBERBLICK ÜBER DIE LEKTION
In ALE-Szenarien tauschen die beteiligten Systeme Daten im Form von Intermediate
Documents (IDocs) aus. In dieser Lektion wird die Struktur von IDocs erläutert, und es
werden verschiedene Methoden zur Erzeugung von IDocs vorgestellt. Sie erhalten einen
Überblick über den gesamten Prozess – von der IDoc-Erzeugung im Sendersystem bis zur
Verarbeitung der Daten im Empfängersystem.
Unternehmensszenario
Sie möchten mithilfe von ALE Daten zwischen zwei SAP-Systemen austauschen und hierbei
mehr über die technische Implementierung von ALE-Szenarien erfahren.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Die Begriff e Basistyp, Master-IDoc und Kommunikations-IDoc und deren Unterschiede
erläutern
●Die Details für die Basistypen festlegen
●Den Prozess vom Anlegen eines IDocs im Sendersystem bis zur Verarbeitung im
Zielsystem beschreiben
Struktur eines IDocs: Basistyp
In ALE-Szenarien werden Daten zwischen zwei SAP-Systemen oder zwischen SAP-Systemen
und SAP-fremden Systemen im Form von Intermediate Documents (IDocs) übertragen. Die
Struktur eines IDocs wird durch den Basistyp oder IDoc-Typ bestimmt. Basistypen sind mit
Nachrichtentypen verknüpft. Ein Basistyp kann auf kompatible Weise für ein neues Release
erweitert werden, ebenso wie die Schnittstellen eines ABAP-Funktionsbausteins. Dies
bedeutet, dass es oft verschiedene Basistypen für einen Nachrichtentyp gibt: Jeder Basistyp
stellt eine Version desselben Grundmusters dar.
Notiz:
Nachrichtentypen geben die Art der zu verteilenden Daten an. Sie sind in
Verteilungsmodellsichten enthalten. In den Ausgangspartnervereinbarungen für
Sender und Empfänger wird der entsprechende Basistyp einem Nachrichtentyp
(siehe Lektion „Grundlegenes ALE-Customizing“) zugeordnet.
Die Abbildung „Basistyp“ zeigt einen Auszug aus der Struktur des Basistyps MATMAS05.
©Copyright. Alle Rechte vorbehalten. 21Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

28. Abbildung 19: Basistyp
Der Basistyp strukturiert die Formatierung der zu sendenden Anwendungsdaten. Unter
anderem enthält er Informationen darüber, welche Daten an welchem Ort (Zeile und Off set)
gesichert sind. Der Basistyp gibt auch die Reihenfolge vor, in der die Anwendungsdaten zu
einer Nachricht gehören. Die Daten in einem IDoc sind in Zeilen angeordnet. Die Zeilen bilden
die Segmente eines IDocs, und diese Segmente setzen sich wiederum aus Segmentfeldern
zusammen. Die Zeilenstruktur eines IDoc-Segments wird durch den Segmenttyp festgelegt.
Für jedes Segmentfeld wird der Feldname zusammen mit den technischen Eigenschaften und
der Feldsemantik hinterlegt. IDoc-Segmente können hierarchisch miteinander verknüpft sein.
Ein IDoc muss nicht alle Segmente seines Segmenttyps enthalten, und ein Segmenttyp kann
mehr als ein Segment umfassen. Ob ein IDoc ein bestimmtes Segment enthalten muss und
wie viele Segmente für einen Segmenttyp zulässig sind, legt der IDoc-Typ fest.
Notiz:
Einen Überblick über die Segmentstruktur eines Basistyps können Sie über die
TransaktionWE30(Entwicklung IDoc-Typen) anzeigen.
Die Struktur der von SAP ausgelieferten Basistypen wird ausführlich in SAP ERP und SAP
ERM dokumentiert. Um diese Dokumentation aufzurufen, wählen SieWerkzeuge→ALE→
ALE-Administration→Dienste→Dokumentation→IDoc-Typen und Segmenteoder die
TransaktionWE60.
Zusätzlich zu den Informationen über die IDoc-Segmente und ihre hierarchischen
Abhängigkeiten enthält diese Dokumentation die folgenden Attribute:
●
IDoc-Typ-Attribute: Informationen wie z.B. die erste Version des IDoc-Typs.
●Segmenttyp-Attribute: Diese enthalten die Information, ob ein Segment erforderlich oder
optional ist und wie viele Segmente für einen Segmenttyp mindestens bzw. höchstens
erlaubt sind.
●Segmentfeld-Attribute: Dies sind die technischen und semantischen Eigenschaften eines
Feldes.
Darüber hinaus enthält die Dokumentation in der Regel auch Informationen zur Zweckbindung eines Segmentfelds für organisatorische oder geschäftliche Anforderungen.
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 22Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

29. Notiz:
Die von SAP ausgelieferten Basistypen können entsprechend den Anforderungen
des Kunden erweitert werden. BIT350 befasst sich mit der Erweiterung von IDoc-
Basistypen (ALE-Erweiterungen).
Master-IDoc
Die Anwendungsprogramme, die Sie in ALE-Szenarien verwenden, generieren immer zuerst
eine interne Tabelle basierend auf dem IDoc-Basistyp unter Verwendung eines ABAP-
Programms. Diese Tabelle wird als Master-IDoc bezeichnet. Die Anwendungsdaten werden
zeilenweise entsprechend dem Basistyp aufbereitet und in diese interne Tabelle eingefügt.
Eine interne Tabelle ist ein Datenobjekt des ABAP-Programms, das nur während der Laufzeit
des Programms existiert. Interne Tabellen werden folglich nicht in der Datenbank
gespeichert.
Abbildung 20: Struktur eines Master-IDocs
Jede Zeile in der internen Tabelle besteht aus einem Kontrollteil, der die Metainformationen
für die Zeile enthält, sowie dem eigentlichen Datenteil. Die wichtigste Information im
Kontrollteil ist der Name des Segmenttyps, der die Struktur des Datenteils beschreibt.
Der Kontrollteil einer Zeile umfasst die folgenden Felder:
MANDT Mandant
DOCNUM Nummer des IDocs
SEGNUM Fortlaufende Nummer (Zeilennummer in der internen Tabelle)
SEGNAM Name des Segmenttyps
PSGNUM Zeilennummer des übergeordneten Segments
HLEVEL Hierarchieebene
Der Datenteil besteht aus den folgenden Feldern:
Lektion: Intermediate Documents
©Copyright. Alle Rechte vorbehalten. 23Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

30. DTINT2 Gesamtlänge des Datenteils
SDATA Langes Feld vom Typ CHAR. Enthält die Daten in der Struktur, die durch
den Segmenttyp beschrieben wird.
Der Zeilentyp der internen Tabelle wird durch den ABAP-Dictionary-Strukturtyp EDIDD
bestimmt.
Kommunikations-IDoc
Später während der Ausführung des Programms verwendet das System die Daten vom
Master-IDoc, um ein Kommunikations-IDoc zu erzeugen, ein Intermediate Document, das in
der Datenbank gesichert und dann gesendet wird. Wenn sich das System bzw. die
Dokumentation auf ein IDoc bezieht, ist im Allgemeinen dieses Kommunikations-IDoc
gemeint.
Jedes Kommunikations-IDoc besteht aus genau einem Kontrollsatz und mehreren Daten- und
Statussätzen.
Abbildung 21: Struktur eines Kommunikations-IDocs
Der wichtige Teil des Kontrollsatzes ist die IDoc-Nummer. Diese wird intern im System
zugewiesen. Diese Nummer ist innerhalb eines logischen Systems eindeutig. Sie definieren
den Wertebereich in jedem System über ein Nummernkreisintervall. Der Kontrollsatz enthält
auch die Schlüsselfelder der Partnervereinbarungen und den letzten Verarbeitungsstatus.
Die Datensätze im Kommunikations-IDoc entsprechen den Zeilen im Master-IDoc.
Die Statussätze enthalten die Verarbeitungsschritte des IDocs. Sie halten die Stationen fest,
die ein IDoc von der Erstellung bis zum Versand durchlaufen hat. Dies hilft Ihnen dabei, die
Datenverteilung zwischen Systemen zu überwachen.
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 24Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

31. IDocs erzeugen
Die Anwendungsprogramme erzeugen IDocs auf unterschiedliche Art und Weise. Die
Abbildung „Erzeugen eines IDocs“ zeigt die vier Grundformen der IDoc-Erstellung:
Abbildung 22: Erzeugen eines IDocs
●Dedizierte Transaktionen: Die vorkonfigurierten ALE-Szenarien für die zentrale
Stammdatenverwaltung verwenden Anwendungstransaktionen, die speziell für die IDoc-
Erzeugung programmiert wurden. Diese Transaktionen werden unter dem Oberbegriff
„Shared Master Data (SMD)“ zusammengefasst.
●Nachrichtensteuerung: Einige logistische Anwendungen in SAP ERP und SAP ERM
verwenden die Nachrichtensteuerung zur Ausgabe der Daten aus den zugehörigen
Belegen. Die Aufbereitung der Belegdaten im IDoc-Format ist eine der
Nachrichtenausgabeoptionen.
●
Anwendungsprogramme: Einige Anwendungsprogramme erzeugen IDocs direkt, indem
sie eine interne Tabelle im IDoc-Format füllen und dann weiterverarbeiten.
●Business Application Programming Interfaces (BAPIs): Das Anwendungsprogramm nutzt
ein BAPI mit einer ALE-Schnittstelle.
Notiz:
In späteren Kapiteln werden Beispiele für die IDoc-Erzeugung mittels SMD,
Nachrichtensteuerung und BAPIs vorgestellt. In den Lektionen in diesem Kapitel
erfahren Sie, wie Sie diese Instrumente für Ihre ALE-Szenarien nutzen können.
Datenaustausch mit IDocs: Überblick über den Prozess
Der Datenaustausch über IDocs beginnt im Sendersystem, wenn ein Intermediate Document
im IDoc-Format erzeugt wird, und endet mit der Buchung der vom IDoc transportierten Daten
in einer Anwendung im Zielsystem. Während dieses Prozesses werden verschiedene
Lektion: Intermediate Documents
©Copyright. Alle Rechte vorbehalten. 25Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

32. Stationen verarbeitet, die das Sender- und Zielsystem jeweils mit Statuswerten
kennzeichnen.
Abbildung 23: IDoc-Pfad und -Statuswerte
In der Abbildung „IDoc-Pfad und -Statuswerte“ sind die folgenden Statuswerte dargestellt:
●01: Unabhängig davon, wie das IDoc erzeugt wurde, wird es zuerst in der Datenbank des
sendenden Sys
tems gesichert.
●
30: Wenn alle für das Senden erforderlichen Informationen vom Empfänger empfangen
wurden, erhält das IDoc den Statusv
ersandfertig.
●
03: Wenn in den Ausgangspartnervereinbarungen angegeben ist, dass das IDoc sofort an
den Port übertragen werden muss, der in dem jeweiligen Nachrichtentyp hinterlegt ist,
wird das IDoc gesendet und erhält einen entsprechenden Status. Es ist jedoch auch
möglich, mehrere IDocs zu einem späteren Zeitpunkt gebündelt zu senden.
●
50: Das IDoc wird in der Datenbank des Zielsystems gesichert.
●64: Wenn alle Informationen zur Weiterverarbeitung bekannt sind, kann das IDoc an die
Anwendung überg
eben werden.
●
62: Wenn in den Eingangspartnervereinbarungen festgelegt ist, dass das IDoc sofort an die
Anwendung übertrag
en werden muss, versucht das Zielsystem, die IDoc-Daten zu buchen.
●
53: Wenn die Eingangsverarbeitung erfolgreich ist, erhält das IDoc diesen Statuswert.
Notiz:
Informationen zu weiteren Statuswerten erhalten Sie im Kapitel „Überwachung
der Datenverteilung, Fehlerbehandlung und Archivierung“.
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 26Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

33. Datenaustausch mit IDocs: Prozessteilschritte
Das Anwendungsprogramm erzeugt ein Master-IDoc, das die Anwendungsdaten enthält.
Abbildung 24: Master-IDoc erzeugen
Das Master-IDoc wird an die sogenannte ALE-Schicht übergeben. Die ALE-Schicht ist der
ALE-spezifische Teil des Anwendungsprogramms.
Die ALE-Schicht überprüft das Verteilungsmodell, um die Empfänger der Nachricht zu
ermitteln.
Lektion: Intermediate Documents
©Copyright. Alle Rechte vorbehalten. 27Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

34. Abbildung 25: Empfängerbestimmung in der ALE-Schicht
Als nächsten Schritt während der Programmausführung überprüft das Sendersystem die
Ausgangspartnervereinbarungen auf den verwendeten Nachrichtentyp. Für jeden Empfänger
wird entsprechend dem Basistyp ein Kommunikations-IDoc erzeugt und in der Datenbank
abgelegt.
Um das Kommunikations-IDoc zum Empfänger senden zu können, verwendet das
Sendersystem die Ausgangspartnervereinbarung zur Ermittlung des Ports (bzw. des
Kommunikationskanals), über den das IDoc an das Zielsystem übertragen werden soll. Das
IDoc wird dann in das passende Format für den Port konvertiert. Dieser Teil des Programms
wird auch als Kommunikationsschicht bezeichnet.
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 28Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

35. Abbildung 26: Weitere Verarbeitung in der Kommunikationsschicht
Die ALE-Schicht kann ein Kommunikations-IDoc direkt an die Kommunikationsschicht
übergeben. Aus Performancegründen ist es jedoch besser, die IDocs in der Datenbank zu
speichern und zu einem späteren Zeitpunkt gemeinsam zu verarbeiten. Die
Partnervereinbarung legt fest, ob ein Kommunikations-IDoc sofort oder erst später an den
Port gesendet werden soll.
Das Kommunikations-IDoc lässt sich mit einem Brief vergleichen, der an einen oder mehrere
Empfänger geschickt werden soll. Der Brief wird kopiert, und für jeden Empfänger wird eine
Kopie in einen Umschlag gesteckt. Der Absender und der Empfänger sind auf dem Umschlag
notiert. Der Umschlag wird dann in ein Postausgangsfach gelegt, dessen Inhalt später in einen
Briefkasten geworfen wird.
Für das Versenden der IDocs werden die tRFC- und Datei-Ports verwendet.
Lektion: Intermediate Documents
©Copyright. Alle Rechte vorbehalten. 29Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

36. Abbildung 27: Porttypen
Durch die Technologie des transaktionalen Remote Function Call (tRFC) wird sichergestellt,
dass der Empfänger das Dokument nur einmal erhält. Wenn der Empfänger zum Zeitpunkt
der Zustellung nicht erreichbar ist, versucht das System in regelmäßigen Abständen, die
Verbindung erneut herzustellen. Das Dokument wird erst aus der tRFC-Warteschlange
gelöscht, wenn es das Zielsystem erreicht hat. In ALE-Szenarien erfolgt die Datenübertragung
über tRFC.
Nicht jedes Partnersystem ist in der Lage, das RFC-Protokoll zu interpretieren. In EDI-
Szenarien mit Konverter wird deshalb häufig ein Datei-Port verwendet. Das IDoc wird in
diesem Datei-Port als sequenzielle Datei auf Betriebssystemebene auf eine Weise
gespeichert, dass das Zielsystem darauf zugreifen kann. Im Port wird ein entsprechender
Pfad im Dateisystem eingetragen.
Im Empfängersystem wird das IDoc anfänglich in der Datenbank gesichert.
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 30Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

37. Abbildung 28: Eingangsverarbeitung im Zielsystem
Je nach Standardwerten in den Partnervereinbarungen wird das IDoc entweder sofort an die
ALE-Schicht übertragen oder erst später durch ein Programm für die
Hintergrundverarbeitung.
Die ALE-Schicht ermittelt anhand der Partnervereinbarung einen Transaktionscode, der
steuert, wie das IDoc weiter verarbeitet wird. In der Regel werden die Daten über einen
Funktionsbaustein an die Anwendung übergeben. Es kann aber auch ein Workflow gestartet
werden.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Die Begriff e Basistyp, Master-IDoc und Kommunikations-IDoc und deren Unterschiede
erläutern
●Die Details für die Basistypen festlegen
●Den Prozess vom Anlegen eines IDocs im Sendersystem bis zur Verarbeitung im
Zielsystem beschreiben
Lektion: Intermediate Documents
©Copyright. Alle Rechte vorbehalten. 31Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

38. Kapitel 1
Lektion 5
Synchronisation von Customizing-
Einstellungen
ÜBERBLICK ÜBER DIE LEKTION
Ein systemübergreifender Datenaustausch setzt grundlegende Konfigurationen der
Anwendungen voraus, die an den abzustimmenden Sender- und Zielsystemen beteiligt sind.
In dieser Lektion wird die Synchronisation von Customizing-Einstellungen für ALE-Zwecke
erörtert.
Unternehmensszenario
Sie haben Ihre Geschäftsprozesse bereits in einem System modelliert. Sie möchten nun einen
Teilprozess in ein Zweitsystem auslagern. Sie möchten die Auswirkungen dieses Vorgangs
beurteilen und sich einen Überblick über die verschiedenen Methoden zur Abstimmung der
Systemkonfigurationen verschaff en.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Methoden zur Anpassung der Customizing-Einstellungen in SAP-Systemlandschaften
beschreiben
Auswirkungen der Anwendungsverteilung über zwei Systeme
Wenn alle Anwendungen in einem System integriert sind, greifen die Programme auf die
gleiche Datenbank zu. Bei dieser Art von System ist deshalb Datenkonsistenz gewährleistet,
weil jede logische Information in nur einer Datenbanktabelle gespeichert wird und alle
Programme Daten direkt von dieser Datenbank abrufen. Sobald jedoch eine Anwendung von
den übrigen Anwendungen getrennt wird, weil sie z.B. in einem anderen System installiert
wird, müssen die Anwendungen über Schnittstellen kommunizieren. Die Customizing-
Einstellungen und Stammdaten müssen aber in allen untereinander kommunizierenden
Systemen konsistent sein.
©Copyright. Alle Rechte vorbehalten. 32Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

39. Abbildung 29: Anwendungen auf zwei Systeme verteilen
In ALE-Szenarien werden Anwendungsdaten mithilfe von IDocs zwischen den an einem
Vorgang beteiligten Systemen ausgetauscht. Dieser Austausch kann nur funktionieren, wenn
ein IDoc ausschließlich Felder enthält, die ebenfalls im Zielsystem definiert sind, es sei denn,
es handelt sich um Felder, für die eine uneingeschränkte Datenerfassung vorgesehen ist. In den meisten Feldern in den Stammdaten und Belegen für SAP-Anwendungen sind aber nur
die im Customizing vordefinierten Feldwerte zulässig. Dies heißt, dass Sie vor der Verteilung
der Daten sicherstellen müssen, dass diese Kataloge von Werten im Sender- und Empfängersystem übereinstimmen. Wenn Sie die Systeme nicht in Einklang bringen können (oder wollen), müssen abweichende Feldwerte während der weiteren Verarbeitung des aus- oder eingehenden IDocs durch Werte aus dem Zielsystem ersetzt werden.
Geschäftsprozess in einem System
Ein Geschäftsprozess besteht oft aus mehreren einzelnen Prozessschritten. Innerhalb eines
Geschäftsprozesses kann ein Bearbeiter für mehr als einen Schritt verantwortlich sein.
Prozessschritte können jedoch auch von verschiedenen Bearbeitern ausgeführt werden. An
den Anwendungen in SAP können mehrere Teillösungen beteiligt sein. Sobald ein
Prozessschritt verarbeitet wurde, werden die neu angelegten oder geänderten Daten in der
Datenbank gesichert. Der Bearbeiter des nächsten Prozessschritts muss benachrichtigt
werden. Außerdem müssen die für die Ausführung des nächsten Schritts erforderlichen
Daten übertragen werden.
Lektion: Synchronisation von Customizing-Einstellungen
©Copyright. Alle Rechte vorbehalten. 33Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

40. Abbildung 30: Geschäftsprozess in einem System: Beispiel
Die Abbildung „Geschäftsprozess in einem System: Beispiel“ zeigt einen Kundenauftrag, der
aktuell in einem SAP-ERP-System verarbeitet wird. Bearbeiter 1, ein Vertriebsmitarbeiter,
erfasst den Kundenauftrag im System. Das System (Bearbeiter 2) erzeugt automatisch die
Auslieferung dieses Kundenauftrags. Ein weiterer Mitarbeiter (Bearbeiter 3) legt einen
Transportauftrag an, sodass das auszuliefernde Produkt aus dem Lagerbestand entfernt
wird. Sobald das Produkt ausgelagert wurde, bucht das System (Bearbeiter 2) den
Warenausgang. So kann der Vertriebsmitarbeiter (Bearbeiter 1) den Prozess durch Anlegen
der Faktura, d.h. der Rechnung für den Kunden, abschließen. An diesem Prozess sind also
nicht nur verschiedene Bearbeiter, sondern auch unterschiedliche Teillösungen beteiligt
(Vertrieb, Lieferabwicklung, Lagerverwaltung und Bestandsführung).
Geschäftsprozesse in mehreren Systemen
Wenn sich ein Geschäftsprozess nicht nur auf verschiedene Teillösungen erstreckt, sondern
auch auf unterschiedliche Systeme, müssen bestimmte Daten an den nächsten Bearbeiter
weitergeleitet werden. In den ALE-Szenarien fungiert ein IDoc als Container für diese Daten.
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 34Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

41. Abbildung 31: Geschäftsprozesse in zwei Systemen: Beispiel
Die Abbildung „Geschäftsprozesse in zwei Systemen: Beispiel“ veranschaulicht den gleichen
Prozess. Der Unterschied zum ersten Beispiel besteht darin, dass die Lagerverwaltung an ein
zweites SAP-System ausgelagert ist. Die Versanddaten aus dem ersten System werden in
einem IDoc an das zweite System übertragen. Im zweiten System findet die weitere
Bearbeitung im Schritt der Auslagerung statt. Ist dieser Vorgang abgeschlossen, erzeugt das Lagerverwaltungssystem ein zweites IDoc mit allen notwendigen Daten, um den Auslieferungsprozess im ersten System fortzusetzen.
Notiz:
Dies ist eine vereinfachte Darstellung des ALE-Szenarios des dezentralen
Lagerverwaltungssystems.
Customizing-Einstellungen mit ALE synchronisieren
Zusätzlich zur Verteilung von Stamm- und Bewegungsdaten können Sie mithilfe von ALE auch
die Customizing-Einstellungen zwischen Systemen abstimmen (zur Vorbereitung auf die
Verteilung von Stamm- und Bewegungsdaten). Zu diesem Zweck gibt es den Nachrichtentyp
CONDA2in den SAP-ERP-Systemen (ALE: Synchronisation von Customizing-Daten). Den
Kern dieser Funktion bildet eine automatische Anpassung ausgewählter Customizing-Objekte
in zwei SAP-Systemen, wodurch Transportaufträge für alle Änderungen erzeugt werden.
Notiz:
In Systemen vor Release SAP R/3 4.6A wurde stattdessen der Nachrichtentyp
CONDATverwendet.
Um die Verwendung von ALE für die Customizing-Synchronisation zu optimieren, wird in der
Systemlandschaft ein logisches System als das zentrale Customizing-System festgelegt.
Lektion: Synchronisation von Customizing-Einstellungen
©Copyright. Alle Rechte vorbehalten. 35Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

42. Änderungen an bestimmten Customizing-Tabellen erfolgen ausschließlich in diesem System.
Sie können genau festlegen, welche Objekte nur im Kontext der ALE-Verteilung geändert
werden dürfen. Sie gruppieren diese Objekte (ALE-Customizing-Objekte) in
Verteilungsgruppen, die automatisch dem logischen Pflegesystem zugeordnet werden.
Anschließend müssen Sie diese Verteilungsgruppen an die Zielsysteme verteilen. Es ist nun
nicht mehr möglich (bzw. nur eingeschränkt möglich, je nach Systemkonfiguration), im
Zielsystem Änderungen an den Objekten in den Verteilungsgruppen vorzunehmen.
Notiz:
Sie können alle mandantenabhängigen Customizing-Objekte der KategorieCUST
verteilen. Jedes Objekt kann jeweils nur einer Verteilungsgruppe zugeordnet
werden.
Alle Customizing-Einstellungen, die Sie für den systemübergreifenden Customizing-Abgleich
und eine nachfolgende Synchronisation benötigen, finden Sie über die Transaktion SALE.
Wählen Sie im MenüIDoc-Schnittstelle / Application Link Enabling (ALE)
→Geschäftsprozesse modellieren und implementieren→Synchronisation von Customizing-
Daten. Sie können die relevanten Anwendungstransaktionen im Menü „SAP Easy Access“
über folgenden Pfad aufrufen:Werkzeuge→ALE→ ALE-Administration→Dienste→
Customizing-Daten. Hier finden Sie ein Programm für den Abgleich der Customizing-Tabellen
im Sender- und Zielsystem, den Customizing Cross-System Viewer (TransaktionSCU0),
sowie eine Transaktion zur Erzeugung und Weiterverarbeitung von ALE-Transportaufträgen
für die Customizing-Synchronisation. Das sendende System erzeugt die IDocs des
NachrichtentypsCONDA2für die Transportaufträge. Diese IDocs enthalten die wichtigsten
Informationen zu jedem Auftrag. Die Eingangsverarbeitung dieser IDocs steuert den Import
der Auftragsdaten im Zielsystem: Entweder wird ein Workflow an den zuständigen
Administrator gesendet, in dem dieser gebeten wird, den Import auszuführen, oder der Import wird automatisch durch ein Programm im Hintergrund ausgeführt.
Notiz:
Der ALE-Transportauftrag kann über eine eigene Transaktion (BDXL) mit
Transportaufträgen für den Export der Änderungen in die Qualitätssicherungs-
und Produktionssysteme zusammengeführt werden.
Customizing-Einstellungen mit SAP Solution Manager synchronisieren
Alternativ zur Verteilung der Customizing-Einstellungen mit ALE, wie im letzten Abschnitt
beschrieben, können Sie auch SAP Solution Manager verwenden. Dieser enthält zahlreiche
Werkzeuge für die Konfiguration und den Betrieb von SAP-Lösungen. SAP Solution Manager
umfasst zwei Komponenten für die Synchronisation von Customizing-Einstellungen zwischen SAP-Systemen: Customizing Scout und Customizing-Verteilung. Customizing Scout
vergleicht die Konfigurationen mehrerer SAP-Systeme und zeigt die Unterschiede an. Der
Vergleich kann (wie in ALE) interaktiv oder im Hintergrund ausgeführt werden. Bei Bedarf ist auch eine periodische Ausführung möglich. Nach dem Abgleich der Einstellungen können
über die Customizing-Verteilung für jedes geänderte Customizing-Objekt im Pflegesystem
Transportaufträge angelegt werden. Diese Aufträge werden dann automatisch an die nachgelagerten Systeme verteilt. Eine manuelle Verteilung ist aber auch möglich. Bestimmte Customizing-Objekte sind bereits in SAP Solution Manager als Synchronisationsobjekte
vordefiniert.
Kapitel 1: ALE-Grundlagen
©Copyright. Alle Rechte vorbehalten. 36Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

43. Konvertierung von Feldwerten: globale Buchungskreise
Es ist nicht immer möglich oder wünschenswert, das Customizing innerhalb einer
Systemlandschaft zu standardisieren. Wenn beispielsweise ein logisches System die
Tochtergesellschaft eines Unternehmens darstellt, unterscheiden sich in der Regel die
Schlüssel für die Organisationseinheiten, zumindest teilweise. Die Tochtergesellschaft wird
einem anderen Buchungskreis zugeordnet als die Muttergesellschaft. Deshalb verwenden Sie
in ALE-Szenarien die sogenannten globalen Buchungskreise. Dies sind frei definierbare
Schlüssel, die jeweils einem echten Buchungskreis (d.h. einem in der Anwendung verwendeten Buchungskreis) zugewiesen sind. Wird ein Kommunikations-IDoc, in dem ein Segment das FeldBuchungskreisenthält, erzeugt, ersetzt das Sendersystem den
Buchungskreisschlüssel der Anwendung (z.B. ein zu verteilender Kundenstamm) durch den Schlüssel für den zugeordneten globalen Buchungskreis. Das Zielsystem führt den gleichen Vorgang umgekehrt aus: Es ersetzt den globalen Buchungskreis durch den echten
Buchungskreis, um den Kundenstamm anzulegen oder zu ändern. Sie finden die Tabellen zur
Definition von globalen Buchungskreisen und zu deren Verknüpfung mit den in den
Anwendungen verwendeten Buchungskreisen über die TransaktionSALEunterIDoc-
Schnittstelle / Application Link Enabling (ALE)→Geschäftsprozesse modellieren und
implementieren→Globale Organisationseinheiten einrichten→Globale Buchungskreise
einrichten. Sie müssen ähnliche Einstellungen für die Geschäftsbereiche vornehmen.
Achtung:
Sie müssen mindestens einen globalen Buchungskreis im Sender- und im
Zielsystem definieren und zuweisen, selbst wenn die Buchungskreisschlüssel
identisch sind. Wenn diese Einstellung fehlt, schlägt die IDoc-Verarbeitung fehl.
Das Ausgangs-IDoc erhält den Status 29 (Fehler in ALE-Dienst) und das
Eingangs-IDoc den entsprechenden Status 65.
Es gibt nur wenige Fälle, in denen Sie Feldwerte direkt unter Verwendung von Customizing-
Tabellen konvertieren können, bevor das IDoc gesendet wird oder dessen
Eingangsverarbeitung erfolgt. Für alle anderen Feldwerte, die durch andere Werte ersetzt
werden müssen, können Sie die Feldumsetzung verwenden. Dieses Tool ermöglicht es dem
Sender- oder Zielsystem, den Inhalt der IDoc-Segmentfelder während der Laufzeit des
betreffenden Anwendungsprogramms zu ändern. Die Feldumsetzung basiert auf Regeln und
unterstützt eine diff erenziertere Datenänderung, als wenn Werte auf der Basis von
Customizing-Tabelleneinträgen ausgetauscht werden.
Notiz:
Die Konfiguration der Feldumsetzung ist eines der in der Schulung BIT350 (ALE-
Erweiterungen) behandelten Themen.
*Diese moderierte Diskussion wurde aus rein formellen Gründen in die Lektion aufgenommen.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Methoden zur Anpassung der Customizing-Einstellungen in SAP-Systemlandschaften
beschreiben
Lektion: Synchronisation von Customizing-Einstellungen
©Copyright. Alle Rechte vorbehalten. 37Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

44. KAPITEL 2Stammdatenverteilung
Lektion 1
Beispiel: Materialstamm 39
Lektion 2
Verwenden von Änderungszeigern 50
Lektion 3
Datenfilterung und Verringern der Datenmenge 53
LERNZIELE
●Die Konfiguration eines ALE-Szenarios zum Verteilen von Materialstammdaten
beschreiben
●Materialstämme verteilen
●Die Verwendung von Änderungszeigern in der Stammdatenverteilung und Einrichten von
diesen im System erläutern
●Die verschiedenen Methoden zur Datenfilterung in der IDoc-Verarbeitung beschreiben
●Einen reduzierten Nachrichtentyp anlegen und diesen im Verteilungsprozess verwenden
©Copyright. Alle Rechte vorbehalten. 38Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

45. Kapitel 2
Lektion 1
Beispiel: Materialstamm
ÜBERBLICK ÜBER DIE LEKTION
Die Stammdatenverteilung ist eine der Anwendungen von Application Link Enabling (ALE).
Diese Lektion bietet eine Einführung in das SMD-Tool (Shared Master Data) für die
Stammdatenverteilung mithilfe des Materialstamms als Beispiel.
Unternehmensszenario
Sie möchten, dass in Zukunft sämtliche Materialstämme für das gesamte
Unternehmensnetzwerk ausschließlich im zentralen System gespeichert werden. Außerdem
sollen sie von dort aus an die nachgelagerten Systeme der Vertriebsniederlassungen und der
Produktion gesendet werden.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●
Die Konfiguration eines ALE-Szenarios zum Verteilen von Materialstammdaten
beschreiben
●Materialstämme verteilen
Zentrale Materialstammverwaltung
Eine Methode für die konsistente Beibehaltung der Stammdaten in einer Systemlandschaft
besteht darin, die Stammdaten in einem zentralen System zu pflegen und sie in regelmäßigen
Abständen in den nachgelagerten Systemen zu replizieren. In diesen Systemen können Daten
entweder überhaupt nicht oder nur eingeschränkt geändert werden.
©Copyright. Alle Rechte vorbehalten. 39Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

46. Abbildung 32: Beispielszenario
In der Abbildung „Beispielszenario“ werden die Materialstämme für das Unternehmen in der
Zentrale (zentrales System) angelegt und geändert. Neue Materialstämme und Änderungen
an vorhandenen Daten werden regelmäßig an die nachgelagerten Systeme für Vertrieb und
Produktion gesendet.
Notiz:
Die Lektion „Verwenden von Änderungszeigern“ behandelt die Verteilung von
Änderungen an den Stammdaten in regelmäßigen Abständen.
Für die Verteilung von Stammdaten sind ALE-Standardszenarien vorhanden. Diese werden in
der SAP-Bibliothek und im Einführungsleitfaden dokumentiert. Mithilfe der TransaktionSALE
finden Sie Beschreibungen dazu, wie Sie bestimmte Verteilungsszenarien für Stammdaten
einrichten. Wählen Sie dazuIDoc-Schnittstelle / Application Link Enabling
(ALE)→Geschäftsprozesse modellieren und implementieren→Vordefinierte ALE-
Geschäftsprozesse konfigurieren →Logistik→Stammdatenverteilung. Weitere Informationen
finden Sie unter dem MenüpfadDoc-Schnittstelle / Application Link Enabling
(ALE)→Geschäftsprozesse modellieren und implementieren→Verteilung von Stammdaten
konfigurieren . In diesem Abschnitt des Einführungsleitfadens können Sie die Customizing-
Einstellungen für die Verteilungsszenarien Ihrer Stammdaten durchführen, die in dieser Lektion beschrieben werden.
Vor dem Konfigurieren eines beliebigen Verteilungsszenarios müssen Sie die folgenden
Fragen beantworten:
●In welchem System werden welche Stammdaten gepflegt?
●Wann und wie oft sollen die Stammdaten in den nachgelagerten Systemen repliziert
werden?
●Wenn mehrere Zielsysteme vorhanden sind, sind alle Änderungen an den Stammdaten für
alle Zielsysteme relevant?
Kapitel 2: Stammdatenverteilung
©Copyright. Alle Rechte vorbehalten. 40Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

47. ●Welche Customizing-Einstellungen müssen in den beteiligten Systemen synchronisiert
werden?
Konfigurieren der zentralen Materialstammverwaltung
Die Abbildung „Grundeinstellungen für das ALE-Szenario“ stellt die wichtigsten Elemente im Beispielszenario dar:
Abbildung 33: Grundeinstellungen für das ALE-Szenario
Das logische System in der Zentrale wirdCOREgenannt. Die logischen Systeme in den
Vertriebsniederlassungen werdenSALESund das logische System für die Produktion wird
PRODUCTIONgenannt. Der Nachrichtentyp für die Verteilung der Materialstämme lautet
MATMAS.
Anhand dieser Informationen legen Sie im Verteilungsmodell eines der beteiligten Systeme
eine neue Sicht an. Im Schulungsszenario stellt „CORE“ das Pflegesystem für alle
Modellsichten dar. In der neuen Sicht müssen Sie das Verhalten des Senders und des
Empfängers angeben und das System darüber informieren, welcher Nachrichtentyp verteilt
werden soll.
Abbildung 34: Verteilungsmodell pflegen und Sichten verteilen
Lektion: Beispiel: Materialstamm
©Copyright. Alle Rechte vorbehalten. 41Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

48. Aus Konsistenzgründen sollten Sie das Verteilungsmodell zentral pflegen und die
entsprechenden Sichten an die anderen beteiligten Systeme verteilen oder zu diesen
transportieren.
Wenn bereits RFC-Destinationen (RFC = Remote Function Call) mit demselben Namen wie die
logischen Zielsysteme vorhanden sind, können Sie jetzt veranlassen, dass das System die
Ausgangspartnervereinbarungen für die neue Modellsicht anlegt. Beim Generieren von
Partnervereinbarungen legt das System automatisch einen Eintrag für den Nachrichtentyp
MATMASsowie einen Eintrag für den NachrichtentypSYNCH
für jedes Profil an ( ALE:
Dummy-Nachrichtentyp zur Ermittlung von RFC-Destinationen). Dieser Nachrichtentyp wird
nicht zum Erzeugen von IDocs verwendet. Er dient ausschließlich zur Ermittlung der RFC- Destination des entsprechenden Zielsystems. Der Eintrag für den NachrichtentypSYNCHist
eine Voraussetzung für die Verteilung von Modellsichten.
Notiz:
Wenn Ihre RFC-Destinationen andere Namen als die Zielsysteme aufweisen, zu
denen sie führen, müssen Sie zunächst den Eintrag für den Nachrichtentyp
SYNCHmanuell anlegen und anschließend die erforderliche RFC-Destination mit
dem entsprechenden Port zuordnen. Anschließend kann das System die
verbleibenden Partnervereinbarungen generieren.
Für ALE-Szenarien wird stets die Partnerart LS (logisches System) angelegt. Der Name des
Partners entspricht stets dem Namen des logischen Systems.
Abbildung 35: Partnervereinbarung: Partnerart
Die Abbildung „Partnervereinbarung (Ausgang)“ ist eine schematische Darstellung der
wichtigsten Einstellungen auf der Ebene der Ausgangspartnervereinbarung:
Kapitel 2: Stammdatenverteilung
©Copyright. Alle Rechte vorbehalten. 42Librer?a= ERm https://libreriaerp.com/us [email protected] Librer?a= ERm https://libreriaerp.com/us [email protected]

49. Abbildung 36: Ausgangspartnervereinbarung für den Materialstamm
Speichern Sie in der Ausgangspartnervereinbarung für einen Nachrichtentyp die folgenden
Informationen:
●Empfängerport: In ALE-Szenarien tauschen Sender- und Zielsysteme Daten über RFC aus.
Daher müssen Sie in den Ausgangspartnervereinbarungen für ALE-Szenarien einen Port
vom Typ des transaktionalen RFC verwenden. Die RFC-Destination für diesen RFC führt
zum Zielsystem, dem Partner in den Vereinbarungen.
●
Ausgabemodus: Sie können zwischenIDoc sofort übergebenoderIDocs sammelnwählen.
●Paketgröße: Wenn SieIDoc sofort übergebenwählen, werden die IDocs einzeln gesendet.
Wenn SieIDocs sammelnwählen, werden mehrere IDocs in Paketen zusammengefasst
und gemeinsam gesendet. Wenn Sie IDocs gesammelt senden, kann dies zu einer verbesserten Performance führen. Als Richtlinie empfehlen wir Ihnen, abhängig von der Größe der IDocs zwischen 20 und 100 IDocs zu sammeln.
●
Basistyp: In diesem Feld müssen Sie den IDoc-Typ eingeben, der kompatibel mit der
Freigabeebene des Zielsystems ist.
Notiz:
Wenn Sie den AusgabemodusIDocs sammelnauswählen, müssen Sie die IDocs
mit dem Programm RSEOUT00 an die Kommunikationsschicht übertragen.
Dieses Programm wird in der Regel als regelmäßiger Hintergrundjob eingeplant.
Nachdem Sie die Ausgangspartnervereinbarungen für die Zielsysteme angelegt haben,
können Sie die neue Modellsicht an diese Systeme verteilen.
Lektion: Beispiel: Materialstamm
©Copyright. Alle Rechte vorbehalten. 43Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

50. Abbildung 37: Verteilen der Modellsicht
Nachdem Sie die Modellsicht erfolgreich an die Systeme „SALES“ und „PRODUCTION“
verteilt haben, können Sie die Kopien in ihren entsprechenden Verteilungsmodellen anzeigen.
Als letzten Schritt müssen Sie veranlassen, dass das System die
Eingangspartnervereinbarungen mit dem Sendersystem „CORE“ generiert. Alternativ können
Sie die Daten manuell speichern.
Abbildung 38: Partnervereinbarung (Eingang)
Speichern Sie in der Eingangspartnervereinbarung für einen Nachrichtentyp die folgenden
Informationen:
●Vorgangscode: Der Vorgangscode ist ein Schlüssel, der sich entweder auf einen
Funktionsbaustein oder auf einen Workflow für die Verarbeitung der IDocs bezieht. Der
Kapitel 2: Stammdatenverteilung
©Copyright. Alle Rechte vorbehalten. 44Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

51. Vorgangscode für den NachrichtentypMATMASlautetMATM. Wenn Sie auf den
Vorgangscodeschlüssel doppelklicken, wird ein Bild mit den Informationen angezeigt,
welcher Funktionsbaustein bzw. Workflow für die IDoc-Eingangsverarbeitung verwendet
wird. In der Regel werden in ALE-Szenarien Funktionsbausteine verwendet.
Notiz:
Für einen Nachrichtentyp können auch mehrere Vorgangscodes (und
entsprechend mehrere Eingangsbausteine oder Workflows) vorhanden sein.
Informationen dazu, welche Vorgangscodes welchen der Nachrichtentypen
zugeordnet sind, finden Sie in der Tabelle Eingangsvorgangscode(Transaktion
WE42).
●Verarbeitungsmodus: Sie können zwischenAnstoß durch Hintergrundprogrammund
Anstoß sofortwählen Falls SieAnstoß durch Hintergrundprogrammwählen, werden die
IDocs mit dem Programm RBDAPP01 an die ALE-Schicht übergeben. Dieses Programm
wird in der Regel als regelmäßiger Hintergrundjob eingeplant.
Abbildung 39: Verarbeitungszeitpunkte
Sie können für die Programme RSEOUT00 und RBDAP001 Varianten für die
Sammelbearbeitung der IDocs im Hintergrund definieren. Beide Programme finden Sie im
Einführungsleitfaden über die TransaktionSALE. Wählen Sie IDoc-Schnittstelle / Application
Link Enabling (ALE)→Überwachung der Systeme einstellen→IDoc-Verarbeitung→Versand
gesammelter IDocsoderVerbuchung von IDocs im Empfängersystem.
Sie können den aktuellen Status der IDocs in SAP ERP oder SAP ERM über einen
Statusmonitor prüfen. Diesen Monitor können Sie mit TransaktionBD87oder über den
MenüpfadWerkzeuge→ALE→ ALE-Administration→Monitoring→IDoc-
Anzeige→Statusmonitoraufrufen.
Lektion: Beispiel: Materialstamm
©Copyright. Alle Rechte vorbehalten. 45Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

52. Notiz:
Die Überwachung der IDoc-Verarbeitung wird zusammen mit der
Fehlerbehandlung im Kapitel „Überwachung der Datenverteilung,
Fehlerbehandlung und Archivierung“ behandelt.
Senden und Anfordern von Stammdaten
Das SMD-Tool (Shared Master Data) bietet Ihnen eine Reihe von Anwendungstransaktionen
zum Erzeugen von IDocs für die Verteilung von Stammdaten. Sie finden diese Transaktionen
über den MenüpfadWerkzeuge→ALE→ Stammdatenverteilung. Sie können auch alle SMD-
Transaktionen direkt über die TransaktionBALMaufrufen.
Abbildung 40: Senden von Stammdaten
Sie können beispielsweise die Materialstämme direkt über die TransaktionBD10senden
(Menüpfad:
Werkzeuge→ALE→ Stammdatenverteilung→Anwendungsübergreifend→Material). In
dieser Transaktion können Sie entweder ein Zielsystem angeben oder vom System den
Empfänger aus dem Verteilungsmodell ermitteln lassen. Wenn Sie kein Zielsystem angeben,
erzeugt das Sendersystem möglicherweise mehrere IDocs.
In ALE-Szenarien werden Stammdaten normalerweise aus dem Pflegesystem an die
nachgelagerten Systeme gesendet. Bei anwendungsübergreifenden Stammdaten (Material, Kunde, Lieferant) können Sie jedoch auch Daten abrufen.
Kapitel 2: Stammdatenverteilung
©Copyright. Alle Rechte vorbehalten. 46Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

53. Abbildung 41: Abrufen von Stammdaten
Der NachrichtentypMATFETwird beispielsweise zum Abrufen von Materialstämmen
verwendet. Dieser Nachrichtentyp ist mit den entsprechenden Sichten im Verteilungsmodell
verknüpft (siehe Abbildung). Im Anwendungsmenü finden Sie die Transaktion BD11über
Werkzeuge→ALE→ Stammdatenverteilung→Anwendungsübergreifend→Material→Holen
. Das Zielsystem kann mit dieser Transaktion Materialstämme vom Sendersystem anfordern.
Der NachrichtentypMATMASwird zum Senden der Materialstamm-IDocs verwendet.
Anlegen und Verteilen einer Modellsicht
1.Wählen Sie im EinführungsleitfadenSAP Ne tWeaver→Application Server→IDoc-
Schnittstelle / Application Link Enabling (ALE)→Geschäftsprozesse modellieren und
implementieren→Verteilungsmodell pflegen und Sichten verteilen aus. Wechseln Sie vom
Anzeige- in den Änderungsmodus, indem Sie aufZwischen Anzeige- und
Bearbeitungsmodus wechseln klicken.
2.Wählen SieModellsicht anleg en, und geben Sie im neuen Fenster eine Kurzbeschreibung
Ihrer Modellsicht sowie einen technischen Namen für die Ermittlung der Modellsicht ein.
Bestätigen Sie Ihre Eingaben mit derEingabetaste, und sichern Sie, um die neue
Modellsicht anzulegen.
3.Markieren Sie Ihre neue Modellsicht, und wählen SieNachrichtentyp einfügen. Geben Sie
im sich öffnenden Fenster die logischen Systemnamen sowohl des Senders als auch des
Empfängers und Ihren gewünschten Nachrichtentyp ein. Bestätigen Sie diese Eingaben mit derEingabetaste. Dadurch kehren Sie zum Verteilungsmodell zurück, in dem Sie die
Änderungen sichern können.
Wenn Sie ein BAPI mit der Modellsicht anstelle eines Nachrichtentyps verknüpfen
möchten, klicken Sie auf die DrucktasteBAPI einfügen. Fügen Sie die logischen
Systemnamen des Senders und des Empfängers hinzu (d.h. das Zielsystem des
Methodenaufrufs), und geben Sie die Beschreibung (nicht den Schlüssel) des Business-
Objekttyps, der verwendet werden soll, sowie die entsprechende Methode ein. Bestätigen
Sie die Eingaben mit derEingabetaste.
4.Zum Verteilen der Modellsicht an ein Partnersystem müssen Ausgangspartnervereinbarungen mit dem Partner für den NachrichtentypSYNCH
Lektion: Beispiel: Materialstamm
©Copyright. Alle Rechte vorbehalten. 47Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

54. vorhanden sein. Um zu prüfen, ob diese vorhanden sind, wählen Sie (im Menü des
Verteilungsmodells)Umfeld→Partnervereinbarung ändernaus. Suchen Sie im Ordner für
die Partnerart LS nach einem Eintrag für Ihr Partnersystem, und prüfen Sie die
Ausgangsparameter. Wenn Sie keinen Eintrag für den NachrichtentypSYNCH
finden,
fügen Sie einen Eintrag manuell ein, indem Sie einen Empfängerport mit einem Eintrag für die RFC-Destination zuweisen, die zum Partnersystem führt. Der Basistyp weist SYNCHRONals Schlüssel auf.
Hinweis:
Wenn der logische Systemname des Empfängersystems mit dem Namen der
RFC-Destination identisch ist, die zu ihm führt, kann das System die
Ausgangspartnervereinbarungen für den NachrichtentypSYNCHund für
sämtliche anderen die Nachrichtentypen der Modellsicht automatisch
anlegen. Wählen Sie dazu im Menü des Verteilungsmodells
Umfeld→Partnervereinbarung generierenaus.
5.Verteilen Sie die neue (oder geänderte) Modellsicht, indem Sie den entsprechenden
Eintrag im Verteilungsmodell auswählen und das Menü
Bearbeiten→Modellsicht→Verteilenaufrufen. Wenn für die zu verteilenden Daten
mehrere mögliche Empfänger vorhanden sind, die Modellsicht jedoch nur an einen
bestimmten Empfänger gesendet werden soll, heben Sie im sich öffnenden Fenster
Modellsichten verteilendie Auswahl der Einträge für die anderen Empfänger auf.
Sie erhalten dann ein Protokoll, das Sie darüber informiert, ob die neue (oder geänderte)Modellsicht erfolgreich verteilt wurde.
6.Sofern noch nicht bereits durchgeführt, legen Sie die Ausgangspartnervereinbarungen fürdie Nachrichtentypen an, die Sie gerade der Modellsicht hinzugefügt haben. Wenn für denNachrichtentypSYNCHAusgangspartnervereinbarungen vorhanden sind (siehe Schritt
4), kann das System sämtliche Partnervereinbarungen für alle anderen denNachrichtentyp generieren (Umfeld→Partnervereinbarung generieren). Wenn Sie eine
Ausgangspartnervereinbarung manuell angelegt haben, müssen Sie zusätzlich zumNachrichtentyp einen Empfängerport mit der entsprechenden RFC-Destination und einenBasistyp zuordnen.
Achtung:
Beachten Sie bei der Versionsauswahl den Freigabestatus des
Empfängersystems, da der Basistyp auch im Zielsystem erkannt werden
muss.
Außerdem müssen Sie entscheiden, ob die IDocs sofort oder zu einem späteren Zeitpunkt
gesendet werden sollen.
7.Damit Sie die neue (oder geänderte) Modellsicht in einem ALE-Szenario verwenden können, müssen Sie jetzt geeignete Eingangspartnervereinbarungen im Zielsystem anlegen (oder veranlassen, dass das System diese generiert). In den Eingangspartnervereinbarungen ist ein entsprechender Vorgangscode für den Nachrichtentyp erforderlich. Dieser Code muss mit dem Funktionsbaustein oder dem
Workflow für die Eingangsverarbeitung verknüpft sein. Wenn das System die
Partnervereinbarungen generiert, sollten Sie prüfen, ob für Ihr Szenario der richtige Vorgangscode zugeordnet wurde.
Kapitel 2: Stammdatenverteilung
©Copyright. Alle Rechte vorbehalten. 48Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

55. ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Die Konfiguration eines ALE-Szenarios zum Verteilen von Materialstammdaten
beschreiben
●Materialstämme verteilen
Lektion: Beispiel: Materialstamm
©Copyright. Alle Rechte vorbehalten. 49Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

56. Kapitel 2
Lektion 2
Verwenden von Änderungszeigern
ÜBERBLICK ÜBER DIE LEKTION
Sie können Stammdaten jederzeit während ihrer gesamten Lebensdauer ändern. Wenn Sie
über eine zentrale Stammdatenverteilung verfügen, müssen Sie sicherstellen, dass sämtliche
Änderungen sofort an die nachgelagerten Systeme übertragen werden. In dieser Lektion
lernen Sie die Verteilung von Änderungen an den Stammdaten über Änderungszeiger.
Unternehmensszenario
In Ihrem Unternehmen werden Stammdaten in einem einzigen zentralen System angelegt
und geändert. Sie müssen sicherstellen, dass alle Änderungen sofort an die Vertriebs- und
Produktionssysteme weitergeleitet werden.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Die Verwendung von Änderungszeigern in der Stammdatenverteilung und Einrichten von
diesen im System erläutern
Verteilen von Stammdatenänderungen
In diesem Beispiel besteht die Systemlandschaft aus der Zentrale, einer
Vertriebsniederlassung und der Produktion:
Abbildung 42: Beispielszenario
Alle Stammdaten werden im logischen System der Zentrale angelegt und dort ggf. geändert.
Neu angelegte und geänderte Stammsätze sollen regelmäßig an logische Systeme des
©Copyright. Alle Rechte vorbehalten. 50Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

57. Vertriebs und der Produktion verteilt werden, damit auch diese Systeme über aktuelle Daten
verfügen.
Änderungszeiger
Viele Anwendungsprogramme legen für jede Änderung, die an ihren Objekten (Stammdaten
und Belege) vorgenommen wird, Änderungsbelege an. Diese Änderungsbelege erfassen
Änderungen an den Anwendungsobjekten, wobei in der Regel der Änderer und der Zeitpunkt,
zu dem die Änderung vorgenommen wurde, angegeben werden. Mithilfe dieser
Änderungsbelege können in Application Link Enabling (ALE) Änderungszeiger festgelegt
werden. Mit Änderungszeigern kann das Sendersystem alle geänderten Datensätze
auswählen und nur diese an die Zielsysteme senden.
Abbildung 43: Änderungsbelege und Änderungszeiger
Bei der Stammdatenverteilung über das SMD-Tool (Shared Master Data) können Sie in
Customizing festlegen, ob ein Nachrichtentyp mit der Änderungszeigerfunktion funktioniert.
Der Änderungszeiger stellt eine Verbindung zwischen Änderungsbelegen und dem
entsprechenden Nachrichtentyp her.
Beim Anlegen oder Ändern eines Stammsatzes fragt das Anwendungsprogramm ab, ob der
Mechanismus des Änderungszeigers aktiviert wurde. Wenn die Funktion aktiv ist, wird der
Änderungszeiger in der Datenbank zusammen mit dem Anwendungsbeleg und dem
Änderungsbeleg gespeichert.
Notiz:
Zeigen Sie die Änderungsbelege mit dem BerichtRSSCD100an. Sie können die
Änderungsbelege auch über die betreffende Anwendungstransaktion aufrufen.
Die Änderungszeiger können Sie in der Datenbanktabellen-ViewBDCPVanzeigen.
Lektion: Verwenden von Änderungszeigern
©Copyright. Alle Rechte vorbehalten. 51Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

58. Abbildung 44: Erzeugen von IDocs aus Änderungszeigern
Sie können mit dem ProgrammRBDMIDOCÄnderungszeiger auswerten. Dieses Programm
wird in der Regel als regelmäßiger Hintergrundjob eingeplant. Sie können das Programm zu
Testzwecken mit der TransaktionBD21starten (wählen SieWerkzeuge→ALE→ ALE-
Administration→Dienste→Änderungszeiger→Auswerten).
Die Anwendung bietet einen Funktionsbaustein, der die Änderungszeiger auswählt, und
erzeugt ein Master-IDoc für jeden für die Verteilung relevanten, geänderten
Anwendungsbeleg, der dann an die ALE-Schicht übergeben wird. Sie können die Zuordnung
von Nachrichtentyp und Funktionsbaustein zum Auswerten des Änderungszeigers mit der
TransaktionBD60anzeigen (wählen SieWerkzeuge→ALE→ ALE-
Entwicklung→IDoc→Änderungsdienst→
Funktionsbaustein für Auswertung pflegen ).
Wenn Sie Stammdaten verteilen möchten, prüfen Sie, ob die Änderungszeigerfunktion generell aktiviert ist (d.h. für die Mandanten Ihres SAP-Systems). Aktivieren Sie dann die Aktualisierung der Änderungszeiger für alle Nachrichtentypen, die Sie in Ihren Verteilungsszenarien verwenden möchten. Sie können die entsprechende Tabelle im Einführungsleitfaden über die TransaktionSALEaufrufen. Wählen Sie dazuIDoc-
Schnittstelle / Application Link Enabling (ALE)→Geschäftsprozesse modellieren und
implementieren→
Verteilung von Stammdaten konfigurieren →Replikation von geänderten
Daten einrichten→Änderungszeiger generell aktivierenbzw.Änderungszeiger pro
Nachrichtentyp aktivieren.
*Diese moderierte Diskussion wurde aus rein formellen Gründen in die Lektion aufgenommen.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Die Verwendung von Änderungszeigern in der Stammdatenverteilung und Einrichten von
diesen im System erläutern
Kapitel 2: Stammdatenverteilung
©Copyright. Alle Rechte vorbehalten. 52Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

59. Kapitel 2
Lektion 3
Datenfilterung und Verringern der
Datenmenge
ÜBERBLICK ÜBER DIE LEKTION
In ALE-Szenarien (Application Link Enabling) sollen nicht immer alle Empfängersysteme
sämtliche Daten vom Sendersystem erhalten. In dieser Lektion werden verschiedene
Optionen zur Steuerung der Menge der gesendeten Daten vorgestellt.
Unternehmensszenario
In Ihrem Unternehmen werden Stammdaten in der Zentrale angelegt und geändert. Allerdings
erhalten die Vertriebsniederlassung und die Produktion nicht immer die gleichen Daten.
Außerdem sollen die verschiedenen Abteilungen in Vertrieb und Produktion in der Lage sein,
bestimmte Teile der Stammdaten in eigenen Systemen zu ergänzen.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●
Die verschiedenen Methoden zur Datenfilterung in der IDoc-Verarbeitung beschreiben
●Einen reduzierten Nachrichtentyp anlegen und diesen im Verteilungsprozess verwenden
Segmentfilterung
Wenn Sie nicht möchten, dass ein Empfänger den vollständigen Datensatz in einem IDoc
erhält, können Sie die Segmentfilterung verwenden. Die Segmentfilterung ist ein
anwendungsunabhängiger ALE-Service, der sicherstellt, dass einzelne Segmente aus dem
Datenteil gelöscht werden, bevor das Kommunikations-IDoc in der Datenbank gesichert wird.
Abbildung 45: Segmentfilterung
Mithilfe der Segmentfilterung können Sie Folgendes ausführen:
●Reduzieren der Datenmenge auf die Informationen, die vom Zielsystem benötigt werden
●Sicherstellen, dass die im Zielsystem gepflegten Detaildaten nicht überschrieben werden
Wenn Sie in einem ALE-Szenario die Segmentfilterung verwenden möchten, sollten Sie die
Struktur des Basistyps prüfen, anhand dessen Sie die Schlüssel für die Segmente bestimmen,
©Copyright. Alle Rechte vorbehalten. 53Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

60. die gelöscht werden sollen. Wenn Sie beispielsweise möchten dass die Daten des
Vertriebsbereichs für die Kundenstämme (BasistypDEBMAS0x) im System der
Vertriebsniederlassung angelegt werden sollen, können Sie mithilfe der Segmentfilterung
Segmentgruppe E1KNVVM (Verkaufsdaten Hauptkundenstamm) aus allen Kommunikations-
IDocs für den Nachrichtentyp DEBMAS und den Empfänger „SALES“ löschen. Die Kundenstämme werden dann ohne die Vertriebsbereichsdaten an den Vertrieb verteilt.
Notiz:
Wenn Sie für die Segmentfilterung eine Segmentgruppe auswählen, d.h. ein
Segment mit den zugehörigen Untersegmenten, werden sämtliche
Untersegmente aus dem Kommunikations-IDoc gelöscht.
Abbildung 46: Einführungsleitfaden: Segmentfilterung
Sie können die Segmentfilterung im Einführungsleitfaden mit der Transaktion SALEüber
IDoc-Schnittstelle / Application Link Enabling (ALE)→Geschäftsprozesse modellieren und
implementieren→Verteilung von Stammdaten konfigurieren →Umfang der zu verteilenden
Daten festlegen→IDoc-Segmente filtern einrichten. Geben Sie in dieser Tabelle den
Nachrichtentyp, das Zielsystem und die zu löschenden Segmente an. Das nächste
Kommunikations-IDoc für den angegebenen Nachrichtentyp und Empfänger wird ohne diese
Segmente erzeugt. Die Abbildung „Ausgangsverarbeitung mit Segmentfilterung“ stellt
schematisch den Prozessablauf der IDoc-Ausgangsverarbeitung mit Segmentfilterung dar.
Kapitel 2: Stammdatenverteilung
©Copyright. Alle Rechte vorbehalten. 54Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

61. Abbildung 47: Ausgangsverarbeitung mit Segmentfilterung
Filterobjekte
In den folgenden Abschnitten werden Filteroptionen eingeführt, die im Unterschied zur oben
beschriebenen Segmentfilterung anwendungsabhängig sind. Sie müssen daher in jedem
einzelnen Fall prüfen, ob die Option für Ihr ALE-Szenario verfügbar ist.
Viele Anwendungen sind für die Verwendung mit Filterobjekten konzipiert. Zu diesen Objekten
zählen Anwendungsdaten (häufig Organisationseinheiten und -gruppierungen), deren
einzelne Merkmale bestimmen können, ob ein Kommunikations-IDoc für einen Empfänger
angelegt wird oder welche Teile des verteilten Datensatzes im Kommunikations-IDoc
enthalten sein sollen.
Lektion: Datenfilterung und Verringern der Datenmenge
©Copyright. Alle Rechte vorbehalten. 55Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

62. Abbildung 48: Filterung anhand von Filterobjekten
Wenn Sie in ALE-Szenarien mit Filterobjekten arbeiten, müssen Sie Bedingungen definieren,
die von bestimmten Anwendungsdaten erfüllt werden müssen, damit diese in ein
Kommunikations-IDoc aufgenommen werden. Wenn das Filterobjekt ein obligatorisches
Segment des entsprechenden Basistyps darstellt, wird ein Kommunikations-IDoc erst
angelegt, wenn die Bedingung erfüllt wird.
In der Abbildung „Beispiel: Verteilung in Abhängigkeit von der Materialart“ wird dargestellt,
wie Materialstämme (NachrichtentypMATMAS) in regelmäßigen Abständen von der Zentrale
auf Vertrieb und Produktion aufgeteilt werden. Allerdings soll der Vertrieb nur
Materialstämme für Fertigerzeugnisse erhalten, während die Produktion die Stammdaten für
Fertigteile und Rohstoffe benötigt.
Abbildung 49: Beispiel: Verteilung in Abhängigkeit von Materialart
Die Materialart gehört zu den Filterobjekten, die für Materialstämme vorgesehen sind. Die
Materialart fasst Materialien entsprechend ihren physikalischen Eigenschaften zusammen,
beispielsweise Fertigerzeugnisse, Handelsware und Rohstoffe. Im BasistypMATMAS0xist
Kapitel 2: Stammdatenverteilung
©Copyright. Alle Rechte vorbehalten. 56Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

63. das Segmentfeld für die Materialart(MTART)Teil eines Segments, das als obligatorisch
gekennzeichnet ist. Wenn Sie jetzt in der Modellsicht die Materialart als Filterobjekt für IDocs
den NachrichtentypMATMASzur Verteilung der Materialstämme an den Vertrieb verwenden
und den Materialartschlüssel(FERT)für Fertigerzeugnisse zuweisen, stellen Sie sicher, dass
an den Vertrieb nur Materialstämme mit dieser Materialart verteilt werden. Das
Sendersystem erzeugt keine Kommunikations-IDocs für Materialstämme mit anderen
Materialarten, wenn der Empfänger „SALES“ lautet. Wenn ein Filterobjekt sich auf ein
optionales Segment des entsprechenden Basistyps bezieht, werden das Segment und die
zugehörigen Untersegmente aus dem IDoc gelöscht, wenn ein Feldwert eine Bedingung nicht
erfüllt, die im Verteilungsmodell enthalten ist.
Notiz:
Kunden können die von SAP bereitgestellte Liste der Filterobjekte mit eigenen
Filterobjekten erweitern. Die hierfür erforderlichen Tabellen finden Sie im
Anwendungsmenü über den PfadWerkzeuge→ALE→ ALE-
Entwicklung→IDoc→Datenfilterung .
Die Abbildung „Verteilungsmodell: Anlegen von Filtergruppen“ ist eine schematische
Darstellung der obligatorischen Customizing-Einstellungen:
Abbildung 50: Verteilungsmodell: Anlegen von Filtergruppen
Bedingungen innerhalb einer Filtergruppe sind durch eine„UND-Logik”miteinander
verknüpft. Sie können für jeden Nachrichtentyp im Verteilungsmodell mehrere Filtergruppen
anlegen. Diese Filtergruppen sind durch eine„ODER-Logik”miteinander verknüpft.
Lektion: Datenfilterung und Verringern der Datenmenge
©Copyright. Alle Rechte vorbehalten. 57Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

64. Abbildung 51: IDoc-Ausgangsverarbeitung mit Filterobjekten
Die Filterobjekte werden in der ALE-Schicht bewertet. Wenn in einem Verteilungsmodell
Filterwerte für einen Nachrichtentyp angegeben sind, werden diese vom System zum Ableiten
einer Bedingung verwendet. Wenn die Bedingung erfüllt ist, wird das Kommunikations-IDoc
unverändert übergeben. Wenn die Bedingung nicht erfüllt ist, werden die entsprechenden
Zeilen aus dem Datenteil gelöscht.
Klassifizierung
Logistikanwendungen in SAP-ERP-Systemen können unabhängig von ALE-Szenarien die
Klassifizierung verwenden, die eine anwendungsübergreifende Funktion darstellt. Die
Klassifizierung ermöglicht es Ihnen, Anwendungsdaten anhand von einigermaßen frei
definierbaren Kriterien zu gruppieren (üblicherweise Stammdaten oder Dokumente). Mithilfe
dieser Gruppierungen können Sie z.B. bestimmte Datensätze gezielt auswählen. Im Kontext
von ALE erfüllt die Klassifizierung jedoch einen anderen Zweck: Die Zugehörigkeit eines
Datensatzes zu einer bestimmten Klasse bestimmt, wie dieser verteilt wird.
Kapitel 2: Stammdatenverteilung
©Copyright. Alle Rechte vorbehalten. 58Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

65. Abbildung 52: Filterung mit Klassifizierung
Wenn Sie in einem ALE-Szenario die Klassifizierung als Filtermethode verwenden möchten,
müssen Sie im Klassensystem bestimmte Grundeinstellungen vornehmen. Sie müssen eine
Klassenart als Verteilungsklassenart kennzeichnen und mindestens eine Klasse für die
Gruppierung der Daten in dieser Klassenart anlegen. Anschließend können Sie die ALE-
spezifischen Einstellungen hinzufügen. Sie können die Verwendung der Klassifizierung in
einem ALE-Szenario im Filterobjektbereich einer Modellansicht aktivieren (siehe oben).
Abbildung 53: Verteilung über Klassen
Rufen Sie zum Konfigurieren der Klassifizierung für ALE-Szenarien die Transaktion SALE(im
Einführungsleitfaden) auf, und wählen SieIDoc-Schnittstelle / Application Link Enabling
(ALE)→Geschäftsprozesse modellieren und implementieren→Verteilung von Stammdaten
Lektion: Datenfilterung und Verringern der Datenmenge
©Copyright. Alle Rechte vorbehalten. 59Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

66. konfigurieren →Verteilung über Klassen von Objekten einrichten. Sie ordnen in der
entsprechenden Anwendung selbst Anwendungsdaten Klassen zu. Sie klassifizieren
Materialstämme beispielsweise durch Anlegen einer entsprechenden Sicht, d.h. eines
Datenbilds. Wenn ein Materialstammsatz nicht Teil der Verteilungsklasse ist, die für das
Zielsystem angegeben wurde, wird er an dieses System nicht verteilt.
Reduzierte Nachrichtentypen
Einige Anwendungen weisen derart flexible Programme für die Eingangs- und
Ausgangsverarbeitung auf, sodass Sie auswählen können, ob optionale Segmentfelder
übertragen werden sollen. Dazu legen Sie im Kundennamensraum einen sogenannte
reduzierte Nachrichtentypals Kopie eines Nachrichtentyps an, der von SAP bereitgestellt
wird, und wählen die Felder aus, deren Inhalt an ein bestimmtes Zielsystem übertragen werden soll.
Abbildung 54: Filterung mit reduzierten Nachrichtentypen
Sie können diese reduzierten Nachrichtentypen in allen ALE-Szenarien verwenden, in denen
die verteilten Daten nicht ausschließlich im Sendersystem verarbeitet werden. Bei dieser Art
von Szenario kann z.B. die Vertriebsniederlassung die Materialstämme unabhängig ändern,
nachdem diese zunächst von der Zentrale übertragen wurden. Wenn diese Stammdatensätze
erneut gesendet werden, werden alle im System „SALES“ geänderten Felder überschrieben,
und die Arbeit des Vertriebsbeauftragten war umsonst. Wenn in diesem Szenario jedoch ein
reduzierter Nachrichtentyp ohne diese Felder verwendet wird, sind die lokal verwalteten
Daten vor einem Überschreiben geschützt, da die Felder (die im Segment enthalten, aber
nicht ausgewählt sind) mit einem Nodata-Zeichen (/) ausgefüllt sind.
Der eingehende Funktionsbaustein stellt sicher, dass nur die in dem reduzierten
Nachrichtentyp aktivierten Felder in die Datenbank des Zielsystems geschrieben werden.
Segmentfelder, die für die sinnvolle Verarbeitung im Zielsystem unbedingt erforderlich sind,
werden in der Anwendung alsobligatorischgekennzeichnet.
Kapitel 2: Stammdatenverteilung
©Copyright. Alle Rechte vorbehalten. 60Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

67. Abbildung 55: Voraussetzungen für die Verwendung von reduzierten Nachrichtentypen
Bevor Sie reduzierte Nachrichtentypen verwenden können, muss die Anwendung über die
folgenden Funktionen verfügen:
●Ausgangsbaustein: Eine ALE-Funktion prüft, ob ein reduzierter Nachrichtentyp verwendet
werden soll. Wenn das Master-IDoc erzeugt wird, wird in allen Feldern, die nicht übertragen
werden sollen, ein Nodata-Zeichen (/) eingegeben.
●Eingangsbaustein: Jedes Segment wird geprüft, um festzustellen, welche Felder ein
Nodata-Zeichen aufweisen. Diese Felder werden nicht in die Datenbank geschrieben.
Dadurch können Sie bestimmte Detaildaten in den lokalen Systemen pflegen und
sicherstellen, dass beim Replizieren von Stammdaten keine Daten versehentlich mit einem ursprünglichen Wert überschrieben werden.
●
Nachrichtentypen: Der Nachrichtentyp wird alsreduzierbargekennzeichnet.
Rufen Sie zum Anlegen einer reduzierten Nachrichtentypsd die TransaktionSALEauf, und
wählen SieIDoc-Schnittstelle / Application Link Enabling (ALE)→Geschäftsprozesse
modellieren und implementieren→Verteilung von Stammdaten konfigurieren →Umfang der
zu verteilenden Daten festlegen→Nachrichten reduzieren→Reduzierten Nachrichtentyp
erstellen.
Lektion: Datenfilterung und Verringern der Datenmenge
©Copyright. Alle Rechte vorbehalten. 61Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

68. Abbildung 56: Erstellen eines reduzierten Nachrichtentyps
Wenn Sie einen neuen reduzierte Nachrichtentyp anlegen, basiert diese auf dem aktuellsten
IDoc-Typ. Zunächst werden die obligatorischen Segmente ausgewählt, danach nur die Felder
in diesen Segmenten, die in einem SAP-Standardsystem als Mussfelder gekennzeichnet sind.
Diese Segmente und Felder werden grün hinterlegt.
Wählen Sie ein Segment aus, indem Sie es markieren, und wählen SieAuswählen.
Notiz:
Wenn Sie ein Segment auswählen, werden nur Felder ausgewählt, die in einem
SAP-Standardsystem als Mussfelder definiert sind. Um zusätzliche Felder für ein
ausgewähltes Segment auszuwählen, navigieren Sie zur SichtDetail. Wählen Sie in
der SichtDetaildie zusätzlichen Felder aus, und wählen Sie erneutAuswählen.
Optionale Segmente oder Felder, die noch nicht ausgewählt wurden, werden rot
hinterlegt. Optionale Segmente oder Felder, die bereits ausgewählt wurden,
werden weiß hinterlegt.
Achtung:
Sie müssenAuswählenwählen, bevor Sie die SichtDetailüber dieEingabetaste
beenden können. Wenn Sie Felder auswählen und dann sofort dieEingabetaste
drücken, wird die Auswahl nicht gesichert.
Wenn Sie bei einem reduzierten Nachrichtentyp die Änderungszeigerfunktion verwenden
möchten (siehe Lektion „Verwenden von Änderungszeigern“), müssen Sie das entsprechende
Kennzeichen für diesen reduzierten Nachrichtentyp festlegen. Rufen Sie dazu die Transaktion
SALEauf, und wählen SieIDoc-Schnittstelle / Application Link Enabling
Kapitel 2: Stammdatenverteilung
©Copyright. Alle Rechte vorbehalten. 62Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

69. (ALE)→Geschäftsprozesse modellieren und implementieren→Verteilung von Stammdaten
konfigurieren →Nachrichten reduzieren→Reduzierten Nachrichtentyp erstellen.
Reduzierte Nachrichtentypen werden für Folgendes verwendet:
●Zum Erstellen eines reduzierten Nachrichtentyps
●Zum Auswählen von Mussfeldern
●Zum Sichern und Zuordnen eines Änderungsauftrags
●Zum Aktivieren von Änderungszeigern (falls erforderlich)
Reduzierte Nachrichtentypen müssen in allen beteiligten Sender- und Empfängersystemen
erkannt werden.
Abbildung 57: Transportieren von reduzierten Nachrichtentypen
Da die Nachrichtentypen mandantenunabhängige Customizing-Objekte sind, werden sie
mithilfe eines Workbench-Auftrags transportiert. Sie können einen Transportauftrag für jeden
reduzierten Nachrichtentyp erzeugen. Wählen Sie dazuApplication Link Enabling
(ALE)→Geschäftsprozesse modellieren und implementieren→Verteilung von Stammdaten
konfigurieren →Umfang der zu verteilenden Daten festlegen→Nachrichten
reduzieren→Transportauftrag für Nachrichtentyp generieren.
Lektion: Datenfilterung und Verringern der Datenmenge
©Copyright. Alle Rechte vorbehalten. 63Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

70. Abbildung 58: Ausgangsverarbeitung mit reduzierten Nachrichtentypen
Für die Erzeugung von IDocs für einen reduzierten Nachrichtentyp sowie für die Erzeugung
von IDocs für den Vorlagennachrichtentyp ist dasselbe Programm zuständig. Beim Anlegen
eines Master-IDocs bestimmt das Anwendungsprogramm zunächst Detailinformationen zum
verwendeten reduzierten Nachrichtentyp. Zur Eingabe von/in den inaktiven Feldern des
Master-IDocs wird ein ALE-Funktionsbaustein verwendet. Das Master-IDoc wird dann an die
ALE-Schicht übergeben.
Kapitel 2: Stammdatenverteilung
©Copyright. Alle Rechte vorbehalten. 64Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

71. Abbildung 59: Eingangsverarbeitung mit reduzierten Nachrichtentypen
Für die Eingangsverarbeitung sowie für ein IDoc für den Vorlagennachrichtentyp wird
derselbe Eingangsfunktionsbaustein verwendet. Das System prüft alle optionalen Segmente,
um zu ermitteln, ob diese das Zeichen/enthalten. Nur die Felder, die kein/enthalten,
werden in die Datenbank geschrieben.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●
Die verschiedenen Methoden zur Datenfilterung in der IDoc-Verarbeitung beschreiben
●Einen reduzierten Nachrichtentyp anlegen und diesen im Verteilungsprozess verwenden
Lektion: Datenfilterung und Verringern der Datenmenge
©Copyright. Alle Rechte vorbehalten. 65Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

72. KAPITEL 3Bewegungsdaten
verteilen:
Nachrichtensteuerung
Lektion 1
Nachrichtensteuerung und IDoc-Erzeugung 67
Lektion 2
Beispiel: Bestellungsbearbeitung 76
LERNZIELE
●Unterscheiden zwischen ALE und EDI
●Die Grundfunktionen der Nachrichtensteuerung beschreiben
●Erläutern, wie die Nachrichtensteuerung zur Erzeugung von IDocs verwendet wird
●Eine Bestellung anlegen und die Ergebnisse Ihrer Nachrichtenfindung prüfen
●Den systemübergreifenden Bestellprozess beschreiben
●Die wichtigsten Customizing-Einstellungen für diesen Prozess erläutern
©Copyright. Alle Rechte vorbehalten. 66Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

73. Kapitel 3
Lektion 1
Nachrichtensteuerung und IDoc-Erzeugung
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion erhalten Sie Informationen zur Nachrichtensteuerung als Instrument zum
Verteilen von Bewegungsdaten im IDoc-Format.
Unternehmensszenario
Bisher hat Ihr Unternehmen Bestellungen an Lieferanten in Papierform per Post gesendet. Sie
möchten zukünftig diesen Prozess in elektronische Kommunikation umwandeln. Darüber
hinaus möchten Sie, dass die Bestellungen der Vertriebsniederlassung automatisch in
Aufträge umgewandelt werden, wenn sie von der Zentrale empfangen werden.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Unterscheiden zwischen ALE und EDI
●Die Grundfunktionen der Nachrichtensteuerung beschreiben
●Erläutern, wie die Nachrichtensteuerung zur Erzeugung von IDocs verwendet wird
ALE und EDI: Ein Vergleich
Für ALE- und EDI-Szenarien verwenden Sie stets dasselbe Instrument: Die Daten (wie
Bestellungen, Bestellbestätigungen oder Rechnungen) werden im IDoc-Format an den
entsprechenden Empfänger gesendet oder von Ihrem System als IDocs empfangen und
anschließend an die Zielanwendungen übertragen.
Abbildung 60: EDI: Bestellung bei einem Lieferanten
©Copyright. Alle Rechte vorbehalten. 67Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

74. Bisher wurden die Bestellungen bei einem Lieferanten in unserem Beispielunternehmen in
Papierform verarbeitet: Die Mitarbeiter des Einkaufs legen möglicherweise auf der Grundlage
von Bestellanforderungen anderer Abteilungen im System in der Zentrale Bestellungen an
und senden diese per Post an den Lieferanten. In Zukunft soll der Lieferant jedoch die
Bestelldaten elektronisch in einem EDI-Standardformat erhalten.
In vielen Fällen sind die externen Lieferanten nicht Teil des Unternehmensnetzwerks. Daher
erfolgt die elektronische Kommunikation mit ihnen häufig über zwischengeschaltete
Subsysteme, auch bekannt als EDI-Konverter. SAP stellt eine offene Schnittstelle zu solchen
Systemen bereit (CA-EDI). Die EDI-Subsysteme übernehmen die Verantwortung für alle EDI-
spezifischen Aufgaben wie Datenkonvertierung, Verwaltung von Partnervereinbarungen und
Prozessüberwachung.
Abbildung 61: Kommunikation über ein EDI-Subsystem
Die SAP-Anwendung sendet ein IDoc an das Subsystem. Im Falle einer Bestellung lautet der
NachrichtentypORDERS. Das Subsystem liest das IDoc und wandelt es in einen EDI-Beleg
um. Dieser Beleg wird an den Lieferanten gesendet, dessen EDI-Konverter die eingehenden
Daten in ein Format umwandelt, das im ERP-System des Lieferanten verarbeitet werden
kann. Häufig wird aus den Daten der eingegangenen Bestellung automatisch ein Auftrag
erzeugt.
Kapitel 3: Bewegungsdaten verteilen: Nachrichtensteuerung
©Copyright. Alle Rechte vorbehalten. 68Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

75. Abbildung 62: Porttypen
Viele Subsysteme können mit SAP-Systemen über tRFC kommunizieren. Wenn allerdings Ihr
Subsystem RFC-Protokoll nicht entschlüsseln kann, verwenden Sie in der Regel einen Datei-
Port. Das Verzeichnis des Betriebssystems, in dem eingehende und ausgehende Daten
gesichert werden sollen, wird für diesen Port in den Detaileinstellungen eingegeben.
Partnervereinbarungen für EDI-Szenarien müssen sich immer auf Partner vom Typ LI
(Lieferant) oder KU (Kunde) beziehen. Partner in ALE-Szenarien sind hingegen immer
logische Systeme (Partnerart LS).
Abbildung 63: Partnervereinbarung: Partnerart LI
Lektion: Nachrichtensteuerung und IDoc-Erzeugung
©Copyright. Alle Rechte vorbehalten. 69Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

76. Daher sind für das in der ersten Abbildung der Lektion dargestellte EDI-Szenario
Partnervereinbarungen der Partnerart LI erforderlich. Beim Anlegen solcher
Partnervereinbarungen beziehen Sie sich stets auf die Lieferantenstammdaten. Wenn daher
der Lieferant mit dem Schlüssel T-BIL00 angelegt wurde, lautet auch der EDI-Partner T-
BIL00.
Abbildung 64: Partnerrollen
Der Lieferant kann als Geschäftspartner gegenüber dem Unternehmen verschiedene Rollen
einnehmen. Während eines Beschaffungsvorgangs ist ein Lieferant zunächst der Empfänger
der Bestellung, dann der Warenlieferant, später der Rechnungssteller und schließlich der
Zahlungsempfänger. Nicht immer übernimmt ein Partner alle Rollen selbst. So kann z.B. ein
anderer Beteiligter als der Bestellempfänger die Ware liefern. Aus diesem Grund arbeiten
logistische Anwendungen in SAP-R/3- und SAP-ECC-Systemen mit
Partnerrollen, die in den
Partnerstammdaten zugeordnet sind und ggf. in den Anwendungsbelegen geändert werden können.
Kapitel 3: Bewegungsdaten verteilen: Nachrichtensteuerung
©Copyright. Alle Rechte vorbehalten. 70Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

77. Abbildung 65: Partnervereinbarung für EDI
Daher müssen Sie beim Anlegen von Partnervereinbarungen für EDI-Partner (im Gegensatz
zu ALE) die entsprechende Rolle eingeben, in der ein Partner eine Nachricht sendet oder
empfängt.
Für EDI-Szenarien spielt das Verteilungsmodell, das Sie als wichtiges ALE-Element
kennengelernt haben, keine Rolle. Die Anwendungsprogramme ermitteln den Empfänger der
Nachricht aus dem jeweiligen Anwendungsbeleg. Anschließend wird das Kommunikations-
IDoc auf der Grundlage der Parameter in den Partnervereinbarungen erzeugt und
weiterverarbeitet (beispielsweise auf Betriebssystemebene als sequenzielle Datei abgelegt).
Nachrichtensteuerung: Einführung
Die Anwendung „mySAP ERP Procurement“ ermöglicht es Ihnen bereits, eine Bestellung in
gedruckter Form oder im IDoc-Format zu senden. Die Anwendung verwendet dazu die
Nachrichtensteuerung, ein anwendungsübergreifendes Funktionspaket. In SAP-Systemen
stellt eine Nachricht Informationen dar, die in verschiedenen Formaten ausgegeben werden. Die auf Papier gedruckte oder als IDoc gesendete Bestellung ist nur eines von vielen Beispielen für die Verwendung von Nachrichtensteuerung in logistischen Anwendungen. Sie können die in Ihren SAP-R/3- oder SAP-ECC-Belegen enthaltenen Informationen auch als Fax oder E-Mail an Mitarbeiter oder Partner senden. Das Format, in dem die Nachricht ausgegeben wird, wird durch das
Sendemediumfestgelegt, das Sie zuvor definieren oder das
Sie je nach Standardeinstellungen in einzelnen Fällen vor der Ausgabe angeben können.
Lektion: Nachrichtensteuerung und IDoc-Erzeugung
©Copyright. Alle Rechte vorbehalten. 71Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

78. Abbildung 66: Sendemedium
Bei jedem Sichern eines neuen oder geänderten Einkaufsbelegs (z.B. einer Anfrage, einer
Bestellung oder eines Rahmenvertrags) prüft das System, ob eine Nachricht für diesen Beleg
erzeugt werden muss und in welchem Format, d.h. durch welches Sendemedium, diese
Nachricht ausgegeben werden soll.
Die einzelne Nachricht (beispielsweise das IDoc mit den Bestelldaten) wird stets auf der
Grundlage einer Nachrichtenart erzeugt, die im Customizing der jeweiligen Anwendung
definiert ist. Nachrichtenarten sind Schlüssel, mit denen die wichtigsten
Steuerungsparameter für die Ermittlung und spätere Ausgabe von Nachrichten verknüpft sind. Die Nachrichtenart für die Ausgabe von Einkaufsbelegdaten heißt beispielsweise NEU (Bestellneudruck).
Kapitel 3: Bewegungsdaten verteilen: Nachrichtensteuerung
©Copyright. Alle Rechte vorbehalten. 72Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

79. Abbildung 67: Nachrichtenarten
Nachrichtenarten sind anwendungsspezifisch. Jede Anwendung, die die
Nachrichtensteuerung verwendet, wird mit einem aus zwei Zeichen bestehenden Schlüssel
gekennzeichnet. Beispielsweise weist der Einkauf, der für die Bestellungsbearbeitung
verantwortlich ist, den Schlüssel EF auf. Einen Überblick über alle Anwendungen, die die
Nachrichtensteuerung nutzen, erhalten Sie über die TransaktionNACE. Mit dieser Transaktion
(DrucktasteNachrichtenarten) können Sie auch die Liste aller Nachrichtenarten aufrufen, die
für eine Anwendung definiert sind.
Nachrichtenfindung
Die Nachrichtensteuerung funktioniert mit der Konditionstechnik. Hierbei handelt es sich um
eine Methode, die es dem System ermöglicht, auf der Grundlage von zuvor definierten
Bedingungen nach Anwendungsobjekten zu suchen. Die Konditionstechnik wird in vielen
Anwendungen in SAP R/3 und SAP ECC verwendet. Beispiele sind die Preisfindung in Einkauf
und Vertrieb sowie die Chargenfindung in der gesamten Logistik. Darüber hinaus findet das
System Nachrichten auf der Grundlage von Konditionssätzen, d.h. Kombinationen von Bedingungen, unter denen eine bestimmte Nachricht in einem bestimmten Format ausgegeben werden soll.
Die Konditionstechnik funktioniert mit sog. Konditionselementen, die voneinander abhängig
sind. Die Abbildung „Nachrichtensteuerung: Konditionselemente“ zeigt die innere Hierarchie
der Konditionselemente am Beispiel der Nachrichtensteuerung für den Einkauf:
Lektion: Nachrichtensteuerung und IDoc-Erzeugung
©Copyright. Alle Rechte vorbehalten. 73Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

80. Abbildung 68: Nachrichtensteuerung: Konditionselemente
Das jeweilige Anwendungsprogramm (z.B. Bestellung anlegen) gibt die Anwendung an (z.B.
EF). Das entsprechende Nachrichtenschema (z.B. RMBEF1), das Nachrichtenarten auf der
Grundlage verschiedener Perspektiven gruppiert, wird je nach Anwendung über Customizing-
Tabellen gesucht. Daher kann z.B. die Belegart entscheiden, welches Verfahren verwendet
werden soll.
Zusammen mit dem Sendemedium (siehe oben) müssen Sie im Konditionssatz immer auch
einen Verarbeitungszeitpunkt eingeben. Sie haben die Auswahl zwischen den folgenden drei
Verarbeitungszeitpunkten:
●Sofortige Übertragung beim Anlegen des Belegs (4)
●Anschließende Übertragung durch einen Job (1 und 2)
●Anschließende Übertragung, die durch den Benutzer über eine spezielle Transaktion
ausgelöst wird (3)
Wenn Sie im Konditionssatz das Sendemedium EDI auswählen, müssen Sie für den
eingegebenen Partner und seine Rolle entsprechende Partnervereinbarungen anlegen. Wenn
Sie das Sendemedium ALE verwenden möchten, muss neben den Partnervereinbarungen im
Verteilungsmodell auch eine entsprechende Modellsicht vorhanden sein.
Kapitel 3: Bewegungsdaten verteilen: Nachrichtensteuerung
©Copyright. Alle Rechte vorbehalten. 74Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

81. Abbildung 69: Nachrichtenfindung in der Bestellung
Beim Anlegen einer Bestellung prüft das Anwendungsprogramm im Rahmen der
Nachrichtenfindung, ob eine Nachricht erzeugt werden soll. Wenn als Sendemedium EDI oder
ALE verwendet wird, prüft das System, ob geeignete Partnervereinbarungen vorhanden sind
und welcher IDoc-Typ für die Datenausgabe angegeben ist. Verläuft die Nachrichtenfindung
erfolgreich, wird eine Nachricht erzeugt. Alle Nachrichten werden in der Datenbanktabelle
NAST abgelegt. Auf der Grundlage des in den Partnervereinbarungen festgelegten IDoc-
Basistyps erzeugt das Programm RSNAST00 aus den Daten der Bestellung ein
Kommunikations-IDoc. (Wenn hingegen die Druckausgabe angegeben wurde, wird das
entsprechende Formular ausgefüllt.)
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Unterscheiden zwischen ALE und EDI
●Die Grundfunktionen der Nachrichtensteuerung beschreiben
●Erläutern, wie die Nachrichtensteuerung zur Erzeugung von IDocs verwendet wird
Lektion: Nachrichtensteuerung und IDoc-Erzeugung
©Copyright. Alle Rechte vorbehalten. 75Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

82. Kapitel 3
Lektion 2
Beispiel: Bestellungsbearbeitung
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion erhalten Sie am Beispiel einer Bestellung Informationen zur IDoc-Erzeugung
mithilfe der Nachrichtensteuerung. Darüber hinaus erhalten Sie eine Einführung in eines der
bereitgestellten ALE-Szenarien (Umlagerung zwischen verteilten Systemen).
Unternehmensszenario
Die Vertriebsniederlassung bestellt bei der Zentrale regelmäßig Nachschub für den Bestand
zur Bearbeitung von Kundenaufträgen, wobei die Zentrale sich an demselben Ort wie das
Hauptlager des Unternehmens befindet. Diese Bestellungen sollen zukünftig mit ALE an die
Zentrale gesendet und dort automatisch in Aufträge umgewandelt werden. Die Vertriebsniederlassung erhält umgehend eine elektronische Auftragsbestätigung. Die Bestellungen bei Lieferanten werden von der Zentrale ebenfalls elektronisch erstellt, allerdings über eine EDI-Verbindung.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●
Eine Bestellung anlegen und die Ergebnisse Ihrer Nachrichtenfindung prüfen
●Den systemübergreifenden Bestellprozess beschreiben
●Die wichtigsten Customizing-Einstellungen für diesen Prozess erläutern
Nachrichtensteuerung: Sendemedien ALE und EDI
Logistische Anwendungen in SAP-R/3- und SAP-ECC-Systemen können über die
NachrichtensteuerungIDocs zum Senden von Bewegungsdaten erzeugen. Das System
überträgt die Daten eines Anwendungsbelegs abhängig vom jeweiligen IDoc-Basistyp in die
Felder des IDocs. Das IDoc kann entweder an einen Geschäftspartner oder ein anderes
logisches System innerhalb des Unternehmens gesendet werden.
©Copyright. Alle Rechte vorbehalten. 76Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

83. Abbildung 70: Beispiel: Senden einer Nachricht im EDI-Format
Hier wird Ihnen die Übertragung eines IDocs an einen externen Lieferanten mithilfe eines EDI-
Konverters dargestellt. Somit wurde das Sendemedium EDI (6) im Nachrichtenfindungssatz
eingegeben. Darüber hinaus müssen auch Partnervereinbarungen für die Partnerart des
Lieferanten (LI) vorhanden sein, denen ein Empfängerport zugeordnet ist, der eine
Verbindung mit dem EDI-Konverter darstellt oder der ein Verzeichnis enthält, in dem IDocs als
sequenzielle Dateien abgelegt werden.
Abbildung 71: Partnervereinbarungen mit einem externen Lieferanten
Lektion: Beispiel: Bestellungsbearbeitung
©Copyright. Alle Rechte vorbehalten. 77Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

84. Wenn hingegen das Sendemedium der Findungssätze ALE (A) lautet, müssen entsprechende
Partnervereinbarungen mit einem logischen System (Partnerart LS) angelegt werden. Das
FeldPartnerrollebleibt leer. Die Einstellungen für die Erzeugung eines IDocs (IDoc-Basistyp
und Vorgangscode) sind identisch. Der Port ist in der Regel ein tRFC-Port.
Abbildung 72: Partnervereinbarung mit einem logischen System
Wenn Sie die Nachrichtensteuerung zur Verteilung von Bewegungsdaten verwenden
möchten, muss einVorgangscodefür die Ausgangsverarbeitung vorhanden sein. Anhand
dieses Vorgangscodes wird der Funktionsbaustein bestimmt, der anschließend anhand des
Eintrags, der durch die Nachrichtenfindung in der Tabelle NAST (NAST-Satz) angelegt wurde,
die entsprechenden Anwendungsdaten bestimmt und das Master-IDoc anlegt.
Notiz:
Anhand des AttributsMit ALE-Servicesim Vorgangscode wird gesteuert, ob Sie
das IDoc mithilfe der Segmentfilterung und Feldumsetzung der ALE-Services
anpassen können. Wenn dieses Attribut nicht festgelegt ist, wird das Master-IDoc
ohne Änderungen an die Datengruppe des Kommunikations-IDocs übertragen und
in der Datenbank gespeichert.
Bei ALE-Szenarien, bei denen Bewegungsdaten mithilfe einer Nachrichtensteuerung
gesendet werden müssen, müssen Sie entsprechende Sichten im Verteilungsmodell des
Pflegesystems anlegen oder expandieren und sie anschließend an die entsprechenden
empfangenden Systeme verteilen.
Kapitel 3: Bewegungsdaten verteilen: Nachrichtensteuerung
©Copyright. Alle Rechte vorbehalten. 78Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

85. Abbildung 73: Modellsicht für die Verteilung von Bestellungen
Im dargestellten Beispiel sendet der Vertrieb (d.h. das logische System „SALES“)
Bestellungen (Nachrichtentyp ORDERS) an die Zentrale (logisches System „CORE“). Nach
Erhalt und Prüfung der Bestellungen sendet die Zentrale Bestellbestätigungen
(Nachrichtentyp ORDRSP) an den Vertrieb.
Nachrichtenfindung in der Bestellung und IDoc-Erzeugung
Wenn Sie eine Bestellung anlegen, führt das System die Nachrichtenfindung auf der
Grundlage der anwendungsspezifischen Customizing-Einstellungen zur
Nachrichtensteuerung durch. Wenn diese Findung erfolgreich ist, können Sie das Ergebnis sofort über den Anwendungsbeleg aufrufen (MenüeintragSpringen→Nachrichtenoder
DrucktasteNachrichtenauf dem Einstiegsbild).
Abbildung 74: IDoc-Erzeugung über die Nachrichtensteuerung
Lektion: Beispiel: Bestellungsbearbeitung
©Copyright. Alle Rechte vorbehalten. 79Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

86. Wenn im Findungssatz das Sendemedium ALE oder EDI zugeordnet ist, wird vom NAST-Satz
auf der Grundlage der Ausgangsparameter der zugehörigen Partnervereinbarungen ein
Master-IDoc angelegt. Der Vorgangscode steuert, welche Anwendungsfunktionsbausteine
verwendet werden, um dieses IDoc zu erzeugen. Der Anwendungsbelegschlüssel wird aus
dem NAST-Satz an diesen Anwendungsfunktionsbaustein übertragen. Der Baustein liest die
Belegdaten und überträgt sie in die Segmentfelder des Master-IDocs. Wenn im Findungssatz
der Verarbeitungszeitpunkt 4 eingegeben wurde, führt das System das Programm
RSNAST00 sofort nach dem Speichern aus, um ein IDoc aus dem NAST-Satz zu erzeugen.
Wenn der Verarbeitungszeitpunkt 1 angegeben ist, wird vorerst nur ein NAST-Satz angelegt.
Das Programm RSNAST00 muss als Hintergrundjob eingeplant oder manuell gestartet
werden. Im Programm RSNAST00 wird das Master-IDoc als Datengruppe der
Kommunikations-IDocs übertragen. Außerdem werden ihm ein Kontrollsatz und ein
Statussatz hinzugefügt. Das Kommunikations-IDoc wird anschließend in der Datenbank
gesichert und je nach Einstellungen in den Partnervereinbarungen sofort oder zu einem
späteren Zeitpunkt versendet.
ALE-Szenario: Umlagerung zwischen zwei Systemen
In SAP-R/3- oder SAP-ECC-Systemen finden Sie Unterstützung für die Konfiguration einer
Umlagerung eines ALE-Szenarios zwischen zwei Systemen. Sie können dieses Szenario
verwenden, wenn Vertriebsniederlassungen oder Produktionsstätten voneinander oder vom
Zentrallager getrennt sind oder der zentrale Vertrieb nicht nur physisch, sondern auch im
Hinblick auf die Systeme beteiligt ist.
Abbildung 75: Szenario: Umlagerung zwischen zwei Systemen
Mit diesem Szenario können Sie den folgenden Grundprozess darstellen: Die Niederlassung
bestellt Waren von der Zentrale. Die neue Bestellung im IDoc-Format (Nachrichtentyp
ORDERS) wird automatisch vom empfangenden System in einen Kundenauftrag
umgewandelt. Das logische System der Zentrale sendet ebenfalls automatisch eine
Auftragsbestätigung (Nachrichtentyp ORDRSP) an die Niederlassung. Die
Eingangsverarbeitung der Auftragsbestätigung wird in der Bestellung aktualisiert: Der
Sachbearbeiter des Einkaufssachgebiets sieht in der Regel die Belegnummer des
Kundenauftrags der Zentrale auf der Belegpositionsebene seiner Bestellung.
Kapitel 3: Bewegungsdaten verteilen: Nachrichtensteuerung
©Copyright. Alle Rechte vorbehalten. 80Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

87. In der Zentrale wird bei Verfügbarkeit der Ware eine Lieferung zum Kundenauftrag angelegt.
Mit der Nachrichtensteuerung kann der Niederlassung automatisch ein Lieferavis im IDoc-
Format für diese Lieferung (Nachrichtentyp DESADV) gesendet werden. Je nach
Einstellungen im System der Niederlassung wird während der IDoc-Eingangsverarbeitung
eine Anlieferung (ein weiteres SAP-Dokument) angelegt. Andernfalls wird in der Bestellung
ein entsprechender Hinweis eingegeben. Nach dem Versand der Ware an die Niederlassung
kann die Zentrale auch die Rechnung elektronisch übertragen (Nachrichtentyp INVOIC).
Wenn die Eingangsverarbeitung des IDocs in der Niederlassung erfolgreich ist, wird
automatisch eine Eingangsrechnung gebucht.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●
Eine Bestellung anlegen und die Ergebnisse Ihrer Nachrichtenfindung prüfen
●Den systemübergreifenden Bestellprozess beschreiben
●Die wichtigsten Customizing-Einstellungen für diesen Prozess erläutern
Lektion: Beispiel: Bestellungsbearbeitung
©Copyright. Alle Rechte vorbehalten. 81Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

88. KAPITEL 4Bewegungsdaten
verteilen: BAPIs
Lektion 1
Business-Objekttypen und BAPIs 83
Lektion 2
Nutzung von BAPIs in ALE 89
Lektion 3
Beispiel: Reisekostenabrechnung 98
LERNZIELE
●Die Begriff e „Business-Objekttyp“ und „BAPI“ erläutern
●Objekttypen und BAPIs über den BAPI Explorer ermitteln sowie detaillierte Informationen
zu BAPIs bestimmen
●Customizing-Einstellungen für synchrone BAPI-Aufrufe vornehmen
●Die Konfiguration des ALE-Szenarios „Übertragung der Abrechnungsergebnisse der
Reisekostenabrechnung an die Buchhaltung“ beschreiben
©Copyright. Alle Rechte vorbehalten. 82Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

89. Kapitel 4
Lektion 1
Business-Objekttypen und BAPIs
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion erhalten Sie Informationen zu Business-Objekttypen und BAPIs. Sie
erfahren, wie Sie nach BAPIs suchen und diese finden und wie Sie erkennen, ob eine
asynchrone ALE-Schnittstelle für ein BAPI vorhanden ist.
Unternehmensszenario
Sie möchten einen Geschäftsprozess in einer verteilten Systemlandschaft einrichten. Dazu
suchen Sie nach entsprechenden Eingangsschnittstellen in empfangenden Systemen und
prüfen, ob diese Schnittstellen in einem vordefinierten ALE-Szenario verwendet wurden.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Die Begriff e „Business-Objekttyp“ und „BAPI“ erläutern
●Objekttypen und BAPIs über den BAPI Explorer ermitteln sowie detaillierte Informationen
zu BAPIs bestimmen
Business-Objekttyp
Integrationsszenarien sind wichtig für die Designphase von verteilten Geschäftsprozessen.
Für die technische Integration ist ein tieferes Verständnis der zugrunde liegenden
Technologie erforderlich (Business-Objekte und Zugriff smöglichkeiten auf Business-Objekte).
©Copyright. Alle Rechte vorbehalten. 83Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

90. Abbildung 76: Business-Objekttyp – Definition
Die Business-Objekttypen sind ein wichtiger Teil des Internet Business Frameworks und
Voraussetzung für die Interoperabilität. Business-Objekttypen decken ein breites Spektrum
an SAP-Geschäftsdaten und -Prozessen ab und können über standardisierte Methoden,
nämlich BAPIs, verwendet werden. Die Business-Objekttypen und ihre BAPIs bieten daher
eine objektorientierte Sicht der Business Functions in SAP-Systemen.
Abbildung 77: Business-Objekttyp – Darstellung
Damit diese Kapselung erreicht wird, werden Business-Objekttypen als Entitäten mit
verschiedenen Schichten erstellt: Im Zentrum des Business-Objekttyps ist der Kernel, der die
eigentlichen Daten des Objekts darstellt.
Kapitel 4: Bewegungsdaten verteilen: BAPIs
©Copyright. Alle Rechte vorbehalten. 84Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

91. Die zweite Schicht, die Integritätsschicht, stellt die Geschäftslogik des Objekts dar. Sie
umfasst die Geschäftsregeln für die konsistente Einbettung in die Umgebung sowie die
Einschränkungen in Bezug auf die Werte und Bereiche im Zusammenhang mit dem Business-
Objekttyp.
Die dritte Schicht, die Schnittstellenschicht, beschreibt die Implementierung und die Struktur
des Business-Objekttyps und definiert die Schnittstelle des Objekts zur Außenwelt.
Die vierte und äußerste Schicht eines Business-Objektstyps ist die Zugriff sschicht. Diese
Schicht definiert die Technologien, mit deren Hilfe ein externer Zugriff auf den Objekttyp
erfolgen kann, beispielsweise COM/DCOM (Component Object Model/Distributed
Component Object Model).
Abbildung 78: Beispiele für SAP-Business-Objekttypen
Jedes einzelne Business-Objekt gehört abhängig von seinen Eigenschaften zu einem
bestimmten Business-Objekttyp. Zum Beispiel gehören alle Mitarbeiter eines Unternehmens
zum Business-Objekttyp „Mitarbeiter“. Ein Mitarbeiter mit der Mitarbeiternummer 4711 ist
eine Instanz des Business-Objekttyps „Mitarbeiter“ und wird als Business-Objekt
gekennzeichnet.
Lektion: Business-Objekttypen und BAPIs
©Copyright. Alle Rechte vorbehalten. 85Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

92. Abbildung 79: Business Object Repository (BOR)
Alle Business-Objekttypen und ihre Methoden sind im Business Object Repository (BOR) in
SAP-Systemen definiert. Das BOR wurde erstmalig in SAP R/3 3.0 gleichzeitig mit der
Einführung der Business-Objekttypen und des SAP-Workflows eingeführt. In SAP R/3 3.0
wurde das BOR hauptsächlich vom SAP-Workflow genutzt.
Das BOR enthält die folgenden beiden Kategorien von Objekttypen:
●Business-Objekttypen
Hierbei handelt es sich um die bereits besprochenen Business-Objekttypen. Im BOR sind
die Business-Objekttypen hierarchisch den Anwendungskomponenten zugewiesen, z.B.
Vertrieb und Materialwirtschaft.
●
Technische Objekttypen
Hierbei handelt es sich um Elemente wie Texte, Workitems, archivierte Dokumente sowie
Entwicklungs- und Modellierungsobjekte.
Mit der Einführung der BAPIs in SAP R/3 3.1 wuchs die Bedeutung des BORs. Es ist nun der
zentrale Zugriff spunkt auf die Business-Objekttypen und die zugehörigen BAPIs in SAP-
Systemen für externe Anwendungen.
BAPI
Externe Anwendungen können auf Business-Objekte in SAP-Systemen über standardisierte,
plattformunabhängige Schnittstellen, nämlich BAPIs, zugreifen. Die Business-Objekttypen
und ihre BAPIs ermöglichen eine objektorientierte Sicht der Geschäftsprozesse und -daten in
einem SAP-System.
Kapitel 4: Bewegungsdaten verteilen: BAPIs
©Copyright. Alle Rechte vorbehalten. 86Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

93. Abbildung 80: Schnittstellen von Business-Objekttypen
Ein BAPI ist eine Standardschnittstelle, die Zugriff auf die Geschäftsdaten und
Geschäftsprozesse von Business-Objekttypen in SAP-Systemen bietet.
Beispielsweise enthalten die mit dem Business-Objekttyp „Material“ implementierten
Funktionen eine Prüfung der Verfügbarkeit des Materials. Daher weist der Business-Objekttyp
„Material“ ein BAPI mit dem NamenMaterial.CheckAvailabilityauf.
Abbildung 81: Wie wird ein BAPI in einem SAP-System implementiert?
Über den BAPI Explorer können Sie Informationen zu Business-Objekttypen und den
zugehörigen BAPIs abrufen. Wählen Sie im AnwendungsmenüWerkzeuge→Business
Framework→BAPI Explorer, oder rufen Sie direkt die TransaktionBAPIauf.
Lektion: Business-Objekttypen und BAPIs
©Copyright. Alle Rechte vorbehalten. 87Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

94. Abbildung 82: BAPI Explorer
Die Anzeige des BAPI Explorers gliedert sich in einen Hierarchiebereich und ein Detailfenster.
Die Komponentenhierarchie wird im Hierarchiebereich angezeigt. Sie können die Ordner der
Anwendungskomponenten öffnen und die Business-Objekttypen abrufen, die zur jeweiligen
Komponente gehören. Wenn Sie das Verzeichnis eines Business-Objekttyps öffnen, wird
Ihnen ein Teilbaum mit seinen Schlüsselattributen und seinen API-Methoden angezeigt. (API steht für Application Programming Interface).
*Diese moderierte Diskussion wurde aus rein formellen Gründen in die Lektion aufgenommen.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●
Die Begriff e „Business-Objekttyp“ und „BAPI“ erläutern
●Objekttypen und BAPIs über den BAPI Explorer ermitteln sowie detaillierte Informationen
zu BAPIs bestimmen
Kapitel 4: Bewegungsdaten verteilen: BAPIs
©Copyright. Alle Rechte vorbehalten. 88Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

95. Kapitel 4
Lektion 2
Nutzung von BAPIs in ALE
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion erfahren Sie, wie BAPIs in einem ALE-Szenario für synchrone Prüfungen und
Abfragen sowie asynchronen Datenaustausch verwendet werden können.
Unternehmensszenario
Sie möchten ein ALE-Szenario konfigurieren, in dem die Bewegungsdaten über BAPIs verteilt
werden.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Customizing-Einstellungen für synchrone BAPI-Aufrufe vornehmen
Synchrone Kommunikation mit BAPIs
Seit SAP R/3 4.6 werden BAPIs als Funktionsbausteine umgesetzt. Über den BAPI Explorer
können Sie zu der Anzeige des Funktionsbausteins für das ausgewählte BAPI im Function
Builder navigieren.
Abbildung 83: BAPI-Funktionsbausteine
BAPIs können für die synchrone Kommunikation zwischen zwei Systemen verwendet werden.
©Copyright. Alle Rechte vorbehalten. 89Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

96. Abbildung 84: Synchroner Aufruf eines BAPIs
Für den synchronen Aufruf eines BAPIs in einem ALE-Szenario müssen im
Anwendungsprogramm die folgenden Schritte durchgeführt werden:
1.Abfrage des Verteilungsmodells:
Das Anwendungsprogramm ermittelt den Empfänger und gegebenenfalls Filterwerte für
Filterobjekte aus dem Verteilungsmodell. Ist das BAPI nicht im Verteilungsmodell
enthalten, wird es in der Regel lokal aufgerufen.
2.Ermittlung der RFC-Destination:
Wenn das logische System bekannt ist, in dem das BAPI aufgerufen werden soll, ermittelt
das Anwendungsprogramm des aufrufenden Systems die RFC-Destination für dieses
Remote-System aus einer Tabelle. Diese rufen Sie über die TransaktionBD97oder im
Einführungsleitfaden im Customizing von ALE (TransaktionSALE) über den Pfad IDoc
Schnittstelle / Application Link Enabling (ALE)→Kommunikation→RFC-Destinationen für
Methodenaufrufe festlegenauf.
3.Aufruf des BAPI-Funktionsbausteins über RFC:
Das aufrufende System überträgt die Anwendungsdaten über RFC, indem es im
Zielsystem den BAPI-Funktionsbaustein aufruft.
Kapitel 4: Bewegungsdaten verteilen: BAPIs
©Copyright. Alle Rechte vorbehalten. 90Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

97. Abbildung 85: RFC-Destinationen für synchrone Methodenaufrufe
Mithilfe der TransaktionBD97können Sie einem Zielsystem eine Standarddestination für
BAPIs zuordnen. Alle BAPI-Aufrufe, für die keine spezielle Destination eingegeben wurde,
nutzen diese Destination. Der RFC-Benutzer der Standarddestination muss über die
entsprechenden Anwendungsberechtigungen verfügen. Sie können auch eine Destination für
jeden Methodenaufruf pro Zielsystem pflegen. In diesem Fall können Sie die Berechtigungen
des RFC-Users gezielter zuordnen.
Im Verteilungsmodell können Sie BAPIs über die DrucktasteBAPIs einfügenden einzelnen
Modellsichten hinzufügen.
Abbildung 86: Verteilungsmodell: Hinzufügen von BAPIs
Neben den sendenden und empfangenden Systemen geben Sie in der Modellsicht den Namen
des beteiligten Business-Objekttyps und die gewünschte Methode ein, d.h. das BAPI. In den
FeldernBusiness-ObjekttypundMethodegeben Sie nicht die technischen Namen der
Business-Objekttypen aus dem Business Object Builder, sondern den Namen aus dem BAPI
Explorer ein.
Lektion: Nutzung von BAPIs in ALE
©Copyright. Alle Rechte vorbehalten. 91Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

98. Asynchrone Kommunikation mit BAPIs
Abbildung 87: Asynchroner Aufruf eines BAPIs im Zielsystem
Zum asynchronen Aufrufen eines BAPIs im Zielsystem wird ein IDoc an das Zielsystem
gesendet. Dieses enthält die Schnittstellenparameter des BAPIs und im Fall einer
Instanzmethode die Schlüsselfelder des Business-Objekts. Im Zielsystem wird der BAPI-
Funktionsbaustein mit den Parametern aus dem IDoc lokal aufgerufen.
Abbildung 88: ALE-Schnittstelle eines BAPI
Sie rufen die Anzeige der ALE-Schnittstelle eines BAPI auf, indem Sie in der Detailsicht des
BAPI Explorer auf den ALE-Nachrichtentyp klicken. Rufen Sie auf diese Weise die Transaktion
BDBGauf, mit der Sie die vorhandenen ALE-Schnittstellen von BAPIs anzeigen und darüber
hinaus neue Schnittstellen generieren können.
In der TransaktionBDBGwählen Sie die DrucktasteSchnittstelle anzeigenaus, um die
automatisch generierten Elemente der ALE-Schnittstelle eines BAPIs anzuzeigen.
Kapitel 4: Bewegungsdaten verteilen: BAPIs
©Copyright. Alle Rechte vorbehalten. 92Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

99. Abbildung 89: ALE-Schnittstelle eines BAPI
Die folgenden Elemente sind Teil der generierten ALE-Schnittstelle eines BAPI:
●Nachrichtentyp:
Nachrichtentypen der ALE-Schnittstelle von BAPIs werden nicht direkt einer Modellsicht
zugeordnet. Sie werden ausschließlich in den Partnervereinbarungen zwischen sendenden
und empfangenden Systemen verwendet. Die BAPIs selbst werden im Verteilungsmodell
zugeordnet (siehe oben).
●
IDoc-Typ:Der IDoc-Typ ist die Grundlage für das IDoc, das für die asynchrone
Kommunikation mit BAPIs erforderlich ist.
●Segmenttypen:Die elementaren Importparameter werden in einem Segmenttyp
zusammengefasst. Für jeden strukturierten Importparameter wird ein Segmenttyp angelegt.
●
Funktionsbaustein für ALE-Ausgang:Im Ausgangsbaustein werden die
Schnittstellenparameter in die IDoc-Segmente kopiert, und ein Master-IDoc wird erzeugt. Anschließend wird ein Funktionsbaustein aufgerufen, der dieses Master-IDoc an die ALE- Schicht überträgt.
●
Funktionsbaustein für ALE-Eingang:Der Eingangsbaustein kopiert den Inhalt der
Segmentfelder in die zugehörigen Schnittstellenparameter und ruft den BAPI- Funktionsbaustein lokal im Zielsystem auf.
Lektion: Nutzung von BAPIs in ALE
©Copyright. Alle Rechte vorbehalten. 93Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

100. Abbildung 90: Ausgangsverarbeitung eines IDocs für einen BAPI-Aufruf
Die folgenden Schritte werden im Anwendungsprogramm durchgeführt:
1.Die Anwendungsdaten, das empfangende System und alle Filterwerte für Objekte aus dem
Verteilung
smodell des sendenden Systems werden ermittelt.
2.Der generierte Ausgangsbaustein der ALE-Schnittstelle zum BAPI wird aufgerufen. Dieser Baust
ein erzeugt das Master-IDoc und übergibt es an die ALE-Schicht.
Das Kommunikations-IDoc wird auf dieselbe Weise wie in den ALE-Szenarien angelegt, die nicht auf BAPIs basieren: Für den Nachrichtentyp des BAPI müssen Partnervereinbarungen mit dem empfangenden System vorhanden sein, in dem der erzeugte IDoc-Basistyp des ALE- Szenarios des BAPI sowie ein entsprechender RFC-Port zugeordnet werden.
Kapitel 4: Bewegungsdaten verteilen: BAPIs
©Copyright. Alle Rechte vorbehalten. 94Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

101. Abbildung 91: Senden des Kommunkations-IDocs
Das Kommunikations-IDoc wird sofort oder zu einem späteren Zeitpunkt über RFC gesendet,
je nach den Spezifikationen in den Partnervereinbarungen mit dem empfangenden System.
Abbildung 92: Eingangsverarbeitung eines IDocs für einen BAPI-Aufruf
Lektion: Nutzung von BAPIs in ALE
©Copyright. Alle Rechte vorbehalten. 95Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

102. Im empfangenden System wird das IDoc in der Datenbank abgelegt. Je nach Einstellung in
den Partnervereinbarungen wird es entweder sofort an die Anwendung übertragen oder vom
Programm RBDAPP01 als Hintergrundjob zu einem späteren Zeitpunkt verarbeitet.
Anhand des Vorgangscodes
BAPIin den Partnervereinbarungen erkennt ALE, dass der
Eingabefunktionsbaustein der ALE-Schnittstelle, die für das BAPI erzeugt wurde, aufgerufen
werden muss. Der Eingangsbaustein kopiert den Inhalt der Segmentfelder des IDocs in die
BAPI-Schnittstellenparameter und ruft anschließend den BAPI-Funktionsbaustein lokal auf.
Abbildung 93: Ausgangspartnervereinbarung im Sendersystem
Wenn möglich, generieren Sie die Partnervereinbarungen von BAPI-basierten ALE-Szenarien
aus dem Verteilungsmodell. Das System gibt dann die für das BAPI relevanten
Nachrichtentyp und den IDoc-Typ ein.
Abbildung 94: Eingangspartnervereinbarung im Empfängersystem
Kapitel 4: Bewegungsdaten verteilen: BAPIs
©Copyright. Alle Rechte vorbehalten. 96Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

103. Generieren Sie auch die Partnervereinbarung im Empfängersystem aus dem
Verteilungsmodell: Das System ordnet den Vorgangscode BAPI zu.
*Diese moderierte Diskussion wurde aus rein formellen Gründen in die Lektion aufgenommen.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Customizing-Einstellungen für synchrone BAPI-Aufrufe vornehmen
Lektion: Nutzung von BAPIs in ALE
©Copyright. Alle Rechte vorbehalten. 97Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

104. Kapitel 4
Lektion 3
Beispiel: Reisekostenabrechnung
ÜBERBLICK ÜBER DIE LEKTION
Diese Lektion erläutert die Konfiguration des ALE-Szenarios „Übertragung der
Abrechnungsergebnisse der Reisekostenabrechnung an die Buchhaltung“. Dieses Szenario
nutzt BAPIs sowohl für die synchrone als auch für die asynchrone Kommunikation.
Unternehmensszenario
Ihr Unternehmen hat das Personalwesen in ein eigenes System verlagert. Die Mitarbeiter
erfassen die Kosten ihrer Dienstreisen im Reisemanagement dieses Systems. In Zukunft
werden die Ergebnisse der Reisekostenabrechnung per ALE an das Buchhaltungssystem
übertragen.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●
Die Konfiguration des ALE-Szenarios „Übertragung der Abrechnungsergebnisse der
Reisekostenabrechnung an die Buchhaltung“ beschreiben
Reisekostenabrechnung: Prozess
Das Reisemanagement ist Teil der Anwendung mySAP ERP Financials, betrifft jedoch auch
das Personalwesen. Aus diesem Grund finden Sie die Anwendungstransaktionen für die
Verwendung der Funktionen des Reisemanagements im Berichtsmenü beider Anwendungen.
Das Reisemanagement muss nicht unbedingt systematisch von den anderen
Buchhaltungsanwendungen getrennt werden. Nicht selten wird es jedoch dem separat
betriebenen System für das Personalwesen (im Beispiel HR_TRAVEL) zugeordnet. Wenn die
Systeme auf diese Weise getrennt sind, dann müssen die Ergebnisse der
Reisekostenabrechnung für Buchungen und für die anschließende Auszahlung von
Erstattungsbeträgen an das Buchhaltungssystem (im Beispiel: CORE) übertragen werden. In
SAP R/3 und SAP EEC wird das vorkonfigurierte ALE-Szenario „Übertragung der
Abrechnungsergebnisse der Reisekostenabrechnung an die Buchhaltung“ für diesen Prozess bereitgestellt.
©Copyright. Alle Rechte vorbehalten. 98Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

105. Abbildung 95: Reisekostenabrechnung: Buchungsvorgang
Die Abbildung „Reisekosten: Buchungsvorgang“ veranschaulicht den buchungstechnischen
Ablauf des Prozesses. Er besteht aus den folgenden Einzelschritten:
●Erfassung der Reisekosten:Im Reisemanagement gibt der Mitarbeiter die Details (Beginn
und Ende der Reise, Reiseziel, Ausgaben für Unterkunft, Verkehrsmittel usw.) seiner
Geschäftsreise ein (Reise anlegen).
●Genehmigung der Reise:Der Vorgesetzte bzw. Mitarbeiter der Personalabteilung
genehmigt die Erstattung der Kosten (Reise genehmigen).
●Abrechnung der Reise:Die Personalabteilung lässt das System die Erstattungsbeträge
berechnen. Unter anderem berücksichtigt dieser Schritt die im System hinterlegten Tagessätze zur Berechnung der Ausgaben (Reise abrechnen).
●
Erstellung des Buchungslaufs:Beim Anlegen des sogenannten Buchungslaufs führt das
System synchrone BAPI-Aufrufe durch. So wird unter anderem geprüft, ob die Konten, auf die gebucht werden soll, die in den Reisekosten festgelegten Kontierungsobjekte des Controllings und die für die Erstattung der Ausgaben erforderlichen Lieferantenstammsätze für die Personalnummern der Mitarbeiter auf der Reise im Buchhaltungssystem vorhanden sind.
●
Prüfung des Buchungslaufs:Um sicherzustellen, dass auf den Konten und den
Kontierungsobjekten der Buchhaltung zum Zeitpunkt der Abrechnungsdatenübertragung Buchungen vorgenommen werden dürfen, kann das Reisemanagementsystem zusätzliche synchrone BAPI-Aufrufe durchführen.
●
Buchung des Buchungslaufs:Zuletzt überträgt das Reisemanagementsystem die
Ergebnisse der Abrechnung an das Buchhaltungssystem. Die in diesem Schritt vom System verwendeten BAPIs werden asynchron im Rahmen der IDoc-Eingangsverarbeitung aufgerufen.
Lektion: Beispiel: Reisekostenabrechnung
©Copyright. Alle Rechte vorbehalten. 99Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

106. Notiz:
Ein Buchungslauf ist eine Art Behälter für die Belege, in denen die Ergebnisse der
Reisekostenabrechnung festgehalten werden. Jeder Buchungslauf erhält eine
eindeutige fortlaufende Nummer durch das System.
Notwendige Voreinstellungen
Für das ALE-Szenario „Übertragung der Abrechnungsergebnisse der Reisekostenabrechnung
an die Buchhaltung“ ist die Vorabverteilung der in beiden Systemen erforderlichen
Stammdaten (Personalstammdaten, Kostenstellen) eine notwendige Voraussetzung.
Zusätzlich muss das Customizing in den betroffenen Bereichen synchronisiert werden.
Abbildung 96: Stammdatenverteilung
Detaillierte Informationen zu diesen Einstellungen finden Sie im IMG über die Transaktion
SALE. Wählen Sie dann IDoc-Schnittstelle / Application Link Enabling (ALE)
→Geschäftsprozesse modellieren und implementieren→Vordefinierte ALE-
Geschäftsprozesse
konfigurieren →Personalwirtschaft→HR→ AC→→Reisekostenüberleitung ins FI.
Details des Buchungslaufs der Reisekostenabrechnung
Um im System der Reisekostenabrechnung einen Buchungslauf anzulegen, übertragen Sie
die relevanten BAPIs (siehe Abbildung unten) in eine entsprechende Sicht des
Verteilungsmodells im Pflegesystem und ordnen dem Zielsystem dieser synchronen
Methodenaufrufe mit der TransaktionBD97eine RFC-Destination zu.
Kapitel 4: Bewegungsdaten verteilen: BAPIs
©Copyright. Alle Rechte vorbehalten. 100Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

107. Abbildung 97: Modellsicht: Buchungslauf anlegen
Um einen Buchungslauf zu prüfen, übertragen Sie ebenfalls die relevanten BAPIs in eine Sicht
des Verteilungsmodells und ordnen dem Zielsystem des synchronen Methodenaufrufs mit
der TransaktionBD97eine RFC-Destination zu.
Abbildung 98: Modellsicht: Buchungslauf prüfen
Um einen Buchungslauf im Buchhaltungssystem zu buchen, übertragen Sie die relevanten
BAPIs in eine Sicht des Verteilungsmodells und erzeugen die Partnervereinbarungen für die
IDoc-Generierung in den Sender- und Empfängersystemen.
Lektion: Beispiel: Reisekostenabrechnung
©Copyright. Alle Rechte vorbehalten. 101Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

108. Abbildung 99: Modellsicht: Buchungslauf buchen
Wenn Sie die Reiseübernahmebelege nach der Übertragung des Buchungslaufs an das
Buchhaltungssystem im Reisekostenabrechnungssystem anzeigen, sehen Sie anhand einer
Ampelanzeige, ob die Datenübertragung erfolgreich war.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●
Die Konfiguration des ALE-Szenarios „Übertragung der Abrechnungsergebnisse der
Reisekostenabrechnung an die Buchhaltung“ beschreiben
Kapitel 4: Bewegungsdaten verteilen: BAPIs
©Copyright. Alle Rechte vorbehalten. 102Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

109. KAPITEL 5Überwachung der
Datenverteilung,
Fehlerbehandlung und
Archivierung
Lektion 1
IDoc-Statusverwaltung 104
Lektion 2
Fehleranalyse und -behandlung 110
Lektion 3
SAP Workflow im ALE-Umfeld 120
Lektion 4
IDocs archivieren 130
LERNZIELE
●Den Statusmonitor effizient verwenden
●Das ALE-Audit einrichten und nutzen
●Fehleranalyse mithilfe des ALE-Statusmonitors durchführen
●Fehler in der IDoc-Verarbeitung beheben
●Workflow-Einstellungen für die Fehlerbehandlung von IDocs prüfen
●Einstellungen zu Vorgangscodes nachvollziehen
●Das Benachrichtigungskonzept beschreiben
●Die IDoc-Verarbeitung über den SAP Workflow überwachen
●Das Verfahren der IDoc-Archivierung beschreiben
●Die archivierbaren Status im System setzen
©Copyright. Alle Rechte vorbehalten. 103Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

110. Kapitel 5
Lektion 1
IDoc-Statusverwaltung
ÜBERBLICK ÜBER DIE LEKTION
Diese Lektion vermittelt Ihnen detaillierte Informationen zum IDoc-Statusmonitor. Außerdem
erfahren Sie, wie das Sendersystem das ALE-Audit zum Abrufen von Informationen über die
Weiterverarbeitung von IDocs im Empfängersystem verwendet.
Unternehmensszenario
Sie verwenden verschiedene ALE-Szenarien und müssen die Datenverteilung überwachen.
Fehler bei der IDoc-Ausgangs- oder -Eingangsverarbeitung sollen frühzeitig erkannt werden.
Sie suchen außerdem nach Möglichkeiten, im Sendersystem Informationen zur
Weiterverarbeitung von IDocs im Empfängersystem aufzurufen.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●
Den Statusmonitor effizient verwenden
●Das ALE-Audit einrichten und nutzen
IDoc-Statusverwaltung
Der Statusmonitor bietet Ihnen einen Überblick über die Ausgangs- und Eingangs-IDocs aus
der Perspektive des logischen Systems durch das Ausführen der Transaktion
(TransaktionscodeBD87). Ab SAP R/3 4.6C zeigt der Statusmonitor alle IDocs an, auch
solche, die fehlerfrei verarbeitet wurden.
Da meist nicht alle noch nicht archivierten IDocs gleichzeitig angezeigt werden sollen, bietet
Ihnen der Statusmonitor verschiedene Auswahlkriterien für die Anzeige bestimmter Belege
an:
●IDoc-Nummern
●Erstelldatum und -uhrzeit
●Änderungsdatum und -uhrzeit
●IDoc-Status
●Partnersysteme
●Nachrichtentypen
●Business-Objekttypen und Objektschlüssel
Die anhand der Auswahlspezifikationen ermittelten IDocs werden im Statusmonitor zunächst
nach Richtung (Ausgang oder Eingang) gruppiert. Außerdem werden sie in Statusgruppen
zusammengefasst. Beispielsweise werden alle Ausgangs-IDocs für einen Nachrichtentyp, die
erfolgreich an einen tRFC-Port übertragen wurden, in Statusgruppe 03 zusammengefasst.
Jeder Statuswert ist einem Ampelsymbol zugeordnet. Erfolgreich verarbeitete IDocs werden
©Copyright. Alle Rechte vorbehalten. 104Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

111. mit grünen Ampelsymbolen im Statusmonitor angezeigt, noch nicht (vollständig) verarbeitete
IDocs mit gelben Ampelsymbolen und fehlerhaft verarbeitete IDocs mit roten
Ampelsymbolen.
Abbildung 100: Statusgruppen
Die Zuordnung eines Status zu einem Ampelsymbol kann geändert werden. Rufen Sie dazu
die TransaktionWE47auf. Statuswerte werden zu Statusgruppen zusammengefasst. Die
Ampelsymbole werden Statusgruppen in einer Tabelle zugeordnet, die Sie über die
TransaktionWELIaufrufen können.
Notiz:
In SAP R/3 4.7 finden Sie diese Transaktionen über den Menüpfad
Werkzeuge→Business Communication→IDoc-Basis→Steuerung→Status. In
SAP ECC 5.0 rufen Sie die Transaktionen aus dem IMG (TransaktionSALE) unter
IDoc-Schnittstelle / Application Link Enabling (ALE)→Überwachung der Systeme
einstellen→IDoc-Statusanzeige einstellen→IDoc-Statuswerte bearbeitenoder
Statusgruppen bearbeitenauf.
Über den EintragEinstellungen→Hierarchieim Menü des Statusmonitors können Sie wählen,
ob der Nachrichtentyp oder der Statuswert hervorgehoben werden soll.
IDocs anzeigen und verfolgen
Verwenden Sie die DrucktasteIDocs anzeigen, um eine Liste aller IDocs zu einem
Nachrichtentyp aufzurufen.
Lektion: IDoc-Statusverwaltung
©Copyright. Alle Rechte vorbehalten. 105Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

112. Abbildung 101: IDocs anzeigen
Durch Doppelklick auf eine der IDoc-Nummern in dieser Liste geben Sie die Anzeige des
Belegs selbst ein. Hier können Sie den Kontrollsatz, die Datensätze und die Statussätze
überprüfen.
Sie können unter bestimmten Bedingungen auch aus dem Sendersystem ein IDoc im
Empfängersystem aufrufen und anzeigen. Die Funktion der IDoc-Verfolgung finden Sie auch
im Statusmonitor, indem Sie die entsprechende Drucktaste wählen.
Abbildung 102: IDoc-Verfolgung
Um diese Funktion zu verwenden, müssen folgende Voraussetzungen erfüllt sein:
Kapitel 5: Überwachung der Datenverteilung, Fehlerbehandlung und Archivierung
©Copyright. Alle Rechte vorbehalten. 106Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

113. ●In der Ausgangspartnervereinbarung mit dem jeweiligen Empfängersystem müssen
Parameter für den Nachrichtentyp SYNCH vorhanden sein.
●Der RFC-Benutzer, der in der RFC-Destination eingegeben ist, die dem Port der
Ausgangspartnervereinbarung für den Nachrichtentyp SYNCH zugeordnet ist, muss im
Empfängersystem über die Berechtigung „Ausführen“ für die Funktionsgruppe BDMT für
das Berechtigungsobjekt S_RFC verfügen.
●Im Sendersystem muss dem Empfängersystem eine RFC-Destination für Dialoge
zugeordnet werden. Diese Zuordnung können Sie im IMG vornehmen, indem Sie die
TransaktionSALEaufrufen und den PfadIDoc-Schnittstelle / Application Link Enabling
(ALE)→Kommunikation→RFC-Destinationen für Methodenaufrufe festlegenwählen.
●Der RFC-Benutzer muss im Empfängersystem ein Dialog-User mit entsprechenden
Berechtigungen für das Berechtigungsobjekt S_IDOCMONI sein.
ALE-Audit
Die Funktion ALE-Audit stellt dem Sendersystem Informationen über den
Verarbeitungsstatus eines IDocs im Empfängersystem zur Verfügung.
Abbildung 103: ALE-Audit: Modellsicht
Das Empfängersystem verwendet die asynchrone IDoc-Schnittstelle, um
Statusinformationen an das Sendersystem eines IDocs zurückzusenden. Der Nachrichtentyp
der Rückmeldung istALEAUD. Das Empfängersystem erstellt sein eigenes IDoc mit
Statusinformationen zu IDocs, das es für bestimmte Nachrichtentypen in einem bestimmten
Zeitraum empfangen hat. Diese Audit-Rückmeldung wird in der Regel periodisch über einen
Hintergrund-Job versendet, kann aber auch direkt vom Statusmonitor ausgelöst werden.
Das ALE-Audit einrichten
1.Fügen Sie den Nachrichtentyp ALEAUD zu allen relevanten Modellsichten hinzu. Das Empf
ängersystem der IDocs, deren Statuswerte im Rahmen des Audits übermittelt
werden sollen, ist das Sendersystem für der Nachrichtentyp ALEAUD.
Lektion: IDoc-Statusverwaltung
©Copyright. Alle Rechte vorbehalten. 107Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

114. 2.Filtern Sie bei Bedarf nach dem Nachrichtentyp. Ein entsprechendes Filterobjekt ist
vorhanden. Geben Sie als Filter
werte alle Nachrichtentypen ein, für die Sie eine Audit-
Meldung anlegen möchten.
3.Verteilen Sie die geänderten Nachrichtensichten neu, und generieren Sie diePartnervereinbarungen in allen beteiligten Systemen.
4.Fügen Sie das ProgrammRBDSTATEzum Versenden der Audit-Rückmeldungen hinzu.
Abbildung 104: ALE-Audit: Statuswerte
Der Statuswert eines Ausgangs-IDocs im Sendersystem nach der erfolgreichen
Eingangsverarbeitung des Rückmeldungs-IDocs für den Nachrichtentyp ALEAUD hängt vom
Status des entsprechenden Eingangs-IDocs im Empfängersystem zum Zeitpunkt der
Ausführung des Programms RBDSTATE ab:
●Wenn das Eingangs-IDoc im Empfängersystem den Status
53(Anwendungsbeleg gebucht)
aufw
eist, erhält das entsprechende Ausgangs-IDoc im Sendersystem den Status
41
(Anwendungsbeleg im Zielsystem erzeugt).
●Wenn das IDoc im Empfängersystem mit dem Status64(IDoc ist übergabebereit an die
Anw
endung) oder
62(IDoc an Anwendung übergeben) eingeht , die Daten aber noch nicht
in der Anwendung gebucht sind, dann erhält das entsprechende IDoc im Sendersystem
den Status39(IDoc im Zielsystem (ALE-Dienst)). Daher bedeut et Status39lediglich, dass
das IDoc im Emp
fängersystem angekommen ist. Status
39sagt nichts darüber aus, ob das
IDoc noch den Status 64 auf
weist, da das Programm RBDAPP01 noch nicht gestartet
wurde, oder ob ein Fehler aufgetreten ist.
●Wenn das IDoc im Empfängersystem falsch verarbeitet wurde und dieser Fehler nichtbehoben werden kann – zum Beispiel wenn das IDoc an das falsche Empfängersystem
gesendet wurde – dann kann sich der Status des IDocs zu Status 68ändern. In diesem Fall
wir
d der Status des zugehörigen IDocs im Sendersystem auf den Status
40
(Anwendungsbeleg im Zielsystem nicht erzeugt) gesetzt.
Sie finden die Funktionen des ALE-Audits im Menü des Statusmonitors über den Pfad
Springen→ALE-Audit. Sie können Rückmeldungen direkt senden (indem Sie das Programm
Kapitel 5: Überwachung der Datenverteilung, Fehlerbehandlung und Archivierung
©Copyright. Alle Rechte vorbehalten. 108Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

115. RBDSTATE starten), statistische Auswertungen anlegen und nicht mehr benötigte Audit-
Statistiken löschen.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Den Statusmonitor effizient verwenden
●Das ALE-Audit einrichten und nutzen
Lektion: IDoc-Statusverwaltung
©Copyright. Alle Rechte vorbehalten. 109Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

116. Kapitel 5
Lektion 2
Fehleranalyse und -behandlung
ÜBERBLICK ÜBER DIE LEKTION
Die IDoc-Verarbeitung funktioniert nicht immer auf Anhieb. Konfigurationsfehler im ALE-
Bereich und in der betroffenen Anwendung selbst können zu Fehlern bei der IDoc-
Generierung oder der weiteren IDoc-Verarbeitung führen. In dieser Lektion lernen Sie, wie Sie
Fehler systematisch analysieren und anschließend beheben.
Unternehmensszenario
Sie haben verschiedene ALE-Szenarien eingerichtet. Ein Administrator soll die
Fehlerbehandlung in der Zukunft übernehmen. Sie möchten sich einen Überblick über die
Möglichkeiten der Fehleranalyse und -behebung verschaff en.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Fehleranalyse mithilfe des ALE-Statusmonitors durchführen
●Fehler in der IDoc-Verarbeitung beheben
IDoc-Ausgangsverarbeitung
In der Ausgangsverarbeitung durchläuft ein IDoc verschiedene Phasen, deren Ergebnisse
durch Statuswerte dargestellt werden. Eine erfolgreiche IDoc-Ausgangsverarbeitung umfasst
obligatorische und optionale Statuswerte, wie in der Abbildung „Statuswerte für fehlerfreie
IDoc-Ausgangsverarbeitung“ dargestellt.
©Copyright. Alle Rechte vorbehalten. 110Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

117. Abbildung 105: Statuswerte für fehlerfreie IDoc-Ausgangsverarbeitung
●01:IDoc erzeugt
●30:IDoc ist versandfertig (ALE-Dienst)
●03:Datenübergabe an Port OK
Ob das Sendersystem ein IDoc sofort sendet, hängt von den Spezifikationen in der jeweiligen
Ausgangspartnervereinbarung ab. Wenn die OptionIDocs zusammenfassenausgewählt ist,
werden die IDocs an den Empfängerport der Partnervereinbarung übertragen, nachdem das
Programm RSEOUT00 ausgeführt wurde. Status 30 ist immer ein Zwischenstatus.
Status 03 informiert Sie darüber, dass die IDoc-Daten erfolgreich an den Port übertragen
wurden. Sie erfahren erst, ob das IDoc tatsächlich im Empfängersystem zugestellt werden
konnte, wenn Sie das Programm RBDMOIND ausführen. Dieses Programm, das für die
regelmäßige Hintergrundverarbeitung mit Jobs bestimmt ist, prüft, ob sich in der tRFC-Queue
IDocs befinden. Alle nicht mehr in dieser Queue enthaltenen IDocs erhalten den Status 12
(Versand OK).
Wenn Sie das ALE-Audit eingerichtet haben, gibt es auch die folgenden Statuswerte:
●39:IDoc im Zielsystem (ALE-Dienst)
●41:Anwendungsbeleg im Zielsystem angelegt
Für das ALE-
Audit muss das Programm RBDSTATE im Empfängersystem ausgeführt werden.
Dieses Programm ist auch für die regelmäßige Hintergrundverarbeitung mit Jobs bestimmt.
Status 39 im Sendersystem informiert Sie darüber, dass ein IDoc in der Datenbank im
Empfängersystem gespeichert wurde, aber noch nicht an die Anwendung übertragen wurde.
Das IDoc kann über den Status 64 oder 62 im Empfängersystem verfügen. Status 41
kennzeichnet ein IDoc, dessen Daten in der jeweiligen Anwendung des Empfängersystems
erfolgreich verbucht wurden (Status 53).
Lektion: Fehleranalyse und -behandlung
©Copyright. Alle Rechte vorbehalten. 111Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

118. Bei Fehlern in der IDoc-Ausgangsverarbeitung setzt das Sendersystem einen der
Statuswerte, die in der Abbildung „Statuswerte für fehlerhafte IDoc-Ausgangsverarbeitung“
dargestellt sind.
Abbildung 106: Statuswerte für fehlerhafte IDoc-Ausgangsverarbeitung
●02:Fehler bei Datenübergabe an Port
●26: Fehler beiSyntaxfehler im IDoc (Ausgang)
●25:Weiterverarbeitung trotz Syntaxfehler (Ausgang)
●29:Fehler im ALE-Dienst
Status 02 wir
d anstelle des Status 03 gesetzt, wenn ein Fehler bei der Übergabe an den Port
auftritt. Das Sendersystem ermittelt den Transaktionscode EDIO und sendet auf der
Grundlage der zugeordneten Workflow-Aufgabe ein Workitem an den zuständigen Bearbeiter.
Wenn der Fehler behoben ist, kann das IDoc aus diesem Workitem oder aus dem IDoc-
Statusmonitor wieder an den Port übertragen werden.
Status 26 zeigt an, dass dem IDoc ein Segment fehlt, das nach Angabe des IDoc-Basistyps
erforderlich ist, dass mehr Segmente für einen Segmenttyp vorhanden sind als im IDoc-
Basistyp angegeben oder dass eine sonstige Verletzung der Spezifikationen des IDoc-
Basistyps vorliegt. Wenn das KennzeichenVerarbeitung nach Syntaxfehler abbrechenin der
Ausgangspartnervereinbarung nicht gesetzt ist, wird das IDoc trotzdem an Status 30 übertragen und weiterverarbeitet. Wenn das Kennzeichen jedoch gesetzt ist, ermittelt das Sendersystem den Transaktionscode EDIX und sendet ein Workitem gemäß der
zugeordneten Workflow-Aufgabe. Es ist möglich, die Weiterverarbeitung des IDocs trotz eines
Syntaxfehlers auszulösen. Das IDoc erhält zunächst den Status 25 und wechselt dann zu Status 02.
Wenn Ausgangspartnervereinbarungen vollständig fehlen oder unvollständig sind, erhält das
betroffene IDoc den Status 29. Dieser Status wird auch zugeordnet, wenn ein globaler
Buchungskreis oder ein Geschäftsbereich fehlt. Wenn das IDoc wieder verarbeitet wird,
nachdem die fehlenden Einstellungen hinzugefügt wurden, protokolliert das System dies als
Bearbeitung des IDocs und erstellt eine Kopie des Originals, die zu Dokumentationszwecken
Kapitel 5: Überwachung der Datenverteilung, Fehlerbehandlung und Archivierung
©Copyright. Alle Rechte vorbehalten. 112Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

119. aufbewahrt wird, selbst in inkorrekter Form. Die Kopie erhält den Status 30 und das Original
den Status 33 (Original eines IDocs, welches editiert wurde).
IDoc-Eingangsverarbeitung
In der Eingangsverarbeitung durchläuft ein IDoc ebenfalls verschiedene Phasen, deren
Ergebnisse durch Statuswerte dargestellt werden. Eine erfolgreiche IDoc-
Eingangsverarbeitung umfasst obligatorische Statuswerte wie in der Abbildung „Statuswerte
für fehlerfreie IDoc-Eingangsverarbeitung“ dargestellt.
Abbildung 107: Statuswerte für fehlerfreie IDoc-Eingangsverarbeitung
●50:IDoc hinzugefügt
●64:IDoc ist übergabebereit an die Anwendung
●62:IDoc an Anwendung übergeben
●53:Anwendungsbeleg gebucht
Ob das Empf
ängersystem ein IDoc sofort an die Anwendung überträgt, hängt von den
Einstellungen in der jeweiligen Eingangspartnervereinbarung ab. Wenn dort die OptionAnstoß
durch Hintergrundprogrammausgewählt ist, wird das IDoc erst nach Ausführung des
Programms RBDAPP01 an die Anwendung übertragen.
Notiz:
In solchen Szenarien benötigt der RFC-Benutzer nur die Berechtigung, IDocs in
der Datenbank abzulegen. Hierzu sind die RFC-Berechtigungen zu den
Funktionsgruppen EDIN und ERFC (Berechtigungsobjekt S_RFC) und die
Berechtigung für das Berechtigungsobjekt B_ALE_RECV mit den gewünschten
Nachrichtentypen erforderlich. Der Benutzer für die Hintergrundverarbeitung des
Programms RBDAPP01 muss über die Berechtigungen verfügen, das IDoc aus der
Datenbank zu lesen (Berechtigungsobjekt S_IDOCMONI), sowie über die
Anwendungsberechtigungen, die Daten über das Anwendungsprogramm zu
buchen.
Lektion: Fehleranalyse und -behandlung
©Copyright. Alle Rechte vorbehalten. 113Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

120. Bei Fehlern in der IDoc-Eingangsverarbeitung setzt das Sendersystem einen der Statuswerte,
die in der Abbildung „Statuswerte für fehlerhafte IDoc-Eingangsverarbeitung“ dargestellt
sind.
Abbildung 108: Statuswerte für fehlerhafte IDoc-Eingangsverarbeitung
●56:Fehlerhaftes IDoc hinzugefügt
●60:Syntaxfehler im IDoc (Eingang)
●61:Weiterverarbeitung trotz Syntaxfehler (Eingang)
●65:Fehler im ALE-Dienst
●51:Anwendungsbeleg nicht gebucht
An Status 56 erkennen Sie in der R
egel, dass die Eingangspartnervereinbarung für den
Nachrichtentypen fehlt.
Wenn das KennzeichenVerarbeitung nach Syntaxfehler abbrechenin der
Eingangspartnervereinbarung gesetzt ist, erhält ein IDoc mit einem Syntaxfehler den Status
60. Das System sendet dem zuständigen Bearbeiter ein Workitem auf der Basis der dem
Vorgangscode EDIY zugeordneten Workflow-Aufgabe. Wenn die Syntaxprüfung nicht aktiviert
ist, wird das falsche IDoc direkt von Status 60 auf Status 64 gesetzt. Wenn ein IDoc mit einem Syntaxfehler mit Status 60 weiterverarbeitet wird, erhält es erst Status 61 und dann Status 64.
Das System setzt den Status 65, wenn ein globaler Buchungskreis oder ein Geschäftsbereich
fehlt.
Wenn die Übertragung der Daten des IDocs an die jeweilige Anwendung fehlschlägt, erhält
das IDoc in den meisten Fällen den Status 51. Eine Anzahl von Logistikanwendungen haben
eigene Status (52 und 54), zeigen aber alle einen Fehler in der Verarbeitung der IDoc-Daten
im Anwendungsprogramm selbst an. Workitems werden an die zuständigen Bearbeiter
Kapitel 5: Überwachung der Datenverteilung, Fehlerbehandlung und Archivierung
©Copyright. Alle Rechte vorbehalten. 114Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

121. gesendet. Je nach Anwendung kann ein solches IDoc auch im Vordergrund verarbeitet
werden (d.h. interaktiv). Fehlende oder falsche Werte können dann manuell ergänzt bzw.
korrigiert werden.
Am Ende dieser Lektion finden Sie Vorschläge für eine systematische Fehleranalyse mit
Informationen zur Fehlerbehebung.
Problem: Das IDoc wurde nicht angelegt.
Ein ALE-Szenario wurde konfiguriert. Sie kennen den Nachrichtentyp des Szenarios und das
Programm, mit dem die IDoc-Ausgangsverarbeitung ausgeführt wird. Im Sendersystem
wurde jedoch kein IDoc angelegt.
1.Analysieren Sie den Typ der Ausgangsverarbeitung.
Soll das IDoc über die Nachricht
ensteuerung angelegt werden? Sie können mit der
TransaktionWE64
die Nachrichtentypen für IDoc-Szenarien finden, die über die
Nachrichtensteuerung angelegt wurden.
Handelt es sich bei dem betreffenden Szenario um ein Stammdatenverteilungsszenario,
bei dem Änderungszeiger ausgewertet werden sollen? Sie können mit der Transaktion
SALENachrichtentypen für ALE-Szenarien, die mit Änderungszeigern arbeiten, finden,
indem SieIDoc-Schnittstelle / Application Link Enabling (ALE)→Geschäftsprozesse
modellieren und implementieren→Verteilung von Stammdaten
konfigurieren →Replikation von geänderten Daten einrichtenwählen. Wenn Sie für einen
Nachrichtentyp auf dieser Liste einen reduzierten Nachrichtentyp angelegt haben, der
sich nicht in dieser Liste befindet, dann gehen Sie wie folgt vor: Wählen Sie IDoc-
Schnittstelle / Application Link Enabling (ALE)→Geschäftsprozesse modellieren und
implementieren→Verteilung von Stammdaten konfigurieren →Umfang der zu
verteilenden Daten festlegen→Nachrichten reduzieren→Reduzierten Nachrichtentyp
erstellen(TransaktionBD53). Markieren Sie den reduzierten Nachrichtentyp, und wählen
SieÄnderungszeiger aktivieren.
Wenn das IDoc über die Nachrichtensteuerung angelegt werden soll, fahren Sie mit Schritt 2 fort. In einem Szenario, in dem Änderungszeiger ausgewertet werden sollen, fahren Sie mit Schritt 3 fort. In allen anderen Fällen können Sie direkt mit Schritt 4 fortfahren.
2.Stammdatenverteilung über das SMD-Tool.
Wurde ein Änderung
szeiger für den Änderungsbeleg gesetzt, dessen Daten in einem IDoc
verteilt werden sollen?
Wenn die Stammdaten seit der letzten Erstellung von IDocs aus Änderungszeigern
geändert wurden, sollten Änderungsbelege sowie Änderungszeiger vorliegen. Sie können
die Änderungsbelege mit dem Programm RSSCD100 anzeigen. Sie können die
Änderungszeiger in der Datenbanktabelle BDCPV prüfen.
Wurde das Programm RBDMIDOC gestartet?
In der Regel wird das Programm RBDMIDOC als regelmäßiger Hintergrundjob eingeplant.
Dieses Programm stößt die Erzeugung von IDocs aus Änderungszeigern an. Stellen Sie
sicher, dass der richtige Nachrichtentyp im Selektionsbild markiert ist. Prüfen Sie, ob der
Bericht mit der richtigen Variante eingeplant wurde und wann er zuletzt ausgeführt wurde.
Zu Testzwecken können Sie dieses Programm auch über die TransaktionBD21starten.
3.IDoc-Erzeugung über die Nachrichtensteuerung.
War die Nachrichtenfindung und -verarbeitung erfolgreich?
Lektion: Fehleranalyse und -behandlung
©Copyright. Alle Rechte vorbehalten. 115Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

122. Die Nachrichtenfindung ist in der Regel mit einem Anwendungsbeleg verknüpft, z.B. einer
Bestellung, einem Auftrag oder einer Rechnung. Rufen Sie in der Anzeige oder im
Änderungsmodus den Beleg auf, dessen Daten im IDoc-Format hätten gesendet werden
sollen, und prüfen Sie das Ergebnis der Nachrichtenfindung. In den meisten Belegen
können Sie diese Information über den MenüeintragSpringenoderZusätzeaufrufen. In
Einkaufsbelegen gibt es eine eigene DrucktasteNachrichten. Prüfen Sie, ob die Nachricht
gefunden wurde und ob sie erfolgreich verarbeitet wurde (grüne Ampel). In der Regel
können Sie außerdem aus den Details der Nachrichtenfindung ein Verarbeitungsprotokoll
zur Anzeige aufrufen.
Sind die Konditionssätze korrekt gepflegt?
Wenn die erwartete Nachricht im Beleg nicht gefunden wurde, prüfen Sie den Findungssatz (Konditionssatz) für die Nachrichtenart. Es ist möglich, dass für die Schlüsselkombination in dem Beleg kein passender Findungssatz vorhanden ist. Wenn Sie
mit der betroffenen Anwendung nicht vertraut sind, können Sie auch über die Transaktion
NACEnach Findungssätzen suchen. Wurde die Nachricht gefunden, aber nicht korrekt
verarbeitet, prüfen Sie das Sendemedium und den Sendezeitpunkt. Um IDocs zu generieren, muss das Sendemedium A (ALE) oder 6 (EDI) im Findungssatz eingetragen sein.
Existieren passende Partnervereinbarungen?
Rufen Sie die TransaktionWE20auf, oder wählen Sie
Werkzeuge→ALE→ Laufzeiteinstellungen→Partnervereinbarungen. Suchen Sie nach
dem Partner. In EDI-Szenarien muss der Partner für den Partnertyp LI (Lieferant) oder KU
(Kunde) und in ALE-Szenarien für den Partnertyp LS (logisches System) angelegt sein.
Prüfen Sie bei EDI-Szenarien immer auch die Partnerrolle. Stimmt sie mit der Partnerrolle
des Findungssatzes überein? Sind Ausgangsparameter zum jeweiligen Nachrichtentyp
angelegt worden? Sind die erforderlichen Daten in diesen Parametern erfasst
(Anwendung, Nachrichtentyp, Prozesscode)?
Wurde das Programm RSNAST00 gestartet?
Oft wird die Nachricht nicht sofort durch das Programm RSNAST00 verarbeitet, sondern
später durch einen Hintergrundjob oder eine anwendungsspezifische Transaktion. Das
Programm stößt die Erzeugung von IDocs aus Nachrichten in der Nachrichtensteuerung
an. Wenn der Sendezeitpunkt im Konditionssatz nicht 4, sondern 1, 2 oder 3 ist, muss das
Programm RSNAST00 in einem separaten Schritt gestartet werden.
4.Ist das Verteilungsmodell korrekt gepflegt?
Umfasst das Verteilungsmodell des Sendersystems eine Sicht mit dem erforderlichen Nachrichtentyp oder dem erforderlichen BAPI? Wenn Ihr Verteilungsmodell viele Sichten umfasst, können Sie auch den MenüeintragBearbeiten→
Anzeige filtern oder die
DrucktasteModellanzeige filtern nutzen, um eine Auswahl anhand des Nachrichtentyps
oder des Business-Objekttyps zu treffen. Falls erforderlich, fügen Sie die fehlende Sicht
oder Nachrichtentyp oder das fehlende BAPI im Pflegesystem hinzu, und übertragen oder
verteilen Sie diese Sicht an die betreffenden Systeme.
Ist die Modellsicht noch gültig?
Die Gültigkeit von Modellsichten ist beschränkt. Prüfen Sie bei Bedarf, ob Ihre Sichten
zum aktuellen Zeitpunkt noch genutzt werden können. Doppelklicken Sie dazu auf den
Namen der Modellsicht.
Sind für die Nachricht Filter über Filterobjekte definiert?
Kapitel 5: Überwachung der Datenverteilung, Fehlerbehandlung und Archivierung
©Copyright. Alle Rechte vorbehalten. 116Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

123. Prüfen Sie die betroffene Sicht in Ihrem Verteilungsmodell. Wenn Filterobjekte
eingetragen sind, müssen die für das Filterobjekt eingegebenen Werte mit den Werten
übereinstimmen, die mit dem IDoc aus der Anwendung übertragen wurden. Es ist möglich,
dass das Filterobjekt auf ein obligatorisches Segment im IDoc-Basistyp verweist. Wenn
die Bedingungen für die Feldwerte nicht erfüllt sind, wird kein Kommunikations-IDoc
angelegt.
Erfolgt die Filterung über die Klassifizierung? Ist die Klasse im Sendersystem dem
logischen System des Empfängers zugeordnet? Sind die zu verteilenden Stammdaten der Verteilungsklasse zugeordnet?
Überprüfen Sie im Verteilungsmodell, ob in der betreffenden Sicht eine Filtergruppe
angelegt ist. Ist das KennzeichenAbhängig von Klassenmitgliedschaftgesetzt, erfolgt die
Filterung über die Klassifizierung. Wählen Sie dann IDoc-Schnittstelle / Application Link
Enabling (ALE)→Geschäftsprozesse modellieren und implementieren→Verteilung von
Stammdaten konfigurieren →Verteilung über Klassen von Objekten einrichten→Klassen
dem empfangenden logischen System zuordnen. Überprüfen Sie bei Bedarf in den zu
verteilenden Stammdaten, ob die SichtKlassifizierung angelegt wurde und ob sie sich auf
die richtige Klasse bezieht.
Problem: Das IDoc wurde angelegt, aber nicht versendet
Ein ALE-Szenario wurde konfiguriert. Ein IDoc wurde im Sendersystem angelegt, aber nicht
versendet.
1.Die Ausgangspartnervereinbarung fehlt (Status 29).
Verw
enden Sie die TransaktionWE20, um zu prüfen, ob das Sendersystem eineAusgangspartnervereinbarung mit dem Empfängersystem für den betreffenden
Nachrichtentyp hat. Ist dies nicht der Fall, erzeugen Sie die fehlende Partnervereinbarung
aus der entsprechenden Sicht des Verteilungsmodells, und überprüfen Sie die
Einstellungen, oder legen Sie die Partnervereinbarung manuell an.
2.IDoc bleibt im Status 30.
Verw
enden Sie die TransaktionWE20, um im Sendersystem dieAusgangspartnervereinbarung mit dem Empfängersystem für den betreffenden
Nachrichtentyp zu überprüfen. Wenn der AusgabemodusIDocs sammelngewählt ist,
muss zunächst das ProgrammRSEOUT00ausgeführt werden. Überprüfen Sie, ob dieses
Programm als Job für die Hintergrundverarbeitung geplant ist und ob der betroffene
Nachrichtentyp in einer Variante eingeplant ist. Zu Testzwecken können Sie den Bericht
manuell starten oder das IDoc im Monitor markieren (TransaktionBD87) und das Senden
mit der DrucktasteAusführenanstoßen.
3.Fehler bei Datenübergabe an Port (Status 02).
Prüfen Sie im Kontrollsatz des IDocs, über welchen Port es versendet wurde. Rufen Sie
das IDoc zur Anzeige auf. Im BereichTechnische Kurzinfosehen Sie im FeldPortden
Namen des Ports, der mithilfe der Partnervereinbarung ermittelt wurde. Überprüfen Sie
die Attribute dieses Ports über die TransaktionWE21
. Wenn der Port falsch konfiguriert
wurde, können Sie diesen Fehler hier beheben und das IDoc erneut senden. Wenn dagegen ein falscher Port in der Partnervereinbarung eingetragen ist, korrigieren Sie die Partnervereinbarung. In bereits versendeten IDocs können Sie den Wert des Ports im Kontrollsatz manuell ändern. Doppelklicken Sie dazu auf den Kontrollsatz in der IDoc- Anzeige, und wählen SieKontrollsatz→Anzeigen→Ändern. Sie gelangen in den
Änderungsmodus. Wählen Sie die RegisterkartePartner, und tragen Sie im FeldPortden
richtigen Port ein. Anschließend können Sie das IDoc erneut versenden.
Lektion: Fehleranalyse und -behandlung
©Copyright. Alle Rechte vorbehalten. 117Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

124. Problem: Das IDoc wurde erfolgreich versendet, kam aber nicht im Empfängersystem an
Ein IDoc wurde über einen tRFC-Port an ein Empfängersystem versendet. Das IDoc hat den
Status 03 im Sendersystem, kam aber im Empfängersystem nicht an. Der Bericht
RBDMOIND führt nicht zu einer Statusänderung.
1.Aus der IDoc-Anzeige können Sie über die Objektverknüpfung prüfen, ob eine tRFC-ID eingegeben is
t. Wenn eine solche ID vorhanden ist, wurde das IDoc an die tRFC-Ebene
übertragen. Wenn eine DrucktasteAnzeigenerscheint, befindet sich das Datenpaket noch
in der tRFC-Queue. Mit dieser Drucktaste können Sie direkt in die tRFC-Queue navigieren (TransaktionSM58). Untersuchen Sie die Fehlermeldung zum entsprechenden Eintrag in
der tRFC-Queue.
Hinweis:
Eine mögliche Ursache könnten Berechtigungseinschränkungen des
Benutzers sein, der in der RFC-Destination eingetragen ist. Der Benutzer
könnte möglicherweise wegen mehrerer fehlerhafter Anmeldungen gesperrt
sein, oder in der RFC-Destination ist ein falsches Kennwort gespeichert.
Überprüfen Sie daher auch die RFC-Destination im Sendersystem und die
Berechtigungen des dort eingetragenen Benutzers im Empfängersystem.
Beachten Sie, dass in der Regel die RFC-Destination und der RFC-User von
verschiedenen Programmen verwendet werden. Eine Änderung der
Eigenschaften kann daher Einfluss auf andere ALE-Szenarios haben.
2.Wenn Sie den Fehler behoben haben, können Sie die Bearbeitung in der tRFC-Queue
manuell anstoßen: D
azu markieren Sie den Eintrag, und wählen SieBearbeiten→LUW
ausführen. Abhängig von den Einstellungen startet die RFC-Ebene diese Verarbeitung
automatisch nach einigen Minuten.
Hinweis:
Sie können die allgemeinen Einstellungen des tRFC über die Transaktion
SM58überprüfen. Wählen SieAusführen, um vom Selektionsbild zur Liste
zu springen, und wählen SieInformationen→Systemeinstellung, um zu
einem Dialogfenster mit den gewünschten Informationen zu navigieren. Sie
können diese Systemeinstellung in jeder RFC-Destination durch eine lokale
Einstellung überschreiben. Navigieren Sie zur Anzeige der RFC-Destination
(z.B. über die TransaktionSM59). Wählen Sie dortDestination→TRFC-
Optionen.
Problem: Das IDoc wurde vom Empfängersystem empfangen, aber nicht gebucht.
Ein IDoc wurde vom Empfängersystem empfangen, hat aber noch nicht den Status 53.
1.Die Eingangspartnervereinbarung fehlt (Status 56).
Wenn die Partner
vereinbarung laut Statustext fehlt, fügen Sie sie manuell hinzu, oder
lassen Sie sie vom System aus dem Verteilungsmodell generieren. Bei Bedarf können Sie
auch aus dem Kontrollsatz des fehlerhaften IDoc ermitteln, welches logische System der
Sender war.
2.Das IDoc bleibt im Status 64 (IDoc ist über gabebereit an die Anwendung).
Kapitel 5: Überwachung der Datenverteilung, Fehlerbehandlung und Archivierung
©Copyright. Alle Rechte vorbehalten. 118Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

125. Wenn die OptionAnstoß durch Hintergrundprogrammin der Partnervereinbarung gesetzt
ist, wird das IDoc in der Regel durch das Programm RBDAPP01 an die Anwendung
übertragen. Wählen SieSystem→Dienste→Jobs→Job-Übersicht, und geben Sie im
FeldABAP-Programmname RBDAPP01ein. Wählen SieAusführen. Sie erfahren, wann und
in welchen Intervallen das Programm als Hintergrundjob eingeplant wurde. Sie können es
zu Testzwecken manuell starten, oder Sie können das IDoc aus dem Statusmonitor direkt
an die Anwendung übertragen. Soll das IDoc immer sofort an die Anwendung übertragen
werden, so setzen Sie in der Partnervereinbarung das KennzeichenAnstoß sofort.
3.Das IDoc hat den Status 51.
Überprüfen Sie, ob im Langtext zur Fehlermeldung für den Status weitere Informationen
über die Fehlerursache vorliegen. Im Allgemeinen benötigen Sie für die Fehlersuche
Kenntnisse der Anwendung. Die folgenden technischen Fehler sind häufig Ursache für eine
fehlerhafte IDoc-Verarbeitung in der Anwendung:
●Falscher Vorgangscode in der Partnervereinbarung: Wenn der Statustext/Fehlertext
Kein Funktionsbaustein für Eingangsvorgangscode xylautet, so liegt ein falscher
Vorgangscode in der Partnervereinbarung vor.
●Fehlende Berechtigungen: Hat der RFC-User (bei sofortiger Verarbeitung) bzw. der
Batch-User (bei Hintergrundverarbeitung) die erforderlichen Berechtigungen?
Fehlerhafte IDocs mit dem Status 51 können nach der Fehlerbehebung verarbeitet
werden, indem Sie das Programm RBDMANI2 ausführen (manuelle Verarbeitung von
IDocs:Nicht gebuchte IDocs einbuchen). Dieses Programm kann als Hintergrundjob
eingeplant werden.
4.Es ist keine (aktive) Partnervereinbarung vorhanden (Status 63).
Sie haben die Möglichkeit, die Partnervereinbarung für einen Partner auf inaktiv zu setzen.
Überprüfen Sie im Empfängersystem die Partnervereinbarung mit dem Sendersystem,
geben Sie die TransaktionWE20ein, rufen Sie die Partnervereinbarungen zur Anzeige auf,
und wählen Sie auf der Kopfebene die Registerkarte
Klassifizierung . Wenn der
PartnerstatusIlautet, ist der Partner inaktiv. Sie können den Wert in A (Aktiv) ändern.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Fehleranalyse mithilfe des ALE-Statusmonitors durchführen
●Fehler in der IDoc-Verarbeitung beheben
Lektion: Fehleranalyse und -behandlung
©Copyright. Alle Rechte vorbehalten. 119Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

126. Kapitel 5
Lektion 3
SAP Workflow im ALE-Umfeld
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion lernen Sie, wie Sie den SAP Workflow für die IDoc-Eingangsverarbeitung,
Fehlerbehandlung und aktive Überwachung nutzen.
Unternehmensszenario
Sie haben in Ihrer Systemlandschaft ALE-Szenarien konfiguriert. Wenn Fehler auftreten, sollte
ein Administrator oder ein Mitarbeiter der Fachabteilung über den SAP Workflow informiert
werden.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Workflow-Einstellungen für die Fehlerbehandlung von IDocs prüfen
●Einstellungen zu Vorgangscodes nachvollziehen
●Das Benachrichtigungskonzept beschreiben
●Die IDoc-Verarbeitung über den SAP Workflow überwachen
Den SAP Workflow in ALE-Szenarien verwenden
Der SAP Workflow ist ein Werkzeug zur Automatisierung von Geschäftsprozessen innerhalb
eines SAP-Systems, aber auch über Systemgrenzen hinweg. Er ist nicht mit bestimmten
Anwendungen verknüpft, sondern funktioniert unabhängig in allen Anwendungen. Das
Hauptziel besteht darin, dem richtigen Bearbeiter zum richtigen Zeitpunkt eine Aufgabe
bereitzustellen.
In ALE-Szenarien können Sie die Funktionen des SAP Workflow für die IDoc-
Eingangsverarbeitung als Alternative zu Eingangs-Funktionsbausteinen, zur Überwachung der Eingangs- und Ausgangs-IDocs im laufenden Betrieb und für die Verarbeitung fehlerhafter IDocs verwenden.
IDoc-Eingangsverarbeitung über SAP Workflow
Ein Vorgangscode für die IDoc-Eingangsverarbeitung kann auf eine Aufgabe oder einen
Workflow verweisen.
©Copyright. Alle Rechte vorbehalten. 120Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

127. Abbildung 109: IDoc-Eingangsverarbeitung über einen Workflow
Für das Eingangs-IDoc kann über einen Vorgangscode ein Workflow gestartet werden. Einen
solchen Workflow können Sie frei definieren und dem gewünschten Vorgangscode zuordnen.
Beispiele für die Nutzung solcher Workflows sind:
●Sie möchten einen Anwendungsbeleg automatisch aus dem IDoc erzeugen. Anschließend
soll der Anwendungsbeleg zur Überprüfung an einen Mitarbeiter übertragen werden.
●Das IDoc soll geprüft und gegebenenfalls geändert werden, bevor der Anwendungsbeleg
erzeugt wird. In diesem Fall wird das IDoc bearbeitet, und nicht der Anwendungsbeleg.
●Das IDoc oder der Anwendungsbeleg soll an einen oder mehrere Bearbeiter weitergeleitet
werden.
●Neue (Ausgangs-)IDocs sollen auf Basis des Eingangs-IDocs gesendet werden.
●Der Empfang eines IDocs soll eine andere Aktion auslösen.
Ein Beispiel für eine Workflow-basierte IDoc-Eingangsverarbeitung finden Sie im ALE-
Szenario „Umlagerung zwischen verteilten Systemen“. Für den Regelfall der Eingangsverarbeitung von IDocs mit Bestelldaten ist der Vorgangscode ORDE vorgesehen, dem ein Funktionsbaustein für die Datenübertragung an die Anwendung zugeordnet ist. In bestimmten Fällen soll der Auftrag jedoch nicht automatisch im Empfängersystem, sondern erst nach der Prüfung der Bestelldaten durch einen Mitarbeiter der Fachabteilung angelegt werden. Für solche Fälle steht der Vorgangscode ORDE_BY_WORKFLOW zur Verfügung, der
auf einen Workflow und nicht auf einen Funktionsbaustein verweist. Auf diese Weise kann die
IDoc-Eingangsverarbeitung interaktiv erfolgen. Der Mitarbeiter kann nicht nur die Daten prüfen, sondern auch Änderungen vornehmen.
IDoc-Überwachung mit Workflow-Anbindung
Die aktive Überwachung von Eingangs- und Ausgangs-IDocs wird in der Regel als periodischer Hintergrundjob eingeplant. Die Überwachung wertet aus, ob die Anzahl der IDocs mit einem
bestimmten Status einen zuvor definierten Schwellenwert überschreitet. Während des
Selektionslaufs werden IDocs, die die Selektionskriterien erfüllen, ausgewertet. Wenn der aktuelle Statuswert eines IDoc dem Status im Selektionsbild entspricht, wird dieses IDoc als kritisch bewertet. Wenn die Anzahl der kritischen IDocs den eingegebenen Schwellenwert überschreitet, wird diese Situation als kritisch bewertet, und es wird automatisch eine
Lektion: SAP Workflow im ALE-Umfeld
©Copyright. Alle Rechte vorbehalten. 121Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

128. Statusrückmeldung angestoßen. Die AufgabeActiveIDocMonitoring(TS4508518) wird
gestartet, und es wird ein Workitem an den ermittelten Empfänger versendet.
Mithilfe des Programms RSEIDOCA können Sie die aktive Überwachung durchführen. Zu
diesem Zweck müssen Sie eine Variante definieren (Menüpfad: Werkzeuge→ALE→ ALE-
Administration→Dienste→Periodische Arbeiten→Aktive IDoc-Überwachung mit Workflow-
Anbindung einplanen).
Fehlerbehandlung mit SAP Workflow
Die Ausnahmen- und Fehlerbehandlung im ALE-Umfeld erfolgt immer über einen Workflow.
Im Falle einer Ausnahme werden ein oder mehrere Bearbeiter per Workitem über die
Fehlersituation informiert, und das betreffende IDoc wird ihnen bereitgestellt.
Abbildung 110: Fehlerbehandlung mit Workflow
Die jeweiligen zuständigen Bearbeiter werden in den Partnervereinbarungen bzw. in den
Einstellungen zur IDoc-Administration eingetragen. Die generell möglichen Bearbeiter werden
in der Aufgabendefinition eingegeben. Wenn in Ihrem Unternehmen ein Organisationsmodell
gepflegt wird, können Sie neben Benutzern auch Planstellen oder Organisationseinheiten als
Bearbeiter zuordnen (siehe unten).
Hinter den Ausnahmebehandlungen der IDoc-Schnittstelle, die von der SAP ausgeliefert
werden, liegen einzelne Aufgaben vor. Sie werden über die Vorgangscodes der
Fehlerbehandlung gestartet. Diese Vorgangscodes werden in
System-undStatus-
Vorgangscodes unterteilt.
Wenn Sie das Eilkennzeichen in den Detaileinstellungen eines Vorgangscodes setzen,
erhalten die Bearbeiter der jeweiligen Aufgabe unmittelbar eine Eilmeldung auf ihrem
Bildschirm, wenn sich ein neues Workitem in ihrem Posteingang befindet.
Die Abbildung zeigt die Ausnahmebehandlung im IDoc-Ausgang:
Kapitel 5: Überwachung der Datenverteilung, Fehlerbehandlung und Archivierung
©Copyright. Alle Rechte vorbehalten. 122Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

129. Abbildung 111: Vorgangscodes für Fehler im Ausgangs-IDoc
●Der VorgangscodeEDIMgilt für Ausgangs- und Eingangsverarbeitung. Er gilt, wenn das
Anlegen eines IDocs noch nicht möglich war.
●EDINdient der Ausgangsverarbeitung über die Nachrichtensteuerung: Sie können mithilfe
des NAST-Satzes aus dem Workitem in den Anwendungsbeleg verzweigen.
●EDIOreagiert auf ein Ausgangs-IDoc, für das ein allgemeiner Verarbeitungsfehler
aufgetr
eten ist.
●
EDIXreagiert auf ein Ausgangs-IDoc, für das ein Syntaxfehler aufgetreten ist.
●EDIPreagiert auf einen IDoc-Stack (Batch-Prozess des Berichts RSEOUT00), für den ein
Verarbeitungsfehler vorliegt, der alle IDocs im gleichen Maße betrifft (Beispiel: ein nicht
vorhandener Port). Das beim Starten der zugehörigen Aufgabe gesendete Workitem
ermöglicht Ihnen, den Fehler zu korrigieren und die Verarbeitung des IDoc-Stacks erneut
anzustoßen.
●Wenn vom externen System ein Fehlerstatus bestätigt wird, wird über den
Statusvorgangscode
EDISauch eine Aufgabe für die Fehlerbehandlung gestartet. Über
den StatusvorgangscodeEDIRkönnen Sie zusätzlich noch einmal die
Ausg
angsverarbeitung auslösen, nachdem Sie den Fehler behoben haben.
Hinweis:
Der VorgangscodeEDIRist in SAP R/3 4.6A neu. Er ersetzt den
Vorg
angscode
EDIS. Bei einem Upgrade müssen Sie den Wechsel zuEDIR
explizit im IMG durchführen.
Sie können zusätzliche Ausnahmebehandlungen für die Statusrückmeldung definieren und
diese über Vorgangscodes identifizieren.
Lektion: SAP Workflow im ALE-Umfeld
©Copyright. Alle Rechte vorbehalten. 123Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

130. Die Eingangs-Ausnahmebehandlung entspricht der Ausgangs-Ausnahmebehandlung. Über
entsprechende Vorgangscodes werden Aufgaben gestartet, für die ein Workitem an die
ermittelten Bearbeiter gesendet wird.
Abbildung 112: Vorgangscodes für Fehler im Eingangs-IDoc
●Wie in der Ausgangsverarbeitung gilt der VorgangscodeEDIM, wenn das Anlegen eines
IDocs nicht möglich war
.
●
EDIIundEDIYentsprechen den AusgangsvorgangscodesEDIOundEDIX.
●Sie können über den IDoc-T
yp
TXTRAW01Nachrichten Ihrer Wahl im Textformat
versenden. Diese Technik wird z.B. verwendet, wenn eine Ausnahme im externen System
aufgetreten ist und das SAP-System über diese Ausnahme informiert werden soll.
●Wenn eine Statusdatei des externen Systems nicht gelesen werden konnte, wird der
Vorgangscode
EDILaktiv. In der Ausnahmebehandlung wird die Fehlermeldung des SAP-
Sys
tems angezeigt wird.
Wenn bei der Buchung der Anwendungsbelege Fehler auftreten (beispielsweise weil die Customizing-Einstellungen nicht synchron sind), wird für die Fehlerbehandlung eine andere
Methode eingesetzt. Statt der relativ unflexiblen Reaktion über Vorgangscodes verwendet die
Anwendung das flexiblere Ereigniskonzept. Im Falle einer Ausnahme wird ein Ereignis
angestoßen, das 1 bis n Aufgaben starten und entsprechende Workitems versenden kann.
Notiz:
Die von der SAP ausgelieferten Aufgaben für Fehler bei der Buchung in der
Anwendung tragen meist das Namenssuffix error– zum BeispielMATMAS_error
oderORDERS_error. Für von BAPI-Aufrufen angelegte IDocs wird im Falle eines
Fehlers die von der SAP bereitgestellte AufgabeIDOC_APPL_Er(TS20000051)
verwendet. Diese Aufgabe wird auch über ein Ereignis gestartet.
Alle ausgewählten Bearbeiter erhalten nun die Benachrichtigung als Workitem (als konkrete
Instanz der Workflow-Aufgabe) in ihrem integrierten Posteingang. Reparaturen und die
weitere Bearbeitung des Workitems mit Fehlern sind nur aus diesem Posteingang möglich.
Kapitel 5: Überwachung der Datenverteilung, Fehlerbehandlung und Archivierung
©Copyright. Alle Rechte vorbehalten. 124Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

131. Berechtigungskonzept
Im Falle einer Ausnahme wird eine Aufgabe über einen Vorgangscode gestartet. Ein Workitem
wird dabei als eine Instanz dieser Aufgabe angelegt. Um den richtigen Bearbeiter für das
Workitem zu ermitteln, benötigt das System zwei Mengen von Bearbeitern, die möglichen und
die erlaubten Bearbeiter. Die Schnittmenge dieser Mengen filtert die Empfänger des
Workitems heraus.
Abbildung 113: Die Workitem-Bearbeiter ermitteln
In jeder Partnervereinbarung für ALE- oder EDI-Szenarien müssen Sie dem Partner einen
erlaubten Bearbeiter für die Fehler- und Ausnahmebehandlung zuordnen. Außerdem können
Sie für jeden Nachrichtentyp einen erlaubten Bearbeiter eingeben, der von diesem
übergeordneten Bearbeiter abweicht. Im Falle eines Fehlers (beispielsweise eines Eingangs-
IDocs mit einem Syntaxfehler) versucht das System zunächst, einen Bearbeiter für die
Kombination aus Partner und Nachrichtentyp zu ermitteln. Wenn für den Nachrichtentyp mit
dem Fehler kein bestimmter Bearbeiter vorhanden ist, wird der dem Partner zugeordnete
Bearbeiter benachrichtigt. Liegen keine Partnervereinbarungen mit dem Partner vor, so
versucht das System, den IDoc-Administrator zu ermitteln. Daher sollten Sie für Situationen,
in denen das System keine Partnervereinbarungen findet, in den allgemeinen Einstellungen
für die IDoc-Administration einen Bearbeiter bestimmen, sodass beim Auftreten eines Fehlers ein Mitarbeiter benachrichtigt wird. Rufen Sie hierzu die TransaktionSALEauf, und wählen Sie
IDoc-Schnittstelle / Application Link Enabling (ALE)→Grundeinstellungen→IDoc
Administration.
Lektion: SAP Workflow im ALE-Umfeld
©Copyright. Alle Rechte vorbehalten. 125Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

132. Abbildung 114: Bearbeitersuche im ALE-Umfeld
Wenn eine Aufgabe gestartet wird, wird eine für die Aufgabe eingegebene Regel verwendet,
um die Gruppe möglicher Bearbeiter anhand der Aufgabendefinition zu ermitteln. Dann
ermittelt das System die Schnittmenge der möglichen und erlaubten Bearbeiter anhand der
Partnervereinbarungen und der IDoc-Administration. Alle erlaubten Bearbeiter erhalten das
Workitem für die Aufgabe. Das Workitem wird in den Posteingang des SAP Business
Workplace des Empfängers gelegt. Über das Workitem hat er direkten Zugriff auf das
fehlerhafte IDoc und kann sofort mit der Fehlerbearbeitung beginnen.
Die Aufgaben der IDoc-Fehlerbehandlung werden in SAP R/3 bzw. SAP ECC im Workflow-
Customizing (TransaktionSWU3) als allgemeine Aufgaben klassifiziert. Mit dieser Einstellung
ist jeder Benutzer ein möglicher Bearbeiter, und alle erlaubten Bearbeiter erhalten das Workitem. Wenn es für ein Workitem mehrere Empfänger gibt, wird das Workitem aus dem Posteingang der anderen Empfänger gelöscht, sobald der erste Bearbeiter darauf zugreift.
Sie können Benutzer oder Elemente des Organisationsmanagements, wie z.B. Planstellen
oder Organisationseinheiten, als erlaubte Bearbeiter eingeben. Die Verwendung der Elemente
des Organisationsmanagements erhöht die Flexibilität bei organisatorischen Änderungen.
Pflege einer Organisationsstruktur
Im automatischen Workflow-Customizing (Transaktion SWU3) gelten die von der SAP
bereitgestellten Workflows für die IDoc-Verarbeitung, die sich in der Aufgabengruppe
TG74500044 befinden, als allgemein. Sie können also von allen Benutzern bearbeitet werden.
Die Einschränkung auf die für IDoc-Fehler zuständigen Bearbeiter erfolgt durch eine Überschneidung mit den erlaubten Bearbeitern für die IDoc-Schnittstelle (siehe oben).
Kapitel 5: Überwachung der Datenverteilung, Fehlerbehandlung und Archivierung
©Copyright. Alle Rechte vorbehalten. 126Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

133. Abbildung 115: Organisationsstruktur
Wenn Sie Elemente eines Organisationsmodells verwenden, um die erlaubten Bearbeiter zu
definieren, können Sie beispielsweise der entsprechenden Ebene eine ganze
Bearbeitergruppe zuordnen, indem Sie eine entsprechend besetzte Organisationseinheit oder
Planstelle eingeben. Sie können auch zentral in der Pflege des Organisationsmodells über eine
einfache Neuzuordnung zur organisatorischen Zuständigkeit wechseln. Dies erspart Ihnen
den Aufwand, alle Ebenen der IDoc-Schnittstelle zu durchsuchen.
Notiz:
Die Verwendung solcher Organisationsmodelle ist unabhängig von der
Verwendung der Anwendung mySAP ERP Human Capital Management. Das
Basissystem stellt allen Mitarbeitern das erforderliche Werkzeug (einfache Pflege
des Organisationsmanagements – Transaktionen PPOC, PPOM, PPOS) zur
Verfügung.
In der einfachen Pflege erstellen Sie die hierarchische Struktur Ihres Organisationsmodells,
ausgehend von der Wurzelorganisationseinheit. In einem weiteren Schritt legen Sie die
gewünschten Planstellen an und ordnen diese den gewünschten Organisationseinheiten zu.
Im letzten Schritt ordnen Sie den Planstellen Benutzer als Planstelleninhaber zu.
Workitems im SAP Business Workplace verarbeiten
Der SAP Business Workplace integriert Workflowfunktionen in allgemeine Bürofunktionen.
Dort erhalten Sie zusammen mit Workitems auch E-Mails, Belege und Fristnachrichten. Die
Bearbeiter erhalten die für sie vorgesehenen Workitems im Posteingang ihres Business
Workplace. Sie gelangen mit der TransaktionSBWPzum Business Workplace.
Lektion: SAP Workflow im ALE-Umfeld
©Copyright. Alle Rechte vorbehalten. 127Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

134. Abbildung 116: SAP Business Workplace
Dort wählen Sie den OrdnerEingangund den BereichWorkflow , um zur Arbeitsvorratsanzeige
zu gelangen. Sie sehen nun alle aktiven Workitems. Per Doppelklick starten Sie die
Ausführung des ausgewählten Workitems. Wenn einer der Empfänger das Workitem auf diese
Weise zur Verarbeitung aufgerufen hat, wird es aus dem Posteingang der anderen Empfänger
gelöscht.
Wenn in den Einstellungen für die Vorgangscodes ein Eilkennzeichen gesetzt ist, erhalten die
Empfänger der Workitems unabhängig von ihrem derzeitigen Aufenthalt im SAP-System eine
Eilbenachrichtigung. Aus der Eilbenachrichtigung können sie dann direkt in ihren Business
Workplace navigieren und schnell reagieren.
Werkzeuge der Workflow-Administration
Beim Arbeiten mit Workflowunterstützung können Sie bei Bedarf auch die Werkzeuge der
Workflow-Administration verwenden – beispielsweise wenn ein Workitem einen falschen
Status hat und Sie den Workflow nach Beseitigung der Fehlerursache neu starten möchten
oder wenn ein Workitem keinen Empfänger hat und der Administrator, der es findet, es selbst
bearbeiten oder an den tatsächlichen Verantwortlichen weiterleiten soll. Sie können ebenfalls direkt nach Workitems suchen, deren Frist überschritten wurde.
Workitems, die innerhalb der IDoc-Ausnahmebehandlung angelegt wurden, sind kritisch.
Daher benötigen Sie Werkzeuge, um technische oder organisatorische Fehler schnell
erkennen und beheben zu können. Die am häufigsten verwendeten Werkzeuge sind die
folgenden Transaktionen:
●TransaktionSWI1(Selektionsreport für Workitems) zur Ermittlung fehlerhafter Workitems
●TransaktionSWPR(Workflow-Restart nach Fehler ) für den Neustart eines fehlerhaften
Workitems nach der Fehlerbehebung
●TransaktionSWI2_DEAD(Workitems mit Fristablauf) zum Auffinden von Workitems mit
überschrittenen Terminen
●TransaktionSWI2_ADM1(Workitems ohne Bearbeiter) zum Auffinden von Workitems ohne
Empfänger
Kapitel 5: Überwachung der Datenverteilung, Fehlerbehandlung und Archivierung
©Copyright. Alle Rechte vorbehalten. 128Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

135. Die genannten Transaktionen dienen dem Auffinden von Workitems für bestimmte Aufgaben,
sodass Sie IDoc-relevante Workitems finden können. Sie können dann aus dem gefundenen
Workitem zur IDoc-Anzeige verzweigen.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Workflow-Einstellungen für die Fehlerbehandlung von IDocs prüfen
●Einstellungen zu Vorgangscodes nachvollziehen
●Das Benachrichtigungskonzept beschreiben
●Die IDoc-Verarbeitung über den SAP Workflow überwachen
Lektion: SAP Workflow im ALE-Umfeld
©Copyright. Alle Rechte vorbehalten. 129Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

136. Kapitel 5
Lektion 4
IDocs archivieren
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion lernen Sie, wie Sie IDocs über die Transaktion SARA archivieren und welche
Optionen für die Anzeige archivierter IDocs vorhanden sind. Weitere Möglichkeiten für die
Reorganisation im IDoc-Umfeld werden ebenfalls gezeigt.
Unternehmensszenario
Sie haben verschiedene ALE-Szenarien eingerichtet und möchten die IDocs, die erfolgreich
verarbeitet wurden, archivieren. Sie möchten außerdem Einträge für IDoc-Verbindungen und
verarbeitete Änderungszeiger aus der Datenbanktabelle löschen.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Das Verfahren der IDoc-Archivierung beschreiben
●Die archivierbaren Status im System setzen
IDocs archivieren
IDocs können nicht direkt aus der Datenbank gelöscht werden, sondern nur innerhalb des
Datenarchivierungsprozesses. Die Datenarchivierung erfolgt beim Schreiben der
Archivdateien für die zur Archivierung ausgewählten IDocs und beim Löschen der
entsprechenden Datenbankeinträge.
Abbildung 117: IDocs archivieren – erster Schritt: Archivdateien schreiben
©Copyright. Alle Rechte vorbehalten. 130Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

137. Die Archivierung erfolgt über ein Archivierungsobjekt, das alle Funktionen für die Archivierung
eines Business-Objekts bereitstellt, insbesondere die erforderlichen Schreib- und
Löschprogramme. Das Archivierungsobjekt für die Archivierung von IDocs wird IDOC
genannt.
Nach dem Einstellen der gewünschten Customizing-Optionen können Sie mit der Transaktion
SARAdie Datenarchivierung mit dem Archivierungsobjekt IDOC starten, indem Sie eine
Variante des Schreibprogramms mit den gewünschten Selektionswerten anlegen, die
Startdaten und die Spoolparameter pflegen und die Ausführung starten.
Je nach der Customizing-Einstellung wird der zweite Schritt der Datenarchivierung – die
Löschung der entsprechenden Datenbankeinträge – entweder automatisch direkt nach dem
Schreiblauf ausgeführt oder manuell über die TransaktionSARAgestartet.
Abbildung 118: IDocs archivieren – zweiter Schritt: IDocs aus der Datenbank löschen
Bei der Selektion für den Löschlauf können Sie nur bereits geschriebene Archivdateien
auswählen. Dadurch wird sichergestellt, dass keine Daten in der Datenbank gelöscht werden,
für die noch keine Archivdateien existieren. Außerdem pflegen Sie hier den Starttermin und
die Spoolparameter und starten die Ausführung. Über die TransaktionSARAkönnen Sie direkt
in die Jobübersicht navigieren und das Protokoll für den jeweiligen Lauf dort anzeigen. Die eigentliche Archivierung ist abgeschlossen, wenn der Löschlauf beendet ist.
Sie können die archivierten IDocs mit der TransaktionWE09anzeigen. Sie können sie jedoch
auch zur Anzeige mit den Archivinformationssystem aufrufen (TransaktionSARI). Eine
Voraussetzung hierfür ist eine aktive Archivinformationsstruktur, die Sie entweder implizit mit
dem Löschlauf oder explizit mit der TransaktionSARIausgefüllt haben.
Notiz:
In einem SAP-R/3- oder SAP-ECC-System steht zu diesem Zweck die
Archivinformationsstruktur SAP_IDOC_001 zur Verfügung. Sie können jedoch
auch benutzerdefinierte Archivinformationsstrukturen auf der Grundlage des
Feldkatalogs mit dem gleichen Namen anlegen.
Lektion: IDocs archivieren
©Copyright. Alle Rechte vorbehalten. 131Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

138. Kriterium für die Archivierbarkeit: IDoc-Status
Der IDoc-Status ist das einzige Archivierbarkeitskriterium, welches das Schreibprogramm für
das Archivierungsobjekt IDOC prüft. Sie können mit der TransaktionWE47die als archivierbar
gekennzeichneten IDoc-Status anzeigen.
Abbildung 119: Statuspflege – Archivierung
Die Abbildungen „Archivierbare Statuswerte in der Ausgangsverarbeitung“ und
„Archivierbare Statuswerte in der Eingangsverarbeitung“ bieten Ihnen einen Überblick über
die Standardeinstellungen für archivierbare IDocs sowohl in der Ausgangs- als auch in der
Eingangsverarbeitung.
Abbildung 120: Archivierbare Statuswerte in der Ausgangsverarbeitung
Kapitel 5: Überwachung der Datenverteilung, Fehlerbehandlung und Archivierung
©Copyright. Alle Rechte vorbehalten. 132Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

139. Sie können die Bedeutung der einzelnen Status direkt in der TransaktionWE47in der
Detailsicht des Status oder in der TransaktionBD87in der Eingabehilfe für das FeldStatus
ermitteln.
Die folgenden Statuswerte sind in der Ausgangsverarbeitung als archivierbar gekennzeichnet:
03 Datenübergabe an Port OK
12 Versand OK
31 Fehler, keine weitere Bearbeitung
39 IDoc im Zielsystem (ALE-Dienst)
40 Anwendungsbeleg im Zielsystem nicht erzeugt
41 Anwendungsbeleg im Zielsystem angelegt
Manchmal müssen diese Standardeinstellungen geändert werden, beispielsweise wenn Sie
für alle Nachrichtentypen ein ALE-Audit einrichten und Status 03 kein endgültiger Statuswert
ist.
Wenn ein Fehler auftritt, der nicht korrigiert werden kann (oder sollte), können Sie die IDocs
von einem beliebigen Status mit Fehlern zu Status 31 (Fehler, keine weitere Bearbeitung)
übertragen und dann archivieren.
Für die Übertragung eines fehlerhaften IDocs zu Status 31 gehen Sie wie folgt vor: In der
TransaktionBD87markieren Sie den Eintrag mit dem fehlerhaften IDoc. Wählen Sie
Bearbeiten→Einschränken und verarbeiten, und entfernen Sie das Kennzeichen
Hintergrundverarbeitung. Wählen Sie auf dem nächsten BildLöschvormerkung, und
bestätigen Sie die Sicherheitsabfrage mit derEingabetaste.
Abbildung 121: Archivierbare Statuswerte in der Eingangsverarbeitung
Die folgenden Statuswerte sind in der Eingangsverarbeitung als archivierbar gekennzeichnet:
Lektion: IDocs archivieren
©Copyright. Alle Rechte vorbehalten. 133Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

140. 53 Anwendungsbeleg gebucht
68 Fehler, keine weitere Bearbeitung
Verknüpfungen mit IDocs löschen
Möglicherweise bestehen Verknüpfungen zwischen IDocs und anderen Objekten. Im
Statusmonitor (TransaktionBD87) können Sie diese Verknüpfungsbeziehungen anzeigen.
Beispielsweise kann ein Ausgangs-IDoc mit einem Eingangs-IDoc, einem editierten IDoc oder
einem Anwendungsbeleg verknüpft sein.
Wenn die Anzahl der IDocs steigt, vergrößert sich nicht nur die Tabelle der Datensätze. Die
Tabellen, in denen die Verknüpfungen aktualisiert werden, vergrößern sich ebenfalls, sodass
veraltete Einträge ab und zu daraus gelöscht werden sollten. Seit SAP R/3 4.6B steht das
Programm RSDLDREL zur Verfügung. Mit diesem Programm können Sie in der Tabelle
IDOCREL abgelegte Anwendungsverknüpfungen löschen. Im Gegensatz zum
Archivierungsprozess sind diese damit für immer verloren. Seit Application Server 6.20
können die Verknüpfungen bei der Archivierung von IDocs mit archiviert werden. Seit
Application Server 6.40 werden die Verknüpfungen automatisch zusammen mit den IDocs
archiviert. Wenn Sie die Verknüpfungen nicht mehr benötigen, können Sie diese Daten vor der
Archivierung dennoch mit dem Programm RSRLDREL löschen.
Änderungszeiger reorganisieren
Wenn Sie zum Anlegen zahlreicher IDocs den Änderungszeigermechanismus nutzen, füllen
Sie die entsprechenden Datenbanktabellen. Da Änderungszeiger nach ihrer Verarbeitung
veraltet sind, sollten Sie nicht mehr benötigte Tabelleneinträge regelmäßig löschen. Hierzu
wird das Programm RBDCPCLR zur Verfügung gestellt. Sie können dieses Programm über die
TransaktionBD22aufrufen. Es löscht Änderungszeigereinträge aus den Datenbanktabellen.
Sie können veraltete und/oder verarbeitete Änderungszeiger auswählen. Die Auswahl kann
auch über das Datum und die Uhrzeit erfolgen. Sie können vorab eine Liste der im Testmodus
ausgewählten Änderungszeigereinträge anzeigen. Veraltete Änderungszeiger sind diejenigen,
die vor dem von Ihnen im Selektionsbild angegebenen Datum und der angegebenen Uhrzeit
angelegt wurden. Die von Ihnen als veraltet ausgewählten Änderungszeiger werden
unabhängig davon, ob sie bereits verarbeitet wurden oder nicht, gelöscht.
Verarbeitete Änderungszeiger sind diejenigen, die vor dem von Ihnen im Selektionsbild
angegebenen Datum und der angegebenen Uhrzeit verarbeitet wurden. Daher werden nur die
bereits verarbeiteten Änderungszeiger gelöscht.
*Diese moderierte Diskussion wurde aus rein formellen Gründen in die Lektion aufgenommen.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Das Verfahren der IDoc-Archivierung beschreiben
●Die archivierbaren Status im System setzen
Kapitel 5: Überwachung der Datenverteilung, Fehlerbehandlung und Archivierung
©Copyright. Alle Rechte vorbehalten. 134Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

141. KAPITEL 6Anhang
Lektion 1
Logische Systeme umbenennen 136
Lektion 2
Wiederherstellung von IDocs nach einem Datenbankfehler 140
LERNZIELE
●Die richtige Vorgehensweise zum Ändern von logischen Systemnamen erläutern
●Das Verfahren zur Wiederherstellung von IDocs und die für diese Funktion erforderlichen
Einstellungen beschreiben
©Copyright. Alle Rechte vorbehalten. 135Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

142. Kapitel 6
Lektion 1
Logische Systeme umbenennen
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion wird erläutert, warum es problematisch ist, logische Systeme
umzubenennen, und wie logische Systemnamen bei Bedarf geändert werden können.
Unternehmensszenario
Beim Einrichten eines SAP-Systems haben Sie einen Namen verwendet, der nicht mehr den
aktuellen Namenskonventionen entspricht. Daher möchten Sie prüfen, ob es möglich ist, den
logischen Systemnamen nun zu ändern, und welche Vorgehensweise dabei die beste ist.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Die richtige Vorgehensweise zum Ändern von logischen Systemnamen erläutern
Logische Systeme umbenennen
Logische Systeme haben einen technischen Namen, der bis zu 10 Zeichen lang ist, und einen
erklärenden Kurztext. Logische Systeme werden in einer Customizing-Aktivität von ALE
definiert. Seit SAP R/3 4.5A erfordern bestimmte Anwendungen die Zuordnung eines
logischen Systemnamens für den Mandanten.
Abbildung 122: Logische Systeme
©Copyright. Alle Rechte vorbehalten. 136Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

143. Anwendungsbelege, bei denen das FeldLogisches Systemleer geblieben ist oder die mit dem
aktuellen logischen Systemnamen Ihres Mandanten gesichert wurden, werden vom
Mandanten als lokale Belege interpretiert.
Wenn der logische Systemname eines Mandanten geändert wird, kann die Modellierung des
ALE-Nachrichtenflusses unter Umständen inkonsistent werden. Vor der Änderung des
logischen Systemnamens angelegte Anwendungsbelege werden nach der Änderung als
externe Belege klassifiziert und können deshalb oft nicht mehr aufgefunden werden.
ALE bietet ein Werkzeug zur Umbenennung von logischen Systemen in Anwendungstabellen:
die TransaktionBDLS.
Abbildung 123: Umsetzung von logischen Systemnamen
Mandanten- und Datenbankkopien werden häufig verwendet, um eine Entwicklungs- und
Testlandschaft einzurichten. Wenn Benutzer zentral verwaltet werden, müssen die
teilnehmenden logischen Systeme eindeutige Namen tragen. In einem unabhängigen SAP-
System können beliebige logische Systemnamen zugeordnet werden.
Achtung:
Es wird ausdrücklich davon abgeraten, logische Systemnamen in
Produktivsystemen zu ändern, da dies zu Datenverlusten und Dateninkonsistenz
führen kann.
Lektion: Logische Systeme umbenennen
©Copyright. Alle Rechte vorbehalten. 137Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

144. Abbildung 124: Worin liegt das Problem?
Abbildung 125: Wie werden logische Systemnamen geändert?
Informationen zum Ändern des logischen Systemnamens eines Mandanten finden Sie in der
SAP-Bibliothek oder im Customizing in ALE unterIDoc-Schnittstelle / Application Link
Enabling (ALE)→Grundeinstellungen→Logische Systeme einrichten→Logische
Systemnamen in Anwendungstabellen umsetzen.
Kapitel 6: Anhang
©Copyright. Alle Rechte vorbehalten. 138Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

145. Notiz:
Eine entsprechende Berechtigung ist für die Ausführung des Programms
erforderlich (Berechtigungsobjekt B_ALE_LSYS).
Wir empfehlen, die Umsetzung im Testmodus zu starten. Wenn Sie das KennzeichenTestlauf
setzen, werden alle relevanten Tabellen analysiert und die Anzahl der Einträge in den Tabellen
ermittelt. Diese werden dann in einer Liste ausgegeben. Wenn der neue logische Systemname
bereits in den relevanten Tabellen vorhanden ist, werden Sie gefragt, ob die Umsetzung
fortgeführt werden soll oder nicht. Prüfen Sie die Tabelle, in der dieser logische Systemname
gefunden wurde, und ermitteln Sie, ob Sie die Umsetzung dieser Einträge ausführen möchten.
Wenn Sie diese Einträge nicht umsetzen möchten, brechen Sie die Konvertierung ab.
Abbildung 126: Umsetzung – zu beachtende Punkte:
*Diese moderierte Diskussion wurde aus rein formellen Gründen in die Lektion aufgenommen.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Die richtige Vorgehensweise zum Ändern von logischen Systemnamen erläutern
Lektion: Logische Systeme umbenennen
©Copyright. Alle Rechte vorbehalten. 139Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

146. Kapitel 6
Lektion 2
Wiederherstellung von IDocs nach einem
Datenbankfehler
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion erfahren Sie, wann und wie Sie die Funktionen für die IDoc-
Wiederherstellung verwenden.
Unternehmensszenario
Bei einer IDoc-Übertragung ist die Datenbank des empfangenden Systems abgestürzt. Sie
möchten mit der IDoc-Wiederherstellung die Übertragung aller IDocs, die nicht in der
Datenbank des empfangenden Systems gesichert werden konnten, erneut starten.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Das Verfahren zur Wiederherstellung von IDocs und die für diese Funktion erforderlichen
Einstellungen beschreiben
Wiederherstellung von IDocs nach einem Datenbankfehler
Abbildung 127: Wiederherstellung von IDocs nach einem Datenbankfehler
Die IDoc-Wiederherstellung verwendet zwei Transaktionen:
©Copyright. Alle Rechte vorbehalten. 140Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

147. ●TransaktionBDRCzur Ermittlung der Wiederherstellungsobjekte
●TransaktionBDRLfür die Bearbeitung der Wiederherstellungsobjekte
Abbildung 128: IDoc-Wiederherstellung – Ablauf I
Bevor die Transaktion gestartet wird, werden die folgenden Einträge zum Verteilungsmodell
in einer Modellsicht hinzugefügt (S1 ist das vom Datenbankfehler betroffene System):
●S1 sendet RCYFET an S2
●S1 empfängt RCYRSP von S2
●S1 sendet RCYLST an S2
Die im System S1 angelegte Modellsicht wird an das System S2 verteilt. Die
Partnervereinbarungen werden in beiden Systemen generiert.
Die Transaktion wird im System S1 gestartet. Das beteiligte System S2 wird ausgewählt. Die
Systemeinstellungen in S1 und S2 werden geprüft. Wenn die Prüfung erfolgreich war, werden
die Wiederherstellungsobjekte ermittelt (F8). Zuletzt meldet das System, dass ein IDoc für
den NachrichtentypRCYFETeingerichtet wurde.
Sobald die IDocs für die NachrichtentypenRCYFET, RCYRSPundRCYLSTerfolgreich in den
Systemen S1 und S2 gebucht wurden, kann der nächste Schritt der Bearbeitung von
Wiederherstellungsobjekten gestartet werden.
Wir empfehlen die Verwendung der ALE-Audit-Technologie für den NachrichtentypRCYFET
aus dem Partnersystem, um das wiederhergestellte System zu informieren, dass die Aktivität
in diesem Partnersystem ausgeführt wurde.
Lektion: Wiederherstellung von IDocs nach einem Datenbankfehler
©Copyright. Alle Rechte vorbehalten. 141Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

148. Abbildung 129: IDoc-Wiederherstellung – Ablauf II
Alle beteiligten Systeme erhalten unter Verwendung des NachrichtentypsRCYFET
Informationen zum Datum und zur Uhrzeit des zurückgesetzten Systems. IDocs, die mit dem
zurückgesetzten System ausgetauscht wurden, werden hier ausgewählt und mit dem
NachrichtentypRCYRSPbestätigt.
Die IDocs, die in diesem System fehlen, und die weiteren durchzuführenden Aktivitäten
werden im zurückgesetzten System ermittelt. Diese Informationen werden in IDocs für den
NachrichtentypRCYLSTan die Partnersysteme gesendet, damit die Aktivitäten für
bestimmte Objekte in den Partnersystemen abgeleitet werden können.
Kapitel 6: Anhang
©Copyright. Alle Rechte vorbehalten. 142Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

149. Abbildung 130: IDoc-Wiederherstellung – Ablauf III
*Diese moderierte Diskussion wurde aus rein formellen Gründen in die Lektion aufgenommen.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Das Verfahren zur Wiederherstellung von IDocs und die für diese Funktion erforderlichen
Einstellungen beschreiben
Lektion: Wiederherstellung von IDocs nach einem Datenbankfehler
©Copyright. Alle Rechte vorbehalten. 143Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]