Modeling Process Integration Scenarios -
General
Name
The name of a Process 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 Process Integration Scenario must have a meaningful 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 Process 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 Process 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
You must assign a software component version to a Process Integration Scenario when you create it. This assignment defines the software component versions that are delivered to the customer with the Process Integration Scenario (as a design object of the Enterprise Services 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 a Process Integration Scenario that defines it and takes organizational responsibility. In this case, the Process Integration Scenario should be assigned a software component version that is appropriate for this product.
● However, it is also possible to assign the Process Integration Scenario to a software component version that corresponds to another product or to none of the products used, if required.
Granularity of Process Integration Scenarios
Process 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 Process Integration Scenario must represent a whole business process or clearly defined part of a process.
● The Process Integration Scenario is transferred as a whole to configuration. Different sub processes must therefore only be grouped together for a Process Integration Scenario if all parts are always to be configured together.
● The Process 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 a Process Integration Scenario can possibly lead on to separate Process Integration Scenarios. This is particularly interesting if a sub process of this type occurs in multiple Process 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 a Process Integration scenario. Use the following guidelines when defining different component views:
● Create different variants of a Process Integration scenario by using different component views.
The following
variants are defined for the demo Process 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 Process 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 Process 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 a Process 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 Process
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: