Pipeline Variable substitution to the JSON payload/body while using Pub.client:http

[1]: "Hi all, I am trying to consume an outbound (post method) service using pub.client:http service. The input structure for the inbound post service has been attached in the image which is a json string. I have all this data available from previous outputs but these are in the form of document, when i convert this document to json string using documenttoJSONString service and send this as input to the pub.client.http service it shows parser error. I have verified everything else the only thing i don’t know is how to pass the json string in the required post format.
Here is the image for the correct required input structure

here is my doctojsonstring output

{“UniqueKey__c” : “123456789”,“Name” : “Ankit”,“Phone”: “91123458”}

Below is how i am passing the input to http service as a set value
{
“data”: “[%jsonString%]”
}

Do let me know in case of any other clarifications.
Thanks for help in advance

@Ajay_Joshi kindly verify perform pipeline variable substitution is enabled while mapping below structure to payload body

{
“data”: “[%jsonString%]”
}

2 Likes

yes it is enabled and also is there any better way to input payload structure.

The string value shown for the data element appears as it is intended to be JSON, but it is not. Single quotes are not JSON. Nor is placing an array within quotes valid JSON.

If the payload shown is really what is needed, documentToJSONString will not provide the desired result. If the above is really intended to be JSON, it would look like this (using formatting with line breaks and indents simply for clarity):

{
    "data": [{
            "UniqueKey__c": "123456789",
            "Name": "Ankit",
            "Phone": "91123458"
        }
    ]
}

Note the differences. Is the Postman screen shot really what is needed? Seems odd.

Edit: Forgot to note – avoid variable substitution whenever possible. Sometimes it is the preferable way to create a string. In this case, it is not.

or like this if it is converted to and/or used as string. Nevertheless manually creating a json string is a bad idea. Why do you need this string value in global variable? May be there is a better way of doing what you want instead of pipeline substitution.

Thank you for the response.
The inbound post service that i am consuming has input structure of what i have attached. It is working when i hit it through postman. Now i want to do the same using http service. The only problem is i have all the required input in the document format.
( UniqueKey__c, Name, Phone). In order to consume the inbound service i need to convert the document to required input structure that’s why i am creating a jsonstring manually using pipeline variable substitution.
Can you suggest any alternative for the same or some solution for the current method.

Thanks,
Regards

Hi, reamon thank you for the response.
I understand your point that the values inside curly brackets is not exactly json input. But the format for the inbound service is correct as it is working when i hit it through postman. i want to do the same using http service. The only problem is i have all the required input in the document format.( UniqueKey__c, Name, Phone). In order to consume the inbound service i need to convert the document to required input structure that’s why i am creating a jsonstring manually using pipeline variable substitution.
Is there any specific reason i should avoid using pipeline substitution in this case and if yes then is there an alternative for the same?

Thank you,
Regards

More simply, it is not JSON. So you cannot use documentToJSONString for creating that part. You will need to create your own component to create that string.

One may be tempted to use documentToJSONString and then replace all " with ’ – technically that could be done but doing some has its perils. Since we don’t know what format/convention that is, we don’t know its rules such as how to encode reserved characters and the contexts of ’ vs. ".

In this specific case, var substitution is not necessary. The steps:

  1. Create the custom format string ins some way. The result being [{‘UniqueKey__c’ : ‘123456789’,‘Name’ : ‘Ankit’,‘Phone’: ‘91123458’}] – it looks very much like JSON but it is not.

  2. Map this string to a var something like this:
    doc
    data

  3. Use documentToJSONString passing the doc var as the document to get your JSON string – which is an anonymous object with one string field named data that has a value that looks very much like JSON but is not.

Is the API you are trying to call (I’ve never understood why people refer to calling and API as “consume”) public so that others can review it? It seems to be a strange approach.

1 Like

Why not create 2 documents and use documentToJsonString twice? It will do all the necessary conversions. Imo you found a workaround to your problem in postman and you are trying to apply it to a different platform. This doesn’t mean you found the correct solution. Your solution works in postman because you are using 2 different quotes in conjunction while assuming json is also a javascript. It should work but it will make a mess that way. If your object is declared like a data object having nested object within it, as in the code below, you don’t need to do anything, just mimic the json object with document and convert it to json.

{
  "data": [{
    "object1": "value1",
    "object2":"value2"
  },
{    
    "object1": "value3",
    "object2":"value4" 
}]
}

If your object defined as below, you need to call documentToJsonString twice, once for creating the inner jsonobject, second time for outer json object, because your field is not an object instead it is a string. Your example looks like this.

"JsonObject":{
  "data":"someOtherJsonString"
}

If you convert your data object twice your inner json object will have \" instead of " for enclosing strings. Your solution works because you are using a different quotes chars like we do it in javascript programing, but that’s a manual operation and it can cause inconsistencies. After converting a json object to a json string; it is no longer an object, it is string; hence you need to make proper conversions like using escape chars for quotes. You are not supposed to make any changes (other then escaping some chars) to the jsonString once you create the jsonString. You can definately break it.

Also keep in mind that http.client can produce the outter json object, if you map a document.

1 Like

No the API is not public. I am sorry if this sounds confusing, but as of now i have only its input structure and nothing else that’s why i am trying to mimic the same input. I will let you know once i know more about it. For now this is helpful.
Thank you
p.s. even i don’t know why i call it consuming the service maybe because it sounds more interesting.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.