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.