Skip to Content

Parallel SAP Backend Modules


A main target of integration is usually an easy, quick and secre maintenance. SAP Netweaver Process Integration is build as  modular as possible. Interfaces, Determinations, Agreements or Communication Channels can be replaced quite easy. Indeed this is  a very useful capacity of PI because requirements often change in short intervals. But imagine the new requirement would be: “We have connected our SAP backend system via many interfaces to a couple of 3rd party system. We need at once a mechanism to test some interfaces temporary with another SAP backend which contains better master data.” This sounds in the first moment like a painful copy and change of hundreds of IB Directory Objects – we are tempted to reject the challenge. But after sitting down and having a coffee, we remember the transport targets in SLD. Yes, we can replace a system in any IB Directory object by use of transport targets. Let’s look to the details:

Messages from SAP Backend to 3rd Party Systems 

If each IB Directory Object exists for SAP backend system 1 AND for SAP backend system 2, messages from both backend systems can be sent at the same time.

  Messages from SAP Backend to 3rd Party Systems

Image 1:Messages from different SAP systems can be sent at the same time to the same or different 3rd party systems

Use of Transport Targets

If all Integration Builder content is transported twice but using a different transport target for the SAP backend, all IB Directory objects containing the backend will exist in two versions at the new layer, objects not containing the backend will be overwritten with same values during the transport. |

Transport Target used to copy all IB Directory content

Image 2: Transport target determines which system the Development System ”becomes” in the routing objects of the next transport layer. Each content will be transported twice with another+ transport target.

Check List for the Transport

The copy should be done by scenario. Scenarios are dedicated to structure IB Director content as they contain only links and provide a good reuse of all configuration objects.  

  1. Copy the Scenario at PI Development System (for example into same folder with a certain suffix like “_2”)
  2. Execute a normal transport (export) of the original scenario (all objects)
  3. Import to PI Test System: Delete channels from the Change List (“Context: Reject Changes”) if they exist already at the PI Test System
  4. Activate your Change List
  5. Export the copied scenario (*_2) from PI Development System
  6. Change the transport target at SLD level to SAP System 2
  7. Clear the SLD cache in PI Test System Directory
  8. Import scenario (*_2) to PI Test System
  9. Delete non-SAP channels from the Change List (“Reject Changes”)
  10. Adapt the SAP channels – they should look quite similar to the System 1 channels
  11. Activate your Change List
  12. Change the transport target back to System 1
  13. Clear SLD cache in IB Directory Test System

Messages from 3rd Party Systems to SAP Backend

The situation for messages from 3rd party is a bit more complex. We cannot have Receiver Determinations for both systems at the same time. Obviously this would lead to data inconsistencies. At a certain time for a certain interface we need exactly *one* SAP receiver and we need an easy maintenance for this configuration.

Messages from 3rd party systems to certain SAP backendMessages from 3rd party systems to certain SAP backend 

Image 3: Messages need a certain SAP system as receiver -> messages from one 3rd party to different SAP systems are not possible at the same time. An easy to maintain PI ”SAP Receiver Switch” is required for each 3rd Party Sender

Extended Receiver Determination using a PI ABAP table

The implementation of the switch requirements is pretty simple: The receiver determination is done by an ABAP program what accesses a table storing fields for 3rd party sender and SAP receiver. That table can be maintained with standard transaction SM30.

Lookup to an ABAP table for Receiver Determination 

Image 4: The Extended Receiver Determination allows determine the receiver dynamic during Runtime. It is using a simple standard message type. The corresponding ABAP mapping program creates a instance by looking up to a customizing table

If you are new to Extended Receiver Determination or to ABAP mappings please have a look to the following links:

SDN Blog: Illustration of Enhanced Receiver Determination – SP16

SAP Library: Mapping Development with the ABAP Workbench

  ABAP table for Receiver Determination

Image 5: The table for the Receiver Determination needs at least two important field: For the 3rd party sender Business System and the SAP Receiver backend Business System

The ABAP mapping class can be reused for each interface! It is completly independend from input parameter “SOURCE”.

Source Code of ABAP mapping program:

* Data declarations
  DATA l_message TYPE string.
  DATA l_sender_service TYPE string.
  DATA lva_sender_conv TYPE zsender.
  DATA lva_receiver TYPE zreceiver.

* Get mapping constant SENDER_SERVICE
  l_sender_service = param->get( if_mapping_param=>sender_service ).

* To avoid conversion problems in table select.
  lva_sender_conv = l_sender_service.

* Find the Business System from the 3rd party
    sender = lva_sender_conv.

*Create the output in form of SAP type Receivers of
    ‘<?xml version=”1.0″ encoding=”UTF-8″?>’
    ‘<ns0:Receivers xmlns:ns0=””>’

* create a XString
      im_string   = l_message
      im_encoding = ‘UTF-8’
      ex_xstring  = result.


Disadvantages of such a Scenario

  • Risc for data inconsistence
  • 3rd party system does not ”know” the receiver
  • Messages of one process (e.g. purchase process) could be spread to different SAP systems, if the receiver is changed before a process is finished
  • 3rd party system could expect data contained in a different SAP system
Be the first to leave a comment
You must be Logged on to comment or reply to a post.