Describing the Scenario 

The Business Process

A business process consists of a series of individual business functions. The content of the business process should be described separately from any technical details.

Creating a sales order in an affiliate with a credit standing check in the central organization.

To define a business process you have to:

Define the purpose and the scope of the business process

Identify the individual steps in the business process. To do this you can use a process model or the tool "Use Cases".

The Scenario

A scenario is the computerized implementation of a business process. It describes the distribution and interaction of the tasks between the participating components. So there may be several scenarios that implement the same business process.

Creating sales orders and credit standing checks in different R/3 Systems (central accounting, decentralized sales and distribution).

The process of defining the scenario involves:

Identifying the relevant components and the tasks they perform.

Determining whether application systems are to be integrated in the scenario or other frontends are to be connected. This can affect the granularity of the steps, for example.

Determining the information and process flows. Here you have to:

 

Determine which steps are to be processed system-wide and which steps are to be processed within a single component.

 

Define which data is exchanged between which components and who initiates this exchange.

 

Determine the sequence in which the individual steps are processed.

 

Identify the steps belonging to a single transaction (LUW).

Example : Developers must ask themselves whether it makes sense to create a customer in one LUW and then create a sales order in the same LUW .
See also Transaction Model for Developing BAPIs

 

Error handling must be much more precise and comprehensive than with local applications.

You have to decide whether system coupling should be narrow or loose for the scenario. You should consider factors such as system availability and performance and how often the scenario is used.

All steps critical to performance must be identified.

You should also consider which R/3 Releases are to be supported within the scenario.

For each scenario you must identify a person responsible for ensuring that the scenario is correct and up-to-date.

Business Object Types and BAPIs

Each component in the scenario must provide services so that the cross-component steps can be carried out. You have to work out how to distribute responsibility for the services between the business object types and their BAPIs. For example, the BAPI CreateFromData of business object type SalesOrder is used to create a sales order in the R/3 System from an external application.

For more information see also: Business Object Types.

For each component you have to first determine the business object types required. You should consider the following issues:

Encapsulation of the required functions in business object types. This involves breaking down the whole system into separate responsibilities. The breakdown and encapsulation of functions must be explicit and disjunctive.

Do business object types already exist for these responsibilities?

Do design patterns already exist?

Find out whether any problems have already been dealt with.

Example : Header/item pattern, for example, for SalesOrder, PurchaseOrder, etc.

Delimit the responsibility for other business object types.

Determine the services provided based on the defined responsibility.

For more information see also: Design Criteria for Business Objects.

For each business object type you have identified, you have to determine how the services assigned to it can be implemented using BAPIs.
You should consider the following issues:

Each service is implemented by one or more BAPIs (= method of business object type).

BAPIs make available the functions of a business object type. You should be able to use them independently of individual scenarios and also in different scenarios.

To make it easier to use a BAPI in different scenarios, the BAPI signature should be created so that the BAPI's parameters and fields are assigned separately according to the application.

However, this type of scenario can affect the granularity of the BAPI. Application systems are integrated differently from the integration of alternative frontends:

1. Integrating application systems

  • The integration of application systems typically involves program-to-program communication, loose asynchronous coupling and the exchange of larger volumes of data.
  • The main requirement of the business object types and BAPIs used in these scenarios is that performance is high, for example, by minimizing the number of calls.
  • The result is a rough granularity of the application that is implemented by more extensive BAPIs.
  • Example : A program to create a sales order automatically.
    The program uses the business object type SalesOrder with the BAPI CreateFromData. The complete sales order is created in the sending system and then sent to the receiving system.

2. Integrating alternative frontends

  • Scenarios with alternative frontends represent human-to-machine communication and can be implemented synchronously as well as asynchronously .
  • Business object types and BAPIs must be structured to ensure flexibility, configurability and minimal error situations.
  • The result is a finer granularity of the application that should correspond to the dialog processing in R/3.
  • Example : Customer sales order is created interactively in the Internet.
    The sales order is can be created using the two methods CreateFromData and AddItem of the business object type SalesOrder. In this case the method CreateFromData simply creates the sales order header, whilst the method AddItem can add new sales order items.

SAP Internal :

Wherever possible, a BAPI should be created so that it can be used for both purposes. The most important objective is to develop a range of standardized BAPIs for each business object type which can be used universally.

The scenario must be structured so that it is possible to get all the information required for a BAPI call from the R/3 System from other BAPIs beforehand.

If there are any BAPIs that are Customizing-dependent, BAPIs must be provided that can export these Customizing settings.

 SAP Internal

The scenario, the link to the application's object model and the design of new business object types is agreed with one of the BFA Application Groups.

If business object types that do not yet exist are identified during the analysis phase, these object types can only be created by the BFA AGs. You have to create a request for a new business object type in the BAPI Explorer.

For examples of BAPI scenarios refer to Overview of ALE Integration Scenarios in the Library of ALE Business Processes.