You are on page 1of 113

ALE-Einführung und

Administration

HELP.BCMIDALEIO

Release 4.6C
ALE-Einführung und Administration SAP AG

Copyright

© Copyright 2001 SAP AG. Alle Rechte vorbehalten.

Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem
Zweck und in welcher Form
auch immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP AG nicht gestattet. In
dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert
werden.

Die von SAP AG oder deren Vertriebsfirmen angebotenen Software-Produkte können Software-
Komponenten auch anderer Software-Hersteller enthalten.
® ® ® ® ® ® ®
Microsoft , WINDOWS , NT , EXCEL , Word , PowerPoint und SQL Server sind eingetragene
Marken der
Microsoft Corporation.
® ® ® ® ® ® ® ® ®
IBM , DB2 , OS/2 , DB2/6000 , Parallel Sysplex , MVS/ESA , RS/6000 , AIX , S/390 ,
® ® ®
AS/400 , OS/390 und OS/400 sind eingetragene Marken der IBM Corporation.
®
ORACLE ist eine eingetragene Marke der ORACLE Corporation.

® ® TM
INFORMIX -OnLine for SAP und Informix Dynamic Server sind eingetragene Marken der
Informix Software Incorporated.
® ® ® ®
UNIX , X/Open , OSF/1 und Motif sind eingetragene Marken der Open Group.
®
HTML, DHTML, XML, XHTML sind Marken oder eingetragene Marken des W3C , World Wide
Web Consortium,
Massachusetts Institute of Technology.
®
JAVA ist eine eingetragene Marke der Sun Microsystems, Inc.
®
JAVASCRIPT ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet unter der
Lizenz der von Netscape entwickelten und implementierten Technologie.

SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow,
SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo und mySAP.com
sind Marken oder eingetragene Marken der SAP AG in Deutschland und vielen anderen Ländern
weltweit. Alle anderen Produkte sind Marken oder eingetragene Marken der jeweiligen Firmen.

2 April 2001
SAP AG ALE-Einführung und Administration

Symbole

Symbol Bedeutung
Achtung

Beispiel

Hinweis

Empfehlung

Syntax

April 2001 3
ALE-Einführung und Administration SAP AG

Inhalt

ALE-Einführung und Administration................................................................. 6


Integrationstechnologie ALE.........................................................................................................7
ALE und das R/3-Vorgehensmodell..............................................................................................9
Nachrichtenverteilung..................................................................................................................10
Ablauf der Verteilung über BAPIs..............................................................................................11
Ablauf der Verteilung über Nachrichtentypen ...........................................................................18
Massenverarbeitung von IDocs.................................................................................................22
Fehlerbehandlung......................................................................................................................23
Modellieren der Verteilung ..........................................................................................................24
Verteilungsmodell.........................................................................................................................25
Filter...........................................................................................................................................26
Filtergruppe ..........................................................................................................................27
Filterobjekte..........................................................................................................................29
Klassen.................................................................................................................................30
Abhängigkeiten.....................................................................................................................31
Einrichten der Kommunikation ...................................................................................................32
Entfernte Destinationen pflegen .................................................................................................33
Destinationen anzeigen, pflegen und testen .............................................................................34
Destinationsparameter eingeben ..............................................................................................36
Destinationstypen ......................................................................................................................38
Gruppendestinationen pflegen ..................................................................................................41
RFC-Destinationen für synchrone Methodenaufrufe................................................................42
Technische Grundlagen zu ALE-Geschäftsprozessen.............................................................45
Customizing-Datenabgleich zwischen Systemen .....................................................................46
Zu synchronisierende Customizing-Daten ................................................................................48
Technischer Ablauf der Verteilung vor 4.x ................................................................................49
Stammdatenverteilung .................................................................................................................50
Strategien der Stammdatenverteilung.......................................................................................51
Stammdatenverteilung über Klassifizierung..............................................................................52
IDocs für Stammdaten...............................................................................................................53
Stammdatenverteilung mit dem SMD-Werkzeug ......................................................................55
Beispiel für die Stammdatenverteilung......................................................................................56
Verteilbare Stammdatenobjekte ................................................................................................59
R/2-Anbindung ..............................................................................................................................65
Anbindung von Fremdsystemen.................................................................................................67
Übersetzungsprogramme für die Anbindung ............................................................................69
Administration der ALE-Funktionen...........................................................................................71
Überwachung des Nachrichtenaustausches.............................................................................72
Zentrale Überwachung mit dem ALE-CCMS-Monitor ...............................................................73
Statusmonitor für ALE-Nachrichten...........................................................................................77
ALE-Audit und IDoc-Verfolgung ...........................................................................................80
IDoc-Status im Eingang mit ALE-Audit überwachen ......................................................81
Audit-Datenbank auswerten ......................................................................................83
IDocs systemübergreifend verfolgen ..............................................................................85

4 April 2001
SAP AG ALE-Einführung und Administration

Customizing-Daten zwischen Systemen abgleichen................................................................ 86


ALE-Performance-Optimierung .................................................................................................. 88
Steuerung des zeitlichen Ablaufs.............................................................................................. 89
Terminierung der IDoc-Erzeugung ...................................................................................... 90
Terminierung der IDoc-Übergabe an die Kommunikationsschicht ...................................... 91
Terminierung der IDoc-Verbuchung .................................................................................... 92
Parallele IDoc-Verarbeitung ...................................................................................................... 93
Parallele IDoc-Erzeugung .................................................................................................... 94
Paralleles Versenden von IDocs.......................................................................................... 95
Parallele IDoc-Verbuchung .................................................................................................. 96
Paketverarbeitung ..................................................................................................................... 97
Paketverarbeitung in der IDoc-Erzeugung........................................................................... 98
Paketverarbeitung beim Versenden von IDocs ................................................................... 99
Paketverarbeitung in der IDoc-Verbuchung....................................................................... 100
Administration der IDoc-Kommunikation................................................................................. 101
Hintergrund-Job unterdrücken bei Kommunikationsfehlern .............................................. 102
Versendestatus Versand OK setzen.................................................................................. 103
Status der tRFC-Aufrufe prüfen ......................................................................................... 104
Serialisierung von Nachrichten ................................................................................................ 105
Serialisierung über Objekttypen .............................................................................................. 106
Serialisierung über Nachrichtentypen ..................................................................................... 108
Serialisierung auf IDoc-Ebene ................................................................................................ 109
Umsetzung logischer Systeme ................................................................................................. 110
ALE-Recovery für Datenkonsistenz ......................................................................................... 112

April 2001 5
ALE-Einführung und Administration SAP AG
ALE-Einführung und Administration

ALE-Einführung und Administration

6 April 2001
SAP AG ALE-Einführung und Administration
Integrationstechnologie ALE

Integrationstechnologie ALE
Einsatzmöglichkeiten
Application Link Enabling (ALE) ist als Integrationstechnologie (Middleware) ein wesentliches
Werkzeug im Rahmen der Business Framework Architecture [Extern] (BFA) von SAP. BFA ist
eine komponentenbasierte Architektur, die eine Interaktion und Integration von
Softwarekomponenten von SAP und anderen Herstellern ermöglicht.
ALE integriert Geschäftsprozesse zwischen R/3-Systemen wie auch zwischen R/3-Systemen und
Fremdsystemen.
Dabei werden Daten zwischen Anwendungssystemen kontrolliert ausgetauscht und konsistent
gehalten.

In der Unternehmenszentrale werden übergreifende Anwendungen wie


Rechnungswesen, Personalwirtschaft oder Absatzplanung durchgeführt, während in
dezentralen Werken die Fertigung und die Materialwirtschaft geplant und gesteuert
werden.
Die Anwendungssysteme eines ALE-Verbunds sind lose gekoppelt. Die Daten werden asynchron
ausgetauscht, wobei sichergestellt wird, daß sie auch im Empfängersystem ankommen, wenn
dieses zum Sendezeitpunkt nicht erreichbar ist. Synchrone Verbindungen werden von ALE nur
zum Lesen von Daten genutzt.
ALE stellt Ihnen Werkzeuge für Verwaltung, Entwicklung und Test zur Verfügung.
Die ALE-Werkzeuge rufen Sie über Werkzeuge ® ALE auf.
Zur Standard-R/3-Auslieferung gehören auch ALE-Geschäftsprozesse, die in der ALE-
Geschäftsprozess-Bibliothek [Extern] dokumentiert sind.
Die erforderlichen Systemeinstellungen finden Sie im R/3-Einführungsleitfaden:
Werkzeuge ® AcceleratedSAP ® Customizing ® Projektbearbeitung
SAP Referenz-IMG
Basis ® Application Link Enabling (ALE).
Einzelheiten zur Programmierung finden Sie im ALE-Programmierleitfaden [Extern].
Um die Zuordnung von ALE-Funktionen zu bestimmten Benutzertypen zu erleichtern, wurden
folgende Benutzerrollen definiert:

· ALE-Administration
SAP_BC_MID_ALE_ADMIN

· ALE-Entwicklung
SAP_BC_MID_ALE_DEVELOPER

· Logistik-Stammdatenverteilung SAP_BC_MID_ALE_MD_LO

· Rechnungswesen-Stammdatenverteilung SAP_BC_MID_ALE_MD_FI

· Personal-Stammdatenverteilung SAP_BC_MID_ALE_MD_HR

April 2001 7
ALE-Einführung und Administration SAP AG
Integrationstechnologie ALE

Einführungshinweise
Eine Dezentralisierung von betriebswirtschaftlichen Anwendungen bei gleichzeitiger Wahrung der
Datenkonsistenz ist aus folgenden Gründen sinnvoll:
· Die zunehmende Globalisierung der Märkte führt zur physischen Trennung von
Organisationseinheiten.
· Geschäftsprozesse sind nicht auf ein einzelnes Unternehmen beschränkt, und in
zunehmendem Maße werden Kunden und Lieferanten einbezogen.
· Die Leistungsfähigkeit eines R/3-Systems kann durch die Verteilung
betriebswirtschaftlicher Anwendungen vergrößert werden.

Funktionsumfang
ALE unterstützt Konfiguration und Betrieb von verteilten Anwendungen. Es umfaßt einen
betriebswirtschaftlich kontrollierten Nachrichtenaustausch [Seite 10] zwischen verteilten
Anwendungen bei konsistenter Datenhaltung auf lose gekoppelten R/3-Systemen.
Die Anwendungsintegration erfolgt nicht über eine zentrale Datenbank. Statt dessen greifen
Anwendungen auf eine lokale Datenbank zu. Die Datenhaltung ist redundant. ALE gewährleistet
Verteilung und Abgleich von Stamm-, Steuer- und Bewegungsdaten über asynchrone
Kommunikation.
Zum Lesen von Daten nutzt ALE synchrone Verbindungen.
Der Einsatz von ALE bietet eine Reihe von Vorteilen:
· Verteilung von Anwendungsdaten zwischen R/3-Systemen unterschiedlicher Release-
Stände
· Datenaustausch nach Release-Wechsel ohne weitere Pflege gewährleistet
· Kundenspezifische Erweiterungen
· Anbindung von Nicht-SAP-Systemen über Kommunikationsschnittstellen
· Kopplung von R/3- und R/2-Systemen
ALE bietet Funktionen zur Überwachung des Nachrichtenflusses und zur Behebung von
Störungen.

8 April 2001
SAP AG ALE-Einführung und Administration
ALE und das R/3-Vorgehensmodell

ALE und das R/3-Vorgehensmodell


Das R/3-Vorgehensmodell [Extern] unterstützt anwendungsübergreifend die Einführung von R/3-
Produkten. Es handelt sich um ein Phasenmodell. Jeder Phase sind Arbeitsabschnitte
zugeordnet, zu denen ein oder mehrere Customizing-Arbeitsschritte gehören.
Orientieren Sie sich bei der Einführung von ALE-Funktionen am R/3-Vorgehensmodell, um eine
strukturierte Organisation der R/3-Einführung zu gewährleisten.
Im Vorgehensmodell müssen ALE-Funktionen an vier Stellen berücksichtigt werden:
· Festlegung von Funktionen und Prozessen
· Vornehmen der globalen Einstellungen
· Abbildung der Unternehmensorganisation
· Abbildung der Steuer- und Stammdaten
Werden ALE-Geschäftprozesse unterstützt, müssen Funktionen und Prozesse
systemübergreifend festgelegt werden. Im Verteilungsmodell werden die Beziehungen zwischen
Systemen und Nachrichten definiert.
Bei der Definition von Organisationeinheiten wie Buchungskreisen oder Werken müssen Sie
darauf achten, daß diese weltweit eindeutig sind. Beispielsweise darf das Werk 0001 nur in
einem R/3-System vorhanden sein.

April 2001 9
ALE-Einführung und Administration SAP AG
Nachrichtenverteilung

Nachrichtenverteilung
Einsatzmöglichkeiten
Die Grundlage für verteilte Anwendungen in einem ALE-Systemverbund ist die asynchrone
Verteilung von Nachrichten über die Ausgangs- und Eingangsverarbeitung.

Voraussetzungen
Grundlage für den Nachrichtenverteilung ist das IDoc [Extern]. IDocs werden sowohl bei der
Verteilung über Nachrichtentypen als auch über SAP-Business-Objektmethoden (BAPIs) erzeugt
und versendet.
Ab R/3-Release 4.0 sollen synchrone und asynchrone Schnittstellen als BAPI implementiert
werden. Wenn Sie asynchrone Schnittstellen als BAPIs implementieren, muss für das BAPI eine
BAPI-ALE-Schnittstelle vorhanden sein. SAP stellt für viele BAPIs solche Schnittstellen zur
Verfügung. Sie können auch selbst solche Schnittstellen generieren.
Mit diesen Schnittstellen können Sie Ihre ALE-Geschäftsprozesse implementieren.
Einzelheiten dazu finden Sie im ALE-Programmierleitfaden [Extern] unter Verteilung über BAPIs
und Verteilung über Nachrichtentypen.

Ablauf
Im Ausgangssystem wird ein IDoc mit den zu übertragenden Daten erzeugt und zur Versendung
aufbereitet.
Dann wird das IDoc an das Zielsystem übertragen.
Im Zielsystem stößt das IDoc die Eingangsverarbeitung an. Im einzelnen erfolgt die Bearbeitung
der Daten den Einstellungen entsprechend bis zur Verbuchung in der Anwendung, entweder
automatisch oder mit manuellen Zwischenschritten.
Die Ausgangs- bzw. Eingangsverarbeitung kann für jedes IDoc einzeln oder in einer
Paketverarbeitung erfolgen. Bei der Massenverarbeitung werden mehrere, in einem Paket
zusammengefaßte IDocs in einem Schritt bearbeitet.

10 April 2001
SAP AG ALE-Einführung und Administration
Ablauf der Verteilung über BAPIs

Ablauf der Verteilung über BAPIs


BAPIs können von einer Anwendung synchron oder asynchron aufgerufen werden. ALE-
Funktionen wie die Pflege der BAPIs im Verteilungsmodell und die Empfängerermittlung stehen
in beiden Fällen zur Verfügung.
Beachten Sie, daß synchron aufgerufene BAPIs nur zum Lesen von externen Daten benutzt
werden sollten, um Datenbank-Inkonsistenzen durch Übertragungsfehler zu vermeiden.

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

April 2001 11
ALE-Einführung und Administration SAP AG
Ablauf der Verteilung über BAPIs

Anwendung ALE-Schicht Kommunikations- ALE-Schicht Anwendung


Schicht

- Empfänger ermitteln
- Generierten Funktions- Verteilungs-
baustein aufrufen modell

IDoc Segmentfilterung

Datenfilterung Feldumsetzung
Generierter Generierter
Funktionsbaustein Funktionsbaustein
auf Ausgangsseite auf Eingangsseite
BAPI ® IDoc tRFC Übergabe-
Umwandlung oder IDoc ® BAPI
steuerung
EDI Umwandlung
Segmentfilterung
Serialisierung
Feldumsetzung BAPI-
IDoc Funktions-
Versionswandlung baustein
aufrufen

IDoc Daten und


IDoc-Status
aktualisieren IDoc-Status
Verknüpfung Versende- ermitteln
Datenbank steuerung Datenbank

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

12 April 2001
SAP AG ALE-Einführung und Administration
Ablauf der Verteilung über BAPIs

· Umwandlung des IDocs in einen BAPI-Aufruf


· Aufruf des BAPI-Funktionsbausteins
· IDoc-Status ermitteln
· Buchen der Anwendungsdaten und des IDoc-Status
· Fehlerbehandlung
Nachfolgend sind die Teilphasen der Ausgangs- und Eingangsverarbeitung beschrieben.

Ausgangsverarbeitung
Auf der Ausgangsseite wird in der Anwendungsschicht nach der Ermittlung der
Empfänger aus dem Verteilungsmodell der Ausgangsfunktionsbaustein aufgerufen, der
aus einem BAPI als Teil der BAPI-ALE-Schnittstelle generiert wurde (siehe auch
Beispielprogramme mit asynchronem BAPI-Aufruf [Extern]). In der ALE-Schicht wird das
zugehörige IDoc mit den gefilterten Daten aus dem BAPI-Aufruf gefüllt.
Über die Versendesteuerung wird die Datenübertragung zeitlich und mengenmäßig
gesteuert.
Im einzelnen setzt sich die Ausgangsverarbeitung aus den nachfolgend beschriebenen
Teilschritten zusammen.

Empfängerermittlung
Analog zum synchronen Aufruf eines BAPIs werden im Verteilungsmodell die potentiellen
Empfänger eines BAPI-Aufrufs definiert.
Vor dem Aufruf eines BAPIs bzw. einer generierten BAPI-ALE-Schnittstelle müssen
deren Empfänger ermittelt werden. Bei der Empfängerermittlung wird geprüft, ob die
Filterobjekte die vorgegebenen Bedingungen erfüllen, und es werden die erlaubten
Empfänger zurückgegeben.
Ist die Verteilung der Daten zusätzlich an Bedingungen geknüpft, werden diese
Abhängigkeiten zwischen BAPIs oder zwischen BAPIs und Nachrichtentypen als
Empfängerfilter definiert.
Für jeden dieser Empfängerfilter wurde vor der Pflege des Verteilungsmodells zunächst
ein Filterobjekt angelegt, dessen Wert zur Laufzeit darüber entscheidet, ob die
Bedingung erfüllt ist oder nicht.
Weitere Einzelheiten finden Sie unter Empfänger für ein BAPI ermitteln [Extern].

Aufruf des generierten Ausgangsfunktionsbausteins


Sind die Empfänger ermittelt, muß differenziert werden, ob die Empfänger lokal oder
remote sind. Für lokale Empfänger kann das BAPI direkt aufgerufen werden. Für
remote-Aufrufe wird dagegen der generierte ALE-Ausgangsfunktionsbaustein
ausgeführt und somit die Verarbeitung an die ALE-Schicht weitergeleitet. Diesem
Funktionsbaustein werden die Daten für den BAPI-Aufruf und die Liste der erlaubten
logischen Empfängersysteme mitgegeben.
Hinweis für die Programmierung:
Nach dem Aufruf des generierten Funktionsbausteins muß das
Anwendungsprogramm den Befehl COMMIT WORK enthalten. Der normale
Datenbank-Commit am Transaktionsende reicht nicht aus. Der COMMIT WORK muß

April 2001 13
ALE-Einführung und Administration SAP AG
Ablauf der Verteilung über BAPIs

nicht sofort nach dem Aufruf, sondern kann auch in höheren Aufrufebenen oder nach
mehreren Aufrufen des Funktionsbausteins erfolgen.
Die erzeugten IDocs sind bis zum Ende der aufrufenden Transaktion gesperrt. Um
sie vorher zu entsperren, können Sie einen der folgenden Funktionsbausteine
aufrufen:
DEQUEUE_ALL gibt alle Sperrobjekte frei
EDI_DOCUMENT_DEQUEUE_LATER gibt einzelne IDocs frei, deren Nummern dem
Funktionsbaustein als Parameterwerte übergeben werden.

Datenfilterung
Für die Filterung stehen zwei Filterdienste zur Verfügung: die an Bedingungen geknüpfte
Parameterfilterung und die bedingungslose Schnittstellenreduzierung.
· Wenn bei der Schnittstellenreduktion vollständige Parameter ausgeblendet wurden,
dann werden diese nicht in das IDoc übernommen. Sollen dagegen bei strukturierten
Parametern nur einzelne Felder nicht übernommen werden, erscheinen trotzdem die
vollständigen Parameter im IDoc.
· Bei der Parameterfilterung herausgefilterte Tabellenzeilen werden nicht in das IDoc
übernommen.
Weitere Einzelheiten finden Sie unter Daten filtern [Extern].

Umwandlung des BAPI-Aufrufs in ein IDoc


Ist die Datenfilterung abgeschlossen, wird vom Ausgangsfunktionsbaustein aus dem
BAPI-Aufruf ein IDoc mit den zu übertragenden Daten erzeugt.

Segmentfilterung
Nachdem das IDoc aufgebaut worden ist, kann eine zusätzliche Filterung der IDoc-
Segmente vorgenommen werden. Diese Filterung wird allerdings bei BAPIs nur in den
seltensten Fällen verwendet.
Einzelheiten dazu finden Sie im R/3-Einführungsleitfaden über folgenden Pfad:
Basis
Application Link Enabling
Geschäftsprozesse modellieren und implementieren
Verteilung von Stammdatenverteilung einstellen
Umfang der zu verteilenden Daten festlegen
Nachrichten reduzieren

Feldumsetzung
Empfängerspezifische Feldumsetzungen können Sie im R/3-Einführungsleitfaden
definieren:
Basis
Application Link Enabling
Geschäftsprozesse modellieren und implementieren
Datenumsetzung zwischen Sender und Empfänger einstellen
Es können allgemeine Regeln festgelegt werden, auf die man sich bei konkreten
Feldumsetzungen beziehen kann. Diese Funktion ist wichtig für die Konversion des

14 April 2001
SAP AG ALE-Einführung und Administration
Ablauf der Verteilung über BAPIs

Feldformats beim Datenaustausch zwischen R/2- und R/3-Systemen. In diesem Fall wird
beispielsweise das Feld Werk von 2 auf 4 Stellen erweitert.
Technisch erfolgt die Umsetzung mit Hilfe allgemeiner Umsetzungswerkzeuge aus dem
EIS-Bereich (Executive Information System).

IDoc-Versionswandlung
Damit die korrekte Funktion von ALE zwischen R/3-Systemen unterschiedlicher
Releasestände gewährleistet ist, kann eine Konversion von IDoc-Formaten durchgeführt
werden, um Nachrichtentypen unterschiedlicher Release-Stände anzupassen.
Ist die Versionswandlung abgeschlossen, werden die IDocs auf der Datenbank abgelegt
und die Versendesteuerung gestartet, die entscheidet, welche dieser IDocs sofort
versendet werden.
Bei der Änderung bestehender Nachrichtentypen hält sich die SAP-Entwicklung an
folgende Regeln:
· Felder können einem Segmenttyp angehängt werden;
· Segmente können hinzugefügt werden;
Im ALE-Customizing wird zu jedem Empfänger festgehalten, welche Version eines
Nachrichtentyps dort verwendet wird. Auf der Ausgangsseite wird das IDoc in der
korrekten Version erzeugt.

Versendesteuerung
Zeitliche Steuerung:
· Die IDocs können sofort oder per Hintergrundverarbeitung versandt werden. Diese
Einstellungen werden in der Partnervereinbarung vorgenommen.
· Erfolgt die Versendung per Hintergrundverarbeitung, muß ein Job eingeplant
werden. Der Ausführungsrhythmus ist frei wählbar.
Mengensteuerung:
· IDocs können gebündelt in Paketen versendet werden. Die Paketgröße wird im ALE-
Customizing partnerspezifisch vereinbart:
Basis
Application Link Enabling
Geschäftsprozesse modellieren und implementieren
Partnervereinbarung und Verarbeitungszeitpunkt einstellen
Partnervereinbarung manuell pflegen
oder: Partnervereinbarung generieren

Diese Einstellung ist nur wirksam, wenn Sie die Verarbeitung der IDocs im
Hintergrund einplanen.

Eingangsverarbeitung
Auf der Empfängerseite übernimmt die ALE-Schicht die Eingangsverarbeitung.

April 2001 15
ALE-Einführung und Administration SAP AG
Ablauf der Verteilung über BAPIs

Auf der Anwendungsseite wird bei der Ausführung des generierten


Eingangsfunktionsbausteins der BAPI-Aufruf aus dem IDoc erzeugt, der BAPI-
Funktionsbaustein aufgerufen und der IDoc-Status ermittelt.
Nachdem die Verarbeitung des BAPIs bzw. des gesamten Pakets abgeschlossen
worden ist, werden die Statussätze aller IDocs sowie die von erfolgreich
abgeschlossenen BAPIs erzeugten Anwendungsdaten zusammen verbucht.
Im einzelnen setzt sich die Eingangsverarbeitung aus den nachfolgend beschriebenen
Teilschritten zusammen.

Segmentfilterung
Auf der Eingangsseite kann analog zur Ausgangsverarbeitung eine Filterung von IDoc-
Segmenten vorgenommen werden. Diese Filterung auf der Eingangsseite wird bei BAPIs
ebenfalls nur in den seltensten Fällen verwendet.

Feldumsetzung
Ebenfalls wie bei der Ausgangsverarbeitung ist es möglich, Feldumsetzungen
durchzuführen, wenn sich die Formate eines Feldes im Empfänger- und Sendesystem
unterscheiden.
Nachdem die Feldumsetzung stattgefunden hat wird das IDoc auf der Datenbank
gespeichert und die weitere Verarbeitung an die Übergabesteuerung übergeben.

