Feldübernahme und Verhalten bei Drag'n'Drop von E-Mails aus Outlook

enaio®
1

Weil ich es wieder gesucht habe und zumindest via Suche in der offiziellen Anleitung (help.enaio.com/…/…?q=emaildrop) keinen Eintrag dazu gefunden habe:

In der as.cfg des enaio-Servers kann für jeden E-Mail-Dokumenttyp eine Sektion ergänzt werden, welche das Verhalten beim Drag’n’Drop von E-Mails aus Outook steuert.

Die Sektion ist dabei [EMAILDROP@<Typ-ID des E-Mail-Objekts>] zu bennennen, also zum Beispiel [EMAILDROP@262160]

Dabei kann mit der Option ShowNoDialog bestimmt werden, ob nach dem Drag’n’Drop-Vorgang das Öffnen der Verschlagwortungsmaske unterdückt werden soll. Über die Optionen FROM, TO usw. können die entsprechenden internen Namen angepasst werden, wenn diese nicht dem Standard entsprechen.

Im Ganzen wären das dann bespielsweise:

[EMAILDROP@262160]
FROM=MAIL_FROM
TO=MAIL_TO
CC=MAIL_CC
DATE=MAIL_SUBMIT_TIME
SUBJECT=MAIL_SUBJECT
BODY=MAIL_BODY
ShowNoDialog=0
2 „Gefällt mir“
2

Ich möchte gerne ergänzen, was ausser der oben genannten Anpassungen in der as.cfg zu beachten ist, falls man die E-Mail nicht als Typ E-Mail, sondern als Typ Dokument anlegen möchte:

enaio Editor

Alle Felder der Mail, insbesondere das Feld INDEX_DIGEST (hierzu später mehr) müssen auf der Indexdatenmaske des Dokuments hinterlegt sein.
image

Der Einfachheit halber sind die internen Namen Indexdaten in meinem Beispiel gleich, wie bei einer normalen Mail, aber bei Bedarf könnte man die Felder auch mit anderen internen Namen versehen.

ems-prod.yml

Innerhalb des config-Verzeichnisses des Service-Managers von enaio befindet sich die Datei ems-prod-yml.

In dieser muss der neue Dokumenttyp hinzugefügt werden.
Hierbei sind folgende Dinge zu beachten:

Name: Das ist der Anzeigename des Objekts
internalName des deduplicationContext: Das muss bei nicht E-Mail-Dokumenttypen zwingend INDEX_DIGEST anstatt MAIL_DIGEST sein, so wie wir es auch schon im Editor vorbereitet haben (siehe hierzu auch die offizielle Doku von Optimal Systems: Service 'mailstorage' )
showIndexdata: das auf true zu setzen, hilft, falls es auf der Maske noch (Pflicht-)Felder gibt, die manuell vor dem Speichern zu befüllen sind)
Unterhalb der Mail-Felder wurden in diesem Fall noch zusätzlich die Felder Source, Subject und Code vorbelegt.

- name: "Dokument"
      internalName: "SampleDoc"
      showIndexdata: true
      deduplicationContext:
              internalName: "INDEX_DIGEST"
              mode: NONE
      mappingFields:
       - internalName: "MAIL_FROM"
         extractionName: "OS:MailFrom"
       - internalName: "MAIL_TO"
         extractionName: "OS:MailTo"
       - internalName: "MAIL_CC"
         extractionName: "OS:MailCc"
       - internalName: "MAIL_SUBJECT"
         extractionName: "OS:Subject"
       - internalName: "MAIL_BODY"
         extractionName: "OS:MailBody"
       - internalName: "MAIL_SUBMIT_TIME"
         extractionName: "OS:MailDate"     
       - internalName: "Source"
         defaultValue: "E-Mail DragDrop"
       - internalName: "Subject"
         extractionName: "OS:Subject"
       - internalName: "Code"
         defaultValue: "10"

Debugging

Leider erhält man bei Fehlern bei der Ablage in enaio nur wenig aussagekräftige Fehlermeldungen.

Hilfreich ist daher das flow-Event-Log des Clients in dem die Felder dokumentiert sein sollten.

Bei Anpassungen an der ems-prod.yml muss der Service EMS neu gestartet werden. Funktioniert das nicht über die Service Manager gui, so kann auch der mailstorage- Task über den Task Manager beendet werden.

3 „Gefällt mir“
3

Vielen Dank für die ausführliche Ergänzung bzw. auch Richtigstellung: Mit den neueren enaio-Versionen ist die Konfiguration des EMS-Microservices soweit ich weiss immer sinnvoll. Die Besonderheit des INDEX_DIGEST-Felds bei Nicht-E-Mail-Typen ist wirklich tricky.

4

Ergänzend dazu:

Bei modulübergreifenden Dokumenttypen sollte unbedingt mainType: 6 in der ems-prod.yml gesetzt werden. Ansonsten werden die Anhänge von E-Mails ignoriert, wenn man über den AppConnector bei einem Aufruf mit dem Parameter complete=true (z.B. /api/documentfiles/__OSID__/pdf?complete=true ein PDF-Rendition des Objekts anfordert.

Hintergrund ist, dass der AppConnector bei einem Aufruf mit dem Parameter complete=true in der URL überprüft, ob es sich um eine E-Mail handelt (überprüft auf Haupttyp 6). Das ist bei abgelegten E-Mails in modulübergreifenden Dokumenttypen nicht der Fall, wenn mainType: 6 nicht explizit konfiguriert ist.

4 „Gefällt mir“