Most of the work has been bug fixes and small visual improvements.
- It is possible to add objects to global collections.
- Jamming asset lists are fixed. They were causing problems with some locales and date formats.
- To allow faster rule opening, loading of some widgets have been deferred. For example the images show how assets meta data can be reviewed. Image on the right shows the default view and the left one shows detailed view.
- There is now a “About” selection under Admin panel to show the Guvnor version and svn revision. This will help with bug reporting and support.
lots of bug fixes, see JIRA for M5 for details.
The Drools pipeline helps with the automation of getting information into and out of Drools, especially when using services, such as JMS, and non pojo data sources. Transformers for Smooks, JAXB, Xstream and Jxls are povided. Smooks is an ETL tooling and can work with a variety of data sources, JAXB is a Java standard aimed at working with XSDs, while XStream is a simple and fast xml serialisation framework and finally Jxls allows for loading of pojos from an excel decision table. See the Javadocs PipelineFactory for documentation. Below shows part of a unit test which illustrates part of the JmsMessenger in action:
// as this is a service, it's more likely the results will be logged or sent as a return message
Action resultHandlerStage = PipelineFactory.newExecuteResultHandler();
// Insert the transformed object into the session associated with the PipelineContext
KnowledgeRuntimeCommand insertStage = PipelineFactory.newStatefulKnowledgeSessionInsert();
insertStage.setReceiver( resultHandlerStage );
// Create the transformer instance and create the Transformer stage, where we are going from Xml to Pojo. Jaxb needs an array of the available classes
JAXBContext jaxbCtx = KnowledgeBuilderHelper.newJAXBContext( classNames,
Unmarshaller unmarshaller = jaxbCtx.createUnmarshaller();
Transformer transformer = PipelineFactory.newJaxbFromXmlTransformer( unmarshaller );
transformer.setReceiver( insertStage );
// payloads for JMS arrive in a Message wrapper, we need to unwrap this object
Action unwrapObjectStage = PipelineFactory.newJmsUnwrapMessageObject();
unwrapObjectStage.setReceiver( transformer );
// Create the start adapter Pipeline for StatefulKnowledgeSessions
Pipeline pipeline = PipelineFactory.newStatefulKnowledgeSessionPipeline( ksession );
pipeline.setReceiver( unwrapObjectStage );
// Services, like JmsMessenger take a ResultHandlerFactory implementation, this is because a result handler must be created for each incoming message.
ResultHandleFactoryImpl factory = new ResultHandleFactoryImpl();
Service messenger = PipelineFactory.newJmsMessenger( pipeline,
The biggest improvement by far is improvement of the documentation. We’re not there yet, but we’ve added sections on getting started, human task management, persistence, etc. The latest Flow documentation can be found here:
Some features have also been extended, including:
- The history log – that keeps the history of all executed process instances in a database – has been extended so it is now caable of storing more detailed information for one specfic process instance. It is now possible to find out exactly which nodes were triggered during the execution of the process instance.
- A new type of join has been added, one that will wait until n of its m incoming connections have been completed. This n could either be hardcoded in the process or based on the value of a variable in the process.
- Improvements have been made to make persistence easier to configure. The persistence approach is based on a command service that makes sure that all the client invocations are executed inside a transaction and that the state is stored in the database after successful execution of the command. While this was already possible in M4 using the commands directly, we have extended this so that people can simply use the normal StatefulKnowledgeSession interface but simply can configure the persistence using configuration files. For more details, check out the chapter on persistence in the Drools Flow documentation.
Some small bug fixes were added to make the IDE more stable.
Support to event expiration policy
added the ability to define a per-type event expiration policy. In the example bellow, the StockTick events will expire 10 minutes after they enter the system:
declare StockTick @role( event ) @expires( 10m ) end
Support to temporal operations over arbitrary dates.
added the ability for point-in-time operators (before, after and coincides) to be used with any arbitrary date field:
rule “Allow access”
WorkHours( $s : start, $e : end )
LogIn( time after $s, time before $e )
// allow access
lots of bug fixes, see JIRA for M5 for details.