AW: Dokumentation zur Erstellung eines JTL 1.0 Connectors
Alle Requests laufen auf die
Connector-URL als POST-Request. Requestformat ist JSON, wir setzen es in einer Abwandung von JSON-RPC ein. Das wird auch schnell klar, wenn du die URL zu einem Connector einmal direkt aufrufst, denn auch die Exceptions werden als JSON-RPC-Messages übertragen. Das Ganze sieht in etwa so aus:
Code:
{
"method": "...",
"params": { ... },
"jtlrpc": "2.0",
"id": "..."
}
Vor dem ersten Request muss eine Authentifizierung mittels Auth-Token (den der Benutzer als Passwort in
JTL-Wawi eingibt) erfolgen - ebenfalls per JSON-RPC. Diese liefert eine Session-ID zurück, die an die Client-IP-Adresse gebunden ist und die bei allen künftigen Requests als "id"-Parameter mitgeliefert werden muss. Läuft die Session ab - z.B. wegen eines Timeouts, wird eine SessionException geworfen, sodass der Client die Gelegenheit hat, erst eine neue Session anzufordern, bevor er den Request wiederholt.
Wir verwenden ein Protokoll, das RPC-Methoden der Form "<object>.<method>" kennt. Die häufigsten Methoden sind dabei "push"/"pull"/"delete" zur Übertragung bzw. zum Löschen von Daten, jeweils aus Sicht des Clients gesehen. Zusätzlich gibt es an den meisten Objekten eine Methode "statistic", die eine Information zurückliefert, wie viele Objekte zum Pull zur Verfügung stehen. Das gesamte Mapping zwischen den Primary-Keys des Servers und denen des Clients findet serverseitig statt - ebenso wie das Vorhalten der Infos, welche Objekte bereits gepulled worden sind und welche nicht.
Wenn du auf Basis des .NET-Frameworks arbeitest, könnte ich dir evtl. die C#-Schnittstellendefinitionen zukommen lassen, aus denen unsere PHP-Model-Klassen generiert werden. Wir verwenden die json.net-Bibliothek, um die Daten zwischen managed objects und JSON hin- und herzukonvertieren. Dann siehst du schon einmal, wie die Datenstrukturen aussehen, auf denen du arbeiten musst.
