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.
I would like to share the details for these various keywords,
$plan.nativeIdentity â This will retrun the value which is configured as Account ID in Webservice Source account schema
$plan.planNativeIdentity â This will return identity Account Name
$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.
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
Hi Angelo, after looking at the input you provided , @harshal-suryawansh has suggested the below points:
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
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
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?
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.
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.