Bestandteile eines Lobster-RFCs

Ein Funktionsbaustein, der im Lobster Integration Server/Lobster_data bereitgestellt wird, besteht aus drei Komponenten:

• RequestListener mit Konfiguration in Datei ./etc/sap.xml,

• Schnittstellendefinition des RFCs als XML-Datei,

• Implementierung des RFCs als Lobster_data-Profil mit Message-Eingang.

Der Request, der von dem SAP-System gesendet wurde, wird durch den RequestListener entgegengenommen. Wenn der Request mit dem Namen des RFCs und der Schnittstellendefinition übereinstimmt, werden die Daten über die Message Queue an das Verarbeitungsprofil gesendet.

Listener-Konfiguration in ./etc/sap.xml

Der folgende XML-Abschnitt beschreibt die Konfiguration eines RequestListeners für den RFC MY_RFC. Das erste Argument (hier sap) muss mit dem definierten SAP-Alias übereinstimmen.

Die Klasse com.ebd.hub.datawizard.sap.DataWizardForwardRequestListener wird mit dem SapConnectionService ausgeliefert.

Der functionName definiert den Namen des RFCs, xmlFile ist der Pfad zur Schnittstellendefinition. Die Message Queue wird über die Parameter messageContext und messageQueue definiert. Das Verarbeitungsprofil dataProfile muss für den Empfang der Message Queue konfiguriert und aktiv sein. Der conversionType kann einen der Werte XML, CSV oder FR haben und muss mit der Dokumentenart des Profils übereinstimmen. Der messageServiceName ist nur erforderlich, wenn über einen anderen, als den Default-Message-Service gearbeitet werden soll. Normalerweise kann die Zeile entfernt werden.

Wenn die Response bedient werden soll (useResponse), muss auch der Aufruf synchron (synchronCall) erfolgen. Der Parameter clearTablesForResponse ist nur für die Fälle relevant, wenn große Datenmengen im Request als TABLES Parameter übergeben werden, die aber in der Response nicht wieder zurück gesendet werden sollen.

RFC-Schnittstellendefinition als XML-Datei

Die Schnittstellendefinition erfolgt in einer XML-Datei, deren Pfad in der Listener-Konfiguration über den Parameter xmlFile angegeben wird. Die Struktur der XML-Datei wird über die DTD-Datei sap_rfc_configure_1_0.dtd geprüft, die unter dem Verzeichnis ./etc/dtd/ vorhanden sein muss. Das Root-Element heißt RFC und im Attribut name wird der Name des RFCs erwartet. Er muss mit dem functionName in der Listener-Konfiguration übereinstimmen.

Im Abschnitt <!-- Weitere Einstellungen --> steht die Definition der

• Import-Parameter als einfache Felder oder "flache" Strukturen,

• Export-Parameter als einfache Felder oder "flache" Strukturen,

• Tabellen-Parameter,

• Exceptions.

Wir unterstellen hier, dass das Grundkonzept einer SAP-RFC-Schnittstelle (ABAP) bekannt ist. Alle Teile der Schnittstelle sind optional.

IMPORT-Parameter

EXPORT-Parameter

TABLE-Parameter

Jede TABLE-Definition enthält genau eine ROW. Man kann sich die ROW als eine namenlose Struktur vorstellen. Die Werte einer Tabelle bilden dann eine Liste solcher zusammengesetzter Struktur-Werte.

Wenn mehrere Tabellen mit absolut gleicher Struktur definiert werden, sollten Sie den gleichen refname verwenden. Der refname kann formal aus dem name durch Voranstellen von REF_ gebildet werden. Der tabletype kann die Werte in, out oder inout haben. Hinweis: Die Klasse DataWizardForwardRequestListener unterstützt nur in.

Exceptions

Feld-Definitionen

Bei Typen, bei denen decimals keine Bedeutung hat, wird der Wert ignoriert. Die Typen INT1 und INT2 sollten nicht verwendet werden, weil hier vom JCo eine falsche Länge gemeldet wird. Ersatzweise wird NUM mit length empfohlen.

Strukturdefinitionen

Strukturen in den Import- und Export-Parametern sind "flache" Strukturen. Das bedeutet, eine Struktur enthält nur Felder, aber keine weitere Strukturen.

Analog zu den Tabellen-Definitionen sollten mehrere Strukturen mit absolut gleichem Aufbau denselben refname verwenden.

Struktur des Beispiel-RFCs MY_RFC

Das folgende Beispiel definiert den Funktionsbaustein MY_RFC, der nur einen numerischen Wert als Import-Feld NUMERIC_ID erwartet.

Hinweis zu Datentypen bei STRUCTURE und TABLE

Der Begriff "flache Struktur" bezieht sich auf einen zusammengesetzten Datentyp, der aus einer Folge einfacher Felder zusammengesetzt ist. Jedes einzelne Feld muss dabei eine konkrete Feldlänge haben. Der Typ STRING mit variabler Länge ist dadurch nicht für Strukturen zulässig.

Ein TABLE-Parameter entspricht eigentlich einer Liste von Zeilen, wobei jede Zeile eine flache Struktur darstellt. Deshalb ist auch in der TABLE-Definition die Verwendung des Typs STRING unzulässig.

Auf der SAP-Seite empfehlen wir grundsätzlich die Verwendung von Repository-Typen. Die Übereinstimmung mit der Definition auf der Lobster-Seite muss vom Anwender bewusst hergestellt werden, indem ein passender Datentyp (vorzugsweise CHAR oder NUM) mit Angabe der Länge eingetragen wird, so wie sie im SAP-Repository definiert ist.

Beispiel: Wenn man z. B. für eine EAN im SAP den Repository-Typ CHAR13 verwendet, muss das Feld auf Lobster-Seite mit folgenden Attributen definiert werden.

Bei STRUCTURE- und TABLE-Definitionen sollte die Reihenfolge der Felder innerhalb der Definition auf SAP-Seite mit der Definition auf Lobster-Seite übereinstimmen.