Siebel CardDAV Dynamic Mapping

This chapter includes information about how to set up and enable CardDAV dynamic mapping for Siebel. It contains the following topics:

About CardDAV

CardDAV (vCard Extensions to WebDAV) is a client-server protocol designed to allow users to access and share address book or contact data on a server. CalDAV (Calendaring Extensions to WebDAV) is an internet standard designed to allow users to access and share calendar data on a remote server. By supporting both standards, users are able to view and update Siebel Business Application contact/address book data and calendar information on Apple iOS 9.x mobile devices.

Setting Up Siebel CardDAV Dynamic Mapping

Before you can use CardDAV functionality in Siebel applications, you must set up CardDAV dynamic mapping. CardDAV dynamic mapping defines the mapping between Siebel objects and the CardDAV properties. The Siebel CardDAV Sync module synchronizes the defined entities (address book and contact data) accordingly between mobile devices and Siebel CRM applications.

Siebel CardDAV dynamic mapping supports:

Google Maps Geocoding API integration (with geocoding response in JSON) to normalize address data.

Note: Customers are responsible for Google Maps API licensing.
Addresses containing non-ASCII characters.
Non-US addresses with a specified Province or County.

Before setting up CardDAV dynamic mapping for Siebel CRM deployments, the following requirements apply:

Install the latest Siebel Innovation Pack.
Configure Transport Layer Security (TLS) in Siebel Application Interface. For more information, see Siebel Security Guide.
Configure the server environment to enable CardDAV or CalDAV functionality. For more information, see Siebel Installation Guide for the operating system you are using and also Siebel System Administration Guide and additional documentation on Siebel Bookshelf for Siebel Enterprise Application Integration.
In the Siebel CRM applications, valid email addresses must be associated with all Employees and Contacts. For each mobile user, the email address defined in Siebel CRM must match the user’s email address on the mobile device. For more information, see Setting Up CalDAV and CardDAV Publishing and Siebel Applications Administration Guide.
Users of mobile devices must set up CardDAV and CalDAV publishing on their devices in order to be able to access contact or calendar data. For more information, see Setting Up CalDAV and CardDAV Publishing.
Enable CardDAV dynamic mapping between Siebel objects and CardDAV properties. For more information, see Enabling Siebel CardDAV Dynamic Mapping.
Review the remaining sections in this appendix:

Enabling Siebel CardDAV Dynamic Mapping

To set up CardDAV dynamic mapping between Siebel objects and CardDAV properties, do the following:

Make sure that the following CardDAV Workflows are activated:
- SiebDAV vCard Sync Decision Sub Process
- SiebDAV vCard Sync Process

(Required) Define System Preference to point to the CardDAV main workflow:

Name = "CardDAV Dynamic Mapping WFP"
Value = "SiebDAV vCard Sync Process"

(Optional) To enable Google Maps Geocoding API integration to normalize the address, define System Preference for Google Maps Geocoding API integration as follows:
```
Name = "Google API Key" 
Value = ""
```
For more information about Google Maps Geocoding API, see Google Maps Geocoding API Integration.

Default Supported CardDAV Clients

Siebel CardDAV dynamic mapping is supported on:

iOS 9.x mobile devices with vCard 3.0.
Third-party CardDAV clients:
- For Android, such as, Kerio Connect Sync Android client or CardDAV-Sync Android CardDAV client.
- For Outlook, such as, Outlook CalDavSynchronizer plugin (sync Outlook with Google, SOGo, or any other CalDAV or CardDAV server).
  
  Note: These are examples of CardDAV clients and are not supported by Oracle.

To override the supported CardDAV clients, add the User Properties to the CalDAV Service business service where for example:

Name = "Supported CardDAV UserAgent Prefix 2"
Value = "iOS/10"

For example:

"Supported CardDAV UserAgent Prefix 2": "iOS/10"

The prefix in the Value field must be confirmed when the version information becomes available. You must define all the supported CardDAV UserAgent prefixes here so that you override the default supported prefix.

Supported CardDAV Synchronization

The following standard vCard 3.0 properties are supported for synchronization:

Extension properties, except X-ABLabel and X_ABADR are not supported.

Unspecified properties are not supported and will not be preserved after synchronization.

Contact Properties

The following table lists the vCard 3.0 Contact properties that are supported with two-way synchronization (data upload and data download).

Table Supported v Card 3.0 Contact Properties

Contact Property	Maximum Supported Length
First Name (Required)	50
Last Name (Required)	50
Middle Name	50
Prefix	15. For more information, see About the Prefix Contact Property.
Suffix	15. For more information, see About the Suffix Contact Property.
Alias	50
Job Title	75
Note	255. Note that multiple lines of data are also supported.
Birthday	Not applicable. For more information, see About the Birthday Contact Property.

