-
1. Re: database maintenance
Which version of jBPM are you using? Starting with jBPM 4.x it uses a separate table for finished process instances. After completion of the process they are moved there. So there shouldn't be any problems with instance tables growing to big. However, in jBPM 3.x this can be the case AFAIK. But I am not sure since I am not using jBPM 3.x.1 of 1 people found this helpful -
2. Re: database maintenance
Hi, Im using Jbpm 3.0.1. I've just tried Jbpm for about a month or more so dont have much experience about it. Thank for sharing that information. I think you're correct. Probably I will try the new version to see the difference when data is persisted to database. -
-
4. Re: database maintenance
Hi, actually I and my team have downloaded jbpm4.2 and start experience with it. However we have alot of trouble customize the GUI interface because our dev team lack of Google Web Toolkit skill, furthermore we ultimately want running Jbpm with Oracle 10g and wasnt able to get it running at first place. Then we come across Runa WFE, a SourceForge project that use Struts as web framework, based on Jbpm 3.01 as it core process engine. Its also easy to configure datasource with Oracle.
So infact we dont use Jbpm 3.01 directly but yes we use Jbpm 3.01.
Please excuse my english and my lack of knowledge in Jbpm also.
Regards,
Giang
-
5. Re: database maintenance
Of course you are free to modify the BPM console but in case you want to have your own user interfaces anyway why don't just build a web-application with your preferred technology making use of the jBPM-API? -
6. Re: database maintenance
we did think of this. The GWT console consists of console-ui, console-server, domain-model and integration layer. So in case we want our own GUI, none of these can be used? You mentioned about the Jbpm API, is that "jBPM 4 Developers Guide" and "jBPM 4 API Javadocs" ?
Thank for helping me
-
7. Re: database maintenance
You are right that the API ist documented in the javadocs. The console makes indirectly use of the jBPM-API. The console is supposed to be also used with different projects so it's a kind of generic BPM Console. It interacts via RESTful webservices (console-server) with the API. They are used for 2 reasons:
- The use of the jBPM-API is abstracted from the console project.
- You can easily run the console on a different server.
You are free to to use the console-server but be aware that it might not support all the things you need since the console does not support all functionalities of jBPM right now and the only purpose of it is actually to serve the console. Not sure about the functionality.
What do you mean by domain-model and integration layer? The domain-model is usually a part of your own application.
corrected typos
-
8. Re: database maintenance
I read these information from "BPM console reference" 1.0.0 GA by Heiko Braun in which console-ui is gwt-console.war, console-server is gwt-console-server.war, domain model is gwt-console-rpc.jar and integration layer is gwt-console-server-integration.jar. That are 4 related components acording to the document. Since we moved to Runa WFE afterward, I havent read more detail of it but surely when having more time I will take a better look. -
9. Re: database maintenance
If Heiko wrote it it will be correct. I am not very firm about the console. But domain-model now makes more sense to me. Since the console has to deal with different objects depending on its usage. in jBPM these are tasks and process instances etc. But anyway, these things all serve one purporse: to integrate the generic console with jBPM. I see no advantage of taking them as a start to building an own web application. Maybe you should ask aboout this in the related forum.
-
10. Re: database maintenance
Thank for sharing infomation. I would indeed start new thread on building own console using web framework if otherwise searching similar topic not found. -
11. Re: database maintenance
I think that starting a new thread will not give you much: http://community.jboss.org/thread/147466?tstart=0 since as Sebastian mentioned, it is nothing more than using the jBPM api as you would from a unit test. -
12. Re: database maintenance
Ok, but for the Jbpm API could you point to better document than Javadocs API? something that I can understand the overivew architecture of Jbpm API rather than detail in Javadocs.
Sorry if I ask question that answered somewhere in community dicusion already
-
13. Re: database maintenance
It seems that you've been able to locate the javadocs so locating the normal documentation shouldn't be a problem for you. So why don't go ahead and read it before asking more questions? And also take a look at the examples. There easy ones to start with and they all make use of the API.