Übergabe von Scanprodukten an Fremdsysteme

Geändert am Mo, 23 Okt, 2023 um 2:56 NACHMITTAGS

Soll die Übergabe von CROSSCAP Scanprodukten an ein Folgesystem (typischerweise ein DMS) durch einen Import ins Folgesystem bewerkstelligt werden (also nicht durch eine dedizierte CROSSCAP Export-Funktion, wie sie z.B. für Saperion oder nscale existiert), dann sind dabei folgende Dinge zu beachten:

Formate zur Übergabe von Bild- und Indexdaten:

Bilddaten (die gescannten Abbilder der Papier-Originale) können entweder als Einzelbilder (z.B. JPG, BMP) übermittelt werden oder als sogenannte Multi-Page Formate. Genau zwei Multi-Page Formate stehen beim CROSSCAP Export zur Verfügung, TIF und PDF. Diese Datei-Formate fungieren als Container und können nicht nur mehrere Bilder in einer Ausgabedatei zusammenfassen sondern erlauben zusätzlich auch die Hinterlegung von sog. Bild-Metadaten (siehe weiter unten).
Indexdaten (auch Metadaten, also Bild-Zusatzinformationen) werden an Folgesysteme üblicherweise in Form von maschinenlesbaren Dateien übergeben. Dies sind entweder Dateien mit einer speziellen (proprietären) Formatierung (wie z.B. JPL-Dateien beim D3 DMS) oder sie sind angelehnt an standardisierte Formate (wie z.B. CSV-, TAB-separierte- oder XML-Dateien). In CROSSCAP werden derartige Dateien typischerweise mit der Export-Funktion Indexdatei erzeugt. Es handelt sich bei CROSSCAP Indexdateien im Grunde um Textdateien, welche aufgrund ihrer komplexen inneren Struktur andere bzw. standardisierte Dateiformate emulieren.
Zusätzlich existiert in CROSSCAP die Export-Funktion XML-Datei, welche eine fest vorgegebene XML-Struktur erzeugt. Diese enthält zwar grundsätzlich sämtliche alle anfallenden Index-, Barcode- und Datei-Informationen, aber aufgrund ihrer starren Struktur muss sich ein Folgesystem die benötigten Daten aus einer so entstandenen XML-Datei "herauspicken" - hier ist also typischerweise erhöhter Konfigurationsaufwand auf Seiten des Folgesystems nötig.
Sowohl in TIF-Dateien, als auch in PDF-Dateien existieren - vom Inhalt her - vordefinierte Metadatenfelder, welche ebenfalls die Aufnahme von Indexdaten erlauben. Allerdings werden diese Metadatenfelder üblicherweise nicht für die Übergabe an Folgesysteme genutzt, sondern richten sich eher an Menschen, die diese TIF- oder PDF-Dateien (irgendwann später) zu Gesicht bekommen.
Im Fall von PDF-Dateien besteht zusätzlich die Möglichkeit, sog. benutzerspezifische Metadatenfelder zu definieren. Hier lassen sich beliebige CROSSCAP Indexdaten in selbst definierten PDF Metadatenfeldern hinterlegen.
Des Weiteren besteht bei PDF-Dateien die Möglichkeit, CROSSCAP Indexdaten zur Erstellung eines Indexbaumes (über sog. Bookmarks) zu verwenden, welche den Anwendern bei größeren PDF-Dateien (mehrere dutzend bis hundert Seiten) die Orientierung innerhalb einer PDF-Datei erleichtern kann.

Auslösen des Import-Prozesses im Folgesystem:

