RFC-Trigger

Über den RFC-Trigger lösen angebundene SAP®-Systeme Datentransfers im OPC Router aus. SAP®-seitig muss dazu in der Transaktion SM59 ein entsprechender Eintrag angelegt werden.

Dialogübersicht

Der Screenshot zeigt die Auswahl der SAP®-Anbindung sowie die Konfiguration von Programm-ID, Gateway-Service, Funktion und Parametern.

Konfiguration

Eigenschaft	Beschreibung
SAP-Anbindung	Hier stehen alle im Bereich Plug-ins erstellten SAP®-Anbindungen zur Auswahl. Sollte die gewünschte Anbindung noch nicht vorhanden sein, können Sie diese im Plug-ins-Bereich als SAP®-Anbindung bereitstellen.
Programm-ID	Programm-ID, mit der am SAP®-System die Destination aufgerufen wird, identisch mit der Programm-ID in der Transaktion SM59.
Gateway-Service	RFC-Protokoll: Eingabe des Gateways, zum Beispiel sapgw00 (SAP Gateway 0). NetWeaver RFC-Protokoll: Angabe des Ports (3300 + Id für Basic-Authentifizierung, 4800 + Id für SNC-Authentifizierung).
Funktion	Im SAP®-System definierte Funktion, die diesen Trigger auslöst.
Timeout	Zeitspanne, nach der der OPC Router bei andauernder Aufgabe eine Timeout-Meldung an das SAP®-System sendet.
Ausgabe	Setzen Sie dieses Feld, wenn Sie eine Ausgabe als JSON erhalten möchten.
Eingabe (Reiter „Input“)	Parameter, die das aufrufende SAP®-System beim Auslösen an den OPC Router übergibt (Import-Parameter des Funktionsbausteins).
Ausgabe (Reiter „Output“)	Parameter, die der OPC Router nach Ausführung des Flows an das aufrufende SAP®-System zurückgibt (Export-Parameter des Funktionsbausteins).
Tabellen (Reiter „Tables“)	Tabellenparameter, die in beide Richtungen verwendet werden – sie können Daten in den Aufruf übergeben und (geänderte) Daten an SAP® zurückliefern.
JSON-Format kopieren	Kopiert ein JSON-Dokument in die Zwischenablage, dessen Struktur dem Funktionsaufruf entspricht.

Eingabe, Ausgabe und Tabellen

Ein RFC-Funktionsbaustein besitzt eine feste Schnittstelle aus Parametern. Beim RFC-Trigger übernimmt der OPC Router die Rolle des aufgerufenen Bausteins – Sie definieren dessen Schnittstelle daher über drei Reiter:

• Input: Werte, die das SAP®-System beim Aufruf an den OPC Router übergibt. Sie stehen anschließend im Flow zur Verfügung.
• Output: Werte, die der OPC Router nach Ablauf des Flows an das SAP®-System zurückgibt. Diese werden im Flow gefüllt.
• Tables: Tabellen (mehrzeilige Datenstrukturen), die in beide Richtungen verwendet werden können.

Legen Sie in jedem Reiter die benötigten Parameter an, indem Sie einen Namen vergeben und den Datentyp wählen. Neben einfachen Typen sind auch STRUCTURE (eine Struktur mit mehreren Feldern) und ITAB (eine interne Tabelle) möglich. Über „Bearbeiten“ definieren Sie bei diesen Typen die einzelnen Felder; eine Verschachtelung ist nicht möglich.

Bei CHAR- und NUM-Feldern legen Sie die erwartete Länge über „Bearbeiten“ fest. Die Standardlänge ist 0; wurde sie nicht geändert, erscheint beim Schließen des Dialogs ein entsprechender Hinweis.

Achtung

Der Aufruf eines nicht existierenden Funktionsbausteins führt zwangsläufig zur Deregistrierung des Servers im SAP®-Gateway. Die Registrierung kann nicht weiterverwendet werden und muss erneut durchgeführt werden, was sich in ERP-Connect durch einen Serverneustart äußert.

Achtung

Einmal gegenüber der NetWeaver-Library bekannt gemachte Funktionen können nicht wieder gelöscht werden. Das gilt für den gesamten Prozess, über alle SAP®-Systeme und RFC-Server hinweg. Sie können also Name und Typ der Import-/Export-/Tables-Parameter eines per RFC-Server aufgerufenen Funktionsbausteins ebenso wenig nachträglich ändern wie die Existenz des Bausteins selbst. Nehmen Sie keine Änderungen vor, während der OPC Router-Dienst läuft. Bei Änderungen muss immer vollständig veröffentlicht werden.

Rückgabeparameter

Wenn das SAP®-System den Funktionsbaustein aufruft, führt der OPC Router den zugehörigen Flow aus und gibt anschließend ein Ergebnis an das aufrufende SAP®-System zurück. Über den Rückgabeparameter TRANSFER_OK erkennt das SAP®-System, ob der Transfer erfolgreich war:

Name	Beschreibung
TRANSFER_OK	1 = OK: Erfolgreicher Transfer des Flows. 2 = Aborted: Der Transfer wurde von einem Transferobjekt abgebrochen, zum Beispiel wenn eine Tabelle für ein Datenbank-Transferobjekt keine Daten enthielt. 3 = Error: Während der Ausführung des Transfers trat ein Fehler auf. Die Anfrage muss später erneut gesendet werden und darf vom angebundenen System nicht als abgeschlossen markiert werden.

warnung

