Wissen aus erster Hand. Leseprobe »Grundlagen für die Definition von Geschäftsprozessen«(Kapitel 3) Inhalt Index Der Autor Leseprobe weiterempfehlen

Transkript

1 Wissen aus erster Hand. Leseprobe SAP bietet mehr als ein herkömmliches Dokumentenmanagement- System: Zusätzlich zu den Workflow-Funktionalitäten bietet es Technologien für den Schriftverkehr und für die Integration zwischen fachlichen Anwendungen und den zugehörigen Dokumenten im SAP- System. Diese Leseprobe stellt sie Ihnen vor.»grundlagen für die Definition von Geschäftsprozessen«(Kapitel 3) Inhalt Index Der Autor Leseprobe weiterempfehlen Rinaldo Heck Geschäftsprozessorientiertes Dokumentenmanagement mit SAP E-Book (PDF, Online), 279 Seiten, Mai ,90 Euro, ISBN

2 SAP bietet mehr als ein herkömmliches DokumentenmanagementSystem: Zusätzlich zu den Workflow-Funktionalitäten bietet es Technologien für den Schriftverkehr und für die Integration zwischen fachlichen Anwendungen und den zugehörigen Dokumenten im SAPSystem. 3 Grundlagen für die Definition von Geschäftsprozessen Nachdem wir uns im letzten Kapitel mit den Funktionen eines SAP-Systems für die Abbildung eines Dokumentenmanagement-Systems (DMS) beschäftigt haben, wollen wir im Folgenden die Funktionen eines geschäftsprozessorientierten Dokumentenmanagements näher betrachten. Abbildung 3.1 verschafft Ihnen einen ersten Überblick. Geschäftsprozessorientiertes Dokumentenmanagement mit SAP Integration Schriftverkehr Workflow Administration Anzeige Recherche Ablage/ Archivierung Eingang/ Klassifikation Datenbank mit Verwaltungsdaten SAP Content Server Filesystem SAP Cache Server RAID-System Third-Party-Archiv Datenbank Jukebox Abbildung 3.1 Überblick über das geschäftsprozessorientierte Dokumentenmanagement 81

3 3 Grundlagen für die Definition von Geschäftsprozessen Services für die Benachrichtigung von Zuständigen 3.1 Beim geschäftsprozessorientierten Dokumentenmanagement spielen offene Architekturen eine wesentliche Rolle. In diesem Kapitel beschäftigen wir uns daher mit den folgenden Themen: Start Erzeugung eines Workflows Benutzer öffnet Business Workplace Benutzer startet Workitem Benachrichtigung von Zuständigen Integration von Dokumenten in Geschäftsprozessen Schriftverkehr Workflow Ereignistabellen Workflow Laufzeittabellen Anwendungstabellen 3.1 Services für die Benachrichtigung von Zuständigen Für eine effektive Bearbeitung eines Geschäftsprozesses müssen die jeweils Zuständigen zum richtigen Zeitpunkt informiert werden. Jeder Zuständige hat dabei einen Schritt des Geschäftsprozesses zu erledigen. Die Reihenfolge der Schritte ist durch die Definition des Geschäftsprozesses festgelegt. Diese Funktionalitäten werden technologisch in einem SAP-System durch den SAP Business Workflow sichergestellt. In den nächsten Abschnitten werden wir uns mit diesem Workflow auseinandersetzen und ein Grundverständnis für dessen Funktionsweise entwickeln Prinzipielle Arbeitsweise von SAP Business Workflow Sehen wir uns zunächst die prinzipielle Arbeitsweise des SAP Business Workflows an (siehe Abbildung 3.2). Ein Workflow durchläuft folgende Schritte: 1. Eine Anwendung startet meist per Ereignis einen Workflow. Bei der Behandlung des Ereignisses wird nicht lediglich der Workflow gestartet. Vielmehr werden zunächst über den sogenannten Ereignismanager die Ereignistabellen gefüllt sowie mögliche Ereignis-Typ-Kopplungen geprüft. Sind Ereignis-Typ-Kopplungen vorhanden, werden weitere Schritte abhängig von den Einstellungen dieser Kopplungen durchgeführt. Hierzu zählt beispielsweise das Starten eines weiteren Workflows oder die Ausführung eines Funktionsbausteins, der als Verbraucher eines Ereignisses hinterlegt ist. Zum Abschluss werden die Workflow-Laufzeittabellen mit den übergebenen Daten des Ereignisses sowie den Daten aus der Definition des Workflows gefüllt (siehe Abschnitt 3.1.2,»Definition von Workflows«). Ein Eintrag in den Tabellen des Laufzeitsystems wird dabei als Workitem bezeichnet. Ende Erzeugung des nächsten Schritts Einzelschritt-Workflow Mehrschritt-Workflow Einzelschrittoder Mehrschritt- Workflow? Abbildung 3.2 Prinzipielle Arbeitsweise von SAP Business Workflow (angelehnt an: Ulrich Mende,»Workflow und ArchiveLink mit SAP«, S. 215) 2. Ein Benutzer startet den SAP Business Workplace (Transaktion SBWP). Während des Startens werden die Workflow-Laufzeittabellen gelesen und die Workitems auf Basis des Datums und der Bearbeiterzuordnung (siehe Abschnitt 3.1.3,»Bearbeiterfindung«) gefiltert und angezeigt (siehe Abbildung 3.3). Abbildung 3.3 Anzeige eines Workitems im SAP Business Workplace Benutzer schließt Workitem 82 83

