Workers subscribe to a topic, several workers are bundled together as a microservice. Each microservice instance connects directly to a Camunda instance, instead of a message broker such as Kafka or Mosquitto.
Repository: https://gitlab.com/lovia/lovia-infra
Camunda Instance
Camunda recommends that Camunda BPM is treated as lightweight, embeddable process engine instead of a “single BPM orchestrator instance for all” philosophy.
| Instance Hostname | Region/AZ | Distribution & Deployment |
|---|---|---|
| camunda.lovia.life | AWS ap-southeast-1a | Camunda BPM Run Docker (camunda/camunda-bpm-platform:run) on Fargate Version: 7.14 Memory: 400 Mi -> 0.5 GB CPU: 100m -> 0.25 vCPU ALB: alb-lovia-sg2 CDN: none Health check delay: with 1 GB and 0.25 vCPU it requires up to 5 minutes to start. |
Migration: make sure to apply migration SQLs in sql/upgrade in any camunda distribution, here: https://downloads.camunda.cloud/release/camunda-bpm/run/. To check which migrations you have done, and that implies which ones you haven’t applied, check table “ACT_GE_SCHEMA_LOG”.
Environment variables in Task Definition:
# https://github.com/camunda/docker-camunda-bpm-platform/issues/137
- name: JAVA_OPTS
value: ''
# Change back to HTTP port 8080 because we terminate SSL at nginx-ingress
- name: SERVER_PORT
value: '8080'
- name: SERVER_SSL_ENABLED
value: 'false'
- name: SERVLET_SESSION_COOKIE_SECURE
value: 'false'
- name: DB_DRIVER
value: com.mysql.jdbc.Driver
- name: DB_URL # /lovia/prod/mariadb/camunda/url
valueFrom:
secretKeyRef:
name: camunda
key: mariadb-url
- name: DB_USERNAME
value: camunda
- name: DB_PASSWORD # /lovia/prod/mariadb/camunda/password
valueFrom:
secretKeyRef:
name: camunda
key: mariadb-password
- name: DB_VALIDATE_ON_BORROW
value: 'true'
- name: CAMUNDA_BPM_RUN_AUTH_ENABLED
value: 'true'
- name: CAMUNDA_BPM_RUN_CORS_ENABLED
value: 'true'
- name: CAMUNDA_BPM_RUN_CORS_ALLOWED_ORIGINS
value: 'file://,http://localhost:3000,https://marketing-kit.lovia.life'
Target Group Health check path: /camunda/app/welcome/default/
However as our stack mostly uses NodeJS instead of Java, we’re still unsure how to use Camunda while still retaining this Camunda-inside-microservice principle, without complicating development and deployment. The current plan is:
- Events that are published by microservices powered by NestJS & FastAPI can be logged in Camunda (for example, by subscribing to an event bus), making it possible to trace the overall flow of a process.
- A BPMN model can be used to check whether the events have taken place in the expected order and within defined SLA limits
- Camunda itself can publish events that use an event-command pattern to signify that a certain activity in a business process should take place. This can be done by an autonomous Camunda-powered microservice subscribed to a relevant upstream event, and the resulting command can also be published as an event–meaning that Camunda coordinates the business process without violating the principle of loose coupling.
- Camunda does not necessarily play the role of a “controlling” layer and is itself simply another service with a well-defined scope: specifically, the monitoring (and possibly also management) of the end-to-end process.
Topics & Workers for Instance “camunda.lovia.life”
infra.rocketchat.PostMessage
Post message to Rocket.Chat channel in chat.lovia.life.
Note: When using regular /login API, Rocket.Chat will invalidate existing auth tokens and return 401 error “You must be logged in to do this.” which means you need to re-login the user using API. The solution is to use Personal Access Token. First grant create-personal-access-tokens to the bot. Then login (standard, without OAuth) as bot to: Profile -> My Account -> Security -> Personal Access Tokens. After that you can disable standard login in Admin Settings > Accounts.
| Variable | Description | Default |
|---|---|---|
| channel | Channel to post message | |
| text | Text to post | |
| botUsername | Bot username, e.g. miluv | loviateam | loviateam |