Customers store the credentials to access external systems in one place because
1. They don't want every method to store the password
2. Keep the secret password in a separate domain which doesn't get shared
3. By storing the information in a separate domain it can be easily overridden
This article shows you how to keep the userid password in automate models and access it from Automate Methods.
In a new domain you can add some namespaces, classes and instances.
In this example I am using a
Namespaces : Global/Credentials
This class has 3 variables userid, password, bind_dn
You can have whatever attributes you want in here
You can set the attributes in the instances and modify them and the automate methods would pick up the correct updated values.
When I need to use the credentials in one of my methods, I would ensure that I can first resolve the credentials using the relationship and use collect to pick up the attributes.
In my class I have a relationship called credentials (you can call it whatever you want) which connects to /Global/Credentials/LDAP/Basic.
Please note that it doesn't include the domain name, so that we can override the credential at runtime from different domains. If you include the domain name, then the instance cannot be overridden at runtime from other higher priority domains.
The collect picks up 2 attributes userid and password from the object resolved via the relationship.
Collect has the ability to use the attribute name as defined in the child object or call it something else. In the above example the collect looks like
user = userid; password = password
Which basically says
- From the child object fetch userid and add an attribute in the current object called user.
- From the child object fetch password and add an attribute in the current object called password.
At this point the current object has the 2 new attributes user and password which didn't exist in the original schema.
Then in my method I can use something like this