10.8 dynamische blöcke - bücher.de · 2017-12-15 · s block-workitem des umgebenden blockes bei...

10 Klassenbasierte Techniken im Workflow288

Workflows selbst weiterläuft sowie dass der lokale Workflow keineDaten an den auslösenden Workflow zurückgeben kann. N-fachesAuslösen eines Startereignisses für einen lokalen Subworkflow löst die-sen auch N mal aus! Im Workflow-Protokoll findet man in diesem FallN Instanzen zu diesem lokalen Workflow.

10.8 Dynamische Blöcke

Ein dynamischer Block bearbeitet eine Liste mit gleichartigen Elemen-ten (Objektreferenzen), deren Elementanzahl zur Definitionszeit nichtbekannt ist.

In früheren Releases gab es dafür die dynamische Parallelverarbei-tung. Dieses Verfahren ist in [2] ausführlich beschrieben. Wollte manmehrere Schritte dynamisch parallel verarbeiten, so musste man eineigenes Workflow-Muster anlegen, das dann dynamisch parallel auf-gerufen wurde.

Die dynamischen Blöcke lösen das Problem viel eleganter. Zwi-schen den Blockbegrenzern (Pfeil nach oben, Pfeil nach unten) könnenbeliebig viele Workflow-Schritte eingefügt werden. Diese bilden dannquasi einen eigenen, eingebetteten Workflow mit eigenem Containerund Datenfluss zum umgebenden Workflow.

Es sind zwei Arten von Blöcken möglich:

■ Dynamisch sequenzieller BlockDas ist letztlich ein Iterator auf Workflow-Ebene.

■ Dynamisch paralleler BlockDas ist eine dynamische Parallelverarbeitung.

Blöcke werden durch X-Workitems repräsentiert. Bei sequenziellenBlöcken existiert genau ein Block-Workitem mit genau einem Block-container. Dieser Container wird nacheinander von den Workitemsdes Blockes benutzt.

Bei dynamisch-parallelen Blöcken existieren so viele Block-Work-items mit je einem Blockcontainer wie es Einträge in der Objektlistegibt. Die Workitem-Hierarchie in der Kopftabelle SWWWIHEADwird ergänzt:

■ SWWWIHEAD-WI_CHCKWIWorkitem des umgebenden Flows

■ SWWWIHEAD-PARENT_WIBlock-Workitem des umgebenden Blockes

Bei Block-Workitems sind PARENT_WI und WI_CHCKWI gleich.


10.8.1 Dynamisch sequenzieller Block = Workflow-Iterator

Der sequenzielle dynamische Block entspricht genau einem Iterator imWorkflow-Kontext.

10.8.2 Dynamisch paralleler Block

Der dynamisch parallele Block bearbeitet die N Objekte in einem par-allelen Abschnitt, dessen Zweiganzahl erst zur Laufzeit bekannt ist.

Blockcontainer <Liste>_LINE

Blockschritte

Dynamische Liste mit N Objekten

Dynamisch sequenzieller Block

Subworkflow- Container

<Liste>_LINE

Subworkflow-Schritte

n > N?

Block-Subworkflow

n := n + 1


n := 1

<Liste>_LINE = Liste[n]

Abb. 10–26Dynamisch sequenzieller

Block als eingebetteter

Subworkflow

Blockcontainer <Liste>_LINE

Blockschritte


Dynamisch paralleler Block

Subworkflowflow- Container

<Liste>_LINE


Block-Subworkflow


<Liste>_LINE = Liste[1]

Subworkflow- Container

<Liste>_LINE


Block-Subworkflow

Subflow- Container

<Liste>_LINE


Block-Subworkflow

<Liste>_LINE = Liste[2] <Liste>_LINE = Liste[N]

Parallel N / N (dynamisch)

Parallel N / N (dynamisch)

Abb. 10–27Dynamisch paralleler

Block als eingebetteter

Subworkflow


10.8.3 Beispiel: Bewertungs-Workflow für Vertrag

Im folgenden Beispiel wird ein Vertrag dynamisch parallel durch NMitarbeiter bewertet. Jeder Mitarbeiter kann über eine Sachbearbei-terentscheidung (SBE) von minimal 0 bis maximal 3 Punkte vergeben.Die Parallelverarbeitung soll abgebrochen werden, wenn insgesamtbereits N*2 Punkte erreicht wurden.

Variablen im Workflow-Container:Vertrag Ref To ZCL_VERTRAGUserListe Ref To ZCL_USER, mehrzeiligUserCount 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 Verarbei-tung. Als Blockschritt wurde irgendein Schritt gewählt.

Der Datenfluss Workflow Blockcontainer sieht folgendermaßenaus: In &_WF_PARFOREACH_INDEX& steht der aktuelle Index derUserListe. Das Element mit diesem Index wird übergeben und könntebearbeitet werden. Hier wird als Rückgabewert einfach eine 1 auf denUserCount im Workflow-Container addiert. Zum Schluss hat manalso die Anzahl der Einträge in der dynamischen Liste ermittelt.

(Natürlich würde man dazu nicht extra einen Block anlegen, son-dern eher eine Utility-Methode; hier geht es nur um die Demonstration

Abb. 10–28Dynamisch-sequenzielle

Bearbeitung der UserListe


einer speziellen Variante des Datenflusses). Das PunkteLimit wird mitPunkteLimit = 2 * UserCount festgelegt.

Der dynamisch-parallele Block erzeugt je User in der UserListe eineSBE mit den vier Bewertungsergebnissen. Als Bearbeiter wird ein Aus-druck der Form &_USERLISTE_LINE.GET_PDUSER()& benutzt. DieReturningmethode setzt einfach ein »US« vor den Usernamen der Instanz.

© SAP AG

Abb. 10–29Datenfluss zum

dynamisch-sequenziellen

Block

Vertragsbewertungparallel

Vertragsbewertungparallel

Bewerten Sie Vertragmit 0 – 3 Punkten

Punkte: = 2 Punkte: = 0 Punkte: = 1 Punkte: = 3

ok ok okok

Abb. 10–30Dynamisch-paralleler

Block zur

Vertragsbewertung


Dem Blockcontainer wird wieder das n-te Element der UserListe über-geben, zusätzlich der zu bewertende Vertrag. Das Ergebnis einerBewertung ist die vom jeweiligen User vergebene Punkteanzzahl, siewird im Datenfluss vom Blockcontainer zum Workflow auf die Punk-teGesamt aufaddiert.

Die dynamische Parallelverarbeitung wird abgebrochen, wenn dasPunkteLimit erreicht wurde, bevor alle Bewertungen vorliegen.

Das Workflow-Protokoll zeigt den Stand nach Abarbeitung dessequenziellen Blocks (ohne Dialogschritte) und nach Erzeugung allerdrei Dialogschritte im parallelen Block. Es ist zu sehen, dass dersequenzielle 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).

© SAP AG

Abb. 10–31Datenfluss zwischen

Workflow-Container und

Blockcontainer

© SAP AG

Abb. 10–32Abbruchbedingung für

dynamisch-parallelen

Block


In der SBE werden von jedem User die Punkte vergeben. In einem Linksoll das zu bewertende Objekt, hier also der Vertrag, anzeigbar sein.

Leider funktionieren die im Container vordefinierten _ADHOCOB-JECTS nicht für Referenzen von Klassen. Man muss also für jeden Klas-senlink eine eigene Variable im Container anlegen. Aber das ist keingroßer Aufwand, zumal man den Datenfluss ohnehin angeben muss.

© SAP AG

Abb. 10–33SBE zur Vertrags-

bewertung mit Link

zum Vertrag

Abb. 10–34Protokoll eines Workflows

mit Blöcken

© SAP AG

1

Einleitung

Wer hat das Buch geschrieben?

Autor des Buches ist Dr. Ulrich Mende, der auch bereits das Vorgänger-buch »Workflow und ArchiveLink mit SAP« [2] beim dpunkt.verlaggeschrieben hat. Er arbeitet seit 13 Jahren selbstständig als Entwicklerfür SAP Business Workflow, in den letzten Jahren hauptsächlich imIS-U-(Industry Solution Utilities) Umfeld für große Energieversorger.Parallel dazu führt er Workshops für Workflow-Entwickler durch.

[email protected]

Dank

Der ganz besondere Dank des Autors gilt der Fa. affinis consultingGmbH in Hamburg. Ohne deren großzügige Unterstützung durch dieBereitstellung eines SAP-Entwicklungssystems wäre dieses Buch nichtzustande gekommen.

