What is the appropriate debug level to set in the local.properties file?

By default, Borland Connect will run with the debug level set to Low and will log any Errors, Warnings and Update messages. This is the appropriate log level for running in standard mode. Running Borland Connect at a higher debug level is only recommended at the suggestion of Borland Technical Support.

What StarTeam Item Types can be synchronized using Borland Connect?

You can create a DataSource Type for synchronization of any of the core StarTeam Item Types (Change Request, Task, Topic, Requirement, Story, Sprint) as well as any Custom Item Type created on the Server.

What StarTeam Property Type values can be synchronized using Borland Connect?

Borland Connect supports the following Property Type values in the PropertyMap: Boolean, Multi-value Enumeration, Single-value Enumeration, Date, DateTime, TimeSpan, User, Content, Text,  Integer, and Double.

Once an Item has been synchronized into the StarTeam Server, what capabilities are available on it?

All of the StarTeam change management capabilities are available on the synchronized item, including versioning, branching, linking, workflow and process enforcement, DataMart reporting, labeling and merging.

Do I need to specify all of the Properties of the Type in the configuration PropertyMap?

No, you only need to specify the properties that you wish Borland Connect to synchronize. Any properties not named in the PropertyMap will be ignored.

How can a one-way synchronization be configured?

To configure a one-way synchronization, set the 'readOnly' value of a DataSource Type to true. This will prevent Borland Connect from making any changes to the item of that Type in the DataSource and thus result in 1 way synchronization.

I don't see a sample connector available for my repository, what can I do?

See How to Build a Borland Connector on the Borland Community for creating a connector for your repository.

Can I update the sample connector to customize its behavior for my environment?

The sample connectors have been created to handle standard configurations and allow for some customization within the Connect.xml definition. However, the source code of the samples is provided if any further customization is required.

How are users matched up between the source and target repositories?

When a synchronized property contains a user value, the user's full name will be passed for comparison between the repositories. If the full name does not have a match in the target repository then the value will not be set and a warning message will be published to the log stating that the matching user could not be found.

Where can I find the default values for Connect.xml?

Connect.xml.sample provides an example configuration as well as documentation on the required and optional attributes with default values.

Where can I find the StarTeam property names to specify in the Connect.xml?

The Connect.xml.sample that is installed with Borland Connect provides examples of the default property names required to create a StarTeam DataSource. Additionally, you can use the stcmd describe command or Cross-Platform Client's Customize Dialog to see all the property information available in your StarTeam repository.

Are the XML elements specified in Connect.xml case sensitive?

Yes, the elements specified in Connect.xml are case sensitive. See Connect.xml.sample and ConnectConfig.xsd for further documentation on the supported xml formatting.

I've updated the Connect.xml file stored in the Borland Connect install directory, do I need to restart Borland Connect to pick up these changes?

Yes, Borland Connect needs to be restarted to pick up changes to the local configuration file. If the local.properties specify a Connect.xml that is checked into the StarTeam Server, then Borland Connect will pick up changes during runtime when they are committed to the file.

I've only specified the linkMap property for one type of Synchronization. Will Deletes occur in both directions?

No, Borland Connect will only synchronize a delete action if the linkMap value is being stored in the ‘other’ repository. For example, if the delete occurs in the target then the linkMap must be stored in the source. If the linkMap value is not stored in the 'other' repository then the deleted item will be recreated if the Type calls for new items to be created. To avoid deletes from not being synchronized in all instances, it is recommended to specify a linkMap on both the source and target.

How can I specify the Hours Worked and Hours Remaining for a StarTeam Task in the Property Map since they are stored in the StarTeam Server as Work Records?

Use the property names “HoursWorked” and “HoursRemaining” in the PropertyMap definition, respectively, to specify the StarTeam Task’s Hour Worked and Hours Remaining. See Connect.xml.sample for an example of mapping these Task properties.

I see warnings and errors in the Borland Connect log files indicating that item updates were not successful due to specific repository constraints. What can I do to bypass these conditions?
Not all repositories support the same validation standards and thus data stored in one repository may not be pushed into the other repository. An example of this condition is when the data limit of a text field in the source repository is smaller than the limit in the target repository. When Borland Connect tries to update the item with the invalid data, it will log the error from the repository and continue with other item updates. Following are some suggested options for avoiding these conditions:

1. Map properties of similar data storage size between the repositories (for instance, Text Fields that can store the same amount of characters). This is the most common and suggested best practice with Borland Connect.
2. Update the connector implementation to ignore the invalid data in SyncItem.getValue and SyncItem.setValue. This will allow the update to succeed without including the invalid property value(s).
3. Update the connector implementation to truncate the data in SyncItem.getValue and SyncItem.setValue so that the data in both repositories matches the smallest size limit.