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

Hi Elisa,

The issue has been resolved! I’ve updated the documentation based on the engineering team’s inputs.

Thank you for your understanding and support throughout this process!

Best regards,
Sayali

Hi @vaishali_thakur,

I stumbled upon this topic again and saw you responded to my post (for which I want to thank you), but since you referred to my name statically (Angelo) instead of using the tag (@angelo_mekenkamp ), I did not receive a notification. I recommend applying tagging.

For 1, can you give an example of how these values can be different? Based on documentation purely for ISC and not for IIQ, how should we know the difference between account request level and provisioning plan level? Also I don’t understand what you mean with ‘value of identity’. What does this mean from a technical perspective? Could you please document this?

For 2, this documentation is directed to those who need to implement the web service connector, this does not necessarily mean they know the inner mechanisms of such a connector, for example the existence of the method getObject. Can you please note what happens here. If I am using $getObject.email$ and $getObject.lastLoginDate$. Does this mean the getObject method will be called twice, and hence that the steps for single account aggregation will be performed twice? I also have the feeling that the documentation is not consistent on whether we should use $getobject.email$ or $getObject.email$. Could you please double check case sensitivity?

Regarding response variable. What if there is no parent-child setup? For example in the create account action, you can not specify the parent. So suppose we need to perform 3 different API calls to create an account. Does this mean you can’t use the response variable then?

Kind regards,
Angelo

Hi @angelo_mekenkamp,

Vaishali is unfortunately no longer with SailPoint, so I will step in for her. This is good feedback we can use to improve the document. I created CONDOCS-6751 to track the work to review it and fill in any holes where we think we can.

Also, your question is quite complex, and it could probably be best answered in the ISC Discussions and Questions category. I can move it over there, but I wanted to check in with you first.

-Josh

Thank you @joshb488!

I will await the update of the documentation. I wouldn’t say my question is complex. I would say I am asking several questions, which are individually straightforward, and should individually be deduced from the documentation.

Hi Angelo, we will address some of the concerns from your comments, but some of these are more implementation related questions. Those should be directed to the ISC Discussions and Questions section.

Hi @ryan_mccall, can you please name the specific question(s) I asked you think should not belong here as documentation feedback?

Sure thing, it’ll be easier to let you know what we’ll look into.

  • We’ll provide more information on the definition for “value of identity”
  • We will check the case sensitivity for $getObject.email$

The rest of your questions can be asked in the community.