Welcome to the Jazz Community Forum
Best Practices for participants?

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

Comments

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

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.

Comments

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"/>