JCO RFC Provider configuration - generally understanding

[Former Member]

We have PI 7.11 (Dual Stack)

In NWA JCO RFC Provider there are a lot of entries which point in tab Server Configuration to PI Gateway and in tab Repository Configuration to any applicationserver of ABAP system in our landscape. SysNr, Client and user credentials belong to the abap system.

I can stopp and start the programs in NWA.JCO configuration.

In SMGW of PI I can see, that the programs are registered at PIs gateway.

If an ABAP-System, mentioned in Repository Configuration of JCO entry, is down, then the JCO server can't be started.

For what reason one would create such JCO entries?

In my oppinion gatway and applicationserver in a JCO entry should point to same system. Usually to PIs gateway and applicationserver.

Is there a reason why SAP spread the entries to different tabs?

[Former Member]

I have deleted all these mysterious JCO RFC Destinations, in which GatewayHost was PI Gateway and ApplicationserverHost was Applicationsverver of any other ABAP system.

SM59 Destinations of ABAP systems I have pointed to ProgramID_<PI-SID> at PI Gateway.

Everything seem's to work fine.

[former_member265504]

Hi Ronald,

As far as i understood your question you wanted to know why the JCO connection,JCO entry is necessary & why the entry for gateway and application server.

to answear your first question-

example- if user want to view payslip in EP there is an iview for that wherein the JCO connection name to your backend ECC system is mentioned in iview object details so if that JCO connection is not working he wont be able to view his salary when he clicks on the iview.

In summery-The JCO connection details contain the details of the system to which you need to connect.

and regarding the two different entry for message server and application server-

When you try to create a JCO connection for the first time it will ask if you would like to create the connection for load balancing or without load balancing.Accordingly if you choose with load balancing the Message server details entry becomes important and application server entry doesnot hold any relevance & vice versa for connection without load balancing.

Thanks,

Rajdeep

[Former Member]

By my understandig JCO is for providing RFC functionality by AS-JAVA.

But JCO doesn't implement the function of RFC-Gateway itself.

JCO needs a running RFC-Gateway of an ABAP system or a standalone RFC-Gateway and has to register all the functions, which shall be reachable per RFC, at the Gateway.

The functions (ProgramID) JCO will register at Gateway are prepared in NWA JCO RFC Provider.

All settings made for a JCO RFC Destinations are for registration at the gateway not for using the function.

Therefore gateway and applicationserver settings in one JCO RFC Destination should belong to same system, in my opinion. If system uses more than one applicationserver, then there may be a difference between gateway host and applicationserver host.

Am I right so far?

At our PI someone has configured JCO RFC Destinations in which Gateway and Applicationserver point to different systems, which don't belong together.

In principle these JCO RFC Destinations seem to work.

But I don't understand the reason for these settings.

By my understanding of JCO these settings are false and I would expect that they wouldn't work at all.

Perhaps they work because in all cases RFC Gateway of PI was used.

[former_member265504]

Therefore gateway and applicationserver settings in one JCO RFC Destination should belong to same system, in my opinion. If system uses more than one applicationserver, then there may be a difference between gateway host and applicationserver host.

Hi,

Is your PI system in distributed landscape.If its in distributed landscape and if you have installed ASCS or your message server resides in different instance which is on another server then the gateway details will be the server details of your server where the MS and GWD resides  and application details will be different.

Thanks,

Rajdeep

[Former Member]

Our PI is not in distributed landscape.