Show TOC

Dokumentation zur KomponenteGrundkonzepte der ALE-Technologie Dieses Dokument in der Navigationsstruktur finden

 

ALE unterstützt Konfiguration und Betrieb von verteilten Anwendungen. Es umfasst einen betriebswirtschaftlich kontrollierten Nachrichtenaustausch zwischen verteilten Anwendungen bei konsistenter Datenhaltung. Die Kopplung zwischen den verteilten Systemen kann dabei eng oder lose sein.

Die Anwendungsintegration erfolgt nicht über eine zentrale Datenbank. Stattdessen 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 SAP-Systemen unterschiedlicher Release-Stände

  • Datenaustausch nach Release-Wechsel ohne weitere Pflege gewährleistet

  • Kundenspezifische Erweiterungen

  • Anbindung von Nicht-SAP-Systemen über Kommunikationsschnittstellen

Für die Kommunikation zwischen verteilten Anwendungssystemen stellt ALE bestimmte Services und Tools zur Verfügung:

  • Möglichkeit zur Pflege eines Verteilungsmodells

  • Konsistenzprüfungen

  • Monitoring der Datenübertragung

  • Fehlerbehandlung

  • Werkzeuge zur Synchronisation

  • Werkzeuge zur Definition neuer ALE-Geschäftsprozesse

Integration

Arten der Kopplung

Wie zuvor erwähnt, kann die Kopplung zwischen den verteilten Anwendungssystemen entweder lose oder eng erfolgen. Eine lose Kopplung wird über asynchrone Kommunikation realisiert und bei schreibenden Zugriffen verwendet. Eine enge Kopplung über synchrone Aufrufe sollte dagegen nur beim Lesen von Daten eingesetzt werden.

Beide Arten der Kopplung können über den Aufruf von BAPIs realisiert werden.

Lose Kopplung

Im verteilten Umfeld ist es besonders wichtig, dass die Systeme lose gekoppelt und voneinander unabhängig sind. Bei einem Ausfall des aufgerufenen Systems oder einem Kommunikationsfehler kann das Aufrufsystem weiterarbeiten. Ein Beispiel, in dem eine lose Kopplung essentiell ist, ist die Bestandsführung: Wenn eine Bestandsführungskomponente mit einer Rechnungswesenkomponente gekoppelt ist, müssen Warenbewegungen auch dann buchbar sein, wenn die Rechnungswesenkomponente nicht verfügbar ist.

Lose Kopplung bedeutet also, dass die einzelnen Systeme größtenteils asynchron miteinander kommunizieren. Bei dieser Art der Kommunikation werden Nachrichten zwischen den Systemen ausgetauscht. Das für diese Nachrichten verwendete Datenformat ist das Intermediate Document (IDoc). IDocs sind strukturierte Datencontainer, in denen Daten hierarchisch abgelegt werden können. Weitere Informationen zu Idocs finden Sie im Dokument "ALE-Einführung und Administration" unter IDoc-Schnittstelle / ALE.

Für das Versenden dieser IDocs können unterschiedliche Kommunikationstechnologien verwendet werden:

  • Bei der asynchronen Kommunikation zwischen zwei SAP-Systemen ist die zugrundeliegende Kommunikationstechnik der transaktionale Remote Function Call (tRFC). Der transaktionale Aufruf wird nicht sofort ausgeführt, sondern die zu übertragenden Daten werden zuerst in eine Datenbanktabelle geschrieben. Wenn im Aufrufprogramm ein COMMIT WORK abgesetzt wird, wird der Remote-Call zum Empfangssystem ausgeführt. Ist das Empfangssystem gerade nicht verfügbar, so versucht ein periodisch eingeplanter Hintergrundprozess, die Daten an das Empfangssystem zu senden. Der tRFC garantiert dabei, dass die Daten genau einmal übertragen werden.

  • Sollen SAP-Systeme und Fremdsysteme asynchron miteinander kommunizieren, können auch CPIC, MQSeries oder andere Komunikationstechniken für die Übertragung der IDocs verwendet werden.

