Modellierung von Integrationsszenarien
allgemein 
Name
Der Name identifiziert ein Integrationsszenario (innerhalb seines Namensraums) eindeutig. Der Name ist sprachunabhängig. Sonderzeichen und Leerzeichen sind nicht gestattet.
Beachten Sie die folgenden Konventionen zum Namen:
· Vergeben Sie einen aussagekräftigen Namen für das Integrationsszenario. 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 die Hinweise zur Namenskonvention von Designobjekten unter Neues Objekt anlegen).
Beispiel: SingleFlightBooking
Beschreibung
Die Beschreibung ist sprachabhängig und erläutert das Integrationsszenario näher.
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 des Integrationsszenarios. 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.
· Sie können höchstens 250 Zeichen verwenden. Kürzen Sie gegebenenfalls sinnvoll ab.
Englisches Beispiel: Single flight booking.
Deutsches Beispiel: Einzelflugbuchung
Zuordnung zu einer Software-Komponentenversion
Beim Anlegen eines Integrationsszenarios müssen Sie dieses einer Software-Komponentenversion zuordnen. Über diese Zuordnung wird festgelegt, mit welcher Software-Komponentenversion das Integrationsszenario (als Designobjekt des Integration Builder) zum Kunden ausgeliefert wird.
Berücksichtigen Sie folgende Aspekte bei der Wahl einer Software-Komponentenversion:
· Wählen Sie die Software-Komponentenversion entsprechend der Auslieferungsstrategie.
· Oft gibt es innerhalb eines Integrationsszenarios ein führendes Produkt (z.B. SAP APO), welches das Integrationsszenario definiert und organisatorisch verantwortet. In diesem Fall sollte das Integrationsszenario einer geeigneten Software-Komponentenversion dieses Produkts zugeordnet werden.
· Es ist aber auch möglich – wenn dies auslieferungstechnisch so gewollt ist – das Integrationsszenario einer Software-Komponentenversion zuzuordnen, die einem anderen Produkt oder gar keinem der verwendeten Produkte entspricht.
Granularität von Integrationsszenarien
Integrationsszenarien können in verschiedenem Umfang und Detaillierungsgrad dargestellt werden. Dies ist zunächst eine Modellierungsentscheidung.
Beachten Sie dabei die folgenden Aspekte:
· Das Integrationsszenario sollte einen betriebswirtschaftlich sinnvoll abgeschlossenen Prozess bzw. einen gut abtrennbaren Teil eines Prozesses repräsentieren.
· Das Integrationsszenario wird als Ganzes in die Konfiguration überführt. Verschiedene Teilprozesse sollten damit nur dann zu einem Integrationsszenario zusammengefasst werden, wenn stets alle Teile zusammen konfiguriert werden müssen.
· Das Integrationsszenario sollte eine Größe nicht überschreiten, die für einen Benutzer noch verständlich ist.
· Sinnvoll abgeschlossene Teilprozesse am Beginn oder Ende eines Integrationsszenarios können Sie unter Umständen in ein eigenes Integrationsszenario ausgliedern. Dies ist vor allem dann interessant, wenn ein solcher Teilprozess in mehreren Integrationsszenarien vorkommt (Wiederverwendung und Komplexitätsreduktion).
· Berücksichtigen Sie eventuell vorhandene Modellierungsergebnisse im Solution Manager bzw. im Business Process Repository.
Definition unterschiedlicher Component Views
Sie können für ein Integrationsszenario unterschiedliche Component Views definieren. Beachten Sie folgende Richtlinien für die Definition unterschiedlicher Component Views:
· Bilden Sie unterschiedliche Varianten eines Integrationsszenarios durch unterschiedliche Component Views ab.
Für das Demo-Integrationsszenario SingleFlightBooking sind folgende Varianten definiert: Kommunikation über die Proxy-Laufzeit und Kommunikation über die Adapter-Laufzeit. Beide Varianten werden durch unterschiedliche Component Views abgebildet (siehe Einzelflugbuchung).
· Bilden Sie unterschiedliche Releasekombinationen (für Produktversionen von Anwendungskomponenten) in unterschiedlichen Component Views ab.
Einbinden von Ausführbaren Integrationsprozessen (ccBPM)
Wenn Sie in das Integrationsszenario einen ausführbaren Integrationsprozess (cross-component Business Process Management) einbinden wollen, beachten Sie folgende Richtlinien:
· Verwenden Sie für den Integrationsprozess eine eigene Anwendungskomponente. Verwenden Sie genau eine Anwendungskomponente pro Integrationsprozess.
· Der Integrationsprozess muss in der Software-Komponentenversion implementiert sein, die auch der Anwendungskomponente entspricht.
· Modellieren Sie nur die Actions, bei denen komponentenübergreifende Kommunikation zwischen dem Integrationsprozess und den anderen Systemen stattfindet. Modellieren Sie nicht den Ablauf des Integrationsprozesses im Integrationsszenario nach.
· Eine Action repräsentiert einen oder mehrere Prozessschritte des Integrationsprozesses „nach außen“. Diese Actions sollten daher nicht zusätzlich in anderen Anwendungskomponenten, sondern ausschließlich in der Anwendungskomponente des Integrationsprozesses verwendet werden.
Modellierung von Business-to-Business (B2B)-Kommunikation
Sie können in einem Integrationsszenario eine Anwendungskomponente als externen Geschäftspartner mit B2B-Kommunikation (kurz: B2B-Komponente) klassifizieren. Hierdurch geben Sie für diese Komponente B2B-Kommunikation vor.
Um eine Anwendungkomponente als B2B-Komponente zu klassifizieren, markieren Sie bei der Bearbeitung der Anwendungskomponente unter Kommunikationstyp das Ankreuzfeld Externer Partner mit B2B-Kommunikation.
Verwenden Sie als B2B-Komponenten nur Anwendungskomponenten vom Typ Vorlage.
Diese Informationen werden verwendet, wenn Sie das Integrationsszenario als Vorlage für die Konfiguration verwenden. Bei der Generierung der Konfigurationsobjekte werden dann bestimmte B2B-spezifische Einstellungen vorkonfiguriert. Hierzu gehören:
· Header-Mapping
· Virtueller Empfänger
· Business-Service
Siehe auch: