Hinweise zur HitBatch-Konfiguration

Inhalt

	Welche Dateien benötigt man für den HitBatch und welche werden erzeugt?
	Wie sieht eine Eingabedatendatei aus?
	Welche Parameter können in einer Ini-Datei angegeben werden?
	Betriebsnummer und PIN

	Wann ist ein Satzmodus sinnvoll, wann ein Blockmodus und welche Einstellungen sind dafür nötig?
	Wo gibt man welche Aktion an?
	Informationen zu den Protokolldateien siehe HitBatch-Logfiles.
	Informationen zu den Parametern der Steuerdatei (i.d.R. HitBatch.INI) siehe HitBatch.INI-Parameter.
	Wie benutze ich die Verschlüsselung bei Anmeldung und Datentransfer?

Welche Dateien benötigt man für den HitBatch und welche werden erzeugt?

	Für die Benutzung des HitBatch muss eine Ini-Datei verwendet werden, aus der der HitBatch die für die Datenübertragung notwendigen Informationen liest. In dieser Ini-Datei werden unter anderem auch die Ein- und Ausgabedateien angegeben.
	Die Eingabedatendatei wird beim Parameter INFILE in der Ini-Datei angegeben. Diese enthält die Feldnamen und Datenzeilen, die als Meldungen zum Hit-Server geschickt werden
	Sämtliche Antworten des Hit-Servers werden in der Logdatei (Parameter LOGFILE in der Ini-Datei) vermerkt
	Alle Daten, die von einer fehlerfrei ausgeführten Meldung stammen, werden in einer 'Gut'-Datei (Parameter GOODFILE in der Ini-Datei) gespeichert. Dort werden nur die Daten abgelegt, d.h. keine Antwortstrings und auch keine Feldnamen.
	Alle Daten, die von einer fehlerhaft ausgeführten Meldung stammen, werden in einer 'Schlecht'-Datei (Parameter BADFILE in der Ini-Datei) gespeichert. Dort werden auch nur die Daten abgelegt, d.h. keine Antwortstrings und auch keine Feldnamen.
	Bei Abfragen über den HitBatch werden die Antworten in der Ausgabedatendatei (Parameter OUFILE in der Ini-Datei) abgelegt.
	Wird der Blockmodus verwendet, dann werden fehlerhafte Blockübertragungen in einer separaten Logdatei (Parameter BLOCKRESTLOG in der Ini-Datei) ausgegeben. Ist eine Blockübertragung erfolgreich (dies ist unabhängig von den Meldungen selbst), dann werden die Antworten zu den Meldungen in die Logdatei geschrieben.

Wie sieht eine Eingabedatendatei aus?

Die Eingabedatendatei wird beim Parameter INFILE in der Ini-Datei angegeben. Der HitBatch kann zwei Datenformate verarbeiten:

Datenformat: CSV

Diese hat generell folgenden Aufbau:

Zeile 1: Feldnamen (in GROßBUCHSTABEN), jeweils durch ';' getrennt
Zeile 2: Daten gemäß Feldnamenzeile, jeweils auch durch ';' getrennt
  .....
Zeile n: Daten gemäß Feldnamenzeile, jeweils auch durch ';' getrennt

Datenformat: ADIS

Jede Eingabedatendatei muss mindestens die Felder enthalten, die je nach Meldung zwingend erforderlich sind (gekennzeichnet durch PK und MAN für Primary Key und Mandatory). Weitere Felder zu den Meldungen sind optional, aber Systemfelder (gekennzeichnet durch SYS) können nicht verwendet werden. Sind jedoch bei den optionalen Feldern (bzw. Spalten) nicht alle Datenzeilen belegt, dann werden sie bei numerischen Werten mit '%--' und bei alphanumerischen Feldern mit '' (leere Zeichenkette) als leer gekennzeichnet (ADIS verwendet hierfür Fragezeichen '?' als 'leer'). Diese dürfen jedoch bei Pflichtfeldern nicht angegeben werden!

Welche Serveradressen und Ports muss ich in der HitBatch.ini angeben?

Der Anwender muss im [Global]-Bereich folgende Adressen verwenden:

PRIMARYSERVER=hitserver.hi-tier.de
BACKUPSERVER=hitbackup.hi-tier.de

Beide zu verbindenden Ports müssen im Idealfall identisch sein, also:

PRIMARYPORT=2222
BACKUPPORT=2222

Damit kann man sich redundant mit unserem Produktionssystem verbinden. Sollte nämlich eine Verbindung nicht möglich sein, wird intern über die BACKUP-Verbindung physikalisch ein anderer Server angesprochen. Sind die Ports unterschiedlich, kann es passieren, dass man sich in an beiden Ports mit ein und demselben Server verbindet und wenn der gerade nicht verfügbar ist, dann erhalten Sie trotz alternativer Angabe keine Verbindung zu uns!

Für Verbindungen mit unseren Test-System:

PRIMARYPORT=2223
BACKUPPORT=2223

Landesstellen, die sich per TESTA-Netz mit uns verbinden, nehmen statt den obigen Adressen diese:

PRIMARYSERVER=hitserver.hi.tier.de.testa-de.net
BACKUPSERVER=hitbackup.hi.tier.de.testa-de.net

Wieder andere Landesstellen und auch größere Betriebe verwenden eigene Übergänge ins Internet, deren Adressen wir nicht kennen. Dazu sind Ihre eigenen Administratoren im Haus zu kontaktieren und ggf. die genannten Ports an den Übergängen freizuschalten.

Was muss im HitBatch.ini stehen, damit mehrere Eingabedatendateien mit jeweils verschiedenen Meldungen an den Hit-Server geschickt werden können?

Es müssen Betriebsnummer (Parameter USERID) und PIN (Parameter PIN) angegeben werden.
Zudem sind evtl. Parameter für eine Blockübertragung einzustellen.

Wesentlichster Bestandteil sind die Sets. Jeder Set enthält Angaben zur Eingabe- und zu den Ausgabedatendateien, zur Meldung und Aktion, und zu zusätzlichen Anweisungen. Jeder dieser Sätze beginnt mit einem [SET-n], wobei n eine mit 1 beginnende fortlaufende Nummer ist. Nach dieser Einleitungszeile folgen nachstehende Parameter, die unbedingt gesetzt sein müssen:

	MELDUNG: Dies ist die Meldung, zu der die Daten aus dem INFILE zum HitServer geschickt werden sollen
	COMMAND: Dies ist die Aktion für die Meldung, mehr dazu siehe unten.
	DATALINESSOFAR: Dies ist der interne Zähler in der Eingabedatendatei. Falls der HitBatch wegen Fehler beim Übertragen abbrechen sollte, vermerkt er hier die Nummer des zuletzt versendeten Satzes und fährt bei einem Neustart an dieser Stelle wieder fort. Zu Beginn sollte er auf 0 gesetzt sein
	INPUTAFTERSUCCESS: Gibt an, was mit der Eingabedatendatei geschehen soll, wenn sie erfolgreich abgearbeitet wurde. 0 steht für unverändert lassen, 1 für Datei leeren (Größe 0), 2 für physisch löschen oder 3 für umbenennen. Voreingestellt ist 0.
	INFILE: Dateiname der Eingabedatendatei (muss angegeben werden)
	LOGFILE: Dateiname der Logdatei (muss angegeben werden)
	OUFILE: Dateiname der Abfrageergebnisdatei (muss angegeben werden)
	GOODFILE: Dateiname für die Datensätze, die korrekt bearbeitet wurden (kann angegeben werden)
	BADFILE: Dateiname für die Datensätze, die fehlerhaft bearbeitet wurden (kann angegeben werden)
	CSVIN, CSVOUT, CSVLOG: geben das Datenformat an, das die Datendateien besitzen. Dabei steht 0 für Zeichenketten ohne Hochkomma, Sonderzeichen hex-Quoted und NULL als '%--', 1 für Zeichenketten in Hochkomma und NULL und Leer sind nicht unterscheidbar und 2 für das ADIS-Datenformat.

Es können mehrere Sets hintereinander folgen. Die Anzahl der Sets wird im Parameter SETCOUNT festgelegt und der Set, bei dem der Hitbatch beginnen soll, wird im Parameter SETSTART angegeben. SETSTART ist defaultmäßig auf 1 gesetzt. Der HitBatch ändert den Wert von SETSTART auch automatisch auf den zuletzt bearbeiteten Set, falls dieser wegen eines Fehlers abbrechen muss.

Betriebsnummer und PIN

Je nach Meldungsart(en) müssen in den Parametern USERID und PIN die Werte geändert werden. Bestimmte Meldungsarten benötigen Kompetenzen, die zur Betriebsnummer gespeichert sind.

