As a very simple application, here is a little tool that aborts all running workflows.

WorklistService worklist = 
    connection.getWorkflowRepository().getWorklistService();
  Set<Process> running = worklist.getAllProcessesRunning();
  for (Process process: running) {
    process.abort();
  }

The code deals with the workflow repository and one of its aspects, the worklist service. The worklist service maintains a number of collections of workflow objects. Each collection contains those objects that match a certain predicate: running processes, escalated tasks, available process definitions, and so on.

In Example 6.1, “AbortAllProcesses”, one of the administrative worklists is used. The method getAllProcessesRunning() returns the set of all processes that are started, but not yet finished.

Elaborating on this example, a minor variant follows. Example 6.2, “Suspend My Processes” operates only on processes that were started by a single user. More precisely, only processes of the current session's user are returned during a call to getProcessesRunning.

WorkflowRepository repository = connection.getWorkflowRepository()
  WorklistService worklist = repository.getWorklistService();
  Set<Process> running = worklist.getProcessesRunning();
  for (Process process: running) {
    process.suspend();
  }

As you can see, the processes are suspended instead of being aborted. Suspended processes keep their state and can be resumed later on.

In the next example, you will see how to create and control a process using the Unified API. Before running the Example 6.3, “Create Process Example”, the standard three-step publication workflow must have been uploaded. Please see the Administration Manual for details.

The example code starts with retrieving the process definition via the well-known name and creates a process instance afterwards. The process has to be started before its first task can be started.

ProcessDefinition processDefinition =
    repository.getProcessDefinition("ThreeStepPublication");
  Process process = processDefinition.create();
  process.start();

When the process is started, the process definition on the server takes control. In the case of the three step publication, this leads to the Compose task eventually being offered to the process' owner. The code repeatedly tries to accept the task, which may fail because the task is not offered yet, or because it was already automatically accepted by a connected Site Manager.

Task composeTask = process.getTask("Compose");
  while (!composeTask.isAccepted()) {
    try {
      composeTask.accept();
    } catch (IllegalTaskStateException e) {
      // not offered yet, or race condition with editor
    }
    Thread.sleep(1000);
  }

Now that you are sure that the task is accepted, you can freely access its variables.

composeTask.getView().set("subject", "a subject");
  connection.flush();
  Thread.sleep(5000);    // let the user have a good look
  composeTask.complete();

Here one variable is set to a new value and the change is flushed to the server. Just as with content, writes are buffered for workflows, too. After providing you with some time to inspect the new variable value in the editor, the compose task is completed. Because the change set was not changed and is still empty, the three-step publication process terminates automatically.