I mentioned 4 additional pieces of data that I thought should be recorded--three on the
ProcessDefinition and one on the Task. Lets just consider one of them: the ui attribute
on the Task.
Lets say we have a long running process (1+ month) called "order". On day 10
after deployment we have 200 new processes started, and the business realizes that they
would like something done differently on the "shipIt" Task. The change will
require a change to the Definition as well as a change in the Task's UI functionality.
We determine that the UI functionality for the old and new versions of the
"shipIt" Task will NOT be compatible.
Assuming we have a "ui" attribute on the Task object, in the two versions of our
ProcessDefinition we would see something like this:
The first version of the "order" ProcessDefintion was originally deployed with
all Task ui attributes set to 'ui=1'.
Knowing the UI requirements are changing for the "shipIt" Task, the new version
of the "order" ProcessDefintion is deployed with the "shipIt"
Task's ui attribute set to '2' <task name="shipIt"
On the UI side, the developer could utilize this information many ways; here is just one
The developer stores screens in a folder structure similar to
The UI is responsible to provide a screen for each Task/ui requirement, so before
deploying the new version of "order" the developer would create a new screen
Now from the UI application, the user selects a task from their work queue. The UI
fetches the TaskInstance, examines the associated Task.getUi() value and loads the
In this example, the developer creates a new JSF/Facelets/whatever page and backing beans
for each unique ProcessDefiniton_name/Task_name/Task_ui combination; however, the same
Task.ui data could be used just as well by screen configuration files or even a content
management system. I'm sure that each person here could come up with a totally
different and equally viable way to utilize the Task.ui data in their own UI.
As for the three other pieces of data I mentioned...
* The "ui" attribute on the ProcessDefinition itself can be used in exactly the
same ways as mentioned above for identifying appropriate versions of Process summary
* The deployment timestamp on the ProcessDefintion is just a very simple change that can
make at-a-glance trouble shooting or answering some questions VERY easy.
* The release number on the ProcessDefinition makes so much sense I don't even know
where to start--Every major software product records and displays a developer-provided
release number--and remember that long running jBPM processes and their definitions exist
outside the scope of any running application (or database for that matter)--they need to
carry developer-provided versioning info just like any other solution.
All four of these items are simple attribute adds, with no impact to existing
View the original post :
Reply to the post :