It's all about the answers!

Ask a question

[Java]Change Programatically state of Work Item

Fatla 777 (263712) | asked Feb 20 '13, 8:20 a.m.
edited Feb 20 '13, 8:20 a.m.
I need to change the state of a work item.
I have done the following:

    public void changeWorkItemsState(IWorkItem workItem,
            ITeamRepository repository, IProjectArea projectArea)throws TeamRepositoryException {
        IAttribute internalState = findAttribute(repository, projectArea,"internalState");
        Object value = workItem.getValue(internalState);
        Object newWorkItemState = "TEST.project.WorkFlow.state.s3";
        workItem.setValue(internalState, newWorkItemState);

However,I get the following IPE exception:

Exception in thread "main"    at$ProtectAdapter.notifyChanged(    at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(    at    at    at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(    at    at    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)    at sun.reflect.NativeMethodAccessorImpl.invoke(    at sun.reflect.DelegatingMethodAccessorImpl.invoke(    at java.lang.reflect.Method.invoke(

Thanks in advance.

Accepted answer

permanent link
Ralph Schoon (62.9k33645) | answered Feb 20 '13, 9:43 a.m.
edited Feb 20 '13, 9:44 a.m.
Hi Fatla,

first you need a workingcopy and then you have to use another operation that sets the workflow action. You would use a workItemSave operation.
Currently you could use setState, but that is deprecated. I have written something up around this here:
Fatla 777 selected this answer as the correct answer

Fatla 777 commented Feb 20 '13, 10:41 a.m.

Thanks Ralph.

Dan Sevcenco commented May 07 '13, 7:29 a.m.

Hello Ralph,

I am having a problem with both saveWorkItem2 and setState operations when I am trying to trigger a workflow state change. Neither of those are working. They are invoked, are executed but do not produce the expected results. Instead, the work item remains in the same state it was in before the invocation.

How can I figure out what is wrong with the code?


Ralph Schoon commented May 07 '13, 7:47 a.m.

Please read the provided examples in and in to understand that you have to provide a workflow action on save to change the sate of a work item.

Dan Sevcenco commented May 07 '13, 8:07 a.m.

Hello Ralph,

Those 2 examples are the ones I have been looking at for the past 2 days to try and understand why my code is not working. However, the matter of fact is that my code does exactly what yours is doing and still, my work item is not transitioned to the next state in its workflow from within the participant.

And the frustrating thing is that CCM is not throwing any exception or outputting any message to help me understand why the operation is not working.


Ralph Schoon commented May 07 '13, 8:21 a.m.

Do the two examples work for you? Are you able to debug the code?  Are you actually running into your code while debugging? Do you fetch the full state? Do you see if the save succeeds with its return value?

I would expect at least an exception if you do a save with wrong data. If you didn't prevent it, you would also see that your own follow up action is started two times. If you have no logs or indicators there is no way I can help you.

Dan Sevcenco commented May 07 '13, 1:37 p.m.

OK, to answer all your questions:

1. I am able to debug the code and I can confirm that the parameters are correctly set up.
2. When I retrieve the working copy, I do request the full state.
3. I am not able to verify the savestate object that the operation returns because when saveWorkItem is invoked, the participant is called again and then again and again in a recursive way until the server throws an internal error that has no connection to the save of the workitem but rather to the way too many recursive calls that are going on.

Now, you will ask why am I allowing the infinite recursive calls to go on. As a matter of fact, my participant has a guard against this condition and it checks for the workitem state. If the state changes, then the second call ends before anything else is executed. However, the 2nd call shows that the state of the workitem is not changed, so the guard is not triggered.

Since nothing else changes in the workitem, I do not have any other attribute to check for in the guard to avoid recursive calls.

Ralph Schoon commented May 08 '13, 12:51 a.m. | edited May 08 '13, 1:34 a.m.

You want to use saveWorkItem3 and use the technique described here: (see Communication Between Operations to Avoid Recursions) to prevent the recursion from happening. I think the same code is in the other downloads, but commented out.

Ralph Schoon commented May 08 '13, 1:04 a.m. | edited May 08 '13, 1:35 a.m.

For completeness, another technique to prevent recursion when triggering on state changes is to compare the workflow state of the oldState and the workflow state of the newState and exit, if they are the same (no state change happened). But there are cases when this might not be appropriate and you want to use saveWorkItem3 and communication between the participants and advisors.

Dan Sevcenco commented May 08 '13, 5:04 a.m.

Hello Ralph,

I did use your recommended solution and now I am invoking saveWorkItem3 with the additional parameter that prevents recursion from happening.

Now I can say that the operation does not report an error, in the ccm.log file there is no error, but the state of the item is not changed.



Ralph Schoon commented May 08 '13, 5:08 a.m.

Dan, as long as I have no indicators what could be wrong, I am unable to help. It has worked for me in the past I can't tell what you are doing wrong.

Dan Sevcenco commented May 08 '13, 6:38 a.m.

What kind of information could I get from RTC and give you that would help you understand what might be wrong?


Ralph Schoon commented May 08 '13, 7:00 a.m.

I would expect to see at least an exception if something went wrong - transition not applicable, and the save status should show the save failed. Like in the code I publish:

    IStatus saveStatus = fWorkItemServer.saveWorkItem3(parentworkingcopy, null, null,   additionalParams);
if (!saveStatus.isOK()) {
        // generate an error or do it in the calling method
        return false;

Dan Sevcenco commented May 08 '13, 9:18 a.m.

My code does the following:

Set<String> additionalParams = new HashSet<String>();
IStatus saveStatus = fWorkItemServer.saveWorkItem3(workItemWorkingCopy, null, workflowAction, additionalParams);

if (!saveStatus.isOK())
     IReportInfo info = collector.createInfo("Unable to change workitem state", "Error saving workitem with id : " + workItemWorkingCopy.getId());

So, if anything would be wrong with the execution of the saveWorkItem call, I would see the error message in the UI.

That does not happen.

showing 5 of 13 show 8 more comments

Your answer

Register or to post your answer.