Antwortweg SAP
Einführung: Eine Beschreibung dieser Phase finden Sie im Abschnitt Phase 6 (Einführung). Siehe auch Abschnitt SAP.
Hinweis: Auf dem Integration Server muss der SAP-Service lizenziert und aktiviert werden, um diesen Antwortweg benutzen zu können. Bitte kontaktieren Sie hierzu unsere Mitarbeiter vom Support.
Wenn der SAP-Service des Integration Servers aktiv ist, können die Daten an angebundene SAP-Systeme gesendet werden. Dazu kann Lobster_data einen Funktionsbaustein (RFC) des SAP-Systems aufrufen. Siehe auch Abschnitt SAP RFC.
Hinweis: Zur passenden Zielstruktur siehe Abschnitt Laden einer RFC-Struktur aus SAP-Repository.
Hinweis: Siehe auch Abschnitt Dateinamen, Dateimuster, Pfade, System-Konstanten und Variablen.
(1) Der SAP-Alias des angebundenen Systems (siehe Konfigurationsdatei ./etc/sap.xml).
(2) Der Name des Funktionsbausteins, der auf dem SAP-System aufgerufen werden soll.
(3) Ist diese Option gewählt, werden alle Datenblätter in einem Aufruf an den Funktionsbaustein übergeben (ansonsten erfolgt für jedes Datenblatt ein RFC-Aufruf). Die Knoten in der Zielstruktur für Felder und Strukturen dürfen pro RFC-Aufruf nur einmal durchlaufen werden. Dagegen dürfen die Knoten für Tabellen mehrfach durchlaufen werden. Jeder Durchlauf entspricht dabei einer Zeile in der Tabelle.
(4) Um diese Option auswählbar zu machen, muss das Profil einen Eingangsagenten des Typs HTTP(S) haben und (3) muss gesetzt sein. Ist (4) gesetzt und (5) ist nicht gesetzt, dann wird die RFC-Antwort als HTTP-Response samt HTTP-Headern an den externen Client, der den HTTP-Request an das Profil gesendet hat, zurückgegeben. Ist (5) gesetzt, dann muss auch (6) auf Synchron gestellt werden, damit die Option (4) auswählbar wird. Wird (4) dann gesetzt, dann wird analog als HTTP-Response das erste konvertierte Ergebnis des Folgeprofils, das durch diesen Antwortweg angestoßen wurde, zurückgegeben. Siehe dazu auch den Abschnitt Profilketten. Hinweis: Die HTTP-Response ist immer in UTF-8 kodiert.
(5) Die Antwort des SAP-Systems kann per Message an ein weiteres Profil weitergeleitet werden. Darunter werden der Name des Folgeprofils und dessen Message-Kontext und Message-Queue angegeben. Das Folgeprofil muss also einen Eingangsagenten des Typs Message haben.
(6) Eine Message kann drei unterschiedliche Arten haben.
Synchron. Das Profil sendet die Message und macht erst dann weiter, wenn die Antwort erfolgt ist.
Asynchron. Das Profil sendet die Message und macht sofort weiter. Die Antwort ist unerheblich für die weitere Profilausführung.
Persistent. Arbeitet analog zu Asynchron. Als Erweiterung wird aber bei fehlender Gegenstelle die Message abgespeichert und das Programm versuch alle 50 ms die Message zu senden. Konnte in einer bestimmtem Zeit kein Erfolg erreicht werden, geht die Message verloren.
(7) Ist diese Checkbox gesetzt, wird die Antwort des per Message aufgerufenen Folgeprofils abgewartet und ausgewertet. D. h. der Antwortweg erhält nur den Status success, falls der RFC-Aufruf und das nachfolgende Profil erfolgreich waren. Ist die Checkbox nicht gesetzt, muss nur der RFC-Aufruf erfolgreich sein.
(8) Das Format, in dem die Daten an das Folgeprofil weitergereicht werden. Das Format muss dabei der Dokumentenart des Folgeprofils entsprechen. Vorhandene Formate sind CSV, Feste Länge, XML und SAPXML. Hinweis: Der Vorteil bei der Verwendung von Format SAPXML ist, dass wenn der RFC/BAPI in der Response "tiefe Datentypen" liefert, diese geparst und verarbeitet werden können. Das sind String/XSTRING, Tabellen in den EXPORT-Parametern, Tabellen in Tabellen, bzw. die CHANGING-Parameter. Nachteil: Die Quellstruktur des Folgeprofils kann nur durch Ausführen eines RFC-Aufrufs aus der erhaltenen RFC-Response erzeugt werden.