HBCICallback (hbci4j-adorsys 3.3.6 API)

All Known Implementing Classes:

AbstractHBCICallback, HBCICallbackConsole, HBCICallbackIOStreams
```
public interface HBCICallback
```
Schnittstelle, die eine Callback-Klasse implementieren muss. Beim Initialisieren von HBCI4Java muss ein Callback-Objekt angegeben werden. Die Klasse dieses Objektes muss die HBCICallback-Schnittstelle implementieren. Der HBCI-Kernel ruft in bestimmten Situationen Methoden dieser Klasse auf. Das ist z.B. dann der Fall, wenn eine bestimmte Aktion (Einlegen der Chipkarte) oder Eingabe (Passwort) vom Anwender erwartet wird. AuÃerdem werden auf diesem Weg Informationen an den Anwender weitergegeben (Mitteilungen des Kreditinstitutes bei der Dialoginitialisierung).

Ein Anwendungsentwickler muss die Methoden dieser Schnittstelle also geeignet implementieren, um bei jeder möglichen Ursache für den Aufruf einer der Callback-Methoden sinnvoll zu reagieren. Dabei müssen nicht immer tatsächlich alle Anfragen an den Anwender weitergegeben werden. Ist z.B. das Passwort für die Schlüsseldatei eines Passports bereits bekannt, so kann die entsprechende Methode dieses Passwort direkt zurückgeben, ohne den Anwender erneut danach zu fragen.

Field Summary

Fields
Modifier and Type	Field and Description
`static int`	`CLOSE_CONNECTION` Ursache des Callback-Aufrufes: die Netzwerk-Verbindung zum HBCI-Server wird nicht länger benötigt.
`static int`	`HAVE_CHIPCARD` Ursache des Callback-Aufrufes: Chipkarte wurde in Chipkartenterminal eingelegt.
`static int`	`HAVE_CRC_ERROR` Ursache des Callback-Aufrufes: Fehler beim Verifizieren einer Kontonummer mit Hilfe des jeweiligen Prüfzifferverfahrens.
`static int`	`HAVE_ERROR` Ursache des Callback-Aufrufes: Es ist ein Fehler aufgetreten, der auf Wunsch des Anwenders ignoriert werden kann.
`static int`	`HAVE_HARDPIN` Ursache des Callback-Aufrufes: PIN-Eingabe über Chipkartenterminal abgeschlossen.
`static int`	`HAVE_IBAN_ERROR` Ursache des Callbacks: beim Ãberprüfen einer IBAN ist ein Fehler aufgetreten.
`static int`	`HAVE_INST_MSG` Ursache des Callback-Aufrufes: Institutsnachricht erhalten.
`static int`	`NEED_BLZ` Ursache des Callback-Aufrufes: Bankleitzahl der Bank benötigt.
`static int`	`NEED_CHIPCARD` Ursache des Callback-Aufrufes: Chipkarte benötigt (im Chipkartenterminal).
`static int`	`NEED_CONNECTION` Ursache des Callback-Aufrufes: es wird eine Netz-Verbindung zum HBCI-Server benötigt.
`static int`	`NEED_COUNTRY` Ursache des Callback-Aufrufes: Länderkennzeichen der Bankverbindung benötigt.
`static int`	`NEED_CUSTOMERID` Ursache des Callback-Aufrufes: Kunden-ID für HBCI-Zugang benötigt.
`static int`	`NEED_HARDPIN` Ursache des Callback-Aufrufes: PIN-Eingabe am Chipkartenterminal erwartet.
`static int`	`NEED_HOST` Ursache des Callback-Aufrufes: Netzwerkadresse des HBCI-Servers benötigt.
`static int`	`NEED_INFOPOINT_ACK` Ursache des Callbacks: Kernel fragt um Erlaubnis, Daten an den InfoPoint-Server zu senden.
`static int`	`NEED_PASSPHRASE_LOAD` Ursache des Callback-Aufrufes: Passwort für das Einlesen der Schlüsseldatei benötigt.
`static int`	`NEED_PASSPHRASE_SAVE` Ursache des Callback-Aufrufes: Passwort für das Erzeugen der Schlüsseldatei benötigt.
`static int`	`NEED_PORT` Ursache des Callback-Aufrufes: TCP-Port, auf dem der HBCI-Server arbeitet (3000), benötigt.
`static int`	`NEED_PROXY_PASS` Ursache des Callbacks: es wird ein Passwort für die Authentifizierung am Proxy-Server benötigt.
`static int`	`NEED_PROXY_USER` Ursache des Callbacks: es wird ein Nutzername für die Authentifizierung am Proxy-Server benötigt.
`static int`	`NEED_PT_PHOTOTAN` Ursache des Callback-Aufrufes: eine Photo-TAN für PIN/TAN-Verfahren benötigt.
`static int`	`NEED_PT_PIN` Ursache des Callback-Aufrufes: PIN für PIN/TAN-Verfahren benötigt.
`static int`	`NEED_REMOVE_CHIPCARD` Ursache des Callback-Aufrufes: Chipkarte soll aus Chipkartenterminal entfernt werden.
`static int`	`NEED_SIZENTRY_SELECT` Ursache des Callback-Aufrufes: Auswahl eines Eintrages aus einer SIZ-RDH-Datei benötigt.
`static int`	`NEED_SOFTPIN` Ursache des Callback-Aufrufes: PIN-Eingabe über Computer-Tastatur benötigt.
`static int`	`NEED_USERID` Ursache des Callback-Aufrufes: Nutzerkennung für HBCI-Zugang benötigt.
`static int`	`STATUS_DIALOG_END` Kernel-Status: Beende Dialog.
`static int`	`STATUS_DIALOG_END_DONE` Kernel-Status: Dialog beendet.
`static int`	`STATUS_DIALOG_INIT` Kernel-Status: Starte Dialog-Initialisierung.
`static int`	`STATUS_DIALOG_INIT_DONE` Kernel-Status: Dialog-Initialisierung ausgeführt.
`static int`	`STATUS_INIT_SIGID` Kernel-Status: aktualisiere Signatur-ID.
`static int`	`STATUS_INIT_SIGID_DONE` Kernel-Status: Signatur-ID aktualisiert.
`static int`	`STATUS_INIT_SYSID` Kernel-Status: aktualisiere System-ID.
`static int`	`STATUS_INIT_SYSID_DONE` Kernel-Status: System-ID aktualisiert.
`static int`	`STATUS_INIT_UPD` Kernel-Status: hole UPD.
`static int`	`STATUS_INIT_UPD_DONE` Kernel-Status: UPD aktualisiert.
`static int`	`STATUS_INST_BPD_INIT` Kernel-Status: hole BPD.
`static int`	`STATUS_INST_BPD_INIT_DONE` Kernel-Status: BPD aktualisiert.
`static int`	`STATUS_INST_GET_KEYS` Kernel-Status: hole Institutsschlüssel.
`static int`	`STATUS_INST_GET_KEYS_DONE` Kernel-Status: Institutsschlüssel aktualisiert.
`static int`	`STATUS_LOCK_KEYS` Kernel-Status: sperre Nutzerschlüssel.
`static int`	`STATUS_LOCK_KEYS_DONE` Kernel-Status: Nutzerschlüssel gesperrt.
`static int`	`STATUS_MSG_CREATE` Kernel-Status: Erzeuge HBCI-Nachricht.
`static int`	`STATUS_MSG_CRYPT` Kernel-Status: Verschlüssele HBCI-Nachricht.
`static int`	`STATUS_MSG_DECRYPT` Kernel-Status: Entschlüssele HBCI-Nachricht.
`static int`	`STATUS_MSG_PARSE` Kernel-Status: Parse HBCI-Antwort-Nachricht (bei diesem Callback ist das `passport`-Objekt immer `null`).
`static int`	`STATUS_MSG_RAW_RECV` Wird aufgerufen unmittelbar nachdem die HBCI-Nachricht vom Server empfangen wurde.
`static int`	`STATUS_MSG_RAW_SEND` Wird aufgerufen unmittelbar bevor die HBCI-Nachricht an den Server gesendet wird.
`static int`	`STATUS_MSG_RECV` Kernel-Status: Empfange HBCI-Antwort-Nachricht (bei diesem Callback ist das `passport`-Objekt immer `null`).
`static int`	`STATUS_MSG_SEND` Kernel-Status: Sende HBCI-Nachricht (bei diesem Callback ist das `passport`-Objekt immer `null`).
`static int`	`STATUS_MSG_SIGN` Kernel-Status: Signiere HBCI-Nachricht.
`static int`	`STATUS_MSG_VERIFY` Kernel-Status: Ãberprüfe digitale Signatur der Nachricht.
`static int`	`STATUS_SEND_INFOPOINT_DATA` Kernel-Status: Der Kernel sendet Informationen über eine erfolgreiche Dialog-Initialisierung an den InfoPoint-Server (siehe auch README.InfoPoint).
`static int`	`STATUS_SEND_KEYS` Kernel-Status: Sende Nutzerschlüssel.
`static int`	`STATUS_SEND_KEYS_DONE` Kernel-Status: Nutzerschlüssel gesendet.
`static int`	`STATUS_SEND_TASK` Kernel-Status: Erzeuge Auftrag zum Versenden.
`static int`	`STATUS_SEND_TASK_DONE` Kernel-Status: Auftrag gesendet.
`static int`	`TYPE_BOOLEAN` erwarteter Datentyp der Antwort: ja/nein, true/false, weiter/abbrechen oder ähnlich.
`static int`	`TYPE_NONE` erwarteter Datentyp der Antwort: keiner (keine Antwortdaten erwartet)
`static int`	`TYPE_SECRET` erwarteter Datentyp der Antwort: geheimer Text (bei Eingabe nicht anzeigen)
`static int`	`TYPE_TEXT` erwarteter Datentyp der Antwort: "normaler" Text
`static int`	`USERID_CHANGED` im Parameter retData stehen die neuen Daten im Format UserID\|CustomerID drin
`static int`	`WRONG_PIN` Ursache des Callbacks: falsche PIN eingegeben

