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.