Retry bei FTAM-DFUe-Problemen moeglich?

Hallo Holger,

leider nicht, da Sfirm32 bis jetzt zumindest keine selbständige Wiederholung der gescheiterten Aufträge anstösst, wie z. B. aus Multicash bekannt ist. Dies muss bisher manuell über Standardaufträge / Fremddateien rechts auf die Zahlung gehen / rechte Maustaste / sofort ausführen. Es wird der gescheiterte Auftrag erneut übertragen.

Tja; den 'Trick' mit der rechten Maustaste kenne ich. Nur: Die Abrufe erfolgen gegen 5 Uhr morgens, und wenn ich (etwas :-) später zum Dienst komme, sollte ich eigentlich nicht mit sowas belästigt werden...
Schlimm genug, dass SFirm eventuell vorhandene DTI-Dateien gnadenlos überschreibt. Ein "Retry" wäre doch eigentlich 'normal'...

"Das Übel an der Wurzel packen" würde ich gerne; aber es scheint keine LINUX-Version von FTAM zu geben?

Ich nutze von SFIRM _nur_ den Datei-Abruf; die Daten selbst werden mit einem Perl-Script per FTP zu einem IBM-Host übertragen. Auch das lässt sich ja mit dem AT-Befehl von Windows automatisieren.
Leider läuft Multicasch nicht mehr unter XP.

"Warum keinen zweiten Auftrag"

a) Kann ich 101% sicher sein, dass die Bank keine zweite Datei bereitstellt, die die erste wie bekannt gnadenlos überschreibt?

b) Ich habe es manchmal, dass -obwohl der erste von 10 Anrufen um 5:20 laufen soll- die Abholungen noch um 8:10 aktiv sind. 'Irgendeine' Verzögerung hat dafür gesorgt.

Kann es vielleicht mit der Abrufuhrzeit um 5 Uhr zusammenhängen, das dort das RZ noch nicht erreichbar ist?

Das kannst du so pasuchal nicht sagen.
Es kommt schon drauf an wie der Kunde die Daten bereitsgestellt haben möchte und ob die Art der Bereitstellung nicht auf ein Vorereignis (Auszugsschnitt z.B. bei Auzugsorientierter Bereitstellung) warten muss.

Bei uns ist der Auzugsschnitt mal auf 14:00 geändert worden, dann stehen die auzugsorientierten ELKO-Auszüge auch eben erst kurz danach bereit.

Grundsätzlich nimmt der Host aber zu jeder Tages- und Nachzeit Aufträge entgegen und gibt sie auch sofort ins Backend zur Verarbeitung weiter.

Also auf 5 Uhr würde ich nicht wetten...

Wie gesagt, kenne ich kein RZ welches "so spät" die Daten bereitstellt. Aber es lohnt sich die Institute zu fragen. Die wissen eigentlich immer die Zeiten wann die Systeme welche Läufe haben und wann die Bereitstellungen sind.
@Holger: Ist es immer ein bestimmtes Institut welches nicht klappt oder ist es unterschiedlich?
Wenn es immer das gleiche Institut ist würde ich meinen Vorschlag wieder ins Spiel bringen, einfach 5-10 Min. nach der letzten Abholung einen zweiten Abholauftrag einstellen.
Gruß
Karsten

Hallo,

vielleicht kannst Du einfach den Waitparameter etwas höher setzen. D. h., dass Sfirm32 zwischen den Übertragungen etwas länger wartet.

Dies kannst Du versuchen zu ändern unter Sfirm32 / CoConet / FT 000X-Verzeichnis in der Capi.ini. Diese solltest Du auf allen FT-Verzeichnissen anpassen.

Naja, standardmässig steht dieser Eintrag bereits auf 30.