4 3 Grundlagen für die Definition von Geschäftsprozessen Services für die Benachrichtigung von Zuständigen Durch einen Doppelklick startet der Benutzer das Workitem und nimmt es damit an. Kommen noch weitere Bearbeiter für das Workitem in Betracht, so ist es für diese nun nicht mehr sichtbar. Beim Start wird die Methode der Workflow-Aufgabe angesprochen. Die Methode kann auf zwei Weisen hinterlegt sein: entweder als Methode eines Business-Objekts (BO) aus dem Business Object Repository (BOR) oder als Methode einer ABAP- Klasse. Eine Klassenimplementierung ist erst ab Release 6.40 des Applikationsservers möglich. In Abschnitt 4.7,»Workflow«, werden wir die erste Variante nutzen. 4. Nach dem Start des Workitems wird die hinterlegte Funktionalität der Workflow-Aufgabe ausgeführt. Handelt es sich beispielsweise um das Anlegen eines Geschäftspartners (Methode Create des Business-Objekts BUS1006), so werden auf Basis der durchgeführten Aktionen die Anwendungstabellen des Geschäftspartners nach Abschluss durch Betätigen der Drucktaste Speichern gefüllt. 5. Mit dem Schließen des Workitems verlässt der Programmablauf die fachliche Logik der aufgerufenen Methode und kehrt in das Workflow-Laufzeitsystem zurück. Dieses prüft nun gegen die Definition des Workflows, ob es sich um einen Einzelschritt-Workflow (nur ein ausführbarer Schritt) oder um einen Mehrschritt-Workflow (mehrere ausführbare Schritte) handelt. 6. Sieht die Definition des Workflows mehrere ausführbare Schritte vor, so prüft das Workflow-Laufzeitsystem den Typ des folgenden Schritts. Ist der nächste Schritt vom Typ Ereignis senden, wird entsprechend der Ereignismanager angesprochen. Ereignis-Typ-Kopplungen werden geprüft und wie im ersten Schritt beschrieben ausgeführt. Wird der Folgeschritt ohne das Auslösen eines Ereignisses vollzogen, so werden die Workflow-Laufzeittabellen mit den aktuellen Parametern des Workflows und mit den Daten der Definition des nächsten Schritts gefüllt. Der Status des vorangegangenen Schritts wird auf COMPLETED gesetzt. Im Falle des letzten Schritts wird der Workflow beendet, und der Workflow-Status wird auf COMPLETED gesetzt. 7. Liegt die Definition eines Einzelschritt-Workflows vor, so wird der Workflow nach dem Schließen durch den Benutzer beendet, und der Status des Workflows wird innerhalb der Workflow-Laufzeittabellen auf COMPLETED gesetzt Definition von Workflows Grundlage der Ausführung ist die vorherige Definition eines Workflows (siehe Abschnitt 3.1.1,»Prinzipielle Arbeitsweise von SAP Business Workflow«) vorgestellt. Die Definition des Workflows erfolgt im SAP Workflow Builder (Transaktion SWDB). Innerhalb des Workflow Builders kann über eine grafische Oberfläche der Ablauf des Geschäftsprozesses als Workflow modelliert werden; Schritte bilden die Grundlage dieses Ablaufs. Ähnlich wie bei der Erstellung eines Programmablaufplans (PAP) ermöglichen Schritttypen eine Modellierung. Es existieren die folgenden Schritttypen: Aktivität (Ausführen einer Workflow-Aufgabe mit definierten Methoden) Benutzerentscheidung (Benutzer entscheidet weiteren Ablauf) Warten auf Ereignis (Warten auf ein definiertes Ereignis) Bedingung (eine definierte Bedingung entscheidet den weiteren Ablauf mit zwei Alternativen) Mehrfachbedingung (Wert eines Containerelements entscheidet weiteren Ablauf mit mehreren Wegen) paralleler Abschnitt (Parallelisieren des weiteren Ablaufs) UNTIL-Schleife (weiterer Ablauf wird ausgeführt, bis die Abbruchbedingung erfüllt ist) WHILE-Schleife (weiterer Ablauf wird ausgeführt, wenn die Bedingung erfüllt ist) Ablaufsteuerung (Steuerung über die Funktionen Workitem abbrechen oder Workitem obsolet setzen anderer Workflows) Containeroperation (Verändern eines Containerelements durch Zuweisung) Ereignis senden (Senden eines Ereignisses an den Ereignismanager) etc. Für die Datenübergabe zwischen den einzelnen Schritten ist ein allgemeingültiges Konzept notwendig. SAP hat dafür das Konzept der Container und der Definition eines Datenflusses zwischen den Containern entwickelt. Im Rahmen der Definition eines Workflows müssen demnach Containerelemente (sie können als Variablen des Workflows betrachtet werden) und der Datenfluss zwischen den einzelnen Containern festgelegt werden. Abbildung 3.4 zeigt den Aufbau der Container sowie einen möglichen Datenfluss zur Laufzeit

