Interface HBCICallback
- All Known Implementing Classes:
AbstractHBCICallback
,HBCICallbackConsole
,HBCICallbackIOStreams
,HBCICallbackNative
,HBCICallbackSwing
,HBCICallbackSwingInternal
,HBCICallbackThreaded
,HBCICallbackUnsupported
Schnittstelle, die eine Callback-Klasse implementieren muss. Beim Initialisieren von HBCI4Java
(HBCIUtils.init(Properties,org.kapott.hbci.callback.HBCICallback)
)
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
FieldsModifier and TypeFieldDescriptionstatic final int
Ursache des Callback-Aufrufes: die Netzwerk-Verbindung zum HBCI-Server wird nicht länger benötigt.static final int
Ursache des Callback-Aufrufes: Chipkarte wurde in Chipkartenterminal eingelegt.static final int
Ursache des Callback-Aufrufes: Fehler beim Verifizieren einer Kontonummer mit Hilfe des jeweiligen Prüfzifferverfahrens.static final int
Ursache des Callback-Aufrufes: Es ist ein Fehler aufgetreten, der auf Wunsch des Anwenders ignoriert werden kann.static final int
Ursache des Callback-Aufrufes: PIN-Eingabe über Chipkartenterminal abgeschlossen.static final int
Ursache des Callbacks: beim Überprüfen einer IBAN ist ein Fehler aufgetreten.static final int
Ursache des Callback-Aufrufes: Institutsnachricht erhalten.static final int
Ursache des Callback-Aufrufes: neue Nutzerschlüssel generiert (INI-Brief erforderlich).static final int
Ursache des Callback-Aufrufes: Bankleitzahl der Bank benötigt.static final int
Ursache des Callback-Aufrufes: Chipkarte benötigt (im Chipkartenterminal).static final int
Ursache des Callback-Aufrufes: es wird eine Netz-Verbindung zum HBCI-Server benötigt.static final int
Ursache des Callback-Aufrufes: Länderkennzeichen der Bankverbindung benötigt.static final int
Ursache des Callback-Aufrufes: Kunden-ID für HBCI-Zugang benötigt.static final int
Ursache des Callback-Aufrufes: es wird die Bezeichnung des zu verwendenden Datenfilters benötigt.static final int
Ursache des Callback-Aufrufes: PIN-Eingabe am Chipkartenterminal erwartet.static final int
Ursache des Callback-Aufrufes: Netzwerkadresse des HBCI-Servers benötigt.static final int
Deprecated.static final int
Ursache des Callback-Aufrufes: Bestätigung für neue Instituts-Schlüssel benötigt (INI-Brief-Vergleich).static final int
Ursache des Callback-Aufrufes: Passwort für das Einlesen der Schlüsseldatei benötigt.static final int
Ursache des Callback-Aufrufes: Passwort für das Erzeugen der Schlüsseldatei benötigt.static final int
Ursache des Callback-Aufrufes: TCP-Port, auf dem der HBCI-Server arbeitet (3000), benötigt.static final int
Ursache des Callbacks: es wird ein Passwort für die Authentifizierung am Proxy-Server benötigt.static final int
Ursache des Callbacks: es wird ein Nutzername für die Authentifizierung am Proxy-Server benötigt.static final int
Ursache des Callback-Aufrufes: Das Decoupled Verfahren wird verwendet und eine Statusabfrage muss durchgeführt werden, um zu prüfen, ob der Kunde den Prozess bestätigt hat.static final int
Ursache des Callback-Aufrufes: Das Decoupled Verfahren wird verwendet und eine weitere Statusabfrage muss durchgeführt werden, um zu prüfen, ob der Kunde den Prozess bestätigt hat.static final int
Ursache des Callback-Aufrufes: eine Photo-TAN für PIN/TAN-Verfahren benötigt.static final int
Ursache des Callback-Aufrufes: PIN für PIN/TAN-Verfahren benötigt.static final int
Ursache des Callback-Aufrufes: eine QR-Code-TAN für PIN/TAN-Verfahren benötigt.static final int
Ursache des Callbacks: bei Verwendung von HBCI-PIN/TAN muss eines der unterstützten Verfahren ausgewählt werden.static final int
Ursache des Callback-Aufrufes: eine TAN für PIN/TAN-Verfahren benötigt.static final int
Ursache des Callbacks: bei Verwendung von HBCI-PIN/TAN muss die Bezeichnung des TAN-Mediums eingegeben werden.static final int
Ursache des Callback-Aufrufes: Chipkarte soll aus Chipkartenterminal entfernt werden.static final int
Ursache des Callback-Aufrufes: Auswahl eines Eintrages aus einer SIZ-RDH-Datei benötigt.static final int
Ursache des Callback-Aufrufes: PIN-Eingabe über Computer-Tastatur benötigt.static final int
Ursache des Callback-Aufrufes: Nutzerkennung für HBCI-Zugang benötigt.static final int
Kernel-Status: Beende Dialog.static final int
Kernel-Status: Dialog beendet.static final int
Kernel-Status: Starte Dialog-Initialisierung.static final int
Kernel-Status: Dialog-Initialisierung ausgeführt.static final int
Kernel-Status: aktualisiere Signatur-ID.static final int
Kernel-Status: Signatur-ID aktualisiert.static final int
Kernel-Status: aktualisiere System-ID.static final int
Kernel-Status: System-ID aktualisiert.static final int
Kernel-Status: hole UPD.static final int
Kernel-Status: UPD aktualisiert.static final int
Kernel-Status: hole BPD.static final int
Kernel-Status: BPD aktualisiert.static final int
Kernel-Status: hole Institutsschlüssel.static final int
Kernel-Status: Institutsschlüssel aktualisiert.static final int
Kernel-Status: sperre Nutzerschlüssel.static final int
Kernel-Status: Nutzerschlüssel gesperrt.static final int
Kernel-Status: Erzeuge HBCI-Nachricht.static final int
Kernel-Status: Verschlüssele HBCI-Nachricht.static final int
Kernel-Status: Entschlüssele HBCI-Nachricht.static final int
Kernel-Status: Parse HBCI-Antwort-Nachricht (bei diesem Callback ist daspassport
-Objekt immernull
).static final int
Wird aufgerufen unmittelbar nachdem die HBCI-Nachricht vom Server empfangen wurde.static final int
Wie STATUS_MSG_RAW_RECV - jedoch noch vor der Entschluesselung der Daten.static final int
Wird aufgerufen unmittelbar bevor die HBCI-Nachricht an den Server gesendet wird.static final int
Kernel-Status: Empfange HBCI-Antwort-Nachricht (bei diesem Callback ist daspassport
-Objekt immernull
).static final int
Kernel-Status: Sende HBCI-Nachricht (bei diesem Callback ist daspassport
-Objekt immernull
).static final int
Kernel-Status: Signiere HBCI-Nachricht.static final int
Kernel-Status: Überprüfe digitale Signatur der Nachricht.static final int
Deprecated.static final int
Kernel-Status: Sende Nutzerschlüssel.static final int
Kernel-Status: Nutzerschlüssel gesendet.static final int
Kernel-Status: Erzeuge Auftrag zum Versenden.static final int
Kernel-Status: Auftrag gesendet.static final int
erwarteter Datentyp der Antwort: ja/nein, true/false, weiter/abbrechen oder ähnlich.static final int
erwarteter Datentyp der Antwort: keiner (keine Antwortdaten erwartet)static final int
erwarteter Datentyp der Antwort: geheimer Text (bei Eingabe nicht anzeigen)static final int
erwarteter Datentyp der Antwort: "normaler" Textstatic final int
im Parameter retData stehen die neuen Daten im Format UserID|CustomerID drinstatic final int
Ursache des Callbacks: falsche PIN eingegeben -
Method Summary
Modifier and TypeMethodDescriptionvoid
callback
(HBCIPassport passport, int reason, String msg, int datatype, StringBuffer retData) Wird vom HBCI-Kernel aufgerufen, wenn die Interaktion mit der Anwendung erforderlich ist.void
log
(String msg, int level, Date date, StackTraceElement trace) Wird aufgerufen, wenn der HBCI-Kernel eine Log-Ausgabe erzeugt.void
status
(HBCIPassport passport, int statusTag, Object o) Kurzform fürstatus(HBCIPassport, int, Object[])
für den Fall, dass dasObject[]
nur ein einziges Objekt enthältvoid
status
(HBCIPassport passport, int statusTag, Object[] o) Wird vom HBCI-Kernel aufgerufen, um einen bestimmten Status der Abarbeitung bekanntzugeben.boolean
useThreadedCallback
(HBCIPassport passport, int reason, String msg, int datatype, StringBuffer retData) Legt fest, ob ein Callback asynchron oder über den threaded-callback-Mechanismus behandelt werden soll.
-
Field Details
-
NEED_CHIPCARD
static final int NEED_CHIPCARDUrsache 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 CodeHAVE_CHIPCARD
erzeugt.- See Also:
-
NEED_HARDPIN
static final int NEED_HARDPINUrsache 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 CodeNEED_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 CodeHAVE_HARDPIN
erzeugt.- See Also:
-
NEED_SOFTPIN
static final int NEED_SOFTPINUrsache des Callback-Aufrufes: PIN-Eingabe über Computer-Tastatur benötigt. Alternativ zum CallbackNEED_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:
-
HAVE_HARDPIN
static final int HAVE_HARDPINUrsache 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:
-
HAVE_CHIPCARD
static final int HAVE_CHIPCARDUrsache 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:
-
NEED_COUNTRY
static final int NEED_COUNTRYUrsache 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:
-
NEED_BLZ
static final int NEED_BLZUrsache 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:
-
NEED_HOST
static final int NEED_HOSTUrsache 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:
-
NEED_PORT
static final int NEED_PORTUrsache 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:
-
NEED_USERID
static final int NEED_USERIDUrsache 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:
-
NEED_NEW_INST_KEYS_ACK
static final int NEED_NEW_INST_KEYS_ACKUrsache des Callback-Aufrufes: Bestätigung für neue Instituts-Schlüssel benötigt (INI-Brief-Vergleich). Dieser Callback tritt nur bei Verwendung des RDH-Verfahrens auf. Bei einer Dialoginitialisierung versucht HBCI4Java, die öffentlichen Schlüssel des Kreditinstitutes zu aktualisieren. Werden tatsächlich neue Schlüsseldaten empfangen (was i.d.R. nur beim erstmaligen Initialisieren eines Passport-Mediums auftritt), so müssen diese Schlüsseldaten vom Anwender verifiziert werden. Dazu muss er die Schlüsseldaten, die HBCI4Java empfangen hat, mit den Daten vergleichen, die die Bank in einem INI-Brief mitgeteilt hat. Erst wenn dieser Vergleich positiv abläuft, wird HBCI4Java diese Schlüssel für die Kommunikation mit der Bank benutzen.Beim Auftreten dieses Callbacks muss die Anwendung also die gerade empfangenen Schlüsseldaten der Bank (öffentlicher Signier-/Chiffrierschlüssel) geeignet anzeigen (Exponent, Modulus, Hash-Wert) und den Anwender auffordern, diese Daten mit denen aus dem INI-Brief zu vergleichen. Dieser Callback erwartet als Rückgabedaten einen Boolean-Wert (siehe
TYPE_BOOLEAN
). Sind die Daten in Ordnung, so muss die Callback-Methode einen leeren String in dem Rückgabedaten-StringBuffer zurückgeben, ansonsten füllt sie den StringBuffer mit einem beliebigen nichtleeren String (siehe dazucallback(org.kapott.hbci.passport.HBCIPassport,int,String,int,StringBuffer)
und die Beschreibung des Rückgabe-DatentypsTYPE_BOOLEAN
)).Da im Moment keine dokumentierten Methoden zur Verfügung stehen, um aus einem Passport die entsprechenden Schlüsseldaten zum Anzeigen zu extrahieren, wird folgendes Vorgehen empfohlen: die Anwendung erzeugt eine HBCICallback-Klasse, die von einer der bereits vorhandenen Default-Implementationen (
HBCICallbackConsole
,HBCICallbackSwing
, ...) abgeleitet ist. Tritt dieser Callback auf, so kann die Anwendung mitsuper.callback(...)
die bereits implementierte Version des entsprechenden Handlers aufrufen. In diesen Default-Implementationen werden zur Zeit nicht dokumentierte Passport-Funktionen benutzt, um die Schlüsseldaten zu extrahieren.- See Also:
-
HAVE_NEW_MY_KEYS
static final int HAVE_NEW_MY_KEYSUrsache des Callback-Aufrufes: neue Nutzerschlüssel generiert (INI-Brief erforderlich). Dieser Callback tritt nur bei Verwendung von RDH-Passports auf. Wird ein RDH-Passport neu erstellt, so werden für den Bankkunden neue Schlüssel für die Signierung und Verschlüsselung der HBCI-Nachrichten erzeugt. Die öffentlichen Teile dieser Schlüssel werden von HBCI4Java an die Bank gesandt. Diese schaltet die neuen Schlüssel aber erst dann frei, wenn ihre Authentizität durch einen INI-Brief bestätigt wird, den der Kunde erzeugen und ebenfalls an die Bank senden muss (per Post oder Fax).Nach der Schlüsselerzeugung und dem erfolgreichen Versand der Schlüsseldaten erzeugt HBCI4Java also diesen Callback. Die Anwendung muss in diesem Fall den Anwender darüber informieren, dass seine neuen Schlüssel erst dann freigeschaltet werden, wenn er einen entsprechenden INI-Brief generiert und zur Bank geschickt hat (und diese die Schlüsseldaten auf Übereinstimmung verglichen hat). Zum Generieren eines INI-Briefes kann das Tool
INILetter
benutzt werden, was Teil von HBCI4Java ist.Nachdem dieser Callback abgearbeitet wurde, wirft HBCI4Java eine Exception (
NeedKeyAckException
) und bricht damit die Ausführung des aktuellen HBCI-Dialoges ab. Ein HBCI-Dialog zum Ausführen von Geschäftsvorfällen kann erst dann wieder stattfinden, wenn die Bank die Schlüssel freigeschaltet hat. Wird ein HBCI-Dialog begonnen, obwohl die Bank die neuen Schlüssel noch nicht aktiviert hat, wird der HBCI-Server mit einer entsprechenden Fehlermeldung beim Initialisieren des HBCI-Dialoges antworten.- See Also:
-
HAVE_INST_MSG
static final int HAVE_INST_MSGUrsache des Callback-Aufrufes: Institutsnachricht erhalten. Tritt dieser Callback auf, so enthält dermsg
-Parameter dercallback
-Methode (siehecallback(org.kapott.hbci.passport.HBCIPassport,int,String,int,StringBuffer)
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:
-
NEED_REMOVE_CHIPCARD
static final int NEED_REMOVE_CHIPCARDUrsache des Callback-Aufrufes: Chipkarte soll aus Chipkartenterminal entfernt werden. Dieser Callback wird zur Zeit noch nicht benutzt.- See Also:
-
NEED_PT_PIN
static final int NEED_PT_PINUrsache 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:
-
NEED_PT_TAN
static final int NEED_PT_TANUrsache des Callback-Aufrufes: eine TAN für PIN/TAN-Verfahren benötigt. Dieser Callback tritt nur bei Verwendung von PIN/TAN-Passports auf. Benötigt HBCI4Java eine TAN, um eine digitale Signatur zu erzeugen, wird sie über diesen Callback abgefragt.- See Also:
-
NEED_CUSTOMERID
static final int NEED_CUSTOMERIDUrsache 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:
-
HAVE_CRC_ERROR
static final int HAVE_CRC_ERRORUrsache 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
dercallback
-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ückgabevariableretData
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 vonretData
unverändert), so übernimmt HBCI4Java die Kontodaten trotz des fehlgeschlagenen Prüfziffern-ChecksDie 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 (HBCIJob.addToQueue()
) 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 dessenHAVE_IBAN_ERROR
als Callback-Reason verwendet.- See Also:
-
HAVE_ERROR
static final int HAVE_ERRORUrsache des Callback-Aufrufes: Es ist ein Fehler aufgetreten, der auf Wunsch des Anwenders ignoriert werden kann. Durch Setzen bestimmter Kernel-Parameter (siehe
HBCIUtils.setParam(String,String)
) 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 alsmsg
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 imretData
Rückgabedaten-Objekt ein leerer String zurückgegeben wird, oder er kann erzwingen, dass HBCI4Java tatsächlich abbricht, indem ein nicht-leerer String imretData
-Objekt zurückgegen wird. Siehe dazu auch die Beschreibung des Rückgabe-DatentypsTYPE_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:
-
NEED_PASSPHRASE_LOAD
static final int NEED_PASSPHRASE_LOADUrsache 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:
-
NEED_PASSPHRASE_SAVE
static final int NEED_PASSPHRASE_SAVEUrsache 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:
-
NEED_SIZENTRY_SELECT
static final int NEED_SIZENTRY_SELECTUrsache 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 inretData
dann jeweils "0", "1" oder "4" zurückgegeben werden.- See Also:
-
NEED_CONNECTION
static final int NEED_CONNECTIONUrsache 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 vonnew HBCIHandler(...)
werden verschiedene Passport-Daten mit der Bank abgeglichen, dabei wird u.U. mehrmalsNEED_CONNECTION
/CLOSE_CONNECTION
aufgerufen. Evtl. sollte der Callback-Handler der Anwendung in diesem Fall also entsprechende Maßnahmen treffen.- See Also:
-
CLOSE_CONNECTION
static final int CLOSE_CONNECTIONUrsache 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 CallbackNEED_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:
-
NEED_FILTER
static final int NEED_FILTERUrsache des Callback-Aufrufes: es wird die Bezeichnung des zu verwendenden Datenfilters benötigt. Mögliche Filterbezeichnungen sind "
None
" (kein Filter) und "Base64
" (Daten BASE64-kodieren). Die jeweilige Filterbezeichnung ist inretData
zurückzugeben. Dieser Callback tritt zur Zeit nur bei Verwendung von PIN/TAN-Passports auf, weil hier nicht alle Banken einheitlich mit der gleichen Art der Filterung arbeiten.Normalweise wird bei PIN/TAN der
Base64
-Filter benutzt. Wenn bei dessen Verwendung aber keine Antwortdaten von der Bank empfangen werden, dann sollte die andere Variante (None
) ausprobiert werden.- See Also:
-
NEED_PT_SECMECH
static final int NEED_PT_SECMECHUrsache des Callbacks: bei Verwendung von HBCI-PIN/TAN muss eines der unterstützten Verfahren ausgewählt werden. Seit FinTS-3.0 gibt es mehrere Verfahren für PIN/TAN - das "normale" Einschrittverfahren sowie mehrere Zweischritt-Verfahren. Unterstützt eine Bank mehr als ein Verfahren, so wird dieser Callback erzeugt, damit der Anwender das zu verwendende Verfahren auswählen kann.
Dazu wird in
retData
ein String mit folgendem Format an die Callback-Methode übergeben: "ID1:Beschreibung1|ID2:Beschreibung2...
". Jedes Token "ID:Beschreibung
" steht dabei für ein unterstütztes PIN/TAN-Verfahren. Die Callback-Methode muss die ID des vom Anwender ausgewählten PIN/TAN-Verfahrens anschließend inretData
zurückgeben.- See Also:
-
NEED_PROXY_USER
static final int NEED_PROXY_USERUrsache 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-Parameterclient.passport.PinTan.proxyuser
gesetzt wurde- See Also:
-
NEED_PROXY_PASS
static final int NEED_PROXY_PASSUrsache 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-Parameterclient.passport.PinTan.proxypass
gesetzt wurde- See Also:
-
HAVE_IBAN_ERROR
static final int HAVE_IBAN_ERRORUrsache des Callbacks: beim Überprüfen einer IBAN ist ein Fehler aufgetreten. inretData
wird die fehlerhafte IBAN übergeben. Der Nutzer sollte die IBAN korrieren. Die korrigierte IBAN sollte wieder inretData
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 auchHAVE_CRC_ERROR
.- See Also:
-
NEED_INFOPOINT_ACK
static final int NEED_INFOPOINT_ACKDeprecated.- See Also:
-
NEED_PT_TANMEDIA
static final int NEED_PT_TANMEDIAUrsache des Callbacks: bei Verwendung von HBCI-PIN/TAN muss die Bezeichnung des TAN-Mediums eingegeben werden. Bei smsTAN ist das z.Bsp. der Alias-Name des Mobiltelefons, wie er bei der Bank hinterlegt wurde. Dieser Name wird verwendet, damit die SMS mit der TAN an mehrere Mobiltelefone schicken kann.
- See Also:
-
NEED_PT_PHOTOTAN
static final int NEED_PT_PHOTOTANUrsache 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:
-
NEED_PT_QRTAN
static final int NEED_PT_QRTANUrsache des Callback-Aufrufes: eine QR-Code-TAN für PIN/TAN-Verfahren benötigt. Dieser Callback tritt nur bei Verwendung von PIN/TAN-Passports mit dem QRCODE-TAN-Verfahren auf. Im Callback wird im StringBuffer der Wert aus dem HHDuc uebergeben. Das sind die Roh-Daten des Bildes. HBCI4Java enthaelt eine Klasse "QRCode", mit dem diese Daten dann gelesen werden koennen.- See Also:
-
NEED_PT_DECOUPLED
static final int NEED_PT_DECOUPLEDUrsache des Callback-Aufrufes: Das Decoupled Verfahren wird verwendet und eine Statusabfrage muss durchgeführt werden, um zu prüfen, ob der Kunde den Prozess bestätigt hat.- See Also:
-
NEED_PT_DECOUPLED_RETRY
static final int NEED_PT_DECOUPLED_RETRYUrsache des Callback-Aufrufes: Das Decoupled Verfahren wird verwendet und eine weitere Statusabfrage muss durchgeführt werden, um zu prüfen, ob der Kunde den Prozess bestätigt hat. Kann nur nachNEED_PT_DECOUPLED
auftreten, wenn der Kunde den Prozess immer noch nicht bestätigt hat. InretData
steht die minimale Wartezeit vor der Statusabfrage in Sekunden. Sollte der callback vor Ablauf dieser Zeit returned werden, pausiert HBCI4Java den Thread für die restliche Zeit.- See Also:
-
WRONG_PIN
static final int WRONG_PINUrsache des Callbacks: falsche PIN eingegeben
- See Also:
-
USERID_CHANGED
static final int USERID_CHANGEDim Parameter retData stehen die neuen Daten im Format UserID|CustomerID drin
- See Also:
-
TYPE_NONE
static final int TYPE_NONEerwarteter Datentyp der Antwort: keiner (keine Antwortdaten erwartet)- See Also:
-
TYPE_SECRET
static final int TYPE_SECRETerwarteter Datentyp der Antwort: geheimer Text (bei Eingabe nicht anzeigen)- See Also:
-
TYPE_TEXT
static final int TYPE_TEXTerwarteter Datentyp der Antwort: "normaler" Text- See Also:
-
TYPE_BOOLEAN
static final int TYPE_BOOLEANerwarteter 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:
-
STATUS_SEND_TASK
static final int STATUS_SEND_TASKKernel-Status: Erzeuge Auftrag zum Versenden. Als Zusatzinformation wird bei diesem Callback dasHBCIJob
-Objekt des Auftrages übergeben, dessen Auftragsdaten gerade erzeugt werden.- See Also:
-
STATUS_SEND_TASK_DONE
static final int STATUS_SEND_TASK_DONEKernel-Status: Auftrag gesendet. Tritt auf, wenn zu einem bestimmten Job Auftragsdaten empfangen und ausgewertet wurden. Als Zusatzinformation wird dasHBCIJob
-Objekt des jeweiligen Auftrages übergeben.- See Also:
-
STATUS_INST_BPD_INIT
static final int STATUS_INST_BPD_INITKernel-Status: hole BPD. Kann nur während der Passport-Initialisierung (HBCIHandler(String,org.kapott.hbci.passport.HBCIPassport)
) 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:
-
STATUS_INST_BPD_INIT_DONE
static final int STATUS_INST_BPD_INIT_DONEKernel-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 einProperties
-Objekt mit den neuen BPD übergeben.- See Also:
-
STATUS_INST_GET_KEYS
static final int STATUS_INST_GET_KEYSKernel-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 (sieheHBCIHandler(String,org.kapott.hbci.passport.HBCIPassport)
) und bei Verwendung von RDH als Sicherheitsverfahren auftreten. Es werden keine zusätzlichen Informationen übergeben.- See Also:
-
STATUS_INST_GET_KEYS_DONE
static final int STATUS_INST_GET_KEYS_DONEKernel-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:
-
STATUS_SEND_KEYS
static final int STATUS_SEND_KEYSKernel-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:
-
STATUS_SEND_KEYS_DONE
static final int STATUS_SEND_KEYS_DONEKernel-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:
-
STATUS_INIT_SYSID
static final int STATUS_INIT_SYSIDKernel-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 (sieheHBCIHandler(String,org.kapott.hbci.passport.HBCIPassport)
) auftreten. Es werden keine Zusatzinformationen übergeben.- See Also:
-
STATUS_INIT_SYSID_DONE
static final int STATUS_INIT_SYSID_DONEKernel-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:
-
STATUS_INIT_UPD
static final int STATUS_INIT_UPDKernel-Status: hole UPD. Kann nur während der Passport-Initialisierung (HBCIHandler(String,org.kapott.hbci.passport.HBCIPassport)
) 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:
-
STATUS_INIT_UPD_DONE
static final int STATUS_INIT_UPD_DONEKernel-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 einProperties
-Objekt mit den neuen UPD übergeben.- See Also:
-
STATUS_LOCK_KEYS
static final int STATUS_LOCK_KEYSKernel-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:
-
STATUS_LOCK_KEYS_DONE
static final int STATUS_LOCK_KEYS_DONEKernel-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:
-
STATUS_INIT_SIGID
static final int STATUS_INIT_SIGIDKernel-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 (sieheHBCIHandler(String,org.kapott.hbci.passport.HBCIPassport)
) auftreten. Es werden keine Zusatzinformationen übergeben.- See Also:
-
STATUS_INIT_SIGID_DONE
static final int STATUS_INIT_SIGID_DONEKernel-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:
-
STATUS_DIALOG_INIT
static final int STATUS_DIALOG_INITKernel-Status: Starte Dialog-Initialisierung. Dieser Status-Callback zeigt an, dass HBCI4Java eine Dialog-Initialisierung startet. Es werden keine zusätzlichen Informationen übergeben.- See Also:
-
STATUS_DIALOG_INIT_DONE
static final int STATUS_DIALOG_INIT_DONEKernel-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:
-
STATUS_DIALOG_END
static final int STATUS_DIALOG_ENDKernel-Status: Beende Dialog. Wird ausgelöst, wenn HBCI4Java den aktuellen Dialog beendet. Es werden keine zusätzlichen Daten übergeben.- See Also:
-
STATUS_DIALOG_END_DONE
static final int STATUS_DIALOG_END_DONEKernel-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:
-
STATUS_MSG_CREATE
static final int STATUS_MSG_CREATEKernel-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:
-
STATUS_MSG_SIGN
static final int STATUS_MSG_SIGNKernel-Status: Signiere HBCI-Nachricht. Dieser Callback wird aufgerufen, wenn HBCI4Java die ausgehende HBCI-Nachricht signiert. Es werden keine zusätzlichen Informationen übergeben.- See Also:
-
STATUS_MSG_CRYPT
static final int STATUS_MSG_CRYPTKernel-Status: Verschlüssele HBCI-Nachricht. Wird aufgerufen, wenn HBCI4Java die ausgehende HBCI-Nachricht verschlüsselt. Es werden keine zusätzlichen Informationen übergeben.- See Also:
-
STATUS_MSG_SEND
static final int STATUS_MSG_SENDKernel-Status: Sende HBCI-Nachricht (bei diesem Callback ist daspassport
-Objekt immernull
). Wird aufgerufen, wenn die erzeugte HBCI-Nachricht an den HBCI-Server versandt wird. Es werden keine zusätzlichen Informationen übergeben.- See Also:
-
STATUS_MSG_DECRYPT
static final int STATUS_MSG_DECRYPTKernel-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:
-
STATUS_MSG_VERIFY
static final int STATUS_MSG_VERIFYKernel-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:
-
STATUS_MSG_RECV
static final int STATUS_MSG_RECVKernel-Status: Empfange HBCI-Antwort-Nachricht (bei diesem Callback ist daspassport
-Objekt immernull
). Wird aufgerufen, wenn die Antwort-HBCI-Nachricht vom HBCI-Server empfangen wird. Es werden keine zusätzlichen Informationen übergeben.- See Also:
-
STATUS_MSG_PARSE
static final int STATUS_MSG_PARSEKernel-Status: Parse HBCI-Antwort-Nachricht (bei diesem Callback ist daspassport
-Objekt immernull
). Wird aufgerufen, wenn HBCI4Java versucht, die empfangene Nachricht zu parsen. Es wird der Name der erwarteten Nachricht als zusätzliche Information übergeben.- See Also:
-
STATUS_SEND_INFOPOINT_DATA
static final int STATUS_SEND_INFOPOINT_DATADeprecated.- See Also:
-
STATUS_MSG_RAW_SEND
static final int STATUS_MSG_RAW_SENDWird 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 mitSTATUS_MSG_RAW_RECV
) die gesendeten und empfangenen rohen HBCI-Nachrichten enthaelt. Sinnvoll zum Debuggen der Kommunikation mit der Bank.- See Also:
-
STATUS_MSG_RAW_RECV
static final int STATUS_MSG_RAW_RECVWird 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 mitSTATUS_MSG_RAW_SEND
) die gesendeten und empfangenen rohen HBCI-Nachrichten enthaelt. Sinnvoll zum Debuggen der Kommunikation mit der Bank.- See Also:
-
STATUS_MSG_RAW_RECV_ENCRYPTED
static final int STATUS_MSG_RAW_RECV_ENCRYPTEDWie STATUS_MSG_RAW_RECV - jedoch noch vor der Entschluesselung der Daten. Abhaengig vom HBCI-Verfahren kann die Nachricht aber auch hier bereits entschluesselt sein. Naemlich bei HBCI-Verfahren, bei denen die Verschluesselung nicht auf im HBCI-Protokoll selbst stattfindet sondern auf dem Transport-Protokoll. Konkret ist das PIN/TAN. Bei Schluesseldatei und Chipkarte hingegen ist die Message zu diesem Zeitpunkt hier noch verschluesselt.- See Also:
-
-
Method Details
-
log
Wird aufgerufen, wenn der HBCI-Kernel eine Log-Ausgabe erzeugt. HBCI4Java gibt Logging-Ausgaben nicht selbst auf irgendeinem Device aus, sondern sendet diese mit Hilfe der Methodelog(...)
an die Anwendung. Diese muss selbst entscheiden, was mit der Information geschehen soll (einfach ignorieren, abspeichern, dem Nutzer anzeigen, ...).- Parameters:
msg
- die eigentliche Text-Meldung des HBCI-Kernelslevel
- Loglevel, welcher die "Wichtigkeit" dieser Meldung angibt. Die möglichen Werte dafür sind inHBCIUtils
definiert und lautenLOG_CHIPCARD
LOG_DEBUG
LOG_INFO
LOG_WARN
LOG_ERR
date
- Zeitpunkt, zu dem die Logausgabe generiert wurdetrace
- einStackTrace
-Element, welches die Stelle im Code beschreibt, an der die Logausgabe erzeugt wurde (kann benutzt werden, um die Klasse, Methode, Zeilennummer etc. des Aufrufes zu ermitteln)
-
callback
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 Parameterdatatype
fest, wie diese Daten erwartet werden. Die eigentlichen Daten muss die Anwendung im ObjektretData
ablegen (keinen neuen StringBuffer erzeugen, sondern den Inhalt vonretData
ü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 CallbacksHAVE_CRC_ERROR
zu beachten!- Parameters:
passport
- enthält das Passport-Objekt, bei dessen Benutzung der Callback erzeugt wurde. Falls also in einer Anwendung mehrere Passport-Objekte gleichzeitig benutzt werden, so kann anhand dieses Parameters festgestellt werden, welches Passport (und damit welches HBCIHandle) HBCI4Java gerade benutzt.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 Parameterreason
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 gleichTYPE_NONE
, so werden keine Antwortdaten (also keine Nutzereingabe) erwartet, beiTYPE_SECRET
undTYPE_TEXT
wird ein normaler String erwartet.
Der Unterschied zwischen beiden ist der, dass beiTYPE_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.
-
status
Wird vom HBCI-Kernel aufgerufen, um einen bestimmten Status der Abarbeitung bekanntzugeben.- Parameters:
passport
- gibt an, welches Passport (und damit welches HBCIHandle) benutzt wurde, als der Callback erzeugt wurde (siehe auchcallback(org.kapott.hbci.passport.HBCIPassport,int,String,int,StringBuffer)
).statusTag
- gibt an, welche Stufe der Abarbeitung gerade erreicht wurde (alle oben beschriebenen Konstanten, die mitSTATUS_
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 einzelnenSTATUS_*
-Tag-Konstanten zu entnehmen.
-
status
Kurzform fürstatus(HBCIPassport, int, Object[])
für den Fall, dass dasObject[]
nur ein einziges Objekt enthält -
useThreadedCallback
boolean useThreadedCallback(HBCIPassport passport, int reason, String msg, int datatype, StringBuffer retData) Legt fest, ob ein Callback asynchron oder über den threaded-callback-Mechanismus behandelt werden soll. Im "Normalfall" gibt diese Methode
false
zurück, womit die asynchrone Callback-Behandlung aktiviert wird. Für bestimmte Anwendungsfälle ist jedoch eine synchrone Callback-Behandlung sinnvoll. Dazu muss zunächst das zu verwendende Callback-Objekt in einer Instanz der KlasseHBCICallbackThreaded
gekapselt werden. Außerdem muss diese Methode so überschrieben werden, dass sie für alle Callbacks, die synchron behandelt werden sollen,true
zurückgibt.Die übergebenen Parameter entsprechen denen der Methode
callback(HBCIPassport, int, String, int, StringBuffer)
. Der Rückgabewert gibt ab, ob dieser Callback synchron (true
) oder asynchron (false
) behandelt werden soll.Mehr Informationen dazu in der Datei
README.ThreadedCallbacks
.
-