Feld-Platzhalter Verwendung bei Document XML Exportservice

[rpfischer]

Hallo Herr Balzuweit,

wie, bereits im Installations und Einrichtungsbereich des Forums geschildert, funktioniert das Scannen und Heften fast wunschgemäß, der Export macht aber noch Probleme. Da ich einige Daten zu den gescannten Dokumenten möglichst automatisiert in einer Excel Tabelle eintragen will, habe ich mich nach einigen Tests für die Nutzung des Document XML Exportservice entschieden. Die Belege werden zwar exportiert, die Namensauflösung der XML Datei bzw. der Verzeichnisse bereitet jedoch Kopfzerbrechen, da ich auch hier schon einige Konfigurationen durchprobiert habe.

In das Feld Import file habe ich den Pfad D:\Test\%DokumentNr\%timestamp.xml eingetragen. Diese Konfiguration erzeugt beim Export der Dokumente zwei Unterverzeichnisse im Pfad D:\Test, nämlich %DokumentNr und 7okumentNr. In dem Verzeichnis %DokumentNr werden die Blobs abgelegt, in dem Ordner 7okumentNr die zugehörigen xml Dateien; die Timestamp wird korrekt aufgelöst. DokumentNr ist ein Feld, dass mit dem Barcode auf der Erstseite des Dokuments gefüllt wird und für jedes Dokument gefüllt sein muss. Ich hatte vorher die Ausgabe mit dem File Exportservice getestet und verschiedene Felder für die Benennung von Verzeichnissen und Dateien konfiguriert. Bei diesem Service wurden die Platzhalter korrekt aufgelöst.

Hier scheint jedoch der Platzhalter %DokumentNr beim Export der Blobs nicht aufgelöst zu werden, beim Export der XML Dateien wird der Anfang des Platzhalters als Tag (%d) interpretiert, der Rest als Text. Die Dokumentation hatte ich so verstanden, dass zumindest für das XML File auch Feld-Platzhalter verwendet werden können. Wenn ich hier %DokumentNr.xml eintrage, wird der Platzhalter aber auch wieder als 7okumentNr aufgelöst. Mache ich etwas falsch oder habe ich die Dokumentation falsch verstanden?

Wie bereits erwähnt würde ich gerne die Daten zu den exportierten Dokumenten automatisiert in eine Excel Tabelle eintragen. Ich habe bislang aber keine Möglichkeit gefunden, den Export zu skripten. Gibt es einen Event unmittelbar vor oder nach dem Export, den man hierfür nutzen könnte? Ist es möglich eine eigene Export Engine als DLL zu erstellen? Wenn ja, wie?

Vielen Dank vorab für Ihre Unterstützung!

[Dennis Balzuweit]

Hallo

* Bei der Verwendung des Platzhalters %DokumentNr wird zuerst %D als Tag aufgelöst und der Rest bleibt dann stehen. Hierzu einfach eindeutige Feldbezeichnungen im Schema verwenden. Wir setzen hier z.B. immer einen Prefix "h_" für Kopffelder und "p_" für Positionsfelder. Damit umgehen sie dieses Verhalten.

* Die Übergabe in eine Excel-Datei kann durchaus fordernd sein. Sofern Ihnen eine .csv Datei ausreicht, gibt es von uns den "Dynamic Importfile" Exportservice. Hier kann eine solche Datei generiert werden. Um eine .xls oder .xlsx Datei zu generieren müssten Sie auf Scripting zurückgreifen und die Microsoft Office API ansprechen. Das ist jedoch ein großes Thema für sich.

