Durchsuchbare Dokumentation aufrufen | Zurück zur Dokumentationsübersicht
Navigation: Dokumentationen agorum core > Konfigurationen zu E-Mails > Behandlung von eingehenden E-Mails
Ein ContentTask reagiert auf definierte Dokumentarten. Sobald diese Dokumentarten neu in agorum core angelegt werden oder sich deren Textinhalt ändert, führt das System einen Automatismus aus.
Ein Beispiel stellt der ContentTask MSG dar, der eine abgelegte msg-Datei automatisch in eine eml-Datei wandelt, die dann von allen E-Mail-Clients darstellbar ist. Das Original (der Inhalt der msg-Datei) bleibt dabei in der E-Mail erhalten.
Hinweis: Der ContentTask ist ein mächtiges Werkzeug und eignet sich für Prozesse, die bei Anlage und jeder Änderung von bestimmten Dateiformaten sofort ausgeführt werden müssen. Laden Sie etwa ein Bild in agorum core hoch, setzt das System automatisch Metadaten auf dieses Bild. Im Gegensatz zu Workern und Aktiven Ordnern starten ContentTasks synchron mit dem Schreibvorgang. Ein Fehler kann dazu führen, dass der Schreibvorgang fehlschlägt und etwa keinerlei Dateien mehr angelegt oder geändert werden können. Sollen Prozesse also nicht synchron ausgeführt werden, weil das Risiko, nicht mehr mit dem System zu arbeiten, zu hoch ist, setzen Sie Worker und Aktive Ordner ein.
Welche Methode Sie einsetzen, hängt vom Anwendungsszenario ab.
ContentTask
Wenn die Verarbeitung bei der Anlage / Änderung sofort stattfinden soll und generell auch auf geänderten Inhalt reagieren muss, nicht nur auf neue Objekte.
Worker
Wenn besonders große Datenmengen verarbeitet werden sollen.
Aktiver Ordner/CronJob
Alle anderen Szenarien
Die genannten ContentTasks werden als ImageMetaData bezeichnet.
Außerdem existieren folgende ContentTasks:
Die letzten vier ContentTasks (fett hervorgehoben) sind die relevantesten.
ACL
ACL | Beschreibung |
---|---|
ACL_ParseACJs | Definiert, welche Benutzergruppen / Benutzer diesen ContentTask verwenden dürfen. |
So finden Sie die ACL:
System/contenttask/ACL_ParseACJs
Hinweise:
Die dem Property-Eintrag ACL zugeordnete ACL muss sich selbst als Recht besitzen. Dies ist notwendig, da hier nur abgefragt wird, ob der Benutzer, der die ContentTask ausführen möchte, die ACL lesen kann. Für Benutzer / Benutzergruppen reicht daher ein Leserecht. Ist dies nicht vorhanden, wird die ContentTask nicht ausgeführt.
Wenn Sie keine ACL eintragen, kann jeder Benutzer den ContentTask verwenden.
Wenn Sie eine nicht vorhandene ACL eintragen, ist dieser ContentTask für alle Benutzer (auch Administratoren) gesperrt.
Wenn der ContentTask bei der Synchronisation eines Adapters ausgeführt werden soll, definieren Sie einen Benutzer mit den erforderlichen Rechten und tragen Sie ihn hier ein.
Standardmäßig ist kein Benutzer eingetragen, die ContentTask würde also bei Synchronisation eines Adapters nicht funktionieren.
Aufbau der Datei akte.ac.js:
/* global Packages, sc, folder */ // // folder = Ordner, in dem das Skript ausgeführt wird // sc = sessionController // let objects = require('common/objects'); let templates = require('common/templates'); folder.createPath(templates.fill( 'F ${xx:f}', { xx: '' + new Date()}));
Dieser ContentTask führt den agorum core-XML-Parser bei Neuanlage oder Änderung einer .ac.xml-Datei auf diese aus.
ACL
ACL | Beschreibung |
---|---|
ACL_ParseACXml | Definiert, welche Benutzergruppen / Benutzer diesen ContentTask verwenden dürfen. |
So finden Sie die ACL:
System/contenttask/ACL_ParseACXml
Hinweise:
Die dem Property-Eintrag ACL zugeordnete ACL muss sich selbst als Recht besitzen. Dies ist notwendig, da hier nur abgefragt wird, ob der Benutzer, der die ContentTask ausführen möchte, die ACL lesen kann. Für Benutzer / Benutzergruppen reicht daher ein Leserecht. Ist dies nicht vorhanden, wird die ContentTask nicht ausgeführt.
Wenn Sie keine ACL eintragen, kann jeder Benutzer den ContentTask verwenden.
Wenn Sie eine nicht vorhandene ACL eintragen, ist dieser ContentTask für alle Benutzer (auch Administratoren) gesperrt.
Wenn der ContentTask bei der Synchronisation eines Adapters ausgeführt werden soll, definieren Sie einen Benutzer mit den erforderlichen Rechten und tragen Sie ihn hier ein.
Standardmäßig ist kein Benutzer eingetragen, die ContentTask würde also bei Synchronisation eines Adapters nicht funktionieren.
Das folgende Beispiel und Vorgehen verdeutlicht, wie Sie Zusatzattribute für eine Datei setzen. Dazu benötigen Sie die Datei MeineDatei.pdf, für die Sie weitere Attribute vergeben möchten.
Tipp: Wenn die zweite Datei MeineDatei.pdf.ac.xml nicht gelöscht wird, können Sie die Attribute immer wieder ändern, indem Sie diese Datei ändern.
Aufbau der Datei MeineDatei.pdf.ac.xml:
<?xml version = "1.0" encoding =" ISO-8859-1"?> <ObjectList> <FileObject> <Update>./MeineDatei.pdf</Update> <ExtendedAttributesXML> <![CDATA[<Dateistatus DataType="STRING">offen</Dateistatus> <Dateitype DataType="STRING">testdatei</Dateitype>]]> </ExtendedAttributesXML> </FileObject> </ObjectList>
Dieser ContentTask erzeugt aus einer msg-/ eml-Datei ein agorum core-E-Mail-Objekt. Die Original-Datei wird mit in das E-Mail-Objekt abgelegt. Durch diesen Wandel können Sie alle Funktionen von agorum core verwenden, etwa Notizen hinzufügen, Verlinken, Metadaten anhängen, Volltextsuche usw.
Hinweis: Dateien, die über einen File-Adapter eingebunden sind, werden nicht gewandelt.
Template, mit dem vorgeben werden kann, wie der neue Dateiname erzeugt wird.
Folgende Platzhalter existieren:
Platzhalter | Beschreibung |
---|---|
CreateDate | Anlegedatum |
SentDate | Sendedatum |
Subject | Betreff |
OriginalName | Ursprünglicher Dateiname der E-Mail |
Extension | Dateiendung |
ID | ID des Mailobjekts |
DocumentProperties
Eigenschaften, die aus dem Dokument ausgelesen werden:
Definition der Namen der Metadaten-Tags. Nach Installation sind folgende Standards definiert und können um beliebig viele Attribute erweitert werden:
Definiert, ob die mit ExtendedAttributeMapping automatisch ausgelesenen Metadaten überschrieben werden dürfen oder nicht.
Wert | Beschreibung |
---|---|
true | Metadaten werden überschrieben. |
false | Metadaten werden nicht überschrieben. |
/MetaDb/MAIN_MODULE_MANAGEMENT/roi/control/contenttask
CT
Hinweis: Eigene Konfigurationen wirken sich nur auf neue Dokumente und neue Änderungen aus.
Folgende Property-Entrys sind in jedem ContentTask vorhanden:
Property-Entry | Beschreibung |
---|---|
class | Definiert die hinterlegte Java-Klasse, die für diesen ContentTask verwendet wird. |
DeleteFileAfterTask | Definiert, ob die Original-Datei nach Ablauf des ContentTasks erhalten bleibt oder gelöscht werden soll. true Die Original-Datei wird gelöscht. false Die Original-Datei bleibt erhalten. |
Extension | Definiert die Dateiendung, auf welche der ContentTask reagieren soll. |
Um eine Contenttask zu deaktivieren, stellen Sie dem Namen des Property-Bundles ein # voran:
#CT
Tipp: Sie können auch die Aktiven Ordner verwenden, um eine TimephasedAction zu definieren.
Mit einer ContentTask können Sie auch das Starten einer TimephasedAction definieren, etwa wenn bei PDFs grundsätzlich ein Posteingangsworkflow starten soll.
Folgende Property-Entrys müssen Sie im Property-Bundle der gewünschten ContentTask definieren.
Property-Entry | Wert/Beschreibung |
---|---|
class | agorum.roi.ejb.common.ContentTaskSetTimePhasedAction |
DeleteFileAfterTask | Definiert, ob die Original-Datei nach Ablauf der ContentTask erhalten bleibt oder gelöscht werden soll. true Die Original-Datei wird gelöscht. false Die Original-Datei bleibt erhalten. |
Extension | Definiert die Dateiendung, auf welche der ContentTask reagieren soll. |
InFolders | Definiert den Pfad zu den Ordnern, in denen der ContentTask verwendet werden soll. Mehrere Einträge werden mit || getrennt eingegeben. |
TimePhasedActionName | Definiert den Namen der aufzurufenden TimephasedAction. |
Als ImageMetaData werden bestimmte Metadaten bezeichnet, die von agorum core automatisch auf Bilder gesetzt werden. Laden Sie etwa ein Bild in agorum core hoch, besitzt dieses Bild automatisch bestimmte Metadaten, die nur bei Bildern vorkommen.
Beispiele als Metadatum
So finden Sie die ImageMetaData:
MAIN_MODULE_MANAGEMENT/roi/control/contenttask/[ ImageMetaData ]
Alle Grafikformate, die hier angezeigt werden, werden auch von agorum core unterstützt.
Neben den allgemeinen Property-Entrys existieren für die ImageMetaData folgende Property-Entrys:
Property-Entry | Beschreibung |
---|---|
ExtendedAttributeMapping | Definiert die Metadaten, die in agorum core bei einem Bild angezeigt werden. Enthalten ist ein Array mit Metadatennamen, in welche die ausgelesenen Metadaten der Exif-Dateien gemappt werden (aus dem Property-Entry ImageMetaProperties). Beispiel Ist im Bild das Metadatum Exif IFD0:X Resolution vorhanden, wird es in agorum core auf das Metadatum image_x_resolution gemappt. |
ImageMetaProperties | Definiert die Metadaten, die in den Exif-Dateien des Bilds vorkommen. Enthalten ist ein Array der auszulesenden Metadaten. |
Manual | Beschreibt, welche Metadaten generell in dem gewählten Grafikformat enthalten sein können. Klicken Sie auf ein nachfolgendes Format, um diese Metadaten aufgelistet zu sehen: .arw .bmp .cr2 .gif .jpg .nef .png .tif .tiff |
Welche Metadaten tatsächlich auf einem Bild gesetzt sind, können Sie auf zwei verschiedene Arten herausfinden:
desk4web Tools
Per JavaScript
Mit folgendem JavaScript können Sie ebenfalls die gesetzten Metadaten auf einem Bild prüfen. Das JavaScript können Sie etwa in Ihren eigenen Dateien in agorum core erstellen.
/* Global Packages */ // Kleines Skript, mit dem Sie prüfen können, welche Metadaten auf einem Bild gesetzt sind. // ACHTUNG: Es handelt sich um Low-Level-Java-Methoden, die sich ändern können. // Kapseln Sie diese, wenn Sie sie in eigenen Projekten verwenden wollen. // Die Methoden können von uns jederzeit ersetzt werden. let BufferedInputStream = Packages.java.io.BufferedInputStream; let ImageMetadataReader = Packages.com.drew.imaging.ImageMetadataReader; let objects = require('common/objects'); let object = objects.find('1432508'); // Geben Sie hier ID eines Objekts an, das Sie prüfen wollen. /**/ let bis = new BufferedInputStream(object.contentStream); let metadata = ImageMetadataReader.readMetadata(bis); let ret = []; metadata.directories.forEach(dir => { let name = dir.name; let iter = dir.tags.iterator(); while (iter.hasNext()) { let tag = iter.next(); ret.push({ tag: name + ':' + tag.tagName, description: tag.description }); } }); ret;
Speichern Sie das Skript, nachdem Sie die Objekt-ID aus Ihrer Zwischenablage in das Skript eingefügt haben, und klicken Sie auf Run.
Die Ausgabe könnte etwa folgendermaßen aussehen:
[ { "description" : "1795", "tag" : "PNG-IHDR:Image Width" }, { "description" : "2613", "tag" : "PNG-IHDR:Image Height" }, { "description" : "8", "tag" : "PNG-IHDR:Bits Per Sample" }, { "description" : "True Color", "tag" : "PNG-IHDR:Color Type" }, { "description" : "Deflate", "tag" : "PNG-IHDR:Compression Type" }, { "description" : "Adaptive", "tag" : "PNG-IHDR:Filter Method" }, { "description" : "No Interlace", "tag" : "PNG-IHDR:Interlace Method" }, { "description" : "Perceptual", "tag" : "PNG-sRGB:sRGB Rendering Intent" }, { "description" : "0.455", "tag" : "PNG-gAMA:Image Gamma" }, { "description" : "7716", "tag" : "PNG-pHYs:Pixels Per Unit X" }, { "description" : "7716", "tag" : "PNG-pHYs:Pixels Per Unit Y" }, { "description" : "Metres", "tag" : "PNG-pHYs:Unit Specifier" } ]
Der ContentTask ContentTaskScript hat folgende Property-Entrys als Einträge:
Sperrt die Contenttask für Benutzer oder gibt sie frei.
Damit das System die Contenttask ausführt, benötigen Benutzer mindestens ein Leserecht auf diese ACL.
Tragen Sie Folgendes ein:
agorum.roi.ejb.common.ContentTaskScript
Ermöglicht es, einen Selektor einzutragen. Wenn dieser greift, führt das System die Contenttask für das geänderte Objekt aus.
Damit die Contenttask sich ausschließlich auf dieses Objekt bezieht, tragen Sie einen eindeutigen Selektor ein.
[name=/.*(\.h|\.nc|\.r|\.acc)|(O[0-9]{4})/i][!isFolder]
Erwartet ein auszuführendes (externes) Skript.
Als Übergabe wird dem Skript object mitgegeben. Darin steht das Objekt, mit dem das System das Skript ausführt.
/* global sc, object */ // // Skript wird inline, nicht als Objektverweis erwartet // // Damit kann ich trotzdem ein externes Script aufrufen. require('/agorum/roi/customers/sample/js/sampleScript');
Externes Skript
/* global Packages, sessionController, object */ let ChangeHistoryUtils = Packages.agorum.roi.ejb.common.ChangeHistoryUtils(sessionController), utils = require('/agorum/roi/customers/CNC/JS/utils'), grp = require('common/objects').find('group://GRP_CNCRestore'), grpNote = require('common/objects').find('group://GRP_CNCNote'), text = ''; // Darf nicht gemacht werden, wenn ein Benutzer aus der Gruppe GRP_CNCRestore eine Änderung macht if (!utils.isUserInGroup(grp,object.lastModifier)) { let objectHistory = ChangeHistoryUtils.getLastHistoryObject(object); if (objectHistory) { if (!utils.compare(object, objectHistory)) { // Jetzt muss eine Notiz angehängt werden // text = '<p>Geändert links:</p>' + '<ul>' + ' <li><a href="agorum:cnc_compare:' + object + '">Vergleich</a></li>' + ' <li><a href="agorum:cnc_historyRestore:' + object + ':' + objectHistory + '">Historie wiederherstellen</a></li>' + '</ul>' + '<p> </p>'; utils.writeNote(object,text,grpNote.allUserMembers); //object.acl.allGrantedUsers } else { //text = 'Das CNC-Programm hat sich nicht geändert'; } } else { //text = 'Das CNC-Programm wurde neu abgelegt'; } }