Zur Homepage www.HI-Tier.de HITP-Spezifikation
Zurück Home Nach oben Weiter
Öffentlicher Bereich für Entwickler

 

Verbale Beschreibung

Vorbemerkungen

bulletDas HIT-Protokoll dient zur Kommunikation zwischen Programmen der Außenstellen (HIT-Clients) mit der Zentralen Datenbank (HIT-Server).
bulletHauptzweck des Protokoll ist das Senden und Abrufen von Meldungen mit Datenelemente, analog zu Datensätze mit Datenfeldern
bulletEs benutzt ASCII-Sockets über eine TCP/IP-Verbindung.
bulletDie Clients erteilen Befehle der Server gibt Antworten.
bulletBefehle gliedern sich in 4 Gruppe und dienen zum
bulletExcecute - Ausführen  von Kommandos, wie z.B. Logon, Logoff, Parameter setzen sowie Ausführen von Meldungen bei denen der Sender nicht weiß, ob Insert oder Update nötig, insbesondere bei Betriebsdaten-Meldungen mit automatischer Historisierung;
bulletInsert, Update, Storno, Delete   - Übertragen oder Pflegen von Datensätzen der einzelnen Meldungsarten;
bulletRetrieve - Abholen von verschiedenen Daten vom Server.
bulletConfirm - Bestätigen bereits abgespeicherter Sätze insbesondere im Konfliktfall (früher XS/S).
bulletLogon, Logoff und Parameter sind Spezialformen von Meldungen.
bulletZu Befehlen existieren Subcodes:
bulletzum Beenden, Abbrechen und Bestätigen usw.
bulletAntworten gliedern sich in 2 Gruppe dienen zum:
bulletMitteilen von Befehlsergebnissen, wie Return-Codes, Hinweise, Fehlermeldungen
(Eine Liste der möglichen konkreten Fehlermeldungen siehe Plausi-Prüfungen im Data-Dictionary)
bulletÜbertragen von Datensätzen bei Abfragen.
bulletBefehle und Antworten können aus mehreren zusammengehörigen Teilen bestehen.
bulletIn der Antwort ist Meldung und Feld, auf das sich z.B. eine Fehlermeldung bezieht, erkennbar.
bulletBefehle und  Antworten bzw. ihre Teile sind zeilenorientiert, d.h. sie beginnen am Zeilenanfang und enden mit Zeilenende.
bulletDas 1. Zeichen einer Zeile kennzeichnet Befehle und Antworten, es ist auch erkennbar ob mehrere Teile vorliegen.
bulletDie Verbindung ist synchron,  zu jedem Client-Befehl erfolgt eine Server-Antwort.
bulletOptimiert für die verschiedenen Clienttypen (IVR, Online ...) können Datenmeldungen verschieden strukturiert werden:
bulletFeldweise - die Datenelemente einer Meldung werden als Folge von mehreren Befehls-Antwort-Sequenzen übertragen,
bulletSatzweise - alle Datenelemente einer Meldung werden mit einer Befehls-Antwort-Sequenzen übertragen,
bulletBlockweise - mehrere Meldung werden mit einer Befehls-Antwort-Sequenzen übertragen.
bulletDa ein Kommunikationspartner unvermittelt ausfallen kann, wird mit Timeouts gearbeitet.
bulletIn der Anmeldephase verkürzte Timeouts zur Abwehr von DoS-Attacken (Denial of service).
bulletAls Codeset ist z.Zt. ausschließlich ISO 8859-1 vorgesehen. Als Dezimaltrenner wird nur '.' (Punkt) akzeptiert, Exponentialdarstellung wird z.Zt. nicht unterstützt. Eine eventuelle Umsetzung ist, schon allein aus Performancegründen, von den Clints vorzunehmen.
bulletBeim Datum ist die Form TT.MM.JJJJ also z.B. 31.01.1999 zu verwenden, siehe Datums-Format, analog siehe Timestamp-Format.
bulletSonderzeichen, insbesondere die Befehls- und Antwort-Trennzeichen ':' (Doppelpunkt) und ';' (Semikolon) sind analog zur Kodierung im HTTP-Protokoll als quoted-hex umzusetzen, siehe Quoted-Hex
bulletBehandlung von Leerzeichen:
bulletNachfolgende Leerzeichen (trailing Blanks) in Strings werden abgeschnitten (RTrim),
bulletFührende und eingebettete Leerzeichen in String sind signifikant und bleiben erhalten,
bulletFührende und nachfolgende Leerzeichen (leading and trailing Blanks) bei Zahlen werden abgeschnitten (Trim).

Allgemeiner Ablauf

Verbindungsaufbau (mandatory)

bulletÖffnen einer Socketverbindung
bulletauf dem definierten Port 2222,
bulletmit dem HIT-Server 212.18.9.50 (DNS-Name "hitserver.hi-tier.de"),
bulletoder falls der nicht verfügbar ist, auf dem selben Port 2222 mit dem Backup-Server 194.94.221.1 ("hitbackup.hi-tier.de"),
bulletfür Testzwecke steht auf den selben Servern der Test-Port 2223 allgemein zur Verfügung gestellt.
bulletNamensauflösung und Erreichbarkeit
bulletdie Namen sind über Standard-DNS-Dienste aufzulösen.
bulletIm Internet sind unter diesen Namen Proxyserver zu erreichen.
bulletDie Proxyserver leiten automatisch zu den internen Server weiter.
bulletIm geschlossenen Intranet sind unter den angegeben Namen die Server direkt zu erreichen.

Die jeweils aktuellen Informationen zu HI-Tier Internet-Adressen und Ports siehe IP-Adressen.

Anmeldung (mandatory)

bulletLogon mit Betriebsnummer als Userid
bulletund PIN als Paßwort
bulletnach 3 fehlerhaften PIN-Eingaben wird die Verbindung getrennt und für eine definierte Zeit gesperrt
bulletdie Angabe des Meldeweges ist verpflichtend, insbesondere ob Daten von einer RS kommen
bulletAktions-Code ist "X" für Excecute
bulletStückelung ist "S" (satzweise) oder "F" (feldweise)
bulletder Ablauf ist analog zu Meldungen mit Meldeart "LOGON"
bulletBeispiel:    *1:XS:LOGON/BNR15;PIN;MELD_WG:276091234567890;123456;1     (Erklärung siehe Befehlsaufbau)

Parameter festlegen (optional) , Erweiterung zum LOGON

bulleteine Reihe von Parametern können festgelegt werden, Liste siehe Parameter-Liste
bulleterfolgt keine explizite Festlegung, so werden sinnvolle Defaultwerte angenommen
bulletParameter-Festlegung erfolgen mit der LOGON-Meldung
bulletdie Einstellungen gelten nur für den aktuell angemeldeten Benutzer
bulletdie Einstellungen können nur durch erneutes LOGON geändert werden
bulletbei einem erneuten LOGON werden nicht angegebene Parameter wieder auf Default zurück gesetzt
bulletStückelung ist i.d.R "S" (satzweise) aber auch "F" (feldweise) ist möglich
bulletes wird empfohlen die eigene benutzte Protokoll-Version anzugeben
bulletdie Parameteränderungen werden mit dem erfolgreichen Abschluß der LOGON-Meldung wirksam
bulletBeispiel:    *1:XS:LOGON/BNR15;PIN;MELD_WG;VERSION;VERBOSE;TIMEOUT:276091234567890;123456;1;1;1;120

Daten senden (optional)

