We've been getting a lot of great feature requests from customers ever since we initially announced the Flux Web-based Designer. These requests have driven development and really improved the Web-based Designer. One of the most common requests that we have received is to support embedding the Web-based Designer, which was added in Flux 7.5. We're building on this feature in the upcoming 7.6 release due out 12 November 2007. Flux 7.6 will support monitoring flow charts in the embeddable Web-based Designer. This will allow you to easily support rich workflow operations for your Java web applications. Embedding the real-time monitor will allow your users to easily export, view, monitor, and change running flow charts without leaving the comfort of your web application.

Support for custom actions and triggers in the Web-based Designer is also coming in Flux 7.6. We're enhancing our support for custom actions to support tweaking the display of custom action properties in the Web-based Designer so you can make your custom actions easier to use. Dependencies for custom actions will be moved to the engine side in Flux 7.6, meaning that you only need to install custom actions on the engine instead of the engine and Operations Console.

The following screen shot illustrates the real-time monitor embedded inside of a Java web application:


The flow chart loaded in the screen shot above illustrates a basic time off request business process. Users of previous versions of Flux will quickly notice the major differences. A control bar has been added to the real-time monitor to allow the user to easily control the flow chart while monitoring. Icons are displayed next to active actions to illustrate their execution status. In this screen shot, the business process is waiting for the supervisor to review the employee's time off request. Once approved, an email goes out and then an event is added to a shared Google Calendar.

Layout of actions are persisted to the Flux repository in Flux 7.6 too. This way, when you position your actions in your flow chart and save to and re-open from the repository, your actions will be displayed just where you left them.

If that isn't enough, we've also added support for our built-in file actions and triggers along with supporting runtime data mapping. This will allow you to create a flow chart that transfers files, involves human interaction, and calls out to custom Java code, all within minutes without leaving your web browser.

I hope these new features will be useful inside your application. Post a comment to this blog entry or contact me directly if you have any questions about the new features coming in Flux 7.6, or if you want a pre-release to experiment with.

I’ve had the pleasure of doing some performance testing against our supported databases lately. It’s really interesting to see concrete performance metrics to compare the impact that the database has on the performance of Flux.

What did we find? Well, we’ve used MySQL internally with Flux and have been very satisfied with the performance. The metrics show why too, MySQL is the fastest database to use with Flux. Of course, HSQLDB (http://hsqldb.sourceforge.net/) is faster, but an in-memory database does not work for all solutions.

A bit of tweaking is required for DB2 and SQL Server 2005 to avoid deadlocks. Flux is a highly concurrent application that executes many transactions simultaneously. You will most likely encounter deadlocks with the default configuration of DB2 or SQL Server 2005 as the default settings of these databases do not work well with highly concurrent applications.

For DB2, setting the DB2_SKIPINSERTED, DB2_SKIPDELETED, and DB2_EVALUNCOMMITTED system registry options in DB2 will help. Also, regularly executing RUNSTATS on all Flux tables will improve performance.

For SQL Server 2005, the new row versioning feature helps out significantly with deadlocks and performance. This feature makes SQL Server 2005 operate much like Oracle, which allows quick SELECT statements and does not block SELECT statements when waiting for uncommitted transactions. Information about enabling row versioning can be found at: http://msdn2.microsoft.com/en-us/library/ms175095.aspx. SQL Server 2000 is not officially supported, but we did run Flux against it and resolved some deadlocks encountered.

We resolved deadlocks with DB2 and SQL Server 2005 as well while gathering performance metrics. All of the deadlock fixes will be in Flux 7.4.2, due out on Tuesday, and also Flux 7.5, which is due mid-September.

We’ll be posting official performance metrics to our website soon. But to give you a general idea, DB2 is the slowest. In comparison to DB2: Oracle is 66% faster, SQL Server 2005 is 70% faster, MySQL is 79% faster, and HSQLDB is 90% faster. These are not final numbers, and not very specific, but they do give a general idea as to what database perform Flux performs best with.