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.<init>(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:
But the bug is general. It's not just about REST API, also the GetProcessInstance command doesn't work when the instance is completed.
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.
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
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
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.
Verified in BPMS 6.0.0.ER2