Registrieren Sie den Funktionsnamen in GROSSBUCHSTABEN (zum Beispiel Z_TRIGGER): SAP® übergibt Funktionsbausteinnamen großgeschrieben, und der OPC Router gleicht sie zeichengenau ab – eine kleingeschriebene Registrierung wird nicht gefunden. Die Programm-ID wird ebenfalls zeichengenau (unter Beachtung der Groß-/Kleinschreibung) ausgewertet und muss exakt mit dem Eintrag in der SAP®-Transaktion SM59 übereinstimmen; Großschreibung ist üblich und empfohlen, aber nicht zwingend. Der SAP®-seitige Aufruf lautet:

Call function '<FUNCTION_NAME>' destination '<SAP-DESTINATION>'.

Die Kombination von Host (SAP-Anbindung), Gateway und Programm-ID muss eindeutig sein. Die Programm-ID selbst kann mehrfach verwendet werden – aber nur mit verschiedenen Gateways/Hosts.

Zusammenspiel mit SAP

Wie diese Darstellung zu lesen ist, erklärt der Abschnitt Sequenzdiagramme.

Der RFC-Trigger ist die Empfangsseite eines am SAP-Gateway registrierten Serverprogramms: Das SAP-System löst den Transfer mit CALL FUNCTION '<Funktion>' DESTINATION '<Destination>' aus. Ob der aufrufende SAP-Prozess dabei auf das Ende des Transfers wartet, entscheidet allein das Kontrollkästchen „Asynchroner Aufruf“ am Trigger, das nur im Expertenmodus sichtbar ist. Beachten Sie die inverse Bedeutung: Nicht angehakt - das ist die Voreinstellung - heißt, dass SAP wartet; angehakt heißt, dass SAP sofort weiterläuft. Die folgenden Diagramme zeigen beide Fälle, und der Unterschied liegt an der Stelle, an der der RFC-Aufruf zu SAP zurückkehrt.

Asynchroner Aufruf: aus (Voreinstellung) - der SAP-Aufruf wartet auf den Transfer

Der Regelfall: SAP ruft die Funktion auf, der aufrufende Prozess bleibt stehen, und der Transfer läuft im Router. Die Export- und Tabellenparameter schreibt das Transferobjekt „an SAP“ schon mitten im Flow in dasselbe Funktionsobjekt, das SAP später zurückerhält; der Rückgabeparameter TRANSFER_OK wird dagegen erst nach dem Transferende gesetzt, unmittelbar bevor der Aufruf zurückkehrt. Läuft das Feld „Timeout“ vorher ab, öffnet sich eine Zeitschere: Der SAP-Aufruf endet, der Flow im Router läuft weiter und schreibt ins Leere - er schreibt weiterhin in dasselbe Funktionsobjekt, dessen RFC-Aufruf inzwischen beendet ist und dessen Inhalt SAP deshalb nie mehr zu sehen bekommt. Das Ticket bleibt dabei in der Warteschlange, ein verspäteter Start des Flows ist also ebenfalls möglich. Was SAP in diesem Fall genau meldet, hängt vom Betriebsmodus des RFC-Servers ab (im voreingestellten Hosting-Prozess greift eine feste 60-Sekunden-Grenze der internen Übergabe; liegt „Timeout“ darunter, sieht SAP eine normale Rückkehr mit unbelegten Exportparametern) - das Diagramm behauptet dafür bewusst keinen eigenen Pfeil.

Asynchroner Aufruf: ein (nur Expertenmodus) - der SAP-Aufruf kehrt sofort zurück

Ist „Asynchroner Aufruf“ angehakt, legt der Trigger kein Wartesignal an: Der RFC-Aufruf kehrt zurück, sobald der Auftrag eingereiht ist, und SAP erhält die Exportparameter so, wie sie vorbelegt sind. Der Flow läuft erst danach, zu diesem Zeitpunkt ist der Aufruf längst beendet; sowohl das Transferobjekt „an SAP“ als auch der nach dem Transfer gesetzte Rückgabeparameter TRANSFER_OK schreiben dann in ein Objekt, das SAP nicht mehr zu sehen bekommt. Ein Transferobjekt „an SAP“ und die Auswertung von TRANSFER_OK sind in dieser Betriebsart daher gegenstandslos.

Die Stellung von „Asynchroner Aufruf“ entscheidet, wann der RFC-Aufruf zu SAP zurückkehrt: nicht angehakt erst nach dem Transfer und mit Exportparametern, Tabellen und TRANSFER_OK, angehakt sofort und nur mit der Vorbelegung der Exportparameter.

Beispiel

Einstellungen am RFC-Trigger:

Eigenschaft	Konfiguration
SAP-Anbindung	<SAP-Anbindung>, über die die relevante Funktion erreicht wird.
Programm-ID	INRAYTRIGGER
Gateway-Service	Gateway-Service des SAP®-Systems, zum Beispiel 3302
Funktion	TRIGGERFUNKTION

Korrespondierende SAP®-Einstellungen, SM59:

Die Programm-ID INRAYTRIGGER wurde in der SAP®-Transaktion SM59 angelegt.

Eigenschaft	Konfiguration
Destination	OPCROUTER
Verbindungstyp	T TCP/IP
Aktivierungsart	Registriertes Serverprogramm
Programm-ID	INRAYTRIGGER
Gateway-Host	(kein Eintrag!)
Gateway-Service	(kein Eintrag!)

Durch den synchronen Funktionsaufruf innerhalb eines Programms, Funktionsbausteins oder Dialogs in SAP® wird der Datentransfer aktiv vom SAP®-System ausgelöst:

Call function 'TRIGGERFUNKTION' destination 'OPCROUTER'.