Product Information
SAP API Management: CI/CD Enhancements
APIs have become the first-class citizen in digital business. API world has evolved covering how APIs can be designed following API best practices, simplify the API design and develop service based on API first approach.
In software development lifecycle there is a radical shift on how software is built, validated and finally deployed. We are seeing more of process automation to facilitate continuous integration (fail fast approach with validations) followed by continuous delivery and deployment. CI/CD strategy along with the tool’s choice may differ across organizations to achieve the common goal: automation, fail fast and time to market.
In this blog we will cover how we could leverage CI/CD strategy with SAP API Management.
CI/CD pipeline relies on
- automation server (eg: Jenkins) to build, test and deploy the software.
- VCS (Version Control System) as single source of truth to keep track of changes.
We want to be agnostic of automation server or VCS to enable and support CI/CD pipeline with SAP API Management so that customer can choose software/tools of their choice and build CI/CD pipeline. We have enabled SAP API Management open APIs and command line utility which can be used during the process.
CI/CD strategy can help to address below listed challenges in API Management.
- API Provisioning workspace (API Portal) is to model an API proxy with polices, trigger API proxy deployment to runtime and publish API proxy to portal (Developer Portal) for consumption. As this is a manual process, can API proxy creation (to certain extent) and its deployment be automated? How to manage multiple versions of API proxies for subsequent changes?
- Multiuser workspace: Same workspace (API Portal) is shared across different team members or multiple teams. As additional tenant comes with a cost how can we ensure its optimal usage?
- API proxy movement across different landscape(dev/test/production)
Let’s cover in detail how we will be solving above listed challenges with CI/CD approach.
Client-side VCS support: Git/GitHub
We want to enable VCS agnostic approach thereby exposing open APIs and command line utility to export API proxies (along with dependencies). Once exported, user could make use of commands specific to VCS to create/clone a repository, check-in the exported API proxies (and dependencies). This can be the single source of truth to track any subsequent changes from client side. In this example, we will consider Git, but user could make use of any other VCS.
In this section we will cover how CI/CD approach can help to address above listed challenges:
- Automate Deployment and manage multiple versions of API proxies for subsequent changes
To automate deployment, API proxies can be created using command line (we will cover this in next blog with enhanced functionality) or existing proxies can be exported which can be deployed further to same or different environment or proxies can be exported to maintain and track subsequent changes at client side.
Steps:
- Clone the existing remote repository in your client machine. (or create new repository if does not exist). Considering this as the master where API proxies are maintained.
- git clone < repository URL>
- To perform any changes, create and switch to a new branch
- git checkout -b <new branch>
- Export API proxies (with dependencies: API Provider, KVM…) using command line utility
- Download Client SDK following the help documentation. Readme file of Client SDK has details of all the available commands in the current release.
- Client SDK offering comes with SAP API Management in Neo and CF environment. Command line arguments and functionality remain same in both Neo and CF other than access details. In Neo its protected with username/password and in CF it’s with secure token.
- Neo Environment:
java -jar apim-cli-1.3.0.jar -exportapiproxies -apiproxynames {comma separated proxy names} -apiportalurl {apiportalurl} -user {id} -pass {pwd}
-
- CF Environment:
java -jar apim-cli-1.3.0.jar -exportapiproxies -apiproxynames {comma separated API proxy names} -apiportalurl {apiportalurl} -clientid {clientid} -clientsecret {clientsecret} -tokenurl {tokenurl}
- CF Environment:
- Once zip is downloaded, it will contain API proxies (with dependencies)
- Stage and commit the API proxies to newly created branch.
- git add. (to add all files in the current directory or explicitly specify the file name)
- git commit -m ” Commit message”
- Create a pull request and merge the changes.
Once master branch has exported API proxies from API Management, any subsequent changes can be tracked and maintained. From here on, API developer can persist, track and maintain multiple version/revision of API proxy with client-side git (VCS agnostic) integration by leveraging the export functionality exposed by Client SDK.
2. Movement across landscape
- To move API proxies (with dependencies) to different environment for eg from dev to test or production environment. Once, API proxies are maintained in VCS (remote repository), user could clone the repository to local machine. API proxies can further be imported and deployed to target API Management server
- CF environment:
- java -jar apim-cli-1.3.0.jar -importapiproxies -apiproxiesziplocation {zip file location} -apiportalurl {apiportalurl} -clientid {clientid} -clientsecret {clientsecret} -tokenurl {tokenurl}
- Neo Environment:
- java -jar apim-cli-1.3.0.jar -importapiproxies -apiproxiesziplocation {zip file location} -apiportalurl {apiportalurl} -user {id} -pass {pwd}
- CF environment:
3. Multiuser workspace
- Each team/user can maintain their API proxies in the separate branch and deploy it using CI/CD pipeline.
- It ensures, all their changes are tracked, persisted and can be recovered if accidently deleted by some other team in API provisioning workspace (API Portal)
With subsequent release we will cover how API proxies can be created using command line and policy templates can be applied on same.
Hi Nitin,
Please tell us that SAP is working on VCS integrated into Integration Suite and We do not need to use command line tools.
Max.
Hi Max,
Thanks for sharing your feedback. We have enhanced API Management client sdk/command line. Any planned future investments will reflect in product roadmap.
Best Regards
Nitin
Hi Nitin,
do you have a changelog what was improved on the SDK?
For me it looks like that it still cannot be used standelone without using non public management APIs. Some reasons:
Therefore it's not really a solution for Git integration for API Management which is asked by 20+ companies.
Regards
Roman
Hi Roman,
Thanks for sharing your feedback.
All available functionalities of client sdk are listed in readme.md file of client sdk zip. It was the incremental step in enhancing client sdk functionality. Currently it's not exposing all the functionality which is available via API Management APIs.
We would request to raise a feature request via CSN listing in the priority order that you are looking forward in client sdk.
Best Regards
Nitin
Hi Nitin,
there is already a feature request for Git integration which should still be open from my point of view:
https://influence.sap.com/sap/ino/#idea/248650
Regards
Roman
Hi Nitin,
thank you for the blog post. This approach was imho opinion there for a while now. It lack 2 major features:
I 2nd Roman, that this is not a solution to the improvement request but rather a blog post on what was already possible for a while enhanced by some git commands for everyone who didnt work with git so far.
For me a robust solution would need:
Any Info on if this will be tackled also?
Regards
Holger
Hi Holger,
Thanks for sharing your feedback.
This was the incremental step and as you rightly mentioned lot can be enhanced and improved over the current feature set.
I would request to raise a feature request and lets have a sync along with product team to share the requirements and next increments you are looking forward.
Best Regards
Nitin
Hi Nitin,
The request exists: Git integration for API Management However it was closed as delivered by Udo with reference to this blog post.
This is where it starts going around in circles.
Anyway, I commented in the request that I do not agree to it being delivered. Maybe you check internally and revisit the requirement of this request.
Regards
Holger