Alle 30 Tage werden die KIIDs zu allen aktuellen Fonds automatisch nachts geladen. Manche KIIDs sind Passwortgewchützt. Dadurch können sie dann nicht in die Antragsmappe integriert werden; es kommt ein Fehler beim Erstellen der Antragsmappe.
Aus diesem Grund werden bei allen KIIDs morgens nach dem Herunterladen eventuell vorhandene Passwörter entfernt.
Die passiert derzeit mit der Testversion (Triel) von A-PDF Secuity
http://www.a-pdf.com/security/password.htm
Das Vorgehen ist einfach: Programm herunterladen, installieren, aufrufen
Batch-Verarbeitung auswählen -> Next
Add Dir -> KIID-Verzeichnis wählen -> Next -> Save
Das dauert dann ein wenig, weil alle PDFs geprüft werden.
Anschliessend liegen ale KIIDs ungeschützt vor. Fertig.
Mit der Umstellung auf DBDok wurde es auch notwendig, die Applikation zum Scannen von Dokumenten zu aktualisieren.
Hierzu wurde eine neue Applikation unter .NET erstellt; die Quellen sind im TFS unter /VWS/Tools/ScanToPDF abgelegt. Die Applikation verwendet iTextSharp (über nuget) und TwaiDotNet (referenziert aus /Fortuna/External/DLL) und zudem DevArt. Bei Letzterem ist darauf zu achten, daß die Lizenzinformationen mitgeliefert werden; dies geschieht in Visual Studio 2013 im Projekt über Tools -> Oracle -> License Information.
Danach kann man einfach eine Version als Release erstellen und das bin/Release-Verzeichnis auf den Ziel-PC kopieren. Ggf. kann man in der app.config noch Optionen anpassen; ansonsten ist die Anwendung sofort einsatzbereit.
Möglicher Zustand von Dokumenten
1. Noch nicht gescannt
2. DOK_CONTAINER_WORK auf GUTINGIA
3. DOK_CONTAINER auf ARCHIV
4. DOK_CONTAINER auf DBDOK
Den ersten Punkt kann man ausklammern. Es gibt noch kein gescanntes Dokument.
Bei 2. Wird das existierende Dokument verworfen und durch das neue ersetzt. Dies geschieht quasi zeitgleich. Da sich Dokumente nur sehr kurz in DOK_CONTAINER_WORK befinden, greift dieser Punkt üblicherweise nur, wenn beim Scannen ein Fehler auftrat, z.B. eine Seite nicht gescannt wurde, zwei Seiten auf einmal eingezogen wurden oder Ähnliches.
Bei 3. Und 4. greift dann die eigentliche Behandlung der Historisierung.
Betroffen bei Punkt 3 ist der Prozess, welcher Dokumente aus DOK_CONTAINER_WORK nach DOK_CONTAINER (auf ARCHIV) verschiebt: Gibt es zur DOK_NR bereits einen Eintrag in DOK_CONTAINER (ARCHIV), so wird dieser nach DOK_CONTAINER_HISTORIE (ARCHIV) verschoben und das neue Dokument in DOK_CONTAINER geschrieben. DOK_CONTAINER_HISTORIE hat neben den Felder aus DOK_CONTAINER zudem ein automatisch gesetzten Datumsfeld, sodass auch mehrere gleiche DOK-Nummern korrekt historisiert werden können.
Betroffen bei Punkt 4 ist zudem der Prozess, welcher Dokumente aus DOK_CONTAINER (ARCHIV) nach DOK_CONTAINER (DBDOK) verschiebt: Gibt es zur DOK_NR bereits einen Eintrag in DOK_CONTAINER (DBDOK), so wird dieser nach DOK_CONTAINER_HISTORIE (DBDOK) verschoben und das neue Dokument in DOK_CONTAINER geschrieben. DOK_CONTAINER_HISTORIE hat neben den Felder aus DOK_CONTAINER zudem ein automatisch gesetzten Datumsfeld, sodass auch mehrere gleiche DOK-Nummern korrekt historisiert werden können.
In diesem Zuge sind auch sämtliche Einträge aus DOK_CONTAINER_HISTORIE (ARCHIV) nach DOK_CONTAINER_HISTORIE (DBDOK) zu verschieben.
ToDo:
- Erstellen von DOK_CONTAINER_HISTORIE auf ARCHIV
- Erstellen von DOK_CONTAINER_HISTORIE auf DBDOK
- Anpassen des Prozesses beim Speichern eingescannter Dokumente
- Erweitern des Prozesses bei Übernahme der Dokumente aus DOK_CONTAINER_WORK nach DOK_CONTAINER (ARCHIV)
- Erstellen des Prozesses bei Übernahme der Dokumente aus DOK_CONTAINER (ARCHIV) nach DOK_CONTAINER (DBDOK)
DBDOK Abläufe.xlsx (14KB)
Hier habe ich die Abläufe dokumentiert, wie ich sie für möglich halte.
Tabellenblatt Variante 1 ist die ursprünglich gedachte Vorgehensweise; Tabellenblatt Variante 2 ist jene, die entsprechend dem Vorschlag von Torsten notwendig wäre. Änderungen im Vorgehen sind dort blau markiert.
Die Abläufe im Einzelnen:
- Einscannen, nochmal Einscannen vor Übertragung, Übertragung, Archivierung. Also: was passiert, wenn ein Dokument kurz nach dem Einscannen nochmal eingescannt wird.
- Einscannen, Übertragen, nochmal Einscannen, wieder Übertragen, Archivieren. Also: was passiert, wenn ein Dokument, welches bereits übertragen wurde, nochmals eingescannt wird.
- Einscannen, Übertragen, nochmal Einscannen, wieder Übertragen, nochmal Einscannen, wieder Übertragen, Archivieren. Also, was passiert, wenn ein Dokument mehrfach nach der Übertragung nochmals eingescannt wird.
- Einscannen, Übertragen, nochmal Einscannen, wieder Übertragen, Archivieren, nochmal Einscannen, wieder Übertragen, Archivieren. Also wie unter 3. aber dieses mal wird anschließend noch ein weiteres Mal eingescannt.
- Einscannen, Übertragen, nochmal Einscannen, wieder Übertragen, Archivieren, nochmal Einscannen, wieder Übertragen, nochmal Einscannen, wieder Übertragen, Archivieren. Also: Wie unter 4. aber es wird nach der ersten Archivierung noch mehrfach eingescannt.
Mittels des Befehlt DBDok_ToPDF.exe lassen sich Dokumente (TIFF) aus der Datenbank nach PDF umwandeln; mehrseitige Dokumente werden zusammengefasst und ins Archiv gespeichert.
Der Befehl akzeptiert verschiedene Parameter, die man in der Form /Parametername=Parameterwert anhängen kann und/oder in der zugehörigen .config-Datei hinterlegen kann:
- ConnectionString = Datenbankverbindung zur Quelldatenbank. Hieraus werden die TIFFs gelesen
- ConnectionStringDBDOK = Datenbankverbindung zur Zieldatenbank. Hierhin werden die PDFs geschrieben
- Executable = Pfad zu Tiff2Pdf.exe, welches intern aufgerufen wird, um ein TIFF in eine PDF zu wendeln
- WorkPath = Temporäres Arbeitsverzeichnis; Hier werden Arbeitsdateien zwischengelagert und eine Log-Datei fortgeschrieben
- DocMax = Anzahl der Maximal zu verarbeitenden Dokumente je Aufruf
- DocPerRun = Anzahl der zu verarbeitenden Dokumente je Durchlauf. Pro Durchlauf werden u.a. Datenbankverbindungen neu aufgebaut. Die ist notwendig, da es ansonsten mitunter zu Timeouts bei der Datenbankverbindung kommen kann.