Allgemeines

Die HTTP-Schnittstelle stellt folgende Dienste bereit:

DienstBeschreibung
connectFührt den Anmeldevorgang durch.
callRuft ein beliebiges oxaion-Programm auf.
reportRuft einen oxaion-Report ab.
disconnectMeldet die aktuelle Sitzung ab.
setDisposableSetzt die Property HTTP-CONNECTOR-DISPOSABLE=true

Anmeldevorgang (connect)

Beispiel-Aufruf:http://hostname/app-tunnel/connect?user=INETUSER&pwd=xxx&host=oxaion
ParameterParameter / 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 optionalParameter / 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

UmgebungBeispiel-Aufruf
PRODUCTIONhttp://<PRODUCTION-Server>/app-tunnel/connect?user=USERNAME&pwd=PASSWORT&host=PRODUCTION
STAGINGhttp://<STAGING-Server>/app-tunnel/connect?user=USERNAME&pwd=PASSWORT&host=STAGING
DEVELOPhttp://<DEVELOP-Server>/app-tunnel/connect?user=USERNAME&pwd=PASSWORT&host=DEVELOP

Aufruf eines oxaion-Programmes (call)

Beispiel-Aufrufhttp://hostname/app-tunnel/call?user=13032933474483&pgmn=US10100J&akto=*READ&LALANR=003
ParameterParameter / 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ückgabeDer 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
ParameterParameter / 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 HeaderHeader / Beschreibung -- Authorization / Basic Authentication mit Nutzer und Kennwort -- oxaion-host / Name der oxaion-Umgebung
Parameter optional im HeaderParameter / 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ückgabeDer 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-Aufrufhttp://hostname/app-tunnel/report?user=13032933474483&id=25
ParameterParameter / 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ückgabeDer 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-Aufrufhttp://hostname/app-tunnel/disconnect?user=13032933474483
ParameterParameter / 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

UmgebungBeispiel-Aufruf
PRODUCTIONhttp://<PRODUCTION-Server>/app-tunnel/disconnect?user=<SESSION-ID>
STAGINGhttp://<STAGING-Server>/app-tunnel/disconnect?user=<SESSION-ID>
DEVELOPhttp://<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-Aufrufhttp://hostname/app-tunnel/setDisposable?user=13032933474483
ParameterParameter / 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.

  • Keine Stichwörter
>