[Design of JBoss jBPM] - Re: Analytical and operational dashboards
by kukeltje
@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#4185304
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185304
14 years, 11 months
[Design of JBoss jBPM] - Re: Analytical and operational dashboards
by camunda
anonymous wrote :
| Open Orders: 20
| But just
| <processdefinition name>: 20
|
Add support for super-states (<processdefinition / super state name>) and I think you can satisfy a lot of the requirements already with the generic solution...
To what Tom said: Yes, very good ideas! I think these are the right directions!
Something somehow similar I had in mind with the simulation, see http://www.camunda.com/jbpm_simulation/jbpm_simulation_language_draft.html:
anonymous wrote :
|
| ...
| <business-figure name = "missed discount"
| type = "costs"
| automatic-calculation = "none|process-start|process-end"
| handler = "org.jbpm.sim.tutorial.TutorialBusinessFigureCalculator " />
| <business-figure name = "missed discount"
| type = "costs"
| automatic-calculation = "none|process-start|process-end"
| expression = "#{order.discountForFastPayment}" />
| ...
| </ scenario >
|
Basically this would be a cool improvement and the same logic could/should be used in BAM/BPR (BP-Reporting) as in BPS (BP-Simulation).
I don't remember exactly if I had implemented the "Business figures" already or if it was just a sketched idea, I think it was the latter ;-) But I can have a look at this later...
Greeting from the jBPM training in Stuttgart
Bernd
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185295#4185295
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185295
14 years, 11 months
[Design of JBoss jBPM] - Re: Analytical and operational dashboards
by tom.baeyens＠jboss.com
Another approach to KPI could be identify a special set of variables. Suppose that an Order process has an order variables which is a hibernate Order entity. Then in that entity, there is a field retributionCost. Then in the process, we could copy that field into a KPI variable field at indicated places in the process.
The benefit is that our console then has a generic way to diplay and work with key performance indicators.
Another type of KPI is time measurements. E.g: How much time is there between the quote approval and the closing of the deal. Therefor we need to be able to store the start en end times of the process execution at specific places indicated by the process developer in the process definition. Also super-states could serve for this purpose.
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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185293#4185293
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185293
14 years, 11 months
[Design of POJO Server] - [JBMETA-119] LocalBindingMetaData
by ALRubinger
"emuckenhuber" wrote : Do you need a LocalBindingMetaData similar to the Remote one or is something like this also ok ?
|
| String localBinding;
Let's add the LocalBindingMetaData for 2 reasons:
1) If we decide to add @LocalBinding(someNewAttribute="Whatever") in the future
2) Keeps the API uniform, easy-to-read (ie. matches RemoteBindingMetaData)
"emuckenhuber" wrote : or would you prefer a List localBindings
At the moment we allow for explicit declaration of only one local binding; my opinion is that this should be changed to support many.
If you make it look the same as RemoteBindingsMetaData does, that paves the way for @LocalBindings({}) looking forward.
I suppose either approach is valid for the time being. One might argue that it's silly to put in support for unimplemented features.
"emuckenhuber" wrote : then a postprocessing - setLocalJndiName
I'm no longer sure this is the right approach. Again we're mixing managed properties of the object model with logic that belongs elsewhere (ie a JNDI Binding Policy or Decorator).
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185275#4185275
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185275
14 years, 11 months
[Design of POJO Server] - Re: ProfileService Guidance
by scott.stark＠jboss.org
If we are going to keep the old security objects they really should have a similar management interface to the new beans where it make sense. Beans annotated at the bean class level with @ManagementObject are now showing up and the SecurityManagedObjectsTestCase shows obtaining the SecurityConfig whose component type is "MCBean","Security". There is an annotation on the JNDIBasedSecurityRegistration deployment:
| <bean name="JNDIBasedSecurityRegistration"
| class="org.jboss.security.integration.JNDIBasedSecurityRegistration">
| <!-- This has to be on one line, see JBMDR-49 -->
| <annotation>@org.jboss.managed.api.annotation.ManagementObject(name="JNDIBasedSecurityRegistration",componentType=(a)org.jboss.managed.api.annotation.ManagementComponent(type="MCBean", subtype="Security"))</annotation>
| <property name="policyRegistration"><inject bean="JBossSecurityPolicyRegistration" /></property>
| <property name="securityManagement"><inject bean="JNDIBasedSecurityManagement" /></property>
| </bean>
|
which should also be showing up, but currently is not as the metadata level annotation is not propagated to the management object factory. I'm looking into what to do about that.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185263#4185263
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185263
14 years, 11 months
[Design the new POJO MicroContainer] - Merged ClassInfo annotation view?
by scott.stark＠jboss.org
Right now the default ManagedObjectFactory implementation looks to the class for the management annotations using the org.jboss.beans.info.spi.BeanInfo/ClassInfo spis. Do we have framework to augment the ClassInfo with annotation information from other sources, such as mc BeanMetaData?
We need to be able to have annotation information described in the deployment, such as:
| <bean name="JNDIBasedSecurityRegistration"
| class="org.jboss.security.integration.JNDIBasedSecurityRegistration">
| <annotation>@org.jboss.managed.api.annotation.ManagementObject(name="JNDIBasedSecurityRegistration",
| componentType=@ManagementComponent(type="MCBean", subtype="Security"))</annotation>
| <property name="policyRegistration"><inject bean="JBossSecurityPolicyRegistration" /></property>
| <property name="securityManagement"><inject bean="JNDIBasedSecurityManagement" /></property>
| </bean>
|
show up in the ClassInfo, or change the management apis to accept a BeanInfo/ClassInfo so this information can be added via layers closer to the component deployers.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185255#4185255
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185255
14 years, 11 months