Skip to Content
Product Information
Author's profile photo Nitin Arora

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.

  1. 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?
  2. 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?
  3. 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:

  1. 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}
  • 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}

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.

 

 

 

Assigned Tags

      8 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Maximiliano Colman
      Maximiliano Colman

      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.

      Author's profile photo Nitin Arora
      Nitin Arora
      Blog Post Author

      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

      Author's profile photo Roman Greil
      Roman Greil

      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:

      • Products cannot be updated (description, restrictions, ..)
      • Secure Key Value Maps cannot be maintained
      • Virtualhost can still not be provided as a parameter. How to publish to a specific virtualhost?

      Therefore it's not really a solution for Git integration for API Management which is asked by 20+ companies.

      Regards

      Roman

      Author's profile photo Nitin Arora
      Nitin Arora
      Blog Post Author

      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

      Author's profile photo Roman Greil
      Roman Greil

      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

      Author's profile photo Holger Neub
      Holger Neub

      Hi Nitin,

       

      thank you for the blog post. This approach was imho opinion there for a while now. It lack 2 major features:

      • Separation on configuration (See Roman Greils comment before)
      • explosion of the API files - All it does is create a zip to download. That in the end is just the deyployment part and the initial download for a git integration.  For a smooth git integration one would need to unzip and then comit the changes on document level. Version managing the zip file is git managing an exe file. That does not give added value

       

      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:

      • source file version control
      • sdk with build functionality to build the api artifacts / deployables.
      • sdk / API to deploy undeploy (is already present as I understand)
      • Configuration / .env / yaml files that can be injected in the deployment process

      Any Info on if this will be tackled also?

       

      Regards

      Holger

      Author's profile photo Nitin Arora
      Nitin Arora
      Blog Post Author

      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

      Author's profile photo Holger Neub
      Holger Neub

      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