@Tom,
Your first example might pull in to many domain data into the processvariables. The same
is partly true for the 'missed discount' in Bernds' example. You should not
have to take this into account while running/executing the process. The BI software (Sorry
Heiko ;-)) should be able to (and e.g. Pentaho is to get that data from multiple
datasources. Missed discount can vary per customer, heck even per 'special order',
and in some cases there even might be penalties etc... Leave that data where it belongs...
in the domain model.
anonymous wrote : Another variation would be to put probes on transitions. One probe could
initialize a KPI variable to true and multiple other probes could turn it off. Then you
can count for all the process executions that past the first probe, how many of them did
not pass a second probe. This might be used to get statistical data on the % that each
transition out of a decision is taken.
This is almost exactely how SeeWhy uses it. Personally I do like it, but do not like to
have to model those things in. Makes it look ugly (at least in the source) and if I forgot
something, I do not have the data afterwards. BEA (in to of their former BPM
'solutions') had a cooperation with a company that just knew the domain model of
the engine and every x seconds did a select from the database, read the new log records
since the last time (know from that specific record) and updated the metrics. Somehow,
that just feels better
To bad I never had the time to try out Pentaho (tried SeeWhy) to get a detailed
impression.
@Bernd,
Including those figures in the simulation is nice for generic analysis but did you also
use these with slowing down e.g. one of the actors in a pool that should act on a node?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185304#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...