Getting Started

Overview

This set of Getting Started guides is an end-to-end scenario that will walk you through major Kyma components and show its two main use cases:

  • Extensibility - when you first connect external applications to Kyma and expose their APIs and events to the cluster. Then, you can create extensions for them by building a simple Function, a more complex microservice, or a mixture of those, depending on your use case complexity level. You can also simplify these integrations and use Open Service Broker-compliant services enabled in Kyma's Service Catalog.
  • Application runtime - when you want to shape your business logic from scratch and use Kyma to build standalone microservices and Functions rather than extensions for existing systems.

With these features in mind, we will:

  1. Create a microservice that can expose HTTP endpoints and receive a specific type of events from external applications. It has built-in in-memory storage for storing event details, but it can also work with the external Redis storage.
  2. Provision the Redis service through Service Catalog and use it as an alternative database for the microservice.
  3. Connect an external mock application to Kyma as an addon. We will use it to send events with order delivery details to the microservice.
  4. Create a Function with the logic similar to that of the microservice. You will see how it, too, can be triggered by order events from the mock application and how it can save the order details in the external storage.

CAUTION: These guides refer to a sample orders-service application deployed on Kyma as a microservice. This way it can be easily distinguished from external Commerce mock that represents an external monolithic application connected to Kyma. In Kyma docs, they are referred to as application and Application respectively.

All guides, whenever possible, demonstrate the steps in both kubectl and Console UI.

Prerequisites

  1. Install:
  1. Download the kubeconfig file with the cluster configuration.

Main actors

Let's introduce the main actors that will lead us through the guides. These are our in-house examples, mock applications, and experimental services:

  • orders-service is a sample microservice written in Go. It can expose HTTP endpoints that can be used to create and read basic order JSON entities. The service can run with either an in-memory database that is enabled by default or an external Redis database. We will use it as an example to show you how you can use Kyma to deploy your own microservice, expose it on HTTP endpoints to make it available for external services, and then bind it to an external database service (Redis).

  • orders-function that is an equivalent of orders-service. Function's configuration allows you to save individual order data in its storage and retrieve multiple order records it. Like the microservice, the Function can run with either an in-memory database or a Redis instance.

  • Redis addon is basically a bundle of two Redis services available in two plans: micro and enterprise. You will connect it to Kyma through Helm Broker and expose it in the Kyma cluster as an addon under Service Catalog. The Redis service represents an open-source, in-memory data structure store used as a database, cache, and message broker. For the purpose of these guides, you will use the micro plan with in-memory storage to demonstrate how it can replace the default memory of the microservice.

  • Commerce mock is to act as an example of an external monolithic application which we want to extend with Kyma. It is based on the Varkes project and is also available in the form of an addon. It will simulate how you can pair an external application with Kyma and expose the application's APIs and events. In these guides, you will use its order.deliverysent.v1 event type to trigger both the microservice and the Function.

Steps

These guides cover the following steps:

  1. Create the orders-service Namespace in which you will deploy all resources.
  2. Create a microservice by deploying orders-service on the cluster in the created Namespace.
  3. Expose the microservice through the APIRule custom resource (CR) on HTTP endpoints. This way it will be available for other services outside the cluster so you can retrieve data from it and send sample orders to it. Since the microservice uses in-memory storage, when you send a sample order to its endpoint, the order details will be gone after you restart the microservice.
  4. Add the Redis service as an addon.
  5. Create the Redis service instance (ServiceInstance CR) in the Namespace so you can bind it with the microservice and Function.
  6. Bind the microservice to the Redis service by creating ServiceBinding and ServiceBindingUsage CRs. Send a sample order to its endpoint. Since it now uses the Redis storage, the order details will not be gone after you restart the microservice.
  7. Connect Commerce mock as the external application.
  8. Trigger the microservice to react to the order.deliverysent.v1 event from Commerce mock. Send the event. Then, see if the microservice reacts to it and saves its details in the Redis database.
  9. Create a Function in the Namespace and repeat the microservice flow:
  • Expose the Function through the APIRule CR on HTTP endpoints. This way it will be available for other services outside the cluster.
  • Bind the Function to the Redis service by creating ServiceBinding and ServiceBindingUsage CRs.
  • Trigger the Function to react to the order.deliverysent.v1 event from Commerce mock. Send the event. Then, see if the Function reacts to it and saves its details in the Redis database.