Übergabesteuerung
In der Übergabesteuerung wird entschieden, wann die BAPIs in der Anwendung
aufgerufen werden sollen. Dies kann entweder sofort nach dem Eintreffen des IDocs
oder zeitgesteuert per Hintergrundverarbeitung erfolgen.
Werden mehrere voneinander abhängige Objekte verteilt, kann während der
Übergabesteuerung die Serialisierung genutzt werden. Durch eine serialisierte
Verteilung von Nachrichten wird eine bestimmte Reihenfolge bei der Erzeugung,
Versendung und Verbuchung der entsprechenden IDocs eingehalten. Dadurch werden
Fehler bei der Eingangsverarbeitung der IDocs vermieden.
Bei der Verwendung von BAPIs kann ausschließlich die Objektserialisierung genutzt
werden, die sicherstellt, daß die Reihenfolge der Nachrichten bezüglich eines
bestimmten Objektes auf der Empfängerseite immer gewahrt bleibt.
Weitere Einzelheiten zur Objektserialisierung finden Sie im ALE-Customizing:
Basis
Application Link Enabling
Geschäftsprozesse modellieren und implementieren
Verteilung von Stammdaten konfigurieren
Serialisierung der Daten beim Senden und Empfangen einstellen
Serialisierung über Objekttypen
Wenn der Zeitpunkt zur Verarbeitung des BAPIs gekommen ist, wird der generierte
Eingangsfunktionsbaustein aufgerufen.

Umwandlung des IDocs in einen BAPI-Aufruf


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

16 April 2001
SAP AG ALE-Einführung und Administration
Ablauf der Verteilung über BAPIs

Aufruf des BAPI-Funktionsbausteins


Anschließend wird der BAPI-Funktionsbaustein synchron mit den gefüllten Parametern
ausgeführt. Da das BAPI kein COMMIT-WORK-Kommando absetzt, werden die von ihm
angelegten, modifizierten oder gelöschten Anwendungsdaten noch nicht in die
Datenbank übernommen.

IDoc-Statusermittlung
Ist die Ausführung des Funktionsbausteins abgeschlossen, wird im
Eingangsfunktionsbaustein in Abhängigkeit vom Ergebnis des Aufrufs der IDoc-Status
ermittelt.

Buchen der Anwendungsdaten und des IDoc-Status


Wenn jedes IDoc bzw. BAPI einzeln verarbeitet wird, werden die Daten sofort auf die
Datenbank geschrieben.
Wenn allerdings mehrere IDocs innerhalb eines Pakets verarbeitet werden, sind folgende
Situationen denkbar:
· Die Anwendungsdaten der erfolgreich abgeschlossenen BAPIs werden zusammen
mit den Statussätzen aller IDocs verbucht, sofern kein BAPI-Aufruf innerhalb des
Pakets abgebrochen wurde.
· Sobald allerdings ein BAPI-Aufruf innerhalb des Pakets abgebrochen wurde, wird der
Status des zugehörigen IDocs als fehlerhaft betrachtet. Anwendungsdaten werden
nicht verbucht. Anschließend wird für alle BAPI-Aufrufe, die zuvor erfolgreich
beendet wurden, die Eingangsverarbeitung erneut durchlaufen. Tritt bei diesem Lauf
kein Abbruch mehr auf, werden die Anwendungsdaten der erfolgreich
abgeschlossenen BAPIs zusammen mit den Statussätzen aller IDocs verbucht. Beim
Auftreten weiterer Abbrüche wird dieser Vorgang wiederholt.
Hinweis: Die Paketverarbeitung wird nur durchgeführt, wenn keine Serialisierung
stattfindet.

Fehlerbehandlung
Für die ALE-Fehlerbehandlung können Sie den SAP-Workflow verwenden:
· Die Verbuchung des fehlerverursachenden IDocs bzw. der BAPI-Daten wird
abgebrochen.
· Ein Ereignis wird ausgelöst. Dieses Ereignis stößt eine Fehler-Aufgabe (Workitem)
an.
· Sobald die Daten des BAPIs bzw. IDocs erfolgreich verbucht worden sind, wird ein
Ereignis ausgelöst, das die Fehler-Aufgabe beendet. Damit verschwindet die
Aufgabe aus dem Eingangssystem.
Weitere Einzelheiten finden Sie unter Fehlerbehandlung [Extern].

April 2001 17
ALE-Einführung und Administration SAP AG
Ablauf der Verteilung über Nachrichtentypen

Ablauf der Verteilung über Nachrichtentypen


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

Anwendung ALE-Schicht Kommunikations- ALE-Schicht Anwendung


Schicht

Nachricht Verteilungs-
erzeugen?
modell

Stamm-IDoc Stamm Empfänger-


erzeugen ermittlung IDoc
IDoc

Segment- Segment-
filterung filterung
tRFC
Feld-
oder Feld-
umsetzung EDI umsetzung

Versions- Übergabe-
wandlung steuerung IDoc

IDoc
IDoc
verarbeiten
IDoc Serialisierung

Versende- IDoc-Status Anwendungs-


Datenbank Verknüpfung Datenbank beleg buchen
steuerung gleichzeitig
aktualisieren

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

18 April 2001
SAP AG ALE-Einführung und Administration
Ablauf der Verteilung über Nachrichtentypen

Einzelheiten zur Programmierung finden Sie unter Ausgangsverarbeitung implementieren


[Extern].
Die einzelnen Schritte sind nachfolgend erläutert.

Empfängerermittlung:
Ein IDoc hat analog zu einem Brief einen Absender und einen Empfänger. Wenn der
Empfänger nicht durch die Anwendung eingetragen wurde, ermittelt die ALE-Schicht
anhand des Verteilungsmodells den oder die Interessenten für diese Nachricht.
Aus dem Modell kann die ALE-Schicht entnehmen, ob und wieviele verteilte Systeme die
Nachricht erhalten sollen. Es können kein, ein oder mehrere Empfänger ermittelt werden.
Für jedes der ermittelten verteilten Systeme werden die Daten, die laut Filterobjekte im
Verteilungsmodell festgelegt sind, aus dem Master-IDoc selektiert. Mit diesen Daten wird
ein IDoc gefüllt, in das der Interessent als Empfänger eingetragen wird.

Segmentfilterung:
Vor dem Versenden können in diesem Verarbeitungsschritt einzelne Segmente aus dem
IDoc entfernt werden. Zu unterdrückende Segmente können Sie im ALE-Customizing
über folgenden Pfad festlegen:
ALE-Geschäftsprozessen modellieren und implementieren
Verteilung von Stammdatenverteilung konfigurieren
Umfang der zu verteilenden Daten einstellen
IDoc-Segmente filtern
Die Einstellung erfolgt abhängig vom sendenden und empfangenden logischen R/3-
System.

Feldumsetzung:
Empfängerspezifische Feldumsetzungen können Sie im ALE-Customizing definieren:
ALE-Geschäftsprozessen modellieren und implementieren
Datenumsetzen zwischen Sender und Empfänger einstellen
Es können allgemeine Regeln festgelegt werden, auf die man sich bei konkreten
Feldumsetzungen beziehen kann. Die Regeln werden pro IDoc-Segment angelegt und je
Segmentfeld definiert. Diese Funktion ist wichtig für die Konversion des Feldformats beim
Datenaustausch zwischen R/2- und R/3-Systemen. In diesem Fall wird beispielsweise
das Feld Werk von 2 auf 4 Stellen erweitert.
Technisch erfolgt die Umsetzung mit Hilfe allgemeiner Umsetzungswerkzeuge aus dem
EIS-Bereich (Executive Information System).

IDoc-Versionswandlung:
SAP gewährleistet die korrekte Funktion von ALE zwischen R/3-Systemen
unterschiedlicher Release-Stände. Zur Anpassung der Nachrichtentypen verschiedener
R/3-Releasestände kann in diesem Verarbeitungsschritt eine Konversion der IDoc-
Formate erfolgen.
Bei der Änderung bestehender Nachrichtentypen hält sich die SAP-Entwicklung an
folgende Regeln:
· Felder können einem Segmenttyp angehängt werden.
· Segmente können hinzugefügt werden.

April 2001 19
ALE-Einführung und Administration SAP AG
Ablauf der Verteilung über Nachrichtentypen

Im ALE-Customizing wird zu jedem Empfänger festgehalten, welche Version eines


Nachrichtentyps dort verwendet wird. Im Ausgang wird das Communication-IDoc in der
korrekten Version erzeugt.

Versendesteuerung
In der Versendesteuerung wird der Versand nach Zeitpunkt und Menge gesteuert.
Zeitliche Steuerung:
Die IDocs können sofort oder per Hintergrundverarbeitung versandt werden. Diese
Einstellungen werden in der Partnervereinbarung vorgenommen.
Erfolgt die Versendung per Hintergrundverarbeitung, muß ein Job eingeplant
werden. Der Ausführungs-Rhythmus ist frei wählbar.
Mengensteuerung:
IDocs können gebündelt in Paketen versendet werden. Die Paketgröße wird im ALE-
Customizing wie folgt partnerspezifisch vereinbart:
Geschäftsprozesse modellieren und implementieren
® Partnervereinbarung und Verarbeitungszeitpunkt einstellen
® Partnervereinbarungen manuell pflegen

Diese Einstellung ist nur wirksam, wenn die IDocs im Hintergrund verarbeitet
werden.

Eingangsverarbeitung
In der ALE-Schicht durchläuft das ankommende IDoc folgende Schritte:
· Segmentfilterung
· Feldumsetzung
· Übergabesteuerung
· Serialisierung
Einzelheiten zur Programmierung finden Sie unter Eingangsverarbeitung implementieren
[Extern].
Die einzelnen Schritte sind nachfolgend erläutert.

Segmentfilterung
Im Eingang können Sie eine Filterung von IDoc-Segmenten vornehmen.
Diese Funktion in der Eingangsverarbeitung gleicht im Prinzip der der
Ausgangsverarbeitung.

Feldumsetzung
Empfängerspezifische Feldumsetzungen können Sie im ALE-Customizing definieren:
ALE-Geschäftsprozessen modellieren und implementieren
Datenumsetzen zwischen Sender und Empfänger einstellen
Es können allgemeine Regeln festgelegt werden, auf die man sich bei konkreten
Feldumsetzungen beziehen kann. Die Regeln werden pro IDoc-Segment angelegt und je

20 April 2001
SAP AG ALE-Einführung und Administration
Ablauf der Verteilung über Nachrichtentypen

Segmentfeld definiert. Diese Funktion ist wichtig für die Konversion des Feldformats beim
Datenaustausch zwischen R/2- und R/3-Systemen. In diesem Fall wird beispielsweise
das Feld Werk von 2 auf 4 Stellen erweitert.
Technisch erfolgt die Umsetzung mit Hilfe allgemeiner Umsetzungswerkzeuge aus dem
EIS-Bereich (Executive Information System).

Bei reduzierbaren Nachrichtentypen werden Feldwerte im empfangenden R/3-


System nicht überschrieben, wenn im entsprechenden IDoc-Feld das Zeichen "/"
steht.

Übergabesteuerung
Wurden die IDocs auf der Datenbank abgelegt, können sie von der entsprechenden
Anwendung gebucht werden.
Die Übergabe an die Anwendung kann sofort nach Eintreffen der IDocs oder
zeitgesteuert per Hintergrundverarbeitung erfolgen.
IDocs können auf drei Arten verbucht werden:
· Ein Funktionsbaustein wird direkt aufgerufen:
Die eingehenden IDocs werden direktes gebucht. Nur im Fehlerfall wird ein Fehler-
Workflow gestartet.
· Ein SAP Business Workflow wird gestartet. Ein Workflow ist die Abfolge von
Schritten zur Buchung eines IDocs.
Es werden keine Workflows für ALE ausgeliefert.
· Ein Workitem wird gestartet:
Start eines einzigen Schrittes zur Einbuchung eines IDocs.
Standardmäßig werden von ALE in der Eingangsverarbeitung die ausgelieferten
Funktionsbausteine aufgerufen. Informationen über die SAP Business Workflow-Alternativen
finden Sie unter Eingangsverarbeitung über SAP-Workflow [Extern].
Zur Behandlung von Störungen in der IDoc-Verarbeitung können Sie im SAP-Workflow zu
benachrichtigende Personen festlegen. Dies kann für jeden Nachrichtentyp getrennt

April 2001 21
ALE-Einführung und Administration SAP AG
Massenverarbeitung von IDocs

Massenverarbeitung von IDocs


Unter Massenverarbeitung versteht man das Bündeln von IDocs zu Paketen, das Versenden
dieser Pakete und deren Verarbeitung im empfangenden R/3-System. Damit wird zur
Übermittlung mehrerer IDocs nur ein RFC-Aufruf benötigt. Aus diesem Grund ergibt sich bei einer
optimalen Paketgröße ein erheblicher Performance-Vorteil.
Die Einstellung der Massenverarbeitungs-Parameter erfolgt im ALE-Customizing unter
Geschäftsprozesse modellieren und implementieren ® Partnervereinbarung und
Verarbeitungszeitpunkt einstellen ® Partnervereinbarungen generieren. Für einen
Nachrichtentyp können hier als Ausgangsparameter die Paketgröße und der Ausgabemodus
festgelegt werden.
Ist der Ausgabemodus auf IDocs sammeln und übergeben eingestellt, so werden in der
Ausgangsverarbeitung IDocs gleichen Nachrichtentyps und Empfängers zu IDoc-Paketen der
angegebenen Größe zusammengestellt. Die Versendung der IDoc-Pakete erfolgt durch einen
geplanten Hintergrund-Job oder in der ALE-Administration.
Für manche Verteilungsszenarios ist eine Massenverarbeitung nicht möglich, da auf der
Eingangsseite das Buchen von IDoc-Paketen nicht unterstützt wird. Dies ist insbesonders der
Fall, wenn die einbuchende Anwendung den ABAP-Befehl CALL TRANSACTION USING
ausführt. In diesem Fall muß der Ausgangsparameter PAKETGRÖßE "1" gesetzt werden.
Massenverarbeitungsfähige Funktionsbausteine finden Sie in der ALE-Entwicklung über IDoc ®
Eingangsverarbeitung ® Funktionsbaustein ® Attribute pflegen. Sie sind durch den INPUTTYP 0
gekennzeichnet.

22 April 2001
SAP AG ALE-Einführung und Administration
Fehlerbehandlung

Fehlerbehandlung
Einzelheiten zu den erforderlichen Einstellungen finden Sie im R/3 Customizing
Einführungsleitfaden:
Basis
Application Link Enabling (ALE)
Fehlerbehandlung einstellen

Fehlerbehandlung im ALE-Ausgang
Bei einem Fehler in der ALE-Schicht wird das fehlerhafte IDoc gesichert und ein Workflow
erzeugt. Über den Workflow kann der ALE-Administrator den Fehler bearbeiten.

Fehlerbehandlung im ALE-Eingang
Treten während der ALE-Eingangsverarbeitung Fehler auf, hat das folgende Konsequenzen:
· Die Verbuchung des fehlerverursachenden IDocs wird abgebrochen.
· Es wird ein Ereignis ausgelöst. Dieses Ereignis stößt eine Fehler-Aufgabe (Workitem) an:
- Die verantwortlichen Personen bekommen eine Aufgabe in ihren Workflow-Eingang.
- Durch Verarbeitung der Aufgabe wird die Fehlermeldung gezeigt.
- Nach dem Korrigieren des Fehlers in einem anderen Fenster kann das IDoc zur
Verarbeitung wieder vorgelegt werden.
- Sollte der Fehler irreparabel sein, kann das IDoc zur Löschung vorgemerkt werden.
· Ist das IDoc erfolgreich eingebucht worden, wird ein Ereignis ausgelöst, daß die Fehler-
Aufgabe beendet. Damit verschwindet die Aufgabe aus dem Eingang.

Fehlerhafte IDocs nachträglich buchen


Bei einem Fehler in der Eingangsverarbeitung (IDoc-Status 51 "Anwendungsbeleg nicht gebucht"
oder 63 "Fehler bei der IDoc-Übergabe an die Anwendung") können IDocs mit Hilfe des
Programms RBDMANI2 erneut zur Verbuchung an die Anwendung übergeben werden.
Das Programm erlaubt es, bestimmte Fehler zu selektieren.
Um IDocs gesammelt zu bearbeiten, die auf Grund eines Sperrproblems nicht verbucht werden
konnten, läßt es sich auch zur periodischen Ausführung in einem Job einplanen:
R/3 Customizing Einführungsleitfaden,
Basis, Application Link Enabling (ALE),
Geschäftsprozesse modellieren und implementieren
Partnervereinbarung und Verarbeitungszeitpunkt einstellen
Verbuchung von fehlerhaften IDocs einplanen

April 2001 23
ALE-Einführung und Administration SAP AG
Modellieren der Verteilung

Modellieren der Verteilung


Einsatzmöglichkeiten
Um eine Verteilung betriebswirtschaftlicher Prozesse und Funktionen mit Hilfe von ALE
einzuführen; müssen Sie ein logisches Verteilungsmodell [Seite 25] des Gesamtsystems
aufbauen. Im Rahmen dieser Konfiguration legt der Kunde fest, welche Anwendungen auf
welchen Systemen laufen und welche Nachrichten die Anwendungen untereinander
austauschen.

Voraussetzungen
Die folgenden Schwerpunktfragen sollten Sie bei der Erarbeitung eines Verteilungskonzeptes
berücksichtigen:
· An welchen Standorten sollen verteilte R/3-Systeme installiert werden?
· Welche Anwendungen sollen auf welchen Systemen laufen?
· Welche Stamm- und Bewegungsdaten sollen die Anwendungen untereinander
austauschen?
· Welche Konfigurationsdaten müssen den verteilten Systemen bekannt sein?

Ablauf
Das logische System ist so zu modellieren, als handle es sich um eine einzige R/3 Instanz.
Danach werden Anwendungen auf verschiedene physischen Systeme verteilt. Die meisten
Organisationseinheiten, wie WERK oder VERTRIEBSORGANISATION, müssen eindeutig
benannt werden. Buchungskreise und Geschäftsbereiche bilden die einzigen Ausnahmen.

24 April 2001
SAP AG ALE-Einführung und Administration
Verteilungsmodell

Verteilungsmodell
Definition
Das Verteilungsmodell beschreibt den ALE-Nachrichtenfluß zwischen logischen Systemen.

Verwendung
Im Verteilungsmodell sind die Beziehungen zwischen logischen Systemen, Nachrichtentypen,
BAPIs und Filtern festgelegt. Es wird von den Anwendungen und der ALE-Schicht zur
Empfängerermittlung und Steuerung der Datenverteilung genutzt.
Einzelheiten zur Pflege des Verteilungsmodells finden Sie im R/3 Customizing
Einführungsleitfaden:
Basis
Application Link Enabling (ALE):
Geschäftsprozesse modellieren und implementieren
Verteilungsmodell pflegen

Struktur
Im Verteilungsmodell wird festgelegt, welche Nachrichten an ein logisches System versendet
werden. Zusätzlich erlauben Filter [Seite 26], Bedingungen für den Inhalt und das Versenden
einer Nachricht zu definieren.
Das Verteilungmodell besteht aus einer oder mehreren frei definierbaren Sichten. Bei komplexen
Verteilungsaufgaben können betriebswirtschaftliche Teilbereiche oder Gruppen von logischen
Systemen einzelnen Sichten zugeordnet werden.
Zur korrekten Funktion müssen relevante Sichten des Verteilungsmodells auf allen beteiligten
logischen Systemen vorhanden sein. Das Customizing des ALE stellt Funktionen zur Verteilung
der Sichten bereit.

April 2001 25
ALE-Einführung und Administration SAP AG
Filter

Filter
Definition
Filter sind Bedingungen, die von Nachrichtentypen und BAPIs erfüllt werden müssen, um von der
ALE-Ausgangsverarbeitung verteilt zu werden.

Verwendung
Die ALE-Ausgangsverarbeitung entscheidet aufgrund von Filtern über den Datenumfang und die
Empfänger einer Nachricht. Im Verteilungsmodell sind Filter einer Methode oder einem
Nachrichtentyp zugeordnet. Ein Filter ist immer einer Filtergruppe [Seite 27] zugeordnet.
Weitere Einzelheiten zu Filtern finden Sie im R/3-Einführungsleitfaden:
Basis
Verteilung (ALE):
Geschäftsprozesse modellieren und implementieren
Verteilungsmodell pflegen

Struktur
Für die Filterung von Nachrichtentypen und BAPIs stehen folgende Filtertypen zur Verfügung:
· Filterobjekte [Seite 29]
· Klassen [Seite 30]
· Abhängigkeiten [Seite 31]

26 April 2001
SAP AG ALE-Einführung und Administration
Filtergruppe

Filtergruppe
Definition
Eine Filtergruppe besteht aus einem einzelnen oder mehreren Filtern.

Verwendung
Filtergruppen erlauben es, komplexe Bedingungen für die Filterung von Nachrichten zu
definieren. Für eine Nachricht können mehrere Filtergruppen definiert werden. Ein Filter ist immer
einer Filtergruppe zugeordet. Die Filtergruppe wird automatisch angelegt, sofern der Filter keiner
bestehenden Filtergruppe hinzugefügt wird.
Die Verküpfung zwischen Filtergruppen ist disjunktiv (logisches ODER).
Jede Filtergruppe wird unabhängig von anderen Filtergruppen ausgewertet.
Innerhalb einer Filtergruppe ist die logische Verküpfung der Filter im allgemeinen konjunktiv
(logisches UND). Zwischen gleichnamigen Filterobjekten einer Filtergruppe besteht eine ODER-
Verknüpfung. Die Abhängigkeiten von Nachrichtentypen sind konjunktiv (logisches UND)
verknüpft.

Beispiel für die Filterung innerhalb einer Filtergruppe


Die Filtergruppe besteht aus folgenden Filtern:
Werk 001
Werk 002
Sparte 01
Sparte 02
Verteilung über Klassen
Abhängigkeit vom Nachrichtentyp MATMAS
Abhängigkeit vom Nachrichtentyp CREMAS
Es ergibt sich daraus folgende Filterbedingung:
(Werk 0001 ODER Werk 0002)
UND
(Sparte 01 ODER Sparte 02)
UND
Verteilung über Klassen
UND
Abhängigkeit vom Nachrichtentyp MATMAS
UND
Abhängigkeit vom Nachrichtentyp CREMAS

Beispiel für die Filterung mit mehreren Filtergruppen


Die Filtergruppe 1 besteht aus folgendem Filter:
Global eindeutiger Buchungskreis GL0001
Die Filtergruppe 2 besteht aus folgendem Filter:

April 2001 27
ALE-Einführung und Administration SAP AG
Filtergruppe

Verkaufsorganisation YYZZ
Da die Filtergruppen getrennt ausgewertet werden, wird in diesem Beispiel keine
Filterung stattfinden.
Grund:
In Filtergruppe 1 ist keine Bedingung für die Verkaufsorganisation enthalten. Daher
wird das entsprechende Segment aufgebaut, selbst wenn die Bedingung in
Filtergruppe 2 nicht zutrifft.
In Filtergruppe 2 ist keine Bedingung für den Buchungskreis enthalten. Daher wird
das entsprechende Segment aufgebaut, selbst wenn die Bedingung in Filtergruppe 1
nicht zutrifft.

28 April 2001
SAP AG ALE-Einführung und Administration
Filterobjekte

Filterobjekte
Definition
Filterobjekte sind Attribute einer Nachricht im Verteilungsmodell. Sie bestehen aus einem
Filterobjekttyp (z.B. Materialart) und zugeordnetem Objektwert (z.B. FERT).

Verwendung
ALE nutzt Filterobjekte in der Ausgangsverabeitung. Mit ihrer Hilfe lassen sich Umfang und
Empfänger einer Nachricht bestimmen.
Die Wirkung eines Filterobjekts unterscheidet sich für Nachrichtentypen und BAPIs:
· Beim Filtern von Nachrichtentypen werden alle IDoc-Segmente unterdrückt, die ein Feld mit
dem Namen des Objekttyps besitzen und dessen Wert mit dem Objektwert nicht
übereinstimmt. Untersegmente solcher IDoc-Segmente werden ebenfalls unterdrückt.
War das unterdrückte Segment ein Muß-Segment, und existieren keine weiteren Muß-
Segmente gleichen Namens auf der gleichen Stufe der IDoc-Hierarchie, wird auch das
übergeordnete IDoc-Segment unterdrückt. Dieser Vorgang ist rekursiv, und das
Endresultat ist abhängig von der konkreten IDoc-Struktur, von Muß-Segmenten und
Segmentwiederholungen.
Bleibt nach diesem Prozess das oberste Mußsegment eines IDocs erhalten, so wird das
übrigbleibende IDoc verteilt.
· Bei BAPIs entspricht der Filterobjekttyp einem Parameternamen. Filterobjekte für BAPIs
prüfen, ob ein Parameter den vorgegebenen Objektwert besitzt. Nur wenn dies zutrifft, wird
über das BAPI ein IDoc erzeugt und verteilt.
Dabei wird folgende Unterscheidung getroffen:
- Empfängerermittlung
Bei der Empfängerermittlung wird geprüft, ob die Filterobjekte die vorgegebenen
Bedingungen erfüllen, und es werden die erlaubten Empfänger zurückgegeben.
Einzelheiten dazu erfahren Sie im ALE-Programmierleitfaden unter Empfänger für
ein BAPI ermitteln [Extern].
- Parameterfilterung
Über die Filterung von BAPI-Tabellenparametern wird die Datenmenge der Tabellen
eines BAPIs ähnlich wie bei der IDoc-Segmentfilterung bestimmt.
Einzelheiten dazu erfahren Sie im ALE-Programmierleitfaden unter BAPI-Parameter
filtern [Extern].

Struktur
Filterobjekte bestehen aus einem Filterobjekttyp und zugeordnetem Objektwert.
Filterobjekttypen sind entweder Feldnamen in IDoc-Segmenten oder Namen von Parametern in
BAPI-Aufrufen.

