Modellierung von Actions 

Actions repräsentieren einen Teil der Funktionalität, die eine Anwendungskomponente im Rahmen eines Integrationsszenarios zur Verfügung stellt.

Name

Der Name identifiziert eine Action (innerhalb ihres Namensraums) eindeutig. Der Name ist sprach-unabhängig. Sonderzeichen und Leerzeichen sind nicht gestattet.

Beachten Sie die folgenden Konventionen zum Namen:

·        Vergeben Sie einen aussagekräftigen Namen für die Action. Dieser sollte in englischer Sprache verfasst sein, um allgemein verständlich zu sein.

Trennen Sie einzelne Wörter durch den Wechsel von Groß- und Kleinschreibung (siehe allgemeine Namenskonvention von Designobjekten unter Neues Objekt anlegen).

SendSingleFlightBookingOrder

Beschreibung

Die Beschreibung erläutert die betriebswirtschaftliche Funktion der Action in Kurzform.

Der Text, den Sie in der Beschreibung zu einer Action erfassen, wird in der Grafik des Integrationsszenarios angezeigt wird, wenn diese Action verwendet wird.

Sie sollten bei der Beschreibung folgenden Konventionen folgen.

·        Erfassen Sie die Beschreibung auf Englisch. Achten Sie darauf, dass die Originalsprache Englisch eingestellt ist.

Bei Bedarf können Sie zusätzlich eine deutsche Beschreibung angeben. Achten Sie darauf, dass in diesem Fall die Originalsprache Deutsch eingestellt ist.

·        Orientieren Sie sich am (technischen) Namen der Action. Wenn Sie die Beschreibung in der Originalsprache Englisch erfassen, schreiben Sie die einzelnen Bestandteile des Namens auseinander in „natürlicher Sprache“.

·        Schreiben Sie keinen vollständigen Satz.

·        Halten Sie die Beschreibung möglichst kurz, damit die Anzeige im Integrationsszenario überschaubar bleibt.

·        Sie können höchstens 250 Zeichen verwenden. Kürzen Sie gegebenenfalls sinnvoll ab.

Englisches Beispiel: Send single flight booking order

Deutsches Beispiel: Flugbuchungsauftrag senden

Zuordnung zu einer Software-Komponentenversion

Beim Anlegen einer Action müssen Sie diese einer Software-Komponentenversion zuordnen. Diese Zuordnung hat folgende Konsequenzen:

·        Die Zuordnung entscheidet, mit welcher Software-Komponentenversion die Action (als Designobjekt des Integration Builder) zum Kunden ausgeliefert wird.

·        Die Zuordnung entscheidet, in welchen Anwendungskomponenten die Action verwendet werden kann.

Für weitere Details siehe den folgenden Abschnitt.

Interne und Externe Actions

Sie können eine Action entweder als interne oder als externe Action klassifizieren.

·        Interne Actions werden für eine „eigene“ Software-Komponentenversion definiert

Interne Actions können nur in Anwendungskomponenten vom Typ Hauptinstanz oder Produktversion verwendet werden, wobei die Software-Komponentenversion der Action Teil der Hauptinstanz oder der Produktversion sein muss.

·        Externe Actions werden für eine Software-Komponentenversion eines Partners oder für Vorlagen definiert.

Externe Actions können in Anwendungskomponenten vom Typ Hauptinstanz oder Produktversion (für beliebige Software-Komponentenversionen) oder vom Typ Vorlage verwendet werden. In diesem Fall muss die Action in derselben Software-Komponentenversion wie das Integrationsszenario imlpementiert sein.

Beachten Sie folgende Anwendungsfälle für interne bzw. externe Actions:

Verwendung von Internen Actions

Es handelt sich um eine implementierte Action, d.h. die von der Action implementierte Funktionalität ist Teil einer bekannten Software-Komponentenversion.

Betrachten Sie die Verwendung von internen Actions als Standardfall, wenn die Action eine vorhandene (implementierte) Funktion repräsentiert, die durch ein Interface aufgerufen wird. Die Action liegt deshalb naturgemäß in derselben Software-Komponentenversion, in der die Funktion und das Interface implementiert sind.

·        Wählen Sie für die Art der Verwendung Intern (definiert für eigene Software-Komponentenversion).

·        Wählen Sie die Software-Komponentenversion, in welcher die Action implementiert wird. (D.h. eine implementierte Action gehört immer der implementierenden Software-Komponentenversion an.)

·        Sie können diese Action in beliebigen Integrationsszenarien in Anwendungskomponenten vom Typ Hauptinstanz oder Produktversion verwenden, bei denen die Software-Komponentenversion der Action Teil der Produktversion ist.

·        Die Action wird mit ihrer Software-Komponentenversion ausgeliefert, d.h. die Action wird im Allgemeinen unabhängig von den Integrationsszenarien ausgeliefert, in denen sie verwendet wird.

Begründung

