Information Technology Reference
In-Depth Information
Executor service commands
Configuring
WorkItemHandlers
is a great way of creating interactions with external
systems. However, the more complex those interactions are, the more time the thread that
interacts with the process will be waiting for the task to finish. This is a natural conse-
quence of complex executions; they do take time. However, having a behavior that is de-
tached from the actual process execution in our tasks will allow us to invoke more process
executions with fewer resources. In order to provide this detached, asynchronous manage-
ment of tasks, we will use the following three components:
• The
org.kie.internal.executor.api.Command
interface, which
provides a new way of writing external interactions
• The
ExecutorService
class, which creates a managed thread pool for execut-
ing the said commands
• The
AsyncWorkItemHandler
class, which ends up connecting the process ex-
ecution with the
ExecutorService
method in an asynchronous fashion
The
Command
interface is a very simple one. It provides an
execute
method that will re-
ceive a
Context
object and return an
ExecutionResults
object, as follows:
public interface Command {
ExecutionResults execute(Context ctx) throws Exception;
}
The interface isn't just meant to work with
WorkItemHandlers
, but with anything that
requires a pluggable and pooled asynchronous behavior. In order to use it as an interaction
with process tasks, we will have a variable in the context marked by the key
workItem
to
access the parameters of the task. The
custom-work-item-handlers
project in this
chapter's code bundle defines a very simple command for handling a specific domain task:
public ExecutionResults execute(CommandContext c)throws
Exception{
WorkItem wi = (WorkItem) context.getData("workItem");
Object domainXParameter =
wi.getParameter("domainXParameter");
//Your specific domain operations should go here
ExecutionResults results = new ExecutionResults();
results.setData("domainXResult", domainXParameter);
