Prozedur zur Verwaltung der Arbeitsschritte eines „TRI-Trigger“.

„TRI-Trigger“ sind Objekte, die innerhalb der Engine bei bestimmten Datenänderungen ausgelöst werden (z.B. dem Status-Wechsel von Auftragspositionen). Die Definition eines solchen Triggers besteht aus Arbeitsschritten, zu denen optional eine Bedingung hinterlegt sein kann und zu denen immer eine bestimmte Reihe von Anweisungen (derzeit Prozedur-Aufrufen) konfiguriert ist.

Ein Arbeitsschritt darf optional einen „Iterator“ enthalten (→ „IterationList“). Dabei handelt es sich um einen sogenannten „TRI-Ausdruck“, d.h. eine Zeichenkette, die „Platzhalter-
Funktionen“ enthalten darf - s. mi_GetTRITriggerReplFuncts_Ad. Nach Auswertung muß eine Liste von Werten entstehen, die durch „;;;“ getrennt sind - wohlgemerkt NACH der Auswertung, d.h. in der Iterator-Definition (→ „IterationList“) selbst muß nicht zwangsläufig „;;;“ vorkommen !

Beispiel für einen Iterator in einem „ChangeOrderStateTrigger“ (wenn also „TriggerTypeID = 2“ für „TriggerID“ gilt) :
'#affectedids(trigger)##columnvalue(OrderContent,OrderContentID,OrderID)##distinct()#'
Damit ergibt sich eine Iteration über alle VERSCHIEDENEN Aufträge („OrderIDs“), zu denen die vom Status-Wechsel betroffenen Auftragspositionen gehören. D.h. man kann die Positionen „Auftragsweise behandeln“, wenn man denn außerdem eine Bedingung zum Arbeitsschritt formuliert, die nur die Positionen beachtet, deren zugehörige „OrderID“ dem aktuellen Iterator-Wert entspricht (s. mi_ModifyTRITriggerConds_Ad).

Anmerkungen zum Parameter „CancelOnError“ :

Bei der Abarbeitung eines „TRI-Trigger“ wird natürlich nach jeder Anweisung geprüft, ob es einen Fehler gab. Mit „CancelOnError“ kann man nun konfigurieren, was passieren soll, wenn bei dem Arbeitsschritt (egal in welcher Anweisung) ein Fehler auftritt :

• „0“ : Den Fehler ignorieren und weitermachen (nicht empfohlen, es kann aber durchaus Anwendungsfälle dafür geben)
• „1“ : Kompletter „rollback“, d.h. die GESAMTE Transaktion (in der ein Trigger immer stattfindet) wird abgebrochen und sämtliche Änderungen werden verworfen
• „2“ : „rollback“ nur für den Arbeitsschritt, d.h. alle Änderungen des Arbeitsschritts werden rückgängig gemacht und es geht mit dem evtl. vorhandenen nächsten Schritt weiter (insbesondere wird also die Transaktion um den Trigger herum NICHT abgebrochen)

Hinweise :

1. Sofern der Trigger schon zugewiesen ist (s. Rückgabespalte „TriggerStatus“ von mi_GetTrigger_Ad), kann NICHTS mehr geändert werden !
2. Falls für den Trigger bereits eine Prozedur, die bei Auslösung ausgeführt werden soll, konfiguriert ist (s. Rückgabespalte „ExecuteProcedureName“ von mi_GetTRITrigger_Ad), können keine Arbeitsschritte definiert werden.
3. Egal, WAS durch diesen Aufruf geändert wird (neuer Arbeitsschritt oder bestehenden ändern/löschen), wir gehen sicherheitshalber davon aus, daß der Trigger dadurch erstmal unbrauchbar wird, weswegen er als fehlerhaft gekennzeichnet wird (s. Rückgabespalte „TriggerStatus“ von mi_GetTrigger_Ad). Um den Trigger (wieder) verwendbar zu machen, muß mi_ValidateTRITrigger_Ad aufgerufen werden !

Die Prozedur hat keine Rückgaben.

Die Rückgabe erfolgt als XML-Dokument welches gegen das Schema Response/EngineProcedure_v1_0.xsd validiert.

Der folgende Link öffnet in einem separaten Fenster den Engine Playground der fest mit dem dbap-demo System verbunden ist:

• mi_ModifyTRITriggerWorkflow_Ad im Engine Playground öffnen

Unformatierte Ausgabe:

curl -X POST  'http://<partner>-<project>.dstore.de/default/engine/mi_ModifyTRITriggerWorkflow_Ad?TriggerID=<value>'

Mit xmllint ⁵⁾ formatierte Ausgabe:

curl -X POST  'http://<partner>-<project>.dstore.de/default/engine/mi_ModifyTRITriggerWorkflow_Ad?TriggerID=<value>' | xmllint --format -

use dStore_php\WebService;
 
$service = new WebService\Service( WebService\Scheme::HTTP,'<partner>-<project>.dstore.de', 80);
 
$request = new WebService\Requests\Engine\Procedure\Request(
			new WebService\Requests\AccessData('default'),
	'mi_ModifyTRITriggerWorkflow_Ad',
		array(
			'TriggerID' => <value>,
			// 'IterationList' => NULL,
			// 'WorkStep' => NULL,
			// 'Description' => NULL,
			// 'CancelOnError' => 1,
			// 'DeleteWorkStep' => 0
		)
);
 
$service->execute($request);
 
			$xml_result = $request->getResponse()->getBody()->toSimpleXmlDocument();
			$ResultSet = $xml_result->getRowsAsArray();
 
$OutputParams = $xml_result->getOutputParametersAsArray();

XML zur Ausführung mit der Methode engine/execute, z.B. per

curl --header 'Content-Type: application/xml' -X POST 'http://<partner>-<kunde>.dstore.de/default/engine/execute' -d '<xml-daten>'

<?xml version="1.0" encoding="UTF-8"?>
<ListOfBatches>
	<Batch No="0">
		<Procedure Name="mi_ModifyTRITriggerWorkflow_Ad">
			<Parameters>
				<Parameter Name="TriggerID"><!-- smallint value --></Parameter>
				<!-- <Parameter Name="IterationList">NULL</Parameter> -->
				<!-- <Parameter Name="WorkStep">NULL</Parameter> -->
				<!-- <Parameter Name="Description">NULL</Parameter> -->
				<!-- <Parameter Name="CancelOnError">1</Parameter> -->
				<!-- <Parameter Name="DeleteWorkStep">0</Parameter> -->
			</Parameters>
		</Procedure>
	</Batch>
</ListOfBatches>