What are the steps and pre-requisites for moving work items cross server and cross project area?
I have two RTC 3.0.1.1 installations on two separate servers with two identical project areas (based off of the same process template). Since I am decommissioning one I need to move the work items to the new server. I have explored various possibilities (DB migration, export/import functionality) but have not managed to satisfy all of my requirements.
I am currently evaluating the possibility of using the move/copy functionality to transfer work items between project areas. What are the pre-requisites/steps for doing this? I have found this link: https://jazz.net/wiki/bin/view/Main/BulkMoveWorkItemsBetweenProjectAreasInRTC3, but it is for RTC 3.0.1.3, and I was going to use the web interface for doing so (although I supposed the Eclipse client would work as well) by clicking the move/copy button and selecting the target project area.
What are the connections that I have to establish between project areas (on separate servers) under the server configuration? Once I have done this, will the move/copy functionality copy history and attachments as well?
Thank you and best regards,
Andrew
One answer
this function is not supported, nor is there any code that 'works'.
we have built a tool that does most of the work, ~95%.. there is manual touchup on almost every workitem .
we use pentaho as our base etl tool.
Comments
Hello Sam,
Thank you for the information.
Is the tool that you are referring to available for public use? If so, where can I get it?
Best regards,
Andrew
No, sorry, it is not. Just letting you know that we had to create our own as IBM is as yet unable to provide this function.
I strongly believe that IBM needs to resolve the workitem numbering across multiple servers to make this problem go away. If they moved the workitem number calculation to the jts server and called to get the next number, and the number was unique across all servers we could fix this going forward. I also think this would open up the repository to be more re-entrant..
for scalability we need to have multiple app engines over a single database, instead of complete multiple app instances with unique databases.
It is actually possible to create a work item with a specific ID, provided that it is not yet used.
If you don't you get a number automatically. In that case you need to be able to store or be able to map the numbers.
I did store the new number on the old work item and used that for multiple passes e.g. to recreate linkage between work items on another server, which requires to have all work items and you to know which ones to connect. This does not require to keep the ID on the target server.
I have prototyped that and it works pretty well actually. I am not sure if I can finish it up. I am especially not sure if I can publish that work. I will look at it. Right now it is just that I did not have the time to implement all the attribute types.
Another thing that I did not do and probably wouldn't do, because it is just too expensive is keeping the history. It t might be possible to add it to a special HTML field, but recreating every state is just too expensive and I doubt the history is really all that interesting.
well, if history is important enough to create, it will be important enough to move.
you should be able to capture the data items documenting the history and move it..
(I know, easier said than done)..
that caveat about not the workitem number not being used is the killer..