It's all about the answers!

Ask a question

CQ connector questions


Gary Dang (59328855) | asked Dec 13 '07, 5:01 p.m.
Q1. How does the sync gateway deal with the CQ UCM changeset in Jazz repository? We have the CQ web open/edit hotfix that allows the CQweb user to open the CC file from the CQ UCM changeset. How is this feature impacted when using the Jazz interface.

Q2. What is the rough effort to take the OOTB sync rules which map to the native defect record type and change it to map to other custom record types.

Q3. What are the quidelines of what custom fields to map and what not to map.

Q4. The following are use cases of using the CQ connector. Can you confirm these are supported use cases with the CQ conenctor?

Use Cases
a. Creating/updating CQ record will create corresponding work item in Jazz immediately and displayed in RTC or web client.

b. Synchronization is allowed to custom schemas

c. Administrator can easily use GUI to specific custom sync rules without a lot of manual intervention into the XML files.

d. Synchronization mapping allows mapping of any custom CQ fields and work item properties.

e. Changing the workflow state in CQ will trigger update of the work item state in Jazz or vice versa.

f. Synchronization must respect project specific security that allows the mapping of multiple projects in Jazz to one CQ database (e.g. the CQ db may have multiple projects).

g. jazz server must be backward compatible (e.g. new server shouldnt require update of the Jazz client).

h. Upgrade of Jazz repository or CQ schema should not break existing sync rules.

i. Be able to run synchronization conflict report that lists all conflicts without the need to go into individual workitem and look at the sync tab.

j. Support bi-directional create/update/delete between CQ and Jazz.

k. Support display of respective record id in CQ and Jazz

l. Jazz server supports LDAP authentication.

m. Jazz server performance and scalability. When can we expect to get this report?

3 answers



permanent link
John Vasta (2.6k15) | answered Dec 15 '07, 10:06 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
Q1. How does the sync gateway deal with the CQ UCM changeset in Jazz repository? We have the CQ web open/edit hotfix that allows the CQweb user to open the CC file from the CQ UCM changeset. How is this feature impacted when using the Jazz interface.

