Bei der zweiten Art von „Actions“ handelt es sich um „Jobs“, die durch eine „ActionID“ eindeutig referenziert werden. Diese werden zusammen mit gewissen Parametern (o.a. Einstellungen) in speziellen Tabellen gespeichert.

Einen kurzen Überblick gibt der Abschnitt Terminologie "Actions".

Diese Art wird häufig in der Dokumentation der Prozeduren, in anderen Dokumenten des dStore und auch in dieser Einführung (ab jetzt) nur kurz als „Actions“ bezeichnet, insbesondere ist mit „Action“ ein einzelner „Job“ (also eine „ActionID“) dieser Art gemeint.

Der Zugriff auf die Daten einer „Action“ kann durch die dokumentierten Prozeduren, deren Name mit „ac“ beginnt, erfolgen. Erzeugt werden können sie aber auch durch die im vorigen Abschnitt beschriebenen „Action“-Prozeduren.

Anmerkung : Um die Verwirrung komplett zu machen, werden die dokumentierten Prozeduren für den Zugriff auf „Actions“ auch gerne als „Action“-Prozeduren bezeichnet, oder alle Prozeduren, die mit „_ac“ oder „ac“ beginnen, werden so genannt. Man muß also immer auf den Kontext achten, um zu verstehen, was jetzt gemeint ist. In dieser Einführung achten wir aber darauf, daß möglichst keine Verwechslung passieren kann.

Zu jeder „Action“ muß ein „Kommando“ (genauer eine „CommandID“) hinterlegt werden, das letztlich das externe Programm angibt, das für ihre Abarbeitung zuständig ist. Außerdem werden der Zeitpunkt, wann die „Action“ angelegt bzw. der Status geändert wurde, gespeichert, sowie ein Status. Bei letzterem handelt es sich um eine „integer“-Zahl, die den „Verarbeitungs- Zustand“ der „Action“ anzeigen soll, ob also die Verarbeitung begonnen hat, ob es einen Fehler gab, oder ob die Abarbeitung erfolgreich war usw.

Von der Engine (also durch eine „Action“-Prozedur) angelegte „Actions“ haben immer den Status-Wert „-1“, der „nicht gelaufen“ oder „nicht bearbeitet“ bedeutet. Es ist der einzige von der Engine vordefinierte Status-Wert mit fester Bedeutung. Andere Status-Werte können definiert werden, es gibt aber keine weitere von Prozeduren programmatisch festgelegte Beziehung oder Interpretation, d.h. ihr Einsatz wird einzig durch die externen Programme, die die „Actions“ abarbeiten, bestimmt und kontrolliert.

Die typische Abarbeitung von „Actions“ besteht aus einem „polling“ aller „Actions“ einer bestimmten „CommandID“, die im Status „-1“ sind, die dann einzeln verarbeitet werden. Und während der Abarbeitung werden eben entsprechende Status-Werte gesetzt.

Eine „Action“ kann (was i.d.R. der Fall ist) diverse Parameter, also zusätzliche Informationen bzw. Einstellungen haben. Diese dienen dazu, die Abarbeitung zu steuern, also dem zuständigen externen Program mitzuteilen, was genau zu tun ist. Wenn z.B. eine Bestellbestätigung geschickt werden soll, ist die Angabe einer „OrderID“, also um welchen Auftrag es geht, unumgänglich.