Setting up a simple IDOC-to-IDOC scenario on SAP PO 7.5

Background
Although I considered myself a fairly experienced SAP PI/PO developer in the past, I wasn’t really able to work with the integration solution from SAP for the last couple of years. Back then it was still called SAP Process Integration (PI), the go-to version was 7.1 and maybe the most important difference, there was still an ABAP stack present! Now that I started freelancing and setting my first steps towards entrepreneurship I came across an assignment in which SAP PI experience was required. What looked like a great opportunity to me for a first assignment as a freelancer soon turned out to be a reality check.

After the intake with my first potential client in which they explained the architectural features of their system landscape to-be I soon realized my acquired PI 7.1 knowledge in the past wasn’t really going to make the cut with the JAVA stack only, 7.5 version of what is now called SAP Process Orchestration (PO). I could have easily walked away from the situation with an “I don’t think my skillset matches the requirements of this assignment” excuse, but I decided to take on the challenge and eventually discovered that my PI 7.1 knowledge wasn’t really useless at all 😉

Scenario
My client is migrating his current SAP R/3 system to a brand new on-premise S/4HANA environment. If you haven’t been able to work with a S/4HANA environment, believe me, it’s a Ferrari compared to the traditional SAP ERP on-premise solution. Anyway, enough on S/4HANA. With this migration there is a requirement to transfer master data of employees from the current (old) SAP HCM environment to the new S/4HANA environment through SAP PO. Also, after the initial load of all employees from SAP HCM, every change in the selected infotypes of an employee in SAP HCM, should also trigger a change in S/4HANA.

Proposed Solution
Because of limited time given for this interface (and my limited experience with PO 7.5) we decided to go with a relatively easy to build IDOC-to-IDOC interface using the IDOC_AAE adapter of SAP PO. This gave me the opportunity to break in my hands-on experience with PO 7.5 while not worrying too much about the fast approaching go-live date. An initial load of employees will be triggered through transaction PFAL, while changes in their respective infotypes will be triggered through change pointers.

Setting up the connections
First and foremost you need to setup all required connections between the sender system, PO and the target system. In most cases this might have been done already by a SAP Basis consultant but in my case there weren’t any, so I had to set them up myself. Here’s what I did:

Go to transaction SM59 and create a new TCP/IP connection of type T in your source system.

I named the RFC destination (PD1) after the system name of the PO system. Make sure you use the PROGRAM ID “PD_RI” later on in your “inboundRA” resource adapter of PO. Select the option “Registered Server Program” and choose the Gateway Host and Service on which you want to register the PD_RI Program ID. I chose the Host and Service name of the HCM source system here because I couldn’t get it to work with the Gateway Host and Service of the PO system (somehow recommended by SAP).

Use the “Connection Test” button to test the new connection.

Now that your connection between the source system and SAP PO is set, let’s look into the configuration on the SAP PO side:

Browse to the SAP Netweaver administrator and go to Configuration->Infrastructure->Application Resources.

Filter out the “inboundRA” resource adapter and select the “Properties” tab.

As you can see, the “PD_R1” ProgramID corresponds with the value used in the RFC destination we created in the previous section. Also, you need to use the same Gateway Service and Gateway Host here as you did in the before mentioned RFC destination. Also notice the “XI_IDOC_DEFAULT_DESTINATION” destination which will come in use later in this blog. The property “MaxReaderThreadCount” is usually set to 0 by default. SAP recommends setting a value between 5 and 10 for this scenario. You might experience some difficulties restarting the inboundRA after setting this property. A restart of the JAVA instance helped me out in this case.

I set the “Local” property to “false” since the Program ID is registered on the Gateway Host and Service of the sender system. You will have to set this particular property to “true” if you use the PO Gateway Host and Service to register your Program ID.

Let’s take a look at the before mentioned “XI_IDOC_DEFAULT_DESTINATION” destination in PO. From the SAP Netweaver Administrator page browse to Configuration->Infrastructure->Destinations and look up the RFC destination.