About the Prefix Contact Property

When uploading the Contact's prefix data to Siebel, the data is converted to LIC (language independent code) before saving the data in Siebel. If the data cannot be converted, then the prefix data is discarded. Invalid prefix data cannot be saved (because picklist is bounded) in Siebel.

"Bounded Pick List: PickList MrMs
"LOV Type: MR_MS

About the Suffix Contact Property

When uploading the Contact's suffix data to Siebel, the data is converted to LIC (language independent code) before saving the data in Siebel. If the data cannot be converted, then the suffix data is discarded. Invalid suffix data cannot be saved (because picklist is bounded) in Siebel.

"Bounded Pick List: FIN PickList Suffix
"LOV Type: FINS_SUFFIX_MLOV

About the Birthday Contact Property

Apple iOS supports no year-date data. Internally, iOS stores the year as 1604 for no year-date data. The earliest year-date data that Siebel supports is 1753. So when synchronizing with the iOS CardDAV client or Android CardDAV client, 1753 is used to indicate the no year-date data.

When uploading data (upload synchronization), any year-date data less than or equal to 1753 is stored in Siebel as the year 1753.
For example:
April 1, 1754 on an iOS and Android CardDAV client uploads to Siebel as 04/01/1754.
April 1, 1700 on an iOS and Android CardDAV client uploads to Siebel as 04/01/1753.
April 1 on an iOS and Android CardDAV client uploads to Siebel as 04/01/1753
When downloading data (download synchronization), the Siebel date year 1753 is converted to the year 1604, and the data shows up in the CardDAV client as follows:
- In the iOS CardDAV client as no year-date data.
- In the Android CardDAV client as date data with the year 1604.
  For example:
  04/01/1754 on Siebel downloads to the iOS and Android CardDAV client as April 1, 1754.
  04/01/1753 on Siebel downloads to the iOS CardDAV client as April 1.
  04/01/1753 on Siebel downloads to the Android CardDAV client as April 1, 1604.

Contact Company Property

The vCard 3.0 Contact Company property refers to the contact's Primary Account in Siebel, and is supported for (data download and upload) synchronization as follows:

Uploading Company data is supported only for newly created contacts. Any updates made to the Company of an existing Contact are ignored and are not uploaded (or synchronized) to the server.
The latest contact primary account data is downloaded again to the client in the subsequent synchronization.
The Contact's Department data in Siebel is not supported for synchronization.

Note the following about deleting Contact Company data:

If a user is not the primary sales team member of a contact, then that user cannot delete the contact on the server or the client. Because CardDAV client does not have the same record level access control that Siebel has, the user can still delete the contact on the client. Synchronization fails, however, during the subsequent data upload and the server (Siebel CardDAV service) returns an error code 403 in the log file. During the next synchronization, the deleted contact is re-downloaded from the server to the client.
If a user is the primary sales team member of a contact, then that user can delete the contact on the server and the client. If the contact is deleted on the client and data upload synchronization is then performed, the deleted contact will be removed from the server as well.

Type Property

The vCard 3.0 Type or Label property supports the Siebel contact's Phone, Email, URL, and Address LOV types (child components). Siebel LOV types that are not a predefined type in the iOS and Android CardDAV client are handled as follows:

When the vCard is constructed during data download synchronization, a custom label is automatically created for Siebel LOV types that are not a predefined type in the iOS and Android CardDAV client.
Custom labels are not supported for Address on the Siebel side because there is no extra schema to store the custom label data for the Siebel Address object.
Any non-Siebel LOV custom labels for Phone/Voice, Email, and URL are stored as a Personal type, and the custom label is stored in the Description field.
Use a combination of Use Type and Description to handle some iOS and Android CardDAV client predefined types/labels as follows:
- iOS CardDAV client phone's iPhone type Stored in Siebel:
  UseType="Cell" and Description="type=IPHONE"
- iOS CardDAV client email's iCloud type Stored in Siebel:
  UseType="Personal" and Description="iCloud"
- iOS CardDAV client URL's homepage type Stored in Siebel:
  UseType="Personal" and Description="_$!<HomePage>!$_"
- Android CardDAV client phone's Company Main type Stored in Siebel:
  UseType="Personal" and Description="Company Main"
If PhoneNumber, FaxNumber, EmailAddress, or URL data is not specified, then those entries are ignored and the information is discarded during upload synchronization to Siebel.

Type Property: Phone

The vCard 3.0 Type property supports the Siebel contact's Phone LOV type (child component) as follows:

