Skip to Content

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.

Value Mapping Replication Scenario

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.
Transparent Table (SE11) for Mapping Values

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
Table Maintenance Dialog Generator

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.

Event and FORM routine to be called

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.

New Include in the Function Group containing the FORM routine

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.

ABAP Proxy ValueMappingReplicationOutSynchronous

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:

Asynchronous: http://:/ProxyServer/register?ns=http://sap.com/xi/XI/System&interface=ValueMappingReplication &bean=localejbs/sap.com/com.sap.xi.services/ValueMappingApplication &method=valueMappingReplication

Synchronous: http://:/ProxyServer/register?ns=http://sap.com/xi/XI/System&interface=ValueMappingReplicationSynchronous &bean=localejbs/sap.com/com.sap.xi.services/ValueMappingApplicationSynchronous &method=valueMappingReplicationSynchronous

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

Standard Function Value Mapping

SAP Help Linx

Value Mapping
Value Mapping Replication for Mass Data

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Ravi Siddamsettiwar
    Nice blog.
    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

    (0) 
  2. Andrzej Wanicki
    Hi Udo

    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

    (0) 
    1. Udo Martens Post author
      Hi Andrzej,

      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

      (0) 
      1. Andrzej Wanicki
        Thanks a lot for the reply Udo. Implementing the solution in a File Sender (with XML file) or even Mail sender (using say an Excel file attachment for example) might be an alternative solution where the business can also maintain the mappings (if necessary) and send an email or place on a file share for processing. This approach would remove the middleware logic from the ECC backend. What is your opinion on this approach ?.

        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

        (0) 

Leave a Reply