Insbesondere hat Herr Marc Trümer (affinis intelligent solutionsGmbH & 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 Fachkollegin-nen und Kollegen, Frau Eva Schleißheimer, Herrn Stefan Porges, HerrnAyhan Toraman, Herrn Hüdayi Mengus und Herrn Mario Gratz, fürthematische Diskussionen, Hinweise und Korrekturen zum Buch.

Dem dpunkt.verlag sei vielmals gedankt für die jederzeit konstruk-tive und vertrauensvolle Zusammenarbeit, insbesondere dem LektorHerrn Dr. Barabas sowie der Korrektorin Frau Ursula Zimpfer.

Einleitung2

Worum geht es in diesem Buch?

Längst hat sich SAP Business Workflow als modulübergreifende Quer-schnittstechnologie zur Abbildung und automatisierten Bearbeitungkomplexer, arbeitsteiliger Prozesse im SAP-Umfeld etabliert. VieleUnternehmen haben erkannt, welches enorme Rationalisierungspoten-zial diese Technologie für die Prozessbearbeitung in ihrem Unterneh-men enthält.

Stellvertretend seien hier die Workflow-Prozesse im IS-U (IndustrySolution Utilities) genannt, die vermutlich die komplexesten Prozesseim SAP-Umfeld überhaupt darstellen. So hat ein Netzbetreiber-Work-flow im Lieferantenwechsel ca. 100 Schritte und kommuniziert viaMarktkommunikation (IDOCs, B2B) mit Workflows, die parallel aufden SAP-Systemen fremder Unternehmen (Lieferanten und Messstel-lenbetreiber) laufen.

Entsprechend hoch ist der Aufwand, den die Unternehmen inzwi-schen für die Entwicklung und Administration von Workflows betrei-ben. Viele Entwickler, die sich früher ausschließlich mit ABAP (Advan-ced Business Application Programming) befasst haben, müssen sichnun in der einen oder anderen Form mit der Workflow-Entwicklungvertraut machen.

Inzwischen gibt es zum Thema Workflow-Entwicklung mehrereBücher, in denen die Technologie aus Entwicklersicht von Anfang andetailliert besprochen wird [1], [2], [3]. Die Grundlagen der Work-flow-Entwicklung sind daher relativ gut beschrieben und deshalb nichtHauptgegenstand dieses Buches.

Dieses Buch konzentriert sich dagegen auf die erheblichen Verän-derungen in der Workflow-Entwicklung, die durch ABAP Objectsmöglich bzw. nötig werden.

Mit dem Entstehen der Workflow-Technologie wurden die soge-nannten BOR-Objekttypen (BOR = Business Object Repository) alsquasi objektorientierte Verschalung aller ABAP-Anwendungen einge-führt. BOR-Objekttypen (BOR-OT) waren von Anfang an die Work-flow-Objekttypen. Für ABAP-Entwickler war die stark makroorien-tierte Programmierung von und mit BOR-Objekttypen oft sehr gewöh-nungsbedürftig, was vermutlich auch ein Grund dafür ist, dass esimmer noch wenig Workflow-Entwickler gibt.

Um das Jahr 2000 erschien ABAP Objects als echter objektorien-tierter Sprachbestandteil von ABAP. Viele Anwendungen nutztensofort die stark verbesserten Möglichkeiten der Programmierung, diesich damit boten. Workflow-Entwickler mussten allerdings bis zumBasisrelease 6.20 warten, bis sie neben BOR-OT auch ABAP-Klassenin Workflows benutzen konnten. (Dabei muss man den Zeitverzug von

3An wen richtet sich das Buch?

einigen Jahren beachten, der zwischen der Freigabe eines Release beiSAP und dessen flächendeckender Einführung beim Anwenderbesteht.) Dies führte in vielen Fällen dazu, dass die BOR-OT nur dieWorkflow-Verschalung waren, in deren Inneren sofort Klassenmetho-den aufgerufen wurden.

Inzwischen kann ein Releasestand von SAP Basis von 6.20 undhöher durchaus vorausgesetzt werden. Der Nutzung von ABAPObjects anstelle von BOR-OT steht also nichts mehr im Wege. Dasssich viele Entwickler dennoch vor diesem Schritt scheuen, mag an derjahrelangen 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 »Entweder-oder« notwendig ist. BOR-OT und ABAP Objects können in fried-licher Koexistenz in ein und demselben Workflow leben. Die alten,bewährten, aber unverzichtbaren Dinge erledigen BOR-Objekte; neueFunktionalitäten werden über ABAP Objects realisiert.

Oft hört man von Entwicklern folgende Meinung: Wozu eigentlichObjektorientierung? Das verkompliziert alles nur; ein einfacher Re-port tut es auch.

In diesem Sinne stellt SAP Business Workflow eine echte »Daseins-berechtigung« für ABAP Objects dar. Letztlich ist der Workflow näm-lich ein komplexes Framework, das mit beliebigen, unbekanntenObjekten gleichartig hantieren soll. In diesem Umfeld kommen alleKonzepte der Objektorientierung wie Kapselung, Vererbung, Inter-faces, Polymorphie, Events und Ausnahmeklassen auf völlig natürlicheArt zum Tragen.

Dies zu vermitteln ist das hauptsächliche Ziel des Buches. Für die»Praktiker« unter den Entwicklern kann es den Zugang zur Objektori-entierung erleichtern.

An wen richtet sich das Buch?

Das Buch richtet sich an EDV-Spezialisten, die auf die eine oder andereWeise 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 leidsind, immer wieder Container mit SWC_GET_ELEMENT auszupa-

Einleitung4

cken und am Ende der Methode mit SWC_SET_ELEMENT wiedereinzupacken.

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 benutzenmöchten.

Für diejenigen unter den Lesern, die mit der Objektorientierungnoch nicht vertraut sind, ist eine Einführung in ABAP Objects enthal-ten. Hier werden Begriffe wie Kapselung, Vererbung, Redefinition undPolymorphie praxis- und Workflow-bezogen dargestellt.

Und dann ist das Buch für solche Entwickler gedacht, die den Ein-stieg in die Workflow-Entwicklung wagen wollen bzw. sollen. Ihnen istzu raten, von Anfang an mit der neuen Technologie zu arbeiten.

Aber auch Entwickler, denen der übliche Zugang zu ABAP Objectszu theoretisch ist, können hier u.U. einen besseren, weil praktischenZugang zur Objektorientierung finden.

Workflow-Berater, die bereits über gute Kenntnisse in ABAPObjects und Workflow verfügen, können in diesem Buch viele kon-krete Hinweise für ihre Projekte bekommen.

Workflow-Administratoren sollten auf jeden Fall das einführendeKapitel sowie die Kapitel zum Laufzeitsystem und zur Administrationlesen.

Entscheider (Teamleiter), die sich einen Überblick über SAP Busi-ness Workflow verschaffen möchten, sollten das einführende Kapitellesen. 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 Workflowmit ihren wichtigsten Bestandteilen und Begriffen einführend darge-stellt.

■ Neue BegriffeLaufzeit, Definitionszeit, Bearbeiter, Workplace

Kapitel 2 – Workflow – Entwicklung Tools

Hier werden Hinweise zu den Entwicklungstools gegeben. Ausführlichwird das Workflow-Bereichsmenü SWLD vorgestellt. Empfohlen wirddie paketorientierte Arbeit im Object Navigator (SE80). Weiterhin

5Hinweise zu den einzelnen Kapiteln

werden zwei große Gruppen von Beispiel-Workflows von SAP be-schrieben. Hinweise zum Thema Workflow im SAP Service Market-place und in der SDN-Community (SDN = SAP Developer Network)runden dieses Kapitel ab.

■ Neue BegriffeSchichtenmodell der Workflow-Entwicklung, Bereichsmenü SWLD,WFUNIT, WF_Verify, Online Help, SDN

Kapitel 3 – ABAP Objects – Grundlagen

In diesem Kapitel werden überblicksartig die notwendigen Grundlagenvon ABAP Objects zusammengefasst. Es erspart dem Leser ohneKenntnisse von ABAP Objects (ABAP OO) das Nachschlagen derGrundbegriffe in anderen Büchern. Wo es möglich ist, wird bereitsBezug auf die spätere Verwendung im Workflow-Umfeld genommen.Der erfahrene ABAP-OO-Entwickler kann dieses Kapitel ohne Nach-teile überspringen.

■ Neue Begriffe:Klassen, Komponenten, Attribute, Methoden, Sichtbarkeit, Ereig-nisse, Vererbung, Redefinition, Instanzen, Referenzen, Interfaces,Polymorphie, Ausnahmeklassen

Kapitel 4 – Durchgängiges Beispiel des Buches: Kreditverträge

Im Buch wird ein durchgehendes Beispiel zur Vertragsbearbeitungbenutzt. In diesem Kapitel werden die Tabellen und Transaktionenkurz 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-Klassenverwendet. Ausführlich wird das Interface IF_WORKFLOW bespro-chen. Es wird gezeigt, wie die Ereignisse von ABAP Objects als Work-flow-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 Containernund Ereignissen im Workflow-Umfeld besprochen.

Einleitung6

Für Container werden Beispielprogramme zu Definition, Daten-flüssen, persistenter XML-Speicherung diskutiert.

Danach werden die Erzeugung und Verarbeitung von systemwei-ten Ereignissen detailliert besprochen. Neben den verschiedenen direk-ten und indirekten Methoden der Ereigniserzeugung liegt der Schwer-punkt auf der Ereignisverarbeitung. Letztere stellt die Reaktion aufStatusänderungen an Objektinstanzen dar. Es werden Beispiele für dieImplementierung eigener Koppelbausteine diskutiert.

■ Neue Begriffe:Containerklasse CL_SWF_CNT_CONTAINER, Strukturpersistenz,XML-Persistenz, Eventklasse CL_SWF_EVT_EVENT, Ereignis-kopplung, Ereignisverbraucher, Check-Funktionsbaustein, Typ-Funktionsbaustein, Eventqueue, Ereigniscontainer, Datenfluss

Kapitel 7 – Organisationsmanagement und Regeln

Dieses Kapitel erläutert die Möglichkeiten zur Abbildung des Organi-sationsmanagements. Hier wird auf die sogenannten Infotypen, insbe-sondere auf die Objekte des Organisationsmanagements sowie diezwischen ihnen möglichen Beziehungen, eingegangen. Ziel ist die Nut-zung der hinterlegten Informationen zur automatischen Bearbeiterfin-dung in Workflows.

■ Neue Begriffe:Organisationseinheit, Stelle, Planstelle, Person, User, Regel, Zustän-digkeit, Auswertungsweg, Bearbeiterfindung

Kapitel 8 – Standardaufgaben anlegen und verwenden

Es wird gezeigt, wie Einzelschrittaufgaben mit Bezug auf eine Klassen-methode angelegt werden.

■ Neue Begriffe:Einzelschrittaufgabe, Hintergrundaufgabe, Aufgabencontainer, füh-rendes 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, Eventsund Einzelschrittaufgaben und Regeln angelegt werden.

■ Neue Begriffe:Workflow, Workflow-Interface, führendes Objekt, Import-, Export-und lokale Containervariablen, startendes Ereignis, Workflow-


Definition, Aktivität, ausgewählte Bearbeiter, Alternative, Mehr-fachverzweigung, paralleler Abschnitt, Schleife, Containeropera-tion, 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, Work-item-Exit, dynamische Blöcke, Startbedingungen, Ad-hoc-Funktio-nen

Kapitel 11 – Klassenbasierte Eigenentwicklungen im Workflow

Hier werden einige in der Praxis der Workflow-Entwicklung entstan-dene, Workflow-taugliche Utility-Klassen besprochen. ZCL_DATEbietet Methoden zur kompakten Berechnung von Datums- und Zeit-werten auf Fabrikkalendern an.

Die Klasse ZCL_SYSTEM stellt Methoden zur generischen Erzeu-gung von Klassenreferenzen und zum Mailversand bereit.

Beide Klassen können im Downloadbereich zum Buch in XML-Form heruntergeladen und mit dem im Buch vorgestellten Reportdirekt ins System eingespielt werden.

■ Neue Begriffe/Stichwörter:GENERICINSTANTIATE, Datumsklasse, Konstantenklasse, Kom-munikation zwischen Subflows, generischer Mailversand

Kapitel 12 – Business Workplace als Userinterface

In diesem Kapitel wird der Business Workplace als Userinterface fürden Workflow-Benutzer besprochen. Es werden alle Funktionen aufWorkitems erläutert sowie Möglichkeiten zur persönlichen Konfigura-tion der Workflow-Inbox dargestellt.

■ Neue Begriffe:Worklist, Vorschau, Status, Statusdiagramm, Workitem anzeigen,~ ausführen, ~ annehmen, ~ zurücklegen, ~ wiedervorlegen, ~ wei-terleiten

Kapitel 13 – Webservices im Workflow

Es wird demonstriert, wie SOAP-Webservices angelegt und aus demWorkflow heraus aufgerufen werden können.

Einleitung8

■ Neue Begriffe:Webservice, SOAP-Protokoll, CL_PROXY_CLIENT, WSDL, logi-scher Port

Kapitel 14 – Das Workflow-Laufzeitsystem

In diesem Kapitel wird das Laufzeitsystem des SAP Business Workflowbesprochen. Die hier dargestellte technische Sicht (Tabellen und Funk-tionsbausteine) kann das Verständnis für den Workflow bei Informati-kern 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 vor-gestellt. Dazu gehören die unterschiedlichen Transaktionen zumSuchen nach Workflows bzw. Workitems sowie die Arbeit mit dendiversen Protokollen. Besonders interessant dürfte ein Report sein, deres ermöglicht, B-Workitems nachträglich im Dialog zu debuggen. Hin-weise zur Bearbeitung von Kurzdumps sowie diverse nützliche Hilfs-programme 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ätzein der Arbeit eines Workflow-Administrators. Zunächst werden Fra-gen des Customizings besprochen. Die für die Administration vonWorkflows wichtigen Werkzeuge (Analysetools, Diagnosetools) wer-den erläutert. Es werden Möglichkeiten zur Reorganisation der Lauf-zeitdaten dargestellt.

■ Neue Begriffe:Workflow-Customizing, E-Mail-Notification über neue Workitems,SAPconnect, Terminüberwachung, Fehlerüberwachung, Fehler-item, Diagnosereport, Workitem-Analyse, Workflow-Protokoll,Workload-Analyse, Archivierung von Workitems, SARA


Anhang – Die alte Welt: BOR-Objekte im Workflow

Die Objekttypen des Business Object Repository (BOR) werden als»alte« objektorientierte Verschalung der Anwendungssoftwareerklärt. Dieser Anhang trägt der Tatsache Rechnung, dass viele Millio-nen Zeilen ABAP-Code in den vorhandenen BOR-Objekttypen eingroßes Erfahrungspotenzial darstellen.

■ Neue Begriffe: Objekttyp, Schlüssel, Attribut, Methode, synchron/asynchron,Parameter, Container, Ereignisse, Delegation, Vererbung, Interface


Nach einer Fristüberschreitung setzt ein Steuerschritt das Warte-Work-item auf obsolet, wodurch dessen Obsoletzweig durchlaufen wird. Indiesem befindet sich eine Sachbearbeiterentscheidung (SBE), die dieAlternativen Vertrag stornieren und Vertrag aktivieren zulässt. In denentsprechenden Folgezweigen wird der Vertragsstatus dunkel (= ohneDialog) gesetzt.

10.11 Klassenverwendung im Workflow ohne Standardaufgaben

10.11.1 Konzept

Viele Entwickler scheuen den Aufwand, für jede Workflow-Klasseextra das Interface IF_WORKFLOW zu implementieren und für jede(ggf. statische) Methode unbedingt eine eigene Standardaufgabe anzu-legen. Es fragt sich daher, ob es nicht möglich ist, Klassen auch direktim Workflow zu verwenden. Das geht tatsächlich, wobei unterschied-liche Varianten möglich sind.

Die folgende Tabelle zeigt, wie auf welche Komponenten einerKlasse im Workflow ohne Standardaufgaben zugegriffen werdenkann. Wie sich zeigt, ist dabei nur teilweise eine Implementierung vonIF_WORKFLOW notwendig.

Warte aufAktivierung

Vertragabgelehnt

Status setzenACTIVATED

Verarbeitung obsolet

deaktivieren stornierenändern

StatussetzenCANCELED

beendet

Nach 10 AT:Warten beenden

eingetroffen

Frist für Aktivierungüberschritten

Abb. 10–48Ereignisempfänger mit

Fristüberwachung


Der statische Klassenzugriff, der einen Ausdruck über die %-Zei-chen klammert, ist nur für statische Klassenkomponenten (statischeAttribute und funktionale, statische Methoden) möglich.

Der Referenzzugriff, der einen Ausdruck über die &-Zeichen klam-mert, erfordert immer eine Referenz auf die Klasse im Workflow-Con-tainer. Dabei muss diese Referenz nicht einmal gebunden sein, um sta-tische Attribute anzusprechen.

Die im Folgenden vorgestellten Beispiele benutzen zunächst eineKlasse ZCL_CALC mit einer einfachen funktionalen, statischenMethode SUM (numerische Summenbildung). Zusätzlich greifen sieauf die im Abschnitt 11.1 vorgestellte Utility-Klasse ZCL_DATE zurDatumsberechnung auf Fabrikkalendern vor.

10.11.2 %-%-Zugriff ohne IF_WORKFLOW

Diese Zugriffsart ist nur für statische Konstanten und statische funkti-onale Methoden geeignet. (Im Abschnitt 10.11.6 wird gezeigt, wieauch nicht funktionale Methoden mit mehreren Exportparameternaufgerufen werden können.) Da es keine entsprechende Klassenrefe-renz im Workflow-Container gibt, kann man die Komponenten fürden Ausdruck auch nicht mittels F4 aus dem Container wählen. Manmuss also Namen und Signaturen der statischen Attribute und funkti-onalen Methoden genau kennen. Dafür kommt die Klasse vollständigohne das Interface IF_WORKFLOW aus.

Bei Fehlern in der Eingabe erhält man allerdings detaillierte undsehr hilfreiche Hinweise, was an dem Ausdruck nicht stimmt.

Komponente statisch

Instanz-komponente

Attr. Funkt.Meth. Attr. Funkt.

Meth.

%...%

■ Zugriff ohne Containerreferenz■ kein Interface IF_WORKFLOW

jakein F4

jakein F4

nein nein

&…&

■ Zugriff mitContainer-referenz

■ 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

Tab. 10–5Klassenaufrufe im

Workflow ohne

Standardaufgaben


Die Abbildung 10–49 zeigt, wie eine statische Methode SUM einerKlasse ZCL_CALC (ohne Workflow-Interface) mit zwei konstantenWerten für die beiden Summanden in einer Containeroperation ver-wendet wird.

In der folgenden Abbildung wird dieselbe Methode in einem Daten-fluss benutzt, ihr werden aber als Summanden die beiden Containerva-riablen S1 und S2 übergeben.

10.11.3 &-&-Zugriff über ungebundene Containerreferenzen

Es leuchtet ein, dass ungebundene Referenzen nur auf statische Kom-ponenten zugreifen können, da eben keine Instanz vorhanden ist. Lei-der können sie aber ausschließlich statische Attribute behandeln, mitstatischen, funktionalen Methoden kommen sie nicht zurecht. Diesewerden zwar per F4-Hilfe angeboten und können auch ausgewähltwerden, liefern aber keine Werte. Die statischen Attribute werden mitihren Werten bereits im Container angezeigt.

© SAP AG

Abb. 10–49Ausdruck mit funktionaler

Methode in

Containerzuweisung

© SAP AG

Abb. 10–50Funktionale Methode mit

Parametervariablen im

Datenfluss


10.11.4 &-&-Zugriff über gebundene Containerreferenzen

Mit echten, gebundenen Containerreferenzen kann man auf alle Kom-ponenten zugreifen, es besteht immer eine Eingabehilfe, sowohl fürAttribute als auch für funktionale Methoden. Natürlich muss dasInterface IF_WORKFLOW für entsprechende Instanziierung unter-stützt werden.

Ein Trick für Utility-Klassen, die ausschließlich statische, funktio-nale Methoden besitzen, besteht darin, eine Pseudoinstanziierung zunutzen. Dies wird am Beispiel der Utility-Klasse ZCL_DATE (sieheAbschnitt 11.1) dargestellt. Folgende Punkte sind zu erledigen, um dieKlasse und ihre statischen, funktionalen Methoden im Workflow ohneStandardaufgaben und mit komfortabler F4-Hilfe zu nutzen:

■ Klasse hat keinen CONSTRUCTOR, da nur Pseudoinstanziierungfü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 10–12 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.

© SAP AG

Abb. 10–51Ungebundene

Klassenreferenz im

Container

Listing 10–12Pseudoinstanziierung


Die LPOR-INSTID ist beliebig, sie wird gar nicht verwendet. Bei derInstanziierung (= Initialisierung) im Workflow kann man einfach 0eingeben. Danach erscheint die Referenz im Workflow-Container alsgebunden und man kann die statischen Methoden per F4-Hilfe an derReferenz auswählen und bekommt das vollständige Muster inklusiveSignatur zum Ausfüllen in den Ausdruck eingestellt.

Insbesondere, wenn man eine Utility-Klasse häufig verwendenmöchte, ist der geringe Mehraufwand durch die elegante F4-Hilfegerechtfertigt.

Abbildung 10–53 zeigt einen Referenzausdruck in einem Datenfluss.

METHOD BI_PERSISTENT~LPOR. result-catid = 'CL'. result-typeid = 'ZCL_DATE'. result-instid = '0'. " beliebigENDMETHOD.

© SAP AG

Abb. 10–52Instanziierung (= Initiali-

sierung) der Pseudo-

referenz der Utility-Klasse

© SAP AG

Abb. 10–53Kompletter

(ergänzter) Ausdruck


In der Abbildung 10–54 ist die aufgeklappte Referenz in einem Daten-fluss zu sehen. Man kann die Methode DATE auswählen und muss nurdie Dauer ergänzen.

10.11.5 Geschachtelter Zugriff mit %-% und &-&

Es ist verständlich, dass sich mehrere %-%-Paare oder mehrere &-&-Paare untereinander in einem Ausdruck nicht vertragen. Anders als beiKlammerpaaren 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 & dasschließende zum ersten ist oder ob ein neues Paar beginnt.

Möglich ist allerdings die mehrfache, alternierende Schachtelungvon %-%-Paaren mit &-&-Paaren, wie folgende Abbildung einerBedingung zeigt.

In Bedingungen können Klassenausdrücke nur über den einfachen Zeilen-editor eingegeben werden.

© SAP AG


Methode via Referenz im

Datenfluss

© SAP AG

Abb. 10–55Geschachtelter Ausdruck

in einer Bedingung


Es fragt sich natürlich, ob solche komplexen, geschachtelten Ausdrü-cke sinnvoll sind. In vielen Fällen scheint es besser, eine Zwischenvari-able mit Zwischenwerten zu füllen. Das erleichtert später auch dasLesen der Workflow-Protokolle. Wer könnte schon auf Anhieb sagen,ob das Datum im o.g. Ausdruck wirklich nach dem 13.05.2012 liegt.

10.11.6 Methoden mit mehreren Exportparametern

In den vorangegangenen Teilkapiteln wurde angenommen, dass dieaufgerufenen Methoden funktional waren, also genau einen RETURN-ING-Parameter und keine Exportparameter haben. Diese Annahmewird durch die Verwendung in Ausdrücken (Datenflüsse, Containerzu-weisungen) auch nahegelegt.

SAP bietet aber eine Möglichkeit an, auch nicht funktionaleMethoden, die ggf. auch mehrere Exportparameter besitzen, aufzuru-fen. Dies wird für die folgende Methode ZCL_CALC.POWERdemonstriert, die einen Import- und zwei Exportparameter hat.

Der nachfolgende Datenfluss »ernennt« über die Zuweisung

_RESULT = CUBIC

den Exportparameter CUBIC zum RETURNING-Parameter. DessenWert wird dann in der Zuweisung verwendet (s. Abb. 10–56). DiesesVerfahren funktioniert sinngemäß auch für den anderen ParameterSQUARE.

Gleichzeitig lassen sich die beiden Exportparameter leider nichtverwenden, folgende Anweisung wird abgewiesen:

****************************************************** 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.

ZCL_CALC.POWER(I=&S1&;_RESULT=CUBIC;SQUARE=&QUADRAT&)

Listing 10–13Nicht funktionale

Methode mit zwei

alternativen

Exportparametern

Leider nicht möglich!


Das ist nicht ganz verständlich, denn wenn man via I=&S1& Import-parameter mit Werten aus dem Container versorgen kann, dannkönnte man ja sicher auch mit SQUARE=&QUADRAT& die Werteder Exportparameter in den Container zurückschreiben. Vielleichtbefürchtet man dadurch unkontrollierbare Seiteneffekte im Container.

10.11.7 Objektreferenzen on-the-Flight

Wenn eine Aufgabe als Importparameter Objektreferenzen verlangtund man schon zur Definitionszeit weiß, welche Objektinstanz zuübergeben ist, so kann man Ausdrücke der folgenden Form in Daten-flüssen benutzen:

[BO.ZVERTRAG.00000008] für BOR-Objekte[CL.ZCL_VERTRAG.00000008] für Klasseninstanzen

Das hat den Vorteil, dass man keine Objektreferenz im Quellcontainerhaben muss.

Containervariablen kann man in diese Ausdrücke aber nicht einbin-den, 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.

© SAP AG

Abb. 10–56Aufruf der Methode

ZCL_CALC.POWER in

einem Datenfluss

© SAP AG

Abb. 10–57Objekt on-the-Flight

im Datenfluss




10.11.1 Konzept




Vertragabgelehnt





beendet


eingetroffen



Fristüberwachung








Komponente statisch

Instanz-komponente


Meth.

%...%


jakein F4

jakein F4

nein nein

&…&



Implementierung

ja

F4

nein ! nein nein



Implementierung

ja

F4

ja

F4

ja

F4

ja

F4


Workflow ohne

Standardaufgaben






© SAP AG


Methode in

Containerzuweisung

© SAP AG



Datenfluss










© SAP AG


Klassenreferenz im

Container









© SAP AG



Datenfluss

© SAP AG


in einer Bedingung







_RESULT = CUBIC






Methode mit zwei

alternativen

Exportparametern











© SAP AG


ZCL_CALC.POWER in

einem Datenfluss

© SAP AG


im Datenfluss




10.11.1 Konzept




Vertragabgelehnt





beendet


eingetroffen



Fristüberwachung








Komponente statisch

Instanz-komponente


Meth.

%...%


jakein F4

jakein F4

nein nein

&…&



Implementierung

ja

F4

nein ! nein nein



Implementierung

ja

F4

ja

F4

ja

F4

ja

F4


Workflow ohne

Standardaufgaben






© SAP AG


Methode in

Containerzuweisung

© SAP AG



Datenfluss










© SAP AG


Klassenreferenz im

Container









© SAP AG



Datenfluss

© SAP AG


in einer Bedingung







_RESULT = CUBIC






Methode mit zwei

alternativen

Exportparametern











© SAP AG


ZCL_CALC.POWER in

einem Datenfluss

© SAP AG


im Datenfluss

27910.6 Programmier-Exits für Workitems


10.6.1 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 Inter-face IF_SWF_IFS_WORKITEM_EXIT unterstützen müssen.

Typische Aufgaben, die in Userexits ausgeführt werden, sind:

■ anwendungsspezifisches Logging■ Mailversand■ Manipulieren von Workitems

10.6.2 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. 10–18).

