The correspondence between the id's and the display names is in the process specification. The ClearQuest Importer uses the same mapping infrastructure as the Bugzilla Importer. Please look at the Generate and customize the mapping file section in http://jazz.net/library/techtip/69.

What version of RTC are you using? There was a fix related to the unparseable date problem in RTC 2.0.0.1.

Lorelei

Glad to hear that it is working for you.

I am using the latest versions of CQ and RTC and I am trying to import records from a stateless record to an RTC record type. When I run the importer to generate an xml file using a query that clearly selects 100's of records in ClearQuest only one record is created in the xml file. Any ideas ? No error messages at all.

I am using the latest versions of CQ and RTC and I am trying to import records from a stateless record to an RTC record type. When I run the importer to generate an xml file using a query that clearly selects 100's of records in ClearQuest only one record is created in the xml file. Any ideas ? No error messages at all.

Oops sorry - posted in the wrong place. Please ignore.

The correspondence between the id's and the display names is in the process specification. The ClearQuest Importer uses the same mapping infrastructure as the Bugzilla Importer. Please look at the Generate and customize the mapping file section in http://jazz.net/library/techtip/69.

What version of RTC are you using? There was a fix related to the unparseable date problem in RTC 2.0.0.1.

Lorelei

We tried this State mapping in RTC 3.0. In our process configuration source the attribute is define as...
attributeDefinition id="com.ibm.team.workitem.attribute.state" name="Status" readOnly="true" type="smallString"
with state sections like this...
state group="open" icon="processattachment:/workflow/open.gif" id="s1" name="New" showResolution="false"

So our mapping xml looks like ...
attribute sourceId="State" targetId="com.ibm.team.workitem.attribute.state

with values like
value sourceId="New" targetId="1"
......

When we run the import the Status field ends up with the numeric values.
Why is that?

If it can't find a matching state value for the work item type, then it will return the numeric value.

Verify that the work item type is being set properly, then verify that the state id exists for the work item type in the process specification.

If it can't find a matching state value for the work item type, then it will return the numeric value.

Verify that the work item type is being set properly, then verify that the state id exists for the work item type in the process specification.

This is how our state mapping is currently looking for RTC v3. It's a mixture of the "short" form of the state literal, plus the long form that other typical CQ->RTC mappings would use:

<attribute sourceId="State" targetId="com.ibm.team.workitem.attribute.state">

    <value sourceId="New" targetId="1"/>

    <value sourceId="Assigned" targetId="2"/>

    <value sourceId="Fixed" targetId="3"/>

    <value sourceId="Closed" targetId="com.ibm.team.workitem.defectWorkflow.state.s7"/>

    <value sourceId="Deferred" targetId="com.ibm.team.workitem.defectWorkflow.state.s8"/>

    <value sourceId="Duplicate" targetId="com.ibm.team.workitem.defectWorkflow.state.s9"/>

    <value sourceId="ReOpened" targetId="6"/>

    <value sourceId="NeedMoreInfo" targetId="com.ibm.team.workitem.defectWorkflow.state.s10"/>

</attribute>

Prior to doing this, we used all 'targetID="#"' without the preceeding 's', but Closed records would end up with '7' in the state field. At least now they show up as Closed.

Can anyone verify if this is the correct way the mapping should look in RTC v3?

This custom data mapping is really turning out to be quite cumbersome for our conversion from CQ to RTC. There seems to be a lot of "trial and error" with the tool to figure out how to get it to work, at least in our experience. In addition, you have to manually enter the values from CQ along with the literal string identifiers from RTC in order to get them know about each other. It would be really nice to see this task converted into some sort of a mapping wizard or something that you can drag-n-drop values for. CQ won't let you copy-n-paste values from the Maintenance Tool, so you have to manually enter those. A mapping wizard could do a query from CQ of your schema to see which fields you would like to map. It could then populate the possible CQ values for those fields. Then the wizard could allow you to select the corresponding RTC type / attribute / value the CQ field should be mapped to and allow you to make the connections between them. The output of this would be the custom data mapping file.

Even providing better insight into what is being mapped via some sort of logging would be helpful. I can tell you that without the forums and having access to the developers, we would never have gotten as far as we have with the mapping, and we still have a ways to go!

Just a thought... :-)

Here's a couple of links with more information about the importer just in case you don't have them:

http://jazz.net/library/article/69
https://jazz.net/wiki/bin/view/Main/CQImportWizardTips
http://jazz.net/library/article/391

This mixture of state mappings seems suspicious to me. The first link that I listed above has the following info on state and resolution mappings:

State/Resolution: if the project area to import to uses a different process than the Eclipse Way, look up state and resolution ids of the workflow used for defects on the project area editor's Process Configuration Source page (search for 'com.ibm.team.workitem.configuration.workflow'). Note that for historical reasons state ids of the form 's1' and resolution ids of the form 'r3' need to be added to the mapping file without their respective 's' and 'r' prefixes.

If the state ids defined in your process specification are not of the form "s#", then use the full value of the state id as you have for the closed state mapping. Or, do you have a mixture of state id's defined in your process spec?

I agree that manually editing the mapping file can be cumbersome and error prone. We apologize for your painful experience and would like to have a front end, but haven't had time to implement that feature.

Please enter an enhancement request with what you would like to see.