Make sure this destination points to the sender system from which you’re going to send the IDOCs. Also, make sure you enter the right user with sufficient authorization on the “Logon Data” tab.

The XI_IDOC_DEFAULT_DESTINATION RFC destination is used by PO to retrieve information regarding the IDOCs from the sender system. You can test the new RFC connection by using the “Ping Destination” button in the screen shown above.

Now that the connections between the sender system and SAP PO are set up, you’ll need to set up the connection  between SAP PO and the target system. In my case this is the new S/4HANA system. Like the XI_IDOC_DEFAULT_DESTINATION you’ll need to set this one up in the “Destinations” section of the SAP Netweaver Administrator:

Make sure the RFC destination created points to the target system for the IDOCs and give the technical user used on the “Logon Data” tab sufficient authorization for the destination system.

Now that we have configured all required connections between sender system, SAP PO, and target system it’s time to set up all required objects in the Enterprise Service Repository and the Integration Directory of SAP PO.

Enterprise Service Repository
Setting up objects in the ESR is fairly easy. In my case I had to import the required IDOC HRMD_A05 from both the HCM sender system and the S/4HANA target system into the ESR. Whether you developed your own IDOC or you’re using a standard one like me, importing them into the ESR should be relatively easy.

Make sure to create two software component versions (SWCV) one for each system and import the required IDOC from each system into the SWCV of each corresponding system. Importing IDOCs is accomplished by right-clicking on your SWCV and selecting the importing option:

The user used for importing objects into the SWCV needs sufficient authorization for importing objects.

Warning: Importing standard IDOCs like HRMD_A05 might take a while or even cause JAVA HEAP errors because of the massive size of the IDOC. Make sure you’ll have enough memory available locally (adjust the two JAVA files for the ESR and IB downloaded when starting the ESR and IB) or server side (ask your Basis counterpart). 

Now that we have imported the IDOCs from both the sender system and the target system we are ready to develop a message mapping and subsequently an operation mapping in the ESR. Since I’m using a standard IDOC and this is somewhat of a 1-on-1 mapping, not a whole lot is required here. Like the SWCV’s created for both the source system and destination system, I also created a SWCV for the SAP PO system called “Integration”:

I use the SWCV for the SAP PO system for ordering all mapping objects neatly under separate namespaces.

The first object required, the message mapping is pretty straightforward. You’ll need the IDOCs uploaded from both systems and add them to the message mapping:

Add the IDOC from the sender system as data type on the left and the IDOC from the target system as data type on the right. Use the “Map selected fields and substructures if names are identical” button to breeze through the field mapping.

Now add an operation mapping to the same namespace and use the IDOC from the target system as source message and from the target system as target message. Use the above created message mapping as mapping program:

This way no data types or message types are required for the scenario. These are all the objects you need from the ESR! Easy isn’t?

Integration Directory
Now, the objects you’ll need to develop in the integration directory (ID) are pretty straightforward also. You’ll need a sender and receiver communication channel and an integrated configuration. That’s about it. Let’s look into the sender channel. Create a communication channel for the sender system which you should have defined in the ID as a business system. Make it a “Sender” channel and select adapter type “IDoc_AAE” as adapter of choice:

Select the default option for RFC parameters and leave the rest as-is (unless your scenario needs specific adjustments off course).

Create a receiver channel for the target system underneath the business system you have defined for the target system. Again, select the “IDoc_AAE” adapter, leave the RFC parameters on “Default” and use the RFC destination you have created for the target system in the destinations section for RFC Client Parameters:

Now that you have created both communication channels you’ll have to create an integrated configuration. I wasn’t familiar with this object until now since it wasn’t available in PI 7.1, but in my opinion it neatly organizes all objects involved in your scenario in one….well…configuration. This is what my ID looks like so far:

You’ll need pretty much all the objects you have developed so far in the integrated configuration. Use your sender communication channel on the “Inbound Processing” tab:

