Connection NON-SAP JCO-Client to SAP PI 7.3 Java Single Stack

[martin_pichlo]

Hi,

we are upgrading from SAP PI Double Stack to SAP PI 7.3 Java Single Stack. At the moment we have a lot of trouble communicating via Java IDoc Adapter between NON-SAP JCO-Clients and SAP PI. The biggest point is, that we do not found information how this should work with Java Single Stack. But let’s start from the beginning.

Our scenarios looks like this:

Request: SAP ERP -> SAP PI -> NON-SAP JCO-Client

Response: NON-SAP JCO-Client -> SAP PI -> SAP ERP

All IDoc settings between SAP ERP and SAP PI are set up and the communication is running without any problems. So the “only” challenge is to connect SAP PI with the NON-SAP JCO-Client.

But how to do this? Here a listing what we tried:

1.          First of all we just tried to initiate the connection via JCO with a configuration like this:

JCO.addClientPool(
 "PI",    //pool name
 3,           //maximum pool connections
"001",       //SAP client
"USER",    //user ID
"PWD",  //password
"DE",        //language
"10.10.10.10", //app server host name
"01" );   //system number

Unfortunately this did not work. Probably because there is no (abap) client at a Java Single stack installation.

2.          So we checked if JCO communication is supported by AEX IDoc Adapter. Here we have found the following article “Consolidated view on release notes for Process Integration and Orchestration”. Within this article we found the reference “PI Release Notes Consolidated - Features Comparison” and at page 10 in line “Communication with non-SAP backend systems via JCo standalone 2.1” a green flag for SAP PI 7.31 SP6 and AEX. So in generally SAP JCO connections “should” work.

3. But how? Because it seems that there is not official documentation available we searched for SAP Notes. Here we found note 1729203 and 1752276 with some generally information. But especially the information how JCO could connect to SAP PI are missing or the documentation is incomplete.

Are there any documentation available which describes the IDoc communication between SAP PI Java Single and NON-SAP JCO systems? What we need is a way how all existings NON-SAP JCO based clients could communicate with SAP PI Java Single Stack without modification.

Many thanks in advance

Martin

[MarkusTolksdorf · Accepted solution]

Hello Martin,

simply use the addClientPool() method for connecting to registered servers, that's the one with gwhost, gwserv and tpname arguments (see JavaDoc). A PI 7.31 is in principle a an AS Java that offers a registered RFC server as entry point for RFC.

Best regards,

Markus

[martin_pichlo · Accepted solution]

Hi Markus,

thank you for your answer. As written above we are searching for a solution to connect to PI without program modifications. But may this don't exist...

To test your suggestion we've created a JCO 2.1 test client with external property-file and could establish a connection with the following configuration:

jco.client.gwhost=123.123.123.123 
jco.client.gwserv=sapgw01
jco.client.tpname=jcoclient
jco.client.type=E 

So if we have a chance to modify the JCO side we may have a solution for JCO 2.1. In this context we've also created a JCO 3 test client with an "jcoDestination" File with the same properties as above. As result we got the following errors:

Exception in thread "main" com.sap.conn.jco.JCoException: (101) RFC_ERROR_PROGRAM: Configuration of destination sender is incomplete: Communication with RFC server programs is not supported with JCo standalone 3.0.9 (2012-07-19)
(.....)
Caused by: RfcException: [null]
message: Communication with RFC server programs is not supported with JCo standalone 3.0.9 (2012-07-19)
Return code: RFC_INVALID_PARAMETER(19)
error group: 101
key: RFC_ERROR_PROGRAM
(...)

Could you provide us the information how to adopt your JCO 2.1 solution to JCO 3.0?

PS: Please let us if you could imagine any workarround how to connect with the "old-way" parameters.

[MarkusTolksdorf · Accepted solution]

Hello Martin,

Up to JCo 3.0.9 a communication with a non-ABAP communication partner is not supported It is planned to be changed again. There is no work-around with the old-way parameters.