The VOICE and FAX Type property is supported.
The Phone Number property is supported.
The iOS-specific iPhone type is supported.
Alphanumeric phone and fax numbers are supported.
Custom labels for the TEL/VOICE type sent from the client are supported.
If the custom label is not a Siebel Type entry, then the type is stored as Personal in Siebel and the custom label is stored in the Description field.
Both iOS and Android CardDAV clients do not support the custom label for the Phone/Fax type.
If a Siebel user creates a fax number with a non-default type in Siebel (for example: Personal, Campus, or Dormitory), it becomes other fax type/label in the iOS and Android CardDAV client after synchronization. Eventually on the Siebel side, the Phone/Fax type is updated to other fax type implicitly.
The Primary entry is handled as follows when synchronizing Siebel Phone/Fax data to the CardDAV client:
- In the CardDAV/vCard client, there is only one TEL with type=pref entry (primary). In Siebel, TEL is split into Phone and Fax child components and each one has its own primary record.
- When data comes from the CardDAV client into Siebel, the type=pref (VOICE or FAX) entry is honored as the primary in Siebel. The first non pref of another type is assigned as the Primary in Siebel.
- When data is returned back to the CardDAV client, determining which Phone or Fax's primary entry is the original primary (type=pref entry) on the CardDAV client-side is difficult. Currently, the Phone's primary is chosen as the TEL's type=pref entry - however, this might unexpectedly change the user's setting.
Updating a contact's Work Phone, Home Phone #, Cell Phone #, and Main Fax # is supported during CardDAV download synchronization, provided those numbers do not exist in the child Phone or Fax entries.

Download Synchronization

The supported behavior for download synchronization is as follows:

The child Phone/Fax's existing primary entry based on the Contact's phone number will not be altered.
The child Phone or Fax number will automatically be created in the CardDAV client (vCard) with the appropriate type only if no such number entry exists in the child Phone or Fax. If a child Phone or Fax number exists but the type is different, then another child Phone or Fax number will not be created.
- Create a phone entry with label as work (iOS) or Work (Android) on client based on Contact's Work Phone #
  vCard: TEL;type=WORK;type=VOICE
- Create a phone entry with label as home (iOS) or Home (Android) on client based on Contact's Home Phone #
  vCard: TEL;type=HOME;type=VOICE
- Create a phone entry with label as mobile (iOS) or Mobile (Android) on client based on Contact's Cell Phone #
  vCard: TEL;type=CELL;type=VOICE
- Create a fax entry with label as work fax (iOS) or Work Fax (Android) on client based on Contact's Main Fax #
  vCard: TEL;type=WORK;type=FAX
  
  Note: Users will not be able to remove all phone entries from the CardDAV client if the server-side contact has at least one single value for Work Phone #, Home Phone #, Cell Phone #, and Main Fax #. The subsequent synchronization recreates the child phone entry based on the contact's single value phone/fax number.

Upload Synchronization

The supported behavior for upload synchronization is as follows:

The Work Phone #, Home Phone #, Cell Phone #, and Main Fax # for contacts will be updated on the server only for newly created contacts.
If a user updates an existing contact, the server-side Work Phone #, Home Phone #, Cell Phone # and Main Fax # data for the contact will not be modified.

Type Property: Email

The vCard 3.0 Type property supports the Siebel contact's Email LOV type (child component) as follows:

The Mail Type property is supported (maximum supported length is 100).
The Email Address property is supported (maximum supported length is 100).
The iOS-specific iCloud email type is supported.
Custom labels sent from the client are supported.
If the custom label is not a Siebel Type entry, then the type is stored as Personal in Siebel and the custom label is stored in the Description field.
Updating a contact's single value Email Address property is supported.

Download Synchronization

The supported behavior for download synchronization is as follows:

The child Email's existing primary entry based on the Contact's phone number will not be altered.
The child Email entry will automatically be created in the vCard with work type only if no such email address entry exists in the child Email. If the child Email address entry exists but the type is different, then another child Email address entry will not be created.
- Create an email entry with label as work (iOS) or Work (Android) on client based on Contact's Email Address
  vCard: EMAIL;type=INTERNET;type=WORK
Note: Users will not be able to remove all emails from the CardDAV client if the server-side contact has a single value for Email Address. The subsequent synchronization recreates the child email based on the contact's single value Email Address.

Upload Synchronization

The supported behavior for upload synchronization is as follows:

The Email Address for contacts will be updated on the server only for newly created contacts.
If a user updates an existing contact, the server-side Email Address for the contact will not be modified.

Type Property: URL

