# Feldübernahme und Verhalten bei Drag'n'Drop von E-Mails aus Outlook **URL:** \ **Category:** enaio®\ **Tags:** tip\ **Created:** [7. April 2021 um 07:51 UTC](https://ecm.community/t/felduebernahme-und-verhalten-bei-dragndrop-von-e-mails-aus-outlook/93 "2021-04-07T07:51:00Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![rk](https://ecm.community/user_avatar/ecm.community/rk/32/679_2.png) [@rk](https://ecm.community/u/rk)\ **Post date:** [7. April 2021 um 07:51 UTC](https://ecm.community/t/felduebernahme-und-verhalten-bei-dragndrop-von-e-mails-aus-outlook/93/1 "2021-04-07T07:51:00Z")
Weil ich es wieder gesucht habe und zumindest via Suche in der offiziellen Anleitung ([help.enaio.com/…/…?q=emaildrop](https://help.optimal-systems.com/enaio/v910/admin/administrator/de/Search.htm?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@`] 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: ```ini [EMAILDROP@262160] FROM=MAIL_FROM TO=MAIL_TO CC=MAIL_CC DATE=MAIL_SUBMIT_TIME SUBJECT=MAIL_SUBJECT BODY=MAIL_BODY ShowNoDialog=0 ``` ---
**Author:** ![ag](https://ecm.community/user_avatar/ecm.community/ag/32/687_2.png) [@ag](https://ecm.community/u/ag)\ **Post date:** [17. August 2021 um 14:17 UTC](https://ecm.community/t/felduebernahme-und-verhalten-bei-dragndrop-von-e-mails-aus-outlook/93/2 "2021-08-17T14:17:11Z")
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](https://ecm.community/uploads/default/original/1X/c934ebde25c7fae3164b78b6958612b51dfac1fe.png) 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'](https://help.optimal-systems.com/enaio/v910/admin/administrator/de/services/e_tsk_services-mailstorage.htm) ) `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. ```auto - 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. ---
**Author:** ![rk](https://ecm.community/user_avatar/ecm.community/rk/32/679_2.png) [@rk](https://ecm.community/u/rk)\ **Post date:** [18. August 2021 um 05:11 UTC](https://ecm.community/t/felduebernahme-und-verhalten-bei-dragndrop-von-e-mails-aus-outlook/93/3 "2021-08-18T05:11:26Z")
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. ---
**Author:** ![bb](https://ecm.community/letter_avatar_proxy/v4/letter/b/7ba0ec/32.png) [@bb](https://ecm.community/u/bb)\ **Post date:** [23. August 2021 um 13:00 UTC](https://ecm.community/t/felduebernahme-und-verhalten-bei-dragndrop-von-e-mails-aus-outlook/93/4 "2021-08-23T13:00:58Z")
**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.