Wenn aktiviert, zeichnet ABRA Flexi alle an der Firmendatenbank vorgenommenen Änderungen im Änderungsprotokoll auf und ermöglicht es Ihnen, die Liste der Änderungen abzurufen. Die Änderungen sind aufsteigend nummeriert, so dass das Unternehmen zu jedem Zeitpunkt über eine klar definierte globale Version verfügt. (Die Versionsnummern müssen nicht genau aufeinander folgen; aus technischen Gründen kann es Lücken in der Reihe geben. Die Versionsnummer ist jedoch immer eindeutig und aufsteigend). Diese kann für die automatisierte Synchronisation von Fremdsystemen mit ABRA Flexi genutzt werden und ist auch die Basis für die sofortige Änderungsbenachrichtigungsfunktion(Web Hooks).
ABRA Flexi-Lizenzen müssen mindestens über eine aktive REST-API zum Lesen verfügen. Das Überprüfen des Status und das Aktivieren/Deaktivieren lassen sich am einfachsten in der Weboberfläche unter /c/{firm}/changes/control durchführen. Alternativ kann sie durch eine PUT-Anforderung an /c/{firma}/changes/enable.xml aktiviert und durch eine PUT-Anforderung an /c/{firma}/changes/disable.xml deaktiviert werden. Zusätzlich zu PUT kann auch POST verwendet werden. Wenn Sie die REST-API nicht zum Lesen oder Schreiben aktiviert haben, lautet die Antwort 403 Forbidden.
Beispiel für die Aktivierung mit curl:
curl -k -L -u Name:Passwort -X PUT https://localhost:5434/c/{firma}/changes/enable.xml -H Content-Length:0Abrufen der aktuellen globalen Version
Sie können die aktuelle globale Version zu jedem über die REST-API erhaltenen XML- (oder JSON-) Export hinzufügen, indem Sie den Parameter ?add-global-version=true hinzufügen. Die Antwort sieht dann so aus:
<?xml version="1.0"?> <winstrom version="1.0" globalVersion="6"> ... </winstrom>
Änderungsprotokolle abrufen
Unter /c/company/changes.xml befindet sich eine Liste mit allen Änderungen seit Beginn der Verfolgung. Die Auflistung sieht wie folgt aus:
<?xml version="1.0"?>
<winstrom version="1.0" globalVersion="6">
<faktura-vydana in-version="3" operation="create" timestamp="2019-01-01 00:00:00.0">
<id>1</id>
</faktura-vydana>
<faktura-vydana-polozka in-version="4" operation="create" timestamp="2019-06-07 12:34:56.7">
<id>1</id>
</faktura-vydana-polozka>
<faktura-vydana in-version="5" operation="update" timestamp="2019-06-07 12:34:56.7">
<id>1</id>
<id>Code:VF1-0001/2012</id>
</faktura-vydana>
<next>6</next>
</winstrom>Die numerische ID des Objekts(1 ) und der Code (code:CODE ) werden immer angegeben; wenn das Objekt zum Zeitpunkt der Operation externe IDs hatte, werden diese ebenfalls angegeben (<id>ext:...</id> ).
Die Attribute der einzelnen Elemente geben an, in welcher Version der Vorgang stattgefunden hat(in-version) und was der Vorgang war(operation; mögliche Werte sind create, update und delete).
Das Attribut globalVersion ist immer vorhanden. Das letzte Element in der Auflistung ist immer next, das die Versionsnummer angibt, mit der diese Auflistung fortgesetzt würde, oder none, wenn es keine weiteren Änderungen gibt.
Die Auflistung kann mit den folgenden Parametern geändert werden:
| Ab welcher Version aufgelistet werden soll (einschließlich); Standard ist ab dem Beginn der Verfolgung. |
| Wie viele Datensätze aufgelistet werden sollen; standardmäßig 100, maximal 1000. |
| Für welche Datensätze Änderungen ausgegeben werden sollen; kann mehrfach angegeben werden, wenn nicht angegeben, werden alle ausgegeben. |
Im JSON-Format sehen die Änderungen wie folgt aus:
{
"winstrom": {
"@globalVersion": "8",
"changes": [
{
"@evidence": "invoice-issued",
"@in-version": "3",
"@operation": "create",
"@timestamp": "2019-01-01 00:00:00.0",
"id": "1",
"external-ids": []
},
{
"@evidence": "faktura-vydana-polozka",
"@in-version": "4",
"@operation": "create",
"@timestamp": "2019-06-07 12:34:56.7",
"id": "1",
"external-ids": []
},
{
"@evidence": "faktura-vydana",
"@in-version": "5",
"@operation": "update",
"@timestamp": "2019-06-07 12:34:56.7",
"id": "1",
"external-ids": [
"code:VF1-0001\/2012"
]
}
],
"next": "6"
}
}Abrufen des Status der Changes-API
Der Benutzer kann den Einschaltstatus unter /c/{firma}/changes/control überprüfen. Hier ist es auch möglich, die Änderungen-API ein- oder auszuschalten.
Wenn Sie den Status programmatisch herausfinden müssen, verwenden Sie GET /c/firm/changes/status.xml. Bei einer true-Antwort ist die Changes API aktiviert. Wenn die Antwort falsch oder ein Fehler ist (wenn die REST-API nicht aktiviert ist), wird die Änderungs-API deaktiviert.
Synchronisation von Fremdsystemen mit ABRA Flexi
Versionierte Änderungen können einfach verwendet werden, um externe Systeme effizient mit ABRA Flexi zu synchronisieren (im Gegensatz zum letzten Änderungsdatum). Die Vorgehensweise ist wie folgt:
Erstes Hochladen von Daten:
Holt die aktuellen Daten einschließlich ihrer Version (
?add-global-version=true)Daten speichern
Merken Sie sich die Version (aus dem Attribut
globalVersion)
Differentialsynchronisation:
Änderungen seit der letzten gespeicherten Version herunterladen (
?start=)Geänderte Daten herunterladen und speichern, oder gelöschte Daten löschen
Version merken (vom
nächstenElement oderglobalVersion-Attribut)GOTO 1
ERROR: konnte keine Sperre auf Relation "????" erhalten
Wenn Sie eine Fehlermeldung ERROR: could not obtain lock on relation "????" erhalten, verzweifeln Sie nicht. Aus Leistungsgründen werden die Funktionen, die die Changes-API bedienen, gar nicht in die Datenbank aufgenommen. Wenn die Änderungs-API aktiviert ist, fügen wir sie dem System hinzu. Daher müssen Sie die gesamte Datenbank exklusiv sperren.
Die Lösung ist daher, sich von ABRA Flexi abzumelden - sowohl von der Weboberfläche als auch von der Client-Anwendung. Dann wird es passieren.
Beispielfehler:
ERROR: konnte keine Sperre auf die Relation "drady" erhalten Wo: SQL-Anweisung "LOCK TABLE drady IN ACCESS EXCLUSIVE MODE NOWAIT"