Layer7 API Management

HI Team,

We have imported the WADL file (with Sample request/response) for Post operation in Portal 3.5, however when request is executed from the Documentation page, it is sending the JSON Schema as payload. This causes our backend to fail. We have tried this with couple of WSDL files downloaded from the internet but the same behavior is observed. We don't have any Sample WADL from CA to test this functionality. 

Below is the request Portal generates:

POST http://testserver:54003/cards/consumers/v1/***

Content-Type: application/json

traceId: 4323b85f-a7cb-49ba-acfb-03abc7e07fb0

{ "type": "object", "required": [ "consumerId" ], "properties": { "consumerId": { "type": "string", "description": "The consumer's unique ID. <br> Some clients may refer to this as the member number.", "maxLength": 20, "example": "12345" }...

I

I have attached the WADL files we have used, they are converted from Swagger via SOAP UI (CA suggested method) and APImatic. What we have observed that even that standard WADL document availble on the internet does not work.

Any help would be appreciated.

I want to make sure I understand... is the issue here that when executing an API from the Interactive Documentation, it sends the JSON schema as the payload? Does this mean that it works fine when the API itself is executed by a client?

What version of API Portal 3.5 are you running, in terms of CRs? If not on the latest CR, I'd recommend definitely upgrading to the latest CR (which currently is CR9). Documentation on this is here for reference: Upgrade to the Latest CR Release - CA API Developer Portal 3.5 - CA Technologies Documentation 

Specifically, I believe CR3 may actually resolve the issue you are describing, as it notes the following for resolved issues in CR3: (ref: Resolved Issues in 3.5 - CA API Developer Portal 3.5 - CA Technologies Documentation) 

There are at least several improvements made to Interactive Documentation in Portal 3.5 through the CRs, not to mention other unrelated improvements and fixes, so you'll definitely want to upgrade.

Once you're on CR9, please test again and let me know if this is still an observed behaviour in your environment.

Thanks Dustin, we are on CR09. Same behavior when API is executed from the API explorer as well. To summerise:

a)  When WADL is converted from SWAGGER (attached JSON) file using SOAP-UI, which CA suggests then no sample request is populated. Our SWAGGER is created using the Restlet Studio. Hence testing functions provided by the Documentation and API Explorer becomes useless.

b) We the add customization to WADL file, so that Request and Response samples gets added to it. However Portal does not renders it as expected, creating follow two problems:

   1) Request is populated with Schema instead of Sample Payload (in both Documentation and API explorer).

   2) On the API Explorer page  "Method" Drop down is not getting populated with method "name" rather mathod "id". below is the WADL entry.

<method id="UnlinkcaToken" name="DELETE">
<doc title="Unlink ca Token" xml:lang="en">Unlink a ca Token from a Consumer</doc>
<request>

As we don't even have the sample working WADL file which has POST operation with Sample Request and Response, I am not sure what changes we need to make in our conversion process to make it working. Our SWAGGER file works well with other CA products such as DevTst and LISA CE/EE, but the same file when converted via SOAP UI (into WADL) does not populate any thing in Portal.

Thanks,

Unfortunately I'm not certain what to suggest at this point for the conversion process neither. The Portal 3.5 does not support Swagger. While Swagger files can be converted using third-party tools, it's not always perfect and may present issues such as this one.

For my curiosity sake though - where does CA recommend that method? I'd assume we recommend it only as a workaround, but I'd like to check our documentation in case I'm missing something. Could you point me in the direction of where you saw CA recommending that method?

Hi Dustin,

Please refer the below link,

Create WADL Files - CA API Developer Portal 3.5 - CA Technologies Documentation 

Thanks,

https://communities.ca.com/thread/241784167-upload-swagger-2-json-doc-in-ca-dveloper-portal-3

This is suggested in community.

Understood. The thing is that it is third-party tools used to do the conversion, so CA Support cannot really offer too much support in that part as we have no control over those third-party products. In most cases, they would work perfectly fine. However you may have a case where it won't be perfect, or it could be a bug in the SoapUI version you are using, for example. Lots of factors that we cannot control, unfortunately.

You are welcome to upload your Swagger file for us here if you'd like (be sure to remove identifiable information from it though), we can look to try it in our own version of SoapUI and see how it will work from there. The thing is, that will only let us determine if it works or not for us and might shed light if it's a SoapUI version specific issue. We wouldn't be able to go too much further than that, I'm afraid.

Ultimately, the Portal does not support Swagger, so if you are trying to get a Swagger file into the supported WADL format but issues arise when doing so, the conversion process is the place likely causing the issues, especially if you are indeed running the latest CR on the Portal 3.5.

All you are saying makes sense. WADL is an out dated specification, which never really took off. Draft itself leaves many things to the interpretation of the implementer. That's why different tools (in fact different section of 3.5, API Explorer and Documentation) treats the same swagger differently.

Ideally, one should create their specification in WADL itself to get it working in Portal, but this is a way backwards as world has already moved to Swagger 2.0. Same case with us, I managed to manually tweak the WADL to get it working from the documentation page. However API explorer does not work, so I have decided to hide that option from the Portal. We can still use the TryIt Out option on the Documentation page, and it gives users the better UX.

Thanks for your support, I was reading your other posts where you have provided solutions on changing the default ports on Gateway in our case Software 9.2  (require 443). Would make another post in the forum for that.

Thanks a lot for your time and help

Get Outlook for iOS<https://aka.ms/o0ukef>