Method Summary

All Methods Instance Methods Abstract Methods
Modifier and Type	Method and Description
`void`	`callback(int reason, String msg, int datatype, StringBuffer retData)` Wird vom HBCI-Kernel aufgerufen, wenn die Interaktion mit der Anwendung erforderlich ist.
`String`	`needTAN()`
`void`	`status(int statusTag, Object o)` Kurzform für `status(int, Object[])` für den Fall, dass das `Object[]` nur ein einziges Objekt enthält
`void`	`status(int statusTag, Object[] o)` Wird vom HBCI-Kernel aufgerufen, um einen bestimmten Status der Abarbeitung bekanntzugeben.
`void`	`tanChallengeCallback(String orderRef, String challenge)`

- Field Detail
  - NEED_CHIPCARD
```
static final int NEED_CHIPCARD
```
    Ursache des Callback-Aufrufes: Chipkarte benötigt (im Chipkartenterminal). Dieser Callback tritt auf, wenn der HBCI-Kernel auf das Einlegen der HBCI-Chipkarte in den Chipkartenleser wartet. Als Reaktion auf diesen Callback darf nur eine entsprechende Aufforderung o.ä. angezeigt werden, die Callback-Methode muss anschlieÃend sofort beendet werden. Das eigentliche "Warten" auf die Chipkarte sowie das Erkennen, dass eine Chipkarte eingelegt wurde, wird von HBCI4Java übernommen. Ist das Einlegen der Chipkarte abgeschlossen, so wird ein weiterer Callback mit dem Code HAVE_CHIPCARD erzeugt.
    
    See Also:
    
    Constant Field Values
  - NEED_HARDPIN
```
static final int NEED_HARDPIN
```
    Ursache des Callback-Aufrufes: PIN-Eingabe am Chipkartenterminal erwartet. Dieser Callback zeigt an, dass der Anwender jetzt die HBCI-PIN am Chipkartenterminal eingeben muss. Hier gilt das gleiche wie beim Code NEED_CHIPCARD: Die Callback-Methode darf hier nur eine entsprechende Meldung o.ä. anzeigen und muss dann sofort zurückkehren -- HBCI4Java erledigt die eigentliche Entgegennahme der PIN. Wurde die PIN eingegeben (oder die Eingabe abgebrochen), so wird ein weiterer Callback-Aufruf mit dem Code HAVE_HARDPIN erzeugt.
    
    See Also:
    
    Constant Field Values
  - NEED_SOFTPIN
```
static final int NEED_SOFTPIN
```
    Ursache des Callback-Aufrufes: PIN-Eingabe über Computer-Tastatur benötigt. Alternativ zum Callback NEED_HARDPIN kann dieser Callback auftreten, wenn die direkte PIN-Eingabe am Chipkartenterminal nicht möglich oder deaktiviert ist. In diesem Fall muss die PIN "softwaremäÃig" eingegeben werden, d.h. der Anwender gibt die PIN über die PC-Tastatur ein, welche über diesen Callback-Aufruf an den HBCI-Kernel übergeben wird. Der Kernel übermittelt die PIN anschlieÃend zur Verifikation an die Chipkarte. In diesem Falle gibt es keinen weiteren Callback-Aufruf, wenn die PIN-Verifikation abgeschlossen ist!
    
    See Also:
    
    Constant Field Values
  - HAVE_HARDPIN
