It's all about the answers!

Ask a question

RTC process sharing design considerations for consumer Project Areas

Karthikeyan Narayanan (2625) | asked Nov 07 '14, 3:34 p.m.
edited Nov 26 '14, 8:50 a.m. by Ralph Schoon (59.7k23643)

Managing Rational Team Concert work item changes with process sharing allows the ability to centrally manage any work items configuration changes as described in the below article using the Provider / Consumer concept.

Moreover any configuration changes at the consumer Project Area that are deemed necessary to be made like adding custom attributes are possible with the following options.

A.      You may customize the consumer's process configuration for any process element. But when you customize the process configuration for a process element on the consumer then the consumer uses its own process configuration for that entire process element. This happens for each process element in an all or nothing manner. Once you have customized a process element on the consumer it no longer uses any settings for that process element from the provider

More on Work Item Configuration and Shared Process in Rational Team Concert can be found in

B.      B. Using fine grained customization of configuration data by defining small configuration deltas to a shared workitem configuration, projects will continue to inherit changes to the shared process instead of completely overriding it. RTC 4.0.4 extended this support by permitting the modification of the name of a custom attribute in a work item. This early support will cover a small set of critical of use-cases and will require manually copying snippets of XML into the process specification, but this is only a first look at the feature. We will continue to grow and evolve it in future releases.


More on fine grained customization of configuration data can be found in

My questions/concerns

1.       1. What is the best option to choose between A and B considering that we are adopting process sharing with a potential need to customize consumer PA configurations in the future.

i).       It appears option A is safe as all configurations on the consumer PA are done using the RTC designer; however the inheritance is broken once a process element is customized.

ii).      Also it appears option B is attractive since one is able to customize the consumer and still be able to inherit from the provider; however, the configuration is manual and needs to be carefully performed directly as XML fragments.

                   iiI)Also how well can we rely on the statement “We will continue to grow and evolve it in future releases” on the delta configurations enhancements?

2. 22.  How does one avoid making configuration changes (that are deemed necessary) using option A or B directly on the consumer PA in real time but be able to test and promote the changes (from another test consumer PA) all at once on demand seamlessly?

3.       I understand that once we choose one of the above methods (A or B), one cannot change or switch between the two.





2 answers

permanent link
sam detweiler (12.5k6184201) | answered Nov 07 '14, 4:14 p.m.
B is also limited in scope..

Only limited workitem fields are supported for delta config.
not workflow, not new workitems, not new states,

careful design of what needs to be customized at the child and what can be standardized at the parent will help you

there ARE ways to get back under control

there is nothing to prevent poor process mgmt.

I set a rule, NO, repeat NO live process area changes when using parent child.
there isn't ANYTHING that needs 2 second response time. (if you test and cycle changes in)

other info

note that RTC currently doesn't provide a utility to change the process parent, which is very useful when you have more than 5 children. (we had 100's) I created a utility to change the parent in 1 or more projects
see the accepted answer here

permanent link
Karthikeyan Narayanan (2625) | answered Nov 26 '14, 8:24 a.m.
Thank you for your response.

I do not see a custom value list that can be used on the consumer using the delta config syntax? Is this another limitation?

Also from the I see that the delta fragments have syntax that extends to adding new types, states, workflows etc which I believe falls under the statement “Not all of them are currently supported by the Process runtime. “ Correct?

sam detweiler commented Nov 26 '14, 8:35 a.m.

what is a 'custom value list'?

you can add new attributes for which there is a type defined in the process config.
you cannot add a new data TYPE via the delta config.
you can add an attribute that USES a custom type.

Karthikeyan Narayanan commented Nov 26 '14, 8:49 a.m.

I meant support in the consumer for "Value set provider" to be used a multi-select drop down presentation element to represent an attribute that is a stingLlist data type ?


sam detweiler commented Nov 26 '14, 9:56 a.m.

I believe you are correct.. there is no capability to configure the attributes of an attribute like in the UI

Your answer

Register or to post your answer.