You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »


The Common Attachment document is an XML schema that contains default fields for mapping change request form values from one system to another. The common attachment format mirrors what one would see in an ITIL view of an Attachment form with related lists expressed in embedded XML form.

Since the approach of using embedded attachments in common documents limits us to 7MB per message in ServiceNow, this format allows you to support sending large attachments when e-bonding ServiceNow instances for supported integrations. Common Attachment solves this by sharing out the sys_attachment_doc records in their 4k chunks while also adding the attachment metadata such as the file name, content type and the table record the attachment is attached to. The common_attachment records are read into the PSP Common Attachment import set table and saved into the sys_attachment_doc table while also creating the sys_attachment record and linking it properly to the table record.


A sample Common Attachment looks like this:

<common_attachment>
    <compressed/>
    <content_type/>
    <data/>
    <file_name/>
    <length/>
    <position/>
    <size_bytes/>
    <size_compressed/>
    <table_correlation_display/>
    <table_correlation_id/>
    <table_name/>
    <table_number/>
    <table_sys_id/>
</common_attachment>


The Perspectium Common Attachment Helium update set will contain the following:


Outbound Table Maps 

NameTypeSource tableDescription
Attachment Doc to Common Attachmentcommon_attachmentAttachment Document [sys_attachment_doc]Main body of the common_attachment format

Inbound Table Maps

NameTypeTarget tableDescription
Common Attachment to PSP Common Attachmentcommon_attachmentPSP Common Attachment [ u_psp_common_attachment ]Main body of the common_attachment format

Import Set

NameDescription
PSP Common Attachment to Attachment Doc (u_psp_common_attachment)Transforms the common_attachment format to attachment


Script Actions


In order to capture the event of an attachment being added to a record, script actions are run that will share out the attachment when the event occurs. The Perspectium Common Attachment script actions come packaged as part of the Common Attachment update set and the only change needed is to update the script actions to use the same tag as created when installing a common document format.

The two script actions captured are the “attachment.uploaded” and “attachment.renamed” events.

(info) NOTECommon attachment deletes are not supported.

Since common attachments are subscribed to an import set table, both events will share out attachments that can be added to a record on the subscribing side. The attachment.uploaded event will send messages as “.bulk” while the attachment.renamed event sends messages as “.rename” in case you want to add special processing on the subscribing instance.


Dynamic Share


For the correct outputs to be produced, you must create a dynamic share on the Attachment Document [sys_attachment_doc] table with the same queue as the table that is being e-bonded (i.e. incident, problem, etc.). If you have multiple integrations such as incident, change, etc. that all use the same queue, then only one dynamic share on sys_attachment_doc is needed.

The script will evaluate the conditions of the dynamic share on the table where the attachment is attached (such as incident) to determine if the attachment is shared out. To ensure the attachment is captured when a record is first created (i.e. the user is adding an attachment as he/she creates an incident), add the following script to the Before share script of the dynamic share for the table (such as incident) where the attachments are attached to:

// only do on insert as script action will run other times
if (psp_action == 'insert') {	
	// schedule a job to run in the background to share out attachments
	var pspRepl = new PerspectiumReplicator();
	
	// share record, setting tag to mark attachments
	pspRepl.shareAttachmentsDelayed(current.sys_id, dynamicshare_gr, "bulk", true, 'msp_incident_sent');
	
}

When creating a new record (such as a new incident), script actions on the attachment.uploaded event will run if a new record is submitted immediately after adding the attachment. So in that case you may have duplicate records shared out as both the above code and the script action will run sharing out the attachment (this will be properly handled on the subscribing ServiceNow instance to not cause a duplicate attachment record).

We do need the above code to handle the case where the record isn't submitted until later. For example, if the user adds an attachment first and then spends a few minutes filling out the incident form before creating the incident, then the above script will capture the attachment and share it out since the script action will not run.

(info) NOTEThe “msp_incident_sent” tag listed above as this will be the same tag as created when installing a common document format.