Description: Main goal of the Order Management component is to manage B2B Messaging utilziing the Command Query Responsibility Segregation (CQRS) Pattern.
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)
- 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
The following deployment parameters are defined in the
|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 Event Streams clusters.|
|TRUSTSTORE_ENABLED||NO||Required to be set to |
|TRUSTSTORE_PATH||NO||The local path to the required truststore file when connecting to Event Streams on CP4I. See Volume Mounts below.|
|TRUSTSTORE_PWD||NO||The password for the truststore file used for 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.|
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
TRUSTSTORE_PATH parameter is documented in the Event Streams
Certificates section of the
page. The Appsody run command should include a parameter similar to
--docker-options string to run this microservice locally.
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
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" ...
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
- The neccesary deployment parameter information will be read from the
app-deploy.yamlfile in the same directory.