```
static final int HAVE_HARDPIN
```
    Ursache des Callback-Aufrufes: PIN-Eingabe über Chipkartenterminal abgeschlossen. Dieser Callback tritt auf, wenn die direkte PIN-Eingabe am Chipkartenleser abgeschlossen (oder abgebrochen) ist. Dieser Aufruf kann dazu genutzt werden, evtl. angezeigte Meldungsfenster ("Bitte jetzt PIN eingeben") wieder zu schlieÃen.
    
    See Also:
    
    Constant Field Values
  - HAVE_CHIPCARD
```
static final int HAVE_CHIPCARD
```
    Ursache des Callback-Aufrufes: Chipkarte wurde in Chipkartenterminal eingelegt. Dieser Callback tritt auf, wenn das Einlegen der Chipkarte in den Chipkartenleser abgeschlossen (oder abgebrochen) ist. Dieser Aufruf kann dazu genutzt werden, evtl. angezeigte Meldungsfenster ("Bitte jetzt Karte einlegen einlegen") wieder zu schlieÃen.
    
    See Also:
    
    Constant Field Values
  - NEED_COUNTRY
```
static final int NEED_COUNTRY
```
    Ursache des Callback-Aufrufes: Länderkennzeichen der Bankverbindung benötigt. Der Kernel benötigt für ein neu zu erstellendes Passport-Medium das Länderkennzeichen der Bank, für die dieses Passport benutzt werden soll. Da es sich i.d.R. um deutsche Banken handelt, kann die Callback-Routine hier immer "DE" zurückgeben, anstatt tatsächlich auf eine Nutzereingabe zu warten.
    
    See Also:
    
    Constant Field Values
  - NEED_BLZ
```
static final int NEED_BLZ
```
    Ursache des Callback-Aufrufes: Bankleitzahl der Bank benötigt. Für ein neu zu erstellendes Passport-Medium wird die Bankleitzahl der Bank benötigt, für die dieses Passport verwendet werden soll.
    
    See Also:
    
    Constant Field Values
  - NEED_HOST
```
static final int NEED_HOST
```
    Ursache des Callback-Aufrufes: Netzwerkadresse des HBCI-Servers benötigt. Es wird die Hostadresse benötigt, unter welcher der HBCI-Server der Bank zu erreichen ist. Dieses Callback tritt nur auf, wenn der Kernel ein neues Passport-Medium erzeugt. Bei RDH- bzw. DDV-Passports wird hier eine IP-Adresse oder ein vollständiger Hostname erwartet. Für PIN/TAN-Passports wird hier die URL erwartet, unter der der HBCI-PIN/TAN-Handler auf entsprechende HTTPS-Requests reagiert. Dabei muss das Prefix "https://" weggelassen werden (also beispielsweise "www.hbci-kernel.de/pintan/PinTanServlet").
    
    See Also:
    
    Constant Field Values
  - NEED_PORT
```
static final int NEED_PORT
```
    Ursache des Callback-Aufrufes: TCP-Port, auf dem der HBCI-Server arbeitet (3000), benötigt. Dieser Callback tritt nur auf, wenn ein neues Passport-Medium vom Kernel erzeugt wird. Da die TCP-Portnummer für HBCI-Server immer "3000" ist, kann dieser Wert direkt von der Callback-Methode zurückgegeben werden, anstatt auf eine Nutzereingabe zu warten.
    
    See Also:
    
    Constant Field Values
  - NEED_USERID
```
static final int NEED_USERID
```
    Ursache des Callback-Aufrufes: Nutzerkennung für HBCI-Zugang benötigt. Wird beim Anlegen eines neuen Passport-Mediums und manchmal beim erstmaligen Benutzen einer DDV-Chipkarte erzeugt, wenn auf der Chipkarte die Benutzerkennung noch nicht gespeichert ist.
    
    See Also:
    
    Constant Field Values
  - HAVE_INST_MSG
```
static final int HAVE_INST_MSG
```
    Ursache des Callback-Aufrufes: Institutsnachricht erhalten. Tritt dieser Callback auf, so enthält der msg-Parameter der callback-Methode einen String, den die Bank als Kreditinstitutsnachricht an den Kunden gesandt hat. Diese Nachricht sollte dem Anwender i.d.R. angezeigt werden. HBCI4Java erwartet auf diesen Callback keine Antwortdaten.
    
    See Also:
    
    Constant Field Values
  - NEED_REMOVE_CHIPCARD
```
static final int NEED_REMOVE_CHIPCARD
```
    Ursache des Callback-Aufrufes: Chipkarte soll aus Chipkartenterminal entfernt werden. Dieser Callback wird zur Zeit noch nicht benutzt.
    
    See Also:
    
    Constant Field Values
  - NEED_PT_PIN
```
static final int NEED_PT_PIN
```
    Ursache des Callback-Aufrufes: PIN für PIN/TAN-Verfahren benötigt. Dieser Callback tritt nur bei Verwendung von PIN/TAN-Passports auf. Benötigt HBCI4Java die PIN, um die digitale Signatur zu erzeugen, wird sie über diesen Callback abgefragt.
    
    See Also:
    
    Constant Field Values
  - NEED_CUSTOMERID
```
static final int NEED_CUSTOMERID
```
    Ursache des Callback-Aufrufes: Kunden-ID für HBCI-Zugang benötigt. Dieser Callback tritt nur beim Erzeugen eines neuen Passports auf. HBCI4Java benötigt die Kunden-ID, die das Kreditinstitut dem Bankkunden zugewiesen hat (steht meist in dem Brief mit den Zugangsdaten). Hat eine Bank einem Kunden keine separate Kunden-ID zugewiesen, so muss an dieser Stelle die Benutzer-Kennung (User-ID) zurückgegeben werden.
    
    See Also:
    
    Constant Field Values
  - HAVE_CRC_ERROR