April 2001 29
ALE-Einführung und Administration SAP AG
Klassen

Klassen
Definition
Zusammenfassung ähnlicher Objekte, die durch gemeinsame Merkmale beschrieben werden.

Verwendung
Die Klassifizierung des R/3-Systems kann zur Steuerung der ALE-Verteilung genutzt werden.
Verteilbare Klassen von Objekten können einem Nachrichtentyp zugeordnet werden und dienen
als Filter für die Verteilung dieses Nachrichtentyps.
Es können z.B. Objekte folgenden Typs klassifiziert werden:
· Material
· Kunde
· Lieferant

Struktur
Eine Klasse enthält Merkmale, die die Eigenschaften der zu klassifizierenden Objekte
beschreiben. Für die Merkmale können zulässige Werte definiert werden.

30 April 2001
SAP AG ALE-Einführung und Administration
Abhängigkeiten

Abhängigkeiten
Definition
Abhängigkeiten beschreiben Beziehungen zwischen den folgenden Schnittstellen bezüglich ihrer
Verteilbarkeit:
· zwischen BAPIs
· zwischen Nachrichtentypen
· zwischen einem BAPI und einem Nachrichtentyp

Verwendung
Die Verteilung von betriebswirtschaftlichen Prozessen und Daten ist unter Umständen nur dann
sinnvoll, wenn andere Prozesse in ähnlicher Weise verteilt werden. Aus diesem Grunde besteht
die Möglichkeit, das Versenden einer Nachricht vom Versenden einer anderen abhängig zu
machen.
Eine solche Abhängigkeit muss über einen Funktionsbaustein der Anwendung implementiert und
in der ALE-Entwicklung eingestellt werden. Einzelheiten dazu finden Sie im ALE-
Programmierleitfaden [Extern].
Bei der Pflege des Verteilungsmodells werden solche definierten Abhängigkeiten im Rahmen der
Empfängerfilterung als Option angeboten.
Beispiel für die Abhängigkeit eines BAPIs von einem Nachrichtentyp:
Die Verteilung von Organisationsadressen wurde in die Objektpflege zum Lieferanten integriert.
Über ALE werden diese Adressdaten dann zusammen mit den Objektdaten verteilt. Die
Adressdaten stehen in Abhängigkeit zu den Objektdaten und werden mittels BAPI verteilt. Die
Objektdaten werden über den Nachrichtentyp CREMAS verteilt.
Es existiert also eine Abhängigkeit zwischen einem BAPI und einem Nachrichtentyp.
Im Verteilungsmodell ist dem BAPI zur Verteilung von Organisationsadressen
(AddressOrg.SaveReplica) ein aktiver Empfängerfilter zugewiesen. Über das Attribut abhängige
Verteilung in der Filteranzeige wurde die Abhängigkeit aktiviert.
Aufgrund der Empfängerermittlung werden die Objektdaten mit den BAPI-Adressdaten nur dann
verteilt, wenn die Filterbedingung für CREMAS erfüllt sind.

April 2001 31
ALE-Einführung und Administration SAP AG
Einrichten der Kommunikation

Einrichten der Kommunikation


Für das Einrichten der Kommunikationsbeziehungen sind eine Reihe von Schritten erforderlich,
die Sie im ALE-Einführungsleitfaden (Transaktion SALE) durchführen müssen:
Einzelheiten zur Pflege der ALE-Kommunikationsbeziehungen finden Sie im R/3 Customizing
Einführungsleitfaden unter Basis ® Verteilung (ALE):
· RFC-Destinationen definieren
Über die Parameter der RFC-Destination wird der Remote Function Call gesteuert.
Einzelheiten zur Pflege von RFC-Destinationen finden Sie unter Entfernte
Destinationen pflegen [Seite 33].
Sie können auch festlegen, welche RFC-Destinationen für synchrone
Methodenaufrufe verwendet werden sollen. Dabei handelt es sich entweder um
BAPIs oder Dialogmethoden [Extern]. Einzelheiten zur Pflege von RFC-
Destinationen für solche Aufrufe finden Sie unter RFC-Destinationen für synchrone
Methodenaufrufe [Seite 42]
Wählen Sie folgende Schritte im ALE-Einführungsleitfaden:
Sender- und Empfängersysteme vorbereiten
Systeme im Netzwerk konfigurieren
· Partnervereinbarungen generieren
Auf der Basis des Kundenverteilungsmodells werden die Partnervereinbarungen
generiert.
Wählen Sie folgende Schritte im ALE-Einführungsleitfaden:
Geschäftsprozesse modellieren und implementieren
Partnervereinbarung und Verarbeitungszeitpunkt einstellen
· Partnervereinbarungen und Modelleinstellungen auf Konsistenz prüfen
Neben der Konsistenz der Partnervereinbarungen und Modelleinstellungen können
Sie auch die Konsistenz der Anwendungseinstellung auf den beteiligten Systemen
sowie der Steuerdatenverteilung prüfen.
Wählen Sie folgende Schritte im ALE-Einführungsleitfaden:
Geschäftsprozesse modellieren und implementieren
Partnervereinbarung und Verarbeitungszeitpunkt einstellen
· Kommunikation prüfen
Sie können bei laufendem Betrieb prüfen, ob gesendete Nachrichten im
Empfängersystem angekommen sind und welchen Verarbeitungsstatus die
Nachrichten hat.
Wählen Sie folgende Schritte im ALE-Einführungsleitfaden:
Überwachung der Systeme einstellen
IDoc-Rückmeldung im Empfängersystem einrichten (ALE-Audit)

32 April 2001
SAP AG ALE-Einführung und Administration
Entfernte Destinationen pflegen

Entfernte Destinationen pflegen


Wählen Sie Werkzeuge ® Administration ® Verwaltung ® Netzwerk ® RFC-Destinationen.
Einzelheiten finden Sie in folgenden Themen:

Destinationstypen [Seite 38]

Destinationen anzeigen, pflegen und testen [Seite 34]

Destinationsparameter eingeben [Seite 36]

Gruppendestinationen pflegen [Seite 41]

April 2001 33
ALE-Einführung und Administration SAP AG
Destinationen anzeigen, pflegen und testen

Destinationen anzeigen, pflegen und testen


Um Destinationen anzuzeigen, zu erstellen oder zu ändern, wählen Sie Werkzeuge ®
Administration, Verwaltung ® Netzwerk ® RFC Destinationen.
Entfernte Destinationen werden in Tabelle RFCDES gespeichert. Die Tabelle RFCDES
beschreibt logische Destinationen für entfernte Funktionsaufrufe (RFCs).
Sie können die Tabelle RFCDES nicht direkt pflegen.

Sie können logische Destinationen auch über den R/3-Einführungsleitfaden (IMG)


pflegen. Wählen Sie Werkzeuge ® AcceleratedSAP ® Customizing
Projektbearbeitung, SAP Referenz-IMG.
Im Einführungsleitfaden expandieren Sie folgende Hierarchiestruktur:
Basis
Application Link Enabling (ALE)
Sender- und Empfängersysteme vorbereiten
Systeme im Netzwerk konfigurieren
Zielsysteme für RFC-Aufrufe definieren

Destinationen anzeigen
Das Einstiegsbild zeigt einen Baum:

RFC-Destinationen

+ R/2-Verbindungen

+ R/3-Verbindungen

+ Interne Verbindungen

+ Logische Destinationen

+ TCP-IP-Verbindungen

+ Verbindungen über ABAP-Treiber

Unterschiedliche Verbindungstypen (z.B. Partnersysteme oder -programme) sind möglich.


Nähere Informationen finden Sie unter Destinationstypen [Seite 38].
Um eine Destination zu suchen, wählen Sie Suchen und geben Ihre Selektion an. Sie erhalten
eine Liste aller passenden Einträge. Zu jedem Eintrag können Sie alle verfügbaren Informationen
anzeigen.

Destinationen anlegen
Auf dem Einstiegsbild für Destinationen sehen Sie die Verbindungstypen und alle bestehenden
Destinationen in einer Baumstruktur.

34 April 2001
SAP AG ALE-Einführung und Administration
Destinationen anzeigen, pflegen und testen

Eine Erläuterung der verfügbaren Verbindungstypen finden Sie unter Destinationstypen [Seite
38].
Um eine neue RFC-Destination anzulegen, wählen Sie Anlegen. Es erscheint ein neues Bild mit
leeren Feldern, die Sie ausfüllen müssen.
Wenn Sie eine entfernte Destination anlegen, können Sie einen bestimmten Anwendungs-Server
oder eine Gruppe von Servern angeben, um die Systembelastung zu verteilen.
Nähere Informationen zu Destinationsparametern finden Sie unter Destinationsparameter
eingeben [Seite 36].

Bestehende Destinationen ändern


Auf dem Einstiegsbild für Destinationen (Transaktion SM59) sehen Sie die Verbindungstypen
und alle bestehenden Destinationen in einer Baumstruktur.
Um eine bestehende RFC-Destination zu ändern, wählen Sie Ändern.
Nähere Informationen zu Destinationsparametern finden Sie unter Destinationsparameter
eingeben [Seite 36].

Destinationen testen
Um eine Destination zu testen, wählen Sie aus dem Menü Test die gewünschte Funktion.
· Verbindung (auch als Drucktaste)
· Berechtigung (prüft Logon-Daten)
· Netz d. Appl.Server (liefert eine Liste der Anwendungs-Server)

April 2001 35
ALE-Einführung und Administration SAP AG
Destinationsparameter eingeben

Destinationsparameter eingeben
Zusätzlich zur RFC-Destination müssen Sie folgende Informationen eingeben:
Technische Einstellungen
· Verbindungstyp
Geben Sie einen bestehenden Verbindungtyp ein.
Eine Erläuterung der verfügbaren Verbindungstypen finden Sie unter Destinationstypen
[Seite 38].
· Trace
Um die RFC-Kommunikation zu protokollieren und in einer Datei zu sichern, markieren
Sie die Option Trace. Sie können die Datei dann mit Hilfe des Reports RSRFCTRC
sowohl im rufenden als auch im gerufenen System anzeigen.
· Lastverteilung
Wenn Sie Lastverteilung wählen, müssen Sie folgendes angeben:
- Zielsystem-ID (Um eine Liste der verfügbaren Server zu erhalten, melden Sie sich im
Zielsystem an und wählen Sie Werkzeuge ® Administration, Monitor ®
Systemüberwachung ® Server.)
- Messageserver (Melden Sie sich im Zielsystem an und wählen Sie aus dem CCMS-
Hauptmenü Steuerung/Monitoring ® Control Panel. Der Message-Server ist der
Server, der den Dienst M anbietet.)
- Gruppe (SAP Logon-Gruppe von Servern).
Sonst müssen Sie folgendes angeben:
- Zielmaschine
Den Namen einer Servermaschine des Zielsystems, den Sie als Port zum System
verwenden wollen.
- Systemnummer
Den im Zielsystem verwendeten Kommunikationsservice. Um ihn zu erhalten,
wählen Sie Werkzeuge ® Administration ® Monitor ® Systemüberwachung ®
Server.
Sicherheitsoptionen
Die folgenden Optionen sind nicht bei allen Verbindungstypen verfügbar:
· Trusted System (nur für Typ 3)
Wenn das Zielsystem ein Trusted System (Vertrauenssystem) ist, wählen Sie Yes.
Detaillierte Informationen zu Trusted Systems finden Sie unter Trusted System:
Vertrauensbeziehungen zwischen R/3-Systemen pflegen [Extern].
· SNC (Secure Network Communications, verfügbar nur für die Typen 3 und T)
Wenn Sie ein aktives SNC-unterstütztes Sicherheitssystem haben, können Sie
zusätzliche Sicherheitsoptionen aktivieren, die Sie über Destination ® SNC-Optionen
setzen müssen.
Beschreibung

36 April 2001
SAP AG ALE-Einführung und Administration
Destinationsparameter eingeben

Beschreibung des Eintrags.


Anmeldung
· Sprache
zu verwendende Systemsprache
· Mandant
Mandantennummer
· Benutzer
Benutzername für entfernte Anmeldung, falls abweichend von aktuellem Benutzernamen
· Passwort
Benutzerkennwort
· Aktueller Benutzer
Die Anmeldung am entfernten System soll unter dem aktuellen Benutzernamen erfolgen.
· Passwort unverschlüsselt (2.0)
Wenn das Zielsystem ein R/3-System mit Release 2.0 ist, darf das Kennwort nicht
verschlüsselt sein.
Unter Attribute finden Sie den Ersteller und den letzten Änderer mit den zugehörigen Daten.

April 2001 37
ALE-Einführung und Administration SAP AG
Destinationstypen

Destinationstypen
Jede Destination hat ein Feld Verbindungstyp, das über die Art der Systemverbindung Auskunft
gibt:
· R/2-Verbindungen (Typ 2)
Einträge vom Typ 2 geben R/2-Systeme an. Wenn Sie einen Eintrag vom Typ 2 anlegen,
müssen Sie nur den Host-Namen angeben; alle Kommunikationsinformationen sind
bereits in der Hintergrundinfotabelle des SAP-Gateway-Hosts gespeichert. Falls
erwünscht, können Sie Angaben zur Anmeldung machen.
Beispiel eines Namenseintrags: K50
· R/3-Verbindungen (Typ 3)
Einträge vom Typ 3 geben R/3-Systeme an. Wenn Sie einen Eintrag vom Typ 3 anlegen,
müssen Sie den Host-Namen und den Kommunikationsservice angeben. Falls
erwünscht, können Sie Angaben zur Anmeldung machen. Ab R/3-Release 3.0 können
Sie zusätzlich Lastverteilung als Option wählen.

Ab R/3-Release 3.0 können Sie einen Anwendungs-Server des R/3-Message-


Servers angeben. Dieser Anwendungs-Server wird dann entsprechend des
Lastverteilungsprozesses ermittelt. Dies gilt sowohl für RFCs zwischen zwei R/3-
Systemen als auch für RFCs zwischen einem R/3- und einem externen System.
Beispiel eines Namenseintrags: K11
· Interne Verbindungen (Typ I)
Einträge vom Typ I geben R/3-Systeme an, die mit derselben Datenbank verbunden sind
wie das aktuelle System. Diese Einträge sind vordefiniert und können nicht geändert
werden. Die Eintragsnamen entsprechen den Namen im SAP-Message-Server
(Transaktion SM51).
Beispiel eines Namenseintrags: hs0010_K11_24
- hs0010=Host-Name
- K11=Systemname (Datenbankname)
- 24=TCP-Servicename
· Logische Destinationen (Typ L)
Anstatt eine Systemverbindung anzugeben, beziehen sich Einträge vom Typ L auf eine
physikalische Destination. Dabei kann sich eine Destination vom Typ L auf weitere
Destinationen vom Typ L beziehen. Ein Eintrag vom Typ L verwendet die Informationen
aus dem Bezugseintrag und fügt eigene Informationen hinzu. Der Bezugseintrag enthält
in der Regel die Host-Informationen, während der Eintrag vom Typ L die
Anmeldeinformationen enthält. Sie können auch einen Benutzernamen, ein bestimmtes
Paßwort, eine Anmeldesprache oder einen bestimmten Mandanten angeben.
Ein Eintrag vom Typ L kann sich auf andere Einträge vom Typ L beziehen.
Beispiel eines Namenseintrags: K11_SD oder K11_01

38 April 2001
SAP AG ALE-Einführung und Administration
Destinationstypen

- K11=Name des RFCDES-Eintrags für das R/3-System K11


- SD oder 01: für die Felder Benutzer='SD_INPUT' oder Mandant='001'
· Verbindungen über ABAP-Treiber (Typ X)
Einträge vom Typ X geben Systeme an, in denen Gerätetreiber in ABAP gesondert
installiert wurden. Wenn Sie einen Eintrag vom Typ X anlegen, müssen Sie den Namen
des ABAP-Gerätetreibers angeben.
· TCP/IP-Verbindungen (Typ T)
Destinationen vom Typ T sind Verbindungen zu externen Programmen, die die RFC-
Bibliothek zum Empfang von RFCs verwenden. Die Aktivierungsart kann entweder
Anstarten oder Registrierung sein.
Bei Anstarten auf müssen Sie den Host-Namen und den Pfadnamen des Programmes
angeben, das Sie starten wollen.
Aktivierungsart Anstarten auf
Die Kommunikationsmethode hängt davon ab, wie Sie die Programmposition wählen:
- Explizitem Host
In diesem Fall wird das Programm entweder vom Standard-Gateway des Systems
oder vom explizit angegebenen Gateway (gwrd) über die entfernte Shell gestartet.
Geben Sie /etc/ping <Hostname> ein, um sicherzustellen, daß der Computer
mit dem Gateway-Prozeß auf den angegebenen Computer zugreifen kann.
Damit Sie über die entfernte Shell ein Programm auf einem anderen Computer
starten können, muß das Zielsystem bestimmte Bedingungen erfüllen.
§ Die Benutzer- ID des Gateway-Prozesses muß existieren und eine Datei mit
Namen.rhosts muß im Verzeichnis des Benutzers liegen.
§ Die Datei.rhosts muß den Namen des rufenden Computers enthalten.
Um dies zu überprüfen, melden Sie sich mit der geeigneten Benutzer-ID an dem
Computer an, der den Gateway-Prozeß enthält, und geben folgenden Benfehl ein:
remsh <Hostname> <Programmname>. Dabei müssen <Hostname> und
<Programmname> mit denen aus SM59 übereinstimmen. (Wenn Sie ein RFC-
Server-Programm ohne Parameter aufrufen, gibt der RfcAccept-Aufruf immer einen
Rückgabewert zurück (RFC_HANDLE_NULL), und das Programm bricht sofort ab.)
- Applikationsserver
Wenn Sie Applikationsserver wählen und Ihr Programm angeben, können Sie das
Programm vom SAP-Anwendungs-Server aus starten.
Stellen Sie jedoch zuerst sicher, daß der SAP-Anwendungs-Server auf das
Programm zugreifen kann und daß er die Berechtigung hat, das Programm zu
starten.
Um dies zu überprüfen, melden Sie sich mit der Benutzer-ID des SAP-Anwendungs-
Servers an (z.B. c11adm). Falls möglich, wechseln Sie in das Arbeitsverzeichnis des
SAP-Anwendungs-Servers (/usr/sap/.../D.../work) und versuchen Sie, das RFC-
Server-Programm von dort aus von Hand zu starten. (Wenn Sie ein RFC-Server-
Programm ohne Parameter aufrufen, gibt der RfcAccept-Aufruf immer einen
Rückgabewert zurück (RFC_HANDLE_NULL), und das Programm bricht sofort ab.)

April 2001 39
ALE-Einführung und Administration SAP AG
Destinationstypen

- Front End-Workstation
Wenn Sie Front End-Workstation wählen und Ihr Programm angeben, können Sie
das Programm aus dem SAPGUI starten.
Stellen Sie sicher, daß Sie mit SAPGUI auf das Programm zugreifen können.
Stellen Sie sicher, daß SAPGUI die Berechtigung hat, das Programm zu starten.
Um dies zu überprüfen, rufen Sie einfach das RFC-Server-Programm in Ihrer
Umgebung auf.
Der Aufruf des Funktionsbausteins kann auch transaktional sein (CALL FUNCTION...
IN BACKGROUND TASK DESTINATION...).
Aktivierungsart Registrierung
Wenn Sie Registrierung wählen, müssen Sie ein registriertes RFC-Programm angeben.
Mit einem SAP-Gateway können Sie ein RFC-Server-Programm unter dieser ID
registieren und dann auf RFC-Aufrufe aus anderen SAP-Systemen warten.
Beispiel eines Namenseintrags: SERVER_EXEC
· Typ M
Einträge vom Typ M sind asynchrone RFC-Verbindungen zu R/3-Systemen über CMC
(Protokoll X.400).
· Typ S
Typ S entspricht Typ 2, außer daß die Destination SNA oder APPC ist.

40 April 2001
SAP AG ALE-Einführung und Administration
Gruppendestinationen pflegen

Gruppendestinationen pflegen
Um eine gleichmäßige Lastverteilung im Zielsystem zu erreichen, müssen Sie eine Gruppe von
Anwendungs-Servern als eine RFC-Destination definieren. Die Gruppendestination kann bei der
Durchführung von Parallelverarbeitungsaufgaben nur in Verbindung mit dem asynchronen RFC
[Extern] verwendet werden.
Die auf jedem einzelnen Anwendungs-Server verfügbaren Ressourcen hängen von der aktuellen
Systembelastung ab.
So zeigen Sie RFC-Gruppen an und pflegen sie:
1. Auf dem Übersichtsbild über die RFC-Destinationen wählen Sie RFC ® RFC-Gruppen.
Sie sehen dann
- die Namen aller bereits definierten RFC-Gruppen
- eine Liste der Instanzen in Ihrem R/3-System (Host, System- und Instanznummer)
- den aktuellen Status (aktiv oder nicht) eines jeden Servers.
2. Um eine RFC-Gruppe zu definieren, wählen Sie Bearbeiten ® Anlegen. Im folgenden
Dialogfenster geben Sie einen Server-Gruppennamen und eine Instanz ein.
Um Instanzen zu einer bestehenden Gruppe hinzuzufügen, klicken Sie zweimal auf die
entsprechende Gruppe und geben im nachfolgenden Dialogfenster die neue Instanz ein.
Sie können einen Server auch zu mehreren Gruppen zuordnen, indem Sie Einträge
doppelt anlegen. Jobs, die diese Gruppen verwenden, werden dann auf dem oder den
gemeinsam genutzten Server(n) um freie Arbeitsprozesse streiten.

Beispiele zur Verwendung:


Sie können Gruppen einsetzen, um verschiedene parallelverarbeitete Jobs zur
selben Zeit laufen zu lassen, ohne daß sie sich um denselben Server streiten. Dazu
müssen Sie für die von den Jobs verwendeten unterschiedlichen Gruppen
unterschiedliche Server angeben.
Sie können Gruppen auch dazu verwenden, um die Verarbeitung von den Servern
fernzuhalten, auf denen Benutzerdialoge aktiv sind. In diesem Fall müssen Sie für
die zur Verarbeitung verwendeten Gruppen andere Server angeben als in den
Anmeldegruppen für Benutzer.

April 2001 41
ALE-Einführung und Administration SAP AG
RFC-Destinationen für synchrone Methodenaufrufe

RFC-Destinationen für synchrone Methodenaufrufe


Verwendung
Ab R/3 Release 4.0 können Sie auch synchrone Schnittstellen in ALE-Verteilungsszenarien
nutzen.
Bei diesen Schnittstellen handelt es sich entweder um BAPIs oder um Dialogmethoden. In jedem
Fall handelt es sich um eine Objektmethode aus dem BOR, die als API-Methode gekennzeichnet
ist und durch einen RFC-fähigen Funktionsbaustein implementiert wird. Dieser Funktionsbaustein
wird dann per synchronem RFC gerufen.
Sie können festlegen, welche RFC-Destinationen für verschiedene synchrone Methodenaufrufe
verwendet werden sollen.

Um eine Kompatibilität zu vorangehenden Releases zu gewährleisten, wird die


Standard RFC-Destination für BAPI-Aufrufe auch für den Aufruf der folgenden RFC-
fähigen Funktionsbausteine verwendet, die nicht einer Objetktmethode im BOR
zugeordnet sind:
· COHR_ORDER_CONF_MAINTAIN_RFC
· COHR_ORDER_CONF_GET_RFC
· COHR_ORDER_CONF_DETAILS_RFC
· RP_REMITTANCE_ACKNOWLEDGEMENT
· HRTIM_AA_DOC_SHOW

Vorgehensweise
RFC-Destinationen für synchrone Methodenaufrufe können Sie über den R/3-
Einführungsleitfaden pflegen:
Basis
Application Link Enabling (ALE)
Sender und Empfängersysteme vorbereiten
Systeme im Netzwerk konfigurieren
Synchrone Verarbeitung
Folgende Arten von RFC-Destinationen können Sie pflegen:
· Die Standard RFC-Destination für BAPI-Aufrufe verwendet eine fest eingetragene
Benutzerkennung, die im Server-System vom Typ CPIC ist und nur über die
Berechtigungen verfügt, die BAPI-Aufrufe über ALE durchzuführen. Die dazu
notwendigen Berechtigungen sind allesamt unkritisch. Daher sind über diese
Benutzerkennung keine unbefugten Zugriffe möglich.
· Die Standard RFC-Destination für Dialog-Aufrufe verwendet eine fest eingetragene
Benutzerkennung, die im Server-System vom Typ DIALOG ist und nur über die
Berechtigungen verfügt, die Dialog-Aufrufe über ALE durchzuführen. Die dazu
notwendigen Berechtigungen sind allesamt unkritisch. Daher sind über diese
Benutzerkennung keine unbefugten Zugriffe möglich.

42 April 2001
SAP AG ALE-Einführung und Administration
RFC-Destinationen für synchrone Methodenaufrufe

Einzelheiten zu Dialogmethoden finden Sie im ALE-Programmierleitfaden unter


Integration von Dialogschnittstellen [Extern].
· Für spezielle Methoden (BAPIs oder Dialogmethoden), die vor unbefugtem Zugriff
geschützt werden müssen, wird auf dem Client-System eine eigene RFC-Destination
angelegt.
Die Voraussetzung dafür ist, daß das Client-System auf dem Server-System als Trusted
System eingetragen ist (siehe Remote Communications, Trusted System:
Vertrauensbeziehungen zwischen R/3-Systemen [Extern]).
In dieser RFC-Destination wird keine Benutzerkennung und auch kein Kennwort
eingetragen. Diese RFC-Destination wird den abzuschottenden Methoden zugeordnet.
Für die Anmeldung am Server-System wird dann die aktuelle Benutzerkennung auf dem
Client-System verwendet. Die Methode kann nur gerufen werden, wenn der Benutzer
eine Berechtigung dafür hat (Berechtigungsobjekt S_RFCACL).
Im Einzelfall kann eine andere Zuordnung erforderlich sein.

