Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

HTTP post method optional parameter in json content

Felix20
Mega Guru

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

 

1 ACCEPTED SOLUTION

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 🙂

View solution in original post

8 REPLIES 8

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}

}

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

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 🙂

Ok thanks Simon, I'll try that way. Best regards, Felix