Migration from Appway to Camunda (with CIB seven): Architecture and integration

Introduction
Welcome to the three-part ONLU blog series “Migration from Appway to Camunda (with CIB seven)”. We will provide you with in-depth expert knowledge – from the reasons behind the migration to the technical implementation and tried-and-tested best practices.

Table of contents

1. Part 1: Introduction & Motivation
2. Part 2: Architecture & Integration
3. Part 3: Best practices & migration strategies

Modern architecture: Kafka integration and event-driven workflows

Camunda and Kafka fulfill different but complementary roles. Camunda acts as an orchestrator that controls the process flow and decisions – what should happen next – while Kafka serves as a highly scalable event platform to exchange these decisions and data between distributed systems camunda.com. In other words, Camunda decides on the next step based on the process context, and Kafka reliably transports the corresponding messages/events to the microservices that are supposed to execute the steps camunda.com. This combination of process-oriented orchestration and event-driven processing combines the best of both worlds: Camunda maintains an overview of long-running, complex processes, while Kafka decouples the services and allows them to run in parallel.

In practical implementation, there are several options for integration:

• Service tasks with Kafka connection: A service task in the Camunda process can be implemented in such a way that it automatically sends a message to a Kafka topic (producer) when it is reached. A consuming microservice listens to this topic and executes the action (e.g. a calculation or database operation). As soon as the microservice has completed its work, it can in turn send an event to Kafka, which informs Camunda of a pending next step. Camunda can receive such events by, for example, an external worker or a Kafka connector intercepting the message and then correlating a message catch event or a corresponding process instance via REST. Newer Camunda versions (8 / SaaS) even offer out-of-the-box Kafka connectors for this, which enable inbound and outbound events on Kafka without a lot of boilerplate code camunda.com. In Camunda 7/CIB seven you can achieve something similar with External Task Workers or custom Java Delegates.
• Complete event orchestration: Alternatively, Camunda can also be embedded more strongly in an event-driven architecture by using it as a kind of supervising service. An example pattern is event-driven orchestration: The Camunda process waits at certain points for events (message intermediate events) that come from other systems via Kafka and then decides how to proceed. The process model therefore increasingly works with message events instead of synchronous service calls. The models become somewhat more complex, but a very loose coupling is achieved. A practical example: A Camunda instance (e.g. in an “Orchestrator” microservice) starts a business process and first publishes events for the necessary steps (e.g. “Check A started”). The consuming services carry out their task and send back an event on completion (“Check A completed”). The Camunda process intercepts this event and moves on to the next step. This pattern requires a little more implementation effort, but offers maximum decoupling and scalabilitymedium.com. In any case, it is important to clearly define which events are expected by the process and how errors (e.g. timeouts or missing responses) are handled.

Regardless of the integration approach, when migrating to an event-driven architecture, care should be taken not to cast existing synchronous calls (such as SOAP or REST) 1:1 into events without careful consideration. Not every process step is suitable as an asynchronous event. A hybrid architecture often makes sense: time-critical or highly sequential steps can continue to be connected synchronously via REST/HTTP, while decoupled parts are orchestrated via Kafka. The target image is a microservice-based workflow system in which Camunda acts as the central brain and Kafka as the nervous system that distributes the messages. This architecture enables new services to be easily connected or exchanged without having to change the process – only the corresponding event needs to be produced or consumed.

In the next article , we will delve deeper into best practices and migration strategies and show how Camunda and CIB seven can be integrated into modern microservice landscapes for a smooth transition.

• Appway background and takeover by FNZ fnz.com
• Challenges of monolithic BPM platforms (vendor lock-in) camunda.com
• BPMN standard prevents vendor lock-in camunda.com
• Camunda vs. Appway – a comparison of functions softwaresuggest.com
• CIB seven and CIB flow – Description of the components onlu.ch
• CIB seven advantages (open source, compatibility) onlu.ch
• Camunda SOAP integration (Connector) docs.camunda.org
• Camunda & Kafka Interaction camunda.com
• Event-driven orchestration with Camunda (example) medium.com
• Migration strategies Parallel vs. big bang camunda.com