Beispiel
Das ALE-Szenario besteht aus zwei Systemen:
· AC
Im System AC gibt es 200 Online-Benutzer, darunter einen mit der Benutzerkennung
CEO.
Das System AC soll im System HR einige Methoden synchron aufrufen.
Nur dem Benutzer CEO soll es erlaubt sein, die Methode Document.Display "remote" im
System HR aufzurufen.
· HR
Im System HR gibt es nur einen Online-Benutzer mit der Benutzerkennung CEO.
Die folgenden Methoden sollen vom System AC synchron aufgerufen werden:
- Document.ReadInfo (synchrones BAPI, wird über RFC gerufen)
- Document.Check (synchrones BAPI, wird über RFC gerufen)
- Document.Display (Dialogmethode, wird nur von Benutzer CEO über RFC gerufen)

Benutzerstammsätze
Im System HR wird neben dem Benutzer CEO ein Benutzer ALE_AC angelegt.
ALE_AC ist vom Typ CPIC, also kein Dialog-Benutzer. Benutzer des Typs CPIC können generell
keine Dialogtransaktionen starten. ALE_AC erhält nur die Berechtigungen, die den Remote-
Aufruf der Methoden Document.ReadInfo und Document.Check ermöglichen.

RFC-Destinationen
In beiden Systemen wird der Profilparameter auth/rfc_authority_check für die RFC-
Berechtigungsprüfung gesetzt. Dadurch wird bei jedem eingehenden RFC eine
Berechtigungsprüfung auf die Funktionsgruppe des gerufenen Funktionsbausteins durchgeführt
(Berechtigungsobjekt S_RFC).
· System HR:
Im System HR wird das System AC als Trusted System eingerichtet.

April 2001 43
ALE-Einführung und Administration SAP AG
RFC-Destinationen für synchrone Methodenaufrufe

In den vom Trusted System gelieferten Daten werden Systemname, Mandant,


Benutzername und andere optionale Daten gesucht und gegen die Feldwerte des
Berechtigungsobjekts S_RFCACL geprüft.
· System AC:
Im System AC sollen zwei RFC-Destinationen angelegt werden, die beide den gleichen
Applikationsserver des Systems HR beinhalten:
- HR_DOC
Für diese Destination sind die Benutzerkennung ALE_AC und ein Kennwort zu
hinterlegen.
- HR_BLANK
Dieser Destination wird keine Benutzerkennung zugeordnet.

RFC-Destinationen für Methoden


Im System AC wird HR_DOC als Standard-RFC-Destination für synchrone BAPI-Aufrufe aus
dem System HR eingetragen.
Für Aufrufe der Methode Document.Display des Systems HR wird die RFC-Destination
HR_BLANK eingetragen.

Ergebnis
Durch dieses Vorgehen erreichen Sie folgende Ergebnisse:
· Ein gut abgeschirmtes Empfangssystem HR.
· Das Kennwort des Benutzers CEO wird nicht übertragen.
· Keine unnötigen Online-Benutzer im System HR.
· Da keine Standard RFC-Destination für Dialogaufrufe hinterlegt wurde, ist
Document.Display die einzige Dialogmethode, die vom System AC aus gerufen werden
kann.
· Bei einem Release-Wechsel kann es nicht vorkommen, daß ungewollt Methoden im
System HR aufgerufen werden. Die Berechtigungen der Benutzer im System HR lassen
dies nicht zu.

Weitere Informationen
· Bei einem asynchronen Aufruf eines BAPIs wird die RFC-Destination in der
Partnervereinbarung für den zugehörigen Nachrichtentyp hinterlegt.
· Einzelheiten zur Destinationspflege und zu Trusted Systems finden Sie in der
Dokumentation Remote Communications:
- Entfernte Destinationen pflegen [Seite 33]
- Trusted System: Vertrauensbeziehungen zwischen R/3-Systemen [Extern]

44 April 2001
SAP AG ALE-Einführung und Administration
Technische Grundlagen zu ALE-Geschäftsprozessen

Technische Grundlagen zu ALE-Geschäftsprozessen


Definition
ALE-Geschäftsprozesse sind ausgearbeitete Anwendungsfälle des Application Link Enabling.

Verwendung
Die ALE-Geschäftsprozesse der Standardauslieferung decken wichtige Anwendungsfälle für
Verteilung betriebswirtschaftlicher Funktionen und Prozesse ab. Sie sind vorkonfiguriert und ihre
Benutzung wird durch das Customizing des ALE sowie der Anwendungen erleichtert.
ALE-Geschäftsprozesse existieren für folgende Verteilungsaufgaben:
· Customizing-Datenabgleich zwischen Sytemen [Seite 46]
· Stammdatenverteilung [Seite 50]
Darüber hinaus erlaubt ALE die R/2-Anbindung [Seite 65] und die Anbindung von
Fremdsystemen [Seite 67].
Automatische Tests erlauben es, die Qualität der ALE-Schicht und der ALE-Szenarien mit Hilfe
der CATT-Umgebung zu überprüfen. Einzelheiten dazu finden Sie im ALE-Programmierleitfaden
unter Automatische Tests [Extern].
Betriebswirtschaftliche Einzelheiten zu den Prozessen finden Sie in der ALE-Geschäftsprozess-
Bibliothek [Extern].

April 2001 45
ALE-Einführung und Administration SAP AG
Customizing-Datenabgleich zwischen Systemen

Customizing-Datenabgleich zwischen Systemen


Im Rahmen der Synchronisation der Customizing-Daten geht es um zwei Themen:
· Welche Customizing-Daten müssen zwischen Systemen abgeglichen werden?
· Wie wird die Synchronisation technisch vorgenommen?
Customizing-Daten sind alle Daten, die über das Customizing eingestellt werden.
Hierzu gehören beispielsweise die Organisationseinheiten (Buchungskreis, Sparte, Werk),
Maßeinheiten und viele weitere im System einzustellende Parameter.
Grundvoraussetzung für den Datenaustausch zwischen zwei R/3-Systemen ist ein in bestimmten
Bereichen gleiches Customizing der beiden R/3-Systeme.
Innerhalb eines ALE-Systemverbunds können Sie ein zentrales Pflegesystem definieren, in dem
bestimmte Customizing-Datenobjekte zentral gepflegt werden. Von dem zentralen System aus
werden die Customizing-Daten in die zu synchronisierenden Systeme transportiert.

Synchronisation von ALE-Customizing-Daten

Customizing/Referenz- Qualitätssicherungs- Produktiv-


Systeme Systeme Systeme

Customizing-Aufträge
Transport- Logisches Änderbar Freigegeben Logisches Logisches
schicht A System DA System QA System PA

Synchronisation
Customizing-Aufträge selektieren
von ALE-Customizing- ALE-Aufträge generieren
Daten
Verteilungsmodell
ALE-
Log.Sys DA
Aufträge
CONDA2 Log.Sys DB CONDA2
(Transport
Verteilungsgruppe von Kopien)
• Customizing-Objekt 1
:
Customizing-Objekt n

Objektsperre Import der ALE-Aufträge Konsolidierung

Transport- Logisches Logisches Logisches


schicht B System DB System QB System PB

Die Synchronisation der Customizing-Daten gliedert sich wie folgt:


· Modellierung
Ein zentrales Modellierungselement ist die ALE-Verteilungsgruppe. ALE-
Verteilungsgruppen enthalten mandantenabhängige Customizing-Objekte der Kategorie
CUST.
Für Ihre eigenen Customizing-Tabellen müssen Sie jeweils einen Eintrag in der
Verwaltungstabelle der Customizing-Objekte (Transaktion SOBJ) vornehmen. Solche
Einträge werden automatisch vorgenommen, wenn Sie für Ihre Customizing-Tabellen
eine Pflegeoberfläche mit dem Tabellenpflegegenerator erstellen (Werkzeuge ®

46 April 2001
SAP AG ALE-Einführung und Administration
Customizing-Datenabgleich zwischen Systemen

Entwicklung ® Dictionary ® Hilfsmittel ® Tabellenpflegegenerator, oder


Transaktionscode SE11).
ALE-Verteilungsgruppen müsssen Sie mit Hilfe des Customizing (R/3-
Einführungsleitfaden) in dem System definieren, das auch das Pflegesystem der
Verteilungsgruppe sein soll:
Basis ® Application Link Enabling (ALE)
Geschäftsprozesse modellieren und implementieren
Synchronisation von Customizing-Daten konfigurieren

Die Verteilung wird in den Releases vor 4.6A mit dem Nachrichtentyp CONDAT
modelliert. Dabei müssen die zu verteilenden Customizing-Daten (Steuerdaten) als
Filterobjekte dieses Nachrichtentyps definiert werden.
Die alte und die neue Modellierung können Sie nicht parallel verwenden.
Aus diesem Grund müssen Sie im ALE-Einführungsleitfaden für bestehende
Customizing-Objekte mit einem Werkzeug Verteilungsgruppen generieren.

Sie können für jede Verteilungsgruppe einen eigenes Pflegesystem definieren.


· Transport-Management
Über die ALE-Administration können Sie ALE-Transportaufträge zur Synchronisation der
Customizing-Daten zwischen Systemen wie folgt bearbeiten:
- Im Sendersystem:
ALE-Aufträge generieren
- Im Empfängersystem:
ALE-Aufträge importieren, mit Workflow-Anbindung
ALE-Aufträge konsolidieren und weiterleiten

April 2001 47
ALE-Einführung und Administration SAP AG
Zu synchronisierende Customizing-Daten

Zu synchronisierende Customizing-Daten
Welche Customizing-Datenobjekte in einem konkreten Verteilungsfall abzugleichen sind, hängt
vom eingesetzten ALE-Geschäftsprozess ab.
Neben den eingesetzten ALE-Geschäftsprozessen spielt auch die "Verteilungsphilosophie" Ihres
Unternehmens eine entscheidende Rolle. "Zentralisten" wollen eher zuviel als zu wenig zentral
pflegen - "Individualisten" wollen so wenig zentrale Zuständigkeiten wie möglich.
SAP bietet Ihnen folgende zwei Möglichkeiten an, einen Customizing-Objektvergleich
vorzunehmen:
· Systemübergreifender Customizing-Objektvergleich
Den Objektvergleich können Sie in der ALE-Administration (Dienste ® Customizing-
Daten ® Customizing Cross System Viewer) durchführen.

Wenn eines der beteiligten Systeme einen Release-Stand vor 4.6A hat, müssen Sie
für den Objektabgleich ein Werkzeug des ALE-Einführungsleitfadens nutzen
(Geschäftsprozesse modellieren und implementieren ® Synchronisation von
Customizing-Daten konfigurieren ® Modellierung vor Release 4.6A (mit CONDAT)
® Konsistenz der Customizing-Verteilung prüfen). Damit können Sie durch eine
Repository-Auswertung für einem konkreten Verteilungsfall eine Liste von
abzugleichenden Customizing-Datenobjekten erhalten.
· Zu jeder Einstellung, die Sie im Rahmen des ALE-Einführungsleitfadens vornehmen,
können Sie im System erfahren, welches das zugehörige Customizing-Objekt ist.
Bitte beachten Sie bei der Untersuchung:
· Sie sollten die gesamte Organisationsstruktur Ihres Unternehmens wenn möglich zentral
pflegen.
· Beziehen Sie zukünftige Überlegungen bzgl. des Einsatzes von Verteilunsszenarien
frühzeitig ein. Einmal "auseinander gelaufene" Systeme sind nur sehr schwer wieder
"gleichzuschalten".
Wenn Sie wissen, welche Customizing-Datenobjekte Sie zwischen den Systemen abgleichen
wollen, müssen Sie festlegen, wie die Verteilung konkret erfolgen soll.
Im Regelfall werden Sie zu einer recht zentralistisch geprägten Sicht kommen, d.h., Sie
definieren ein zentrales Pflegesystem für alle abzugleichenden Customizing-Daten.

48 April 2001
SAP AG ALE-Einführung und Administration
Technischer Ablauf der Verteilung vor 4.x

Technischer Ablauf der Verteilung vor 4.x


Zur Pflege der Konfigurationsdatenverteilung werden im Verteilungsmodell Filterobjekte für den
Nachrichtentyp CONDAT eingetragen. Die Pflege der Konfigurationsdatenverteilung im
Verteilungsmodell und die nachfolgende Verteilung des Verteilungsmodells hat folgende
Auswirkungen:
· Konfigurationsdaten werden mit Hilfe des Korrektur- und Transportwesens vom
Pflegesystem an die im Verteilungsmodell eingetragenen Empfängersysteme verteilt.
· In Systemen, die als Empfänger von Konfigurationsdatenobjekten eingetragen sind, ist
die Pflege dieser Konfigurationsdatenobjekte gesperrt. Nur die an ein System verteilten
Konfigurationsdatenobjekte sind nicht betroffen.

Pflege von Konfigurationsdaten


Wenn Sie Konfigurationsdaten pflegen, werden Ihre Änderungen vom Korrektur- und
Transportwesen protokolliert. Sie benötigen aus diesem Grund einen Änderungsauftrag. Nach
beendeter Pflege wird der Änderungsauftrag freigegeben und steht damit zum Transport bereit.
Bei der Freigabe des Transportauftrags wird auf der Basis des Verteilungsmodells geprüft, ob
andere Systeme an den Konfigurationsdatenobjekten des Transportauftrags interessiert sind. Ist
dies der Fall, so wird die Transaktion BD77 mit dem Transportauftrag als Parameter aufgerufen,
und dem Benutzer werden alle Objekte in einer Liste angezeigt. Für das weitere Vorgehen
bestehen zwei Optionen:
1. Für jedes System wird ein Transportauftrag generiert, der genau die Objekte enthält, die
durch die Schnittmenge aus Verteilungsmodell (Nachrichtentyp CONDAT) und dem
gerade freigegebenen Auftrag definiert werden. Dieser Transportauftrag muß freigeben
und transportiert werden.
2. Zu jedem System kann ein IDoc des Nachrichtentyps CONDAT geschickt werden, das im
Zielsystem ein Workflow-Item erzeugt. Der Bearbeiter dieses Workflow-Items sieht dann
alle Objekte in einer Liste (analog zur Transaktion BD77) und kann für jedes Objekt den
Standardtabellenabgleich in der SM30 bzw. SCU0 starten. Dieser Abgleich muß dann
manuell durchgeführt werden.
Es wird empfohlen, nach Option 1 vorzugehen und zusätzlich den Administrator nach Option 2 zu
informieren, ohne daß dieser einen manuellen Tabellenabgleich durchführt.

April 2001 49
ALE-Einführung und Administration SAP AG
Stammdatenverteilung

Stammdatenverteilung
Es wird nicht die gesamte Stammdateninformation verteilt, sondern Sichten darauf (z.B.
Materialvertriebsdaten, Materialeinkaufsdaten). Jede zu verteilende Stammdatensicht wird in
einem eigenen Nachrichtentyp abgelegt.
Der Anwender kann die zu verteilenden Datenelemente zu einem Stammsatz selbst bestimmen.
Verschiedene Verteilungsstrategien [Seite 51] werden unterstützt:
· Systemübergreifende Stammdaten können zentral gepflegt und anschließend verteilt
werden. Die konkrete Ausprägung erfolgt lokal.
· Eine Sicht auf die Stammdaten wird lokal gepflegt. Dabei existiert immer ein
Pflegesystem für die jeweilige Sicht. Die gepflegten Stammdaten werden auf ein
zentrales R/3-System übertragen und von dort aus verteilt.

Verteilungsarten
· Aktive Verteilung (PUSH)
Bei einer Änderung in den Stammdaten (Neuanlage, Ändern, Löschen) wird im
Originalsystem ein Stammdaten-IDoc erzeugt und gemäß Verteilungsmodell und Klassen
verteilt.
· Anfordern (PULL)
Bei einer Anforderung benötigt das Client-System Informationen zu den im System
vorhandenen Stammdaten. Der Anforderer kann zu einem Stammdatum Informationen
auswählen. So ist es z.B. möglich, für ein Material die Werksdaten anzufordern.
Besteht der Wunsch, auch später mit Änderungen dieses Stammdatums versorgt zu
werden, muß das noch organisatorisch zwischen beiden Systemen geregelt werden. Es
ist noch nicht möglich, durch die Anforderung automatisch in einen Verteiler im
Originalsystem aufgenommen zu werden.

Übertragung von Stammdaten


Grundsätzlich wird bei der Übertragung von Stammdaten zwischen Gesamtübertragung und
Übertragung von Änderungen unterschieden.
Bei einer Gesamtübertragung wird auf direkte Anforderung eines Systems das komplette Master-
IDoc für das zu verteilende Objekt erstellt. Es werden nur die angeforderten Daten gelesen und
anschließend versendet. Der Kunde bestimmt durch einen Anforderungsreport den Umfang des
zu verteilenden Objektes.
Bei einer Übertragung von Änderungen wird das Master-IDoc anhand der protokollierten
Änderungen erstellt.

50 April 2001
SAP AG ALE-Einführung und Administration
Strategien der Stammdatenverteilung

Strategien der Stammdatenverteilung


Die folgende Abbildung stellt ein Beispiel einer Stammdatenverteilung dar.

Pflege- und Referenzsystem Pflegesystem Pflegesystem

A, B, C A, B C, D

Referenz- A, B, C, D
system

A, B B, C A, B, D B, C A, D

Client-Systeme Client-Systeme

Auf der linken Seite der obigen Abbildung ist der einfachste Fall abgebildet:
· Sämtliche Stammdaten werden in einem zentralen System angelegt und von dort aus auf
lokale Systeme verteilt.
Zum Beispiel werden Materialien A, B und C zentral angelegt; A und B werden auf ein
System verteilt, während B und C auf ein zweites System verteilt werden.
Rechts wird eine dreistufige Hierarchie abgebildet:
· Stammdaten dürfen in mehreren Systemen angelegt werden; es wird aber ein zentrales
R/3-System als Referenz für andere Systeme verwendet.
Zum Beispiel werden Materialien A und B in einem System angelegt, während C und D in
einem zweiten System angelegt werden. In allen Fällen werden die Materialien auf das
Referenzsystem verteilt. Von dort aus werden sie auf die entsprechenden Client-
Systeme verteilt.
Grundsätzlich können Stammdaten von jedem an jedes System verteilt werden. Das zentrale
System ist nicht unbedingt erforderlich, es vereinfacht jedoch die Organisation der
Stammdatenverteilung.

April 2001 51
ALE-Einführung und Administration SAP AG
Stammdatenverteilung über Klassifizierung

Stammdatenverteilung über Klassifizierung


Klassen werden im Rahmen der Stammdatenverwaltung eingesetzt, wenn die Verteilungsregeln
nicht über Organisationseinheiten abbildbar sind. Es existieren Klassen für Material-, Kunden-
und Lieferantenstammdaten.
Für Kostenstellen und Sachkonten gibt es keine Klassifizierung, eine Verteilung über Klassen ist
daher nicht möglich. Da in diesen Fällen die Datenmengen klein sind, können alle Daten an alle
Systeme verteilt werden. Eine Filterung nach Organisationseinheiten ist zusätzlich möglich.
Anhand von Klassen werden Stammdatenobjekte definiert, an denen ein System interessiert ist.

Das R/3-System HAMBURG interessiert sich für alle Einkaufsdaten in der Klasse
WHOLE in der das Großhandelssortiment zusammengefaßt ist und für alle in
Süddeutschland verkauften Materialien der Klasse SOUTH.
Für jeden Objekttyp kann eine vom Kunden definierte Klassenart als ALE-relevant angegeben
werden. Alle Klassen dieser Klassenart können in den Klassen verwendet werden
Die Klassenpflege erfolgt im Rahmen der Stammdatentransaktionen. Ein Stammdatenobjekt wird
einer Klasse hinzugefügt, indem es klassifiziert wird.

52 April 2001
SAP AG ALE-Einführung und Administration
IDocs für Stammdaten

IDocs für Stammdaten


Maximal-IDoc
Ein von SAP festgelegtes Maximal-IDoc enthält möglichst umfassend alle verteilbaren
Informationen zu einem Objekt. Die Struktur ist eng an die Tabellenstruktur im R/3 angelehnt.

Erzeugen eines reduzierten IDocs


Aus einem Maximal-IDoc kann entsprechend der Kundenbedürfnisse ein reduziertes IDoc
erzeugt werden.

Anforderungsbild
Anforderungsbild
Nachrichtentyp MATMAS01 Bei Neuanlage wird neuer
Nachrichtentyp dem IDoc-Typ
Ref. Nachr.-typ MATMAS zugeordnet

Strukturdarstellung
Strukturdarstellung
Segmente des IDOCs können
MATMAS01 deaktiviert werden.

E1MARAM allgemeine Daten

E1MAKTM Kurztexte
Feldliste
E1MARAM Umrechnung Feldliste E1MARAM
E1MARAC Werkdaten MATNR Materialnummer Felder eines
Segmentes können
MTART Materialart deaktiviert werden.
MBRSH Branche

MATKL Warengruppe

WRKST Werkstoff

In einer aus dem Customizing des ALE gestarteten Transaktion wird die Struktur des IDocs
angezeigt. Segmente und auch Felder können durch Anklicken deaktiviert werden. Mußfelder
können jedoch nicht reduziert werden.
Die Erzeugung eines reduzierten IDocs aus einem Maximal-IDoc bedeutet, daß ein neuer
Nachrichtentyp generiert und diesem IDoc zugeordnet wird. Die Referenz auf den Nachrichtentyp
des Maximal-IDocs bleibt erhalten (z.B. Beim Material kann der neue Nachrichtentyp MATSMD
sein, der Referenz-Nachrichtentyp ist MATMAS.)
Dieses IDoc mit dem neuen Nachrichtentyp ist jetzt statt des Maximal-IDocs für die
Kommunikation vorgesehen. Es erfolgt eine automatische Zuordnung zu den Änderungsbelegen.

Beim Versenden von IDocs des Typs MATMAS02 werden die Segmente E1MKALM
(Fertigungversion) gefüllt und gesendet, jedoch von einem empfangenden R/3-

April 2001 53
ALE-Einführung und Administration SAP AG
IDocs für Stammdaten

System ignoriert. Fremdsystemen stehen diese Daten uneingeschränkt zur


Verfügung.
Geänderte Kurz- und Langtexte für Stammdaten werden verteilt und im Empfänger
gebucht. Löschungen von Texten werden nicht übertragen.

54 April 2001
SAP AG ALE-Einführung und Administration
Stammdatenverteilung mit dem SMD-Werkzeug

Stammdatenverteilung mit dem SMD-Werkzeug


Änderungen an Stammdatenobjekten werden über das SMD-Werkzeug (Shared Master Data)
verwaltet. Das SMD-Werkzeug dient der Verteilung von Stammdatenänderungen an dezentrale
Systeme.
Das Werkzeug faßt Änderungen zeitlich und inhaltlich zusammen:
· Zum einen werden mehrere Änderungen an einem Stammdatenobjekt, die im SAP R/3
über mehrere Transaktionen durchgeführt und in mehreren Tabellen verstreut abgelegt
sind, zu einer Änderung an dem Stammdatenobjekt zusammengeführt.
· Zum anderen werden mehrere zeitlich aufeinanderfolgende Änderungen zu einer
einzigen zu verteilenden Änderung zusammengefaßt.

Anwendungs- Änderungsbeleg- ALE-Schicht


buchung dienst

SMD
Customizing

Stammdaten
SMD-Tool
anlegen/ändern
Änderungsbeleg Standard-ALE-
erzeugen ALE-Felder ? Ausgang

Zeiger schreiben

Hintergrund-Job / manuell

IDocs erzeugen M CC
C

Stammdaten Änderungsbelege Änderungszeiger

Das SMD-Werkzeug ist an die Änderungsbelegschnittstelle angeschlossen. Ist ein Stammdatum


verteilungsrelevant, schreibt die Anwendung einen Änderungsbeleg. Der Inhalt wird an das SMD-
Werkzeug übergeben. Das Werkzeug schreibt Änderungszeiger, liest die Anwendungsdaten und
erzeugt das Master-IDoc.
Das Master-IDoc wird von der ALE-Schicht übernommen und an interessierte Systeme
versendet.

April 2001 55
ALE-Einführung und Administration SAP AG
Beispiel für die Stammdatenverteilung

Beispiel für die Stammdatenverteilung


Die Stammdatenverteilung soll am Beispiel der Materialstammpflege erläutert werden. Alle
Szenarien der Stammdatenverteilung sind analog zur Materialstammdatenverteilung aufgebaut.

NachrTyp (Sicht) Filterobjekte Listung

Werk VkOrg VtWeg

Gesell. Sparte WarGrp

Materialstamm Materialstamm
Original Kopieverwaltung

Anforderung Materialstamm Materialstamm Materialstamm Materialstamm Anforderung


bearbeiten versenden empfangen anfordern versenden bearbeiten

MATMAS MATMAS

MATFET MATFET

Die Funktionstypen Materialstammpflege und Materialstammpflege-Kopie liegen in verteilten


