Product/components used and version/fix level:

Intergration server 10.15 last fixes

Detailed explanation of the problem:

Hi,
i’ve to use an external REST API with some anonymous schema like :

[
“string”,
“string”,
“string”,
{
“noAccount”: 0,
“noAccountEx”: 0,
“noOffer”: 0,
“noVoucher”: 0,
“noSegmentation”: 0,
“noCustomer”: 0,
“noCustomerEx”: 0,
“noChildren”: 0,
“noEmail”: 0,
“noAddress”: 0,
“noPhone”: 0,
“noClub”: 0,
“noCard”: 0,
“noCardEx”: 0,
“noCustomerList”: 0,
“noCounter”: 0,
“numberOfLastTicket”: 0,
“noContactType”: 0,
“noTarget”: 0,
“numServer”: 0
}
]

On webMethods :

I have no problem at all to create the consumer REST API Descriptor but i MUST add a prefixe for that kind of anonymous schema but, unfortunately, the endpoint send me an ERROR due to the bad request. It doesn’t recognize the prefixe.

How to deal with that ? It is possible to tell webMethods to “anonymize” on call a particular set of JSON properties ?

Thanks !

Regards.

#webMethods
#Integration-Server-and-ESB

Send the request according to the openapi document and IS should transform the data correctly to the generated service signature.
If you still cannot get it working, a sample of the schema in question would be helpful.
Regards,
Aishvarya

#Integration-Server-and-ESB
#webMethods

Hi, thanks for your answer.
I don’t understand your statement.
“Send the request according to the openapi document”, there is some UNAMMED objects in the schema.
Here is the schema :
hxxps://drive.google.com/file/d/1PihnJ0DydjOCoXENJr5QpP3_QA2Js-pI/view?usp=drive_link
Try to import it in a 10.15 integration server … You have to specify a prefix for anonymous object.
Thx

#Integration-Server-and-ESB
#webMethods

I mean you should send the request as follows, without the prefix used while importing the openapi doc.
[
“string”,
“string”,
“string”,
{
“noAccount”: 0
}
]

The prefixes are used to act as key/name in the signature as in IS pipeline you cannot have a value without a key. When you send the request as above, IS will handle the anonymous schema to convert the data according to the service signature.

I used the schema provided and send the request as above and there were no errors. However there is still a problem/defect that the data did not come into the service pipeline for this service. You may open an ticket for the same.
Regards.

#Integration-Server-and-ESB
#webMethods

Hi, thx for your answer.
You CANNOT import the openAPI doc WITHOUT set a prefix for anonymous schema :

“I used the schema provided and send the request as above and there were no errors”
How do you manage to do that ? Are you using the default connector from the rad consumer ?
Yeah, you can send http post request with client.http but the purpose of the openapi file is to use the default connector generated by the IS openAPI importer : wm.server.openapi:invoke.

#webMethods
#Integration-Server-and-ESB

The Usage Notes for pub.json services in the Integration Server Built-in Services Reference describe how to handle unnamed arrays.

#Integration-Server-and-ESB
#webMethods

Hi,
$rootValue and $rootArray, yeah, i know the trick, but WHY the openapi schema importer doesn’t set that kind of information when there is an anonymous schema ? It’s only doable for array and value without name not for a simple object … :

Could not run ‘deleteProfile’
com.softwareag.is.rest.openapi.exception.UncheckedServiceException: com.wm.app.b2b.server.ServiceException: com.softwareag.is.rest.openapi.exception.InvalidDataFormatException
com.softwareag.is.rest.openapi.exception.UncheckedServiceException: com.wm.app.b2b.server.ServiceException: com.softwareag.is.rest.openapi.exception.InvalidDataFormatException
That is not working …

#Integration-Server-and-ESB
#webMethods

Does seem odd that the consumer RAD wizard doesn’t do the right thing. The applicable JSON schema fragment:

"schema": {
"type": "array",
"items": {
"anyOf": [{
"title": "storeChain",
"description": "",
"type": "string"
}, {
"title": "accountKey",
"description": "",
"type": "string"
}, {
"title": "customerKey",
"description": "(allow empty, can be used as filter)",
"type": "string"
}, {
"$ref": "#/components/schemas/AccountProfileOptions"
}
]
},
"uniqueItems": true,
"minItems": 4,
"maxItems": 4
}

According to the IS docs, the following is supposed to apply to an array with mixed types:

If the JSON object contains a array having different types of objects (for example, integer, string, etc.), Integration Server sets the corresponding field in the IS document type to Object List with Java wrapper type as UNKNOWN.

Seems like that is not happening here? This might be a case where using RAD to “help” is actually in the way? Maybe manually defining the doc types and corresponding client service(s) would be the path of least resistance so that your own doc types and code can manage $rootArray and $rootValue entities. Interesting that the JSON schema is defined the way it is. Seems a bit unusual.

(Side note: we avoid using RAD and generated components. Gets in the way more than helps, as was the case with WSD components in the past.)

#Integration-Server-and-ESB
#webMethods

Thx for your answer, it’s a really a shame that i can’t use the automatic import …
I cannot define the doc type manually neither due to mismatch in the JSON.
Ex :
[
“string”,
0,
{
“offer”: “string”,
“num_campaign”: 0,
“name”: “string”,
“description”: “string”,
“internal_description”: “string”,
“customer_description”: “string”,
“start_time”: “string”,
“end_time”: “string”,
“shadow”: 0
}
]
new doc → import from JSON give me that kind of stuff :

Usually for that kind of problem, i use the pub.client:HTTP with a json string but with that kind of json, i cannot use it …
Why ppl make that kind of json ?!
Thx

#webMethods
#Integration-Server-and-ESB

Exactly. Technically it is valid JSON but usability-wise it is lacking. The first 3 unnamed strings requires that someone review the schema to know what each value refers to – why not just use name/value pair? Very odd.

The earlier doc type you shared seemed to potentially be on the right track.

Adding a third string $rootValue and a doc $rootValue.

Then create doc type that uses names (the title for each in the schema). Use that doc type for mapping/processing. Then just before documentToJSONString, map each element to the corresponding $rootValue items. Might that work?

#webMethods
#Integration-Server-and-ESB

Thx for your answer, don’t bother, it’s clearly a BAD json implementation from the external society.
webMethods can’t use it, it’s not my problem ! “Make it right or deal with it” !
Thx anyway !
Regards

#Integration-Server-and-ESB
#webMethods