10.8 Dynamische Blöcke

Transkript

1 Klassenbasierte Techniken im Workflow Workflows selbst weiterläuft sowie dass der lokale Workflow keine Daten an den auslösenden Workflow zurückgeben kann. N-faches Auslösen eines Startereignisses für einen lokalen Subworkflow löst diesen auch N mal aus! Im Workflow-Protokoll findet man in diesem Fall N Instanzen zu diesem lokalen Workflow Dynamische Blöcke Ein dynamischer Block bearbeitet eine Liste mit gleichartigen Elementen (Objektreferenzen), deren Elementanzahl zur Definitionszeit nicht bekannt ist. In früheren Releases gab es dafür die dynamische Parallelverarbeitung. Dieses Verfahren ist in [2] ausführlich beschrieben. Wollte man mehrere Schritte dynamisch parallel verarbeiten, so musste man ein eigenes Workflow-Muster anlegen, das dann dynamisch parallel aufgerufen wurde. Die dynamischen Blöcke lösen das Problem viel eleganter. Zwischen den Blockbegrenzern (Pfeil nach oben, Pfeil nach unten) können beliebig viele Workflow-Schritte eingefügt werden. Diese bilden dann quasi einen eigenen, eingebetteten Workflow mit eigenem Container und Datenfluss zum umgebenden Workflow. Es sind zwei Arten von Blöcken möglich: Dynamisch sequenzieller Block Das ist letztlich ein Iterator auf Workflow-Ebene. Dynamisch paralleler Block Das ist eine dynamische Parallelverarbeitung. Blöcke werden durch X-Workitems repräsentiert. Bei sequenziellen Blöcken existiert genau ein Block-Workitem mit genau einem Blockcontainer. Dieser Container wird nacheinander von den Workitems des Blockes benutzt. Bei dynamisch-parallelen Blöcken existieren so viele Block-Workitems mit je einem Blockcontainer wie es Einträge in der Objektliste gibt. Die Workitem-Hierarchie in der Kopftabelle SWWWIHEAD wird ergänzt: SWWWIHEAD-WI_CHCKWI Workitem des umgebenden Flows SWWWIHEAD-PARENT_WI Block-Workitem des umgebenden Blockes Bei Block-Workitems sind PARENT_WI und WI_CHCKWI gleich.

2 10.8 Dynamische Blöcke Dynamisch sequenzieller Block = Workflow-Iterator Der sequenzielle dynamische Block entspricht genau einem Iterator im Workflow-Kontext. Dynamische Liste mit N Objekten Dynamische Liste mit N Objekten n := 1 Abb Dynamisch sequenzieller Block als eingebetteter Subworkflow Dynamisch sequenzieller Block <Liste>_LINE = Liste[n] Block-Subworkflow Blockcontainer <Liste>_LINE Blockschritte Subworkflow- Container <Liste>_LINE Subworkflow-Schritte n := n + 1 n > N? Dynamisch paralleler Block Der dynamisch parallele Block bearbeitet die N Objekte in einem parallelen Abschnitt, dessen Zweiganzahl erst zur Laufzeit bekannt ist. Dynamische Liste mit N Objekten Dynamische Liste mit N Objekten Parallel N / N (dynamisch) Abb Dynamisch paralleler Block als eingebetteter Subworkflow Dynamisch paralleler Block <Liste>_LINE = Liste[1] <Liste>_LINE = Liste[2] <Liste>_LINE = Liste[N] Blockcontainer <Liste>_LINE Blockschritte Block-Subworkflow Subworkflowflow- Container <Liste>_LINE Block-Subworkflow Subworkflow- Container <Liste>_LINE Block-Subworkflow Subflow- Container <Liste>_LINE Subworkflow-Schritte Subworkflow-Schritte Subworkflow-Schritte Parallel N / N (dynamisch)

3 Klassenbasierte Techniken im Workflow Beispiel: Bewertungs-Workflow für Vertrag Im folgenden Beispiel wird ein Vertrag dynamisch parallel durch N Mitarbeiter bewertet. Jeder Mitarbeiter kann über eine Sachbearbeiterentscheidung (SBE) von minimal 0 bis maximal 3 Punkte vergeben. Die Parallelverarbeitung soll abgebrochen werden, wenn insgesamt bereits N*2 Punkte erreicht wurden. Variablen im Workflow-Container: Vertrag Ref To ZCL_VERTRAG UserListe Ref To ZCL_USER, mehrzeilig UserCount Type I, Anzahl der User in der Liste (=N) PunkteGesamt Type I, Anzahl der vergebenen Gesamtpunkte PunkteLimit Type I, notwendige Punkteanzahl für Abbruch 2*N Der erste Block demonstriert die dynamisch-sequenzielle Verarbeitung. Als Blockschritt wurde irgendein Schritt gewählt. Abb Dynamisch-sequenzielle Bearbeitung der UserListe Der Datenfluss Workflow Blockcontainer sieht folgendermaßen aus: In &_WF_PARFOREACH_INDEX& steht der aktuelle Index der UserListe. Das Element mit diesem Index wird übergeben und könnte bearbeitet werden. Hier wird als Rückgabewert einfach eine 1 auf den UserCount im Workflow-Container addiert. Zum Schluss hat man also die Anzahl der Einträge in der dynamischen Liste ermittelt. (Natürlich würde man dazu nicht extra einen Block anlegen, sondern eher eine Utility-Methode; hier geht es nur um die Demonstration

4 10.8 Dynamische Blöcke 291 einer speziellen Variante des Datenflusses). Das PunkteLimit wird mit PunkteLimit = 2 * UserCount festgelegt. Abb Datenfluss zum dynamisch-sequenziellen Block Der dynamisch-parallele Block erzeugt je User in der UserListe eine SBE mit den vier Bewertungsergebnissen. Als Bearbeiter wird ein Ausdruck der Form &_USERLISTE_LINE.GET_PDUSER()& benutzt. Die Returningmethode setzt einfach ein»us«vor den Usernamen der Instanz. Vertragsbewertung parallel Bewerten Sie Vertrag mit 0 3 Punkten Abb Dynamisch-paralleler Block zur Vertragsbewertung Punkte: = 2 Punkte: = 0 Punkte: = 1 Punkte: = 3 ok ok ok ok Vertragsbewertung parallel

5 Klassenbasierte Techniken im Workflow Dem Blockcontainer wird wieder das n-te Element der UserListe übergeben, zusätzlich der zu bewertende Vertrag. Das Ergebnis einer Bewertung ist die vom jeweiligen User vergebene Punkteanzzahl, sie wird im Datenfluss vom Blockcontainer zum Workflow auf die PunkteGesamt aufaddiert. Abb Datenfluss zwischen Workflow-Container und Blockcontainer Abb Abbruchbedingung für dynamisch-parallelen Block Die dynamische Parallelverarbeitung wird abgebrochen, wenn das PunkteLimit erreicht wurde, bevor alle Bewertungen vorliegen. Das Workflow-Protokoll zeigt den Stand nach Abarbeitung des sequenziellen Blocks (ohne Dialogschritte) und nach Erzeugung aller drei Dialogschritte im parallelen Block. Es ist zu sehen, dass der sequenzielle Block für die drei Durchläufe nur ein Block-Workitem hat (9147). Demgegenüber hat der parallele Block drei Block-Workitems (9151,9152, 9153).

6 10.8 Dynamische Blöcke 293 Abb Protokoll eines Workflows mit Blöcken In der SBE werden von jedem User die Punkte vergeben. In einem Link soll das zu bewertende Objekt, hier also der Vertrag, anzeigbar sein. Abb SBE zur Vertragsbewertung mit Link zum Vertrag Leider funktionieren die im Container vordefinierten _ADHOCOB- JECTS nicht für Referenzen von Klassen. Man muss also für jeden Klassenlink eine eigene Variable im Container anlegen. Aber das ist kein großer Aufwand, zumal man den Datenfluss ohnehin angeben muss.

7 1 Einleitung Wer hat das Buch geschrieben? Autor des Buches ist Dr. Ulrich Mende, der auch bereits das Vorgängerbuch»Workflow und ArchiveLink mit SAP«[2] beim dpunkt.verlag geschrieben hat. Er arbeitet seit 13 Jahren selbstständig als Entwickler für SAP Business Workflow, in den letzten Jahren hauptsächlich im IS-U-(Industry Solution Utilities) Umfeld für große Energieversorger. Parallel dazu führt er Workshops für Workflow-Entwickler durch. Dank Der ganz besondere Dank des Autors gilt der Fa. affinis consulting GmbH in Hamburg. Ohne deren großzügige Unterstützung durch die Bereitstellung eines SAP-Entwicklungssystems wäre dieses Buch nicht zustande gekommen. Insbesondere hat Herr Marc Trümer (affinis intelligent solutions GmbH & Co. KG) nicht nur organisatorisch, sondern auch fachlich (Kap. 13) vielfältig zum Gelingen des Buches beigetragen. Weiterhin bedankt sich der Autor herzlich bei seinen Fachkolleginnen und Kollegen, Frau Eva Schleißheimer, Herrn Stefan Porges, Herrn Ayhan Toraman, Herrn Hüdayi Mengus und Herrn Mario Gratz, für thematische Diskussionen, Hinweise und Korrekturen zum Buch. Dem dpunkt.verlag sei vielmals gedankt für die jederzeit konstruktive und vertrauensvolle Zusammenarbeit, insbesondere dem Lektor Herrn Dr. Barabas sowie der Korrektorin Frau Ursula Zimpfer.

8 2 Einleitung Worum geht es in diesem Buch? Längst hat sich SAP Business Workflow als modulübergreifende Querschnittstechnologie zur Abbildung und automatisierten Bearbeitung komplexer, arbeitsteiliger Prozesse im SAP-Umfeld etabliert. Viele Unternehmen haben erkannt, welches enorme Rationalisierungspotenzial diese Technologie für die Prozessbearbeitung in ihrem Unternehmen enthält. Stellvertretend seien hier die Workflow-Prozesse im IS-U (Industry Solution Utilities) genannt, die vermutlich die komplexesten Prozesse im SAP-Umfeld überhaupt darstellen. So hat ein Netzbetreiber-Workflow im Lieferantenwechsel ca. 100 Schritte und kommuniziert via Marktkommunikation (IDOCs, B2B) mit Workflows, die parallel auf den SAP-Systemen fremder Unternehmen (Lieferanten und Messstellenbetreiber) laufen. Entsprechend hoch ist der Aufwand, den die Unternehmen inzwischen für die Entwicklung und Administration von Workflows betreiben. Viele Entwickler, die sich früher ausschließlich mit ABAP (Advanced Business Application Programming) befasst haben, müssen sich nun in der einen oder anderen Form mit der Workflow-Entwicklung vertraut machen. Inzwischen gibt es zum Thema Workflow-Entwicklung mehrere Bücher, in denen die Technologie aus Entwicklersicht von Anfang an detailliert besprochen wird [1], [2], [3]. Die Grundlagen der Workflow-Entwicklung sind daher relativ gut beschrieben und deshalb nicht Hauptgegenstand dieses Buches. Dieses Buch konzentriert sich dagegen auf die erheblichen Veränderungen in der Workflow-Entwicklung, die durch ABAP Objects möglich bzw. nötig werden. Mit dem Entstehen der Workflow-Technologie wurden die sogenannten BOR-Objekttypen (BOR = Business Object Repository) als quasi objektorientierte Verschalung aller ABAP-Anwendungen eingeführt. BOR-Objekttypen (BOR-OT) waren von Anfang an die Workflow-Objekttypen. Für ABAP-Entwickler war die stark makroorientierte Programmierung von und mit BOR-Objekttypen oft sehr gewöhnungsbedürftig, was vermutlich auch ein Grund dafür ist, dass es immer noch wenig Workflow-Entwickler gibt. Um das Jahr 2000 erschien ABAP Objects als echter objektorientierter Sprachbestandteil von ABAP. Viele Anwendungen nutzten sofort die stark verbesserten Möglichkeiten der Programmierung, die sich damit boten. Workflow-Entwickler mussten allerdings bis zum Basisrelease 6.20 warten, bis sie neben BOR-OT auch ABAP-Klassen in Workflows benutzen konnten. (Dabei muss man den Zeitverzug von

9 An wen richtet sich das Buch? 3 einigen Jahren beachten, der zwischen der Freigabe eines Release bei SAP und dessen flächendeckender Einführung beim Anwender besteht.) Dies führte in vielen Fällen dazu, dass die BOR-OT nur die Workflow-Verschalung waren, in deren Inneren sofort Klassenmethoden aufgerufen wurden. Inzwischen kann ein Releasestand von SAP Basis von 6.20 und höher durchaus vorausgesetzt werden. Der Nutzung von ABAP Objects anstelle von BOR-OT steht also nichts mehr im Wege. Dass sich viele Entwickler dennoch vor diesem Schritt scheuen, mag an der jahrelangen Gewöhnung an das BOR und dessen Business-Intelligenz (in Form vieler Millionen Zeilen Code) liegen. Insofern ist es beruhigend, zu wissen, dass hier kein»entwederoder«notwendig ist. BOR-OT und ABAP Objects können in friedlicher Koexistenz in ein und demselben Workflow leben. Die alten, bewährten, aber unverzichtbaren Dinge erledigen BOR-Objekte; neue Funktionalitäten werden über ABAP Objects realisiert. Oft hört man von Entwicklern folgende Meinung: Wozu eigentlich Objektorientierung? Das verkompliziert alles nur; ein einfacher Report tut es auch. In diesem Sinne stellt SAP Business Workflow eine echte»daseinsberechtigung«für ABAP Objects dar. Letztlich ist der Workflow nämlich ein komplexes Framework, das mit beliebigen, unbekannten Objekten gleichartig hantieren soll. In diesem Umfeld kommen alle Konzepte der Objektorientierung wie Kapselung, Vererbung, Interfaces, Polymorphie, Events und Ausnahmeklassen auf völlig natürliche Art zum Tragen. Dies zu vermitteln ist das hauptsächliche Ziel des Buches. Für die»praktiker«unter den Entwicklern kann es den Zugang zur Objektorientierung erleichtern. An wen richtet sich das Buch? Das Buch richtet sich an EDV-Spezialisten, die auf die eine oder andere Weise mit SAP Business Workflow zu tun haben. Das können sein: Studenten der Informatik Entwickler bei SAP-Anwendern Systemverantwortliche bei SAP-Anwendern (Administratoren, Entscheider) Angestellte oder freie SAP-Berater Das Buch richtet sich zunächst an alle Workflow-Entwickler, die es leid sind, immer wieder Container mit SWC_GET_ELEMENT auszupa-

10 4 Einleitung cken und am Ende der Methode mit SWC_SET_ELEMENT wieder einzupacken. An solche also, die die modernen Methoden von ABAP Objects, die sie u.u. bereits in der reinen ABAP-Programmierung verwenden, nun auch direkt, ohne Bruch in der Workflow-Entwicklung benutzen möchten. Für diejenigen unter den Lesern, die mit der Objektorientierung noch nicht vertraut sind, ist eine Einführung in ABAP Objects enthalten. Hier werden Begriffe wie Kapselung, Vererbung, Redefinition und Polymorphie praxis- und Workflow-bezogen dargestellt. Und dann ist das Buch für solche Entwickler gedacht, die den Einstieg in die Workflow-Entwicklung wagen wollen bzw. sollen. Ihnen ist zu raten, von Anfang an mit der neuen Technologie zu arbeiten. Aber auch Entwickler, denen der übliche Zugang zu ABAP Objects zu theoretisch ist, können hier u.u. einen besseren, weil praktischen Zugang zur Objektorientierung finden. Workflow-Berater, die bereits über gute Kenntnisse in ABAP Objects und Workflow verfügen, können in diesem Buch viele konkrete Hinweise für ihre Projekte bekommen. Workflow-Administratoren sollten auf jeden Fall das einführende Kapitel sowie die Kapitel zum Laufzeitsystem und zur Administration lesen. Entscheider (Teamleiter), die sich einen Überblick über SAP Business Workflow verschaffen möchten, sollten das einführende Kapitel lesen. Außerdem gibt es in fast jedem Kapitel einen Punkt»Konzept«, der die jeweilige Grundidee erläutert. Hinweise zu den einzelnen Kapiteln Kapitel 1 SAP Business Workflow im Überblick Hier wird die grundlegende Architektur des SAP Business Workflow mit ihren wichtigsten Bestandteilen und Begriffen einführend dargestellt. Neue Begriffe Laufzeit, Definitionszeit, Bearbeiter, Workplace Kapitel 2 Workflow Entwicklung Tools Hier werden Hinweise zu den Entwicklungstools gegeben. Ausführlich wird das Workflow-Bereichsmenü SWLD vorgestellt. Empfohlen wird die paketorientierte Arbeit im Object Navigator (SE80). Weiterhin

11 Hinweise zu den einzelnen Kapiteln 5 werden zwei große Gruppen von Beispiel-Workflows von SAP beschrieben. Hinweise zum Thema Workflow im SAP Service Marketplace und in der SDN-Community (SDN = SAP Developer Network) runden dieses Kapitel ab. Neue Begriffe Schichtenmodell der Workflow-Entwicklung, Bereichsmenü SWLD, WFUNIT, WF_Verify, Online Help, SDN Kapitel 3 ABAP Objects Grundlagen In diesem Kapitel werden überblicksartig die notwendigen Grundlagen von ABAP Objects zusammengefasst. Es erspart dem Leser ohne Kenntnisse von ABAP Objects (ABAP OO) das Nachschlagen der Grundbegriffe in anderen Büchern. Wo es möglich ist, wird bereits Bezug auf die spätere Verwendung im Workflow-Umfeld genommen. Der erfahrene ABAP-OO-Entwickler kann dieses Kapitel ohne Nachteile überspringen. Neue Begriffe: Klassen, Komponenten, Attribute, Methoden, Sichtbarkeit, Ereignisse, Vererbung, Redefinition, Instanzen, Referenzen, Interfaces, Polymorphie, Ausnahmeklassen Kapitel 4 Durchgängiges Beispiel des Buches: Kreditverträge Im Buch wird ein durchgehendes Beispiel zur Vertragsbearbeitung benutzt. In diesem Kapitel werden die Tabellen und Transaktionen kurz dargestellt, die dann in den Workflow-Klassen benutzt werden. Kapitel 5 Die neue Welt: ABAP Objects im Workflow Hier werden die Erkenntnisse aus Kapitel 3 in den Workflow-Klassen verwendet. Ausführlich wird das Interface IF_WORKFLOW besprochen. Es wird gezeigt, wie die Ereignisse von ABAP Objects als Workflow-Ereignisse systemweit sichtbar gemacht werden. Neue Begriffe: Workflow-Interface IF_WORKFLOW, persistente Objektreferenz, Workflow-Ereignisse Kapitel 6 Workflow-Container und Workflow-Ereignisse In diesem Kapitel werden Definition und Verwendung von Containern und Ereignissen im Workflow-Umfeld besprochen.

12 6 Einleitung Für Container werden Beispielprogramme zu Definition, Datenflüssen, persistenter XML-Speicherung diskutiert. Danach werden die Erzeugung und Verarbeitung von systemweiten Ereignissen detailliert besprochen. Neben den verschiedenen direkten und indirekten Methoden der Ereigniserzeugung liegt der Schwerpunkt auf der Ereignisverarbeitung. Letztere stellt die Reaktion auf Statusänderungen an Objektinstanzen dar. Es werden Beispiele für die Implementierung eigener Koppelbausteine diskutiert. Neue Begriffe: Containerklasse CL_SWF_CNT_CONTAINER, Strukturpersistenz, XML-Persistenz, Eventklasse CL_SWF_EVT_EVENT, Ereigniskopplung, Ereignisverbraucher, Check-Funktionsbaustein, Typ- Funktionsbaustein, Eventqueue, Ereigniscontainer, Datenfluss Kapitel 7 Organisationsmanagement und Regeln Dieses Kapitel erläutert die Möglichkeiten zur Abbildung des Organisationsmanagements. Hier wird auf die sogenannten Infotypen, insbesondere auf die Objekte des Organisationsmanagements sowie die zwischen ihnen möglichen Beziehungen, eingegangen. Ziel ist die Nutzung der hinterlegten Informationen zur automatischen Bearbeiterfindung in Workflows. Neue Begriffe: Organisationseinheit, Stelle, Planstelle, Person, User, Regel, Zuständigkeit, Auswertungsweg, Bearbeiterfindung Kapitel 8 Standardaufgaben anlegen und verwenden Es wird gezeigt, wie Einzelschrittaufgaben mit Bezug auf eine Klassenmethode angelegt werden. Neue Begriffe: Einzelschrittaufgabe, Hintergrundaufgabe, Aufgabencontainer, führendes Objekt, Datenfluss, mögliche Bearbeiter, generelle Aufgabe, Workitem-Text, Ausdruck, Defaultregel Kapitel 9 Workflow-Muster anlegen und verwenden Es wird gezeigt, wie Workflows unter Benutzung von Klassen, Events und Einzelschrittaufgaben und Regeln angelegt werden. Neue Begriffe: Workflow, Workflow-Interface, führendes Objekt, Import-, Exportund lokale Containervariablen, startendes Ereignis, Workflow-

