Die Aktionen von ELOxc sind die Menge verfügbarer Verarbeitungsvorschriften bzw. –muster. Sie sind so konzipiert, dass sie modular und hierarchisch mit möglichst wenigen Abhängigkeiten untereinander erstellt werden können. Während die Konfigurationen für eine Instanz und ihre Aktionsbäume die Elementselektion beeinflussen, ist die Konfiguration von Aktionen das Regelwerk, wie die selektierten Elemente verarbeitet werden. Die hierarchische Anordnung der Aktionen innerhalb eines Aktionsbaums ergibt sich aus der Tatsache, dass eine Aktion maximal zwei Ergebnisse haben kann – Erfolg („TRUE“) oder Misserfolg („FALSE“), und daraus, dass der Aktionsbaum ein Aktionsergebnis auswertet und daraus dynamisch die Folgeaktion bestimmt.

Die verbleibenden und unvermeidbaren Abhängigkeiten der Aktionen untereinander ergeben sich aus der Notwendigkeit, Verarbeitungsdaten in verschiedenen Aktionen verwenden zu können. Maßgeblich hierfür sind überwiegend die selektierten Elementfelder, die den Selektionsumfang eines Aktionsbaumes bestimmen und von ELOxc vor einer Elementselektion automatisch ermittelt werden.

Zusätzlich kommen jedoch auch die von ELOxc definierten Pseudoelementfelder hinzu, die spezielle Daten enthalten, welche die Datenquellen normalerweise nicht enthalten. Ein Beispiel hierfür ist die ELO GUID, welche sowohl beim Archivieren („CheckinDef“) erzeugt wird, als auch in anderen Aktionen wie z. B. beim Löschen („DeleteDef“) oder in der Existenzprüfung („ExistsDef“) verwendet werden kann und deshalb auch vorausgesetzt werden muss. Das lässt sich veranschaulichen, indem Sie von dem Fall ausgehen, dass ein geprüftes, sicheres Löschen konfiguriert wird und der zuständige Aktionsbaum aber Elemente selektiert, die bisher noch nicht archiviert worden sind. In diesem Fall würde das sichere Löschen, welches die Existenz eines einer ELO GUID zwingend erfordert, automatisch scheitern, da nicht archivierte Elemente gar keine ELO GUID besitzen können.

Eine weitere Art von Aktionsabhängigkeiten ist die „Intention eines Aktionsbaumes“: Möchten Sie beispielsweise ein Element archivieren, benötigen Sie natürlich die entsprechende Aktion („CheckinDef“), welche die Archivierung durchführt. Das kann jedoch nur gelingen, wenn zuvor auch ein Elementexport stattgefunden hat, was ebenfalls eine eigenständige Aktion („ExportDef“) ist, die nur dafür zuständig ist, Elementdaten in Dokumentform von der Datenquelle zu lesen. In diesem Fall sind Export und Archivierung untrennbar miteinander verknüpft. Im Regelfall werden Sie über diese Minimalkonfiguration hinaus jedoch auch die Verschlagwortung und den Ablagepfad festlegen wollen, weshalb dann der Export eine Verschlagwortungsvorlage erhält und die Archivierung zusätzlich den konfigurierten Ablagepfad ermittelt. Der Ablagepfad ist dabei wieder eine eigenständige und beliebig oft verwendbare Aktion, die wiederum eigene Verschlagwortungsvorlagen verwenden kann.

Jedes verarbeitete Element hält seine eigenen Arbeitsdaten vor, die im Kontext eines Aktionsbaums, also nach der erfolgreichen Elementselektion, gesammelt werden können, gültig sind und für die Elementverarbeitung genutzt werden können. Wenn dabei Aktionen, die diese internen Arbeitsdaten erzeugen, in einem Baum mehrfach ausgeführt werden, sind bei Verwendung der Daten stets die zuletzt ermittelten Werte gültig.

Doch auch hierfür gibt es eine Ausnahme: Berechtigungen („ItemSecurityDef“) werden pro Element kumulativ gesetzt bzw. entfernt, um die Gesamtliste der ACLs über mögliche Fallunterscheidungen im Aktionsbaum bilden zu können.

ELOxc hält intern für verwendete Felder der Datenquelle zusätzlich zwei Ebenen bereit. Diese sind folgendermaßen zu unterscheiden: Zum einen, ob Datenänderungen beim Speichern von Elementen („CommitDef“) an die Datenquelle übergeben werden und deshalb auch die Elemente selbst ändern. Zum anderen, ob Datenänderungen als Kopien bzw. reine Aktionsdaten verwendet werden sollen und ihre Werte aber nicht in der Datenquelle gespeichert werden sollen. ELOxc verwendet an allen Stellen, welche die Elementdaten direkt verwenden, den Attributwert „fieldname“, während die Feldkopien mit „cachedname“ festgelegt werden. Der Standardfall ist, dass die Aktionen von ELOxc davon ausgehen, dass alle Datenänderungen auch gespeichert werden sollen und deshalb die Elementfelder direkt verwendet und verändert werden.

Bevor Sie die erste Aktion erstellen, klicken Sie auf „+“ neben dem Knoten des Aktionsbaums. Hier sehen Sie stets alle zur Verfügung stehenden Aktionen.

Im Dialog Aktion hinzufügen werden Ihnen stets alle Aktionen als Auswahl zur Verfügung gestellt.

Bevor die verfügbaren Aktionen in diesem Abschnitt einzeln und vollständig erklärt werden, werfen wir einen ersten Blick auf ihre Rollen: