Transferring data by using DSO

Important

The Distributed Server Option (DSO) is available only for on-premises deployments.

In Developer Studio, you can transfer data from a source form to a destination form.

Before you begin

Before attempting the procedures in this topic, ensure that you are familiar with distributed operations. For detailed information about performing individual distributed operations, see Setting up DSO to synchronize data across multiple AR System servers.
Make sure that the servers create records with unique IDs:
- Configuring-forms-to-use-DSO-unique-prefixes
- Running-the-Prefix-Manager for a hub and spoke environment

To configure the DSO environment for data transfer

Perform these steps on the source server to transfer data:

Create distributed mappings for the forms by specifying the fields to be transferred.
The mapping can be based on matching IDs, field name, or custom field mappings.
Tip
If you are mapping a source form to a destination form that has the same number of fields and that use the same field IDs as the source form, base the mappings on matching IDs.

Create a DSO filter, specifying Transfer for the DSO action.
You can create multiple distributed transfer filters, with each filter based on a specific use case scenario:

Use case	Filter qualification	Notes
All	'z1D Action' != "DELETE"	This qualification prevents processing of any modify filters that execute for that keyword on the source server.
Replicating data through DSO from one server to another	Set the filter to execute on Submit and Modify	No other specific qualification condition.
Transferring only closed incidents	Qualify the filter to execute only when Status is Closed	You can use an additional qualification to support your use case.

Audit forms handling

Through auditing, you can keep track of changes to data in any form (except display-only forms).

If you have at least one field configured for auditing on a form, data in a main form can be recorded in an audit form or log form when any of the following actions occur:

A new entry is created on the form.
An entry is deleted from the form.
Any audit field on the form is modified.
Data is merged into a form.

Auditing requires configuration at the following levels:

Form level — Enable auditing for a form, specify an audit style, and specify the name of the form that contains the audited data. If the audit form does not exist, AR System creates it.
Field level — Specify whether a field should be:
- Audited — A change to the field triggers audit processing.
- Copied — The field value is copied to the corresponding field in the audit form if the audit field is triggered. Audit fields that have not changed are not copied.
- Audited and copied — The field triggers an audit if the field is changed. If it is not changed, it is still copied.

You can selectively audit entries by providing an audit qualification. If the audit qualification fails, the audit doesn't occur (even if the values of audit fields have changed).

For more information about auditing, see Auditing data and approvals.

To manage data in an audit form

Log in to AR System Administrator Tool, or Developer Studio.
Open the form for which you want to manage audit data.
Select Form > Form Properties.
Select the Audit property:
- (
  AR System
  Administrator Tool) In the Form Properties dialog box, click the Audit tab.
- (Developer Studio) Select Audit property on the Form Properties dialog box.
  The audit form gets records from parent forms based on their audit settings. When data is inserted or modified in the audited fields on the form, an audit record is created in the specified audit form.
Add the $USER$!= "Distributed Server" condition to the Qualification field for the parent form audit properties. This qualification ensures the audit form records are transferred to the target server through the DSO filters only.

If your business requires you to copy the audit record from your source server to the target server, you must create separate distributed transfer filters for the audit data. The following table lists the BMC Helix ITSM parent form and the associated Audit form.

Parent forms and corresponding audit forms

Parent form name	Audit form name
HPD:Help Desk HPD:Associations	HPD:HelpDesk_AuditLogSystem
CTM:People	CTM:AuditLogSystem
PBM:Problem Investigation PBM:Solution Database PBM:Known Error	PBM:Problem_AuditLogSystem
AST:PurchaseLineItem AST:PurchaseOrder AST:CI Unavailability AST:Configuration	AST:AuditLogSystem
CHG:Infrastructure CHG:Associations	CHG:ChangeRequest_AuditLogSystem
CTR:ContractBase	CTR:AuditLogSystem
TMS:Association TMS:Flow TMS:FlowTemplate TMS:Task TMS:TaskGroup TMS:TaskTemplate TMS:Variable	TMS:AuditLogSystem
RMS:Release	RMS:AuditLogSystem
AAS:Activity	AAS:AuditLogSystem

Association forms data

You can transfer data for an association form, such as HPD:Associations or PBM:Investigation Associations, from the source servers as long as the target server has the same form. Otherwise, the association records do not work.

Product Catalog form handling

If you create a distributed transfer filter for the PCT:Product Catalog form, include the following qualification in the Run If DSO filter condition.

NOT (
(( 'Product Name' = $NULL$ ) AND ( 'z1D Char02' != $NULL$ ) AND ( 'z1D Char02' != 'Product ID') AND ($USER$ != "Distributed Server" ))
OR
((( 'Product Name' = "BMC_UNKNOWN" ) OR ( 'Manufacturer' = "BMC_UNKNOWN" )) AND ( 'z1D Char02' != $NULL$ ) AND ( 'z1D Char02' != 'Product ID') AND ($USER$ != "Distributed Server" ))
OR
(( 'Product Name' != $NULL$ ) AND ( 'Product Name' != "BMC_UNKNOWN" ) AND ( 'Manufacturer' != $NULL$ ) AND ( 'Manufacturer' != "BMC_UNKNOWN" ) AND ( 'z1D Char02' != $NULL$ ) AND ( 'z1D Char02' != 'Product ID') AND ($USER$ != "Distributed Server" )) OR
( 'z1D Action' = "DELETE" )
OR
( 'z1D Action' = "PDLDELETE" )
)

The qualification is necessary to prevent the following distributed transfer filters from being executed when validation filters modify data in the PCT:Product Catalog records:

PCT:PDC:ChkCategoryIndex_011_Delete
PCT:PDC:ChkProductIndex_013_BMC_UNKNOWN_Delete
PCT:PDC:ChkProductIndex_016_Delete

Notification forms handling

The following notification forms process transactions and do not store data. No distributed transfer workflow is required for these forms.

NTE:Notifier Log
NTE:SYS-Define NT Events
NTE:SYS-Group NT Control
NTE:SYS-Individual NT Control
NTE:SYS-NT Process Control

Software License Management (SWLM) rules engine forms handling

The following rules engine forms process transactions and do not store data. No distributed transfer workflow is required for these forms.

RLE:LoadRule
RLE:LoadRuleSet
RLE:LoadRuleSetType
RLE:LoadRunTag
RLE:LoopRuleSpecificData
RLE:RuleEngineFireInterface

BMC Helix ITSM application merge filters

When a distributed transfer filter executes on the source form on the source server, the data is transferred to the target form on the target server and any merge filters on the target form are executed.

Merge filters used when user is DSO (for distributed transfer)

Not all out-of-the-box BMC Helix ITSM application merge workflows are required to execute on a DSO transaction. To save processing time, BMC has identified and qualified the merge filters necessary to execute if the user is Distributed Server for a distributed transfer.

The filters are divided into the following categories:

Filters that execute on merge.
Filters that execute on Submit, Modify, or Delete with merge combinations.