13 Hinweise zu den einzelnen Kapiteln 7 Definition, Aktivität, ausgewählte Bearbeiter, Alternative, Mehrfachverzweigung, paralleler Abschnitt, Schleife, Containeroperation, Steuerschritt, Workflow-Version, Transport Kapitel 10 Klassenbasierte Techniken im Workflow Hier werden weitergehende klassenbasierte Techniken der Workflow- Definition und der Laufzeitsteuerung besprochen. Neue Begriffe/Stichwörter: Terminüberwachung, Nebenmethoden, Workitem-Vorschau, Workitem-Exit, dynamische Blöcke, Startbedingungen, Ad-hoc-Funktionen Kapitel 11 Klassenbasierte Eigenentwicklungen im Workflow Hier werden einige in der Praxis der Workflow-Entwicklung entstandene, Workflow-taugliche Utility-Klassen besprochen. ZCL_DATE bietet Methoden zur kompakten Berechnung von Datums- und Zeitwerten auf Fabrikkalendern an. Die Klasse ZCL_SYSTEM stellt Methoden zur generischen Erzeugung von Klassenreferenzen und zum Mailversand bereit. Beide Klassen können im Downloadbereich zum Buch in XML- Form heruntergeladen und mit dem im Buch vorgestellten Report direkt ins System eingespielt werden. Neue Begriffe/Stichwörter: GENERICINSTANTIATE, Datumsklasse, Konstantenklasse, Kommunikation zwischen Subflows, generischer Mailversand Kapitel 12 Business Workplace als Userinterface In diesem Kapitel wird der Business Workplace als Userinterface für den Workflow-Benutzer besprochen. Es werden alle Funktionen auf Workitems erläutert sowie Möglichkeiten zur persönlichen Konfiguration der Workflow-Inbox dargestellt. Neue Begriffe: Worklist, Vorschau, Status, Statusdiagramm, Workitem anzeigen, ~ ausführen, ~ annehmen, ~ zurücklegen, ~ wiedervorlegen, ~ weiterleiten Kapitel 13 Webservices im Workflow Es wird demonstriert, wie SOAP-Webservices angelegt und aus dem Workflow heraus aufgerufen werden können.

14 8 Einleitung Neue Begriffe: Webservice, SOAP-Protokoll, CL_PROXY_CLIENT, WSDL, logischer Port Kapitel 14 Das Workflow-Laufzeitsystem In diesem Kapitel wird das Laufzeitsystem des SAP Business Workflow besprochen. Die hier dargestellte technische Sicht (Tabellen und Funktionsbausteine) kann das Verständnis für den Workflow bei Informatikern erfahrungsgemäß erheblich fördern. Neue Begriffe: Workitem, Top-Level-Workitem, Laufzeittabellen, WAPI-Bausteine Kapitel 15 Tests und Fehlersuche In diesem Kapitel werden Verfahren zum Test und zur Fehlersuche vorgestellt. Dazu gehören die unterschiedlichen Transaktionen zum Suchen nach Workflows bzw. Workitems sowie die Arbeit mit den diversen Protokollen. Besonders interessant dürfte ein Report sein, der es ermöglicht, B-Workitems nachträglich im Dialog zu debuggen. Hinweise zur Bearbeitung von Kurzdumps sowie diverse nützliche Hilfsprogramme runden das Kapitel ab. Neue Begriffe: CHECKPOINT-GROUPS, Workflow-Protokolle, Debug-Report, Dump-Analyse Kapitel 16 Workflow-Administration Dieses Kapitel beschreibt die Aufgabenstellungen und Lösungsansätze in der Arbeit eines Workflow-Administrators. Zunächst werden Fragen des Customizings besprochen. Die für die Administration von Workflows wichtigen Werkzeuge (Analysetools, Diagnosetools) werden erläutert. Es werden Möglichkeiten zur Reorganisation der Laufzeitdaten dargestellt. Neue Begriffe: Workflow-Customizing, -Notification über neue Workitems, SAPconnect, Terminüberwachung, Fehlerüberwachung, Fehleritem, Diagnosereport, Workitem-Analyse, Workflow-Protokoll, Workload-Analyse, Archivierung von Workitems, SARA

15 Hinweise zu den einzelnen Kapiteln 9 Anhang Die alte Welt: BOR-Objekte im Workflow Die Objekttypen des Business Object Repository (BOR) werden als»alte«objektorientierte Verschalung der Anwendungssoftware erklärt. Dieser Anhang trägt der Tatsache Rechnung, dass viele Millionen Zeilen ABAP-Code in den vorhandenen BOR-Objekttypen ein großes Erfahrungspotenzial darstellen. Neue Begriffe: Objekttyp, Schlüssel, Attribut, Methode, synchron/asynchron, Parameter, Container, Ereignisse, Delegation, Vererbung, Interface

16 Klassenbasierte Techniken im Workflow Abb Ereignisempfänger mit Fristüberwachung Warte auf Aktivierung Verarbeitung obsolet Frist für Aktivierung überschritten Vertrag abgelehnt eingetroffen Nach 10 AT: Warten beenden ändern deaktivieren stornieren Status setzen ACTIVATED Status setzen CANCELED beendet Nach einer Fristüberschreitung setzt ein Steuerschritt das Warte-Workitem auf obsolet, wodurch dessen Obsoletzweig durchlaufen wird. In diesem befindet sich eine Sachbearbeiterentscheidung (SBE), die die Alternativen Vertrag stornieren und Vertrag aktivieren zulässt. In den entsprechenden Folgezweigen wird der Vertragsstatus dunkel (= ohne Dialog) gesetzt Klassenverwendung im Workflow ohne Standardaufgaben Konzept Viele Entwickler scheuen den Aufwand, für jede Workflow-Klasse extra das Interface IF_WORKFLOW zu implementieren und für jede (ggf. statische) Methode unbedingt eine eigene Standardaufgabe anzulegen. Es fragt sich daher, ob es nicht möglich ist, Klassen auch direkt im Workflow zu verwenden. Das geht tatsächlich, wobei unterschiedliche Varianten möglich sind. Die folgende Tabelle zeigt, wie auf welche Komponenten einer Klasse im Workflow ohne Standardaufgaben zugegriffen werden kann. Wie sich zeigt, ist dabei nur teilweise eine Implementierung von IF_WORKFLOW notwendig.

17 10.11 Klassenverwendung im Workflow ohne Standardaufgaben 305 Der statische Klassenzugriff, der einen Ausdruck über die %-Zeichen klammert, ist nur für statische Klassenkomponenten (statische Attribute und funktionale, statische Methoden) möglich. Komponente statisch Attr. Funkt. Meth. Instanzkomponente Attr. Funkt. Meth. Tab Klassenaufrufe im Workflow ohne Standardaufgaben %...% Zugriff ohne Containerreferenz kein Interface IF_WORKFLOW ja kein F4 ja kein F4 nein nein & & Zugriff mit Containerreferenz Referenz ungebunden Interface ohne Implementierung ja F4 nein! nein nein Interface nötig: IF_WORKFLOW Referenz gebunden Interface mit Implementierung ja F4 ja F4 ja F4 ja F4 Der Referenzzugriff, der einen Ausdruck über die &-Zeichen klammert, erfordert immer eine Referenz auf die Klasse im Workflow-Container. Dabei muss diese Referenz nicht einmal gebunden sein, um statische Attribute anzusprechen. Die im Folgenden vorgestellten Beispiele benutzen zunächst eine Klasse ZCL_CALC mit einer einfachen funktionalen, statischen Methode SUM (numerische Summenbildung). Zusätzlich greifen sie auf die im Abschnitt 11.1 vorgestellte Utility-Klasse ZCL_DATE zur Datumsberechnung auf Fabrikkalendern vor %-%-Zugriff ohne IF_WORKFLOW Diese Zugriffsart ist nur für statische Konstanten und statische funktionale Methoden geeignet. (Im Abschnitt wird gezeigt, wie auch nicht funktionale Methoden mit mehreren Exportparametern aufgerufen werden können.) Da es keine entsprechende Klassenreferenz im Workflow-Container gibt, kann man die Komponenten für den Ausdruck auch nicht mittels F4 aus dem Container wählen. Man muss also Namen und Signaturen der statischen Attribute und funktionalen Methoden genau kennen. Dafür kommt die Klasse vollständig ohne das Interface IF_WORKFLOW aus. Bei Fehlern in der Eingabe erhält man allerdings detaillierte und sehr hilfreiche Hinweise, was an dem Ausdruck nicht stimmt.

18 Klassenbasierte Techniken im Workflow Die Abbildung zeigt, wie eine statische Methode SUM einer Klasse ZCL_CALC (ohne Workflow-Interface) mit zwei konstanten Werten für die beiden Summanden in einer Containeroperation verwendet wird. Abb Ausdruck mit funktionaler Methode in Containerzuweisung In der folgenden Abbildung wird dieselbe Methode in einem Datenfluss benutzt, ihr werden aber als Summanden die beiden Containervariablen S1 und S2 übergeben. Abb Funktionale Methode mit Parametervariablen im Datenfluss &-&-Zugriff über ungebundene Containerreferenzen Es leuchtet ein, dass ungebundene Referenzen nur auf statische Komponenten zugreifen können, da eben keine Instanz vorhanden ist. Leider können sie aber ausschließlich statische Attribute behandeln, mit statischen, funktionalen Methoden kommen sie nicht zurecht. Diese werden zwar per F4-Hilfe angeboten und können auch ausgewählt werden, liefern aber keine Werte. Die statischen Attribute werden mit ihren Werten bereits im Container angezeigt.

19 10.11 Klassenverwendung im Workflow ohne Standardaufgaben 307 Abb Ungebundene Klassenreferenz im Container &-&-Zugriff über gebundene Containerreferenzen Mit echten, gebundenen Containerreferenzen kann man auf alle Komponenten zugreifen, es besteht immer eine Eingabehilfe, sowohl für Attribute als auch für funktionale Methoden. Natürlich muss das Interface IF_WORKFLOW für entsprechende Instanziierung unterstützt werden. Ein Trick für Utility-Klassen, die ausschließlich statische, funktionale Methoden besitzen, besteht darin, eine Pseudoinstanziierung zu nutzen. Dies wird am Beispiel der Utility-Klasse ZCL_DATE (siehe Abschnitt 11.1) dargestellt. Folgende Punkte sind zu erledigen, um die Klasse und ihre statischen, funktionalen Methoden im Workflow ohne Standardaufgaben und mit komfortabler F4-Hilfe zu nutzen: Klasse hat keinen CONSTRUCTOR, da nur Pseudoinstanziierung für Workflow. Interface IF_WORKFLOW in der Klasse eintragen. Statische Membervariable MO_SELF Type Ref To ZCL_DATE anlegen. Keine Schlüsselattribute Coding für Interfacemethoden FIND_BY_LPOR und LPOR wie in Listing eintragen. Klassenreferenz im Workflow eintragen und initialisieren. METHOD BI_PERSISTENT~FIND_BY_LPOR. * statisch: DATA: mo_self Type Ref To ZCL_DATE if not mo_self is bound. create object mo_self. " kein CONSTRUCTOR! endif. result = mo_self. ENDMETHOD. Listing Pseudoinstanziierung

20 Klassenbasierte Techniken im Workflow METHOD BI_PERSISTENT~LPOR. result-catid = 'CL'. result-typeid = 'ZCL_DATE'. result-instid = '0'. " beliebig ENDMETHOD. Die LPOR-INSTID ist beliebig, sie wird gar nicht verwendet. Bei der Instanziierung (= Initialisierung) im Workflow kann man einfach 0 eingeben. Danach erscheint die Referenz im Workflow-Container als gebunden und man kann die statischen Methoden per F4-Hilfe an der Referenz auswählen und bekommt das vollständige Muster inklusive Signatur zum Ausfüllen in den Ausdruck eingestellt. Insbesondere, wenn man eine Utility-Klasse häufig verwenden möchte, ist der geringe Mehraufwand durch die elegante F4-Hilfe gerechtfertigt. Abb Instanziierung (= Initialisierung) der Pseudoreferenz der Utility-Klasse Abbildung zeigt einen Referenzausdruck in einem Datenfluss. Abb Kompletter (ergänzter) Ausdruck

21 10.11 Klassenverwendung im Workflow ohne Standardaufgaben 309 In der Abbildung ist die aufgeklappte Referenz in einem Datenfluss zu sehen. Man kann die Methode DATE auswählen und muss nur die Dauer ergänzen. Abb Ausdruck mit funktionaler Methode via Referenz im Datenfluss Geschachtelter Zugriff mit %-% und &-& Es ist verständlich, dass sich mehrere %-%-Paare oder mehrere &-&- Paare untereinander in einem Ausdruck nicht vertragen. Anders als bei Klammerpaaren haben sie ja keinen öffnenden und schließenden Teil. So wird der Ausdruck &ZCL_DATE.DATE(DUR=&Tage&)& abgewiesen. Der Interpreter weiß einfach nicht, ob das zweite & das schließende zum ersten ist oder ob ein neues Paar beginnt. Möglich ist allerdings die mehrfache, alternierende Schachtelung von %-%-Paaren mit &-&-Paaren, wie folgende Abbildung einer Bedingung zeigt. Abb Geschachtelter Ausdruck in einer Bedingung In Bedingungen können Klassenausdrücke nur über den einfachen Zeileneditor eingegeben werden.

22 Klassenbasierte Techniken im Workflow Es fragt sich natürlich, ob solche komplexen, geschachtelten Ausdrücke sinnvoll sind. In vielen Fällen scheint es besser, eine Zwischenvariable mit Zwischenwerten zu füllen. Das erleichtert später auch das Lesen der Workflow-Protokolle. Wer könnte schon auf Anhieb sagen, ob das Datum im o.g. Ausdruck wirklich nach dem liegt Methoden mit mehreren Exportparametern In den vorangegangenen Teilkapiteln wurde angenommen, dass die aufgerufenen Methoden funktional waren, also genau einen RETURN- ING-Parameter und keine Exportparameter haben. Diese Annahme wird durch die Verwendung in Ausdrücken (Datenflüsse, Containerzuweisungen) auch nahegelegt. SAP bietet aber eine Möglichkeit an, auch nicht funktionale Methoden, die ggf. auch mehrere Exportparameter besitzen, aufzurufen. Dies wird für die folgende Methode ZCL_CALC.POWER demonstriert, die einen Import- und zwei Exportparameter hat. Listing Nicht funktionale Methode mit zwei alternativen Exportparametern ***************************************************** * Parameters: * I Importing TYPE INT4 Natürliche Zahl * SQUARE Exporting TYPE INT4 Quadrat * CUBIC Exporting TYPE INT4 Kubik ***************************************************** method POWER. square = i ** 2. cubic = i ** 3. endmethod. Der nachfolgende Datenfluss»ernennt«über die Zuweisung _RESULT = CUBIC den Exportparameter CUBIC zum RETURNING-Parameter. Dessen Wert wird dann in der Zuweisung verwendet (s. Abb ). Dieses Verfahren funktioniert sinngemäß auch für den anderen Parameter SQUARE. Gleichzeitig lassen sich die beiden Exportparameter leider nicht verwenden, folgende Anweisung wird abgewiesen: Leider nicht möglich! ZCL_CALC.POWER(I=&S1&;_RESULT=CUBIC;SQUARE=&QUADRAT&)

23 10.11 Klassenverwendung im Workflow ohne Standardaufgaben 311 Abb Aufruf der Methode ZCL_CALC.POWER in einem Datenfluss Das ist nicht ganz verständlich, denn wenn man via I=&S1& Importparameter mit Werten aus dem Container versorgen kann, dann könnte man ja sicher auch mit SQUARE=&QUADRAT& die Werte der Exportparameter in den Container zurückschreiben. Vielleicht befürchtet man dadurch unkontrollierbare Seiteneffekte im Container Objektreferenzen on-the-flight Wenn eine Aufgabe als Importparameter Objektreferenzen verlangt und man schon zur Definitionszeit weiß, welche Objektinstanz zu übergeben ist, so kann man Ausdrücke der folgenden Form in Datenflüssen benutzen: [BO.ZVERTRAG ] [CL.ZCL_VERTRAG ] für BOR-Objekte für Klasseninstanzen Das hat den Vorteil, dass man keine Objektreferenz im Quellcontainer haben muss. Abb Objekt on-the-flight im Datenfluss Containervariablen kann man in diese Ausdrücke aber nicht einbinden, folgender Ausdruck ist ungültig: [CL.ZCL_VERTRAG. &VerNr&] F A L S C H! Die Ausdrücke müssen zur Definitionszeit vollständig bekannt sein.

40 10.6 Programmier-Exits für Workitems Programmier-Exits für Workitems Das Interface IF_SWF_IFS_WORKITEM_EXIT Am Schritt einer Workflow-Definition im Reiter»Programmier-Exits«können verschiedene Klassen eingetragen werden, die alle das Interface IF_SWF_IFS_WORKITEM_EXIT unterstützen müssen. Abb Workitem-Exit Typische Aufgaben, die in Userexits ausgeführt werden, sind: anwendungsspezifisches Logging Mailversand Manipulieren von Workitems Logging mit CHECK-POINT-Gruppe Das Logging wird am Beispiel einer CHECK-POINT-Gruppe ZVER- TRAG demonstriert, die mit TA SAAB angelegt und aktiviert wird (s. Abb ). Als Beispiel wird die Klasse ZCL_WI_USEREXIT_LOGGING betrachtet, die verschiedene Statusübergänge an Workitems protokolliert. Durch Verwendung des Interface erbt die Klasse die Methode EVENT_RAISED mit folgenden Importparametern (s. Abb ).

41 Klassenbasierte Techniken im Workflow Abb CHECK-POINT-Gruppe ZVERTRAG mit Aktivierungen Abb Parameter im Workitem-Exit Die möglichen Events sind: Abb Mögliche Events für den Aufruf des Workitem-Exits

42 10.6 Programmier-Exits für Workitems 281 Alle notwendigen Angaben über das Workitem, den zugehörigen Workflow, die Containerelemente und -objekte usw. bekommt man bei Bedarf aus der Referenz auf den Workitem-Kontext: Abb Interface IF_WAPI_WORKITEM_ CONTEXT METHOD if_swf_ifs_workitem_exit~event_raised. DATA: ls_wi_header TYPE swr_wihdr, ls_statra TYPE sww_statra, lv_datum_txt(10) TYPE c, lv_zeit_txt(8) TYPE c, lv_subkey(60) TYPE c. ls_wi_header = im_workitem_context->get_header( ). ls_statra = im_workitem_context->get_state_transition( ). WRITE sy-datum TO lv_datum_txt. WRITE sy-uzeit TO lv_zeit_txt. CONCATENATE ls_wi_header-wi_id lv_datum_txt lv_zeit_txt im_event_name INTO lv_subkey SEPARATED BY space. if ls_statra-tar_stat is initial. concatenate lv_subkey ls_wi_header-wi_stat into lv_subkey separated by space. else. concatenate lv_subkey '-->' ls_statra-tar_stat into lv_subkey separated by space. endif. Listing 10 8 Workitem-Exit mit Logging

43 Klassenbasierte Techniken im Workflow wait up to 1 seconds. LOG-POINT ID zvertrag SUBKEY lv_subkey FIELDS ls_wi_header-wi_rh_task ls_wi_header-wi_id im_event_name. ENDMETHOD. Das folgende Protokoll zeigt, welche Ereignisse für ein Workitem durchlaufen wurden, wobei bei Statusübergängen der neue Status angezeigt wird. Abb Anzeige der Log-Einträge zum Userexit Mit dieser Übersicht ist es einfach, weitere Dinge wie Mailversand zu programmieren Automatisches Zurücklegen eines Workitems Wenn Workitems begonnen und abgebrochen werden, dann sind sie im Status STARTED und damit nicht mehr für alle ursprünglichen Empfänger sichtbar. Dies kann zu Arbeitsverzögerungen führen, wenn Mitarbeiter vergessen, begonnene (angenommene), aber nicht abschließend bearbeitete Workitems in den Bearbeiterpool zurückzulegen. Der hier vorgestellte Userexit erledigt das automatisch. Leider ist das nicht ganz so einfach, wie man vermuten könnte. Ein direkter Aufruf eines FBS zum Zurücklegen eines Workitems (z.b. SWL_ADM_BACK) schlägt fehl, da das während eines Statusüberganges nicht erlaubt ist. Es wird daher ein asynchrones Verfahren eingesetzt, wozu die Klasse ZCL_WI_USEREXIT_PUTBACK benutzt wird. Das Verfahren funktioniert für beliebige Dialog-Workitems, da es keinerlei Anwenderdaten liest. Das zurückzulegende Workitem wird in

