Central Business Scenario Configuration

Central business scenario configuration is used in closed ABAP landscapes where provider and consumer systems are controlled by a central ABAP system for Web service configuration. It allows configuration of connections between consumer and provider systems and supports consumer driven configuration of provider as well as provisioning of provider configurations for external systems.

In central business scenario configuration there is one dedicated ABAP system which is marked as the central system. All systems that want to participate in central configuration will have to set up a management connection to the central system and thus pass control to the central system. With this management connection, the central system can create, update and delete Web service configurations on the domain systems.
During the set up of the management connection, in the managed systems, the design time information of service defnitions, consumer proxies and service groups are read and locally stored in a design time cache. This information is then transferred to the central system so that valid configuration request are supported there.
In the central system, a domain system is automatically created once the management connection is set up. The domain system combines the meta data access data with the technical connection to the backend system and is part of one or more domains.
With the creation of domains the domain systems are assigned to domains and build a valid numer of systems for which web service configuration is possible with certain security settings.

In a central business scenario configuration, the following entities are used in the central system:

Domain Systems

Domain systems are used in central business scenario configuration to represent systems that are configured centrally. The domain system is only present in the central system, and it carries information needed to retrieve metadata of the represented system like WSIL service URL, Services Registry identifier and deployed Business Applications.
Within one central system, a domain system can be assigned to one or multiple domains. Domains group domain systems that share the same security and proxy settings. For each domain system and each possible provider system the common domain with the highest priority is calculated.
The profile name (with the same name as the domain) and version is used to find the bindings exposed for the domain systems in the domain during consumer configuration.

Domains

Are used to group domain systems which are allowed to establish web service communication between each other using the same set of security and proxy settings.
These settings are stored in versioned profiles generated from the domain with the same name. Hence multiple profile version can exist with one domain.
Profile versions are used to support change management and are controlled by the change processor.
Web service communication between two domain systems can only be established in case these system share at least one common domain. If both domain systems share multiple common domains
the domain priority is used to determine the effective domain.

Domains and domain systems are typically maintained by the technical system administrator who knows best about system landscape, security and proxy settings.

Logon Data & Assignment

During automated consumer configuration logon data is used to provide the required credentials (username/password or PSE) and preferred authentication method to the consumer system.
The allowed authentication methods are specifed by the provider configuration. The credentials must be valid for the provider system and the addressed application.
Therefore logon data can be assigned to a business application on a provider system. This assignment can addtionally be restricted by speciyfing a Web service interface and/or service group.
This allows to use different authentication methods and credentials for different interfaces in the same provider system.
If no logon data is specified for a provider system, Single Sign-on gets used as default (if the provider configuration supports this authentication method).

Central Business Scenario

A central business scenario is used to define connections between domain systems by specifying the service group used in the consumer system. The assigned consumer proxies of the service group are then assigned to the compatible provider interfaces on the provider system. Only if there are multiple compatible provider interfaces for a consumer proxy, the business administrator has to choose the interface used between the consumer and provider system. The assignment is stored as central matching interface in the central system and can only be changed in the corresponding application.
Furthermore provider side configurations can be defined in central business scenarios to support consumer systems which are not configured in central configuration as these consumer systems
are e.g. not part of any defined domain or are non-ABAP Systems. In the provider system for each active profile version distributed by central system, a provider configuration is created.
The profile versions are controlled by the change processor.

Matching Interfaces

Are used in a central system to assign the preferred service interface to a consumer proxy of a service group for a consumer provider system combination. This assignment can be created in matching interface application or during maintenance of a business scenario.

Central Design Time Cache

The central design time cache is used in the central system to store which service interfaces, consumer proxies and service groups exist in the backend systems. This is necessary as the central system may not have all the design time objects present because not all business applications (e.g. CRM, SRM, ByD, ERP, eWM, BW) are installed in the central system. For example, a central system may be a plain SAP NetWeaver system where the design time objects are not present. Furthermore the central design time cache is able to check compatibility between service interfaces and consumer proxies
and additionally between service interfaces and service groups. The central design time cache information of a design time object is updated in the central system after a design time change in the backend system.
The cache can also be updated manually by a program in the backend system and transferred to the central system. For more information, see the #Troubleshooting section below.

Change Processor

The change processor is used in the central system to control the central configuration process. Once the required information is maintained by the technical and business administrator in the central system, the change processor has to be started by an administrator.
The change processor devides its tasks into four phases:
#1. Necessary modifications are calculated and transferred to the managed systems.
#2. New provider configurations are created in the managed systems.
#3. New consumer configurations are created in the managed systems.
#4. Obsolete consumer and provider configurations are removed from the managed systems.
As the change processor transfers the configuration relevant information as a whole to all backend systems, it can be restarted at any time.
For each backend system each phase has its own task which provides all data necessary to complete the task. Furthermore the result of task processing is reported in the central system. The results are stored in the central system until a new configuration process is started by an administrator.

The entities from the central system are converted into the backend systems as follows:

Domain

The security and proxy settings of the domain is transfered as a profile version of the same name to the assigned backend systems.

Domain Systems

The domain system information is transfered as provider system entity to the backend systems enriched with the profile name and version used to find the relevant bindings.

Logon Data

The logon data is transferred without modification to domain systems which have to configure logical ports with authentication methods where credentials are really necessary.

Business Scenario

For each domain system the relevant parts of the central business scenarios is extracted and stored in one business scenario named CENTRAL_SCENARIO.

Connections

The maintained connections in the scenario are split into provider configurations requests and consumer configuration requests.
These provider configuration requests are enriched with the profile name of the calculated common domain between the consumer and the provider system.

Provider Configurations

The provider configuration requests of the scenario create one provider configuration request for each domain the domain system is assigned to as profile of the same name.

• How to create a Management Connection to a central system
• How to create a Domain in Central SOAManager
• How to manually create a Domain System in Central SOAManager
• How to create and process Central Business Scenario Configuration
• How to create and assign Logon Data
• How to use Technical Receiver Determination
• How to use Logical Receiver Determination