It's all about the answers!

Ask a question

Best Practices for participants?

Susan Hanson (1.6k2186193) | asked Jan 28 '14, 11:24 p.m.

I'm looking for best practices around Participants, specifically those that are for the same operation.  For example, we have a participant for workItemSave that will generate an Approval if needed based on a set of criteria for a User Story work item.  We are also going to look at doing something similar to generate Verification type approval records for Defect work items.

Is it the best practice to put both of these in a single participant?
Is it the best practice to have 1 participant per operation (workItemSave) and have everything you would ever want to do within the save operation in a single one?  One per work item type? On per logical "use case"?


2 answers

permanent link
Eric Jodet (6.3k5111120) | answered Jan 29 '14, 2:09 a.m.
 Hello Susan,
I would say there is no real best practices here.
As a general rule, I would define 1 operation per participant.
The main reasons are:
- code is easier to maintain
- code is easier to reuse

On the other hand, if you have a single participant to perform a couple of operations for various types,
you will end up with more complex and less re-usable code.

Hope it helps,

Susan Hanson commented Jan 29 '14, 5:04 a.m.

Thanks .... if we have multiple participants all for WorkItemSave, are they synchronous?  That is, if I am doing multiple things for the same work item type in different participants, then we wouldn't want both of them trying to modify the same work item at the same time. 

This was one of my thoughts of 1 participants per work item type: do all of the "stuff after saving a Story" in a single participant.  However, it does mean if I am creating approvals in different work item types, then it would span different participants and therefore, be less re-usable. 

So then I went to 1 participant per operation (like 1 participant to create all of the approvals across all work item types) so that I can reuse the createApproval logic, but  then I would have to be sure that participant #1 completes prior to participant #2 starting if they are both going to be modifying the same work item/type.


sam detweiler commented Jan 29 '14, 5:51 a.m. | edited Jan 29 '14, 6:43 a.m.

as I understand it, the participants, like Advisors are serial. only one at a time.  the order is how they are defined in the process config xml. you can move them around in the UI (up/down) to affect the order.
and remember when u save, it causes another iteration thru the advisors and participants.

I'm nearing completion of my approval injector as well, all configurable thru xml directives on what transitions for what workitem types generate what kind of approval for who (role or person)..

because you have to reboot the server to install/change the plugin, this is a very limited occurrence event. so I want as much capability in the plugin to start.

permanent link
Aradhya K (1.4k44345) | answered Jan 29 '14, 6:11 a.m.
For the use case you have defined, i.e. adding the approvals will be a advisor not the participant.
You can use process configuration XML to configure the condition such as state and work item type.

sam detweiler commented Jan 29 '14, 6:14 a.m. | edited Jan 29 '14, 6:46 a.m.

the general rules are 'NO CHANGES ALLOWED' by Advisors. they ADVISE..

Participants Participate. ie make changes.  Adding approvals CHANGES a workitem. (ie you must issue a save)

my xml config looks like this, also have approvalbyuser
<approvalbyrole workItemType="defect" approvaltype="review" oldSstate="In Progress" newState="Review"  role="reviewer" label="Code Review"/>

Your answer

Register or to post your answer.