Systemen.
Die Kopieverwaltung befindet sich bei zentraler Pflege direkt im dezentralen System. Bei
mehreren Pflegesystemen (z.B. je Sicht auf das Material) ist die Kopieverwaltung auf dem
Referenzsystem. Dieses verteilt dann die Stammdatenänderungen auf alle anderen dezentralen
Systeme.
Zwischen diesen Funktionstypen werden Nachrichten übermittelt.
· Beim PUSH-Prinzip erfolgt die Kommunikation mit dem Nachrichtentyp MATMAS (Diese
Nachricht enthält zu verteilende Daten des Materialstamms).
· Beim PULL-Prinzip wird zwischen der Materialstamm-Kopieverwaltung und dem
Materialstammpflege-Original die Nachricht MATFET übermittelt. (Diese Nachricht ist
eine Aufforderung an das Original, Materialstammdaten zu senden.)
Folgende Filter steuern die Verteilung:
· Klassen [Seite 52] (z.B. klassifizierte Materialnummern für die Verteilung an bestimmte
Systeme).
· Filterobjekte: Organisationseinheiten (Verkaufsorganisation, Werk).
Als Teil des Customizing des ALE legt der Kunde im Verteilungsmodell pro Nachrichtentyp fest,
welche Felder in welcher Anwendungstabelle verteilungsrelevant sind.

56 April 2001
SAP AG ALE-Einführung und Administration
Beispiel für die Stammdatenverteilung

Verteilungsmodell Materialstammdatenverteilung. Es wird das Filterobjekt "Werk"


verwendet. Da im System LYON Werk 001 verwaltet wird, erhält LYON die
Materialstammdaten für Werk 001.

Beispiel:
Maschinenbau- und
Buchhaltunssichten
Materialstamm
Materialstamm
Original
Original

System
SystemLyon
Lyonerhält
erhältDaten
Daten System
SystemRom
Romerhält
erhältDaten
Daten
nur
nurfür
fürWerk
Werk0001
0001 nur
nurfür
fürWerk
Werk0002
0002

Werk
Werk Werk
Werk

Materialstamm
Materialstamm Materialstamm
Materialstamm
Kopieverwaltung
Kopieverwaltung Kopieverwaltung
Kopieverwaltung

Prüfung auf Verteilungsrelevanz


Der Inhalt des Änderungsbelegs wird vom Änderungsbelegwesen an das SMD-Tool
weitergereicht. Pro Belegposition wird überprüft, ob die Kombination aus geändertem Feld und
Tabelle einem Nachrichtentyp zugeordnet ist.

Änderungszeiger schreiben
Sind die Felder verteilungsrelevant, werden vom SMD-Tool Änderungszeiger geschrieben und in
den Tabellen BDCP und BDCPS abgelegt. Änderungszeiger sind im wesentlichen die
Schlüsselfelder der Tabelle, in der sich das geänderte Feld befindet. Über das Customizing des
ALE kann der Kunde die verteilungsrelevanten Felder festlegen.
Eine Erzeugung von Änderungszeigern findet nur statt, wenn sowohl ALE als auch der
Nachrichtentyp aktiv sind.

Versenden von Änderungen


Zum Verteilen von geänderten Stammdaten müssen die Änderungszeiger weiterverarbeitet
werden. Dabei werden, abhängig vom Nachrichtentyp, Stamm-IDocs erzeugt und zum
Versenden an die ALE-Schicht weitergegeben.
Dazu dient das Program RBDMIDOC. Üblicherweise wird RBDMIDOC automatisch durch einen
Hintergrund-Job ausgeführt, wobei ein Hintergrund-Job pro Nachrichtentyp einzuplanen ist.
Abhängig von der Einstellung der Partnervereinbarungen kann es notwendig sein, das
Versenden von IDocs durch Ausführen des Programms RSEOUT00 explizit anzustoßen. Im

April 2001 57
ALE-Einführung und Administration SAP AG
Beispiel für die Stammdatenverteilung

Hintergrund-Job, der RBDMIDOC ausführt, kann dies in einem zweiten Schritt geschehen.
Weitere Informationen zu diesen Funktionen finden Sie im R/3-Einführungsleitfaden:
Basis
Application Link Enabling (ALE)
Geschäftsprozesse modellieren und implementieren
Verteilung von Stammdaten konfigurieren
Replikation von geänderten Daten einrichten
IDoc-Erzeugung aus Änderungszeigern einplanen

Für den Aufbau des Master-IDocs gelten folgende Regeln:


· Das Master-IDoc beinhaltet alle IDoc-Segmente, in deren Feldern eine
Änderung aufgetreten ist.
· Das Master-IDoc beinhaltet alle Mußsegmente des IDocs.
· Die diesen Segmenten übergeordneten Muttersegmente werden versendet.
· Die IDoc-Segmente werden vollständig verschickt, d.h. alle Felder werden
mit Daten gefüllt.

Hinweis für das Einlesen von Änderungen


Beim Stammdateneingang kann man verhindern, daß Senderfelder auf Felder im
Empfangssystem eingespielt werden. Wie diese Einstellung vorgenommen werden kann,
erfahren Sie im Customizing:
Basis
Application Link Enabling (ALE)
Geschäftsprozesse modellieren und implementieren
Datenumsetzung zwischen Sender und Empfänger einstellen

Bei IDocs der Nachrichtentypen MATMAS, DEBMAS oder CREMAS sowie allen
anderen IDocs die ein CALL TRANSACTION bei der Eingangsverarbeitung
vewenden, werden Felder im empfangenden R/3-System nicht überschrieben, wenn
im entsprechenden IDoc-Feld die Konstante "/" steht.

58 April 2001
SAP AG ALE-Einführung und Administration
Verteilbare Stammdatenobjekte

Verteilbare Stammdatenobjekte
Folgende Stammdatenobjekte sind verteilbar:
· Änderungsnummer
· Artikelstammsatz
· Benutzerstammsatz
· Einkaufsinfosatz
· Geschäftsprozess
· Klassifizierung, Klasse, Merkmal,
· Konditionen
· Kostenstelle
· Kostenstellen-GruppeWeitere
· Kostenarten-Gruppe
· Kostenart
· Kundenstammsatz
· Leistungsart
· Leistungsstammsatz
· Leistungsarten-Gruppe
· Lieferantenstammsatz
· Materialstammsatz
· Mengeneinheit für die Kombination Kostenstelle/Kostenart
· Orderbuch
· Personalwirtschaft: Personalstammdaten, Organisationsdaten
· Profit-Center
· Sachkonto
· Stückliste (Materialien und Dokumente)
· Tarife für die Kombination Kostenstelle/Kostenart
· Werte- und Quotenleisten
Im folgenden werden einige dieser Stammdatenobjekte näher erläutert:

Änderungsnummer
Die Verteilung einer Änderungsnummer über den Nachrichtentyp ECMMAS beinhaltet folgende
Informationen:
· Änderungsstammsatz (mit Langtext, wenn vorhanden)
· Datumselemente

April 2001 59
ALE-Einführung und Administration SAP AG
Verteilbare Stammdatenobjekte

· Gültigkeiten
· Objekttypen zum Änderungsstamm
· Objektverwaltungssätze (mit Langtext, wenn vorhanden)
Die verteilte Änderungsnummer wird im Zielsystem neu angelegt falls diese hier noch nicht
existiert. Noch nicht unterstützt wird das Löschen einer Änderungsnummer auf dem Zielsystem
und die Verteilung über Änderungszeiger.

Artikelstammsatz
Einzelheiten zur Verteilung von Artikeln finden Sie im Dokument ISR - SAP Retail unter dem
folgenden Thema:
Artikel: Übernahme und Verteilung von Stammdaten [Extern]

Benutzerstammsatz
Einzelheiten zur zentralen Verwaltung von Benutzerstammsätzen finden Sie im ALE-
Einführungsleitfaden (Transaktion SALE):
Geschäftsprozesse modellieren und implementieren
Vordefinierte ALE-Geschäftsprozesse konfigurieren
Anwendungsübergreifende Geschäftsprozesse
Zentrale Benutzerverwaltung einrichten

Einkaufsinfosatz
Beim Verteilen von Einkaufsinfosätzen [Extern] über die Nachricht INFREC werden folgende
Daten übermittelt:
· allgemeine Daten und Texte für allgemeine Daten
· Einkaufsorganisationsdaten und Texte für Einkaufsorganisationsdaten
Nicht verteilt werden folgende Daten:
· Zollpräferenz-Daten
· Bestellpreisentwicklung
Voraussetzung ist, daß die Stammsätze der betroffenen Lieferanten und Materialien zuvor verteilt
wurden.
Die Nummernkreise für Einkaufsinfosätze müssen systemübergreifend abgestimmt sein:
· Beim Einkaufsinfosatz zu einem Lagermaterial wird bei der Einbuchung des IDocs die
Nummer des Einkaufsinfosatzes aus dem zentralen System übernommen, falls der
Einkaufsinfosatz zum Material und dem entsprechenden Lieferanten im Empfangssystem
nicht existiert. Andernfalls wird der bereits existierende Einkaufsinfosatz aktualisiert.
· Beim Einkaufsinfosatz zu einem Nichtlagermaterial wird immer die Nummer des
Einkaufsinfosatzes vom zentralen System übernommen. Falls ein Einkaufsinfosatz mit
dieser Nummer bereits existiert, wird geprüft, ob dieser Infosatz denselben Lieferanten
und dieselbe Warengruppe hat, wie der Infosatz aus dem zentralen System.
Bei der Einbuchung eines Einkaufsinfosatzes werden die Konditionen zum Einkaufsinfosatz nicht
verändert, es werden aber die Felder NETPR (Nettopreis) und EFFPR (Effektivpreis) im Infosatz
aktualisiert, d.h. die Werte werden vom zentralen System übernommen.

60 April 2001
SAP AG ALE-Einführung und Administration
Verteilbare Stammdatenobjekte

Konditionen zu Infosätzen müssen gesondert über die allgemeine Konditionsverteilung


(Nachricht COND_A) übermittelt werden.
Falls bei der Modellierung der Verteilung von Infosätzen das Filterobjekt Werk verwendet wird,
muß bei den werksübergreifenden Einkaufsinfosätzen das Werksfeld mit SPACE belegt sein.
Falls bei der Modellierung der Verteilung von Infosätzen das Filterobjekt Material oder
Materiallistung verwendet wird, muß bei Einkaufsinfosätzen zu Nichtlagermaterialien das
Materialfeld mit SPACE belegt sein.
Das Filterobjekt Lieferantenlistung kann bei der Verteilung von Einkaufsinfosätzen nicht benutzt
werden. Es sind nur Materiallistungen als Filterobjekte für die Verteilung von Einkaufsinfosätzen
zulässig
SAP stellt folgenden Erweiterungen zur Verfügung:
· MMAL0003: ALE Einkaufsinfosatz-Verteilung: Ausgangsverarbeitung
· MMAL0004: ALE Einkaufsinfosatz-Verteilung: Eingangsverarbeitung
Weitere Informationen zu Einkaufsinfosätzen finden Sie in der Dokumentation MM - Einkauf unter
Einkaufsinfosätze [Extern].

Geschäftsprozess
Einzelheiten zur Verteilung von Geschäftsprozessen finden Sie im Dokument CO -
Prozesskostenrechnung unter dem folgenden Thema:
Stammdaten in der Prozeßkostenrechnung [Extern]

Klassifizierung
Für den Nachrichtentyp CLFMAS müssen die Abhängigkeiten von anderen Nachrichtentypen,
wie z.B. MATMAS und CREMAS in verschiedenen Filtergruppen gepflegt werden.

Konditionen
Zum Verteilen von Konditionen [Extern] wird die Nachricht COND_A verwendet.
Felder, die reduziert wurden, werden im Empfangssystem auf initial gesetzt/geändert. Reduziert
man ganze Segmente, werden diese im Zielsystem gelöscht.
Konditionen mit Verwendung = E (=Bonus, Konditionen der nachträglichen Abrechnung) können
nur manuell und nicht über das Änderungsbelegwesen versandt werden.

Kostenstelle
Bei der Verteilung von Kostenstellen wird das Feld CV_OTYPE für den Objekttyp Joint Venture
nicht mitübertragen.

Kundenstammsatz
Adressen von Ansprechpartnern werden nicht verteilt.
Langtexte sind nicht an das Änderungsbelegwesen angeschlossen.

Leistungsstammsatz
Beim Verteilen von Leistungsstammsätzen [Extern] mit der Nachricht SRVMAS werden folgende
Daten versendet:

April 2001 61
ALE-Einführung und Administration SAP AG
Verteilbare Stammdatenobjekte

· Leistungsgrunddaten
· Kurztexte (mehrsprachig)
· Langtexte (mehrsprachig)
Die Leistungskonditionen müssen gesondert mit der Nachricht COND_A verteilt werden.
Wenn Sie Kontrakte für Leistungen verteilen möchten oder die gleichen Stammdaten zentral
pflegen möchten, damit Sie sie in anderen R/3-Systemen nutzen können, dann sollten Sie
Leistungsstammsätze verteilen.
Leistungsstammsätze bzw. deren Änderungen werden mit dem Report RBDSESRV oder mit
dem SMD-Tool verteilt.
Weitere Informationen finden Sie in der Dokumentation MM - Dienstleistung unter
Dienstleistungsstammsatz [Extern].

Lieferantenstammsatz
Bei der Verteilung von Lieferantenstammdaten werden in der Eingangsverarbeitung Mahndaten
nur zum Default-Mahnbereich eingebucht.
Wenn Sie SAP Retail einsetzen, können Sie auch Lieferantenmerkmalswerte verteilen.

Materialstammsatz
Änderungen der Materialart eines Materials können nicht verteilt werden. Die Materialart eines
Materials (Feld MTART) wird vom empfangenden R/3-System nur dann übernommen, wenn Sie
ein Material anlegen, aber nicht, wenn Sie ein Material ändern. Dadurch ist es möglich, daß ein
Material auf verschiedenen Systemen unterschiedliche Materialarten haben kann.
Das Fertigungsversionen-Segment (E1MKALM) wird nur im Ausgang verwendet. Das Einbuchen
der entsprechenden Informationen in ein R/3-System wird nicht unterstützt. Die Informationen
können jedoch von Fremdsystemen verarbeitet werden.
Weitere Informationen zur Verteilung von Materialstammsätzen finden Sie in der SAP-Bibliothek
in der Dokumentation LO - Verwaltung von Materialstammdaten unter IDoc-Typen zur Verteilung
von Materialstammdaten über ALE [Extern].

Orderbuch
Zur Verteilung von Orderbuchsätzen [Extern] wird die Nachricht SRCLST verwendet.
Voraussetzung ist, daß die Stammsätze der betroffenen Lieferanten, Materialien und ggf.
Kontrakte zuvor verteilt wurden.

Die Verteilung von Orderbuchsätzen mit Bezug auf einen Lieferplan ist nicht
unterstützt, da Lieferpläne nicht über ALE verteilt werden können.
Falls bei der Modellierung der Orderbuchverteilung das Filterobjekt Einkaufsorganisation
verwendet wird, muß bei den einkaufsorganisationsübergreifenden Orderbuchsätzen das Feld
Einkaufsorganisation mit SPACE belegt sein.
Falls bei der Modellierung der Orderbuchverteilung das Filterobjekt Lieferant verwendet wird,
muß bei lieferantenunabhängigen Orderbuchsätzen das Lieferantenfeld mit SPACE belegt sein.

62 April 2001
SAP AG ALE-Einführung und Administration
Verteilbare Stammdatenobjekte

Das Filterobjekt Lieferantenlistung kann bei der Orderbuchverteilung nicht benutzt werden. Es
sind nur Materiallistungen als Filterobjekte für die Orderbuchverteilung zulässig.
SAP stellt folgenden Erweiterungen zur Verfügung:
· MMAL0001: ALE Orderbuch-Verteilung: Ausgangsverarbeitung
· MMAL0002: ALE Orderbuch-Verteilung: Eingangsverarbeitung

Weitere Informationen zum Orderbuch finden Sie in der Dokumentation MM - Einkauf unter
Pflege des Orderbuchs [Extern].

Personalwirtschaft: Personalstammdaten, Organisationsdaten


Einzelheiten dazu finden Sie unter Stammdatenverteilung (Personalwirtschaft) [Extern].

Profit-Center
Statistische Kennzahlen werden nicht versendet.
Die Stammdaten können nur im Heimatsystem des Kostenrechnungskreises gepflegt werden

Sachkonto
Das Feld KONTOFÜHRUNG EXTERN im Buchungskreissegment wird nur bei der Neuanlage
von Sachkonten im Buchungskreis beachtet. Änderungen dieses Feldes werden nicht
eingebucht. Sie müssen aus Sicherheitsgründen manuell erfolgen.

Stückliste
Die Stückliste wird mit allen zum Stichtag gültigen Positionen und ggf. vorhandenem lokalen
Beziehungswissen verteilt. Nur einfache Stücklisten können verteilt werden.
Die Verteilung der Stückliste umfaßt nicht
· die Langtexte für Kopf, Alternative und Positionen.
· Unterpositionen
· globales Beziehungswissen. Dieses muß im Zielsystem vorhanden sein!
· die Historie der Stückliste, d.h. nur der stichtagsbezogene Zustand der Stückliste wird
verteilt.
· die Positionsobjekte der Stückliste, z.B. Materialien, Dokumente und Klassen. Diese
Objekte müssen separat und vor der Stückliste verteilt werden.
· die ggf. angegebene Änderungsnummer. Sie muß im Zielsystem vorhanden sein.
Beim direkten Senden erhält der Anwender zunächst eine der Selektion entsprechende Liste
aller vom System selektierten Stücklisten, die anschließend manuell bearbeitet werden kann. Da
nur einfache Stücklisten verteilt werden können, werden die ggf. angezeigten Alternativ-
/Varianten-Stücklisten, Werkszuordnungen und konfigurierten Materialien nicht zur Verteilung
angeboten.
Das im Selektionsbild angegebene Selektionsdatum kann in der Detailliste überschrieben oder
durch die Angabe einer Änderungsnummer ersetzt werden. Für die Pflege im Zielsystem kann
hier ebenfalls ein Gültig-ab-Datum oder eine Änderungsnummer (Änderungsdienst) mitgegeben

April 2001 63
ALE-Einführung und Administration SAP AG
Verteilbare Stammdatenobjekte

werden. Erfolgt kein Eintrag, so wird das Gültig-ab-Datum bzw. die Änderungsnummer aus dem
sendenden System übernommen.
Für den Nachrichtentyp BOMMAT gibt es zur Zeit die folgenden Nachrichtenvarianten:
· CNG (change, standard): Ändern der Stücklistenpositionen.
Es werden die Positionen einer existierenden Stückliste geändert, die Kopfdaten bleiben
erhalten. Falls die Stückliste im Zielsystem nicht existiert, wird sie dort angelegt. Dies ist
die Standardvorgabe, falls keine Nachrichtenvariante gewählt wird.
· CRE (create): Anlegen der Stückliste.
Falls die Stückliste im Zielsystem schon existiert, wird das IDoc nicht eingebucht.
· DEL (delete): Löschen der Stückliste.
Diese Möglichkeit sollte nur mit äußerster Vorsicht angewandt werden, da durch das
Löschen der Stückliste die Referenzen von anderen Anwendungen, beispielsweise dem
Arbeitsplan und dem Fertigungsauftrag, auf die Stückliste verloren gehen.
Änderungen an Stücklisten und Stücklistenpositionen können für einfache Materialstücklisten
auch über das SMD-Tool verteilt werden. Die Identifikation der Positionen im Zielsystem erfolgt
hierbei über die Felder Positionstyp, Positionsnummer, Sortierbegriff und Objekt und ist abhängig
vom Positionstyp, z.B. Material, Dokumentdaten oder Klassendaten.

Werte- und Quotenleisten


In SAP Retail müssen Merkmalswerte vor Werte- und Quotenleisten verteilt werden. Die
Merkmalswerte werden nicht zusammen mit den Werte- und Quotenleisten verteilt. Weitere
Informationen finden Sie in der Dokumentation zu SAP Retail unter Warengruppe: Werte- und
Quotenleisten [Extern].

64 April 2001
SAP AG ALE-Einführung und Administration
R/2-Anbindung

R/2-Anbindung
Verteilung von Stammdaten von R/2 nach R/3
Die Verteilung zwischen R/2- und R/3-Systemen wird mit den Migrationswerkzeugen für die
Datenmigration von R/2 ins R/3 realisiert. Dies ist nötig, da die R/2-Datenbasis nur mit einem
aufwendigen Regelwerk auf die R/3-Datenbasis abgebildet werden kann.
Verteilt wird unter Zuhilfenahme dieses Migrationsregelwerkes über einen ALE-Server, auf einem
R/3-System (Eine umfassende Beschreibung des Migrationstools kann im Migrationsleitfaden
nachgelesen werden.).
Damit wird die Verteilung zurückgeführt zum einen auf eine permanente Migration zu verteilender
Objekte aus einem R/2-System in ein R/3-System (ALE-Server genannt) und zum zweiten auf die
Verteilung der Daten vom ALE-Server in ein oder mehrere Zielsystem(e), ebenfalls R/3-Systeme.

Verteilung der Daten zwischen gekoppelten R/2 und R/3 Systemen

R/3-System 1
EDI
R/2-System
R/3-System 2
Migration

CPI-C ALE

ALE-Server
(Migrationssystem
und EDI-Subsystem)

R/3-System 3
Synchroner RFC

R/3-System 4
Der ALE-Server übernimmt die Konvertierung des Datenformats und den Dateitransfer zwischen
dem Hostsystem und den R/3-Instanzen.

Verteilung von Bewegungsdaten von R/3 nach R/2


