API Connect

API Connect

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.


#API Connect
#Applicationintegration
#APIConnect
 View Only

Governance Models, Version Control, Migration of Subscriptions (complex scenario)

By Ravi Ramnarayan posted 03/30/21 03:23 PM

  

As the API economy matures from gen one to two and beyond, we need to apply version control and devops methods to the burgeoning API inventory.

The sample scripts use several “apic” toolkit commands to construct the input file for “products:migrate-subscriptions”. The scripts were developed on IBM API Connect v10.0.1.x. You could dovetail steps from the sample scripts into your devops process, or build your process around the scripts’ steps.

The documents and scripts can be reached from this blog or through ibm-apiconnect/apic-hybrid-cloud-enablement.

In-the-works: Sample scripts built around “products:set-migration-target” and “products:execute-migration-target”. If you have other scenarios, please write a thumbnail in the comments.

Another community blog on API design: API Versioning – Best Practices (and not so great practices)

2 comments
75 views

Permalink

https://community.ibm.com/community/user/blogs/ravi-ramnarayan1/2021/03/30/governance-models-version-control-migration-of-sub

Comments

Ravi Ramnarayan
04/20/21 04:57 PM

Parveen, thank you for the comments. I have clarified the points you raised in v1.5 of the Governance models doc. Application Lifecycle is available in API Connect v10. Subscription Client ID will guide the invocation to the API -- I had to perform the experiment to remove doubts. Of course, the API should require subscription with Client ID.

Parveen Kumar
04/09/21 09:03 AM

Governance models blog is concise and informative. I have a few points to make:

- You have referred to App lifecycle in light of approved or unapproved subscriptions but left out the App state of Development (initial) and Production (once upgraded). An API would be published either with api_key security or without. Subs are required only if api_key security is defined. Subscription approval must also be enabled in the Catalog. An API published with api_key security can not be invoked without a subscription regardless of the application state.

- App lifecycle would give the most benefit when used with Development and Production vanity endpoints of an API. APIC should have ideally used these two to prevent cross talk and to route calls from an application in Development state to Dev endpoint and same application in Production state to Production endpoint without requiring context query on app state.

- Your assertion of routing to different versions of an API without requiring a version identifier in the URI while having same base path is not technically feasible. I can not see how two versions of an API can have the same vanity endpoint e.g. v1 and v2 both are at  https://api.dev.orgname.com/applications to test routing based on subscription and api key (Client Id). It would have to be https://api.dev.orgname.com/v1/applications and https://api.dev.orgname.com/v2/applications, for example.

- i have asked and not yet found an answer as to why the application lifecycle feature is not supported after v5. Any thoughts? It is interesting to note though that the feature is still available in v2018, even though the functionality is not supported.

- One of your tables re major version change and lifecycle operation has Publish operation for UAT and Prod. It should be supersede (by deprecating existing version) if production mode is enabled.

- It is worth a mention that a replace operation results in migration of any subscriptions on the replaced product to the replacement product. It is also worth mentioning that the product plan mapping is important.

Thanks