44 10.6 Programmier-Exits für Workitems 283 eine Tabelle ZPUTBACKWI geschrieben, danach wird im Hintergrund der Report ZAO_PUTBACK_WI via SIMPLE_BATCH_JOB_- SUBMIT gestartet, der alle Einträge dieser Tabelle liest und die Workitems mit o.g. FBS zurücklegt. METHOD IF_SWF_IFS_WORKITEM_EXIT~EVENT_RAISED. DATA: ls_wi_header TYPE swr_wihdr, lv_wi_stat TYPE sww_wistat, lv_wi_id TYPE sww_wiid, lo_wi_cont TYPE REF TO if_swf_ifs_parameter_container, ls_witab TYPE zvmk_put_back_wi. Listing 10 9 Workitem-Exit für das Zurücklegen eines Workitems lo_wi_cont = im_workitem_context->get_wi_container( ). ls_wi_header = im_workitem_context->get_header( ). lv_wi_id = ls_wi_header-wi_id. lv_wi_stat = ls_wi_header-wi_stat. * Zurücklegen des WI asynchron im Batchjob bei Statuswechsel * zu Status STARTED oder COMMITTED (nach Abbrechen dies WI) IF im_event_name = 'AFT_EXEC' AND ( lv_wi_stat = 'STARTED' OR lv_wi_stat = 'COMMITTED' ). ls_witab-wi_id = ls_wi_header-wi_id. MODIFY zputbackwi FROM ls_witab. CALL FUNCTION 'SIMPLE_BATCH_JOB_SUBMIT' EXPORTING program = 'ZAO_PUTBACK_WI' * VARIANT = ' ' EXCEPTIONS submit_failed = 1 OTHERS = 2. ENDIF. ENDMETHOD. REPORT ZAO_PUTBACK_WI. DATA: lv_wi_stat TYPE sww_wistat, ls_witab TYPE zputbackwi, lt_witab TYPE STANDARD TABLE OF zputbackwi. * START-OF-SELECTION. " Alle zurückzulegenden WIs holen SELECT * FROM zputbackwi INTO TABLE lt_witab. WAIT UP TO 1 SECONDS. LOOP AT lt_witab INTO ls_witab. Listing Bacht-Report zum Zurücklegen eines Workitems

45 Klassenbasierte Techniken im Workflow SELECT SINGLE wi_stat INTO lv_wi_stat FROM swwwihead WHERE wi_id = ls_witab-wi_id. IF sy-subrc = 0 AND ( lv_wi_stat = 'STARTED' OR lv_wi_stat = 'COMMITTED' ). CALL FUNCTION 'SWL_WI_ADM_BACK' EXPORTING wi_id = ls_witab-wi_id authorization_checked = 'X' EXCEPTIONS replace_failed = 1 enqueue_failed = 2 OTHERS = 3. IF sy-subrc <> 0. " WI ist zwar in der Tabelle und hat den richtigen " Status, kann aber nicht zurückgelegt werden, " also warten bis zum nächsten Mal ELSE. DELETE FROM zputbackwi WHERE wi_id = ls_witab-wi_id. commit work. ENDIF. ELSE. DELETE FROM zputbackwi WHERE wi_id = ls_witab-wi_id. commit work. ENDIF. ENDLOOP. Nach dem Zurücklegen des Workitems, an dessen Schritt die Klasse ZCL_WI_USEREXIT_PUTBACK eingetragen ist, dauert es ein bis zwei Sekunden, dann steht das Workitem wieder auf READY. Mit diesem Userexit kann man jeden beliebigen Dialogschritt in jedem beliebigen Workflow mit der Funktion des automatischen Zurücklegens versehen Fortgeschrittene Workflow-Definition Lokale Ereignisse und Ausnahmen Unter den versionsabhängigen Grunddaten eines Workflow-Musters lassen sich auf dem Reiter Lokale Ereignisse sogenannten lokale Ereignisse und lokale Ausnahmen definieren. Diese sind ausschließlich dem jeweiligen Workflow-Muster ab der Version bekannt, in der sie definiert wurden.

46 Klassenbasierte Eigenentwicklungen im Workflow 11.1 Utility-Klasse ZCL_DATE: Datumsberechnung auf Kalendern Verwendung von Datumsberechnungen Datums- und Zeitberechnung tritt an vielen Stellen im Workflow auf. Typischerweise wird sie bei der Ermittlung von Vorlage und Erledigungsfristen verwendet. Kompliziert wird es erst, wenn die Datumsberechnung auf einem Fabrikkalender ausgeführt werden soll, wenn also Wochenenden und Feiertage ausgeblendet werden sollen. Das ist häufig bei der Angabe von Fristen oder Deadlines der Fall Implementierung von ZCL_DATE Die folgende Utility-Klasse ZCL_DATE besitzt die beiden Returningmethoden DATE() und TIME(). DATE() ermittelt ausgehend von einem Startdatum und einer Startzeit ein Ergebnisdatum durch Addition von DUR Zeiteinheiten (UNIT). Dabei kann ein Fabrikkalender angegeben werden. Außer der Dauer sind alle Parameter optional und mit Defaultwerten versehen. Gibt man nur DUR=3 an, so wird z.b. ein Datum ermittelt, das bezogen auf heute 3 Werktage auf dem Defaultfabrikkalender»01«in der Zukunft liegt. ************************************************************* * Parameters: * STARTD Importing TYPE SY-DATUM Aktuelles Datum * STARTT Importing TYPE SY-UZEIT Aktuelle Uhrzeit * DUR Importing TYPE FLOAT Dauer * UNIT Importing TYPE MSEHI Maßeinheit * CAL Importing TYPE WFCID Fabrikkalender * RV_DATE Returning TYPE SYDATUM Aktuelles Datum ************************************************************* Listing 11 1 Klasse ZCL_DATE, Methode DATE

47 Klassenbasierte Eigenentwicklungen im Workflow METHOD DATE. DATA: lv_start_date TYPE sy-datum, lv_start_time TYPE sy-uzeit, lv_end_date TYPE sy-datum, lv_end_time TYPE sy-uzeit. lv_start_date = startd. lv_start_time = startt. CALL FUNCTION 'END_TIME_DETERMINE' EXPORTING duration = dur unit = unit FACTORY_CALENDAR = cal IMPORTING end_date = lv_end_date end_time = lv_end_time CHANGING start_date = lv_start_date start_time = lv_start_time EXCEPTIONS factory_calendar_not_found = 1 date_out_of_calendar_range = 2 date_not_valid = 3 unit_conversion_error = 4 si_unit_missing = 5 parameters_no_valid = 6 OTHERS = 7. IF sy-subrc = 0. rv_date = lv_end_date. else. * MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO * WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4. ENDIF. ENDMETHOD. Die Methode TIME() funktioniert ganz ähnlich, liefert nur die Zeit zurück. Man beachte allerdings, dass die Zeitberechnung ebenfalls ein Startdatum und nicht nur eine Startzeit benötigt!

48 11.1 Utility-Klasse ZCL_DATE: Datumsberechnung auf Kalendern 315 ************************************************************* * Parameters: * STARTD Importing TYPE SY-DATUM Aktuelles Datum * STARTT Importing TYPE SY-UZEIT Aktuelle Uhrzeit * DUR Importing TYPE FLOAT Dauer * UNIT Importing TYPE MSEHI Maßeinheit * CAL Importing TYPE WFCID Fabrikkalender * RV_TIME Returning TYPE SYUZEIT Uhrzeit ************************************************************* METHOD TIME. DATA: lv_start_date TYPE sy-datum, lv_start_time TYPE sy-uzeit, lv_end_date TYPE sy-datum, lv_end_time TYPE sy-uzeit. Listing 11 2 Klasse ZCL_DATE, Methode TIME lv_start_date = startd. lv_start_time = startt. CALL FUNCTION 'END_TIME_DETERMINE' EXPORTING duration = dur unit = unit FACTORY_CALENDAR = cal IMPORTING end_date = lv_end_date end_time = lv_end_time CHANGING start_date = lv_start_date start_time = lv_start_time EXCEPTIONS factory_calendar_not_found = 1 date_out_of_calendar_range = 2 date_not_valid = 3 unit_conversion_error = 4 si_unit_missing = 5 parameters_no_valid = 6 OTHERS = 7. IF sy-subrc = 0. rv_time = lv_end_time. else. * MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO * WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4. ENDIF. ENDMETHOD.

49 Klassenbasierte Eigenentwicklungen im Workflow Um in den Fristen die Zeiten auf feste Werte eines berechneten Tages zu setzen (z.b. auf morgens 09:00), wurden entsprechende Read-only- Attribute in der Klasse angelegt. Abb Zeitkonstanten der Klasse ZCL_DATE Verwendung von ZCL_DATE in Ausdrücken Die Methoden DATE und TIME können, wie im vorhergehenden Kapitel bereits dargestellt, direkt in Zuweisungsausdrücken oder in Ausdrücken bei der Berechnung von Terminen (Vorlage, Frist) benutzt werden. Die optionalen Parameter können dabei weggelassen werden. Die Zeit bezieht sich immer auf den Tag, der mit DATE ermittelt wurde. Das folgende Beispiel zeigt einen Vorlagetermin mit folgenden Eigenschaften: Datum = Zeit = SY-DATUM (Default) + 3 TAG(Default) auf Fabrikkalender»01«(Default) Morgens 09:00 am berechneten Tag Abb Verwendung von ZCL_DATE im Vorlagetermin In der Abbildung 11 3 ermittelt ein Datenfluss das Containerelement &KeyDate& durch Rückrechnung von einem anderen Containerelement &EndDate&. Dieses wird als Parameter mitgegeben (STARTD = &EndDate&). Die Dauer ist negativ (DUR = -3), es wird ein von der Defaulteinstellung abweichender Fabrikkalender (CAL =»ZU«) benutzt.

50 11.2 Utility-Klasse ZCL_COND: komplexe Bedingungen 317 Abb Datumsberechnung in die Vergangenheit Es ist erstaunlich, wie leistungsfähig diese Verwendung von statischen Returningmethoden ist. Beim Einsatz von BOR-Methoden hätte man hier extra einen Schritt einfügen müssen. Verwendet man ZCL_DATE wie oben dargestellt nur in %-Ausdrücken, so ist das Interface IF_WORKFLOW nicht notwendig. Wenn man es doch implementiert, ggf. mit der im letzten Kapitel erwähnten Pseudoinstanziierung, dann kann man die Ausdrücke bequem über die F4-Hilfe vorschlagen lassen. Klassenausdrücke mit % ohne IF_WORKFLOW 11.2 Utility-Klasse ZCL_COND: komplexe Bedingungen Konzept komplexer Bedingungen im Workflow Bereits die Modellierung einer einfachen Überkreuzbedingung zwischen Parallelzweigen (Abschnitt ) mithilfe von lokalem Ereignis und Ereignisempfänger war sehr unhandlich. Noch komplexere Bedingungen würden entsprechend zu noch aufwendigerer Modellierung führen. Es fragt sich daher, ob man nicht eine allgemeine Methode zur Abbildung solcher Bedingungen finden kann, die mit der Modellierung über Vorgänger-Nachfolger-Beziehungen nicht erfassbar sind. Eine solche Methode wird hier vorgestellt. Sie lässt sich als eine Art Meilensteinmethode verstehen, mit deren Hilfe wichtige Zustände in der Objektbearbeitung erfasst und in Workitem-Startbedingungen geprüft werden können. Folgende Bestandteile werden vorgestellt: Abbildung beliebiger Bedingungen Tabelle ZCONDITION, in der die für eine Objektinstanz erfüllten Bedingungen stehen. Eine Utility-Klasse ZCL_COND (ohne IF_WORKFLOW), die die statischen Methoden SET und CHECK für den Tabellenzugriff implementiert.

51 107 5 Die neue Welt: ABAP Objects im Workflow 5.1 Problemstellung Workflows laufen über Tage, Wochen, Monate oder sogar Jahre. Sie überstehen Systemdownzeiten, Systemupgrades und sogar Releasewechsel. Und nur Bruchteile dieser Zeit werden zur eigentlichen Codebearbeitung in den Methoden der Einzelschrittaufgaben benutzt. Die übrige Zeit warten die Daten von Workitems (von Workflow-Mustern und von Einzelschrittaufgaben) daher in persistenter Form in sogenannten Containern. Ursprünglich waren Container einfach transparente Tabellen (SWWCONT, SWW_CONTOB), heute wird als Persistenzform die sogenannte XML-Persistenz (Tabelle SWWCNTP0) bevorzugt. Dabei ist es wichtig, dass in diesen Containern nie die Anwendungsdaten selbst, sondern immer nur Referenzen auf die eigentlichen Anwendungsdaten in den Anwendungstabellen gehalten werden. Erst unmittelbar vor der Ausführung eines Workitems wird aus solch einer persistenten Referenz ein Objekt im Hauptspeicher, dessen zugehörigen Instanzmethoden aufgerufen werden können. Nun ist SAP Business Workflow eine modulübergreifende Querschnittstechnologie. Das Workflow-System muss daher mit den unterschiedlichsten Arten von Business-Objekten umgehen können. Dazu geht es generisch vor. Es verlangt von allen Objekten, die im Workflow bearbeitet werden sollen, dass sie sich an gewisse Konventionen halten. Technisch bedeutet das, dass die Klassen von Workflow-Objekten alle das Interface IF_WORKFLOW implementieren müssen. Nach diesen Ausführungen wird deutlich, dass der Gegenstand dieses Interface nur die Konvertierung von Objektreferenzen von der persistenten in die transiente Form und umgekehrt sein kann.

52 108 5 Die neue Welt: ABAP Objects im Workflow 5.2 IF_WORKFLOW Dieses Interface macht eine beliebige Klasse»Workflow-tauglich«. Dadurch wird die in den BOR-Objekttypen bereits fest eingebaute Konvertierung zwischen flüchtigen Klassenreferenzen (Hauptspeicher, Aufruf von Methoden) und persistenten Referenzen (Container von Workflows und Schritten) im Kontext von ABAP Objects erreicht. Erst die Verwendung dieses Interface ermöglicht die Kennzeichnung eines oder mehrerer Instanzattribute als»key-attribut«. Die angesprochene Konvertierung wird ausschließlich dann benötigt, wenn auch Instanzen von Workflow-Klassen verwendet werden sollen, d.h., wenn Instanzmethoden aufgerufen werden sollen. Wenn man also eine Klasse im Workflow benutzen will, die ausschließlich statische Attribute und Methoden verwendet, so braucht man dieses Interface gar nicht auszuprägen (muss es aber aus formellen Gründen doch in die Klasse aufnehmen). Das Erzeugen bzw. Löschen von Klasseninstanzen hat keinerlei Einfluss auf die DB-Daten der Objektinstanz in den Anwendungstabellen. Zu einem Eintrag in der Kopftabelle eines Business-Objektes (Rechnung, Wechselbeleg, Sperrbeleg usw.) können zu einem Zeitpunkt 0..N (N beliebig) persistente oder transiente Objektinstanzen existieren. Die SAP Workflow Engine behandelt alle Objekte auf generische Weise. Bei der schrittweisen, interpretativen Abarbeitung eines Workflow-Musters entstehen ständige Kontextwechsel, zu denen die Referenzen auf die zu bearbeitenden Objekte persistent gespeichert bzw. wieder in den Hauptspeicher geladen werden müssen, um die entsprechende Instanz einer ABAP-Klasse zu erzeugen. Beispiel einer Vertragsbearbeitung im Workflow Der Workflow gelangt an einen Dialogschritt zu einer Vertragsgenehmigung, der zunächst für einige Stunden oder auch Tage im Eingangskorb des überlasteten Empfängers liegen bleibt. Während dieser Zeit existiert die Vertragsreferenz ausschließlich persistent auf der Datenbank. Der Bearbeiter markiert das Workitem (WI) und klickt auf den in der WI-Vorschau angegebenen Link zum Vertrag, um ihn anzuzeigen. In diesem Moment wird automatisch eine Konvertierung der persistenten in die transiente Vertragsreferenz durchgeführt. An der transienten Referenz wird vom Workflow-Laufzeitsystem dynamisch die Displaymethode aufgerufen. Der Bearbeiter legt das WI zurück, um essen zu gehen persistente Vertragsreferenz.

53 5.2 IF_WORKFLOW 109 Der Bearbeiter führt das Workitem aus, was wieder zu einer Konvertierung persistent transient führt. Die Methode GENEHMIGEN wird an der so im Hauptspeicher erzeugten Objektreferenz ausgeführt. Der Schritt ist beendet und die Vertragsreferenz existiert wieder nur auf der DB. Die transienten Objektreferenzen im Hauptspeicher sind einfach Objektreferenzen nach ABAP Objects, die aus der Klasse und dem Schlüssen in der persistenten Darstellung erzeugt werden. Die persistente Darstellung SIBFLPOR ist eine Struktur aus 3 CHAR-Feldern: Abb. 5 1 Struktur SIBFLPOR für persistente Klassenreferenzen Während die eingebettete SIBFOTYPE auch für die Typisierung von BOR-Objekten gilt, besitzen diese einen längeren Schlüssel. Deshalb gibt es für BOR-Objekte auch eine andere Persistenzstruktur: SIBFL- PORB: Abb. 5 2 Struktur SIBFLPORB für persistente BOR-Referenzen Da das generische Laufzeitsystem die einzelnen Workflow-Klassen, mit denen es später arbeiten soll, gar nicht kennen kann, überträgt es die Aufgabe der wechselseitigen Konvertierung an die Klassen selbst. Genau das ist der Gegenstand des Interface BI_PERSISTENT, das das erste eingebettete Teilinterface von IF_WORKFLOW ist. Außerdem gibt es eine Reihe von Komponenten der SAP Workflow Engine, z.b. das Workflow-Protokoll, die Objekte anzeigen können. Hierfür müssen entsprechende Funktionen durch das Objekt bereitgestellt werden.

54 110 5 Die neue Welt: ABAP Objects im Workflow Das Interface IF_WORKFLOW legt eine logische Klammer um die Interface BI_PERSISTENT (Instanzverwaltung) und BI_OBJECT (Objektverhalten). Das Interface IF_WORKFLOW enthält folgende Methoden: Abb. 5 3 Interface IF_WORKFLOW im Class Builder (SE24) Listing 5 1 Komponenten von BI_OBJECT *"* components of interface BI_OBJECT interface BI_OBJECT public. methods DEFAULT_ATTRIBUTE_VALUE returning value(result) type ref to DATA. methods EXECUTE_DEFAULT_METHOD. methods RELEASE. endinterface. Listing 5 2 Komponenten von BI_PERSISTENT *"* components of interface BI_PERSISTENT interface BI_PERSISTENT public. Interface BI_OBJECT. class-methods FIND_BY_LPOR importing LPOR type SIBFLPOR Returning value(result) type ref to BI_PERSISTENT. methods LPOR returning value(result) type SIBFLPOR. methods REFRESH. endinterface.

55 5.2 IF_WORKFLOW 111 *"* components of interface IF_WORKFLOW interface IF_WORKFLOW public. Listing 5 3 Komponenten von IF_WORKFLOW Interface BI_PERSISTENT. aliases DEFAULT_ATTRIBUTE_VALUE for BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE. aliases EXECUTE_DEFAULT_METHOD for BI_OBJECT~EXECUTE_DEFAULT_METHOD. aliases FIND_BY_LPOR for BI_PERSISTENT~FIND_BY_LPOR. aliases LPOR for BI_PERSISTENT~LPOR. endinterface. BI_PERSISTANT~FIND_BY_LPOR Diese statische Methode wird immer dann gerufen, wenn eine transiente Hauptspeicherinstanz des Objektes benötigt wird, also unmittelbar vor der Ausführung eines Workitems. Mit CREATE OBJECT wird einfach ein neues Objekt vom Typ der implementierenden Klasse angelegt und als RETURNING-Parameter an das Laufzeitsystem zurückgeliefert. Der RETURNING-Parameter RESULT ist eine Interfacevariable vom Typ Ref To BI_PERSISTENT, der jede Referenz auf eine Klasse zugewiesen werden darf, die das Interface BI_PERSISTENT (oder auch IF_WORKFLOW) unterstützt. Das ist zwangsläufig bei jeder implementierenden Klasse der Fall. Das Workflow-Laufzeitsystem interessiert sich in diesem Moment nicht für die anderen Klassenmethoden der implementierenden Klasse, sondern behandelt alle Klassen bzw. ihre Objekte gleich. Das ist polymorphes Verhalten. Konvertierung Referenz DB Hauptspeicher BI_PERSISTANT~LPOR Diese Instanzmethode füllt einfach die benötigte persistente Struktur vom Typ SIBFLPOR aus den Instanzdaten und gibt sie zurück. Konvertierung Referenz Hauptspeicher DB BI_PERSISTENT~REFRESH Diese Instanzmethode füllt die Attribute der Instanz mit Werten. Dazu gehören das Lesen von Daten aus den Anwendungstabellen und ggf. der Aufbau von Referenzen auf andere Objekte.

56 112 5 Die neue Welt: ABAP Objects im Workflow BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE Diese funktionale Instanzmethode besitzt keine Importparameter, sondern nur einen RETURNING-Parameter. Sie ist vergleichbar den virtuellen Attributen im BOR. Dieser Wert wird im Workflow überall dort verwendet, wo der Schlüssel des Attributes angezeigt werden soll. BEACHTE: Der Wert wird als Datenreferenz übergeben. BI_OBJECT~EXECUTE_DEFAULT_METHOD Diese Instanzmethode ist der Defaultmethode im BOR vergleichbar. Sie hat keine Parameter, sondern kennt nur die Instanzkomponenten. Meist ist es eine Anzeigemethode. BI_OBJECT~RELEASE Diese Instanzmethode wird aufgerufen, wenn das Objekt nicht mehr benötigt wird. Letztlich kann der Garbage Collector diese Aufgabe übernehmen. 5.3 Vertragsbearbeitung im Workflow Klasse ZCL_VERTRAG Der CONSTRUCTOR merkt sich einfach den Wert des Objektschlüssels in einer Instanzvariablen MV_VERNR und liest den gesamten Satz in die Struktur MS_VERTRAG ein. Listing 5 4 CONSTRUCTOR der Klasse ZCL_VERTRAG ************************************************************* * Parameters: * IV_VERNR Importing TYPE ZVERNR Vertragsnummer ************************************************************* method CONSTRUCTOR. * Schlüsselattribut me->mv_vernr = iv_vernr. * Vertragsdaten von DB laden select single * from ZVERTRAG into MS_VERTRAG where vernr = mv_vernr. endmethod Attribute MV_VERNR und MS_VERTRAG Das Attribut MV_VERNR ist der Schlüssel in den Anwendungstabellen und wird daher vorausschauend speziell behandelt.