Tritt bei der Verarbeitung des IDocs ein Fehler auf, wird das fehlerhafte IDoc abgespeichert und ein Workflow erzeugt, der es dem ALE-Administrator ermöglicht, diesen Fehler zu bearbeiten. Durch diese ALE-Fehler-behandlungsfunktionen wird sichergestellt, dass die Daten konsistent fortgeschrieben werden. Daher sollten generell Datenreplikationen, Updates oder Inserts von Daten auf anderen Systemen asynchron erfolgen. Der Nachteil der asynchronen Kommunikation über ALE ist, dass auf Rückgabeparameter vom aufgerufenen System, abgesehen vom Return-Parameter, nicht zugegriffen werden kann.

Hinweis Hinweis

Beachten Sie bitte, dass asynchrone Kommunikation nicht automatisch gleichzusetzen ist mit großem Zeitverzug zwischen Aufruf und Ausführung. Für den Fall, dass das Zielsystem verfügbar ist, kann ein asynchroner Aufruf ebenfalls sofort nach dem COMMIT WORK im aufgerufenen System ausgeführt werden.

Ende des Hinweises.

Bei der asynchronen Kommunikation über BAPIs wird im rufenden System (Client) anstatt des BAPI-Aufrufs ein IDoc mit den Daten aus dem BAPI-Aufruf erzeugt und an das gerufene System (Server) geschickt. Im gerufenen System wird anschließend das BAPI mit den Daten aus diesem IDoc aufgerufen. Weitere Einzelheiten finden Sie in Realisierung der losen Kopplung über BAPIs.

Enge Kopplung

Im Gegensatz zur losen Kopplung erfordert die enge Kopplung das Vorhandensein des aufgerufenen Systems. Die enge Kopplung wird allgemein über den synchronen Aufruf eines remotefähigen Funktionsbausteins realisiert. Im Gegensatz zur asynchronen Kommunikation können die Exportparameter des Funktionsbausteins ausgewertet werden. Synchrone Aufrufe eignen sich zum Prüfen oder Lesen von Daten in anderen Systemen. ALE unterstützt ab Release 4.0 synchrone BAPI-Aufrufe. Ab Release 4.5A werden sogenannte synchrone Dialogaufrufe unterstützt. Hier wird der Aufrufer des BAPI-Funktionsbausteins unter Angabe der "destination" automatisch in das andere System eingeloggt ("Remote Login"). Er sieht die Transaktion im gleichen Fenster und kann über Menues etc. im aufgerufenen System navigieren. Synchrone Dialogmethoden sind im BOR sichtbar und werden im ALE-Verteilungsmodell modelliert.

Achtung Achtung

In der Regel ist das synchrone Schreiben zwischen zwei Datenbanksystemen nicht erlaubt, um zu vermeiden, dass bei Übertragungsfehlern Datenbank-Inkonsistenzen auftreten !

Ende der Warnung.

Weitere Einzelheiten finden Sie unter Realisierung der engen Kopplung über BAPIs.

Nutzung des ALE-Verteilungsmodells

Das ALE-Verteilungsmodell beschreibt den Nachrichtenfluss zwischen logischen Systemen. Im Verteilungsmodell wird festgelegt, welche Nachrichten zwischen Systemen ausgetauscht werden bzw. welche BAPIs (ab Release 4.0) aufgerufen werden.

Filterung

Die Übertragung kann über Filter datenabhängig gesteuert werden. Filter sind Bedingungen, die von Nachrichtentypen und BAPIs erfüllt werden müssen, um von der ALE-Ausgangsverarbeitung verteilt zu werden.

Beispiel Beispiel

Ein Kunde hat ein zentrales Bestandsführungssystem und mehrere Rechnungswesensysteme im Einsatz. Ändert sich der Bestand im Buchungskreis 0001, werden RW-Daten an das RW-System 01 geschickt, bei Bestandsänderungen im Buchungskreis 0002 werden die RW-Daten an das RW-System 02 geschickt.

