Update Activity status for email completed via CRM inbox

[former_member204382]

This seems to be to be a feature omission from a fully integrated CRM-BCM  (it's easier to write than SAP Contact Center) solution.

Our scenario is thus:

We are using the ERMS push, where email workitems are pushed to an advisor by BCM. However, we have introduced a standard feature to alert the user to other incomplete emails from the same email address, and to direct the user to the inbox to complete them from there.

There is currently no mechanism that I can see whereby completing a mail from the inbox can update the corresponding activity item (linked by ERMS CON_ID and workflow workitem ID) to "Handled" status. Even a hack where we in the background update the database would require a CEM restart.

Does anyone have any thoughts on this, and how would we go about suggesting this as a feature request to SAP?

[former_member187604 · Accepted solution]

Hi

Have you looked at the TMI interface of SAP Contact Center 7.0 (http://help.sap.com/contact-center70/ -> Integration Interface Documents)? It is always recommended to rather use the integration interfaces than eg. direct database hacks.

With GetTaskList you could fetch the wanted e-mails / activities and then use the UpdateTask method to update the status of certain e-mails to "Handled" or "Deleted", one by one.

You would need to consider special cases, though. For example, if an agent is already working on an item you want to update via TMI, the user / softphone UI might not be notified of the change in any way.

BR,
-Lasse

[former_member204382 · Accepted solution]

Regarding using TMI to update tasks - as the doc states that it makes changes in the same way as an email arrives, is it a correct assumption that a BCM restart is NOT required?

Reason i ask, is that we've performed occasional direct updates on the Operative database to correct email tasks that could not be updated via CRM IC. On each occasion, we've had to restart the BCM instance in order for the changes to be effected (on recommendation from SAP).

[former_member187604 · Accepted solution]

Yes, if you do the updates via the integration interfaces, it is correct to assume that no BCM restarts are required.

Will be interesting to hear how your and Dawood's solutions work out, please kindly update your results to this thread (or a linked blog).

Regards,

-Lasse-

[former_member158363 · Accepted solution]

Hi Lasse, Shamsul,

some news from the battlefield, we have made some progress:

• This scenario is apparently not supported by CRM by default (has to do nothing with SAP CCtr, just the CRM IC / ERMS actions do not have anything like this predefined.

• SAP CCtr has ActionID as primary key for the email, however, CRM makes no use of this identifier. CRM sends more data to CCtr when making the Push (requestId, procesId), which is then later used to pair the very action from CCtr with the email in CRM.

• SAP CCtr documentation for ICI is inaccurate and contains error(s) in this area (version April 2014).

• We use ICI method IciActionItem_End and it WORKS! One of the problem here is that in our version of SAP CRM (7 EhP2) the ActionID is not stored in CRM - but it is mandatory parameter for the method, so we have to store it in a Z-table.

• Here is snippet of code made by our developper that makes the email "purge" from CCtr:

DATA:
  lr_item       TYPE REF TO cl_ici_action_item,
  lv_action_id  TYPE string,
  lv_uname      TYPE string.

lv_uname = sy-uname.
CREATE OBJECT lr_item
EXPORTING
userid = 'WF-BATCH'.

cl_bcb_customizing=>get_cti_destination( ). See comment below

TRY.
CALL METHOD lr_item->if_ici_action_item~_end
EXPORTING
  action_item_id = lv_action_id. See comment below
CATCH cx_root.
ENDTRY.

Comment - here go in debug and fill CL_BCB_CUSTOMIZING=>CC_SOAP_DESTINATION with your RFC destination pointing to CCtr's VU Integrations IP (or where you have your OII component).

Comment - the lv_action_id must be filled with the ActionID, which CCtr sends back as result of push operation. You should be able to find this in transaction CRM_ICI_TRACE for user WF-BATCH.

We will make the call probably on pressing button Reserve in IC Inbox.

And I think I will write a blog about this, once finished , good idea, Lasse...

Regards,

Dawood.

[former_member187604 · Accepted solution]

Hi Dawood,

and thanks for your interesting update! Looking forward to your blog

As for any documentation errors, please create an incident to support with adequate details, or share the information otherwise, so that the docs can be reviewed and updated where necessary.

Regards,

-Lasse-

[former_member204382 · Accepted solution]

OK, it's been a while but as always, struggling for time to try out something new.

We've now enabled TMI in our development system, and I think I've figured out the basic requirements we need to fulfil. I'll also make a blog entry in due course, but here's a brief rundown of the steps we are planning to follow.

We will go with the assumption that our agents will always have a current push email item when they go to complete other emails from the same customer via the inbox. We will start this routine when the agent presses the Complete button in the Inbox, after selecting one or more email items with the status "Open".

First, we will grab the ActionItemID from the current push item's attached data - and we will fire off our first request through TMI, using  GetTaskList  and passing the actionitemid as a single parameter. We could also use GetTaskContent, but GetTaskList returns a minimal set of data that happens to respond with the data we need. In this case, we need the ResponsibleID. This will be the BCM GUID relating to the agent currenly handling the push item. We will want to use this later to update the items we will be completing, so we know who's done them - else it remains blank.

Second, we need to do some digging around to get the right ID. In Dawood's post from June, it correctly says that the Route action receives a response containing the action item ID. This action is initiated for each and every email received in CRM that we push to BCM via ERMS. So checking the ICI trace for user WF-BATCH elicits the the Route request - with the email CON_ID (referred to in the request as ProcessID) - and the corresponding response contains the all-important ActionItemID! I assume that a smart developer will be able to locate the data source of this trace - there is a table containing the data (CRM_ICI_TRACES), but i'm not sure that is too useable. Any ideas on this would be very welcome!
So, assuming that we can retrieve the action item ID for the open email in the inbox, we can then use GetTaskList again for this item - this time to retrieve the QueueID. It appears from my testing that QueueID is always required by UpdateTask.

Finally, we are ready to make a UpdateTask request. We can fill out the ID for the action item, the queue ID, the Responsible ID (which will be the same for all emails we complete per session) and we can hardcode the status as "Handled" - a string, and not a GUID

While going through all this, I was thinking we were going to have to make some kind of custom routine to fetch the actionItemID from BCM database given the ProcessID, and persist it in a custom mapping table in CRM....which would be tricky. Hopefully, the trace storage can be utilised.

kind regards,

Sham

[former_member158363 · Accepted solution]

Hi Shamsul,

good description, thanks!

We have our ICI based solution ready and it works, though we are not yet in production (it is connected with larger change release).

I do not recommend digging the ActionID from traces. The table is quite volatile, as it you can easily delete records from the CRM_ICI_TRACE transaction. Also searching substrings or XML representations is not very performance effective.

We solved this in an enhancement, where we connect workid, emailID, and CCtr ActionItemID and store it into a Z-table. We have used implicit ehnancement in class CL_ICI_SOAP_DELEGATE, local method CRM_SOAPINCL_TRANSPORT->RECEIVE_REPLY.

We have a little bit different business process, we need to make sure that the email is Handled for CCtr the very moment, whan the non-CCtr user grabs them.

The actual deletion of the email from CCtr is therefore done with use of the code I have outlined earlier - we have implemented the logic into Email Inbox Reserve button. Advantage of this approach is that it is synchronous - if the item selected by non-CCtr user would be meanwhile allocated by CCtr to and agent and accepted, the ICI END method will respond with error, which can be processed.

Regards,

Dawood.

[former_member204382]

thanks Lasse and Dawood for your helpful suggestions. We look forward to trying this out shortly, and I will update this thread with our results, for others to benefit from.

Dawood: We are using SAP Contact Center (BCM) 7.06.106 and SAP CRM 7.02 SP5

[former_member158363]

Hi Shamsul,

this is interesting issue, kind of hoped that this is supported . I am going to implement the same scenario at customer site next week, so I will know more then.

Nevertheless, I believe the right approach is to use the ICI interface, as it is logged, nicely traced, session management maintained etc.

According to documentation, there is IciActionItem_end method, which I believe can be used, with description:

Indicates that the processing of the Action Item has ended.

The only thing is that you have to supply the actionItemId parameter, which is returned by SAP CCtr in response to the method IciActionItem_route. Strange thing - according to ICI spec, the method sends no response parameters but with SAP CCtr, it actually does:

Please, which version of SAP CCtr and SAP CRM do you use?

Regards,

Dawood.

[former_member204382]

bump for any ideas on this?