KGS DocumentRouter is being shipped with the option to create a protocol that includes the information of all processed documents - whether they have been archived and processed successfully or not.
In order to open the protocol you may click on Main → Protocol Writer. This will lead you to the KGS Protocol Writer, which has been shipped together with DocumentRouter.
In case you have enabled protocolling, you may see a list of entries representing the documents that have been processed so far, similar to the example below.
Sample of Protol Writer output after processing documents in an DocumentRouter instance. |
|---|
 |
Protol Writer will provide you with the following information.
Column name | Description |
|---|---|
Repository | The column Repository contains information regarding the repository the document has been archived to. |
Document | Within the column Document you’ll find the document Id, which has been used or was created in order to store and find again the archived document. |
Module | The defined alias for the protocol information may be found in the column Module, which helps you to identify, which DocumentRouter instance was archiving the document. |
Client | The column Client contains the |
Node | You may find the name of the server on which the DocumentRouter instance is running on in the column Node |
Operation | The operation that had been tried by the DocumentRouter instance against the archive may be found in the column Operation |
Start Time | The column Start Time contains the date and time, when the operation was started. |
End Time | You’ll find the date and time when the operation finished in the column End Time. |
Status | The column status contains the HTTP code which had been returned by the archiving system during the archiving process. |
Remove protocol writer bundle
Alle OSGi-basierten KGS Produkte:
KGS Contentserver
KGS Webservice
KGS DocumentRouter (3.x & 4.x)
KGS Scanserver
KGS WriteCache
KGS ReadCache
haben den KGS ProtocolWriter im Auslieferungspaket (.war). Dieser erlaubt es in eine Datenbank diverse Aktionen (create,put,get etc.) zu protokollieren. Dies kann in den Produkten explizit aktiviert bzw. deaktiviert werden.
Ist zusäzlich TiA Core (mit CMIS konformer Ablage) im Einsatz, so wird zusätzlich zum ProtocolWriter auch in das konfigurierte TiA Core Modul protokolliert (z.B. ElasticSearch).
Die Implementierung ist über Services realisiert wurden. Die einzelnen KGS Komponenten fungieren dabei als Service-Consumer. Sie “publishen” einen Protokolleintrag an den ein Interface (IProtocolWriter), welcher im KGS Core Bundle liegt.
Existieren nun Service-Listener im OSGi-Framework, so nehmen diese die Protokollnachricht entgegen und verarbeiten diese.
Der KGS ProtocolWriter ist ein Service-Listener
TiA Core ist ein Service-Listener
Diese Services sind losgelöst voneinander und kennen sich nicht. Dieses Konzept ermöglicht es uns, belieb viele neue Service-Listener hinzuzufügen oder zu entfernen, ohne den anderen Listener zu beeinflussen.
Möchte man nun z.B. nicht mehr in eine ProtocolWriter DB schreiben, so kann das Bundle “KGS ProtocolWriter” aus dem WAR entfernt werden. Es ist sogar möglich im laufenden Betrieb das Bundle zu stoppen. Ist TiA Core noch in dem WAr enthalten, wird hier weiterhin in Elastic protokolliert, nicht aber mehr in die konfigurierte Datenbank des ProtocolWriters.
Es ist ausreichend den KGS ProtocolWriter (com.software.kgs.plugin.protocol-x.x.x.jar) aus dem WAR zu entfernen. Dieses befindet sich unter:
<WAR>\WEB-INF\eclipse\plugins\
Eine weitere Anpassung ist nicht mehr notwendig.
Optional:
OSGi startet Bundles beim starten in einer speziellen Reihenfolge. Diese Reihenfolge ist in
<WAR>\WEB-INF\eclipse\configuration\config.ini
festgelegt.
Diese kann entfernt werden. Dies muss aber nicht geschehen, da OSGi nur die Bundles in der Reihenfolge startet, die es auch finden kann. Existiert das Bundle “com.software.kgs.plugin.protocol-x.x.x.jar” nicht mehr im eclipse/plugins ordner, so überspringt OSGi den Startvorgang für dieses Bundle.
Sollte diese Datei modifiziert werden, so ist auf die Syntax zu achten. Jede Zeile (außer der letzten) endet mit einem Komma sowie ein Space und ein Backslash (für Zeilenumbruch). Für mehr [interne] Informationen gibt es hierzu mehr:
/wiki/spaces/WIKI/pages/6750661
Wichtig: Die config.ini wird nur einmalig beim deployment ausgeführt. Das bedeutet, dass jede Änderung an dieser Datei ein komplettes Redeployment der WAR-Datei vorraussetzt. Die Datei in einer bereits deployten Version zu modifizieren hat keinen Effekt.
Zugehörige Konfigurationsdateien
Wird der ProtocolWriter gestartet und es ist noch keine Konfiguration im Vorfeld in dem WAR enthalten (Default-Auslieferung), so legt der ProtocolWriter selbstständig in seinem config-Ordner (…/protocol/) eine neue Konfiguration mit dem Namen “Protocol Service.cfg” an. Dies gilt für alle OSGi Bundles.
Wurde der WAR-Container aber bereits vorkonfiguriert (<WAR>\conf\protocol\Protocol Service.cfg), so kann dieser Ordner (ab inlusive “protocol”) entfernt werden. Diese Dateien sind ohne das Bundle / die JAR Datei verwaist.
Referenzen in anderen Konfigurationsdateien
Der ProtocolWriter kann von vielen KGS Produkten benutzt werden. (Liste: Siehe oben). Jeder dieser KGS Produkte besitzt eine Konfiguration, in der die Einstellungen zum Protokoll gesetzt werden können. Zum Beispiel:
../contentserver/ContentServer.cfg
z.B.
Diese Einträge (KEYs) müssen behalten werden. Es ist erlaubt die Werte (true und false) zu ändern, der gesamte <entry>-Zeile muss aber in der Konfiguration weiterhin existieren.
Die Parameter in den KGS Produkten steuert, ob das Bundle (hier: KGS Contentserver) ein Protokolleintrag an das OSGi weitergibt und welche Art von Protokolleinträgen es weitergibt. Insofern ein zweiter Service-Listener (wie KGS TiA Core [AutoDigit]) im Framework existiert, so wird dieser nur ausgelöst, wenn Protokolle an das OSGi Framework weitergegeben werden.
Ein entfernen hat zur Folge, dass die Werte bei Applikationsstart mit Default-Werten neu geschrieben werden.