57 5.3 Vertragsbearbeitung im Workflow Klasse ZCL_VERTRAG 113 Für die Attribute gibt es vor der Einbeziehung des Interface IF_ WORK- FLOW keine Kennzeichnung»Schlüsselattribut«. Dass das Attribut MV_VERNR der Schlüssel der Vertrags-Kopftabelle ist, weiß bis hierher nur der Programmierer, die Klasse weiß es nicht. Abb. 5 4 Keine Schlüsselattribute vor IF_WORKFLOW Methoden ANZEIGEN, AENDERN, GENEHMIGEN Diese Dialogmethoden (Instanz) rufen direkt den im Kapitel 4 besprochenen FBS Z_VERTRAG jeweils mit der betreffenden Aktion auf. Alle drei Instanzmethoden benutzen das Schlüsselattribut MV_ VERNR zur Identifizierung des Vertragsobjektes. Die Methoden AN- ZEIGEN und AENDERN benötigen überhaupt keine Parameter. ************************************************************* * Parameters: * * Exceptions: ************************************************************* method ANZEIGEN. CALL FUNCTION 'Z_VERTRAG' EXPORTING iv_vernr = MV_VERNR iv_aktion = 'ANZEIGEN' * IMPORTING * EV_STATUS = * EV_VERNR = EXCEPTIONS ABBRUCH = 1 OTHERS = 2. IF sy-subrc <> 0. * MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO * WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4. ENDIF. Listing 5 5 Instanzmethode ZCL_VERTRAG.ANZEIGEN endmethod.

