Un expected behavior observed with Token details

[narasimha_addanki]

For our Application we have defined a Process Definition which consists of States. When a Process Instance is created of this Process Definition and the workflow is initiated, The Root Token flows throw the Workflow (which may result in the creation of Child Tokens) and these tokens will eventually stop or halt at certain states. The states they reside on is decided by certain parameters and the path followed by the token.

After the successful execution of a Process Instance we have a necessity to know the state (i.e. State Name) in which the token has halted. So we firstly find the Process Instance we require, get the Root Token, and then get the children of this Root Token. We then use the Token Class method getNode().getName(), which will return the Node Name on which this Token resides.

Expected Behavior:

This value of getNode().getName() can never be null as the Token has to be on a State at the point when the execution has completed successfully.

Deviation:

The State is returned as null, thus resulting in a NULLPOINTEREXCEPTION.

On later inspecting the database we found that in the table JBPM_TOKEN where the details of the token are stored, the column value of Node for this particular token is NULL.

We have attached an Excel Sheet with the details of this table and have highlighted the NULL field.

I have exported database details for JBPM_TOKEN to an spreadsheet which depicts null value under the NODE_ column

I intended to attach the excel sheet but couldn't find a way to attach to this message.

Can any one help in:

1) for attaching the spread sheet
2) to find the solution for NODE_ attribute becoming NULL.

[kukeltje]

1: impossible, publish it somewhere and post the link
2: please state which jbpm version, which database, a unit test demonstrating the behaviour etc...etc...etc

[malish]

We have similar issues with getting a null token using call process.getRootToken(). It is fairly easy to achieve that:
* Define your own ActionHandler class. All it should do in execute(ctx) method, is throw new java.lang.Exception("haha")
* Place this ActionHandler into jpdl
* Invoke state transition by calling process.getRootToken().signal()

That would be the last moment when you are able to access rootToken. Next time process.getRootToken() will return NULL value.

[malish]

Just to correct the last sentence of my previous message:
process.getRootToken().getNode() will return NULL value.
Also, process.getRootToken().getAvailableTransitions() will start returning NULL value as well.
Not sure which how to check the JBPM version. Timestamp is 2007-03-16.

[malish]

Until an appropriate solution is found or reply is received from JBoss, we have just decided to apply the following local fix.
Again this is related to loss of Node after Exception is thrown within the custom ActionHandler.
All we do is saving the Node object before calling token.signal() method. When we catch the Exception and if new value of getNode() is NULL, we store the saved copy of the Node. Sample code is below:

public void processWorkflowEvent(long pid, String eventName) throws ...
{
 JbpmConfiguration jbpmConfiguration = JbpmConfiguration.getInstance();
 JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
 try
 {
 ... your own code
 ProcessInstance process = jbpmContext.getProcessInstanceForUpdate(pid);
 Token token = process.getRootToken();
 // save the node
 Node nodeSaved = token.getNode();

 // process signal
 try
 {
 token.signal(eventName);
 }
 catch(Exception e)
 {
 if(token.getNode() == null)
 {
 // node is lost due to JBPM internals
 // restore the node
 token.setNode(nodeSaved);
 }
 ...
 }
 }
 catch(Exception e)
 {
 // do whatever you need to handle own exceptions
 }
 finally
 {
 jbpmContext.close();
 }
}

[kukeltje]

If you think this is a bug or enhancement, please file a jira issue. By just stating it here there is no guarantee it will get fixed

[estaub]

malish,

When you jira it, you might ask for javadoc describing what to expect, regardless of the disposition of the request for a change in behavior. The current doc leaves it to your imagination.

-Ed

[mputz]

I could reproduce this with your suggestions of throwing an exception in an ActionHandler. But only if I signal this from a custom application, not from within the default jBPM 3.2 web app. So I suspect this is a configuration issue. I'll try to dig deeper and let you know when I find something...

[mputz]

Please disregard my previous comment - it has nothing to do with configuration.

I oversaw that you were throwing an exception, but didn't mark the current transaction as to be rolled back.

So instead of your workaround of re-setting the node on the context again, just add jbpmContext.setRollbackOnly() in the catch block.

public void processWorkflowEvent(long pid, String eventName) throws ...
{
 JbpmConfiguration jbpmConfiguration = JbpmConfiguration.getInstance();
 JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
 try
 {
 ... your own code

 // process signal
 token.signal(eventName);

 }
 catch(Exception e)
 {
 // mark this transaction as dirty
 jbpmContext.setRollbackOnly();
 // do whatever you need to handle own exceptions
 }
 finally
 {
 jbpmContext.close();
 }
}

No need for a JIRA entry IMO.

[kukeltje]

Would be nice to add a jira issue nevertheless. Just not for the original problem, but for adding this to the docs.

[estaub]

Ronald,

Given what this turned out to be caused by, what are you thinking should be doc'd?

Maybe the getNode() return? Like so:

@return the last node entered, or the start node for the root token of an unsignaled new process instance. Guaranteed non-null.

[I don't know for a fact that this is true, though... I'm just recording my own fantasy of how it works/should-work!]

-Ed Staub

[kukeltje]

Yes that to, but I was more thinking about the example Martin gave of the use of jBPMContext.setRolbackOnly()

[estaub]

I suspect there are more problems here.

If I'm not mistaken, when an actionhandler is invoked, the transaction will have started at the last asynchronous event that caused something to be written persistently. If all the nodes are asynchronous, this is fine. But if there's a sequence of synchronous nodes, the process may unwind quite far back. This seems like it would be surprising to the developer. If any of the external actions in the rolled-back sequence aren't transactional, the process will now be "skewed", living in the past, relative to the real-world process being performed, probably waiting for an event that has already happened and now will never occur again.

If there are any actionhandlers or other elements that may or may not signal synchronously, the amount of rollback becomes somewhat unpredictable. This is common when waiting for an event that may have already happened, e.g., a timer that may have already expired.

I'm not saying that the JBPM internal process integrity is lost, just that the distance rolled back in the graph seems likely to be unexpected and/or uncertain, and hence difficult to design error-handling for.

Did I miss something? Is there an easy workaround? A best practice to propose?

-Ed Staub

[kukeltje]

Ed,

Your analysis is correct. These are common issues and have been discussed previously when talking about an 'undo' function.

Some issues/solutions have to modeled on the businesslevel. Others require a more technical approach. Do's /don'ts/best practices/common pitfalls are not really available yet.

[estaub]

Ronald,

Thanks for the feedback.
Transactions are never easy!

-Ed