[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:
How can I handle the repository's parts which needs a more empowered user than that who launches the policy?
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
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?
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?
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
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