Process definition deployment

[magoris]

Hi,

I am developing a web app with JSF 1.2, Spring 2.5.6 and jBPM 4.3. I am running it on JBOSS AS 5.1.0. I have integrated jBPM with Spring so I can use the jBPM 4.3 services as Spring beans.

I can't get the process definition deployment to work as I want though. When the app starts/restarts I deploy the process definition with the following code, as I want to be sure the process is deployed when the web app is running:

repositoryService.createDeployment().addResourceFromClasspath("process.jpdl.xml").deploy();

which works the first time, but on a following server start/restart i get the following exception:

org.jbpm.api.JbpmException: error: process 'process-1' already exists

I suppose this is because i have version="1" specified in the process definition. When I remove the version it works, but then it deploys a new version to the db every time, which seems illogical to me as it is the same process definition each time. Is this what is supposed to happen, or is there a way to check if a certain process version is already deployed, so it runs the deploy() code only when necessary?

Any help with this would be greatly appreciated, this is the first time I use jBPM in a project.

Greetings,

Maarten

[walterjs]

Hi Maarten,

The process needs to be deployed once into the db. Only if you have a change to the process definition, do you need to redeploy and it will automatically create a new version in the db.

By default, new processes will use the new definition.

Cheers

Walter

[magoris]

Hi Walter, thanks for your reply, that answered my question. I'll avoid the redeploy in my code.

What is the best way to do the deploy? Can I check in my code whether the process has been deployed yet and then deploy it if necessary, or is it best to already have the process in the db before the server starts? If so, how can i do this (for instance, is it ok to include it in the db create script)?

[walterjs]

No, there is an ant task that does deployments to the database. Run this whenever you need to do a deployment and leave the runtime environment free of doing deployments.

Take a look at the examples build script /jbpm-4.3/examples/build.xml.

Cheers

Walter

[magoris]

Hi again, thanks a lot for the help.

I wasn't sure how to do deployments because the examples always did them from code, so I didn't know using ant was the proper way of doing it. The build script gives me a good idea on how it is done, so I should be able to go from there.

Thanks again,

greetings,

Maarten

[kukeltje]

Well, ant is not specifically the proper way of doing it, it is a way of doing it. Ant infact deploys from code also. but that is probably not strange. Deploying from ant has the disadvantage that you need remote access to the database other then from your app. An alternative way is looking looking up the latest version of the process via the repository service and compare that with the one in the app. If they differ, deploy otherwise do nothing. You can also interpret the exception you get when deploying and detect that nothing happend....

So there are more ways to deploy.

[magoris]

Hey Ronald, thanks for the pointers.

Remote db access could indeed be a problem for the production server. For the moment I've surrounded the deploy code with a try...catch(JbpmException), but I think a conditional deploy like you described would be better as I'm afraid the try...catch could possibly catch JbpmExceptions thrown for a different reason than the already deployed version issue, which would cause them not to be noticed.

I've looked at the API for the services, but I can't seem to get it to work to compare the currently deployed process definition(s) with the one in my NewDeployment. Is there an advised way of doing this by any chance?

[kukeltje]

use the RepositoryService to create a  ProcessDefinitionQuery and use that to retrieve the infor from the database. Compare that with the definition you have. Something like this.... (partly correct, partly pseudocode, partly... )

    List<ProcessDefinition> processDefinitions = repositoryService.createProcessDefinitionQuery()
      .processDefinitionKey("nuclear_fusion")
      .orderDesc(ProcessDefinitionQuery.PROPERTY_VERSION)
      .list();

   NewDeployment newDeployment= repositoryService.createDeployment.addResourceFromString("xmlstring.jpdl.xml", jpdlXmlString)

   if (processDefinitions.get(0).getVersion()) < newDeployment.getProcessDefinitionVersion("nuclear_fusion") {

      newDeployment.deploy()

   } else {

       //latest version is active

   }

[magoris]

ah thanks, that's exactly what I needed. Your process definition query did the trick.

I ended up parsing the process xml myself though to get the new deployment's version (the getProcessDefinition method or something similar doesn't seem to exist in the NewDeployment api), but it comes down to the same thing.

Works like a charm

Thanks again,

greetings,

Maarten.

[kukeltje]

Right, sorry, it was (is) in DeploymentImp (a non-api class). Maybe file a jira issue to extend the (New)Deployment Interface with a method for retrieving it

[jedizippy]

Hi,

Be aware we came across some issues this week with versioned deployments. We have an EJB that does the deployments but we ran into issues if there were versions already deployed with the same version number. The deployer would correctly throw an exception if it encountered an existing process with the version you are trying to deploy but we were calling the deployer in a for loop for each process. In this case if a newer version of the processe did not exist in the DB the deployer would report success but not actually update the DB (presumably due to the exceptions on the processes which already had the latest versions deployed).

As we didnt have time to look into it we changed the EJB to deploy one process in the ejb method and then call that method for each process which solved the issue. Something to be aware of !.

Cheers

Martin