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:
- 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.
- Provision the Redis service through Service Catalog and use it as an alternative database for the microservice.
- Connect an external mock application to Kyma as an addon. We will use it to send events with order delivery details to the microservice.
- 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 amicroservice
. 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 asapplication
andApplication
respectively.
All guides, whenever possible, demonstrate the steps in both kubectl and Console UI.
Prerequisites
- Install:
- 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 oforders-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
andenterprise
. 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 themicro
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:
- Create the
orders-service
Namespace in which you will deploy all resources. - Create a microservice by deploying
orders-service
on the cluster in the created Namespace. - 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.
- Add the Redis service as an addon.
- Create the Redis service instance (ServiceInstance CR) in the Namespace so you can bind it with the microservice and Function.
- 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.
- Connect Commerce mock as the external application.
- 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. - 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:
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
Retrieve the domain of the exposed microservice and save it to the environment variable:
Click to copyexport 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]}')Run this command in the terminal to call the Service:
Click to copycurl -ik "https://$SERVICE_DOMAIN/orders"The system returns a response similar to this one:
Click to copycontent-length: 2content-type: application/json;charset=UTF-8date: Mon, 13 Jul 2020 13:05:33 GMTserver: istio-envoyvary: Originx-envoy-upstream-service-time: 37[]Send a
POST
request to the microservice with sample order details:Click to copycurl -ikX POST "https://$SERVICE_DOMAIN/orders" \-H 'Cache-Control: no-cache' -d \'{"orderCode": "762727210","consignmentCode": "76272725","consignmentStatus": "PICKUP_COMPLETE"}'Call the microservice again to check the storage:
Click to copycurl -ik "https://$SERVICE_DOMAIN/orders"Expect a response similar to this one:
Click to copyHTTP/2 200content-length: 73content-type: application/json;charset=UTF-8date: Mon, 13 Jul 2020 13:05:51 GMTserver: istio-envoyvary: Originx-envoy-upstream-service-time: 6[{"orderCode":"762727210","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}]You can see that the microservice returns the previously sent order details.
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 copykubectl delete pod -n orders-service -l app=orders-serviceCall the microservice again to check the storage:
Click to copycurl -ik "https://$SERVICE_DOMAIN/orders"The system returns a response similar to this one:
Click to copycontent-length: 2content-type: application/json;charset=UTF-8date: Mon, 13 Jul 2020 13:05:33 GMTserver: istio-envoyvary: Originx-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
Retrieve the domain of the exposed microservice and save it to an environment variable:
Click to copyexport 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]}')Run this command in the terminal to call the service:
Click to copycurl -ik "https://$SERVICE_DOMAIN/orders"Expect a response similar to this one:
Click to copycontent-length: 2content-type: application/json;charset=UTF-8date: Mon, 13 Jul 2020 13:05:33 GMTserver: istio-envoyvary: Originx-envoy-upstream-service-time: 37[]Send a
POST
request to the microservice with sample order details:Click to copycurl -ikX POST "https://$SERVICE_DOMAIN/orders" \-H 'Cache-Control: no-cache' -d \'{"orderCode": "762727210","consignmentCode": "76272725","consignmentStatus": "PICKUP_COMPLETE"}'When you call the
https://$SERVICE_DOMAIN/orders
URL again, the system returns a response with order details similar to these:Click to copyHTTP/2 200content-length: 73content-type: application/json;charset=UTF-8date: Mon, 13 Jul 2020 13:05:51 GMTserver: istio-envoyvary: Originx-envoy-upstream-service-time: 6[{"orderCode":"762727210","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}]Similarly to the previous guide where you exposed the
orders-service
microservice, remove the Pod created by theorders-service
Deployment. Run this command, and wait for the system to delete the Pod and start a new one:Click to copykubectl delete pod -n orders-service -l app=orders-serviceCall the microservice again to check the storage:
Click to copycurl -ik "https://$SERVICE_DOMAIN/orders"Expect a response similar to this one:
Click to copycontent-length: 2content-type: application/json;charset=UTF-8date: Mon, 13 Jul 2020 13:05:33 GMTserver: istio-envoyvary: Originx-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:
- Once in the
order-service
Namespace, go to Configuration > API Rules > commerce-mock in the left navigation panel. - Open the link under the Host column to access Commerce mock.
- Click Connect.
- Paste the previously copied URL with the token, check Insecure Connection, confirm by selecting Connect, and wait until the application gets connected.
- 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:
Access Commerce mock at
https://commerce-orders-service.{CLUSTER_DOMAIN}.
or use the link under Host in the Configuration > API Rules view in theorder-service
Namespace.Switch to the Remote APIs tab, find SAP Commerce Cloud - Events, and select it.
From the Event Topics drop-down list, select the
order.deliverysent.v1
event type.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.
Call the microservice to verify that the event details were saved:
Click to copycurl -ik "https://$SERVICE_DOMAIN/orders"NOTE: To get the domain of the microservice, run:
Click to copyexport 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 copycontent-length: 2content-type: application/json;charset=UTF-8date: Mon, 13 Jul 2020 13:05:33 GMTserver: istio-envoyvary: Originx-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
andPOST
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
Retrieve the domain of the exposed Function and save it to an environment variable:
Click to copyexport 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]}')Call the Function:
Click to copycurl -ik "https://$FUNCTION_DOMAIN"The system returns a response similar to this one:
Click to copycontent-length: 2content-type: application/json;charset=UTF-8date: Mon, 13 Jul 2020 13:05:33 GMTserver: istio-envoyvary: Originx-envoy-upstream-service-time: 37[]Send a
POST
request to the Function with sample order details:Click to copycurl -ikX POST "https://$FUNCTION_DOMAIN" \-H "Content-Type: application/json" \-H 'Cache-Control: no-cache' -d \'{"orderCode": "762727210","consignmentCode": "76272725","consignmentStatus": "PICKUP_COMPLETE"}'Call the Function again to check the storage:
Click to copycurl -ik "https://$FUNCTION_DOMAIN"The system returns a response similar to this one:
Click to copyHTTP/2 200access-control-allow-origin: *content-length: 187content-type: application/json; charset=utf-8date: Mon, 13 Jul 2020 13:05:51 GMTetag: W/"bb-Iuoc/aX9UjdqADJAZPNrwPdoraI"server: istio-envoyx-envoy-upstream-service-time: 838x-powered-by: Express[{"orderCode":"762727210","consignmentCode":"76272725","consignmentStatus":"PICKUP_COMPLETE"}]You can see the Function returns the previously sent order details.
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 copykubectl delete pod -n orders-service -l "serverless.kyma-project.io/function-name=orders-function"Call the Function again to check the storage:
Click to copycurl -ik "https://$FUNCTION_DOMAIN"The system returns a response similar to this one:
Click to copyHTTP/2 200access-control-allow-origin: *content-length: 187content-type: application/json; charset=utf-8date: Mon, 13 Jul 2020 13:05:33 GMTetag: W/"bb-Iuoc/aX9UjdqADJAZPNrwPdoraI"server: istio-envoyx-envoy-upstream-service-time: 838x-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
Retrieve the domain of the exposed Function and save it to an environment variable:
Click to copyexport 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]}')Run this command in the terminal to call the Function:
Click to copycurl -ik "https://$FUNCTION_DOMAIN"The system returns a response similar to this one:
Click to copyHTTP/2 200access-control-allow-origin: *content-length: 187content-type: application/json; charset=utf-8date: Mon, 13 Jul 2020 13:05:33 GMTetag: W/"bb-Iuoc/aX9UjdqADJAZPNrwPdoraI"server: istio-envoyx-envoy-upstream-service-time: 25x-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.
Send a
POST
request to the Function with sample order details:Click to copycurl -ikX POST "https://$FUNCTION_DOMAIN" \-H "Content-Type: application/json" \-H 'Cache-Control: no-cache' -d \'{"orderCode": "762727234","consignmentCode": "76272725","consignmentStatus": "PICKUP_COMPLETE"}'When you call the
https://$FUNCTION_DOMAIN
URL again, the system returns a response similar to this one:Click to copyHTTP/2 200access-control-allow-origin: *content-length: 280content-type: application/json; charset=utf-8date: Mon, 13 Jul 2020 13:05:51 GMTetag: W/"118-lAc/HJqUaWFKlQ/uyvrhuPb++80"server: istio-envoyx-envoy-upstream-service-time: 9x-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.
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 copykubectl delete pod -n orders-service -l "serverless.kyma-project.io/function-name=orders-function"Call the Function again to check the storage:
Click to copycurl -ik "https://$FUNCTION_DOMAIN"The system returns a response similar to this one:
Click to copyHTTP/2 200access-control-allow-origin: *content-length: 280content-type: application/json; charset=utf-8date: Mon, 13 Jul 2020 13:05:33 GMTetag: W/"118-lAc/HJqUaWFKlQ/uyvrhuPb++80"server: istio-envoyx-envoy-upstream-service-time: 975x-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:
Access Commerce mock at
https://commerce-orders-service.{CLUSTER_DOMAIN}.
or use the link under Host in the Configuration > API Rules view in theorder-service
Namespace.Switch to the Remote APIs tab, find SAP Commerce Cloud - Events, and select it.
From the Event Topics drop-down list, select the
order.deliverysent.v1
event type. In the details of the printed event, change orderCode to987654321
and select Send Event.A message confirming that the event was sent will appear in the UI.
Call the Function to verify that the event details were saved:
Click to copycurl -ik "https://$FUNCTION_DOMAIN"NOTE: To get the domain of the Function, run:
Click to copyexport 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 copyHTTP/2 200access-control-allow-origin: *content-length: 652content-type: application/json; charset=utf-8date: Mon, 13 Jul 2020 13:05:33 GMTetag: W/"28c-MLZh1MyovyUrCPwMzfRWfVQwhlU"server: istio-envoyx-envoy-upstream-service-time: 991x-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"}]