Best practices of using service task in Camunda


While working with “Service Task” in Camunda which is the recommended way or the best practices to use it when deploying the code on cloud platforms like Azure etc.

Is it Java class or External or Delegate Expression?

Also, please highlight some benefits of it.

Hi @GauravSinha,

It depends on the requirement and the application setup.

By using expression delegates, we can initialize the delegate class as we want using spring DI without letting Camunda engine to initialize it. And take all advantages of DI.

For example,

<bpmn:serviceTask id="PerformKYC" name="Perform KYC" camunda:asyncBefore="true" camunda:delegateExpression="${kycVerificationDelegate}">

In above, kycVerificationDelegate is resolved from spring and it will be an instance of JavaDelegate which has already initialized with required dependencies through dependency injection (DI).

If we use Java classes, then the instance initialization part will be done by the camunda engine, and there is a restriction that there must be a public default constructor. This is very limited since most of practical applications have dependencies and must be already initialized before the code.

For long running service tasks, timeout and scaling can be achieved better using External Task patterns. This pattern is based on Pull approach.

External tasks can be used to achieve:

  1. Temporal decoupling: the pattern can replace a message queue between the service task (the “consumer”) and the service implementation (the “provider”). It can eliminate the need for operating a dedicated message bus while keeping the decoupling that messaging would provide.
  2. Polyglott architectures: the pattern can be used to integrate - for example - .NET based services, when it might not be that easy to write Java delegates to call them. Service implementations are possible in any language that can be used to interact with a REST API.
  3. Better scaling: the pattern allows you to start and stop workers as you like - and run as many of them as you need. By doing so, you can scale each service task (or to be precise: each “topic”) individually.
  4. Connect Cloud BPM to On Premise services: the pattern supports you in running Camunda somewhere in the cloud (as our customers often do), because you can still have services on-premise, as they can now query their work via REST over SSL, which is also quite firewall-friendly.
  5. Avoid Timeouts: the pattern allows you to asynchronously call long-running services, which eventually block for hours (and would therefore cause transaction and connection timeouts when being called synchronously).
  6. Run services on specialized hardware: Each worker can run in the environment that is best suited for the specific task of that worker, for example CPU-optimized cloud instances for complex image processing and memory-optimized instances for other tasks.