Skip to Content
Can/should you store passwords in user defined functions ? (for example for JCO calls).
You should never do that, why:

1) because you will need to change the pass when your landscape will change (from DEV to QAT to PRD)

2) because everyone who will be able to open your mapping will be able to see the password if you store it in plain text

3) because you may need to change the password from time to time

So is there any alternative ? Maybe a standard one?
Secure Storage Service is one of the possibilities. It’s a place where you can put your passwords.

Step 1

Import necessary libraries as External Archives into your Integration Repository:

tc_sec_securestorage_service.jar
which can be found in: \j2ee\cluster\server0\bin\services\tc~sec~securestorage~service

and

frame.jar
which can be found in: \j2ee\cluster\server0\bin\system

Step 2

Create a user defined funtion in your Message Mapping with the code as shown below:

Make sure you will those libraries into import section of your UDF:
com.sap.security.core.server.securestorage.*;javax.naming.*;com.sap.engine.frame.state.*;
java.rmi.*;com.sap.security.core.server.securestorage.remote.*;com.sap.security.core.server.securestorage.exception.*;

If you create the object in Secure Storage you will see it it there directly after creation:

image

Step 3

And when you execute your function you will that the value was successfuly restored.

image

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Adalbert Wysocki
    Hi Michal,

    Nice blog, and this secure storage could be used in a couple of use cases.

    But I see 2 issues:

    * You need to implement an external app for storing the password and being deployed on the same app sever with the same data source. Another solution would be to have a special custom “configuration” mapping that you could run once at configuration time to initialize the pass… but it sounds like workaround. Do you have a suggestion for this configuration phase?

    * I am wondering if the JCO example is a good inspiration for best-practices as from an architectural point of view, the Adapters should be used to represent the EIS connection.
    The adapter framework with the metadata has the support for parameters secure storage.

    I do not think that UDFs are there for this kind of processing even if you can do whatever you can in the java code.

    It is the paradigm of JSPs. You can write any java code you want in your JSP but it is better to separate the data model, the controller and the view and have well architectured and maintainable applications.

    Cheers,
    Adalbert

    (0) 
    1. Henrique Pinto
      Adalbert,

      just to comment, theres no JCo here per se, only a simple lookup in the J2EE services.

      Regarding architecture, you are probably right about using a different one (maybe an EJB to do the password handling would be better).
      But I think the main point of the blog was to let people know of the possibilities, and I think it does that well. 🙂

      Regards,
      Henrique.

      (0) 
  2. Nilesh Taunk

    Hi Michal,

    I wanted to ask a question on this old blog that was posted by you. We have a similar requirement of storing data securely within PI and I was planning to use the Secure store for this purpose. My current PI version 7.4 single stack ,I have used the same code mentioned above and it  works in the 7.4 as well. But we are not able to view the secure store entry which has been created on the server via the code  . You have provided a screenshot of a view above which shows a graphical view where we can see the entry “pass” created . In the new PI 7.4 version do you know where can we see a simila entry . Can we see entries like these via NWA .

    And besides Secure Store option , Do you know if we have any other new feature in the new version (7.4) that can be used to store data securely.

    Regards

    Nilesh.

    (0) 

Leave a Reply