Bug 1082029 - Exclude unnecessary elements (results) in the rest JaxbWorkItem reply
Summary: Exclude unnecessary elements (results) in the rest JaxbWorkItem reply
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: JBoss BPMS Platform 6
Classification: Retired
Component: Business Central
Version: 6.0.1
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: ---
Assignee: Marco Rietveld
QA Contact: Ivo Bek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-28 14:01 UTC by Anton Giertli
Modified: 2018-12-04 17:50 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-25 18:14:15 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Anton Giertli 2014-03-28 14:01:42 UTC
Description of problem:

When you issue following rest query
[GET] /runtime/ {deploymentId} /workitem/ {workItemId}

the reply looks similar to this:
<work-item>
<id>5</id>
<name>Human Task</name>
<state>0</state>
<parameters>
<entry>
<key>ActorId</key>
<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">anton</value>
</entry>
<entry>
<key>TaskName</key>
<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">callbacktask</value>
</entry>
<entry>
<key>NodeName</key>
<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">callback task</value>
</entry>
</parameters>
<results/>
<processInstanceId>5</processInstanceId>
</work-item>

Is it necessary to include element <result> ? To my understanding this attribute will *always* be empty. If the workitem is still active, the results are not filled in yet. They are being filled in upon complete(result) method if I am not mistaken. However, when you query this workitem after completing it is not available anymore. Which simply makes me think that <result> will always be empty no matter what, therefore it seems unnecessary to include it in the reply.

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

6.0.0 GA

How reproducible:
always

Steps to Reproduce:
1. Create process with one human task in the business-central, deploy and start the process
2. execute http://localhost:8080/business-central/rest/runtime/deploymentid/workitem/workitemid

I just used "1" on a clean installation, wasn't really sure how to retrieve the actual workitemid besides using method "try&fail".
3. Observe the output - <results/> element is *always* empty.

Actual results:

The output for runtime/deploymentid/workitem/workitemid includes element <results/> which will always be empty

Expected results:
the output does not include <results> element at all.

Additional info:

In case there is some way how to actually retrieve content of results using Rest API, please do let me know how before marking this as NOTABUG.

Comment 1 Anton Giertli 2014-03-28 14:03:00 UTC
Also, the same issue might be applicable also for output for some other queries, not just this particular one.

Comment 3 Marco Rietveld 2014-04-01 14:35:07 UTC
Hi Anton, 

The results element refers to the data submitted when completing the WorkItem. If you were doing this locally (instead of via REST), you would do it with this method: 

org.kie.api.runtime.process.WorkItemManager.completeWorkItem(long, Map<String, Object>)

The Map contains the "results" that are added to the WorkItem. With REST, at the moment, you can only add results that are Strings, Integers or Longs. You add them via "map query parameters". 

Hmm, this is *NOT* documented well in the product documentation. :/ Will fix that this week. 

It is documented here: 
https://hudson.jboss.org/hudson/job/droolsjbpm-knowledge/lastSuccessfulBuild/artifact/kie-docs/jbpm-docs/target/docbook/publish/en-US/html/jBPMRemoteAPI.html

See [17.2.6.5. Map query parameters] and the explanation for "/runtime/{deploymentId}/workitem/{workItemId}/complete" in [17.2.1.1. Process calls].

Comment 4 Marco Rietveld 2014-04-01 14:35:50 UTC
Anton, would it be okay to close this bug as NOTABUG? If there are other things that are not clear, please let me know!

Comment 5 Anton Giertli 2014-04-01 14:55:36 UTC
Hi Marco,

thanks for that resource. Though one thing is still unclear.

Let me rephrase maybe a little bit.

1) I call
/runtime/{deploymentId}/workitem/{workItemId}
result element is empty

2) I call /runtime/{deploymentId}/workitem/{workItemId}/complete?map_key=value
output is <status>SUCCESS</status>


3) I call /runtime/{deploymentId}/workitem/{workItemId} again - workitem is already completed, the result is NPE (probably some other message once that will be fixed, informing me that workitemid I have supplied is not valid anymore)

My point is user can never actually see the content of <result> element. If he queries it before the workitem is finished - it is empty, obviously. If he queries that workitem after it is completed, the response is empty completely. So question is - why to bother even showing this <result> element at all if it always will be empty ?


================================================
Is there *any* scenario when I will receive an answer when this element (result) will contain something ?

I understand that result is used internally for completing workitem, but for this particular query
GET /runtime/{deploymentId}/workitem/{workItemId}
it will never be filled with values, at least from what I can see.
================================================

It's not really an issue, more like a cosmetic thing, so if the overhead for solving it is too high then it is simply not worth it.
There is still a possibility that I've got this completely wrong though I hope I have expressed myself more clearly this time.

Cheers,
Anton

Comment 6 Marco Rietveld 2014-11-14 15:49:09 UTC
For administrative purposes, I've removed the 6.2.0+ flag, seeing as this bug is on the line between a bug and a feature (both?) and easy enough to fix.

Comment 7 Marco Rietveld 2014-11-25 18:14:15 UTC
Anton and Ivo, 

I tried to fix the bug -- and then realized I couldn't! The JaxbWorkItemResponse object is used as the REST DTO for the WorkItem implementation. 

https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/master/kie-api/src/main/java/org/kie/api/runtime/process/WorkItem.java#L106
https://github.com/droolsjbpm/droolsjbpm-integration/blob/6.2.x/kie-remote/kie-remote-jaxb/src/main/java/org/kie/services/client/serialization/jaxb/impl/process/JaxbWorkItemResponse.java#L22

The WorkItem implementation mandates a getResults() method. 

It's possible to include the method and not include the field, but that's not something I'm going to do: if the field is ever used, then the method and object should make sure to provide that information.


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