Eine implementierte Action soll genauso wieder verwendet werden können, wie die entsprechende Funktionalität wieder verwendet wird. Deshalb wird die Action bei der Software-Komponentenversion definiert, in der ihre Funktion implementiert ist, und nicht bei der Software-Komponentenversion des Integrationsszenarios.

Sie definieren eine Action in der Software-Komponentenversion SAP APO 3.0A. Da diese Software-Komponentenversion Bestandteil der Produktversion SAP APO 3.0A ist, können Sie diese Action in allen Anwendungskomponenten mit dieser Produktversion einsetzen.

Sie definieren eine Action in der Software-Komponentenversion SAP BASIS 4.6C. Diese Software-Komponentenversion ist Bestandteil vieler Produktversionen (z.B. SAP R/3 4.6C und SAP APO 3.0A), und somit können Sie diese Action in allen Anwendungskomponenten mit solchen Produktversionen einsetzen.

Verwendung von Externen Actions

Es handelt sich um eine modellierte Action, d.h. die Action repräsentiert eine Funktion in nicht näher spezifizierten Produkten oder eine Funktion in einer Software-Komponentenversion eines Partners.

Betrachten Sie die Verwendung von externen Actions als Modellierungshilfe für den Fall, wenn die Funktion, die durch die Action im Integrationsszenario repräsentiert wird, nicht vorhanden (implementiert) ist.

·        Wählen Sie für die Art der Verwendung Extern (definiert für Software-Komponentenversionen eines Partners oder Vorlagen).

·        Wählen Sie die Software-Komponentenversion des Integrationsszenarios, in welcher Sie die Action verwenden wollen.

·        Sie können diese Action in Anwendungskomponenten vom Typ Hauptinstanz oder Produktversion (für beliebige Software-Komponentenversionen) oder vom Typ Vorlage verwenden. Die Action muss hierbei in derselben Software-Komponentenversion implementiert sein wie das Integrationsszenario.

·        Die Action wird mit ihrer Software-Komponentenversion ausgeliefert, d.h. die Action wird immer zusammen mit den Integrationsszenarien ausgeliefert, in denen sie verwendet wird.

Begründung

Eine modellierte Action gehört ihrer Funktionalität nach zu keiner bestimmten Software-Komponentenversion. Die Zuordnung erfolgt deshalb zur Software-Komponentenversion des Integrationsszenarios, in der sie verwendet wird. Eine breite Wiederverwendung der Action erscheint nicht sinnvoll. Deshalb kann diese Action auch nur in Integrationsszenarien mit derselben Software-Komponentenversion wieder verwendet werden.

Sie definieren eine Action für Anwendungskomponenten vom Typ Vorlage in der Software-Komponentenversion SAP APO 3.0A. Sie können diese Action in allen Integrationsszenarien einsetzen, die selbst der Software-Komponentenversion SAP APO 3.0A zugeordnet sind.

Betriebswirtschaftliche Bedeutung von Actions

Beachten Sie bei der Definition und Abgrenzung der Actions die folgenden Aspekte:

·        Die Granularität von Actions sollte es sich an der Granularität von Prozessen oder Prozessschritten orientieren.

·        Bei den Actions sollte (insbesondere durch die Namensgebung und die Dokumentation) der Bezug zur lokalen, betriebswirtschaftlichen Funktion klar werden, welche die Aufgabe innerhalb der Anwendungskomponente erfüllt. Actions sind sozusagen die Ankerpunkte zur lokalen Funktionalität der Anwendungskomponente.

·        Neben der Verbindung zur lokalen Funktionalität sollten Actions auch eine logische Verbindung zu den Customizing-Einstellungen erlauben, die notwendig sind, um diesen Teil eines Integrationsszenarios nutzen zu können.

Weitere Hinweise zur Granularität von Actions finden Sie auch im folgenden Abschnitt.

Verwendung von Actions in Anwendungskomponenten

Beachten Sie bei der Verwendung von Actions in Integrationsszenarien die folgenden Aspekte zu Umfang und Granularität von Actions:

·        Im Integrationsszenario müssen alle die Prozesse/Prozessschritte als Action dargestellt werden, die eine Kommunikation zwischen unterschiedlichen Anwendungskomponenten erfordern. Erfordert ein lokaler Prozess nur einen (oder sehr wenige) Kommunikationsschritt(e), dann genügt es, den ganzen Prozess als eine Action zu modellieren. Erfordert ein lokaler Prozess mehrere Kommunikationsschritte, dann sollte der Prozess als Ablauf mehrerer Prozessschritte modelliert werden.

·        Im Integrationsszenario ist es möglich, auch Zwischenschritte innerhalb eines lokalen Prozesses zu modellieren, welche keine Kommunikationsschritte zu anderen Anwendungskomponenten erfordern. Dies sollte allerdings nur geschehen, wenn dies für das Verständnis des Integrationsszenarios unbedingt nötig ist.