Camunda em detalhe: o motor de orquestração BPMN/DMN para processos modernos
A Camunda é uma plataforma de orquestração de processos baseada em BPMN 2.0 e DMN 1.3. Com o motor distribuído Zeebe e aplicações como Operate, Tasklist e Optimize, coordena pessoas, sistemas, APIs, RPA e até agentes de IA em larga escala.
Principais destaques
- Execução escalável e resiliente para workloads distribuídos (partições, job workers, backpressure).
- Transparência operacional com métricas, incidents e logs quase em tempo real no Operate.
- Integração com qualquer stack — Java, Python, REST, Kafka, etc.
- Suporte nativo a BPMN 2.0, DMN 1.3 e padrões de compensação/eventos. :contentReference[oaicite:1]{index=1}
- Open source no core, com extensões enterprise para governança e segurança.
Arquitetura de alto nível
- Zeebe como motor distribuído de processos e decisões. :contentReference[oaicite:2]{index=2}
- Operate para monitorização e resolução de incidents.
- Tasklist para trabalho humano (user tasks).
- Optimize para analytics de processos.
- Web/Desktop Modeler para modelação colaborativa em BPMN/DMN.
Exemplo de processo BPMN (Camunda 8.5+, com compensação)
Modelo pronto a importar no Camunda Desktop Modeler (8.5+). Inclui service tasks, boundary timer, boundary error e compensação (suportada desde 8.5). :contentReference[oaicite:3]{index=3}
<?xml version="1.0" encoding="UTF-8"?>
<definitions
xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:zeebe="http://camunda.org/schema/zeebe/1.0"
targetNamespace="http://example.tld/camunda">
<!-- Erro de negócio para a expedição -->
<error id="Error_Ship" name="Shipping failed" errorCode="SHIP_FAIL"/>
<process id="order_fulfillment" name="Order Fulfillment" isExecutable="true">
<startEvent id="start" name="Order Received"/>
<sequenceFlow id="f1" sourceRef="start" targetRef="reserveStock"/>
<serviceTask id="reserveStock" name="Reserve Stock">
<extensionElements>
<zeebe:taskDefinition type="reserve-stock" retries="3"/>
</extensionElements>
</serviceTask>
<!-- Boundary timer com ISO-8601 duration -->
<boundaryEvent id="timeoutReserve" attachedToRef="reserveStock">
<timerEventDefinition>
<timeDuration>PT30S</timeDuration>
</timerEventDefinition>
</boundaryEvent>
<sequenceFlow id="f2" sourceRef="reserveStock" targetRef="authorizePayment"/>
<serviceTask id="authorizePayment" name="Authorize Payment">
<extensionElements>
<zeebe:taskDefinition type="authorize-payment" retries="3"/>
<zeebe:ioMapping>
<zeebe:input source="=order.amount" target="amount"/>
</zeebe:ioMapping>
</extensionElements>
</serviceTask>
<!-- Handler de compensação para 'Authorize Payment' -->
<serviceTask id="undoPayment" name="Undo Payment" isForCompensation="true">
<extensionElements>
<zeebe:taskDefinition type="undo-payment" retries="3"/>
</extensionElements>
</serviceTask>
<!-- Associação correta: tarefa original -> tarefa de compensação -->
<association id="assoc_comp_payment" sourceRef="authorizePayment" targetRef="undoPayment" associationDirection="One"/>
<sequenceFlow id="f3" sourceRef="authorizePayment" targetRef="shipOrder"/>
<serviceTask id="shipOrder" name="Ship Order">
<extensionElements>
<zeebe:taskDefinition type="ship-order" retries="3"/>
</extensionElements>
</serviceTask>
<!-- Se o worker lançar erro 'SHIP_FAIL', desvia para o boundary -->
<boundaryEvent id="errorOnShip" attachedToRef="shipOrder">
<errorEventDefinition errorRef="Error_Ship"/>
</boundaryEvent>
<!-- Dispara a compensação do pagamento (ex.: após erro de expedição) -->
<intermediateThrowEvent id="compTrigger" name="Trigger Compensation">
<compensateEventDefinition activityRef="authorizePayment"/>
</intermediateThrowEvent>
<sequenceFlow id="f4" sourceRef="shipOrder" targetRef="end"/>
<endEvent id="end" name="Completed"/>
</process>
</definitions>
Notas de compatibilidade: timers requerem timeDuration/timeCycle válidos; boundary error deve referenciar um <error> com errorCode; compensação em 8.5 usa isForCompensation="true" + <compensateEventDefinition>. :contentReference[oaicite:4]{index=4}
Exemplo de decisão DMN 1.3 (importável no Modeler)
Decisão simples de elegibilidade STP com FEEL; pronta a importar no Modeler (DMN 1.3). :contentReference[oaicite:5]{index=5}
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="https://www.omg.org/spec/DMN/20191111/MODEL/"
xmlns:feel="https://www.omg.org/spec/DMN/20191111/FEEL/"
id="defs" name="STPDefinitions" namespace="http://example.tld/dmn">
<decision id="STPEligibility" name="STPEligibility">
<decisionTable id="table" hitPolicy="FIRST">
<input id="i1">
<inputExpression id="iex1" typeRef="string">
<text>riskTier</text>
</inputExpression>
</input>
<input id="i2">
<inputExpression id="iex2" typeRef="number">
<text>score</text>
</inputExpression>
</input>
<input id="i3">
<inputExpression id="iex3" typeRef="boolean">
<text>pepMatch</text>
</inputExpression>
</input>
<input id="i4">
<inputExpression id="iex4" typeRef="boolean">
<text>docsComplete</text>
</inputExpression>
</input>
<output id="o1" name="result" typeRef="string"/>
<rule id="r1">
<inputEntry id="ie11"><text>-</text></inputEntry>
<inputEntry id="ie12"><text>-</text></inputEntry>
<inputEntry id="ie13"><text>true</text></inputEntry>
<inputEntry id="ie14"><text>-</text></inputEntry>
<outputEntry id="oe1"><text>"REVIEW"</text></outputEntry>
</rule>
<rule id="r2">
<inputEntry id="ie21"><text>-</text></inputEntry>
<inputEntry id="ie22"><text>-</text></inputEntry>
<inputEntry id="ie23"><text>-</text></inputEntry>
<inputEntry id="ie24"><text>false</text></inputEntry>
<outputEntry id="oe2"><text>"REVIEW"</text></outputEntry>
</rule>
<rule id="r3">
<inputEntry id="ie31"><text>"LOW"</text></inputEntry>
<inputEntry id="ie32"><text>>= 640</text></inputEntry>
<inputEntry id="ie33"><text>false</text></inputEntry>
<inputEntry id="ie34"><text>true</text></inputEntry>
<outputEntry id="oe3"><text>"STP"</text></outputEntry>
</rule>
<rule id="r4">
<inputEntry id="ie41"><text>"MEDIUM"</text></inputEntry>
<inputEntry id="ie42"><text>>= 680</text></inputEntry>
<inputEntry id="ie43"><text>false</text></inputEntry>
<inputEntry id="ie44"><text>true</text></inputEntry>
<outputEntry id="oe4"><text>"STP"</text></outputEntry>
</rule>
<rule id="r5">
<inputEntry id="ie51"><text>"HIGH"</text></inputEntry>
<inputEntry id="ie52"><text>-</text></inputEntry>
<inputEntry id="ie53"><text>-</text></inputEntry>
<inputEntry id="ie54"><text>-</text></inputEntry>
<outputEntry id="oe5"><text>"REVIEW"</text></outputEntry>
</rule>
</decisionTable>
</decision>
</definitions>
Integração com qualquer stack
- Job workers (Java, Python, Node, Go, etc.) para executar service tasks.
- REST para comandos e consulta; Kafka/AMQP para eventos.
- RPA como adapter quando não há API, mantendo orquestração no BPMN.
- IA: acionar LLM agents como tarefas assíncronas com timeouts/compensações.
Exemplo — Mensagem Zeebe (JSON)
{
"messageName": "kyc_result",
"correlationKey": "ONB-7f3c9c12",
"timeToLive": 600000,
"variables": {
"kycStatus": "PASS",
"providerLatencyMs": 842
}
}
Exemplo — Variáveis de instância (JSON)
{
"orderId": "ORD-98765",
"amount": 129.90,
"paymentAuthId": "PA-332211",
"reservationId": "RSV-333"
}
Padrões de resiliência e governança
- Retry com backoff e idempotência a partir dos workers.
- Compensações modeladas em BPMN (ordem inversa das ações) e event subprocess para cancelamentos. :contentReference[oaicite:6]{index=6}
- Observabilidade: traceparent, correlationId, métricas e event store.
- Segurança & compliance: authn/authz, auditing, segregação de funções e políticas de retenção.
Camunda vs. alternativas
| Critério | Camunda | Alternativas pontuais |
|---|---|---|
| Notação | BPMN 2.0 / DMN 1.3 | Proprietária ou parcial |
| Escala | Zeebe distribuído | Limitada ao nó |
| Observabilidade | Operate/Optimize | Scripts e logs ad hoc |
| Integração | Workers, REST, Kafka | Conectores fechados |
| Modelo comercial | Core open source + enterprise | Fechado |
Boas práticas
- Separar decisões em DMN; manter BPMN limpo de regras complexas.
- Idempotency keys e outbox pattern nas integrações.
- Message correlation com chaves estáveis (ex.:
correlationId). - Timer boundary events para SLAs e recuperação automática. :contentReference[oaicite:7]{index=7}
- Playbooks para tratar incidents e DLQ.
Conclusão
Em cenários que exigem orquestração end-to-end, a Camunda revela-se um ativo estratégico indispensável: combina BPMN/DMN padrão, execução distribuída com o Zeebe e aplicações de observabilidade que trazem transparência e confiança. Com os modelos acima, já tens exemplos compatíveis com 8.5+ para importar diretamente no Modeler e começar a executar.
You may also like
Leave a Reply