Interface Objects

Service Interfaces, Operations and Message Types

As interface objects also encapsulate each other (as illustrated in the figure above), a top-down design approach is also feasible, starting with the definition of a service interface.

A service interface represents a set of functions that is either provided by an application (inbound service interface) or used by an application (outbound service interface). You can consider the set of functions a service interface represents as a subset of the functions implemented by a process component. However, a service interface in the ES Repository contains merely the metadata of a service, abstracted from any implementation details.

Service interfaces are based on Web Services Description Language (WSDL), an XML-based language for describing Web services and how to access them. However, when you create interface objects in the ES Repository, you do not need to be familiar with the syntax of WSDL because you can use the relevant editor to specify the interface attributes.

The Category service interface attribute determines whether the service interface is an outbound or an inbound service interface.

A service interface groups one or multiple operations. An operation represents the smallest, separately-callable function, described by a set of data types used as input or output. You can specify the Communication Mode for each operation. This attribute determines if the communication defined by the operation is synchronous or asynchronous. In a synchronous communication step, a response is expected for each call or request message that is sent out. In an asynchronous communication step, a request message is sent out but no response is expected.

You assign one or multiple message types for each operation - depending on the communication mode.

A message type defines the root element of a message. You use a message to exchange data between systems. A message type refers to exactly one data type that defines the structure of this data.

For a synchronous operation, you assign three message types: A request, a response, and a fault message type. A fault message type represents the message that is expected in case an error occurs. For an asynchronous operation, you only assign one request message type. The following figure shows the role the different interface objects play for the message exchange as designed based on the process model (shown above). The example shows an asynchronous message exchange where a request message is sent from the service consumer to the service provider.

The following figure shows a synchronous message exchange including a request and a response message being defined for the service interface operation:

In a lot of scenarios, the application forces that a specific communication sequence and transactional behavior is maintained during message exchange. With the attribute Interface Pattern you can design this behavior in the ES Repository. An interface pattern describes the type of communication that is to be executed on the message when the interface is used. It determines what kind of operations can be defined for a service interface. The interface pattern that you select has an impact on the activities related to the programming of the business logic in the related back-end system (task of application developer).

More information: Service Interface

Data Types

A data type determines the data structure for a specific business entity, for example, an address. Data types are referenced by message types and therefore define the structure of a message.

As defined in the ES Repository, data types are based on XML Schema (also referred to as XSD ). Data types can reference other data types which enables you to build up complex data types out of simpler ones. The basis for all data types are XSD types contained in XML schema and approved by W3C, (for example, xsd:string, xsd:decimal, xsd:integer). These data types define the properties of an element at a technical level.

More information: Data Types in the Enterprise Services Repository

External Definitions

If you would like to reuse existing XML definitions as message definitions described in either WSDL or XSD, you can import these XML definitions into the ES Repository, rather than re-enter them manually using the data type editor. You then encapsulate the imported definition in the form of an external definition.

Context Objects

With a context objects, you can specify an XPATH expression that can be used to access a field in an XML message.

These expressions can then be used at configuration time to configure content-based routing and in integration processes (ccBPM)

More information:

• Context Objects

• Routing

Imported Objects

If you would like to reuse XML definitions of existing functions - RFCs or IDocs - so that you can call these functions using the Integration Server, you can import IDocs and RFCs into the ES Repository and make the interface signature known there.