Wednesday, December 29, 2010

Must-have parameters on the ITS

When using the ITS to launch transactions from CRM in the ERP system, there are a few parameters that I would recommend you check, to make the life of the users a little better.

You can choose to set the parameters in the webgui service in SICF (in the target system), or to add it as a parameter in the URL in CRMS_IC_CROSS_SYS in SAP CRM (after the ? or &).

To set the values in the SICF, change the webgui node
(/default_host/sap/bc/gui/sap/its/webgui) or create an alias for this node, and edit the GUI configuration settings in the Service Data tab.

Wednesday, December 22, 2010

Calling transactions and reports using the Transaction Launcher

From CRM, you can call functions in other applications using the transaction launcher.
When calling a transaction in SAP ECC or when calling a SAPGUI transaction in SAP CRM, you will be using the ITS. The setup of the ITS is described here.

Calling reports or transactions is done using so-called BOR-Methods. BOR stands for Business Object Repository, and is one of the first object-oriented initiatives in SAP. The business object repository contains a wide variety of objects like 'businesspartner', 'activity', 'marketingcampaign' etc. Most Business objects in the BOR start with 'BUS', followed by a number.

The Objects of the Business Object Repository can be viewed using transaction SWO1 (not to be confused with SW01). In this transaction, you can view the standard BUS Objects, and if necessary create a new one containing your own coding.

Often used objects are REPORT and TSTC (which in the ERP system has to be copied to ZTSTC because the method has to be synchronous).

Maintenance of the transaction launcher is available in the IMG under Customer Relationship Management --> UI Framework --> Technical Role Definition --> Transaction Launcher --> Configure Transaction Launcher.
The wizard will guide you through the process.
In the first screen you enter an ID. This should start with a Z or Y.
In the field Component Set, you can enter value 'ALL'.
In the second screen you enter the Description and the class name.
The class name is important. When you finish the wizard, this class will be generated using the values you entered in the wizard. The class will be saved in collection $TMP. This means the generated class will not be transported to other systems.

This screen also contains two checkboxes. 
The stateful checkbox determines whether the called screen should open in a popup or embedded in the current screen. When you set the indicator, the screen will open as a popup.
The Raise Veto checkbox determines whether a message should be raised when the user navigates away from the page. At least, that's what the helpfile wants us to believe. In practice, the popup will unfortunately always be raised when calling a BOR Object, whether the Stateful and Raise Veto checkboxes are selected or not.

Once you have finished the wizard, you can take a look at the class in SE80. The class will contain a couple of important and less important methods.

Because the class isn't transported (because it's in $TMP), you can expect that the after transporting the customizing to the QAS and PRD, the system will automatically generate the class in the target system.

I have noticed that in some cases (I believe when you have changed your launch transaction customizing), it sometimes happens that the classes are not automatically generated in the target system. Due to this, your change will not take effect.

If this happens, just manually run the wizard in the QAS (or PRD). Even though the system tells you you are not allowed to change the customizing, it will regenerate the coding, and the change will be effective. You don't need to open customizing to do this.

Wednesday, December 15, 2010

Setting up the ITS in SAP ERP and in SAP CRM

ITS stands for Internet Transaction Server, and was incorporated in SAP Netweaver as of version 04 Before that time, the ITS was a service that ran outside of SAP.

The ITS renders the SAPGUI screens online into a browser-supported format. This means that any changes that have been made in the SAPGUI screen will automatically also be available via the ITS.

The ITS is a plug-and-play service, which enables you to call your SAPGUI transactions in the webclient without building them in a web-page. This can be a very well affordable solution if you have created for instance a maintenance view or SAP query that you need to have available in the CRM Webclient. Of course it is also very usefull if you want ERP data to be visible or even maintainable for SAP CRM users without the big costs of rebuilding the functionality in BSP applications.

The downside of the tool is that the screens in the browser will not 'remember' the last entered values like the SAPGUI does, and because the screens are rendered real-time, the performance of the screens will not meet up to the performance of the SAP Webclient screens or the SAPGUI itself.

If you want to enable the ITS, you have to enable the following services in SICF of the system where you want to use the ITS.
default_host > sap > bc > gui > sap > its.

If you want to call screens from SAP CRM using the ITS, you will also need to set up the ABAP connection between the systems in SM59, maintain the logical system in BD54, map the logical system to the ABAP connection in BD97, and maintain the ITS URL in transaction CRMS_IC_CROSS_SYS.

