CRM and CX Blogs by SAP
Stay up-to-date on the latest developments and product news about intelligent customer experience and CRM technologies through blog posts from SAP experts.
cancel
Showing results for 
Search instead for 
Did you mean: 
jamie_cawley
Advisor
Advisor
This blog will detail how a Microservice can be triggered to run when an event is published into the Kyma environment.  To eliminate any barriers, we will utilize the SAP Commerce mock application to send events, but the process flow would be the same if using SAP Commerce or any other connected application. This blog continues from the setup of the SAP Commerce mock application detailed in this blog. The setup of SAP Commerce can be found in this blog.

If you already have the application bound to a namespace and an instance of the SAP Commerce Cloud – Events created, you can skip down to the step: Creating the Microservice. In the home workspace of your Kyma instance choose the commerce-mock application and then choose Create Binding and bind the application to your mocks namespace.  This will provide access to the commerce-mock application in your mocks namespace.



This will also result in one Bound Application showing in the Namespaces view. Choose the mocks namespace tile to open the namespace.



Choose the Catalog, Services and then choose SAP Commerce Cloud – Events, which is labeled with commerce-mock.



Choose Add to add a service instance, which will allow us to utilize the events within this namespace.



Accept the default values and choose Create Instance.


Creating the Microservice


For the microservice, we will use an example found on the Kyma project github site in the examples repository.  Download and save the deployment file found here as deployment.yaml 

The deployment file consists of a definition to define a Service and a Deployment.  Notice how each definition is separated by "---" which is required to define multiple definitions within a single deployment file.

The Deployment definition defines a deployment named http-db-service which exposes a number of endpoints.  For this example we will focus on the endpoint /events/order/created which will be utilized to capture an order.created event from our mock application.  More information regarding this example service can be found here.

The Service definition exposes the deployment as a local service url running as

http://<service.metadata.name>.<namespace>:<service.spec.ports.port>;

which in our case will be

http://http-db-service.mocks:8017

To subscribe the microservice to an event, we can utilize the CustomResourceDefinition (CRD) subscriptions.eventing.kyma-project.io provided by Kyma.  The CRD provides us with a set of parameters to configure our subscriptions which can be found here.  CRDs are used to extend the functionality provided by Kubernetes, more detailed information about CRDs can be found here.

Copy the contents of this subscription definition into the deployment.yaml file making sure to include the separator.
---
apiVersion: eventing.kyma-project.io/v1alpha1
kind: Subscription
metadata:
name: commerce-mock-subscription
labels:
example: commerce-mock-subscription
spec:
endpoint: http://http-db-service.mocks:8017/events/order/created
include_subscription_name_header: true
push_request_timeout_ms: 2000
max_inflight: 10
event_type: order.created
event_type_version: v1
source_id: commerce-mock

Take note that if you are not following this example exactly that the endpoint, event_type, event_type_version and source_id may need to be modified.  The first three values I believe are self explanatory and the source_id represents the name of the application as shown in the Applications list found in the home workspace.

With the subscription added to the deployment.yaml we can now deploy the example into our mocks namespace.  Within the mocks overview screen click the Deploy new resource to the namespace button and choose and upload the deployment.yaml file.

You should receive a message indicating that the resource has been created after uploading the file.



To verify that the subscription has been registered correctly, choose the Logs option in the home workspace.



We can use the following label to view the subscription result which should show that it has been created and reconciled as shown in the image below.

{app="event-bus-subscription-controller-knative"}



After verifying that the subscription has been registered, open the commerce mock application, choose Remote APIs and then choose SAP Commerce Cloud – Events.



This will navigate you to a page where you can send an event and also provides details regarding the API.  In Event Topics choose order.created.v1 from the drop down list for the desired event.  This will place an entry into the field below, which can be edited as desired.  This is the data object that will be sent and consumed by the microservice.  Press the Send Event button to trigger the event.



To verify that the event has been consumed open the logs and use the following search value to verify the output of microservice.  You should find the message "Handling event ... with my custom logic".

{app="http-db-service"}Handling



Next, explore the tracing features of Kyma, which are provided by Jaeger.  The intent of this section is to outline how a trace should appear for a working microservice. Using a known working example should help identify possible focus areas in the case of troubleshooting issues.

In the home workspace choose the Tracing menu.


Within the Find Traces pane, set commerce-mock-event-service.kyma-integration as the chosen service and then choose the Find Traces to show the results of the event order.created being sent.  Notice how the event has spanned multiple services.  Any of these services could be used as the selected service in the Find Traces to show the same information.  Choose the trace to obtain further information.



Here you can see the entire flow of trace in the order it was processed, and the time utilized by each service.  Choosing the http-db-service.mocks we can verify that the event was published to the http-db-service endpoint.