Show TOC Anfang des Inhaltsbereichs

ProzessdokumentationAblauf der Verteilung über BAPIs  Dokument im Navigationsbaum lokalisieren

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, dass synchron aufgerufene BAPIs nur zum Lesen von externen Daten benutzt werden sollten, um Datenbank-Inkonsistenzen durch Übertragungsfehler zu vermeiden.

Beispiel

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 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.

Die Verteilung von Daten über BAPIs ist nachfolgend grafisch dargestellt und erläutert.

Diese Grafik wird im zugehörigen Text erklärt

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, dass die Daten genau einmal übertragen werden.

3.      Eingangsverarbeitung

·         Segmentfilterung

·         Feldumsetzung

·         Übergabesteuerung

·         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).  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.

Aufruf des generierten Ausgangsfunktionsbausteins

Sind die Empfänger ermittelt, muss 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 muss das Anwendungsprogramm den Befehl COMMIT WORK enthalten. Der normale Datenbank-Commit am Transaktionsende reicht nicht aus. Der COMMIT WORK muss 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:

EDI_DOCUMENT_DEQUEUE_LATER  gibt einzelne IDocs frei, deren Nummern dem Funktionsbaustein als Parameterwerte übergeben werden.

DEQUEUE_ALL gibt alle Sperrobjekte frei.

Achtung

Der Funktionsbaustein Dequeue_all darf nur verwendet werden, wenn die Anwendung nicht im Workkflow-Umfeld verwendet werden kann, da dieser Funktionsbaustein notwendige Sperren von Workitems löscht.

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.

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 SAP-Einführungsleitfaden über folgenden Pfad:

Application Server
  IDoc-Schnittstelle / ALE
    Geschäftsprozesse modellieren und implementieren
          Verteilung von Stammdaten konfigurieren
                Umfang der zu verteilenden Daten festlegen
                      Nachrichten reduzieren

Feldumsetzung

 

Empfängerspezifische Feldumsetzungen können Sie im Einführungsleitfaden (IMG) definieren:

SAP Web Application Server
  IDoc-Schnittstelle / ALE
   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 Feldformats beim Datenaustausch zwischen R/2- und neueren SAP-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 SAP-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, muss 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:

Application Server
  IDoc-Schnittstelle / ALE
    Geschäftsprozesse modellieren und implementieren
          Partnervereinbarungen
                Partnervereinbarung generieren

 

Hinweis

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.

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, dass 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:

Application Server
  IDoc-Schnittstelle / ALE
      Geschäftsprozesse modellieren und implementieren
            Verteilung von Stammdaten konfigurieren
                  Serialisierung der Daten beim Senden und Empfangen einstellen
                        Serialisierung über Business-Objekte

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.

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.

 

 

Ende des Inhaltsbereichs