Serializeable / DeploymentImpl
by Bernd Rücker
Hi!
Shouldnt classes like DeploymentImpl implements Serializable?
Cheers
Bernd
--
Unsere Seminare: www.camunda.com/seminare/
Blog: www.bpm-guide.de
---------------------------------------------
camunda services GmbH - The Business Process Company
Zossener Straße 55-58 - 10961 Berlin / Werastraße 18 - 70182 Stuttgart
www.camunda.com - info(a)camunda.com
---------------------------------------------
Bernd Rücker
Geschäftsführer
Telefon +49 +49 30 664040 901
Mobil +49 171 1473461
bernd.ruecker(a)camunda.com
---------------------------------------------
Amtsgericht Charlottenburg: HRB 113230 B
Geschäftsführer: Jakob Freund, Bernd Rücker
---------------------------------------------
EJB-3-Buch: http://www.ejbbuch.de/
BPMN-Buch: http://www.hanser.de/buch.asp?isbn=978-3-446-41768-7
15 years, 5 months
[Design of JBoss jBPM] - Re: Status / Documentation of gwt-console & report-server
by camunda
A short comment from me as well.
The wiki page looks already promising. For me, most important would be some easy things:
- see the current activity of a process instance (would be sufficient as a column in the table)
- See all process instances (not selecting a process definition)
By the way: How do I see Child Executions / the Execution Hierarchie? This would be important as well.
And and some feedback on the usability: To have the ProcessDefinition/ProcessInstance Tab was a bit confusing for me first. I didn't recognize they have a relationship to each other...
Heiko wrote :
| Process variable inspection is one of those cases. There is currently no constraint on variables whatsoever. The "hashmap" style of design allows for everything and nothing at the same time. Of course it would be useful have that feature in the console, but without any type descriptions associated with the process it will only work in particular situations and break in others.
|
I agree with the others, a simple table with the toString representation would be already a big step ahead. With some improvement it may get a generic Tree (e.g. to show lists, maps and object properties easily). This is what we have in a couple of rich clients at some customers already.
If you then cann delete, change or add variables/entries (add by specifying the class name), it would be already very sophisticated :-) But this has not a very high priority (even if I had the demand already a couple of times).
But I am eager to the see the next evolution of it :-)
Heiko wrote :
| Currently the console has to cope with a lot of unknowns, which derive from the "everything possible, but nothing mandatory" style of coding that jbpm4 reflects.
|
Yeah, I think thats the destiny of a generic process engine console ;-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238246#4238246
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238246
15 years, 5 months
[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?
by camunda
Okay, I checked the Remote configuration now. Quite cool! Pretty nice for normal use cases I think.
I still have some concerns:
1.) For Marketing reasons I would like to see EJB 3 inside of it. Even if you don't use it directly, EJB 2.1 is just "odd old" ;-) Too unsexy for jbpm 4. Maybe not a high priority, but still. And as Jorram pointed out, the developers supporting it or people trying to figure out transaction problems or whatever have a harder live here.
2.) I wouldn't completly let got of the commands. Zwo use cases from my last projects of a big customer, where I still would prefer them:
a) Batch Commands: We just added a thin layer around the commands in order to be able to call them in a batch. The same command, but just with different parameters (e.g. from a csv). So in one batch you could execute a couple of thound commands (sync or async. Normally async with a big amount). Would be possible with the current API as well, but was/is much easier by using the commands directly.
b) Chained Commands: Think of the use case, where you have to fix an instance. E.g. you have to cancel it, start a different "fixing" process for it, maybe jump to a special node and execute a Groovy script to fix process variables. Okay, maybe not the best example here, but we had business requirements to do stuff like this. Therefro we introduced a CommandChain which can execute other commands IN ONE transaction. (Clue is you can execute the chain as batch :-)). If you use the remote ProcessEngine it executes every call in its own transaciton, right?
And again, I think it is even easier to implement with the commands, than with the API...
This is why I still like the commands. But maybe I am just too used to it? So if you have good points agaionst it just let me know :-)
Thoughts?
Cheers
Bernd
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238174#4238174
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238174
15 years, 5 months
