topic Re: Global eventlistener and history api in Alfresco Archive

Global eventlistener and history api

mpriess — Tue, 19 Feb 2013 09:39:04 GMT

Hi,I checked the board, the documentation and the engine and I miss the following:- A global listener/interceptor/bus whatever which can catch events and sending out notifications for each process without modeling. For example to inform the user that an error occure via XMPP or E-Mail or something e

Re: Global eventlistener and history api

mmaker1234 — Wed, 20 Feb 2013 08:32:42 GMT

Hello,

I'm not quite good in the BPM slang - what "process without modeling" means?

From business logic point of view - what do you mean by "an error occure"? Where do you expect this error to occur?
I can share our experience here: Our processes contain calls to our business logic. We expect that our business logic might fail and throw an exception. That is why our process definitions contain activities to
- notify the user
- help (an administrator) to repeat the business logic call (if appropriate)
Additionally, BPMN 2.0 contains so called compensation activities - take a look on them.

Yes, it is possible to reveal the state and the history of a process instance but you have to:
- properly configure the history level;
- design your process definitions to persist their state right before the activities where you expect crashes.

Although my posting does not give concrete answers to your questions, I hope it contains helpful information.

Re: Global eventlistener and history api

jbarrez — Wed, 20 Feb 2013 12:54:58 GMT

I want to add this to the explanation above: it is also possible to use BpmnParseListeners (note: will be changed to BpmnParseHandlers in 5.12) to hook in custom logic to any step in the process. That way you can for example send an event for every sequencefloiw that is taken…

Re: Global eventlistener and history api

mpriess — Sun, 24 Feb 2013 21:31:40 GMT

My business logik throws maybe an error and an administrator or an user get a notification and should be able to repeat a part of the process.

Hello,
That is why our process definitions contain activities to
- notify the user
- help (an administrator) to repeat the business logic call (if appropriate)

That's the feature what I like to use, but without doing the explicit modeling on each process.

Re: Global eventlistener and history api

jbarrez — Mon, 25 Feb 2013 13:42:27 GMT

Like I said above: that is possible with a custom class that is added to the process using a BpmnParseListener.

Re: Global eventlistener and history api

mpriess — Mon, 25 Feb 2013 14:12:27 GMT

Ok If I use a BpmnParseListeners. I get a call foreach step that is taken. Is this correct? But how can I detect the state or an error inside the ParseListener and retrigger a part of my process. Could you provide an example?

Re: Global eventlistener and history api

jbarrez — Mon, 25 Feb 2013 16:34:24 GMT

Ok If I use a BpmnParseListeners. I get a call foreach step that is taken.Is this correct?

No, you get the possibility to hook in custom logic during the parsing of the step.

But how can I detect the state or an error inside the ParseListener and retrigger a part of my process. Could you provide an example?

I haven't tried this, but what I would do is wrap the ActivityBehaviour of the service task with a custom ActivityBehaviour that catches any Exception and then send an email or whatever you want to do.

Re: Global eventlistener and history api

mpriess — Tue, 26 Feb 2013 09:20:05 GMT

Ok thanks. Any idea how I can retrigger or start a part of a process?

Re: Global eventlistener and history api

jbarrez — Tue, 26 Feb 2013 10:15:11 GMT

Hmm that is more tricky. The easiest would be to send an event to some external queue. That queue is processed and it restarts the process based on what was in the event.

Re: Global eventlistener and history api

mpriess — Tue, 26 Feb 2013 11:22:08 GMT

ok thanks, but how can I adress a special part of the process? This is very important for me, because every task need a lot of time.

For example:
A –> B —> C –> D

C failed because something was wrong in B. Now I like to skip back to B and repeat from B forward.

Re: Global eventlistener and history api

mmaker1234 — Thu, 28 Feb 2013 09:20:44 GMT

Hello,

IMHO the power of the process definitions, especially their graphical form, is indeed the visibility of the whole process, which helps its understanding. Hiding the knowledge on the decisions - why the process flows in one or another way - does not help process understanding instead it frustrates both the designer(s), implementer(s), and analytic(s).

Nevertheless, the approach, that comes on the top of my head for your case, is to use additional MessageCatchingEvent to each activity where you want to restart. For your example:

    mceB
      |
      v
A –> B –> C –> D

Then, when you detect an exception, you will need to throw the corresponding message to "call" (again) the corresponding activity (step).

Here is what "hedgehog" might look your process definition like:

mceA  mceB  mceC  mceD
  |     |     |     |
  v     v     v     v
  A –> B –> C –> D

and all these "needles" do not make the process definition more easy understandable.

AFAIK you can also add these catchers programmatically but I never used this option and can not help you with this option.