As a result, you get two scenarios of the same flow — a microservice and a Function that are triggered by new order events from Commerce mock and send the order data to the Redis database:

Order flow

Create a Namespace

Almost all operations in these guides are performed using Namespace-scoped resources, so let's start by creating a dedicated orders-service Namespace for them.

Reference

This and all other guides demonstrate steps you can perform in both the terminal (kubectl) and the Console UI. Read about the Console through which you can graphically and securely administer Kyma functionalities and manage the basic Kubernetes resources.

Steps

Follow these steps:

  • kubectl
  • Console UI

Deploy a microservice

You will now deploy a standalone orders-service microservice in the orders-service Namespace. This microservice will act as a link between the external application and the Redis service and we will build the whole end-to-end flow around it.

In this guide you will create:

  • Deployment in which you specify the configuration of your microservice.
  • Kubernetes Service through which your microservice will communicate with other resources on the cluster.

Steps

Create the Deployment

Create a Deployment that provides the microservice definition and enables you to run it on the cluster. The Deployment uses the eu.gcr.io/kyma-project/pr/orders-service:PR-162 image. This Docker image exposes the 8080 port on which the related Service is listening.

Follow these steps:

  • kubectl
  • Console UI

Create the Service

Deploy the Kubernetes Service in the orders-service Namespace to allow other Kubernetes resources to communicate with your microservice.

Follow these steps:

  • kubectl
  • Console UI

Expose the microservice

Now that you deployed a standalone orders-service microservice, allow other resources to communicate with it. Make it available for other resources outside the cluster by exposing its Kubernetes Service through an APIRule custom resource (CR).

Reference

This guide demonstrates how API Gateway works in Kyma. It exposes your Service on secured or unsecured endpoints for external Services to communicate with it.

Steps

Expose the Service

Create an APIRule CR which exposes the Kubernetes Service of the microservice on an unsecured endpoint (handler set to noop) and accepts the GET and POST methods.

TIP: noop stands for "no operation" and means access without any token. If you want a more secure option, see the tutorial on how to secure your Service.

Follow these steps:

  • kubectl
  • Console UI

NOTE: For the whole list of endpoints available in the Service, see its OpenAPI specification.

Call and test the microservice

Follow these steps:

CAUTION: If you have a Minikube cluster, you must first add its IP address mapped to the hostname of the exposed Kubernetes Service to the hosts file on your machine:

