cancel
Showing results for 
Search instead for 
Did you mean: 

Can a JCo server simulate a SAP remote function?

Former Member
0 Kudos

Gentlemen,

we want to test the behaviour of a system that connects via RFC to a SAP server. Instead of calling the remote function, we want to have the system call a test dummy of this function, a mock-up that we can control. We want to avoid creating the test dummy in the ABAP environment.

Is it possible to set up and deploy a JCo server that has the same calling interface as a BAPI?

Can I call this server from a JCo client, thus, simulating the execution of BAPI function?

I appreciate yout hints to find a solution.

Regards

Johannes

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Johannes,

well, this so called RFC extern-to-extern communication is officially not supported by SAP.

The SAP Java Connector (SAP JCo) is a toolkit that allows a Java application to communicate with any SAP System.

Obviously there is no SAP system in your desired scenario. Technically it works with some restrictions with JCo 2.1 and does not work with JCo 3.0. The most obvious restriction in JCo 2.1 is that each connection will be automatically closed after each RFC request, therefore stateful communication is impossible. Another one is that the tRfc does not work as expected since none of the communication partners is able to create TIDs. And of course, you would still need a SAP gateway where the RFC server must register itself.

If you may live with these limitations, you may simulate your calls with JCo 2.1, but to say it once again clearly:

There is no support from SAP and using JCo 2.1 this way is at your own risk.

Answers (2)

Answers (2)

roman_scholz
Explorer
0 Kudos

Hi Johannes,

even if this thread is about three years old, I would like to ask the question if you found a solution to simulate a SAP system.

We currently have a similar topic: testing the data received by a SAP function, without calling the function itself.

The data is sent by a JCO Client, the client normally calls a function module.

But we don't want to setup test data all the time, and we don't want to have the function module processing data.

So we want to simulate the function as usable in SE37 by setting the DESTINATION parameter.

Do you have any suggestions?

Thanks for your support and best regards,

Roman

Former Member
0 Kudos

Hi Johannes,

I think such a test is not possible, for the following reasons: It is impossible to have a JCo client program directly connect to a JCo server program. All communication is done via the SAP gateway and this cannot be bypassed.

Now, of course it's possible to create a JCo server program, which provides logic for handling an RFC function call (i.e. the mock-up for the actual RFC in your case). However, it seems impossible to execute the RFC on the JCo server from an external JCo client without any actual RFC module in SAP, which delegates the call (using an appropriate RFC destination).

In general I thought it might be possible, because there are connection parameters in class DestinationDataProvider (JCo 3.x) that seem suitable: jco.client.gwhost, jco.client.gwserv and jco.client.tpname (and even <em>jco.client.tphost</em>); furthermore you can even set a different connection to a repository. When I created a dummy server though and tried to run execute an RFC using those connection parameters, I got an exception complaining that connection parameter ashost is missing. When specifying this it then asked for sysnr, client and then complained about missing logon data; once I finally gave all the details it just executed the RFC directly within SAP...

I tried a variety of settings, but nothing seemed to work. Thus my conclusion is that creation of such a mock-up is not possible. However, let's wait for the expert's comments... <b>Stefan?</b>

Cheers, harald

p.s.: Maybe somebody can also shed some light on what those parameters jco.client.tpname, jco.client.tphost are used for (e.g. seems more reasonable in the ServerDataProvider context, like jco.server.progid and others).