Log Service
Dieses Modul bietet unter anderem einen REST-Endpunkt, um Monitor-Daten entgegenzunehmen und diese nach OpenSearch und optional in eine Datenbank zu schreiben. Die betreffenden Monitor-"Clients" werden sofort per Websocket-Event über neue Daten informiert.
|
Soll auch in eine Datenbank geschrieben werden, dann müssen die Datenbanktabellen bereits angelegt sein. Diese werden nicht automatisch angelegt und bei Änderungen der Datenstruktur auch nicht automatisch angepasst. |
|
Falls in eine Datenbank geschrieben wird, dann werden über eine DB-Transaktion zuerst die Datenbankdaten geschrieben (ist normalerweise fehleranfälliger) und erst danach die Daten nach OpenSearch. Beim Schreiben in die Datenbank wird zuerst ein DB-Update (siehe keys-Einstellung) durchgeführt und wenn dies fehlschlägt ein DB-Insert. |
|
Wie bereits oben erwähnt, werden die Daten des Log-Service üblicherweise über den Monitor dargestellt.
Dieser verwendet einen Process-Index (= parent Daten) sowie einen History-Index (= child Daten). |
Konfigurationsparameter Log Service Modul
Pflichtparameter sind fett hervorgehoben.
| Setting (Key) | Gruppe | Beschreibung |
|---|---|---|
Security_ClientCertificateAuthMandatory |
security |
Legt fest, ob die Log-Service-Endpunkte nur per Client Certificate Authentication aufgerufen werden können. |
OpenSearch_DataCountLimit |
opensearch |
Maximale Anzahl Dokumente die abgefragt werden können. |
OpenSearch_DataViewLimit |
opensearch |
Bis zu diesem Wert soll OpenSearch genaue Angaben über die Anzahl der Dokumente (trackTotalHitsUpTo) zurückliefern. |
Konfigurationsparameter je Log Service Komponente
Fett hervorgehobene Werte sind Pflichtparameter.
| Setting (Key) | Gruppe | Beschreibung | ||
|---|---|---|---|---|
Enabled |
config |
Wenn etwas an der Datenbank oder dem OpenSearch-Index angepasst werden muss, dann kann der Endpunkt für diese Instanz in einen Wartungsmodus gesetzt werden.
In diesem Fall bekommt der Aufrufer des Endpunktes einen HTTP Status 503 (Service Unavailable) zurückgeliefert. |
||
ParentKeyFields ChildKeyFields |
config |
Hier werden jeweils die Schlüsselfelder festgelegt. Beim Schreiben in die Datenbank werden diese für das DB-Update verwendet. Bei OpenSearch zur Festlegung der Dokumenten-IDs. Sind mehrere Felder betroffen, dann müssen diese durch Kommata voneinander getrennt werden. Default: PROCESSID bzw. PROCESSID, CHILDID |
||
ParentFields ChildFields |
config |
Hier können unter anderem Feinjustierungen an den Datentypen vorgenommen werden (Mapping für die OpenSearch-Indexe). Default
Beispiel
In der Voreinstellung werden alle Felder nach OpenSearch und in die Datenbank geschrieben. Sollen einzelne Felder nicht geschrieben werden, dann können diese hier festgelegt werden.
true = das Feld wird nicht nach OpenSearch geschrieben false = das Feld wird nach OpenSearch geschrieben (Voreinstellung)
true = das Feld wird nicht in die Datenbank geschrieben false = das Feld wird in die Datenbank geschrieben (Voreinstellung) |
||
JsonSchemaValidation |
config |
Festlegung, ob bei den zu schreibenden Daten eine JSON Schema Validierung durchgeführt werden soll.
Das JSON Schema wird dabei anhand der definierten
|
||
Enable File Storage Upload |
config |
Wenn diese Option aktiviert ist, können Felder vom Typ Default: |
||
File Storage Backend Connection |
config |
Die File-Storage-Backend-Connection, die beim Ablegen von Dateien im File-Storage genutzt wird. |
||
File Storage Bucket |
config |
Der Bucket-Name, um Dateien im File-Storage abzulegen. |
||
Read Restriction Write Restriction |
config |
Die Lese- bzw. Schreibbeschränkung, die beim Ablegen von Dateien im File-Storage genutzt wird. Es muss entweder ein Benutzer, oder mindestens eine Rolle, Organisation oder ein Recht festgelegt werden. Beispiel mit einem Nutzer
Beispiel mit Rollen, Organisationen und Rechten
|
||
OpenSearch_LoggingEnabled |
opensearch |
Nur wenn aktiviert, werden die Daten nach OpenSearch geschrieben. |
||
OpenSearch_ParentIndex |
opensearch |
Festlegung, in welchen Index die Parent/Haupt/Eltern-Daten geschrieben werden sollen. Der Index wird automatisch angelegt. Dabei werden die festgelegten ‘Fields’-Typen berücksichtigt.
|
||
OpenSearch_ChildIndex |
opensearch |
Festlegung, in welchen Index die Child/Detail/Kind-Daten geschrieben werden sollen. Der Index wird automatisch angelegt. Dabei werden die festgelegten ‘Fields’-Typen berücksichtigt.
|
||
Joins |
config |
Können verwendet werden, um die loggenden Dokumente automatisch mit zusätzlichen Daten anzureichern. Wenn z.B. in den zu loggenden Daten nur eine Partner-ID steht und noch der Name des Partners etc. im Monitor benötigt wird. Ist die gleiche Konfiguration wie bei den 'Lookup Joins' des Replikationsdienstes. Beispiel:
|
||
RDMS_LoggingEnabled |
rdms |
Nur wenn aktiviert, werden die Daten in die Datenbank geschrieben. |
||
RDMS_DataSourceName |
rdms |
Name der Data Source (Datenbankverbindung) welche unter 'Backend Connections' bereits angelegt wurde. |
||
RDMS_TimeZone |
rdms |
Optionale Ziel-Zeitzone für Datum-Felder (verwendet intern ZoneId). |
||
RDMS_ParentTable |
rdms |
Name der Zieltabelle mit den Parent/Haupt/Eltern-Daten.
|
||
RDMS_ChildTable |
rdms |
Name der Zieltabelle mit den Child/Detail/Kind-Daten.
|
Endpunkte
Zur Verwendung der Endpunkte ist ein angemeldeter Benutzer bzw. API Key mit den jeweiligen Rollen/Rechten notwendig.
Als zusätzlichen Schutz kann über die "Log Service"-Moduleinstellung Security_ClientCertificateAuthMandatory für alle Log Service Endpunkte die Client Certificate Authentication aktiviert werden.
| Method | Endpoint | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||
Description Get a compact overview of the available log service instances. Only the following data is returned for each instance:
|
||||||||||
Returns The log service instances as JSON. HTTP Status Code
Content-Type
|
||||||||||
Required Access Rights The logged in user or API Key must have either the following role or right.
|
||||||||||
|
||||||||||
Description Get the current configuration of the log service instance. |
||||||||||
Path Parameter
|
||||||||||
Returns The requested config as JSON. HTTP Status Code
Content-Type
|
||||||||||
Required Access Rights The logged in user or API Key must have either the following role or right.
|
||||||||||
|
||||||||||
Description Gets the data of a log service instance. |
||||||||||
Path Parameter
|
||||||||||
Query Parameter
|
||||||||||
Returns The requested data as JSON. HTTP Status Code
Content-Type
|
||||||||||
Required Access Rights The logged in user or API Key must have either the following role or right.
|
||||||||||
|
||||||||||
Description Get the data of a log service entry with its child entries. |
||||||||||
Path Parameter
|
||||||||||
Query Parameter
|
||||||||||
Returns The requested data as JSON. HTTP Status Code
Content-Type
|
||||||||||
Required Access Rights The logged in user or API Key must have either the following role or right.
|
||||||||||
|
||||||||||
Description Get the data of a log service child entry. |
||||||||||
Path Parameter
|
||||||||||
Returns The requested data as JSON. HTTP Status Code
Content-Type
|
||||||||||
Required Access Rights The logged in user or API Key must have either the following role or right.
|
||||||||||
|
||||||||||
Description Writes the data provided in the body to OpenSearch and/or the database. For calls from Iguasu the following HTTP headers are used and their values written to the following 'externalReference' object fields of all 'parent' related documents:
|
||||||||||
Consumes
|
||||||||||
Path Parameter
|
||||||||||
Query Parameter
|
||||||||||
Returns HTTP Status Code
Content-Type
|
||||||||||
Required Access Rights The logged in user or API Key must have either the following role or right.
|
||||||||||
|
||||||||||
Description Deletes log service entries and their child entries from OpenSearch and the database. Attention: When you use 'childQuery' and/or 'childFilter' only those children get deleted, not the parent itself. |
||||||||||
Path Parameter
|
||||||||||
Query Parameter
|
||||||||||
Returns HTTP Status Code
Content-Type
|
||||||||||
Required Access Rights The logged in user or API Key must have either the following role or right.
|
||||||||||
|
||||||||||
Description Deletes log service child entries from OpenSearch and the database. |
||||||||||
Path Parameter
|
||||||||||
Returns HTTP Status Code
Content-Type
|
||||||||||
Required Access Rights The logged in user or API Key must have either the following role or right.
|
||||||||||
|
||||||||||
Description Deletes log service entries and their child entries from OpenSearch by query. Deletion from database is not supported. |
||||||||||
Consumes
|
||||||||||
Path Parameter
|
||||||||||
Query Parameter
|
||||||||||
Returns HTTP Status Code
Content-Type
|
||||||||||
Required Access Rights The logged in user or API Key must have either the following role or right.
|
||||||||||
|
||||||||||
Description Deletes only log service child entries from OpenSearch by query. Deletion from database is not supported. |
||||||||||
Consumes
|
||||||||||
Path Parameter
|
||||||||||
Query Parameter
|
||||||||||
Returns HTTP Status Code
Content-Type
|
||||||||||
Required Access Rights The logged in user or API Key must have either the following role or right.
|
||||||||||
|
||||||||||
Description Deletes/drops the parent and child indices of a log service instance. |
||||||||||
Path Parameter
|
||||||||||
Returns HTTP Status Code
Content-Type
|
||||||||||
Required Access Rights The logged in user or API Key must have either the following role or right.
|
||||||||||
|
||||||||||
Description Creates a BPC deeplink to redirect the caller to the admin page of a log service instance. |
||||||||||
Path Parameter
|
||||||||||
Returns The requested data as JSON. HTTP Status Code
Content-Type
|
||||||||||
Required Access Rights Can be used without a user session. |
||||||||||
|
||||||||||
Description Redirects the user to the monitor using the OpenSearch indices of the log service instance. All provided query params are used to build a monitor filter on fields of the 'externalReference' object. For Iguasu the following query parameters can be used to access the HTTP header values when the entry has been created.
|
||||||||||
Path Parameter
|
||||||||||
Query Parameter
|
||||||||||
Returns The requested data as JSON. HTTP Status Code
Content-Type
|
||||||||||
Required Access Rights Can be used without a user session. |
||||||||||
|
||||||||||
Description Get a JSON schema for the defined 'keys' and 'fields' of a log service instance. Such a JSON schema can be used to validate the JSON data POSTed to the create log service entries endpoint. |
||||||||||
Path Parameter
|
||||||||||
Query Parameter
|
||||||||||
Returns The requested JSON schema. HTTP Status Code
Content-Type
|
||||||||||
Required Access Rights The logged in user or API Key must have either the following role or right.
|
Response im Fehlerfall
Bei jedem Fehler (Status != 200) wird eine JSON mit folgendem exemplarischen Aufbau zurückgeliefert:
{
"error": {
"code": 301,
"name": "MODULE_INSTANCE_NOT_FOUND",
"message": "Did not found the instance 'of_test2' of the module 'logservice'.",
"properties": {
"instanceId": "of_test2",
"moduleId": "logservice"
}
}
}
Die möglichen Error Codes
Error Code |
|
Info |
1 |
|
sollte nicht aufreten |
20 |
|
das 'Log Service' Modul wurde nicht gefunden |
21 |
|
die 'Log Service' Instanz wurde nicht gefunden |
10000 |
|
Es wurden keine Daten zum "loggen" übergeben |
10010 |
|
Die übergebenen Daten sind kein gültiges JSON bzw. entsprechen nicht dem hier genannten Aufbau |
20000 |
|
Die Zugangsdaten stimmen nicht mit den hinterlegten überein (Log Service Modul Einstellung) |
20001 |
|
Der Log Service befindet sich derzeit im Wartungsmodus bzw. das DB- und OpenSearch-Logging sind deaktiviert |
20002 |
|
Ein vom Log Service benötigter Dienst steht nicht zur Verfügung |
20100 |
|
Beim DB Logging ist ein Fehler aufgetreten |
20101 |
|
Beim Löschen von DB Einträgen ist ein Fehler aufgetreten |
20102 |
|
Es wurde ein ungültiger Tabellenname angegeben |
20103 |
|
Die verwendete Datenbank-Tabelle konnte nicht gefunden werden |
20104 |
|
Die zu verwendende Datenbank-Spalte existiert nicht |
20105 |
|
Die Metadaten der Datenbank konnten nicht ausgelesen werden |
20106 |
|
Die angeforderte Funktionalität steht bei relationalen Datenbanken nicht zur Verfügung |
20201 |
|
Beim Zugriff auf OpenSearch ist ein Fehler aufgetreten |
20202 |
|
Zum Bilden des Dokument-Schlüssels fehlen die erforderlichen Daten im zu loggenden Dokument |
20203 |
|
Beim Schreiben der Daten nach OpenSearch kam es zu einem Problem |
20204 |
|
Beim Löschen von Dokumenten aus dem OpenSearch Index ist ein Fehler aufgetreten |
20205 |
|
Es wurden mehr Daten angefordert als zur Verfügung stehen |
POST : Aufbau der zur übergebenden JSON Nachricht
Eintrag erstellen/aktualisieren
{
"entries": [
{
"parent": {
"keyname_parent": keywertparent1,
"feldname1": wert1,
"feldname2": wert2,
...
},
"children": [
{
"keyname_parent": keywertparent1,
"keyname_child": keywertchild1,
"feldname1": wert1,
"feldname2": wert2,
"datei_binary": base64_3,
...
},
{
"keyname_parent": keywertparent1,
"keyname_child": keywertchild2,
"feldname1": wert3,
"feldname2": wert4,
"datei_binary": base64_5,
...
},
...
]
},
...
]
}
Einzelne Felder aktualisieren (Partial Update)
{
"entries": [
{
"partialUpdate": true,
"parent": {
"keyname_parent": keywertparent1,
"feldname1": wert1,
"feldname2": wert2
},
...
},
...
]
}
Infos zum Partial Update
Das Partial Update bezieht sich auf den Parent Eintrag und die Child Einträge. Das bedeutet, wenn man ein Parent Eintrag updaten möchte, sollte man keinen "neuen" Child Log im gleichen JSON Dokument erstellen. Wenn man beim Update eines Parent Eintrages einen neuen Child Log erstellen möchte, sollte es in zwei Log-Service-Calls implementiert werden. Es könnte beispielsweise wie folgt aussehen (siehe INFOBLOCK 1 und 2):
In dem folgenden Beispiel entsprechen die Felder "ANFRAGENUMMER" dem "keyname_parent" und "CHILDID" dem "keyname_child" von zuvor.
Werte der JSON Felder
| Typ | Wertebereich |
|---|---|
Boolean |
true / false ohne Hochkommata |
Datum |
als ISO-8601 mit Hochkommata, z.B. "2017-05-17T15:28:23.181Z".
In der Datenbank das Feld als |
Zahlen |
Wert ohne Hochkommata |
Binär |
Base64 encoded.
In der Datenbank als |
Text |
Wert mit Hochkommata |
Feldnamen Konvention
Über die Modulinstanz Einstellung fields (siehe unten) können die Datentypen pro Feld festgelegt werden.
Dies ist für binary-Typen nicht unbedingt notwendig und kann auch über die Feldnamen Konvention FIELDNAME_binary (_binary als Postfix) durchgeführt werden.
Hintergrund: In OpenSearch speichern wir Binärdaten Base64 encoded ab (so müssen diese auch im übergebenen JSON stehen). Diese wollen wir aber, wie bei der Replikation unter dem speziellen Typ 'attachment' ablegen. Da beides für OpenSearch Strings sind, müssen wir dies wissen und ein spezielles Mapping durchführen.
Beispiel: Wenn wir ein Feld mit dem Namen 'datei' haben und die Namen frei vergeben können, dann kann daraus der Name 'datei_binary' werden und OpenSearch legt die Daten als 'attachment' ab bzw. erstellt das Mapping dafür.
Beispiel Aufruf
curl -H "X-ApiKey: 1f697af5-c147-3d94-c529-e06f3f15bb87" \
-H "Content-Type: application/json" \
-XPOST 'localhost:8181/cxf/bpc-logservice/log/of_test' \
-d @logservice.json
Erläuterung:
Option |
Beschreibung |
|
Der API-Key mit der passenden Rolle bzw. passendem Recht |
|
Der Content-Type muss auf |
|
HTTP POST ist erforderlich |
|
|
|
das zu postende JSON (siehe unten) |
logservice.json (Eintrag erstellen/aktualisieren)
{
"entries": [
{
"parent": {
"processid": 40,
"name": "hello world",
"city": "Berlin",
"lastupdate": "2017-05-17T15:28:23.181Z"
},
"children": [
{
"processid": 40,
"childid": 1,
"ersteller": "Oliver",
"kommentar": "Bild und langer Text",
"datei": "iVBORw0KGgoAAAANSUhEUgAAAAIAAAACAQMAAABIeJ9nAAAABlBMVEUAAAD///+l2Z/dAAAADElEQVQIHWNwYGgAAAFEAMGoX3f9AAAAAElFTkSuQmCC",
"langertext": "Dieser Text ist aber ziemlich .................... lang. :-)",
"lastupdate": "2017-05-17T15:28:23.181Z"
}
]
}
]
}
File-Storage im Log-Service
Der Log-Service unterstützt Log-Einträge mit Verweisen auf Dateien im File-Storage. Dabei gibt es zwei Möglichkeiten:
-
Direkter Verweis: Es wird ein Verweis (URI) auf eine bereits vorhandene Datei im File-Storage gespeichert.
-
Base64-Upload: Die Datei wird als Base64-kodierter String übertragen. Der Log-Service legt diese Datei anschließend im File-Storage ab und speichert eine Referenz darauf im Log-Eintrag.
File-Storage-Referenzen
Für File-Storage-Referenzen wird der Feld-Typ file-storage verwendet.
Eine Referenz hat das Schema:
bpc://backend-connection/FILE_STORAGE_BACKEND_CONNECTION_ID/FILE_STORAGE_ITEM_ID
Beispiel für eine POST-Anfrage mit direkter Referenz:
{
"entries": [
{
"parent": {
"id": "1",
"file": "bpc://backend-connection/1752063970035/5919ea1ca9b5b8baee8b0cedc5e37c3c59c98fafefd71ed35d38bfc2aea288c7"
}
}
]
}
Base64-Upload
Soll eine Datei direkt hochgeladen werden, muss in der Log-Service-Instanz zunächst der File-Storage-Upload aktiviert werden. Dies geschieht über folgende Optionen:
-
filestorageUploadEnabled: muss auftruegesetzt werden -
filestorageBackendConnection: ID der zu verwendenden File-Storage-Backend-Connection -
filestorageBucket: Bucket, in dem Dateien abgelegt werden -
filestorageReadRestriction: Lese-Beschränkung für neue Dateien -
filestorageWriteRestriction: Schreib-Beschränkung für neue Dateien
Die File-Storage-Backend-Connection muss zuvor konfiguriert sein. Außerdem muss der definierte Bucket im File-Storage vorhanden sein.
Beispiel für eine POST-Anfrage mit Base64-kodierter Datei:
{
"entries": [
{
"parent": {
"id": "1",
"file": {
"mediatype": "text/plain",
"filename": "test.txt",
"content": "RGFzIGlzdCBlaW4gVGVzdC1UZXh0ZGF0ZWkK"
}
}
}
]
}
In diesem Fall ist das file-storage-Feld ein JSON-Objekt.
Darin enthält:
-
content: die Datei als Base64-kodierter String (Pflichtfeld) -
mediatype: Media-Type der Datei (optional, Standard:application/octet-stream) -
filename: Dateiname (optional, Standard:file)
Der Log-Service speichert in der Datenbanktabelle und im OpenSearch-Index jeweils nur die Referenz (bpc://backend-connection/../..) ab.
|
Beim Löschen oder Überschreiben eines Log-Eintrags wird die referenzierte Datei nicht automatisch im File-Storage gelöscht. Soll die Datei entfernt werden, muss dies manuell über die File-Storage API erfolgen. |
