KIE

A recent addition to Drools Flow allows users to create processes using what could be called a “fluent API”. While it has always been possible to create processes using our graphical editor or the underlying XML, we do acknowledge that some people simply prefer creating process definitions using an API. The underlying example shows howRead more →

A recent addition to Drools Flow allows users to create processes using what could be called a “fluent API”. While it has always been possible to create processes using our graphical editor or the underlying XML, we do acknowledge that some people simply prefer creating process definitions using an API. The underlying example shows how easy it is now to create a simple “Hello World” example process using this API:

RuleFlowProcessFactory factory =
    RuleFlowProcessFactory.createProcess("org.drools.process");
factory
    // header
    .name("My process").packageName("org.drools")
    // nodes
    .startNode(1).name("Start").done()
    .actionNode(2).name("Action")
    .action("java", "System.out.println("Hello World");").done()
    .endNode(3).name("End").done()
    // connections
    .connection(1, 2)
    .connection(2, 3);
RuleFlowProcess process = factory.validate().getProcess();

Many thanks go out to salaboy for doing a large part of the work and adding the different factories to create the various types of nodes supported in RuleFlow. This also shows how easy it is to contribute to the Drools project if you want to: come join us at our #drools irc channel, describe what you want to do and we’ll help you as much as possible and welcome contributions !

Kris

One of the main things we want to offer to end users is the ability to specify themselves what their processes look like. This includes the ability to extend the process engine with custom-defined nodes, to add domain-specific work items, etc. We now have introduced the concept of a (process) skin, which controls how theRead more →

One of the main things we want to offer to end users is the ability to specify themselves what their processes look like. This includes the ability to extend the process engine with custom-defined nodes, to add domain-specific work items, etc. We now have introduced the concept of a (process) skin, which controls how the different nodes are visualized. This allows you to change the visualization of the different node types the way you like them (by implementing your own SkinProvider).

BPMN is a popular language used by business users for modeling business processes. BPMN defines terminology, different types of nodes, how these should be visualized, etc. People who are familiar with BPMN might find it easier to implement an executable process (possibly based on a BPMN process diagram) using a similar visualization. We have therefore created a BPMN skin that maps the Drools Flow concepts to the equivalent BPMN visualization.

For example, the following figure shows a process using some of the different types of nodes in the RuleFlow language using the default skin …

Simply by switching the preferred process skin in the Drools preferences …

and then reopening the editor shows the same process using the BPMN skin …

Tell us what you like! Or more in general, let us know what you think the other features are that are important when deciding how to visualize (executable) business processes (as flow charts).

Some process languages allow you to basically do anything you want by allowing you to include code fragments in your process that are then executed during the execution of that process. This allows you for example to interact with basically any external service by writing a piece of code that invokes the service. While thisRead more →

Some process languages allow you to basically do anything you want by allowing you to include code fragments in your process that are then executed during the execution of that process. This allows you for example to interact with basically any external service by writing a piece of code that invokes the service. While this approach offers a huge amount of power and flexibility to the end user, there are some mayor problems as well:

• Using code fragments to specify work is not really declarative: it does not only specify what should be executed but also how.
• By embedding the code in your process your are also usually linking your process to one specific environment. For example, creating a new personnel record is usually done differently in different locations / companies.
• If code fragments are used to communicate with external services, the process has no way of knowing this, which might result in errors in later stages. For example, a piece of code might be used to request the asynchronous execution of an external service, but the process might have been completed or aborted by the time the results return.
• It is usually difficult to test your process in a test environment without having to change the code (or making it a lot more complex), as the code usually refers to specific services and you don’t really want to contact production services during testing.

While it also possible to embed code fragments directly into your processes in Drools Flow, we encourage users to use work items to communicate with external services. A work item represents an abstract unit of work that needs to be executed by an external service. A work item specifies a name (which uniquely identifies the type of work, e.g. email or log) and parameters (as name-value pairs). These parameters can be hardcoded when defining the process or can be dynamically derived from the runtime process state.

Work item handlers are used to link abstract work item to the actual implementation that knows how to contact the specific external services. They must implement the executeWorkItem(WorkItem, WorkItemManager) method and signal the WorkItemManager upon completion (or abortion) of the work item, including possible results (as name-value pairs). These results can then of course be used in the process instance. Work item handlers need to be registered (at deployment or even at runtime) at the process engine. This allows us to for example to register a custom work item handler in test cases to simulate a specific environment.

The use of work items allows users to easily extend the power of the process engine themselves, by creating domain-specific work item nodes. The process designer supports the definition of different types of work items using a configuration file that defines the name, the parameters, the results and possibly a custom icon for the work item.

We have already created a small set of work items for common problems that can be used out of the box:

• Sending email
• Logging messages
• Finding files on a file system
• Archiving files
• Executing system commands

The following screenshot shows an example where a Finder is used to select all files on the file system that match certain criteria, followed by a logger that logs and checks each of these files, where the valid files are archived and then copied to a specific location, where an email is sent to the administrator after successful completion of this process.

We are working on adding more work items by default, like invoking a web service, integration with services on the JBoss ESB, etc. With the help of the community, we hope to extend this set of work items significantly so we can offer users a large selection of work items in different application domains.

Drools Flow has evolved into a powerful workflow language for describing executable business processes. It is different from other existing workflow languages in that it allows advanced integration between processes and rules and offers unified interfaces and tooling to end users. The complexity of your business logic can be reduced and the agility of yourRead more →

Drools Flow has evolved into a powerful workflow language for describing executable business processes. It is different from other existing workflow languages in that it allows advanced integration between processes and rules and offers unified interfaces and tooling to end users. The complexity of your business logic can be reduced and the agility of your processes can be improved by using rules inside processes in a smart way for managing a part of your logic.

The expressiveness of the Drools Flow language has been extended significantly in our latest version to support advanced business process requirements. This includes support for long-running processes (e.g. using states), human task management (and assignment), integration with external services, timers, exception handling, persistence, etc. The following screenshot shows for example two of our newest features: intermediate events and composite nodes.

Intermediate events (using a star icon) allow you to respond to events that are external to the process itself but may influence its flow. Events have a type (e.g. orderAborted) and can carry additional data that can be accessed inside the process once the event has occured. If a large number of events can occur during the execution of your process, using rules inside your process to handle these events and select the appropriate action can greatly simplify your process definition as well.

A ForEach node is an example of a composite node that allows you to execute a part of your process for each element in a collection (e.g. process each of the order items in an order separately). The process can wait for the completion of that sub-flow for each of the elements in the collection before continuing.

Another key feature is the integration with external services using (declarative, domain-specific) work items, but I’ll cover that topic in another blog.

You can expect to see the addition of more of these ‘patterns’ in the future, as we intend to improve the expressiveness of our Drools Flow languages continuously!