Contents

Troubleshooting the Salesforce Object Routing Server

Salesforce Object Routing Server Status Dashboard

The dashboard webpage enables you to monitor the Instance status of Salesforce object routing servers (SORS) running for different tenants. You can configure this dashboard to monitor SORS status for multiple tenants. The Heartbeat port should be the port number configured at the logon page for the SORS instance. This dashboard also displays several status messages if something goes wrong with the instance.

The dashboard features the download of the currently configured table. The location for the downloaded configuration file is the “Downloads” folder of the user account. Administrators can also upload the configuration file using the Upload Config button on the dashboard page. A green circle indicates a running and configured SORS service; a red circle indicates a stopped SORS service.

All the Salesforce queues are fetched from Salesforce and subscribe to only those queues in CIC server for getting the interactions-related information.

The dashboard webpage file location is "[InstalledPath]/Dashboard/index.html".

Running behind proxy server

The service automatically detects the Windows proxy server settings configured in Windows server and send each request through proxy server. SORS instance should be restarted if proxy server configurations are changed in the Windows server.

Windows Event Logs

SORS instance will generate several Windows event logs for few scenarios related to connection success, failure and reconnection with Salesforce and IC server. Customers and PCC environment monitoring applications can use these Windows event logs. Some of the event data messages include:

Successfully connected to Primary CIC server
Logged in successfully to Salesforce
Error:503: Connecting to alternate CIC Server
Failed to connect to IC server
Re-logging to Salesforce
Subscribed successfully to Push Topic /topic/ININ_ObjectRouting
Failed to subscribe. Error Message: actual error message
Workgroup <WorkgroupName> does not exist in IC, queue will not be monitored. Refer to Workgroup_does_not_exist_in_IC_queue_will_not_be_monitored.

Event ID: 1000

level: Error

Source:sors_service

Logs

The Logs path is based on the Windows environment variable ININ_TRACE_ROOT. If ININ_TRACE_ROOT is not defined, the default path would be "[InstalledPath]/logs/sors_service-%DATE%.log". The logs are created on daily basis and older logs are removed based on elapsed days

Edge Cases

If the SORS instance process is terminated or killed, Windows automatically starts the SORS service. All the Salesforce queues are fetched from Salesforce and subscribe to only those CIC workgroups in the CIC server for getting the interactions-related information. The Salesforce Object Routing Server supports Off-Host Session Manager and Switchover environments.

When the SORS instance starts, it logs in to the CIC server and Salesforce. Then it scans the Salesforce object routing table for un-routed Salesforce case objects and processes the unrouted cases.

Email interactions stop routing

Problem

Push Notifications for the Salesforce Console do not work after deploying the Salesforce Console app in the target org or in a refreshed sandbox.

Causes

Emails stop routing after sandbox refresh because Push Notification Objects and Fields in Console configuration are not copied when deploying a Console app or when refreshing a sandbox. No notification means that the connector never hears about the new salesforce objects.

The cause of emails failure is due the removal of Push Topics. Push Notifications are part of Salesforce streaming API which helps in subscribing the ININ Object Routing Queue table to SORS.

Solution

Tip: See also the Salesforce help topic, Configure Push Notifications for a Salesforce Console in Salesforce Classic.

You can recreate the Push Topic following these steps:

From Setup, enter Apps in the Quick Find box, then select Apps.
Select the name of a Console App.
Select Select objects and fields for notifications next to Choose Push Notifications.
In the Push Notifications page, click Edit.
In the Choose objects for push notifications list, select ININ Object Routing Queues.
In the Choose fields for push notifications section, select Edit.
Add all Available Items to the Selected Items list and click OK.
In the Push Notifications page, click Save.

In the Workbench Application, click queries and select Streaming Push Topics option from the list.

In the Streaming Push Topics page, select ININ_ObjectRouting option from the Push Topic list.

To display the object Name, API Version, and Query boxes, click Details.

To delete the details, click Delete.
Click next to the user name and select the Developer Console from the list.

Select the Open Execute Anonymous Window from the Debug list.

In the Open Execute Anonymous Window, run the below script.

PushTopic pushTopic = new PushTopic();

pushTopic.Name = 'ININ_ObjectRouting';

pushTopic.Query = 'SELECT id,ObjectRouting__IsRoutingComplete__c,ObjectRouting__ItemId__c,ObjectRouting__ObjectType__c,ObjectRouting__QueueName__c,ObjectRouting__SearchableID__c,ObjectRouting__SenderEmail__c,ObjectRouting__SenderName__c,ObjectRouting__Direction__c, ObjectRouting__InteractionType__c, ObjectRouting__AdditionalAttributes__c, ObjectRouting__Skills__c FROM ObjectRouting__ININ_Object_Routing_Queue__c';

pushTopic.ApiVersion = 29.0;

pushTopic.NotifyForOperationCreate = true;

pushTopic.NotifyForOperationUpdate = true;

pushTopic.NotifyForOperationUndelete = true;

pushTopic.NotifyForOperationDelete = false;

pushTopic.NotifyForFields = 'Referenced';

insert pushTopic;

Restart the SORS.

SORS service failed to start

