Hi yfedotov,
To clarify your observation:
"Social Miner seem to create new customer for every request and polluting Context Service with multiple copies of the same customer"
This could actually be an undesirable behavior due to the standard Context Service gadget loaded into Finesse. The Context Service gadget has an "auto-create" feature where it tries to create a customer if no customer is found associated with a POD. Please approach Cisco TAC and we can debug your setup and confirm if this is indeed the case.
I can confirm 100% that SocialMiner does not even have the capability to create customers in Context Service cloud.
To answer your questions:
1. How those SocialMiner description and author fields are mapped to Task Submission API parameters?
The <name/> field in the Task creation API request payload maps to SocialContact author field
The <description/> field in the Task creation API request payload maps to SocialContact description field
2. If there is existing POD, how should it be submitted to TR API for Social Miner to pick up? Guess it may be POD.ID ECC variable. Please confirm.
Say you have an existing POD (with RefURL - https://context-service.produs1.ciscoccservice.com/context/pod/v1/podId/b066c3c0-c346-11e5-b3dd-3f1450b33459), and you want to send this POD along with the task so the agents can be able to see that POD and associated Context Service data and operations.
All you need to do is construct the task creation API request payload with the following variable field:
<variable>
<name>podRefURL</name>
<value>https://context-service.produs1.ciscoccservice.com/context/pod/v1/podId/b066c3c0-c346-11e5-b3dd-3f1450b33459</value>
</variable>
When you do this, SocialMiner will skip creating a POD for this task, and just use the supplied POD RefURL, extract the POD ID into the POD.ID ECC variable while pushing the task into CCE. From this point on, everything is the same as though SocialMiner had created the POD itself.
3. Why SocialMiner populates customer email from the same author field? Isn't it supposed to contain the name of the customer?
Well, what you say makes sense. However, the task routing API spec does not have a dedicated field for customer email, so the default behavior is to just take the same author field and use it for customer email. This is so that if you need Context Service integration and intend to do a customer lookup based on email, you can do so by placing the customer email in the author field. Name is one identifier for a customer, email can also be an identifier for a customer.
We understand this is not a very neat thing - so we are fixing this in the next release of SocialMiner (post 11.6) where there will be dedicated customer "lookup fields" provided in the task API specs.
4. Is it assumed that all customers have unique names for the SocialMiner automatic POD creation to be any useful? I must be missing something. Are we supposed to put unique customer email in the name parameter of TR API? But then it would show it as name in Finesse gadget...
If you put the customer email in the task <name/> field, that will be used to lookup a customer (by email ID) in the Context Service cloud (in case one already exists). If no result is found from this lookup, then SocialMiner will anyway create a POD with this email value in the POD where the "Customer Name" field of the POD will have this email ID.
As I said, we are trying to improve this (among other things) both from the SocialMiner/Task Routing API side as well as from the Context Service gadget side in the next release.
