Übersicht
Der Service RestService dient als eingehender Service für REST Aufrufe.
Extension EAI_RS_CONFIG
Die Konfiguration des REST-Endpoints in der B2B erfolgt vollständig in der Extension EAI_RS_CONFIG.
In der Extension können mehrere Endpoints konfiguriert werden. Die Konfiguration erfolgt deshalb immer mit einem Prefix für den Endpoint in der Form {EndpointName}.{PropertyName}={PropertyValue}.
Aktive Endpoints müssen am Anfang der Extension unter dem Key ENDPOINTS angegeben werden. Mehrere Endpoints müssen mit Semikolon getrennt werden.
Folgende Konfigurations-Möglichkeiten stehen zur Verfügung:
| PropertyName | Beschreibung | Werte |
|---|---|---|
| PATH | Der Pfad für den eingehenden REST-Service. Alle Pfade beziehen sich immer auf die Basis-URL {Server}/b2bbp-engine/rs. Die Pfad-Angabe muss immer entweder mit plain/ oder binary/ beginnen. Darüber wird gesteuert, ob die eingehende Nachricht als Plain-Text oder Binär-Daten verarbeitet wird. Die Pfad-Angabe kann durch eina Asterisk als Wildcard abgeschlossen werden oder um Platzhalter für Pfad-Variablen ergänzt werden. Pfad-Variablen werden durch geschweifte Klammern {variablenName} gekennzeichnet und automatisch unter dem VariablenNamen im MessageContext abgelegt. | Beispiel: /plain/example_endpoint - Der Endpoint ist dann über {Server}/b2bbp-engine/rs/plain/example_endpoint ansprechbar. |
| baseServiceId | Service-ID, die dem REST-Service zugeordnet ist. Siehe Service. | |
| skipFr | Boolean-Wert, ob die FormatRecognition ausgeführt wird. Die Angabe ist optional, ohne Angabe wird die FormatRecognition nicht ausgeführt. | true/false(default) |
| skipCD | Boolean-Wert, ob die ChannelDistribution ausgeführt wird. Die Angabe ist optional, ohne Angabe wird die ChannelDistribution ausgeführt | true(default)/false |
| createFormatObject | Bei der Verarbeitung eines REST-Aufrufs wird in der Regel kein Format-Objekt benötigt, deswegen wird standardmäßig kein Format-Objekt angelegt. Wird bei der weiteren Verarbeitung von anderen Actions oder Services die Existenz eines Format-Objekts vorausgesetzt, so kann ein leeres Format-Objekt mit Hilfe dieser Property erzeugt werden. | true/false(default) |
| senderName | Mit dieser optionalen Property kann der System-Text im Monitoring konfiguriert werden. Ist kein Wert hinterlegt, so wird “Incoming Request from: {RemoteHost} to: {Endpoint-Pfad}” verwendet. | |
| partnerName | Mit dieser optionalen Property kann der Partner-Text im Monitoring angepasst werden.Als Partner-Text wird immer “Redirecting to: {partnerName}” verwendet. | |
| validateRequestForPutMethod | Boolean-Wert, ob eine JSON-Validierung für eingehende PUT-Requests durchgeführt wird. Die Angabe ist optional, ohne Angabe wird keine Validierung ausgeführt. | true/false(default) |
| validateRequestForPostMethod | Boolean-Wert, ob eine JSON-Validierung für eingehende POST-Requests durchgeführt wird. Die Angabe ist optional, ohne Angabe wird keine Validierung ausgeführt. | true/false(default) |
| validateRequestForPatchMethod | Boolean-Wert, ob eine JSON-Validierung für eingehende PATCH-Requests durchgeführt wird. Die Angabe ist optional, ohne Angabe wird keine Validierung ausgeführt. | true/false(default) |
| validationRepsonseHttpStatus | Angabe eines Http-Status-Codes, der bei einem Validierungsfehler zurückgegeben wird. Standardmäßig wird der Status-Code 400 zurückgegeben. | 400 |
| METHODS | Http-Methoden, mit denen der Endpoint aufgerufen werden kann. Mehrere Werte müssen durch Semikolon getrennt werden. Die Angabe ist optional, standardmäßig kann der Endpoint mit allen http-Methoden aufgerufen werden. | GET;POST;PUT;DELETE; HEAD;OPTIONS;PATCH |
| FILTERS | Eine Liste der verwendeten Filter. Mehrere Filter müssen durch Semikolon getrennt werden. | LoginFilter |
| FILTERS.LoginFilter.{http-Method} | Der LoginFilter ermöglicht die Konfiguration einer Authentifzierung. Dabei kann die Authentifizierung auch nur für einzelne http-Methode konfiguriert werden. Z.B. {EndpointName}.FILTERS.LoginFilter.POST=BASIC aktiviert Basic-Authentifizierung für POST-Aufrufe. {EndpointName}.FILTERS.LoginFilter.DEFAULT=BASIC aktiviert die Baisc-Authentifizierung für alle http-Methoden. | BASIC |
| FILTERS.LoginFilter.INBOUND_AUTHENTICATION_USER.{http-Method} | Verwendeter UserName für die Authentifizierung. {EndpointName}.LoginFilter.INBOUND_AUTHENTICATION_USER.DEFAULT setzt den Usernamen für alle http-Methoden | |
| FILTERS.LoginFilter.INBOUND_AUTHENTICATION_PASSWORD.{http-Method} | Passwort für die Authentifizierung. Das Passwort ist mit dem Master-Passwort verschlüsselt. {EndpointName}.LoginFilter.INBOUND_AUTHENTICATION_PASSWORD.DEFAULT setzt den Usernamen für alle http-Methoden | |
| ADDITIONAL.{MessageContextProperty} | Die ADDITIONAL-Properties ermöglichen es, feste Werte in den MessageContext zu schreiben. Z.B. {EndpointName}.ADDITIONAL.B3P_EXAMPLE_PROPERTY=ExampleValue würde die Property B3P_EXAMPLE_PROPERTY im MessageContext anlegen und auf den Wert “ExampleValue” setzen. Es können mehrere Konfigurations-Einträge mit der ADDITIONAL-Property angegeben werden. |
Service
Zusätzlich zu der Konfiguration in der EAI_RS_CONFIG muss ein neuer Service angelegt werden.
Die ID des Services muss der in der EAI_RS_CONFIG angegebenen baseServiceId entsprechen. Der Name ist frei wählbar, der Typ ist RS. Ein Klassenname wird nicht angegeben.
Es muss ein Channel ausgewählt werden, in dem die Verarbeitung erfolgen soll.
Die Option Startup hat keinen Einfluss. Jeder REST-Service, der in der EAI_RS_CONFIG konfiguriert ist, steht in der B2B grundsätzlich zur Verfügung.
Rückgabe einer Response an den Aufrufer (im Erfolgsfall)
Über die Action GenerateRestResponse kann eine Response konfiguriert werden, die dem urspünglichen Aufrufer zurückgegeben wird.
Rückgabe einer Response an den Aufrufer (im Fehlerfall)
Wenn es im Falle einer Workflow-Verarbeitung im Channel zu einem Fehler kommt, sendet die EAI default-mäßig einen 500-HTTP Fehlercode zurück mit einem Standardtext und dem Media Type text/plain. Dieses Verhalten kann mit diesen MessageContext-Variablen übersteuert werden. Die Variablen müssen also (z.B. durch eine Action) erst in den MessageContext geschrieben werden.
| MessageContext-Variable | Beschreibung | Default |
|---|---|---|
| DEFAULT_ERROR_RESPONSE_TEXT | Der Inhalt (Body), der an den Aufrufer im Fehlerfall zurückgehen soll | “Error occured while processing the REST request” |
| ERROR_RESPONSE_CODE | Der HTTP-Code, der an den Aufrufer im Fehlerfall zurückgehen soll | 500 |
| ERROR_RESPONSE_TYPE | Der Media Type, der an den Aufrufer im Fehlerfall zurückgehen soll | text/plain |
JSON-Validierung
Für REST-Services kann der eingehende JSON-Content gegen ein JSON-Schema validiert werden.
Die JSON-Validierung kann für POST, PUT und PATCH-Aufrufe aktiviert werden. Dies erfolgt über die Property validateRequestFor{Put/Post/Patch}Method in der Extension EAI_RS_CONFIG.
Das JSON-Schema, gegen das die Validierung erfolgt, muss dafür in einer Extension hinterlegt werden. Die Extension muss dabei der Namenskonvention EAI_RS_JSON_VALIDATION_{http-Methode}_{EndpointName} folgen.
