Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-8439

I can use a Java client for external tasks

    XMLWordPrintable

    Details

    • Type: Feature Request
    • Status: Closed
    • Priority: L3 - Default
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 7.9.0, 7.9.0-alpha3
    • Component/s: engine
    • Labels:
      None

      Description

      User stories

      • In TaskContext I can complete tasks, handle failures, handle bpmn errors
      • In TaskContext I can use variables (get) and set variables on task completion
        • all variables or a defined set of variables can be retrieved according to the name per client#registerWorker#variables
      • I can configure the thread pool through application servers
      • I can use the CamundaClient fluent builder to pass basic authentication credentials
      • I can enable the priority flag per CamundaClient#create#usePriority / I can enable the priority flag per client#registerWorker#usePriority
      • I can see/report if a task could not be successfully completed due to the expiration of the lock duration
      • I can create/delete deployments and start process instances
      • I can read documentation about the java client for external tasks
      • CI / SRE
        • Tests are executed
        • Artefact is publicly available

      See prototype on https://github.com/tasso94/camunda-worker-java

      API

      • CamundaClient#create returns a fluent builder to init the client with
        • endpoint url (mandatory), client id, max tasks per fetch and lock request, async respose timeout
        • queue size, number of worker threads => thread pool to execute Worker objects
      • CamundaClient#build returns the configured CamundaClient object
      • client#registerWorker returns a fluent builder to register a new worker with
        • topic name, lock duration, Worker object supposed to be executed, filter for variables by name (all variables if not invoked)
      • client#build
        • adds the configured registration object to the WorkManager
        • returns the registration object WorkerRegistration
      • WorkerRegistration#remove removes the registration from WorkManager
      • TaskContext provides methods the user can invoke in the customized Worker implementation
        • methods are applied to a task which belongs to a task topic
        • TaskContext#getTaskId
        • TaskContext#complete
        • TaskContext#handleFailure
        • TaskContext#handleBpmnError
        • TaskContext#setVariable ? => complete
        • TaskContext#extendLock
        • TaskContext#getVariable
        • provide getters according to LockedExternalTask (e. g. worker id, topic name, retries, etc.)

      Implementation

      • WorkManager
        • holds a list of all WorkerRegistration s (registered workers)
          • this list is considered when tasks are being fetched and locked
        • has a singleton thread which is supposed to fetch and lock tasks
          • the respective runnable realizes the acquisition of external tasks (fetch and lock)
          • long polling realizes the back off strategy
        • has a thread pool which is supposed to execute Worker objects
          • has a default configuration in terms of number of threads and queue size
          • can be alternatively configured via the fluent builder of the CamundaClient
      • FetchAndLockTasksRunnable
        • is supposed to fetch and lock tasks based on WorkerRegistration s of WorkManager
        • one acquisition cycle contains the following steps:
          • POST /external-task/fetchAndLock
            • request is performed with the information of all workers which has been registered (topic objects)
            • request is configured additionaly to the topic objects with the maximum number of tasks, the worker id and the async response timeout
              • it exists a sensible default configuration
          • Response
            • for each fetched task a WorkerTask object is created and added to the thread pool
            • each WorkerTask object consists of the respective external task dto, the command executor and the Worker object
      • WorkerTask
        • for each fetched task an object of this class is created
        • object holds task id, task variables, Worker object
        • is a runnable that provides the context for the thread pool to execute the Worker object
          • WorkerTask#run invokes the method of the worker specific custom object to do the work
        • implements the TaskContext interface which provides methods which can be used in Worker object (e. g. complete task, handle failure, set variable, get variable)
      • ClientCommandContext provides methods for the HTTP interaction and marshalling
      • ClientCommandExecutor implementation of abstract HTTP methods

      Questions

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              roman.smirnov Smirnov Roman
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: