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.
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|
Memory: 400 Mi -> 0.5 GB
CPU: 100m -> 0.25 vCPU
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”
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.
|channel||Channel to post message|
|text||Text to post|
|botUsername||Bot username, e.g. miluv | loviateam||loviateam|