Allgemeine Hinweise zu HitBatch-Logfiles

Im Zusammenhang mit dem HitBatch-Client sind folgende Protokolldateien ("Logfiles") zu unterscheiden.

	Ablaufprotokoll mit allgemeinen Informationen zum Programmablauf
	Set-Logfile mit detaillierten Antworten zu allen Befehlen der einzelnen Aufgabe ("Set")
	Block-Logfile als Zwischenlager für Antworten noch nicht abgeschlossener Blöcke im Blockmodus
	Connection-Logfile zur zusätzlichen Protokollierung mit welchen Server die Verbindung erfolgte

Struktur und Speicherform werden durch Parameter der Steuerdatei (i.d.R. Hitbatch.INI) festgelegt. Der Inhalt ergibt sich aus dem konkreten Programmablauf.

Auf Besonderheiten der jeweiligen Betriebssystemumgebung wie Dateisystempfade, Schreibweisen und Zugriffsrechte wird hier nicht näher eingegangen.

Besonderer Hinweis: Die Auswertung der Logfiles ist Pflicht!

Ablaufprotokoll

Der generelle Ablauf des Programms mit Lesen der Steuerdatei, Verbindungsaufnahme zu HIT-Server, abarbeiten der einzelnen Aufgaben (Sets) und Verbindungsabbau wird je nach Konfiguration in unterschiedlicher Ausführlichkeit um Bildschirm und/oder dem Ablaufprotokoll festgehalten.

Struktur & Inhalt

	Speicherort festgelegt durch PROTOFILE
	Umfang festgelegt durch PROTOLEVEL
	Anhängen oder überschreiben durch PROTOAPPEND

Beispiel

Bearbeite Set-1
[Global]
Userid=276090000000015;
...
ProtoLevel=4;
ProtoFile=HitBatch.log;
ProtoAppend=1;
ProtoScreen=-1;
...
AntwortVerbose=3;
Schwere=0;
...
BlockRestLog=BLOCKREST.LOG;
MaxConsecutiveErrors=-1;
...
SetCount=1;
StartSet=1;
WrapAround=0;
ConnectLogFile=CONNECTION.LOG;
ConnectLogLevel=0;
[Set-x]
Meldung=ZUGANG;
Befehl=IS;
VerhaltenBeiNachfrage=1;
NachfrageListe=0;
TestDoppelteHeader=0;
TestRowCounter=1;
DataLinesSoFar=0;
InputAfterSuccess=0;
CsvIn=0;
CsvOut=1;
CsvLog=0;
FuncOnly=0;
FileNameIn=ZUGANG.csv;
FileNameOut=ZUGANG.out;
FileNameLog=ZUGANG.log;

Verbindungsaufbau zum Hit-Server ...
Verbindung zum Backup-Server ok:hitbackup.hi-tier.de/2223
SEND<*1:XS/T:LOGON/BNR15;MBN;PIN;MELD_WG;TIMEOUT;VERBOSE;VERSIONC:276090000000015;0;900015;4;200;3;23>
Datentransfer ...
1.Satz gelesen, Übertragung ...
SEND<*2:IS:ZUGANG/BNR15;LOM;ZUGA_DAT:090000000001;DE0912300100;1.1.2003>
2.Satz gelesen, Übertragung ...
SEND<*3:IS:ZUGANG/BNR15;LOM;ZUGA_DAT:090000000001;DE0912300101;1.6.2004>
Anzahl gelesener Zeilen (inklusive Überschriftszeile) : 3
Anzahl Zeilen ohne Fehler (GOOD)                      : 2
Anzahl Zeilen mit  Fehler (BAD)                       : 0
Anzahl Zeilen mit Antworten in der LOG-Datei          : 2
Set-1 beendet, Sekunden:2

Verbindungsabbau ...
SEND<*4:XS:LOGOFF/:>
HitBatch beendet
HitBatch - Returncode:0, Sekunden:2

Set-Logfile

Für jeder separate Aufgabe in der Steuerdatei HitBatch.INI existiert ein eigener "Set". Mit Angaben zu den Eingabedateien mit den Datensätzen aus denen die einzelnen Befehle an den Hitserver erzeugt werden und Ausgabedateien mit Protokollantworten des Servers ("Logfile") und ggf. Datenausgabedateien für abgeholte Daten oder zur Trennung von vom Server akzeptierten Sätze ("Goodfile") und abgelehnten und damit nicht gespeicherten Sätzen ("Badfile").

Struktur & Inhalt

	Gesteuert durch Parameter in HitBatch.INI, besonders relevant hierbei Speicherort festgelegt durch LOGFILE als Pfad- und Dateiangabe Ausgabeform: CSVLOG als Standard, Readable oder ADIS Umfang entsprechend minimal zu protokollierende Antwort-SCHWERE Reaktion auf Antworten der Schwere=2 über Verhaltenbeinachfrage Ob zu Plausinummern auch Text kommen sollen siehe ANTWORTVERBOSE
	im Prinzip Datenzeile mit Stern dann Antwortzeilen im Antwortformat (siehe HIT-Protokoll - Antwortformat)
	bei Nachfragen als Antwort der Schwere=2 ggf. dieselbe Datenzeile zweimal im Logfile zuerst für das normale Senden mit entsprechenden Antworten der Schwere 2 (Nachfrage) und dann wenn VerhaltenBeiNachfrage=1 oder VerhaltenBeiNachfrage=2 und die konkrete Plausinummer in der NACHFRAGELISTE dann neu "force"-senden mit "command/S" und damit ein zweiter Antwortblock, jetzt i.d.R. mit einer gleichlautenden Antwort der Schwere=1 als Hinweis
	Logfiles von Datensendeaufträgen (mit Command IS oder XS) unterscheiden sich nur im Inhalt, nicht aber in der Struktur von Datenabholaufträgen (mit Command RS)
	Die Gewissheit ob Datenmeldungen erfolgreich in der Zentralen Datenbank abgespeichert bzw. Abfragen erfolgreich ausgeführt wurden, ergibt sich aus der Analyse des Logfiles: Aktion erfolgreich - wenn die maximale Antwortschwere zu einem Satz kleiner oder gleich 1 ist  Aktion nicht erfolgreich - wenn die maximale Antwortschwere zu einem Satz größer 1 ist
	...