When setting up the above, make sure the settings meet up to the following:
  • The logical system must have the same name as the ABAP connection. You won't notice during customizing, but the connection will not work if you don't.
  • Make sure the ABAP connection is one where the user logs on with the own username. This will prevent anonymous changes in the system.
  • Make sure the ABAP connection is a trusted connection. This will prevent that the user has to log on every time he calls the transaction.
  • The URL should be as follows (Note that in ERP the transaction to be called is LTXE, while in CRM it is LTX.
  • Implement logon tickets in SSO 1 and exchange server certificates in transaction SSO1 to prevent that the user has to log on when calling the ERP system.
In CRMS_IC_CROSS_SYS, enter the following, where you should change the values between the <> to the values of your system.

If you don't know the port that is used for HTTP traffic, check transaction SMICM, in the menu choose GOTO --> Services (SHIFT-F11). Note the portnumber in the HTTP value.

When calling a BOR method from SAP CRM using the ITS, the system actually calls a transaction (LTX or LTXE) in the system, which on his turn calls the BOR-method with the parameters that you have specified.

Wednesday, December 8, 2010

Automatically attach the PDF factsheet to activities

In the IMG under Customer Relationship Management-->Transactions-->Settings for Activities-->Attach Fact Sheet to Activities you can set that your PDF factsheet is automatically attached to specified activities that are created.

You can customize per business role for which activity types and in which language the factsheet should be automatically generated and attached.

This functionality is particularly useful if you have for instance Sales Managers visiting customers. If you have implemented the (enhanced) factsheet, implemented the automatic attachment on the visit activity and implemented groupware integration, the Sales Managers will have the factsheet in the appointment in their outlook. When preparing for the meeting, they will now have an offline overview of the customer data.

Note that when saving the activity, this will from now on also include building the customer factsheet. To users, it will seem as if the system is slow if the data retrieval for the factsheet takes a long time.

Wednesday, December 1, 2010

PDF Factsheet enhancements

Getting from this... To this...

If the standard fact sheet does not meet up to the business requirements for a factsheet, you can choose to create a copy of the standard and alter it in transaction smartforms.

After you have made the changes you can assign the newly created PDF factsheet as described here.

In order to create your own factsheet, go to transaction smartforms and enter smartform CRM_ACC_ACCOUNT_OVERVIEW_PRN in the form field.
Click on the copy button and create your own Z-smartform.

If you assign this Z-smartform to the business role as described here you will be able to create your own version.

Particular changes would be:
  • Changing the smartstyle. You can do some easy enhancements on the look and feel by applying a more readable font.
  • Changing the layout. The standard is not as readable as you might expect. Some information is better off without borders in the table columns.
  • Delete unnecessary columns and add proper information.
  • Add your own coding and thus your own customer-specific information. A logical addition would for instance be (part) of the long text of an activity. You might of course also add information from your ERP system by adding a remote function call in the smartform. Be aware of performance though. If you have SAP retrieve much information, you will very likely have to wait for some time when opening the PDF factsheet.
If you want more information on how to do the programming in the factsheet, feel free to leave a message or contact me directly via twitter @p_rijlaarsdam

Wednesday, November 24, 2010

PDF Factsheet customizing using CRMVC_BUIL_PRT in SM34

The account overview page in SAP CRM (component BP_HEAD/BPHEADOverview) contains a button 'PDF Factsheet'. This PDF Factsheet will only be shown if the proper customizing has been done in SM34, as described here:

Open transaction SM34 and enter view cluster CRMVC_BUIL_PRT.

Here you have to assign the form (smartform) name of the factsheet to the authorization (PFCG) role that is assigned to the business role.

If you do not do this you will not see the PDF Fact Sheet button.

The standard form is CRM_ACC_ACCOUNT_OVERVIEW_PRN and uses class CL_UIU_PRN_ACCOUNT to move data from the screen to the smartform.

If you make a copy of one of the standard entries, you will get the standard PDF Fact Sheet.

If not all components from the factsheet are interesting (very likely), you can delete them in customizing by deleting the assignment between the print object and the related objects in the SM34 --> CRMVC_BUIL_PRT.

Select the row you want to change and click on 'Related Objects'.

In t
he next screen, if you delete the component, it will no longer show up in the factsheet. So for instance if the SALES AREAS are of no interest to your users, you can delete the assignement to the component SALES_AREAS here, and the factsheet will no longer contain this information.

There is a special component in the factsheet for R/3 data. If you wish to delete this from the factsheet you can do this by deleting the data from the view column in the fact sheet customizing in SM34.

Deleting items from the assigned objects in customizing will also improve the performance of the creation of the factsheet, because retrieving the information takes time. Especially some of the the R/3 info blocks can be a menace performance-wise.

If you wish to moderate the fact sheet, check next week's the posting.

Wednesday, November 17, 2010

SAP CRM Performance: Caching of MIME components

SAP CRM is a web based application. Static components of web pages are stored locally automatically using web caching. Web caching is part of the HTTP protocol

Caching of components influences the performance of the webclient. Particularly caching of frequently viewed components such as the skins is of great influence.

There are several tools available to test the performance of a webpage like httpwatch and ieinspector. These tools tell you which components on the site are loaded from the cache and which are coming from the server.If lots of info is coming from the server, you might have to check the cache expiration settings.

Every component of a web page can have its own expiration period in client cache. The expiration period in SAP is set in transaction SE80, under the option MIME Repository.

The skins that are available in SAP CRM are stored in the folder SAP/BC/BSP/SAP/thtmlb_styles/sap_skins. If any of the skins has a expiration period of 0, this means that every refresh of the screen will involve a full refresh from the server.

Of course if you have created your own company-specific skin in SAP CRM, you will have to have your settings correct. Especially if you have chosen to have a logo image somewhere in the screen which is not very well compressed.

See also the following SAP Notes:
Note 1242585 - SAP expiration header for static HTTP objects
Note 1162605 - Network performance for CRM (IC) Webclient
Note 1162685 - SAP CRM Webclient Performance

Wednesday, November 10, 2010

SAP CRM Performance: Account Overview Filter on Transactions using BADI CRM_BP_UIU_BT

In the CRM Webclient, it is very often that the standard contact history assignment block in the account overview or in the customer fact sheet does not meet up to the requirements of the users. For instance, SAP will always select all historical contacts. This of course will take some time in case of large 'busy' accounts.

Customizing can be done to improve the performance on this assignment block, by setting a maximum number of selected activities. The selection on the database will then be 'up to n rows'. The effect of this is that the system will select the first n rows it finds.

As the crmd_order_index is sorted by guid, the outcome of the selection is not guaranteed. Most likely, the system will show the n oldest activities, and the chance that the most recent activity is shown, decreases overtime as more activities are created in the system.

Especially in a B2B environment with many contacts on large accounts, this can become a problem.

The solution is to implement your own logic in the BADI CRM_BP_UIU_BT. Here, you can delete items based on their contents. This will improve performance as after the BADI, more details will be retrieved from the system, and less data is moved to the browser.

In our example, we added coding to delete marketing-related activities from the overview, for the account manager business role, as this is of less interest for them. After reading the current profile, we used the following code to narrow the selection:

CASE lv_profile_name.
CLEAR ls_selrow.
ls_selrow-attr_name = 'PROCESS_TYPE'.
ls_selrow-sign = 'I'.
ls_selrow-option = 'NE'.
ls_selrow-low = '[PROCESS_TYPE]'.
APPEND ls_selrow TO ct_selection_param.



Wednesday, November 3, 2010

Deleting personalized views

When changing a configuration in an overview screen, there is always the risk that users have maintained their own personalized view. The change you have made, will then not be applied to these users, unless they click the button ‘reset to default’ in the personalization screen.

You can determine which users have maintained a personal view by checking table BSPC_DL_PERSSTOR. In this table, you can select the changed view, and see the users.

You can now of course email them to delete their personalized view, or you can (a littlebit more forced) just delete the entries from the table. SAP has supplied a SE38 program to delete the personalized views.

In this program, you can set for instance the component, viewname and rolekey of the personalized views to be deleted. Be aware that the program will not show you an overview of the views to be deleted, so be sure to check the table before executing the program.

Wednesday, October 27, 2010

Routing of escalated service tickets

When an agent creates a service ticket or service process which is supposed to be picked up by another department, SAP CRM supplies an escalation process. This means that SAP can determine which agent or group is supposed to be the next to take a look at the service ticket.
The service ticket escalation process is part of the Rule Policy functionality. Based on several conditions, different agents or groups can be determined to look at the service ticket.
Most common conditions would be that the status must be OPEN, and then per category a different agent or group will be determined. A common process would be as follows:
  • The customer has a question or complaint that cannot be immediately resolved
  • The agent creates a service ticket
  • The agent enters the details. One of the actions is to select the correct categorization.
  • When clicking the escalate button, the system determines the responsible group based on the selected categories.
The service ticket is now assigned to the correct department (for instance the financial department in case of dunning questions). They will pick up the service ticket from the Agent Inbox, and handle the customer's question.

The settings for the escalation routing can be done in het IC_Manager business role under Process Management --> Rule Modeler.

The rules can be implementing Rules in the ORDERROUTING node.

Wednesday, October 20, 2010

Efficient Agent Inbox Processing

In the IC Webclient, functionality is available called the Agent Inbox, formerly known as the Universal Agent Inbox (AUI).

A typical proces involving the Agent Inbox is the processing of complex customer questions that have been escalated by callcenter.

The Agent Inbox basically is a list of items to be processed. The items can be workflow Items, Activities, Emails, Service Tickets, Service Processes, etcetera.

The list is determined using a search on the database. It thus isn't an actual 'inbox' (where items are placed in a box), but a search result page.

When working on the agent inbox, you first select the parameters on which you want to search the system for the items. Users can be helped by Fast Search options, which are defined by the system administrator or the Callcenter Manager. A typical Fast Search option would be 'Open Items assigned to My Group'.

After the items are determined, the agent can process the open items.

PRO's of the agent inbox:

Dynamic inbox definition
Because you can set the search parameters you can define the inboxes so that one item can be in several boxes at the same time. For instance, an open service ticket can be in the Open Items box, as well as in the unfinished items box, where the Open Items contains only the Open items, where the unfinished items box also contains the items with status ‘In Progress’.

Single point of entry for different types of items that need attention
You will have Workflow Items, Contacts and Service Requests all in the same place.

Immediate Customer Context
When you choose to edit the item, the attached businesspartner (customer) is automatically ‘confirmed’ This means that you have all relevant information at you fingertips immediately without having to search for the data

Multiple User
Multiple users can work on the same inbox without running into locked items.

Search based on the Organisational Model
When retrieving the data from the system, you can use 'Items assigned to My Group', which retrieves all items assigned to any of the organisational groups the agent belongs to.

The Agent Inbox can prioritize based on Due Date. If you implement so that items with a higher priority or with a certain classification have an earlier Due Date, the Agent Inbox can give them priority.

Automatic Next Item Determination
You can have the Inbox determine the next available (highest priority) item automatically.

CON's of the Agent Inbox

The agent inbox does not automatically refresh
When the agent has processed an item it would be helpfull if this item would automatically be removed from the inbox. In some cases, this does not happen.
Especially if the item would be assigned to another organisational unit or if the item's status has changed, but is not closed yet.

Loading all items can take a while as technically it launches a search on the system
Depending on the size of the database, a search can take a while. You can set the maximum number of hits though, so it won't look for all of the thousand open tasks ;-). Standard number is 50, which should be sufficient.

No Automatic 'next-item-determination'. 
The screen does not automatically determine the next item to be processed, but there is button with this functionality.
No automatic return to the Inbox
When finishing an InboxItem, the system will not automatically return to the inbox, but to the search screen.

So, what to do now?
Of course, this blog would be useless if it would not give you an answer to the CON's.

The agent inbox does not automatically refresh
To tackle this issue, you can implement a refresh in the do_prepare_output.
You might expect longer runtimes as the system retrieves the data from the database every time, but in practice the search time is ok, as all info is already buffered.

  DATA: lv_index TYPE int4,
        lr_node TYPE crmt_bsp_treetable_node,
        lr_mixed_ent     TYPE REF TO   cl_bsp_wd_mixed_node,
        lr_item TYPE REF TO cl_crm_aui_entity.

  CALL METHOD super->do_prepare_output
      iv_first_time = iv_first_time.

* We want to retrieve the current data EVERY time the screen is opened, 
* to avoid showing lines that have already been processed.

  DATA: lr_controller TYPE REF TO cl_iccmp_in_bspwdcomponen_impl,
        lr_context TYPE REF TO cl_iccmp_in_bspwdcomponen_ctxt,
        lr_search TYPE REF TO cl_iccmp_in_bspwdcomponen_cn00,
        lr_collection_wrapper TYPE REF TO cl_bsp_wd_collection_wrapper,
        lr_bol_access TYPE REF TO if_bol_bo_property_access,
        lr_query_service TYPE REF TO cl_crm_aui_advquery_service,
        lr_result TYPE REF TO if_bol_bo_col.

      lr_controller ?= me->comp_controller.
      lr_context ?= lr_controller->typed_context.
      lr_search ?= lr_context->search.
      lr_collection_wrapper ?= lr_search->get_collection_wrapper( ).
      lr_bol_access = lr_collection_wrapper->get_first( ).
      lr_query_service ?= lr_bol_access.
      lr_result ?= lr_query_service->get_query_result( ).
    CATCH cx_sy_move_cast_error.
* set result to custom controller
      typed_context->items->set_collection( collection = lr_result ).
    CATCH: cx_bol_exception, cx_root.

  LOOP AT typed_context->items->node_tab INTO lr_node.
    lr_mixed_ent ?= typed_context->items->get_bo( lr_node-node_key ).
    lr_item ?= lr_mixed_ent->if_bsp_wd_ext_property_access~get_model_node( ).

  READ TABLE typed_context->items->selection_tab INTO lv_index INDEX 1.
  IF lv_index < 0. "No line selected yet.
*  if iv_first_time is not INITIAL.
    typed_context->items->refresh( ).
      CALL METHOD eh_onitemnext.
    typed_context->items->build_table( ).

Automatic Next Item Determination
This one was easy. You might have noticed that in one of the last rows of the coding above, the method 'eh_onitemnext' is called. This method determines thre next available item to be processed. Combined with the typed_context->items->build_table( ). that follows it, the table is also re-built.

No automatic return to the Inbox
In order to return to the inbox when the agent has pressed the 'end contact' button, an IDI rule can be implemented, that if the CURRENTINBOXITEM in the GDC is bound, the system should navigate to the inbox. As there is no standard attribute in the IDI concerning the CURRENTINBOXITEM from the GDC, you will have to create one as described here.
Of course, you will have to add some other coding in the fact gathering class.
You can for instance determine the processtype of the currentinboxitem (so you can make rules based on whether a serviceticket or contactlog or service order has been processed if you want to).

*get current inboxitem

      lv_string = lo_bdc->get_entity_attribute_as_string( path = '//CURRENTINBOXITEM/BTOrderHeader/PROCESS_TYPE'
                                          iv_suppress_creation = abap_true ).
      CALL METHOD me->set_fb_attr_by_id
          id    = 'INBOX_TYPE'
          value = lv_string.
    CATCH cx_root.

So basically, with a few adjustments, the inbox can be a very user-friendly and efficient tool to process the backlog of items.

If you have any other requirements concerning the agent inbox, feel free to leave a message in the comments below :-).

Wednesday, October 13, 2010

Navigation based on the IDI

Call Center Agents can be supported by automatic navigation in the interaction Center. This is especially recommended to be implemented on the events BPConfirmed and InteractionEnded.

In the rule policy you can select the logical link you want to automatically navigate to. This can for instance be the customer overview, the factsheet, the IC Inbox or even some transaction outside of SAP CRM (for instance in the ERP system) using the transaction launcher.

Together with the creation of own events as described here, this can be a powerful enhancement of the IC. The navigation to logical links can be defined based on events and conditions such as country of the customer, postal code etc.

The IDI rules as well as the navigation targets can be maintained in the IC Manager role.

Wednesday, October 6, 2010

Alerts in the header of the IC Webclient

Call Center Agents can be supported by alerts that appear in the header of the interaction Center.

SAP has implemented some alerts standard available in the system. A nice one is the FICAALERTACCOUNTWITHMANYCONTACTS. This alert counts the number of interaction records in the last 30 days, and displays this. In combination with a check on the number of calls in the last 30 days in the rule policy, this can be valuable. You can for instance implement that when the customer has more then 5 interaction records in the last month, the alert will pop up.

The Alerts can be triggered using the Intent Driven Interaction Rule policy as described here.

If you want to implement your own alert, you can do so by logging on to the CRM system using the IC_MANAGER business role and selecting Process Modeling --> Alerts. Here you can find all SAP standard Alerts and create your own.

You will notice that you have a predefined set of dynamic attributes to your disposal.

If you want to add attributes to the list, this can be done in customizing en ABAP programming.

Customizing extra attributes cen be done in the IMG in:
  • Customer Relationship Management
    • E-mail Response Management System
      • Define Repository
In the contexts, choose ICRULE and double-click Attributes in the left side of the screen.
Now add your (Z-) attribute.
Important when creating a new attribute is that you use a new 'fact gathering Service'. For instance ZFG_IC_BP to retrieve more Business Partner attributes.

Now in customizing, add the new Fact Gathering Service in

  • Customer Relationship Management
    • E-mail Response Management System
      • Service Manager
        • Define Services
The Fact Gathering Service should have a Z-class as service class, This Z-class should be a subclass of CL_CRM_SMF_ABSTRACT_SERVICE.

In this class, implement method IF_CRM_SMF_SERVICE~EXECUTE.

Add coding to retrieve information. For instance:

* Get current customer
*     bp number
      CLEAR lv_string.

      lv_string = lo_bdc->get_entity_attribute_as_string( path =
                      iv_suppress_creation = abap_true ).

    CALL METHOD me->set_fb_attr_by_id
          id    = 'BP_NUMBER'
          value = lv_string.

    CATCH cx_root.

Now last but not least, add your own fact gathering service to the service manager profile you have created (or create one and assign it to the business role) in customizing:

  • Customer Relationship Management
    • E-mail Response Management System
      • Service Manager
        • Define Service Manager Profiles
Add your own Service in the list. Make sure it is not in the end, as you want to gather the facts BEFORE calling alerts.
You will now be able to add the newly created attributes both to Alerts as well as to conditions in the IDI maintenance in the IC Manager Role.

As the fact gathering services will be called frequently when in use, stick to efficient BOL programming in fact gathering services as much as possible.

Wednesday, September 29, 2010

Intent-Driven Interactions

In complex multi-tasking call centers, it can be helpful if users are guided through the system using context based rules. In other words, it can be helpful to implement rules based on which the user is notified or navigated through the system.

You can use Intent driven interaction, also known as IDI to support users in the interaction center.

Intent driven interaction is part of the rule modeler. The Rule Modeler is a collection of rule based functionalities supporting ERMS (Email Response Management System), IDI, Case Routing, Lead & Opportunity distribution and Order Routing.

In Intent Driven Interaction, when configured correctly, the IC Manager is able to activate the following functionalities:
  • Navigate to a screen automatically
  • Trigger Alerts
  • Delete Alerts
  • Add objects to the wrap-up list
  • Confirm an account
  • Launch an interactive script
  • Raise an IC event
All of these actions are context sensitive, meaning that they can be triggered based on conditions.

For each action, you can determine which event it listens to, for which business roles it applies and what the conditions are that the situation must comply to.
So for instance, you can implement the event 'navigate' to the customer overview, when the event 'BPCONFIRMED' is raised. This directs the agent to the account overview screen when the customer is confirmed. You can also call a script if this is needed.

