Best Practices for participants?

Susan Hanson (1.6k●2●201●194) | 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"?

Susan

2 answers

Most liked answers ↑|Newest answers|Oldest answers

permanent link

Eric Jodet (6.3k●5●111●120) | answered Jan 29 '14, 2:09 a.m.
JAZZ DEVELOPER

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,

Eric

Comments

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.

Susan

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.4k●5●43●45) | answered Jan 29 '14, 6:11 a.m.
JAZZ DEVELOPER

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.

Comments

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 log in 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.

It's all about the answers!

Related questions

Best Practices for participants?

2 answers

Your answer