August 2008 - jbpm-dev - Jboss List Archives

by vinodkv

hi I have 2 processes p1 and p2. I want to call p2 in p1. I have made both the processes separately and deployed them separately too. p2 was deployed first and p1 later. Now when i call p2 in p1, it says cannot initiate process as the ProcessDefinition is NULL. This happens even when i deploy both the processes together. Please provide a solution. Thanks in advance View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168880#4168880 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168880

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Making the BPM API more generic?

by kukeltje

+1 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168771#4168771 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168771

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Making the BPM API more generic?

by tom.baeyens＠jboss.com

"thomas.diesler(a)jboss.com" wrote : The jBPM4 project is expected to take part in the JBossBPM API design and eventually provide an implementation of it. The project efforts in jBPM 4 for client API will be concentrated around the PVM API and if the product wants to do something else, it will have to be done in a separate space. Not in the jBPM coderepositories, forums, wikis, mailing lists, jira. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168625#4168625 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168625

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Making the BPM API more generic?

by thomas.diesler＠jboss.com

Mark anonymous wrote : | This api will be able to wrap, to some degree, other process engine apis. Our PVM will also be capable of executing their models. As proof of concepts krisv has done partial implementations for BPEL, OSWorkfow and jBPM. BPEL runtime is almost complete (Drools is able to execute most examples), although it has not been wired up to WS and still needs work on XML assignment issues. OSWorkflow and jBPM runtime mappings are about 70% complete. | Whow ... so its high time we actually get together and consolidate what can get consolidated. I'd like to present you and Kris our ideas show you whats there and line up roadmaps. Lets take this off-line and try to find a way to get together. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168575#4168575 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168575

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Making the BPM API more generic?

by thomas.diesler＠jboss.com

anonymous wrote : | The API is a product not related in any way to jBPM | Branding is not decided yet. For now I'd like to call it JBossBPM, which comprises API + RI + CTS. Yes it is not related to jBPM anonymous wrote : | The PVM is an improvement of jBPM but not related to the API | The jBPM4 project is expected to take part in the JBossBPM API design and eventually provide an implementation of it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168570#4168570 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168570

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Making the BPM API more generic?

by kukeltje

Hmmm... I admire JBoss having this discussion on a public forum. It is good to have the intention to achieve synergy. Personally though, I get the impession there are, at least to a certain extend, 2 competing camps. If I were a potential/current customer/user I'd become a little restless on where 'everything' (and I know I exaggerate) is going. 'Drools executing BPEL', jBPM runtime mappings? A second PVM, OSWorkflow?... Besides that, as an (upcomming) consultant, I to have to be able to rely on something. A stable API?afaik, the jBPM api was kind of stable. Not very transparant, but stable. In fact it is not that different from what Kris mentions for Drools. I know this is only partially a comment on the contents of this topic, but I thought I'd give my â¬0.0125 (at an exchangerate of 1:1.6) anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168515#4168515 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168515

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Making the BPM API more generic?

by mark.proctor＠jboss.com

Drools in M3 in about 3 weeks will be orienting away from a rules centric api to a knowledge centric api - i.e. it will not be process centric either, nor will it be tied to Drools. This has been planned for a while: http://www.mail-archive.com/rules-dev@lists.jboss.org/msg00757.html This api will be able to wrap, to some degree, other process engine apis. Our PVM will also be capable of executing their models. As proof of concepts krisv has done partial implementations for BPEL, OSWorkfow and jBPM. BPEL runtime is almost complete (Drools is able to execute most examples), although it has not been wired up to WS and still needs work on XML assignment issues. OSWorkflow and jBPM runtime mappings are about 70% complete. Diego from OSWorkflow is keen on finishing the OSWorkflow adaption. And I'm hoping someone else will take ownership of the BPEL side - we are in talks with large health organisation that is possible going to lend 2 resources for BPEL and WS-Human-Task implementation. We've checkout the Eclipse BPEL tooling and it's now much more improved and almost complete, making BPEL support with tooling now a possibility. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168496#4168496 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168496

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Making the BPM API more generic?

by KrisVerlaenen

