Synchronizing the Calendar Domain 9-5
through secondary translation or by including ICAL and custom fields in the Hub calendar definition.
If a connector opts to use the secondary-translation mechanism, you can define the custom fields in the PIM-specific XSDs and define the mappings. The custom fields
remain in the ICAL message provided by the Hub.
If a connector opts not to use the secondary-translation option, you can define a Hub data type in the Hub type library XSD, and define the custom Hub and PIM fields to
be of this type in the respective XSDs. You can then map them in the PIM-To-Hub and Hub-To-PIM XSLT files. The connectors would place custom field data outside of the
ICalBody. The data type definition must allow multiple values so that connectors can specify different custom properties and values for each exception perhaps something
similar to the HubTokens data type. With this approach, there is a danger of data loss because it would be possible for a ICAL custom field in a source connector to be
mapped to a regular ICAL field on the target connector. For more information, see
Section 9.5.2, Mapping a Custom ICAL Field to a Regular ICAL Field.
9.5 Data Side Effects Caused by Synchronizing ICAL Fields
Data loss can occur because of:
■
Failed Synchronization of Any ICAL Field
■
Mapping a Custom ICAL Field to a Regular ICAL Field
9.5.1 Failed Synchronization of Any ICAL Field
As mentioned in Section 9.2, Transforming Custom Calendar Fields,
there is the danger of data loss if any ICAL field is not synchronized. Therefore, connectors should
attempt to synchronize every ICAL field using hidden custom fields if the target calendar system does not support a given field.
If the connectors PIM Server does not support hidden custom fields, a connector implementation must devise a method to persist and retrieve the field data. Data loss
can occur even with this approach. In the case of an XSL that converts Embedded-ICAL to XML, if the XSL omits a ICAL field then data loss can occur
because the target connector does not write a value to the field. If the connector uses the secondary-translation approach, the same problem occurs if a mapping of a ICAL
field is not made. In both cases, this can be remedied by ensuring each ICAL field is mapped. A connector may appear as though a field is not synchronizing if it
synchronizes the field to a custom PIM field that the client applications do not display by default. If the connectors system does not support custom hidden fields, then the
connector must devise a method to persist the field data so it can be provided back to the Hub during extractions.
If a connector cannot translate Embedded-ICAL to XML, or opts not to do the secondary-translation method, it may not support field mapping customization and
rely on a
natural map of ICAL field names to PIM field names. In this case, there
would be no support for field definition or mapping customizations.
9.5.2 Mapping a Custom ICAL Field to a Regular ICAL Field
As noted in Section 9.4, Creating Custom Calendar Fields,
a connector that places field data outside of the ICalBody may result in an ICAL custom field in a source
connector to be mapped to a regular ICAL field on the target connector. For example, suppose the BPEL calendar has a field called HTTP Link that, when clicked, navigates
the BPEL user to a page in the BPEL application that provides information associated