Als Beispiel wird die Klasse ZCL_WI_USEREXIT_LOGGINGbetrachtet, die verschiedene Statusübergänge an Workitems protokol-liert.

Durch Verwendung des Interface erbt die Klasse die MethodeEVENT_RAISED mit folgenden Importparametern (s. Abb. 10–19).

© SAP AG

Abb. 10–17Workitem-Exit


Die möglichen Events sind:

© SAP AG

© SAP AG

Abb. 10–18CHECK-POINT-Gruppe

ZVERTRAG mit

Aktivierungen

Abb. 10–19Parameter

im Workitem-Exit

© SAP AG

Abb. 10–20Mögliche Events für den

Aufruf des Workitem-Exits


Alle notwendigen Angaben über das Workitem, den zugehörigen Work-flow, die Containerelemente und -objekte usw. bekommt man bei Be-darf aus der Referenz auf den Workitem-Kontext:

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.

© SAP AG

Abb. 10–21Interface

IF_WAPI_WORKITEM_

CONTEXT

Listing 10–8Workitem-Exit mit

Logging


Das folgende Protokoll zeigt, welche Ereignisse für ein Workitemdurchlaufen wurden, wobei bei Statusübergängen der neue Statusangezeigt wird.

Mit dieser Übersicht ist es einfach, weitere Dinge wie Mailversand zuprogrammieren.

