It's all about the answers!

Ask a question

Can you not update the AdapterTask via the API?


Michael Caldwell (114) | asked Sep 13 '20, 10:38 a.m.

 Hello,


Is it possible to update an adaptertask record via the API when it is queued in the Execution Console?  I have tried doing a POST after doing a GET with an updated selectedAdapterId value but even though it returns a 200, the update was not made.

Thanks..

RQM Version 6.0.6

One answer



permanent link
abhishek gour (3812) | answered Sep 14 '20, 7:37 a.m.

Hi,

Adapter task can be updated via the API  - https://jazz.net/wiki/bin/view/Main/RqmApi
For example - if you try to change the progress tag via a PUT call, then it should update the progress on the task. 
What attribute you are trying to update? If the update was not made then it should not return 200. May be in that case it is a defect. 
Could you provide some example or sample? 


Comments
Michael Caldwell commented Sep 14 '20, 9:10 a.m. | edited Sep 14 '20, 9:15 a.m.

 As mentioned in the question I am trying to update the selectedAdapterId attribute.  Here is the segment of the xml that is is being updated:


<ns15:selectedAdapterId>89936</ns15:selectedAdapterId>.

I confirmed in the UI and via an API GET that the update was not made.


Michael Caldwell commented Sep 14 '20, 4:09 p.m. | edited Sep 14 '20, 4:39 p.m.

Every so oftent the update works and I see the new adapter in the UI assigned to the task.  When it does update, it just sits in a Queued status and never kicks off on the adapter machine.  Is there something else I need to change in the adapterTask xml to have RQM "start" the execution on the update adapter Id?  Thanks... 


Michael Caldwell commented Sep 14 '20, 5:42 p.m.

 I take that back, I am unable to see where the selected adapter id has changed.  On one attempt I thought it did, but that doesn't seem to be the case.


abhishek gour commented Sep 14 '20, 11:51 p.m.

I think there is complicated logic of selecting adapters for execution. The adapter should be assigned before the adapter task goes in to queue, so that the required resources (adapter) could be reserved. Unless the resource is reserved it wont be picked up for execution.
Changing the adapter id for a task which is already in queue may result in unstable behavior. 

Could you work around this?


Michael Caldwell commented Sep 15 '20, 8:49 a.m.

Yeah, what I am attempting here is a workaround for RQM's inability to truly run in a parallel automated fashion.  When a test suite execution starts all test cases are pre-assigned adapters rather than assigning them as test cases finish.  So we end up having adapters assigned to shorter running tests not doing anything while there is a queue on adapters that had longer running scripts.  I was hoping to help with this by monitoring this behavior and reassigning queued tasks to available adapters. 

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.