Das in diesem Kapitel beschriebene Engine-Konzept der „Actions“ ist aus zwei Gründen entstanden :

• Nicht alle Aufgaben können durch „Stored Procedures“ erledigt werden. Dies kann aus funktionalen Gründen so sein (fehlende Features der Sprache T-SQL), es gibt aber auch Aufgaben, die innerhalb einer Transaktion erledigt werden müßten, aber viel zu lange dauern - und damit einen enormen Flaschenhals darstellen würden.
• Es gibt Prozess-Abläufe, die individuell an die Bedürfnisse des Kunden, der die Engine verwendet, angepaßt werden müssen - wo also das berühmte „customizing“ erforderlich ist.

Verallgemeinert gesprochen sind „Actions“ Abläufe oder Aktionen (daher der Name), die i.d.R. aus einer Transaktion heraus entstehen und entweder noch in derselbigen erledigt werden können, oder aber später durch ein externes Programm (z.B. action_SmartGate) ausgeführt werden müssen. Dementsprechend gibt es zwei Arten von „Actions“ :

• User-Exits: Prozeduren, in denen eine individuelle (auch „customized“ genannte) Funktionalität implementiert ist
• Jobs: Gespeicherte Daten, die einen durch ein externes Programm auszuführenden „Job“ darstellen und steuern

Klassische Beispiele für „Actions“ sind der Preisfindungs-Prozeß, das Verschicken einer Bestell-Bestätigung als E-Mail bei Auftragseingang oder das Erzeugen von Dokumenten wie Packlisten, Lieferscheinen oder Rechnungen. Bei all diesen Beispielen sind immer „Action“-Prozeduren als „User-Exits“ involviert und meistens müssen auch „Jobs“ angelegt werden.