on 02-14-2023 8:15 PM
I want to access an RFC function on sap from my java program.
When I call getDestination("connect")
I can connect and run my function without problems.
But I will have more than one config file because I will be connecting to different SAP servers.
I want to collect all of these files in one folder, but when I write getDestination("src/JcoDestinations/connect")
it does not read my config file that I put in the folder and does not connect.
How do I get all my connect jcoDestination config files together and run?
The error I get is this :
(106) JCO_ERROR_RESOURCE: Destination 'connect' does not exist. –
I tried:
<code>File file = new File("src/JcoDestinations/connect");
JCoDestination destination = JCoDestinationManager.getDestination(file.toString());
and:
<code>File file = new File("C:\\connect");
JCoDestination destination = JCoDestinationManager.getDestination(file.toString());
these did not work for me.
Hi Yiğit,
in addition to Markus reply I would like to stress that using the default implementation of the DestinationDataProvider (which reads from files <DestName>.jcoDestination) is not recommended for productive scenarios.
This is what the JCo JavaDoc says:
For security reasons, the default implementation of the DestinationDataProvider
should not be used
in productive environments. This default implementation stores sensitive user logon credentials as unsecured
plain text in property files (<DESTINATION_NAME>.jcoDestination
) in the current working directory.
Although at least passwords are getting obfuscated automatically on their first usage, this is still no real
encryption or secure storage for user credential data. Everyone having read access to these property files
would be able to use the therein contained user credentials for logging on to the respective SAP back-end
system under this user identity with also obtaining all authorizations of this user.
The default DestinationDataProvider
implementation is only offered for quick development purposes
and prototyping. It might also be tolerable for being used in test scenarios with SAP back-end systems
which do not contain any critical or confidential data. However, in productive scenarios one should always
register and use a custom DestinationDataProvider
infrastructure component, which is capable of
storing sensitive user credential data in a secure storage.
Best regards,
Stefan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Yiğit,
the defaullt implementation for the DestinationDataProvider uses the process work directory as a location for all destinations (file extension needs to be jcoDestination, the file name the name of the destination). Assume you have the files MyDest1.jcoDestination and MyDest2.jcoDestination, then you can access them using
JCoDestination destination = JCoDestinationManager.getDestination("MyDest1");
and
JCoDestination destination = JCoDestinationManager.getDestination("MyDest2");
No need to provide a path for the destination, only the destination name needs to be used
Best regards,
Markus
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Markus, thanks for replying.
I know i can use different target files as you wrote, but these files need to be in the working directory.
I want to collect all these jco files in a folder and use these files from within this folder.
But i cant do it, because getDestination method is not allow writing path, it's only allows file name.
Thank you.
Hello Yiğit,
you do not provide a file name, you provide a destination name and the implementation of the DefaultDestinationDataProvider simply uses the work directory to search for files following the naming scheme it expects. If you need some different behavior, you should implement your own DestinationDataProvider, which is anyway strongly recommended for productive environments as outlined by Stefan in his answer.
Best regards
Markus
" The default DestinationDataProvider implementation is only offered for quick development purposes and prototyping. It might also be tolerable for being used in test scenarios with SAP back-end systems which do not contain any critical or confidential data. However, in productive scenarios one should always register and use a custom DestinationDataProvider infrastructure component, which is capable of storing sensitive user credential data in a secure storage. "
🙂
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
86 | |
11 | |
8 | |
7 | |
7 | |
6 | |
6 | |
6 | |
6 | |
6 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.