Name
The name of an integration scenario is unique (within its namespace). This name is not language-specific. Special characters and blanks are not permitted.
Note the following conventions for names:
· The integration scenario must have a meaningful business name. The name should be written in English so that it is globally understood.
Separate individual words by switching between uppercase and lowercase characters (see the notes on naming conventions for design objects under Creating New Objects).
Example: SingleFlightBooking
Description
The description is language-specific and gives more details about the integration scenario.
Note the following conventions when writing the description:
· Create the description in English. Ensure that the original language is English.
If required, you can enter a description in German as well. In this case, ensure that the original language is German.
· Use the (technical) name of the integration scenario. If you create the description in the original language English, write the individual parts of the name separately.
· Do not write complete sentences.
· You can write a maximum of 250 characters. Abbreviate where appropriate, if applicable.
English example: Single flight booking.
German example: Einzelflugbuchung
Assignments to a Software Component Version
When you create an integration scenario you must assign it to a software component version. This assignment defines the software component versions that are delivered to the customer with the integration scenario (as a design object of the Integration Builder).
Note the following aspects when selecting a software component version:
· Choose the software component version according to your shipment strategy
· Often there is one leading product (for example, SAP APO) within an integration scenario that defines it and takes organizational responsibility. In this case, the integration scenario should be assigned a software component version that is appropriate for this product.
· However, it is also possible to assign the integration scenario to a software component version that corresponds to another product or to none of the products used, if required.
Granularity of Integration Scenarios
Integration scenarios can be represented in varying degrees of detail and scope. This is foremost a decision to be made during modeling.
Note the following aspects:
· The integration scenario must represent a completed business process or clearly defined part of a process.
· The integration scenario is transferred as a whole to configuration. Different sub processes must therefore only be grouped together for an integration scenario if all parts are always to be configured together.
· The integration scenario must not become so large that it ceases to be comprehensible for the user.
· Completed sub processes at the start and end of an integration scenario can possibly lead on to separate integration scenarios. This is particularly interesting if a sub process of this type occurs in multiple integration scenarios (enables it to be reused and reduces complexity).
· Take into account any existing modeling results in the Solution Manager or Business Process Repository.
Defining Different Component Views
You can define different component views for an integration scenario. Use the following guidelines when defining different component views:
· Create different variants of an integration scenario by using different component views.
The following variants are defined for the demo integration scenario SingleFlightBooking: communicating using the proxy runtime; communication using the adapter runtime. Both variants are represented by different component views (see Single Flight Booking).
· Create different release combinations (for product versions of application components) in different component views.
Including Executable Integration Processes (ccBPM)
If you want to include an executable integration process (cross-component Business Process Management), use the following guidelines:
· Use a separate application component for the integration process. Use exactly one application component for each integration process.
· The integration process must be implemented in the same software component version as the application component.
· Only model actions for which there is cross-component communication between the integration process and other systems. Do not model the process flow of the integration process in the integration scenario.
· One action represents one or more process steps of the integration process ‘to the outside world’. For this reason, do not use these actions in any other application components except the application component of the integration process concerned.
Modeling Business-to-Business (B2B) Communication
In an integration scenario, you can classify an application component as an External Business Partner with B2B Communication (B2B component for short). B2B communication is then specified for this component.
To classify an application component as a B2B component, when editing the application component, under Communication Type, select the checkbox External Party with B2B Communication.
Only use application components of type Template as B2B components.
This information is used when you use the integration scenario as a template for configuration. Certain B2B-specific settings are then preconfigured when generating the configuration objects. These are for example:
· Header Mapping
· Virtual Receivers
· Business service
See also:
Configuring B2B Scenarios
No comments:
Post a Comment