Für die umgekehrte Richtung werden in das R/2-System zu verteilende Daten an das R/2-
System adressiert. (Angabe des R/2-Systems als logisches System. Über die Portbeschreibung
gelangen die Daten zunächst auf den ALE-Server.
Im ersten Verarbeitungsschritt erfolgt die normale Eingangsverarbeitung im ALE-Server.
Dann wird nach dem Vergleich des logischen Zielsystems und eigenem logischem System
erkannt, daß das eingehende IDoc an das R/2-System weitergeleitet werden muß:
· Der neue Port wird ermittelt.
· Das IDoc wird in den Ausgang gestellt.
· Der Versende-Funktionsbaustein wird aufgerufen. Er sendet an das R/2 über CPI-C.

April 2001 65
ALE-Einführung und Administration SAP AG
R/2-Anbindung

· Im R/2-System wird es als Eingangs-IDoc verzeichnet.


· Ein Anwendungsbaustein verbucht dann das IDoc im R/2.
Im R/2-System werden diese Daten über geeignete Schnittstellen gebucht. Es werden entweder
Batch-Input-Schnittstellen oder, wenn zu einer Anwendung ausreichende EDI-Schnittstellen in
beiden Richtungen (gilt zumeist für Belegdaten) zur Verfügung stehen, diese zur Verteilung
herangezogen.

Eine Datenübertragung R/2-R/3 für EDI-Kommunikation setzt auf der R/2-Seite das
Release 5.0f oder höher voraus.

66 April 2001
SAP AG ALE-Einführung und Administration
Anbindung von Fremdsystemen

Anbindung von Fremdsystemen


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

Kommunikation eines R/3-Systems mit einem Fremdsystem

R/3-System ALE Kommunikation


Empfängerermittlung
.
Stamm-
Anwendung Filterung Komm-
IDoc IDoc
Umsetzung

ALE-Schnittstelle
CALL FUNCTION ‘IDOC_INBOUND_ASYNCHRONOUS’
IN BACKGROUND TASK DESTINATION ...
TABLES IDOC_CONTROL_REC_40=...
IDOC_DATA_REC_40=...

tRFC
Implementierung
RFC
Fremdsystem Bibliothek
Daten Komm-
IDoc
Daten
Übersetzungsprogramm

Kommunikation eines Fremdsystems mit einem R/3-System

April 2001 67
ALE-Einführung und Administration SAP AG
Anbindung von Fremdsystemen

Fremdsystem
Daten Komm.-
IDoc
Daten
Übersetzungs-
programm
tRFC
Implementierung RFC-Bibliothek

RfcRc = RfcIndirectCall( hRfc,


"IDOC_INBOUND_ASYNCHRONOUS",
Exporting, Tables,
TransID );

R/3-System Workflow-Anbindung IDOC_INBOUND_


ASYNCHRONOUS

Anwendungsfunktionen

Anwendungs-
Anwendungs-
Filterung Komm.-
daten Umsetzung IDoc

Ein Beispiel für eine IDoc-Schnittstelle zu Nicht-R/3-Systemen finden Sie in der


Dokumentation Schnittstellen zur mobilen Datenerfassung und
Lagersteuerrechnerkopplung [Extern].

· Die programmtechnische Realisierung finden Sie im ALE-


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

68 April 2001
SAP AG ALE-Einführung und Administration
Übersetzungsprogramme für die Anbindung

Übersetzungsprogramme für die Anbindung


Definition
Übersetzungsprogramme (Translators) sind Programme zum ALE-Anschluß von
Fremdsystemen, die von SAP zertifiziert werden müssen.

Verwendung
Übersetzungsprogramme führen typischerweise folgende Funktionen aus:
· Umsetzen der IDocs in beliebige Strukturen von Fremdsystemen/Kundensystemen
· Steuerung der Kommunikation, wie z.B. den Verbindungsaufbau und den -neustart.

Struktur
Zusammenspiel R/3-Translator-Fremdsystem

Anwendung ALE Kommuni- ALE/


kation EDI
Inter-
face
Anwendung Master
IDoc
Komm

Kommunikation
Doc IDoc
IDoc

Translator Nicht-
SAP-
System
ALE/
Workflow EDI
Inter-
Anwendungs face
funktion
Komm
Anwendungs- IDoc
daten

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

April 2001 69
ALE-Einführung und Administration SAP AG
Übersetzungsprogramme für die Anbindung

70 April 2001
SAP AG ALE-Einführung und Administration
Administration der ALE-Funktionen

Administration der ALE-Funktionen


Einsatzmöglichkeiten
Application Link Enabling stellt Ihnen eine Reihe von Werkzeugen für die Administration zur
Verfügung:
· Überwachung der IDoc-Verarbeitung und der tRFC-Kommunikation
· Transportieren von Customizing-Daten von Pflegesystemen in Empfängersysteme
· Optimierung der ALE-Performance
· Serialisierung von Nachrichten

Die Funktionen zur ALE-Administration finden Sie in der ALE-Administration


In den Hinweisen zur Optimierung der ALE-Verarbeitung wird häufig auf
Einstellungen im R/3-Customizing verwiesen. Den ALE-spezifischen Teil finden Sie
unter Basis ® Verteilung (ALE).
In den untergeordneten Abschnitten finden Sie konzeptionelle Informationen wie auch konkrete
Anweisungen. Sie finden dort jeweils auch Hinweise auf die erforderlichen Einstellungen im
Customizing.

April 2001 71
ALE-Einführung und Administration SAP AG
Überwachung des Nachrichtenaustausches

Überwachung des Nachrichtenaustausches


Über die ALE-Administration können Sie den Nachrichtenaustausch [Seite 10] mit
verschiedenen Werkzeugen überwachen.
Sie erhalten einen Überblick über die Kommunikation und den Verarbeitungsstatus von IDocs.
Die erforderlichen Einstellungen für die Überwachung müssen Sie im ALE-Einführungsleitfaden
vornehmen. In den untergeordneten Abschnitten erhalten Sie dazu konkrete Hinweise.

72 April 2001
SAP AG ALE-Einführung und Administration
Zentrale Überwachung mit dem ALE-CCMS-Monitor

Zentrale Überwachung mit dem ALE-CCMS-Monitor


Verwendung
Sie können mehrere R/3-Systeme im ALE-Verbund von einem zentralen System aus
überwachen. Dazu nutzen Sie einen Alertmonitor [Extern] des CCMS.
Sie erhalten damit einen Überblick über folgende ALE-relevanten Performance-Attribute der R/3-
Systeme im ALE-Verbund:
· Änderungszeiger für IDocs
· IDocs in der Ausgangsverarbeitung
· tRFC-Warteschlange
· IDocs in der Eingangsverarbeitung
Sie können von einem einzigen System aus beliebig viele R/3-Systeme überwachen. Technische
Faktoren wie z. B. die Geschwindigkeit Ihres Netzwerks und der Verkehr in Ihrem Netzwerk
schränken die Anzahl der Systeme ein, die überwacht werden können. Erfahrungsgemäß sind
solche praktischen Einschränkungen jedoch nur bei der Überwachung eines sehr großen
Systemverbunds von Bedeutung.

Integration
Dieses ALE-Werkzeug realisiert eine Anbindung an das CCMS-Monitoring. Dafür stehen Data
Supplier zur Verfügung, die dem CCMS Kennzahlen liefern. Diese Data Supplier sind im CCMS
eingebunden (per Customizing).
ALE-Monitorobjekte werden im ALE-Einführungsleitfaden definiert.

Voraussetzungen
Sie haben im Einführungsleitfaden ALE-Monitorobjekte definiert (Basis ® Verteilung (ALE) ®
Überwachung der Systeme einstellen ® Zentrale Überwachung aller Systeme).
ALE-Monitorobjekte bilden eine zusammengehörige Menge von Selektionsoptionen über IDoc-
Attribute für Auswertungszwecke.
Die Werte der einzelnen Objekte ergeben sich aus dem aktuellen Systemzustand und der
Zuordnung von Selektionsoptionen über IDoc-Attribute.

Aktivitäten
Überprüfen Sie den aktuellen Zustand und die offenen Alerts Ihres R/3-Systems:
Sie haben in der ALE-Administration die folgende Funktion gewählt: Überwachung ® ALE-
Monitor im CCMS.
Sie erkennen den aktuellen Zustand in Form der Performancewerte und Statusmeldungen, die in
jüngster Zeit an den Alertmonitor übergeben wurden. Ältere, noch offene (nicht bearbeitete)
Alerts sind in der Farbkennzeichnung nicht berücksichtigt.
Verfahren Sie wie folgt:
1. Überprüfen Sie die Farbkennzeichnung im Monitorbaum.

April 2001 73
ALE-Einführung und Administration SAP AG
Zentrale Überwachung mit dem ALE-CCMS-Monitor

Die Farben der Knoten oder MTEs (Monitorbaumelemente) im Baum haben die folgende
Bedeutung:
Grün: Die Komponente läuft normal. Alles ist in Ordnung.
Gelb: Es wurde eine Warnung – ein “gelber Alert” – ausgegeben.
Rot: Ein Problem oder kritischer Zustand wurde gemeldet, ein “roter Alert”.
Grau: Für einen Knoten wurden keine Daten geliefert. (Überprüfen Sie im CCMS im
Monitor Selfmonitoring, warum das Collection Tool für diesen Knoten nicht verfügbar
ist.)
Hinweis: Wählen Sie Zusätze ® Legende, um eine Legende der im Alertmonitor
verwendeten Farben und Symbole anzuzeigen.
Der Alertmonitor gibt die höchste Alertebene im Monitorbaum an den obersten Knoten
weiter. Wenn beispielsweise der Knoten mit dem Namen Ihres R/3-Systems grün ist,
bedeutet das, daß alle Komponenten im Monitorbaum des Systems einen “grünen”
Zustand aufweisen. Alles ist in Ordnung.
Doppelklicken Sie auf einen Knoten, um die entsprechende Analysemethode zu starten.
Die Analysemethode zeigt ausführliche Informationen über den aktuellen Zustand des
Knotens an.
Sie können optional das automatische Auffrischen der Anzeige einschalten. Wählen
Sie Zusätze ® Anzeigeoptionen. Wählen Sie dann das Register allgemein. Markieren
Sie im Gruppenrahmen Anzeigen auffrischen die Option ja und geben Sie das
Aktualisierungsintervall ein. Empfohlener Wert: 300 Sekunden oder länger.

Wenn das automatische Auffrischen ausgeschaltet ist, zeigt der Alertmonitor die
Daten an, die bei dessen Start verfügbar waren.
2. Überprüfen Sie, was in letzter Zeit in Ihrem System geschehen ist.
Wählen Sie in der Symbolleiste Offene Alerts.
Anstatt des aktuellen Zustands des Systems zeigt die Farbmarkierung im Monitor jetzt,
wo offene Alerts vorhanden sind. Als offene Alerts bezeichnet man Alerts, die noch nicht
analysiert und auf erledigt gesetzt wurden.
Wenn Sie morgens Ihre Arbeit beginnen oder nach der Mittagspause an Ihren
Arbeitsplatz zurückkehren, können Sie in der Sicht Offene Alerts überprüfen, ob in Ihrer
Abwesenheit Probleme im System auftraten. Der Monitor zeichnet Alerts für Sie auf,
selbst wenn der den Alert auslösenden Zustand sich inzwischen verbessert hat.
3. Reagieren Sie auf einen Alert.
Wenn Sie im Monitorbaum gelbe oder rote Einträge sehen, liegt eine Warnung (gelb)
oder ein Fehler (rot) vor.
Gehen Sie in diesem Fall wie folgt vor:
a) Wählen Sie Offene Alerts, um in die Alertanzeige zu wechseln, sofern sie noch nicht aktiv
ist.
Der Monitor zeigt jetzt an, wieviele Alerts für jedes Monitorbaumelement vorhanden
sind. Er zeigt auch die schwerwiegendsten noch zu bearbeitenden Alertmeldungen
an.

74 April 2001
SAP AG ALE-Einführung und Administration
Zentrale Überwachung mit dem ALE-CCMS-Monitor

b) Bewegen Sie den Cursor auf ein gelbes oder rotes Monitorbaumelement, und wählen Sie
Alerts anzeigen.
Das System öffnet den Alert-Browser und zeigt die offenen Alerts an. Der Browser
enthält alle Alerts in dem von Ihnen markierten Zweig des Baums. Bewegen Sie den
Cursor weiter nach oben im Monitorbaum, um eine breitere Spanne von Alerts
anzuzeigen. Bewegen Sie den Cursor auf ein MTE auf der untersten Ebene der
Anzeige, um nur Alerts anzuzeigen, die dieses MTE betreffen.
c) Analysieren Sie einen Alert.
Jede Zeile im Alert-Browser liefert zusammenfassende Informationen zu einem Alert
sowie die Alertmeldung (ganz rechts).
Der Browser bietet zudem noch zwei weitere Informationsquellen. Markieren Sie ein
Alert-Ankreuzfeld und wählen Sie folgende Funktionen (über Ikonen):
· Analysemethode starten
Damit starten Sie die zu einem Alert gehörige Problemanalysetransaktion oder das
entsprechende Werkzeug.
· Details anzeigen
Das System zeigt Details zu dem Monitorbaumelement an. Hierzu gehören die
neuesten Werte oder Statusmeldungen, die Alertschwellenwerte und die
Performancedaten für die letzte Erfassungszeit (nur bei Performance-
Monitorbaumelementen) an. Sie können die Detaildaten bildlich darstellen, indem Sie
die betreffende Zeile markieren und die Ikone Performancewerte graphisch anzeigen
wählen.
4) Wenn der Alert bereinigt ist, setzen Sie seinen Bearbeitungsstatus um.
Wenn Sie das Problem analysiert und entweder behoben haben oder wissen, daß Sie es
ohne Bedenken ignorieren können, markieren Sie den Alert und wählen Sie Alerts
erledigen.
Der Alertmonitor löscht den Alert aus der Liste der offenen Alerts.

Erweiterte Funktionen
Die folgenden Themen beschreiben, wie Sie den Alertmonitor Ihren Anforderungen entsprechend
anpassen und mehr seiner Funktionen nutzen können.
· Überwachung: Vorgehensweisen [Extern]:
Genaue Anweisungen für Aufgaben, die Sie eventuell im Alertmonitor durchführen müssen.
· Eigene Monitore erstellen [Extern]:
Anstatt mit einem vordefinierten Monitor zu arbeiten, können Sie auch Ihre eigenen
speziellen Monitore anlegen. Sie können nur die Monitorbaumelemente einfügen, die Sie
wirklich anzeigen müssen.
· Customizing des Alertmonitors [Extern]:
Alle Monitorbaumelemente haben bewährte Standardschwellenwerte für das Auslösen von
Alerts und Standardzuordnungen zu Analysemethoden.
Sie können die Schwellenwerte und die zugeordneten Analysemethoden nach Bedarf
ändern.

April 2001 75
ALE-Einführung und Administration SAP AG
Zentrale Überwachung mit dem ALE-CCMS-Monitor

76 April 2001
SAP AG ALE-Einführung und Administration
Statusmonitor für ALE-Nachrichten

Statusmonitor für ALE-Nachrichten


Verwendung
Über den Statusmonitor können Sie den Verarbeitungsstatus von IDocs im ALE-Ausgangs- und
im ALE-Eingangssystem überwachen und IDocs manuell verarbeiten.

Funktionsumfang
Über Werkzeuge ® ALE ® Administration ® Statusmonitor für ALE-Nachrichten gelangen Sie
zum Selektionsbild des Statusmonitors.
Über Selektionsoptionen können Sie die IDoc-Auswahl einschränken und darstellen.
Die nach Statustexten geordneten IDocs der Hierarchiedarstellung können Sie umordnen (nach
Nachrichtentyp / Objekttyp oder Partnersystem), eine IDoc-Auswahl darstellen oder IDocs direkt
verarbeiten oder einschränken und dann verarbeiten.
Aus der Hierarchiedarstellung können Sie in eine IDoc-Auswahl in Listendarstellung und von dort
in die IDoc-Einzelanzeige verzweigen.

IDoc-Auswahl einschränken
Im Selektionsbild können Sie folgende Selektionsoptionen für die IDoc-Auswahl nutzen:
· IDoc-Nummer
· Erstellungsdatum *
· Erstellungszeit
· Änderungsdatum *
· Änderungszeit
· IDoc-Status
· Partnersystem
· Nachrichtentyp
· Business-Objekttyp und Objektschlüssel (Auswahl ist zeitintensiver als bei Nachrichtentyp)
* Die Pfeiltasten dienen zum wochenweisen Blättern.
Beachten Sie die kontextspezifischen Menüs, die Ihnen über die rechte Maustaste zur Verfügung
stehen.
Sie erhalten eine hierarchische Darstellung der IDocs im Ausgang und Eingang gruppiert nach
IDoc-Statusinformationen:
Status (Text mit oder ohne Statusnummern, IDoc-Anzahl)
Nachrichtentyp (Objektmethode: über Einstellungen ® Businessobjekt anzeigen)
Meldungstext
Eine Legende zu den Symbolen in der Hierarchie erhalten Sie über Springen ® Legende
anzeigen.
Die Menge der anzuzeigenden IDocs können Sie auch nachträglich aus dem Hierarchiebild
heraus über IDocs auswählen einschränken.

April 2001 77
ALE-Einführung und Administration SAP AG
Statusmonitor für ALE-Nachrichten

Beachten Sie auch, dass das Expandieren des Teilbaums IDoc-Einträge in der
tRFC-Queue sehr viel Zeit in Anspruch nehmen kann. Sie sollten daher diesen
Knoten nur bei Bedarf expandieren.

Hierarchiedarstellung ändern
Über das Menü Einstellungen und teilweise auch über Symbole können Sie die Hierarchie wie
folgt ändern:
· Nachrichtentyp / Objekttyp hervorgehoben
· IDoc-Status hervorgehoben
· Partnersysteme anzeigen (Nachrichtentyp oder IDoc-Status hervorgehoben)
Statusinformationen können Sie zu Gruppen zusammenfassen und Statusnummern ein- oder
ausblenden (über das Menü Einstellungen).

IDoc-Liste anzeigen
Über IDocs anzeigen erhalten Sie zu jedem Haupt- oder Untereintrag der Hierarchie eine Liste
(IDoc-Auswahl) der zugehörigen IDocs mit folgenden Informationen:
· IDoc-Nummer
· Status
· Nachrichtentyp
· Objekttyp (nur bei Business-Objekt)
· Methode (nur bei Business-Objekt)
· Statustext
· Partnernummer des Empfängersytems
· Datum der Erstellung
· Uhrzeit der Erstellung
· IDoc-Basistyp
· Anzahl der Segmente

IDocs einzeln anzeigen


Die IDocs zu den angezeigten IDoc-Nummern können Sie sich jeweils einzeln anzeigen.
Selektieren Sie dazu ein IDoc, und wählen Sie IDocs anzeigen oder führen Sie einen Doppelklick
aus. Die IDoc-Anzeige enthält den Kontrollsatz, Datensätze und Statussätze.

Verknüpfungen zu Objekten anzeigen


Verknüpfungen können Sie anzeigen, indem Sie eine IDoc-Nummer selektieren und
Verknüpfungen anzeigen wählen.
Sie erhalten eine Liste der mit dem IDoc direkt verknüpften Objekte.

78 April 2001
SAP AG ALE-Einführung und Administration
Statusmonitor für ALE-Nachrichten

Statuslangtext anzeigen
In der IDoc-Auswahl können Sie sich zum jeweiligen Statustext einer IDoc-Nummer über die
gleichnamige Drucktaste den zugehörigen Statuslangtext anzeigen.

Objektschlüssel anzeigen
Zu jeder IDoc-Nummer in der IDoc-Auswahl können Sie sich über die Drucktaste Objektschlüssel
die Darstellung um die Spalten Objekttyp und Objektschlüssel erweitern.

Status im Empfängersystem ermitteln


Den Status der IDocs im Empfängersystem (Eingang) können Sie über ALE-Audit und IDoc-
Verfolgung [Seite 80] ermitteln:
· Asynchrone Statusrückmeldung
Sofern Sie im Sendersystem (Ausgang) den IDoc-Status im Eingang mit ALE-Audit
überwachen [Seite 81] und periodische Rückmeldungen aus dem Empfängersystem
vorliegen, werden diese in der Hierarchie des Statusmonitors angezeigt. Solche IDocs
haben den Status 39, 40 oder 41. Diese Statusangaben fassen die verschiedenen
Statusinformationen aus dem Empfängersystem zusammen. In der entsprechenden
IDoc-Auswahl finden Sie zu jedem IDoc die Partnernummer und den Status des
zugeordneten IDocs im Empfängersystem (50, 51, ...).
Alternativ dazu könnnen Sie sich eine aggregierte Übersicht aller periodischen
Rückmeldungen anzeigen. Dazu müssen Sie über Springen ® ALE-Audit ® Statistische
Auswertung im Sendersystem (Ausgang) die Audit-Datenbank auswerten [Seite 83].
· Synchrone Statusermittlung
Zu den IDocs im Eingang (im Empfängersystem) und den Ausgangs-IDocs im Status 3
und 12 können Sie synchron den Status des IDocs im Partnersystem abrufen. Wählen
Sie dazu IDocs verfolgen in der Hierarchie des Statusmonitors. Einzelheiten dazu finden
Sie unter systemübergreifende IDoc-Verfolgung [Seite 85].
Die Hierarchiedarstellung des Statusmonitors können Sie drucken (über IDoc-Auswahl ®
Drucken).

IDocs verarbeiten
Wenn fehlerhafte oder unvollständig verarbeitete IDocs vorliegen, können Sie anhand des
Statuslangtextes (rechte Maustaste oder IDoc-Auswahl) die Ursache ermitteln und beseitigen.
Die entsprechenden IDocs können Sie anschließend verarbeiten oder erst einschränken und
dann verarbeiten.
Sie erhalten eine Liste der verarbeiteten IDocs mit dem vorherigen und dem aktuellen Status.

· Bei der Eingangsverarbeitung nicht gebuchte IDocs (Status 51) können Sie
nachträglich buchen (siehe Fehlerbehandlung [Seite 23]).
· Kommunikationsfehler können Sie nicht verarbeiten.

April 2001 79
ALE-Einführung und Administration SAP AG
ALE-Audit und IDoc-Verfolgung

ALE-Audit und IDoc-Verfolgung


Zwischen dem ALE-Audit und der systemübergreifenden IDoc-Verfolgung gibt es folgende
Unterschiede:
· Die Audit-Auswertung ist im Regelfall schneller als die IDoc-Verfolgung, da die
Rückmeldungen aus dem Empfängersystem bereits im Ausgangssystem vorliegen.
· Die Audit-Datenbank wird nur periodisch aktualisiert. Die Periode ist zwar variabel,
trotzdem sind neu entstandene IDocs erst nach einem Zeitverzug auch in der Audit-
Auswertung sichtbar.
· Bei der systemübergreifenden IDoc-Verfolgung werden Informationen aus dem
Empfängersystem synchron beschafft.
· Im Gegensatz zum ALE-Audit können Sie die IDoc-Verfolgung nur für logische Systeme
nutzen, jedoch nicht für EDI-Kommunikationspartner wie Kunden und Lieferanten.
Mit dem ALE-Audit können Sie aus dem Sendesystem die IDoc-Übertragung auf einfache Art
überwachen, sofern die Übertragung nicht ausgesprochen zeitkritisch ist.

80 April 2001
SAP AG ALE-Einführung und Administration
IDoc-Status im Eingang mit ALE-Audit überwachen

IDoc-Status im Eingang mit ALE-Audit überwachen


Verwendung
Mit Hilfe des ALE-Audit können Sie im sendenden R/3-System den Verarbeitungsstand der
gesendeten IDocs im empfangenden R/3-System (Eingang) überwachen. Das empfangende R/3-
System schickt periodisch Rückmeldungen an das sendende R/3-System. Diese Rückmeldungen
werden auf dem Sendesystem in IDoc-Statussätzen und in Audit-eigenen Tabellen protokolliert.
Außerdem werden Verknüpfungen zwischen IDocs des Sender- und des Empfängersystems
erstellt.
Zur Auswertung der Audit-Datenbank existiert auf dem sendenden R/3-System ein
Auswertungsprogramm.

Sendende Empfangende
Anwendung Anwendung
Anwendungs-
Anwendungs-
nachricht

Audit
Statistik
Audit-
Audit-
Verknüpfungen
Verknüpfungen Nachricht

aktueller Status

Voraussetzung
Als Voraussetzung für das Versenden von Rückmeldungen müssen Sie im Verteilungsmodell
einen Nachrichtenfluß für den Nachrichtentyp ALEAUD pflegen.
Wählen Sie dazu folgende Aktivität im R/3 Customizing Einführungsleitfaden:
Basis ® Application Link Enabling (ALE) ® Überwachung der Systeme einstellen ® IDoc-
Rückmeldung im Empfängersystem einrichten (ALE-Audit) ® Verteilungsmodell für ALE-Audit
konfigurieren.
Aus Gründen der Performance werden die Rückmeldungen nicht einzeln für jedes eintreffende
IDoc, sondern periodisch für ein gesamtes Paket von IDocs verschickt. Für die Rückmeldungen
gibt es ein spezielles IDoc ALEAUD01 [Extern] mit Nachrichtentyp ALEAUD.

April 2001 81
ALE-Einführung und Administration SAP AG
IDoc-Status im Eingang mit ALE-Audit überwachen

Zur näheren Spezifizierung steht das Filterobjekt Nachrichtentyp (MESTYP) zur Verfügung. Mit
Hilfe dieses Filterobjekttyps können Sie die Nachrichtentypen einstellen, für die Audit-
Rückmeldungen erzeugt werden sollen. In der Regel werden nicht für alle Nachrichtentypen
Rückmeldungen geschickt. Bei Stammdaten beispielsweise ist es denkbar, auf Rückmeldungen
zu verzichten. Bei Nichtverwendung des Filterobjekttyps MESTYP werden alle IDocs an den
Empfänger von ALEAUD zurückgemeldet.

Aktivitäten
Im Empfängersystem müssen Sie Einstellungen für periodische Rückmeldungen vornehmen. Sie
können Rückmeldungen auch direkt versenden.
Beim Senden von Rückmeldungen (Programm RBDSTATE) werden IDocs des Nachrichtentyps
ALEAUD erzeugt, die Informationen über den Verarbeitungsstand von Eingangs-IDocs enthalten.
Ein Audit-IDoc enthält Rückmeldungen für bis zu 500 IDocs. Liegen mehr rückzumeldende IDocs
an, werden mehrere IDocs erzeugt. Die Ausgabe besteht aus einer Liste der erzeugten IDocs.
Falls kein IDoc erzeugt wurde oder ein Fehler auftrat, erfolgt eine entsprechende Meldung.
IDocs, deren Status sich in letzter Zeit geändert hat, werden selektiert. Da fast jede Aktion an
einem IDoc eine Statusänderung zur Folge hat (Anlegen, erfolgreiches Buchen in der
Anwendung, erfolgloser Versuch in der Anwendung zu Buchen,...), handelt es sich genau um die
IDocs, die in irgendeiner Weise verarbeitet worden sind.

Periodische Rückmeldungen einstellen


Damit Audit-Daten periodisch an das Sendersystem zurückgemeldet werden, müssen Sie im
Empfängersystem mit dem Programm RBDSTATE einen Hintergrund-Job einplanen.
Wählen Sie dazu folgende Aktivität im R/3 Customizing Einführungsleitfaden:
Basis ® Application Link Enabling (ALE) ® Überwachung der Systeme einstellen ® IDoc-
Rückmeldung im Empfängersystem einrichten (ALE-Audit) ® Rückmeldung von Audit-Daten
einplanen
Rückmeldungen können Sie stündlich oder täglich einplanen.
Eine aggregierte Übersicht aller periodischen Rückmeldungen erhalten Sie, wenn Sie im
Sendersystem die Audit-Datenbank auswerten [Seite 83].

Rückmeldungen direkt versenden


Um Rückmeldungen direkt an das Sendersystem zu senden, wählen Sie im Statusmonitor
Springen ® ALE-Audit ® Rückmeldungen senden.
Über Selektionsparameter können Sie steuern, an welche Systeme und für welche
Nachrichtentypen Rückmeldungen erzeugt werden sollen.
Sie müssen den Änderungszeitraum über ein Beginn- und Endedatum eingeben.

82 April 2001
SAP AG ALE-Einführung und Administration
Audit-Datenbank auswerten

Audit-Datenbank auswerten
Verwendung
Eine aggregierte Übersicht zu allen Statusrückmeldungen eines bestimmten Zeitraums erhalten
Sie über die statistische Auswertung der Audit-Datenbank.

Aktivitäten
Übersichtsbild aller Statistiken anzeigen
Die Audit-Datenbank können Sie über den IDoc-Statusmonitor auswerten: Springen ® ALE-Audit
® Statistische Auswertung.
Das Übersichtsbild enthält alle selektierten Audit-Statistiken. Pro Empfangssystem,
Nachrichtentyp und Erstellungsdatum von IDocs wird eine Statistik geführt.
Die Spalten haben folgende Bedeutung:
Letztes IDoc
Zeitpunkt, bis zu dem IDocs berücksichtigt wurden
Wenn der Wert 24:00:00 eingetragen ist, dann sind alle IDocs eines Tages
berücksichtigt. Wenn eine frühere Zeit eingetragen ist, sind nur die IDocs in der Statistik
bereits berücksichtigt, die bis zu dieser Zeit angelegt worden sind.
IDocs gesamt
Anzahl aller IDocs dieser Statistik.
Queue Ausgang
Anzahl der IDocs dieser Statistik, die noch im eigenen System bearbeitet werden, d. h.
noch nicht versendet wurden.
Queue Eingang
Anzahl der IDocs, die vom Zielsystem empfangen wurden, zum Zeitpunkt der letzten
Rückmeldung aber noch in Bearbeitung waren. Durch Doppelklick auf eine Statistik
gelangen Sie in die Statusübersicht zu einer Statistik.

Statusübersicht zu einer Statistik anzeigen


Per Doppelklick auf einen Statistikeintrag gelangen Sie in die zugehörige Statusübersicht.
Die Übersicht enthält alle gesendete Nachrichten und Detailinformationen zu fehlerhaften IDocs
im Empfängersystem. Die Detailinformationen bestehen aus dem aktuellen Status, der Anzahl
von IDocs und der Fehlermeldung.
Die Statussätze, die aufgrund der Rückmeldungen geschrieben werden, haben folgende Werte
und Bedeutungen:
39 IDoc im Empfangssystem (ALE-Dienst) und noch in Bearbeitung.
40 Anwendungsbeleg im Empfangssystem nicht erzeugt.
Die Verarbeitung wurde auf dem Empfangssystem endgültig ohne Erfolg beendet.

