SAP NW PI provides content with the interfaces of enterprise services for Enterprise Services Repository. You can also define new interfaces for enterprise services in the Enterprise Services Builder.
Data types are the basic components of interfaces. Data types define simple or complex XML data structures, which can be created in a data type editor or imported.
With SAP NW PI, you determine the structure of data types based on their classification. There are three types of data type:
• Freely-modeled data types
• Core data types
• Aggregated data types
SAP uses core data types and aggregated data types to create the signature of enterprise services.
The modeling of core data types (CDT) and aggregated data types is based on the UN/CEFACT Core Component Technical Specification, or CCTS for short (see also ISO 15000-5). This methodology formulated by the UN/CEFACT Committee defines semantic modules (core component types) independently of syntax, which take account of the current requirements for the generic description of business data. The implementation of this methodology facilitates, in particular,
For internal use by CSC only For internal use by CSC only
TBIT40 Lesson: Design Objects in the SLD and Enterprise Services Repository
the realization of cross-company processes. In SAP, a CDT defines a “primary component” (also referred to as a “content component”) and one or more optional “supplementary components”. The character of a CDT is defined using a “representation term” (for example, “Amount”). Unlike Free-Style data types, core data types also contain additional information about the semantics of a data type. SAP currently identifies 25 representation terms for core data types (for example, Amount, Text, Identifier, Date, Time, Name, Description).
Caution: The representation term of a core data type defines semantics for a more accurate characterization of the data type, but does not yet define business-relevant semantics with a specific reference to business processes. For example, the characterization of a data type with the
“Amount” representation term indicates directly that the value of this type must also be specified more precisely with a currency. This type of mandatory characterization does not apply to free modeling of this category of data type as an XSD type (for example, xsd:decimal).
The actual business semantics are contained in the Global Data Types (GDT).
Global Data Types are based on CDTs, and are used across SAP as a basis for application-specific data types. However, in contrast to last category of data type described above, they are not intended for a specific usage. On the contrary, a GDT is designed to be reused later in many different application scenarios. These data types are therefore rather “broad”, and need to be refined when they come to be used in a specific application. CDTs themselves are not application-specific, and are therefore also described as “context-free”. SAP creates a GDT as a core data type or aggregated data type in Enterprise Services Repository. This depends on whether the CDT merely enhances a CDT with business semantics, or whether CDTs (and any aggregated data types that may already exist) are used in a new, aggregated data type.
Note that all data types contained in your Repository PI 7.0 or lower are classified as Free-Style data types in the upgrade.
Hint: ES Repository was named Integration Repository in older PI releases.
Freely-modeled data types include elementary data types, which define the properties of elementary fields. Several fields can be grouped together in a complex data type to describe the structure of an XML document node. Elements belonging to a complex data type can be typed with an elementary XML type, an elementary data type, or with a complex data type. This allows you to construct nested data types. An occurrence is specified for each element. In SAP NW PI 7.0 and lower, a complex data type was created for the structure of the document
For internal use by CSC only For internal use by CSC only
Unit 2: The System Landscape TBIT40
as a whole. The fields of this structure reference complex data types, which correspond to line types. The number of occurrences of the node permitted at runtime (cardinality) is also determined.
Hint: The term node here is used to mean a structure.
The message type describes the structure of a message that was either sent or received by SAP NetWeaver Process Integration, and determines the root element of the message. It references a single, complex data type. A message type can be used for both outbound and inbound service interfaces.
An XSD version of the message type is provided in Enterprise Services Repository for the export of the interface.
In contrast to the message interfaces in SAP PI 7.0 and lower, you use a service interface to describe operations that you need for a subsequent implementation in the application system, independently of a platform or programming language.
Figure 16: Service Interface and Service Operation
Note: With SAP NetWeaver PI 7.3, you can create some interface objects in the SAP NetWeaver Developer Studio. You can create service interfaces, data types, and message types using the Enterprise Services Browser view. New for this version is that you can activate or reject changes of a pending change just in SAP NetWeaver Developer Studio.
For internal use by CSC only For internal use by CSC only
TBIT40 Lesson: Design Objects in the SLD and Enterprise Services Repository
A service interface therefore serves as a structured element, and contains one or more service operations. The service operations, in turn, reference one or more message types (request/response in the case of synchronous operations), and thus also the description of the inbound or outbound messages. A service operation represents the service interface and its interface as a whole, uses attributes to describe the type of interface used, and distinguishes between inbound and outbound interfaces. If the interface is used in an integration process, then it becomes an interface with the attribute abstract, this attribute has no direction (outgoing or inbound) but represents the placeholder of the message in the integration process.
You can define Fault Message Types for application error messages and reference them in synchronous interfaces.
Hint: Asynchronous inbound interfaces can also reference a fault message type, in which case the application error persists in the target system.
Figure 17: Enterprise Services Repository: Service Interface, Service Operation, Message Type, and Data Types
Example: Interface with a Nested Structure
These interface objects are presented in a specific sample scenario below.
For internal use by CSC only For internal use by CSC only
Unit 2: The System Landscape TBIT40
Figure 18: Data Type and Message Type
The following objects have been created in Enterprise Services Repository for the SC_BIT400_A software component:
A service interface and service operation of the outbound and asynchronous type references the MT_Material message type A message type MT_Material that references the nested data type DT_Material
An elementary data type DT_MaterialID
A simply structured data type DT_MaterialDescription that contains the two string-like fields Language and Description
A nested data type that contains required entry fields as well as an optional field and a structured element defined using the data type DT_MaterialDescription. This structured element is optional since the attribute MinOccurs = 0; the number of occurrences is not restricted since the attribute MaxOccurs = unbounded.
At runtime, the corresponding message might look as an XML document:
For internal use by CSC only For internal use by CSC only
TBIT40 Lesson: Design Objects in the SLD and Enterprise Services Repository
Figure 19: XML Structure of the Source Document
Example: Message with Multiple Nodes
The receiver inbound interface in the example scenario consists of a message with two independent node types. Each node is optional and can have an unlimited number of occurrences at runtime. The term node here means structure in an XML document.
Figure 20: Message Type with Multiple Nodes
For internal use by CSC only For internal use by CSC only
Unit 2: The System Landscape TBIT40
Figure 21: XML Structure of the Target Document
The interface is available as a WSDL file for exporting interfaces. In the WSDL file messages types become message elements, data types become type elements and the interface itself becomes a port element.
Figure 22: Interface Objects and WSDL
Context objects are a particular element within the interface definitions.
Imagine a message InvoiceOut that, among other things, contains the address of a customer.
For example, you would use the following expression in XPath to access the contents of a field such as postalCode, which is stored in the address of customerData and which belongs to the InvoiceOut message:
For internal use by CSC only For internal use by CSC only
TBIT40 Lesson: Design Objects in the SLD and Enterprise Services Repository
/InvoiceOut/customerData/address/postalCode. If you need this expression in several conditions, then you must type it or copy it in every time. Alternatively you can assign a context object to the postalCode field, for example with the name PostalCode. In all conditions where you need the field value, it is enough to use PostalCode from the context object, so that these conditions are more readable.
Figure 23: Context Objects in Enterprise Services Repository and Their Assignment
Context objects encapsulate the XPath expression with which you would otherwise access the field contents and they represent a comfortable alternative to XPath expressions for accessing message contents.
Hint: The context object is used for typical key fields and has a business-related/meaningful name. You can reference a context object in several interfaces to clarify which different interface fields correspond to the same business content.
After you have created a context object in Enterprise Services Repository and assigned it to the field of a request message (Context Object tab page in the service interface), you can use it in the following situations:
1. To determine the receiver of a message depending on its content.
2. To process the process steps depending on the content of a message.
For internal use by CSC only For internal use by CSC only
Unit 2: The System Landscape TBIT40
There is a range of predefined technical context objects to enable you to access the message header information.