I saw many thread about the Value Mapping options that PI offers to us to solve our requirement.So I decided to post this document to make the decision more clear when deciding for one of them.
In some situations, senders and receivers know the same objects, but under different names. This value transformation needs to be represented by a mapping program.
a more elegant way of solving this task is to use value mappings or value-mapping tables. In this case, the values you need to map are stored in a value-mapping
table and then read during the mapping.
| Fix Values | Value Mapping | Mapping Lookups |
|---|---|---|
Value-mapping tables are maintained in the ES Repository | Value-mapping tables are maintained in the Integration Directory | Value-mapping tables are maintained in a back-end system |
FixValues
FixValues is a standard function of the Conversions function group; it enables fixed value pairs to be saved in a message mapping (that is, in Enterprise Services Repository).
In the example, the source field CUSTTYPE is mapped to the target field CUSTTYPE . The default value for the target field is “business”. However, if the source field contains the values “B”, then the target field is given the value “business_XX”. In a similar way, a source value “P” will be mapped to target value “private_XX” .
Advantages and disadvantages of the standard function FixValues:
+ Easy to use
+ Possible to changes entries manually
+ Good runtime performance
- No mass upload of values
- Configuration values are in design
- Values only used in respective message mapping
Value Mapping
The standard function Value Mapping is in the Conversions function group area and you insert it between the source and target fields. You do not save the value
pairs for the conversion directly as the parameters of the function, but instead specify key fields for accessing the value pairs (conversion values). The value
pairs themselves are saved in the configuration (in the Integration Directory), using identical key fields. The entries in the value-mapping table must be assigned to a value-mapping context. This context enables you to distinguish between value mappings from different areas.
Values that are manually maintained in the Integration Directory automatically belong to the context http://sap.com/xi/XI. Alternatively, you can replicate values from outside PI into PI with another context by using an interface.
The actual values are referenced with the key fields Agency and Scheme. These key fields must be reused in the configuration.
You can enter any strings for Agency and Scheme for the sender and receiver. It is also possible to save a placeholder for the Agency field for the runtime constant SenderParty or SenderService (and likewise for the receiver), which is replaced by the current value during execution. The standard function Value mapping can be used in different message mappings with the same key fields, thus referencing the same “mapping table”.
If the mapping of the standard function Value mapping was not executed, the message trace of the converted message contains the following entry: Key mapping from ... has not been performed. Check the key fields Agency and Scheme.
Advantages and disadvantages of the standard function Value Mapping:
+ Possible to change entries manually (not in replication, see below)
+ Good runtime performance
+ Configuration values are in the Integration Directory
+ Possible to use values from different message mappings
+ Possible to use Java and XSLT mappings
+ Possible to transport values (DEV to TEST)
+ In replication: Possible to use values from the back end
- Takes time to learn
- Mass upload of values only possible using replication
Value Mapping Replication
To replicate value-mapping data from other applications in the runtime cache (on the Integration Server), you can use service interfaces (“value-mapping
replication interfaces”). The interfaces enable you to realize both synchronous and asynchronous replication scenarios. You can also use these interfaces to
automatically create value-mapping groups for mass data.
The value-mapping replication interfaces are included in the SAP NetWeaver PI shipment and are located in software component version SAP BASIS →
SAP BASIS 7.30 in the namespace http://sap.com/xi/XI/System. There are four interfaces in total; two synchronous and two asynchronous, or two outbound
and two inbound. The AS Java offers inbound proxies for the inbound service interfaces. The AS ABAP offers outbound proxies for the outbound interfaces in
the basis (in the ABAP stack of the Integration Server, as in every ABAP system based on Basis 6.40 and above).
| Name | Mode | Direction | Implementation |
|---|---|---|---|
| ValueMappingReplication | Async. | Inbound | Java |
| ValueMappingReplicationOut | Async. | Outbound | ABAP |
| ValueMappingReplicationSynchronous | Sync. | Inbound | Java |
| ValueMappingReplicationOutSynchronous | Sync. | Outbound | ABAP |
The sender can be any system containing values for value mapping. If it is an ABAP system (with proxy runtime), you can use the ABAP outbound interfaces
that are already implemented as ABAP proxies to transfer the data. The sender interface can be any other interface containing the required information. You must also create a mapping (from the sender interface to the ValueMappingReplication interface).
refer to those blog to get a more clear idea about to configure both type of services.
http://scn.sap.com/docs/DOC-3848
Mapping Lookups
Mapping lookups access values (tables) in a back-end system during mapping runtime. The lookup can be executed using the standard functions RFC Lookup or JDBC Lookup (see below), or using the lookup API from java coding. The lookup API can be used either in a user-defined function in amessage mapping, or in Java or XSLT mappings.
The lookup API provides methods for generic access to application systems using the RFC, JDBC, and SOAP adapter. There is also a special API for the JDBC
adapter that simplifies access.
The Java program transfers a payload stream to the API, which the Adapter Engine uses to send synchronously to the target system (but not a complete PI
message with message header). To deliver to the target system, a communication channel must have been set up in the Integration Directory. The response to this synchronous request is received as a stream by the Java program and must be parsed. For more information about these APIs, see the SAP Developer Network at https://www.sdn.sap.com/irj/sdn/javadocs (you will need an SDN user). If the configuration is complete and runtime is active, you can test lookups as part of a mapping program by using the test environment of an operation mapping.
The mapping editor includes standard functions RFC Lookup and JDBC Lookup that you can use to graphically define a mapping lookup using either the RFC
adapter or the JDBC adapter.
RFC Lookup takes into account the request, response, and fault parts of an imported RFC-Signature. To be able to model the lookup graphically, the structure
of the RFC interface must be known. To use this structure in the mapping editor, you have to import the RFC-Signature into Enterprise Services Repository. In the figure below, an RFC lookup is used in a target-field mapping to obtain additional information about the number of available seats on a flight from an SAP system at runtime.
Advantages and disadvantages of mapping lookups:
+ Configuration values are in the back-end system
+ Possible to use values from different mappings
+ Graphical support for RFC and JDBC
– Takes time to learn (programming) when the standard graphical functions
(RFC and JDBC) are not used
– Runtime performance issues
you can see these blog refering to Mapping Lookups
http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/08/07/how-to--soap-lookup
Best regards to all of you
- SAP Managed Tags:
2 Comments