5 3 Grundlagen für die Definition von Geschäftsprozessen Services für die Benachrichtigung von Zuständigen 3.1 Ereignis Ereigniscontainer Workflowcontainer Containerelement 1 Containerelement 2 Anwendung Variable 1 Variable 2 Variable 3 Variable n Aufgabencontainer von Schritt 1 Methodencontainer 5. Wie beim Starten des ersten Schritts vom Benutzer erfolgt, entsprechend dem festgelegten Datenfluss, die Übergabe in den Aufgabencontainer des zweiten Schritts. 6. Vom Aufgabencontainer wird beim Ausführen des Workitems jedes definierte Containerelement des Datenflusses weiter an den Methodencontainer übergeben. Dieser sieht dabei ebenfalls nur die vom Datenfluss definierten und übergebenen Containerelemente. Auf Basis der Schritttypen, der Container, der Containerelemente sowie des Datenflusses kann die Modellierung eines Workflows stattfinden. Die praktische Durchführung einer solchen Definition betrachten wir in Abschnitt 4.7,»Workflow«. Containerelement 3 Containerelement n Aufgabencontainer von Schritt 2 Methodencontainer Bearbeiterfindung Ein wichtiger Aspekt bei der Zustellung eines Workitems ist die Bearbeiterfindung. Bei der Bearbeiterfindung wird grundsätzlich zwischen folgenden Arten von Bearbeitern unterschieden: Abbildung 3.4 Datenfluss zwischen Containern 1. Eine Anwendung löst ein Ereignis aus. Dabei füllt sie einen Ereigniscontainer mit den Variablen der Anwendung. Containerelemente sind dabei die Variablen des Workflows. 2. Das Ereignis wird vom Ereignismanager gesteuert, um darauf basierend einen Workflow zu erzeugen. Dabei werden Containerelemente über den definierten Datenfluss vom Ereigniscontainer in den Workflow-Container überführt. 3. Beim Start des SAP Business Workplace durch einen Benutzer werden die Containerelemente des Workflow-Containers in den Aufgabencontainer des ersten Schritts gestellt. Die übergebenen Elemente können dann in den Spalten des SAP Business Workplace angezeigt werden. Der Aufgabencontainer sieht nur die per Datenfluss übergebenen Containerelemente. 4. Führt der Benutzer das Workitem aus, werden über den definierten Datenfluss zwischen Aufgabencontainer und Methodencontainer die Containerelemente überführt. Nun stehen sie der aufgerufenen Methode des Business-Objekts zur Verfügung. Am Ende des Methodendurchlaufs werden eventuell geänderte Containerelemente wieder über den Datenfluss zurück an den Aufgabencontainer und, falls definiert, auch an den Workflow-Container zurückgegeben. mögliche Bearbeiter zuständige Bearbeiter ausgeschlossene Bearbeiter Beispiel: Reklamation In einem Gebäude eines Unternehmens arbeiten dreißig Mitarbeiter, verteilt auf sechs Abteilungen. Jeder Abteilung sind vier Kollegen und ein Auszubildender zugeordnet. Per Post kommt eine Reklamation eines Großkunden. Es könnte jeder der 30 Mitarbeiter angesprochen werden (mögliche Bearbeiter). Es gibt aber eine spezielle Abteilung für die Betreuung der Großkunden (zuständige Bearbeiter). Da es sich um einen wichtigen Kunden handelt, soll der Auszubildende den Fall nicht bearbeiten (ausgeschlossene Bearbeiter). Die Abbildung der Bearbeiterfindung kann auf unterschiedlichen Wegen stattfinden. Zum einen können Sie über das Organisationsmanagement entsprechende Zuordnungen durchführen. Dazu werden sogenannte Regeln in der Workflow-Aufgabe hinterlegt. Diese Aufgabe ermittelt auf Basis von Regeln die entsprechenden Bearbeiter über die gepflegte Organisationsstruktur eines Unternehmens. Eine Regel könnte zum Beispiel lauten:»ermittle den Abteilungsleiter des aktuell angemeldeten Benutzers.«Beim Starten des Workflows könnten auch zuvor aus anderer Quelle ermittelte Bearbeiter von außen als Containerelement übergeben werden. Dabei wird an der Work

