Fortuna Entwickler Blog

Hier wird Ihnen geholfen

Aktualisierung von DevArt Oracle DLL

Nach einer Übergabe in die Produktonsumgebung wird die aktuelle Version von DevArt geladen und unter \\VCENTER2\Entwickler-Tools\Datenbank\devart abgelegt.
Alle Entwickler aktualisieren daraufhin ihre lokale Installation von DevArt
Zudem wird der Entwicklungsserver //WEBENTW3 und der Buildserver //BUILDSERVER aktualisiert.
Diese Version bleibt dann unverändert und wird nciht im laufenden Entwicklungsprozess erneut aktualisiert.

Zur Übergabe auf die Testumgebung wird DevArt auf dem Testserver //WEBTESTDMZ3 aktualisiert und die Übergabe durchgeführt.

Nach der Übergabe in die Produktionsumgebung wird wieder wie oben verfahren.

Ausnahme von diesem Vorgehen: Es tritt in der Entwicklung ein Fehler auf, welcher auf die aktuell verwendete DevArt-Version schliessen lässt und durch eine neuere DevArt-Version beseitigen lässt. In diesem Falle wird die neue Version von DevArt geladen und unter \\VCENTER2\Entwickler-Tools\Datenbank\devart abgelegt, lokal, auf der Entwicklungsumgebung und dem Buildserver installiert.


Scan Programm

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.



Historisierung von Dokumenten in DBDOK

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:

  1. Einscannen, nochmal Einscannen vor Übertragung, Übertragung, Archivierung. Also: was passiert, wenn ein Dokument kurz nach dem Einscannen nochmal eingescannt wird.
  2. Einscannen, Übertragen, nochmal Einscannen, wieder Übertragen, Archivieren. Also: was passiert, wenn ein Dokument, welches bereits übertragen wurde, nochmals eingescannt wird.
  3. Einscannen, Übertragen, nochmal Einscannen, wieder Übertragen, nochmal Einscannen, wieder Übertragen, Archivieren. Also, was passiert, wenn ein Dokument mehrfach nach der Übertragung nochmals eingescannt wird.
  4. 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.
  5. 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.