Beispiel

*090000000001;DE0912300100;1.1.2003
%2%1:1/2084:ZUGANG/ZUGA_DAT:Das Zugangsdatum liegt über 1 Jahr zurück.
%2%2:1/2116:ZUGANG/*:Zum Tier liegen widersprüchliche Stammdaten vor. - Geburtsdatum 01.01.2003, Alter ....
=2%3:0/130:ZUGANG:Die Meldung wurde abgespeichert.
*090000000001;DE0912300101;1.6.2004
%3%1:1/2115:ZUGANG/*:Zum Tier liegen keine Stammdaten vor.
=3%2:0/130:ZUGANG:Die Meldung wurde abgespeichert.
*090000000001;DE0912311100;1.1.2003
%2%1:1/2084:ZUGANG/ZUGA_DAT:Das Zugangsdatum liegt über 1 Jahr zurück.
=2%2:2/701:ZUGANG/LOM:Diese Ohrmarkennummer existiert nicht in der Datenbank.
*090000000001;DE0912311100;1.1.2003
%3%1:1/2084:ZUGANG/ZUGA_DAT:Das Zugangsdatum liegt über 1 Jahr zurück.
%3%2:1/419:ZUGANG/LOM:Diese Ohrmarkennummer existiert nicht in der Datenbank.
%3%3:1/2115:ZUGANG/*:Zum Tier liegen keine Stammdaten vor.
=3%4:0/130:ZUGANG:Die Meldung wurde abgespeichert.
*090000000001;DE0912300101;1.6.2004
%4%1:1/2115:ZUGANG/*:Zum Tier liegen keine Stammdaten vor.
=4%2:1/133:ZUGANG:Diese Meldung liegt bereits identisch vor und wurde deshalb ignoriert.

Die mit Stern gekennzeichneten Datenzeilen sind zur besseren Lesbarkeit fett angezeigt.
Der Aufgrund der Nachfrage ein zweites mal übertrage Datensatz ist zur besseren Lesbarkeit fett und rot angezeigt.

Block-Logfile

Im Blockmodus wird eine Folge von Befehlen immer als Ganzes betrachtet. Wenn nun während einer Blockübertragung die Verbindung abbricht, gilt der ganze Block als noch nicht gesendet. Bei einem automatischen Wiederaufsetzen wird die Übertragung mit dem ersten Satz des Blockes fortgesetzt.

In aller Regel ist davon aus zu gehen, dass die Sätze des abgebrochenen Blocks nicht im Server verarbeitet sind, da der COMMIT implizit am Blockende erfolgt. Würde nun schon ein Teil der Antworten im normalen Set-Logfile stehen, könnte eine Auswertung dieses Logfiles anhand der Schwere zur falschen Annahme gelangen, diese Sätze wäre verarbeitet.

Aus diesem Grund werden die Antworten zu einem Block erst am Ende der Verarbeitung des gesamten Blockes ins Set-Logfile geschrieben. Dies dahin werden diese "halbfertigen" Antworten in einer eigenen Datei, dem Block-Logfile, zwischengespeichert.

Im Falle des Blockabbruch, insbesondere wenn der durch zu viele aufeinanderfolgenden Datenfehler provoziert war (vgl. Parameter MAXCONSECUTIVEERRORS), kann diese Datei bei der Fehleranalyse hilfreich sein. Eine vollautomatische Auswertung ist aber in der Regel nicht erforderlich.

Speicherort festgelegt durch BLOCKRESTLOG

Connection-Logfile

In den obigen Logfiles ist nicht erkennbar mit welchem  - Primary oder Backup - Server die Verbindung tatsächlich erfolgte. Wenn der INI-Parameter CONNECTLOGFILE angegeben ist, wird dort exakt protokolliert mit welchen Server die Verbindung erfolgte. Damit können etwaige Verbindungsprobleme analysiert werden.

	Speicherort festgelegt durch CONNECTLOGFILE
	Umfang festgelegt durch CONNECTLOGLEVEL

Beispiel

HitBatch Version 23, 23.03.2004 16:00
Start HitBatch-Ausführung: 02.06.2004 18:57:13
Primary Server nicht verfügbar - Secundary Server anwählen ...
Secundary Server - max. Schwere-Antwort 0 erhalten:
=0:0/39::HitServer bereit. Version 39, 25.05.2004 18-30h. Sie sind mit dem Test-System verbunden ... 
Verbunden mit hitbackup.hi-tier.de:2223

Zurück zum Anfang