4.3    Data Types and Message Types

Service interfaces consist of message types and data types, which define the information they carry from sender to receiver. Fault message types are a special variety of message type designed to help you handle interface errors triggered at the application layer. Those are exceptions that may occur on the inbound side and that are reported back to the sender or persisted in the SAP PO monitoring layer.

Service interfaces, data types, message types, fault message types, and external definitions are all commonly referred to as interface objects.

4.3.1    Data Types

Data types are used to describe the internal data structure of a message type, which in turn is used to define the structure of a service interface. Data types can be reused in different messages types inside the same SWCV as well as in other SWCVs across the ES Repository. To enable that functionality, you have to make sure that all necessary SWCV dependencies have been previously configured in the SLD.

The following data types are supported in the ES Repository:

• Core and aggregated data types
  Core and aggregated data types are based on the Core Components Technical Specification (CCTS) and are the basis for application-specific data types accepted across several industries.
  For example, address is considered to be an aggregate data type, and any field of an address, such as city, is considered to be a core data type.
• Freestyle data types
  Freestyle data types are those you design, create, and maintain yourself with the aid of the data type editor in the ES Builder. They are based on the primitive data types and are self-descriptive (e.g., string, integer, Boolean, etc.).

4.3.2    External Definitions

An external definition in the ES Repository is an imported message structure that describes either an entire message or a part of it. An external definition can be imported as a WSDL, XML Schema Definition (XSD), or Document Type Definition (DTD). After a successful import, you can decide which part of the external definition you want to assign to the service interface definition (i.e., request, response, or fault).

Note

Currently, there are some limitations in terms of the XSD features supported by external definitions in SAP PO. An important one prevents making use of the XML choice element used in XSDs. The following example shows an element named "entity", which must contain either a "company" element or a "person" element:

<xs:element name="entity">
  <xs:complexType>
    <xs:choice>
      <xs:element name="company" type="company"/>
      <xs:element name="person" type="person"/>
    </xs:choice>
  </xs:complexType>
</xs:element>

4.3.3    Message Type

A message type encapsulates a data type that describes the structure of a message of a service interface at the operation level. The message type defines the root element of a message and describes an instance of a message to be exchanged. Message types describe the root element of the request, response (only for synchronous service interfaces), and fault messages of a service interface. You can reference the same message type in different service interface operations and also in different service interfaces across the ES Repository. A message type is direction agnostic; in other words, it doesn’t define whether you should use it for the request or response part of your service interface. In fact, you can use the same message type for both the request and response messages.

A fault message type is a special message type that is used to carry application-specific error information about technical or functional errors that occur while processing an inbound request. The information is generated on the service provider side and is passed back to the service consumer that expects the response. Fault message types are only intended to be applied in synchronous service interfaces in principle; therefore, you can’t assign fault message types to asynchronous operations of outbound service interfaces. When an ABAP or Java proxy is generated from a service interface that contains a fault message type, an exception class is also generated for the fault message type. This exception class is used to handle application errors at runtime.

A fault message type is made up of two parts: a mandatory standard data part and an optional additional data part:

• Standard data (mandatory)
  This data part is used to return the fault message standard information for an error during runtime. All fault message types reference the data type ExchangeFaultData for this part and, indirectly, the data type ExchangeLogData. These data types are automatically created when you create the first fault message type in a namespace.
• Additional data (optional)
  Use this data part to attach any additional application-specific information to the fault message. To do so, reference any data type in the same SWCV or in a sub-SWCV.

4.3.4    Additional Design Objects

So far, we’ve only concentrated on the most commonly used design objects in integration scenarios. However, the ES Repository has more features to offer, which are provided by additional design objects that support specific functionality for different purposes. Table 4.3 provides a quick overview of these remaining objects.

Name	Description
Modeling
Model	Supports a model-driven approach applying a top-down development strategy. Start design time in the ES Repository by modeling the process components and their corresponding data objects first and then the service interface objects.
Object definition	The data objects used by the model and the process components it contains. Each business object belongs to exactly one process component.
Interface objects
Imported object	IDoc, BAPI, or RFC interface that exists on an SAP backend system and is imported into the ES Repository.
Data type enhancement	Provides a flexible and easy way of enhancing existing data types that are part of standard SAP business content, such as Enterprise Services provided as ABAP proxies.
Context object	Used as abbreviated expressions for XPath expressions to address specific payload elements. Context objects are used in routing conditions.
UI text object	A UI text object has a text category, with which you specify the use of the text created. You can use text objects of the Field Label category in data types.
Adapter objects
Adapter metadata	Allows you to define configuration data needed for a certain type of adapter at design time. Adapter metadata defines the part of a communication channel that is specific to the adapter type.
Communication channel template	Used to preconfigure a communication channel and to define a communication channel at configuration time. In this way, all communication channels can follow strict rules (and save configuration time), as configured in the template. This is extremely useful when you’re using adapter modules or the Apache extensible Interaction System (Axis) framework configuration.
Version creation
Change list	Used to create your own change lists in advance and organize changes made to design objects.
Work areas
Usage profile	Offers personalized filters based on the user role and/or preferences. System administrators can predefine a set of design objects, SWCVs, and business modeling filters for developers to select from. All the other design object types remain hidden.

Table 4.3    Additional Design Objects in ES Repository