Get Account Schema in before provisioning Rule

Hello,

I am writing a before provisioning rule for a web service connector, and I need a list of all the attributes in the account schema. I was wondering if I can reference the Application directly in my Before provisioning Rule and use application.getSchema("account") or application.getAccountSchema() if I can could you please tell me what package needs to be imported in my rule and where these lines of code should be in the rule?

Another solution I saw was to get the account using idn.getAccountByNativeIdentity() and then call use the getAttributes() method.

But I prefer to use the first Solution if it’s applicable.

Regards

From IDN Java docs

import sailpoint.object.Application;
import sailpoint.object.Schema;
import java.util.List;
import sailpoint.object.AttributeDefinition;

Schema schema = application.getAccountSchema()
List attList = schema.getAttributes();

foreach (AttributeDefinition attDef : attList) {

	String attName = attDef.getName();
	String attDispName = attDef.getDisplayName();

}

I would like to know why do you need schema attributes and what do you want to implement.

Hi Nadim,
Here you can find how to build Before Provisioning rule

As you see application object is read only available here already so you don’t have to do anything else to get it.

You can also execute getAccountSchema() method to get the schema

The only thing you have to remember is that is a Cloud Executed Rule - that means the following

We have a web service connector for an application that requires all attributes to be sent in the PUT API call we are making.

Therefore I need all the attributes to be in my provisioning plan

Expected response.

I have implemented this many times. I check account request, if attribute request is not there then I add it to account request. I didn’t extract schema attributes and I don’t think you need all attributes that are in schema only some. I wouldn’t go with this approach.

You can use this Rule.

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Rule name="Before Provisioning Rule" type="BeforeProvisioning">
  <Description>Before Provisioning Rule which handles mandatory attributes for update operation.</Description>
  <Source><![CDATA[
  import sailpoint.object.*;
  import sailpoint.object.ProvisioningPlan.AccountRequest;
  import sailpoint.object.ProvisioningPlan.AccountRequest.Operation;
  import sailpoint.object.ProvisioningPlan.AttributeRequest;
  import sailpoint.object.ProvisioningPlan;
  import sailpoint.object.ProvisioningPlan.Operation;

  Identity identity = null;
  if(null != plan){
    identity = plan.getIdentity();
    if(null != identity){
      boolean fnameFlag = false;
      boolean lnameFlag = false;

      List accReqList = plan.getAccountRequests();
      if(null != accReqList && !accReqList.isEmpty()){
        for (AccountRequest accReq : accReqList){
          if(AccountRequest.Operation.Modify.equals(accReq.getOperation())){
            List attReqList = accReq.getAttributeRequests();
            if(null != attReqList && !attReqList.isEmpty()){
              for(AttributeRequest attReq : attReqList){
                if(attReq.getName().equals("firstName")){
                  fnameFlag = true;
                }else if(attReq.getName().equals("lastName")){
                  lnameFlag = true;
                }
              }
              if(!fnameFlag){
                accReq.add(new AttributeRequest("firstName", ProvisioningPlan.Operation.Set, identity.getAttribute("firstname")));
              }if(!lnameFlag){
                accReq.add(new AttributeRequest("lastName", ProvisioningPlan.Operation.Set, identity.getAttribute("lastname")));
              }
            }
          }
        }
      }
    }
  }
]]></Source>
</Rule>
2 Likes

I have implemented a similar rule for some (and not all) attributes, it just happens that this time we need to make sure to put in the plan all attributes (or at least the ones that are not null) we have in the account schema of the account

So If I understand correctly,

You are looking to automate this somehow, incase if any new attribute is required in API call, you don’t want to touch the cloud Rule again ?

Yes that is the main goal we have in mind for this rule, another thing we also solve is that we don’t need to name each attribute, which are around 100 for the source we are configuring.

This is feasible only if your account schema attribute name and identity attribute name is same.

Hello Krishna,

You would be right only if I am pulling the values from the identity, which is not the case here.

What we take advantage of with our rule is the fact that a provisioning plan should already contain everything that needs to be updated for the account (entitlements or account attributes) and we retrieve the rest of the attributes from account itself.

We know this could cause sync issues in case the pushed values from the account did not update in IDN, but this is a risk we are okay with

I think it works.

Whatever the attribute that is changed will be there in the plan already, because it is modified and it won’t be filtered.

Attributes that are not there in the plan can be extracted from Link/Account of the user.

  • You can extract attributes from the schema
  • Iterate it
  • Check if that attribute is not there in plan
  • If not there, get the value from account
  • Add the attribute request to the account request

Only thing you need to make sure is, Account should be aggregated with latest data.

I can confirm that it does work.

We have deployed the rule in our sandbox environment and tested it, our tests were successful

Great work @Nadim, It is a cool idea to optimize the work and efficient coding/implementation.

Thanks for bringing it to our notice.

If you think it is useful I could share the code I wrote in this post converstation

Regards,

I would say no for complete code. We have approaches here, code snippets that is enough.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.