Jazz Register Log in
Jazz Forum Welcome to the Jazz Community Forum

Welcome to the Jazz Community Forum

Connect and collaborate with IBM Engineering experts and users

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 votes



2 answers

Permanent link
 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

2 votes

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.


Permanent link
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.

0 votes

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

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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 10,985

Question asked: Jan 28 '14, 11:24 p.m.

Question was seen: 4,573 times

Last updated: Jan 29 '14, 6:46 a.m.

Confirmation Cancel Confirm