-
Notifications
You must be signed in to change notification settings - Fork 21
FAQ
The major difference is that the starting-point of your CI/CD-Pipeline: With apimanager-promote you need to use an API-Manager to manage your APIs, which is an additional overhead to API-Developers to do. They don't want to manage their APIs separately to make them compatible with the API-Manager. With Swagger-Promote an API-Developer can use any tool or framework (e.g. Code-Generators) that is able to produce a Swagger-File and connect his APIs directly with the API-Management platform.
The intention is to put your APIs under version control and by that you have something I call: APIs as Code similar to infrastructure as code. Perhaps review this slide-deck: https://www.slideshare.net/Axway/streamline-api-management
There are many reasons why it's better to start with the Swagger-File:
- Deploy your APIs directly into the API-Management platform
- you can repeat this over and over again, for instance on a change in your Swagger-File
- adding new methods, parameters, etc.
- Doing this by hand in API-Manager is a pain and error-prone
- you can repeat this over and over again, for instance on a change in your Swagger-File
- Staging your APIs becomes a matter you deployment
- you can easily deploy your APIs into different environments, having different requirements
- Security-Requirements, other Custom-Policies, etc.
- you can easily deploy your APIs into different environments, having different requirements
- the Swagger-File is a Standard-Format, the API-Export DAT-File is not
- the API-Export Dat-File format is changing from API-Manager version to the next
- as it is a kind of a Memory-Dump written to a JSON-File
- as the internal data-structure is changing, the export-format is changing
- this becomes important when you update your API-Manager and you can't import your existing API-Export files anymore
- see this discussion here: https://community.axway.com/s/feed/0D52X00007XjEWdSAN
- the API-Export Dat-File format is changing from API-Manager version to the next
- Swagger-Files and the API-Configs are simple JSON-Files
- standardized formats
- easy to read, easy to compare revisions, easy to rollback if needed, easy to audit
- you can work collaborative on it using the Git-Flow (e.g. Pull-Requests, etc.)
- existing tools can be made part of the CI/CD-Pipeline
- e.g. validating the Swagger-File according corporate rule set
- test your APIs with an existing test tool
- etc.
- there are many useful tools out there, but non of these will work with the Custom Export-Dat file
In one sentence I would say: With Swagger Promote your CI/CD pipeline starts with the API (the Swagger-File + Config) itself and it can be registered directly & repeatable into the API-Management platform. This streamlines the API-Lifecycle dramatically.
Yes, as long as the Operating-System provides a Java-Runtime (JAVA_HOME set) Swagger-Promote can be used. And of course, the host must have access to the API-Manager.
Swagger-Promote as the core component is not supposed to handle multiple APIs in one execution.
If you need to process multiple APIs, I recommend to write your own wrapper (e.g. Shell-Script), which may iterate over a directory/list/etc. and calls Swagger-Promote for each API individually.
Yes, since version 1.6.3 this is possible. You need to provide the following details when calling Swagger-Promote:
-Djavax.net.ssl.keyStore=</path/to/keystore.jks>
-Djavax.net.ssl.keyStorePassword=
-Djavax.net.ssl.keyStoreType=
When trying to register an API in API-Manager you may get the following error:
Response: 'HTTP/1.1 500 Internal Server Error'
Following with the error message:
Error creating API-Proxy. Unexpected response from API-Manager....
Most of the time this error is caused by the API-Manager when trying to import an API having an HTTPS downstream server. During registration the API-Manager tries to download the required certificates from the downstream server, hence the API-Manager needs to reach HTTPS-Host at registration time.
HTTPS-Post is not reachable
If the HTTPS-Host, given in the Swagger-File, can't be reached you get that error. For instance, the Swagger-File contains any Development-System not reachable from the production environment.
To workaround this problem do the following:
- Use the configuration option:
backendBasepath
to define a valid host, that is reachable from that environment. Learn more
With that, Swagger-Promote will adjust the Swagger-File before importing it into the API-Manager. Hence, the import should work.
When using a proxy for downstream communication
If your API-Management platform requires a proxy-connection to reach HTTPS-Downstream servers do the following:
- define a plain downstream server in your Swagger-File (e.g. http://any.host.com). This might be even a non-existing host
- set the option replaceHostInSwagger to false (to avoid the Swagger-File is adjusted before importing it)
- set the parameter:
backendBasepath
to the valid HTTPS-Host With that, the API-Manager during import will no longer trying to download the server-certificates, but the correct downstream host is finally configured in the Frontend-API.
☝️ Swagger-Promote has been discontinued and is replaced by the new APIM-CLI