"tom.baeyens(a)jboss.com" wrote : Are your API docs online ? A link would be great. Yes, of course, all Drools code can be found in our svn repository. But as it might be a bit difficult to find what you need in this web of classes, let me give you a high-level overview. Note that I will only include generic interfaces, specific process languages could extend some of these interfaces to offer more options to the end users. /* A process contains the definition of the business logic, specific process languages need to extend this interface. */ Process void setId(String id); String getId(); void setName(String name); String getName(); void setVersion(String version); String getVersion(); void setType(String type); String getType(); void setPackageName(String packageName); String getPackageName(); void setMetaData(String name, Object value); Object getMetaData(String name); /** End users that want to execute processes interact with a session */ Session ProcessInstance startProcess(String processId); ProcessInstance startProcess(String processId, Map<String, Object> parameters); public Collection getProcessInstances(); public ProcessInstance getProcessInstance(long id); /** A process instance represents one instance of a process that is currently executing, specific process languages need to extend this interface */ ProcessInstance long getId(); String getProcessId(); int getState(); void setState(int state); /* Events */ void signalEvent(String type, Object event); /* Variable Scope */ Object getVariable(String name); Map<String, Object> getVariables(); void setVariable(String name, Object value); /* Whenever the execution engine want to invoke external services, it does so using an abstract workitem (contains name-value parameters) */ WorkItemHandler void executeWorkItem(WorkItem workItem, WorkItemManager manager); void abortWorkItem(WorkItem workItem, WorkItemManager manager); /* Results of these invocations can be returned to the execution engine */ WorkItemManager void completeWorkItem(long id, Map<String, Object> results) void abortWorkItem(long id) Then there are of course also interfaces for storage and deployment, monitoring, etc. Note that these interfaces are generic and contain nothing specific about Drools Flow. Kris View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168489#4168489 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168489

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Making the BPM API more generic?

by KrisVerlaenen

"thomas.diesler(a)jboss.com" wrote : Using the BPMN spec we created a model which is meant to accommodate the conceptual constructs from the BPM world All these constructs sound extremely familiar of course, basically all workflow specifications and languages define these in one way or another. What I don't see is this language is different from for example the jPDL language, WS-BPEL, XPDL or Drools Flow? Why not use an existing process model (and possibly extend that if necesary)? "thomas.diesler(a)jboss.com" wrote : With respect to DroolsFlow, I would expect that you can map your model to the API model implementing a DialectHandler This would mean that the common API is some kind of uber process model that can be used to execute any process and that all process languages could be mapped to this language? The PVM idea on the other hand tries to offer the flexibility of different process languages on the same execution platform without having to map everything to one core language. Different contexts typically require different types of nodes: service orchestration is quite different from pipelining events and from healthcare processes for example. Sometimes it's just better to allow users to plug in their own implementation (based on a generic core) than force them to translate to one specific model. However, regardless of which process model is used internally, I think that it is possible however to define a high-level generic API in how the user interacts with the different BPM components: repository, runtime engine, monitoring, etc. Kris View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168475#4168475 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168475

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Making the BPM API more generic?

by tom.baeyens＠jboss.com

"KrisVerlaenen" wrote : I believe that the idea of creating a public API for jPDL or BPM in general is very interesting. We (the JBoss Drools team) try to achieve close integration between processes and rules. A generic BPM API could be very useful here. Our vision is to create a unified platform where rules and processes are simply different ways of expressing (some of your) business logic and can be seamlessly integrated. This would allow users to select the most appropriate paradigm for their problem and integrate rules and processes without requiring them to learn and integrate different products themselves. | | This is partially based on the observation that both rules and processes have a very similar life cycle: creation in a custom editor, storing your business logic in a repository, deployment to a runtime environment, monitoring and management of the execution, etc. We believe that is should be possible to offer an unified environment where this life cycle is supported as much as possible and both rules and processes are considered different types of business logic. | | Drools has a RuleFlow language (for specifying the order in which rules should be executed using a flow chart) since v4.0 and is now extending that scope to become a more generic workflow language as well, where rules and processes can be integrated seamlessly (called Drools Flow). It would be interesting to see whether Drools Flow (or any other language like e.g. BPEL) can also fit in this common API effort, and maybe in the long term whether we can offer a similar API for both rules and processes. | | I think it would be possible to achieve this if we split the API into a more generic part (offering methods to interact with processes of any type) and allow specific process languages (like jPDL3 or 4 or Drools Flow) to extend this API with more specific constructs. For example, different languages would probably have a different process model, but they all could implement a generic process interface. I also believe that the API for interacting with a process engine (starting processes, signalling events , communicating with external services, etc.) can all be made independent of the underlying process model and implementation (the user should not be confronted with these details in most cases). The interfaces defined by the WfMC are a very good example of this. | | I'd be glad to provide more details on the different APIs Drools Flow is currently using to communicate with the outside world if needed ! | | Kris PVM contains 3 different API views: 1) client 2) activity implementation 3) event listener In its current shape, Thomas' BPM API has the same scope and target then the client API part (1) of the PVM. I think this is to be considered a learning excercise in Thomas' start to work out the BPM product requirements. But to answer your question, I think it is always good to compare each other's work. Are your API docs online ? A link would be great. PVM API lastest version is here: http://docs.jboss.com/jbpm/pvm/api/ This is still in flux, but the next version to a couple of weeks will be pretty much stable. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168469#4168469 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168469

16 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jbpm-dev August 2008