We’ve definitely been a bit remiss on announcing this, but better late than never :). On February 26th, the Product team released Neuron ESB 3.5 Cumulative Update 2 (CU2). This update followed the release of Cumulative Update 1 (CU1) by about two and half months. Our goal is to always improve upon what we built, and deliver these improvements as early and often as practical. This patch includes all the enhancements and fixes that were included in CU1, as well as over 80 critical fixes and new capabilities that our customers have asked for.
If you’re using Neuron ESB 3.5 today, you should download the Cumulative Update 2 patch to update your existing installation. Current customers can obtain either the Patch or the full installation from the Neuron ESB Support Site. If you are new to Neuron ESB, you can download the full installation from the Neuron ESB Web site. All the details of this release can be found in the Knowledge base Article KB351-0226151.
We’ve always prided ourselves on being customer driven and this update is no exception.
Customers wanted to be able to select one or more records for deletion in our auditing reports. Previously, they could just delete all or nothing. Individual deletes had to be done at the database level. Now customers can simply right click on one or more records and delete them.
With the introduction of our new fault tolerant, long running Workflow engine, we gave users the ability to see all the executing or finished Workflows within the Workflow Tracking UI.
Users could click on the record and actually see the details of the Workflow execution including the activity event path, the state of the variables and arguments at every step, as well as any exceptions that may have occurred during execution. Users could walk through each step to see what happened.
However, we did not provide insight or visibility into the Workflows that were “pending” execution i.e. queued up messages waiting for the Neuron ESB Workflow scheduler to fire them up. The CU2 release provides a new “Messages” tab to the Workflow Tracking UI that provides just that. From the Messages tab, users can view, manage and suspend the execution of any pending message that would otherwise launch a Workflow. Most should be able to see where this is going :). By providing this level of visibility and control, the next logical step for our team will be to provide customers (in the near future) with the ability change the Workflow definition for those that have yet to execute.
Along the lines of new Workflow features, we took the liberty to introduce some new Workflow Activities as well as enhance existing ones. First, the Delay Workflow Activity had some underlying issues we fixed. However, the big problem we had with this activity was that it was not “Persistent”. In other words, if a user had this configured to wait for 2 hours, it would force the Workflow instance to remain in memory for the entire 2 hours. We changed this to a fully persistent model. When using the new Delay Workflow Activity, if the wait is configured longer than 60 seconds Neuron ESB will unload the Workflow instance from memory into the database.
The next big thing we introduced was the Timeout Workflow Activity. We ran across this requirement when we had a customer that needed to design a simple escalation pattern. The beauty of this activity is that it can contain other workflow activities and be configured with a specific period of time. This represents the amount of time that all the workflow activities contained within the Timeout activity have to complete their execution. The Timeout activity can be used to “Timebox” one or more activities. The Timeout activity is also persistable. In other words it can cause the existing workflow instance to unload into the database if it has to wait longer than 60 seconds. Once the time span expires, the workflow instance is reloaded and continues to run where it left off. Users can inspect the “Result” argument after the Timeout activity has fired to determine whether or not the activities within it completed successfully. A good example for this: User sends out document to be approved by a manager. However, the manager only has 3 days to approve before it needs to be escalated to a director.
Lastly, we added a new “MessageCorrelationScope” activity. This activity will register a correlation set for the workflow instance so that the workflow can use the “ReceiveMessage” activity to receive messages without having to use a “PublishMessage” activity. This provides the ability for users to configure correlated receives without having to first publish a message :).
This is more great work by the Neuron ESB Product team, most notably Michael Collins , Mark Tucker, Joe Klug, Manoj Talreja, John Peterson and Abhilash Shanmugan.