IDOC AAE non-SAP communication

This blog shows how to establish IDOC AAE communication to and from non-SAP systems using the Java single stack. There are a few notes around and some pitfalls when starting to integrate with non-SAP systems using IDOCs.

First of all, these are the relevant notes about IDOC AAE non-SAP communication:

Now, let’s go into detail. First of all, you have to set the system VM parameter “jco.allow_non_abap_partner” to “1”, otherwise the non-SAP communication is not allowed. This is also important for JCO server applications, because otherwise you are not able to handle requests coming from a java stack. Therefore also set “-Djco.allow_non_abap_partner=1” as VM argument, when starting the server.

Scenario 1: IDOC AAE adapter is sending an IDOC to a non-SAP system

We need to create 3 objects to complete this scenario.

NWA RFC Destination

JCA Connection Factory

IDOC AAE receiver adapter

My personal recommendation is to start with the IDOC AAE receiver adapter within NWDS or IB. Create a new receiver adapter using the RFC Client Parameters “From NWA”.

There seems to be a naming scheme, but it is not documented anywhere. I think it is used as shown in the screenshot. First the static part “xi/idoc/CF_” then the party name, followed by the business system or business component and the last part is the channel name.

You can choose a name here, but I would recommend to start with a dummy value, pinging the channel in NWA afterwards, to get the right JCA connection factory name suggested. Otherwise the channel ping will always show an error for that.

Now create the needed JCA Connection Factory within the NWA. Filter for the outboundRA JCA Resource and switch to the “Related JCA Connection Factories” tab. Select the outboundRA_CF entry, and press the button “Copy and add…”.

Now use the JCA Connection Factory name, which you got from the channel ping, for the JNDI name, and switch to the “Configuration Properties” tab, and add the property autoCommit with the value false. Also set the DestinationName, which you want to use for the RFC destination, which we will create next.

Now we have to create the RFC destination within the NWA. You could do this as first step also, this is not imported. Create a new RFC destination, tick Load Balancing “No” and fill in the gateway host and service which is used for the communication and press the next button. Choose a destination for the repository connection and press next. This destination is used to read the IDOC metadata. Now just add the parameter “jco.client.tpname” to the Generic Options table, and fill in the Program-ID, which is used for the communication with the external system. The Program-ID should be registered in the gateway you configured before. That’s it, press finish.

Now you can ping the destination, to check if it is working fine. If you forgot to set the “jco.allow_non_abap_partner” parameter mentioned before, this will show up as an error. Also it checks, if the Program-ID is present in the gateway you provided. Just give it a shot…

There is also a variant to configure this without using a destination, providing all the details in the JCA Connection Factory. I do not recommend this, as afaik it is not possible to perform a ping on the factory.

Scenario 2: IDOC AAE adapter is receiving an IDOC from a non-SAP system

The way back is much easier to configure. Just use the Program-ID set in the inboundRA Resource Adapter to communicate with the Java stack. You then can configure an IDOC AAE sender adapter, which uses the default RFC Server Parameters.

Just watch out to set the Logical System name for the Business Component according to the sender port (SNDPOR) in the IDOC Control Record. This is used to identify the right Business Component during runtime.