```
static final int HAVE_CRC_ERROR
```
    Ursache des Callback-Aufrufes: Fehler beim Verifizieren einer Kontonummer mit Hilfe des jeweiligen Prüfzifferverfahrens. Tritt dieser Callback auf, so hat HBCI4Java festgestellt, dass eine verwendete Kontonummer den Prüfziffercheck der dazugehörigen Bank nicht bestanden hat. Der Anwender soll die Möglichkeit erhalten, die Kontonummer und/oder Bankleitzahl zu korrigieren. Dazu wird ein String in der Form "BLZ|KONTONUMMER" im Parameter retData der callback-Methode übergeben. Die Anwendung kann dem Anwender also BLZ und Kontonummer anzeigen und diese evtl. ändern lassen. Die neue BLZ und Kontonummer muss im Ergebnis wieder in der o.g. Form in die Rückgabevariable retData eingetragen werden. Wurden BLZ oder Kontonummer geändert, so führt HBCI4Java eine erneute Prüfung der Daten durch - schlägt diese wieder fehl, so wird der Callback erneut erzeugt, diesmal natürlich mit den neuen (vom Anwender eingegebenen) Daten. Werden die Daten innerhalb der Callback-Methode nicht geändert (bleibt also der Inhalt von retData unverändert), so übernimmt HBCI4Java die Kontodaten trotz des fehlgeschlagenen Prüfziffern-Checks
    
    Die automatische Ãberprüfung von Kontonummern findet statt, wenn HBCI-Jobs mit Hilfe des Highlevel-Interfaces (siehe dazu Paketbeschreibung von org.kapott.hbci.GV) erzeugt werden. Beim Hinzufügen eines so erzeugten Jobs zur Menge der auszuführenden Aufträge wird die Ãberprüfung für alle in diesem Job benutzten Kontonummern durchgeführt. Für jeden Prüfzifferfehler, der dabei entdeckt wird, wird dieser Callback erzeugt.
    Tritt beim Ãberprüfen einer IBAN ein Fehler auf, wird statt dessen HAVE_IBAN_ERROR als Callback-Reason verwendet.
    
    See Also:
    
    Constant Field Values
  - HAVE_ERROR
```
static final int HAVE_ERROR
```
    Ursache des Callback-Aufrufes: Es ist ein Fehler aufgetreten, der auf Wunsch des Anwenders ignoriert werden kann. Durch Setzen bestimmter Kernel-Parameter kann festgelegt werden, dass beim Auftreten bestimmter Fehler zur Laufzeit nicht sofort eine Exception geworfen wird, sondern dass statt dessen erst dieser Callback erzeugt wird, welcher als msg eine entsprechende Problembeschreibung enthält. HBCI4Java erwartet einen boolschen Rückgabewert, der beschreibt, ob der Fehler ignoriert werden soll oder ob eine enstprechende Exception erzeugt werden soll. Der Anwender kann den Fehler ignorieren, indem im retData Rückgabedaten-Objekt ein leerer String zurückgegeben wird, oder er kann erzwingen, dass HBCI4Java tatsächlich abbricht, indem ein nicht-leerer String im retData-Objekt zurückgegen wird. Siehe dazu auch die Beschreibung des Rückgabe-Datentyps TYPE_BOOLEAN.
    
    Das Ignorieren eines Fehlers kann dazu führen, dass HBCI4Java später trotzdem eine Exception erzeugt, z.B. weil der Fehler in einem bestimmten Submodul doch nicht einfach ignoriert werden kann, oder es kann auch dazu führen, dass Aufträge von der Bank nicht angenommen werden usw. Es wird aber in jedem Fall eine entsprechende Fehlermeldung erzeugt.
    
    See Also:
    
    Constant Field Values
  - NEED_PASSPHRASE_LOAD
```
static final int NEED_PASSPHRASE_LOAD
```
    Ursache des Callback-Aufrufes: Passwort für das Einlesen der Schlüsseldatei benötigt. Dieser Callback tritt beim Laden eines Passport-Files auf, um nach dem Passwort für die Entschlüsselung zu fragen. ACHTUNG: Die folgenden Zeichen duerfen NICHT im Passwort enthalten sein: ÃÂ´Â°Â§üÃöäÃÃ
    
    See Also:
    
    Constant Field Values
  - NEED_PASSPHRASE_SAVE
```
static final int NEED_PASSPHRASE_SAVE
```
    Ursache des Callback-Aufrufes: Passwort für das Erzeugen der Schlüsseldatei benötigt. Dieser Callback tritt beim Erzeugen eines neuen Passport-Files bzw. beim Ãndern der Passphrase für eine Schlüsseldatei auf, um nach dem Passwort für die Verschlüsselung zu fragen. ACHTUNG: Die folgenden Zeichen duerfen NICHT im Passwort enthalten sein: ÃÂ´Â°Â§üÃöäÃÃ
    
    See Also:
    
    Constant Field Values
  - NEED_SIZENTRY_SELECT
```
static final int NEED_SIZENTRY_SELECT
```
    Ursache des Callback-Aufrufes: Auswahl eines Eintrages aus einer SIZ-RDH-Datei benötigt. Dieser Callback tritt nur bei Verwendung der Passport-Variante SIZRDHFile auf. In einer SIZ-RDH-Schlüsseldatei können mehrere HBCI-Zugangsdatensätze gespeichert sein. Wird eine solche Datei mit mehreren Datensätzen geladen, so wird dieser Callback erzeugt, um den zu benutzenden Datensatz aus der Datei auswählen zu können.
    
    Dazu wird beim Aufruf der Callback-Routine im Parameter retData ein String übergeben, der aus Informationen über alle in der Datei vorhandenen Zugangsdatensätze besteht. Das Format dieses Strings ist <ID>;<BLZ>;<USERID>[|<ID>;<BLZ>;<USERID>...] Es werden also die verschiedenen Datensätze durch "|" getrennt dargestellt, wobei jeder einzelne Datensatz durch eine ID, die Bankleitzahl und die UserID dieses Datensatzes repräsentiert wird.
    
    Dem Anwender müssen diese Daten in geeigneter Weise zur Auswahl angezeigt werden. Die Callback-Routine muss schlieÃlich die ID des vom Anwender ausgewählten Eintrages im retData-Rückgabedatenobjekt zurückgeben.
    
    Beim Aufruf der Callback-Routine könnte retData also folgendes enthalten: 0;09950003;Kunde-001|1;01234567;Kunde8|4;8765432;7364634564564. Der Anwender muss sich also zwischen den Datensätzen "09950003;Kunde-001", "01234567;Kunde8" und "8765432;7364634564564" entscheiden. Je nach Auswahl muss in retData dann jeweils "0", "1" oder "4" zurückgegeben werden.
    
    See Also:
    
    Constant Field Values
  - NEED_CONNECTION
