ALE-Einführung und Administration

Transkript

1 ALE-Einführung und Administration HELP.BCMIDALEIO Release 4.6C

2 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. INFORMIX -OnLine for SAP und Informix Dynamic Server TM 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

3 SAP AG Symbole Symbol Bedeutung Achtung Beispiel Hinweis Empfehlung Syntax April

4 SAP AG Inhalt...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 April 2001

5 SAP AG 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 Administration der IDoc-Kommunikation Hintergrund-Job unterdrücken bei Kommunikationsfehlern Versendestatus Versand OK setzen Status der trfc-aufrufe prüfen Serialisierung von Nachrichten Serialisierung über Objekttypen Serialisierung über Nachrichtentypen Serialisierung auf IDoc-Ebene Umsetzung logischer Systeme ALE-Recovery für Datenkonsistenz April

6 SAP AG 6 April 2001

7 SAP AG 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

8 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

9 SAP AG 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

10 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

11 SAP AG 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

12 SAP AG Ablauf der Verteilung über BAPIs Anwendung ALE-Schicht Kommunikations- ALE-Schicht Anwendung Schicht - Empfänger ermitteln - Generierten Funktionsbaustein aufrufen Verteilungsmodell IDoc Segmentfilterung Generierter Funktionsbaustein auf Ausgangsseite Datenfilterung BAPI IDoc Umwandlung trfc oder EDI Feldumsetzung Übergabesteuerung Generierter Funktionsbaustein auf Eingangsseite IDoc BAPI Umwandlung Segmentfilterung Serialisierung Feldumsetzung Versionswandlung IDoc BAPI- Funktionsbaustein aufrufen Datenbank Verknüpfung IDoc Versendesteuerung Daten und IDoc-Status aktualisieren Datenbank IDoc-Status ermitteln 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

13 SAP AG Umwandlung des IDocs in einen BAPI-Aufruf Aufruf des BAPI-Funktionsbausteins IDoc-Status ermitteln Buchen der Anwendungsdaten und des IDoc-Status Ablauf der Verteilung über BAPIs 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

14 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

15 SAP AG 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

16 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

17 SAP AG 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

18 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 erzeugen? Verteilungsmodell Stamm-IDoc erzeugen Stamm IDoc Empfängerermittlung IDoc Segmentfilterung Feldumsetzung trfc oder EDI Segmentfilterung Feldumsetzung Versionswandlung Übergabesteuerung IDoc IDoc IDoc Serialisierung IDoc verarbeiten Datenbank Verknüpfung Versendesteuerung Datenbank IDoc-Status gleichzeitig aktualisieren Anwendungsbeleg buchen 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

19 SAP AG 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

20 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

21 SAP AG 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

22 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

23 SAP AG 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

24 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: Ablauf 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? 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

25 SAP AG 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

26 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

27 SAP AG 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

28 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

29 SAP AG 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

30 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 Struktur Lieferant 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

31 SAP AG 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

32 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

33 SAP AG 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

34 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