|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object | +--org.kapott.hbci.manager.HBCIUtils
Hilfsklasse für diverse Tools. Diese Klasse definiert nur statische Methoden und Konstanten. Sie kann nicht instanziiert werden.
Die wichtigsten Methoden dieser Klasse sind die Methoden zum Initialisieren des HBCI-Kernel
(init()
) sowie zum
Setzen von HBCI-Kernel-Parametern (setParam()
).
Kernel-Parameter können zu jedem beliebigen Zeitpunkt der Laufzeit einer Anwendung gesetzt werden.
Das Setzen eines Kernel-Parameters geschieht mit der Methode setParam()
. Dieser Methode
werden der Name eines Kernel-Parameters sowie der neue Wert für diesen Parameter übergeben. Alternativ
bzw. in Verbindung mit dieser Variante können diese Parameter in einer Datei abgelegt werden, die
beim Initialiseren des HBCI-Kernels eingelesen wird (via Properties.load()
).
Folgende Kernel-Parameter werden zur Zeit von verschiedenen Subsystemen des HBCI-Kernels ausgewertet:
client.product.name
und client.product.version
Diese beiden Parameter identifizieren die HBCI-Anwendung. Diese Daten werden von einigen HBCI-Servern ausgewertet, um bestimmte HBCI-Anwendungen besonders zu unterstützen. Werden diese Parameter nicht explizit belegt, so erhalten sie die Standardwerte "HBCI4Java" und "2.4". Es wird empfohlen, diese Werte nicht zu ändern.
client.passport.DDV.path
(für DDV-Passports)
Hier wird eingestellt, wo die Datei
mit den Zusatzdaten ("Hilfsmedium") gespeichert werden soll. Der
Dateiname für das Hilfsmedium setzt sich zusammen aus dem Wert
dieses Parameters sowie der Seriennummer der HBCI-Chipkarte.
Ein Wert von "/home/hbci/passports/
" führt also zur Speicherung
der Dateien im Verzeichnis /home/hbci/passports
, wobei der
Dateiname nur aus der Seriennummer der Chipkarte besteht ("/" am
Ende beachten!). Ein Wert von "/home/hbci/passports/card-
" führt
ebenfalls zur Speicherung der Dateien im Verzeichnis
/home/hbci/passports
, allerdings bestehen die Dateinamen jetzt
aus dem Prefix card- sowie der Seriennummer der Chipkarte.
In der Regel wird hier nur eine Pfadangabe verwendet werden, dabei darf aber auf keinen Fall der Slash (oder Backslash unter Windows) vergessen werden, da der Dateiname aus einer simplen Aneinanderkettung von Parameterwert und Seriennummer besteht.
client.passport.DDV.libname.ddv
(für DDV-Passports)
Hier wird der vollständige Dateiname (also mit Pfadangabe) der shared library (dynamisch ladbaren Bibliothek) angegeben, welche als Bindeglied zwischen Java und der CTAPI-Bibliothek für den Chipkartenleser fungiert. Diese Bibliothek wird bereits mit dem HBCI4Java-Paket mitgeliefert.
client.passport.DDV.libname.ctapi
(für DDV-Passports)
Mit diesem Parameter wird der komplette Dateiname (mit Pfad) der CTAPI-Bibliothek eingestellt, die die CTAPI-Schnittstelle für den zu verwendenden Chipkartenleser implementiert. Diese Bibliothek ist vom Hersteller des Chipkartenterminals zu beziehen.
client.passport.DDV.port
(für DDV-Passports)
Die logische Portnummer, an der der Chipkartenleser angeschlossen ist (i.d.R. 0, 1 oder 2, abhängig vom Anschluss (COM1, COM2, USB) und vom Treiber (manche Treiber beginnen mit der Zählung bei 1, andere bei 0)) (am besten ausprobieren). Achtung -- unter UN*X darauf achten, dass für den ausführenden Nutzer Schreib- und Leserechte auf das entsprechende Device (/dev/ttyS0, /dev/ttyUSB0 o.ä.) bestehen.
client.passport.DDV.ctnumber
(für DDV-Passports)
Die logische Nummer des Chipkartenterminals, die im weiteren Verlauf verwendet werden soll. Dies ist i.d.R. 0, falls mehrere Chipkartenterminals angeschlossen und in Benutzung sind, sind diese einfach durchzunummerieren.
client.passport.DDV.usebio
(für DDV-Passports)
Dieser Parameter kann entweder 0, 1 oder -1 sein und hat
nur Bedeutung, wenn die PIN-Eingabe direkt am Chipkartenterminal
erfolgt (also wenn client.passport.DDV.softpin
ungleich
1 ist und wenn ein Keypad am Chipkartenterminal vorhanden ist).
Wenn dieser Wert auf 1 gesetzt wird, so bedeutet das, dass die PIN-Eingabe nicht manuell erfolgt, sondern dass statt dessen biometrische Merkmale des Inhabers ausgewertet werden. Zurzeit ist dieses Feature speziell auf den Chipkartenleser PinPad-Bio von Reiner-SCT angepasst, bei dem einem Fingerabdruck eine PIN zugeordnet werden kann, deren Eingabe beim Auflegen des Fingers simuliert wird. Für andere biometriefähige Chipkartenterminals wird dieser Parameter wahrscheinlich nicht funktionieren, entsprechende Unterstützung ist aber geplant.
Durch das Setzen dieses Wertes auf 0 wird das Benutzen der Biometrie-Einheit definitiv abgeschaltet. Bei einem Wert von -1 wird automatisch geprüft, ob eine Biometrie-Einheit verfügbar ist. Wenn ja, so wird diese benutzt, ansonsten erfolgt die PIN-Eingabe über das Keypad des Chipkartenterminals
client.passport.DDV.softpin
(für DDV-Passports)
Dieser Parameter kann entweder 0, 1 oder -1 enthalten. Für alle Chipkartenterminals, die über keine eigene Tastatur zur Eingabe der PIN verfügen, ist er auf 1 zu setzen. Damit wird der HBCI-Kernel darüber informiert, dass die PIN vom Anwender über die PC-Tastatur einzugeben ist. Durch Setzen dieses Wertes auf 0 wird die PIN-Eingabe für das Keypad des Chipkartenlesers erzwungen.
Setzt man den Parameter auf -1, so wird automatisch erkannt, welches PIN-Eingabeverfahren bei dem jeweils verwendeten Chipkartenterminal zu benutzen ist.
client.passport.DDV.entryidx
(für DDV-Passports)
Prinzipiell kann auf einer DDV-Chipkarte mehr als ein Datensatz mit HBCI-Zugangsdaten gespeichert werden (bis zu fünf). Dieser Parameter legt fest, welcher der fünf Datensätze tatsächlich benutzt werden soll. Da in den meisten Fällen aber nur der erste Datensatzu tatsächlich belegt ist, wird dieser Parameter meist den Wert "1" haben (ist auch default, falls dieser Parameter gar nicht gesetzt ist).
client.passport.RDHNew.filename
(für RDHNew-Passports)
Dieser Parameter legt den Dateinamen der Schlüsseldatei fest. Diese Datei sollte am besten auf einem mobilen Datenträger (Diskette) gespeichert sein. Außerdem sollte ein Backup dieser Datei angefertigt werden, da bei Verlust der Schlüsseldatei keine HBCI-Kommunikation mehr möglich ist.
client.passport.RDHNew.init
(für RDHNew-Passports)
Dieser Parameter ist immer auf "1" zu setzen (wird nur intern anders verwendet).
client.passport.RDH.filename
(für RDH-Passports; diese Variante der
RDH-Passports sollte nicht mehr benutzt werden, sondern RDHNew
;
siehe Datei README.RDHNew
)
analog zu client.passport.RDHNew.filename
.
client.passport.RDH.init
(für RDH-Passports; diese Variante der
RDH-Passports sollte nicht mehr benutzt werden, sondern RDHNew
;
siehe Datei README.RDHNew
)
analog zu client.passport.RDHNew.init
.
client.passport.PinTan.filename
(für PIN/TAN-Passports)
Dieser Parameter legt den Dateinamen der "Schlüsseldatei" fest. Beim PIN/TAN-Verfahren handelt es sich nicht wirklich um eine Schlüsseldatei, da bei diesem Sicherheitsverfahren keine kryptografischen Schlüssel auf HBCI-Ebene eingesetzt werden. In dieser Datei werden also nur die HBCI-Zugangsdaten abgelegt.
client.passport.PinTan.certfile
(für PIN/TAN-Passports)
Dieser Parameter gibt den Dateinamen einer Datei an, die
ein Zertifikat für die Kommunikation via HTTPS (SSL-Verschlüsselung)
enthält. Diese Datei kann mit dem Tool keytool
erzeugt werden,
welches zur Java-Laufzeitumgebung gehört. Das Zertifikat (ein bestätigter
öffentlicher Schlüssel) kann i.d.R. von der Bank angefordert werden.
Dieser Parameter wird nur dann benötigt, wenn das SSL-Zertifikat der Bank
nicht mit dem defaultmäßig in die JRE eingebauten TrustStore überprüft
werden kann (also am besten erst ohne diesen Parameter ausprobieren -
wenn eine entsprechende Fehlermeldung erscheint, muss das jeweilige Zertifikat
von der Bank angefordert, mit keytool
konvertiert und hier
angegeben werden). Wenn ein entsprechendes Root-Zertifikat für die Überprüfung
gar nicht zur Verfügung steht, so kann mit dem Parameter
client.passport.PinTan.checkcert
die Zertifikatsüberprüfung
gänzlich deaktiviert werden.
client.passport.PinTan.checkcert
(für PIN/TAN-Passports)
Dieser Parameter steht defaultmäßig auf "1
". Wird dieser
Parameter allerdings auf "0
" gesetzt, so wird die Überprüfung
des Bank-Zertifikates, welches für die SSL-Kommunikation verwendet
wird, deaktiviert. Diese Vorgehensweise wird nicht empfohlen, da dann
Angriffe auf das SSL-Protokoll und damit auch auf die HBCI-Kommunikation
möglich sind. In einigen Fällen steht aber kein Root-Zertifikat für die
Überprüfung des SSL-Zertifikats der Bank zur Verfügung, so dass diese
Überprüfung abgeschaltet werden muss, um überhaupt eine Kommunikation
mit der Bank zu ermöglichen.
client.passport.PinTan.init
(für PIN/TAN-Passports)
Dieser Parameter ist immer auf "1" zu setzen (wird nur intern anders verwendet).
client.passport.SIZRDHFile.filename
(für SIZRDHFile-Passports)
Dieser Parameter legt den Dateinamen der SIZ-Schlüsseldatei fest. Dabei handelt es sich um die Schlüsseldatei, die von anderer HBCI-Software (z.B. StarMoney) erzeugt wurde.
Siehe dazu auch README.SIZRDHFile
client.passport.SIZRDHFile.libname
(für SIZRDHFile-Passports)
Dieser Parameter gibt den vollständigen Dateinamen der SIZ-RDH-Laufzeitbibliothek an. Diese Bibliothek ist nicht Teil von HBCI4Java, sondern muss separat von http://hbci4java.kapott.org heruntergeladen und installiert werden.
Siehe dazu auch README.SIZRDHFile
client.passport.SIZRDHFile.init
(für SIZRDHFile-Passports)
Dieser Parameter ist immer auf "1" zu setzen (wird nur intern anders verwendet).
Siehe dazu auch README.SIZRDHFile
client.passport.OpenHBCI.mediafile
(für OpenHBCI-Passports)
Dieser Parameter legt den
Dateinamen der Schlüsseldatei fest.
Siehe dazu auch Datei README.OpenHBCI
.
client.passport.OpenHBCI.datafile
(für OpenHBCI-Passports)
Dieser Parameter legt den
Dateinamen der Datei fest, in welcher die Informationen zu den einzelnen
HBCI-Zugängen gespeichert sind (i.d.R. .openhbci
im Homedirectory
des Nutzers). Siehe dazu auch Datei README.OpenHBCI
.
client.passport.OpenHBCI.init
(für OpenHBCI-Passports)
Dieser Parameter ist immer auf "1" zu setzen (wird nur intern anders verwendet).
client.passport.Anonymous.filename
(für Anonymous-Passports)
Dieser Parameter legt den Dateinamen der Schlüsseldatei fest.
client.passport.Anonymous.init
(für Anonymous-Passports)
Dieser Parameter ist immer auf "1" zu setzen (wird nur intern anders verwendet).
client.passport.default
Wird bei der Erzeugung eines Passport-Objektes
(AbstractHBCIPassport.getInstance()
)
nicht explizit angegeben, für welches Sicherheitsverfahren ein Passport-Objekt
erzeugt werden soll, so wird der Wert dieses Parameters
benutzt, um die entsprechende Variante auszuwählen. Gültige
Werte sind "DDV
", "RDHNew
", "RDH
" (nicht
mehr benutzen!), "PinTan
", "SIZRDHFile
", "OpenHBCI
"
oder "Anonymous
" (Groß-/Kleinschreibung beachten).
client.retries.passphrase
Ist das Passwort für die Entschlüsselung der Passport-Datei falsch, so kann die Eingabe so oft wiederholt werden, wie dieser Parameter angibt, bevor eine Exception geworfen und die weitere Programmausführung unterbrochen wird.
client.connection.localPort
Für Anwendungen, die sich hinter einer Firewall befinden, welche nur ausgehende Verbindungen mit bestimmten lokalen Portnummern zulässt (sowas soll's geben), kann mit diesem Parameter die Portnummer festgelegt werden, die lokal benutzt werden soll. Dieser Parameter hat im Moment nur bei "normalen" HBCI-Verbindungen Auswirkungen. Beim PIN/TAN-Verfahren wird eine HTTPS-Verbindung mit dem HBCI-Server aufgebaut, für diese Verbindung wird der localPort-Parameter im Moment noch nicht unterstützt.
kernel.kernel.xmlpath
(wird nicht gesetzt, zur Zeit nur intern benutzt)
kernel.kernel.blzpath
(wird nicht gesetzt, zur Zeit nur intern benutzt)
log.loglevel.default
Mit diesem Parameter kann eingestellt werden, welche vom HBCI-Kernel erzeugten Log-Ausgaben tatsächlich bis zur Anwendung gelangen. Dieser Parameter kann Werte von 1 (nur Fehlermeldungen) bis 5 (einschließlich aller Debug-Ausgaben) annehmen.
Bei Problemen mit dem Kernel diesen Level bitte auf 4 oder 5 setzen, alle erzeugten Log-Ausgaben protokollieren und zusammen mit einer Beschreibung des Problems an den Autor schicken.
kernel.rewriter
Einige HBCI-Server-Implementationen bzw. die Backend-Systeme einiger Banken halten sich nicht strikt an die in der HBCI-Spezifikation vorgeschriebenen Formate. Um solche Unzulänglichkeiten nicht direkt im HBCI-Kernel abfangen zu müssen, existieren sogenannte Rewriter-Module. Ein solches Modul ist für jeweils einen bekannten "Bug" zuständig. Kurz vor dem Versand und direkt nach dem Eintreffen von HBCI-Nachrichten werden diese durch alle registrierten Rewriter-Module geschickt. Für ausgehende Nachrichten werden hier u.U. nicht HBCI-konforme Veränderungen vorgenommen, die vom jeweiligen HBCI-Server so erwartet werden. Eingehende Nachrichten, die nicht HBCI-konform sind, werden so umgeformt, dass sie der Spezifikation entsprechen. Auf diese Art und Weise kann der HBCI-Kernel immer mit streng HBCI-konformen Nachrichten arbeiten. Siehe dazu auch die Paketdokumentation zum Paket org.kapott.hbci.rewrite.
Der Parameter kernel.rewriter
legt die Liste aller
Rewriter-Module fest, welche eingehende und ausgehende Nachrichten
durchlaufen sollen. Wird dieser Parameter nicht gesetzt, so
verwendet HBCI4Java eine default-Liste von aktivierten
Rewriter-Modulen (kann mit getParam(String)
ermittelt werden).
Wird dieser Parameter gesetzt, so wird die default-Einstellung
überschrieben. Es können mehrere zu durchlaufende Rewriter-Module
angegeben werden, indem sie durch Komma voneinander getrennt werden.
Die folgenden Parameter legen die Größe sog. Object-Pools fest, die
intern von HBCI4Java verwendet werden. Object-Pools stellen eine
Art Cache dar, um Instanzen häufig benutzter Klassen nicht jedesmal neu
zu erzeugen. Statt dessen werden nicht mehr benötigte Objekte in einem
Pool verwaltet, aus dem bei Bedarf wieder Objekte entnommen werden. Die
Größe der Pools für die einzelnen Objekttypen kann hier festgelegt werden.
Falls Speicherprobleme auftreten (OutOfMemory
-Exception), so sollten
diese Werte verringert werden. Durch Setzen eines Wertes auf "0
" wird
das Object-Pooling für die entsprechenden Objekte komplett deaktiviert.
Zur Zeit werden nur bei der Nachrichtenerzeugung und -analyse Object-Pools
verwendet. In der folgenden Auflistung steht in Klammern jeweils der
eingebaute default-Wert.
kernel.objpool.MSG
-- Pool für Nachrichten-Objekte (3)
kernel.objpool.SF
-- Pool für SF- (Segmentfolgen-) Objekte (128)
kernel.objpool.SEG
-- Pool für Segment-Objekte (256)
kernel.objpool.DEG
-- Pool für DEG- (Datenelementgruppen-) Objekte (256)
kernel.objpool.DE
-- Pool für Datenelement-Objekte (1024)
kernel.objpool.Sig
-- Pool für Signatur-Objekte (3)
kernel.objpool.Crypt
-- Pool für Crypt-Objekte (3)
kernel.objpool.Syntax
-- Pool für Daten-Objekte (=Werte in Nachrichten) (128 je Datentyp)
Mit den folgenden Parametern kann HBCI4Java veranlasst werden, beim Auftreten bestimmter Fehler keine Exception zu werfen, sondern diesen Fehler zu ignorieren bzw. den Anwender entscheiden zu lassen, ob der Fehler ignoriert werden soll. Bei den Fehlern handelt es sich hauptsächlich um Fehler, die beim Überprüfen von Eingabedaten und Institutsnachrichten bzgl. der Einhaltung der HBCI-Spezifikation auftreten.
Jeder der folgenden Parameter kann einen der Werte yes
,
no
oder callback
annehmen. Ist ein Parameter auf
no
gesetzt, so wird beim Auftreten des jeweiligen Fehlers
eine entsprechende Exception geworfen. Dieses Verhalten ist das Standardverhalten
und entspricht dem der Vorgängerversionen von HBCI4Java. Ist
ein Parameter auf yes
gesetzt, so wird der Fehler komplett
ignoriert. Es wird nur eine entsprechende Warnung mit Loglevel LOG_WARN
erzeugt. Wird ein Parameter auf callback
gesetzt, so wird ein
Callback mit dem Callback-Reason HAVE_ERROR
erzeugt, bei dem
die Callback-Message (Parameter msg
) die entsprechende Fehlermeldung
enthält. Gibt die Callback-Methode einen leeren String im retData
-Objekt
zurück, so bedeutet das für HBCI4Java, dass der entsprechende
Fehler ignoriert werden soll (so als wäre der Parameter auf yes
gesetzt). Ist der Rückgabestring nicht leer, so wird HBCI4Java eine
entsprechende Exception werfen, so als wäre der zugehörige Parameter gleich
no
. Nähere Informationen zu Callbacks befinden sich in der
Beschreibung des Interfaces HBCICallback
.
"Normalen" Benutzern von HBCI4Java ist dringend von der Verwendung dieser Parameter abzuraten, weil sie bei falscher Anwendung dazu führen können, dass HBCI4Java gar nicht mehr funktioniert. Diese Parameter sind nur für HBCI4Java-Entwickler (also mich ;-)) gedacht und sind hier nur der Vollständigkeit halber aufgeführt.
Eine genauere Beschreibung der einzelnen Parameter befindet sich in
der Properties-Template-Datei hbci.props.template
.
client.errors.ignoreJobResultStoreErrors
client.errors.ignoreWrongJobDataErrors
client.errors.ignoreWrongDataLengthErrors
client.errors.ignoreWrongDataSyntaxErrors
client.errors.ignoreAddJobErrors
client.errors.ignoreCreateJobErrors
client.errors.ignoreExtractKeysErrors
client.errors.ignoreDialogEndErrors
client.errors.ignoreSecMechCheckErrors
client.errors.ignoreVersionCheckErrors
client.errors.ignoreSignErrors
client.errors.ignoreMsgSizeErrors
client.errors.ignoreCryptErrors
client.errors.ignoreMsgCheckErrors
client.errors.allowOverwrites
client.errors.ignoreValidValueErrors
client.errors.ignoreSegSeqErrors
Field Summary | |
static int |
LOG_CHIPCARD
Loglevel für Chipkarten-Debug-Ausgaben (identisch mit LOG_SIZRDH ) |
static int |
LOG_DEBUG
Loglevel für Debug-Ausgaben |
static int |
LOG_ERR
Loglevel für Fehlerausgaben |
static int |
LOG_INFO
Loglevel für Informationen |
static int |
LOG_SIZRDH
Loglevel für Ausgaben der SIZ RDH native library (identisch mit LOG_CHIPCARD ) |
static int |
LOG_WARN
Loglevel für Warnungen |
Method Summary | |
static boolean |
checkAccountCRC(java.lang.String blz,
java.lang.String number)
Überprüft, ob gegebene BLZ und Kontonummer zueinander passen. |
static java.lang.String |
data2hex(byte[] data)
Wandelt ein Byte-Array in eine entsprechende hex-Darstellung um. |
static java.lang.String |
date2String(java.util.Date date)
Wandelt ein gegebenes Datumsobjekt in einen String um |
static byte[] |
decodeBase64(java.lang.String st)
Dekodieren eines Base64-Datenstroms. |
static void |
done()
Bereinigen aller HBCI4Java-Datenstrukturen. |
static void |
doneThread()
Aufräumen der Datenstrukturen für aktuelle ThreadGroup . |
static java.lang.String |
encodeBase64(byte[] x)
Gibt Daten Base64-encoded zurück. |
static java.lang.String |
exception2String(java.lang.Exception e)
Erzeugen eines Strings, der die Ursache einer Exception beschreibt. |
static java.lang.String |
exception2StringShort(java.lang.Exception e)
Erzeugen eines Strings, der die Messages einer Exception und deren Ursache-Exceptions enthält. |
static java.lang.String |
getBICForBLZ(java.lang.String blz)
Gibt zu einer gegebenen Bankleitzahl den BIC-Code zurück. |
static java.lang.String |
getNameForBLZ(java.lang.String blz)
Ermittelt zu einer gegebenen Bankleitzahl den Namen des Institutes. |
static java.lang.String |
getParam(java.lang.String st)
Gibt den aktuellen Wert eines bestimmten HBCI-Parameters zurück. |
static java.lang.String |
getParam(java.lang.String st,
java.lang.String def)
Gibt den aktuellen Wert eines bestimmten HBCI-Parameters zurück. |
static void |
init(java.lang.ClassLoader cl,
java.lang.String configfile,
HBCICallback callback)
Initialisieren der HBCI4Java-Umgebung. |
static void |
initThread(java.lang.ClassLoader cl,
java.lang.String configfile,
HBCICallback callback)
Initialisieren der HBCI4Java-Umgebung für eine neue ThreadGroup . |
static void |
log(java.lang.Exception e)
Ausgabe der Meldungen einer Exception-Kette mit dem Level LOG_ERR . |
static void |
log(java.lang.Exception e,
int level)
Ausgabe der Meldungen einer Exception-Kette über den Log-Mechanismus des HBCI-Kernels. |
static void |
log(java.lang.String st,
int level)
Ausgabe eines Log-Strings über den Log-Mechanismus des HBCI-Kernels. |
static void |
setParam(java.lang.String key,
java.lang.String value)
Setzt den Wert eines HBCI-Parameters. |
static java.util.Date |
string2Date(java.lang.String date)
Wandelt einen String, der ein Datum in der lokalen Form enthält, in ein Datumsobjekt um |
static java.util.Date |
string2Time(java.lang.String date)
Wandelt einen String, der eine Uhrzeit in der lokalen Form enthält, in ein Datumsobjekt um |
static java.util.Date |
strings2Date(java.lang.String date,
java.lang.String time)
Wandelt übergebene Datums- und Zeitangaben in ein Date-Objekt um |
static java.lang.String |
time2String(java.util.Date date)
Wandelt ein gegebenes Datums in einen String um, der die Uhrzeit enthält |
Field Detail |
public static final int LOG_ERR
public static final int LOG_WARN
public static final int LOG_INFO
public static final int LOG_DEBUG
public static final int LOG_CHIPCARD
LOG_SIZRDH
)
public static final int LOG_SIZRDH
LOG_CHIPCARD
)
Method Detail |
public static void init(java.lang.ClassLoader cl, java.lang.String configfile, HBCICallback callback)
Initialisieren der HBCI4Java-Umgebung. Diese Methode muss vor allen anderen HBCI-Methoden aufgerufen werden. Hiermit wird die HBCI4Java-Laufzeitumgebung initialisiert. Dazu gehören das Laden verschiedener Dateien aus dem HBCI4Java-Classpath (Dateien für die Lokalisierung von Nachrichten, Verzeichnis der Banken usw.) sowie das Initialisieren einiger interner Datenstrukturen.
Zusätzlich wird in dieser Methode die Methode initThread()
aufgerufen, um alle Datenstrukturen, die ThreadGroup
-weise verwaltet werden,
für die aktuelle ThreadGroup
zu initialisieren. Siehe dazu auch die Dokumentation
zu initThread()
sowie die Datei
README.MultiThread
.
cl
- der ClassLoader, der zum Laden von configfile
verwendet werden soll.configfile
- der Name des zu ladenden Property-Files.callback
- das zu verwendende Callback-Objekt. Beim Aufruf dieser Methode
darf callback
niemals null
sein (im Gegensatz
zum Aufruf von initThread
, um weitere ThreadGroups
zu initialisieren).public static void initThread(java.lang.ClassLoader cl, java.lang.String configfile, HBCICallback callback)
Initialisieren der HBCI4Java-Umgebung für eine neue
ThreadGroup
. Soll HBCI4Java in
einer multi-threaded Anwendung verwendet werden, bei der mehrere Threads
gleichzeitig HBCI4Java benutzen, so muss für jeden solchen
Thread eine separate ThreadGroup
angelegt
werden. Jede dieser ThreadGroup
s muss mit dieser Methode
für die Benutzung von HBCI4Java initialisiert werden. Alle
HBCI-Kernel-Parameter sowie die HBCI-Callbacks werden für jede
ThreadGroup
separat verwaltet, so dass jede
ThreadGroup
also einen eigenen Satz dieser Daten benutzt.
Der Thread, in dem die Methode HBCIUtils.init()
aufgerufen wird,
muss nicht zusätzlich mit initThread()
initialisiert
werden, das wird automatisch von der Methode init()
übernommen.
Siehe dazu auch die Datei README.MultiThreading
in
den HBCI4Java-Archiven.
Ist der Parameter configfile
ungleich null
, so
wird versucht, ein Property-File mit default-Einstellungen für die
HBCI-Kernel-Parameter für die aktuelle ThreadGroup
zu laden. Der Name des
Property-Files wird durch den Parameter configfile
bestimmt.
Wie dieser Name interpretiert wird, um das Property-File tatsächlich zu
finden, hängt von dem zum Laden benutzten ClassLoader ab. Im Parameter
cl
kann dazu eine ClassLoader-Instanz übergeben werden,
deren getRessource
-Methode benutzt wird, um das Property-File
zu lokalisieren und zu laden. Wird kein ClassLoader angegeben (cl==null
),
so wird zum Laden des Property-Files der ClassLoader benutzt, der auch zum
Laden der aufrufenden Klasse benutzt wurde.
Achtung: Dieser Default-ClassLoader ist in den
meisten Fällen ein ClassLoader, der in einem JAR-File bzw. im aktuellen CLASSPATH
nach Ressourcen sucht. Soll ein Property-File von einer bestimmten Stelle im Filesystem
geladen werden, so sollte hier statt dessen der ClassLoader
new FileSystemClassLoader()
benutzt werden. In diesem Fall wird der angegebene Dateiname als relativer
Pfad von der Wurzel des Dateisystems aus interpretiert.
Eine Demonstration befindet sich im Tool
AnalyzeReportOfTransactions
.
Außerdem wird mit dieser Methode ein Callback-Objekt registriert, welches von HBCI4Java für die Kommunikation mit der Anwendung verwendet wird.
cl
- der ClassLoader, der verwendet werden soll, um das Property-File
configfile
zu laden (mit der Methode
ClassLoader.getRessource()
). Ist dieser Parameter
null
, so wird der ClassLoader verwendet, der auch zum
Laden der Klasse benutzt wurde, die die aufrufende Methode enthält.configfile
- der Name des zu ladenden Property-Files. Ist dieser Parameter
null
, kein Property-File geladen.callback
- ein Objekt einer HBCICallback
-Klasse, das benutzt
wird, um Anfragen des Kernels (benötigte Daten, benötige
Chipkarte, wichtige Informationen während der Dialog-Ausführung etc.)
an die Anwendung weiterzuleiten.
Siehe dazu HBCICallback
.
Jede ThreadGroup
kann ein eigenes Callback-Objekt registrieren,
welches dann für alle HBCI-Prozesse innerhalb dieser ThreadGroup
verwendet wird. Wird beim Initialisieren einer ThreadGroup
kein callback
-Objekt angegeben (callback==null
),
dann wird für diese ThreadGroup
das Callback-Objekt der
"Eltern-ThreadGroup
" verwendet. Die "initiale" ThreadGroup
,
die mit HBCIUtils.init()
initialisiert wird, muss ein public static void doneThread()
ThreadGroup
. Alle
ThreadGroups
, die via initThread()
initialisiert wurden, sollten kurz vor deren Ende mit dieser Methode wieder
"aufgeräumt" werden, damit HBCI4Java die entsprechenden Datenstrukturen
für diese ThreadGroup
wieder freigeben kann.
public static void done()
init()
kann HBCI4Java wieder re-initialisiert werden.
public static java.lang.String getParam(java.lang.String st, java.lang.String def)
ThreadGroup
wird ein separater
Satz von HBCI-Parametern verwaltet.
st
- Name des HBCI-Parametersdef
- default-Wert, falls dieser Parameter nicht definiert ist
public static java.lang.String getParam(java.lang.String st)
ThreadGroup
wird ein separater
Satz von HBCI-Parametern verwaltet.
st
- Name des HBCI-Parameters
public static java.lang.String getNameForBLZ(java.lang.String blz)
blz
- die Bankleitzahl
public static java.lang.String getBICForBLZ(java.lang.String blz)
blz
- Bankleitzahl der Bank
public static void setParam(java.lang.String key, java.lang.String value)
Klassenbeschreibung
zur dieser Klasse.
Für jede ThreadGroup
wird ein separater
Satz von HBCI-Parametern verwaltet.
key
- Name des HBCI-Parameters.value
- neuer Wert des zu setzenden HBCI-Parameterspublic static void log(java.lang.String st, int level)
st
- der auszugebende Stringlevel
- die "Wichtigkeit" dieser Meldung. mögliche Werte:
LOG_ERR
LOG_WARN
LOG_INFO
LOG_DEBUG
LOG_CHIPCARD
(wird nur intern benutzt)public static void log(java.lang.Exception e)
LOG_ERR
.
e
- die Exception, deren getMessage()
-Meldungen geloggt
werden sollenpublic static java.lang.String exception2String(java.lang.Exception e)
getCause()
-Strings der Exception e
und deren Cause
rekursiv aneinandergekettet werden. Zusätzlich wird am
Ende ein kompletter StackTrace angehängt. Der Ergebnisstring hat also die folgende Form:
e.getMessage() -> e.getCause().getMessage() -> e.getCause().getCause().getMessage() ... e.printStackTrace();
e
- Exception, deren Messages zusammengefasst werden sollen
public static java.lang.String exception2StringShort(java.lang.Exception e)
exception2String(Exception)
, allerdings wird bei dieser Methode
kein StackTrace (e.printStackTrace()
) angehängt.
e
- Exception, deren Messages zusammengefasst werden sollen
public static void log(java.lang.Exception e, int level)
getCause()
-Exceptions
verfolgt und deren Meldung ausgegeben. Enthält keine der Exceptions dieser
Kette eine Message, so wird statt dessen ein Stacktrace ausgegeben.
e
- die Exception, deren getMessage()
-Meldungen ausgegeben
werden sollen.level
- der Log-Level, mit dem die Meldungen geloggt werden sollen.
Siehe dazu auch log(String,int)
public static java.lang.String data2hex(byte[] data)
data
- das Byte-Array, für das eine Hex-Darstellung erzeugt werden soll
data
zwei Zeichen (0-9,A-F) enthält.public static java.lang.String date2String(java.util.Date date)
date
- ein Datum
public static java.util.Date string2Date(java.lang.String date)
date
- ein Datum in der lokalen Stringdarstellung
public static java.lang.String time2String(java.util.Date date)
date
- ein Datumsobjekt
public static java.util.Date string2Time(java.lang.String date)
date
- eine Uhrzeit in der lokalen Stringdarstellung
public static java.util.Date strings2Date(java.lang.String date, java.lang.String time)
date
- das Datum in der lokalen Darstellung (je nach defaultLocale())time
- die Uhrzeit in der lokalen Darstellung (darf null
sein)
public static java.lang.String encodeBase64(byte[] x)
x
- zu kodierende Daten
public static byte[] decodeBase64(java.lang.String st)
st
- Base64-kodierten Daten
public static boolean checkAccountCRC(java.lang.String blz, java.lang.String number)
Überprüft, ob gegebene BLZ und Kontonummer zueinander passen. Bei diesem Test wird wird die in die Kontonummer "eingebaute" Prüziffer verifiziert. Anhand der BLZ wird ermittelt, welches Prüfzifferverfahren zur Überprüfung eingesetzt werden muss.
Ein positives Ergebnis dieser Routine bedeutet nicht, dass das entsprechende Konto bei der Bank existiert, sondern nur, dass die Kontonummer bei der entsprechenden Bank prinzipiell gültig ist.
blz
- die Bankleitzahl der Bank, bei der das Konto geführt wirdnumber
- die zu überprüfende Kontonummer
true
wenn die Kontonummer nicht verifiziert werden kann (z.B.
weil das jeweilige Prüfzifferverfahren noch nicht in HBCI4Java
implementiert ist) oder wenn die Prüfung erfolgreich verläuft; false
wird immer nur dann zurückgegeben, wenn tatsächlich ein Prüfzifferverfahren
zum Überprüfen verwendet wurde und die Prüfung einen Fehler ergab
|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |