- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-09-2018 12:47 AM
Hi all,
I'm working on integration of Microsoft Graph API into my application and facing an issue with optional parameter in the json body content.
How can I filter optional parameter of that json content of my HTTP method defined in my REST Message, if it has not been set in my workflow?
To be more precisely:
I have a RestMessage "Graph API User" and a corresponding HTTP Method "updateUser PATCH" which has a predefined content of the following:
{
"preferredLanguage": "${preferredLanguage}",
"givenName":"${givenName}",
"surname":"${surname}"
}
I want to use that REst message + http method in a script but i just want to set preferredLanguage as a parameter. So I just pass that one as a settingparameter.
But when i fire that rest message, i get an error, that the json format is wrong, because givenName and surname will also be part of the message but have no value.
How can i prevent them to be part of the requestBody when i use it in a script?
Many regards
Solved! Go to Solution.
- Labels:
-
Scripting and Coding
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-12-2018 11:29 PM
What I've done is a create a script include with all the functions needed that I can call from a BR, workflow or whatever triggers the message. That way you have one script included where you can maintain call all the rest messages. That should help you take care of the "," part as well.
It's not ideal but if MS would add a new variable that is needed for the payload you would still need to add it to the rest message and then add it as a parameter to all places where you use that rest message. So building the payload in a script included and use that might actually be the easiest. Apart from the third party not changing the API ofc 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-11-2018 11:03 AM
Well you can change it so that it's all one variable like ${payload} in the rest message and then build that variable in the script. That way you get total control of when you want to send surname or when you dont want to send it. That's normally what I do when the payload differs a lot. I think that you could also do as below so that you can either set the ${surname}-parameter or not.
{
"preferredLanguage": "${preferredLanguage}",
"givenName":"${givenName}",
${surnName}
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-12-2018 05:10 AM
You are right again, that will work.
But what about maintenance of external API?
If microsoft changes the surname parameter to name, and i follow your approach, then i have to change every script, which sets this parameter.
I would like to have that functional / technical description in one file (for example the content field of http method).
That will work as my documentation of external API and if something changes, I just have to fix it at this one place.
Furthermore how to handle format parts like "," the separator in json for elements.
When I want to add an additional element, I have to take care, to add an "," at the end of my last set parameter. That might also change all of my scripts which uses this API.
Best regards,
Felix
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-12-2018 11:29 PM
What I've done is a create a script include with all the functions needed that I can call from a BR, workflow or whatever triggers the message. That way you have one script included where you can maintain call all the rest messages. That should help you take care of the "," part as well.
It's not ideal but if MS would add a new variable that is needed for the payload you would still need to add it to the rest message and then add it as a parameter to all places where you use that rest message. So building the payload in a script included and use that might actually be the easiest. Apart from the third party not changing the API ofc 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-13-2018 01:30 AM
