Bug 975798

Summary: Cannot get process instance details via REST API when the instance is completed
Product: [Retired] JBoss BPMS Platform 6 Reporter: Ivo Bek <ibek>
Component: Business CentralAssignee: Marco Rietveld <mrietvel>
Status: CLOSED CURRENTRELEASE QA Contact: Ivo Bek <ibek>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.0.0CC: kverlaen, rzhang, smcgowan
Target Milestone: ER2   
Target Release: 6.0.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-06 20:06:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ivo Bek 2013-06-19 11:30:34 UTC
Description of problem:

When I try to get process instance details about the instance, which is completed, it throws NPE. BTW the process instance is visible in the business central with status 'completed'.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<response>
    <status>FAILURE</status>
    <url>/business-central/rest/runtime/org.jboss:integration:1.0.0.Final/process/instance/8</url>
    <stackTrace>java.lang.NullPointerException
	at org.kie.services.client.serialization.jaxb.impl.JaxbProcessInstanceResponse.initialize(JaxbProcessInstanceResponse.java:88)
	at org.kie.services.client.serialization.jaxb.impl.JaxbProcessInstanceResponse.&lt;init&gt;(JaxbProcessInstanceResponse.java:84)
	at org.kie.services.remote.rest.RuntimeResource.getProcessInstanceDetails(RuntimeResource.java:81)
	at org.kie.services.remote.rest.RuntimeResource$Proxy$_$$_WeldClientProxy.getProcessInstanceDetails(RuntimeResource$Proxy$_$$_WeldClientProxy.java)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216)
	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
	at org.jboss.resteasy.core.AsynchronousDispatcher.invoke(AsynchronousDispatcher.java:243)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.jboss.solder.servlet.exception.CatchExceptionFilter.doFilter(CatchExceptionFilter.java:65)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.jboss.solder.servlet.event.ServletEventBridgeFilter.doFilter(ServletEventBridgeFilter.java:74)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.jbpm.designer.web.filter.impl.PluggableFilter.doFilter(PluggableFilter.java:70)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:481)
	at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:134)
	at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:99)
	at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:92)
	at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:64)
	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920)
	at java.lang.Thread.run(Thread.java:662)
</stackTrace>
</response>


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Ivo Bek 2013-06-19 11:34:04 UTC
But the bug is general. It's not just about REST API, also the GetProcessInstance command doesn't work when the instance is completed.

Comment 2 Kris Verlaenen 2013-06-27 12:27:57 UTC
The observed behaviour is the intended behaviour.  The GetProcessInstanceCommand (and the REST API that is using this underneath) is querying the runtime data for this information.  Runtime data only contains the current state of active instances, it doesn't contain history information.

Information about completed instances (or completed nodes of an active instance) can be found in the history log.

This information is however not (yet) exposed through REST for the 6.0 release.

I do believe that the NPE should be resolved of course, and an appropriate error message should be returned to the user.

Comment 3 Ivo Bek 2013-06-27 13:08:41 UTC
Hi Kris,

I think it would be better to not return any error because nothing is wrong when a user just want to get information about process instance, which was only completed or aborted and probably the user doesn't know that, so he asks.

Would it be problem to get the information from history data in the getProcessInstance method when the process instance isn't found in the runtime data? Because when the user gets the error that the process instance doesn't exist, he must asks again for history information to just find out result of process instance, which seems to me redundant.

Thanks

Comment 4 Kris Verlaenen 2013-06-27 13:14:12 UTC
Ivo,

Yes, I meant make sure no error is thrown internally, and in this case probably just return null (as no active ProcessInstance with that id was found).

The REST API just mirrors the behaviour of the ksession, so I don't think we can change it.  But in general queries about which process instances are active and what their state is should go to the history log (as that also has all the information about active process instances).  This way, the user will get the information he needs in one invocation (and by using the history log, these queries won't impact runtime performance).  This information is however currently not yet exposed through REST.

Kris

Comment 5 Ivo Bek 2013-06-27 13:31:23 UTC
Oh ok then. For the performance it makes sense to ask just the history log when it's separate from the runtime. So, for our tests it will be enough to use the operation, using history log. That's helpful, thanks.

Comment 8 Ivo Bek 2013-09-09 13:51:45 UTC
Verified in BPMS 6.0.0.ER2