Access request (created via Service Catalog) REQ number in IdentityNow

We are working on ServiceNow Service Catalog integration with SailPoint IDN. We have requirement for admin account creation in AD using Service Catalog and during account creation, need to get the request number from ServiceNow to set it in “description” attribute in AD. How do we achieve this? Is it feasible to do this? Please assist.

Regards,
Bhima

The ServiceNow Service Catalog integration uses the access request API to submit the request to IDN.

You can modify the request payload on the ServiceNow side to include a comment attribute, and add the request number to that comment:

{
  "requestedFor": [
    "<Identity ID>"
  ],
  "requestedItems": [
    {
      "id": "<ACCESS_PROFILE ID>",
      "type": "ACCESS_PROFILE",
      "comment": "RITM2354458"
    }
  ]
},
  "requestType": "GRANT_ACCESS"
}

That comment can be accessed either in powershell or in before provision rule. It comes in as an Attribute(argument) in the AccessRequest obejct.

in powershell, you can grab it this way:

Add-type -path utils.dll;
$sReader = New-Object System.IO.StringReader([System.String]$env:Request);
$xmlReader = [System.xml.XmlTextReader]([sailpoint.utils.xml.XmlUtil]::getReader($sReader));
$requestObject = New-Object Sailpoint.Utils.objects.AccountRequest($xmlReader); 
$attributes = $requestObject.Attributes
$reqNumber = $requestObject.Attributes.comments
foreach ($attribute in $requestObject.AttributeRequests) {
	if (<logic to know if this is SN request>){
		$ritm = $attribute.Attributes.comments
	}
}

In Before Provision rule, you should be able to get it like this (haven’t tested personally):

for (AccountRequest req : plan.getAccountRequests()){
   if (serviceNowRequest){
      String reqNumber = req.getArgument("comments");
   }
}
1 Like

Thanks Dylan for the update. We used powershell method to achieve this.

Regards,
Bhima

Hi Dylan,

I tried the Before provisioning rule method. The getArgument does not seem to be a valid method for Attribute Request or Account Request. And looks like “AccessRequest” above is a typo, I didnt find any package called AccessRequest

Hi Vikram,

You are absolutely right about the AccessRequest typo. It should have been AccountRequest. So sorry for any confusion that caused. I’ve corrected it.

getArgument(String s) should be a valid method, though. AccountRequest and AttributeRequest both inherit the method from sailpoint.object.ProvisioningPlan.AbstractRequest

It returns a type Object.

You could also try:
Attributes attributes = req.getArguments()

that would contain ALL the arguments, and you would just need to grab the one you’re interested in. attributes.get(“comments”);

Idk what i am doing wrong. But obj.getArgument(“comment”) where obj is a AccountRequest type gives me null

and,

Attributes attributes = req.getArguments()
also gives me attributes as null for “attributes”. Not sure what am i doing wrong.

My request body looks like this:

{
  "requestedFor": [
    "XXXXXXXXXXXXXX"
  ],
  "requestedItems": [
    {
      "id": "XXXXXXXXXXXX",
      "type": "ENTITLEMENT",
      "comment": "Hello, this is a comment",
      "clientMetadata": {
        "servicenow": "This is servicenow client metadata"
      }
    }
    
  ],
  "requestType": "GRANT_ACCESS",
  "clientMetadata": {
    "ticketno": "This is another set of tikcet no"
  }
}

Hello Vikram,

I think that ‘comment’ field in the API request actually gets translated to an argument “comments” (plural). I know that’s the argument attribute I’m using to pull the value in powershell.

You say you’re getting Null for Attributes in general?

Can you post the rule here?

Also, could you try uploading the ProvisioningPlan xml?

It should be visible under Admin → Identities → Activities (then click the little ‘i’ icon next to the provisioning status)


Clicking the i button gives me this. There is no provisioningPlan.xml

I did try both comment and comments. Both happen to be null for some reason.
Null for attributes too. The rule is big and complicated but I just did something like

ProvisioningResult result = new ProvisioningResult();
    if (null!=plan){
        try {
            List accounts = plan.getAccountRequests();
            if ((accounts!=null) && (accounts.size()>0)) {
                for (int i=0; i<accounts.size(); i++) {
                    AccountRequest account = accounts.get(i);
                    Attributes attributes = accounts.getArguments();
                    log.info(attributes.get(“comments”);
              ......

Do you think the comment from the access request doesn’t get pulled at all?

This may just be a typo in what you’ve pasted here, but your accounts.getArguments() method is being invoked on a List object (accounts), not the AccountRequest (account).

That line should be account.getArguments();

Now, if that’s just a typo in the post, and your rule is correct, you can try this: (I know this isn’t the ideal method for testing, but at least we’ll know what’s available)

Attributes attributes = account.getArguments();
log.info(attributes.toString());

Yes you are right that’s a typo. In my case the “attributes” obj is null after the

Attributes attributes = account.getArguments();

so, idt the toString() is gonna work.
Do you think the comment from the access request doesn’t get pulled at all, looking at the screenshot of activities?

I did a little more digging on my side, and it looks like the provisioning plan is only displayed on that screen when the application is IIQ (so assigning roles and access profiles). I think that’s just a display issue, but it’s possible the attributes get populated differently if your requesting an entitlement vs an access profile or role.

Are you requesting the entitlement directly? You could try adding it to an access profile to see if that changes the behavior.

We were requesting an Access Profile in ServiceNow when we built our integration.

Yeah even I felt the same.As a user I feel there are a lot of inconsistencies in the sailpoint ecosystem.

we have lots of entitlements wrapping each one in an access profile is tedious. Thanks a lot for looking into it though.