You can define mappings for a source and target operation based on operations from service interfaces and message types in the ES Repository:
You can also define the corresponding mappings when the source or target operation is an IDoc, an RFC, or another interface connected by an adapter.
The figure shows that you can reference message types for three different application cases for each operation.
Request (asynchronous and synchronous communication)
The request is the message that the consumer sends - using an operation in the outbound-service-interface - to a corresponding operation in the inbound-service-interface.
Response (synchronous communication only)
The response is the direct response that the consumer waits for after the request message has been sent. The message is sent from the provider (inbound-service-interface) to the consumer (outbound-service-interface).
Fault (asynchronous and synchronous communication)
Message that is either sent to the consumer (synchronous) or persisted for monitoring (asynchronous) if an error occurs at the provider.
The arrows in the figure indicate the direction of message exchange at runtime: In the context of mappings, the operation that sends a message is also referred to as a source operation, and the operation that receives a message as a target operation. You can define mapping programs for mapping the message type of a source operation to the message type of a target operation (depending on the type of operation for the request, response, and fault message). The Enterprise Services Builder supports the following mapping programs for this purpose:
● Message mappings that you define using a graphical editor in the ES Builder. This is used to create a Java source code for the runtime.
● XSLT and Java mappings that you can import into the ES Repository as an archive.
● XSLT and ABAP mappings that customers can implement using the ABAP Workbench (see Mapping Development with the ABAP Workbench).
Essentially it is possible to create or import multiple mapping programs in the ES Repository for the same message type pair (or the corresponding part of an imported or external interface).
SAP recommends that you use message mappings. However, in exceptional cases it may be advisable to use different mapping programs, for example, because you can apply XSLT or Java mapping programs from a previous integration project.
Note the following regarding the speed at which the mapping program types are executed:
● Handwritten Java programs by experienced Java developers are usually quicker than generated Java source code from message mappings.
● Message mappings can cope with significantly larger messages than XSLT. Whether an XSLT program or a message mapping is quicker depends on the complexity of the mapping. Tests have shown that even message mappings for larger messages are quicker than the equivalent XSLT mapping programs.
● Experience has also shown that Java-based mapping programs are quicker than ABAP-based mapping programs.
When defining mapping programs for request, response, or fault messages, the definition is first separated from the operations that reference the corresponding message types. You can use the same message type for multiple operations. The definition of a mapping program therefore remains decoupled from a specific interface pair that you use later to implement the communication between the sender and receiver. Furthermore, depending on the type of operation, there can be multiple mapping programs that can be applied for a specific interface pair.
The operation mapping establishes the connection between operations by means of mapping programs:
● An operation mapping specifies the corresponding mapping programs for request, response, or fault messages for a selected pair of operations. You register mapping programs at design time by using an operation mapping. In this respect, an RFC or IDoc is on the same level as an operation (more information: Interfaces, Operations, and Message Types).
● You can also specify multiple mapping programs to be executed one after the other in the case of requests and responses for an operation mapping.
You can also define multiple operation mappings for the same pair of operations, to provide multiple variants in the ES Repository. At configuration time, the customer or the consultant only accesses the operation mappings and not the individual mapping programs. This reduces the configuration effort for an interface determination in the Integration Directory.
There are two types of mappings, regardless of the mapping technology that you use:
● Structure mappings where the structure of an XML document is mapped to the structure of another XML document.
● Value mappings where the values of an XML document are mapped to the values of another XML document.
In the example below, data about a flight booking is exchanged using XML documents. The XML schema of the source document provides more hierarchy nodes than the XML schema of the target document. Furthermore, the target document schema does not use all the information that is provided by the source document schema. Both structures can be mapped to each other by using a structure mapping.
An example of when a value mapping is required is for the passenger class on a flight. In the source document, this information is coded by using a string, while in the target document, a decimal value is used. Another example of a value mapping would be the date format.
Using the ES Builder graphical mapping editor, you can define structure mappings easily using Drag & Drop. You can then use a function to assign fields to each other from source and target structures that require a value mapping.