10.6.3 Automatisches Zurücklegen eines Workitems

Wenn Workitems begonnen und abgebrochen werden, dann sind sie imStatus STARTED und damit nicht mehr für alle ursprünglichen Em-pfänger sichtbar. Dies kann zu Arbeitsverzögerungen führen, wennMitarbeiter vergessen, begonnene (angenommene), aber nicht abschlie-ßend bearbeitete Workitems in den Bearbeiterpool zurückzulegen. Derhier vorgestellte Userexit erledigt das automatisch.

Leider ist das nicht ganz so einfach, wie man vermuten könnte. Eindirekter Aufruf eines FBS zum Zurücklegen eines Workitems (z.B.SWL_ADM_BACK) schlägt fehl, da das während eines Statusübergan-ges nicht erlaubt ist. Es wird daher ein asynchrones Verfahren einge-setzt, wozu die Klasse ZCL_WI_USEREXIT_PUTBACK benutzt wird.Das Verfahren funktioniert für beliebige Dialog-Workitems, da es kei-nerlei Anwenderdaten liest. Das zurückzulegende Workitem wird in

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.

© SAP AG

Abb. 10–22Anzeige der Log-Einträge

zum Userexit


eine Tabelle ZPUTBACKWI geschrieben, danach wird im Hintergrundder Report ZAO_PUTBACK_WI via SIMPLE_BATCH_JOB_-SUBMIT gestartet, der alle Einträge dieser Tabelle liest und die Work-items 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.

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 10–9Workitem-Exit für das