Bei der hier beschriebenen Import-Methode erfolgt die Übergabe der Scanprodukte in zwei Schritten:
- Zuerst gibt CROSSCAP die fertigen Scanprodukte an einem definierten Ort (dem sog. Übergabeverzeichnis) vollständig ins Dateisystem aus.
- Erst danach importiert ein Folgesystem die Scanprodukte aus genau diesem Übergabeverzeichnis. Üblicherweise "orientiert" sich das Folgesystem dabei an den o.g. Metadaten-Dateien (welche deswegen häufig auch Import-Dateien genannt werden) und erfasst und kategorisiert die zu importierenden Bilddaten anhand der darin enthaltenen Informationen.
- Nach einem erfolgreichen Import werden die bislang verarbeiteten Scanprodukte typischerweise vom Folgesystem aus dem Übergabeverzeichnis gelöscht, um Platz für neue Exporte zu schaffen.
Der Import durch das Folgesystem kann auf verschiedene Weise gestartet werden:
- Manuell: Ein Anwender startet den Import-Prozess im Folgesystem im Bedarfsfall und von Hand. Bei geringem Export-Aufkommen (oder zu Testzwecken) mag diese Methode praktikabel sein, bei größerem bzw. regelmäßigem Export-Aufkommen ist sie indiskutabel.
- Automatisiert, von CROSSCAP ausgehend: Am Ende eines CROSSCAP Exports können Fremd-Programme (z.B. ein separat aufrufbarer Import-Prozess des Folgesystems) oder eigene Programm-Routinen (d.h. in CROSSCAP hinterlegte Export-PowerShell Skripte) aufgerufen werden. Dieses Vorgehen sorgt dafür, dass auf jeden CROSSCAP Export sofort und unweigerlich ein Import ins Fremdsystem folgt. Eine Signalisierung der Fertigstellung eines Exports durch CROSSCAP bzw. ein Handshake zwischen CROSSCAP und dem Fremdsystem ist bei diesem Vorgehen nicht nötig.
- Zeitgesteuert, vom Fremdsystem ausgehend: Im Folgesystem wird ein zeitgesteuerter Prozess definiert, welcher zyklisch (z.B. im Minutentakt) das Übergabeverzeichnis auf neue CROSSCAP Exporte hin untersucht. Dabei sucht dieser Prozess entweder nach einer neuen, noch nicht verarbeiteten Import-Datei (siehe oben) oder er sucht nach einer sog. Signal-Datei, welche einen vollständigen Export durch CROSSCAP signalisiert (siehe nächster Abschnitt).

Warten auf den Abschluss eines CROSSCAP Exports:

Wird der Import-Prozess zeitgesteuert oder von Hand ausgelöst (also nicht durch CROSSCAP selbst), dann ist eine Koordinierung zwischen dem CROSSCAP Export und dem Import durch das Folgesystem nötig: Zum Einen ist zu vermeiden, dass der Import ins Fremdsystem einen noch laufenden CROSSCAP Export stört, zum Anderen muss sichergestellt werden, dass beim Import ins Folgesystem keine noch unfertigen CROSSCAP Exportdateien erfasst werden. Abhängig von der CROSSCAP Systemumgebung stellt dies ein mehr oder weniger großes Problem dar:
- CROSSCAP Enterprise System (Mehrplatz-Lösung), direkter Export ausgeschaltet:
  Hier erfolgt die Erzeugung und ggf. Signatur aller Scanprodukte in einer verborgenen, internen Netzwerk-Freigabe, dem sog. Work-Verzeichnis. Erst wenn alle Ausgabedateien erzeugt und ggf. signiert wurden, werden sie gemeinsam (und üblicherweise schnell genug) in das eigentliche Ausgabeverzeichnis (Zielverzeichnis) umkopiert. Insofern bekommt der Importer eines Folgesystems immer den bereits abgeschlossenen CROSSCAP-Export "zu Gesicht".
  Fazit: In einem solchen Szenarium müssen üblicherweise keine besonderen Maßnahmen zur Koordinierung von CROSSCAP und dem Importer des Fremdsystems getroffen werden. Vorausgesetzt, dass die abschließende Kopier-Aktion zügig genug vonstatten geht, können von der Index-Funktion erzeugte Index-Dateien zum Auslösen des Imports verwendet werden.
  Ausnahme: Wird ein Export-PowerShell-Skript verwendet, um die vom Importer des Fremdsystems benötigten Trigger-Dateien zu erstellen, dann kann dies prinzipbedingt erst im Ausgabeverzeichnis (Zielverzeichnis) erfolgen. In diesen Fällen ist das Export-PowerShell-Skript so zu gestalten, dass solche Dateien unter anderem Namen angelegt werden (z.B. mit einer temporären Datei-Endung, die den Importprozess des Fremdsystems nicht auslöst) und erst abschließend so umbenannt werden, dass sie vom Importer als Trigger erkannt werden.