58 114 5 Die neue Welt: ABAP Objects im Workflow Die Ausnahme CX_BO_ACTION_CANCELLED wird in der Methode AENDERN geworfen, wenn der User auf Abbrechen gedrückt hat. (Das Workflow-System behandelt diese Ausnahme ganz speziell: Es legt ein Workitem, das diese Aufgabe verwendet, zurück in den Eingangskorb. Listing 5 6 Instanzmethode ZCL_VERTRAG.AENDERN ************************************************************* * Parameters: * * Exceptions: * CX_BO_ACTION_CANCELLED Temporary Bus. Exception: Dialog ************************************************************* METHOD AENDERN. CALL FUNCTION 'Z_VERTRAG' EXPORTING iv_vernr = MV_VERNR iv_aktion = 'AENDERN' * IMPORTING * EV_STATUS = * EV_VERNR = EXCEPTIONS abbruch = 1 OTHERS = 2. IF sy-subrc <> 0. RAISE EXCEPTION TYPE cx_bo_action_cancelled. ENDIF. ENDMETHOD. Die Methode GENEHMIGEN hat einen RETURNING-Parameter, der den neuen Status zurückliefert. Im Workflow wird dieser Wert zur Verzweigung benutzt. Listing 5 7 Instanzmethode ZCL_VERTRAG.GENEHMIGEN ************************************************************* * Parameters: * RV_STATUS Returning TYPE ZSTATUS Vertragsstatus neu * * Exceptions: * CX_BO_ACTION_CANCELLED Temporary Bus. Exception: Dialog ************************************************************* METHOD genehmigen. DATA: lv_new_status TYPE zstatus. CALL FUNCTION 'Z_VERTRAG' EXPORTING iv_vernr = mv_vernr iv_aktion = 'GENEHMIGEN'

59 5.3 Vertragsbearbeitung im Workflow Klasse ZCL_VERTRAG 115 IMPORTING ev_status = lv_new_status * EV_VERNR = EXCEPTIONS abbruch = 1 OTHERS = 2. IF sy-subrc <> 0. RAISE EXCEPTION TYPE cx_bo_action_cancelled. ELSE. rv_status = lv_new_status. ENDIF. ENDMETHOD. Die Methoden selbst prüfen nicht, ob auf der DB tatsächlich ein Vertrag mit der Nummer MV_VERNR existiert. Man geht üblicherweise davon aus, dass ein Vertrag, der auf der DB angelegt wurde und über Änderungsbelege einen Workflow gestartet hat, nicht böswillig von der DB gelöscht wird. Möchte man allerdings ganz sicher gehen, so muss man in der Methode FIND_BY_LPOR (s. Abschnitt 5.4) stets auf Existenz prüfen, und zwar nicht nur beim Neuanlegen, sondern auch beim Lesen der Objekte aus der Puffertabelle Ereignisse CREATED, CHANGED und CANCELLED Die Ereignisse werden als PUBLIC-Instanzereignisse angelegt. Es werden keine Eventhandlermethoden implementiert, da sich nur der Workflow für das Ereignis interessiert. Das Laufzeitsystem stellt generische Eventhandler für alle Workflow-Klassen bereit: Abb. 5 5 Ereignisse der Klasse ZCL_VERTRAG

60 116 5 Die neue Welt: ABAP Objects im Workflow Erste Tests der Klasse ohne Interface IF_WORKFLOW Bereits an dieser Stelle können und sollten alle Komponenten der neuen Klasse getestet werden. Dazu gehören auch die Fehlersituationen wie Abbruch, falsche Vertragsnummer usw. Je mehr Softwareschichten nämlich dazukommen, desto schwieriger gestalten sich die Tests. 5.4 Einfachste Ausprägung von IF_WORKFLOW Die Einbindung des IF_WORKFLOW erweitert die Methoden von ZCL_VERTRAG. Die vom Interface»geerbten«und zu implementierenden Methoden sind grau hinterlegt. Abb. 5 6 Methodenliste von ZCL_VERTRAG nach Einbindung von IF_WORKFLOW Zunächst lagert man das Nachlesen der Instanzdaten aus dem CON- STRUCTOR in die neue Methode BI_PERSISTENT~REFRESH aus. Sie liest den gesamten Satz der Vertragstabelle in die Objektdaten. Listing 5 8 Methode BI_PERSISTENT~REFRESH ************************************************************ * Parameters: ************************************************************ method BI_PERSISTENT~REFRESH. SELECT SINGLE * FROM zvertrag INTO MS_VERTRAG WHERE vernr = me->mv_vernr. IF sy-subrc <> 0. * RAISE EXCEPTION TYPE cx_bo_error. ENDIF. endmethod. Danach wird im CONSTRUCTOR der Aufruf auf BI_PERSISTENT~ REFRESH( ) gemacht; so spart man Redundanz.

61 5.4 Einfachste Ausprägung von IF_WORKFLOW 117 ****************************************************** * Parameters: * IV_VERNR Importing TYPE ZVERNR Vertragsnummer ************************************************************ method CONSTRUCTOR. * Schlüsselattribut me->mv_vernr = iv_vernr. Listing 5 9 CONSTRUCTOR mit Aufruf auf BI_PERSISTENT~REFRESH * Vertragsdaten von DB laden BI_PERSISTENT~REFRESH( ). endmethod. Unter dem Attribute-Reiter ist durch die Einbindung des Interface IF_WORKFLOW nun eine neue Spalte»Schlüssel«zu sehen. Hier markiert man das Schlüsselfeld MV_VERNR. Dieser Schritt ist sehr wichtig. Vergisst man ihn, können Objektinstanzen später ggf. nicht richtig gefunden werden. Insbesondere die TA SWI6 (Workflows zu Objekten) funktioniert ohne Schlüsselkennzeichen gar nicht. Jeder neue Aufruf von FIND_BY_LPOR erzeugt für denselben Vertrag in der Datenbank ein neues Objekt im Hauptspeicher. Abb. 5 7 Key-Flag an der Vertragsnummer Die Klasse wird explizit angegeben, sodass diese Methode bei einer Ableitung redefiniert werden muss. ************************************************************ * Parameters: * LPOR Importing TYPE SIBFLPOR Lokale pers. Obj.-Ref * RESULT Returning TYPE REF TO BI_PERSISTENT Bus. Ref. ************************************************************ METHOD bi_persistent~find_by_lpor. * Konvertierung Container --> Hauptspeicher Listing 5 10 Methode BI_PERSISTENT~ FIND_BY_LPOR DATA: lo_vertrag DATA: lv_vernr TYPE REF TO zcl_vertrag. TYPE zvertrag-vernr. CHECK lpor-instid IS NOT INITIAL.

62 118 5 Die neue Welt: ABAP Objects im Workflow *- Inst-Id ist die Vertragsnummer lv_vernr = lpor-instid. TRY. CREATE OBJECT lo_vertrag EXPORTING iv_vernr = lv_vernr. CATCH cx_bo_error. * object not found EXIT. ENDTRY. * die neu angelegte Instanz wird zurückgegeben result = lo_vertrag. ENDMETHOD. Die Instanzmethode BI_PERSISTANT~LPOR füllt einfach die benötigte persistente Struktur vom Typ SIBFLPOR und gibt sie zurück. Auch hier wird der explizite Klassenname benutzt, was der Vererbung entgegensteht. Listing 5 11 Methode BI_PERSISTANT~LPOR ************************************************************ Parameters: * RESULT Returning TYPE SIBFLPOR Lokale pers. Obj.-Ref ************************************************************* method BI_PERSISTENT~LPOR. * Konvertierung Hauptspeicher --> Container result-catid = 'CL'. result-typeid = 'ZCL_VERTRAG'. result-instid = me->mv_vernr. endmethod. Die Instanzmethode BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE schreibt eine Referenz auf die Vertragsnummer der Instanz in das Ergebnis. Listing 5 12 Methode BI_OBJECT~DEFAULT_ATT RIBUTE_VALUE ************************************************************ * Parameters: * RESULT Returning TYPE Ref To DATA Ref.auf Datenobjekt ************************************************************ method BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE. GET REFERENCE OF MV_VERNR INTO result. endmethod. Die Instanzmethode BI_OBJECT~EXECUTE_DEFAULT_METHOD ruft hier die Anzeigemethode auf.

63 5.5 Erweiterte Ausprägung IF_WORKFLOW 119 ************************************************************ * Parameters: ************************************************************ method BI_OBJECT~EXECUTE_DEFAULT_METHOD. me->anzeigen( ). endmethod. Listing 5 13 Methode BI_OBJECT~EXECUTE_DE FAULT_METHOD ruft die Anzeigemethode auf. Die Instanzmethode BI_OBJECT~RELEASE ist leer. method BI_OBJECT~RELEASE. endmethod. 5.5 Erweiterte Ausprägung IF_WORKFLOW Listing 5 14 Methode BI_OBJECT~RELEASE ist leer. Hier wird eine erweiterte, deutlich bessere Implementierung vorgestellt, die folgende zusätzliche Leistungen bietet: Ermitteln der Objektklasse im CONSTRUCTOR, sodass die Ausprägung von IF_WORKFLOW stabil gegen Vererbung ist und nicht redefiniert werden muss. Pufferung angelegter Objektinstanzen in einer statischen Tabelle Es wird ein Instanzattribut GS_LPOR TYPE SIBFLPOR angelegt, das die persistente Objektreferenz gleich beim Anlegen des Objektes im CONSTRUCTOR speichert. Das ist sinnvoll, weil sich von einem Objekt weder Typ noch Schlüssel ändern können. Weiterhin wird im CONSTRUCTOR anstelle des SELECT SINGLE die vom IF_WORK- FLOW verlangte Refreshmethode aufgerufen. Diese kapselt den Datenbankzugriff. ************************************************************* Parameters: * IV_VERNR Importing TYPE ZVERNR Vertragsnummer ************************************************************ method CONSTRUCTOR. * Schlüsselattribut me->mv_vernr = iv_vernr. Listing 5 15 CONSTRUCTOR bei erweitertem Interface * Persistente Objektreferenz auf Klasse ZCL_VERTRAG * oder abgeleitete wird in der Interfacemethode * BI_PERSISTENT~LPOR zurückgeliefert me->gs_por-catid = 'CL'. me->gs_por-typeid = zcl_system=>get_class_of_object( me ). me->gs_por-instid = me->mv_vernr.

64 120 5 Die neue Welt: ABAP Objects im Workflow * Vertragsdaten von DB laden me->bi_persistent~refresh( ). endmethod. Weiterhin wird ein statisches PRIVATE-Attribut zur Pufferung aller Objektinstanzen in einer Tabelle eingeführt. Der Zeilentyp ist T_VER- TRAG_INSTANCE, er speichert den Schlüssel (also die Vertragsnummer VERNR) und die zugehörige Objektreferenz nebeneinander. Der darauf aufbauende Tabellentyp ist T_VERTRAG_ INSTANCES. Listing 5 16 Typen und Klassendaten für Instanzverwaltung *"* private components of class ZCL_VERTRAG *"* do not include other source files here!!! private section. types: BEGIN OF t_vertrag_instance, vernr TYPE zvernr, instance TYPE REF TO zcl_vertrag, END OF t_vertrag_instance. types: t_vertrag_instances TYPE STANDARD TABLE OF t_vertrag_instance. class-data MT_VERTRAG_INSTANCES type T_VERTRAG_INSTANCES. Die statische Methode BI_PERSISTANT~FIND_BY_LPOR sucht nun mit dem Schlüssel aus INSTID zunächst in der Puffertabelle, ob es dort bereits eine Referenz mit IV_VERNR gibt. Wenn ja, so wird diese zurückgeliefert. Nur wenn die Referenz nicht vorhanden ist, dann wird sie mit CREATE OBJECT angelegt, in die Puffertabelle eingefügt und zurückgeliefert. Diese Pufferung funktioniert auch bei Vererbung, weil in GT_INSTANCES ja auch Referenzen für abgeleitete Klassen gespeichert werden können (die Schlüsselattribute dürfen sich natürlich bei Ableitung nicht ändern). Listing 5 17 Methode FIND_BY_LPOR mit Instanzpufferung ************************************************************* * Parameters: * LPOR I TYPE SIBFLPOR Lokale pers. Obj.-Ref * RESULT R TYPE REF TO BI_PERSISTENT Pers. Bus. Instanz ************************************************************* METHOD bi_persistent~find_by_lpor. DA-TA: lo_vertrag TYPE REF TO zcl_vertrag. DATA: lv_vernr TYPE zvertrag-vernr. DATA: ls_vertrag_instance TYPE t_vertrag_instance.

65 5.5 Erweiterte Ausprägung IF_WORKFLOW 121 CHECK lpor-instid IS NOT INITIAL. *- Inst-Id ist die Vertragsnummer lv_vernr = lpor-instid. * Die Klassenvariable gt_vertrag_instances verwaltet * alle Instanzen dieser Klasse, die gleichzeitig im * Hauptspeicher leben * Nachsehen, ob es eine Instanz zum Vertrag VERNR gibt READ TABLE gt_vertrag_instances WITH KEY vernr = lv_vernr INTO ls_vertrag_instance. IF sy-subrc <> 0. " nein, neu anlegen und in die Liste TRY. CREATE OBJECT lo_vertrag type (lpor-typeid) EXPORTING iv_vernr = lv_vernr. CATCH cx_bo_error. * object not found EXIT. ENDTRY. ls_vertrag_instance-vernr = lv_vernr. ls_vertrag_instance-instance = lo_vertrag. APPEND ls_vertrag_instance TO mt_vertrag_instances. ENDIF. * die gefundene oder neu angelegte Instanz wird zurückgegeben result = ls_vertrag_instance-instance. ENDMETHOD. Die Instanzmethode BI_PERSISTANT~LPOR gibt einfach die bereits gefüllte Struktur GS_POR zurück. method BI_PERSISTENT~LPOR. result = me->gs_por. endmethod. Listing 5 18 Methode LPOR liefert Instanzdatum GS_POR. Die Instanzmethode BI_PERSISTENT~REFRESH liest den gesamten Satz der Vertragstabelle in den Hauptspeicher. method BI_PERSISTENT~REFRESH. SELECT SINGLE * FROM zvertrag INTO MS_VERTRAG WHERE vernr = me->mv_vernr. IF sy-subrc <> 0. * RAISE EXCEPTION TYPE cx_bo_error. ENDIF. endmethod. Listing 5 19 Methode REFRESH liest Vertragsdaten von der DB

66 122 5 Die neue Welt: ABAP Objects im Workflow Die Instanzmethode BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE schreibt eine Referenz auf die Vertragsnummer der Instanz in das Ergebnis. Listing 5 20 Wert des Defaultattributes ist Vertragsnummer. method BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE. GET REFERENCE OF MV_VERNR INTO result. endmethod. Die Instanzmethode BI_OBJECT~EXECUTE_DEFAULT_METHOD ruft hier die Anzeigemethode auf. Listing 5 21 Defaultmethode ruft parameterlose Anzeigemethode auf. method BI_OBJECT~EXECUTE_DEFAULT_METHOD. me->anzeigen( ). endmethod. Die Instanzmethode BI_OBJECT~RELEASE ist leer. Listing 5 22 Methode RELEASE bleibt leer. method BI_OBJECT~RELEASE. endmethod. Wenn man sich ein Gefühl dafür verschaffen möchte, wie häufig die Methode FIND_BY_LPOR aufgerufen wird und wie effektiv die Pufferung der Objektinstanzen ist, dann kann man in diese Methode einen Logpoint- Eintrag zu einer CHECK-POINT-Gruppe schreiben (siehe Kap. 10). Instanzpufferung: Performance vs. Datensicherheit Der Grundgedanke der Instanzverwaltung (Instanzpufferung) in einer statischen Liste der Klasse ist die Erhöhung der Performance. In diesem Sinne wird man im Konstruktor möglichst viele (alle?) Daten der Objektinstanz von der Datenbank in entsprechende Instanzattribute einlesen. Bei nachfolgenden Zugriffen auf die Instanz sind die Daten dann bereits vorhanden. Diesem Vorteil stehen zwei potenzielle Nachteile gegenüber: Redundanz zwischen Objekt- und DB-Daten Unbefugte Instanziierung der Klasse an der Instanzverwaltung vorbei Datenunterschied zwischen Datenbank und Hauptspeicher Beide Nachteile können genau dann auftreten, wenn die Anwendungsdaten einer Objektinstanz auf der Datenbank geändert werden, was ja der eigentliche Zweck der gesamten EDV ist. Das unbefugte Instanziieren umgeht man dadurch, dass die Instanzerzeugung einer Klasse auf PRIVATE gesetzt wird. Damit ist sie nur den Methoden der eigenen

67 5.5 Erweiterte Ausprägung IF_WORKFLOW 123 Klasse erlaubt. Diese müssen zwingend zur Instanziierung die statische Methode benutzen, die die Instanzverwaltung unterstützt: *********************************************************** * Parameters: * IV_VERNR I TYPE ZVERNR Vertragsnummer * RV_VERTRAG R TYPE REF TO ZCL_VERTRAG Vertrag * * Exceptions: *********************************************************** method GET_REF. data: LS_POR type sibflpor. ls_por-catid = 'CL'. ls_por-typeid = 'ZCL_VERTRAG'. ls_por-instid = iv_vernr. rv_vertrag?= find_by_lpor( ls_por ). endmethod. Listing 5 23 Statische Methode zur Instanzerzeugung Abb. 5 8 PRIVATE- Instanzerzeugung bei Instanzverwaltung In vielen Fällen kann dies einfach die Methode FIND_BY_LPOR sein. So wird zunächst sichergestellt, dass es zu einer Datenbankinstanz maximal eine Objektinstanz gibt. Die im Kapitel 11 vorgestellte Methode GENERICINSTANTIATE für Klassenreferenzen im Workflow ruft für die Instanziierung immer die Methode FIND_BY_LPOR auf, die die Instanzverwaltung berücksichtigt.

68 124 5 Die neue Welt: ABAP Objects im Workflow Nun muss sichergestellt werden, dass diese einzige Objektinstanz immer synchron mit dem Datenbankstand gehalten wird. Das ist dann relativ einfach möglich, wenn die Methoden der Klasse selbst die DB ändern. Dann können sie die Änderung nach COMMIT WORK 1:1 in die gepufferte Hauptspeicherinstanz übernehmen. Beim nächsten Aufruf von FIND_BY_LPOR wird dann der korrekte Datenstand gezogen. Bei komplexen Datenstrukturen kann es manchmal einfacher sein, statt eines Updates in Attributdaten der Instanz einfach die Objektinstanz via IF_WORKFOW~RELEASE( ) aus der Puffertabelle zu löschen. Dann wird sie beim nächsten FIND_BY_LPOR neu von der Datenbank gelesen. Schwieriger wird es, wenn externe Anwendungen von außerhalb des Workflows schreibend auf die Datenbank zugreifen. Dann kann die Klasse, die die Objektinstanzen verwaltet, davon ggf. gar nichts merken. Wenn dies erlaubt sein soll, dann muss man dem Workflow die Änderungen (z.b. via Eventsteuerung) mitteilen. Dieser kann dann die betreffende Instanz invalidieren und so ein Refresh erzwingen.