Zurücklegen eines

Workitems

Listing 10–10Bacht-Report zum

Zurücklegen eines

Workitems


Nach dem Zurücklegen des Workitems, an dessen Schritt die KlasseZCL_WI_USEREXIT_PUTBACK eingetragen ist, dauert es ein biszwei Sekunden, dann steht das Workitem wieder auf READY.

Mit diesem Userexit kann man jeden beliebigen Dialogschritt injedem beliebigen Workflow mit der Funktion des automatischenZurücklegens versehen.

10.7 Fortgeschrittene Workflow-Definition

10.7.1 Lokale Ereignisse und Ausnahmen

Unter den versionsabhängigen Grunddaten eines Workflow-Musterslassen sich auf dem Reiter Lokale Ereignisse sogenannten lokale Ereig-nisse und lokale Ausnahmen definieren. Diese sind ausschließlich demjeweiligen Workflow-Muster ab der Version bekannt, in der sie defi-niert wurden.

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.

313

11 Klassenbasierte Eigenentwicklungen im Workflow

11.1 Utility-Klasse ZCL_DATE: Datumsberechnung auf Kalendern

11.1.1 Verwendung von Datumsberechnungen

Datums- und Zeitberechnung tritt an vielen Stellen im Workflow auf.Typischerweise wird sie bei der Ermittlung von Vorlage und Erledi-gungsfristen verwendet. Kompliziert wird es erst, wenn die Datumsbe-rechnung auf einem Fabrikkalender ausgeführt werden soll, wenn alsoWochenenden und Feiertage ausgeblendet werden sollen. Das ist häu-fig bei der Angabe von Fristen oder Deadlines der Fall.

11.1.2 Implementierung von ZCL_DATE

Die folgende Utility-Klasse ZCL_DATE besitzt die beiden Returning-methoden DATE() und TIME(). DATE() ermittelt ausgehend voneinem Startdatum und einer Startzeit ein Ergebnisdatum durch Addi-tion von DUR Zeiteinheiten (UNIT). Dabei kann ein Fabrikkalenderangegeben werden. Außer der Dauer sind alle Parameter optional undmit Defaultwerten versehen. Gibt man nur DUR=3 an, so wird z.B. einDatum ermittelt, das bezogen auf heute 3 Werktage auf dem Default-fabrikkalender »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–1Klasse ZCL_DATE,

Methode DATE

11 Klassenbasierte Eigenentwicklungen im Workflow314

Die Methode TIME() funktioniert ganz ähnlich, liefert nur die Zeitzurück. Man beachte allerdings, dass die Zeitberechnung ebenfalls einStartdatum und nicht nur eine Startzeit benötigt!

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.

31511.1 Utility-Klasse ZCL_DATE: Datumsberechnung auf Kalendern

************************************************************** 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.

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.

Listing 11–2Klasse ZCL_DATE,

Methode TIME

11 Klassenbasierte Eigenentwicklungen im Workflow316

Um in den Fristen die Zeiten auf feste Werte eines berechneten Tageszu setzen (z.B. auf morgens 09:00), wurden entsprechende Read-only-Attribute in der Klasse angelegt.

11.1.3 Verwendung von ZCL_DATE in Ausdrücken

Die Methoden DATE und TIME können, wie im vorhergehendenKapitel bereits dargestellt, direkt in Zuweisungsausdrücken oder inAusdrücken bei der Berechnung von Terminen (Vorlage, Frist) benutztwerden. Die optionalen Parameter können dabei weggelassen werden.Die Zeit bezieht sich immer auf den Tag, der mit DATE ermitteltwurde. Das folgende Beispiel zeigt einen Vorlagetermin mit folgendenEigenschaften:

■ Datum = SY-DATUM (Default) + 3 TAG(Default) auf Fabrikkalender »01« (Default)

■ Zeit = Morgens 09:00 am berechneten Tag

In der Abbildung 11–3 ermittelt ein Datenfluss das Containerelement&KeyDate& durch Rückrechnung von einem anderen Containerele-ment &EndDate&. Dieses wird als Parameter mitgegeben (STARTD =&EndDate&). Die Dauer ist negativ (DUR = -3), es wird ein von derDefaulteinstellung abweichender Fabrikkalender (CAL = »ZU«)benutzt.

© SAP AG

Abb. 11–1Zeitkonstanten der

Klasse ZCL_DATE

