SAP JCo3 : Initialization of repository destination 'ABAP' failed - No logon data provided for JCoCustomDestination#getRepository()

[Former Member]

I'm currently working on an SAP external project which aimes to get data from SAP via SAP JCo3. I've read the SAP JCo3 JavaDoc and development went just fine until I encountered an issue when I'm trying to get repository data from an JCoCustomDestination.

I implemented a custom DestinationDataProvider and registered it in the JCo Environment. The DestinationDataProvider works just fine and I'm able to get my JCoDestinations from the JCoDestinationManager. Due to the fact that the JCoDestination objects do not contain any logon data, I have to use JCoCustomDestination objects with different logon informations.

JCoCustomDestination#ping() works just fine, if the JCoCustomDestination.UserData object was filled correctly. Now I'm getting some trouble when I try to execute JCoCustomDestination#getRepository() which fetches the JCoRepository (meta data) for the underlying JCoDestination.

I'm getting the error: Initialization of repository destination 'ABAP' failed.

The detailed error message tells me that neither logon information (username +  password) nor a certificate is provided. But in fact they are (in JCoCustomDestination.UserData). When I'm trying to check this via JCoCustomDestination#getRepositoryUser() my configured username is returned.

Why the hell does the JCoCustomDestination#getRepository() not pass the configured JCoCustomDestination.UserData for retrieving the JCoRepository to the underlying JCoDestination? If this behaviour is intended, why does JCoCustomDestination#getRepositoryUser() return my configured user although this logon is not used for fetching the JCoRepository?

I know about the workaround to maintain a repository user, but this will only work for users with username + password or certificates but not for MYSAPSSO2 tickets. Just guess what most of our users use for login? MYSAPSSO2 tickets.

So there seems to be no other option than maintaining a seperate repository user (a user that needs no permission in SAP except for fetching repository information) and configure it in the application.

Changing the logon information inside the JCODestination would be another option but this won't work for us, because changing the information of the JCoDestination requires to trigger the DestinationDataEventListener which notifys the JCoDestinationManager and the JCoDestinationManager would invalidate the existing JCoDestination and create a new one. This could lead to an unexpected behaviour in a multi user context with multiple threads (race conditions... bla bla).

So my question: Is there any way to fetch the JCoRepository information with an JCoCustomDestination without maintaining explicit logon data inside the underlying JCoDestination?

[HAL9000]

Hi Sebastian,

I would go that far to say that your desired approach with always using a business application user's logon data (SSO2 ticket) for repository meta data queries is a design error from security perspective.

Because the precondition in a generic approach like yours is, that really all users need to have the authorizations for the DDIC repository queries then.

But why for example should get a non-technical user who maybe is only responsible for processing some specific business workflow get access to all technical DDIC data of an ABAP system? If this would be no problem, why not giving administration authorizations to all users?

As you can see, there is usually a reason why the JCo framework design is like it is. This design often prevents developers from making some fundamental bad decisions and errors.

I don't see why it should be such a NO-GO that a system administrator has to define one single(!) technical repository user ID and password or one single(!) additional configured JCoDestination for repository queries only where he is able to restrict the needed authorizations to a minimum requirement only.

By the way, you may also use MYSAPSSO2 tickets for this but as these tickets have an expiration time you would have to take care and update it to a valid one in time. It is not advisable to use assertion tickets for this.

Best regards,

Stefan

[MarkusTolksdorf]

Hello Sebastian,

Standard repositories cannot make use of a JCoCustomDestination as a connection provider. This is actually intended as you already assumed. If JCoCustomDestination#getRepositoryUser() returns the adjusted user from your custom destination, then this could be considered a bug, even if the destination is definitely not used within a standard JCoRepository.

The way to go is actually already mentioned by you: Provide the explicit logon data in the parent JCoDestination - and make the user as week as possible: For details about the minimal permissions are available in note 460089.

Alternatively, you could also use a JCoCustomRepository and set a JCoCustomDestination with setDestination()  to it for the metadata lookup. However, with that approach you would have to take care yourself to share the repository between different users and the original user will be used for the lookups all the time.

One last remark: with your bla bla approach you are absolutely right - this won't work in multithreaded applications you will get outdated invalid destination instances all the time. Nevertheless, there are people that are trying this again and again ...

Best regards,

Markus