Openapi WM10.7 doesnt work

IS 10.7 with fix 17 installed

First question has anyone got a rest consumer working when importing openapi 3.0.0 with 10.7 ?

Before patch 16, nothing worked, thanks to SAG bug not send the API key, i recently patched our servers because of this.

I tried creating 2 separate consumer rest services from different commercial vendors, both failed. I tried to tweak the API json to try and get around data format, but just gave up and went back to using http client

Just cant stop the connector failing because it cant understand header elements defined in API ie
com.softwareag.is.rest.openapi.exception.InvalidDataFormatException: Invalid data “unlimited” set for the field “X-Rate-Limit-Remaining”

Am i being very unlucky with WM code just not compatible with these commercial APIs ?

Hi Mark,

Can you provide the openapi document? What the datatype and constraints defined for the header X-Rate-Limit-Remaining? My guess is that it is an integer and if it is an integer then the value should have been an integer.

Regards,
Aishvarya

Hi,

Its defined as either a string or integer, i did try to force it to a string in a local copy of the spec, to stop it trying to convert unlimited to integer, but it still failed.

I wouldn’t mind if the openapi call gave me a validation error, but still tried to give me the output of the rest call so i could handle the error in data.

“RemainingQuotes”: {
“oneOf”: [
{
“type”: “string”,
“enum”: [
“unlimited”
]
},
{
“type”: “integer”
}
],
“description”: “If your plan is not quote limited, this will be the string ‘unlimited’.”
}

Can you provide the complete openapi document?

Apologies for delay, been busy, complete openapi spec can be downloaded from link
https://developer.oanda.com/exchange-rates-api/openapi.json

This isn’t helpful I suppose but this is one of the many reasons I avoid RAD (and WSDs) – more often than not they just get in the way by trying to do too much. We typically create bespoke components that reflect the API definition as closely as possible (doc types, services) and use pub.client:http to make the calls.

Of course this is a YMMV item.

Starting from 10.1 where the REST capabilities started to mature in IntegrationServer it has undergone tremendous improvements. @reamon would like to know what are the typical challenges that one would face working with RADs (both OpenAPI 3.0 and Swagger 2.0). Is it usage? Is it functional?

Thanks,
Sree

This is a defect and you may create a support incident for your usecase.

thanks for all replies

I have to agree with raemon, just use http client, you have much more control.

I tried to have another go with openapi wizard, as i have a number of junior developers coming on board, and thought it would help them. But its frustrating, that 3 different commercial API’S i tried, and all failed. Now the other 2 might now work, since it now sends the APIKey. But i just don’t have the time to waste on reporting basic errors

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