April 2001 83
ALE-Einführung und Administration SAP AG
Audit-Datenbank auswerten

41 Anwendungsbeleg im Zielsystem erzeugt.


Die Verarbeitung verlief erfolgreich. Die Meldung in diesen Statussatz ist eine Kopie der
entsprechenden Meldung aus dem IDoc-Statussatzes des Empfangssystems.
Getrennt nach Ausgang und Eingang werden alle IDocs der ausgewählten Statistik gruppiert
nach Status aufgelistet.

IDoc-Liste zu einem Statuswert anzeigen


Durch Doppelklick auf einen nicht endgültigen Statuswert gelangen Sie in die IDoc-Liste zu
diesem Statuswert. Die IDoc-Liste ist nur für Statuswerte ohne endgültigen Status verfügbar, also
z. B. nicht für den Status 53 - "Anwendungsbeleg gebucht". Das ALE-Audit liefert nur
Detailinformationen für IDocs, die noch in Bearbeitung sind.
Falls vorhanden, wird das verknüpfte Anwendungsobjekt ebenfalls ausgegeben. Falls es sich um
IDocs handelt, die sich bereits im Zielsystem befinden, wird die IDoc-Nummer des
Empfangssystem ebenfalls angezeigt.

Einzelne IDocs anzeigen


Durch Doppelklick auf eine Zeile können Sie in die Anzeige des jeweiligen (lokalen) IDocs
verzweigen.
In der Einzelanzeige sind sämtliche Informationen abrufbar, die zu diesem IDoc auf dem eigenen
System vorhanden sind.
Fehlermeldungen des Empfangssystems finden Sie zu den Statuswerten 39 und 40.

84 April 2001
SAP AG ALE-Einführung und Administration
IDocs systemübergreifend verfolgen

IDocs systemübergreifend verfolgen


Verwendung
Im Statusmonitor können Sie zu den IDocs im Status 3 und 12 über die systemübergreifende
IDoc-Verfolgung deren Verarbeitungsstatus im Empfängersystem synchron ermitteln.

Aktivitäten
Neben der Statusübersicht können Sie auch Verknüpfungen zwischen IDocs und Objekten und
einzelne IDocs anzeigen.

Statusübersicht anzeigen
Markieren Sie einen Statustext oder einen Nachrichtentyp / eine Objektmethode und klicken Sie
auf IDocs verfolgen.
Sie gelangen zu einer aggregierten Statusübersicht von IDoc-Paaren im sendenden und
empfangenden System.
Die IDoc-Auswahl enthält folgende Spalten:
· IDoc-Nummer
· Status im Sendersystem
· IDoc-Nummer im Empfängersystem
· Status im Empfängersystem
· Nachrichtentyp
· Statustext aus dem Empfängersytem
· Partnernummer des Empfängersytems
· Datum der Erstellung
· Uhrzeit der Erstellung
· IDoc-Basistyp
· Anzahl der Segmente

Verknüpfungen zu Objekten anzeigen


Verknüpfungen können Sie anzeigen, indem Sie eine IDoc-Nummer selektieren und
Verknüpfungen anzeigen wählen.
Sie erhalten eine Liste der mit dem IDoc direkt verknüpften Objekte.

IDocs anzeigen
Die IDocs der sendenden und empfangenden Systeme können Sie sich jeweils einzeln anzeigen.
Selektieren Sie dazu ein IDoc, und wählen Sie IDocs anzeigen oder führen Sie einen Doppelklick
aus. Die IDoc-Anzeige enthält den Kontrollsatz, Datensätze und Statussätze. Weitere
Informationen dazu erhalten Sie über Hilfe ® Hilfe zur Anwendung.

April 2001 85
ALE-Einführung und Administration SAP AG
Customizing-Daten zwischen Systemen abgleichen

Customizing-Daten zwischen Systemen abgleichen


Verwendung
Über die ALE-Administration können Sie Customizing-Daten zu Customizing-Objekten zwischen
Systemen abgleichen.
Customizing-Objekte werden Verteilungsgruppen zugeordnet und in die beteiligten Systeme über
ALE-Transportaufträge transportiert. Verteilungsgruppen müssen Sie im ALE-
Einführungsleitfaden definieren.
Hintergrundinformationen zu diesem Thema finden Sie unter Customizing-Datenabgleich
zwischen Systemen [Seite 46].

Voraussetzungen
Sie haben im ALE-Einführungsleitfaden Verteilungsgruppen angelegt und eine Modellierung
durchgeführt:
Geschäftsprozesse modellieren und implementieren
Synchronisation von Customizing-Daten konfigurieren

Vorgehensweise
Um Customizing-Daten zwischen Systemen abzugleichen, müssen Sie im Sendersystem und in
den Empfängersystemen eine Reihe von Schritten ausführen. Wählen Sie dazu die
entsprechenden Funktionen unter Werkzeuge ® ALE ® Dienste ® Customizing-Daten ® ALE-
Aufträge.

Im Sendersystem:
- ALE-Aufträge im Ausgang anzeigen
Über Ausgang anzeigen können Sie sich pro Verteilungsgruppe und Zielsystem
für einen anzugebenden Zeitraum bestehende ALE-Transportaufträge mit
Statusinformationen anzeigen.
- ALE-Aufträge generieren
Über Generieren können Sie anhand der Selektionsoptionen und Parameter
ALE-Transportaufträge und IDocs erzeugen, die die Empfängersysteme
benachrichtigen.
Bemerkung zum Feld CTS-Dummysystem:
Das CTS erfordert die Angabe eines Zielsystems, obwohl diese Information in
diesem ALE-Fall nicht benutzt wird, da ALE die Verteilung über das Info-IDoc
selbst steuert. Geben Sie ein "leeres Pseudosystem" an, zu dem normalerweise
keine Transporte stattfinden.
Bemerkungen zu den Objekten:
Die Customizing-Daten sind sog. Customizing-Objekten zugeordnet, die
ihrerseits einen Typ besitzen. Abhängig von diesem Typ können folgende
Probleme bei der Erzeugung des Transportauftrages auftreten:
Objekttyp Bemerkungen

86 April 2001
SAP AG ALE-Einführung und Administration
Customizing-Daten zwischen Systemen abgleichen

L Logisches Transportobjekt keine Probleme


S Tabelle (mit Texttabelle) keine Probleme
T Individuelles Transaktionsobjekt funktioniert nur eingeschränkt
(kein allgemein. definierte Art der
Auftrags-generierung, keine
Zeilenselektion)
V View normalerweise keine Probleme,
aber bei nicht verknüpften
Objekten (z.B. SADR*-Tabellen)
keine Zeilenselektion möglich
Die aus den Customizing-Aufträgen im System selektierten Objekte, die in den
ALE-Auftrag übernommen wurden, werden in der Dokumentation des Auftrages
protokolliert.

Im Empfängersystem:
- ALE-Aufträge im Eingang anzeigen
Über Eingang anzeigen können Sie sich pro Verteilungsgruppe und Quellsystem
für einen anzugebenden Zeitraum die ALE-Aufträge mit Importstatus anzeigen.
- ALE-Aufträge importieren
Über Importieren können Sie pro Verteilungsgruppe Quellaufträge in ein
anzugebendes Zielsystem transportieren.
- ALE-Aufträge konsolidieren und weiterleiten
Über Konsolidieren können Sie aus ALE-Aufträgen einen Konsolidierungsauftrag
erzeugen. Der Konsolidierungsauftrag wird für den Transport der mittels ALE-
Aufträgen importierten Customizing-Daten in Qualitätssicherungs- und
Produktivsysteme verwendet.
Diese Funktion können Sie nur in Customizing-Systemen ausführen, in denen
Customizing-Daten durch ALE-Transporte importiert wurden.
Die Funktion erzeugt einen regulären, nicht freigegebenen Customizing-Auftrag.
Der Anwender der Funktion ist auch der Inhaber des Konsolidierungsauftrags.

Ergebnis
Die Customizing-Objekte sind in allen Systemen Ihres ALE-Systemverbunds identisch.

April 2001 87
ALE-Einführung und Administration SAP AG
ALE-Performance-Optimierung

ALE-Performance-Optimierung
Für die Funktion des Application Link Enabling sind IDocs von zentraler Bedeutung. Eine
optimale ALE-Verarbeitung ist aus diesem Grund gleichbedeutend mit einem optimierten
Durchsatz an IDocs.
IDocs werden während des Ablaufs der ALE-Verarbeitung an folgenden Stellen manipuliert:
· Im sendenden R/3-System bei der IDoc-Erzeugung
· Im sendenden R/3-System bei der IDoc-Übergabe an die Kommunikationsschicht
· Bei der Kommunikation zwischen dem sendenden und empfangenden R/3-System
· Im empfangenden System bei der IDoc-Verbuchung
Es bestehen Optimierungsmöglichkeiten durch eine oder mehrere der folgenden Maßnahmen:
· Steuerung des zeitlichen Ablaufs [Seite 89]
· Parallele IDoc-Verarbeitung [Seite 93]
· Paketverarbeitung [Seite 97]
· Administration der IDoc-Kommunikation [Seite 101]

88 April 2001
SAP AG ALE-Einführung und Administration
Steuerung des zeitlichen Ablaufs

Steuerung des zeitlichen Ablaufs


Die Zeitpunkte der IDoc-Erzeugung, IDoc-Übergabe an die Kommunikationsschicht und IDoc-
Verbuchung können Sie im ALE-Einführungsleitfaden festlegen.
Über die Hintergrundverarbeitung können Sie zeitaufwendige ALE-Verarbeitungsschritte zu
Zeiten geringerer Systemauslastung durchführen.

Siehe auch:
Terminierung der IDoc-Erzeugung [Seite 90]
Terminierung der IDoc-Übergabe an die Kommunikationsschicht [Seite 91]
Terminierung der IDoc-Verbuchung [Seite 92]

April 2001 89
ALE-Einführung und Administration SAP AG
Terminierung der IDoc-Erzeugung

Terminierung der IDoc-Erzeugung


Nur bei der Verteilung von Stammdaten ist es möglich, den Zeitpunkt der IDoc-Erzeugung
festzulegen. Bei der Verteilung von Bewegungsdaten werden IDocs zeitgleich mit dem Sichern
der Daten in der Anwendung erzeugt.
Stammdaten-IDocs können auf zwei Arten erzeugt werden:
· Durch Auswerten von Änderungszeigern, die beim Anlegen oder Ändern von Stammdaten
angelegt werden.
Führen Sie dazu im ALE-Einführungsleitfaden den folgenden Schritt aus:
Geschäftsprozesse implementieren und konfigurieren
Verteilung von Stammdaten konfigurieren
Replikation von geänderten Daten einrichten
IDoc-Erzeugung aus Änderungszeigern einplanen
· Durch direktes Senden oder Anfordern von Stammdaten im ALE-Stammdaten-Menü oder
Aufruf eines geeignetes Programms.

Es wird empfohlen, die Änderung von Stammdaten durch Anlegen von


Änderungszeigern zu protokollieren. Dadurch wird vermieden, daß externe Listen der
Stammdatenänderungen geführt werden müssen, um einen späteren Datenabgleich
durch direktes Senden durchführen zu können.
Wird das selbe Stammdatum mehrfach geändert, wird nur der zuletzt angelegte
Änderungszeiger zur Erzeugung des Stammdaten-IDocs herangezogen. Die Anzahl
der zu versendeten IDocs wird dadurch auf ein Minimum reduziert.
Um Änderungszeiger anzulegen, müssen Sie im ALE-Customizing Änderungszeiger
sowohl generell als auch für einzelne Nachrichtentypen aktivieren:
Geschäftsprozesse implementieren und konfigurieren
Verteilung von Stammdaten konfigurieren
Replikation von geänderten Daten einrichten
Änderungszeiger generell aktivieren
Änderungszeiger pro Nachrichtentyp aktivieren
Direktes Versenden oder Anfordern von Stammdaten kann sinnvoll sein, wenn ein
R/3-System initialisiert oder abgeglichen werden soll. Wählen Sie dazu unter
Stammdatenverteilung in der ALE-Administration das gewünschte Stammdatum und
die entsprechende Funktion.

90 April 2001
SAP AG ALE-Einführung und Administration
Terminierung der IDoc-Übergabe an die Kommunikationsschicht

Terminierung der IDoc-Übergabe an die


Kommunikationsschicht
Die Übergabe eines IDocs an die Kommunikationsschicht löst dessen Übertragung an ein
externes System mittels transaktionalem RFC (tRFC) aus. Die Übergabe des IDocs ist Aufgabe
der ALE-Schicht.
Die ALE-Schicht übernimmt die IDoc-Ausgangsverarbeitung, an deren Ende die
Versendesteuerung steht. Abhängig von den im Customizing des ALE getroffenen
Partnervereinbarungen bestehen für die Übergabe des IDocs folgende Möglichkeiten:
· Die einem Partner und Nachrichtentyp zugeordneten IDocs werden gesammelt und zu einem
späteren Zeitpunkt durch das Programm RSEOUT00 an die Kommunikationsschicht
übergeben.
Führen Sie dazu im R/3-Einführungsleitfaden den folgenden Schritt aus:
Basis
Application Link Enabling (ALE)
Geschäftsprozesse implementieren und konfigurieren
Partnervereinbarungen und Verarbeitungszeitpunkt einstellen
Versand gesammelter IDocs einplanen
Die Übergabe der gesammelten IDocs an die Kommunikationsschicht kann auch manuell in
der ALE-Administration über Überwachung ® IDocs manuell verarbeiten gestartet werden.
· Das IDoc wird sofort an die Kommunikationsschicht übergeben

Es ist empfehlenswert, den Ausgabemodus IDocs sammeln zu verwenden, besonders wenn


Massendaten verteilt werden. Durch die zeitliche Trennung von IDoc-Erzeugung und IDoc-
Übergabe an die Kommunikationsschicht wird die Systemauslastung verbessert.
Außerdem kann bei gesammelten IDocs die Paketverarbeitung [Seite 97] genutzt werden.
Um das Sammeln von IDocs zu vereinbaren, wählen Sie im ALE-Customizing folgenden
Pfad:
Geschäftsprozesse implementieren und konfigurieren
Partnervereinbarungen und Verarbeitungszeitpunkt einstellen
Partnervereinbarung manuell pflegen oder
Partnervereinbarung generieren
Unter Ausgangsparameter wählen Sie den Ausgabemodus IDocs sammeln bzw. IDocs
sammeln und übergeben.

April 2001 91
ALE-Einführung und Administration SAP AG
Terminierung der IDoc-Verbuchung

Terminierung der IDoc-Verbuchung


Die Übergabesteuerung der ALE-Eingangsverarbeitung bietet für die Verbuchung von
eingehenden IDocs folgende Alternativen:
· Sofortige Verarbeitung:
Eingehende IDocs werden unmittelbar nach deren Empfang zur sofortigen Verarbeitung
freigegeben. Eingehende IDoc-Pakete werden durch die ALE-Eingangsverarbeitung ggf.
in einzelne IDocs aufgetrennt.
· Verarbeitung im Hintergrund
Eingehende IDocs und IDoc-Pakete werden zunächst auf der Datenbank
zwischengespeichert. IDoc-Pakete werden zuvor in einzelne IDocs aufgetrennt.
Die gespeicherten IDocs werden zu einem späteren Zeitpunkt mit dem Programm
RBDAPP01 zur Verbuchung freigegeben. Einzelne IDocs können zu Paketen geschnürt
und dann verarbeitet werden.
Führen Sie dazu im ALE-Einführungsleitfaden die folgenden Schritte aus:
1. Hintergrundverarbeitung vereinbaren:
Geschäftsprozesse implementieren und konfigurieren
Partnervereinbarungen und Verarbeitungszeitpunkt einstellen
Partnervereinbarung manuell pflegen
Nehmen Sie die erforderlichen Eingaben vor. Wählen Sie dann im Detailbild zu
Eingangsparameter die Option Anstoß durch Hintergrundprogramm.
2. Verbuchung einplanen:
Geschäftsprozesse implementieren und konfigurieren
Partnervereinbarungen und Verarbeitungszeitpunkt einstellen
Verbuchung von IDocs im Empfängersystem einplanen
Alternativ dazu können Sie über die manuelle IDoc-Verarbeitung die zur Verbuchung
anstehenden IDocs dem verbuchenden Funktionsbaustein übergeben. Wählen Sie
dazu in der ALE-Administration den Pfad Überwachung ® IDocs manuell
verarbeiten, markieren Sie die IDocs und wählen Sie dann Verarbeiten.

Sie sollten die Hintergrundverarbeitung wählen, besonders wenn Massendaten


verteilt werden. Durch die zeitliche Trennung von IDoc-Erzeugung und IDoc-
Übergabe an die Kommunikationsschicht wird die Systemauslastung verbessert.
Bei im Hintergrund zu verarbeitenden, einzeln eintreffenden IDocs kann die
Paketverarbeitung [Seite 97] genutzt werden. Voraussetzung dafür ist ein
massenverarbeitungsfähiger Funktionsbaustein. Weiterere Vorteile bietet die
Parallele IDoc-Verarbeitung [Seite 93] im Eingang.

92 April 2001
SAP AG ALE-Einführung und Administration
Parallele IDoc-Verarbeitung

Parallele IDoc-Verarbeitung
Eine parallele IDoc-Verarbeitung ermöglicht die gleichzeitige Bearbeitung von IDocs durch
mehrere Dialogprozesse. Vorteile ergeben sich besonders beim Versenden von Massendaten.

Siehe auch:
Parallele IDoc-Erzeugung [Seite 94]
Paralleles Versenden von IDocs [Seite 95]
Parallele IDoc-Verbuchung [Seite 96]

April 2001 93
ALE-Einführung und Administration SAP AG
Parallele IDoc-Erzeugung

Parallele IDoc-Erzeugung
Parallele IDoc-Erzeugung durch mehrere Dialogprozesse kann nur beim direkten Senden von
Stammdaten genutzt werden. Das Programm RBDMIDOC zum Auswerten von
Änderungszeigern benutzt dagegen nur einen einzigen Dialogprozess.
Bei der ALE-Verteilung von Bewegungsdaten ist eine parallele IDoc-Erzeugung im allgemeinen
nicht sinnvoll, da es sich hier zumeist um Einzelvorgänge handelt, die durch zeitgleich
ablaufende Dialogprozesse nicht beschleunigt werden können.
Zur parallelen IDoc-Erzeugung ist es zwingend notwendig, daß eine Server-Gruppe definiert ist.
Die Server-Gruppe umfaßt die Applikationsserver, deren freie Dialogprozesse zur IDoc-
Erzeugung verwendet werden. Auf jedem Applikationsserver einer Server-Gruppe bleiben zwei
Dialogprozesse ungenutzt.
Die Server-Gruppe kann aus einem einzigen Applikationsserver bestehen. Werden von diesem
Applikationsserver Stammdaten gesendet, so werden die lokalen Dialogprozesse zur parallelen
IDoc-Erzeugung genutzt.
Zur Pflege der Server-Gruppe führen Sie im Customizing des ALE den folgenden Schritt aus:
Sender- und Empfängersysteme vorbereiten
Systeme im Netzwerk konfigurieren
Zielsysteme für RFC-Aufrufe definieren
Wählen Sie dann RFC ® RFC-Gruppen, um Gruppen anzulegen.

Parallele IDoc-Erzeugung ist von Vorteil beim direkten Senden großer Mengen von
Stammdaten.
Wählen Sie dazu Werkzeuge ® ALE ® Stammdatenverteilung ®
Anwendungsübergreifend ® Material ® Senden, und navigieren Sie weiter zum
gewünschten Stammdatum und Funktion.
Um die parallele IDoc-Erzeugung zu ermöglichen, müssen Sie im Dialogfenster
Material senden den Namen einer Server-Gruppe eintragen.
Da auf jedem Applikationsserver einer Server-Gruppe zwei Dialogprozesse
ungenutzt bleiben, ist darauf zu achten, daß auf den Applikationsservern genügend
Dialogprozesse vorhanden sind.

94 April 2001
SAP AG ALE-Einführung und Administration
Paralleles Versenden von IDocs

Paralleles Versenden von IDocs


Für die IDoc-Kommunikation durch den transaktionalen RFC (tRFC) werden alle verfügbaren
Dialogprozesse des Applikationsservers genutzt, auf dem die IDoc-Übergabe an die
Kommunikationsschicht erfolgt. Parallelisierung der tRFC-Kommunikation erfolgt unabhängig
davon, ob IDocs gesammelt oder sofort übergeben werden.

Die IDoc-Übergabe an die Kommunikationsschicht sollte auf einem


Anwendungsserver mit einer ausreichenden Anzahl von Dialogprozessen stattfinden.
Auf dem Anwendungsserver des empfangenden R/3-Systems ist eine ausreichende
Anzahl von Dialogprozessen zu definieren. Die Anzahl der Dialogprozesse soll nicht
kleiner sein als die Anzahl der Dialogprozesse des sendenden Anwendungsservers.

April 2001 95
ALE-Einführung und Administration SAP AG
Parallele IDoc-Verbuchung

Parallele IDoc-Verbuchung
Parallele IDoc-Verbuchung kann in folgenden Fällen genutzt werden:
· Sofortige Verarbeitung
Bei der sofortigen Verarbeitung werden zur Verbuchung alle Dialogprozesse des
empfangenden Applikationsservers genutzt. Dadurch kann es unter Umständen zu einer
Blockierung des Applikationsservers kommen. Eine Verteilung der eingehenden IDoc-
Pakete auf eine Server-Gruppe ist nicht möglich.
Ein IDoc-Paket kann aus einem oder mehreren IDocs bestehen. Für jedes IDoc-Paket
wird auf dem Applikationsserver ein Dialogprozess gestartet um den verbuchenden
Funktionsbaustein auszuführen. Besteht das IDoc-Paket aus mehreren IDocs und ist der
verbuchende Funktionsbaustein nicht massenverarbeitungsfähig, so wird die ALE-
Schicht den Funktionsbaustein innerhalb desselben Dialogprozesses mehrfach aufrufen
und ihm jeweils ein einzelnes IDoc zur Verbuchung übergeben.
· Verarbeitung im Hintergrund
Eingehende IDoc-Pakete werden in einzelne IDocs aufgetrennt und auf der Datenbank
abgelegt.
Übergabebereite IDocs (Status 64) können Sie in der ALE-Administration manuell
verarbeiten (Überwachung ® IDocs manuell verarbeiten).
Alternativ dazu können Sie die Verbuchung per Hintergrundverarbeitung veranlassen.
Führen Sie dazu im ALE-Einführungsleitfaden den folgenden Schritt aus:
Geschäftsprozesse modellieren und implementieren
Partnervereinbarungen und Verarbeitungszeitpunkt einplanen
Verbuchung von IDocs im Empfängersystem einplanen
Bei der IDoc-Verbuchung im Hintergrund können alle Applikationsserver einer Server-
Gruppe zur Parallelisierung genutzt werden. Die Server-Gruppe kann aus einem einzigen
Applikationsserver bestehen. Ohne Angabe einer Server-Gruppe werden alle
Dialogprozesse des lokalen Servers zur Parallelisierung genutzt. Dadurch kann es unter
Umständen zu einer Blockierung des Applikationsservers kommen.

Parallele IDoc-Verarbeitung ist von Vorteil bei der Verarbeitung von Massendaten.
Um die parallele IDoc-Verbuchung zu ermöglichen, wählen Sie im Einstiegsbild des
Programms RBDAPP01 (Eingangsverarbeitung von übergabebereiten IDocs) auf der
Karteikarte Parallelverarb. die Option unter Parallele Einbuchung wählen.
Geben Sie zur Parallelisierung der Verbuchung auf mehrere Applikationsserver eine
Server-Gruppe an.
Da auf jedem Applikationsserver einer Server-Gruppe zwei Dialogprozesse
ungenutzt bleiben, müssen Sie darauf achten, dass auf den Applikationsservern
genügend Dialogprozesse vorhanden sind.

96 April 2001
SAP AG ALE-Einführung und Administration
Paketverarbeitung

Paketverarbeitung
Die Paketverarbeitung erlaubt das Bearbeiten von Stapeln gleichartiger Daten durch ein
Programm oder einen Funktionsbaustein. Dadurch wird die Anzahl der aufgerufenen
Dialogprozesse verringert und das R/3-System entlastet.
Paketverarbeitung kann von ALE an folgenden Stellen genutzt werden:
· Paketverarbeitung in der IDoc-Erzeugung [Seite 98]
· Paketverarbeitung beim Versenden von IDocs [Seite 99]
· Paketverarbeitung in der IDoc-Verbuchung [Seite 100]

April 2001 97
ALE-Einführung und Administration SAP AG
Paketverarbeitung in der IDoc-Erzeugung

Paketverarbeitung in der IDoc-Erzeugung


Beim direkten Senden von Stammdaten wird für jedes einzelne Stammdatenobjekt, z.B.
Material, von spezifischen Funktionsbausteinen ein IDoc erzeugt. In den meisten Fällen kann
diesen Funktionsbausteinen mehr als ein Stammdatenobjekt zur IDoc-Erzeugung übergeben
werden.

Machen Sie von der Möglichkeit Gebrauch, beim direkten Senden von Stammdaten
eine größere Anzahl von Stammdatenobjekten pro Prozess zu übergeben. Als
Richtwert sei eine Anzahl zwischen 20 und 100 genannt. Dadurch verringert sich die
Zahl der genutzten Dialogprozesse und die Belastung eines R/3-Systems mit
administrativen Aufgaben.
Paketverarbeitung und Parallelisierung ergänzen einander. Unter Umständen
können sie miteinander konkurrieren. Wenn die Anzahl von Stammdatenobjekten pro
Prozess zu groß ist, werden möglicherweise nicht alle zur Verfügung stehenden
Dialogprozesse genutzt.

