Eventuate Tram Customers and Orders Examples

The Order History Service is responsible for maintaining order history. It functions as a consumer of events from both the Customer and Order domains to build and serve its data.

Capabilities

• Order Management

Service API

• Queries (Synchronous):
  • getOrderForCustomer()

Observability

• Health check endpoint: /actuator/health

The Customer Service is responsible for managing customers and their available credit. It provides a synchronous command API and publishes events to specific event channels to communicate state changes to other services.

### Service API

**Synchronous Commands:**
* `createCustomer()`

**Events Published (Customer event channel):**
* `Credit Reserved`
* `Credit Reservation Failed`
* `Customer Validation Failed`

The Order Service is responsible for managing orders. It provides synchronous command and query APIs and publishes events to an order event channel. It also subscribes to events from the Customer event channel to react to customer-related changes.

### Service API

**Commands (Synchronous):**
* `createOrder()`
* `cancelOrder()`

**Queries (Synchronous):**
* `getOrder()`

**Events Published (Order event channel):**
* `Order Created`
* `Order Approved`
* `Order Rejected`

**Subscribed Events (Customer event channel):**
* `Credit Reserved`
* `Credit Reservation Failed`
* `Customer Validation Failed`

The Order History Service maintains its state by subscribing to the following events from the event channels:

Customer event channel

• Customer Created

Order event channel

• Order Created
• Order Approved
• Order Rejected

The Customer Service subscribes to the Order event channel to react to changes in order states. It listens for the following events:

• Order Created
• Order Approved
• Order Rejected
• Order Cancelled

The services use the Eventuate Tram framework for asynchronous communication via events. The framework ensures atomicity between database updates and event publishing using the following flow:

1. Local Transaction: Eventuate Tram inserts events into a MESSAGE table as part of the same ACID transaction that updates the JPA entity.
2. CDC (Change Data Capture): The Eventuate Tram CDC service tracks inserts into the MESSAGE table (using MySQL binlog or Postgres WAL) and publishes those messages to Apache Kafka.
3. Consumption: A subscribing service receives the event from Kafka, updates its own database, and may publish further events.

Once the application is running, you can interact with the services through the API Gateway. Note that you must replace 8080 with the actual port assigned to the API Gateway during startup.

Common tasks include creating customers, creating orders, checking order status, and querying order history.

# 1. Create a customer
curl -X POST --header "Content-Type: application/json" -d '{
  "creditLimit": {
    "amount": 5
  },
  "name": "Jane Doe"
}' http://localhost:8080/customers

# 2. Create an order
curl -X POST --header "Content-Type: application/json" -d '{
  "customerId": 1,
  "orderTotal": {
    "amount": 4
  }
}' http://localhost:8080/orders

# 3. Check order status
curl -X GET http://localhost:8080/orders/1

# 4. Check customer order history (CQRS view)
curl -X GET --header "Accept: */*" "http://localhost:8080/customers/1/orderhistory"

Use the invoke-api.sh script to verify that the deployed services are responding correctly.

./deployment/terraform_azure/invoke-api.sh

To deploy the application infrastructure on Azure, first authenticate with the Azure CLI, then execute the Terraform apply script. This process sets up the necessary Azure resources, including the AKS cluster.

az login

deployment/terraform_azure/terraform_azure-apply.sh

To start the application along with all required infrastructure services (databases, Kafka, etc.), use the Gradle wrapper. You can choose between MySQL or Postgres as the underlying database. The command will start containers on unique ports and print the home page URL, which contains links to the Swagger UIs and the API Gateway.

# Using MySQL
./gradlew :end-to-end-tests:runApplicationMySQL

# Using Postgres
./gradlew :end-to-end-tests:runApplicationPostgres

To avoid ongoing costs, perform the cleanup in the following order:

1. Delete the main Kubernetes resources.
2. Delete the Ingress Controller.
3. Destroy the Terraform-managed Azure resources.

# 1. Delete main Kubernetes resources
./deployment/terraform_azure/terraform_azure-k8s-delete.sh

# 2. Delete the Ingress Controller
./deployment/terraform_azure/terraform_azure-k8s-delete-ingress-controller.sh

# 3. Destroy Terraform resources
./deployment/terraform_azure/terraform_azure-destroy.sh