I will check your notes to see if I made some mistakes.
All the examples that you see in the posts has their own test that you can run, if you want to have a project per example we will end up with 10 different projects which will contain just one single test.
We should find a way to add this content to the docs. I mention to marco, that as soon as the book is published I will be focused in my blog and in the docs, so we can start adding this kind of things.
More comments inline :)
On Sat, Aug 4, 2012 at 11:49 AM, Maciej Swiderski <mswiders@redhat.com> wrote:
Mauricio, these posts are really good.
I like that they are kind of series that provides more and more
details and advanced usage scenarios and what's in my opinion most
important real life examples. Great work!
Any idea on how many posts you are going to provide? Was wondering
that it looks like nice content to be introduced into
documentation as well. Maybe not whole posts but sort of essence
of it, as users especially new comers will look into documentation
first and could not be aware of our blogs, wdyt?
I have two more scheduled about processes and rules before jumping to Fusion
So far you have not introduced the main (in my opinion)
integration between process and rule - business rule task, but
that is probably scheduled for next posts... However introduction
of using work item handlers here is more than needed. That gives
opportunity to users to get a chance to get familiar with work
item handlers concept.
I kinda understand your point, but the Business Rule Task from the BPMN2 specification perspective is more related to the Stateless interaction mentioned in my posts. Talking with one of the BPMN2 spec members they only think about that kind of interaction. I think that at some point Tiho was working in something to be able to link a business rule task to a special work item like that one that I was trying to show in my examples. If that work is already done, I will update my posts to show that integration. I think that most of the true advantages of having the Rule Engine are Stateful scenarios where almost everything is handled as Facts (which is the topic of the next posts).
In the third one - great stuff is about reactive modes - both
based on fireUntilHalt and event listeners and some pros and cons
of each solution. Have not tried the examples myself but what
could really rock is an runnable example for each post to conclude
it.
Do you have a better idea about how we can distribute the examples? I mean, all the examples are in my github repo. It will really rock if we standardize this kind of things. The archetypes that you mention some time ago will probably help a lot :)
P.S.
While reading I spotted few minor things:
- on first post last two process diagrams (illustrations) shows
inclusive gateway but both text and annotations on its sequence
flows refer to/suggest exclusive gateway
I need to check this.. but I probably made a mistake there
- on third post I think you meant beforeProcessStarted method of
process event listener instead of afterProcessStarted as when this
method is called process is already finished or reached first
state node which could be after some rules evaluation nodes, isn't
it?
I need to check this specific example, but if I've used afterProcessStarted probably was because of the reason that you mention. I want to execute some rules after the process reaches the first wait state.
Maciej
On 29.07.2012 14:14, Mauricio Salatino wrote:
Hi guys,
I've post a new article about the process and rules
integrations.
I'm extremely open to discuss if this is the right way of
exposing this topics. I've found that when people doesn't
understand this topics they end up with very complicated
architectural problems.
The main idea behind these posts is to clarify from the
functional behavior what kind of things can be done, in order
to:
1) Gather feedback about new features that can be introduced
to facilitate the adoption of certain patterns
2) Classify in different patterns the functional requirements
to then explain which architecture fits better, or what kind of
things the users needs to be have in mind to define their own
architecture.
After this post a set of patterns will be described and then
a set of architectural posts will go out. At this point feedback
from the other developers is crucial :)