Allgemeines
Die HTTP-Schnittstelle stellt folgende Dienste bereit:
| Dienst | Beschreibung |
|---|---|
| connect | Führt den Anmeldevorgang durch. |
| call | Ruft ein beliebiges oxaion-Programm auf. |
| report | Ruft einen oxaion-Report ab. |
| disconnect | Meldet die aktuelle Sitzung ab. |
| setDisposable | Setzt die Property HTTP-CONNECTOR-DISPOSABLE=true |
Anmeldevorgang (connect)
| Beispiel-Aufruf: | http://hostname/app-tunnel/connect?user=INETUSER&pwd=xxx&host=oxaion |
| Parameter | Parameter / Beschreibung -- hostname / Name des Servers (wird beim Kunden einmalig festgelegt) -- connect / Befehl zur Anmeldung -- user / Benutzername (bei oxaion open: Benutzername des System-Profils) -- pwd oder md5pwd / oxaion open: Passwort der Benutzerverwaltung; alternativ kann das Passwort als MD5-Hash übergeben werden -- host / Name der oxaion-Umgebung (wird beim Kunden einmalig festgelegt) |
| Parameter optional | Parameter / Beschreibung -- profile / oxaion-Profil, falls kein Standard-Profil existiert -- firm / Firma (=Mandant), falls im Profil keine Standard-Firma hinterlegt ist -- sessionTimeout / Dauer der Session (Dauer kann durch die Angabe lediglich verkürzt werden) -- disposable / Wird dieser Parameter auf "true" gesetzt, dann kann die ID genau einmal verwendet werden. D.h. mit dem nächsten Programmaufruf (call) erfolgt gleichzeitig eine Abmeldung. |
| Rückgabe | <ID>13032933474483</ID> -- Unter dieser ID wird die aktuelle Benutzer-Anmeldung geführt. Diese ID muss bei allen zukünftigen Server-Calls mitgegeben werden. |
Beispiele je Umgebung
| Umgebung | Beispiel-Aufruf |
|---|---|
| PRODUCTION | http://<PRODUCTION-Server>/app-tunnel/connect?user=USERNAME&pwd=PASSWORT&host=PRODUCTION |
| STAGING | http://<STAGING-Server>/app-tunnel/connect?user=USERNAME&pwd=PASSWORT&host=STAGING |
| DEVELOP | http://<DEVELOP-Server>/app-tunnel/connect?user=USERNAME&pwd=PASSWORT&host=DEVELOP |
Aufruf eines oxaion-Programmes (call)
| Beispiel-Aufruf | http://hostname/app-tunnel/call?user=13032933474483&pgmn=US10100J&akto=*READ&LALANR=003 |
| Parameter | Parameter / Beschreibung -- hostname / Name des Servers (wird beim Kunden einmalig festgelegt) -- call / Befehl zum Programmaufruf -- user / Benutzer-ID aus dem Anmeldevorgang -- pgmn / Programmname des oxaion-Programmes -- akto / Funktion des oxaion-Programmes -- Zusätzlich können dem call-Befehl beliebig viele Input-Parameter übergeben werden. Diese Parameter sind abhängig von dem jeweiligen oxaion-Programm. Für das US10100J/*READ wird z. B. der Parameter &LALANR=003 benötigt |
| Rückgabe | Der Befehl gibt den XML-Datenstrom des oxaion-Programmes zurück. Die XML-Struktur sowie die Inhalte sind abhängig vom jeweiligen oxaion-Programm. Bspw. liefert das US10100J/*READ folgende Rückgabe: <?xml version="1.0" encoding="UTF-8" ?> <PARM> <DTA> <LALCDA>HOL</LALCDA> <LAASBZ>7</LAASBZ> <TX_XSPR>Niederländisch</TX_XSPR> <LAASBK>10</LAASBK> <LAIBRL>E</LAIBRL> <LAKPLZ>N</LAKPLZ> <LAPLNM>N</LAPLNM> <LAYLAE>2010-11-07</LAYLAE> <LADCTZ>.</LADCTZ> <LALNAM>Niederlande</LALNAM> </DTA> <ATR /> </PARM> |
Anmeldung und Aufrufe mit BasicAuth
Für oxaion open ab Version 2021.5306.1 ist es alternativ möglich, die Anmeldung mit BasicAuth durchzuführen.
Dabei erfolgt das Login nicht separat durch /connect, sondern integriert mit /call.
Die Anmeldeinformationen werden dafür im Request-Header übergeben.
In der Antwort der HTTP-Schnittstelle wird ein Cookie mitgeliefert, worüber nach der Anmeldung weitere Aufrufe möglich sind.
Die Abmeldung erfolgt analog wie beschrieben für /disconnect.
| Beispiel-Aufruf: | http://hostname/app-tunnel/call?pgmn=US10100J&akto=*READ&LALANR=003 |
| Parameter | Parameter / Beschreibung -- hostname / Name des Servers (wird beim Kunden einmalig festgelegt) -- call / Befehl zum Programmaufruf -- host / Name der oxaion-Umgebung (wird beim Kunden einmalig festgelegt) |
| Parameter im Header | Header / Beschreibung -- Authorization / Basic Authentication mit Nutzer und Kennwort -- oxaion-host / Name der oxaion-Umgebung |
| Parameter optional im Header | Parameter / Beschreibung -- oxaion-login / Anmeldeverfahren: LDAP oder DIGEST_MD5 -- oxaion-profile / oxaion-Profil, falls kein Standard-Profil existiert -- oxaion-firm / Firma (=Mandant), falls im Profil keine Standard-Firma hinterlegt ist -- oxaion-autologout / Wird dieser Parameter auf "true" gesetzt, dann erfolgt direkt nach dem Ausführen des Programmes die Abmeldung. |
| Rückgabe | Der Befehl gibt den XML-Datenstrom des oxaion-Programmes zurück. |
Abruf eines oxaion Reports (report)
Diese Funktion ist derzeit nur in oxaion open verfügbar. Für oxaion business solution wenden Sie sich bitte an Ihren oxaion Berater.
| Beispiel-Aufruf | http://hostname/app-tunnel/report?user=13032933474483&id=25 |
| Parameter | Parameter / Beschreibung -- hostname / Name des Servers (wird beim Kunden einmalig festgelegt) -- report / Befehl zum Abruf eines oxaion Reports -- id / ID des abzurufenden Reports (einsehbar über das Programm "IS60200R") |
| Rückgabe | Der Abruf eines Reports stellt insofern eine Ausnahme dar, als dass in diesem Fall keine XML-Daten zurück geliefert werden, sondern der aktuell abgerufene und aufbereitete Report in Form eines HTML-Dokumentes. Dieses HTML-Dokument kann direkt in einem Browser angezeigt werden. |
Abmelden (disconnect)
| Beispiel-Aufruf | http://hostname/app-tunnel/disconnect?user=13032933474483 |
| Parameter | Parameter / Beschreibung -- hostname / Name des Servers (wird beim Kunden einmalig festgelegt) -- disconnect / Befehl zur Abmeldung -- user / Benutzer-ID aus dem Anmeldevorgang |
| Rückgabe | <OK/> |
Beispiele je Umgebung
| Umgebung | Beispiel-Aufruf |
|---|---|
| PRODUCTION | http://<PRODUCTION-Server>/app-tunnel/disconnect?user=<SESSION-ID> |
| STAGING | http://<STAGING-Server>/app-tunnel/disconnect?user=<SESSION-ID> |
| DEVELOP | http://<DEVELOP-Server>/app-tunnel/disconnect?user=<SESSION-ID> |
Automatisches Abmelden beim nächsten Programmaufruf (setDisposable)
Durch Aufruf dieses Dienstes wird beim nächsten Aufruf eines oxaion-Programmes (call) der User automatisch abgemeldet.
| Beispiel-Aufruf | http://hostname/app-tunnel/setDisposable?user=13032933474483 |
| Parameter | Parameter / Beschreibung -- hostname / Name des Servers (wird beim Kunden einmalig festgelegt) -- setDisposable / Befehl zur Abmeldung -- user / Benutzer-ID aus dem Anmeldevorgang |
| Rückgabe | <OK/> |
System-Fehler
Fachliche Fehler eines oxaion-Programmes (bspw. Preis nicht gefunden) werden wie im Abschnitt Fehler beschrieben zurück geliefert.
Technische Fehler werden wie folgt zurück geliefert:
<ERROR ID="TUN0001"> <![CDATA[ CODE: TUN0001 INFO: 20.04.2016 12:23:47 SHORT: Authentifizierung fehlerhaft LONG: Authentifizierung fehlerhaft ... ]]/> </ERROR>
Auswahl des Rückgabeformats
Das Rückgabeformat ist normalerweise XML. Es besteht allerdings auch die Möglichkeit das Rückgabeformat zu beeinflussen.
JSON
Um die Daten als JSON anstatt XML zu erhalten, muss an den http-Request der Parameter
responseFormat=json
angehängt werden. Dieser Parameter muss an jeden Request angehängt werden, ansonsten wechselt das Rückgabeformat wieder auf XML.
Wenn das Rückgabeformat JSON ist, kann durch den zusätzlichen Parameter
prettyPrint=true
die JSON-Rückgabe mit Zeilenumbrüchen und Einrückungen versehen werden, damit sie besser gelesen werden kann. Dies ist vor allem zum Entwicklungszeitpunkt sinnvoll. Danach sollte man diese Funktion nicht nutzen, da sie nur zusätzliches Datenaufkommen produziert.
Javascript-Callback (JSONP)
Wenn die http-Schnittstelle direkt per Javascript aus einer Webseite aufgerufen werden soll, welche nicht unter dem gleichen Hostnamen läuft, blockiert der Webbrowser normalerweise sämtliche Ajax-Requests auf andere Hosts und dadurch auch auf die oxaion http-Schnittstelle. Um diese Problematik zu umgehen, kann eine Callback-Methode verwendet werden. Dazu sendet der Aufrufer der http-Schnittstelle den Namen einer Callback-Methode mit. Die http-Schnittstelle liefert dann eine Javascript-Datei zurück, welche nichts anderes macht, als die Methode mit diesem Namen aufzurufen und dort die Daten als Parameter zu übergeben.
Für die Angabe des Namens der Callback-Methode wird der Parameter
callback
verwendet.
Dieses Rückgabeformat funktioniert sowohl mit JSON, also auch mit XML-Daten. JSON-Daten werden als JSON-Objekt übergeben. XML-Daten werden als String übergeben.
Aufruf per HTTP-POST
Bei Aufrufen einiger Programme kann es vorkommen, dass aufgrund der Anzahl oder Länge der Parameter die maximal erlaubte Länge von URLs überschritten wird, wenn der Aufruf wie oben beschrieben per HTTP-GET durchgeführt wird. In diesem Fall wird die Anfrage mit dem Fehler "414 uri too long" abgelehnt. Dies kann vermieden werden, wenn die Anfrage stattdessen per HTTP-POST durchgeführt wird. Dies bedeutet, dass eine GET-Anfrage in der Form
http://hostname/app-tunnel/call?user=13032933474483&pgmn=US10100J&akto=*READ&LALANR=003
in eine POST-Anfrage an die URL
http://hostname/app-tunnel/call
mit folgenden Daten im Body ausgetauscht wird.
user=13032933474483&pgmn=US10100J&akto=*READ&LALANR=003
Hierbei muss dann im HTTP-Header der Parameter "Content-Type" mit dem Wert "application/x-www-form-urlencoded" mitgegeben werden.
Zentrale Schlüsselwerte
Bei Prozessen, die sich über mehrere call-Aufrufe der HTTP-Schnittstelle ziehen, werden beim ersten Aufruf auf Seiten des Servers ggf. Daten im Hauptspeicher gehalten, die erst mit den nachfolgenden Aufrufen verarbeitet werden. Damit der Server diese Daten dem aktuellen Prozess zuordnen kann, gibt es mehrere IDs und Schlüsselwerte, die je nach Prozess relevant sein können.
Session-ID
Dies ist die von der login-Methode zurückgegebene ID. Sie wird in allen weiteren Aufrufen als Parameter "user" mitgegeben. Alle Daten, die im Hauptspeicher vorgehalten werden, werden mit dem Abmelden der Sitzung (sowohl direkt als auch über den Auto-Disconnect) entfernt. Es sollte generell sichergestellt werden, dass keine zwei Zugriffe mit der gleichen Session-ID über die HTTP-Schnittstelle erfolgen, da nicht alle Prozesse auf den Parallelbetrieb mit der selben Anmeldung ausgelegt sind.
Aktivierungsgruppe
Über den oxaion-Client können mehrere Programme parallel geöffnet werden, die dann in getrennten Laschen angezeigt werden. Diese Laschen haben jeweils eine sogenannte Aktivierungsgruppe, die bei Zugriffen als Schlüssel für die Daten im Hauptspeicher genommen wird. Diese ID kann über die HTTP-Schnittstelle als Parameter actg mitgegeben, als Standard wird der Wert "DEFAULT_ACTG" genommen. Solange die Aktivierungsgruppe innerhalb einer Prozessausführung konsistent ist, können hier beliebige IDs vom Aufrufer mitgegeben werden.
SSID
Damit es möglich ist, eine Auflistung mit einem bestimmten Filter in einer neuen Lasche zu öffnen, sind die Daten der Listprogramme innerhalb einer Session nicht über die Aktivierungsgruppe gespeichert. Stattdessen gibt es eine sogenannte SSID, hinter der z.B. der aktuelle Filter oder der aktuell gelesene SQL gespeichert werden. Alle Transaktionen, die auf einem Listprogramm agieren, müssen somit eine SSID übergeben bekommen. Die SSID muss dabei von einem vorherigem Aufruf vom Server generiert und zurückgegeben werden.
Keytype
Bei Transaktionen, die aus einem Explorer heraus aufgerufen werden, wird im Feld KEYTYPE immer der Name des Knotens mitgegeben, auf dem die Transaktion aufgerufen wird. Z.B. ist das VAKOPF für den VKS-Auftragskopf und VAMPOS für die Auftragspositionen. Stößt man diese Prozesse über die HTTP-Schnittstelle an, müssen auch hier immer der jeweilige KEYTYPE mitgegeben werden. Der Keytype eines Explorerknoten lässt sich ermitteln, indem man mit gedrückter Alt-Taste einen Rechtsklick auf den jeweiligen Knoten macht und die Option "Feldinformationen anzeigen" auswählt.