The vCard 3.0 Type property supports the Siebel contact's URL LOV type (child component) as follows:

The URL Type property is supported (maximum supported length is 100).
The URL Address property is supported (maximum supported length is 100).
The primary URL is not supported (Siebel does not have the schema to support it).
The iOS-specific homepage URL type is supported.
Custom labels sent from the client are supported.
If the custom label is not a Siebel Type entry, then the type is stored as Personal in Siebel and the custom label is stored in the Description field.

Type Property: Address

The vCard 3.0 Type property supports the Siebel contact's Address LOV type as follows:

The Address LOV type supports the child components listed in the following table. Note the following about the Address property type:
- US and non US addresses are supported.
  During data upload synchronization, the iOS CardDAV client stores US address State data and non-US address Province or County data at the same Region portion of the ADR line. Siebel stores the Region data into the same appropriate State, Province, or County field.
  - US address State data is stored in the State field.
  - Ireland and United Kingdom County data is stored in the County field.
  - All other non-US address Province data is stored in the Province field whenever applicable.
  This behavior is enforced in the SiebDAV_vCardXMLToXMLDoc.xsl file.
- If the display language for the iOS device is set to non-ENU, then the iOS CardDAV Address Country name is sent (during upload synchronization) in its own localized language display.
  Because of the bounded Country picklist restriction, the localized Country name must be converted into a language independent code (LIC) before it is stored and the data saved in Siebel. All en-us Country name-to-LIC conversion codes are defined in the SiebDAVCountryNameConversion.xsl file. However, there are only some examples of non-ENU Country name to LIC conversion codes in the same xsl file. To support more non-ENU iOS display clients, the SiebDAVCountryNameConversion.xsl must be enhanced (by the customer) to include more languages.
- If the Country name is selected for an address in Siebel, then after the download synchronization, that Country name is displayed as is on the iOS CardDAV client.
- The US State data can be any text that the user enters on their device. If the US State data entered cannot be converted to the Siebel State LIC (language independent code), then it cannot be saved to the state field because the State field picklist is bounded. To prevent data loss, Siebel appends the unrecognizable US State name after the StreetAddress 2 field, and the data is separated with a comma (", ").
- If the Country name data entered (for example, Montenegro) cannot be converted to the Siebel Country LIC (language independent code), then it cannot be saved to the country field because the Country field picklist is bounded. To prevent data loss, Siebel appends the unrecognizable Country name after the StreetAddress 2 field, and the data is separated with a comma (", ").
The custom label for Address is not supported when uploading data (upload synchronization) to Siebel. Siebel does not have the extra address field to store the custom label. After uploading data, Address shows up as empty/no type in Siebel and later becomes other type in the CardDAV client after downloading data (download synchronization)

Table Type Property: Address

Contact Property	Maximum Supported Length	Comments
Address Type	30
Apartment Number	5
Street Address	200	This required field will be set to "---" if it is not specified.
Street Address 2	100
City	50	This required field will be set to "---" if it is not specified.
State	10	Bounded Pick list: PickList State LOV Type: STATE_ABBREV
Zipcode	30
County	50
Province	50
Country	30	Bounded Pick list: PickList Country LOV Type: COUNTRY

Google Maps Geocoding API Integration

Note: Customers are responsible for Google Maps API licensing.

Google Maps Geocoding API integration is supported to normalize the address. Note the following about Google Maps Geocoding API integration:

The address line, containing the "ADR" property, in the vCard is processed.
The address line, which contains none of the required Siebel fields, is validated:
- To define the required Siebel fields, use the ValidvCardAddressLine Input Argument of the Workflow Process Step: "Normalize Address".
- The default setting is ";;x;x;;;x" which indicates that the StreetAddress, City, or Country portion of the address data will be checked to see if it is empty. If any portion of the address is empty, then Google Maps Geocoding API is invoked to normalize the address data.
The address line is reconstructed based on the Google Maps Geocoding API Response and vCardAddressFormat of the "CalDAV Service" Business Service user property:
- The default setting for vCardAddressFormat is:
  ;;street_number route;locality;administrative_area_level_1;postal_code;country:long_name
- You can customize different address formats for each country. The following address format for Germany is available by default:
  vCardAddressFormat-DE
  ;;route street_number;locality;;postal_code;country:long_name
Siebel will keep the original address line unchanged if the address line data cannot be processed by Google (for example, if there is an empty response).
Google Maps Geocoding API does not always handle the following entities as expected: PO Box, Apt#, or Unit#. In some cases, this data is lost after being processed by Google.
Google Maps Geocoding API might return more than one "address_components". When this happens, all matching addresses that are returned from Google will be added to Siebel, and the address records will be cleansed later. For example, if the input address line contains only "San Jose", then the Google Maps Geocoding API might return, for example, the following matching addresses:
```
"formatted_address" : "San Jose, CA, USA",
"formatted_address" : "San Jose, NM 87565, USA",
"formatted_address" : "San Jose, IL 62682, USA",
```