* Einen eigenen Export können Sie entweder selbst scripten (WARP Processing Script - siehe https://help.clarc-software.de/display/ ... +Scripting) oder eben auch eine eigene Export-Engine (Dll) entwickeln. Hierzu gibt es eine entsprechende Dokumentation: https://help.clarc-software.de/display/ ... ervice+API. Der deutlich einfachere Weg ist aber definitiv ein eigenes Export-Script zu schreiben. Damit sollte man fast alles abdecken können.

Ich hoffe ich konnte Ihnen erstmal etwas weiterhelfen.

Viele Grüße
Dennis Balzuweit

[rpfischer]

Hallo Herr Balzuweit,

vielen Dank für die erneute, sehr umfangreiche Rückmeldung. Sie haben mir mal wieder deutlich weitergeholfen.

Zum ersten Punkt:

Die Umbenennung war leider nicht erfolgreich. Jetzt wird die XML Datei mit dem Namen %h_DokumentNr.xml bzw. einer fortlaufenden Numerierung hinter dem Basisnamen exportiert. Ich habe alle drei Feldbezeichner im fields scheme umbenannt, d.h. den Technical name, Display name und den External field Bezeichner.

Zum zweiten Punkt:

Tatsächlich versuche ich, die Daten in eine LibreOffice Calc Tabelle zu importieren. Die API kenne ich relativ gut, habe aber, bis auf das Scripting der Import Recognition, keine Erfahrung mit Delphi - Pascal (ohne Objektorientierung) habe ich zuletzt im Studium genutzt, was mittlerweile eine ganze Weile her ist. Trotzdem Danke für den Hinweis

Zum dritten Punkt:

Das WARP Scripting Beispiel hatte ich mir bereits angesehen, war aber nicht auf den Gedanken gekommen, dass man hier den Export Prozess implementieren und damit die Export Engine ersetzen kann. Ist jedenfalls ein interessanter Ansatz, den ich wahrscheinlich mal ausprobieren werde. Bevorzugen würde ich allerdings die DLL Implementierung der Export Engine in C++, da mir diese Umgebung deutlich vertrauter ist. Danke für die Verlinkung der Hilfeseiten! Diese hatte ich bisher noch nicht entdeckt. Möglicherweise versuche ich auch erstmal, die DLL in Delphi/Lazarus zu implementieren. Wäre es Ihnen möglich, hierzu als Vorlage den Code der ccfileexport.dll zur Verfügung zu stellen? Das würde sicher sehr helfen, so wie auf der Import Seite das Beispiel Skript für die fixe Heftung geholfen hat, den Prozess zu verstehen und die eigene Heftung zu implementieren.

Vielen Dank vorab und ein schönes und sonniges Wochenende nach Stuttgart!
Rainer Fischer

[Dennis Balzuweit]

Hallo Herr Fischer,

freut mich wenn ich helfen kann.

Die Umbenennung war leider nicht erfolgreich. Jetzt wird die XML Datei mit dem Namen %h_DokumentNr.xml bzw. einer fortlaufenden Numerierung hinter dem Basisnamen exportiert. Ich habe alle drei Feldbezeichner im fields scheme umbenannt, d.h. den Technical name, Display name und den External field Bezeichner.

Hier gab es leider einen Fehler in der Dokumentation. In diesem Exportservice selbst können nur die Standardplatzhalter verwendet werden. Jedoch keine Feld-Platzhalter. Das sollte sich jedoch über die Möglichkeit umgehen lassen, dass man den Zielpfad auch über die "Export Destination" in der Anwendung oder einem WARP Script steuern kann. Dann sollten auch die Feld-Platzhalter funktionieren.

Das WARP Scripting Beispiel hatte ich mir bereits angesehen, war aber nicht auf den Gedanken gekommen, dass man hier den Export Prozess implementieren und damit die Export Engine ersetzen kann. Ist jedenfalls ein interessanter Ansatz, den ich wahrscheinlich mal ausprobieren werde. Bevorzugen würde ich allerdings die DLL Implementierung der Export Engine in C++, da mir diese Umgebung deutlich vertrauter ist. Danke für die Verlinkung der Hilfeseiten! Diese hatte ich bisher noch nicht entdeckt. Möglicherweise versuche ich auch erstmal, die DLL in Delphi/Lazarus zu implementieren. Wäre es Ihnen möglich, hierzu als Vorlage den Code der ccfileexport.dll zur Verfügung zu stellen? Das würde sicher sehr helfen, so wie auf der Import Seite das Beispiel Skript für die fixe Heftung geholfen hat, den Prozess zu verstehen und die eigene Heftung zu implementieren.

Den Code des File Exports kann ich Ihnen so leider nicht zur Verfügung stellen, da er zu viele interne Lib-Abhängigkeiten hat. Ich schaue aber mal was ich dazu noch finde und gebe Ihnen Bescheid.

Viele Grüße
Dennis Balzuweit

[Dennis Balzuweit]

...ich habe nochmal geschaut und auf der Dokumentationsseite für die Exportservice-Schnittstelle befindet sich auch ein komplettes Delphi Beispielprojekt (DelphiExample.Zip). Das sollte auf jeden Fall direkt mit der kostenlosen Delphi Community Version compiliert und in CLARC verwendet werden können.

Viele Grüße

[rpfischer]

Hallo Herr Balzuweit,

ich habe die ZIP Datei bisher nicht gefunden. Kann es ein Berechtigungsproblem sein, dass ich sie nicht sehe? Können Sie die Datei evtl. hier verlinken?

Beim Export bin ich ein gutes Stück weiter gekommen. Ich nutze den Dokument-XML Export Service und ein Post Export Script für die Übergabe der Daten in eine Excel Tabelle (derzeit ist es nur eine CSV Datei mit der Endung .xls - geht aber auch). Interessant dabei ist, dass ich die XML Datei gar nicht auswerten muss - alle Daten, die ich benötige, sind über ccDocument abrufbar. Optimal ist die Lösung nicht, weshalb ich gerne noch die Implementierung einer Export Engine DLL probieren möchte.

[Dennis Balzuweit]

Hallo Herr Fischer,

ich habe bemerkt, dass ich Ihnen zu Anfangs einen Link zu einer alten Version geschickt habe.
Hier der korrekte Link: https://help.clarc-software.de/display/ ... ervice+API
Zudem anbei noch das Beispielprojekt.

Interessant dabei ist, dass ich die XML Datei gar nicht auswerten muss - alle Daten, die ich benötige, sind über ccDocument abrufbar.

Sie können die Angabe und Verwendung eines Exportservice komplett auslassen und die gesamte Exportverarbeitung im PreProcessing-Script durchführen. Sie müssen dazu lediglich im Script noch die Angaben ccDocument.AllowProcessing := true; und nach erfolgreicher Verarbeitung ccDocument.DeleteFromQueue := true; setzen.

Viele Grüße und einen schönen Sonntag
Dennis Balzuweit

[rpfischer]

Hallo Herr Balzuweit

grundsätzlich scheint man tatsächlich auf die Export Engine verzichten zu können, nimmt dabei aber in Kauf, dass man die Scan Image Blobs direkt aus der CLARC Datenbank übernehmen muss, wofür man einen Connection String mit User und Password erstellen muss - oder habe ich eine Funktion zum Abrufen der Blobs übersehen? Eleganter wäre es, die Export Engine selbst zu implementieren, wobei ich allerdings auf Probleme stoße. Danke für die Bereitstellung des Beispiel Programms. Ich habe versucht, dieses mit Lazarus zu kompilieren. Dazu waren zwei Änderungen notwendig: In der ccexampleexport Code Datei musste der Parameter {$R *.res} auskommentiert werden, da sich der Compiler sonst beschwert, dass es keine ccexampleexport.res Datei gibt. In der ConfigUnit musste unter uses der Eintrag "jpeg" entfernt werden - die Unit ist wohl nicht vorhanden. Dann ließ sich die DLL erstellen. Im CLARC Configuration Center habe ich eine dummy Export Engine mit ccexampleexport.dll erstellt. Wenn ich diese Doppelklicke, erhalte ich die Fehlermeldung

Code: Alles auswählen

c4 plugin operation exception()

Diese Meldung findet sich auch in den logging Daten:

Code: Alles auswählen

18.10.22 17:41:05-955 localhost       trace.....: found offline help
18.10.22 17:41:15-501 localhost       trace.....: searching for /clarc/Engines/Export/dummy/ / ENGINE_EXPORT_ccexampleexport
18.10.22 17:41:15-577 localhost       trace.....: execpfnc 700 on Exportservices in key /clarc/Engines/Export/dummy
18.10.22 17:41:17-829 localhost       error.....: c4 plugin operation exception
18.10.22 17:41:17-923 localhost       trace.....: loading help from cloud for tag ENGINE_EXPORT_CCEXAMPLEEXPORT
18.10.22 17:41:18-032 localhost       trace.....: checking offline help for key /clarc/Engines/Export/dummy/

Leider kann ich aus der Information nicht ableiten, was hier genau schief läuft. Tritt der Fehler beim Aufruf der Funktion mit dem Code 700 , also der RollBack Funktion, auf? Können Sie mir hier evtl. weiterhelfen oder einen Tip geben, wo ich mit der Fehlersuche ansetzen kann?

Vielen Dank vorab!

[Dennis Balzuweit]

Hallo Herr Fischer,

die Images/Blobs bzw. die Referenz dazu müssen Sie nicht selbst aus der Datenbank holen.
Sie können dazu einfach auf die bestehenden Funktionen wie z.B. ccDocument.BlobCount oder ccDocument.GetFileName (https://help.clarc-software.de/display/ ... etFileName) zurückgreifen.

Mit Lazarus habe ich leider keinerlei Erfahrungen - ich hatte daher bzgl. Kompatibilität auf die Embarcadero Community Version verwiesen.
Die 700er FM bezieht sich auf das C4 Log, oder?
Was passiert denn bis dahin? Ich vermute Sie versuchen über das C4 den Plugin-Dialog zu öffnen, oder? Kommt dieser? Ist denn auch die 700er Plugin Funktion im Plugin integriert? Fragen über Fragen...

Viele Grüße

[Dennis Balzuweit]

Hallo Herr Fischer,

dürfte ich Sie fragen wie Sie auf unsere CLARC Community Version aufmerksam geworden sind?
Wir bewerben diese ja nicht gerade offensiv...

Viele Grüße
Dennis Balzuweit