98 April 2001
SAP AG ALE-Einführung und Administration
Paketverarbeitung beim Versenden von IDocs

Paketverarbeitung beim Versenden von IDocs


Beim Versenden können mehrere IDocs zu einem Paket gebündelt und durch einen einzigen
transaktionalen Remote Function Call (tRFC) übergeben werden. Daraus ergeben sich folgenden
Vorteile:
· Die Systembelastung durch administrative Aufgaben bei der Kommunikation wird
verringert
· Auf dem sendenden R/3-System sind weniger Dialogprozesse mit der Bearbeitung des
tRFC belegt
· Auf dem empfangenden R/3-System sind weniger Dialogprozesse mit der Bearbeitung
des tRFC belegt

Die Paketgröße von Nachrichtentypen vereinbaren Sie im ALE-Einführungsleitfaden:


Geschäftsprozesse modellieren und implementieren
Partnervereinbarungen und Verarbeitungszeitpunkt einplanen
Partnervereinbarung generieren
Ein Richtwert für die Paketgröße ist 10 bis 200 IDocs. Je kleiner die IDocs sind,
desto größer kann die Paketgröße gewählt werden. Bei Nachrichtentypen wie z.B.
GLROLL oder ALEAUD, die eine große Anzahl von Daten beinhalten können, sollte
die Paketgröße bei 1 bis 10 liegen.
Falls die IDocs im empfangenden R/3-System nicht sofort gebucht werden, kann die
Anzahl aller Datensätze im IDoc-Paket ca. 10000 betragen. Beispielsweise kann bei
10 Datensätzen pro IDoc die Paketgröße bis zu 1000 IDocs betragen.

April 2001 99
ALE-Einführung und Administration SAP AG
Paketverarbeitung in der IDoc-Verbuchung

Paketverarbeitung in der IDoc-Verbuchung


Es gibt zwei Gruppen von verbuchenden Funktionsbausteinen:
· An massenverarbeitungsfähige Funktionsbausteine können ganze IDoc-Pakete
übergeben werden, deren IDocs in der selben Logical Unit of Work (LUW) verbucht
werden.
· Funktionsbausteine mit Einzeleingang verarbeiten nur ein IDoc pro Aufruf.
· Die Verarbeitungsweise eines Funktionsbausteins ist im INPUTTYP kodiert.
Zur Anzeige des INPUTTYPs eines Funktionsbausteins wählen Sie im Dialogfenster der ALE-
Entwicklung folgenden Pfad: IDoc ® Eingangsverarbeitung ® Funktionsbaustein ® Attribute
pflegen.
Der INPUTTYP kann folgende Werte annehmen:
· "0", für massen- bzw. paketverarbeitungsfähige Funktionsbauteine
"1" und "2", für Funktionsbausteine mit Einzeleingang
Bei sofortiger Verarbeitung bestimmt das sendende R/3-System die IDoc-Paketgröße. Die
ALE-Eingangsverarbeitung erkennt, ob der verbuchende Funktionsbaustein die
Paketverarbeitung zuläßt und übergibt diesem das IDoc-Paket. Wenn nicht, wird das IDoc-Paket
in einzelne IDocs aufgelöst.
Läuft die IDoc-Verbuchung im Hintergrund ab, kann bei der Ausführung des Programms
RBDAPP01 die Größe der zu erstellenden IDoc-Pakete angegeben werden.

Durch die Paketverarbeitung verringert sich die Datenbankbelastung bei der IDoc-
Verbuchung durch massenverarbeitungsfähige Funktionsbausteine.
Auch bei Funktionsbausteinen mit Einzeleingang kann das Bündeln von IDocs
sinnvoll sein, da die ALE-Schicht den Funktionsbaustein innerhalb des selben
Dialogprozesses mehrfach aufruft und dadurch die Belastung eines R/3-Systems
durch administrative Aufgaben verringert.
Bei der Hintergrundverarbeitung durch RBDAPP01 gilt für die Paketgröße ein
Richtwert von 20 bis 100.
Paketverarbeitung und Parallelisierung ergänzen einander. Unter Umständen
können sie miteinander konkurrieren. Wenn die Paketgröße zu groß ist, werden
möglicherweise nicht alle zur Verfügung stehenden Dialogprozesse genutzt.

100 April 2001


SAP AG ALE-Einführung und Administration
Administration der IDoc-Kommunikation

Administration der IDoc-Kommunikation


Die technische Basis der IDoc-Kommunikation ist der transaktionale Remote Function Call
(tRFC).
Durch folgende Einstellungen und Prozeduren kann die ALE-Verarbeitung optimiert werden:
· Hintergrund-Job unterdrücken bei Kommunikationsfehlern [Seite 102]
· Versendestatus Versand OK setzen [Seite 103]
· Status der tRFC-Aufrufe prüfen [Seite 104]

April 2001 101


ALE-Einführung und Administration SAP AG
Hintergrund-Job unterdrücken bei Kommunikationsfehlern

Hintergrund-Job unterdrücken bei


Kommunikationsfehlern
In der Standardauslieferung wird vom R/3-System bei tRFC-Fehlern ein Hintergrund-Job erzeugt,
um eine erneute Kommunikation zu versuchen. Dies führt unter Umständen zu einer sehr großen
Zahl von Hintergrund-Jobs, die die Hintergrundverarbeitung vollkommen blockieren können.

Unterdrücken Sie das Erzeugen eines Hintergrund-Jobs bei tRFC-


Kommunikationsfehlern und benutzen Sie das Programm RSARFCEX, um
fehlerhafte tRFC-Aufrufe erneut auszuführen.
Wählen Sie dazu im ALE-Einführungsleitfaden des ALE eine Verbindung zur
Änderung aus:
Sender- und Empfängersysteme vorbereiten
Systeme im Netzwerk konfigurieren
Zielsysteme für RFC-Aufrufe definieren
Wählen Sie dann Destination ® tRFC-Optionen und markieren Sie die Option
Batchjob unterdrücken bei Komm. Fehler. Alternativ dazu können Sie auch im R/3-
Eingangsdialogfenster über Werkzeuge ® Administration ® Verwaltung ® Netzwerk
® RFC-Destinationen zur Destinationspflege gelangen.

102 April 2001


SAP AG ALE-Einführung und Administration
Versendestatus Versand OK setzen

Versendestatus Versand OK setzen


Bei der Übergabe eines IDocs an die Kommunikationsschicht wird dem IDoc ein weltweit
eindeutiger Transaktions-Identifikator (TID) zugeteilt. Wenn das IDoc erfolgreich versendet
wurde, wird diese Information nicht automatisch an die ALE-Schicht weitergeben. Damit die ALE-
Verarbeitung den IDoc-Status auf Versand OK setzt, ist ein Abgleich zwischen Kommunikations-
und ALE-Schicht über die Transaktions-Identifikatoren nötig.
Das Programm RBDMOIND prüft, ob die an den transaktionalen RFC übergebenen IDocs bereits
in das empfangende R/3-System übertragen wurden. Falls die Kommunikation erfolgreich war,
wird der IDoc-Status auf "12", Versand OK, gesetzt.

Starten Sie das Programm RBDMOIND nach der Übergabe des IDocs an die
Kommunikationsschicht, um den Versendestatus des IDocs zu setzen.

April 2001 103


ALE-Einführung und Administration SAP AG
Status der tRFC-Aufrufe prüfen

Status der tRFC-Aufrufe prüfen


Um den Status der tRFC-Aufrufe zu überprüfen, wählen Sie Werkzeuge ® Administration ®
Monitor ® Transaktionaler RFC und geben Sie, wenn gewünscht, zusätzliche Selektionskriterien
an. tRFC-Aufrufe, die IDocs übertragen, benutzen auf der Empfängerseite den Funktionsbaustein
IDOC_INBOUND_ASYNCHRONOUS (vor Release 4.0: INBOUND_IDOC_PROCESS).
Falls ein IDoc im sendenden R/3-System an den tRFC übergeben wurde (IDoc-Status "03"), aber
auf der Empfängerseite noch nicht eingegangen ist, gilt der entsprechende tRFC-Aufruf als noch
nicht ausgeführt.
Mit dem Programm RSARFCEX können nicht ausgeführte tRFC-Aufrufe erneut gestartet werden.

In der Hintergrundverarbeitung darf die Option wird gerade ausgeführt nicht


ausgewählt sein.

104 April 2001


SAP AG ALE-Einführung und Administration
Serialisierung von Nachrichten

Serialisierung von Nachrichten


Verwendung
Serialisierung spielt eine wichtige Rolle bei der Verteilung von voneinander abhängigen
Objekten, insbesonders bei Stammdaten.
Durch eine serialisierte Verteilung von Nachrichten wird eine bestimmte Reihenfolge bei der
Erzeugung, Versendung und Verbuchung der entsprechenden IDocs eingehalten.
Dadurch werden Fehler bei der Eingangsverarbeitung der IDocs vermieden.

Funktionsumfang
Für eine serialisierte Verteilung voneinander abhängiger Nachrichten stehen Ihnen folgende
Möglichkeiten zu Verfügung:
· Serialisierung über Objekttypen [Extern]
· Serialisierung über Nachrichtentypen [Extern]
· Serialisierung auf IDoc-Ebene [Seite 109]
(nicht für IDocs von generierten BAPI-ALE-Schnittstellen)

April 2001 105


ALE-Einführung und Administration SAP AG
Serialisierung über Objekttypen

Serialisierung über Objekttypen


Verwendung
Serialisierte Nachrichten können unterschiedlicher Art sein (z.B. Anlege-, Änderungs-,
Stornierungsnachricht). Alle betrachteten Nachrichten beziehen sich jedoch auf ein einziges
spezielles Anwendungsobjekt.
Die Nachrichten können sowohl Stamm- als auch Bewegungsdaten enthalten.
Mit der Objektserialisierung wird sichergestellt, daß die Reihenfolge dieser Nachrichten bezüglich
eines bestimmten Objektes auf der Empfängerseite immer gewahrt bleibt, d.h. die
Buchungsreihenfolge auf der Empfängerseite der auf der Senderseite festgelegten Reihenfolge
entspricht.

Voraussetzungen
Die serialisierte Verteilung müssen Sie in beiden Systemen per Customizing aktivieren:
Werkzeuge ® AcceleratedSAP ® Customizing ® Projektbearbeitung
SAP Referenz-IMG
Basis
Application Link Enabling (ALE)
Geschäftsprozesse modellieren und implementieren
Verteilung von Stammdaten konfigurieren
Serialisierung der Daten beim Senden und Empfangen einstellen
Serialisierung über Objekttypen

Funktionsumfang
Der zu übertragenden Nachricht (IDoc) wird eine fortlaufende Nummer zugewiesen. Diese wird
im Sender- und im Empfängersystem pro Objekttyp und Objektkanal verwaltet. Ein Objektkanal
enthält eine logische Menge reihenfolgesortierter IDocs und definiert sich über einen Objekttypen
(BOR) und genau eine Kanalnummer, die ein Attribut zu Nachrichten ist. In einem Objektkanal
werden alle Nachrichten im Zielsystem in der gleichen Reihenfolge bearbeitet, wie sie im
Quellsystem entstanden sind. Eine Kanalnummer ist ein Attribut zu Nachrichten. Sie wird über
den Funktionsbaustein ALE_SERIAL_KEY2CHANNEL generiert oder im Anwendungsprogramm
vergeben.
Anhand dieser Nummer werden folgende Situationen erkannt:
· RFC-Übertragungsfehler
· Der Anwendungsbeleg zu einer Nachricht ist noch nicht gebucht (Statuscode 53), obwohl die
nachfolgende Nachricht bereits eingetroffen ist
In beiden Fällen wartet das IDoc im Eingang auf sein Vorgänger-IDoc und erhält zu diesem
Zweck den Statuscode 66. Nachdem das Vorgänger-IDoc gebucht wurde, müssen Sie das IDoc
im Status 66 mit dem Programm RBDAPP01 nachträglich buchen.
Alle Nachrichten, deren Kanalnummer und Objekttyp identisch sind, werden bei der Aktivierung
serialisiert.

106 April 2001


SAP AG ALE-Einführung und Administration
Serialisierung über Objekttypen

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

Auf der Ausgangsseite (Im Quellsystem)


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

Auf der Eingangsseite (Im Zielsystem)


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

April 2001 107


ALE-Einführung und Administration SAP AG
Serialisierung über Nachrichtentypen

Serialisierung über Nachrichtentypen


Verwendung
Durch eine serialisierte Verteilung der Nachrichtentypen wird eine bestimmte Reihenfolge bei der
Erzeugung, Versendung und Verbuchung der entsprechenden IDocs eingehalten.
Die Abhängigkeit zwischen Objekten wird auf Nachrichtentyp-Ebene berücksichtigt.

Ein Beispiel ist der Einkaufsinfosatz mit Lieferant und Material. Auf dem
Empfängersystem müssen der Lieferant und das Material vor dem Einkaufsinfosatz
angelegt werden, um einen Verbuchungsfehler zu vermeiden.

Voraussetzungen
Die serialisierte Verteilung der Nachrichtentypen müssen Sie in beiden Systemen per
Customizing aktivieren.
Basis
Verteilung (ALE)
Geschäftsprozesse modellieren und implementieren
Verteilung von Stammdaten konfigurieren
Serialisierung der Daten beim Senden und Empfangen einstellen
Serialisierung über Nachrichtentypen

Funktionsumfang
Die serialisierte Verteilung wird nur für die Übertragung von Änderungen der Stammdaten
unterstützt. Die Nachrichtentypen der IDocs werden in der vorgesehenen
Übertragungsreihenfolge in einer Serialisierungsgruppe zusammengefaßt. In genau dieser
festgelegten Reihenfolge erfolgt auch die Verteilung der Stammdaten. Sind alle IDocs der
Serialisierungsgruppe erfolgreich versendet worden, so wird vom Sendesystem eine spezielle
Steuernachricht an die Empfängersysteme versendet. Diese Steuernachricht enthält die
Verbuchungsreihenfolge der IDocs und startet die Eingangsverarbeitung der IDocs auf den
Empfängersystemen.
Die serialisierte Verteilung von Nachrichtentypen stellt keine vollkommen neue Art der
Stammdatenverteilung dar, sondern nutzt bereits vorhandene ALE-Mechanismen der Verteilung
unter Beachtung einer bestimmten Reihenfolge der Nachrichtentypen. Diese Verteilung könnte
auch manuell durch die Ausführung vorhandener ALE-Reports durchgeführt werden. Mittels der
serialisierten Verteilung werden diese Einzelschritte jedoch automatisiert und über Batch-Jobs
einplanbar.
Die Menüoberfläche der Serialisierung gestattet die Auswahl von Selektionskriterien, die den
Ablauf der serialisierten Verteilung bestimmen. Dazu gehören z.B. das Versenden der
Steuernachricht und die Eingangsverarbeitung der IDocs.

108 April 2001


SAP AG ALE-Einführung und Administration
Serialisierung auf IDoc-Ebene

Serialisierung auf IDoc-Ebene


Verwendung
Verzögerungen in der Übertragung von IDocs können bewirken, daß ein IDoc mit Daten eines
Objektes vor einem "älteren" IDoc mit unterschiedlichen Daten des gleichen Objektes eintrifft.
Eine Anwendung kann das ALE-Serialisierung-API nutzen, um die zeitliche Reihenfolge von
IDocs eines Nachrichtentyps zu erkennen und bei Überholungen die Verbuchung alter Daten zu
verhindern.
Es wird Ihnen dringend empfohlen, regelmäßig das Programm RBDSRCLR zur Bereinigung der
Tabelle BDSER (alte Zeitstempel) einzuplanen.

Voraussetzungen
Die Serialisierung auf IDoc-Ebene ist nicht möglich für IDocs von generierten BAPI-IDoc-
Schnittstellen, da der Funktionsbaustein zur Eingangsverarbeitung das ALE-Serialisierungs-API
nicht nutzt.

Funktionsumfang
ALE stellt zwei Funktionsbausteine zur Serialisierung von IDocs bereit, die vom verbuchenden
Funktionsbaustein aufgerufen werden müssen:
· IDOC_SERIALIZATION_CHECK
Zum Prüfen von Zeitstempeln im Serialisierungsfeld des IDoc-Kopfes
· IDOC_SERIAL_POST
Zum Aktualisieren der Serialisierungtabelle.

April 2001 109


ALE-Einführung und Administration SAP AG
Umsetzung logischer Systeme

Umsetzung logischer Systeme


Einsatzmöglichkeiten
Aufgrund der zunehmenden Komponentisierung und Offenheit von R/3 müssen logische
Systeme auch jenseits eines ALE-Verbunds miteinander kommunizieren können, beispielsweise
im Rahmen der zentralen Benutzerverwaltung. Logische Systeme sollten daher eindeutige
Namen haben, auch jenseits von Verbundgrenzen.
Ab dem R/3-Release 4.5A bietet SAP eine automatisierte Umsetzung des logischen
Systemnamens in allen Anwendungs-, Stammdaten- und Steuertabellen über ein Werkzeug an.
Ab dem R/3-Release 4.6C ist dieses Werkzeug in die Mandantenkopie integriert.
Dabei werden sowohl mandantenabhängige als auch mandantenunabhängige Tabellen
berücksichtigt.

· Auf keinen Fall dürfen Sie die Umsetzung in einem Produktivsystem


durchführen.

· Die Umsetzung der Namen von logischen Systemen kann zu Inkonsistenzen


des Datenbestandes führen und sollte nur in Ausnahmefällen und nach
Sicherung der Datenbank erfolgen.

· Ändern Sie nie manuell den logischen Systemnamen in den relevanten


Tabellen.

· Noch nicht verarbeitete IDocs müssen verarbeitet werden, bevor Sie mit der
Umsetzung beginnen, da diese IDocs logische Systemnamen enthalten
können.

· Während des Laufs des Umsetzungsprogramms dürfen keine anderen


Aktivitäten im System durchgeführt werden.

· Die Umsetzung muss in allen Partnersystemen durchgeführt werden. Sie


erfolgt im aktuellen Mandanten, d.h., für alle mandantenabhängigen und -
unabhängigen Tabelleneinträge.

Voraussetzungen
Der Benutzer des Programms muß das Berechtigungsobjekt B_ALE_SYS in seinem
Benutzerprofil besitzen.
Es wird empfohlen, daß ausschließlich der ALE-Systemadministrator diese Berechtigung erhält.

Ablauf
Um die Umsetzung zu veranlassen, starten Sie die Transaktion BDLS.
Der alte logische Systemname erscheint als Vorschlagswert.
Geben Sie den neuen logischen Systemnamen an.

110 April 2001


SAP AG ALE-Einführung und Administration
Umsetzung logischer Systeme

Mit dem Testmodus des Reports können Sie eine Umsetzung simulieren, d.h. es werden nur die
betroffenen Tabellen und die Anzahl der umzusetzenden Tabelleneinträge angezeigt. Eine
Umsetzung der Tabelleneinträge auf der Datenbank erfolgt nicht. Sie können die Ergebnisse
auswerten und Abschätzungen über die Laufzeit treffen.
Der Report führt folgenden Schritte aus:
1. Ermitteln aller aktiven, transparenten Datenbanktabellen, deren Felder auf folgende
Domänen referenzieren
· LOGSYS
· EDI_PARTNUM
2. Umsetzen der Feldwerte auf den neuen logischen Systemnamen
3. Änderung auf der Datenbank durchführen

Transport von Änderungen


Es erfolgt kein Transport der geänderten Tabelleninhalte.

Umsetzung von EDI-Tabellen


Bei der Umsetzung von EDI-Tabellen ermittelt das Programm zusätzlich die Tabellenfelder für
die Partnerart, die den Wert LS (logisches System) enthalten. Die zugehörigen logischen
Systemnamen werden umgesetzt.

Ausnahmen
Ist der neue logische Systemname auf dem lokalen R/3-System (d.h. wo die Umsetzung
stattfinden soll) in der Tabelle TBDLS gepflegt, so erfolgt keine Umsetzung. Man muß davon
ausgehen, daß der neue logische Systemname bereits verwendet wird (z.B. im ALE-
Verteilungsmodell).

April 2001 111


ALE-Einführung und Administration SAP AG
ALE-Recovery für Datenkonsistenz

ALE-Recovery für Datenkonsistenz


Verwendung
Auch im verteilten Umfeld können Sie ein R/3-System nach einem Systemausfall aufgrund eines
Datenbankfehlers wiederherstellen. Mit Hilfe der Datenbanksicherung (Backup) und durch
zeitpunktgenaues Wiederaufsetzen (Point-In-Time Recovery) können Sie die Datenbank auf den
Stand des Systemabbruchs zurücksetzen und weiterbetreiben.
In diesem Fall können nach dem Zeitpunkt, auf den das System zurückgesetzt wird, noch
Transaktionen stattgefunden haben, die durch das Zurücksetzen zunächst verloren gehen und
noch einmal wiederholt werden müssen. Dabei werden externe Interaktionen (z.B. ALE, EDI,
Brief, Fax, Telefax), gegebenenfalls unter anderem Schlüssel, verdoppelt und erfordern eine
besondere Behandlung.
Wenn beispielsweise im Zeitraum zwischen dem Auftreten des Fehlers und dessen Entdeckung
auf dem wiederherzustellenden System (Recovery-System) ein Prozeß stattgefunden hat, der
eine Nachricht an ein anderes System gesendet und dort einen neuen Prozeß gestartet hat, so
sind nach dem Wiederaufsetzen die Informationen des Prozesses auf dem wiederaufgesetzten
System nicht mehr vorhanden. Auf dem empfangenden System bestehen die Ergebnisse des
dort ausgeführten Folgeprozesses jedoch weiterhin. Diese Inkonsistenz der beiden Systeme läßt
sich dadurch beheben, daß auf dem Empfängersystem die aus der Kommunikation entstandenen
Daten storniert werden.
Im Fall eines solchen zeitpunktgenauen Wiederaufsetzens müssen also bei den
Kommunikationspartnern des Systems bestimmte Belege storniert werden und Nachrichten, die
zu einem früheren Zeitpunkt vom Empfängersystem schon einmal gesendet wurden, erneut
versendet werden. Dazu ist es notwendig, alle Aktionen zu ermitteln, die im Rahmen der
Wiederherstellung des Systems ausgeführt werden müssen.
Dazu stehen Ihnen die ALE-Recovery-Werkzeuge zur Verfügung.
Die ALE-Recovery-Werkzeuge sind auch für die Kommunikation mit Nicht-SAP-Systemen
nutzbar.

Voraussetzungen
Folgende Voraussetzungen gelten für das Wiederaufsetzen:
· Datenbank, die ein zeitpunktgenaues Wiederaufsetzen (Point-In-Time Recovery) zuläßt
· Kontinuierliche Datenbanksicherung
· Die Datenbank des wiederaufgesetzten Systems ist bereits auf den letzten Stand vor
Auftritt des Fehlers wiederhochgefahren worden.

Funktionsumfang
Die ALE-Recovery-Werkzeuge führen die erforderlichen Analysen durch und unterstützen Sie
beim Durchführen der notwendigen Aktionen:
1. Das wiederhergestellte System veranlaßt seine Kommunikationspartner, Informationen
über die IDocs zu geben, die im betroffenen Zeitraum zwischen den Systemen
ausgetauscht wurden.

112 April 2001


SAP AG ALE-Einführung und Administration
ALE-Recovery für Datenkonsistenz

2. Die Kommunikationspartner des wiederhergestellten Systems liefern diese Informationen


zurück.
3. Auf dem wiederhergestellten System werden die zurückgelieferten Informationen mit den
dort vorhandenen verglichen. Daraus wird abgeleitet, welche weiteren Aktivitäten
erforderlich sind, um einen konsistenten Zustand des gesamten verteilten Umfeldes
wiederherzustellen. Der Status von IDocs wird im wiederhergestellten System
aktualisiert.
4. Für die Kommunikationspartner wird eine Liste der zu stornierenden Belege erzeugt.
Falls erforderlich wird das Wiederversenden von IDocs automatisch angestoßen.
Nicht alle Inkonsistenzen können automatisch durch die Recovery-Tools beseitigt werden. Zum
Teil müssen Sie die ermittelten Inkonsistenzen manuell beseitigen. Dies gilt insbesondere für die
Stornierung von Anwendungsbelegen.

Aktivitäten
Zur Beseitigung von Inkonsistenzen müssen Sie folgende R/3-Transaktionen durchführen:
· Recovery-Objekte ermitteln: Transaktionscode BDRC
· Recovery-Objekte verarbeiten: Transaktionscode BDRL

Weitere Informationen hierzu finden Sie in der Programmdokumentation.


Darüberhinaus stehen Ihnen folgende Funktionen zur Verfügung:
· Anwendungslog für ALE-Recovery-Vorgang:
Transaktionscode BDR1
Die wichtigen Parameter, die Sie in den Transaktionen Recovery-Objekte
ermitteln und Recovery-Objekte verarbeiten angegeben haben, werden
protokolliert. Sie können sich diese über BDR1 angezeigen lassen.
· Reorganisation der Daten für Recovery-Objekte: Transaktionscode BDR2
Es handelt sich um Daten, die in den Transaktionen Recovery-Objekte ermitteln
und Recovery-Objekte verarbeiten erzeugt wurden, um den Status von
Recovery-Objekten zu kennzeichnen.
Bei der Reorganisation werden solche Daten gelöscht, wenn folgende Bedingungen
zutreffen:
· Recovery-Objekte erfordern keine weitere Bearbeitung.
· Recovery-Objekte wurden bereits verarbeitet.

April 2001 113