Image Added

Image RemovedThe following options are available:

Jobs

View the scheduled jobs that process inbound and outbound data to the Perspectium Integration Mesh. There are two job types:

MultiOutput Processing - The job that will run to process messages with a status of Ready in the Outbound Messages table and send them to the specified shared queues in the Integration Mesh.

Replicator Subscriber - The job that will consume messages from the specified subscribed queues in the Integration Mesh. The messages will be consumed and processed by the Perspectium application and saved into the Inbound Messages table in the app so you have the messages for reference.

When creating a new job, you have the following options available:

Description - A description to give the job for your reference (this isn't used). If no description is entered, the job type is used along with the datetime it will run or be aborted i.e. MultiOutput Processing Scheduled at 2024-02-08 14:24:15.036.

Job Type - The type of job as mentioned above.  NOTE: It is recommended to have only one job for each job type to avoid race conditions where the same messages are sent out twice.

Job Interval - How often the job should run.

Job Delay Interval - An interval to delay the job and try again if the maximum number of Salesforce jobs running has been exceeded and the job cannot be executed. For example, if the job tries to run and it cannot execute and you have the delay set to 5 minutes, it will try again in 5 minutes. If not set, it will try again at the job interval which may fail again if the maximum number is still exceeded. This option is a way to give Salesforce time to complete executing other jobs without continuing trying to run again.

Email User - A user to email if the job has connectivity issues connecting to the Perspectium Integration Mesh.

Email Interval - How long we should email about connectivity issues for. If the issue is ongoing until you fix it (such as bad Integration Mesh credentials), you will only be notified for the time specified here at which point it will no longer email even if the issue is still occurring.

Receipts are automatically generated in your Salesforce org for your integration. Receipts indicate the delivery status for records that have been shared from your ServiceNow instance to your Salesforce org, allowing you to quickly identify successfully synced records as well as any records that have not yet been synced. Receipt delivery statuses include:

• Success Your records were synced successfully

• Pending Your Salesforce org is still processing the records shared out from your ServiceNow instance

• Error Your records were not synced successfully

To view the receipts generated in your Salesforce org for data being shared out by ServiceNow, follow these steps:

Image Removed

By default, Salesforce receipts will be generated for every 1,000 ServiceNow messages. However, you can change this default value within the Replicator Settings for your Salesforce org.

Image Removed

Salesforce sandboxes are used to develop and test changes for your organization in an environment that doesn't affect any real data or applications. When development and testing is done, you can migrate these changes from the sandbox to the production org using change sets.

This is especially useful for deploying Apex triggers in production orgs. Dynamic shares in the Perspectium Salesforce Package use Apex triggers, similar to how business rules capture changes in ServiceNow. However, unlike ServiceNow where you can create business rules in a production ServiceNow instance, Salesforce requires you deploy Apex triggers by creating them in a sandbox org and then moving them over to your production org using change sets. 

Apex triggers use Apex code to execute the Perspectium application's code to share records out of Salesforce. To deploy anything containing Apex code (such as Apex triggers) in production, you must have 75% test coverage of all Apex code. By default, the Perspectium Package comes with a test class that covers the basic components of Perspectium's Apex code including the dynamic share Apex triggers. However you may need to add an additional test class to your change set that tests your trigger's Apex code (especially if there are any customizations) to ensure this 75% coverage of all Apex code. An example of a test class that tests the dynamic share Apex trigger code can be found here.

 NOTE: Your Apex trigger trigger should reference a queue that has an alias. When migrating your Apex trigger from sandbox to production using change sets, the Apex trigger code cannot be changed. So using the same alias name when creating a queue in sandbox and creating a queue in production allows you to specify different queues in your sandbox and production orgs that can use the same Apex trigger.

Prerequisites:

 You will need to have two Salesforce orgs:

• A sandbox org sending an outbound change set
• A production org receiving an inbound change set 
• The Perspectium Package is installed and configured in both orgs before the migration process begins

Create Apex test classes for your dynamic share Apex triggers to ensure 75% test coverage of all Apex code. An example of a test class that tests the dynamic share Apex trigger code can be found here.

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Now that you've created a change set from your sandbox org and have sent it outbound to your production org, you can go to your production org to receive the change set inbound and deploy your dynamic share Apex triggers in production. See the next section for how to receive this change set.

Image Removed

Image Removed

Image Removed

Image Removed

Back to the Inbound Change Sets, under Change Set Awaiting Deployment, find the change set you previously validated and click Deploy.

Image Removed

If the change set succeeds, the change set will be deployed. To see all migrated Apex triggers, go to Setup.

If failed, update the selected test or make appropriate changes to the change set.

Other

Table Maps

Logs

View the logs generated by the Perspectium application. The configuration for how the 

To read Salesforce attachments into ServiceNow, the u_sfdc_attachment_import import set table is provided as part of the Perspectium Salesforce Update Set for ServiceNow.

The update set comes with a subscribe configuration for u_sfdc_attachment_import so records can be read into the import set table. A script action will then run on records being inserted to properly add and delete attachments.

The Perspectium message that is shared out of Salesforce for an attachment will come with a ParentTable field that has the name of the Salesforce table that you can then use to determine which table this should map to in ServiceNow.

The Set parent table to attach to business rule on the u_sfdc_attachment_import table is provided so you can modify the corresponding field in the import set table (u_parenttable) to the appropriate ServiceNow table based on how you are subscribing Salesforce records into ServiceNow.

For example, if you are subscribing Salesforce Case records into ServiceNow Incident records, you can use the following business rule to update the field:

if (current.u_parenttable == 'Case')
    current.u_parenttable = 'Incident';

answer= {"type":"Attachment"};

answer= {"type":"File"}; 

var sysEncodedAttachment = new GlideSysAttachment();  
var binData = sysEncodedAttachment.getBytes(current);  
var StringUtil = (typeof GlideStringUtil != 'undefined') ? new GlideStringUtil() : new Packages.com.glide.util.StringUtil();
answer = StringUtil.base64Encode(binData);

var gr = new GlideRecord(current.table_name);
gr.addQuery("sys_id", current.table_sys_id);
gr.query();
if (gr.next()){
	answer = String(gr.number);
}

var gr = new GlideRecord(current.table_name);
gr.addQuery("sys_id", current.table_sys_id);
gr.query();
if (gr.next()){
	answer = String(gr.correlation_id);
}

By default, records subscribed into Salesforce will coalesce on the ID field to determine if we should insert a new record or update a current record. So in most cases, you will want to create JSON messages to be consumed into Salesforce with the record's ID as found in Salesforce.

For example, if you are replicating records between ServiceNow and Salesforce, you can use the table map feature of the Perspectium application to map out a field that holds the record's Salesforce Id. This Id field will generally be saved as the correlation_id field in ServiceNow tables. That way when the record is subscribed into Salesforce, it can use this Id field to find the record and update or insert as appropriate.

However there may be cases where you want records in Salesforce to coalesce on an External ID field (such as when you want Salesforce to coalesce on the replicated record's ServiceNow sys_id) since records may generally be created on another platform like ServiceNow versus starting in Salesforce. Another reason is you may prefer to have more control in the ServiceNow app and have it be your central location for all data transformation and thus want to control coalescing there as well.

Here's how:

Here's an example to Illustrate:

Image Removed

Using the above example, when the message is subscribed into Salesforce, the app will query the Case table and look for a record with ExternalID__c = 'f4e2e6104f120300b6a444b18110c726' and if it finds a record as such, use that record to update.

Here's how the table field map would look for the ExternalIDField attribute:

Image Removed

In this example, the ExternalIdField is scripted to always use the same value since the custom External ID field in Salesforce will always be the same field name while the record's sys_id is used for the External ID field's value.

You can schedule the MultiOutput Processing (share) and Replicator Subscriber (subscribe) jobs to run at predefined intervals, so that Salesforce data is effectively shared out. When you create a new Perspectium job for Salesforce (or edit an existing one), you can choose from a defined set of Job Intervals - the default settings include 30 seconds, 1 minute, 5 minutes, 15 minutes, 30 minutes, and 60 minutes. You may want to set your intervals to a custom time duration that isn't included in the default settings. Here's how:

Salesforce stores comments in a separate table, so when you share out a Case's comments, you would share out the CaseComment table and then subscribe these records into an import set table that targets the sys_journal_field table.

However, to get these comments to refresh properly in the incident's activity log as well as fire notifications, the best way to save these comments is using an onBefore transform map script in the import set table you create that targets the sys_journal_field table. Doing this will ensure that the activity log refreshes properly and any notifications set for incident comments also fire as expected. 

Based on a) the incoming CaseComment JSON containing a reference to the Case record as stored in the ParentId field (which is mapped to u_parentid when read into the import set table) and b) this Case record ID stored in the correlation_id field in the incident table in ServiceNow, this script will find the incident record to add the comment through the incident:

