Order Management - Query
Overview
Description: Main goal of the Order Management component is to manage the shipping orders for the entire shipping fleet. This component is made up of two microservices - one named Order Command and one named Order Query. The reason for the component to be split into two microservices is to implement the Command Query Responsibility Segregation (CQRS) pattern.
This microservice will implement the query logic in the CQRS pattern. It will be in charge of implementing any type of query, based on building the necessary projections over the totality of the data. In order to build those projections, this microservice can listen to more topics and events than the Order Command microservice.
This microservice has been implemented using MicroProfile 3.0 and runs on OpenLiberty.
Github repository: refarch-kc-order-ms
Folder: order-query-ms
Kafka topics consumed from:
Kafka topics produced to: None
Events reacted to:
- Order Created Event
- Order Updated Event
- Order Reject Event
- Order Cancel Event
- Order Spoilt Event
- Voyage Assigned Event
- Container Allocated Event
- Container Added Event
- Container On Maintenance Event
- Container Off Maintenance Event
- Container Assigned Event
Events produced: None
EDA Patterns implemented:
- Command Query Responsibility Segregation (CQRS)
Build
This microservice is built using the Appsody development framework. The Appsody CLI is a required prerequisite for building the application locally.
Appsody will build the application by pulling the contents of the Appsody Stack it is based on and then performing the local application build inside the containerized environment:
appsody build -t <yournamespace>/kcontainer-order-query-ms[:tag] [--push]
- You can optionally specify a container tag. If left blank,
latestwill be used. - You can optionally supply the
--pushflag to automatically push the built image to specified remote repository.
Performing an Appsody build will update the app-deploy.yaml file in the same directory with current information for the application image, labels, and annotations fields.
Run
Deployment parameters
The following deployment parameters are defined in the app-deploy.yaml file:
| Name | Required | Description |
|---|---|---|
| KAFKA_BROKERS | YES | Comma-separated list of Kafka brokers to connect to |
| KAFKA_APIKEY | NO | API Key used to connect to SASL-secured Kafka brokers. This is required when connecting to IBM Event Streams clusters. |
| TRUSTSTORE_ENABLED | NO | Required to be set to true when connecting to IBM Event Streams on the IBM Cloud Pak for Integration (CP4I). |
| TRUSTSTORE_PATH | NO | The local path to the required truststore file when connecting to IBM Event Streams on CP4I. See Volume Mounts below. |
| TRUSTSTORE_PWD | NO | The password for the truststore file used for IBM Event Streams server verification. |
| ORDER_TOPIC | YES | The topic name used for communication relating to the orders entity. |
| CONTAINER_TOPIC | YES | The topic name used for communication relating to the containers entity. |
| ERROR_TOPIC | YES | The topic name used for communication relating to general application errors. |
Volume Mounts
The Order Query microservice requires up to one file to be injected at runtime for proper operation. As noted in the TRUSTSTORE_PATH parameter above, these files are SSL-based certificates which are required to verfiy the identity of the external service when calling it. These files are provided as --docker-options "-v host-src:container-dest ..." when running the microservice locally and as a Volume Mount when running the microservice on a Kubernetes cluster.
The TRUSTSTORE_PATH parameter is documented in the Event Streams Certificates section of the Prerequisites page. The Appsody run command should include a parameter similar to -v /Users/myuser/Downloads/es-cert.jks:/config/resources/security/es-ssl/es-cert.jks in its --docker-options string to run this microservice locally.
Example: appsody run --docker-options "-v /Users/myuser/Downloads/es-cert.jks:/config/resources/security/es-ssl/es-cert.jks" ...
Running the microservice locally
When running the microservice locally, you must specify all the required deployment parameters from above as environment variables via the --docker-options flag being passed in from the Appsody CLI command.
Example: appsody run --docker-options "-e KAFKA_BROKERS=remotebroker1:9092,remotebroker2:9092 -e ORDER_TOPIC=orders -e CONTAINERS_TOPIC=containers -v /Users/myuser/Downloads/es-cert.jks:/config/resources/security/es-ssl/es-cert.jks" ...
For more details on running the microservice locally, consult the Appsody run documentation as well as the deployment information contained in the app-deploy.yaml file.
Running the microservice remotely
The Appsody Operator is a required prerequisite for deploying the microservice to a remote Kubernetes or OpenShift cluster.
To deploy the microservice to a remote cluster:
appsody deploy <yournamespace>/kcontainer-order-query-ms[:tag] --no-build
- You can omit the
--no-buildflag to have Appsody perform a build before deploying the application. - Note: Performing a build at deploy time requires specifying the absolute container reference path, as well as the
--pushflag. - The neccesary deployment parameter information will be read from the
app-deploy.yamlfile in the same directory.