SORS is a node.js app written in JavaScript. The node-windows NPM module creates the Windows service (sors_service). This service creates two internal processes. The parent process is sors_service.exe (Windows Wrapper Service). This parent process starts one child process named cic-crm-middleware-email-to-case.exe (SORS Node.js application). If the service stops gracefully, then both the process are exited. (Expected outcome). But if the service is idle for long time, Windows may automatically shut down the parent service and leave the child process active.

To shut down the child process and restart SORS:

Open Task Manager and locate the cic-crm-middleware-email-to-case.exe process.
End the child process.
Restart the SORS service from services.

Workgroup <workgroupName> does not exist in IC, queue will not be monitored

When the PureConnect Workgroup Name configured in the Salesforce Interaction Routing Queue does not exist or match with the Workgroup in PureConnect CIC, this error message is seen in the SORS log and Windows Event log.

Upon getting this error, you must verify the corresponding entry in the Interaction Routing Queues table in Salesforce and update the PureConnect Workgroup Name to an existing/valid CIC workgroup name.

NOTE: The case will not be processed in the routing table for this workgroup. Refer to Unprocessed_entries_in_the_Object_Routing_table.

Unprocessed entries in the Object Routing Table

When you install Managed Package, one of the tables that gets created in the Salesforce database is called the routing table (ObjectRouting__ININ_Object_Routing_Queue__c). This table captures the direction of each case (ObjectRouting__Direction__c), the case ID (ObjectRouting__SearchableID__c), the routing status (ObjectRouting__IsRoutingComplete__c), SORS item ID (ObjectRouting__ItemId__c) and other metadata associated with that case. The routing status for a case indicates whether an interaction has been created by SORS in CIC. If the ObjectRouting__IsRoutingComplete__c flag is set to TRUE, it means that the case has been routed.

When an email arrives into Salesforce, a case gets created with a unique case ID. If the case is in one of the monitored Salesforce queues, the managed package adds an entry in the routing table by setting the ObjectRouting__IsRoutingComplete__c flag to FALSE.

The managed package alerts the SORS of the new entry in the routing table and forwards information about the case along with the CIC workgroup. Upon receiving the event, SORS subscribes to the CIC workgroup and invokes a custom handler to create the interaction in the same CIC workgroup.

If the interaction is created in the CIC workgroup, SORS receives a notification from CIC and marks the case entry is processed by updating the ObjectRouting__IsRoutingComplete__c flag to TRUE, for that particular entry in the object routing table.

Refer to how_the_salesforce_object_routing_server_works_with_salesforce.htm .

In SORS v1.1.6 and prior, the routing table may have entries that have never been routed to PureConnect for the following reasons:

PureConnect Workgroup Name configured in the Salesforce Interaction Routing Queue does not exist or match with the Workgroup in PureConnect.

Ø SORS will ignore that alert and logs error messages in the SORS log and the Windows Event log.

Ø The corresponding case entry for the case will not be processed and ObjectRouting__IsRoutingComplete__c will remain False in the Object routing table.

SORS does not receive an alert from Managed Package for the new entry

Ø The corresponding case entry will not be processed and ObjectRouting__IsRoutingComplete__c will remain FALSE in the Object routing table.

In order to manually update the unprocessed records refer to Manually_update_the_object_routing_table_using_Workbench.

Manually update the Object Routing Table using Workbench

In SORS v1.1.6 and prior versions, manual clean-up of your routing table is necessary to avoid the build-up of unrouted objects. These could be orphaned cases and SORS currently goes through these on restart.

We strongly recommend performing this activity on a regular schedule.
We recommend all objects be at least older than three days. Below is an example of a query to pull records older than January 1, 2022, and records that are not processed.

Select * from ObjectRouting__ININ_Object_Routing_Queue__c where createddate < 2022-01-01T00:00:00Z AND

ObjectRouting__IsRoutingComplete__c = false

For each row, determine whether you still need this object to be routed.

In the case of orphaned records where some records are not processed for the same Case ID.

For example, in the below picture, the routing complete flag is set to TRUE for one record and it is FALSE for the other record though both belong

to the same Salesforce case.

Records not processed due to invalid queue configured in Salesforce.

If you believe that case has been handled by an agent, update the routing flag to TRUE else leave it to FALSE. Correct the workgroup name so that

it will be processed when SORS is restarted.

For the rows which you do not want to be routed, update using workbench:

Set the ObjectRouting__IsRoutingComplete__c to TRUE so that it will be considered as processed by SORS.

Follow these steps to update the table data using the workbench:

Data Manipulation using workbench-https://www.mstsolutions.com/technical/salesforce-workbench/

For the rows you DO want to be routed, leave them alone. Restart SORS and these should route.

NOTE: We do not recommend bulk routing more than 5000 rows with a SORS restart.

Lock release here Error: Too much pending task-error message in SORS log

This error would be displayed in the SORS log. If you experience this error upon restart of SORS, it likely means that there are a significant number of unprocessed entries in the object routing table.

Whenever you observe this error, it means that SORS has reached its concurrency limit to handle the requests. Currently, this limit is set to 5000. When this limit is reached, new requests are dropped (unprocessed) until the concurrent requests fall below 5000.

Refer to Unprocessed_entries_in_the_Object_Routing_table for the next course of action to remediate this.