var incsysid='';
var inc = new GlideRecord('incident');
inc.addQuery('correlation_id',source.u_parentid);
inc.query();
if (inc.next()){
    incsysid = inc.sys_id;  //find sysid of incident from parentid in JSON
}

var gr = new GlideRecord('sys_journal_field');
gr.addQuery('name', 'incident');
gr.addQuery('element_id', incsysid);
gr.addQuery('value', source.u_commentbody);
gr.query();
if (gr.getRowCount() > 0) {
    ignore = true; // found comment already previously don't need to re-add
}
else {
    var igr = new GlideRecord('incident');
    if (igr.get(incsysid)) {
        igr.comments.setJournalEntry(source.u_commentbody);
        igr.update();
        ignore = true;
    }
}

Within the Perspectium application in your Salesforce instance, the top navigation menu includes tabs for Inbound Messages and Outbound Messages. 

The Outbound Messages tab contains records that are queued to be sent to the Perspectium server. On this tab, you can view all messages, edit or delete an existing message, and create a new message.

 NOTE: If the Status is at "Ready", the Time Processed field will be blank. Once the status is "Sent", you will be able to see how long it took for the outbound message to be sent.  

The Inbound Messages tab contains records that were shared to this Salesforce instance by other sources, such as ServiceNow. The data flowing into this table will insert or update their respective tables and record once they are processed. On this tab, you can view all messages, edit or delete an existing message, and create a new message.