Best regards,

Markus

[Former Member · Accepted solution]

Martin,

Please use JCO 3.0.10, available since the end of August 2013.

On the JCO server (PI or your code) side, you will also need to set a parameter (see note 1729203)

"jco.allow_non_abap_partner" to "1"

[martin_pichlo · Accepted solution]

Hi Jan,

this patch was supplied regarding the error of our customers. I have had no time to share this information here. Thank you for doing so.

Regards

Martin

[MarcFilella · Accepted solution]

Hi Jan, Martin,

please can you explain exactly how to configure this scenarios (PI 7.31 java-only) to non-SAP JCO 3.0.10 ?

Request: SAP ERP.IDOC -> SAP PI -> IDOC.NON-SAP JCO-Client

Response: NON-SAP JCO-Client.IDOC -> SAP PI -> IDOC.SAP ERP

The bold IDOC side of this interfaces are the ones that I don't know exactly how to configure correctly (below I'll try to explain what is correct from my point of view).

My findings (I build a little java app. to send/receive IDOCs) are that this kind of configuration is not possible without an ABAP Gateway connection in order that the non-SAP JCO can take the IDOC metadata. So this is why I think that this is incorrect : it seems that we need the non-SAP JCO application to be connected both to the PI 7.31 (java-only) and also to an ABAPgw (to take IDOC metadata).

And the correct way (in my opinión) should be that the non-SAP JCO needs to connect ONLY to PI (to send/receive, to register and to take IDOC metadata).

Please, if you know how to do this, please can let me know or provide me some link that explains it in detail ? as a registered server program, or with other kind of connection from the JCO App ...

Best regards, and thanks in advance.

Marc Filella

[Former Member · Accepted solution]

Marc,

You are correct in understanding that you need an ABAP system in order to be able to use IDOCS with SAP JCO, but in my view, this makes sense, as I see no use case for using IDOCs without any SAP ECC/CRM/,,, (or other SAP ABAP-based system) in your landsacpe.

Regarding the configuration, for the "SAP ERP.IDOC -> SAP PI -> IDOC.NON-SAP JCO-Client" (more correctly "SAP ERP.IDOC -> SAP PI -> IDOC.NON-SAP JCO-Server") case, you will need to create an outboundRA Resource Adapter in your SAP PI system, pointing to a SAP GW (can be any SAP GW, but you can use the one of your SAP PI ststem) and specifying a ProgramID (similar, but not identical, to the SM59 RFCDES you need to specifiy in your SAP ERP system to connect to your SAP PI system). Your SAP JCO server then needs to connectd to the same SAP GW with the same ProgramID.

For the "NON-SAP JCO-Client.IDOC -> SAP PI -> IDOC.SAP ERP" case, you will need to connect the SAP JCO Client to the SAP GW and ProgramID of the inboundRA Resource Adapter in your SAP PI system (identical to the SM59 RFCDES you need to specifiy in your SAP ERP).

Kind regards,

Jan Van Achte

[MarcFilella · Accepted solution]

Hi Jan,

I agree with you about the need of an ABAP system in the landscape when sending/receiving IDOCs, but what I don't view as a good option is the configuration needed with the PI 7.31 only-java.

Let me explain a Little more :

- in the past (PI dual-stack), all external systems (IDOC and non-IDOC kind), ONLY needs to connect to our PI (for example 7.0), this was posible because PI have also the ABAP stack and this ABAP stack was the one that provides IDOC metadata (if needed). No connection to the back-end SAP ERP was needed.

- but now the PI single-stack can receive/send messages but can't provide the metadata to the external non-SAP systems (or I can't find how to do it). So the result is that this external systems needs two connections (one to PI, and another one to the ABAPgw), and this is why I said that this configuration is not correct (at least nor 100% correct, on my point of view). Many qüestions arises here, for example if we want to send one IDOC to many ABAP systems, to which one we connect the JCO.Client?, at network level we needo to open connections that before was not needed, in security things we need to open the door to our back-end SAP.ERP system (yes only to read the metadata, and it can be adjusted with a little set of authorisation objects, but previously it was not needed and the only one that takes this data was PI)...

