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.

Related Topic 

• "Type Conversion Mappings"

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.

Related Topic 

• "Type Conversion Mappings"

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.

Related Topic 

• "Type Conversion Mappings"

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 Table 13-2. 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 13-2 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

Related Topic 

• "Type Conversion Mappings"

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

Related Topic 

• "Type Conversion Mappings"