For more information about Google Maps Geocoding API and how to obtain the API key, see the following:

https://developers.google.com/maps/documentation/geocoding/start
https://developers.google.com/maps/documentation/geocoding/get-api-key
https://developers.google.com/maps/documentation/geocoding/usage-limits

Type Conversion Mappings

The following topics are included in this section:

Note: Description values specified in this section do not contain the double quotes around the value

Type Conversion Mappings for Phone

The following table shows the type conversion mappings for phone.

Table Type Conversion Mappings for Phone

Siebel Phone Type LOV	CardDAV Client	Display Label	vCard TEL/VOICE Type
Home	iOS	home	TEL;type=HOME;type=VOICE
	Android	Home	TEL;type=HOME;type=VOICE
Business	iOS	work	TEL;type=WORK;type=VOICE
	Android	Work	TEL;type=WORK;type=VOICE
Other	iOS	other	TEL;type=OTHER;type=VOICE
	Android	Other	TEL, or if it is a primary at Siebel then: TEL;type=OTHER;type=VOICE;type=pref
Cell	iOS	mobile	TEL;type=CELL;type=VOICE
	Android	Mobile	TEL;type=CELL;type=VOICE
Cell with Description = "type=IPHONE"	iOS	iPhone	TEL;type=IPHONE;type=CELL;type=VOICE
	Android	Custom label as iPhone	TEL;type=IPHONE;type=CELL;type=VOICE
Main	iOS	main	TEL;type=MAIN
	Android	Main	TEL;type=MAIN, supported only for download synchronization. There is no upload synchronization support. The vCard line sent becomes Tel;Type=VOICE;TYPE=PREF, and will be converted to Other type on the server.
Pager 1	iOS	pager	TEL;type=PAGER
	Android	Pager	TEL;type=PAGER
Personal	iOS and Android	Custom label as Personal	<group>.TEL <group>.X-ABLabel:Personal
Personal with Description = "MyCustLabel"or the Android's bold predefined labels	iOS and Android	Custom label as specified in Description Example: MyCustLabel	<group>.TEL <group>.X-ABLabel: MyCustLabel
	Android	Predefined labels: Callback Car Company Main ISDN Radio Telex TTY TDD Work Mobile Work Pager Assistant MS	<group>.X-ABLabel:callback TEL;TYPE=CAR <group>.TEL;TYPE=VOICE;TYPE=WORK TEL;TYPE=ISDN <group>.X-ABLabel:radio <group>.X-ABLabel:telex <group>.X-ABLabel:TTY/TDD TEL;type=VOICE;type=CELL;type=WORK After download-synchronization from the server to the client, the Android client cannot consume this type definition. So the label becomes Other on the Android CardDav client. TEL;type=PAGER;type=WORK <group>.X-ABLabel:assistant <group>.TEL;TYPE=CELL <group>.X-ABLabel:mms
All other LOV values: Campus Dormitory Fax Pager 2 Telex Work The Work custom type has an uppercase W. Do not confuse this with the iOS's default work type (which has a lowercase w)	iOS and Android	Custom label as LovValue	<group>.TEL <group>.X-ABLabel: <LovValue>

Type Conversion Mappings for Fax

The following table shows the type conversion mappings for fax. Note the following:

The iOS and Android CardDAV clients do not support the custom label for the TEL/FAX type. You must convert Personal, Campus, and Dormitory types to the other fax type when downloading data (download synchronization) to CardDAV clients.
After the next data upload (client upload synchronization), any Siebel-side Fax entries of type Personal, Campus, or Dormitory will be updated to Other type implicitly.

Table Type Conversion Mappings for Fax

Siebel Fax Type LOV	CardDAV Client	Display Label	vCard TEL/FAX Type
Home	iOS	home fax	TEL;type=HOME;type=FAX
	Android	Home Fax	TEL;type=HOME;type=FAX
Business	iOS	work fax	TEL;type=WORK;type=FAX
	Android	Work Fax	TEL;type=WORK;type=FAX
Other	iOS	other fax	TEL;type=OTHER;type=FAX
	Android	Other Fax	TEL;type=OTHER;type=FAX
All other LOV Values Personal Campus Dormitory	iOS	other fax	TEL;type=OTHER;type=FAX
All other LOV Values Personal Campus Dormitory	Android	Other fax	TEL;type=OTHER;type=FAX