My purpose is that in the same way that we have the IDOC_INBOUND_ASYNCHRONOUS function in the inboundRA also exists the IDOC_READ_COMPLETE (maybe another one is needed to retrieve the IDOC metadata, but I think that this one is mandatory) that can provide the IDOC metadada from the source ABAP system to the external non-SAP system.

I'll try in more detail the non-SAP.Client and the non-SAP.Server configurations for the message sending/receiving and provide some feedback on my findigs in a few days.

Best regards, and thanks for the fast answer.

Marc Filella

[martin_pichlo · Accepted solution]

Hi Marc,

you do not need any ABAP System or Gateway "between" SAP PI and NON-ABAP JCO Client. But you have to make sure to use at least JCO 3.0.10 and some special settings. I suggest you to start with the ERP->PI->NON-ABAP Client, because this do not chance as much. For this purpose you have to use the virtual maschine parameter Djco.allow_non_abap_partner=1 in your jco server. In combination with the nwa Resource Adapter mentioned by Jan this should work.

Let me know if this help.

Martin

[juliocesar_leyva · Accepted solution]

Hi Martin!

In our case we are running in PI 7.11 SP09 release and have the same scenario SAP.IDOC-->PI--->NON-SAP.IDOC with a certified SAP external solution.

Our problem is the IDoc metadata lookup.

In our tests, we saw that JCo Server is executing internally the "IDOCTYPE_READ_COMPLETE" function, but of my PI System not of ECC sys, where are defined this metadata. What is missing here in our configurations? (We have the IDoc metadata imported via IDX2 from our source system and we have copied it into the NON-SAP port LS as the documentation describes)

