Value Mapping Replication Scenario
Background
PI Mapping Runtime can require external data for serveral reasons. Most common are different names for same unities in different systems. For example material classes vary often as well as names for organizations. A mapping program requires in such cases an access to a table where the values from different systems are correlated. There are quite different strategies to implement such a scenario:
- Put the data direct into the mapping program: Most serios disadvantage would be a bad maintenance; the program has to be changed and retested in case of new or changed values .
- Reading the data from an external file or a PI table: Unusual maintenance and no control of authorization
- Access the data during runtime via lookup: Can lead to performance issues. Analyzing any errors could be difficult as the monitoring isnt that smooze as for message traffic. A temporary connection problem to the value mapping storage would be an additional risc.
- Storing the data in a SAP ECC table for usual maintenance (SM30) and good control of authorization and replicating them by any change to PI Java Runtime Cache for a good runtime performance
Description of the scenario
The external data (correlation of different values) are stored in SAP ECC z-table. By any change of the table content an ABAP program calls a proxy, which replicates the whole table content. There wont be any performance issues if the data are not changed too often and if this are not too much data. This preconditions shouldnt be a problem in the most cases. The full table replication is much easier than a delta load and can be implemented within a few hours.
The data are replicated to Java Runtime Mapping Cache, they can be controlled from Runtime Workbench. A standard function from Message Mapping can make use of the correlated values, the Runtime performance for this sceanrio is better than for any scenario with lookup.
Example
Suppose we have different purchase organizations in a SAP system and a third party system. We are planning to add later organizations and we might want to add another third party system in future. To exchange messages we need to map that organizations by an external table.
Mapping Table at SAP System
The mapping table is created at the SAP system (transaction SE11).
The context is individual for our mapping case (and therefore for our scenario and our third party system). The context and at least one of the mapping values should be key of the table.
Table Maintenance Generator
The function Utilities / Table Maintenance Generator at SE11 allows to create a quick controlled table maintenance from SM30). We can choose directly a Authorization Group for a control of access. The Function Group, which later will be extended, must be in the customers namespace. From this dialog we can jump to the event handling: Environment / Modification / Events
Events from Table Maintenance
An event can be defined in that step, for example “02 – After saving in the database”, and a FORM routine what should be called if that event was raised. A own FORM should be typed in here, which will be created in the next step.
Function Group
A new include needs to created in the Function Group (SE80), what was typed in at the Table Maintenance Dialog. It has to be in the customers namespace. During the activation there could popup some confusing messages which can be ignored. The include just contains the FORM routine from the last step.
ABAP Outbound Proxy
With the SAP BASIS Software Component two ABAP outbound proxies were delivered (transaction SPROXY). In our example the synchronous proxy is used.
It can be used to send messages directly (as XML) to the PI Integration Engine. The view tabs are very helpful during implementation of the ABAP program (the FORM) routine. They provide an overview about the structure and by clicking on an element the type can be copied from “ABAP Name Ref.”.
- Operation: Fixed Value: Insert, Delete, DeleteGroup, DeleteContext or DeleteContextGenerice. This value determines the action. In our example we use “Insert” and “DeleteContext”.
- GroupID: 2 Values with the same GroupID belong together (correlation). To create that 32 character hexadecimal number function module ICF_CREATE_GUID is used.
- Context: Values of one context belong to one scenario. For values of one context can be searched at RTW and one context can be deleted by only one message.
- Identifier(VALUE): The value of the parameter in the different systems. In our case the value for the purchase organization.
- scheme: A scheme what the value is about. In our case the fix value “PurchaseOrg”. The scheme would allow to extend the scenario for other mapping tasks to use only one ECC table for a lot PI scenarios. In our example a constant is used, the more generic scenario would require a variable value there.
- agency: The system (or the “agency”) what the value is belonging to. In our case SAP or the the third party system.
Source Code of FORM routine:
*&———————————————————————*
*& Include ZZMM_PURCH_ORGS_EVENTS
*&———————————————————————*
FORM f_pi_export_zzmm_purch_orgs.
*———————————————————————-*
* DATA DECLARATION *
*———————————————————————-*
DATA:
* error text application error
l_appl_fault_text TYPE string,
* One context for Value Mapping Replication
l_context TYPE zz_context,
*———————————————————————-*
* STRUCTURES *
*———————————————————————-*
* request type for proxy
lwa_output TYPE svmr_value_mapping_replication,
* reponse type for proxy
lwa_input TYPE svmr_value_mapping_rep_resp,
* one item in proxy structure
lwa_item TYPE svmr_value_mapping_rep_item,
* Line of table ZZMM_PURCH_ORGS
BEGIN OF lwa_purch_orgs,
context TYPE zz_context,
sap_purch_org TYPE vkorg,
thrd_party_org TYPE zz3rdparty_org,
END OF lwa_purch_orgs,
*———————————————————————-*
* INTERNAL TABLES *
*———————————————————————-*
* internal table like transparent table
lit_purch_orgs LIKE TABLE OF lwa_purch_orgs,
* context entries in transp table zzmm_purch_orgs
lit_contexts TYPE TABLE OF zz_context,
*———————————————————————-*
* OBJECTS definitions *
*———————————————————————-*
* standard proxy for value mapping replication (synchronous)
lo_vmr_proxy TYPE REF TO co_svmr_value_mapping_rep_sync,
* Exception class for Application Integration: Technical Error
lo_sys_fault TYPE REF TO cx_ai_system_fault,
* Exception class for Application Integration: Application Error
lo_appl_fault TYPE REF TO cx_ai_application_fault,
* Exception class for Application Errors
lo_vmr_fault TYPE REF TO cx_svmr_value_mapping_rep.
*———————————————————————-*
* SELECTION SCREEN *
*———————————————————————-*
*———————————————————————-*
* START OF SELECTION *
*———————————————————————-*
*———————————————————————-*
* Main logic *
*———————————————————————-*
*————————————-Fill container for delete operation
SELECT DISTINCT
context
FROM
zzmm_purch_orgs
INTO TABLE
lit_contexts.
LOOP AT lit_contexts INTO l_context.
lwa_item-operation = ‘DeleteContext’.
lwa_item-context = l_context.
APPEND lwa_item TO lwa_output-value_mapping_replication-item.
ENDLOOP.
*——Transfer with ABAP outbound proxy via Java inbound proxy to Java Runtime Cache
CREATE OBJECT lo_vmr_proxy.
TRY.
CALL METHOD lo_vmr_proxy->execute_synchronous
EXPORTING
output = lwa_output
IMPORTING
input = lwa_input.
CATCH cx_ai_system_fault INTO lo_sys_fault.
WRITE:/ lo_sys_fault->errortext.
CATCH cx_svmr_value_mapping_rep INTO lo_vmr_fault.
WRITE:/ lo_vmr_fault->standard-fault_text.
CATCH cx_ai_application_fault INTO lo_appl_fault.
CALL METHOD lo_appl_fault->if_message~get_text
RECEIVING
result = l_appl_fault_text.
WRITE:/ l_appl_fault_text.
ENDTRY.
IF sy-subrc = 0.
WRITE:/ ‘Cache was succesfully deleted with status: ‘, lwa_input-status.
ELSE.
WRITE:/ ‘Old PI cache data could not be deleted, action cancelt’.
LEAVE PROGRAM.
ENDIF.
CLEAR: lwa_item, lwa_output.
*————————————-Fill container for insert operation
lwa_item-operation = ‘Insert’.
lwa_item-identifier-scheme = ‘PurchaseOrg’.
* DB READ
SELECT
context
sap_purch_org
thrd_party_org
FROM
zzmm_purch_orgs
INTO TABLE
lit_purch_orgs.
IF sy-subrc <> 0.
WRITE:/ ‘DB table ZZMM_PURCH_ORGS could not be read, insert to Java cache not possible.’.
LEAVE PROGRAM.
ENDIF.
LOOP AT lit_purch_orgs INTO lwa_purch_orgs.
* Context for pair of values
lwa_item-context = lwa_purch_orgs-context.
* create a guid for a pair of values
CALL FUNCTION ‘ICF_CREATE_GUID’
IMPORTING
id = lwa_item-group_id.
* Insert 3rd Party org
lwa_item-identifier-agency = ‘3rdParty’.
lwa_item-identifier-value = lwa_purch_orgs-thrd_party_org.
APPEND lwa_item TO lwa_output-value_mapping_replication-item.
* Insert SAP org
lwa_item-identifier-agency = ‘SAP’.
lwa_item-identifier-value = lwa_purch_orgs-sap_purch_org.
APPEND lwa_item TO lwa_output-value_mapping_replication-item.
ENDLOOP.
TRY.
CALL METHOD lo_vmr_proxy->execute_synchronous
EXPORTING
output = lwa_output
IMPORTING
input = lwa_input.
CATCH cx_ai_system_fault INTO lo_sys_fault.
WRITE:/ lo_sys_fault->errortext.
CATCH cx_svmr_value_mapping_rep INTO lo_vmr_fault.
WRITE:/ lo_vmr_fault->standard-fault_text.
CATCH cx_ai_application_fault INTO lo_appl_fault.
CALL METHOD lo_appl_fault->if_message~get_text
RECEIVING
result = l_appl_fault_text.
WRITE:/ l_appl_fault_text.
ENDTRY.
IF sy-subrc = 0.
WRITE:/ ‘Cache was succesfully updated with status: ‘, lwa_input-status.
ELSE.
WRITE:/ ‘New values couldnt be updated at PI’.
LEAVE PROGRAM.
ENDIF.
**———————————————————————-*
** END OF SELECTION *
**———————————————————————-*
*
*
ENDFORM. “f_pi_export_zzmm_purch_orgs
Java Inbound Proxys
The Java inbound proxies on the Integration Server can easily be activated by calling a simple URL:
Integration Builder Configuration
- Sending System: SAP System >= WAS 6.20
- Receiving System: Integration Server
- Receiver Determination: Sender: SAP-System / IF: ValueMappingReplicationSynchronous / NS: http://sap.com/xi/XI/System – Receiver: Integration Server
- Interface Determination: Sender: SAP-System / IF: ValueMappingReplicationSynchronous / NS: http://sap.com/xi/XI/System – Receiver: Integration Server Inbound-IF: ValueMappingReplicationSynchronous / Inbound-NS: http://sap.com/xi/XI/System – no Mapping
- Communication Channel: Component: Integration Server – Adapter Type: XI-Receiver – HTTP Destination: Destination to Integration Engine
- Destination: Type: H, Host: Java host, Service No: Java Port, Path-Prefix: /MessagingSystem/receive/JPR/XI
- Receiver Agreement: Sender: SAP-System – Receiver: Integration Server / IF: ValueMappingReplicationSynchronous / NS: http://sap.com/xi/XI/System – Receiver Channel: like above
Replication Control
The proxy replication can be monitored at transaction SXMB_MONI either at SAP and at PI. The values are available at Runtime Workbench / Cache Monitoring / Cache Instance: Mapping Runtime Cache, CAche Object: Value Mapping Groups
Use in Message Mapping
Value Mappings can maintained with standard function “Value Mapping”. The context must be typed in, as well the Schema (“PurchaseOrg” for our example). The organizations are mapped by the typed in values for source and target agency. The behaviour regarding exceptions of the function can be maintained: Source value, default value or runtime exception
Your blog is excellent - incredibly helpful!
Regards,
Mr. President.
i would like to know, we have to use ABAP stack of XI only or we can use the ABAP of SAP R/3 backend system as well. If yes, then how this communication will happen. I mean RFC destination etc?
regards,
Ravi Siddam
Thanks for the blog interesting to see the use of a proxy to populate the Value Mapping cache. A more philasophical question from me in that isn't the use of Z tables in the business backend contrary to the whole thesis of Value Mapping and the outside in approach ?. By creating these Z tables you are storing in the Business backend logic not related to the business but related to middleware processing. The whole purpose of the "PI BUS" is the removal of such logic from the ECC backend itself and concentrating it in the middleware solution. I can see the use of the proxy scenario above if the cross reference data e.g external material number was stored in standard tables e.g. MARA and used in the day to day business by data entry / lookup or the like. Would appreciate if you could feedbaack what you think is gained by such an approach ?, e.g. easy maintenance, that cannot be provided for in the standard Value Mapping Solution where the data is maintained in the Integration Builder.
Thanks
yes, i think you mentioned a critical point. VMR with z-tables is storing mapping content at a ERP backend - contrary to PI philosophy of a central place for colaboration knowledge.
From a practical point of view you have the advantages of an easy maintenance by business users and a corresponding reuse of authorization. If the data were stored at IB (Value Mapping) PI knowledge would be required for any change. It is obvisiously more direct and cheaper for the daily business if the data can be changed in a ERP z-table.
Regards,
Udo
As an aside I have seen this blog widely referred to in the SDN community with a general buy into the approach. Perhaps my questions are from a philosophical and not a pratical standpoint but I would imagine this approach for a large project could lead to many Z tables within the ECC backend.
Thanks
Andrzej
Thanks a lot for sharing Udo, we implemented your approach successfully in a project 🙂