Type Conversion Mappings for Email

The following table shows the type conversion mappings for email.

Table Type Conversion Mappings for Email

Siebel Email Type LOV	CardDAV Client	Display Label	vCard EMAIL Type
Home	iOS	home	EMAIL;type=INTERNET;type=HOME
	Android	Home	EMAIL;type=INTERNET;type=HOME
Business	iOS	work	EMAIL;type=INTERNET;type=WORK
	Android	Work	EMAIL;type=INTERNET;type=WORK
Other	iOS	other	<group>.EMAIL;type=INTERNET <group.X-ABLabel:_$!<Other>!$_
	Android	Other	EMAIL;type=INTERNET
Personal	iOS and Android	Custom label as Personal	<group>.EMAIL;type=INTERNET <group>.X-ABLabel:Personal
Personal with Description "MyCustLabel"	iOS and Android	Custom label as specified in Description Example: MyCustLabel	<group>.EMAIL;type=INTERNET <group>.X-ABLabel: MyCustLabel
All other LOV Values Campus Dormitory	iOS and Android	Custom label as LovValue	<group>.EMAIL;type=INTERNET <group>.X-ABLabel:<LovValue>

Type Conversion Mappings for URL

The following table shows the type conversion mappings for URL.

Table Type Conversion Mappings for URL

Siebel URL Type LOV	CardDAV Client	Display Label	vCard URL Type
Home	iOS	home	URL;type=HOME
	Android	Home	URL;type=HOME
Business	iOS	work	URL;type=WORK
	Android	Work	URL;type=WORK
Other	iOS	other	<group>.URL <group.X-ABLabel:_$!<Other>!$_
	Android	Other	URL;type=OTHER
Personal	iOS and Android	Custom label as Personal	<group>.URL <group>.X-ABLabel:Personal
Personal with Description "MyCustLabel"	iOS and Android	Custom label as specified in Description Example: MyCustLabel	<group>.URL <group>.X-ABLabel: MyCustLabel
All other LOV Values Campus Dormitory	iOS and Android	Custom label as LovValue	<group>.URL <group>.X-ABLabel: <LovValue>

Type Conversion Mappings for Address

The following table shows the type conversion mappings for address. Note the following:

Siebel contact Address types (Mailing Address and Business) not in the CardDAV's default types become the custom label automatically after data download synchronization to the CardDAV client.
An empty address type in Siebel becomes other type in the CardDAV client after data download.
The Siebel contact Address does not have an additional field to hold a custom label. As a result, the ADR entry with custom label will become empty (no value) Address type in Siebel. And the custom label defined in the CardDAV client is cleared or lost after data upload synchronization to Siebel Server. Eventually after data download synchronization, all address custom labels become other type in the CardDAV client.

Table Type Conversion Mappings for Address

Siebel Address Type LOV	CardDAV Client	Display Label	vCard ADR Type
Mailing Address	iOS	home	<group>.ADR;type=HOME <group>.X-ABADR:<CountryCode>
	Android	Home	ADR;type=HOME
Business	iOS	work	<group>.ADR;type=WORK <group>.X-ABADR:<CountryCode>
	Android	Work	ADR;type=WORK
<empty, no type specified>	iOS	other	<group>.ADR;type=OTHER <group>.X-ABADR:<CountryCode>
	Android	Other	ADR
All other LOV Values Billing Service Shipping Primary Address Customer Premise Rate Center Wire Center Central Office Seasonal Temporary	iOS and Android	Custom label as LovValue	<group>.ADR <group>.X-ABLabel:LovValue iOS Only: <group>.X-ABADR:<CountryCode>

Known Limitations for Siebel CardDAV Dynamic Mapping

The known limitations for Siebel CardDAV dynamic mapping include the following:

