API Deployment Types

Portal Admins and API Owners can control how APIs are deployed to a proxy using the API deployment type. You select the API deployment type when adding proxies.
For more information about how to add a proxy, see Integrate On-Premise API Proxies.
The API Details page displays the API deployment information on the
Deployments
tab. The following graphic displays the Details page of API deployment information for different API deployment types and proxies:
Proxies support the following API deployment types:
  • Automatic
    For this API deployment type,
    API Management SaaS
    immediately and automatically deploys changes to the published APIs to all proxies. For example, whenever an API is added, edited, or deleted. This is the default type.
  • On Demand
    For this event-driven API deployment, users with deployment permissions can deploy the API to the proxy as needed. The Portal Deployer client handles deployment, undeployment, and redeployment of the API to the proxy. For example, this API deployment type is useful when you want to stagger the deployment of an API across all or your geographic regions to avoid impacting production instances during peak hours.
  • Scripted
    For this API deployment type, you can integrate the API deployment into your CI/DC process by leveraging the Deployment API and invoking them from a custom API deployment script. The deployment APIs retrieve API deployment data and update the API deployment status for a proxy to keep
    API Management SaaS
    updated.
  • To use the Automatic or On Demand API deployment types, you must install the latest Portal Integration bundle (at the minimum, the bundle associated with Portal version 4.4) during the enrolment or upgrade process. You can check whether you have the latest bundle installed by viewing the Portal compatibility indicator as described in Manage Proxies.
  • On Demand and scripted deployments are available only for Portal-published APIs.
The following sections describe each type in more detail.
Automatic API Deployment Type
Effect on API Deployments
Changes to APIs are automatically deployed to the proxy. For example, whenever an API is created, edited, or deleted.
To assist administrators in troubleshooting any synchronization of API changes between the API Portal and the proxy, the Proxy Details page lets you compare deployment data between proxy and Portal publishing sources and identify deployment errors immediately when they arise. New Gateway or proxy enrolments with the version 5.0.2 or newer with the latest Portal Integration bundle installed of the API Portal will take advantage of this synchronization feature. If your Portal installation uses an older Portal Integration bundle, this enhanced synchronization feature and Proxy Details page will not be available.
Use Case
The Automatic API deployment type is recommended for the following use cases:
  • Rapid iteration of API development.
  • Convenience and low maintenance.
  • Development environments.
Execution Method Used
UI and API Call
Notes
The API count displays for the Portal and the proxy on the API Proxy Details page because the APIs are automatically deployed to the proxy.
If you do not use the Automatic API deployment type for a proxy, the APIs are not synched to and from that proxy regardless of where they were created.
Gateway-published APIs
must
use the Automatic API deployment type because they rely on the synchronized scheduled task to synchronize them from the proxy to the Portal.
To enable automatic deployment of Gateway-published APIs, you must enable migration between environments or clusters using Gateway Migration Utility (GMU). For more information, see the following links:
On-Demand API Deployment Type
Effect on API Deployments
You can trigger API deployments on-demand by calling the Deployment API.
Deployments are triggered when a user with deployment permissions makes calls to the Apideployments resource in the Portal API (PAPI).
On-demand deployments apply only to Portal-published APIs.
Use Case
The On Demand API deployment type is recommended for the following use cases:
  • Deployments that are triggered as needed.
  • Geographically distributed environments.
  • UAT environments.
For example, you want to stagger the deployment of an API across all or your geographic regions to avoid impacting production instances during peak hours.
Execution Method Used
UI and API call.
Deployment APIs to orchestrate and trigger the deployment process.
Notes
The API Proxy Details page displays only the APIs that have been created on the Portal and not the APIs that have been deployed to a proxy.
Scripted API Deployment Type
Effect on API Deployments
You can integrate API deployments into your existing Continuous Integration/Continuous Deployment (CI/CD) process by using the deployment APIs and invoking them from your deployment script.
Deployments are triggered by the script in conjunction with the deployment APIs which are used to retrieve the API deployment data and update the API deployment status for a proxy.
Scripted deployments apply only to Portal-published APIs.
Use Case
The scripted API deployment type is recommended for the following use cases:
  • Integrations with existing CI/CD pipeline.
  • Environments that are tightly controlled.
  • Production environments.
For example, you want control over when an API is deployed using a custom script in conjunction with the Deployment APIs.
Execution Method Used
UI and API call.
Restman used to deploy to proxy.
Deployment APIs and custom script to orchestrate and trigger the deployment process.
Notes
API Proxy Details page displays only the APIs that have been created on the Portal and not the APIs that have been deployed to a proxy.