6 3 Grundlagen für die Definition von Geschäftsprozessen Services für die Benachrichtigung von Zuständigen 3.1 flow-aufgabe für die Bearbeiterzuordnung ein Ausdruck in Form des Containerelements hinterlegt. Dieses Vorgehen werden wir in Abschnitt ,»Verteilung«, nutzen. Funktionsgruppe Funktionsbaustein (SAP_WAPI_...) DECISION_READ Beschreibung Lesen der Benutzerentscheidung Ansteuerung von Workflows aus Programmen Für die Ansteuerung von Workflows aus Programmen bietet SAP Business Workflow mehrere Schnittstellen. Tabelle 3.1 zeigt einige Funktionsbausteine der Schnittstelle und deren Funktionsgruppe. Allen Funktionsbausteinen ist das Präfix SAP_WAPI_ voranzustellen. In Abschnitt ,»Workflow«, werden wir uns den Funktionsbaustein SAP_WAPI_START_WORK- FLOW im Einsatz anschauen. GET_EXCLUDED_FUNCTION GET_PROPERTY GET_TASK_CNT_SCHEMA GET_WI_CNT_SCHEMA READ_CONTAINER Berechnen ungültiger Funktionen Ermitteln der Eigenschaften des Schritts Ermitteln des XML-Schemas für den Aufgabencontainer Ermitteln des XML-Schemas für den Workflow-Container Lesen des Containers Funktionsgruppe Funktionsbaustein (SAP_WAPI_...) Beschreibung SET_ERROR Workitem auf Status»Fehler«setzen SWRDLG DIALOG_NOTES_DISPLAY Dialoge Anzeigen der Anlagen SET_MESSAGE Nachricht zu einem Workitem loggen DIALOG_PROTOCOL Anzeigen des Workflow-Protokolls START_WORKFLOW Workflow starten DISPLAY_WORKITEM Workitem anzeigen WORKITEM_COMPLETE Workitem beenden SWRI Infosystem WORKITEM_CONFIRM Ende des Workitems bestätigen GET_DEPENDEND_WIS Lesen abhängiger Workitems WORKITEM_DELETE Löschen eines Workitems OBJECTS_IN_WORKITEM Objekte in einem Workitem ermitteln WRITE_CONTAINER Container schreiben SWRS Vertretung WORKITEMS_BY_DEADLINE Workitems nach Terminüberschreitung SUBSTITUTES_GET Vertretung ermitteln WORKITEMS_BY_ERROR Workitems im Status Fehler SUBSTITUTE_ACTIVATE Vertretung aktivieren WORKITEMS_BY_FREQUENC Workitems nach Häufigkeit SUBSTITUTE_DEACTIVATE Vertretung deaktivieren WORKITEMS_BY_TASK Workitems nach Aufgabe SUBSTITUTE_DELETE Vertreter löschen WORKITEMS_TO_OBJECT Workitems zu einem Objekt SUBSTITUTE_MAINTAIN Vertreter pflegen SWRR Laufzeit SUBSTITUTE_PROF_GET Liste mit Vertreterprofilen ASYNC_RULE_COMPLETE Bearbeiter der asynchronen Regelauflösung setzen SUBSTITUTIONS_GET SUBSTITUTION_ADOPT Vertretungen ermitteln Vertretung übernehmen CREATE_EVENT Ereignis erzeugen SUBSTITUTION_END Vertretung beenden DECISION_COMPLETE Beenden der Benutzerentscheidung Tabelle 3.1 Schnittstellen von SAP Business Workflow (Forts.) Tabelle 3.1 Schnittstellen von SAP Business Workflow 88 89