- CROSSCAP Enterprise System, direkter Export eingeschaltet, mit Signatur:
  Sobald eine Signatur zugeschaltet wird, behandelt CROSSCAP Enterprise diesen Stapel wie oben: CROSSCAP Enterprise System (Mehrplatz-Lösung), direkter Export ausgeschaltet ...
  Fazit: In einem solchen Szenarium müssen üblicherweise keine besonderen Maßnahmen zur Koordinierung von CROSSCAP und dem Importer getroffen werden. Vorausgesetzt, dass die abschließende Kopier-Aktion zügig genug vonstatten geht, können Index-Dateien in diesem Fall zum Auslösen des Imports verwendet werden.
  Ausnahme: Wird ein Export-PowerShell-Skript verwendet, um die vom Importer des Fremdsystems benötigten Trigger-Dateien zu erstellen, dann kann dies prinzipbedingt erst im Ausgabeverzeichnis (Zielverzeichnis) erfolgen. In diesen Fällen ist das Export-PowerShell-Skript so zu gestalten, dass solche Dateien unter anderem Namen angelegt werden (z.B. mit einer temporären Datei-Endung, die den Importprozess des Fremdsystems nicht auslöst) und erst abschließend so umbenannt werden, dass sie vom Importer als Trigger erkannt werden.
- CROSSCAP Enterprise System, direkter Export eingeschaltet, ohne Signatur:
  Hier erfolgt die Erzeugung aller Scanprodukte direkt im Ausgabeverzeichnis (Zielverzeichnis). Insofern bekommt der Importer eines Folgesystems die Entstehung eines CROSSCAP Exportes "zu Gesicht", d.h. er kann im Zielverzeichnis die Erzeugung und Befüllung aller Ausgabedateien mitverfolgen - insbesondere wenn der Export umfangreich ist, kann dieser Prozess eine nennenswerte Zeit benötigen. Index-Dateien sollten in diesem Fall nicht zum Auslösen eines Imports verwendet werden. Index-Dateien werden bereits während des Exports angelegt und dann eine gewisse Zeit von CROSSCAP geöffnet gehalten. Dadurch würde ein Import-Prozess aber sehr wahrscheinlich verfrüht gestartet werden ...
  Fazit: In einem solchen Szenarium müssen üblicherweise Maßnahmen zur Koordinierung von CROSSCAP und dem Importer eines Fremdsystems getroffen werden - die Möglichkeiten hierzu sind:
  - Abschalten des direkten Exports (siehe oben)
  - Ideallösung: Koordinierung über eine sog. Signaldatei. CROSSCAP erzeugt eine solche Signaldatei erst dann, wenn alle anderen Export-Funktionen abgeschlossen wurden. Voraussetzung hierfür ist, dass der Importer eines Folgesystems derartige Signaldateien beachtet, d.h. dass er sich dadurch steuern lässt.
  - Work-Around: Erzeugen der als Import-Trigger verwendeten Index-Datei(en) unter anderem Namen (z.B. mit einer temporären Datei-Endung, die den Importprozess des Fremdsystems nicht auslöst). Über einen CROSSCAP Programmaufruf bzw. in einem Export-PowerShell-Skript kann dieser Dateityp dann am Ende des CROSSCAP-Exports so umbenannt werden, dass er vom Folgesystem wieder als Trigger für den Import-Prozess akzeptiert wird. So wie die Erzeugung einer Signaldatei werden externe Programmaufrufe oder die Ausführung von Export PowerShell-Skripten erst nach allen anderen Export-Funktionen gestartet ... insofern wird auch hierfür das Ende des Exports abgewartet.