In this PI release, we have an ABAP stack and therefore this "retrieve" of metadata is pointed to the Abap stack, but only with IDocs created in the PI ABAP Stack, thus, if we develop a custom "Z" IDoc we need to create the same structure into PI ABAP system(WE30, WE31)?.(I think it's the wrong way)

From the NON-SAP App  side, we have configured an RFC Destination pointed to PI system as the documentation, but when receives the IDoc  it rases an error "OBJECT_UNKNOWN- IDoc metadata not available". (note: we have all authorizations)

Finally what I'm doing wrong?

Regards!

[Former Member · Accepted solution]

Hi Julio,

When sending or receiving IDocs (via JCO), you need to have an ABAP repository to check the IDoc XML against.

If you are using a customized IDoc, you will need to have this defined in one of your ABAP systems (maybe ECC in your case as that sounds more logical than in PI ABAP).

In your non-ABAP application, you need to point to this ABAP system:

You will need a regular jcoDestination configuration pointing to your ECC system (say "ERP_100"), and in your jcoServer configuration, you will need to point to the above jcoDestination with parameter jco.server.repository_destination=ERP_100.

Kind regards,

Jan Van Achte

[martin_pichlo · Accepted solution]

Hi Julio,

in fact that is exactly what we did. As result your non-sap system need two connections: The first to receive the meta data directly from your sap ecc (may the one which will receive the idoc later) and the second to transfer the data to the pi (which may transfer the idoc to the sap ecc mentioned in step one). This is very poor for several reasons: First you will need to modify the source of your non sap system to implement the additional connection. And moreover it makes simple no sense from a network, security _and_ middleware perspective.

You wrote that you have configured the rfc connection to receive metadata from erp. I agree with you that the pi should provide an service using this connection to provide idoc metadata from sap ecc to external systems. Unfortunately this is not implemented yet. May you could create a ticket for that? Some month ago we have a similary problem creating the TID, which is implemented in pi now.

Cheers

Martin

[Former Member · Accepted solution]

Hi,

i encountered the same problem:

i need to establish a connection from non-sap-system (jco3) to registered Server Programm.

Using JCo3 ist seems impossible to do so without having a second connection.

Unfortunatly this is not in every case a possible solution. In my case i don't have the option for another connection. Security and middleware perspective is another point why it should be possible to do without another connection.

Can anybody say what is current state? Will there be another update to JCo, so a connection similar to classic c-sdk will be possible (single connection)?

Or is there already a solution?

Cheers,

Tom

[MarcFilella · Accepted solution]

Hi Tom,

until now, no news about.

I'll try to check with SAP to know if there are some news about ...

Best regards.

Marc Filella

[Former Member · Accepted solution]

Hi Marc,

thank you for your quick reply and efforts.

i'll wait for your updates ...

Cheers,

Tom

[martin_pichlo · Accepted solution]

Hi Tom,

I absolutely agree with your arguments regardings a second connection. But it's the only workaround I know. May you could create a ticket to clearify this with SAP.

Here some details for this purpose:

Approach 1: Avoid modifications in every single program

From my point of view the idea behind JCO 3 is, that a program like the following could send Idocs to PI:

//PI-Destination
JCoDestination destination_pi=JCoDestinationManager.getDestination("PI");
String tid = destination_pi.createTID();
...


//Read Metadata with PI-Destination
IDocRepository iDocRepository = JCoIDoc.getIDocRepository(destination_pi);
...
//Send IDoc to PI-Destination
JCoIDoc.send(doc, IDocFactory.IDOC_VERSION_DEFAULT, destination_pi, tid);

Because the PI don't have an own metadata repository the following parameter in PI.jcoDestination points to an own destination which contains all details how to connect to the ERP system:

...
jco.destination.repository_destination=ERP
...

Unfortunately this doesn't work, because JCO is ignoring the mentioned line in PI.jcoDestination.

As a result you need a workarround like the following:

//PI-Destination and TID
JCoDestination destination_pi=JCoDestinationManager.getDestination("PI");
String tid = destination_pi.createTID();

//Read Metadata with new ERP-Destination
JCoDestination destination_erp=JCoDestinationManager.getDestination("ERP");
IDocRepository iDocRepository = JCoIDoc.getIDocRepository(destination_erp);
...
//Send IDoc to PI-Destination
JCoIDoc.send(doc, IDocFactory.IDOC_VERSION_DEFAULT, destination_pi, tid);

From my point of view this behavior is a bug wich should be solved. BUT: This is not a solution for the mentioned security issues, because the program is still using two connections.

Approach 2: Avoid ERP connection

To avoid the ERP connection a solution could be the implementation of the function IDOCTYPE_READ_COMPLETE within the PI by SAP. This function could may use the default destination XI_IDOC_DEFAULT_DESTINATION and simple pipe through the request to the ERP internally.

Hope this helps! Please keep me up to date if you get any response from SAP.

Cheers

Martin

[juliocesar_leyva · Accepted solution]

Hi all,

I think we must to move this discussion to another thread. (There are no more room for posting)

Here an update.

We opened a ticket to SAP support and they exposes the following points:

1.-Your external application is certified to run with an application R/3 backend and not with an SAP XI/SI server.

2.- The external application must configure to import IDOC Metadata into de java runtime metadata cache from an external  IDOC R/3 server and not from the caller XI IDoc Adapter.

3.- They forwarded the incident to XI Development support. (I hope they work on a solution)

From the security and middleware point of view this is a poor workaround (as Martin said)  but there is not another way to deal with this problem.

Also, we expose to SAP the possibility of importing IDOC definitions into PI (WE30, WE31) and they told us that there are implications on that, regarding on the DDIC structures dependencies and object releases conflict. We agree with SAP that isn't a best practice. (by the way, we run a PoC with this option and it works fine)

Finally even the security and orthodox middleware concept we ask to provider to perform the modifications (maintain two data connections).

This modifications are as well supported by JCO API and doesn't need a lot of development effort. (the ugly workaround).

For the first part (my java app receives IDocs) you must configure your parameter files (*.jcoServer and *.jcoDestination) as follows:

Jco server file:

jco.server.progid=MY_PROGID
jco.server.name= ( your PI service name)
jco.server.gwhost= (your PI service host)
jco.server.gwserv= your PI gateway service port
jco.server.connection_count=5
jco.server.repository_destination= ( a meaning repository name for metadata)

Jco destination file (IMPORTANT same name as jco.server.repository_destination property)

jco.client.type=3
jco.client.client= R/3 client
jco.client.user= R/3 user
jco.client.passwd= R/3 pwd
jco.client.lang=en
jco.client.ashost= R/3 host name or IP address
jco.client.sysnr= R/3 system number

In this part, JCO uses the server connection data to reach PI system and when it receives an IDOC, then internally uses the client connection to R/3 for metadata lookup.  In our PoC tests it works without problem.

The second part (app sends IDoc), you must configure two different *.jcoDestination files and modify the java client, as follows:

1.- create PI destination file with the parameters:

jco.client.type=3
jco.client.client= PI client
jco.client.user= PI user
jco.client.passwd= PI pwd
jco.client.lang=en
jco.client.ashost= PI host name or IP address
jco.client.sysnr= PI system number

2.- create R/3 metadata destination file with the parameters:

jco.client.type=3
jco.client.client= R/3 client
jco.client.user= R/3 user
jco.client.passwd= R/3 pwd
jco.client.lang=en
jco.client.ashost= R/3 host name or IP address
jco.client.sysnr= R/3 system number

3.- In your java client code you should have some like this:

JCoDestination destination = JCoDestinationManager.getDestination( rfcPIDestination);  // PI destination
JCoDestination destinationMetadata = JCoDestinationManager.getDestination( rfcECCDestinationMetadata);  // R/3 destination
IDocRepository iDocRepositoryMetadata = JCoIDoc.getIDocRepository(destinationMetadata);
String tid = destination.createTID();
IDocFactory iDocFactory = JCoIDoc.getIDocFactory();
IDocXMLProcessor processor = iDocFactory.getIDocXMLProcessor();
IDocDocumentList iDocList = processor.parse(iDocRepositoryMetadata,iDocXML);
JCoIDoc.send(iDocList, IDocFactory.IDOC_VERSION_DEFAULT,destination, tid);

4.- Don't forget to maintain SM59 destinations.

I'm sure that this will don't help if you have only one connection available (only PI system) for security reasons, but I like to share all the implementations details. Maybe you can agree with your security team to open the second connection port and follow this steps.

Best regards to all.

Julio C.

[Former Member · Accepted solution]

Hi all,

small update:

SAP just confirms this is a bug and a fix is in work.

Details can be found here in the comment section.

Best regards

Tom

[martin_pichlo · Accepted solution]

Hi Tom,

do you have any news regardings your mentioned bug?

Best regards

Martin

[Former Member · Accepted solution]

Hi Martin,

nothing new. Fix is ongoing.

Some infos are here:

Best regards,

Tom

[Former Member]

Hi all,

just small piece of information:

SAP DEV Team did great work.

Bug is fixed and will be published in next jco release!

Til then you may want to grab latest JCO Hotfix ...

Best regards,

Tom

[martin_pichlo]

Hi Tom,

do you have some more details about the fixes?

Best regards

Martin

[Former Member]

Hi Martin,

well, calling external programs is now working. A Bug regarding within the Repository has been fixed. You need to create your own function template, when no "ABAP-Connection" is provided.

Another enhanced is the support for stateful "external" connections ...

That's it .

Greetings

Tom

[martin_pichlo]

Hi Tom,

do you have an url with some more details regarding this fixes? Or even better some source code examples? By the way: Where did you got your information?

Cheers

Martin

[Former Member]

Hi Martin,

Just go to download site of jco and then grab hotfix.

Information is direct from sap team.

There's nothing to change in existing code, as a bug has been fixed and now it should work like intended. So setting destination is enough. See

Cheers

Tom