Bug 975798 - Cannot get process instance details via REST API when the instance is completed
Cannot get process instance details via REST API when the instance is completed
Status: CLOSED CURRENTRELEASE
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
6.0.0
Unspecified Unspecified
unspecified Severity unspecified
: ER2
: 6.0.0
Assigned To: Marco Rietveld
Ivo Bek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-19 07:30 EDT by Ivo Bek
Modified: 2016-09-20 01:04 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-08-06 16:06:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ivo Bek 2013-06-19 07:30:34 EDT
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 07:34:04 EDT
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 08:27:57 EDT
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 09:08:41 EDT
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 09:14:12 EDT
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 09:31:23 EDT
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 09:51:45 EDT
Verified in BPMS 6.0.0.ER2

Note You need to log in before you can comment on or make changes to this bug.