unify-flowret-1.6.0

Someone a few months back had recommended to have a simple tutorial in place to help the engineers / developers quickly understand Flowret. Something like a "Getting started in 5 minutes" guide. It did not happen till now primarily because at the back of my mind was the thought that how hard could it be to write a sample program by referring to test cases. And that was the reason that I kept deferring it. It may not be all that hard to write a sample program by referring to the test cases, but it definitely is a stumbling block in adoption - imagine people coming here, going through the documentation and then wanting to try it out but realizing that they cannot because they need to spend a couple of hours understanding the test cases and then giving up and moving on. I came to this realization just recently when I started out to write a sample program. What good is a piece of software or its documentation if it cannot be brought up and running in five minutes to demonstrate its core concept? And so here it is - a sample program added in the code and a chapter added in the documentation. This was long overdue, and I hope it helps in adoption with people being easily able to understand the working of Flowret in five minutes.

Note -> I am seeing some markdown formatting issues while rendering code samples in the section added in the documentation (readme.md). Will correct in the next version in a few days.

unify-flowret-1.4.4

Fixed the defect of a pend in a parallel execution path which is not the direct descendent of the parent execution path. Explaining with an example - assume that there is a parallel route (r1) that creates 5 branches and each of the 5 branches in turn have a parallel routes (r2*) that each create 5 more branches. Now, if parallel execution is happening and there is a pend encountered in an execution path created from route r2*, then the same was not being recognized and the parent execution path pending at route r1 (for threads to complete) was proceeding ahead with the flow (instead of pending). This is now fixed. If you are not doing parallel within parallel processing then you are not impacted.

Test cases have been added. Also unify-jdocs dependency has been updated.

unify-flowret-1.4.3

Fixed following three issues:

SLA milestones not getting setup
In the scenario that a case pends at a step with OK_PEND_EOR in work basket 1, then work management service is used to move the case to work basket 2 and then the case is resumed and again pends in work basket 1. In this scenario, the SLA milestones for work basket 1 were not being setup which is now fixed.

Crash recovery fix
In the scenario of Flowret not being able to write the process info file and the case is resumed, the crash recovery program was not able to recover the process info file to move ahead in the process. This is now addressed.

Pause fix
If the step Pause is used, then the status of the execution path was not being set to completed in the process info file leading to crash recovery process to kick in (though there was no adverse effect). The same has been fixed

unify-flowret-1.4.2

The init method which takes in a ThreadFactory as an input parameter has been withdrawn as it was not serving the objective for which it was introduced.

A new way of parallel processing has been introduced wherein the threads for parallel processing will be created as child threads of the running thread. This is being done to give a chance to clients to be able to propagate the thread context to child threads. For example, the main thread could specify inheritable thread local properties which would propagate to child threads. Clients will need to take into consideration that this mode is not bounded.

Documentation has been updated and test case added.

unify-flowret-1.4.1

Added a new init method which allows clients to pass in their own thread factory implementation.

unify-flowret-1.4.0

1. Documentation updated for reopen API
2. Updated exception handling to take care of Flowret not proceeding ahead in certain cases if an exception is thrown from an event handler
3. startCase method now throws an exception instead of returning null if an exception is encountered. This may be a breaking change for consumers who were testing for null to see if the case started or not
4. Updated unify-jdocs dependency