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:

1752276 – Idoc support for non-sap systems

1729203 – Support for communication with external RFC server

1717833 – RFC destinations to support external rfc servers

1877907 – Support of extern-to-extern RFC communication with JCo 3.0

To be able to use the IDOC AAE for non-SAP communication, you have to be aware of these prerequisites:

What is Supported (enabled with this Note)
-Communication with non-SAP back-end systems connected via the RFC SDK (SAP note 825494)
-Communication with non-SAP back-end systems connected via JCo standalone 3.0.10 (SAP note 1077727)
-Communication with non-SAP back-end systems connected via JCo standalone 2.1 (SAP note 549268 – as per the note the maintenance and support period for SAP JCo 2.1 ended on 03/31/2013)

What is Not supported (no change)
-Communication with non-SAP back-end systems connected via SAP NetWeaver RFC Library (SAP note 1025361)
-Communication with non-SAP back-end systems connected via SAP .NET Connector 3.0 (SAP note 856863)

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.

  1. NWA RFC Destination
  2. JCA Connection Factory
  3. 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”.

IDOC AAE receiver channel.PNG

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.

Channel Ping.PNG

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…”.

NWA AS.PNG

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.

JCA connection factory.PNG

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.

Hopefully this helps some of you out there!

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Marc Filella

    Hello Markus,

    please can you clarify the Scenario 2 for an only-java PI 7.31.

    as far as I found is not so easy and two connections are needed (to the java PI and to the ABAP R/3 back-end to take the IDOC metadata).

    Thanks in advance.

    Marc Filella

    (0) 

Leave a Reply