[RAM 7.5.1] Redefining RAMSession on PolicyContext
Hi all,
The new resources available on RAM 7.5.1 have been solved lots of old problems that I experienced on older versions. Before I used to put the RAM API (ramclient.jar) as a WAS shared library to get advantages against the rest available methods, although its not supported. Now the API is part of policy context and almost all things which I've made with policies works fine. I've a policy which updates an attribute that have a specific user who can update its values, as before I created a session using RAMSession(host, USER, passwd) and I was able to defined this USER as a user who had the permission to changes. Now I tried to redefine the RAMSession on the policy context but I got follow error: java.lang.ClassNotFoundException: com.ibm.ram.internal.client.RAMClient How can I handle the repository's parts which needs a more empowered user than that who launches the policy? |
3 answers
RAMSession(host, USER, passwd) and I was able to defined this USER as There is a difference between a RAMSession against the current RAM and trying to access a different RAM. The RAMSession that is now returned from the policy is a session that is automatically connected to the local RAM. It doesn't use TCP/IP to do anything. Instead it has an internal wrapper that redirects all of the requests to the internal code directly on the server on which the policy is running. If you are trying to update an asset in the current RAM you don't need to connect as a different user. The RAMSession returned from the policy is already connected as a repository admin and has fully authority to do anything. The assumption is that since policies are installed by the Repo Admin that the admin is aware of the fact that the policy can do anything and so has given the blessing to do so. To support accessing a different RAM still requires an entire RAMClient to be included in the policy itself so that you can access a different RAM. -- Rich Kulp Rational Asset Manager developer |
|
Hi Rich,
In fact I'm not trying to access another RAMServer, its the same server. The problem is that the attribute being modified is configured to be changed by a determined user. This determined user in our environment is a 'service user' who is an repository admin too. As the RAMSession on policy context run as Admin Repository there a possibility to defined the Admin Repository as a user allowed to make changes in this attribute? Or better develop a policy which will be executed by a pre-defined user? |
|
The policy runs as a Repository Process Admin user. This is a functional
user that no one can log in as. But this user is a Repository Admin, which means it can do anything. There is a defect that prevents attributes that have a restricted update user set on them from being updated by policies. This is https://jazz.net/jazz02/resource/itemName/com.ibm.team.workitem.WorkItem/62195 It is fixed for the upcoming 7.5.1.1 release so that policies can update such a field. -- Rich Kulp Rational Asset Manager developer |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.