Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
martin_dejl2
Participant

Requirement

Synchonous scenario where Sender system expects synchronous response message for it's request but Receiver is SAP system and receiver interface is IDOC interface(asynchronous).

Prerequisite

Receiver SAP system in version 6.20 or higher(more in note 1487606).

Solution

First of all it's i feel it important to say: NO WSDL IS REQUIRED. I'm saying this because I spent half a day looking for it and then I found out that it's not necessary to have it.

Receiver system

Go to customizing client and run transaction SRTIDOC(or program SRT_REGISTER_SERVICE). Execute it with default variant IDOC_STANDARD. Confirm transport request and transport it into receiver client(for example customizing client could be 100 but receiver 200).

Check transaction SICF if service /sap/bc/srt/IDoc is up and running. Right-click on it and "Test service". In browser you should see something like this:

 

If it's working and you know appropriate system user(and password) receiver SAP system is ready.

PI

Create SOAP receiver communication channel and use it in your Receiver Agreement instead of IDOC channel. Target URL is the URL you can see in your browser after "Test Service". Enable also "Configure User Authentication" option and fill in the receiver system user and password(for example PIAPPLUSER)

Set sender channel as synchronous(Best Effort).

Send test message via sender channel (if it's SOAP then good test tool is SOAP UI)

In monitoring you will see response message from receiver system. If you get here, you have already won the jackpot. Next steps are just to finalize the complete interface:

Take response message from monitoring and create XSD based on it's structure(for each IDOC type is different).

Create external definition and import the original IDOC xsd file.

Create external definition and import the IDOC response xsd created from the first response message.

Create new inbound synchronous message interface. Use external definition of original IDOC as inbound message and response IDOC definition as outbound message.

Update your interface mapping with new target interface(instead of original IDOC use this new synchronous interface).

Create additional mapping between IDOC response message and the outbound interface response message.

Summary

Advantages

Provides real technical response from the receiver system.

Avoid using of BPM, adapter modules, function modules on ECC side etc.

Possibility to send IDOC number back to sender(if its mapped into its response) - could be used in some extended E2E monitoring reports etc.

IDOC is posted to receiver SAP system standard way - it's processed according to partner profile and results can be found in ta WE02.

Disadvantages

EDI_DC40 record is not created automatically by PI. It has to be created in mapping step which is not always feasible.

Additional service has to be running on receiver ECC system and TCP port has to be open. For landscape where PI and receiver SAP system are in one secure network it should be ok. Problem might be if they are not in the same network and some additional firewall rules has to be defined.

Some special settings/features of IDOC adapter are not available here (packaging etc.).

Additional info

When creating EDI_DC40 segment in mapping you'll need to fill also SNDPOR element. You can use some existing tRFC port name but you can also create new one with type XML:

17 Comments