Keywords

Represents the Plans nativeIdentity in the Provisioning plan.

For example, planNativeIdentity is used along with the keyword as follows:


This is the companion discussion topic for the documentation at https://documentation.sailpoint.com/connectors/webservices/help/integrating_webservices/keywords.html

The keywords mention the following options:

  1. $plan.nativeIdentity
  2. $plan.planNativeIdentity
  3. $getobject.nativeIdentity

Are there small differences between these three options? Do they always resemble the same value? Can we always use them interchangeably, or are there contexts in which one value is available while the other is not?

Also, shouldn’t it be getObject rather than getobject? Can we get some more documentation on what this variable gives us? Can we get any existing account attribute when calling this variable? For example $getObject.email or $getObject.lastLoginDate$? Since one of the HTTP operations is called Get Object, is this HTTP operation called whenever we use the $.getObject value?

Also for response, it says “Used for multiple endpoints, where the response from the first endpoint is provided as an input for the second endpoint.”. We can have multiple ways of chaining HTTP requests. For example for account aggregation we could have first one HTTP operation to fetch all account ids, and then for each account id, call another HTTP operation to fetch data for that specific account. We could also for disabling an account first do an HTTP operation to get the latest account data, after which we use some of the responses as input for the second HTTP operation (do we also need to describe parent-child relationships between the HTTP operations here?). In the first case we use looping, in the second case we don’t. Can you perhaps give examples in the documentation for these different options? That way we don’t have to trial and error ourselves.

All in all I think these keywords could use some more documentation.

Kind regards,
Angelo

Hi Angelo,

I would like to share the details for these various keywords,

  1. $plan.nativeIdentity → This will retrun the value which is configured as Account ID in Webservice Source account schema
  2. $plan.planNativeIdentity → This will return identity Account Name
  3. $getobject.nativeIdentity → This will return the value which is configured as Account ID. This should be used in account aggregation operations as per the documentation.

Thanks,
Uday

Hi Angelo! Thank you for your input. We’ve created a Jira issue to track the effort and we’ll update the comment thread when it’s been addressed: CONDOCS-3918

1 Like

Hi Angelo, after looking at the input you provided , @harshal-suryawansh has suggested the below points:

  1. For $plan.nativeIdentity : refers value of identity present in accout request level
    $plan.planNativeIdentity : This refers to the value of identity present at Provisioning Plan level

So there can be a possibility of the nativeIdentity can be present in the account request for create account. So they can sometimes resemble to different values

  1. For $getobject.nativeIdentity

Also, shouldn’t it be getObject rather than getobject? Can we get some more documentation on what this variable gives us? Can we get any existing account attribute when calling this variable? For example $getObject.email or $getObject.lastLoginDate$? Since one of the HTTP operations is called Get Object, is this HTTP operation called whenever we use the $.getObject value?

This is $getobject as refering to getObject method of connector, yes it calls getObject method for resolving variable. So you can use any attribute of account returned from getObject operation e.g. $getObject.lastLoginDate$

Also for response, it says “Used for multiple endpoints, where the response from the first endpoint is provided as an input for the second endpoint.” We can have multiple ways of chaining HTTP requests. For example, for account aggregation, we could have the first one HTTP operation to fetch a…

Here response variable is used for sharing response of only immediate parent incase of chaining.

  • For e.g. EP2 has EP1 as parent, EP3 has EP2 as parent then
  • while resolving EP2 operation responsevariable will always refer to response of EP1
  • While resolving EP3 operations responsevariable will always refer to response of EP2