Deploying a CAP Application to SAP Cloud Platform, Kyma runtime & connecting an iOS app
With the new SAP Cloud Platform, Kyma runtime being available on SAP Cloud Platform, a whole new runtime is available for you now. This technology is based on Kubernetes and allows for simple deployment of all sorts of technologies. For me as an iOS & Cloud Native developer I wanted to see, what my possibilities are with deploying a backend service to the Kyma runtime. A common problem I am having when developing iOS applications is that I am not a full backend developer, so the need for an OData or & Rest Webservice is always a challenge. The Cloud Application Programming Model allows me to simply create a service definition with a database to a web server. Usually CAP applications are designed to be deployed to the SAP Cloud Platform Cloud Foundry runtime via build packages. In my case I wanted to figure out if I could utilise the simplicity of CAP applications being deployed to something which is familiar to me: a Kubernetes runtime in my case Kyma.
If you’re building an OData backend service with CAP you automatically get an OData V4 service generated which is great as you’re on the newest technology stack of OData. Now using the SAP Cloud Platform SDK for iOS you’re facing a challenge with OData V4 as it is not compatible with the OData APIs of the SDK. So how can we take the CAP generated V4 service and expose an OData V2 API to the iOS app without re-writing the complete service and giving up the flexibility of connecting any other UI technology to the V4 service API? – The answer I found is the CDS OData V2 Adapter Proxy.
First of all, what is CDS?
So the OData V2 Adapter Proxy can be used to change the CDS to change the OData V4 service definition to an OData V2 definition dynamically by request. This allows you to have both versions supported without changing any code of your CAP application.
The OData V2 Adapter Proxy can be simply included in your CAP application via npm package and just through a couple of lines of code you get the proxy installed and ready to be consumed.
The architecture is pretty simple: The CAP service includes the OData V2 Adapter Proxy and the general service definition, the application gets packaged in a Docker image and then being deployed over the YAML deployment definition to the Kyma Runtime. Inside the Kyma Runtime the service gets exposed through an API Rule and then can be consumed by any UI technology you want.
For the iOS app to consume the service, you take the base URL of the API Rule and attach /v2 to it for the proxy to do its magic.
Following the tutorial Create a Basic CAP-Based Service, I’ve created a basic CAP service representing a bookshop. If you have never developed a CAP application I can highly recommend to follow the tutorial after you’ve finished reading this blog post.
With the bookshop service created you simply have to build a Docker image and define the deployment.yaml to run the service on Kyma.
The Dockerfile to package the service is pretty simple:
With the Dockerfile created just executed the following command to build a Docker image.
docker build -t <your-docker-id>/bookshop-example:1.0 -f Dockerfile .
Push the Docker Image to your Docker Hub repository for later consumption by the Kyma runtime.
docker push <your-docker-id>/bookshop-example:1.0
To deploy the CAP service to the Kyma runtime a YAML file containing the runtime definitions is required.
The CAP application won’t be secured and can just be accessed through the defined API Rule if the URL is known.
To deploy the image use the Kubernetes-CLI.
kubectl apply deployment.yaml -n default
This will cause the CLI to push the deployment.yaml to the default namespace and Kyma will spin up the pods, service and API Rule for you automatically.
All of this is basic Kubernetes knowledge and shows it is pretty simple to deploy a CAP application to the Kyma Runtime.
The deployment of the bookshop
The created API Rule
Implementing the OData V2 Adapter Proxy
As mentioned in the introduction the CAP application exposes an OData V4 service by default. The SAP Cloud Platform SDK for iOS currently requires an OData V2 service. Fortunately, there is the OData V2 Adapter Proxy which can be implemented into your CAP application.
Over npm, the package can simply be installed and then used inside your CAP application.
To implement the Adapter Proxy just create a server.js file and add the needed code for the adapter initialisation to it. In this example it is really just 4 lines of code.
const proxy = require('@sap/cds-odata-v2-adapter-proxy') const cds = require('@sap/cds') cds.on('bootstrap', app => app.use(proxy())) module.exports = cds.server
Of course you might have more complex applications and architectures so the documentation can be really helpful to find the correct implementation for you @sap/cds-odata-v2-adapter-proxy.
I am telling CDS to simply let the app use an instance of the proxy and the rest is done automatically. The last thing you have to do is to rebuild the Docker image and redeploy the application to the Kyma runtime.
Calling the proxy URL will result in the CAP service being transposed into a V2 OData service.
Great! With just 4 lines of code we get a fully functional V2 OData service where we can let the iOS app connect against. Every other UI can now decide which API it wants to talk to with just one single deployment on Kyma!
The iOS application
With everything setup on the backend, the iOS app itself is easy to create.
You can download the SAP Cloud Platform SDK for iOS right here: Installing the SAP Cloud Platform SDK for iOS.
What I did is simple: I’ve used the SAP Cloud Platform SDK for iOS Assistant to connect to my SAP Cloud Platform Mobile Services account and create a mobile cloud application definition including a destination pointing to my CAP V2 OData service running on Kyma. The iOS Assistant fetches the Metadata document and generates a complete app project out of it, including an OData data service and all needed methods for calling the service for the basic CRUD functionality.
Let’s take a look!
Generating the app
In order to generate the app with the iOS Assistant you have to follow the workflow for it. The beauty is that we get OAuth authentication against the destination out of the box. As our service is currently not secured (Which of course would be a huge security risk in a real project) the authentication is through the SAP IDP against Mobile Services.
The destination to the service is defined in the iOS Assistant. The iOS Assistant then will create the destination on Mobile Services for me, which allows me to inspect the service in the Mobile Services Cockpit.
The Mobile Services Cockpit shows the mobile cloud application definition where you can inspect the destination and display the OData entities.
If the service is configured correctly, OData entities of the service can be inspected directly.
Running the app with generated UI
The great thing about the iOS Assistant is that you can generate the app project in a way where you can immediately run it on an iOS simulator or a real device as it generates some basic UI for you. Of course, this UI is not production ready and shouldn’t be shipped that way but it is a great to see if the connection to the service works and if the data ends up in your app.
In Xcode you can simply run the application on a simulator of your choice.
This small project was a really nice experience to see if I can run CAP applications on Kyma and expose them in a way that my mobile application can consume the service itself. Of course this setup is really basic but is helpful to understand that with the SAP Cloud Platform, Kyma runtime we got a new tool in our toolbox for building great software. There are some other features which can be implemented in this whole workflow like authentication through OAuth2 to the CAP service which can be easily done by securing the CAP application directly using uaa service binding. In case you’re thinking about connecting a SAP UI5 to the CAP service, it would probably be cool to have the App Router up and running. – No worries this is not a big deal with the SAP Cloud Platform, Kyma Runtime. Again, implement your AppRouter and package it into a Docker Image for deployment to Kyma and you’re done!
To get a better feeling about the Kyma runtime and CAP, I would encourage you to try that setup out and build some nice UIs against a CAP service running on Kyma.
I will see you in the next blog post and have a wonderful Winter time!