The web services virtual appliance-based connector supports expression language in URLs, Header values, and in the Body section.
This looks interesting! I do welcome more configuration options like this on the Web Services and Web Services SaaS connectors preventing us from needing to create custom rules.
I do have some questions and remarks based on this documentation, to see if this can really help us resolve the limitations we thus far experience with the web service connector.
if-else statements supported in the body somehow? Either using this expression language (_# tags), or by using “Velocity” (whatever that means) using $$ tags (I don’t understand the documentation here, nor what you can do with it compared to just $ tags, or by just using $ tags. One use case is that update provisioning policy might contain $plan.firstName$ and might contain $plan.lastName$, but the body always expects the value, so we want to first get the current data and then look what needs to be overwritten using something like #if($plan.firstName$)$plan.firstName#{else}$response.firstName$#endif-else is not supported for in the body, can we achieve the above use case without having to rely on rules? Perhaps we need to see if we can hack a solution by cleverly using substring, length and replace, but preverably we use something readable and elegant.https://domain.com/2/team/members/list/_#$response.data$.length()_#, /2/team/members/list/_#'hello'.concat('world')_# and /2/team/members/list/_# 5 >= 4_#. Those examples make no sense at all. Won’t _#5 >= 4_# return true? Can you please add clear real world examples for which this can be used?concat? I thought you can already use "displayName": "$plan.firstName$ $plan.lastName$" or something like that, so why use "displayName": "$plan.firstname$.concat(' ').concat($plan.lastname$)" instead?if-else operations.Thanks for the feedback. Please see my responses to your numbered items below.
if-else question, so I need to again refer you to #2.Thanks,
Josh
Hi @joshb488,
Thank you for your response!
I do think you are referring me too quickly to the ISC Discussions and Questions category here. SailPoint should have clear documentation on their building blocks, on the elemental functionality supporting by SailPoint. It should be clear which building blocks exists, how it behaves and how it should be implemented.
Only once this is clear, could one go to the ISC Discussions and Questions to discuss on how to combine these building blocks to achieve a specific use case.
If SailPoint documentation is just saying it supports velocity, without specifying what this word/tool/concept means in this concept, perhaps a link to third party documentation, and some elementary examples, then there is no clear documentation on the building blocks and we should go to you, not to the ISC Discussions and Questions page.
Since certain operations are now supported which are generally used in if-else statements. I think it makes sense to ask the documentation team if they forget to add this in the documentation. This is something that the general ISC Discussions and Questions group can’t help with.
When in comes to the Web Services and Web Services SaaS connectors, I think there is much room for improvement. Newer developers should be able to read that documentation and understand the functionality and what its general purpose is.
Kind regards,
Angelo
I heartily agree. Adding a new feature is appreciated, but if it’s not documented, then how can the community be of any help?
Hi Docs Team,
Your documentation mentions this exact phrase:
"name": "_#'hello'.concat('world')_#"
I tried it as example (but then with title instead of name since that was the attribute I needed to change.). ISC received a 200OK response and on the target application I saw this value:
So the web service connector did not read these _# commands. Instead it read it as literal string. To me this shows that this bit of the documentation is wrong (or there is a bug). Can you please validate this for me?
Please note I have the following usecase: I have several account attributes (including title) for which I want to perform attribute sync.
The actual body would look something like this if due to attribute sync I need to update title to foo and country to bar:
{
"user": {
"title": "foo",
"country": "bar"
}
}
If due to attribute sync I only need to update country to bar, the body should look like this:
{
"user": {
"country": "bar"
}
}
Since I won’t be changing the title, it should not be in the body.
If due to attribute sync I need to strip the title (should be null) and update the country to bar, then it should look like this:
{
"user": {
"title": null,
"country": "bar"
}
}
How can I achieve this using the web service connector?
I tried doing the following:
{
"user": {
"title": "$plan.title$",
"country": "$plan.country$"
}
}
But in this case, regardless of whether attribute sync wants to keep the title as is (title not visible in the plan) or strip it (title part of the plan as null), this web services connector will omit this data from the body, meaning we can’t strip it. I am trying to see if the expression language can help me, but the documented example doesn’t work.
Kind regards,
Angelo