Show TOC

Background documentationBasics Locate this document in the navigation structure


Modeling as Abstraction from Design and Implementation

The aim of modeling is to model business process flows. The model helps you to understand and then to implement the process flows or to enhance an implementation that already exists.

Although a company's software is tailor-made for the needs of that business, the fundamental business process flows do not vary that much. It is possible that there are many implementations for a process flow in a business and for the same business area but with a different focus. The data and the fundamental process flows are however often the same.

For this reason it makes sense from the beginning to introduce a level of abstraction to the modeling that is removed from the details of implementation. The same modeling object (the “process component”) is always used for the same business process flow, irrespective of how many different implementations there will be in a specific system landscape. The data for each process flow is modeled using “business objects”. The following sections deal with this in more detail.

Abstractions from Data Using Business Objects (BOs)

SAP uses BOs to describe the data of an application. The fundamental idea is that a clear distinction between the data of different business areas contributes to a good modeling of the business processes. Many questions relating to modeling can be answered by the modeling of business objects. Business objects are therefore the central point of the principles used by SAP and form the foundation for the definition of services.

Note Note

An alternative approach to services modeling could be the perspective that is more oriented towards the exchange of messages. The message choreography is, however, only designed for an original use case. It has proven that the felicitate of services can be drastically reduced by this. It is for this reason that SAP always defines services from business objects.

End of the note.

To be able to use BOs effectively for multiple use cases, you must model them in such a way that you avoid overlaps with other BOs. For example, product data should not be part of an order, but rather modeled in a separate BO. In this way the BO for product data can then be used for other use cases.



Business Object (Business Object)

A business object (BO) represents a specific view of data of a well-defined and outlined business area. BOs are identified in such a way that there are no overlaps.

Of course, the character of the data that is described by a BO also plays an important role in modeling. An important characterization is the difference between transaction data and master data:

  • BOs that work with transaction data ( that is, data that is only important for a short period of time during a business process) are also called “business process objects”.

  • BOs that work with master data (data that is needed over a longer period of time) are called “master data objects”.

Aside from this characterization of the BOs you can also use the BO as a template for a whole series of BOs. For example, a business partner can be either a customer or a supplier and the data, with which either the customer or the supplier is described, is the same. If you consider beforehand a “business object template” from which the customer and supplier can be projected, then you avoid an inconsistent definition of the same data.

In short, the data that needs to be accessed (and in turn, the BOs) are the central points of the modeling: services always access data, therefore the modeling of services is intrinsically linked with the modeling of business objects. A well thought-out and consistent identification of BOs leads to a good modeling of services.

Abstraction from Implementation Using Process Components

In ARIS models, SAP works with process components to identify a self-contained part of a value chain. The business relevance of a process component is not designed just for SAP, but is cross-company. This is particularly crucial for implementation later of B2B processes.

Note Note

You can also model process components of business partners or third parties. More information: Integration Scenario Model.

End of the note.

From the meeting view, a process component is a shell where data, and services for accessing this data, are contained. Since data can be modeled using business objects, one or multiple objects belong to exactly one process component and in this way determine the data of a business area. In this way process components form reusable modules of (possibly multiple) larger applications.



Process Component (Process Component)

Process components describe the part of a value chain that is normally (in large companies) performed in a department.

Process components group business objects (BOs). A BO belongs to exactly one process component.

One difficulty with the definition of process components is the level of granularity. In other words: With regard to the data and the process to be modeled, you must decide whether to introduce one or multiple process components . Actually, the modeling of data using one or multiple BOs is closely connected to the modeling of process components. If, for example, different departments access different data of a BO, then this is a sign that the BO does not cover a self-contained business area and that actually you need two separate BOs. It therefore makes sense in such cases to spear the related process components into two process components. There can however also be cases where a process component covers two BOs where one BO describes data that complements the data of the other BO.

Accessing Process Component Data

If the level of granularity of the data and the partitioning of the value chain process that is to be modelled is clarified in process components, then you can specify the access to this data in the modeling. There are two types of access:

  • “Asynchronous Accesses” are the means for choosing either an A2A or a B2B communication.

  • “Synchronous Accesses” depend mainly on other components of the same application (for example: access from the UI or other client to data).

The accesses are modeled by service interfaces and operations that access BOs either synchronously or asynchronously.



Operation (Operation)

An operation is assigned to exactly one BO. Each BO can have more than one operation.

Service interface with two operations. (Service interface with two operations.)

A service interface groups operations.

You derive the service interfaces and operations that are necessary for access from the access type. There are some standard variations for synchronous asynchronous access that cover the majority of use cases. For each variant SAP works with an interface pattern from which service interfaces, operations and message types are directly derived in the modeling and which are always modeled in the same way:

  • For communication between process components there is an A2A interface pattern (that can also be used for B2B communication). Accesses of this type are normally asynchronous.

  • There is also an A2X interface pattern for accesses from UI components or other clients to data (“X” stands for 'any'). At this time SAP models accesses of this type only synchronously.

From Modular Process Components to Installable Units

Until now modeling process components has been the main focus of this chapter, irrespective of whether they are executable independently from other process components or not. This aspect is particularly important for the question: which process components are to interact with each other and how? An important question for the communication method between two process components is: which process components must be installed together on to a system so that they can be executed later? SAP uses “deployment units” to show these dependencies in the modeling.



Deployment Unit (Deployment Unit)

Groups all process components that will later be installed together on the system. To enable these process components to run, it is sometimes necessary to configure the process components of other deployment units, even if this is not ideal.

This graphic is explained in the accompanying text.

Overview of the Most Important Modeling Objects

Overview of Model Types

The following are the most important model types:

  • Process Component Model (SAP ProcComp model)

    Use this model to describe the inner workings of a process component: which business objects are needed for the data and which service interfaces and operations are to be used to access them.

  • Integration Scenario Model (SAP integration scenario model)

    Use this model to describe which process components belong to which deployment units and how the process components interact with each other.

  • Process Component Interaction Model (SAP ProcComp interaction model)

    Use this model to describe the communication between two process components.

Aside from these model types, there is also the business object map or business object template map (accessed using the SAP entity map model type) and the integration scenario catalogue (accessed using the model type SAP Scenario Catalog).

Business object maps or business object template maps aggregate business objects or business object templates in a model for overview purposes. In this way you can, for example, determine all those models that have been created and that are for a BO and you can create statistics and analyses. The following figure provides an example:

This graphic is explained in the accompanying text.

BO Map of the SAP Business Suite as Example of an SAP Entity Map

Integration scenario catalogues group and structure all the integration scenarios of a solution and therefore represent the businesss starting point for process modeling. You can navigate from an integration scenario catalogue to the relevant integration scenario models. To group integration scenarios together within an integration scenario catalogue, use the integration scenario group (integration scenario group) as a grouping element. The following figure provides an example:

This graphic is explained in the accompanying text.

Example of an Integration Scenario Catalogue with Two Integration Scenario Groups