```
static final int NEED_CONNECTION
```
    Ursache des Callback-Aufrufes: es wird eine Netz-Verbindung zum HBCI-Server benötigt. Dieser Callback wird erzeugt, bevor HBCI4Java eine Verbindung zum HBCI-Server aufbaut. Bei Client-Anwendungen, die mit einer Dialup-Verbindung zum Internet arbeiten, kann dieser Callback benutzt werden, um den Anwender zum Aktivieren der Internet-Verbindung aufzufordern. Es werden keine Rückgabedaten erwartet. Sobald die Internet-Verbindung nicht mehr benötigt wird, wird ein anderer Callback (CLOSE_CONNECTION) erzeugt.
    
    Dieses Callback-Paar wird immer dann erzeugt, wenn von der aktuellen HBCI4Java-Verarbeitungsstufe tatsächlich eine Verbindung zum Internet benötigt wird bzw. nicht mehr (CLOSE_CONNECTION) benötigt wird. U.U. werden allerdings mehrere solcher Verarbeitungsstufen direkt hintereinander ausgeführt - das kann zur Folge haben, dass auch diese Callback-Paare mehrmals direkt hintereinander auftreten. Das tritt vor allem beim erstmaligen Initialiseren eines Passports auf. Beim Aufruf von new HBCIHandler(...) werden verschiedene Passport-Daten mit der Bank abgeglichen, dabei wird u.U. mehrmals NEED_CONNECTION/CLOSE_CONNECTION aufgerufen. Evtl. sollte der Callback-Handler der Anwendung in diesem Fall also entsprechende MaÃnahmen treffen.
    
    See Also:
    
    Constant Field Values
  - CLOSE_CONNECTION
```
static final int CLOSE_CONNECTION
```
    Ursache des Callback-Aufrufes: die Netzwerk-Verbindung zum HBCI-Server wird nicht länger benötigt. Dieser Callback wird aufgerufen, sobald HBCI4Java die Kommunikation mit dem HBCI-Server vorläufig beendet hat. Dieser Callback kann zusammen mit dem Callback NEED_CONNECTION benutzt werden, um für Clients mit Dialup-Verbindungen die Online-Zeiten zu optimieren. Bei diesem Callback werden keine Rückgabedaten erwartet
    
    See Also:
    
    Constant Field Values
  - NEED_PROXY_USER
```
static final int NEED_PROXY_USER
```
    Ursache des Callbacks: es wird ein Nutzername für die Authentifizierung am Proxy-Server benötigt. Wird für die HTTPS-Verbindungen bei HBCI-PIN/TAN ein Proxy-Server verwendet, und verlangt dieser Proxy-Server eine Authentifizierung, so wird über diesen Callback nach dem Nutzernamen gefragt, falls dieser nicht schon durch den Kernel-Parameter client.passport.PinTan.proxyuser gesetzt wurde
    
    See Also:
    
    Constant Field Values
  - NEED_PROXY_PASS
```
static final int NEED_PROXY_PASS
```
    Ursache des Callbacks: es wird ein Passwort für die Authentifizierung am Proxy-Server benötigt. Wird für die HTTPS-Verbindungen bei HBCI-PIN/TAN ein Proxy-Server verwendet, und verlangt dieser Proxy-Server eine Authentifizierung, so wird über diesen Callback nach dem Passwort gefragt, falls dieses nicht schon durch den Kernel-Parameter client.passport.PinTan.proxypass gesetzt wurde
    
    See Also:
    
    Constant Field Values
  - HAVE_IBAN_ERROR
```
static final int HAVE_IBAN_ERROR
```
    Ursache des Callbacks: beim Ãberprüfen einer IBAN ist ein Fehler aufgetreten. in retData wird die fehlerhafte IBAN übergeben. Der Nutzer sollte die IBAN korrieren. Die korrigierte IBAN sollte wieder in retData zurückgegeben werden. Wird die IBAN nicht verändert, wird diese IBAN trotz des Fehlers verwendet. Wird eine korrigierte IBAN zum Nutzer zurückgegeben, wird für diese erneut ein Prüfsummencheck ausgeführt. Schlägt der wieder fehl, wird der Callback erneut erzeugt. Das geht so lange, bis entweder der Prüfsummencheck erfolgreich war oder bis die IBAN vom Nutzer nicht verändert wird. Siehe dazu auch HAVE_CRC_ERROR.
    
    See Also:
    
    Constant Field Values
  - NEED_INFOPOINT_ACK
```
static final int NEED_INFOPOINT_ACK
```
    Ursache des Callbacks: Kernel fragt um Erlaubnis, Daten an den InfoPoint-Server zu senden. An bestimmten Punkten der HBCI-Kommunikation sendet der HBCI-Kernel Daten über erfolgreich gelaufene Verbindungen an den InfoPoint-Server (siehe Kernel-Parameter "infoPoint.enabled" und Datei README.InfoPoint). Bei diesem Callback wird im StringBuffer retData das XML-Document übergeben, welches an den InfoPoint-Server gesendet werden soll. Als Antwort wird ein Boolean-Wert erwartet (siehe TYPE_BOOLEAN). Dürfen die Daten gesendet werden, ist von der Anwendung also ein leerer String in retData zurückzugeben, ansonsten ein beliebiger nicht-leerer String.
    
    See Also:
    
    Constant Field Values
  - NEED_PT_PHOTOTAN
```
static final int NEED_PT_PHOTOTAN
```
    Ursache des Callback-Aufrufes: eine Photo-TAN für PIN/TAN-Verfahren benötigt. Dieser Callback tritt nur bei Verwendung von PIN/TAN-Passports mit dem photoTAN-Verfahren auf. Im Callback wird im StringBuffer der Wert aus dem HHDuc uebergeben. Das sind die Roh-Daten des Bildes inclusive Angaben zum Bildformat. HBCI4Java enthaelt eine Klasse "MatrixCode", mit dem diese Daten dann gelesen werden koennen.
    
    See Also:
    
    Constant Field Values
  - WRONG_PIN
```
static final int WRONG_PIN
```
    Ursache des Callbacks: falsche PIN eingegeben
    
    See Also:
    
    Constant Field Values
  - USERID_CHANGED
```
static final int USERID_CHANGED
```
    im Parameter retData stehen die neuen Daten im Format UserID|CustomerID drin
    
    See Also:
    
    Constant Field Values
  - TYPE_NONE
```
static final int TYPE_NONE
```
    erwarteter Datentyp der Antwort: keiner (keine Antwortdaten erwartet)
    
    See Also:
    
    Constant Field Values
  - TYPE_SECRET
```
static final int TYPE_SECRET
```
    erwarteter Datentyp der Antwort: geheimer Text (bei Eingabe nicht anzeigen)
    
    See Also:
    
    Constant Field Values
  - TYPE_TEXT
```
static final int TYPE_TEXT
```
    erwarteter Datentyp der Antwort: "normaler" Text
    
    See Also:
    
    Constant Field Values
  - TYPE_BOOLEAN
```
static final int TYPE_BOOLEAN
```
    erwarteter Datentyp der Antwort: ja/nein, true/false, weiter/abbrechen oder ähnlich. Da das Rückgabedatenobjekt immer ein StringBuffer ist, wird hier folgende Kodierung verwendet: die beiden möglichen Werte für die Antwort (true/false, ja/nein, weiter/abbrechen, usw.) werden dadurch unterschieden, dass für den einen Wert ein leerer String zurückgegeben wird, für den anderen Wert ein nicht leerer beliebiger String. Einige Callback-Reasons können auch den Inhalt des nicht-leeren Strings auswerten. Eine genaue Beschreibung der jeweilis möglichen Rückgabedaten befinden sich in der Beschreibung der Callback-Reasons (HAVE_* bzw. NEED_*), bei denen Boolean-Daten als Rückgabewerte benötigt werden.
    
    Siehe dazu auch die Hinweise in der Paketbeschreibung zum Paket org.kapott.hbci.callback.
    
    See Also:
    
    Constant Field Values
  - STATUS_SEND_TASK
```
static final int STATUS_SEND_TASK
```
    Kernel-Status: Erzeuge Auftrag zum Versenden. Als Zusatzinformation wird bei diesem Callback das HBCIJob-Objekt des Auftrages übergeben, dessen Auftragsdaten gerade erzeugt werden.
    
    See Also:
    
    Constant Field Values
  - STATUS_SEND_TASK_DONE
```
static final int STATUS_SEND_TASK_DONE
```
    Kernel-Status: Auftrag gesendet. Tritt auf, wenn zu einem bestimmten Job Auftragsdaten empfangen und ausgewertet wurden. Als Zusatzinformation wird das HBCIJob-Objekt des jeweiligen Auftrages übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_INST_BPD_INIT
```
static final int STATUS_INST_BPD_INIT
```
    Kernel-Status: hole BPD. Kann nur während der Passport-Initialisierung auftreten und zeigt an, dass die BPD von der Bank abgeholt werden müssen, weil sie noch nicht lokal vorhanden sind. Es werden keine zusätzlichen Informationen übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_INST_BPD_INIT_DONE
```
static final int STATUS_INST_BPD_INIT_DONE
```
    Kernel-Status: BPD aktualisiert. Dieser Status-Callback tritt nach dem expliziten Abholen der BPD (STATUS_INST_BPD_INIT) auf und kann auch nach einer Dialog-Initialisierung auftreten, wenn dabei eine neue BPD vom Kreditinstitut empfangen wurde. Als Zusatzinformation wird ein Properties-Objekt mit den neuen BPD übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_INST_GET_KEYS
```
static final int STATUS_INST_GET_KEYS
```
    Kernel-Status: hole Institutsschlüssel. Dieser Status-Callback zeigt an, dass HBCI4Java die öffentlichen Schlüssel des Kreditinstitutes abholt. Dieser Callback kann nur beim Initialisieren eines Passportes und bei Verwendung von RDH als Sicherheitsverfahren auftreten. Es werden keine zusätzlichen Informationen übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_INST_GET_KEYS_DONE
```
static final int STATUS_INST_GET_KEYS_DONE
```
    Kernel-Status: Institutsschlüssel aktualisiert. Dieser Callback tritt auf, wenn HBCI4Java neue öffentliche Schlüssel der Bank empfangen hat. Dieser Callback kann nach dem expliziten Anfordern der neuen Schlüssel (STATUS_INST_GET_KEYS) oder nach einer Dialog-Initialisierung auftreten, wenn das Kreditinstitut neue Schlüssel übermittelt hat. Es werden keine zusätzlichen Informationen übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_SEND_KEYS
```
static final int STATUS_SEND_KEYS
```
    Kernel-Status: Sende Nutzerschlüssel. Wird erzeugt, wenn HBCI4Java neue Schlüssel des Anwenders an die Bank versendet. Das tritt beim erstmaligen Einrichten eines RDH-Passportes bzw. nach dem manuellen Erzeugen neuer RDH-Schlüssel auf. Es werden keine zusätzlichen Informationen übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_SEND_KEYS_DONE
```
static final int STATUS_SEND_KEYS_DONE
```
    Kernel-Status: Nutzerschlüssel gesendet. Dieser Callback zeigt an, dass die RDH-Schlüssel des Anwenders an die Bank versandt wurden. Der Erfolg dieser Aktion kann nicht allein durch das Auftreten dieses Callbacks angenommen werden! Es wird der Status des Nachrichtenaustauschs (HBCIMsgStatus) als Zusatzinformation übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_INIT_SYSID
```
static final int STATUS_INIT_SYSID
```
    Kernel-Status: aktualisiere System-ID. Dieser Status-Callback wird erzeugt, wenn HBCI4Java die System-ID, die für das RDH-Verfahren benötigt wird, synchronisiert. Der Callback kann nur beim Initialisieren eines Passports auftreten. Es werden keine Zusatzinformationen übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_INIT_SYSID_DONE
```
static final int STATUS_INIT_SYSID_DONE
```
    Kernel-Status: System-ID aktualisiert. Dieser Callback tritt auf, wenn im Zuge der Synchronisierung (STATUS_INIT_SYSID) eine System-ID empfangen wurde. Als Zusatzinformation wird ein Array übergeben, dessen erstes Element die Statusinformation zu diesem Nachrichtenaustausch darstellt (HBCIMsgStatus) und dessen zweites Element die neue System-ID ist.
    
    See Also:
    
    Constant Field Values
  - STATUS_INIT_UPD
```
static final int STATUS_INIT_UPD
```
    Kernel-Status: hole UPD. Kann nur während der Passport-Initialisierung auftreten und zeigt an, dass die UPD von der Bank abgeholt werden müssen, weil sie noch nicht lokal vorhanden sind. Es werden keine zusätzlichen Informationen übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_INIT_UPD_DONE
```
static final int STATUS_INIT_UPD_DONE
```
    Kernel-Status: UPD aktualisiert. Dieser Status-Callback tritt nach dem expliziten Abholen der UPD (STATUS_INIT_UPD) auf und kann auch nach einer Dialog-Initialisierung auftreten, wenn dabei eine neue UPD vom Kreditinstitut empfangen wurde. Als Zusatzinformation wird ein Properties-Objekt mit den neuen UPD übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_LOCK_KEYS
```
static final int STATUS_LOCK_KEYS
```
    Kernel-Status: sperre Nutzerschlüssel. Dieser Status-Callback wird erzeugt, wenn HBCI4Java einen Auftrag zur Sperrung der aktuellen Nutzerschlüssel generiert. Es werden keine Zusatzinformationen übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_LOCK_KEYS_DONE
```
static final int STATUS_LOCK_KEYS_DONE
```
    Kernel-Status: Nutzerschlüssel gesperrt. Dieser Callback tritt auf, nachdem die Antwort auf die Nachricht "Sperren der Nutzerschlüssel" eingetroffen ist. Ein Auftreten dieses Callbacks ist keine Garantie dafür, dass die Schlüsselsperrung erfolgreich abgelaufen ist. Es wird der Status des Nachrichtenaustauschs (HBCIMsgStatus) als Zusatzinformation übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_INIT_SIGID
```
static final int STATUS_INIT_SIGID
```
    Kernel-Status: aktualisiere Signatur-ID. Dieser Status-Callback wird erzeugt, wenn HBCI4Java die Signatur-ID, die für das RDH-Verfahren benötigt wird, synchronisiert. Der Callback kann nur beim Initialisieren eines Passports auftreten. Es werden keine Zusatzinformationen übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_INIT_SIGID_DONE
```
static final int STATUS_INIT_SIGID_DONE
```
    Kernel-Status: Signatur-ID aktualisiert. Dieser Callback tritt auf, wenn im Zuge der Synchronisierung (STATUS_INIT_SIGID) eine Signatur-ID empfangen wurde. Als Zusatzinformation wird ein Array übergeben, dessen erstes Element die Statusinformation zu diesem Nachrichtenaustausch darstellt (HBCIMsgStatus) und dessen zweites Element die neue Signatur-ID (ein Long-Objekt) ist.
    
    See Also:
    
    Constant Field Values
  - STATUS_DIALOG_INIT
```
static final int STATUS_DIALOG_INIT
```
    Kernel-Status: Starte Dialog-Initialisierung. Dieser Status-Callback zeigt an, dass HBCI4Java eine Dialog-Initialisierung startet. Es werden keine zusätzlichen Informationen übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_DIALOG_INIT_DONE
```
static final int STATUS_DIALOG_INIT_DONE
```
    Kernel-Status: Dialog-Initialisierung ausgeführt. Dieser Callback tritt nach dem Durchführen der Dialog-Initialisierung auf. Als Zusatzinformation wird ein Array übergeben, dessen erstes Element die Statusinformation zu diesem Nachrichtenaustausch darstellt (HBCIMsgStatus) und dessen zweites Element die neue Dialog-ID ist.
    
    See Also:
    
    Constant Field Values
  - STATUS_DIALOG_END
```
static final int STATUS_DIALOG_END
```
    Kernel-Status: Beende Dialog. Wird ausgelöst, wenn HBCI4Java den aktuellen Dialog beendet. Es werden keine zusätzlichen Daten übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_DIALOG_END_DONE
```
static final int STATUS_DIALOG_END_DONE
```
    Kernel-Status: Dialog beendet. Wird ausgeführt, wenn der HBCI-Dialog tatsächlich beendet ist. Es wird der Status des Nachrichtenaustauschs (HBCIMsgStatus) als Zusatzinformation übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_MSG_CREATE
```
static final int STATUS_MSG_CREATE
```
    Kernel-Status: Erzeuge HBCI-Nachricht. Dieser Callback zeigt an, dass HBCI4Java gerade eine HBCI-Nachricht erzeugt. Es wird der Name der Nachricht als zusätzliches Objekt übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_MSG_SIGN
```
static final int STATUS_MSG_SIGN
```
    Kernel-Status: Signiere HBCI-Nachricht. Dieser Callback wird aufgerufen, wenn HBCI4Java die ausgehende HBCI-Nachricht signiert. Es werden keine zusätzlichen Informationen übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_MSG_CRYPT
```
static final int STATUS_MSG_CRYPT
```
    Kernel-Status: Verschlüssele HBCI-Nachricht. Wird aufgerufen, wenn HBCI4Java die ausgehende HBCI-Nachricht verschlüsselt. Es werden keine zusätzlichen Informationen übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_MSG_SEND
```
static final int STATUS_MSG_SEND
```
    Kernel-Status: Sende HBCI-Nachricht (bei diesem Callback ist das passport-Objekt immer null). Wird aufgerufen, wenn die erzeugte HBCI-Nachricht an den HBCI-Server versandt wird. Es werden keine zusätzlichen Informationen übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_MSG_DECRYPT
```
static final int STATUS_MSG_DECRYPT
```
    Kernel-Status: Entschlüssele HBCI-Nachricht. Wird aufgerufen, wenn die empfangene HBCI-Nachricht von HBCI4Java entschlüsselt wird. Es werden keine zusätzlichen Informationen übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_MSG_VERIFY
```
static final int STATUS_MSG_VERIFY
```
    Kernel-Status: Ãberprüfe digitale Signatur der Nachricht. Wird aufgerufen, wenn HBCI4Java die digitale Signatur der empfangenen Antwortnachricht überprüft. Es werden keine zusätzlichen Informationen übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_MSG_RECV
```
static final int STATUS_MSG_RECV
```
    Kernel-Status: Empfange HBCI-Antwort-Nachricht (bei diesem Callback ist das passport-Objekt immer null). Wird aufgerufen, wenn die Antwort-HBCI-Nachricht vom HBCI-Server empfangen wird. Es werden keine zusätzlichen Informationen übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_MSG_PARSE
```
static final int STATUS_MSG_PARSE
```
    Kernel-Status: Parse HBCI-Antwort-Nachricht (bei diesem Callback ist das passport-Objekt immer null). Wird aufgerufen, wenn HBCI4Java versucht, die empfangene Nachricht zu parsen. Es wird der Name der erwarteten Nachricht als zusätzliche Information übergeben.
    
    See Also:
    
    Constant Field Values
  - STATUS_SEND_INFOPOINT_DATA
```
static final int STATUS_SEND_INFOPOINT_DATA
```
    Kernel-Status: Der Kernel sendet Informationen über eine erfolgreiche Dialog-Initialisierung an den InfoPoint-Server (siehe auch README.InfoPoint). Als zusätzlicher Parameter wird das XML-Dokument (als String) übergeben, welches an den InfoPoint-Server gesendet wird.
    
    See Also:
    
    Constant Field Values
  - STATUS_MSG_RAW_SEND
```
static final int STATUS_MSG_RAW_SEND
```
    Wird aufgerufen unmittelbar bevor die HBCI-Nachricht an den Server gesendet wird. Als zusaetzliche Information wird die zu sendende Nachricht als String uebergeben. Sie kann dann z.Bsp. in einem Log gesammelt werden, welches ausschliesslich (zusammen mit STATUS_MSG_RAW_RECV) die gesendeten und empfangenen rohen HBCI-Nachrichten enthaelt. Sinnvoll zum Debuggen der Kommunikation mit der Bank.
    
    See Also:
    
    Constant Field Values
  - STATUS_MSG_RAW_RECV