© SAP AG

Abb. 11–2Verwendung von

ZCL_DATE im

Vorlagetermin

31711.2 Utility-Klasse ZCL_COND: komplexe Bedingungen

Es ist erstaunlich, wie leistungsfähig diese Verwendung von statischenReturningmethoden ist. Beim Einsatz von BOR-Methoden hätte manhier extra einen Schritt einfügen müssen.

Klassenausdrücke mit %

ohne IF_WORKFLOW

Verwendet man ZCL_DATE wie oben dargestellt nur in %-Aus-drücken, so ist das Interface IF_WORKFLOW nicht notwendig. Wennman es doch implementiert, ggf. mit der im letzten Kapitel erwähntenPseudoinstanziierung, dann kann man die Ausdrücke bequem über dieF4-Hilfe vorschlagen lassen.

11.2 Utility-Klasse ZCL_COND: komplexe Bedingungen

11.2.1 Konzept komplexer Bedingungen im Workflow

Bereits die Modellierung einer einfachen Überkreuzbedingung zwischenParallelzweigen (Abschnitt 10.7.2) mithilfe von lokalem Ereignis undEreignisempfänger war sehr unhandlich. Noch komplexere Bedingun-gen würden entsprechend zu noch aufwendigerer Modellierung führen.

Abbildung beliebiger

Bedingungen

Es fragt sich daher, ob man nicht eine allgemeine Methode zurAbbildung 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 eineArt Meilensteinmethode verstehen, mit deren Hilfe wichtige Zuständein der Objektbearbeitung erfasst und in Workitem-Startbedingungengeprüft werden können. Folgende Bestandteile werden vorgestellt:

■ Tabelle ZCONDITION, in der die für eine Objektinstanz erfülltenBedingungen stehen.

■ Eine Utility-Klasse ZCL_COND (ohne IF_WORKFLOW), die diestatischen Methoden SET und CHECK für den Tabellenzugriff im-plementiert.

© SAP AG

Abb. 11–3Datumsberechnung in die

Vergangenheit

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 Release-wechsel. Und nur Bruchteile dieser Zeit werden zur eigentlichen Code-bearbeitung in den Methoden der Einzelschrittaufgaben benutzt. Dieübrige Zeit warten die Daten von Workitems (von Workflow-Musternund von Einzelschrittaufgaben) daher in persistenter Form in soge-nannten Containern. Ursprünglich waren Container einfach transpa-rente Tabellen (SWWCONT, SWW_CONTOB), heute wird als Persis-tenzform die sogenannte XML-Persistenz (Tabelle SWWCNTP0)bevorzugt. Dabei ist es wichtig, dass in diesen Containern nie dieAnwendungsdaten selbst, sondern immer nur Referenzen auf dieeigentlichen Anwendungsdaten in den Anwendungstabellen gehaltenwerden. Erst unmittelbar vor der Ausführung eines Workitems wirdaus solch einer persistenten Referenz ein Objekt im Hauptspeicher,dessen zugehörigen Instanzmethoden aufgerufen werden können.

Nun ist SAP Business Workflow eine modulübergreifende Quer-schnittstechnologie. Das Workflow-System muss daher mit den unter-schiedlichsten Arten von Business-Objekten umgehen können. Dazugeht es generisch vor. Es verlangt von allen Objekten, die im Workflowbearbeitet werden sollen, dass sie sich an gewisse Konventionen hal-ten. Technisch bedeutet das, dass die Klassen von Workflow-Objektenalle das Interface IF_WORKFLOW implementieren müssen. Nach die-sen Ausführungen wird deutlich, dass der Gegenstand dieses Interfacenur die Konvertierung von Objektreferenzen von der persistenten indie transiente Form und umgekehrt sein kann.

5 Die neue Welt: ABAP Objects im Workflow108

5.2 IF_WORKFLOW

Dieses Interface macht eine beliebige Klasse »Workflow-tauglich«.Dadurch wird die in den BOR-Objekttypen bereits fest eingebauteKonvertierung zwischen flüchtigen Klassenreferenzen (Hauptspeicher,Aufruf von Methoden) und persistenten Referenzen (Container vonWorkflows und Schritten) im Kontext von ABAP Objects erreicht.

Erst die Verwendung dieses Interface ermöglicht die Kennzeich-nung eines oder mehrerer Instanzattribute als »Key-Attribut«.

Die angesprochene Konvertierung wird ausschließlich dann benö-tigt, wenn auch Instanzen von Workflow-Klassen verwendet werdensollen, d.h., wenn Instanzmethoden aufgerufen werden sollen. Wennman also eine Klasse im Workflow benutzen will, die ausschließlichstatische Attribute und Methoden verwendet, so braucht man diesesInterface gar nicht auszuprägen (muss es aber aus formellen Gründendoch in die Klasse aufnehmen).