Table maps

Sending to the CaseComment table is also supported. Unlike Incident to Case, the target for this table is CaseComment and the source table is Journal Entry [sys_journal_field]. Below are attached images for examples:

Image Removed

Image Removed

Source scripts

Below are the source scrips for required fields above:

attributes:

answer = {"type":"CaseComment"};

isPublished:

if (current.element.contains("comment"))
	answer = "true";

ParentId:

var gr = new GlideRecord('incident');
gr.addQuery("sys_id", current.element_id.toString());
gr.query();
if (gr.next())
	answer = gr.correlation_id.toString();

@RecordId:

var gr = new GlideRecord('incident');
gr.get(current.element_id.toString());
answer = gr.sys_id.toString();

CommentBody:

var pspUtil = new PerspectiumUtil();
var gr = new GlideRecord('incident');
gr.addQuery("sys_id", current.element_id.toString());
gr.query();
gr.next();

var elementId = gr.sys_id;
var tgr = new GlideRecord("sys_journal_field");
tgr.addQuery("element_id", elementId);
tgr.orderByDesc("sys_created_on");
tgr.query();
if (tgr.next())
	pspUtil.addTag(tgr, "msp_client_incident_sent");

answer = current.value;

Transform maps

Receiving into the CaseComment table is also supported. The source for this table is CaseComment and the target table is Journal Entry [sys_journal_field]. Below are attached images for examples:

Image Removed

Image Removed

Source scripts:

Below are the source scripts for the required fields above:

element_id:

var gr = new GlideRecord("incident");
gr.addQuery("correlation_id", source.u_parentid);
gr.query();
gr.next();
return gr.sys_id; // return the value to be put into the target field

element:

return "comments"; // return the value to be put into the target field

name:

return "incident"; // return the value to be put into the target field

Once the field mappings are created, an onBefore transform script is necessary for insertion. Refer to the image and script below for an example.

Image Removed

var gr = new GlideRecord("incident");
gr.addQuery("correlation_id",source.u_parentid);
gr.query();
gr.next();

var elementId = gr.sys_id;
var tgr = new GlideRecord("sys_journal_field");
tgr.addQuery("element_id", elementId);
tgr.addQuery("value", source.u_commentbody);
tgr.orderByDesc("sys_created_on");
tgr.query();
if (tgr.next() && pspUtil.recordHasTag(tgr, "msp_client_incident_sent")) {
	ignore = true;
	return;
}

pspUtil.addTag(tgr, "msp_client_incident_sent");

gr.comments.setJournalEntry(source.u_commentbody);
gr.setForceUpdate(true);
gr.update();

Dynamic share

Image Removed

Image Removed

Image Removed

Image Removed

Be sure to include the “before share script” provided below. This will defer comments that do not have a correlation id and will put it on stand by.