Select your target system as “Communication Component” on the “Receiver” tab:

On the “Receiver Interfaces” tab select your operation mapping for this scenario as the intended receiver interface. Here you can also add filters under the “Condition” column:

Use your receiver communication channel on the “Outbound Processing” tab and leave the rest as-is:

That’s about it for the integrated scenario object in the ID. Now that everything is in place on the sender, PO and target side, let’s dive into configuring the IDOC settings on both ends of the scenario.

Setting up the IDOCs
Although we have already set up a lot of the scenario in the previous parts, we still have some work to do so we can eventually send out and receive the IDOCs on both ends of the scenario. Let’s take a look into the configuration on the sender system first.

Through transaction WE21 create an new IDOC port of type “Transactional RFC” and use the RFC destination created (PD1) in the “Setting up the connections” of this blog:

After you created the dedicated IDOC port create a new logical system for the target system (if one doesn’t exist yet) through BD54:

The client already had logical system BVG_IDOC in place for dedicated IDOC communication, but in your case you might have to create a new one.

Create a partner profile of type logical system with WE20 and make it point to the logical system we have just created:

Add the relevant message type (HRMD_A05) in the outbound parameters and configure as displayed below:

Select the IDOC port you have created at the beginning of this part and point to the relevant IDOC type. Make sure you use an authorized user on the “Post Processing” tab.

Now activate the change pointers on a general level with BD61:

And subsequently on a more specific level with BD50:

In order to register the changes made in the selected infotypes you’ll need to create a distribution model through BD64. Create a new model view with the “Create Model View” button and give it a technical name suitable for your scenario. Add a message type to your new model view:

Use the logical system of the source as sender and the (new) logical system of the target as receiver. Select the relevant message type also. Your new model will (kinda) look like this:

As you can see a filter is active that filters out the infotypes needed for my scenario. I added this filter so that every change made in the selected infotypes will trigger an IDOC and thus changes the infotypes of the target system equally. Underneath are the infotypes needed in my scenario. Off course you can add or delete infotypes to suit your own scenario:

Triggering IDOCs from changes
As said before in the “Proposed Solution” part of this blog, an initial load of employees will be send out by IDOCs through transaction PFAL. This specific transaction is very handy when you want to send out an IDOC for all (or specific) employees with all the infotypes selected:

You can either select one employee (as depicted) or select all employees (this might take a while). Make sure to use the correct receiver and message type.

Subsequent changes in the selected infotypes of employees through (for example) PA30 only trigger IDOCs after you run BD21 (or report RBDMIDOC) for the relevant message type:

In order to receive the generated IDOCs from the sender system your target system needs some configuration too. Create a partner profile of type “Logical System” through WE20 and point to the logical system created for the sender system. If no logical system for the sender present, create one through BD54:

Make sure to add the relevant message type as an inbound parameter and subsequently configure the parameter:

Now that everything is in place for sending and receiving IDOCs through SAP PO, let’s take a short look on the monitoring options.

Monitoring IDOC traffic
IDOCs can be monitored through transaction WE02 on both the sender (outbound) and the target (inbound) system:

You can click on the outbound IDOC to see its content on the sender system.

Whenever an IDOC is not present in the WE02 monitor, you might want to check out SM58 and look for RFC errors on the sender side:

Monitoring IDOCs on SAP PO is achieved through the “Configuration and Monitoring home” link on the startpage of SAP PO. Go to tab Monitoring->Adapter Engine->IDOC Adapter Monitor to check up on IDOCs that are passing through SAP PO:

Off course, there are plenty more monitoring options available (message monitoring, communication channel monitoring), but I’ll stick to the IDOC monitoring for now.

Since this is my first blog and first hands-on experience with the JAVA stack only SAP PO 7.5 feel free to leave suggestions or even corrections on this walkthrough. In no way I’ve had the intention to create the perfect, complete blog J just wanted to share my experiences and leave you with a walkthrough that might come in handy when confronted with the same business scenario!

Cheers!