Proxy
As of today, SAP CRM does not feature the possibility to specifiy more than one ICI endpoint URL. As a consequence, if one component between SAP CRM and the active ICI service (in our case the CRMConnectorSAP) ceases to work properly, the SAP Agents experience a total outage of the ICI functions.
One way to resolve that problem is to manually replace the malfunctioning ICI endpoint URL to a further instance of the ICI service application. This, however, is not very convenient because there must be a person available to perform the manual switch. Furthermore, the outage may simply last too long. See image below for a visual depiction of the problem.
(*): Any reason means e.g. a network or firewall outage/blockage or the unavailability of the CRMConnectorSAP service.
Solution Architecture
A possible solution to overcome the need for a manual user interaction when switching from ICI endpoint A to endpoint B is to place a reverse proxy between the SAP CRM cluster and the various instances of the CRMConnectorSAP. Due to the overall system design of the solution, there are several points that must be taken into account when a customer wants to deploy a proxy based solution.
Reverse Proxy
A complete list of all existing proxy solutions is beyond the scope of this document. For the application covered in this document, only reverse proxies are relevant.
A reverse proxy appears to the client just like the destination server, which is often an ordinary webserver. Thus, the client does not notice that it communicates with a reverse proxy server instead of the real destination server. The image below depicts a SAP specific system with a reverse proxy between the CRM cluster and the CRMConnectorSAP instances.
The reverse proxy decides which destination server has to handle an incoming request. There are several decision algorithms available, but for the current application only two of them are taken into consideration: Load Balancing and Failover.
Reverse proxies also employ health check mechanisms that are used to determine whether a destination server is available or not (*). In a webserver (-service) environment a polling mechanism may be used by the proxy to deduce the state of any destination server (e.g. a webserver which does not respond to repeated http polls is considered unavailable).
(*): There may be proxy server implementations that implement health check mechanisms that do not rely on http polling. Those applications are not discussed in this document
Load Balancing
Assuming that the reverse proxy employs a load balancing algorithm, the proxy server decides on each incoming request which destination server should handle that request. The most common load balancing algorithm is a (weighted) round robin mechanism.
This document does not further discuss load balancing reverse proxies because it is not a feasible solution for the b+s Connects for SAP solution (see SAP Agent Presence).
Failover
When operating the reverse proxy in a (true) failover mode all requests are sent to the same destination server as long as that server is up and running. As soon as the proxy detects that the active instance is down (due to any reason), all requests are sent to the next available instance. With this approach all web session based information is automatically preserved as long as no failover occurs. After a failover procedure, all web sessions must be re-established. In the context of the CRMConnectorSAP application this means that all agents will have to log on again.
The status of the CRMConnectorSAP instances have to be monitored so that the proxy is able to determine which CRMConnectorSAP instance should receive a request from the SAP system and which not. This can be accomplished by either detecting connection failures or by using periodical heartbeats. A heartbeat solution is preferred because it ensures a prompt detection of a connection loss. For this purpose the health check page of the CRMConnectorSAP service can be queried with a HTTP GET request (refer to the Real time status information for more information about the CRMConnectorSAP health check page).
Sticky Session
The term sticky session describes the following behavior: Complex web applications likely make use of session contexts to store data that is available over the course of multiple user interactions. That data is stored in a container on the webserver (-service) and is referenced by using a unique session ID. Typically, the container for a specific session is only stored on one server/service and not shared amongst all servers/services. Thus, it could be devastating for a user session if request A is sent to server/service instance A and request B (containing other/updated data) to server/service instance B. By enabling the sticky session feature in modern reverse proxies, the proxy ensures once a server is chosen for any particular session, all subsequent requests are sent to the same server/service instance.
Reverse Proxy deployment considerations in an SAP environment
The SAP ICI interface is designed as a web service and, thus, there is no persistent client-server-connection between the SAP system and the CRMConnectorSAP service. For each request a new TCP connection is established, and each request has to be routed to the same CRMConnectorSAP service as the corresponding previous one. The image below shows an extract from the message flow between the SAP system and the CRMConnectorSAP service when an agent logs in.
During the agent’s login procedure, SAP sends at least two callback URLs (one for the user interface and one for each container interface) to the CRMConnectorSAP service. The CRMConnectorSAP service has to send the corresponding event messages back to these URLs. The SAP server which receives the events from the CRMConnectorSAP service could be located on a different host than the server which has initially sent the requests to the CRMConnectorSAP service. The web proxy has to handle the client-requests from the SAP system to the CRMConnectorSAP service only. Therefore it is not necessary to send the event messages from the CRMConnectorSAP service back to SAP servers through the proxy. The image below depicts the message sequence of a login procedure with a reverse proxy in place.
Session and User Information in ICI SOAP Messages
In the past, neither the session ID nor the user ID were part of the HTTP header of the SOAP messages that are sent from SAP CRM to the CRMConnectorSAP service. Due to that, a web proxy had to open the SOAP message to retrieve session/user information.
As of SAP CRM release 7.0, SAP Note 1640673 can be applied to the SAP system so that session and user information are inserted into the HTTP header of each SOAP message as followed:
- Additional header field
soapuser- Contains the SAP user name of the agent sending the SOAP message to the CMS
- Additional cookie
WS_SESSION_ID- Contains the server session ID of the current communication session between SAP CRM and the CMS
These headers may be used to configure the sticky session (see above) mode appropriately.
CRMConnectorSAP and Presence Information
At the moment, each CRMConnectorSAP instance acts as a standalone application that is not aware of any other running instances (at least not when it comes to agent states). Thus, an agent that is logged in on instance A must always communicate with that particular instance and cannot simply switch to another instance without losing its entire context consisting of calls, emails and chats. Furthermore, each agent that is using the SAP ICWC may query the CRMConnectorSAP for presence information about all other logged on agents. To do so, the agent sends a specific request to the CRMConnectorSAP and receives a response that contains said information for all agents that are logged in on that particular CRMConnectorSAP instance. However, that agent does not get any information about agents that are using a different CRMConnectorSAP instance because presence information is not shared between the active instances.
The design constraints described above result in the fact, that the proxy must be operated in failover mode (see chapter Load Balancing). There is, however, one exception to the rule: If the presence information of all logged on agents is not needed, a load balancing configuration with sticky session enabled will do the job too.