- CROSSCAP All-in-One System (Einzelplatz-Lösung), ohne Signatur:
  Hier erfolgt grundsätzlich die Erzeugung aller Scanprodukte direkt im Ausgabeverzeichnis (Zielverzeichnis). Insofern bekommt der Importer eines Folgesystems die Entstehung eines CROSSCAP Exportes "zu Gesicht", d.h. er kann im Zielverzeichnis die Erzeugung und Befüllung aller Ausgabedateien mitverfolgen - insbesondere wenn der Export umfangreich ist kann dieser Prozess eine beträchtliche Zeit benötigen. Index-Dateien sollten in diesem Fall nicht zum Auslösen eines Imports verwendet werden. Index-Dateien werden bereits während des Exports angelegt und dann eine gewisse Zeit von CROSSCAP geöffnet gehalten. Dadurch würde ein Import-Prozess aber sehr wahrscheinlich verfrüht gestartet werden ...
  Fazit: In einem solchen Szenarium müssen üblicherweise Maßnahmen zur Koordinierung von CROSSCAP und dem Importer eines Fremdsystems getroffen werden - die Möglichkeiten hierzu sind:
  - Ideallösung: Koordinierung über eine sog. Signaldatei. CROSSCAP erzeugt eine solche Signaldatei erst dann, wenn alle anderen Export-Funktionen abgeschlossen wurden. Voraussetzung hierfür ist, dass der Importer eines Folgesystems derartige Signaldateien beachtet, d.h. dass er sich dadurch steuern lässt.
  - Work-Around: Erzeugen der als Import-Datei verwendeten Index-Datei unter anderem Namen (z.B. mit einer temporären Datei-Endung, die den Importprozess des Fremdsystems nicht auslöst). Über einen CROSSCAP Programmaufruf bzw. in einem Export-PowerShell-Skript kann dieser Dateityp dann am Ende des CROSSCAP-Exports so umbenannt werden, dass er vom Folgesystem wieder als Trigger für den Import-Prozess akzeptiert wird. So wie die Erzeugung einer Signaldatei werden externe Programmaufrufe oder die Ausführung von Export PowerShell-Skripten erst nach allen anderen Export-Funktionen gestartet ... insofern wird auch hierfür das Ende des Exports abgewartet.

CROSSCAP All-in-One System, mit Signatur:
Hier erfolgt grundsätzlich die Erzeugung aller Scanprodukte direkt im Ausgabeverzeichnis (Zielverzeichnis). Im Unterschied zu einem Export ohne Signatur wartet CROSSCAP in diesem Fall mit der Erzeugung von XML-Datei(en) (nicht aber Index-Dateien), bis die Signatur durchgeführt wurde. Da alle anderen Scanprodukte zu diesem Zeitpunkt bereits erstellt und signiert wurden, verbleibt nach der Signatur nur noch die Erstellung der XML-Datei(en). Erfolgt diese schnell genug, können XML-Datei(en) hier als Trigger für einen Import verwendet werden.
Anders ist die Situation bei Verwendung der Exportfunktion Index-Datei: Index-Dateien werden bereits vor der Signatur erzeugt ... In einem solchen Szenarium müssen daher bei der Verwendung von Import-Dateien Maßnahmen zur Koordinierung von CROSSCAP und dem Importer eines Fremdsystems getroffen werden - die Möglichkeiten hierzu sind:
- Ideallösung: Koordinierung über eine sog. Signaldatei. CROSSCAP erzeugt eine solche Signaldatei erst dann, wenn alle anderen Export-Funktionen abgeschlossen wurden. Voraussetzung hierfür ist, dass der Importer eines Folgesystems derartige Signaldateien beachtet, d.h. dass er sich dadurch steuern lässt.
- Work-Around: Erzeugen der als Import-Datei verwendeten Index-Datei unter anderem Namen (z.B. mit einer temporären Datei-Endung, die den Importprozess des Fremdsystems nicht auslöst). Über einen CROSSCAP Programmaufruf bzw. in einem Export-PowerShell-Skript kann dieser Dateityp dann am Ende des CROSSCAP-Exports so umbenannt werden, dass er vom Folgesystem wieder als Trigger für den Import-Prozess akzeptiert wird. So wie die Erzeugung einer Signaldatei werden externe Programmaufrufe oder die Ausführung von Export PowerShell-Skripten erst nach allen anderen Export-Funktionen gestartet ... insofern wird auch hierfür das Ende des Exports abgewartet.