Background
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.
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. |
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.
- Copy the Scenario at PI Development System (for example into same folder with a certain suffix like “_2”)
- Execute a normal transport (export) of the original scenario (all objects)
- Import to PI Test System: Delete channels from the Change List (“Context: Reject Changes”) if they exist already at the PI Test System
- Activate your Change List
- Export the copied scenario (*_2) from PI Development System
- Change the transport target at SLD level to SAP System 2
- Clear the SLD cache in PI Test System Directory
- Import scenario (*_2) to PI Test System
- Delete non-SAP channels from the Change List (“Reject Changes”)
- Adapt the SAP channels – they should look quite similar to the System 1 channels
- Activate your Change List
- Change the transport target back to System 1
- 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.
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.
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
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:
METHOD IF_MAPPING~EXECUTE.
***********************************************************************
* 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
SELECT SINGLE
receiver
FROM
zreceiv_det
INTO
lva_receiver
WHERE
sender = lva_sender_conv.
*——————————————————————-
*Create the output in form of SAP type Receivers of
*SWC BASIS, NS http://sap.com/xi/XI/System
CONCATENATE
‘<?xml version=”1.0″ encoding=”UTF-8″?>’
‘<ns0:Receivers xmlns:ns0=”http://sap.com/xi/XI/System”>’
‘<Receiver>’
‘<Service>’
lva_receiver
‘</Service>’
‘</Receiver>’
‘</ns0:Receivers>’
INTO
l_message.
* create a XString
CALL FUNCTION ‘ECATT_CONV_STRING_TO_XSTRING’
EXPORTING
im_string = l_message
im_encoding = ‘UTF-8’
IMPORTING
ex_xstring = result.
ENDMETHOD.
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