Wednesday, February 8, 2012

ERMS under the microscope

When implementing ERMS, part of the work is to implement a workflow called ERMS1. Another part is to implement routing rules in the IC Manager as well as set up the ERMS Service Manager. The two apparently are more interdependent than I would have thought.

Workflow Task 'Invoke ERMS service manager'

When you look at the workflow, its functionality lies in the ERMS Service Manager node (task TS00207915), where using BOR object ERMSSUPRT2, several functions are performed, like interpreting and mapping of the data from the email to the BOR container.
During this step, the ERMS Service manager is also determined and executed.
The ERMS Service Manager is actually a customizable pile of functions that can be changed in the IMG
SAP Customizing Implementation Guide --> Customer Relationship Management --> E-Mail Response Management System --> Service Manager

We have already seen how the service manager works in the blogpost about IDI. The services consist of Fact Gathering, Rule Invocation, Action Handling and Utitlities.
The standard SAP ERMS service manager profile consists of 6 services.

The SVC_PARAMS actually does nothing. 

The FG_WEBFORM is a service that is able to read an attachment called WEBFORM.XML, and maps the contents of the XML to the factbase (enabling use of the data in the rule modeler)

The UT_WORKITEMTEXT is actually a strange one (being a Utility maybe explains it), because this one updates the workitem that has been created. The workitem is yet to be assigned though.

The RE_RULE_EXEC is the rule execution service that consumes the rules as applied in the IC Manager. This service reads the rule policy and runs the rules that have been applied there, which might be for instance forwarding the email, which in its turn is actually another service, AH_ROUTE to be precise. Even though we would expect this to actually handle the routing of the email, it doesn't. It only checks if an organisational unit has been mentioned in the rule. The actual forwarding is not done here.

The AH_DEF_ROUTING actually checks if a ROUTE or ROUTETORESP etcetera has been applied in the rule modeler, and also does not really forward the email.

The UT_ERMS_REPLICAT for some reason moves the receiving email addresses from the rules to table CRMD_ERMS_RLSNPT. This thus is an easy view on the contents of the (sometimes complex) rules.

Reporting logs are also handled in the programming exit attached to the workflow task.

So, as we have seen, the steps that occur in the 'Invoke ERMS Service Manager' include fact gathering from a webform, adjusting the workitem text and executing the routing rule. Actual routing of the workitem does not take place here.

Workflow Task 'Route'
The route task is a manual step, which contains agent determination (so assignment of the workflow task to one or more agents. This determination is handled in function module CRM_ERMS_AGENT_DETERM1, and uses the in the prior steps determined organisational model from the ROUTE action in the rule modeler. Based on the determined organisational unit, all agents from the orgunit are now determined.

The task in the workflow item is actually a dummy. The method 'donothing' pretty much describes it perfectly.
So, we now have a workflow item with an attached email object assigned to all agents (users) of the determined organisational unit.
Note by the way there is also a 'rich' programming exit in the Route Workflow Task handling the Push_Email action that might have been added by the ERMS service manager.

Cool, when a user is assigned to an organisational unit and an email arrives that is mapped to the organisational unit, the workflow item will automatically be assigned to all employees of the organisational unit.
You can influence where a inbound email is assigned to in the rule modeler (use ROUTE to assign it to all users of an organisational unit, or ROUTETORESP to assign it directly to a specific user)

What if a user moves from one department to another?
What if you use ERMS in a B2C (Interaction Center) environment? 
How does the IC Inbox cope with all the workitems waiting to be processed?
What happens if I use 'My Groups' in the IC Inbox?

Let's look at that next week...