7 3 Grundlagen für die Definition von Geschäftsprozessen Services für die Integration von Geschäftsprozessen und Dokumenten 3.2 Weitere Informationen sowie Erklärungen zu vielen weiteren Funktionen und Eigenschaften des SAP Business Workflows finden Sie im SAP Help Portal und in Workflow-Management mit SAP (Brennecke, Dart, Rickayzen, Schneider, SAP PRESS 2002). 3.2 Services für die Integration von Geschäftsprozessen und Dokumenten Das SAP-System bildet einerseits Ihre betriebswirtschaftlichen Prozesse ab und stellt Ihnen andererseits Funktionen für die Dokumentenverwaltung zur Verfügung. Bei der Vereinigung dieser beiden Welten werden Sie in einem SAP-System von zwei Technologien unterstützt: dem SAP Records Management und den Generischen Objektdiensten (GOS, Generic Object Services). Diese beiden Technologien werden wir uns im Folgenden näher ansehen. Technologie dar. Die Interfaces sind auf Basis ihrer Funktionen in Klassenrollen zusammengefasst. Die Klassenrollen gliedern sich in Backend- und Client-Rollen. Diese Unterscheidung schafft eine klare Trennung zwischen frontend-unabhängigen und frontend-abhängigen Funktionalitäten. Aufgrund dieser Trennung können Massenoperationen auf Service Providern auch als Hintergrundaufgaben in Zeiten verlegt werden, in denen Benutzern weniger Performance zur Verfügung gestellt werden muss. Abbildung 3.5 zeigt dies schematisch. Für Service Provider kann zudem eine Parametrisierung über Connection-Parameter definiert werden. Die Pflege der Connection-Parameter erfolgt bei der Anlage einer Elementart, die damit eine Ausprägung eines Service Providers ist. Die Elementart muss zusätzlich über eine Klassifikation weiter kategorisiert werden und steht dann für die Verwendung in einer Akte zur Verfügung. Records Management Registry SAP Records Management Durch SAP ArchiveLink ist die Möglichkeit gegeben, archivierte Dokumente mit einem Business-Objekt wie dem Geschäftspartner zu verknüpfen. Geschäftsprozesse verlaufen aber in aller Regel über Business-Objektgrenzen hinweg. Dementsprechend entstehen an verschiedenen Business-Objekten Verknüpfungen zu archivierten Dokumenten. Genau hier setzt SAP Records Management an. Es bildet eine fachliche Klammer um mehrere Business- Objekte und deren Dokumente. Es geht sogar noch einen Schritt weiter und bietet eine offene, serviceorientierte Integrationsplattform, die es Ihnen ermöglicht, beliebige (SAP- oder Nicht-SAP-)Anwendungen in einer Oberfläche zu vereinen. Zudem bietet das SAP Records Management einen zentralen Einstieg in den Geschäftsprozess und fördert dessen Transparenz. Dabei setzt es auf fast alle in Kapitel 2,»Grundlagen des Dokumentenmanagements mit SAP«, genannten Technologien auf. Klassenrollen Klassenrolle Client Service Provider Interface 1 Interface 2 Klassenrolle Backend implementiert implementiert Klasse für den Client Interface 1 Klasse für das Backend Interface 2 Interface 3 Abbildung 3.5 Zusammenspiel von Klassenrollen, Interfaces und Service Providern Architektur Die serviceorientierte Architektur von SAP Records Management setzt auf dem Records Management Service Provider Repository (Transaktion SRMREG- EDIT) auf. Dienste wie die Funktionalitäten eines SAP ArchiveLink-Dokuments werden dort als sogenannte Service Provider registriert. Ein Service Provider definiert sich als eine Menge von Klassen, die bestimmte Interfaces implementieren. Service Provider stellen somit eine Schale um die genutzte Für die Koordination der einzelnen Service Provider ist das Records Management Framework (RMF) zuständig (siehe Abbildung 3.6). Dieses unterteilt sich ebenfalls in ein Client- und ein Backend-Framework. Die Kommunikation zwischen zwei Service Providern findet ausschließlich über das Records Management Framework statt. Damit semantische Daten (beispielsweise die Geschäftspartnernummer einer Akte) zwischen zwei Service Providern transportiert werden können, ist im RMF ein Kontextkanal vorhanden, der diese Kommunikation ermöglicht

8 3 Grundlagen für die Definition von Geschäftsprozessen Services für die Integration von Geschäftsprozessen und Dokumenten 3.2 Abbildung 3.6 Koordination zwischen zwei Service Providern (angelehnt an: Becker, Schroeder, Spinola,»SAP Records Management«, S. 152) SAP liefert Standard-Service-Provider aus. Dazu zählen Service Provider für: Akten Vorgänge Office-Dokumente ArchiveLink-Dokumente URLs Business Workflows Reports Notizen Aktenmodelle Transaktionen etc. Clientframework Service Provider 1 Klasse für Client Klasse für Backend Kontext-Kanal Service Provider 2 Klasse für Client Klasse für Backend Records Management Framework Backendframework (RMF) Praxistipp Die Arbeit in Projekten ist mit SAP Records Management effizienter. Zum einen existieren Service Provider, die durch Customizing einfach genutzt werden können, sodass Anforderungen des Kunden relativ schnell umgesetzt werden können. Durch die strikte Einhaltung der Objektorientierung kann zudem eine Anpassung über Redefinitionen ohne Durchführung von Modifikationen erfolgen. Somit ist die Wartung einer Lösung mit SAP Records Management leichter zu gewährleisten. Reichen diese Funktionalitäten der Standard-Service-Provider nicht aus, so hat man die Möglichkeit, einige Klassen des SAP-Standards über die Registrierung eigener Service Provider auszutauschen. Zusätzlich besteht die Möglichkeit, komplett eigene Service Provider zu entwickeln. Identifikation eines Objekts Innerhalb des RMF ist eine eindeutige Identifikation eines Objekts notwendig. Dies erfolgt über die POID (Persistent Object Identifier). Diese setzt sich zusammen aus der AREA POID, der SRM POID und der SP POID. AREA POID Die AREA POID ermöglicht die Verwaltung übergeordneter Informationen. Sie wird von der RMS-ID repräsentiert und über die Klassifikation bei Anlage einer Elementart zugewiesen. Damit wird eine Obermenge der möglichen Service Provider eines Bereichs definiert. In der Praxis wird dieses Konzept zur strikten Trennung von einzelnen Geschäftsbereichen genutzt (beispielsweise Personalwesen und Vertrieb). SRM POID (SAP Records Management POID) Die SRM POID definiert einen Service Provider innerhalb des SAP Records Managements. Als Schlüssel wird die Elementart (SPS-ID) genutzt. Zudem definiert die SRM POID den Zustand des Objekts. Dient sie als Platzhalter eines Objekts, ist der Zustand Modell gesetzt. Stellt sie ein konkretes Objekt dar, welches durch die SP POID näher beschrieben wird, ist der Zustand Instanz. SP POID (Service Provider POID) Im Gegensatz zur SRM POID liefert die SP POID den konkreten Schlüssel des Objekts. Dabei ist der Aufbau des Schlüssels stark abhängig von der jeweils genutzten Anwendung. Für ein ArchiveLink-Dokument setzt sich der Schlüssel beispielsweise aus Content Repository, Dokument-ID und Dokumenttyp zusammen

9 3 Grundlagen für die Definition von Geschäftsprozessen Services für die Integration von Geschäftsprozessen und Dokumenten 3.2 Aktenmanagement Auf Basis der bisher vorgestellten Eigenschaften arbeitet der Service Provider Record. Dieser nutzt als Persistenz die in Abschnitt 2.3.3,»Document Management Service des Knowledge Providers«, vorgestellte Dokumentinfrastruktur und speichert Instanzen einer Akte in Form einer XML-Datei. Seine Funktionen sind darauf spezialisiert, andere Service Provider des Records Management Service Provider Repositorys einzubinden und deren definierte Funktionalität zur Verfügung zu stellen. Um den Service Provider Record zu nutzen, müssen Sie zunächst den Aufbau einer Akte in Form eines Aktenmodells definieren. Dies erfolgt über den sogenannten Records Modeler, bei dem es sich ebenfalls um einen Service Provider handelt. Nach Abschluss der Modellierung kann das Aktenmodell über den Connection- Parameter MODEL_ID mit der Elementart der Akte verknüpft werden. Die einzelnen Schritte werden Sie in Abschnitt 4.9.2,»Aktenmodell anlegen«, und den darauf folgenden Kapiteln kennenlernen. Weitere Informationen sowie Erklärungen zu vielen weiteren Funktionen und Eigenschaften zu SAP Records Management finden Sie im SAP Help Portal und im Buch SAP Records Management (Becker, Schroeder, Spinola, SAP PRESS 2009) Generische Objektdienste Die Integration von weiteren Funktionen an Business-Objekten erfolgt über die Generischen Objektdienste (GOS). Sie bieten den gleichen Zugriff auf allgemeingültige Funktionen zu einem Objekt. Zu diesen Funktionen zählen: das Erfassen von (persönlichen oder allgemeinen) Notizen das Anlegen von Anlagen das Erstellen von ArchiveLink-Verknüpfungen für Dokumente, die im Archiv liegen oder später eingescannt und abgelegt werden sollen das Starten eines Workflows das Anzeigen einer Übersicht über alle Workflows, an denen das Objekt beteiligt ist das Anzeigen einer Übersicht über alle Business-Objekte, die mit dem Objekt verknüpft sind das Versenden des Objekts als Anlage einer Nachricht Gestartet werden die Dienste zu einem Objekt über das Menü System Dienste zum Objekt. Wenn für das aktuelle Business-Objekt Dienste verfüg- bar sind, wird ein Menü in der Titelzeile des SAP-Systems eingeblendet (siehe Abbildung 3.7). Abbildung 3.7 GOS eingeschaltet für das Business-Objekt»Geschäftspartner«Die GOS bieten zudem die Möglichkeit, eigene Dienste für Anwendungen zu definieren. Damit steht der Integration einer Projektlösung nichts im Wege. Die Definition eines Dienstes erfordert folgendes Vorgehen: Anlegen des Generischen Objektdiensts Ein Generischer Objektdienst wird durch eine ABAP-Klasse repräsentiert. Diese muss von der Klasse CL_GOS_SERVICE erben. Statusprüfung des Diensts Es ist die Methode CHECK_STATUS zu redefinieren. Diese Methode CHECK_ STATUS wird im Rahmen der Aktivierung wie zuvor beschrieben durchlaufen. Mit ihrem Ergebnis steuert sie das Verhalten der Drucktaste im Menü der Generischen Objektdienste. Ausführung des Diensts Es ist die Methode EXECUTE zu redefinieren. EXECUTE wird nach Betätigung der Drucktaste im Menü der Generischen Objektdienste durchlaufen und implementiert die Funktionalität des Dienstes. Aktivieren des Dienstes per Customizing Für die Aktivierung des Dienstes müssen Sie in der Tabelle SGOSATTR über die Tabellenpflege (Transaktion SM30) ein Eintrag erstellen. Dabei werden die Beschreibung der Funktion (wird im Menü als Beschreibung der Drucktaste genutzt), das Icon sowie die Klasse hinterlegt. Zudem kann man ein COMMIT WORK nach Ausführung der Methode EXECUTE zur Datensicherung die Ausführung als Control aktivieren. Die Reihenfolge der Funktionen im Menü der Generischen Objektdienste kann ebenso festgelegt werden. Außerdem können Sie anstelle einer einzelnen Drucktaste eine Menge von Diensten hinterlegen. Dazu muss die Klasse das Interface IF_GOS_SERVICE_MULTIPLE unterstützen. Weitere Informationen sowie Erklärungen zu den Standarddiensten der Toolbox der Generischen Objektdienste erhalten Sie im SAP Help Portal

