Implementing DSO for BMC Service Level Management

In an environment with multiple servers, you can transfer the request from one server to another by using Action Request System Distributed Server Option (DSO). DSO is designed to synchronize records for two identical systems using independent copy style transfers. Your system is defined with mappings and filters that allow you to copy all the changes from one system to another while keeping the data sets the same. When working in conjunction with BMC Service Level Management, DSO allows your servers to keep requests and BMC Service Level Management definition and data current on multiple servers.

You must transfer the following items to the new server:

The request
The measurement record
Entries in the SLM:EventSchedule form

Important

If you change the business entities on the request before the transfer, the business entities must exist on the source server and on the destination server.

,
The time taken to transfer the request is ignored in the calculations. For more information, see the following sections :

DSO and actions

You can work with different types of actions in a distributed environment. If you are running BMC Service Level Management on two servers and the data is shared between them, the escalation triggers actions stored in the SLM:EventSchedule form on both servers. As a result, you see two sets of actions. If you disable the escalation on one of the servers, only one set of action triggers.

When you copy a record, it triggers workflow that is set to execute on Merge. In a Service Level Managementgenerated workflow, filters named zSLMGe do not execute on Merge, therefore the same Service Level Management workflow must exist on all servers. Even though Service Level Management measurement information is copied across the servers, only one server triggers the milestones stored in the SLM:EventSchedule form.

Important

Make sure that you disable the SLM:EventSchedule:TAD_Polling escalation on other servers. The only exception is for milestones that are not time-dependent and trigger on a user-defined qualification. These milestones do not execute on Merge and will trigger on the server where the request is updated.

When you are setting up an agreement or service target with a notification action for a milestone, add the qualification AND $\USER$ != "Distributed Server " to the Execute If field on the milestone to prevent multiple notifications.

DSO transfers perform Modify operations in some cases. To avoid problems, modify the filter SLA:Shared:Check for License 01 by adding AND $USER$ != "Distributed Server " to the Run If qualification.

For more information on adding qualifications, see Defining-terms-and-conditions-for-service-targets.

DSO and forms

To work with forms, you must transfer any supporting data stored in application or AR System forms. For example, if you have any frequently updated information referenced by Service Level Management that is stored in Business Time forms, you must create mappings and filters. For more information, see Distributed logical mapping in the Action Request System online documentation.

When you configure a form, for example CustomForm on the source server, the metadata in forms SLM:CongfigDataSource and SLM:Object are distributed to the target server.

DSO and attachments

You can distribute attachments in Service Level Management by transferring the following two additional forms:

SLM:Attachment
SLM:UDA_AttachmentAssociations

For more information, see Distributed transfers in the Action Request System online documentation.

DSO and filters

Occasionally, when you are deleting a service target or an agreement, the zSLMGen filters are not removed from one or both servers. This is because the data is deleted before the BMC Service Level Management engine process that deletes the filters is triggered and therefore the information about which filters to delete is missing. For more information, see Troubleshooting-issues-with-service-targets-and-service-level-agreements.

DSO and reporting servers

Use DSO to send completed measurement records to an archive server for users who need access to report information. This server does not contain Service Level Management definitions, so no milestone actions occur.

DSO and request-based service targets

In a time-based Service Level Management, for example, Help Desk, submitted requests are updated on the original server. DSO is used to copy the requests, the Service Level Management measurement record, and the milestone records. When viewing the request on any server, the SLM tab displays the correct information, including information about the attached service target with the projected due dates and milestone information. However, the milestones trigger on the server with the active escalation.

DSO and availability service targets

Milestones for availability service targets are triggered through escalations and a link on the BMC Service Level Management Console. If the escalations are enabled on multiple servers, the milestone actions will trigger multiple times. You must disable all the escalations for the SLM:EventSchedule form on all servers except the active server. For more information, see Creating escalations in the Action Request System online documentation.

Best practice
For availability service targets, we recommend that you define the service target on one server only.

When configuring a form to work with Service Level Management, use DSO to ensure that the reference GUID (globally unique identifier) for the application form is consistent across all servers