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

[Farhan_Shirgill]

I have the below flow service in IS 10.11

Using Postman, the below JSON payload is sent -

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.

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

[John_Carter4 (John Carter)]

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.

[Farhan_Shirgill]

Exactly the same issue.
Below is the rad config -

Resource as defined below

Structure as below

Postman:

Please suggest/

[John_Carter4 (John Carter)]

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.

[Farhan_Shirgill]

Still doesn’t works

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

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

This doesnt works -

Farhan

[Sreekanth_Siddapur_Channakeshava (Sreekanth SC)]

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.

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

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

[Farhan_Shirgill]

Dear @Sreekanth_Siddapur_Channakeshava

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

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

[John_Carter4 (John Carter)]

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.

[Sreekanth_Siddapur_Channakeshava (Sreekanth SC)]

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 :

Attached is the swagger editor screenshot.

Case 2:

Thanks,
Sree

[Percio_Castro1 (Percio Castro)]

@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

Nibble Technologies

[Dave_Laycock1 (Dave Laycock)]

“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/

[John_Carter4 (John Carter)]

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.