Beschreibung des Szenarios (SAP-Bibliothek - BAPI-Programmierleitfaden (CA-BFA))

Beschreibung des Szenarios

Der Geschäftsprozess

Ein Geschäftsprozess setzt einen betriebswirtschaftlichen Ablauf um und besteht aus einer Abfolge von Einzelfunktionen. Er sollte auf einer inhaltlichen Ebene beschrieben werden und ist unabhängig von jeglichen DV-technischen Details.

Beispiel

Kundenauftragserstellung in einer Filiale mit Bonitätsprüfung in der Zentrale.

Bei der Beschreibung des Geschäftsprozesses müssen folgende Teilaufgaben erledigt werden:

	Definition der Aufgabe und des Umfangs des Geschäftsprozesses.
	Identifizierung der einzelnen Schritte des Geschäftsprozesses. Dies kann beispielsweise über Aufstellen eines Prozessmodells oder über Use Cases erfolgen.

Das Szenario

Ein Szenario ist eine DV-technische Realisierung eines Geschäftsprozesses. Es beschreibt die Aufgabenverteilung und Interaktion zwischen den beteiligten Komponenten. Deshalb kann es mehrere Szenarien geben, die den gleichen Geschäftsprozess umsetzen.

Beispiel

Kundenauftragserfassung und Bonitätsprüfung in verschiedenen SAP-Systemen (Zentrales Rechnungswesen, dezentraler Vertrieb).

Bei der Beschreibung des konkret zu implementierenden Szenarios sind folgende Aspekte zu beachten:

	Identifizierung der beteiligten Komponenten und ihrer jeweiligen Aufgaben.
	Ermittlung, ob über das Szenario Anwendungssysteme integriert oder alternative Frontends angebunden werden sollen. Dies hat z.B. Auswirkungen auf die Granularität der Schritte.
	Festlegung des Informations- und Prozessflusses.
		Es wird festgelegt, welche Schritte komponentenübergreifend durchgeführt werden und welche Schritte innerhalb einer Komponente abzuhandeln sind.
		Insbesondere ist zu definieren, welche Daten zwischen welchen Komponenten ausgetauscht werden und wer diesen Austausch initiiert.
		Festlegung, in welcher Reihenfolge die einzelnen Schritte abgearbeitet werden.
		Identifizierung der Schritte, die in einer Transaktion (LUW) zusammengefasst werden. Siehe auch Transaktionsmodell für die BAPI-Entwicklung. Der Entwickler muss sich beispielsweise die Frage stellen, ob es sinnvoll ist, innerhalb einer LUW einen Kunden anzulegen und anschließend in der gleichen LUW einen Kundenauftrag zu erzeugen.
		Die Fehlerbehandlung muss wesentlich präziser und umfangreicher als bei lokalen Anwendungen sein.
	Für das Szenario ist zu entscheiden, ob die Kopplung der Systeme eng oder lose ist. Für die Art der Kopplung sind Aspekte wie Häufigkeit und Periodizität der Ausführung des Szenarios, Systemverfügbarkeit und Performance ausschlaggebend.
	Es müssen alle Performance-kritischen Schritte identifiziert werden.
	Es ist zu berücksichtigen, welche R/3- Releases innerhalb des Szenarios unterstützt werden sollen.
	Für jedes Szenario ist ein Verantwortlicher zu benennen, der die Korrektheit und Aktualität des Szenarios gewährleisten kann.

Die Business-Objekttypen und BAPIs

Jede an dem Szenario beteiligte Komponente muss Services anbieten, so dass die komponentenübergreifenden Schritte durchgeführt werden können. Es ist nun zu analysieren, wie für diese Services die Verantwortung auf Business-Objekttypen und ihre BAPIs verteilt werden kann. So wird beispielsweise für das externe Anlegen eines Kundenauftrages im SAP-System das BAPI CreateFromData am Business-Objekttyp FlightBooking verwendet.

Für jede beteiligte Komponente sind zunächst die benötigten Business-Objekttypen zu ermitteln. Dabei sind folgende Aspekte zu beachten bzw. Frage zu beantworten:

	Kapselung der benötigten Funktionalität in Business-Objekttypen. Dabei geht es um eine geeignete Zerlegung des Gesamtsystems nach verschiedenen Verantwortlichkeiten. Die Zerlegung bzw. Kapselung soll dabei eindeutig und disjunkt erfolgen.
	Existieren bereits Business-Objekttypen für diese Verantwortlichkeiten? Sind diese genügend differenziert, um die Anforderungen des Szenarios sinnvoll abzudecken?
	Gibt es bestehende Design-Pattern? Es ist zu untersuchen, ob dieses oder ein ähnliches Problem bereits gelöst wurde. Beispiel: Kopf-/Positionspattern, wie beispielsweise bei SalesOrder, PurchaseOrder, etc.
	Abgrenzung der Verantwortlichkeit gegenüber anderen Business-Objekttypen.
	Festlegung der Services, die aufgrund der Verantwortlichkeit zur Verfügung gestellt werden.

