Show TOC

Procedure documentationModeling Guide for model types in the ES Repository Locate this document in the navigation structure


A model-driven development of services is an important aim of service development in a service-oriented architecture for business applications (Enterprise SOA). To this end, the Enterprise Services Builder (ES Builder) offers a modeling environment where you can create various models in the Enterprise Services Repository (ES Repository).

A model-driven service development provides the following advantages:

  • A process should be part of a model-driven process whereby services of new applications are adapted in cooperation with other development departments. No more design objects are created for a model that has not yet been approved. In this way, the model acts as a basis for discussion until it is released for use as a template.

  • Depending on the modeling, you can work out which design objects are necessary in the ES Repository for your application.

  • Interface patterns in the modeling ensure that services are always defined and named in the same way. In particular, interface patterns determine the granularity of services (Service Cut).

  • Finally, the different models are a good way of documenting the whole process of an application and make it easier to enhance software later.

Note Note

SAP already works internally with the modeling environment, including a unification and standardization process (Governance Process), to increase the level of reusability. SAP delivers the models that were produced by this process as ESR content to aid the understanding of the SAP application.

End of the note.

This section focuses on the principles of modeling and in addition, the various model types and interface patterns are introduced. SAP recommends that customers conform to these principles when they create their own models.


Familiarize yourself with the Basics of service modeling before you begin with the actual modeling.


The process component is a central modeling object with which you describe part of the value chain of a business application. The different model types each concentrate on specifically defined aspects of process components so that you can understand the whole process from different angles. To model the process, proceed as follows:

  1. Each process component describes a unique part of the value chain. First of all, use the process component model (SAP ProComp model) to model which data the process component works with and which service interfaces are to be offered.

    More information: Modeling the Interfaces of a Process Component (Provider View)

  2. Since a process component is often only one part of a value chain, there are normally interactions with other process components. To show these interactions, work with the integration scenario model (SAP integration scenario model).

    More information: Modeling the Integration of Process Components

  3. Based on the results of the last steps, use the process component interaction model (SAP ProComp interaction model) to model specifically the message exchanged between two process components.

    More information: Modeling the Interaction Between Two Process Components.