; Key : WAIT_TIMER
; Funktion: Legt die maximale Dauer in Sekunden fest, die auf Capi-
; Nachrichten gewartet wird. Ausgenommen hiervon sind
; DATA_B3_IND-Nachrichten.
;
; erlaubt : > 0
; Default : 5
WAIT_TIMER = 30

Bin mir aber nicht sicher, ob dieser noch höher gestellt werden kann. Wenn ich mich richtig erinnere, ist der maximale Wert bereits 30. Ein Versuch ist es aber wert.

Also, dass die Wählleitungen an sich nicht ausreichen, kann ich mir nicht vorstellen, da standardmässig nur nach der nächst freien Leitung von Sfirm32 gesucht wird und ist diese da, dann wird die Übertragung gestartet.

Ich könnte mir vorstellen, dass einfach die Zeit zwischen den Wählversuchen nicht ausreicht. Also Sfirm32 baut die ISDN-Verbindung auf, bekommt beim 1. Versuch eine Verbindung zur Bank X, baut den B-Kanal wieder ab und versucht die nächste Verbindung aufzubauchen. Und genau hier blockt die Leitung, weil der B-Kanal einfach noch nicht frei ist.

Deshalb klappt die Verbindung gemäss Deinen Angaben ab und zu und ab und zu nicht.

den wait_timer kann man bis 40 stellen. alles dadrüber ist sinnlos. allerdings setzt das voraus das eine ältere sf32-version eingesetzt wird. Ab der 2.0h ist, glaube ich, nur noch das Omicron-FTAM-Modul unterstützt. Der Hinweis bezieht sich auf das Coconet-Modul. Im Omikron-Modul ist mir ein ähnlicher schalte nicht bekannt.

Gruß
Karsten

Leider gibt es eine automatische Wiederholung des Auftrages nicht mehr. Die Wiederholung (war in der 1.6 Version vorhanden) ist wohl deshalb unter den Tisch gefallen weil Kunden, die ein falsches DFUE Kennwort eingegeben hatten, durch die Wiederholungen gesperrt wurden.

Was Du aber machen koenntest waere folgendes:
Die DFUE-Auftraege fuer den Automaten werden im Sfirm Datenverzeichnis in der sfdfu.mdb gespeichert.
Nimm eine leere DFUE-Datenbank oder leere Deine vorhandene durch das loeschen aller DFUE-Auftraege (Extra->Reorg).
Lege den FTAM Auftrag zum abholen der Auszuege fuer die erste BPD-Datei/Bank an.
Kopiere die sfdfu.mdb beiseite.
Loesche den DFUE Auftrag und lege den naechsten Auftrag an und verfahre analog.
Am Schluss hast Du fuer jede Bank/BPD-Datei eine eigene sfdfu.mdb.
Nun laesst Du Dein Programm / Perlscript jeden morgen die vorhandene sfdfu.mdb sichern und durch die mit dem jeweiligen Kontoauszugsabholauftrag ersetzen. Das ersetzen laesst Du solange wiederholen bis das Auswerten des Automatenprotokolls erfolg oder keine Daten vorhanden meldet oder eine von Dir festgelegte maximale Anzahl der Wiederholungen erreicht ist.
Wenn alle sfdfu.mdb mit STA Auftraegen abgearbeitet sind die urspruengliche mdb wieder rein kopieren.

Der Automat pollt mit dem in seinen Optionen eingestelltem Intervall (n Minuten) die sfdfu.mdb und arbeitet die dort enthaltenen Auftraege ab. Falls der Zugriff auf die Datenbank fehlschlaegt gibt es eine Fehlermeldung und der Automat versucht es nach dem Ablauf des Intervalles nochmal.

Das ist zwar ein bischen Bastelarbeit , aber wenn Du eh mit Perl eine automatische Weiterverarbeitung steuerst sollte das kein Problem darstellen. Ich hoffe das die Idee dahinter und die funktionsweise des Automaten im Zusammenspiel mit der sfdfu.mdb ruebergekommen ist.

MfG

Jan