Für jeden identifizierten Business-Objekttyp ist zu ermitteln, wie die ihm zugeordneten Services über BAPIs realisiert werden können.
Dabei sind folgende Aspekte zu beachten:

	Jeder zu erbringende Service wird durch ein oder mehrere BAPIs (= Methode am Business-Objekttyp) realisiert.
	BAPIs stellen allgemeine Funktionalität eines Business-Objekttyps zur Verfügung. Dazu sollten sie weitgehend unabhängig von einzelnen Szenarien und in verschiedenen Szenarien verwendbar sein. Um die Verwendbarkeit eines BAPIs in verschiedenen Szenarien zu vereinfachen, sollte die BAPI-Signatur so aufgebaut sein, dass die Parameter und Felder des BAPIs nach Anwendungsfällen getrennt angeordnet sind, sofern dies möglich ist.
	Allerdings kann die Art des Szenarios Auswirkungen auf die Granularität der BAPIs haben. Es lässt sich die Integration von Anwendungssystemen von der Integration von alternativen Frontends unterscheiden: 1. Integration von Anwendungssystemen · Die Integration von Anwendungssystemen wird typischerweise über eine Programm-zu-Programm-Kommunikation, lose asynchrone Kopplung und den Austausch größerer Datenmengen realisiert. · Die Hauptanforderung an die in diesen Szenarien verwendeten Business-Objekttypen und BAPIs ist die Gewährleistung einer hohen Performance, die z.B. über eine Minimierung der Anzahl der Aufrufe erreicht wird. · Die Konsequenz ist eine grobe Granularität der Anwendung, die durch umfangreichere BAPIs realisiert wird. · Beispiel: Automatisches Anlegen eines Kundenauftrages durch ein Programm. Die Realisierung erfolgt über den Business-Objekttyp SalesOrder mit dem BAPI CreateFromData. Folglich wird der Auftrag zunächst vollständig im Sendesystem erzeugt und anschließend als Ganzes an das Empfängersystem geschickt. 2. Integration alternativer Frontends · Szenarien mit alternativen Frontends stellen eine Mensch-Maschine-Kommunikation dar und können sowohl synchron als auch asynchron realisiert werden. · Anforderungen an die Gestaltung der Business-Objekttypen und BAPIs sind die Gewährleistung von Flexibilität, Konfigurierbarkeit und eine Minimierung von Fehlersituationen. · Die Konsequenz ist eine feinere Granularität der Anwendung, welche der Dialogverarbeitung in einem SAP-System entsprechen sollte. · Beispiel: Dialogbasiertes Anlegen eines Kundenauftrages im Internet. Die Realisierung erfolgt z.B. über die beiden Methoden CreateFromData und AddItem am Business-Objekttyp SalesOrder. Dabei legt die Methode CreateFromData in diesem Fall lediglich den Auftragskopf an, während mit Hilfe der Methode AddItem sukzessive Auftragspositionen hinzugefügt werden können. SAP-intern: Wo immer möglich, sollte ein BAPI so gestaltet werden, dass es für beide Verwendungszwecke verwendet werden kann. Das oberste Ziel sollte daher sein, für jeden Business-Objekttyp eine Reihe von standardisierten BAPIs zu entwickeln, die universell einsetzbar sind.
	Das Szenario muss so gestaltet werden, dass es möglich ist, sämtliche für einen BAPI-Aufruf vom SAP-System benötigten Informationen vorher durch andere BAPIs zu bekommen.
	Gibt es Customizing-abhängige BAPIs, so müssen BAPIs zur Verfügung gestellt werden, um diese Customizing-Einstellungen auszulesen.
	SAP-intern: Das Szenario, die Einbindung in das Objektmodell der Anwendung und das Design neuer BusinessObjekttypen wurde mit einem Ansprechpartner aus den Integrationsteams abgesprochen. Wurden während der Analyse noch nicht vorhandene Business-Objekttypen identifiziert, dann werden diese Objekttypen ausschließlich von den Integrationsteams angelegt.