I am fairly new to jBPM, but I've gone through the user guide, the getting started wiki page, and the various workflow pattern tests. These items have provided me with a decent overview of how jBPM works, but I am still having troubles grasping how various 'real-world' situations should be modeled within jBPM.
I would greatly appreciate any suggestions that can be provided.
Maybe I should give an example scenario of a problem that can be a point of discussion.
There is a shipping department for a bookstore. The department receives orders that must be fulfilled.
Now, this shipping department is not the most streamlined and organized department and, right up to the point that an entire order gets loaded onto the truck for delivery, the department can change the makeup of a shipped order. For example, maybe there is a more important customer that needs a book instead of the current customer, or someone decides to repack the boxes for an order due to weight limits per box.
In this example, I have been given the task of not only telling the company what was shipped, but to also track the intermediate changes that occurred as books and/or boxes were added/removed to a specific order. This information will be later analyzed by the shipping supervisor in valient efforts to improve the department. Also, I will be receiving these events via a soap service from a third-party application, so there isn't any 'direct' user interaction with the process. There are also multiple orders in 'the system' at once, so I'll need to locate the correct task for the correct order.
So, I believe that I have a process that:
* has multiple internal (packing/unpacking) events
* all events that could occur are known at design time
* the effect of each event is known at design time
* there is no specific predefined order for these events
* however, the actual order of runtime events must be maintained
* ex: a specific book must be removed from one box before it is placed in another
* a specific event type can occur multiple times
* but each event occurance is unique
* ex: multiple boxes are added to an order at various times
* can continue until an external event (placing order on delivery truck) occurs
That's the example. I am having trouble determining the best way to approach a solution. Here's my first attempt.
I have a wait node that is basically "Waiting for next step".
This node then has a seperate transition for each packing/unpacking event that may occur.
Each transistion points to another corresponding task-node (add box to order, add book to box, remove book, remove box, etc) where the message would provide specific information about that task.
Each of these task-nodes would then transition back to the 'waiting for next step'. There would be an action on the transistion event that would update the order/box/book database with the changes.
Then, I see another transition from the "waiting for next step" that would be "order placed on truck" that would end the specific process instantiation (for that order).
Then I thought some more and wondered if this was the correct way to model the above example.
For example, instead of having a 'waiting' step that then steps into a second task, would it be better to have one task-node with multiple tasks (continue set to "first") where the user can provide information and then have the transition (with the associated action) deliver the flow directing back to the first task?
Does the above example fit specific workflow patterns? I sort-of see that 15 (MI w/o RT Knowl.), 17 (interleaved parallel routing), and 18 (milestone) fit the scenario. Any thoughts?
I am also having some difficulty understanding how to best deal with issues of granularity. For example, do I try to keep all tasks at the level of a book? a box? an order? Or does it really matter?
Thanks for your patience in this long post,
Anyone willing to comment - or at least tell me the question is inappropriate for this forum?
The question by itself is not inapropriate. The thing is that it is such a long post which probably (at least I think so , since I fully read it) contains a lot of things that are clear to you but require additional info for me (us) that a short answer is difficult. I agree however that this could have been told. Sorry for that.
The same is true for your other post I think (although I did not read it yet).
I hope I do not disappoint you, and hope someone will respond. I personally do not have the free (unpaid) time to realy go into this. Sorry.
Tip: Hire a BPM consultant (not neccesarilly jBPM) for one day, since some of questions are more generic than jBPM specific.
Thank you for your response.
I understand and respect that monitoring and maintaining the forum is voluntary for most (if not all) forum members. I also understand my questions were not "run of the mill".
I guess I was hoping to have a discussion that went beyond the usual questions that I have read in the past about straight technical issues.
I think that jBPM is a very powerful tool that can be utilized in various ways and I was trying to understand its capabilities.
I appreciate your suggestion to shedule an BPM consultant, but I am currently learning about jBPM on my own and I can't justify that expense. Instead, I was hoping to engage in a discussion here that could possibly be beneficial for the entire group and that both myself and others could learn from the experience. Plus, from a product point of view for jBPM, perhaps we find out that there is a new/different way to utilize this software. Not everyone is doing web services and/or web pageflow processes.
However, please don't interpret that I am in any way angry with the lack of response. I am grateful that this resource exists and the support that it provides, and I am sure that I will gain from it. I am, however, a little disappointed that I couldn't get a discussion started. Is there possibly a different forum where these type of discussion are more appropriate.
Thank you all again for assisting us that are learning and broadening our horizon.
My response does not mean I think your question is not interesting, au contraire. Discussing the achritectural issues when designing processes is much more interesting than talking about nitty gritty java details or 'where is /lib/tools.jar'. I would dissapoint Tom a lot if I switch to lengthy, interesting discussions on modelling instead of what I do now ;-) Maybe we should introduce a new forum for this.
The way I thought myself some (a very few) best practices is doing/using it a lot.
I'll see what I can do the comming day's, but don't get your hopes up to high.
No problem. I understand that both modeling and technical issues are important and I was not trying to minimize either one.
I intend to continue to work my way through the thought process and discover what works and what doesn't.
Hopefully, as I gain more expertise, I can answer questions instead of asking them. And I'll keep my expectations low. Most people have too much to focus on already. :)
Think Simple.... meaning that jBPM is so extensible (actionhandlers, custom node types (forks, joins etc) that doing plain modeling with existing nodes can make things unnessecarilly complex. Implemenenting a custom node can sometimes simplify things a lot.
Another tip is to not think in to long running processes and not to many external influences. e.g. one could think of cetting a morgage for 30 years as a 30 year long running process. This would make things more complex like tax changes etc.
Think of the morgage in smaller activities like, getting the morgage, doing additional payment, changing the intrest rate after 10 years. These can be processes acting on a dossier.
On the other hand, do not think in to much small details that you want to relate in processes. e.g. in your example, you have the books, box and order. Things can get complicated as well.
Third tip: do not hesitate to still do some basic things in java. Even separate from the process and signalling states when something happens (e.g. a box is full)
In general, when designing a BP what I have done is to use the component base approch, meaning that - start with the main process. Test and add process rules and constraints one at a time and go further.
This approch has help me test the orchastrations and understand the hidden subtelities of the process as well.
Hope this approch helps you.