If you look at the signature for any FieldValue Rule it looks like this:
In reality, there are many more variables provided at run-time for users in order to use when generating their field values.
So if we take an example from a real world scenario, we get the following variables, if we use the trick from within a FieldValue Rule or the equivalent FieldValue script code associated with the Field in question:
optimisticProvisioning: String = false
objectRequest: AccountRequest = sailpoint.object.ProvisioningPlan$AccountRequest@4e8c79
field: Field = sailpoint.object.Field@e73a4f
plan: ProvisioningPlan = sailpoint.object.ProvisioningPlan@da6890
context: InternalContext = sailpoint.server.InternalContext@900f3
bsh: XThis = 'this' reference (XThis) to Bsh object: NameSpace: Bsh Object (bsh.NameSpace@a54415)
project: ProvisioningProject = sailpoint.object.ProvisioningProject@ae9c4e
bsf: BSFManager = org.apache.bsf.BSFManager@18cb57
noApplicationTemplates: Boolean = false
userPassword: String = password
link = null
application: Application = sailpoint.object.Application@13c7d2e[id=ff80808141cd69da0141cd69fb8a000d,name=LDAP]
log: Log4JLogger = org.apache.commons.logging.impl.Log4JLogger@10ee4c8
cn: String = Test.Test
identityName: String = Test.Test
group = null
operation: Operation = Add
accountRequest: AccountRequest = sailpoint.object.ProvisioningPlan$AccountRequest@4e8c79
source: String = LCM
current = null
disableRetryRequest: Boolean = true
dn: String = cn=Test.Test,ou=people,dc=training,dc=sailpoint,dc=com
sn = null
requester: String = spadmin
template: Template = sailpoint.object.Template@1073205
identity: Identity = sailpoint.object.Identity@1b70b7[id=ff8080814200c6e50143df96b76a1c5b,name=Test.Test]
role = null
The following variables can be grouped to show where they came from as shown here:
objectRequest: AccountRequest = sailpoint.object.ProvisioningPlan$AccountRequest@4e8c79
field: Field = sailpoint.object.Field@e73a4f
log: Log4JLogger = org.apache.commons.logging.impl.Log4JLogger@10ee4c8
context: InternalContext = sailpoint.server.InternalContext@900f3
link = null
application: Application = sailpoint.object.Application@13c7d2e[id=ff80808141cd69da0141cd69fb8a000d,name=LDAP]
identity: Identity = sailpoint.object.Identity@1b70b7[id=ff8080814200c6e50143df96b76a1c5b,name=Test.Test]
project: ProvisioningProject = sailpoint.object.ProvisioningProject@ae9c4e
operation: Operation = Add
group = null
accountRequest: AccountRequest = sailpoint.object.ProvisioningPlan$AccountRequest@4e8c79
current = null
template: Template = sailpoint.object.Template@1073205
role = null
These come from the workflow step arguments for the call that runs compileProvisioningProject. These can be seen in the "Identity Request Initlialize" workflow subprocess in the "Compile Project" step.
<Step action="compileProvisioningProject" icon="Task" name="Compile Project" resultVariable="project">
<Arg name="identityName" value="ref:identityName"/>
<Arg name="plan" value="ref:plan"/>
<Arg name="requester" value="ref:launcher"/>
<Arg name="source" value="ref:source"/>
<Arg name="optimisticProvisioning" value="ref:optimisticProvisioning"/>
<Arg name="disableRetryRequest" value="!ref:enableRetryRequest"/>
<Arg name="noApplicationTemplates">
<Script>
<Source>
boolean ignoreForms = false;
if ("ForgotPassword".equals(flow) || "ExpirePassword".equals(flow) || "PasswordsRequest".equals(flow)) {
ignoreForms = true;
}
return ignoreForms;
</Source>
</Script>
</Arg>
optimisticProvisioning: String = false
plan: ProvisioningPlan = sailpoint.object.ProvisioningPlan@da6890
noApplicationTemplates: Boolean = false
identityName: String = Test.Test
requester: String = spadmin
source: String = LCM
disableRetryRequest: Boolean = true
These are by prior fields in the Provisioning Policy (i.e. from the application template for create inside the LDAP application)
dn: String = cn=Test.Test,ou=people,dc=training,dc=sailpoint,dc=com
sn = null
userPassword: String = password
cn: String =Test.Test
These are native to beanshell and are present in the interpreter already.
bsh: XThis = 'this' reference (XThis) to Bsh object: NameSpace: Bsh Object (bsh.NameSpace@a54415)
bsf: BSFManager = org.apache.bsf.BSFManager@18cb57
Hi Chris,
Above Post explains workflow variables can be used in ProvisioningPolicy Field Value Rules.
Can you specify how can I make use of custom workflow variables in Provisioning Policy Field Value Rule?
Scenario : I have a Custom Workflow with some workflow input variables like RoleName and TicketNumber which will be passed by REST API Program (Holding them as inputs in my workflow)
I have a provisioning policy field value like primaryGroupDN which needs to be calculated based on RoleName, Can I make use of workflow input variables here ?If yes,How?
Right now, I am iterating through project, getting AccountRequests,Getting Attribute Requests for assignedRoles.
But is there any efficient way?
workflow variables are only passed into the compilation process for use in Provisioning Policy field scripts if you call the compileProvisioningProject workflow method as shown here:
<Step action="compileProvisioningProject" icon="Task" name="Compile Project" resultVariable="project">
<Arg name="identityName" value="ref:identityName"/>
<Arg name="plan" value="ref:plan"/>
<Arg name="requester" value="ref:launcher"/>
<Arg name="source" value="ref:source"/>
<Arg name="optimisticProvisioning" value="ref:optimisticProvisioning"/>
<Arg name="disableRetryRequest" value="!ref:enableRetryRequest"/>
<Arg name="noApplicationTemplates">
<Script>
<Source>
boolean ignoreForms = false;
if ("ForgotPassword".equals(flow) || "ExpirePassword".equals(flow) || "PasswordsRequest".equals(flow)) {
ignoreForms = true;
}
return ignoreForms;
</Source>
</Script>
</Arg>
Hi Chris
Always iam getting role value as null in the provisioning policy variables even though i requested for role in 7.1.?
Please clarify : objectRequest and accountRequest both the variables iam getting as accountRequest object? What is the maindifference between those?
Thanks
satish
You should be able to get access to the whole request in the project variable (sailpoint.object.ProvisioningProject) which will contain the compiled version of the plan (sailpoint.object.ProvisioningPlan.)
I just ran a test and the project contained the following informattion which includes the "role" information as well. Look for the MasterPlan section which shows the original request (containing the role request.)
Role request (along with entitlement requests and account requests) will always show up as an AccountRequest object within the plan. ObjectRequests are only for creating LDAP or AD groups (or other types of groups) in connected resources.
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE ProvisioningProject PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<ProvisioningProject identity="spadmin">
<Attributes>
<Map>
<entry key="noApplicationTemplates">
<value>
<Boolean>true</Boolean>
</value>
</entry>
<entry key="noCreateTemplates">
<value>
<Boolean>true</Boolean>
</value>
</entry>
<entry key="noFiltering">
<value>
<Boolean>true</Boolean>
</value>
</entry>
<entry key="noFilteringRetains">
<value>
<Boolean>true</Boolean>
</value>
</entry>
</Map>
</Attributes>
<MasterPlan>
<ProvisioningPlan>
<AccountRequest application="IIQ" op="Modify" targetIntegration="IIQ" trackingId="0398ffb3e49a4579801b5885817f24d0">
<Attributes>
<Map>
<entry key="provisioningTransactionId" value="ff8080815b7cbda1015b86bcb26b00d9"/>
</Map>
</Attributes>
<AttributeRequest assignmentId="a718da88b5ad4178b936ed854146711e" name="assignedRoles" op="Add" trackingId="0398ffb3e49a4579801b5885817f24d0" value="PRISM Super"/>
</AccountRequest>
<Attributes>
<Map>
<entry key="source" value="LCM"/>
</Map>
</Attributes>
<ProvisioningTargets>
<ProvisioningTarget assignmentId="a718da88b5ad4178b936ed854146711e" role="PRISM Super">
<AccountSelection applicationId="ff8080815b113bbb015b113bd5d5001b" applicationName="PRISM" selection="spadmin">
<AccountInfo displayName="spadmin" nativeIdentity="spadmin"/>
</AccountSelection>
</ProvisioningTarget>
</ProvisioningTargets>
</ProvisioningPlan>
</MasterPlan>
<ProvisioningPlan targetIntegration="IIQ">
<AccountRequest application="IIQ" op="Modify" trackingId="0398ffb3e49a4579801b5885817f24d0">
<AttributeRequest assignmentId="a718da88b5ad4178b936ed854146711e" name="assignedRoles" op="Add" trackingId="0398ffb3e49a4579801b5885817f24d0" value="PRISM Super"/>
</AccountRequest>
</ProvisioningPlan>
<ProvisioningPlan targetIntegration="Custom">
<AccountRequest application="Custom" nativeIdentity="spadmin" op="Modify">
<AttributeRequest name="groups" op="Retain">
<Value>
<List>
<String>group1</String>
<String>group2</String>
</List>
</Value>
</AttributeRequest>
</AccountRequest>
</ProvisioningPlan>
<ProvisioningTarget assignmentId="a718da88b5ad4178b936ed854146711e" role="PRISM Super">
<AccountSelection applicationId="ff8080815b113bbb015b113bd5d5001b" applicationName="PRISM" selection="spadmin">
<AccountInfo displayName="spadmin" nativeIdentity="spadmin"/>
</AccountSelection>
</ProvisioningTarget>
</ProvisioningProject>
Chris .
Thanks for your reply. Iam getting the role information inside the project when i requested as you mentioned above. My question is when i dump the bean shell variables inside the field its displaying so many variables like mentioned earlier
optimisticProvisioning: String = false
objectRequest: AccountRequest = sailpoint.object.ProvisioningPlan$AccountRequest@4e8c79
field: Field = sailpoint.object.Field@e73a4f
plan: ProvisioningPlan = sailpoint.object.ProvisioningPlan@da6890
context: InternalContext = sailpoint.server.InternalContext@900f3
bsh: XThis = 'this' reference (XThis) to Bsh object: NameSpace: Bsh Object (bsh.NameSpace@a54415)
project: ProvisioningProject = sailpoint.object.ProvisioningProject@ae9c4e
bsf: BSFManager = org.apache.bsf.BSFManager@18cb57
noApplicationTemplates: Boolean = false
userPassword: String = password
link = null
application: Application = sailpoint.object.Application@13c7d2e[id=ff80808141cd69da0141cd69fb8a000d,name=LDAP]
log: Log4JLogger = org.apache.commons.logging.impl.Log4JLogger@10ee4c8
cn: String = Test.Test
identityName: String = Test.Test
group = null
operation: Operation = Add
accountRequest: AccountRequest = sailpoint.object.ProvisioningPlan$AccountRequest@4e8c79
source: String = LCM
current = null
disableRetryRequest: Boolean = true
dn: String = cn=Test.Test,ou=people,dc=training,dc=sailpoint,dc=com
sn = null
requester: String = spadmin
template: Template = sailpoint.object.Template@1073205
identity: Identity = sailpoint.object.Identity@1b70b7[id=ff8080814200c6e50143df96b76a1c5b,name=Test.Test]
role = null
my question is when we will get the role(bolded above) value as not null. Iam getting in all the cases role is null. what is the use of these variable.?
@chris_hajdu it seems to me that the information in this article is not 100 % correct.
According to https://community.sailpoint.com/t5/IdentityIQ-Forum/Identity-Refresh-problem-with-Refresh-assigned-d... identity is only available inside a Field Script after requesting the role (e.g. via Manage User Access). On a subsequent Identity Refresh with Refresh assigned, detected roles and promote additional entitlements or Provision assignments enabled, the identity variable is empty and therefore useless:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Identity PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Identity/>