bulletDaten für die verschiedenen Meldungsarten, z.Zt. definierte Arten siehe HIT-Meldungen
bulletAktions-Code ist "X" für Excecute (Ausführen einer Datenmeldung) oder in definierten Situationen "I" für Insert (Einfügen neuer Sätze) oder "U" für Update, "S" für Storno oder "D" für Delete (eine genauere Erläuterung, wann welche Aktion zu verwenden siehe HIT-Aktionen und Melden und Korrigieren)
bulletStückelung ist "F" (feldweise), "S" (satzweise) oder "B" (blockweise)
bulletAntwort in Form von OK-Meldung, Hinweisen, Nachfragen, Fehlermeldungen oder Abbruch

Daten abrufen (optional)

bulletDaten für die verschiedenen Meldungsarten oder variable Definitionen
bulletgespeicherte Abfragen
bulletgeänderte Daten ab Timestamp
bulletFehlermeldungen aus früheren Sendungen
bulleti.d.R. Satzweise
bulletAntwort beinhalten Daten, Hinweise und Meldungen

Abmeldung (recommened)

bulletLOGOFF-Befehl beendet die Sitzung und Benutzeridentifikation
bulletdie geänderten Parameter werden nicht zurück gesetzt
bulletLOGON-Befehl für neuen Benutzer bewirkt implizites LOGOFF des angemeldeten Benutzers

Verbindungsabbau (mandatory)

bulletschließen der Socketverbindung

Zustände und Ereignisse

Zustände

  1. NC (=NOT-CONN)
  2. NA (=NOT-AUTH)
  3. RE (=READY)
  4. FM (=FIELD-MODE)
  5. RM (=ROW-MODE)
  6. BM (=BLOCK-MODE)

Ereignisse

  1. open-Socket
  2. Logon
  3. Logoff
  4. Aktion-Feld
  5. Input-Feld
  6. Aktion-Satz

Grobstruktur

Das HIT-Protokoll kennt verschiedene Zustände und Ereignisse. Zustands-Ereignis-Diagramme können in verschiedene Detailgenauigkeit betrachtet werden.

(Diagramm fehlt nocht)

Befehls- und Antwortsyntax

Vorbemerkungen und Definitionen

bulletPflicht- und Nichtpflicht-Bestandteile
bulletMandatory - bestimmte Elemente von Befehlen oder Befehle in einer Dialogsequenz werden unbedingt benötigt
bulletRecommended  - bestimmte Teile sind empfohlen, wie z.B. explizites LOGOFF um Resourcen wieder freizugeben
bulletOptional - Teile können fehlen und werden ggf. sinnvoll ergänzt, z.B. Feldliste einer satzweisen Meldung muß nur beim 1.Satz übertragen werden.
bulletfehlende Betriebsnummern in Meldungen werden durch BNR der Anmeldung ergänzt, wenn BNR aber als Datenfeld in der Meldung angegeben wird, darf sie nicht leer sein.
bulletDie Protokoll-Beispiele haben folgende Darstellung:
S:   <Server-Output>           // Kommentar
C:   <Client-Output>           // Kommentar

Befehlsaufbau

Ein Befehl besitzt eine fortlaufende Befehls-Nummer. Der 1.Befehl der Connection hat die Nummer 1. Ein Befehl kann aus einer oder mehreren Teilbefehlen bestehen. Jeder Teilbefehl ist eine eigene Zeile. Wenn weitere Teilbefehle folgen ist die Zeile mit dem Befehlskennzeichen "+" zu beginnen, beim letzten Befehlsteil oder wenn der Befehl nur aus einem Teil besteht ist die Zeile mit dem Befehlskennzeichen "*" zu beginnen. Jeder Teilbefehl hat die gleiche Befehls-Nummer. Teilbefehle werden ohne dazwischen liegende Antworten versendet. Befehlsteile dienen zur blockorientierten Übertragung.

Neue Befehle dürfen erst gesendet werden, wenn die Antwort für den letzten Befehl vollständig empfangen wurde. Die Teile eines Befehles werden ebenfalls beginnend mit 1 durchnummeriert.

Syntax und Bestandteile

