IS unwraps the JSON payload and puts it under a wrapper document

I have the below flow service in IS 10.11

image

Using Postman, the below JSON payload is sent -
image

Ideally, the IS must have unwrap this JSON payload and convert it into the document type(order here).
However, I see that the values under the order document in debug mode are coming as null.

If I pass the below JSON payload, it works fine.
image

Any suggestions as to why the request doesnt works while including the parent tag ‘order’.
Thanks

1 Like

restv2 is now deprecated, you should create a proper API Descriptor as of now along with the ‘rad’ postfix. Also if you just want to invoke a service, use the following syntax and don’t forget to set the Content-Type to ‘application/json’

http://localhost:5000/invoke/namespace/service
e.g.

## Request
curl -X "POST" "http://localhost:5555/invoke/jc.scratch.api/processOrder" \
     -H 'Content-Type: application/json' \
     -d $'{
  "order": {
    "id": 100,
    "status": "free"
  }
}'

You will need to update your document to make id a number and not a string.

regards,
John.

Exactly the same issue.
Below is the rad config -

Resource as defined below
image

Structure as below
image

Postman:
image

Please suggest/

The confusion is because you only have one input and hence the API Descriptor assumes that the reference is the body, thus it commits “order” from the payload i.e. you have to provide the input as

{
  "id": 100,
  "status": "open"
}

If you want to have order then you will need to wrap it in a document e.g.

You can examine the parameters part of the API Descriptor to see how it works

By inserting the “body” reference into the signature it makes “order” explicit

John.

Still doesn’t works
image

Even though as suggested, it doesnt makes “order” explicit,

This works and data is there as checked in debug mode in Designer.
image

This doesnt works -
image

Farhan

Hi @Farhan_Shirgill ,

After you create a RAD for the resource, you get the swagger content in the “Swagger” tab of the RAD. Copy this content and check it on https://editor.swagger.io/ and as you can see the expected body for this POST request is only the properties (attached snapshot)

and this is for the service whose input is defined as you mentioned.
image

Also, for a service which has input expected to be a document and as @John_Carter4 mentioned it should be wrapped under another document see screenshot below

image

In this case, the expected input for the request would be with the parent element (order in your case), see the swagger editor

HTH

Thanks,
Sree

Dear @Sreekanth_Siddapur_Channakeshava

Isn’t my input same as yours with the exception that the order in my case is a document reference.
image

And if putting a document reference is a problem, does it implies that a input document to a restful flow service can’t have a document reference due to the above limitation.

As a further matter, calling the service with invoke in url directly and not through the rad, it works as expected. So, why the change in behavior b/w the 2 methodologies implementation (rad & invoke).

Thanks

Hi,
You might need to refresh your API Descriptor after updating the service to include body. I noticed that mine didn’t reflect the signature changes until I did that. I agree that the current implementation is confusing and we should probably update the API Descriptor to allow you to choose if you want the order reference to be explicit or implied.
regards,
John.

Hi @Farhan_Shirgill ,

Even with the reference, the API expects the request to provide only the properties in the body and not the parent

Case1 :
image

Attached is the swagger editor screenshot.

Case 2:

image

Thanks,
Sree

@Farhan_Shirgill if you’re still in the early stages of development, I recommend taking a contract-first approach by using an editor like the one Sreekanth recommended, creating your API definition there, and then importing that definition into webMethods and letting webMethods create the artifacts as needed. I’ve used both approaches in the past and defining the API definition first via Swagger or Open API is the way to go.

Good luck,
Percio

1 Like

“restv2 is now deprecated” - really? REST V2 was only introduced a few years ago after deprecating the “legacy approach”

https://tech.forums.softwareag.com/t/rest-capabilities-in-integration-server/

That’s link is to the new rad approach. The labelling is a bit confusing because the legacy approach is prefixed with /rest/… whereas the new approach is …/rad/…

Sorry the confusion.
regards,
John.

1 Like