10 3 Grundlagen für die Definition von Geschäftsprozessen Services für den Schriftverkehr Services für den Schriftverkehr Ein Geschäftsprozess benötigt nicht nur Funktionalitäten für die Verwaltung von Dokumenten. Er besteht ebenso aus dem Schriftverkehr, der mit Kunden, Lieferanten, Mitarbeitern, Kollegen, Krankenkassen oder dem Staat stattfindet. Die Erzeugung des Schriftverkehrs bedarf fachlicher Daten aus einer betriebswirtschaftlichen Anwendung, deshalb bietet SAP ebenso Technologien für die Erzeugung des Schriftverkehrs an. Aktuell sind in einem SAP-System zwei verschiedene Methoden für die Erstellung von Schriftverkehr relevant: SAP Interactive Forms by Adobe SAP ArchiveLink-Szenarien für Ausgangsdokumente Durch die Einführung von SAP Interactive Forms by Adobe wurden die Technologien SAPscript und SAP Smart Forms um eine Alternative erweitert. Welche Technologie man im Projekt einsetzt, hängt von den Systemanforderungen und von den Anforderungen an die Formularerzeugung ab. Funktionale Unterschiede können Auslöser für den Einsatz von SAPscript oder Smart Forms sein. Bitte beachten Sie zu den funktionalen Unterschieden zwischen SAP Smart Forms und SAP Interactive Forms by Adobe den SAP-Hinweis SAP Interactive Forms by Adobe SAP Interactive Forms by Adobe sind aus einer strategischen Partnerschaft zwischen SAP und Adobe entstanden. Dabei wurde die reine Erzeugung von Druckformularen, die durch SAPscript und Smart Forms gegeben ist, durch die Interaktion über Formulare erweitert. Interaktion bedeutet hier die Möglichkeit, PDF-Formulare zu erstellen, die beim Öffnen mit dem Adobe Reader über Eingabefelder verfügen. Nach dem Ausfüllen dieser Eingabefelder können die eingetragenen Werte mit dem Formular gespeichert werden. Für den Einsatz ist eine separate Lizenz notwendig. Die Funktionalität der Druckformulare wird ebenso von SAP Interactive Forms by Adobe unterstützt und ersetzt nach und nach den Einsatz von SAPscript und Smart Forms bei SAP. Beispiel: Antragsformular Ein Unternehmen möchte seinen Kunden die Möglichkeit bieten, das Antragsformular auch offline (sprich: ohne Verbindung zum Internet) auszufüllen. Dadurch sollen die Kundenzufriedenheit gesteigert und der Geschäftsprozess optimiert werden. Dazu wird folgendes Szenario für Kunde Mustermann definiert: Kunde Mustermann lädt sich von der Unternehmenswebsite das Antragsformular auf seinen lokalen Computer herunter. Auf einer Zugfahrt von Hamburg nach München ohne Internetverbindung füllt Herr Mustermann das Antragsformular mit dem Adobe Reader aus und speichert den Antrag einschließlich der eingetragenen Daten. Beim nächsten Büroaufenthalt mit Internetverbindung öffnet der Kunde das Antragsformular mit den gespeicherten Eingaben erneut und betätigt die darin enthaltene Drucktaste Senden. Das Formular wird daraufhin an eine zentrale -Adresse des Unternehmens gesendet. Im System angekommen, werden die Daten extrahiert und in eine Datenbank überführt. Der zuständige Sachbearbeiter wird informiert und bearbeitet den Antrag. Grundprinzip der Generierung/Extraktion Grundprinzip von SAP Interactive Forms by Adobe ist die getrennte Behandlung von Daten und Design der Vorlage bei gemeinsamen Transport. Eine Formularvorlage (XDP) und die Formulardaten im XML-Format werden dabei über den Adobe Document Service zu einer PDF-Datei zusammengeführt. Beim Einsatz von interaktiven Formularen können zusätzlich die Formulardaten im XML-Format bei der Rückkehr einer interaktiven PDF-Datei an das Backend-System über den Adobe Document Service extrahiert werden. Damit wird es möglich, die Daten des Formulars ohne OCR oder manuelle Bearbeitung in die Datenbank zu schreiben oder für die weitere Verarbeitungslogik zu nutzen (siehe Abbildung 3.8). Die Anwendung nutzt für die Steuerung der Formularaktionen das sogenannte PDF-Objekt. Das PDF-Objekt ist eine ABAP-Klasse, welche die Verbindung zwischen dem System, auf dem sich die Anwendung befindet, und dem Adobe Document Service herstellt. Als Kommunikationsbasis dienen dabei Webservices