cancel
Showing results for 
Search instead for 
Did you mean: 

WD JCO SSO ticket not working

Former Member
0 Kudos

Hi,

The following error message keeps following me:

com.sap.mw.jco.JCO$Exception: (102) JCO_ERROR_COMMUNICATION: JCO.Client not connected in repository call

This message gets displayed when I push the test button of a newly created JCO Connection.

The WD application in question uses two JCO Connections who connect to the same SAP backend system.

The JCO for metadata which is set to use usr/pwd logon method does work, however the one which is set to use ticket (saplogonticket) doesn´t.

The fact that the other JCO works tells me that SLD configuration is correct, as a matter of fact the ping-test of the problematic JCO also works.

I´m logged on to the WD Content Administrator with a username which is also present on the backend so that shouldn´t be the problem either.

Another thing I find strange is that the exception group "JCO_ERROR_COMMUNICATION" will occur in case of some system unavailability due to network/gateway/router issue.

But if that´s the case than the other JCO test should also fail.

On top of that I checked if host / port was known and this also had possitive outcome.

commands:

ping [/code]

One thing I could do is set the trace level of JRFC/JCO/JRA, like described in

SAP Java Connector Problem Analysis Scenarios

but its not possible to use the configtool anytime soon because a request should be made to the technical team.

Another thing I was thinking that this could be a incompatibility issue?

  • J2EE WAS (JCO) is 7.0SP9 (NW2004s)

  • SLD also 7.0SP9

  • and the backend system: ECC5.0 WAS 6.40SP18

I checked Product Availability Matrix but didn´t find anything, as yet.

Anyone familiar with this?

Any suggestions?

What does "Client not connected in repository call" mean?

Regards.

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

I also made sure a logonticket was created by using a http analyzer tool.

A cookie with name "MYSAPSSO2" does appear.

Another thing that puts me of is the output of transaction SLDCHECK on the backend system.

.....
Testing the RFC connection to the SLD java client ...
RFC ping returned exception with message:
Error opening an RFC connection.

Summary: Connection to SLD does not work
=> Check SLD function and configurations
.....

But I guess this could only be problematic for XI?

If not how should I correct this?

Regards.

Former Member
0 Kudos

Wim,

Yes, "reverse" connection from backend to WebAS Java is necessary typically only for XI, not for "classic" ui-calls-backend scenarios.

The strange thing about repository means that JCO connection unnable to fetch metadata (information about structures, tables and their attributes' types).

I'm not sure what you are trying to do, but typically WD application uses Adaptive RFC Model that requires 2 connections: one for metadata, second for data.

The metadata connection commonly uses pre-defined user or user mapping. Can't even guess what happens if you set SSO here -- everyone should be able to access metadata and this is not very secure. On other hand data connection does use SSO in any real-life landscapes.

If you just trying to use plain JCO classes (rather then Adaptive RFC Model) then all above is of not help to you. Just check on backend that user may access metadata related functions from function groups RFC1, RFC2 and similar.

Valery Silaev

SaM Solutions

http://www.sam-solutions.net

Former Member
0 Kudos

Valery,

thanks for your reply.

I guess I can say we´re on the same page.

Indeed the case is that we use 2 JCO Connections, one for metadata and the other for application data.

It´s this second one were we want to use tickets so the user who is running the WD will get his relevant data from the backend.

If this JCO is set to connect with same usr/pwd from the other metadata JCO the JCO test will pass, but it should be set to work with ticket.

To answer to your other question about the user being able to access metadata: yes.

It´s maybe helpfull to describe our situation a bit more:

We´re migrating existing apps from old J2EE WAS with SLD to 2004s J2EE WAS with separate SLD and NWDI.

So the same JCO settings and front/backenduser is used, however with other result.

The front/backend user is <j2ee:Administrators:group/abap:SAP_ALL-SAP_NEW:profiles> so credentials shouldn´t be an issue. It wasn´t in the old situation so I guess it wouldn´t be in the new one?

Regards, Wim.

Former Member
0 Kudos

Wim,

After search I found the following post with the same problem description:

/message/2842807#2842807 [original link is broken]

Probably you also trap this pesky time-stamp problem...

The second link is about auth, you sure that this is not an issue, but anyway...

Valery Silaev

SaM Solutions

http://www.sam-solutions.net

Former Member
0 Kudos

Hi Valery,

thanks again.

/message/2842807#2842807 , like I said I´m pretty sure that authentication is not the cause... because the same user/credentials is used as in the old situation...

But I guess if it would be the cause then it would also become clear from the traces/logs were I can evaluate the tickets being accepted.

So again, can anyone guide me through howto get this information from the backend please?

Regards, Wim.