[JBoss jBPM] - Re: Communication between JBoss jBPM application and a web a
by dleerob
All the code you require is in the jbpm-console web application source code. That's probably where most people will learn how to interact with the Jbpm lilbraries.
For example, here is a method in one of my action classes, which shows how I start a process in my own web application:
public ActionForward startProcess(ActionMapping mapping, ActionForm form,
| HttpServletRequest request,
| HttpServletResponse response)
| throws Exception {
| if (log.isDebugEnabled()) {
| log.debug("Entering 'startProcess' method");
| }
| User currentUser = getUser(request);
| String processDefinitionIdStr = request.getParameter("processDefinitionId");
| long processDefinitionId = Long.parseLong(processDefinitionIdStr);
| jbpmContext.setActorId(currentUser.getUsername());
| GraphSession graphSession = jbpmContext.getGraphSession();
| ProcessDefinition processDefinition = graphSession.getProcessDefinition(processDefinitionId);
| ProcessInstance processInstance = processDefinition.createProcessInstance();
| // Signal the root token based on the following criteria:
| // 1. If there is no start task, and
| // 2. If the root token is still at the start state, and
| // 3. If the start state has a default leaving transition, then
| // signal the token along the default transition.
| TaskMgmtInstance taskMgmtInstance = processInstance.getTaskMgmtInstance();
| //set the current user as the initiator
| processInstance.getContextInstance().setVariable("sys_initiator", currentUser.getUsername());
| TaskInstance startTaskInstance = taskMgmtInstance.createStartTaskInstance();
| if (startTaskInstance == null) {
| // There is no start task
| Node initialNode = processDefinition.getStartState();
| Token rootToken = processInstance.getRootToken();
| Node rootTokenNode = rootToken.getNode();
| if (initialNode.getId() == rootTokenNode.getId()) {
| // The root token is still at the start node
| Transition defaultLeavingTransition = initialNode.getDefaultLeavingTransition();
| if (defaultLeavingTransition != null) {
| // There's a default transition
| rootToken.signal(defaultLeavingTransition);
| System.out.println("Signalled Root Token");
| }
| }
| }
| System.out.println("Started");
| if (processInstance.hasEnded()) {
| System.out.println("Finished");
| }
| // Nothing else saves the process, so we must
| jbpmContext.save(processInstance);
|
| return mapping.findForward("myTasks");
| }
And guess what, if I remember correctly, that was taken almost exactly as it from the jbpm-console webapp source code. So take a look there if you need help.
Good luck!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097720#4097720
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097720
18Â years, 8Â months
[JBoss jBPM] - job executor explained in a nutshell
by tom.baeyensï¼ jboss.com
I was writing in an email to someone how the job executor worked. So I thought i leverage that effort in the docs and here in the forum.
Here's how the job executor works in a nutshell:
Jobs are records in the database. Jobs are commands and can be executed. Both timers and async messages are jobs. For async messages, the dueDate is simply set to now when they are inserted. The job executor must execute the jobs. This is done in 2 phases: 1) a job executor thread must acquire a job and 2) the thread that acquired the job must execute it.
Acquiring a job and executing the job are done in 2 separate transactions. A thread acquires a job by putting its name into the owner field of the job. Each thread has a unique name based on ip-address and sequence number. Hibernate's optimistic locking is enabled on Job-objects. So if 2 threads try to acquire a job concurrently, one of them will get a StaleObjectException and rollback. Only the first one will succeed. The thread that succeeds in acquiring a job is now responsible for executing it in a separate transaction.
A thread could die inbetween acquisition and execution of a job. For clean-up of those situations, there is 1 lock-monitor thread per job executor that checks the lock times. Jobs that are locked for more then 30 mins (by default) will be unlocked so that they can be executed by another job.
The required isolation level should be set to REPEATABLE_READ for hibernate's optimistic locking to work correctly. That isolation level will guarantee that
update JBPM_JOB job
| set job.version = 2
| job.lockOwner = '192.168.1.3:2'
| where
| job.version = 1
will only return result 1 row updated in exactly 1 of the competing transactions.
Non-Repeatable Reads means that the following anomaly can happen: A transaction re-reads data it has previously read and finds that data has been modified by another transaction, one that has been committed since the transaction's previous read.
Non-Repeatable reads are a problem for optimistic locking and therefor, isolation level READ_COMMITTED is required if you configure more then 1 job executor thread.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097716#4097716
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097716
18Â years, 8Â months