Freitag, 18. Februar 2011

Workflow-Events bei Änderungen

Wenn das Workflow-Laufzeitsystem in einem SAP-System einmal eingerichtet ist, unterstützt es die Erweiterung aller Geschäftsprozesse – in vielen Fällen ohne zusätzlichen Programmieraufwand, mit einem modellbasierten Ansatz. Mit dem Workflow Builder können Abläufe auf Basis der im BOR (Business Object Repository) definierten Objekte im Zusammenspiel mit manuellen Schritten (Entscheidungen, Bekanntmachungen usw.) definiert und implementiert werden.

Grundidee ist dabei die lose, customizebare Kopplung von BOR-Ereignissen an Verbraucher. Die Kopplung kann auch im Produktivsystem noch an- und abgeschaltet werden. Verbraucher können Workflows, Tasks, BOR- oder Klassenmethoden oder auch Funktionsbausteine sein. Die Ereignisauslösung ist dabei im gesamten System omnipräsent. Es dürfte kaum ein betriebswirtschaftlich relevantes Ereignis geben, das nicht im Workflowsystem eine Entsprechung findet. Typische Beispiele sind die Anlage neuer Belege oder die Änderung von System- oder Anwenderstatus. Selbstverständlich können Workflow-Ereignisse auch programmgesteuert ausgelöst werden (falls unwahrscheinlicherweise doch einmal eines fehlen sollte), wofür man die Methode raise der Klasse cl_swf_evt_event verwenden sollte.

Hier will ich zeigen, wie man sich für die Änderung bestimmter Felder im Artikelstamm registrieren kann. Im konkret vorliegenden Fall sollte sich ein Verbraucher für die Änderung zweier bestimmter Felder registrieren. Um nun nicht für jede Änderung ein Ereignis auszulösen, erschien es mir nötig, ein Custom Event genau für diesen Änderungsfall zu definieren.

Ereignisse sind Bestandteile von BOR-Objekten. Um modifikationsfrei ein neues Ereignis zu definieren, habe ich einen Subtyp des BOR-Objekts BUS1001001 (Handelsartikel) definiert:



Den neuen Typ ZBU1001001 verwende ich, um ein neues Ereignis FIELDSET_CHANGED zu definieren:



Dieses Workflow-Ereignis muss nun an die gewünschten Änderungen des Artikelstamms gebunden werden. Das SAP-System schreibt Änderungen an Geschäftsobjekten in den Tabellen CDHDR und CDPOS fort. Dabei gibt es pro Geschäftsobjekt einen Typschlüssel, das sogenannte Änderungsbelegobjekt. Beim Entwickeln des Geschäftsobjekts (also in der Regel in der SAP-Standard-Entwicklung) wurde dieses Änderungsbelegobjekt eingerichtet, wobei auch automatische Funktionsbausteine zum Fortschreiben generiert wurden. Heisst das Änderungsbelegobjekt beispielsweise MAT_FULL, so bekommt der zugeordnete Funktionsbaustein den Namen MAT_FULL_WRITE_DOCUMENT. Dieser Baustein wird dann, im allgemeinen in der verzögerten Verbuchung (V2), beim Sichern des Geschäftsobjekts aufgerufen.

Um nun dem Änderungsbelegobjekt mitzuteilen, dass es das Ereignis eines BOR-Objekts auslösen soll, definiert man eine Zuordnung in der Transaktion swec.



Im Detailbild zu dieser Zeile kann man über den Bedingungseditor beispielsweise noch festlegen, dass das Ereignis nur bei Änderung bestimmter Felder ausgelöst werden soll:



Nach diesen Einstellungen wird das neue Ereignis bereits ausgelöst. Bis hierhin liess sich alles mit blossem Customizing erledigen. Wenn nun an das Ereignis an einen Verbraucher gekoppelt werden soll, kann man sich entscheiden: Möchte man selbst einen spezifischen Verbraucher implementieren, oder kann man die gewünschten Funktionen im Rahmen eines Workflows modellieren. Der häufig gewünschte 08/15-Fall, dass irgendjemand gern eine E-Mail-Benachrichtigung hätte, lässt sich eigentlich immer mit Workflowmitteln lösen, d.h. ohne Programmierung. Die Verwendung einer Workflow-Aufgabe zur E-Mail-Erzeugung hat darüberhinaus den Vorteil, dass die Kopf- und Detaildaten der Mail frei einstellbar sind, wobei als Platzhalter Anwendungsdaten verwendet werden können.

Wenn man es möchte, kann man auch programmierte Logik an das Ereignis koppeln. In der folgenden Ereignis-Typ-Kopplung wird zum Beispiel der Funktionsbaustein Z_CONSUME_FIELDSET_CHANGED mit dem neuen Ereignis FIELDSET_CHANGED verknüpft. Die Kopplung bekommt einen symbolischen Namen (der im System nicht weiter verprobt wird), hier MARA_FIELDSET_CHANGED:



Der Funktionsbaustein muss die folgende Schnittstelle aufweisen und ist ansonsten frei definierbar. Die interne Tabelle EVENT_CONTAINER enthält Detaildaten zum Anwendungsobjekt: in diesem Fall die Nummer des Änderungsbelegs.

function z_consume_fieldset_changed.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*" IMPORTING
*" VALUE(EVENT) TYPE SWETYPECOU-EVENT
*" VALUE(RECTYPE) TYPE SWETYPECOU-RECTYPE
*" VALUE(OBJTYPE) TYPE SWETYPECOU-OBJTYPE
*" VALUE(OBJKEY) TYPE SWEINSTCOU-OBJKEY
*" VALUE(EXCEPTIONS_ALLOWED) TYPE SWEFLAGS-EXC_OK DEFAULT SPACE
*" EXPORTING
*" VALUE(REC_ID) TYPE SWELOG-RECID
*" TABLES
*" EVENT_CONTAINER STRUCTURE SWCONT
*"----------------------------------------------------------------------


Erwähnenswert ist noch, dass es für Workflowereignisse ein sehr nützliches Trace gibt, das sich über die Transaktion swels ein- und ausschalten lässt (das Ausschalten ist natürlich wichtig, vor allem im Produktivsystem!). In Transaktion swel kann man sich das Log des Ereignis-Trace ansehen. Zum Testen habe ich nacheinander zwei Feldänderungen durchgeführt. Das Log zeigt, dass jeweils das Ereignis ausgelöst und der Verbraucher gemäss der Kopplung MARA_FIELDSET_CHANGED identifiziert und korrekt gestartet wurde.

Keine Kommentare :