Antwortweg SAP
Wenn der SAP-Service aktiv ist, können die Daten an angebundene SAP-Systeme gesendet werden. Dazu kann eine Funktionsbaustein (RFC) des SAP-Systems aufgerufen werden. Siehe auch Abschnitt SAP RFC. Zur passenden Zielstruktur siehe Abschnitt Laden einer RFC-Struktur aus SAP-Repository.
Einstellungen
(1) SAP Alias: Der SAP-Alias des angebundenen Systems (siehe Konfigurationsdatei ./etc/sap.xml).
(2) RFC: Der Name des Funktionsbausteins, der auf dem SAP-System aufgerufen werden soll.
(3) Alle Datenblätter in einem Aufruf: 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) Daten zurückliefern: 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) SAP-Antwort per Message weiterleiten: Die Antwort des SAP-Systems kann per Message an ein weiteres Profil weitergeleitet werden. Darunter werden der Name des Folge-Profils und dessen Message-Kontext und Message-Queue angegeben. Das Folgeprofil muss also einen Eingangsagenten des Typs Message haben.
(6) Message-Typ: 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 alle 50 ms wird versucht, die Message zu senden. Konnte in einer bestimmtem Zeit kein Erfolg erreicht werden, geht die Message verloren.
(7) Bei synch. Message Antwort auswerten: 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) Im Format: 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.
(9) Gesamten Job als gescheitert melden, wenn dieser Antwortweg fehlgeschlagen ist: Normalerweise gilt ein Job nicht notwendigerweise als fehlerhaft, wenn ein einzelner Antwortweg fehlschlägt (siehe Abschnitt Verhalten im Fehlerfall). Das kann hier aber mit dieser Option erzwungen werden.
(10) Zusätzlicher Text bei Fehler: Hier kann ein zusätzlicher Log-Text für den Fehlerfall angegeben werden.