JBossDeveloper

Well, is the current Scheduler clusterable? That is, if I have two jbpm instances on two app servers, can I run the scheduler on both and guarantee and if one server goes down, the other will take its scheduler load? It sounds to me like I can only run the scheduler on one box at a time (I could be wrong however).

On the other hand, for most of my scope, I don't care about a business calendar because I'm dealing with either automated systems or 24/7 staff.

Tom, any possiblity, if my contributions are acceptable, to have access to the CVS?

Thanks,

Ed

Hi tom,

Thanks for taking the time. I really appreciate it. I have some questions about the async support being added to jBPM having briefly looked at the code on the CVS, which I understand is not release quality yet.

How are callbacks going to be handled in your impl? Currently, and correct me if i'm wrong, jBPM only supports internally-induced events, or explicit signaling (toekn.signal takes default, token.signal(transition) takes a specific one). Internally-induced events are things like node-enter, node-leave, etc.

In my mind, when I want something executed asynchronously, I would not want that component to even know what should be done next (like signal the process), so my plan was to add externally-induced events, where actions would be invoked asynchronously through queueing and an event would be raised once the action is complete onto an event queue. From the event queue, I would then map the event to a transition by adding an event-choice node to the definition. In addition, the event could come with some data important for the process, so I was planning to add support for event data mappings to process variables.

The nice thing about this is that actions don't really care about signal, all they must do is queue the operation on the action's queue. When they are done, they raise an event, and all the signaling logic is wihin the event queue MDB, which in my mind is sort of an automated process execution core.

What I saw on the CVS implementation was that a command mechanism is being put in place, where you have to send a signal command to the process from an async action to get it to continue processing, and to me, that is coupling the actual action to the workflow definition, which can be very bad. Its also not clear to me how the queueing system will work....will it be one message queue per async action? will it be one queue for all async actions? What about callbacks? One queue per process instance? Per engine?

Knowing what you will do can save me tons of work, so I just want to know what direction you are taking.

One more thing, another way to implement events is simply to use the existing event tag, but use custom strings for the event types, then use actions to specify which transition to take and each custom event object can contain the process variable mappings by way of action configuration when the action request is created.

Just another idea that might actually be simpler to implement.

Tom,

Your description of the chosen method is great. Like I said I had briefly looked at the code and initially couldn't fit the pieces toghether. It is in fact not too different from what I planned to do.

My domain is a bit different than typical business processes. In my domain, processes rarely will continue without knowing the result of an action. The reasoning behind using asynchronous actions is performance related. My actions can take a lot of time (3+ secs) which will block app server threads from the main app thread pool. The reason we will use asynchronous nodes is of a way to do non-blocking invocation of business logic, hence allowing the app to work on other processes if one process is waiting for the result of an action.

So, your model works great for me, except for two things: I need individial queues for individual actions to isolate performance issues (like one action taking 30 seconds to complete bringing the entire app down), which as you indicated might not be too hard to add to your current model byway of a parameter.

But second, I need some way of being notified that a process needs attention, otherwise, how do I know when to call Token.signal(), or GraphElement.fireEvent()? In other words, in a way, I want to treat the workflow engine as a black box: here's something I need done, give me a process id, and call me back when you are done. Wrapping jbpm in a JMS queue (not related to what you are doing) and have an MDB there listening for "events" from asynchronous actions. If such events were handled as custom events using jBPMs current structure, an example logic for that MDB could be:

? If the process is active, the event?s payload is mapped to process variables and the event is fired immediately. If the event is not being expected, simply ignore it
? If the process instance is paused, the event is added to a pending event list within the process instance. Once the process instance is resumed, each event will be fired in the order it was received. Each event's action is free to clear the pending event queue if such events should no longer apply.
? If the process has been terminated, the event is ignored.
? If the process has hung, the event is added to its pending event queue in case it can be picked up later if the process is reset.

Under such a framework, tasks could simply be asynchronous actions, that at some point will raise an event, like TaskComplete or TaskAborted, etc.

It may just be that there are already ways to do this from within jBPM and if so, I'd like to hear about them, and see some docs too! :)