Ende des Beispiels.

Für BAPIs lassen sich folgende Typen von Filtern unterscheiden:

  1. Empfängerfilterung

    In Empfängerfiltern können Abhängigkeiten zwischen BAPIs oder zwischen einem BAPI und einem Nachrichtentyp definiert werden, die Auswirkungen auf Ermittlung der erlaubten Empfänger haben. Weitere Informationen zur Empfängerfilterung finden Sie im ALE-Programmierleitfaden unter Empfänger für ein BAPI ermitteln.

  2. Datenfilterung

    In Rahmen der Datenfilterung stehen die beiden Filterdienste Schnittstellenreduzierung und Parameterfilterung zur Verfügung.

    • Die Schnittstellenreduzierung ermöglicht das Ausblenden von Feldern an der BAPI-Schnittstelle, so dass beim Empfänger diese Felder nicht beachtet werden. So kann beispielsweise ein ungewolltes Überschreiben bestimmter Felder verhindert werden.

    • Die Parameterfilterung ermöglicht es, den Umfang der im BAPI zu übertragenden Datenmenge zu steuern, indem Zeilen von BAPI-Tabellenparametern herausgefiltert werden können, die nicht bestimmte Bedingungen erfüllen. Liegen zwischen einzelnen Tabellenparametern des BAPIs hierarchische Abhängigkeiten vor, müssen zusätzlich Parameterhierarchien definiert werden. Weitere Informationen hierzu finden Sie im ALE-Programmierleitfaden unter Hierarchien zwischen BAPI-Parametern definieren.

      Weitere Informationen zur Datenfilterung finden Sie im ALE-Programmierleitfaden unter Daten filtern.

Um die Empfängerermittlung und die Parameterfilterung durchführen zu können, werden Filterobjekte benötigt, die vor der Pflege des Verteilungsmodells angelegt werden müssen. Filterobjekte setzen sich aus einem Filterobjekttyp und einem Objektwert zusammen. Filterobjekttypen für BAPIs entsprechen einem Parameternamen beim Aufruf des BAPIs. Sie prüfen, ob ein Parameter den vorgegebenen Objektwert besitzt. Nur wenn dies zutrifft, wird das BAPI verteilt.

Für die Schnittstellenreduzierung müssen dagegen keine Filterobjekte angelegt werden. Sie ist allerdings nur für bestimmte Arten von BAPIs anwendbar, deren Schnittstelle diese Filterung explizit ermöglicht.

Pflege des Verteilungsmodells

Sowohl im synchronen, als auch im asynchronen Fall sollte das Zielsystem für den Remoteaufruf über das ALE-Verteilungsmodell ermittelt werden. Das ALE-Verteilungsmodell, das Bestandteil des allgemeinen IMG-Customizing ist, kann im Einführungsleitfaden über den Pfad   Basis   Application Link Enabling (ALE)   Geschäftsprozesse modellieren und implementieren   Verteilungsmodell pflegen   erreicht werden.

Um die benötigten Filterobjekttypen anzulegen, ist im SAP-Menü zunächst der Pfad   Werkzeuge   ALE   ALE-Entwicklung   BAPI   auszuwählen. Anschließend können Filterobjekttypen für die Datenfilterung unter dem Pfad   Datenfilterung   Filterobjekttyp pflegen   bzw. Filterobjekttypen für die Empfängerfilterung unter   Empfängerermittlung   Filterobjekttyp pflegen   angelegt werden.

Wenn Sie die Verbindung zwischen zwei Systemen testen wollen, müssen Sie beim Pflegen des Verteilungsmodells noch folgende Einstellungen vornehmen:

  1. Festlegen der eindeutigen Mandantenkennung und des logischen Systems

  2. Festlegen der technischen Kommunikationsparameter

  3. Generieren der Partnervereinbarungen im sendenden System

  4. Verteilung des Kundenmodells in die Empfangssysteme

  5. Generieren der Partnervereinbarung in den Empfangssystemen