SMILA/Documentation/WorkerAndWorkflows

Workers and Workflows

Workers

Worker Definition

The worker definition is provided with software. It defines default workers provided and must not be changed by the user.

Worker definitions cannot be added at runtime. They describe worker behaviour as needed by job manager to generate appropriate tasks and data objects.

Required input and output data is described in terms of bucket types as defined before. Additional string parameters may be needed and must be defined when used in workflow. Values for these parameters must be added as properties to the tasks created for this worker. (I.e. the names of all input and output slots have to be explicitly linked to names of existing buckets by the workflow referencing the workers as actions, see below. The workflow doesn't not need to define output slots which are marked as optional.)

As an advanced feature, output slots can be arranged into groups. The purpose of this is to describe which slots must or must not be used together: In a single workflow action it is not possible to use slot from different groups, but only slots of a single group and slots that are not marked with a group (they belong to each group implicitly). When using groups, the rules concerning optional and mandatory slots are as follows:

• A non-optional slot without a group must be always be connected to a bucket.
• An optional slot without a group is allowed in combination with any group slot.
• If a group is used, all non-optional slots of the same group must be connected to a bucket, too.
• If each group contains at least one non-optional slot, at least one group must be connected. It's not possible to use only the groupless slots then.

The worker properties in detail:

• name is mandatory.
• modes is optional and describes the mode of the worker
  • bulkSource: Can start a workflow, does not need input data. A task for this worker is created on demand when the worker requests it (in-progress tasks only)
  • autoCommit: When the worker dies while working on a task (sends no keep-alive anymore) the started bulks are committed by the job manager and follow-up actions are triggered, the task is not rolled back.
• parameters is optional and describes the parameters needed to configure the worker
• taskGenerator is optional and configures a piece of code (OSGi service) that is used to create the actual tasks after changes in the input buckets. Can be used to create multiple tasks for a single change event, or to filter events: If the generator does not actually create a task for the event, the action is cancelled.

Monitor workers

All workers

Use a GET request to retrieve monitoring information for all defined workers.

Supported operations:

• GET: Returns the workers information.

Usage:

• URL: http://<hostname>:8080/smila/jobmanager/workers.
• Allowed methods:
  • GET
• Response status codes:
  • 200 OK: Upon successful execution (GET).

Specific worker

Use a GET request to retrieve monitoring information for a specific worker.

Supported operations:

• GET: Returns the worker information for the given worker name.

Usage:

• URL: http://<hostname>:8080/smila/jobmanager/workers/<worker-name>.
• Allowed methods:
  • GET
• Response status codes:
  • 200 OK: Upon successful execution (GET).