Funktion store_in_cache (client.py) liefert bei Dokumenten mit mehreren Seiten keine Dokumente

Python/ecmind_blue_client
1

Wir haben feststellen können, dass die Server-API Funktion std.StoreInCache bei Dokumenten mit mehren Seiten auf Fehler läuft.

Blockquote
Aufzeichnung aus dem Server-Monitor
=== 5 Eingabeparameter ===
DocState (2) = 1
FileCount (2) = 0
Flags (2) = 1
dwObjectID (2) = 522173
dwObjectType (2) = 262144
=== 3 Ausgabeparameter ===
Extension (1) = jpg
MimeType (1) = image/jpeg
MimeTypeID (2) = 2
=== 2 Fehler ===
(oxjobstd) : 3251765823 = 0xc1d2023f = 575
Der Job StoreInCache hat einen Parameterkonflikt: Schreibzugriff auf gespeicherte Dokumente.

Als Alternative haben wir mit std.StoreInCacheByID getestet. Dies hat problemlos funktioniert.

Eventuell sollte man die Funktion in der client.py auf std.StoreInCacheByID umbauen.

2

Hallo @danielstraub, das ist ja merkwürdig, ich spreche mal mit @uw wie es sich bei der gleichen Funktion bei den Talend Components for enaio® gemacht ist und melde mich zurück.

3

Ich habe das gerade nochmals getestet:

grafik
grafik937×894 203 KB

Bei mir sieht es eigentlich gut aus:

grafik
grafik926×699 109 KB

grafik
grafik894×461 53.6 KB

Könntest Du Dein Problem noch näher aufdröseln? Oder betrifft dieses gar nicht die Helper-Funktion Client.store_in_cache()?

4

Hi @rk,

wir können es nachstellen. Es hängt anscheinend mit archivierten Dokumenten zusammen. Nur bei diesen laufen wir auf den von @danielstraub beschriebenen Fehler, wenn wir store_in_cache ausführen. Bei nicht archivierten Dokumenten läuft es wunderbar durch.

5

Hallo @bb, vielen Dank für den Hinweis. Ich erstelle auf meinem Testsystem ein virtuelles Archiv und prüfe dies. Feedback folgt.

6

Mein Test:

grafik → grafik

grafik

Dabei erhalte ich:

grafik
grafik933×695 86.4 KB

enaio sagt

Job StoreInCache has a parameter conflict: Write-access to saved documents.

grafik
grafik1016×607 9.21 KB

Ich glaube also, ich kann das nachstellen. :slight_smile:

7

Hi @rk,
das sieht nach einem konsistenten Verhalten aus :wink:
Ich hatte zunächst meine Zweifel, ob es nur am Archivierungszustand liegen kann, da dies ja eigentlich keine Rolle spielt, solange man mind. Leserechte hat…
Ich bin gespannt, was du rausfindest.
Viele Grüße, DANKE und ein schönes Wochenende!

8

Hi @rk ,
wie im Anfang des Threads angesprochen tritt das Verhalten interessanterweise mit der Funktion std.storeincachebyid nicht auf. Die API ist hier sehr konsistent :neutral_face:

9

Hallo @danielstraub,

keine Variante lässt in unseren Tests archivierte Dokumente ohne Fehler durch. Als Workaround habe ich jetzt eine weitere API-Funktion in den Client eingebaut: Client.store_in_cache_by_id(). Dieser kann man entsprechend des enaio-Gegenstücks keine Type-ID mitgegeben, weshalb die andere Funktion relevant bleibt (Performance wenn Type-ID bekannt).

@uw hat gerade den Merge Request bearbeitet, Update auf PyPi.org folgt in Kürze.

Danke für Eure Tests und Euer Feedback @bb und @danielstraub!

1 „Gefällt mir“