```
static final int STATUS_MSG_RAW_RECV
```
    Wird aufgerufen unmittelbar nachdem die HBCI-Nachricht vom Server empfangen wurde. Als zusaetzliche Information wird die empfangene Nachricht als String uebergeben. Sie kann dann z.Bsp. in einem Log gesammelt werden, welches ausschliesslich (zusammen mit STATUS_MSG_RAW_SEND) die gesendeten und empfangenen rohen HBCI-Nachrichten enthaelt. Sinnvoll zum Debuggen der Kommunikation mit der Bank.
    
    See Also:
    
    Constant Field Values
- Method Detail
  - callback
```
void callback(int reason,
              String msg,
              int datatype,
              StringBuffer retData)
```
    Wird vom HBCI-Kernel aufgerufen, wenn die Interaktion mit der Anwendung erforderlich ist. In bestimmten Situationen benötigt der HBCI-Kernel zusätzliche Daten bzw. muss auf die Ausführung einer Aktion des Nutzers warten. Dann wird diese Methode aufgerufen. Dabei wird ein Code (reason) übergeben, der anzeigt, welche Ursache dieser Callbackaufruf hat, d.h. welche Daten oder Aktionen erwartet werden. Falls Daten erwartet werden (z.B. ein Passwort, eine Benutzerkennung, ...), so ist legt der Parameter datatype fest, wie diese Daten erwartet werden. Die eigentlichen Daten muss die Anwendung im Objekt retData ablegen (keinen neuen StringBuffer erzeugen, sondern den Inhalt von retData überschreiben!). Bei einigen Callbacks übergibt HBCI4Java einen vorgeschlagenen default-Wert für die Nutzereingabe im retData-Objekt. Diese Tatsache ist besonders bei der Auswertung des Callbacks HAVE_CRC_ERROR zu beachten!
    
    Parameters:
    
    reason - gibt den Grund für diesen Aufruf an. Dieser Parameter kann alle Werte annehmen, die als "Ursache des Callback-Aufrufes" in der Dokumentation aufgeführt sind. Je nach Wert dieses Parameters werden vom Nutzer Aktionen oder Eingaben erwartet.
    
    msg - ein Hinweistext, der den Grund des Callbacks näher beschreibt. Dieser Parameter muss nicht ausgewertet werden, der Parameter reason ist bereits eindeutig. Er dient nur dazu, bei Anwendungen, die nicht für jeden Ursache des Callback-Aufrufes einen eigenen Hinweistext bereitstellen wollen, eine Art default-Wert für den anzuzeigenden Text bereitzustellen.
    
    datatype - legt fest, welchen Datentyp die vom HBCI-Kernel erwarteten Antwortdaten haben müssen. Ist dieser Wert gleich TYPE_NONE, so werden keine Antwortdaten (also keine Nutzereingabe) erwartet, bei TYPE_SECRET und TYPE_TEXT wird ein normaler String erwartet.
    Der Unterschied zwischen beiden ist der, dass bei TYPE_SECRET sensible Daten (Passwörter usw.) eingegeben werden sollen, so dass die Eingaberoutine evtl. anders arbeiten muss (z.B. Sternchen anstatt dem eingegebenen Text darstellen).
    
    retData - In diesem StringBuffer-Objekt müssen die Antwortdaten abgelegt werden. Beim Aufruf der Callback-Methode von HBCI4Java wird dieser StringBuffer u.U. mit einem vorgeschlagenen default-Wert für die Nutzereingabe gefüllt.
  - tanChallengeCallback
```
void tanChallengeCallback(String orderRef,
                          String challenge)
```
  - needTAN
```
String needTAN()
```
  - status
```
void status(int statusTag,
            Object[] o)
```
    Wird vom HBCI-Kernel aufgerufen, um einen bestimmten Status der Abarbeitung bekanntzugeben.
    
    Parameters:
    
    statusTag - gibt an, welche Stufe der Abarbeitung gerade erreicht wurde (alle oben beschriebenen Konstanten, die mit STATUS_ beginnen)
    
    o - ein Array aus Objekten, das zusätzliche Informationen zum jeweiligen Status enthält. In den meisten Fällen handelt es sich um einen String, der zusätzliche Informationen im Klartext enthält. Welche Informationen das jeweils sind, ist der Beschreibung zu den einzelnen STATUS_*-Tag-Konstanten zu entnehmen.
  - status
```
void status(int statusTag,
            Object o)
```
    Kurzform für status(int, Object[]) für den Fall, dass das Object[] nur ein einziges Objekt enthält

Interface HBCICallback

Field Summary

Method Summary

Field Detail

NEED_CHIPCARD

NEED_HARDPIN

NEED_SOFTPIN

HAVE_HARDPIN

HAVE_CHIPCARD

NEED_COUNTRY

NEED_BLZ

NEED_HOST

NEED_PORT

NEED_USERID

HAVE_INST_MSG

NEED_REMOVE_CHIPCARD

NEED_PT_PIN

NEED_CUSTOMERID

HAVE_CRC_ERROR

HAVE_ERROR

NEED_PASSPHRASE_LOAD

NEED_PASSPHRASE_SAVE

NEED_SIZENTRY_SELECT

NEED_CONNECTION

CLOSE_CONNECTION

NEED_PROXY_USER

NEED_PROXY_PASS

HAVE_IBAN_ERROR

NEED_INFOPOINT_ACK

NEED_PT_PHOTOTAN

WRONG_PIN

USERID_CHANGED

TYPE_NONE

TYPE_SECRET

TYPE_TEXT

TYPE_BOOLEAN

STATUS_SEND_TASK

STATUS_SEND_TASK_DONE

STATUS_INST_BPD_INIT

STATUS_INST_BPD_INIT_DONE

STATUS_INST_GET_KEYS

STATUS_INST_GET_KEYS_DONE

STATUS_SEND_KEYS

STATUS_SEND_KEYS_DONE

STATUS_INIT_SYSID

STATUS_INIT_SYSID_DONE

STATUS_INIT_UPD

STATUS_INIT_UPD_DONE

STATUS_LOCK_KEYS

STATUS_LOCK_KEYS_DONE

STATUS_INIT_SIGID

STATUS_INIT_SIGID_DONE

STATUS_DIALOG_INIT

STATUS_DIALOG_INIT_DONE

STATUS_DIALOG_END

STATUS_DIALOG_END_DONE

STATUS_MSG_CREATE

STATUS_MSG_SIGN

STATUS_MSG_CRYPT

STATUS_MSG_SEND

STATUS_MSG_DECRYPT

STATUS_MSG_VERIFY

STATUS_MSG_RECV

STATUS_MSG_PARSE

STATUS_SEND_INFOPOINT_DATA

STATUS_MSG_RAW_SEND

STATUS_MSG_RAW_RECV

Method Detail

callback

tanChallengeCallback

needTAN

status

status