Das Erzeugen bzw. Löschen von Klasseninstanzen hat keinerlei Ein-fluss auf die DB-Daten der Objektinstanz in den Anwendungstabellen.Zu einem Eintrag in der Kopftabelle eines Business-Objektes (Rech-nung, 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 generischeWeise. Bei der schrittweisen, interpretativen Abarbeitung eines Work-flow-Musters entstehen ständige Kontextwechsel, zu denen die Refe-renzen auf die zu bearbeitenden Objekte persistent gespeichert bzw.wieder in den Hauptspeicher geladen werden müssen, um die entspre-chende Instanz einer ABAP-Klasse zu erzeugen.

Beispiel einer Vertragsbearbeitung im Workflow

Der Workflow gelangt an einen Dialogschritt zu einer Vertragsgeneh-migung, der zunächst für einige Stunden oder auch Tage im Eingangs-korb des überlasteten Empfängers liegen bleibt. Während dieser Zeitexistiert die Vertragsreferenz ausschließlich persistent auf der Daten-bank.

Der Bearbeiter markiert das Workitem (WI) und klickt auf den inder WI-Vorschau angegebenen Link zum Vertrag, um ihn anzuzeigen.In diesem Moment wird automatisch eine Konvertierung der persisten-ten in die transiente Vertragsreferenz durchgeführt. An der transientenReferenz wird vom Workflow-Laufzeitsystem dynamisch die Display-methode aufgerufen.

Der Bearbeiter legt das WI zurück, um essen zu gehen persis-tente Vertragsreferenz.

1095.2 IF_WORKFLOW

Der Bearbeiter führt das Workitem aus, was wieder zu einer Kon-vertierung persistent transient führt. Die Methode GENEHMIGENwird an der so im Hauptspeicher erzeugten Objektreferenz ausgeführt.

Der Schritt ist beendet und die Vertragsreferenz existiert wiedernur auf der DB.

Die transienten Objektreferenzen im Hauptspeicher sind einfachObjektreferenzen nach ABAP Objects, die aus der Klasse und demSchlüssen in der persistenten Darstellung erzeugt werden. Die persis-tente Darstellung SIBFLPOR ist eine Struktur aus 3 CHAR-Feldern:

Während die eingebettete SIBFOTYPE auch für die Typisierung vonBOR-Objekten gilt, besitzen diese einen längeren Schlüssel. Deshalbgibt es für BOR-Objekte auch eine andere Persistenzstruktur: SIBFL-PORB:

Da das generische Laufzeitsystem die einzelnen Workflow-Klassen,mit denen es später arbeiten soll, gar nicht kennen kann, überträgt esdie Aufgabe der wechselseitigen Konvertierung an die Klassen selbst.Genau das ist der Gegenstand des Interface BI_PERSISTENT, das daserste eingebettete Teilinterface von IF_WORKFLOW ist.

Außerdem gibt es eine Reihe von Komponenten der SAP Work-flow Engine, z.B. das Workflow-Protokoll, die Objekte anzeigen kön-nen. Hierfür müssen entsprechende Funktionen durch das Objektbereitgestellt werden.

© SAP AG

Abb. 5–1Struktur SIBFLPOR

für persistente

Klassenreferenzen

© SAP AG

Abb. 5–2Struktur SIBFLPORB

für persistente

BOR-Referenzen


Das Interface IF_WORKFLOW legt eine logische Klammer um die InterfaceBI_PERSISTENT (Instanzverwaltung) und BI_OBJECT (Objektverhalten).Das Interface IF_WORKFLOW enthält folgende Methoden:

*"* components of interface BI_OBJECT interface BI_OBJECT

public .

methods DEFAULT_ATTRIBUTE_VALUEreturning

value(RESULT) type ref to DATA .methods EXECUTE_DEFAULT_METHOD .methods RELEASE .

endinterface.

*"* components of interface BI_PERSISTENTinterface BI_PERSISTENT

public .

Interface BI_OBJECT .

class-methods FIND_BY_LPORimporting

LPOR type SIBFLPORReturning

value(RESULT) type ref to BI_PERSISTENT .methods LPOR

returningvalue(RESULT) type SIBFLPOR .

methods REFRESH .endinterface.

Abb. 5–3Interface IF_WORKFLOW

im Class Builder (SE24)

© SAP AG

Listing 5–1Komponenten von

BI_OBJECT


BI_PERSISTENT

1115.2 IF_WORKFLOW

BI_PERSISTANT~FIND_BY_LPOR

Konvertierung Referenz

DB Hauptspeicher

Diese statische Methode wird immer dann gerufen, wenn eine transi-ente Hauptspeicherinstanz des Objektes benötigt wird, also unmittel-bar vor der Ausführung eines Workitems. Mit CREATE OBJECT wirdeinfach ein neues Objekt vom Typ der implementierenden Klasse ange-legt und als RETURNING-Parameter an das Laufzeitsystem zurückge-liefert.

Der RETURNING-Parameter RESULT ist eine Interfacevariablevom Typ Ref To BI_PERSISTENT, der jede Referenz auf eine Klassezugewiesen werden darf, die das Interface BI_PERSISTENT (oderauch IF_WORKFLOW) unterstützt. Das ist zwangsläufig bei jederimplementierenden Klasse der Fall. Das Workflow-Laufzeitsysteminteressiert sich in diesem Moment nicht für die anderen Klassenme-thoden der implementierenden Klasse, sondern behandelt alle Klassenbzw. ihre Objekte gleich. Das ist polymorphes Verhalten.

BI_PERSISTANT~LPOR

Konvertierung Referenz

Hauptspeicher DB

Diese Instanzmethode füllt einfach die benötigte persistente Strukturvom Typ SIBFLPOR aus den Instanzdaten und gibt sie zurück.

BI_PERSISTENT~REFRESH

Diese Instanzmethode füllt die Attribute der Instanz mit Werten. Dazugehören das Lesen von Daten aus den Anwendungstabellen und ggf.der Aufbau von Referenzen auf andere Objekte.

*"* components of interface IF_WORKFLOW interface IF_WORKFLOWpublic .

Interface BI_PERSISTENT .

aliases DEFAULT_ATTRIBUTE_VALUEfor BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE .

aliases EXECUTE_DEFAULT_METHODfor BI_OBJECT~EXECUTE_DEFAULT_METHOD .

aliases FIND_BY_LPORfor BI_PERSISTENT~FIND_BY_LPOR .

aliases LPORfor BI_PERSISTENT~LPOR .

endinterface.


IF_WORKFLOW


BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE

Diese funktionale Instanzmethode besitzt keine Importparameter, son-dern nur einen RETURNING-Parameter. Sie ist vergleichbar den vir-tuellen Attributen im BOR. Dieser Wert wird im Workflow überalldort 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 mehrbenö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üs-sels in einer Instanzvariablen MV_VERNR und liest den gesamtenSatz in die Struktur MS_VERTRAG ein.

5.3.1 Attribute MV_VERNR und MS_VERTRAG

Das Attribut MV_VERNR ist der Schlüssel in den Anwendungstabel-len und wird daher vorausschauend speziell behandelt.

************************************************************* * 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.

Listing 5–4CONSTRUCTOR der Klasse

ZCL_VERTRAG


5.3.2 Methoden ANZEIGEN, AENDERN, GENEHMIGEN

Diese Dialogmethoden (Instanz) rufen direkt den im Kapitel 4 be-sprochenen FBS Z_VERTRAG jeweils mit der betreffenden Aktionauf. Alle drei Instanzmethoden benutzen das Schlüsselattribut MV_VERNR zur Identifizierung des Vertragsobjektes. Die Methoden AN-ZEIGEN und AENDERN benötigen überhaupt keine Parameter.

Für die Attribute gibt es vor der Einbeziehung des Interface IF_ WORK-FLOW keine Kennzeichnung »Schlüsselattribut«. Dass das AttributMV_VERNR der Schlüssel der Vertrags-Kopftabelle ist, weiß bis hierhernur der Programmierer, die Klasse weiß es nicht.

************************************************************* * 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.

endmethod.

© SAP AG

Abb. 5–4Keine Schlüsselattribute

vor IF_WORKFLOW

Listing 5–5Instanzmethode

ZCL_VERTRAG.ANZEIGEN


Die Ausnahme CX_BO_ACTION_CANCELLED wird in derMethode AENDERN geworfen, wenn der User auf Abbrechengedrückt hat. (Das Workflow-System behandelt diese Ausnahme ganzspeziell: Es legt ein Workitem, das diese Aufgabe verwendet, zurück inden Eingangskorb.

Die Methode GENEHMIGEN hat einen RETURNING-Parameter,der den neuen Status zurückliefert. Im Workflow wird dieser Wert zurVerzweigung benutzt.

************************************************************* * 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.

************************************************************* * 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'


ZCL_VERTRAG.AENDERN


ZCL_VERTRAG.GENEHMIGEN


Die Methoden selbst prüfen nicht, ob auf der DB tatsächlich ein Ver-trag mit der Nummer MV_VERNR existiert. Man geht üblicherweisedavon aus, dass ein Vertrag, der auf der DB angelegt wurde und überÄnderungsbelege einen Workflow gestartet hat, nicht böswillig vonder DB gelöscht wird.

Möchte man allerdings ganz sicher gehen, so muss man in derMethode FIND_BY_LPOR (s. Abschnitt 5.4) stets auf Existenz prü-fen, und zwar nicht nur beim Neuanlegen, sondern auch beim Lesender Objekte aus der Puffertabelle.

5.3.3 Ereignisse CREATED, CHANGED und CANCELLED

Die Ereignisse werden als PUBLIC-Instanzereignisse angelegt. Es wer-den keine Eventhandlermethoden implementiert, da sich nur derWorkflow für das Ereignis interessiert. Das Laufzeitsystem stellt gene-rische Eventhandler für alle Workflow-Klassen bereit:

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.

© SAP AG

Abb. 5–5Ereignisse der Klasse

ZCL_VERTRAG


5.3.4 Erste Tests der Klasse ohne Interface IF_WORKFLOW

Bereits an dieser Stelle können und sollten alle Komponenten derneuen Klasse getestet werden. Dazu gehören auch die Fehlersituatio-nen wie Abbruch, falsche Vertragsnummer usw.

Je mehr Softwareschichten nämlich dazukommen, desto schwieri-ger gestalten sich die Tests.

5.4 Einfachste Ausprägung von IF_WORKFLOW

Die Einbindung des IF_WORKFLOW erweitert die Methoden vonZCL_VERTRAG. Die vom Interface »geerbten« und zu implementie-renden Methoden sind grau hinterlegt.

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.

Danach wird im CONSTRUCTOR der Aufruf auf BI_PERSISTENT~REFRESH( ) gemacht; so spart man Redundanz.

************************************************************ * 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.

© SAP AG

Abb. 5–6Methodenliste von

ZCL_VERTRAG nach

Einbindung von

IF_WORKFLOW

Listing 5–8Methode


1175.4 Einfachste Ausprägung von IF_WORKFLOW

Unter dem Attribute-Reiter ist durch die Einbindung des InterfaceIF_WORKFLOW nun eine neue Spalte »Schlüssel« zu sehen. Hiermarkiert man das Schlüsselfeld MV_VERNR. Dieser Schritt ist sehrwichtig. Vergisst man ihn, können Objektinstanzen später ggf. nichtrichtig gefunden werden. Insbesondere die TA SWI6 (Workflows zuObjekten) funktioniert ohne Schlüsselkennzeichen gar nicht.

Die Klasse wird explizit angegeben, sodass diese Methode bei einerAbleitung redefiniert werden muss.

****************************************************** * Parameters:* IV_VERNR Importing TYPE ZVERNR Vertragsnummer************************************************************method CONSTRUCTOR.* Schlüsselattribut me->mv_vernr = iv_vernr.

* Vertragsdaten von DB ladenBI_PERSISTENT~REFRESH( ).endmethod.

Jeder neue Aufruf von FIND_BY_LPOR erzeugt für denselben Vertrag in der Datenbank ein neues Objekt im Hauptspeicher.

************************************************************* 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

DATA: lo_vertrag TYPE REF TO zcl_vertrag. DATA: lv_vernr TYPE zvertrag-vernr.

CHECK lpor-instid IS NOT INITIAL.

Listing 5–9CONSTRUCTOR

mit Aufruf auf


© SAP AG

Abb. 5–7Key-Flag an der

Vertragsnummer

Listing 5–10Methode BI_PERSISTENT~

FIND_BY_LPOR


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 Vererbungentgegensteht.

Die Instanzmethode BI_OBJECT~DEFAULT_ATTRIBUTE_VALUEschreibt eine Referenz auf die Vertragsnummer der Instanz in dasErgebnis.

Die Instanzmethode BI_OBJECT~EXECUTE_DEFAULT_METHODruft hier die Anzeigemethode auf.

*- Inst-Id ist die Vertragsnummerlv_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.

************************************************************ 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.

************************************************************ * Parameters:* RESULT Returning TYPE Ref To DATA Ref.auf Datenobjekt************************************************************method BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE.

GET REFERENCE OF MV_VERNR INTO result.endmethod.


BI_PERSISTANT~LPOR


BI_OBJECT~DEFAULT_ATT

RIBUTE_VALUE

1195.5 Erweiterte Ausprägung IF_WORKFLOW

Die Instanzmethode BI_OBJECT~RELEASE ist leer.


Hier wird eine erweiterte, deutlich bessere Implementierung vorge-stellt, die folgende zusätzliche Leistungen bietet:

■ Ermitteln der Objektklasse im CONSTRUCTOR, sodass die Aus-prägung von IF_WORKFLOW stabil gegen Vererbung ist und nichtredefiniert werden muss.

■ Pufferung angelegter Objektinstanzen in einer statischen Tabelle

Es wird ein Instanzattribut GS_LPOR TYPE SIBFLPOR angelegt, dasdie persistente Objektreferenz gleich beim Anlegen des Objektes imCONSTRUCTOR speichert. Das ist sinnvoll, weil sich von einemObjekt weder Typ noch Schlüssel ändern können. Weiterhin wird imCONSTRUCTOR anstelle des SELECT SINGLE die vom IF_WORK-FLOW verlangte Refreshmethode aufgerufen. Diese kapselt den Da-tenbankzugriff.

************************************************************* Parameters:************************************************************method BI_OBJECT~EXECUTE_DEFAULT_METHOD.me->anzeigen( ).

endmethod.

method BI_OBJECT~RELEASE.endmethod.

************************************************************* Parameters:* IV_VERNR Importing TYPE ZVERNR Vertragsnummer************************************************************method CONSTRUCTOR.* Schlüsselattribut me->mv_vernr = iv_vernr.

* 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.


BI_OBJECT~EXECUTE_DE

FAULT_METHOD ruft die

Anzeigemethode auf.


BI_OBJECT~RELEASE

ist leer.

Listing 5–15CONSTRUCTOR bei erwei-

tertem Interface


Weiterhin wird ein statisches PRIVATE-Attribut zur Pufferung allerObjektinstanzen in einer Tabelle eingeführt. Der Zeilentyp ist T_VER-TRAG_INSTANCE, er speichert den Schlüssel (also die Vertragsnum-mer VERNR) und die zugehörige Objektreferenz nebeneinander. Derdarauf aufbauende Tabellentyp ist T_VERTRAG_ INSTANCES.

Die statische Methode BI_PERSISTANT~FIND_BY_LPOR sucht nunmit dem Schlüssel aus INSTID zunächst in der Puffertabelle, ob es dortbereits eine Referenz mit IV_VERNR gibt. Wenn ja, so wird diesezurückgeliefert. Nur wenn die Referenz nicht vorhanden ist, dann wirdsie mit CREATE OBJECT angelegt, in die Puffertabelle eingefügt undzurückgeliefert. Diese Pufferung funktioniert auch bei Vererbung, weilin GT_INSTANCES ja auch Referenzen für abgeleitete Klassen gespei-chert werden können (die Schlüsselattribute dürfen sich natürlich beiAbleitung nicht ändern).

* Vertragsdaten von DB laden me->bi_persistent~refresh( ).

endmethod.

*"* 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 .

************************************************************* * 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.

Listing 5–16Typen und Klassendaten

für Instanzverwaltung

Listing 5–17Methode FIND_BY_LPOR

mit Instanzpufferung


Die Instanzmethode BI_PERSISTANT~LPOR gibt einfach die bereitsgefüllte Struktur GS_POR zurück.

Die Instanzmethode BI_PERSISTENT~REFRESH liest den gesamtenSatz der Vertragstabelle in den Hauptspeicher.

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.

method BI_PERSISTENT~LPOR. result = me->gs_por.endmethod.

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–18Methode LPOR liefert

Instanzdatum GS_POR.

Listing 5–19Methode REFRESH liest

Vertragsdaten von der DB


Die Instanzmethode BI_OBJECT~DEFAULT_ATTRIBUTE_VALUEschreibt eine Referenz auf die Vertragsnummer der Instanz in dasErgebnis.

Die Instanzmethode BI_OBJECT~EXECUTE_DEFAULT_METHODruft hier die Anzeigemethode auf.

Die Instanzmethode BI_OBJECT~RELEASE ist leer.

Instanzpufferung: Performance vs. Datensicherheit

Der Grundgedanke der Instanzverwaltung (Instanzpufferung) in einerstatischen Liste der Klasse ist die Erhöhung der Performance. In die-sem Sinne wird man im Konstruktor möglichst viele (alle?) Daten derObjektinstanz von der Datenbank in entsprechende Instanzattributeeinlesen. Bei nachfolgenden Zugriffen auf die Instanz sind die Datendann bereits vorhanden. Diesem Vorteil stehen zwei potenzielle Nach-teile gegenüber:

Redundanz zwischen

Objekt- und DB-Daten

■ Unbefugte Instanziierung der Klasse an der Instanzverwaltung vor-bei

■ Datenunterschied zwischen Datenbank und Hauptspeicher

Beide Nachteile können genau dann auftreten, wenn die Anwendungs-daten einer Objektinstanz auf der Datenbank geändert werden, was jader eigentliche Zweck der gesamten EDV ist. Das unbefugte Instanziie-ren umgeht man dadurch, dass die Instanzerzeugung einer Klasse aufPRIVATE gesetzt wird. Damit ist sie nur den Methoden der eigenen

method BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE. GET REFERENCE OF MV_VERNR INTO result.endmethod.

method BI_OBJECT~EXECUTE_DEFAULT_METHOD. me->anzeigen( ).endmethod.

method BI_OBJECT~RELEASE.endmethod.

Wenn man sich ein Gefühl dafür verschaffen möchte, wie häufig dieMethode FIND_BY_LPOR aufgerufen wird und wie effektiv die Pufferungder Objektinstanzen ist, dann kann man in diese Methode einen Logpoint-Eintrag zu einer CHECK-POINT-Gruppe schreiben (siehe Kap. 10).

Listing 5–20Wert des Defaultattribu-

tes ist Vertragsnummer.

Listing 5–21Defaultmethode ruft

parameterlose

Anzeigemethode auf.

Listing 5–22Methode RELEASE

bleibt leer.


Klasse erlaubt. Diese müssen zwingend zur Instanziierung die statischeMethode benutzen, die die Instanzverwaltung unterstützt:

In vielen Fällen kann dies einfach die Methode FIND_BY_LPOR sein.So wird zunächst sichergestellt, dass es zu einer Datenbankinstanzmaximal eine Objektinstanz gibt. Die im Kapitel 11 vorgestellteMethode GENERICINSTANTIATE für Klassenreferenzen im Work-flow ruft für die Instanziierung immer die Methode FIND_BY_LPORauf, die die Instanzverwaltung berücksichtigt.

************************************************************ 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–23Statische Methode zur Ins-

tanzerzeugung

Abb. 5–8PRIVATE-

Instanzerzeugung bei

Instanzverwaltung

© SAP AG


Nun muss sichergestellt werden, dass diese einzige Objektinstanzimmer synchron mit dem Datenbankstand gehalten wird. Das ist dannrelativ einfach möglich, wenn die Methoden der Klasse selbst die DBändern. Dann können sie die Änderung nach COMMIT WORK 1:1 indie gepufferte Hauptspeicherinstanz übernehmen. Beim nächsten Auf-ruf von FIND_BY_LPOR wird dann der korrekte Datenstand gezo-gen. Bei komplexen Datenstrukturen kann es manchmal einfachersein, statt eines Updates in Attributdaten der Instanz einfach dieObjektinstanz via IF_WORKFOW~RELEASE( ) aus der Puffertabellezu löschen. Dann wird sie beim nächsten FIND_BY_LPOR neu vonder Datenbank gelesen.

Schwieriger wird es, wenn externe Anwendungen von außerhalbdes Workflows schreibend auf die Datenbank zugreifen. Dann kanndie Klasse, die die Objektinstanzen verwaltet, davon ggf. gar nichtsmerken. Wenn dies erlaubt sein soll, dann muss man dem Workflowdie Änderungen (z.B. via Eventsteuerung) mitteilen. Dieser kann danndie betreffende Instanz invalidieren und so ein Refresh erzwingen.

10.8 dynamische blöcke - bücher.de · 2017-12-15 · s block-workitem des umgebenden blockes bei...

Documents