The First Name and Last Name fields are required fields for a Contact in Siebel.
The CardDAV client data upload synchronization fails if one or both of these fields are not specified. The CardDAV client will not notify the user about the error during data upload synchronization. Users must make sure that both First Name and Last Name fields are filled in for new Contacts on the CardDAV client.
The sample code in the SiebDAV_vCardXMLToXMLDoc.xsl file defaults the First Name and Last Name field to "---" if the field is empty. Customers can enable the section of code as required
Data download synchronization is blocked until the invalid contact data (that is, the empty Last Name field) is fixed or the invalid contact is deleted.
Data upload synchronization failure occurs if an identical StreetAddress and City are entered for different countries.
The root cause of this is a duplicate key violation for the Address Name field. The Address Name field is constructed from the StreetAddress and City fields based on several calculated fields in the CUT Address business component. Customers must review the CUT Address business component to see if they need to change the construction of the Address Name field or not.
(Android only). After a data upload synchronization failure, the subsequent creation of valid contacts will result in duplicate contacts being created on the server through any future data upload synchronization.
The root cause of this is that the Android CardDAV client resends the PUT request of the same contact with a different UID. The iOS CardDAV client does not have this issue because iOS CardDAV clients resend the same contact with the same UID.
When uploading the Contact's Prefix data to Siebel, the data is converted to LIC (language independent code) before saving the data in Siebel. If the data cannot be converted, then the prefix data is discarded. Invalid prefix data cannot be saved (because picklist is bounded) in Siebel.
When uploading the Contact's Suffix data to Siebel, the data is converted to LIC (language independent code) before saving the data in Siebel. If the data cannot be converted, then the suffix data is discarded. Invalid suffix data cannot be saved (because picklist is bounded) in Siebel.
Uploading a Contacts' Company data is supported only for newly created contacts. Any updates made to the Company of an existing Contact are ignored and are not uploaded (or synchronized) to the server.
The iOS and Android CardDAV clients do not support the custom label for the Phone/Fax type. If a user creates a Fax number with a non-default type (for example: Personal, Campus, or Dormitory) in Siebel, it becomes an other fax type on the iOS and Android CardDAV client after synchronization. Eventually on the Siebel side, the type will be updated to Other type implicitly.
If PhoneNumber, FaxNumber, EmailAddress, or URL data is not specified, then those entries are ignored and the information is discarded during upload synchronization to Siebel.
US State data can be any text that the user enters on their device. If the US State data entered cannot be converted to the Siebel State LIC (language independent code), then it cannot be saved to the state field because the State field picklist is bounded. To prevent data loss, Siebel appends the unrecognizable US State name after the StreetAddress 2 field, and the data is separated with a comma (", ").
If the Country Name data entered (for example, Montenegro) cannot be converted to the Siebel Country LIC (language independent code), then it cannot be saved to the country field because the Country field picklist is bounded. To prevent data loss, Siebel appends the unrecognizable Country name after the StreetAddress 2 field, and the data is separated with a comma (", ").
For Siebel Address, Country is not a required field. If the Country field is empty after data download synchronization to the iOS client, then it will default to the current Region of the iOS device.
Using the United States region as an example, if the issue occurs for an address created on the iOS client where the Country (for example: Montenegro) data is not supported by Siebel. After data upload synchronization to Siebel, the Country field data is empty. Then after data download synchronization to the iOS CardDAV client, the Country field data is United States.
The Siebel contact Address does not have an additional field to hold a custom label. As a result, the Address entry with custom label will become an empty (no value) Address type in Siebel. And the custom label defined in the CardDAV client is cleared or lost after data upload synchronization to Siebel Server. Eventually after data download synchronization, all address custom labels become Other type in the CardDAV client.
(Android only). The Android CardDAV client does not include the display language of the device when sending requests (in the HTTP header's "Accept Language" property) to Siebel. As a result, Siebel sends back only the Address Country name in en-us display to the Android CardDAV client. This is not an issue for the iOS CardDAV client.
The Google Maps Geocoding API does not always handle PO Box. Apt#, or Unit# data as expected. In some cases, this data is lost after API processing.
The Google Maps API may return more than one address. All matching addresses returned from Google are added to Siebel. Multiple returned addresses are cleansed separately later.

Known Limitations for Outlook CardDAV Clients

Note: Oracle does not support any Outlook CardDAV clients.

Outlook CalDav Synchronizer is a CardDAV client (for more information, see https://sourceforge.net/projects/outlookcaldavsynchronizer/). The recommended synchronization profile option settings for Outlook CalDav Synchronizer are as follows:

Outlook settings. Select the following check box:
Synchronize items immediately after change
Sync settings. Set the following settings:
Synchronization Mode: Outlook <—— ——> Server (Two-Way)
Conflict Resolution: Automatic

To enable Outlook CalDav Synchronizer, define the following user properties for the CalDAV Service business service:

"Supported CardDAV UserAgent Prefix n" = "CalDavSynchronizer"
Select an appropriate number for n.
"CardDAV Put Use Actual ETag: CalDavSynchronizer" = "y"
This optional user property is required for CardDAV clients to make sure that client-side changes will not be overridden by the server data. CalDav Synchronizer must be the same as the supported prefix.

Outlook CalDAV Synchronizer Limitations

Some of the known limitations for Outlook CalDav Synchronizer CardDAV clients are as follows, consult your Outlook CardDAV client vendor for further details:

Outlook CardDAV Client uses the native Outlook Contact UI for users to update contact data. However, Outlook allows only a fixed number of Contact Emails (3), Web pages (1), Phone numbers (16 phones and 3 faxes), and Addresses (3).
Data loss occurs if more than the supported number of contact child entries are downloaded to the Outlook CardDAV client.
- Outlook contact supports only 3 Emails:
  - E-mail: maps to vCard's EMAIL WORK type, Siebel's Business type
  - E-mail 2: maps to vCard's EMAIL HOME type, Siebel's Home type
  - E-mail 3: maps to vCard's EMAIL OTHER type (no type), Siebel's Other type
  Where more than one Business, Home, or Other type Email entry is created on the server, only one entry of each type is kept for the Outlook Contact after download synchronization.
- Outlook contact supports only 1 Web page (URL)
  - Web page: maps to vCard's URL WORK type, Siebel's Business type
  Where more than one Business or Home type URL entry is created on the server, only one entry of each type is kept for the Outlook Contact after download synchronization. The Other type of URL entry is always discarded after download synchronization.
- Outlook contact supports 19 Phone numbers but only 13 of them (10 phones and 3 faxes) are uploaded to the server, 6 phone number type entries are removed from the Outlook contact.
  - Business: maps to vCard's TEL WORK type, Siebel's Business type
  - Business 2: maps to vCard's TEL WORK type, Siebel's Business type
  - Home: maps to vCard's TEL HOME type, Siebel's Home type
  - Home 2: maps to vCard's TEL HOME type, Siebel's Home type
  - Mobile: maps to vCard's TEL CELL type, Siebel's Cell type
  - Other: maps to vCard's TEL OTHER type, Siebel's Other type
  - Pager: maps to vCard's TEL PAGER type, Siebel's Pager 1 type
  - Car: maps to vCard's TEL CAR type, Siebel's Car custom label
  - ISDN: maps to vCard's TEL ISDN type, Siebel's ISDN custom label
  - Primary: maps to vCard's TEL MAIN type, Siebel's Main type
  - Business Fax: maps to vCard's TEL FAX WORK type, Siebel's Business Fax type
  - Home Fax: maps to vCard's TEL FAX HOME type, Siebel's Home Fax type
  - Other Fax: maps to vCard's TEL FAX OTHER type, Siebel's Other Fax type
  - The following 6 Outlook Contact phone number type entries are never synchronized to the server (that is, never sent out by the CardDAV client) and are lost:
    Assistant, Callback, Company, Radio, Telex, TTY/TDD type
- Outlook contact supports only 3 Addresses:
  - Business: maps to vCard's ADR WORK type, Siebel's Business type
  - Home: maps to vCard's ADR HOME type, Siebel's Home type
  - Other: maps to vCard's ADR OTHER type (no type), Siebel's Other type (empty type)
  Where more than one Business, Home, or Other type Address entry is created on the server, only one entry of each type is kept for the Outlook Contact after download synchronization.
Outlook Contact cannot display any entries with custom labels sent from the server. Custom label entries are not lost, they are returned for upload synchronization to the server.

OpenProtocols DAVClient Limitations

The OpenProtocols DAVClient (http://www.arpdev.com) has similar limitations to those described in Outlook CalDAV Synchronizer Limitations, however, note the following differences:

Data loss might occur. Unlike the CalDAVSynchronizer CardDAV client, data loss for the OpenProtocols DAVClient occurs for custom label entries after download synchronization.
Duplicate data might occur. The OpenProtocols DAVClient CardDAV client expects the vCard entries to be in a certain order (for example: Email addresses in home, work, and other order). If data is not in this order, then duplicate email addresses appear for the Outlook contact.
Duplicate contacts might appear after upload synchronization to the server. In some cases after updates are made to the contact in Outlook, the OpenProtocols DAVClient CardDAV client uploads the changes using different UIDs (sometimes the original UID.vcf is used, sometimes a totally different UID is used), and this causes the upload synchronization to create a new or duplicate contact on the server.
For example, if you create a new contact on the Outlook CardDAV client, save, and then update the home email, save, and then update the work email, the CardDAV client upload synchronization contains the following UIDs:
- Create a new contact with home and work emails: UID:f311065b-0c76-437e-9bc6-2637449c590a
- Update the home email on the original contact: UID:f311065b-0c76-437e-9bc6-2637449c590a.vcf
- Update the work email on the original contact: UID:f311065b-0c76-437e-9bc6-2637449c590a.vcf.vcf
On the server, there are 3 contacts and each contact has a different email. On the client, there are 3 contacts and two of the contacts are identical.

13Siebel CardDAV Dynamic Mapping