Transferring data using DSO
Note
Before attempting the procedures in this topic, you should be familiar with distributed operations. For detailed information about performing individual distributed operations, see Setting up DSO to synchronize data across multiple AR System servers.
This topic provides the following information:
To transfer data
In BMC Remedy Developer Studio, 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.
- For all forms identified in DSO Forms reference the only required qualification for the distributed transfer filter, is: 'z1D Action' != "DELETE". This qualification prevents processing of any modify filters that execute for that keyword on the source server.
- You can set the filter to execute on Submit and Modify with no other specific qualification condition if the scenario is data replication through DSO from one server to another.
- You can use an additional qualification to support your use case. For example, if you want to just transfer only closed incident tickets, you can qualify the filter to execute only when Status = Closed.
- You can create multiple distributed transfer filters, with each filter based on a specific use case scenario.
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 on 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, BMC Remedy 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 does not occur (even if the values of audit fields have changed).
For more information about auditing see Auditing changes to data.
To manage data in an audit form
- Log in to BMC Remedy Administrator Tool, or BMC Remedy Developer Studio.
- Open the form for which you want to manage audit data.
- Click Form > Form Properties. The Form Properties dialog box opens.
- Select the Audit property:
- (BMC Remedy Administrator Tool) In the Form Properties dialog box, click the Audit tab.
- (BMC Remedy Developer Studio) Select Audit property on the left side of 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. Parent forms and corresponding audit forms lists the BMC Remedy 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 Change 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 |
New in 7.5.0 x |
|
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 executing 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
Note
This section applies only to BMC Remedy ITSM 7.5.00 and later.
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 Remedy 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 Remedy ITSM application merge workflow is 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.
This fix is in BMC Remedy ITSM 7.0.x patch009 and the BMC Remedy ITSM 7.5.00 release or later.
The filters are divided into the following categories:
- Filters that execute on merge.
- Filters that execute on Submit, Modify, or Delete with merge combinations.
Comments
Log in or register to comment.