Click to copy
echo "$(minikube ip) orders-service.kyma.local" | sudo tee -a /etc/hosts

  1. Retrieve the domain of the exposed microservice and save it to the environment variable:

    Click to copy
    export SERVICE_DOMAIN=$(kubectl get virtualservices -l apirule.gateway.kyma-project.io/v1alpha1=orders-service.orders-service -n orders-service -o=jsonpath='{.items[*].spec.hosts[0]}')

  2. Run this command in the terminal to call the Service:

    Click to copy
    curl -ik "https://$SERVICE_DOMAIN/orders"

    The system returns a response similar to this one:

    Click to copy
    content-length: 2
    content-type: application/json;charset=UTF-8
    date: Mon, 13 Jul 2020 13:05:33 GMT
    server: istio-envoy
    vary: Origin
    x-envoy-upstream-service-time: 37
    []

  3. Send a POST request to the microservice with sample order details:

    Click to copy
    curl -ikX POST "https://$SERVICE_DOMAIN/orders" \
      -H 'Cache-Control: no-cache' -d \
      '{
        "orderCode": "762727210",
        "consignmentCode": "76272725",
        "consignmentStatus": "PICKUP_COMPLETE"
      }'

  4. Call the microservice again to check the storage:

    Click to copy
    curl -ik "https://$SERVICE_DOMAIN/orders"

    Expect a response similar to this one:

    Click to copy
    HTTP/2 200
    content-length: 73
    content-type: application/json;charset=UTF-8
    date: Mon, 13 Jul 2020 13:05:51 GMT
    server: istio-envoy
    vary: Origin
    x-envoy-upstream-service-time: 6
    [{"orderCode":"762727210","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}]

    You can see that the microservice returns the previously sent order details.

  5. Remove the Pod created by the orders-service Deployment. Run this command, and wait for the system to delete the Pod and start a new one:

    Click to copy
    kubectl delete pod -n orders-service -l app=orders-service

  6. Call the microservice again to check the storage:

    Click to copy
    curl -ik "https://$SERVICE_DOMAIN/orders"

    The system returns a response similar to this one:

    Click to copy
    content-length: 2
    content-type: application/json;charset=UTF-8
    date: Mon, 13 Jul 2020 13:05:33 GMT
    server: istio-envoy
    vary: Origin
    x-envoy-upstream-service-time: 37
    []

    As you can see, the orders-service microservice uses in-memory storage, which means every time you delete the Pod of the microservice or change the Deployment definition, you lose the order details. In further guides, you will see how you can prevent order data deletion by binding external Redis storage to the microservice.

Add the Redis service

Provision the external Redis service that will replace your microservice in-memory storage. To do so, you will use a sample addon configuration linking to an example in the GitHub repository.

Reference

This guide demonstrates how Service Catalog works in Kyma. It enables easy access to services (ServiceClass custom resources) managed by Service Brokers registered in Kyma. You can consume these services by creating their instances and binding them to your microservices and Functions.

Steps

Follows these steps:

  • kubectl
  • Console UI

Create a ServiceInstance for the Redis service

To create a binding between the microservice and the Redis service, you must first create an instance of the previously provisioned service.

Steps

Follows these steps:

  • kubectl
  • Console UI

This way you provisioned a Redis instance. As the next step, you will finally fit the two puzzle pieces together and bind the new Redis ServiceInstance to the previously deployed orders-service microservice.

Bind the Redis ServiceInstance to the microservice

In this guide, you will bind the created ServiceInstance of the Redis service to the orders-service microservice. Then, you will test the binding by sending a sample order to the microservice. This way you can check that the binding to the external Redis storage works and the order data no longer gets removed upon the microservice Pod restart.

Reference

To create the binding, you will use ServiceBinding and ServiceBindingUsage custom resources (CRs) managed by the Service Catalog.

NOTE: Read more about provisioning and binding ServiceInstances to microservices in Kyma.

Steps

Bind the Redis ServiceInstance to the microservice

Follow these steps:

  • kubectl
  • Console UI

Call and test the microservice

Follow these steps:

CAUTION: If you have a Minikube cluster, you must first add its IP address mapped to the hostname of the exposed Kubernetes Service to the hosts file on your machine:

Click to copy
echo "$(minikube ip) orders-service.kyma.local" | sudo tee -a /etc/hosts

  1. Retrieve the domain of the exposed microservice and save it to an environment variable:

    Click to copy
    export SERVICE_DOMAIN=$(kubectl get virtualservices -l apirule.gateway.kyma-project.io/v1alpha1=orders-service.orders-service -n orders-service -o=jsonpath='{.items[*].spec.hosts[0]}')

  2. Run this command in the terminal to call the service:

    Click to copy
    curl -ik "https://$SERVICE_DOMAIN/orders"

    Expect a response similar to this one:

    Click to copy
    content-length: 2
    content-type: application/json;charset=UTF-8
    date: Mon, 13 Jul 2020 13:05:33 GMT
    server: istio-envoy
    vary: Origin
    x-envoy-upstream-service-time: 37
    []

  3. Send a POST request to the microservice with sample order details:

    Click to copy
    curl -ikX POST "https://$SERVICE_DOMAIN/orders" \
      -H 'Cache-Control: no-cache' -d \
      '{
        "orderCode": "762727210",
        "consignmentCode": "76272725",
        "consignmentStatus": "PICKUP_COMPLETE"
      }'

  4. When you call the https://$SERVICE_DOMAIN/orders URL again, the system returns a response with order details similar to these:

    Click to copy
    HTTP/2 200
    content-length: 73
    content-type: application/json;charset=UTF-8
    date: Mon, 13 Jul 2020 13:05:51 GMT
    server: istio-envoy
    vary: Origin
    x-envoy-upstream-service-time: 6
    [{"orderCode":"762727210","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}]

  5. Similarly to the previous guide where you exposed the orders-service microservice, remove the Pod created by the orders-service Deployment. Run this command, and wait for the system to delete the Pod and start a new one:

    Click to copy
    kubectl delete pod -n orders-service -l app=orders-service

  6. Call the microservice again to check the storage:

    Click to copy
    curl -ik "https://$SERVICE_DOMAIN/orders"

    Expect a response similar to this one:

    Click to copy
    content-length: 2
    content-type: application/json;charset=UTF-8
    date: Mon, 13 Jul 2020 13:05:33 GMT
    server: istio-envoy
    vary: Origin
    x-envoy-upstream-service-time: 37
    [{"orderCode":"762727210","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}]

In the Expose the microservice guide, we saw how the in-memory storage works — every time you deleted the Pod of the microservice or changed the Deployment definition, the order details were lost. Thanks to the binding to the Redis instance, order details are now stored outside the microservice and the data is preserved.

Connect an external application

Let's now connect an external application to Kyma. In this set of guides, we will use a sample application called Commerce mock that simulates a monolithic application. You will learn how you can connect it to Kyma, and expose its API and events. In further guides, you will subscribe to one of Commerce mock events (order.deliverysent.v1) and see how you can use it to trigger the logic of the orders-service microservice.

Reference

This guide demonstrates how Application Connector works in Kyma. It allows you to securely connect external solutions to your Kyma instance.

Steps

Deploy the XF addons and provision Commerce mock

Commerce mock is a part of the XF addons. These are cluster-wide addons giving access to three instances of mock applications, which in turn simulate external applications sending events to Kyma.

Follow these steps to deploy XF addons and add Commerce mock to the orders-service Namespace:

  • kubectl
  • Console UI

CAUTION: If you have a Minikube cluster, you must add the spec.template.spec.hostAliases field in the commerce-mock Deployment with the following hostnames:

Click to copy
hostAliases:
  - ip: $(minikube ip)
    hostnames:
      - connector-service.kyma.local
      - gateway.kyma.local

Create the Application and retrieve a token

After provisioning Commerce mock, connect it to Kyma to expose its APIs and events to the cluster.

First, you must create an Application CR. Then, retrieve the token required to connect Commerce mock to the created Application CR.

Follow these steps:

  • kubectl
  • Console UI

Connect events

To connect events from Commerce mock to the microservice, follow these steps:

  1. Once in the order-service Namespace, go to Configuration > API Rules > commerce-mock in the left navigation panel.
  2. Open the link under the Host column to access Commerce mock.
  3. Click Connect.
  4. Paste the previously copied URL with the token, check Insecure Connection, confirm by selecting Connect, and wait until the application gets connected.
  5. Select Register All on the Local APIs tab or just register SAP Commerce Cloud - Events to be able to send events.

Once registered, you will see all Commerce mock APIs and events available under the Remote APIs tab.

TIP: Local APIs are the ones available within the mock application. Remote APIs are the ones registered in Kyma.

Expose events in the Namespace

To expose events in the orders-service Namespace, first create an ApplicationMapping CR to bind the application to the Namespace. Then, enable the events API in the Namespace using the ServiceInstance CR.

Follow these steps:

  • kubectl
  • Console UI

After all these steps, our microservice running in the orders-service Namespace can finally consume events from Commerce mock.

Trigger the microservice with an event

This tutorial shows how to trigger the deployed orders-service microservice with the order.deliverysent.v1 event from Commerce mock previously connected to Kyma.

Reference

This guide demonstrates how Event Mesh works in Kyma. It allows you to receive business events from external solutions and trigger business flows with Functions or microservices.

Steps

Create the event trigger

Follow these steps:

  • kubectl
  • Console UI

Test the trigger

To send events from Commerce mock to the orders-service microservice, follow these steps:

  1. Access Commerce mock at https://commerce-orders-service.{CLUSTER_DOMAIN}. or use the link under Host in the Configuration > API Rules view in the order-service Namespace.

  2. Switch to the Remote APIs tab, find SAP Commerce Cloud - Events, and select it.

  3. From the Event Topics drop-down list, select the order.deliverysent.v1 event type.

  4. In the details of the printed event, change orderCode to 123456789 and select Send Event.

    A message will appear in the UI confirming that the event was sent.

  5. Call the microservice to verify that the event details were saved:

    Click to copy
    curl -ik "https://$SERVICE_DOMAIN/orders"

    NOTE: To get the domain of the microservice, run:

    Click to copy
    export SERVICE_DOMAIN=$(kubectl get virtualservices -l apirule.gateway.kyma-project.io/v1alpha1=orders-service.orders-service -n orders-service -o=jsonpath='{.items[*].spec.hosts[0]}')

    The system returns a response proving that the microservice received the 123456789 order details:

    Click to copy
    content-length: 2
    content-type: application/json;charset=UTF-8
    date: Mon, 13 Jul 2020 13:05:33 GMT
    server: istio-envoy
    vary: Origin
    x-envoy-upstream-service-time: 37
    [{"orderCode":"762727210","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}, {"orderCode":"123456789","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}]

Create a Function

Let's now repeat the microservice flow for the Function. This guide shows how you can create a simple Function (orders-function) with the same logic as the one in the microservice. In further guides, you will expose the Function, bind it to the Redis storage, and subscribe it to the order.deliverysent.v1 event type from Commerce mock.

Reference

This guide demonstrates how Serverless works in Kyma. It allows you to build, run, and manage serverless applications called Functions. You can bind them to other services, subscribe business events from external solutions to them, and trigger the Function's logic upon receiving a given event type.

Steps

Follows these steps:

  • kubectl
  • Console UI

Expose the Function

In this guide, you will expose your Function outside the cluster, through an HTTP proxy. To expose it, use an APIRule custom resource (CR) managed by the in-house API Gateway Controller. This controller reacts to an instance of the APIRule CR and, based on its details, it creates an Istio Virtual Service and Oathkeeper Access Rules that specify your permissions for the exposed Function.

After completing this guide, you will get a Function that:

  • Is available on an unsecured endpoint (handler set to noop in the APIRule CR).
  • Accepts the GET and POST methods.

NOTE: Learn also how to secure the Function.

Steps

Expose the Function

Follow these steps:

  • kubectl
  • Console UI

Call and test the microservice

Follow these steps:

CAUTION: If you have a Minikube cluster, you must first add its IP address mapped to the hostname of the exposed Kubernetes Service to the hosts file on your machine:

Click to copy
echo "$(minikube ip) orders-function.kyma.local" | sudo tee -a /etc/hosts

  1. Retrieve the domain of the exposed Function and save it to an environment variable:

    Click to copy
    export FUNCTION_DOMAIN=$(kubectl get virtualservices -l apirule.gateway.kyma-project.io/v1alpha1=orders-function.orders-service -n orders-service -o=jsonpath='{.items[*].spec.hosts[0]}')

  2. Call the Function:

    Click to copy
    curl -ik "https://$FUNCTION_DOMAIN"

    The system returns a response similar to this one:

    Click to copy
    content-length: 2
    content-type: application/json;charset=UTF-8
    date: Mon, 13 Jul 2020 13:05:33 GMT
    server: istio-envoy
    vary: Origin
    x-envoy-upstream-service-time: 37
    []

  3. Send a POST request to the Function with sample order details:

    Click to copy
    curl -ikX POST "https://$FUNCTION_DOMAIN" \
      -H "Content-Type: application/json" \
      -H 'Cache-Control: no-cache' -d \
      '{
        "orderCode": "762727210",
        "consignmentCode": "76272725",
        "consignmentStatus": "PICKUP_COMPLETE"
      }'

  4. Call the Function again to check the storage:

    Click to copy
    curl -ik "https://$FUNCTION_DOMAIN"

    The system returns a response similar to this one:

    Click to copy
    HTTP/2 200
    access-control-allow-origin: *
    content-length: 187
    content-type: application/json; charset=utf-8
    date: Mon, 13 Jul 2020 13:05:51 GMT
    etag: W/"bb-Iuoc/aX9UjdqADJAZPNrwPdoraI"
    server: istio-envoy
    x-envoy-upstream-service-time: 838
    x-powered-by: Express
    [{"orderCode":"762727210","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}]

    You can see the Function returns the previously sent order details.

  5. Remove the Pod created by the orders-function Function. Run this command, and wait for the system to delete the Pod and start a new one:

    Click to copy
    kubectl delete pod -n orders-service -l "serverless.kyma-project.io/function-name=orders-function"

  6. Call the Function again to check the storage:

    Click to copy
    curl -ik "https://$FUNCTION_DOMAIN"

    The system returns a response similar to this one:

    Click to copy
    HTTP/2 200
    access-control-allow-origin: *
    content-length: 187
    content-type: application/json; charset=utf-8
    date: Mon, 13 Jul 2020 13:05:33 GMT
    etag: W/"bb-Iuoc/aX9UjdqADJAZPNrwPdoraI"
    server: istio-envoy
    x-envoy-upstream-service-time: 838
    x-powered-by: Express
    []

As you can see, orders-function uses in-memory storage, which means every time you delete the Pod of the Function or change its Deployment definition, the order details will be lost. Just like we did with the microservice in the previous guides, let's bind the external Redis storage to the Function to prevent the order data loss.

Bind a Redis ServiceInstance to the Function

This guide shows how you can bind a sample instance of the Redis service to the Function. After completing all the steps, you will get the Function with encoded Secrets to the service. You will use Redis as an external database for the Function. This database replaces the Function's in-memory storage.

Steps

Bind the Redis ServiceInstance to the Function

Follow these steps:

  • kubectl
  • Console UI

Call and test the Function

Follow these steps:

CAUTION: If you have a Minikube cluster, you must first add its IP address mapped to the hostname of the exposed Kubernetes Service to the hosts file on your machine:

Click to copy
echo "$(minikube ip) orders-service.kyma.local" | sudo tee -a /etc/hosts

  1. Retrieve the domain of the exposed Function and save it to an environment variable:

    Click to copy
    export FUNCTION_DOMAIN=$(kubectl get virtualservices -l apirule.gateway.kyma-project.io/v1alpha1=orders-function.orders-service -n orders-service -o=jsonpath='{.items[*].spec.hosts[0]}')

  2. Run this command in the terminal to call the Function:

    Click to copy
    curl -ik "https://$FUNCTION_DOMAIN"

    The system returns a response similar to this one:

    Click to copy
    HTTP/2 200
    access-control-allow-origin: *
    content-length: 187
    content-type: application/json; charset=utf-8
    date: Mon, 13 Jul 2020 13:05:33 GMT
    etag: W/"bb-Iuoc/aX9UjdqADJAZPNrwPdoraI"
    server: istio-envoy
    x-envoy-upstream-service-time: 25
    x-powered-by: Express
    [{"orderCode":"762727210","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}, {"orderCode":"123456789","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}]

    NOTE: The listed orders are the orders created in the previous guides.

  3. Send a POST request to the Function with sample order details:

    Click to copy
    curl -ikX POST "https://$FUNCTION_DOMAIN" \
      -H "Content-Type: application/json" \
      -H 'Cache-Control: no-cache' -d \
      '{
        "orderCode": "762727234",
        "consignmentCode": "76272725",
        "consignmentStatus": "PICKUP_COMPLETE"
      }'

  4. When you call the https://$FUNCTION_DOMAIN URL again, the system returns a response similar to this one:

    Click to copy
    HTTP/2 200
    access-control-allow-origin: *
    content-length: 280
    content-type: application/json; charset=utf-8
    date: Mon, 13 Jul 2020 13:05:51 GMT
    etag: W/"118-lAc/HJqUaWFKlQ/uyvrhuPb++80"
    server: istio-envoy
    x-envoy-upstream-service-time: 9
    x-powered-by: Express
    [{"orderCode":"762727234","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}, {"orderCode":"762727210","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}, {"orderCode":"123456789","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}]

    You can see the Function returns the previously sent order details.

  5. Remove the Pod created by the orders-function Function. Run this command, and wait for the system to delete the Pod and start a new one:

    Click to copy
    kubectl delete pod -n orders-service -l "serverless.kyma-project.io/function-name=orders-function"

  6. Call the Function again to check the storage:

    Click to copy
    curl -ik "https://$FUNCTION_DOMAIN"

    The system returns a response similar to this one:

    Click to copy
    HTTP/2 200
    access-control-allow-origin: *
    content-length: 280
    content-type: application/json; charset=utf-8
    date: Mon, 13 Jul 2020 13:05:33 GMT
    etag: W/"118-lAc/HJqUaWFKlQ/uyvrhuPb++80"
    server: istio-envoy
    x-envoy-upstream-service-time: 975
    x-powered-by: Express
    [{"orderCode":"762727234","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}, {"orderCode":"762727210","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}, {"orderCode":"123456789","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}]

As you can see, orders-function uses Redis storage now. It means that every time you delete the Pod of the Function or change its Deployment definition, the order details are preserved.

Trigger the Function with an event

As the final step, you will trigger the Function with the order.deliverysent event type from Commerce mock, send a sample event from the mock application, and test if the event reached the Function.

Steps

Create the Trigger

Follows these steps:

  • kubectl
  • Console UI

Test the Trigger

To send events from Commerce mock to orders-function, follow these steps:

  1. Access Commerce mock at https://commerce-orders-service.{CLUSTER_DOMAIN}. or use the link under Host in the Configuration > API Rules view in the order-service Namespace.

  2. Switch to the Remote APIs tab, find SAP Commerce Cloud - Events, and select it.

  3. From the Event Topics drop-down list, select the order.deliverysent.v1 event type. In the details of the printed event, change orderCode to 987654321 and select Send Event.

    A message confirming that the event was sent will appear in the UI.

  4. Call the Function to verify that the event details were saved:

    Click to copy
    curl -ik "https://$FUNCTION_DOMAIN"

    NOTE: To get the domain of the Function, run:

    Click to copy
    export FUNCTION_DOMAIN=$(kubectl get virtualservices -l apirule.gateway.kyma-project.io/v1alpha1=orders-function.orders-service -n orders-service -o=jsonpath='{.items[*].spec.hosts[0]}')

    The system returns the response proving that the 987654321 event was delivered as expected:

    Click to copy
    HTTP/2 200
    access-control-allow-origin: *
    content-length: 652
    content-type: application/json; charset=utf-8
    date: Mon, 13 Jul 2020 13:05:33 GMT
    etag: W/"28c-MLZh1MyovyUrCPwMzfRWfVQwhlU"
    server: istio-envoy
    x-envoy-upstream-service-time: 991
    x-powered-by: Express
    [{"orderCode":"987654321","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"},
    {"orderCode":"762727234","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}, {"orderCode":"762727210","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}, {"orderCode":"123456789","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}]