Jump to: navigation, search

New/Changed Behaviors in UCS 9.1

This topic describes important changes in API behaviors between 8.5 and 9.1.

FindOrCreatePhoneCall & Insert/Update Interaction

ParentId and ThreadId are set in OMInteractions.FindOrCreatePhoneCall The algorithm (detailed below) to set the interaction ParentId and ThreadId for methods:

  • OMInteractions.InsertInteraction
  • OMInteractions.FindOrCreatePhoneCall
  • Chat.Create
If (providedThreadId==null && providedParentId==null) new_ixn.ThreadId = NEW GENERATED ID
 
If (providedThreadId!=null && providedParentId==null) new_ixn.ThreadId = providedThreadId
 
If (providedParentId!=null) { /* if ThreadId is provided as well it is ignored */
 
	if (providedParentId.exists()){
		if (providedParentId.CanBeParent==true) 
		{
			new_ixn.ThreadId = providedParent.ThreadId
                        new_ixn.ParentId = providedParent.Id
		}
		else{
			Return error:
			FaultCode=204 
			FaultString=Incorrect value for parameter 'ParentId', expected 'Parent Interaction with CanBeParent=true' but was 'Interaction '" + providedParent.Id + "' with CanBeParent:false'
		}
	}else{ 
		Return error:
		FaultCode=510 
		FaultString=Msg: Interaction 'providedParent.Id' not found in database
	}
}


OMContacts/UpdateAttributes

OMContacts/UpdateAttributes inserting an attribute specified as primary (index 0 in the request) is now successful even if there is already a primary attribute. The new attribute is set as primary and the previously primary attribute is kept as secondary. Previously (in 8.5), the request would fail.

OMContact.UpdateInteraction

Where a contact has already an email address, if you use OMContacts.UpdateInteraction to insert an address specified as primary (index 0 in the request) the request is successful. The former primary adress has IsPrimary set to false and the new email address is the primary one.

UCS 9.1 supports such a request, which in UCS 8.x was rejected.

OMInteractions.InteractionListGet

In UCS 8.5 OMInteractions.InteractionListGet and OMInteractions.GetInteractionsForContact needed the parameters EntityTypeId to search the tables EmailIn, EmailOut, Callback, Chat, PhoneCall. With no EntityTypeId only the Interaction table could be searched.

In UCS 9.1 the EntityTypeId is no longer needed. This allows queries across several media. For example a query with criteria like StartDate <= 2015-10-21T16:30:00.000Z will search matching interactions in EmailIn and EmailOut. In UCS 8.5, two requests were needed to do this.

Important
Note that it is still possible to filter data by EntityTypeId, thus keeping backward compatibility.

AddDocument method

Previously in UCS 8 there were two modes for the AddDocument method:

  • Link creation mode—The required parameters were InteractionId and DocumentId (to link an interaction to an existing document).
  • Document creation mode

In UCS 9.1, link creation mode is no longer present.

Chat.Update/Close

Important
This behavior has not changed in UCS 9.1 but was previously undocumented in UCS 8.

The following mechanism in Chat.Update and Chat.Close prevents two (or more) instances of ChatServer from updating the transcript of the same chat record simultaneously:

  • If VerifyCreatorId = true, UCS includes CreatorId in the condition to update the record.
  • If VerifyCreatorId = false UCS uses the condition without CreatorId to update the record.


Attributes in Identification Keys

If an identification key uses two or more attributes, the profile identification request must provide all these attributes. If one attribute is missing the request will fail.

Example

1. Consider the following extension schema:

{
	"name": "Subscription",
	"type": "multi-valued",
	"attributes": [
		{
			"name": "title",
			"type": "string"
		},
		{
			"name": "duration",
			"type": "integer"
		},
		{
			"name": "price",
			"type": "double"
		},
		{
			"name": "is_payed",
			"type": "boolean"
		},
		{
			"name": "new_offers",
			"type": "boolean"
		},
		{
			"name": "category",
			"type": "integer"
		}
	]
}

2. .....and the identification key built on the attributes 'category' and 'new_offers':

{
	"source": "Subscription",
	"name": "IdSubscription",
	"attributes": [
		"category",
		"new_offers"
	]
}

3. The following identification request should be successful:


GET /profiles?Subscription.category=5&Subscription.new_offers=true&id_key=IdSubscription&include_profile=yes&extensions=Subscription

4. ...but the following request should fail in UCS 9.1 whereas it works in UCS 8 (this is due to a Cassandra limitation):

GET /profiles?Subscription.category=5&id_key=IdSubscription&include_profile=yes&extensions=Subscription


5. UCS 9.0 returns the error:

Missing parameter 'Subscription.new_offers'

Note that the following request fails in both UCS 8 and UCS 9.1:

GET /profiles?Subscription.new_offers=true&id_key=IdSubscription&include_profile=yes&extensions=Subscription

TenantId Parameter Required in Search for Attributes of Type Date

UCS 9.1 now requires the TenantId parameter to search for attributes of type date.

In UCS 8 it was possible to search for attributes of type date as follows:

Service=Index
Method=Search
Parameters={
     IndexName="contact"
     Query="CreatedDate:2015*"
}

This syntax is no longer possible with UCS 9.1. The following should be used:

Service=Index
Method=Search
Parameters={
     IndexName="contact"
     Query="CreatedDate:[2015-01-01T00:00:00.000Z TO 2015-12-31T23:59:59.000Z]"
     TenantId=101
}

Searching for contact attributes of type date without the TenantId parameter will not find any result. Note that if TenantId is provided as part of the Lucene query, UCS will use it, for example:

Service=Index
Method=Search
Parameters={
     IndexName="contact"
     Query="TenantId:101 AND LCA_TimeStamp_voice:[2015-01-01T00:00:00.000Z TO 2015-12-31T23:59:59.000Z]"
}
Also, if UCS has only one tenant, this tenant will be used by default.

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on May 18, 2018, at 07:04.