Token Definition Bemerkung
<Befehl> <Einleitung>:<Aktion>:<Objekt>:<Datenliste> 4 Haupt-Elemente, mit Doppelpunkt getrennt
<Einleitung> <Befehls-Kenner><Befehls-Nummer>  
<Befehls-Kenner> * (Stern)  |  + (Pluszeichen) kennzeichnet Befehlsbeginn, + wenn weitere Befehlsteile folgen, * beim letzten oder einzigen Befehlsteil
<Befehls-Nummer> <Haupt-Nummer>[+<Unter-Nummer>][#<Rowkeys>] Achte auf Trennung  der Unter-Nummer durch '+'
<Haupt-Nummer> Fortlaufende Nummer des Befehl dient zur richtigen Zuordnung des Ergebnisses und Sicherung der Reihenfolge und Vollständigkeit, beginnt bei 1 für die Connection
<Unter-Nummer> Fortlaufende Nummer des Teilbefehls, wenn der Befehl aus mehreren Zeilen besteht dient zur Sicherung der Reihenfolge und Vollständigkeit wenn Teilbefehle vorliegen, beginnt bei 1 für jede neue Haupt-Nummer
<Rowkeys> <Rowkey>[;<Rowkeys>] Liste von benutzerdefinierten Keys
<Rowkey> benutzerdefinierten Key (String-Konstante) dient zur Identifikation des Befehls
<Aktion> <Aktions-Code><Stückelung>[/<Sub-Codeliste>]  
<Aktions-Code> X | I | U | S | D | R X (=Excecute) | I (=Insert) | U (=Update) | S (=Strono) | D (=Delete) | R (=Retrieve) | C (=Confirm)
<Stückelung> F | S | B | T F (=Feld) | S (=Satz) | B (=Block) | T (=Transaktion)
<Sub-Codeliste> <Sub-Code>[;<Sub-Codeliste>] ein Sub-Code oder mit Semikolon getrennt mehrere Sub-Codes
<Sub-Code> T | E | S | A | P | O | ... T (=Trotzdem) | E (=ENDE) | S (=SICHER) | A (=Abbruch) | P (=Panik) | O (=NOOP) ... siehe Sub-Codes, für RETRIEVE gibt es noch weitere Sub-Codes, siehe HIT-QL
<Objekt> [<Meldung>][/<Feldliste>] Meldung kann bei nachfolgenden Feldern der selben Meldung fehlen
<Meldung> LOGON | BETRD | GEBURT |  .... Feste Strings, siehe Meldung
<Feldliste> <Feldname>[;<Feldliste>] ein Feld oder mit Semikolon getrennt mehrere Felder
<Feldname> BNR15 | PIN | ... komplette Liste je nach Meldung, siehe Meldungselemente
<Datenliste> <Datenelement>[;<Datenliste>] ein Datenwert oder mit Semikolon getrennt mehrere Datenwerte

Schematische Darstellung

*<Nr>:<Aktions-Code><Stückelung>/<Sub-Code>:<Meldung>/<Feldliste>:<Datenliste>            

Aktions-Codes

Token Definition Bemerkung
X EXCECUTE Ausführen von Meldungen. Der Server entscheidet selbsttätig ob Insert oder Update mit Historisierung vorzunehmen ist.
I INSERT Normales Senden von neuen Meldung. Wenn eine Meldung mit identischen Schlüssel vorliegt, wird Speichern abgelehnt.
U UPDATE Für Sonderfälle reserviert wenn gezielt nur ein Update erfolgen soll (fast nur im Adressdatenbereich implementiert). Analog zu EXCECUTE wird über die Werte der Schlüssel der Satz gesucht, alle im Update-Datenteil nicht gelieferten Felder werden aus dem letzten aktuellen Satz übernommen, mitgelieferte Datenfelder führen damit zu einem selektiven Update.
S STORNO Meldung widerrufen, stornieren
D DELETE Meldung löschen, für Sonderfälle reserviert wenn gezielt ohne Historisierung gelöscht werden soll.
R RETRIEVE Abrufen von Daten mit der HIT-Query Language (HIT-QL)
C CONFIRM Nochmaliges Senden von Daten die bereits in der Datenbank abgespeichert sind um sie zu bestätigen (SYS_STAT wird dann entsprechend gesetzt). Dies wird bei der Fehlervorgangsbearbeitung, insbesondere bei zweifelhaften oder widersprüchlichen Meldungen verwendet. Der Befehl hat auch noch die zweite Bedeutung CHECK für Meldungen bei denen eine Folgeberechnung möglich ist, z.B. bei Zahlungten (TP_ZAHLUNG) für der Check zum Berechnen der Veröffentlichngsergebnisse (TP_VEROEFF).

Sub-Codes

Sub-Codes bei feldweiser Übertagung

Token Definition Bemerkung
T TROTZDEM Force für Feldprüfung, d.h. bei Fehlern der Schwere 2 mit Schwere 0 fortfahren, also Wert akzeptieren. Kann präventiv angegeben werden, d.h. Nachfragen werden gar nicht gestellt sondern dürfen automatisch als bestätigt angesehen werden. Oder /T kann zur Wiederholung einer Feldübertragung verwendet werden wenn die Feldübertragung zuvor eine Nachfrage ergeben hat und diese positiv bestätigt werden soll.
E ENDE ENDE der feldweisen Meldung mit Speichern. Der Subcode /E sollte als separater Befehl, d.h. ohne eine Datenfeld übertragen werden da sonst im Falle eines Fehlers der Schwere 2 (Nachfrage) nicht klar ist ob mittels /T eine "Feld-Nachfrage" oder mittels /S eine "Satz-Nachfrage" bestätigt werden soll.
S SICHER ENDE der feldweisen Meldung mit Speichern, Force für Meldungsprüfung d.h. bei Fehlern der Schwere 2 mit Schwere 0 fortfahren, also Meldung akzeptieren. Kann bei der feldweisen Übertragung präventiv statt /E zum Abschließen und Speichern des Satzes und Unterdrücken von Nachfragen verwendet werden. Oder /T kann zur Wiederholung der Speicheraufforderung verwendet werden wenn die vorhergehende Speicheraufforderung mit /E eine Nachfrage ergeben hat und diese positiv bestätigt werden soll.
A ABBRUCH Abbruch der feldweisen Meldung ohne Speichern, weitere Datenelemente in Befehlszeile werden ignoriert.
P PANIK sofortiger Verbindungsabbruch
O NOOP Keine Aktivität, weitere Datenelemente in Befehlszeile werden ignoriert, setzt Timeout-Zähler wieder zurück

Sub-Codes bei satzweiser Übertagung

Token Definition Bemerkung
T TROTZDEM Force für Feld- und Satzprüfung, d.h. bei Fehlern der Schwere 2 mit Schwere 0 fortfahren, also Wert akzeptieren. Kann präventiv angegeben werden, d.h. Nachfragen werden gar nicht gestellt sondern dürfen automatisch als bestätigt angesehen werden. Oder /T kann zur Wiederholung einer Satzübertragung verwendet werden wenn die Übertragung zuvor eine Nachfrage ergeben hat und diese positiv bestätigt werden soll.
E ENDE Bei satzweisen Übertragung nicht erlaubt.
S SICHER Bei satzweisen Übertragung ist /S analog zu /T.
A ABBRUCH Bei satzweisen Übertragung ohne Wirkung.
P PANIK sofortiger Verbindungsabbruch
O NOOP Keine Aktivität, weitere Datenelemente in Befehlszeile werden ignoriert, setzt Timeout-Zähler wieder zurück
U<z> UNTERST. Unterstützung bei komplexen Ändern von Daten mit fachlicher Historisierung (wie Betriebsdaten) oder Intervallsemantik (wie Zahlungsansprüche) mit Level z = 1 bis 6, Details siehe "Intelligentes Update"

Sub-Codes bei blockweiser Übertagung

Blöcke werden als Transaktion verarbeitet. Normalerweise erfolgt am Blockende ein COMMIT, d.h. die Änderungen werden in der Zentralen Datenbank festschrieben. Außer ein Systemfehler erzwingt Abbruch, dann erfolgt ein ROLLBACK, d.h. alle Änderungen des Blocks werden widerrufen.

Durch Angabe der Sub-Codes K oder L im letzten Befehl des Blocks kann dieses Standardverhalten geändert und der Transaktionsabschluss gesteuert werden.

Token Definition Bemerkung
T,P,O analog oben analog zum Satzmodus
K[Schwere|Pausi]

(mehrfache Verwendung möglich z.B. XS/K1023;K1024;K3)
COMMIT

Sub-Code K ohne Angabe von Schwere oder Plausi führt zu unbedingten Commit. Bei Angabe von Schwere oder Plausi (i.d.R. dann Mehrfachangabe sinnvoll) führt zu Commit wenn diese Schwere oder Plausis im Block gegeben andernfalls zum Rollback!

L[Schwere|Pausi]
(mehrfache Verwendung)
ROLLBACK Sub-Code L ohne Angabe von Schwere oder Plausi führt zu unbedingten Rollback. Bei Angabe von Schwere oder Plausi (i.d.R. dann Mehrfachangabe sinnvoll) führt zu Rollback wenn diese Schwere oder Plausis im Block gegeben andernfalls zum Commit!

Bei gemischter Angabe von K- und L-Sub-Codes ist die genaue Vorgehensweise noch offen, wahrscheinlich werden die Bedingungen der Reihe nach abgearbeitet bis eine passt. Wenn keine passt bestimmt die letzte das Verhalten des "andernfalls..."

Sub-Codes (speziell für Aktion RETRIEVE), siehe HIT-QL

Token Definition Bemerkung
M MODIFIED Nach Erzeugen der Abfrage, wird in einer System-Protokoll-Tabelle überprüft, ob und wann der angemeldete Betrieb diese Abfrage das letzte mal ausgeführt hat. Wenn die Entität Timestamp-Abfragen unterstützt erhält werden nur Datensätze deren Änderungs-Zeitstempel neuer als der Zeitpunkt der letzten Ausführung ist zurückgegeben.
D DELTA Wie /M , aber anschließend wird der aktuelle Ausführungszeitpunkt in der Protokolltabelle gespeichert.
I INCLUSIVE Normalerweise werden bei Tabellen, die Historisierung unterstützen, nur aktuelle Sätze angezeigt (BIS-Timestamp offen, bzw. 31.12.2100). Mit dem Subcode I erhält man alle Sätze, inklusive der Stornierten.
Z<TS> TIMESTAMP Zeitpunktabfrage mit Angabe eines Timestamps i.d.F. T.M.J/H.N[.S[.X]] (siehe Timestamp-Format ) zur Abfrage von Werten die genau zu diesem Wissensstand (also dem technischen Zeitpunkt) aktuell und gültig waren. Im Data-Dictionary sind die betrachteten Feldnamen in "FELDVON" / "FELDBIS" angegeben.
F[TS] TIMESTAMP fachliche Zeitpunktabfrage aktuell oder Angabe eines Timestamps i.d.F. T.M.J/H.N[.S[.X]] zur Abfrage von Werten die aktuell jetzt oder zu dem gegebenen Zeitpunkt fachlich aktuell. Wir nur von Entitäten/Meldungen mit fachlichen Gültigkeitszeitpunkten unterstützt, z.B. Betriebsstammdaten BTR_D mit DBET_VON/DBET_BIS. Im Data-Dictionary sind die betrachteten Feldnamen in "FELDVON2" / "FELDBIS2" angegeben.
T, S, N, H ... weitere Subcodes siehe Erläuterungen zu HIT-QL

Hinweise zu Sub-Codes

Die Sub-Codes /T und /S können

bulletzur Bestätigung der zuvor übermittelten Daten dienen nachdem der HIT-Server einen Fehler der Schwere 2 gemeldet hat und zur Bestätigung oder Korrektur aufgefordert hat
bulletoder sie können präventiv verwendet werden, d.h. daß die Daten im aktuellen Befehl oder Meldung keiner Bestätigungsabfrage für Fehler der Schwere 2 bedürfen und stattdessen Schwere 0 als OK geantwortet wird.
bulletWenn /T oder /S angegeben sind, wird kein Hinweis mehr ausgegeben und Schwere ist 0, d.h. OK

Beispiel

C:  *1:XF/T:LOGON/BNR15:276091234567890            
C:  *87:IS:ABGANG/LOM;BNR15;ABGA_DAT:276123456789012;091234567890;01.04.1999            
C:  *88:IS::276111156789012;091234567890;01.05.1999            
C:  +89+1:IB:ABGANG/LOM;BNR15;ABGA_DAT:276123456789012;091234567890;01.04.1999
C:  +89+2:::276123456789012;091234567890;01.04.1999
C:    ...
C:  *89+413:::276123456789012;091234567890;01.04.1999            

Antwortaufbau

Eine Antwort wird vom HIT-Server generiert und bezieht sich, über die Befehlsnummer erkennbar, auf den letzten vom HIT-Client gesendeten Befehl.

Eine Antwort kann aus einer oder mehreren Teilantworten bestehen. Jede Teilantwort ist eine eigene Zeile. Wenn weitere Teilantworten folgen ist die Zeile mit dem Antwortkennzeichen "%" zu beginnen, beim letzten Antwortteil oder wenn die Antwort nur aus einem Teil besteht ist die Zeile mit dem Antwortkennzeichen "=" zu beginnen.

Eine Antwort resultiert aus den Ergebnissen von Plausibilitätsprüfungen der Datenelemente und Meldungen oder als positive Bestätigung wenn ein Befehl erfolgreich ausgeführt wurde.

Syntax und Bestandteile

Token Definition Bemerkung
<Antwort> <Einleitung>:<Result>:<Objekt>:<Textliste> 4 Haupt-Elemente, mit Doppelpunkt getrennt
<Einleitung> <Antwort-Kenner><Befehls-Nummer>[%<Antwort-Teilnr>] Achte auf Trennung  der Antwort-Teilnr durch '%'
<Antwort-Kenner> = (Gleichheitszeichen)  |  % (Prozent) kennzeichnet Antwortbeginn, % wenn weitere Antwortteile folgen, = beim letzten oder einzigen Antwortteil
<Befehls-Nummer> <Haupt-Nummer>[+<Unter-Nummer>][#<Rowkeys>] Achte auf Trennung  der Befehls-Unternummer durch '+'
<Haupt-Nummer> Nummer des Befehl auf den geantwortet wird dient zur richtigen Zuordnung des Ergebnisses
<Unter-Nummer> Fortlaufende Nummer des Teilbefehls wenn der Befehl aus mehreren Zeilen besteht und direkt auf Teilbefehl geantwortet wird
<Rowkeys> <Rowkey>[;<Rowkeys>] Liste von benutzerdefinierten Keys, die aus dem Befehl in die Antwort übernommen werden
<Rowkey> benutzerdefinierten Key (String-Konstante) dient zur Identifikation des Befehls
<Antwort-Teilnr> Fortlaufende Nummer der Teilantwort, wenn die Antwort aus mehreren Zeilen besteht dient zur Sicherung der Reihenfolge und Vollständigkeit wenn Teilantworten vorliegen, beginnt bei 1 für jede Antwort
<Result> <Schwere>/<Antwort-Code>  
<Schwere> 0 | 1 | 2 | 3 | 4 | -1 | -2 | -3 Return-Wert: 0 (=OK) | 1 (=Hinweis) | 2 (=Nachfrage) | 3 (=Fehler) | 4 (=sofortiger Abbruch) | -1 (=Datensätze als Antwort auf Retrieve) | -2 und -3 (Datensätze bei komplexeren Funktionen)
<Antwort-Code> Nummer der Fehlermeldung (Plausi) laut Texttabelle siehe Fehler-Tabelle: PLAUSI
<Objekt> [<Meldung>][/<Feldliste>] Auf welche Meldungsart und ggf. welche Felder sich Antwort bezieht
<Meldung> LOGON | BETRD | GEBURT |  .... Meldungsart des Befehls
<Feldliste> <Feldname>[;<Feldliste>] | * (Stern) ein Feld oder mit Semikolon getrennt mehrere Felder, Stern bedeutet: Antwort bezieht sich auf Meldung und nicht auf Feld
<Feldname> BNR15 | PIN | ... komplette Liste je nach Meldung, siehe Meldungselemente
<Textliste> <Textelement>[;<Textliste>] der Textteil besteht i.d.R. nur aus einem Textelement, bei Datenübertragung mehrere Elemente durch Semikolon getrennt
<Textelement> Text der Antwort aus Tabelle, ggf. etwas detaillierter

Schematische Darstellung

=<Nr>:<Schwere>/<Antwort-Code>:<Meldung>/<Feldliste>:<Textliste>            
%<Nr>:<Schwere-1>/<Antwort-Code-1>:<Meldung>/<Feldliste>:<Text-1>
%...
=<Nr>:<Schwere-N>/<Antwort-Code-N>:<Meldung>/<Feldliste>:<Text-N>            

Beispiele

Einfache Antwort, Kurzform

S:  =87:0/0::            

Einfache Antwort, Langform

S:  =117:1/1013:LOGON/PIN:Hinweis - PIN von Erstinstallation, bitte bald ändern            

Antwort mit 2 Teilen auf einen Befehl

S:  %87%1:1/1002:ABGANG/*:Abgang vor Zugang
S:  =87%2:1/1003:ABGANG/*:Abgang 10 Tage verspätet            

Antwort mit 2 und 1 Teilen auf Befehl mit 9 Unterbefehlen

S:  %87+1%1:1/1002:ABGANG/*:Abgang vor Zugang
S:  %87+1%2:1/1003:ABGANG/*:Abgang 10 Tage verspätet
S:  =87+9:1/1003:ABGANG/*:Abgang 10 Tage verspätet            

Besondere Hinweise

Mehrere Antwortteile

Die Plausibilitätsprüfung eines einzelnen Feldes oder einer gesamten Meldung kann zu mehreren Antwortteilen führen, denn Hinweise (Schwere 1) und Fehler der Schwere 2 führen nicht zum Abbruch der Feldprüfung, d.h. die restlichen Prüfungen für das Feld werden fortgesetzt. Fehler der Schwere 3 dagegen brechen die Prüfung des Feldes ab und Fehler der Schwere 4 brechen sogar den gesamten Prüfprozess und die Dialogsitzung ab.

Beim Befehl zum Beenden und Speichern einer feldweise übertragenen Meldung ("*nr:IF/E::") werden weitere Plausibilitätsprüfungen für die Meldung als ganzes (Querchecks) durchgeführt. Auch diese werden erst bei einem Fehler der Schwere 3 abgebrochen, d.h. es können mehrere Antwortteile mit Schwere 1 und Schwere 2 sowie maximal ein Antwortteil mit Schwere 3 oder 4 entstehen.

Bei der satzweisen Übertragung werden alle Felder nacheinander geprüft, bricht die Prüfung eines einzelnen Feldes mit Schwere 3 ab, werden dennoch die Prüfungen aller anderen Felder weiter durchgeführt. Somit können in beliebiger Reihenfolge mehrere Antwortteile mit Schwere 1 , 2 oder 3 sowie maximal ein Antwortteil mit Schwere 4 entstehen.

Bei der satzweisen Übertragung werden diese Querchecks nach den Prüfungen aller Einzelfelder durchgeführt wenn diese Feldprüfungen Antworten maximal bis zu Schwere 2 erzeugt haben. Bei max. Schwere 3 werden die Querchecks nicht mehr durchgeführt. Bei max. Schwere 2 werden die Querchecks zwar durchgeführt um ggf. noch weitere Hinweise oder Nachfragen für die Gesamt-Meldung zu erzeugen, ein Abspeicher erfolgt aber nicht ! Sinn dieser Vorgehensweise ist, dass alle Fehler der Schwere 2 die nach Bestätigung durch den Client akzeptiert werden könnten gemeinsam und nur einmal bestätigt werden müssen, ein /T (=TROTZDEM, FORCE) für einzelne Feld ist bei der satzweisen Meldung nicht möglich. Stattdessen muß der Client bei max. Schwere 2 den ganzen Satz mit /S (=SICHER) bestätigen oder mit /A (=ABBRUCH) verwerfen.

Der HIT-Client muß aus allen Antwortteilen die maximale Schwere ermitteln und daraus erkennen ob die Meldung nun tatsächlich gespeichert wurde (maximale Schwere 1) oder nicht (Schwere 2,3,4)

Positive Antwort: Schwere 0

Antworten der Schwere 0, d.h. dass ein bestimmter Befehl fehlerfrei ist, z.B. die Übertragung eines einzelnen Feldes oder die Abspeicherung des Satzes werden nicht mehr genauer spezifiziert. Der Antwortcode ist immer 0, Objekt- und Textteil sind leer, Beispiel: "=<nr>:0/0::" .

Bei satzweisen Übertragung werden zwar alle Felder nachinander geprüft und ggf. mehrere Hinweise und Fehlerantworten ausgegeben, aber fehlerfreie Felder werden nicht einzeln mit Antwortsätzen der Schwere 0 bestätigt.

Befehls - Antwort Abfolge

Feldweise Übertragung

F/A - Einleitung der Übertragung

Client Befehl mit Einleitung der feldweisen Übertragung und dem 1. Datenelement
C:  *87:IF:ABGANG/LOM:276123456789012                              
Server Bereitstellen bzw. leeren der Datenstruktur , prüfen und annehmen oder ablehnen des 1. Datenelements.
Fortsetzung je nach Prüfungsergebnis mit F/B/0 , F/B/1 , F/B/2 , F/B/3 oder F/B/4

F/B/0 - Fortsetzung der Übertragung, wenn Feld OK

Server Antworten mit OK-Meldung, der Wert wird akzeptiert
S:  =87:0/0::                              
Client Befehl mit Fortsetzung der feldweisen Übertragung und dem nächsten Datenelement  (die Meldungsart darf fehlen, der Schrägstrich muß angegeben werden) oder Beenden siehe F/C
C:  *88:IF:/BNR15:091234567890                              
Server prüfen und annehmen oder ablehnen des nächsten Datenelements.
Fortsetzung je nach Prüfungsergebnis mit F/B/0 , F/B/1 , F/B/2 , F/B/3 oder F/B/4

F/B/1 - Fortsetzung der Übertragung, wenn Feld mit Hinweis

Server Antworten mit Hinweis, aber der Wert wird akzeptiert
S:  =87:1/2234:ABGANG/LOM:Alte LOM-Serie, bitte nicht weiter verwenden                              
Client Fehlerhinweis sollte dem Benutzer ohne weiteren Interaktionsbedarf einfach mitgeteilt werden. Befehl mit Fortsetzung der feldweisen Übertragung und dem nächsten Datenelement (die Meldungsart darf fehlen, der Schrägstrich muß angegeben werden) oder Beenden siehe F/C
C:  *88:IF:/BNR15:091234567890                              
Server prüfen und annehmen oder ablehnen des nächsten Datenelements.
Fortsetzung je nach Prüfungsergebnis mit F/B/0 , F/B/1 , F/B/2 , F/B/3 oder F/B/4

F/B/2 - Wiederholen oder korrigieren, wenn Nachfrage

Server Antworten mit Nachfrage, der Wert wird noch nicht akzeptiert
S:  =87:2/2234:ABGANG/LOM:Alte LOM-Serie, wirklich verwendet?                              
Client Fehlerhinweis sollte dem Benutzer mit Bestätigungsabfrage mitgeteilt werden. Je nach Benutzerverhalten weiter mit F/B/2a , F/B/2b oder F/C
F/B/2a - Wenn der Benutzer den Wert unverändert bestätigt
Client Befehl mit neuer Nr mit Wiederholung des beanstandeten Datenelement aber Sub-Code T (=Trotzdem)
C:  *88:IF/T:ABGANG/LOM:276123456789012                              
Server prüfen und annehmen oder ablehnen des nächsten Datenelements (durch den Sub-Code T wird jetzt aber auch bei Fehlern der Schwere 2 mit Schwere 0 fortgefahren, d.h. der Wert akzeptiert !). Fortsetzung je nach Prüfungsergebnis mit F/B/0 , F/B/1 , (nicht F/B/2) , F/B/3 oder F/B/4
F/B/2b - Wenn der Benutzer den Wert korrigiert
Client Befehl mit neuer Nr und neuem Wert für beanstandetes Datenelement
C:  *88:IF:ABGANG/LOM:276111111119012                              
Server prüfen und annehmen oder ablehnen des nächsten Datenelements. Fortsetzung je nach Prüfungsergebnis mit F/B/0 , F/B/1 , F/B/2 , F/B/3 oder F/B/4

F/B/3 - Korrigieren, wenn nicht akzeptierbarer Fehler

Server Antworten mit Fehler, der Wert wird nicht akzeptiert
S:  =87:3/2234:ABGANG/LOM:LOM nicht an Betrieb gegeben,korrigieren..                              
Client Fehlermeldung wird an Benutzer ausgegeben und er wird zum Wiederholen bzw. Korrigieren des Wertes
aufgefordert. Befehl mit neuer Nr und neuem Wert für beanstandetes Datenelement oder Beenden siehe F/C
C:  *88:IF:ABGANG/LOM:276111111119012                              
Server prüfen und annehmen oder ablehnen des nächsten Datenelements. Fortsetzung je nach Prüfungsergebnis mit F/B/0 , F/B/1 , F/B/2 , F/B/3 oder F/B/4

F/B/4 - Abbrechen der Verbindung, wenn kritischer Fehler

Server Antworten mit Fehler und Meldung über Sitzungsende
S:  =87:4/2299:ABGANG/LOM:LOM gestohlen, Verbindung beendet
S:  <DISCONNECT>                              
Client Fehlermeldung wird an Benutzer ausgegeben und er wird aufgefordert sich an die zuständige RS zu wenden. Weitere Befehle werden mit <CONNECTION NOT AVAILABLE> abgelehnt

F/C - Ende mit Speichern oder Abbruch der Meldung

Client Befehl mit neuer Nr und entsprechendem Sub-Code (/E , /S, /A oder /P) ohne Datenfeld bedeutet: Aktuelle feldweise Eingabe beenden (Meldungsart ist überflüssig)

oder

oder
oder

C:  *88:IF/E::	(ENDE, mit Speichern zurück in Ready-Status)
C:  *88:IF/S::	(SICHER, mit Speichern, Schwere 2 akzeptieren)                              
C:  *88:IF/A::	(ABBRUCH, ohne Speichern zurück in Ready-Status)
C:  *88:IF/P::	(PANIK, ohne Speichern Verbindung unterbrechen)                              
Server prüfen des gesamten Datensatzes und speichern oder ablehnen der Meldung. Fortsetzung je nach Prüfungsergebnis mit F/D/0 , F/D/1 , F/D/2 , F/D/3 oder F/D/4

F/D/0 - Status Ready, wenn Meldung OK

Server Antworten mit OK-Meldung, die Meldung wird gespeichert
S:  =88:0/0::                              
Client Neue Übertragung siehe F/A oder LOGOFF

F/D/1 - Status Ready, wenn Meldung mit Hinweis

Server Antworten mit einem oder mehreren Hinweisen, aber die Meldung wird gespeichert
S:  %88%1:1/2234:ABGANG/*:Abgang gespeichert, Hinweis der _
		Käufer hat den Zugang bereits vor 10 gemeldet
S:  =88%2:1/2237:ABGANG/*:Abgang gespeichert, es liegen _
		mehrere Zugänge bei anderen Betrieben vor                              
Client Fehlerhinweis sollte dem Benutzer ohne weiteren Interaktionsbedarf einfach mitgeteilt werden. Neue Übertragung siehe A oder LOGOFF

F/D/2 - Wiederholen oder korrigieren, wenn Nachfrage

Server Antworten mit Nachfrage, die Meldung wird noch nicht gespeichert
S:  =88:2/2277:ABGANG/*:Abgang 2 Monate her, ist das OK ?                              
Client Fehlerhinweis sollte dem Benutzer mit Bestätigungsabfrage mitgeteilt werden.  Je nach Benutzerverhalten weiter mit F/D/2a , F/D/2b oder F/C
F/D/2a - Wenn der Benutzer die Meldung unverändert bestätigt
Client Befehl mit neuer Nr aber Befehls Sub-Code S (=Sicher, Force)
C:  *89:IF/S::                              
Server prüfen und annehmen oder ablehnen der Meldung (durch den Sub-Code S wird jetzt aber auch bei  bei Fehlern der Schwere 2 mit Schwere 0 fortgefahren, d.h. die Meldung akzeptiert). Fortsetzung je nach Prüfungsergebnis mit D/0 , D/1 , (nicht D/2) , D/3 oder D/4
F/D/2b - Wenn der Benutzer die Meldung korrigieren möchte
Client Im aktuellen Feld-Modus können einzelne Feldwerte korrigiert werden
C:  *89:IF:/LOM:276111144449012                              
Server prüfen und annehmen oder ablehnen des nächsten Datenelements, analog oben
oder            
Client Da aber i.d.R. nicht eindeutig ein Feld für die Ablehnung verantwortlich ist und bei der feldweiser Meldung Querbezüge schlecht korrigiert werden können muß die Meldung meist verworfen werden, d.h. mittels Abbruch-Sub-Code wird der Feld-Modus verlassen und zum Ready-Status zurückgekehrt.
C:  *89:IF/A::                              
Server gesamte Meldung wird verworfen und in Ready-Status von neuem begonnen

F/D/3 - Korrigieren, wenn nicht akzeptierbarer Fehler

Server Antworten mit Fehler, der Wert wird nicht akzeptiert
S:  =89:3/3299:ABGANG/*:Abgang über 1 Jahr her                              
Client analog zu D/2b

F/D/4 - Abbrechen der Verbindung, wenn kritischer Fehler

Server Antworten mit Fehler und Meldung über Sitzungsende
S:  =89:4/2299:ABGANG/*:Abgangsdatum läßt schweren Unterschleif _
		vermuten, das System bendet die Verbindung
S:  <DISCONNECT>                              
Client Fehlermeldung wird an Benutzer ausgegeben und er wird aufgefordert sich an die zuständige RS zu wenden. Weitere Befehle werden mit <CONNECTION NOT AVAILABLE> abgelehnt

Satzweise Übertragung

S/A - Einleitung der Übertragung

Client Befehl mit Einleitung der satzweisen Übertragung , d.h. Meldungsart und alle Datenelementen und allen Datenwerten der 1.Meldung
C:  *87:XS:ABGANG/LOM;BNR15;ABGA_DAT:27789012;0912890;01.04.1999                              
Server Bereitstellen bzw. leeren der Datenstruktur , prüfen und annehmen oder ablehnen aller Datenwerte und speichern der Meldung, Fortsetzung je nach Prüfungsergebnis mit S/B/0 , S/B/1 , S/B/2 , S/B/3 oder S/B/4

S/B/0 - Status Ready, wenn Meldung OK, weitere Meldungen der selben Art verkürzt möglich

Server Antworten mit OK-Meldung, die Meldung wird gespeichert, der Server geht wieder in den Ready-Status, merkt sich aber die Datenelemente der Meldung wenn eine weitere Meldung dieser Art folgt
S:  =87:0/0::                              
Client Fortsetzung mit Befehl zur satzweisen Übertragung der nächsten Meldung(Angabe der Meldungsart und Datenelemente ist optinal), oder sonstigen Aktionen im Ready-Modus
C:  *88:XS::276123456789012;0914444;07.06.1999                              
Server prüfen und annehmen oder ablehnen der nächsten Meldung, Fortsetzung je nach Prüfungsergebnis mit S/B/0 , S/B/1 , S/B/2 , S/B/3 oder S/B/4

S/B/1 - Status Ready, wenn Meldung mit Hinweis, weitere Meldungen der selben Art verkürzt möglich

Server Antworten mit einem oder mehreren Hinweisen, aber die Meldung wird gespeichert
S:  %87%1:1/2234:ABGANG/*:Der Käufer hat _
		den Zugang bereits vor 10 gemeldet
S:  =87%2:1/2237:ABGANG/*:Es liegen mehrere Zugänge _
		bei anderen Betrieben vor                              
Client Hinweise sollte dem Benutzer ohne weiteren Interaktionsbedarf einfach mitgeteilt werden. Fortsetzung mit Befehl zur satzweisen Übertragung und der nächsten Meldung, Fortsetzung analog zu S/B/0
C:  *88:XS::276123012;091234444;07.06.1999                              
Server prüfen und annehmen oder ablehnen der nächsten Meldung, Fortsetzung je nach Prüfungsergebnis mit S/B/0 , S/B/1 , S/B/2 , S/B/3 oder S/B/4

S/B/2 - Wiederholen oder korrigieren, wenn Nachfrage

Server Antworten mit Nachfrage, die Meldung wird noch nicht akzeptiert. Es können zusätzlich noch Hinweise der Schwere 1 existieren !
S:  =87:2/2277:ABGANG/*:Abgang 2 Monate her, sicher ?                              
Client Fehlerhinweis sollte dem Benutzer mit Bestätigungsabfrage mitgeteilt werden. Je nach Benutzerverhalten weiter mit S/B/2a , S/B/2b oder S/C
S/B/2a - Wenn der Benutzer die Meldung unverändert bestätigt
Client Befehl mit neuer Nr aber Befehls Sub-Code S (=Sicher, Force), alle Daten müssen wiederholt werden.
C:  *88:IS/S::2761289012;091267890;01.04.1999                              
Server prüfen und annehmen oder ablehnen der gesamten Meldung
S/B/2b - Wenn der Benutzer die Meldung korrigieren möchte
Client Befehl mit neuer Nr und neuen Datenwerten analog zu einer neuen Meldung senden
C:  *88:XS::2761239012;09124444;07.05.1999                              
Server prüfen und annehmen oder ablehnen der gesamten Meldung

S/B/3 - Korrigieren, wenn nicht akzeptierbarer Fehler

Server Antworten mit Fehler, die Meldung wird akzeptiert. Es können zusätzlich noch Hinweise der Schwere 1 existieren !
S:  =87:3/3299:ABGANG/*:Abgang 1 Jahr her, korrigieren                              
Client Fehlermeldung mitteilen, Befehl mit neuer Nr und neuen Datenwerten analog zu einer neuen Meldung senden

S/B/4 - Abbrechen der Verbindung, wenn kritischer Fehler

Server Antworten mit Fehler, die Meldung wird akzeptiert. Es können zusätzlich noch Hinweise der Schwere 1 existieren !
S:  =87:4/2299:ABGANG/*:Abgangsdatum läßt schweren Unterschleif _
		 vermuten,das System bendet die Verbindung
S:  <DISCONNECT>                              
Client Fehlermeldung wird an Benutzer ausgegeben und er wird aufgefordert sich an die zuständige RS zu wenden. Weitere Befehle werden mit <CONNECTION NOT AVAILABLE> abgelehnt

Blockweise Übertragung

B/A - Übertragung von mehreren Aktionen als Befehl mit Unterbefehlen

Client Befehl mit mehreren Teilen zur blockweisen Übertragung. In den einzelnen Befehlsteilen kann anlalog zur satzweisen Übertragung ein identischer Objektteil weggelassen werden.
C:  +87+1:XB:ABGANG/LOM;BNR15;ABGA_DAT:27789012;0912890;01.04.1999
C:  +87+2:XB::27789014;0923456;31.01.1999
C:  +87+3:XB::27789017;0911111;11.11.1999
C:  *87+4:XB:ZUGANG/LOM;BNR15;ZUGA_DAT:27789012;0888888;01.04.1999                              
Server Prüfen und annehmen oder ablehnen aller Datenwerte und speichern der Meldung. Ablauf je nach schwerstem Fehler im Block mit B/B/0 , B/B/1. Alle Aktionen laufen innerhalb einer einzigen Datenbank-Transaktion, d.h. alle Aktionen werden erst am Ende des Blocks tatsächlich weggeschrieben ("COMMIT") oder bei schwerem Fehler verworfen ("ROLLBACK").

B/B/0 - Alle Teilbefehle werden abgearbeitet

Server Alle Teilbefehle werden gelesen und zwischengespeichert. Anschließend werden alle Teilbefehle analog zur satzweisen Vorgehensweise abgearbeitet. Für jeden Teilbefehl kann es 0, 1 oder mehrere Antworten geben. Es wird auf den jeweiligen Befehl/Unterbefehl Bezug genommen. Da in diesem Beispiel der maximale Schwere-Code < 4 (Panik) ist, werden die einzelnen Meldungen (Teilbefehle) mit maximaler Antwortschwere 1 in die Datenbank gespeichert. Sätze mit Schwere 2 oder 3 sind fehlerhaft und werden nicht gespeichert. Wenn präventiv mit Forcs "XB/S" gesendet wird werden alle Fehler der Schwere 2 unterdrückt und die betroffenen Sätze werden ohne Fehlermeldungsausgabe akzeptiert. Am Ende der Übertragung erfolgt ein "COMMIT".
S:   %87+2:3/3299:ABGANG/*:Abgang 1 Jahr her, korrigieren
S:   %87+2%1:1/234:ABGANG/ABGA_DAT:Meldefrist überschritten
S:   %87+2%2:1/333:ABGANG/*:Hinweis ...

B/B/1 - Wegen schwerer Fehler "Panik" wird Verarbeitung abgebrochen

Server Alle Teilbefehle werden gelesen und zwischengespeichert. Da in diesem Beispiel der maximale Schwere-Code = 4 (Panik) ist wird die Übertragung abgebrochen und derzeitig ein "ROLLBACK" ausgeführt, d.h. alle Sätze dieses Blocks werden unabhängig von der schon übermittelten Schwere des Teilbefehls verworfen.
S:   %87+2:3/3299:ABGANG/*:Abgang 1 Jahr her, korrigieren
S:   %87+2%1:1/234:ABGANG/ABGA_DAT:Meldefrist überschritten
S:   %87+2%2:4/1000:SYSTEM/*:Datenbank z.Zt. nicht verfügbar

Weitere Beispiele

Fehlerhafte Befehle

C:  *1:AF:LOGON:27609123456789
S:  =1:3/3001:LOGON/*:Syntax - Falscher Befehl	// Nicht akzeptierbarer Fehler            
C:  *1:XF:LOGON:27609123456789
S:  =1:3/3002:LOGON/*:Syntax - Feld feht            

Logon feldweise

C:  *1:XF:LOGON/BNR15:27609123456789		// feldweises Logon mit 1.Feld
S:  =1:3/1001:LOGON/BNR15:NR nicht vorhanden	// Antwort:  Fehler ..
C:  *2:XF:LOGON/BNR15:276099100010001
S:  =2:0/0::
C:  *3:XF:/PIN:123				// Meldung darf fehlen
S:  =3:1/104:LOGON/PIN:Nur 3 Stellen riskant	// OK aber Hinweis
C:  *4:XF/E::					// Ende der feldweisen Meldung
S:  =4:0/123:LOGON/*:Anmeldung ausgeführt	// Antwort 0/1 als Schwere            
oder - bei Nachfrage in Feld            
C:  *3:XF:/PIN:123456				// Meldung darf fehlen
S:  =3:2/105:LOGON/PIN:Noch Start-PIN,sicher ?	// Nachfrage
C:  *4:XF/T:/PIN:123456				// Wert mit FORCE erneut senden
S:  =4:0/0::
C:  *5:XF/E::					// Ende der feldweisen Meldung
S:  =5:0/123:LOGON/*:Anmeldung ausgeführt	// Antwort 0/1 als Schwere            

Logon satzweise

C:  *1:XS:LOGON/BNR15;PIN:123456789;123456	// satzweises LOGON mit Daten
S:  =1:3/1001:LOGON/BNR15:Nr nicht vorhanden	// Antwort:  Fehler ..
C:  *2:XS:LOGON/BNR15;PIN:9100010001;123456
S:  =2:0/0::            

Logoff satzweise

Spezialfall der satzweisen Übertragung, keine Datenfelder nötig

C:  *89:XS:LOGOFF:  				// Client LOGOFF
S:  =89:0/999:LOGOFF/*:Abmeldung OK  		// Server akzeptiert LOGOFF
						// geht in Status NOT-AUTH
						// bleibt aber connected            

Abgänge satzweise

C:  *87:XS:ABGANG/LOM;BNR15;ABGA_DAT:2761234012;091234890;01.04.1999
S:  =87:0/100:ABGANG/*:ABGANG OK            
C:  *88:XS::276123456789012;091234567890;01.04.1999
S:  %88%1:1/1235:ABGANG/LOM:Tier ist beim Abgang erst 1 Tag alt
S:  =88%2:1/1456:ABGANG/*:Weitere Hinweise zum Abgang ...            
C:  *89:XS::276123456789012;091234567890;01.04.1999
S:  =89:2/2123:ABGANG/ABGA_DAT:Abgangsdatum gleich Geburtsdatum, sicher?
C:  *90:XS/S::276123456789012;091234567890;01.04.1999
S:  =90:0/0::            

Abgänge blockweise

C:  +87+1:XB:ABGANG/LOM;BNR15;ABGA_DAT:27789012;0912890;01.04.1999
C:  +87+2:XB::27789014;0923456;31.01.1999
C:  +87+3:XB::27789017;0911111;11.11.1999
C:  *87+4:XB:ZUGANG/LOM;BNR15;ZUGA_DAT:27789012;0888888;01.04.1999
S:  %87+2:3/3299:ABGANG/*:Abgang 1 Jahr her, korrigieren
S:  %87+2%1:1/234:ABGANG/ABGA_DAT:Meldefrist überschritten
S:  %87+2%2:1/333:ABGANG/*:Hinweis ...            

Parameter-Liste

siehe auch HIT-Meldungen

Token Definition Format Default Bemerkung
VERBOSE Geschwätzig 0 oder 1 1 Ausgabe von mehr Information im HITP
TIMEOUT Timeout INT 4 120 Nach wievielen Sekunden Inaktivität Verbindung unterbrochen wird
VERSIONC Version Client INT 4 1 Version des HITP-Clients
ILAND ISO-Land INT 3 276 ISO-Länderschlüssel, für Ergänzung von BNR15
BLAND Bundesland INT 2 0 Bundesland-Schlüssel, für Ergänzung von BNR15

Quoted-Hex

Sonderzeichen, insbesondere die Befehls- und Antwort-Trennzeichen ':' (Doppelpunkt) und ';' (Semikolon) sowie der Quoting-Charakter '%' (Prozent) sind analog zur Kodierung im HTTP-Protokoll als quoted-hex umzusetzen. Die Hex-Codierung des jeweiligen Zeichens ist der Codetabelle ISO 8859-1 zu entnehmen. Im Folgenden werden die wichtigsten Zeichen aufgelistet. Die Substitution ist nur auf die einzelnen Befehls- und Antwort-Token anzuwenden, d.h. die Befehls-  ('+' und '*') und Antwortkenner ('%' und '=') sowie die Tokentrenner  (':' und ';') selbst werden nicht umgesetzt.

Zeichen die umgesetzt werden müssen

Zeichen Bedeutung Quoted-Hex Darstellung
% Prozent %25
; Semikoln %3B
: Doppelpunkt %3A
<CR> Wagenrücklauf %0D
<LF> Zeilenvorschub %0A

Zeichen die umgesetzt werden können (Umlaute, Sonderzeichen)

Zeichen Quoted-Hex Darstellung
ä %e4
ö %f6
ü %fc
ß %df
Ä %c4
Ö %d6
Ü %dc
= %3D
? %3F
° %b0
§ %a7
& %26
/ %2F
( %28
) %29
+ %2B

Zeichen die nicht umgesetzt werden müssen

Zeichen Bedeutung
, Komma
. Punkt
- Bindestrich
_ Unterstrich

Übermittlung von NULL-Values

Quoted-Hex Darstellung Bedeutung
%-- NULL-Value

Erklärung: Es gibt Datenfelder, die optional sind, d.h. keine Werte enthalten müssen, aber falls sie vorhanden sind keinen Leerstring enthalten düfen (NULLABLE = TRUE and EMPTY = FALSE). Bei der feldweisen Übertragung kann das Feld einfach nicht übertragen werden. Bei der satzweisen oder blockweisen Übertragung wenn einzelne Sätze (z.B. LKV-Betriebe) Werte übertragen sollen andere aber Sätze keinen Wert für dieses Feld haben und eine Plausiprüfung einen Leertring nicht zulassen würde, kann das fehlen des Wertes, sprich der NULL-Value mittels Angabe von "%--" übertragen werden. Weitere Hinweise siehe Darlegung der NULL-Semantik (Hier erfolgt ggf. noch eine Änderung ??)

Was wird umgesetzt

Von der Umsetzung betroffen sind alle Datenelemente in der Datenliste eines Befehls und alle Textelemente im Textteil einer Antwort. Jedes Element wird einzeln behandelt und kann daher auch individuelle NULL-Werte oder Separatoren als Inhalt transportieren.

Wann wird umgesetzt

Beim Bilden der Datenliste eines Befehls, aus externen Quellen wie Benutzereingaben oder Input-Dateien, wird jedes Datenelement separat mit "QuoteHex" umgesetzt und durch Semikolon getrennt in der Liste angehängt.

Bei Empfangen eines Befehls wird jedes Datenelement separat mit "UnquoteHex" wieder zurück in den Originalwert oder einen NULL-Value umgesetzt, vor es dann in der Datenabnk gespeichert wird.

Beim Verpacken der Textelemente des Textteils in der Antwortstruktur wird ebenfalls mit "QuoteHex" umgesetzt, so dass auch die Sonderzeichen transportiert werden können. Insbesondere beim Ausgeben von Datenabfragen wird im Textteil der Antwort jeder Datenwert als eigenes Textelement behandelt und separat "hex-quoted".

Erst wenn die Antwort wieder in die Einzelbestandteile getrennt werden soll erfolgt die Rückumsetzung mit "UnquoteHex". Wenn die Antwort insgesamt weiterübermittelt wird, wie z.B. beim HIT-Batchclient in der LOG-Datei darf noch nicht zurückumgesetzt werden, da der Empfänger sonst beim Parsen des Antwortstrings Probleme hat.

NULL-Semantik

Bei der Ausgabe von Werten im HIT-Protokoll werden NULL-Values, d.h. Feldern in denen in der Datenbank nichts gespeichert ist als Quoted-Hex Darstellung "%--" ausgegeben. Bei alle Textstrings werden rechts alle nachfolgenden Leerzeichen ("trailing blanks") abgeschnitten, so daß eine Stringvariable, die nicht NULL ist aber nur Blanks enthält, als leerer String, also i.d.R. ";;" dargestellt wird. (Hier erfolgt ggf. noch eine Änderung ??)

Beim Senden von Daten im HIT-Protokoll ist nach der restriktiven HIT-CSV Festlegung vorzugehen. Einzelheiten siehe Klarstellungen zum CSV-Format

NULL vs. Leerstring

Wie Stringsvariablen ohne Inhalt nun tatsächlich zu behandeln sind, als Leerstring oder NULL, wird separat festgelegt, siehe NULL/Leerstring.

Semantische Feinheiten

Folgende Anmerkungen sind besondere Feinheiten und i.d.R. nicht von Bedeutung. Bei der Entwicklung eigener HIT-Clients können sie aber zur Klarstellung dienen.

  1. Da nach dem letzten Element einer CSV-Auflistung kein Separator folgt, ist eine CSV-Auflistung ohne Elemente nicht von einer Auflistung mit einem Leerstring zu unterscheiden => es gibt keine Auflistung ohne Elemente.
  2. Der Befehl RETRIEVE mit einem einzelnen leeren Element in der Datenliste "*n:RS:<entity>/*:" wird akzeptiert.
  3. Da die Anzahl der Feldelemente gleich der Anzahl der Datenelemente sein muss (außer bei RETRIEVE), gibt es keine Entität ohne Elemente. Die Entität LOGOFF wird mit "*n:XS:LOGOFF:" ausgeführt, dabei wird intern ein Dummy-Feld mit leerem Feldnamen und ein leeres Datenelement angenommen.
  4. Wenn in aufeinander folgenden Meldungen die Objekt-Teile (Meldung/Feldliste) identisch sind, können sie entfallen um Daten auf der Leitung zu sparen. Der Server benutzt dann automatisch die letzte Objekt-Liste erneut, z.B:
    1. Meldung "*n:RS:ABGANG/LOM;BNR15;ABGA_DAT:27600..;27609..;1.1.99".
    2. Meldung "*n:RS::27600..;27609..;2.2.99".
  5. Eine Verkürzung des Objektteils auf nur die Meldung ohne Schrägstrich ist genauso zulässig und eindeutig, z.B:"*n:RS:ABGANG:27600..;27609..;3.3.99".
  6. Nur Meldungsteil und Schrägstrich, z.B. "*n:RS:ABGANG/:27600..;27609..;4.4.99" heißt eigentlich Feldliste hat ein leeres Element und sollte daher nicht verwendet werden.
 
© 1999-2011 Bay.StMELF, Verantwortlich für Fachfragen: Dr. E.Keller mailto:Ellen.Keller@HI-Tier.de, Technik: H. Hartmann mailto:Helmut.Hartmann@HI-Tier.de
Seite zuletzt bearbeitet: 22. August 2013 11:07, Anbieterinformation siehe hier im Impressum.