Wann ist ein Satzmodus sinnvoll, wann ein Blockmodus und welche Einstellungen sind dafür nötig?

Satzmodus ist sinnvoll, wenn kleinere Datenbestände übertragen werden sollen. Dafür reicht die Angabe einer Aktion mit dem Modus 'S', also "XS", "IS", "DS" etc. (Parameter COMMAND). Bei größeren Datenbeständen ist der Blockmodus zu empfehlen, da die Datenbank effektiver arbeiten kann. Dazu gibt man in HitBatch.ini dem Parameter BLOCKMAX die Anzahl der auf einmal zu übertragenden Datensätze an. Werte von 500 oder 1000 sind eine gute Wahl. Dazu muss der Parameter BLOCKRESTLOG zusätzlich mit dem Dateinamen belegt werden, in der die bei der Blockübertragung gesendeten und empfangenen Antworten im Fehlerfall gespeichert werden. Nur wenn die Blockübertragung mit Senden und Empfangen erfolgreich war, wird in die normale Logdatei (Parameter LOGFILE) ausgegeben.

Wo gibt man welche Aktion an?

Es gilt verschiedene Fälle zu beachten:

1. Meldungen und Abfragen im HIT-Format

   	Wird bei COMMAND im Ini-File ein '*' (Stern) eingegeben, dann muss in der Datendatei (Paramater INFILE) eine Spalte mit dem Feldnamen '*' (Stern) und als Daten die Aktion angegeben werden.
   	Wird bei COMMAND die Aktion direkt eingetragen, dann darf in der Datendatei keine Spalte '*' (Stern) mit Daten vorhanden sein.

2. Meldungen und Abfragen im ADIS-Format

   	Wird bei COMMAND im Ini-File ein '*' (Stern) eingegeben, dann müssen in der ADIS-Datendatei (Parameter INFILE) eine Spalte mit der DDI 820055 (Feldlänge 1, Nachkommastellen 0) in der Headerzeile und die Aktionen in den nachfolgenden Datenzeilen eingefügt werden.
   	Wird bei COMMAND '*B' oder '*S' (Stern mit S oder B dahinter) eingetragen, dann werden auch eine Spalte mit der DDI 820055 in der Headerzeile und die Aktionen in den nachfolgenden Datenzeilen eingefügt. Die Aktionen dürfen dann nur einen Buchstaben enthalten: X, I, D, R.
   	Steht bei COMMAND eine vollständige Aktion, dann darf in der ADIS-Datendatei keine Aktionsspalte vorhanden sein.

Leider ist die DDI für die HIT-Aktion als Feld mit 1 alpha-numerischen Zeichen definiert worden. Somit läßt sich der erste angesprochene Punkt nicht realisieren. Es wird aber an einer Änderung der Definition gearbeitet.

Wie benutze ich die Verschlüsselung bei Anmeldung und Datentransfer?

Um Daten verschlüsselt zu übertragen, stehen zwei Arbeitsmodi zur Verfügung.

	Modus 1: Verschlüsseln der Anmeldeinformation (also mindestens BNR15 und PIN) und das unverschlüsselte Austauschen der Daten
	Modus 2: analog Modus 1, aber zusätzliches Verschlüsseln der Daten

Zum Aktivieren der Verschlüsselung ist im Block [Global] der Parameter CIPHERLEVEL auf 1 oder 2 (analog eben beschriebenen Modi) zu setzen. Zusätzlich wird der Parameter SVRPUBKEY benötigt: dieser definiert den öffentlichen Schlüssel für das asymmetrische Verschlüsselungsverfahren bei der Anmeldung. Dies läßt sich auf zwei Arten bewerkstelligen:

1. Angabe des Hex-codierten Schlüssels als Wert
2. Angabe eines Dateinamens, dem ein @ vorangestellt wird. Die Datei selbst enthält dann den Hex-codierten Schlüssel.

Der aktuelle Hex-codierte Schlüssel ist hier zu finden.

In Modus 2 werden die Daten mit einem symmetrischen Verfahren verschlüsselt, d.h. für dieses ist kein Schlüssel notwendig, sondern wird bei Anmeldung zwischen Server und HitBatch ausgehandelt.

Ist CIPHERLEVEL=0, dann wird keine Verschlüsselung verwendet und SVRPUBKEY hat dann keinen Effekt.