-1

I need to create a program, which resides on the client PC, gets executed from SAP LOGON, receives some RFC requests, returns data and terminates.

I've been following this tutorial on how to implement a JCo server:

https://blogs.sap.com/2017/08/25/sap-jco-server-example/

I configured the JCo connection properties according to the tutorial. My program gets executed, but SAP fails to send any RFC requests to it and ends on a timeout.

I noticed that my program gets executed with the following arguments:

/H/gd9.company.com, sapgw02, 87945336, IDX=4

I guess this is SAP telling me configuration values for the RFC connection. I mean, I shouldn't have them static (like in the configuration file in the tutorial), but rather use the values from the arguments.

The first one should be the host (jco.server.gwhost), although I don't understand why its prep-ended with /H/. She second one is probably jco.server.gwserv.

But what are the other two parameters? Should I use them to configure the RFC connection in some way?

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
Jardo
  • 1,939
  • 2
  • 25
  • 45

4 Answers4

1

In SM59 you can setup a destination of type "T" in several different ways:

  • registered server (with a program ID)
  • started server (with the name of an executable to start). This comes in several different flavors: start on application server host, start on gateway, start on frontend PC and some others, if I remember correctly.

In the first case ("registered server"), the connection already exists (it was created by the server program, when registering under the given program ID), and the SAP system simply sends any RFC request for this destination over this open connection.

In the second case (started server), the mechanism is completely different. The SAP system first generates a unique ID (CPIC conversation ID), tells the gateway to start listening for an incoming connection with that ID, then starts the given executable and tells it to open a connection with exactly that ID. When the gateway reports, that someone with that ID has indeed opened a connection, the SAP system finally sends the RFC request over it. The executable is started in several different ways, depending on the "flavor" of the destination: via fork ("start on gateway"), via remote shell ("start on a given app server host") or by sending the name of the executable and the start parameters back to SAPGui over the currently open DIAG connection connecting SAPGui with the current ABAP side user session. SAPGui then starts the executable with the given parameters ("start on frontend PC").

As Trixx already said: JCo3 only supports the registered server, but not the started server. If you need an RFC server of that type (e.g. because you want to have it started on the frontend PC via SAPGui), you will need to write either a C/C++ program using the NetWeaver RFC Library or a .NET program using NCo3. Both, NCo3 as well as NW RFC Library provide the necessary functionality for a started server. (See their documentation.)

Lanzelot
  • 15,976
  • 4
  • 18
  • 14
0

JCo 3.0 does not support started RFC server programs but only registered ones, where the startup initiative comes from the Java side.

You won't get this start RFC server scenario to work with JCo.

Only a workaround would be imaginable with starting some non-Java program like a command shell script whose purpose is only to start the JCo server program which would then register itself at the gateway with some pre-defined program ID. Afterwards you can use a second destination from ABAP side that is configured to use this registered RFC program ID then. Not nice but currently the only way if you need to stick to Java.

Edit (Jan 10, 2018):
I think the four parameters that you get are:

  1. GWHOST (SAP gateway host prepended by a SAProuter string)
  2. GWSERV (SAP gateway service as symbolic service name)
  3. CONVID   (CPIC conversation ID being used)
  4. IDX           (CPIC connection index specifying some SAP internal data structure being used)

There is no API in JCo 3.0 where to pass these values, i.e. especially the arguments no. 3 and 4. But this is required to get a started RFC server program scenario working. The difference compared to a registered RFC server program scenario is, that for a started RFC server program the CPIC connection has already been opened by the gateway and this existing CPIC connection needs to be used, i.e. the RFC server has to attach itself to this existing connection.

Trixx
  • 1,796
  • 1
  • 15
  • 18
  • whats the difference between the java program being started directly or via shell script if the java program does the same thing (register itself somewhere) ? – Jardo Dec 08 '17 at 11:40
  • @Jardo: Counter question: Which executable name do you enter in the SM59 destination as the program to start? – Trixx Dec 08 '17 at 20:17
  • . hcterm5rfc.exe – Jardo Dec 11 '17 at 12:26
  • @Jardo: And hcterm5rfc.exe is Java program using JCo 3.0? I am confused. – Trixx Dec 11 '17 at 13:37
  • Yes its a java program packed as exe. Where arre you going with this? – Jardo Dec 11 '17 at 13:55
  • @Jardo: OK. In this case you don't need a shell script to start a Java program. I was assuming that a script needs to be used for starting the Java program. Nevertheless you cannot use the provided arguments to get back to the ABAP system and fulfill the startup request. As said: JCo 3.0 only supports registered RFC server programs. There is no parameter key with which you would be able to pass the last two arguments ("87945336, IDX=4" from your example). – Trixx Dec 11 '17 at 14:49
-1

I think these PDF materials will be useful for you ..

SAP Business Connector Migration Guide

SAP Connector Installation & User Manual Guide

SAP Java Connector Introduction, Design and sample codes

syam
  • 106
  • 2
  • 9
-2

I have no idea what the IDX=4 means but the first three arguments look like the required values to set up a JCOServer (host, port, program id). I never set up something else than a TCP destination so I might be wrong about this but you could try to set up a JCOServer with these three parameters and look what's happening next. I imagine that SAP creates a dynamic TCP destination and waits for you to connect this way. After that an RFC is called.

Problem with the RFC-call is that you need to set up your RFC server with a fitting repository meta data for that particular RFC, so most likely after setting up the server the SAP system will still fail to send the data. The error message on the SAP side should tell you what RFC call was attempted, alternatively set up your JCOServer with trace messages (another property you can set) to find out what's happening "on the wire" and go on from there, i.e. create the meta data, add it to the server's repository before connecting, etc.

BTW: You might be required to use the numeric port value instead of the alias (here sapgw02) because in difference to JCo 2 that mapping doesn't always work with JCo 3 (it didn't work for exotic values with JCo 2, either)

Lothar
  • 5,323
  • 1
  • 11
  • 27
  • JCo RFC server programs cannot be started from ABAP side. Period. This is not supported by JCo 3.0. Only registered RFC server programs are supported. A program ID is specific to registered RFC server programs. – Trixx Jan 09 '18 at 11:21
  • @Trixx I haven't said anything like that just tried to make sense out of the arguments being passed to the program being called by SAP. If you can explain the meaning of these four arguments, I'd be happy to learn something new today. – Lothar Jan 09 '18 at 11:40
  • I added some info to my answer. Please see there what I think what these parameters are for. – Trixx Jan 09 '18 at 15:48