Other useful events are:
  • ALERTCLICKED (when the user clicks one of the alerts in the top of the screen)
  • AUI_Interact
  • BDCCurrentCustomerChanged
  • BeginInteraction
  • CategoryChanged
  • Dial
  • EndContact
  • EndInteraction
  • InteractionEnded
  • OrderSaved

Some examples of Intent Driven Interactions are the following:
  • Navigating to a screen when a businesspartner is confirmed
  • Navigating to the Agent Inbox when the interaction is ended and the last opened contact is older then one day. (this enables the one by one processing of items in the agent inbox.
  • Triggering an alert with customer details (name, phone, email) when the businesspartner is confirmed.
  • Triggering an alert stating how many times the customer has called in the last month when the businesspartner is confirmed.
You can also implement your own events using the following code:
DATA: lr_event TYPE REF TO cl_crm_ic_event.
DATA: lr_event_srv TYPE REF TO if_crm_ic_event_srv.

lr_event->set_name( value = '[your event name' ).
lr_event->add_param( name = 'source' value = 'B' ).
lr_event_srv = cl_crm_ic_services=>get_event_srv_instance( ).
lr_event_srv->raise( event = lr_event ).

Before you can subscribe to this event, you also need to add it to the Repository in the IDI customizing in the IMG under:
IMG --> Customer Relationship Management --> Interaction Center WebClient --> Additional Functions --> Intent-Driven Interactions --> Define Events in Repository

Wednesday, September 22, 2010

Adding default values to a search screen

Often, users have to search the system for objects such as customers, activities, opportunities, orders, products etc. 

In many cases, users would like to have some values defaulted when the screen opens. This article describes how you can add default values per user group.

In this example, the assignment of the values to the fields is hardcoded. You can of course make the logic more flexible by selecting information from a customizing table, and using this to add the values to the fields.

1. Determine the component and view to be changed.
In the CRM webclient navigate to the search screen to be adjusted, click in a field and press <F2>. Note the component and the viewname.
2. Enhance the component and view
First enhance the component and enhance the view. How to enhance a component and a view can be found here.
3. Redefine the method DO_INIT_CONTEXT.
Redefine the DO_INIT_CONTEXT Remember to always call the super class. How to redefine a method can be found here.
4. Do the coding
First we will be reading the name of the current profile. This enables us to have different default values per profile. After that, in the case statement, we assign default values to one or more profiles.

The trick is to first remove the fields from the screen, and after that insert them with the new values. This way, we will also add the fields if they are not customized, or if the user has deleted them from the screen himself. This also enables us to add a field more then once, resulting in OR statements in the query.
Explanation of the coding:
* First we do the data declaration

          lv_profile_name TYPE BSP_DLC_OBJECT_TYPE,
          lv_selection_parameter type ref to if_bol_bo_property_access,
          lr_qs TYPE REF TO cl_crm_bol_dquery_service,
          lv_iterator type ref to if_bol_bo_col_iterator,
          lr_col_params TYPE REF TO if_bol_bo_col,
          lv_value type string,
          lv_cnode type ref to cl_bsp_wd_context_node_asp.
* Then we read the current user profile
* Then, using the case statement we add different values 
* for different profiles. In case you would like to do 
* the more flexible solution, this is where you 
* would enter the select statement to select 
* the fields and values based on the component, 
* view and profile values.
* We do not want to do this for all profiles.
me->set_init_qs( abap_true ). "Initialise the query

     when '[PROFILE_NAME]', '[PROFILE_NAME2]', '[...ETC]'.

* We read the current information from the 
* screen as well as the query information

* check if QS already exist
lv_cnode = get_dquery_cnode( ).
lr_qs ?= lv_cnode->collection_wrapper->get_first( ).
if lr_qs is not bound.

* add empty QS in order to allow application to prefill values
    assign lv_cnode->('BASE_ENTITY_NAME') to <gs_name>.
    lr_qs = cl_crm_bol_dquery_service=>get_instance(
<gs_name> ).
    lv_cnode->collection_wrapper->add( lr_qs ).

lr_col_params = lr_qs->get_selection_params( ).

lv_selection_parameter = LR_COL_PARAMS->get_first( ).
IF lv_selection_parameter is bound.
    EH_ONCLEAR( ). "CLEAR the screen.

* Delete the fields that we will be adding from the screen to avoid doubles. 
 WHILE lv_selection_parameter is not initial.
  DATA: lv_low type ref to string,
         lv_name type ref to name_komp,
         lv_operator type ref to bapioption.

     lv_name ?= lv_selection_parameter->get_property( 'ATTR_NAME' ).
     IF lv_name->* = '[FIELDNAME1]'
     OR lv_name->* = '[FIELDNAME2]'
     OR lv_name->* = '[... etc]'.
         lr_col_params->remove( lv_selection_parameter ).
         lv_selection_parameter = LR_COL_PARAMS->get_current( ).
         lv_selection_parameter = LR_COL_PARAMS->get_next( ).

DATA: new_selection_parameter type ref to if_bol_selection_param,
         lv_index type sytabix value 1.

* Now we add fields per profile (or several profiles)

    new_selection_parameter =
    lr_qs->insert_selection_param( iv_attr_name = '[FIELDNAME1]'
    iv_sign = 'I'
    iv_option = '[EQ|NE|BT|NB|CP|NP|LT|LE|GT|GE]'
    iv_low = '[VALUE]'
    iv_index = lv_index ). add 1 to lv_index.
    new_selection_parameter =
    lr_qs->insert_selection_param( iv_attr_name = '[FIELDNAME2]'
    iv_sign = 'I'
    iv_option = '[EQ|NE|BT|NB|CP|NP|LT|LE|GT|GE]'
    iv_low = '[VALUE]'
    iv_index = lv_index ). add 1 to lv_index.

   new_selection_parameter =

* We call the super class.
call method super->DO_INIT_CONTEXT.


Additional comments
Of course, any variants on this can be implemented. For instance you can calculate a date (for instance one year back) in a search screen for activities. This way you can create a default search screen for activities created in the last year.
You can also read from the BDC. By doing so, you can add for instance the customer number of the last viewed customer into a search screen.
You can also read the username of the current user. This could be used for instance in the search employee view if users would particularly searching for their own user. This could particularly be the case for account management, where they can view their customer portfolio on their own employee screen.
If you wish to have a customizing table where you define the default values, I would recommend the following table layout:
• Component
• View
• Profile
• Fieldname
• Fieldsign
• Fieldoption
• Fieldvalue_low
• Fieldvalue_high

All fields should be part of the key of the table, as you might want to add a field more than once to a certain screen in order to get the 'OR' statement in the searchquery.
You would now be able to implement standard coding that reads the table, and then loops over the found items. First per field, you should delete them from the searchquery, then per line, add the fields including the default values.

Wednesday, September 15, 2010

How to add buttons to the IC Webclient Toolbar

In the Interaction Center, the agent usually has several buttons in the top of the screen to handle the communication channels like phone and email.

This toolbar consists of several standard deliverd buttons.

This article explains how you can add buttons which launch your own ABAP code (like navigating to a screen, calling ERP transactions, changing the status of the interaction record...)

The implementation of a new button consists of 5 steps:

 1. Creating a new button
 2. Adding the button to the profile
 3. Adding logic in the javascript that handles the buttons
 4. Subscribing to the event
 5. Implementing logic to be called when the event is raised.

1. Creating a new button
The IMG enables you to define your own toolbar buttons.

- SAP Customizing Implementation Guide
  - Customer Relationship Management
    - Interaction Center WebClient
      - Customer-Specific System Modifications
        - Define Toolbar Buttons

2. Adding the button to the profile
In the IMG you have the ability to activate or deactivate buttons in the toolbar profile.

- SAP Customizing Implementation Guide
  - Customer Relationship Management
    - Interaction Center WebClient
      - Basic Functions
        - Communication Channels
          - Define Toolbar Profiles

These new buttons can now be assigned to the toolbar profile, and thus will show up on the screen.

The idea of new buttons is to add DTMF-Tone buttons. A specified DTMF-tone would then be sent when the agent clicks on the button. We will not be discussing this now.

Let's for the example create a button called 'ZGG' and assign it to the profile.
The new button now shows up as expected.

3. Adding logic in the javascript that handles the buttons
In the BSP Workbench (BSP_WD_CMPWB), you should enhance component CRMCMP_IC_FRAME.
This component contains pages with flow logic, one of which we will be changing. This is an enhancement, so let's keep it as general as possible.

Open page header_jscripts.js, and change the logic.
A change needs to be made in function wsb_handler. This function handles all the buttons. If you take a look at it, you will notice that the buttons are handled here one by one.

After the following code:
else if( value == "Logon" )


mcmPublish( cAppEvtLogon, value, null, null ,null , null );


We will insert our own code. As this is JavaScript, bear in mind that statements are different from ABAP. For instance // is comment.
//INS If the value is Z*, raise our event Z_TOOLBAR_EVENT.

else if(value.charAt(0)=="Z"){ // lets just forward all z-buttons as events :-)
                forwardCall( cAppEventCode, "Z_TOOLBAR_EVENT", value, "", "", "", "", "", "", "", "")

So now, if a button is clicked where the technical name starts with a Z, the function forwardcall is raised with parameters Z_TOOLBAR_EVENT and the technical name of the button (in our case ZGG).
The forwardcall function will raise the event Z_TOOLBAR_EVENT, and will supply the event with the Parameter1, which is occupied with the name of the button (ZGG).
4. Subscribing to the event
Now the event is raised, still nothing really happens, because there are no subscribers yet for the event. Our new event Z_TOOLBAR_EVENT is now raised like other events like 'END_CONTACT'  or 'INTERACTION_ENDED'.
We will be subscribing to the event in component CRMCMP_IC_FRAME (we were already enhancing it).
In order to implement the subscription, we should enhance CRMCMP_IC_FRAME/HiddenView.

If the system tells you an enhancement is not possible because class CL_CRM_IC_CONTEXTAREAVIEW_CTXT is marked final, implement SAP 
Note 1142110

Now in our newly created subclass of CL_CRMCMP_I_HIDDENVIEW_IMPL, we will redefine method DO_INIT, and add the following code:


DATA: esrv TYPE REF TO if_crm_ic_event_srv.
* Subscribe to the z_toolbar_event.
esrv = cl_crm_ic_services=>get_event_srv_instance( ).
esrv->subscribe( event_name = 'Z_TOOLBAR_EVENT'
                        listener        = me ).

We have now subscribed to the event.

5. Implementing logic to be called when the event is raised.
The logic to be called when the event is raised, will be implemented in the redefinition of the IF_CRM_IC_EVENT_LISTENER~HANDLE_EVENT of our created subclass of CL_CRMCMP_I_HIDDENVIEW_IMPL.

CALL METHOD super->if_crm_ic_event_listener~handle_event
              event = event.

CHECK event->get_name( ) = 'Z_TOOLBAR_EVENT'.

CALL METHOD event->get_param
        name = 'Parameter1'
        value = lv_param.

CASE lv_param.

    WHEN 'ZGG'.
    WHEN ....


As the above class is within the IC Framework, we have the ability to read the GDC for instance, to check if (and which) businesspartner is selected, or to read the current interactionrecord.

This allows us to implement complex logic.

You can also implement navigation to a certain screen if you want.