The CQ Connector does not support references to a UCM change set, since there is no analogous entity in Jazz to translate such references into. (The CC Connector does not synchronize individual UCM change sets, so they can't be mapped to Jazz change sets, for example.)

Q2. What is the rough effort to take the OOTB sync rules which map to the native defect record type and change it to map to other custom record types.

I don't think there is a way to characterize the mapping effort in general, since the possibilities for CQ schema design are essentially unlimited. Also, I'm not sure I'd approach it by starting with the sync rules provided for the DefectTracking schema, unless your schema looks a lot like it. If it's very different, it might be easier to just start from scratch and let the sync rule editor offer you all the choices for CQ record fields and work item properties.

Q3. What are the quidelines of what custom fields to map and what not to map.

I'm not sure what you're asking; by "custom fields", do you mean CQ record fields, or work item custom attributes? In any case, there are no general guidelines. In order to create work items from CQ record data, there must minimally be mappings that will define values for the required properties of a work item (which in part is determined by your Jazz process specification), and similarly, CQ record creation has its own required properties, depending on the design of your schema. Beyond that, you'll need to determine what additional fields and properties are mappable at all, and of those, which of them are desired to be visible in the other context.

Q4. The following are use cases of using the CQ connector. Can you confirm these are supported use cases with the CQ conenctor?

Use Cases
a. Creating/updating CQ record will create corresponding work item in Jazz immediately and displayed in RTC or web client.

Creation does not occur immediately because the CQ connector periodically polls for changes in CQ to send to Jazz. You can set the polling period, however. I'm not sure what you mean by "displayed"; work items will be created in the Jazz repository, and then become visible in queries or feeds as usual.

b. Synchronization is allowed to custom schemas

Yes, within the bounds of what kinds of CQ record fields are mappable to a work item property.

c. Administrator can easily use GUI to specific custom sync rules without a lot of manual intervention into the XML files.

You can define any attribute of a sync rule via the sync rule editor.

d. Synchronization mapping allows mapping of any custom CQ fields and work item properties.

Since the possibilities for work item properties (the built in properties, and custom attributes) are much more limited than the possibilities of CQ fields, then there certainly will be many constraints. One general constraint is that you can define any number of "auxiliary records" in a CQ schema, and references to them from your primary record type, while you can't define anything like an auxiliary record in Jazz (without creating your own Jazz component). So such auxiliary records will generally not be mappable, unless they happen to align with an existing Jazz item (for example, a work item Category item).

e. Changing the workflow state in CQ will trigger update of the work item state in Jazz or vice versa.

If you mean doing a state transition (e.g. Open->Resolved), then yes, assuming that the transition is mapped to an analogous state transition on the other side, and any process rules are satisfied, then the mapped state transition will be applied.

f. Synchronization must respect project specific security that allows the mapping of multiple projects in Jazz to one CQ database (e.g. the CQ db may have multiple projects).

If the projects used distinct sync rules (i.e. different CQ record types), then that would be true, but since sync rules belong to a project area and cannot currently be shared across project areas, then I don't think we can support what you're thinking of. If this is important to you, feel free to submit an enhancement request.

g. jazz server must be backward compatible (e.g. new server shouldnt require update of the Jazz client).

That is not the case today; clients and servers must have been built against the same service API and storage model definitions, and since those are likely to change from release to release (or even milestone build to milestone build), then clients and servers will in practice be required to be from the same build.

h. Upgrade of Jazz repository or CQ schema should not break existing sync rules.

Since the sync rules reflect the underlying schema, they certainly can become invalid if the schema changes.

i. Be able to run synchronization conflict report that lists all conflicts without the need to go into individual workitem and look at the sync tab.

Yes, you can request a list of all "unsynchronized" items, by either sync rule or project area, from the Synchronization Rules view.

j. Support bi-directional create/update/delete between CQ and Jazz.

Work items cannot be deleted since they become linked to other objects and reflect the history of a project, so CQ record deletion does not imply work item deletion, just "disconnection" from the work item.

k. Support display of respective record id in CQ and Jazz

A work item displays the connected CQ record id in its Links page, and you can also define a custom work item attribute for it. And you could map the work item id to a CQ field and add it to one of the record's forms, if the work item id was available as a mappable property. I've created that enhancement request for you:

https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/40136

l. Jazz server supports LDAP authentication.

Yes (the Jazz server relies on the authentication mechanism of the application server it is running in, e.g. Tomcat or WebSphere).

m. Jazz server performance and scalability. When can we expect to get this report?

I'm not sure what the plans are for any such reports; I suggest you start a new forum topic for it so that the appropriate folks notice and can respond.

permanent link
Gary Dang (59328855) | answered Jan 04 '08, 5:04 p.m.
Q2. What is the rough effort to take the OOTB sync rules which map to the native defect record type and change it to map to other custom record types.

I don't think there is a way to characterize the mapping effort in general, since the possibilities for CQ schema design are essentially unlimited. Also, I'm not sure I'd approach it by starting with the sync rules provided for the DefectTracking schema, unless your schema looks a lot like it. If it's very different, it might be easier to just start from scratch and let the sync rule editor offer you all the choices for CQ record fields and work item properties.

- can you point me to the documentation that explains how to use the sync rule editor?


Q4. The following are use cases of using the CQ connector. Can you confirm these are supported use cases with the CQ conenctor?

Use Cases
a. Creating/updating CQ record will create corresponding work item in Jazz immediately and displayed in RTC or web client.

Creation does not occur immediately because the CQ connector periodically polls for changes in CQ to send to Jazz. You can set the polling period, however. I'm not sure what you mean by "displayed"; work items will be created in the Jazz repository, and then become visible in queries or feeds as usual.
- ok thanks. It seems the objects get replicated in jazz when the poll triggers.

b. Synchronization is allowed to custom schemas

Yes, within the bounds of what kinds of CQ record fields are mappable to a work item property.

- is there some synchronization customization guideline?

c. Administrator can easily use GUI to specific custom sync rules without a lot of manual intervention into the XML files.

You can define any attribute of a sync rule via the sync rule editor.

- how do I launch the editor? Is this in beta2?

d. Synchronization mapping allows mapping of any custom CQ fields and work item properties.

Since the possibilities for work item properties (the built in properties, and custom attributes) are much more limited than the possibilities of CQ fields, then there certainly will be many constraints. One general constraint is that you can define any number of "auxiliary records" in a CQ schema, and references to them from your primary record type, while you can't define anything like an auxiliary record in Jazz (without creating your own Jazz component). So such auxiliary records will generally not be mappable, unless they happen to align with an existing Jazz item (for example, a work item Category item).

- We may need some help from you guys as we have complex custom record types.

e. Changing the workflow state in CQ will trigger update of the work item state in Jazz or vice versa.

If you mean doing a state transition (e.g. Open->Resolved), then yes, assuming that the transition is mapped to an analogous state transition on the other side, and any process rules are satisfied, then the mapped state transition will be applied.

- the out-of-the-box defect sync does not map the state. Can you include it in the next beta drop?

f. Synchronization must respect project specific security that allows the mapping of multiple projects in Jazz to one CQ database (e.g. the CQ db may have multiple projects).

If the projects used distinct sync rules (i.e. different CQ record types), then that would be true, but since sync rules belong to a project area and cannot currently be shared across project areas, then I don't think we can support what you're thinking of. If this is important to you, feel free to submit an enhancement request.

- this is a somewhat complicated subject. Let me see if I can explain using an example. Suppose in the CQ db, I have projectA and projectB users creating CQ records. The record has a CQ Security Context field that allows the user in projectA to flag that record using security contextA. When this record is saved, only users in projectA can view/edit this record. So, when these security context records get replicated to Jazz, what is the behavior that I should expect to see. I assume projectA and projectB records will be replicated in Jazz but could Jazz users in projectB see the projectA records or vice versa?

g. jazz server must be backward compatible (e.g. new server shouldnt require update of the Jazz client).

That is not the case today; clients and servers must have been built against the same service API and storage model definitions, and since those are likely to change from release to release (or even milestone build to milestone build), then clients and servers will in practice be required to be from the same build.

- requiring the user to upgrade the RTC client when the RTC server is upgraded is not a good thing because this is too much of an impact to potentially thousands of users. think about the Cqweb interface. when cqweb server is upgraded, I don't need to upgrade IE. I know this is apples to orange comparison but it's a pain for RTC users (potentially thousands) to upgrade their clients. Does the upgrade require re-install or just online update in Eclipse?

h. Upgrade of Jazz repository or CQ schema should not break existing sync rules.

Since the sync rules reflect the underlying schema, they certainly can become invalid if the schema changes.

- if the mapped fields are not changed, I assume no impact?

i. Be able to run synchronization conflict report that lists all conflicts without the need to go into individual workitem and look at the sync tab.

Yes, you can request a list of all "unsynchronized" items, by either sync rule or project area, from the Synchronization Rules view.

- OK

j. Support bi-directional create/update/delete between CQ and Jazz.

Work items cannot be deleted since they become linked to other objects and reflect the history of a project, so CQ record deletion does not imply work item deletion, just "disconnection" from the work item.

- OK

k. Support display of respective record id in CQ and Jazz

A work item displays the connected CQ record id in its Links page, and you can also define a custom work item attribute for it. And you could map the work item id to a CQ field and add it to one of the record's forms, if the work item id was available as a mappable property. I've created that enhancement request for you:

https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/40136

- OK thanks.

l. Jazz server supports LDAP authentication.

Yes (the Jazz server relies on the authentication mechanism of the application server it is running in, e.g. Tomcat or WebSphere).

- OK

m. Jazz server performance and scalability. When can we expect to get this report?

I'm not sure what the plans are for any such reports; I suggest you start a new forum topic for it so that the appropriate folks notice and can respond.

permanent link
John Vasta (2.6k15) | answered Jan 06 '08, 10:08 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
- can you point me to the documentation that explains how to use the sync rule editor?

In Team Concert, select Help>Help Contents, then navigate to the topic Using Rational Team Concert > Configuring and using Team Concert ClearQuest Connector > Configuring Team Concert > Creating synchronization rules

- is there some synchronization customization guideline?

No; you need to decide what information in your CQ schema is important to have in the Jazz context, and then whether it is possible to represent that information in Jazz.

- how do I launch the editor? Is this in beta2?

Yes, and the editor existed before beta2; it just has a new page added to it. The above cited help topic explains how to use it.

- We may need some help from you guys as we have complex custom record types.

We'd be happy to help.

- the out-of-the-box defect sync does not map the state. Can you include it in the next beta drop?

Yes it does; look at the mapping for the StateResolution property.

- this is a somewhat complicated subject. Let me see if I can explain using an example. Suppose in the CQ db, I have projectA and projectB users creating CQ records. The record has a CQ Security Context field that allows the user in projectA to flag that record using security contextA. When this record is saved, only users in projectA can view/edit this record. So, when these security context records get replicated to Jazz, what is the behavior that I should expect to see. I assume projectA and projectB records will be replicated in Jazz but could Jazz users in projectB see the projectA records or vice versa?

Currently in Jazz you cannot deny read access based on project area boundaries. So there is nothing to prevent a user that has read access to the repository from seeing all projects and all related artifacts.

- requiring the user to upgrade the RTC client when the RTC server is upgraded is not a good thing because this is too much of an impact to potentially thousands of users. think about the Cqweb interface. when cqweb server is upgraded, I don't need to upgrade IE. I know this is apples to orange comparison but it's a pain for RTC users (potentially thousands) to upgrade their clients. Does the upgrade require re-install or just online update in Eclipse?

I suggest you start a separate thread on this topic, since it's independent of the CQ Connector. I'm not sure what the plans are for having an Eclipse update site for RTC.

- if the mapped fields are not changed, I assume no impact?

If all the fields/properties referenced in sync rules still exist and have the same semantics, then the sync rules should still be valid.

John

Your answer


Register or to post your answer.