Wednesday, July 27, 2011

Influencing the Interaction Center with IC Events

In recent posts, I described how you can influence the working of the interaction center. For instance, using IDI, you can influence the screenflow and raise alerts.

IDI actually uses a function in the interaction center called IC events (Interaction Center Events).

The events are raised when certain situations occur, for instance ‘Businesspartner confirmed’ or Contact Ended’.

There are two ways you can influence the working of the IC webclient using IC Events with ABAP coding.
  • Raise an event.
  • Subscribe to an event.
Of course, it is not recommended to raise a standard SAP event in coding unless you are perfectly positive this is what you need, as you are bound to run into unwanted side effects (imagine raising the contact ended event while this is not the case).

You can of course very well combine the two. Raise a custom event which you have subscribed your custom event handler to.

If you want to determine which events are raised in which order at which time, you can put a breakpoint in CL_CRM_IC_EVENT_SRV->IF_CRM_IC_EVENT_SRV~RAISE.

This is actually a good starting point to explain how this works.

In this method, a lookup is done in the event subscriptions table, and all classes that have subscribed to the specified event will be processed subsequently.

For every subscribed class, the method handle_event is called. The event itself is passed to the method, including the parameters that have been added in the calling class.

So basically, using IC events, you can implement extra coding on an event that is being raised in the standard system, like ‘InteractionEnded’ or ‘BPConfirmed’, or you can implement coding on a custom event that you raise somewhere else.

What should you do to subscribe?
  1. Create a Z-class in SE80
  2. In the constructor class, subscribe to the events you want your class to be raised on
  3. In the handle_event class, code your logic.
  4. Instantiate your class anywhere, as long as it is before the first time the event is raised.
Creating the z-class.
The class can be created as a public class.
Add interface IF_CRM_IC_EVENT_LISTENER to the interfaces tab.

Subscribe to events in the constructor class
You can use the following code (as an example) to subscribe to events:

CLASS cl_crm_ic_services DEFINITION LOAD.
CLASS cl_crm_ic_event_srv DEFINITION LOAD.
CLASS cl_crm_ic_interaction_manager DEFINITION LOAD.

ev_srv = cl_crm_ic_services=>get_event_srv_instance( ).

* Subscribe to 'END'
ev_srv->subscribe( event_name = cl_crm_ic_interaction_manager=>event_interaction_after_end
listener = me
prio = 10 ).

* Subscribe to 'ERMS'
event_name = cl_crm_ic_erms_event_handler=>event_erms
listener = me
prio = 10 ).

* Subscribe to 'Z_EVENT_RAISED'
event_name = ‘Z_EVENT_RAISED’ “your custom event
listener = me
prio = 10 ).

The priority allows you to place your method in front or after other methods that have been assigned to the same event.

Implement your coding in method ‘handle_event’.
You can use the following coding as an example.
Feel free to use class attributes to store data gathered during one event, and reusing them during a next event.

DATA: context_area TYPE REF TO cl_crm_ic_contextareaview_impl.

CLASS cl_crm_ic_services DEFINITION LOAD.
CLASS cl_crm_ic_event_srv DEFINITION LOAD.
CLASS cl_crm_ic_mcm_contact DEFINITION LOAD.
CLASS if_crm_ic_events_con DEFINITION LOAD.
CLASS cl_crm_ic_interaction_manager DEFINITION LOAD.

CASE event->get_name( ).
WHEN cl_crm_ic_interaction_manager=>event_interaction_after_end.
WHEN cl_crm_ic_erms_event_handler=>event_erms.
WHEN ‘Z_EVENT_RAISED’ “your custom event

Instantiate your class.
Instantiate the class using the following code.
A good place for this would be an enhanced do_init of component CRMCMP_IC_FRAME/HiddenView.

CREATE OBJECT zcrm_event_handler.

Where zcrm_event_handler is a reference to your Z-class.

What should you do to raise an event?
If you manually want to raise an event, you can use the following coding.
You can add parameters to the event using the add_param method. You can read the parameters using the get_params method. This way, you can communicate with the class you are raising.

DATA: event TYPE REF TO cl_crm_ic_event,
event_service TYPE REF TO if_crm_ic_event_srv,
lt_ev_params TYPE crmt_ic_event_params,
ls_ev_params TYPE LINE OF crmt_ic_event_params.

event->set_name( 'Z_EVENT_RAISED' ).
event->add_param( name = 'anyname' value = ‘the value’ ).
event_service = cl_crm_ic_services=>get_event_srv_instance( ).
event_service->raise( event ).

CALL METHOD event->get_params
value = lt_ev_params.

1 comment:

  1. Hi,

    Very helpful information.

    I've a question. An agent may take up some calls/chats/emails in a day.
    I would like to retrieve that data (call duration/no.of chats/calls abandoned/emails processed etc..) and prepare a report as per the company template.

    Please let me know from which tables we can get that data.

    Thank you,