It's all about the answers!

Ask a question

Where is the xml file saved for Process Configuration Source


Gary Dang (59328552) | asked Jul 17 '08, 10:27 p.m.
We would like to make some changes for Process Configuration Source file and roll out the changes to multiple RTC deployment sites. It would be nice if we change the xml file on the development instance and send the updated file to other deployment sites (instead of asking each site to open the project area and manaully change the Process Configuration Source). Is it possible? I assume Process Configuration Source is saved in a xml file or other file format. Is this right? Thanks.

5 answers



permanent link
Jakub Jurkiewicz (59632) | answered Jul 21 '08, 8:42 a.m.
I'm not 100% sure, but I guess that process configuration source is stored in the database for the particular project/team area and not in separate files.

permanent link
Gary Dang (59328552) | answered Jul 22 '08, 1:18 a.m.
Thanks. That make the customization a little bit harder. But, not too bad since we can remove everything from from the original and copy over what we have customized from the development team.

But, I would still think it would be easier and less error prone for customization if it is saved in a xml file. How do you think? Thanks.

permanent link
Jared Burns (4.5k29) | answered Jul 23 '08, 12:27 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi, Gary.

RTC has support for two kinds of import/export:
1. You can export a process template from the repository to a directory
on the filesystem and then import this template to another repository.
2. You can create a new process template from an existing project area
in the same repository.

We don't have any support for importing into an existing project area,
though. If you want to change the process configuration source of
multiple project areas to be the same, you'll currently have to
copy/paste in the project area editor.

One word of caution: I would make sure that the source you're copying
around only refers to iterations that exist in the target project areas.

Jared Burns
Jazz Process Team


gdang wrote:
Thanks. That make the customization a little bit harder. But, not
too bad since we can remove everything from from the original and
copy over what we have customized from the development team.

But, I would still think it would be easier and less error prone for
customization if it is saved in a xml file. How do you think?
Thanks.

permanent link
Yanzhuang Li (31124126) | answered Jul 25 '08, 12:29 a.m.
Thanks, Jared, for the comments. It os OK for us to manually copy/paste the changes across multiple project areas.

Could you please elaborate "...the source you're copying
around only refers to iterations that exist in the target project areas."?

Thanks.

Yan

permanent link
Kai-Uwe Maetzel (85611) | answered Jul 29 '08, 6:57 p.m.
JAZZ DEVELOPER
Process configurations can define rules so that they only apply to
specific iterations and their child iterations. If the configuration
source you copy into a project area defines rules for iterations that do
not exists, this piece of the configuration is 'dead wood'.

Although this is not an issue in itself it might lead to situations in
which you *think* that a certain process is in place but it actually is
not because the iterations the process configuration talk about do not
exist.

Kai
Jazz Process team


yanli wrote:
Thanks, Jared, for the comments. It os OK for us to manually
copy/paste the changes across multiple project areas.

Could you please elaborate "...the source you're copying
around only refers to iterations that exist in the target project
areas."?

Thanks.

Yan

Your answer


Register or to post your answer.