Remedy DSO

BMC Remedy Action Request System 7.
Administering BMC Remedy DSO
May 2006 Part No: 58469
Copyright 19912006 BMC Software, Inc. All rights reserved. BMC, the BMC logo, all other BMC product or service names, BMC Software, the BMC Software logos, and all other BMC Software product or service names, are registered trademarks or trademarks of BMC Software, Inc. All other trademarks belong to their respective companies. BMC Software, Inc., considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable end user license agreement or nondisclosure agreement for the product and the proprietary and restricted rights notices included in this documentation. For license information about the OpenSource files used in the licensed program, please read OpenSourceLicenses.pdf. This file is in the \Doc folder of the distribution CD-ROM and in the documentation download portion of the product download page. Restricted Rights Legend
U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC Software, Inc., 2101 CityWest Blvd., Houston, TX 77042-2827, USA. Any contract notices should be sent to this address.
Contacting Us If you need technical support for this product, contact Customer Support by email at support@remedy.com. If you have comments or suggestions about this documentation, contact Information Development by email at doc_feedback@bmc.com. This edition applies to version 7.0 of the licensed program.
BMC Software, Inc.

www.bmc.com
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 AR System documents . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Learn about the AR System Developer Community . . . . . . . . . . . . 10 Why should you participate in the Developer Community? . . . . . . . . 10 How do you access the Developer Community? . . . . . . . . . . . . . 10
Chapter 1
Using the distributed server environment . . . . . . . . . . . . . 11

Overview of the Distributed Server Option . . . . . . . . . . . . . . . . 12 Using the Distributed Server Option . . . . . . . . . . . . . . . . . . . 12 Using DSO with server groups . . . . . . . . . . . . . . . . . . . . 13 Managing the exchange of information. . . . . . . . . . . . . . . . . . 14 Using Distributed Server Option forms. . . . . . . . . . . . . . . . . 15 Using distributed mappings . . . . . . . . . . . . . . . . . . . . . 15 Using distributed fields . . . . . . . . . . . . . . . . . . . . . . . 16 Using distributed pools . . . . . . . . . . . . . . . . . . . . . . . 18 Using request IDs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Defining distributed operations . . . . . . . . . . . . . . . . . . . . . 20 Using distributed transfers . . . . . . . . . . . . . . . . . . . . . . 20 Using distributed updates . . . . . . . . . . . . . . . . . . . . . . 24 Using distributed returns . . . . . . . . . . . . . . . . . . . . . . 26 Using distributed deletes . . . . . . . . . . . . . . . . . . . . . . . 28 Overview of setting up distributed operations. . . . . . . . . . . . . . . 29
Contents
BMC Remedy Action Request System 7.0
Chapter 2
Licensing DSO . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Chapter 3
Configuring the distributed server . . . . . . . . . . . . . . . . 33

Setting up the local and remote DSO servers . . . . . . . . . . . . . . . 34 Configuring a local AR System server . . . . . . . . . . . . . . . . . 34 Configuring a remote AR System server . . . . . . . . . . . . . . . . 41 Upgrading previous versions of AR System . . . . . . . . . . . . . . . . 43 Specifying a DSO host name for distributed mappings . . . . . . . . . . . 44 Configuring overwrite behavior for duplicate request IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Configuring the RPC timeout setting . . . . . . . . . . . . . . . . . . 45 Configuring DSO for load balancing . . . . . . . . . . . . . . . . . . . 45 Using debug trace mode to create log files . . . . . . . . . . . . . . . . 46
Chapter 4
Implementing the Distributed Server Option . . . . . . . . . . . 49

Working with distributed fields on forms. . . . . . . . . . . . . . . . . 50 Using the distributed fields window . . . . . . . . . . . . . . . . . . 50 Working with distributed mappings . . . . . . . . . . . . . . . . . . . 57 Using the distributed mapping window . . . . . . . . . . . . . . . . 57 Creating and modifying distributed mappings . . . . . . . . . . . . . . 60 Specifying distributed mapping basics . . . . . . . . . . . . . . . . . 63 Specifying distributed mapping options . . . . . . . . . . . . . . . . 65 Specifying distributed mapping transfers . . . . . . . . . . . . . . . . 69 Specifying distributed mapping returns . . . . . . . . . . . . . . . . . 74 Setting distributed mapping help . . . . . . . . . . . . . . . . . . . 76 Viewing and modifying distributed mapping change history . . . . . . . . 77 Working with distributed pools . . . . . . . . . . . . . . . . . . . . . 78 Using the distributed pool window . . . . . . . . . . . . . . . . . . 79 Creating and deleting distributed pools. . . . . . . . . . . . . . . . . 79 Modifying distributed pool objects . . . . . . . . . . . . . . . . . . 81 Using filters and escalations for DSO actions . . . . . . . . . . . . . . . 82 Creating DSO actions in filters and escalations . . . . . . . . . . . . . 82 Creating DSO actions . . . . . . . . . . . . . . . . . . . . . . . . 84
4 Contents
Controlling pending transfer information . . . . . . . . . . . . . . . . 90 Using the pending distributed operations window . . . . . . . . . . . . 90 How errors affect pending distributed operations . . . . . . . . . . . . 92
Chapter 5
Creating Distributed Server Option workflow . . . . . . . . . . . 93

Basic distributed operations . . . . . . . . . . . . . . . . . . . . . . 94 Distributed transfers . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Adding distributed fields to your forms . . . . . . . . . . . . . . . . 95 Creating distributed mappings . . . . . . . . . . . . . . . . . . . . 96 Creating a filter . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Distributed updates . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Distributed returns . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Distributed deletes. . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Appendix A
Advanced topics . . . . . . . . . . . . . . . . . . . . . . . . 107

Setting up chained distributed transfers . . . . . . . . . . . . . . . . . 108 Special considerations for chained distribution . . . . . . . . . . . . 108 Defining a chained distributed transfer . . . . . . . . . . . . . . . . 111 Broadcast distributed transfers . . . . . . . . . . . . . . . . . . . . . 115 Using broadcast transfers to manage DSO from a central location . . . . 117
Appendix B
Distributed Server Administration program . . . . . . . . . . . 121

Overwriting basic fields example . . . . . . . . . . . . . . . . . . . . 123
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Contents
6 Contents
Preface
Important: The compatibility information listed in the product documentation is subject to change. See the compatibility matrix at http:/ /supportweb.remedy.com for the latest, most complete information about what is officially supported.
Carefully read the system requirements for your particular operating system, especially the necessary patch requirements.
Audience
This guide for administrators who are responsible for setting up and maintaining the BMC Remedy Distributed Server Option. As the administrator, you should be familiar with BMC Remedy User and BMC Remedy Administrator client tools. It is also helpful to have an understanding of how to administer distributed applications. This guide assumes that you are familiar with the information contained in the following help systems and manuals: BMC Remedy User Help Configuring Form and Application Objects Workflow Objects Concepts
Preface
AR System documents
The following table lists documentation available for AR System products. Unless otherwise noted, online documentation in Adobe Acrobat (PDF) format is available on AR System product installation CDs, on the Customer Support site (supportweb.remedy.com), or both. You can access product Help through each products Help menu or by clicking on Help links.
Title Concepts Description Audience
Overview of AR System architecture and features with Everyone in-depth examples; includes information about other AR System products as well as a comprehensive glossary for the entire AR System documentation set. Procedures for installing AR System. Administrators
Installing Getting Started
Introduces topics that are usually only learned when first Everyone starting to use the system, including logging in, searching for objects, and so on. Describes components necessary to build applications in Developers AR System, including applications, fields, forms, and views. Contains all of the workflow information. Contains information about configuring AR System servers and clients, localizing, importing and exporting data, and archiving data. Developers Administrators
Form and Application Objects
Workflow Objects Configuring
Installing and Administering BMC Remedy Mid Tier Integrating with Plug-ins and Third-Party Products Optimizing and Troubleshooting
Contains information about the mid tier, including mid Administrators tier installation and configuration, and web server configuration. Discusses integrating AR System with external systems using plug-ins and other products, including LDAP, OLE, and ARDBC. Administrators /Developers
Server administration topics and technical essays related Administrators to monitoring and maintaining AR System for the purpose of optimizing performance and troubleshooting problems.
8 Preface
Title Database Reference
Description
Audience
Database administration topics and rules related to how Administrators AR System interacts with specific databases; includes an overview of the data dictionary tables. Server administration and procedures for implementing Administrators a distributed AR System server environment with the BMC Remedy Distributed Server Option (DSO). Flashboards administration and procedures for creating Administrators and modifying flashboards and flashboards components /Programmers to display and monitor AR System information. Information about AR System data structures, C API function calls, and OLE support. Quick reference to C API function calls. Information about Java classes, methods, and variables that integrate with AR System. Procedures for installing, configuring, and using the BMC Remedy Email Engine. List and expanded descriptions of AR System error messages. Combined index of all books. Information about new features list, compatibility lists, international issues, and open and fixed issues. Procedures for using BMC Remedy User. Procedures for using BMC Remedy Import. Procedures for creating and modifying an AR System application for tracking data and processes. Procedures for using BMC Remedy Alert. Administrators /Programmers Administrators /Programmers Administrators /Programmers Administrators Administrators /Programmers Everyone Everyone Everyone Administrators Administrators Everyone
Administering BMC Remedy DSO Administering BMC Remedy Flashboards C API Reference C API Quick Reference Java API * Administering BMC Remedy Email Engine Error Messages Master Index Release Notes BMC Remedy User Help BMC Remedy Import Help BMC Remedy Administrator Help BMC Remedy Alert Help BMC Remedy Mid Tier Configuration Tool Help
*.
Procedures for configuring the BMC Remedy Mid Tier. Administrators
A JAR file containing the Java API documentation is installed with the AR System server. Typically, it is stored in C:\Program Files\AR System\Arserver\Api\doc\ardoc70.jar on Windows and /usr/ar/<server_name>/api/doc/ardoc70.jar on UNIX.
AR System documents
Learn about the AR System Developer Community

If you are interested in learning more about AR System, looking for an opportunity to collaborate with fellow AR System developers, and searching for additional resources that can benefit your AR System solution, then this online global community sponsored by BMC Remedy is for you. In the Developer Community, you will find collaboration tools, product information, resource links, user group information, and be able to provide BMC Remedy with feedback. The Developer Community offers the following tools and information: Community message board Community Downloads AR System Tips & Tricks Community recommended resources Product information User Experience Design tips
Why should you participate in the Developer Community?

You can benefit from participating in the Developer Community for the following reasons: The community is a direct result of AR System developer feedback. BMC Remedy provides unsupported applications and utilities by way of Community Downloads, an AR System application. BMC Remedy posts the latest AR System product information in the Developer Community to keep you up to date. It is an opportunity to directly impact product direction through online and email surveys. Its free!
How do you access the Developer Community?

Go to supportweb.remedy.com, and click the Developer Community link.
10 Preface
Chapter
Using the distributed server environment

The BMC Remedy Distributed Server Option (DSO) lets you transfer data between forms on different servers whether the servers are on the same host or on physically different hosts. This option is available on both Windows and UNIX servers, and is configured through BMC Remedy Administrator. The following topics are provided: Overview of the Distributed Server Option (page 12) Using the Distributed Server Option (page 12) Managing the exchange of information (page 14) Defining distributed operations (page 20) Overview of setting up distributed operations (page 29)
Note: Before using the Distributed Server Option, you should be familiar with the features and functions of both BMC Remedy User and BMC Remedy Administrator. If you are not yet familiar with the AR System, review BMC Remedy User help, the Concepts guide, the Configuring guide, the Form and Application Objects guide and the Workflow Objects guide before continuing.
Using the distributed server environment
11
Overview of the Distributed Server Option

To understand the function of the Distributed Server Option, imagine that your company is running AR System in a single-server environmentall transactions that run on the client machines exchange data with one server. All data on that server is current, meaning that it is never updated from sources other than its connected clients. You add a site with AR System on a different server, so you need a solution that lets you exchange data between similar or different forms on the two servers, and that keeps requests on both systems current. The Distributed Server Option helps you configure and maintain these data exchanges, and establishes time intervals for data transfer, update, and return.
Note: The Distributed Server Option in pre5.0 versions of AR System was a separate service. Starting with version 5.0, DSO is not a separate service it has its own executable file, which is included in the AR System Server and is started by armonitor. Upgrading to a version of 5.0 or later removes this service.
Using the Distributed Server Option

The Distributed Server Option has many uses. These include, but are not limited to: Transferring requests to the location at which they can be processed. For example, your company services office furniture. Desks are repaired in San Francisco, and chairs are repaired in Chicago. When someone in San Francisco creates a broken chair request, the request can be automatically transferred to a server in Chicago. If the request needs a specialists attention, for example, ripped upholstery, the request can be transferred to a different server that handles upholstery repairs. Transferring requests between regions in a 24-hour, seven-days-per-week customer support environment. You can configure the Distributed Server Option to automatically forward open problem requests to the next site at the close of the business day in the current region.
12 Chapter 1Using the distributed server environment
For example, your company has customer support centers in San Francisco, Paris, and Tokyo. You can forward open requests from San Francisco to Tokyo at the end of the San Francisco business day, when it is early in Tokyos next business day. In turn, open requests can be forwarded from Tokyo to Paris at the end of the Tokyos business day. This approach helps alleviate down time. Creating a distributed knowledge base, so that problem-solving information is accessible from any location. For example, you can create filters or escalations that instruct the Distributed Server Option to forward requests closed on one server to all other servers in the environment. All servers have access to the problemsolving information and solutions contained in the closed requests. Archiving old requests. This feature is helpful if you have a server dedicated to archival functions in your environment. Closed requests can be sent to the archive server and stored in one place. Additionally, archiving closed requests frees up main servers for users who need access to the information for reports or other resource-intensive tasks.
Using DSO with server groups

Using DSO with a server group provides automatic failover capability for transfer operations typically restricted to one server. To use DSO in a server group environment, you configure your server group as described in Configuring. Then, when you create a distributed mapping and you specify a server (belonging to a server group) from which the transfers will originate, you also specify whether any server in the group can send the transfer. See Specifying distributed mapping basics on page 63.
Note: For distributed returns, distributed deletes and updates within an ownership chain, you cannot use a server group as the targetyou must specify a server explicitly. Such a mapping will only work for the specified server and will not make use of the server group in the event of a system failure.
Using the Distributed Server Option
13
Managing the exchange of information

The BMC Remedy Distributed Server Option provides a multithreaded process that lets you copy AR System requests between servers and keep requests synchronized across multiple servers, even if those servers are geographically dispersed. You can manage the exchange of information in the following ways: Creating distributed mappings between forms. Distributed mappings are most commonly used to link fields with like field IDs or field names between similar or different forms. You can also use distributed mappings to create custom mappings that link a selection of similar or different fields, or that link a single field to multiple fields. Distributed mappings define how data is transferred from one form to another, how frequently updates are processed, and how conflicts in distributed operations are resolved. Adding distributed fields to forms. Adding distributed fields to forms lets you manage distributed mapping in ownership-based transfers. The three groups of distributed fieldsbasic, full, and advancedprovide different levels of control over distributed mappings. Defining distributed pools to handle specific DSO workflow actions. Distributed pools let the DSO process many distributed operations simultaneously. You can create distributed pools and assign DSO actions to these pools for parallel processing, which minimizes delays and significantly increases the output of distributed operations when DSO activity is heavy. For more information about creating and working with distributed pools, see Working with distributed pools on page 78. Assigning unique request ID prefixes. Although request IDs are not DSO-specific, the ability to tailor the format of request IDs is an important feature for distributed operations. Setting up unique request IDs prevents duplicate requests on different servers, and lets you specify what action will be taken should a duplicate request occur.
Using Distributed Server Option forms

After licensing, the Distributed Server Option automatically adds three required forms. The following list describes each type of form: Distributed Mapping formDefines and maintains parameter and data control values of specific distributed mappings. Distributed Pending formMaintains a queue of pending distributed transfers, updates, returns, and deletes. Distributed Pool formDefines and maintains definitions of specific distributed pools. You can transfer entries in the Distributed Mapping and Distributed Pool forms to their counterparts on remote servers, using the instructions in this documentation for mapping any forms.
WARNING: Do not modify or delete these forms.
Using distributed mappings

Configuring mappings for a distributed operation is an important first step toward designing a distributed system. Mappings are created as objects on the server and stored on the Distributed Mapping form. The mapping definition includes resolving duplicate request IDs and handling certain data controls, such as transfer mode, update, and retry intervals. By specifying multiple mappings between two forms, you can explicitly choose the type of mapping appropriate for each situation.You can also specify default mappings if the AR System finds multiple mappings applicable to the specified transfer criteria. Configuring mappings is a simple process if you are transferring data between two identical forms. If you are transferring data between different forms, you need to determine which fields are mapped to specific fields (and in some cases, which multiple fields are mapped to single fields) in the target form. You also need to consider the results of mapping fields of unequal size or mapping fields containing different data types, such as a character field mapped to a date or time field. If a source field type exceeds the limitations of a target field type, for example, the field length, the distributed operation will result in an error.
15
When creating the filter or escalation that triggers a distributed operation, you can specify which mapping to use, or let the system select a default mapping. You can also override the details of a mapping for a particular distributed operation before it occurs by assigning values in the distributed fields that you add to the forms. For more information about overriding mapping settings, see Overriding mapping settings on a per-request basis on page 23. For more information about mappings, see Creating and modifying distributed mappings on page 60.
Using distributed fields

You must add distributed fields to forms to manage ownership-based transfers. You can override much of the mappings definition by adding distributed fields directly into your distributed forms. For information about ownership-based transfers, see Using distributed transfers on page 20.
Note: For information about ownership, see Ownership and ownership chains on page 21.
You can add three groups of distributed fields to your forms to support distributed operationsBasic, Full, and Advanced. The following list describes each type: Basiclets you make transfers with ownership. The Distributed Server Option sets the values for these fields. For example, if you want to know where a request came from, you can review the From Form and From Server fields for information. Fullincludes the Basic fields. Gives you greater control over the choice of mappings when a possible conflict between mappings exists, and it provides mapping history information. You set some of these fields, and the system sets others. For example, if you want to know where a request was transferred, you can review the To Mapping, To Form, and To Server fields for information. Advancedincludes the Basic and Full fields. Lets you override the settings previously defined for a mapping in the Distributed Mapping window.
For example, if you want to override the method of distributed transfer operations from data-only to data+ownership, you can modify the Transfer Mode distributed field. For information about using distributed fields to alter a mapping for a particular distributed operation, see Creating DSO actions in filters and escalations on page 82. The following table shows the distributed fields available for each group.
Table 1-1: Distributed field groups and associated field names
Distributed field group Basic
Field name Transfer status Update status Master flag From Request ID From Form From Server From Pool
Full
To Mapping From Mapping To Request ID To Form To Server
Advanced
Mapping History Current Form Current Server When to Update Transfer Mode Duplicate Request ID Action Max time to retry Enforce Pattern Matching Require Required Fields Matching Qualification
17
For instructions about adding distributed fields, and for descriptions of each field, see Working with distributed fields on forms on page 50.
Using distributed pools

Distributed pools, like distributed mappings, are created as objects on the server, and stored on the Distributed Pools form. Distributed pools let you use multiple pools (threads) to accurately process pending distributed operations during periods of heavy distributed activity. You can define several pools and associate each DSO operation with a pool. All pending DSO operations within each pool are executed in order. Therefore, you must consider the interdependencies between the forms within an applicationall distributed operations associated with one form, and on interdependent forms, should use the same pool to make sure the order of execution is correct. You can use different pools for unrelated distributed operations, or when sending data-only or independent copies of requests to different destinations. For example, your system is experiencing heavy distributed activity, and you have multiple data-only or independent copy transfers pending from different applications. Because these operations do not need to be completed in a particular order, you can assign them to different pools. You can designate one pool as the default pool, or use the default pool created by the system. If you do not create any distributed pools, or assign an operation to a pool that does not exist, the pending distributed operation is handled by the default pool. For information about creating, modifying, and deleting distributed pool objects, see Working with distributed pools on page 78.
Using request IDs

Perhaps the most important component of a request in a distributed environment is the request ID. Like the name of a person, this is the piece of data you will most likely use to identify and track individual requests, and it should be unique. Requests entered on the same server will have different request IDs. Requests entered on two different servers can have the same request ID, causing conflicts when requests are transferred or shared between the servers.
The Distributed Server Option offers different methods for avoiding and addressing duplicate request IDs. You can assign prefixes to requests entered on different servers, or, if you choose not to use prefixes, specify in the Distributed Mapping window how a duplicate request ID should be addressed.
Preventing duplicate request IDs

The best way to avoid having duplicate request IDs in your distributed environment is to assign site-specific prefixes to requests. For example, you might add a prefix of SAN to requests created on server sanfrancisco, creating an ID of SAN00004598. For more information about assigning prefixes to AR System request IDs, see the Database Reference guide.
Handling duplicate request IDs

If you choose not to use site-specific request ID prefixes, duplicate request IDs might be generated. In some cases you might want the newer version of a request to overwrite the older version, but in other cases, you might want to keep all copies of a request. The Distributed Server Option performs one of the following actions when duplicate request IDs occur: Generates an error message and does not perform the transaction. Creates a new request ID for the newer copy. Overwrites the older copy of the request with the newer copy. By default, the overwrite action updates only the mapped fields on the target request, but you can configure this action to replace all fields on the target request. For more information, see Configuring overwrite behavior for duplicate request IDs on page 44. You should determine how you will handle duplicate request IDs for all your mappings, and if possible treat all mappings the same. Using different duplicate request ID strategies can cause administrative problems when tracking data.
Matching source and destination requests

By default, DSO uses request IDs to match source requests with destination requests. You can, however, use other matching qualifications based on fields in the source and target forms.
19
Using matching qualifications is useful when, for example, you have existing data in the source and destination forms and you do not want to use special request ID prefixes to distinguish entries created in one form from another. In this case, you specify a data field other than request ID to uniquely identify each entry. AR System uses that data field to match a destination request (if one exists) with the source request.
Note: A unique index should be created on the data field used to uniquely identify one request from another.
See Specifying distributed mapping options on page 65.
Defining distributed operations

You can perform four primary types of data transactions using the Distributed Server Option: transfers, updates, returns, and deletes. The main differences among these operations are how they are initiated (by filters or escalations, or automatically by the system) and how ownership of a request is treated. In the figures in this section, the forms that are darker in color represent the request that has ownership after the operation has been completed. For sample scenarios of how to perform each of these operations, see Chapter 5, Creating Distributed Server Option workflow.
Using distributed transfers

A distributed transfer transmits information from one server to another, and occurs when you enter or change information in a form. When a request is created or modified, the entry triggers workflow to create a copy of the information and then transfer it to another form. The transfer might include the entire request and all its information, or just specific data. A transfer is not automatically generated; you must create one by defining a mapping and creating a filter or escalation to perform the transfer. Before you begin implementing the Distributed Server Option, determine how much control you need over the data being transferred. Ask yourself the following questions: Should one server own master copies of the requests being transferred, or should all copies be independent of one another?
How often should I update requests on my server? How will I handle duplicate request IDs? Will I need to override the mapping control settings on a per-request basis?
Ownership and ownership chains

Ownership plays a large part in distributed operations, because having ownership of a request lets you make modifications to the information. Typically, you will transfer a request with ownership to a server that can address the request directly. Modifications can only be made in the request with ownership. When ownership is transferred with a request, you create an ownership chain. The active ownership chain begins with the request that has ownership, and extends to those requests from which ownership was transferred. For example, you have a request with ownership on server sanfrancisco, but the issue must be addressed from server chicago. You transfer that request with ownership to server chicagoyou transfer ownership so that chicago users can make necessary modifications to the request. Depending on your workflow configurations, server sanfrancisco might receive updates of the changes made on server chicago through a distributed update operation. Server sanfrancisco cannot, however, make modifications to the request unless the request is returned with ownership through a distributed return operation.
Note: The combination of transferring ownership and overwriting existing requests in a chained environment can create an infinite loop. To perform a chained distributed transfer, you must enable the Override Loop Detection option in the filter that performs the transfer. For more information, see Avoiding infinite loops on page 109.
21
Types of distributed transfer operations

Four types of transfer operations enable you to manage your requests on multiple servers. Data-only Data+Ownership Independent Copy Copy+Delete
Data-only
Data-only transfers let you transfer a request to another server, most typically for archiving and as future information resources. Because dataonly copies do not hold ownership, they cannot be modified and cannot begin an ownership chain.
Data+Ownership
Data+Ownership transfers let you transfer a request with ownership to another server so that users on the target server can make necessary modifications. Because a request with ownership is considered a master copy, you can make modifications that will be updated on all copies of the request within the ownership chain.
Independent copy
Independent copy transfers are like data-only transfers because they are transferred without ownership and do not receive updates from the master copythey are outside of the ownership chain. You can modify independent copies, which can start new ownership chains of their own.
Copy+Delete
Copy+Delete transfers let you transfer an independent copy of a request to a specified server, and then delete the original request. When defining your mappings for these transfer operations, consider what kind of data you are transferring. Dynamic data, such as an entry in a bug tracking form, is often modified at the site to which it is transferred. This type of data can be transferred in a data+ownership transfer. Static data, such as customer biographical information, is probably not modified at the site to which it is transferred, and can be transferred as a dataonly or independent copy.
Overriding mapping settings on a per-request basis

Sometimes individual transfers require you to use an existing mapping, but change how one or more of the functions defined in the Distributed Mapping window is used for the mapping. For example, you have a mapping with the standard transfer mode defined as data-only, but for one particular transfer performed by that mapping, you need to send data and ownership. The Distributed Server Option lets you add to any form distributed fields that accept the same values as their counterparts in the Distributed Mapping window. In turn, when a user submits or modifies data in the form, the workflow can assign values into the distributed fields to override the pre-set definitions in the distributed mapping. In the previous example, you would add distributed fields to the form in question, and then select Data+Ownership in the Transfer Mode field.
Note: In the figures in this section, the forms that are darker in color represent the request that has ownership after the operation has been completed. For sample scenarios of how to perform each of these operations, see Chapter 5, Creating Distributed Server Option workflow.
23
BMC Remedy Action Request System 7.0 Figure 1-1: Transfer flow
Original
1 Bug tracking form on server sanfrancisco. Original entry made here. 2 Entry transferred to server chicago.
Transfer Copy
For more information about how the AR System determines mapping criteria for a transfer, see Creating DSO actions in filters and escalations on page 82.
Using distributed updates

A distributed update is used to keep all copies of a request within an ownership chain current with the master copy. Modified information from the request with ownership is sent to all copies of a request within an ownership chain at a specified time interval. Updates occur automatically, depending on the update option specified in the mapping.
For example, you have a broken keyboard, so you submit a replacement request on server sanfrancisco. Because office equipment replacements are handled by server chicago, the request is transferred using a data+ownership distributed transfer operation (creating an ownership chain between sanfrancsico and chicago). After the keyboard has been replaced, the request status is changed to Completed. This status change triggers an update of the new information back to server sanfrancisco, updating their copy of the request. The Distributed Server Option provides five options to control when requests in an active ownership chain are updated by modifications to the master copy. You can specify to enable updates immediately, once an hour, once daily, on a distributed return operation, or not at all. Various factors should influence your determination of whether to update a request. If the mapping you define is between two forms whose requests are static, you probably do not need to update your copy, because the original and the copy will remain unchanged after the transfer. If you anticipate that users at the other site will modify distributed requests you make and that you require those modifications, then you will want to update your copy. If you decide you want to update requests on your server, you must determine the update interval. Some changes to requests will be so urgent that you will want to see those changes immediately. Other changes that are not so important can be deferred to a greater interval, such as hourly or daily. In other cases, you might only want your copy updated when another site is returning ownership of the request to you. The following figure shows the basic flow of a distributed update.
25
BMC Remedy Action Request System 7.0 Figure 1-2: Update flow
Original
2
Bug tracking form owned by server chicago. An entry is first modified here. The original is then updated on server sanfrancisco.
Update Copy
Using distributed returns

A distributed return is used to send the updated request, with ownership, back to the originating server. Distributed returns are triggered using a filter or escalation on the server that sends the returning request. Using the previous example from the Distributed Updates section, you have a broken keyboard, so you submit a repair request on server sanfrancisco. Because office equipment repairs are handled by server chicago, the request is transferred using a data+ownership distributed transfer operation (creating an ownership chain between servers sanfrancsico and chicago). After the keyboard has been fixed, the request status is changed to Completed.
Server sanfrancisco has requested, however, that the request with ownership be returned to server sanfrancisco after the status of the request is changed to Completed. When the status change is made, workflow is again triggered and the modified request with ownership is transferred back to server sanfrancisco, leaving a data-only copy of the request on server chicago. The request can now be modified on server sanfrancisco again, if necessary. The following figure shows the basic flow of a distributed return with ownership.
Figure 1-3: Return flow
Original
1 Bug tracking request on server chicago. The return is triggered here. 2 Ownership is returned to server sanfrancisco.
Return Copy
27
Using distributed deletes

A distributed delete lets you delete copies of a request. If you delete the master copy in an active ownership chain, all copies of the request are deleted within the ownership chain. Additional delete capabilities lets you delete specific requests, including data-only requests. You must specify a separate filter or escalation action to run the Distributed Delete process for each copy of the request. For more information about ownership chains, see Ownership and ownership chains on page 21. For example, an employee finds that his phone does not work and submits a repair request on server sanfrancisco. Because telecommunication services are handled by server chicago, the request is transferred using a data+ownership distributed transfer operation (creating an ownership chain between servers sanfrancsico and chicago). However, the employee later discovers that his phone is unplugged, not broken, and calls the service center to cancel the repair request. Instead of changing the status of the request to Completed, the support person changes the status to Canceled. Previously configured workflow executes a distributed delete operation when the status changes to Canceled, and deletes the master copy of that request on server chicago, as well as the copy of that request on server sanfrancisco.
Note: All copies of a request within an ownership chain are deleted in a distributed delete operation.
Overview of setting up distributed operations

To set up distributed operations between similar or different forms, follow these basic steps, which are detailed in this manual.
Step 1 License and start the Distributed Server Option on every server involved in a
DSO transfer.
Note: You do need not to have DSO license on target server if it is not sending any response back to source server.
Step 2 Determine which forms need to be mapped to each other. Step 3 Determine whether you will use distributed pools, based on the volume of
distributed operations that will be processed.

Step 4 Determine the amount of control you need over the data being transferred. Step 5 Decide which ownership and control capabilities you need and, if necessary,
add the appropriate fields to each form. For more information, see Working with distributed fields on forms on page 50, and To specify or change distributed mapping transfer definitions on page 70.
Step 6 Using BMC Remedy Administrator, log in to all servers to be used in the
distributed operation.
Step 7 Select an appropriate server, the Forms server object, and an applicable form,
according to the forms you selected in Step 2.

Step 8 Add distributed fields to each form using the Distributed Fields window,
depending on the level of control decided on in step 4. If you plan to transfer requests with ownership, you need to add appropriate distributed fields to every source and target form on each server. Repeat steps 7 and 8 for each applicable form. For more information about distributed fields, see Working with distributed fields on forms on page 50.
Overview of setting up distributed operations
29
Step 9 Create a new Distributed Mapping object on each server involved.
This object identifies the From and To servers and their corresponding forms, and specifies options such as transfer of ownership and frequency of updates. For more information, and for descriptions of the fields on each tab of the Distributed Mapping window, see Creating and modifying distributed mappings on page 60.
Step 10 Create a new Distributed Pool object on each applicable server for each set
of related distributed operations, according to your analysis in step 3. Each object defines a new pool or thread within the Distributed Server Option to handle pending distributed operations. After defining a pool, you must associate DSO filter or escalation actions with the pool. Assign all related operations to the same pool, because operations assigned to different pools might execute out of the intended sequence. For general information about distributed pools, see Using distributed pools on page 18. For information about creating, modifying, and deleting distributed pools, see Working with distributed pools on page 78.
Step 11 Create a filter or escalation that defines the conditions under which a data
transfer, return, or delete will occur. For a discussion of distributed operations triggered by filters and escalations, see Using filters and escalations for DSO actions on page 82.
Step 12 Optionally, employ some of the advanced functions discussed in the
appendixes. Unless otherwise noted, examples in this guide assume you are mapping between two servers. If you need to maintain data integrity on more than two servers, you can extend your usage of the Distributed Server Option by incorporating additional servers into your environment. For information about using more than two servers in your distributed environment, see Advanced topics on page 107
Note: For functional examples of setting up each distributed operation for Acme Industries, a manufacturer of custom office furniture, see Chapter 5, Creating Distributed Server Option workflow.
Chapter
Licensing DSO
This chapter provides information about licensing the AR System. The following topics are provided: Overview (page 32)
Licensing DSO
31
Overview
AR System licensing grants the full and legal use of AR System and is necessary for performing operations that change or update the database (for example, updating requests or records). To run an unlimited AR System server at your site, an AR System server license is required. There are additional AR System server options, such as the Distributed Server Option (DSO) and Flashboards that require a separate, additional license. In addition to server and server option licenses, AR System has user licenses. There are four kinds of user write licenses you can use to access the AR System server: read, restricted read, fixed write, and floating write. The base AR System product, once licensed with the AR System server license, comes with three Fixed Write licenses, unlimited Read licenses, and unlimited Restricted Read licenses. You can purchase additional user Fixed Write licenses and user Floating Write licenses by contacting your BMC Remedy Product sales representative or an authorized reseller. You can evaluate the Action Request System without purchasing or activating any licenses. However, you are limited to a maximum of 2000 records per form. If you plan to install any AR System application that requires a license key (for example, DSO), you can obtain the license key information for all your products at one time. You can then submit a single license key request to take care of all your applications at once. For information about obtaining and activating AR System server, server option, user, and application licenses, see the Configuring guide.
32 Chapter 2Licensing DSO
Chapter
Configuring the distributed server

This chapter describes how to configure general settings for the Distributed Server Option. The following topics are provided: Setting up the local and remote DSO servers (page 34) Upgrading previous versions of AR System (page 43) Specifying a DSO host name for distributed mappings (page 44) Configuring overwrite behavior for duplicate request IDs (page 44) Configuring the RPC timeout setting (page 45) Configuring DSO for load balancing (page 45) Using debug trace mode to create log files (page 46) For more information about Action Request System (AR System) server management, see the Configuring guide and the Optimizing and Troubleshooting guide.
Configuring the distributed server
33
Setting up the local and remote DSO servers

AR System 7.0 lets you configure AR System servers involved in distributed operations with different RPC program numbers, port numbers, and passwords through server information settings. Server information settings for this release of the Distributed Server Option have changed. If you have upgraded from a previous version, your original settings are preserved and can be accessed through the ar.cfg (Windows) or ar.conf (UNIX) file. You might want to migrate to the new settings. See the Release Notes for upgrade instructions.
Configuring a local AR System server

If you want to configure communication, firewall protection, and password security, you must do so for the local DSO server before configuring any remote DSO servers. After you configure the local AR System server, you enter information for remote AR System servers. For more information about configuring remote AR System servers, see Configuring a remote AR System server on page 41.
Assigning a dedicated RPC program number to a local server

Although using specific RPC program numbers is not required by the Distributed Server Option, you might decide to assign specific RPC program numbers if you have a large environment with heavy data traffic, or if your environment has a large amount of distribution. If you plan on using a specific RPC program number, it must be either 390600 (the Administrator program number) or in the following range: 390621 to 390634, 390636 to 390669, or 390680 to 390694, the range for private servers. The distributed server uses the assigned program number for all communication. To assign the Distributed Server Option to a specific RPC program number, configure the AR System server to define at least one thread on the specified private server program number. The Distributed Server Option process does not connect directly to the database itself. This configuration tells it which AR System server queue to communicate with. In the default configuration, the Distributed Server Option process joins the fast and list queues like any other client.
34 Chapter 3Configuring the distributed server
This configuration setting sets the distributed server to use the RPC program number for access to the local server. To configure remote servers, see Configuring a remote AR System server on page 41.
To assign a dedicated RPC program number to a local server

Note: The Private RPC program number must be added in the Server Ports and Queues tab of the Server Information dialog box before configuring the DSO local RPC program number.
1 In BMC Remedy Administrator, open a server window and select the local
server.
2 Choose File > Server Information.
The Server Information window appears.

3 Select the Connection Settings tab. 4 On the Connection Settings tab, click the DSO Server tab. 5 In the Local RPC Program Number field, enter the RPC program number for
your local server, as shown in the following figure.
35
BMC Remedy Action Request System 7.0 Figure 3-1: Server Information window, Connection Settings tab
6 Click OK or Apply to save RPC program number settings.
If you reassign the RPC program number while running the Distributed Server Option, you will not lose any work and the changes are transparent to the user. The AR System server, however, must be stopped and restarted as described in Licensing DSO on page 31.
Running the Distributed Server Option behind a firewall

You can run AR System servers behind a firewall by adding a TCP/IP port number in the Server Ports and Queues window, as shown in the following figure.
Administering BMC Remedy DSO Figure 3-2: Server Ports and Queues tab, TCP/IP Port field
To connect to another machine behind the firewall, you must specify the Local Password and the TCP/IP Port number for the machine to which you want to connect.
37
BMC Remedy Action Request System 7.0 Figure 3-3: Connection Settings tab, Local Password and Local RPC Program Number fields
WARNING: Do not assign a port number that conflicts with port numbers used by other applications or other programs running on your system. To find out which port numbers are already in use, use the netstat -a command (Windows) or the rpcinfo -p command (UNIX) at the command line prompt. If you do not check available ports, you might assign a port number that conflicts with other applications, and your servers might not start as expected.
To configure Distributed Server Option to run behind a firewall

server.
2 Choose File > Server Information.
The Server Information window appears.
3 Select the Server Ports and Queues tab. 4 In the Server TCP/IP Port field, enter the port number used for the local
server.
5 Click OK to save your settings.
For more information about configuring servers in the AR System environment, see the Configuring guide. For information about registering with a portmapper, see the Installing guide.
Configuring password security on the local DSO server

The Distributed Server Option performs all operations as the fixed user, Distributed Server. You are not required to create a user named Distributed Server as it is automatically created by AR System Server. The Distributed Server user has controlled permissions and a locked name, but does not require any additional licensing. To control server communication and user access in Distributed Server operations, you will need to configure passwords in BMC Remedy Administrator for both the local and remote distributed servers. By configuring passwords for both local and remote servers, you can limit which servers can communicate with each other through the Distributed Server Option, and prevent unauthorized access to AR System. A server with password settings can transfer information to a server that does not have password settings. A server without password settings, however, cannot transfer information to a server with password settings, unless the target connection password is set for that server. That is, transfers will not work if the target connection password does not match the settings on the destination server.
Note: Older clients will not ask for these passwords when talking to a newer server. Newer clients talking with older servers will receive an ARERR 218
Server information associated with this tag cannot be retrieved
error message.
39
Note: If you are creating passwords for the Application Service and DSO server, you can set the minimum API version to 10 to make sure that secure 7.0 servers cannot communicate with servers running previous AR System versions. For information about setting the API version, see the Configuring guide.
To configure password security for a local AR System server

server.
2 Choose File > Server Information. 3 From the Server Information window, click the Connection Settings tab, and
then click the DSO Server tab.

Figure 3-4: Connection SettingsDSO Server tab
4 Enter the password into the Local Password field.
Note: The DSO Local Server Password can be any string up to 30 characters.
5 Click OK.
You must stop and restart the AR System server for connection settings to take effect.
Configuring a remote AR System server

You can configure all remote servers with password security, assign dedicated RPC program numbers, and assign TCP/IP port numbers using the Connection Settings tab of the Server Information window.
To configure a remote AR System server for Distributed Server Option operations

1 In BMC Remedy Administrator, open a server window and select a remote
server.
2 Choose File > Server Information to open the Server Information window. 3 Select the Connection Settings tab, and then click the DSO Server tab. 4 In the Target Connection Settings pane, enter the following information, if
applicable: Server Name Password RPC Program Number PortIf the remote target server is running behind a firewall, you will need to enter a port number.
41
BMC Remedy Action Request System 7.0 Figure 3-5: Connection SettingsDSO Server tab
5 Click OK or Apply. 6 Repeat this procedure for each remote server.
Note: You must restart each AR System server for the connection settings to take effect.
Upgrading previous versions of AR System

In versions of AR System prior to 5.1, you configure RPC program and port numbers using the Distributed-RPC-Socket and DSO-private-dest-port settings. Now, you can configure these settings using BMC Remedy Administrator as explained in Configuring a local AR System server on page 34, but you will need to delete the settings in the ar.cfg (Windows) or ar.conf (UNIX) file, or they will override settings made in BMC Remedy Administrator. After you upgrade the AR System and use the new methods for setting the RPC program and port numbers, the Distributed Server RPC Program Number field in the Server Information window will appear disabled. To set RPC program numbers and ports for local and remote servers, review the procedures that begin with Setting up the local and remote DSO servers on page 34.
To remove RPC program and port number settings from configuration files (Windows)
1 Open the ar.cfg file. The typical path is <install_dir>\Conf\ar.cfg. 2 Delete the Distributed-RPC-Socket and DSO-private-dest-port settings. 3 Save the file. 4 Repeat this procedure for each associated AR System server. 5 Stop and restart each applicable AR System server.
To remove RPC program and port number settings from configuration files (UNIX)
1 Open the ar.conf file. The typical path is <install_dir>/conf/ar.conf. 2 Delete the Distributed-RPC-Socket and DSO-private-dest-port settings. 3 Save the file. 4 Repeat this procedure for each associated AR System server. 5 Stop and restart each applicable AR System server.
Upgrading previous versions of AR System
43
Specifying a DSO host name for distributed mappings

The DSO uses the default server name for the From server, unless you specify the DSO host name parameter. The DSO host name parameter will override the From Server reference in the filter DSO action and DSO mapping. You can configure the AR System to use the fully qualified domain name (FQDN) or long name for distributed operations, as required by some operating environments. The DSO will place this name into the From Server field, if this field is on the form. See Working with distributed fields on forms on page 50 for more information about adding distributed fields to forms.
To specify a DSO host name for distributed mappings

1 Stop the Action Request System Server service. 2 Open the ar.cfg file (Windows) or ar.conf file (UNIX). 3 Enter the host name in the following format:
DSO-Host-Name: <host>.<domain>
where <host> is the short name of the From server, such as sanfrancisco, and <domain> is the domain name of the From server, such as acme.com.
4 Save the ar.cfg file (Windows) or ar.conf file (UNIX). 5 Start the Action Request System Server service.
For more information about server names in the Action Request System environment, see the Configuring guide.
Configuring overwrite behavior for duplicate request IDs

If you select the overwrite action for handling duplicate request IDs, the default behavior updates only the mapped fields on the target request. You can configure the overwrite action to overwrite the contents of the target request.
To configure overwrite behavior for duplicate request IDs

1 Stop the Action Request System Server service. 2 Open the ar.cfg file (Windows) or ar.conf file (UNIX).
3 Enter the following flag to update mapped fields and set unmapped fields to
NULL:
DSO-Merge-DupID-Overwrite: T
4 Save the ar.cfg file (Windows) or ar.conf file (UNIX). 5 Start the Action Request System Server service.
For more information about strategies for handling duplicate request IDs, see Handling duplicate request IDs on page 19.
Configuring the RPC timeout setting

You can configure the RPC timeout setting for pending distributed operations to accommodate slow network connections or large amounts of data. If you do not configure this setting, the system uses a default timeout.
To configure the RPC timeout setting

1 Open the ar.cfg file (Windows) or ar.conf file (UNIX). 2 Enter the RPC timeout flag in the following format:
DSO-Timeout-Normal: <time in seconds>
where time represents the number of seconds before a timeout occurs. The timeout value must be an integer between 60 and 21600, which configures the timeout for periods ranging from 60 seconds to 6 hours.
3 Save the ar.cfg file (Windows) or ar.conf file (UNIX). You do not need to
restart the Action Request System Server service for the setting to take effect.
Configuring DSO for load balancing

To configure DSO for load balancing, in addition to the hardware load balancer, you must have multiple server machines using a single database. You can use server groups to configure multiple server machines to use a single database. In addition to allowing multiple servers to use a single database, using server groups provides increased scalability and reliability, and allows several servers to be managed as a unit. If you implement server groups, there is no further AR System configuration necessary to implement load balancing. See the Configuring guide.
Configuring the RPC timeout setting
45
For more information about configuring DSO for load balancing, see the BMC Remedy white paper, Using a Hardware Load Balancer with AR System 6.0 Servers, which is located on the Customer Support website at http:// supportweb.remedy.com.
Using debug trace mode to create log files

The Distributed Server Option includes a debug trace mode. In debug trace mode, distributed operation tracing is active and the AR System creates two log files of distributed server activity. One log file is for the general distributed server activity; the other is for the distributed pool server activity. You can activate logging at any time; logging will start immediately. Each log file is flushed and restarted when you restart the Distributed Server Option or when you reactivate logging after it has been deactivated. When this occurs, the previous log file is written to <logname>.bak. You should be aware that this log file consumes increasing amounts of disk space as messages accumulate. You cannot limit the size of this log file, as you can other log files, in the Server Information window. You might want to monitor your disk resources carefully while logging is active. You can enter a location and name other than the default location and name for the log files created in debug mode. See the Optimizing and Troubleshooting guide for more information about using log files; see the Configuring guide for information about setting debug modes.
To set up distributed server logging

1 In BMC Remedy Administrator, open a server window and select a server. 2 Choose File > Server Information.
The Server Information window appears

3 In the Server Information window, click the Log Files tab, as shown in the
following figure.
Administering BMC Remedy DSO Figure 3-6: Server Information windowLog Files tab
4 Select the Distributed Server check box to enable debug trace mode and make
the File Name field available. You can specify a path and file name for a distributed server log file, or you can accept the default path and file name by leaving this field blank.
Important: When naming log files, do not use special characters (such as : and / and ?). Use alphanumeric characters only.
5 Click OK or Apply to activate distributed server logging.
Using debug trace mode to create log files
47
Chapter
Implementing the Distributed Server Option

This chapter describes the steps you must follow to implement a distributed mapping using BMC Remedy Administrator and then shows you how to administer the data transfer flow between forms. The following topics are provided: Working with distributed fields on forms (page 50) Working with distributed mappings (page 57) Specifying distributed mapping returns (page 74) Working with distributed pools (page 78) Using filters and escalations for DSO actions (page 82) Controlling pending transfer information (page 90) Only users with permissions will be able to configure the Distributed Server Option in BMC Remedy Administrator. See the Form and Application Objects guide for information about defining access control.
Important: You must obtain a separate license for the source server in your distributed environment, or the distributed menu items will not appear in BMC Remedy Administrator. For information about licensing servers, see Licensing DSO on page 31.
The target server does not need a DSO license if the target server is not sending a response back to source server.
Implementing the Distributed Server Option
49
Working with distributed fields on forms

This section discusses the Distributed Fields window, which is used to modify different configurations of reserved fields on forms. In most cases, the first action you take when creating a distributed mapping is to decide which forms you want to make distributedthat is, which ones will be transferring some or all of their data to forms on different machines. A number of reserved fields can be added to the forms. These fields, described in this section, are used to support various functions of the system.
WARNING: If you already have added distributed fields to your forms in a previous version of the AR System, you must open each form in BMC Remedy Administrator and re-add the distributed fields. This will help you make sure that the new From Pool distributed field is also present on your forms.
Note: If a form used in a distributed server operation is archived, the distributed fields will be copied to the archive form but will not be updated. You cannot add distributed fields to an archive form.
See Table 1-1 on page 17 for distributed fields grouped by level in the Distributed Fields window.
Using the distributed fields window

You must, at a minimum, add Basic distributed fields to all forms that will be involved in transfers with ownership. These distributed fields hold information used in request return and update operations. Use the Distributed Fields window, shown in Figure 4-2 on page 58, to: Add distributed fields to or delete distributed fields from a specified form. You can also adjust the levels of distributed fields on a form by changing the distributed fields to a higher or lower selection. For example, if you currently use Advanced fields on a form, you can open the Distributed Fields window and select a lower option like Full or Basic. Select the views to which distributed fields are added. Control whether added distributed fields will be visible to users.
50 Chapter 4Implementing the Distributed Server Option
To add and delete distributed fields

1 In BMC Remedy Administrator, open a server window and select a server.
A list of server objects appears.

2 Click the Forms server object to see a list of available forms. 3 From the Forms list, double-click the form you want to open. 4 Choose Form > Distributed Fields.
The Distributed Fields dialog box appears, as shown in the following figure.
Figure 4-1: Distributed Fields window
51
5 In the Distributed Fields dialog box, select a Distributed Fields option. The
following table shows available options:

Distributed Fields Option None Description If your form contains previously added distributed fields, selecting None will delete all distributed fields. If your form does not contain distributed fields and select None, you will not be able to click OK to save your changes. Adds only the distributed fields necessary for basic mapping functionality and establishing ownership. Values for these fields are automatically set by the Distributed Server Option.
Note: All the Basic fields are system-generated. Several of the
Basic
fields are protected and can only be overridden using the ardist program, which is described in Appendix B, Distributed Server Administration program. The Basic fields are: Transfer StatusSee Transfer and update status on page 55 for details. Update StatusSee Transfer and update status on page 55 for details. Master FlagA Yes/No flag that indicates whether this request holds ownership. From Request IDThe ID of the original request from which this copy was transferred. From FormThe form from which this request was transferred. From ServerThe server from which this request was transferred. From PoolThe distributed pool on the From server that processed the distributed operation.
Distributed Fields Option Full
Description Used for greater control over choice of mappings when multiple mappings exist from the same server and form based on precedence. For more information about precedence, see Controlling distributed mapping selection. The Full selection includes all Basic fields, and also the following fields: To MappingIf this field is filled in, it tells DSO which mapping to use when transferring the request. If the mapping specified in this field does not exist or is disabled, the distributed operation will fail. From MappingThe mapping that was used during a transfer to create this request. Only DSO can set the value for this field. To Request IDThe ID of the request to which the data was transferred. Only DSO can set the value for this field. To FormThe form to which to transfer the request. The DSO looks for a mapping based on this field and the To Server field, if they have been set. If no mapping to the specified form exists, the distributed operation will fail. To ServerThe server to which to transfer the request. The DSO looks for a mapping based on this field and the To Form field, if they have been set. If no mapping to the specified server exists, the distributed operation will fail. Mapping HistoryA history-tracking record created at the time of transfer. Includes the date and time of transfer, source Request ID, source form, source server, and the name of the specific mapping used. The result is a record of all transfers to this request. Only the DSO can set the value for this field.
Note: This field is provided as an unlimited-length character
field. If you set a maximum field length for this field, records might be truncated. Current FormThe form in which the master copy of the request resides. Only DSO can set the value for this field. Current ServerThe server on which the form with the master copy of the request resides. Only DSO can set the value for this field.
53
Distributed Fields Option Advanced
Description Used to override certain mapping characteristics on a perrequest basis. For example, if you enter a value in an Advanced distributed field, that value will override the characteristic setting in the mapping used for the distributed operation. The Advanced selection includes all Basic and Full fields, and also the following fields: When to UpdateThe frequency with which to update the original request if a transferred copy is updated. Transfer ModeType of transfer to perform. Valid transfer types are Copy+Delete, Data+Ownership, Data Only, and Independent Copy. Duplicate Request ID ActionThe action that will occur if
you transfer a request and there is already a request with the same Request ID in the To form
Max Time to Retry Enforce Pattern Matching Require Required Fields Matching Qualification The Advanced field names correspond to the Options tab field names, with the exception of Max Time to Retry field, which is called the Retries field on the Options tab. For more information about Advanced fields, see Specifying distributed mapping options on page 65. 6 For forms with multiple views, select the views from the Add New Fields to
Views pane. Distributed fields will be added to or deleted from these views. If you do not select individual views, the distributed fields will be added to all form views by default.
7 To add distributed fields as visible fields, clear the Add as Hidden Fields check
box. To add distributed fields as hidden fields, select the Add as Hidden Fields check box.
8 Click OK.
If you are adding distributed fields to your form, the selected distributed fields appear at the bottom of your form. If you are deleting distributed fields from your form and selected None or a lower distributed mapping option, a warning appears to confirm that you want to go from a higher mapping type to a lower mapping type. Click Yes.
WARNING: When you delete a field on a From form that has been mapped to a field on a To form, you undo the mapping to the To Form field. If the To Form field is optional, only data transferred between the two mapped fields is affected. If the To Form field is required, the entire transfer operation will fail.
9 Rearrange the distributed fields on the form, if necessary, and click Save.
After adding distributed fields, an alert notice appears for each added field to which only the administrator has access (if your preferences are set this way). For more information about setting preferences, see the Configuring guide. If you have removed distributed fields, a final warning notice appears listing the fields that will be deleted.
Transfer and update status

When you add basic distributed fields to a form, two of the fields added are Transfer Status and Update Status. These fields are included so that you can: Examine the results of distributed operations. Set up filters to watch for failures. Set up escalations to watch for distribution problems.
55
Transfer status
If the form from which entries are being transferred contains the Transfer Status field, the value of the Transfer Status field is set to one of the values from the following table after a transfer is attempted.
Value Success Retry Definition The transfer was completed successfully. The transfer failed, but the mapping is still pending. The failure was caused by a situation that might correct itself (such as a time out, or a server being down). DSO retries the transfer as follows: Every 5 minutes for the first 30 minutes. Every 30 minutes, after the initial 30 minutes and up to 24 hours. Every hour after the initial 24 hours. Failure The transfer failed. The pending distributed operation has been deleted and will not be re-attempted. The failure was such that future attempts will also fail. The transfer was retried until the retry time expired. For more information, see Specifying distributed mapping options on page 65. The transfer was deleted from the pending table before it could be processed. This status would appear if you deleted a pending item from the Pending Distributed Operations window. For more information, see Using the pending distributed operations window on page 90.
Timeout
Canceled
Update status
If the form from which entries are being updated or returned contains the Update Status field, the value of the Update Status field is set to one of the values from the following table after an update or return is attempted.
Value Success Waiting Definition The update/return was completed successfully. The update is waiting for the next transfer time indicated by the setting in the When to Update field. This state is not used for immediate mappings.
Value Retry
Definition The update/return failed, but the mapping is still pending. The failure was caused by a situation that might correct itself (such as a time out, or a server being down). DSO retries the update/return retries as follows: Every 5 minutes for the first 30 minutes. Every 30 minutes, after the initial 30 minutes and up to 24 hours. Every hour after the initial 24 hours.
Failure Timeout
The update/return failed, and the mapping has been deleted and will not be re-attempted. The request was retried until the retry time expired. For more information, see Specifying distributed mapping options on page 65. The request was deleted from the pending table before it could be processed. For more information, see Controlling pending transfer information on page 90.
Canceled
Working with distributed mappings

This section describes how to create and modify distributed mappings using the Distributed Mapping window. For details about creating mappings for specific distributed operations, see Chapter 5, Creating Distributed Server Option workflow.
Using the distributed mapping window

You create and modify distributed mappings within the Distributed Mapping window. The Distributed Mapping window consists of six sections or tabs that let you customize how AR System entries are processed across multiple servers. As described in Chapter 1, Using the distributed server environment, mappings execute on the server when a distributed operation is attempted. The Distributed Mapping window is shown in the following figure.
57
BMC Remedy Action Request System 7.0 Figure 4-2: Distributed Mapping windowBasic tab
For each server involved in ownership transfers and returns, you must define a separate, compatible distributed mapping. That is, to exchange information between server 1 and server 2, you must have a distributed mapping on each server. It is a good practice to use the same distributed mapping name and to have the same criteria selected in each of the tabs. You can use DSO to distribute copies of distributed mappings to other servers. This lets you administer from one server and make sure that all mappings stay synchronized. Use the tabs in the Distributed Mapping window to define the following information:
Basic Options The basic properties of a distributed mapping, including server and form information. The update frequency, transfer type, same Request ID resolution, pattern checking in fields on the target form, allowance of NULL in required fields on the target form, and number of times to retry sending a request.
Transfer Return
How the contents of a source request (From form) are mapped to a target request (To form) during transfer. How the contents of a target request (To form) are mapped back to a source request (From form) during a return or update. Help Text for the distributed mapping. In most cases, the supplied help text is simply a description of the distributed mapping provided to AR System administrators and subadministrators for viewing and editing. For each distributed mapping, information about the owner, the user who last modified the mapping, and the date of the modification.
Help Text
Change History
59
Creating and modifying distributed mappings

This section describes how to create a distributed mapping or to open and modify, copy, or delete an existing distributed mapping.
WARNING: Before you modify the name of a distributed mapping, first verify that it is not associated with a packing list. BMC Remedy Administrator will not update the name of a distributed mapping in a packing listthe distributed mapping is removed and you must restore it to the packing list under the new name.
Creating distributed mappings

Follow these steps to create a new distributed mapping.
To create distributed mappings

1 In the server window, select a server to administer by clicking it. 2 Choose File > New Server Object.
The New Server Object window appears.

3 Select Distributed Mapping from the New Server Object list, and then click
OK. The Distributed Mapping window appears, as shown in Figure 4-2 on page 58.
4 Specify required distributed mapping basic specifications according to the
steps described in Specifying distributed mapping basics on page 63.

5 Specify optional distributed mapping options according to the steps
described in The following figure shows the Options tab for distributed mappings. on page 65.
6 Specify optional distributed mapping transfer specifications according to the
steps described in The Return tab for distributed mapping is shown in the following figure. on page 75.
7 Specify optional distributed mapping return specifications according to the
steps described in The Return tab for distributed mapping is shown in the following figure. on page 75.
Opening distributed mappings

Use the following procedure to open and modify an existing distributed mapping.
To open a distributed mapping

1 Open a server window. 2 Select a server to administer by clicking it.

3 Click the Distributed Mappings server object to see a list of distributed
mappings currently defined on the server.

4 From the Distributed Mappings list, double-click the distributed mapping
you want to open. The distributed mapping appears in the Distributed Mapping window, as shown in Figure 4-2 on page 58. You can modify the distributed mapping as needed.
Copying distributed mappings

A copy of a distributed mapping contains all the properties of the original distributed mapping. The only difference is the name.
WARNING: Before you modify the name of a distributed mapping, first verify that it is not associated with a packing list. BMC Remedy Administrator will not update the name of a distributed mapping in a packing listthe distributed mapping is removed and you must add it back into the packing list under the new name.
To copy a distributed mapping


61
4 From the Distributed Mappings list, open the distributed mapping that you
want to copy and choose File > Save Distributed Mapping As. The Save Distributed Mapping As window appears.
5 In the Distributed Mapping field, enter the name of the new distributed
mapping.
6 Click OK.
The new distributed mapping appears in the Distributed Mappings list.
Deleting distributed mappings

The delete operation is permanent and cannot be undone. Make sure you no longer need a distributed mapping before deleting it. You cannot delete any distributed mapping that is currently open.
To delete a distributed mapping



4 Select the distributed mapping you want to delete. 5 Choose Edit > Delete > Distributed Mapping. 6 Click OK button on the confirmation window to delete the distributed
mapping. The distributed mapping is deleted from the server. For more information about setting preferences, see the Configuring guide.
Specifying distributed mapping basics

You use the Basic tab in the Create Distributed Mapping or Modify Distributed Mapping window to specify the basic properties of a distributed mapping, including: The name of the distributed mapping. Whether the distributed mapping is enabled. Whether the distributed mapping is the default mapping. The name of the server from which the request is mapped. If the from server is part of a server group, whether the mapping can use any server in the group as the from server. The name of the form from which the request is mapped. The name of the server to which the request is mapped for a transfer. The name of the form to which the request is mapped for a transfer.
To define basic properties for a distributed mapping

1 Open the distributed mapping with which you want to work, as described in
Opening distributed mappings on page 61, and click the Basic tab.
2 If the correct name is not already assigned to the distributed mapping, type
the correct name in the Distributed Mapping Name field. Distributed mapping names can be up to 80 characters, including blanks.
3 If applicable, select the Enable check box to enable the distributed mapping. 4 If applicable, select the Default Mapping check box.
The default mapping option specifies that this mapping is used by default for transfers between the From and To servers, and From and To forms, if no specific mapping is indicated in the filter during a Distributed Transfer operation. For more information, see Specifying a distributed transfer on page 84. For any pair of From and To servers and From and To forms, only one distributed mapping should be defined as the Default Mapping. If two or more are selected as defaults, the system will select one when no specific mapping is indicated.
63
5 In the From area, Server Name field, enter the name of the server from which
you want to map a request, or select a server from the list. This is the server from which the transfer operation is initiated. You can map a distributed mapping form from any server on which you are a valid user.
Note: You can specify a server name other than the default server name for distributed operations. For example, your operating environment might require you to use the fully qualified domain name (FQDN) for your server. See Specifying a DSO host name for distributed mappings on page 44 for more information.
6 If the server from which the transfer operation is initiated is part of a server
group and you want to allow a transfer to be initiated from any server in that group, select the Allow Any Server in Server Group check box. See Using DSO with server groups on page 13 for more information.
Note: This check box is enabled only when the server you specify is part of a server group.
7 In the From area, Form Name list, select the form from which you want to
map a request. This is the form from which the transfer operation is initiated.
8 In the To box, Server Name field, enter the name of the server to which you
want to map a request, or select a server from the list. This is the server to which the transfer is performed and is the server from which update and return operations occur.
9 From the To box, Form Name list, select the form to which you want to map
a request. This is the form to which the transfer is performed.

10 Choose File > Save Distributed Mapping.
11 Specify the distributed mapping options, if necessary, as described in the next
section.
WARNING: If you make any changes to a To form or a From form used in a custom mapping, the custom mapping might be invalid until you make the appropriate changes to the mapping itself. For information about custom mappings, see To specify custom mapping fields on page 72.
Specifying distributed mapping options

You can specify the following distributed mapping options: Frequency with which to update the original request if a transferred copy is updated Type of transfer to perform Action that will occur if you transfer a request and there is already a request with the same Request ID in the To form Whether to enforce patterns defined in fields on the target form Whether to require values in fields defined as required fields on the target form Maximum times a distributed operation request will be retried before the system cancels the operation Whether to use entry IDs or some other qualification to find the correct entry in the target form The following figure shows the Options tab for distributed mappings.
65
BMC Remedy Action Request System 7.0 Figure 4-3: Distributed Mapping windowOptions tab
To specify distributed mapping options

1 Make sure the distributed mapping basics are specified correctly according to
the instructions provided earlier in this chapter.

2 From the When to Update list, select the update frequency for the original
request, if a transferred copy with ownership is updated:

Daily Hourly Immediately No Update On Return Update the original at two minutes past midnight. Update the original at two minutes past the hour. Update the original immediately upon change to the request. Do not update the original request. Update the original only when ownership is returned.
3 From the Transfer Mode list, select the type of transfer to perform: Copy+Delete Data+Ownership Used to transfer an independent copy of this request. Deletes the original on the current server upon success. Used to transfer a copy with ownership, so the copy can be modified after the transfer. At a minimum, you must have added the Basic distributed fields to a form, as described in Working with distributed fields on forms on page 50, to transfer ownership. The copy with ownership is automatically the master and the original becomes a dataonly copy. Used to transfer a data-only copy and retain ownership locally. The master flag for the copy is set to No. The master flag for the original is set to Yes. Used to transfer an independent copy (without ownership). The new copy is independent of the original, with no linkage. The Transfer Status and To Request ID distributed fields are set on the source request, if present. No distributed fields are set on the target request.
Data Only
Independent Copy
4 From the Duplicate Request ID Action menu, select the action that will occur
if you transfer a request and there is already a request with the same Request ID in the To form:
Create New Error Overwrite A new request is created for the transfer. The transfer fails. The transferred request overwrites only the mapped fields on the existing request with the same Request ID.
Note: The Distributed Server Option always creates a new ID on the target server for the transferred request if you do not map the Request ID field.
5 From the Enforce Pattern Matching menu, select Yes or No.
If you select Yes, the target system will perform a pattern check on data sent to the target form. Data transferred to fields on the target form must follow pattern attributes defined in mapped fields on the target form. If you select No, the target system will not perform a pattern check on data sent to the target form.
67
For example, you map two character fields. The field on the target form has a pattern attribute of $LOWER$ defined in its field properties. A user enters uppercase letters in the mapped field on the source form. When the system attempts a distributed transfer, the operation will succeed or fail depending on whether you enforce a pattern match on data entered in the source form. Other attributes, such as the Range attribute for integer fields, are also subject to pattern matching. For more information about field pattern attributes, see the Form and Application Objects guide.
6 From the Require Required Fields menu, select Yes or No.
If you select Yes, the target system will not allow NULL entries in required fields on the target form. Optional fields on the source form must contain data if they are mapped to required fields on the target form. If you select No, the system will allow NULL entries in required fields on the target form, except in the core fields. For example, you map an optional field on the source form to a required field on the target form. A user enters no data in the optional field on the source form. When the system attempts a distributed transfer, the operation will succeed or fail depending on whether you allow NULL entries in required fields on the target form.
7 In the Retries box, select the maximum times a distributed operation request
will be retried before the system cancels the operation:

Forever Only Once Try for Maximum of The request is retried until the operation is successful. The request is sent one time, with no retries if the operation does not succeed. The request is retried for the amount of time you specify.
8 Specify how to qualify requests to be sent.
Select the Match by Entry ID check box to perform distributed transfers only when the destination Entry ID matches the source Entry ID. Clear the Match by Entry ID check box and specify a qualification to match destination and source data stored in fields other than the Entry ID.
You might use this method of matching entries, for example, if you had existing data in the source and destination forms and did not want to use special entry ID prefixes to distinguish entries created in one form from another. In this case, you use a different data field to uniquely identify each entry and to match a destination entry with the source entry.
Note: A unique index should be created on the data field used to uniquely identify one entry from another.
For details about how to specify qualifications, see Building Qualifications in the Getting Started guide.
9 Save the distributed mapping. 10 Specify distributed mapping transfer options, if necessary. See Specifying
distributed mapping transfers.
Specifying distributed mapping transfers

Distributed mapping transfer definitions identify how the information in a source request (From form) is mapped to a target request (To form) during a transfer. Use the Transfer tab to define the following items: Preferred mappingField IDs, field names, or a custom field mapping. The field name of the To Form fieldThe form field that will receive values transferred from a From Form field. Used in custom mappings only. A value in the From formA keyword, or static text, that will be transferred to the specified To Form field. Used in custom mappings only. The Transfer tab for distributed mapping is shown in the following figure.
69
BMC Remedy Action Request System 7.0 Figure 4-4: Distributed Mapping windowTransfer tab
Specifying or changing distributed mapping transfer definitions

You choose whether distributed mapping should be between fields with like IDs, like names, or custom relationships.
To specify or change distributed mapping transfer definitions

1 Make sure the distributed mapping basics and options are specified correctly
according to the instructions provided earlier in this chapter.
2 Select the preferred mapping method: Like Field IDs Maps all fields on the From form to the fields on the To form that have the same field IDs. This mode is useful if you are mapping identical forms. If you add fields to the forms, they are automatically mapped if they have the same field IDs. Like Field Names Maps all fields on the From form to the fields on the To form that have the same field names. This mode is useful if you are mapping identical forms. If you add fields to the forms, they are automatically mapped if they have the same field names. Custom Defines a custom field mapping between the From and To forms. You can use keywords, static values, arithmetic operations, functions, other fields, and process results (derived on the From server). If you add fields to forms to which you are applying a custom mapping, the fields in the original form are not automatically mapped to any counterparts on the new form (even if you have used Mapping > Set Like IDs or Mapping > Set Like Names in the custom mapping to initialize the custom mapping list). You must remember to add and map new fields to the new form, if necessary.
Note: If you selected Like Field IDs or Like Field Names as your mapping option, the mapping field information is not displayed and cannot be modified. The Like Field IDs and Like Field Names options are typically used to map between identical forms, so all fields between forms are automatically mapped.
3 If you are mapping by Like Field IDs or Like Field Names and are not
mapping between identical forms, make sure there are no unwanted unmapped fields. See To identify unmapped fields on page 73.
4 If you choose to create a custom mapping, specify custom mapping fields. See
To specify custom mapping fields on page 72.
71
Specifying custom mapping fields

If you choose to map custom fields, you must manually specify which fields to map.
To specify custom mapping fields

1 From the menu bar, choose either Mapping > Set Like Names or
Mapping > Set Like IDs. The To Form Field Name column displays all Field IDs or Field Names that the two forms, specified in the Basic tab, have in common.
2 From the Custom Mapping Field Name drop-down menu, select the name
of the field on the form to which you want to transfer a value.

Note: You should always map a value for the Request ID. If you do not map the Request ID fields, the Distributed Server Option always creates a new ID on the target server for the transferred request. If you are using matching qualifications, you need to map whatever fields are used to uniquely match one request with another.
3 In the Custom Mapping Fields Value field, enter or select the value (Fields,
Keyword, Functions, Processes) in the From form that you want transferred to the specified To Form field. You can specify a: Field on the From form. Keyword. Static value. Arithmetic operation of other values. Function. Process whose result is used as the value to pass.
Note: When specifying field mappings in the Transfer or Return window, make sure the values you enclose in dollar signs ($) are not identical to strings used as BMC Remedy keywords (unless you want to map a keyword value). For example, if you have a field named OS (short for Operating System) and specify the field mapping as $OS$, you will map the value for the keyword OS (in this case, your operating system) instead of the preferred field value. For more information about valid AR System keywords, see BMC Remedy User help, the Getting Started, and the Workflow Objects guides.
4 To delete the mapping of any field name and value, select the mapping in the
To Form Field Name column and press Delete.

5 To see which fields between the forms have not been mapped, review the
procedure To identify unmapped fields on page 73.

6 Choose File > Save Distributed Mapping. 7 Specify distributed mapping return options, if necessary, which are discussed
in Specifying distributed mapping returns on page 74.
Identifying unmapped fields

It is not necessary to map all fields between forms, but only fields that have been mapped from one form to another will transfer, return, or delete data between forms. This procedure assumes that you have defined the From form and To form in the Basic tab of the Distributed Mapping window, and have selected either the Transfer tab or the Return tab.
To identify unmapped fields

1 Open the appropriate distributed mapping, as described in To open a
distributed mapping on page 61.

2 Click the Transfer tab or Return tab. 3 Choose Mapping > Show Unmapped Transfer Fields.
The Unmapped Fields dialog box appears, as shown in the following figure.
73
BMC Remedy Action Request System 7.0 Figure 4-5: Unmapped Fields dialog box
4 Select which unmapped field option to display.
To view unmapped fields in the To form, click the To Fields option button. To view unmapped fields on the From form, click the From Fields option button.
5 Click Close. 6 If applicable, resolve unmapped fields. SeeTo specify custom mapping
fields on page 72.
Specifying distributed mapping returns

The Return tab identifies how the information in a target request (To form) is mapped back to a source request (From form) during an update or return. Use the Return tab to specify the following return criteria: The preferred mappingField IDs, field names, or a custom field mapping. The field name of the From formThe form field that will receive returned information from the specified To Form field. Used in custom mappings only.
Values in the To formA keyword, or static text, that you want returned to the specified From Form field. Used in custom mappings only. The Return tab for distributed mapping is shown in the following figure.
Figure 4-6: Distributed Mapping windowReturn tab
To specify or change distributed mapping return

1 Make sure the information about the distributed mapping Basic, Option, and
Transfer tabs is defined correctly according to the instructions provided earlier in this chapter.
2 Select the preferred mapping methodLike Field IDs, Like Field Names, or
Custom. For detailed information about each method, see Specifying distributed mapping transfers.
75
Note: If you selected Like Field IDs or Like Field Names as your mapping option, the mapping field information is not displayed and cannot be modified. The Like Field IDs and Like Field Names options are typically used to map between identical forms, so all fields between forms are automatically mapped.
3 If you are mapping by Like Field IDs or Like Field Names and are not
mapping between identical forms, make sure there are no unwanted unmapped fields. See To identify unmapped fields on page 73.
4 If you choose to create a custom mapping, specify custom mapping fields. See
make sure there are no unwanted unmapped fields. See To specify custom mapping fields on page 72.
Setting distributed mapping help

In most cases, the help text supplied for a distributed mapping is simply a description of the mapping. Distributed mapping help text is available for viewing and editing only by AR System administrators and subadministrators who have the Distributed Mapping window open. For more information about setting up help, see the Form and Application Objects guide. The Help Text tab for distributed mapping is shown in the following figure.
Administering BMC Remedy DSO Figure 4-7: Distributed Mapping windowHelp Text tab
Viewing and modifying distributed mapping change history

For each distributed mapping, the AR System automatically records information about the owner, the user who last modified the mapping, and the date of the modification. You can view and modify this information at any time by selecting the Change History tab of the Distributed Mapping window. For more information about change history, see the Form and Application Objects guide. The Change History tab for a Distributed Mapping is shown in the following figure.
77
BMC Remedy Action Request System 7.0 Figure 4-8: Distributed Mapping windowChange History tab
Working with distributed pools

Using distributed pools is optional. If you do use distributed pools, however, you must create on both source and target servers, and source and target forms. You can use DSO to transfer pool definitions to other servers, allowing you to administer from one server and make sure that all distributed pools are synchronized across servers. This section describes how to create and modify distributed pools using the Distributed Pool window. Creating pools and assigning DSO actions to them is optional, but might improve performance in some situations. See Using distributed pools on page 18 for general information about using distributed pools.
Using the distributed pool window

You create and modify distributed pools from the Distributed Pool window. The Distributed Pool window has three sections or tabs that let you define pools or threads for processing distributed operations simultaneously. The Create Distributed Pool window is shown in the following figure.
Figure 4-9: Distributed Pool windowBasic tab
The Create Distributed Pool window contains the following three tabs:
Basic Help Text Change History Defines the basic properties of a distributed pool, including the name and whether it is the default. Provides explanatory help text about the distributed pool. For each distributed pool, shows information about the owner, the user who last modified the pool, and the date of the modification.
Creating and deleting distributed pools

Creating a distributed pool
Follow these procedures to create a distributed pool.
79
To create a distributed pool

1 In the BMC Remedy Administrator server window, select a server to
administer by clicking it.

2 Choose File > New Server Object. 3 Select Distributed Pool from the New Server Object list, and click OK.
The Create Distributed Pool window appears, as shown in Figure 4-9 on page 79.
4 On the Basic tab, specify distributed pool information as follows: a Specify the pool name in the Name field.
Distributed pool names can be up to 80 characters, including blank spaces. Do not use special characters (such as : and / and ?). Use alphanumeric characters only.
Note: DSO recognizes one name for each distributed pool and creates a log file accordingly. This means that you cannot use the same name for more than one distributed pool, even if you use a different case. For example, BMC Remedy Administrator sees distributed pool names HIKE4, Hike4, and hike4 exactly the same way and will create only one distributed pool with these values.
b Select the Enable check box to enable the distributed pool, or clear the
Enable check box to disable the distributed pool.

c Select the Default check box to make the pool the default pool, or clear the
Default check box to make the pool not the default pool. The default pool specifies that this pool is used by default if no specific pool is indicated during a distributed operation.
5 On the Help Text tab, enter any applicable help text. 6 On the Change History tab, specify information about the distributed pool
as needed.
7 Restart the DSO server for these DSO pool changes to take effect.
For each distributed pool, the AR System automatically records information about the owner, the user who last modified the mapping, and the date of the modification. You can view and modify this information at any time by selecting the Change History tab of the Distributed Pool window. For more information about change history, see the Form and Application Objects guide.
Deleting a distributed pool

Follow these procedures to create or delete a distributed pool.
WARNING: The delete operation is permanent and cannot be undone. Make sure that you no longer need a distributed pool before deleting it. You cannot delete any distributed pool that is currently open.
To delete a distributed pool

1 In BMC Remedy Administrator, open a server window and select a server. 2 Click the Distributed Pools server object to see a list of distributed pools
currently defined on the server.

3 Select the distributed pool you want to delete. 4 Choose Edit > Delete > Distributed Pools.
If your preferences are set to deliver confirmation messages, you will receive one asking if you are sure you want to delete this distributed pool. Click OK to delete the distributed pool. The distributed pool is deleted from the server. For information about setting preferences, see the Configuring guide.
Modifying distributed pool objects

Use the following procedures to modify existing distributed pool objects.
To modify distributed pool specifications

1 In BMC Remedy Administrator, open a server window and select a server. 2 Click the Distributed Pools server object to see a list of distributed pools

3 From the Distributed Pools list, double-click a distributed pool.
81
4 In the Modify Distributed Pool window, make changes as necessary. 5 Save the distributed pool.
To copy distributed pool objects

1 In BMC Remedy Administrator, ,open a server window and select a server. 2 Click the Distributed Pools server object to see a list of distributed pools

3 From the Distributed Pools list, double-click the distributed pool that you
want to copy. A copy of a distributed pool contains all the properties of the original distributed pool. The only difference is the name.
4 Choose File > Save Distributed Pool As.
The Save Distributed Pool As window appears.

5 In the Distributed Pool Name field, enter the name of the new distributed
pool.
6 Click OK.
The new distributed pool appears in the Distributed Pools list.
Using filters and escalations for DSO actions

This section describes how to use filters and escalations to drive the distribution process (Distributed Transfer, Distributed Return, Distributed Delete).
Creating DSO actions in filters and escalations

Filters trigger distributed operations according to specified conditions. For example, in a bug tracking form, you might create a filter that causes a distributed transfer when a user enters a certain assigned-to individuals name or service region. Escalations trigger operations according to timebased criteria.
To create DSO actions in filters and escalations

1 In BMC Remedy Administrator, open a server window and select a server. 2 Choose File > New Server Object.
3 Select Filter or Escalation from the New Server Object list, and click OK.
The Filter or Escalation window appears. Fields in a new filter or escalation are empty as illustrated in the following figure.
Figure 4-10: Create Filter (or escalation) windowIf Action tab
4 Proceed with the filter or escalation creation steps covered in the Workflow
Objects guide with the following two steps:

a In the Basic tab of the Filter window or Escalation window, enter the name
of the formthe Form Name must be the same form designated as the From form on the distributed mapping.
b From the If Action tab, select DSO Action from the New Action list. Fields
appear for the Distributed Transfer, Distributed Return, and Distributed Delete actions.
5 After you have set up the filter or escalation for DSO actions, specify a
distributed operation within the filter or escalation. See the following sections: Specifying a distributed transfer on page 84.
83
Specifying a distributed return on page 88. Specifying a distributed delete on page 89.
Creating DSO actions

You can specify the following distributed operation actions when defining a filter action or an escalation action for a distributed operation: Distributed transfer Distributed return Distributed delete
Specifying a distributed transfer

Use the distributed transfer operation to transfer a request from one form to another. When the specified filter or escalation criteria is met on a request in the AR System, the system selects a mapping and sends a copy of the request to the specified To form.
Controlling distributed mapping selection

You can control the list of mappings from which the AR System chooses by specifying values in the filter or escalation action, in the mapping, or in the request being transferred. The mapping used in the transfer is selected according to the order of precedence shown in the following table. A field takes precedence as long as no field of higher precedence contains a value.
Precedence 1st 2nd Field To Mapping field on the From form To Server and To Form fields on From form Mapping Selection The mapping in this field is selected. A list of mappings is generated from the values in these fields. Default mappings are listed first, in the order they were created. The first mapping in this list is selected. The mapping in this field is selected.
3rd
Mapping field in the filter or escalation
Precedence 4th
Field
Mapping Selection
To Server and To A list of mappings is generated from the Form fields in the filter values in these fields. Default mappings or escalation are listed first, in the order they were created. The first mapping in this list is selected. From Form field in the A list of mappings is generated from all distributed mapping distributed mappings where the form in which you made the request matches the value in the From Form field. Default mappings are listed first, in the order they were created. The first mapping in this list is selected.
5th
For more information about distributed fields and mappings, see Working with distributed fields on forms on page 50 and Creating and modifying distributed mappings on page 60.
To specify a distributed transfer in a filter or escalation

1 Create a filter or escalation as described in the Workflow Objects guide.
Note: To perform a distributed transfer operation, you must create a distributed mapping plus a filter or escalation with a Distributed Transfer action on the From server.
2 In the If Action tab of the Filter window or Escalation window, select DSO
Action from the New Action list. Fields associated with Distributed Transfer, Distributed Return, and Distributed Delete actions appear in the DSO Action pane as illustrated in the following figure.
85
BMC Remedy Action Request System 7.0 Figure 4-11: Create Filter windowIf Action tab
3 Click the Distributed Transfer option button. 4 To control which mapping is used for the distributed transfer operation, you
can enter data into one or more of the following fields:

a In the Mapping field, enter the specific mapping to use for the transfer.
The Distributed Transfer Mapping field is helpful if you want to use one filter or escalation to broadcast the same request to multiple destinations by specifying different mappings in separate filter actions. For more information about broadcast distribution of entries, see Broadcast distributed transfers on page 115.
b In the Distributed Mapping To Server field, enter the name of the
destination server for the transfer. If you enter a To Server name in this field, but do not specify a mapping in the Distributed Transfer Mapping field, the system selects a default mapping from among all mappings that are defined for this To Server name.
Note: The To Server and To Form are not required in the DSO-Transfer action of a filter or escalation if the To Mapping information is to be used. Add a To Server or a To Form (or both) only if you want to overwrite the Mapping To Server or the To Form information.
c In the To Form field, enter the name of the destination form for the
transfer. If you enter a To form name in this field, but do not specify a mapping in the Distributed Transfer Mapping field, the system selects a default mapping from among all mappings that are defined for this To form name.
5 The Distributed Transfer filter action includes a check box to override loop
detection. For more information, see Avoiding infinite loops on page 109.
6 To assign the DSO action to a distributed pool for processing, enter a valid
pool name in the Distributed Pool field.

WARNING: To make sure the DSO actions are executed in the correct order, assign all related DSO actions to the same distributed pool. For example, all DSO actions associated with the same form should use the same distributed pool.
7 When you have finished specifying your DSO action Distributed Transfer
criteria, click Add Action.

8 Return to the Basics tab of the Filter window or Escalation window and, in
the Execute On field, select the filter trigger criteria. Typically, the trigger criteria used with Distributed Transfer is Execute On Modify or Execute On Submit.
9 Save the filter or escalation.
87
Specifying a distributed return

Use the distributed return operation to request the return of ownership (to the original copy) from the form where ownership was transferred. To perform a distributed return operation, you must create a distributed mapping plus a filter or escalation with a Distributed Transfer action on the source server (From server). On the target server (To server), you must create a compatible distributed mapping plus a filter or escalation with a Distributed Return action.
To specify a distributed return in a filter or escalation

1 Create a filter or escalation as described in the Workflow Objects guide. 2 In the If Action tab of the Filter window or Escalation window, select DSO
Action from the New Action list. Fields appear for the Distributed Transfer, Distributed Return, and Distributed Delete actions as shown in the figure on page 85.
3 Click the Distributed Return option button.
The Distributed Return filter action includes a check box to override loop detection. For more information, see Avoiding infinite loops on page 109.
4 To assign the DSO action to a distributed pool for processing, enter a valid
pool name in the Distributed Pool field.

WARNING: To make sure DSO actions are executed in the correct order, assign all related DSO actions to the same distributed pool. For example, all DSO actions associated with the same form should use the same distributed pool.
To use the Distributed Pool field, you must first create a distributed pool object. For more information about when to use distributed pools, see Using distributed pools on page 18. For information about creating distributed pools, see Creating and deleting distributed pools on page 79.
5 When you have finished specifying your DSO Action Distributed Return
criteria, click Add Action or Modify Action.

the Execute On field, select the trigger criteria.

Specifying a distributed delete

Use the distributed delete operation to delete specific requests, such as dataonly copies of a request that are not part of the original copys ownership chain. (Entries in an active ownership chain are automatically deleted when the request with ownership is deleted.)
To specify a distributed delete in a filter or escalation

1 Create a filter or escalation as described in the Workflow Objects guide. 2 In the If Action tab of the Filter window or Escalation window, select DSO
Action from the New Action list. Fields associated with Distributed Transfer, Distributed Return, and Distributed Delete actions appear in the DSO Action pane as shown in the figure on page 85.
3 Click the Distributed Delete option button. 4 Fill in all the following fields: a In the Request ID field, enter the request ID of the request to delete. b In the Server field, enter the name of the server on which the form
containing the specified request resides.

c In the Form field, enter the name of the form containing the specified
request.
d In the Distributed Pool field, enter a valid pool name to assign the DSO
action to a distributed pool for processing.

WARNING: To make sure DSO actions are executed in the correct order, assign all related DSO actions to the same distributed pool. For example, all DSO actions associated with the same form should use the same distributed pool.
To use the Distributed Pool field, you must first create a distributed pool object. For more information about when to use distributed pools, see Using distributed pools on page 18. For information about creating distributed pool objects, see Creating and deleting distributed pools on page 79.
5 Click Add Action or Modify Action.
89
the Execute On field, select the trigger criteria.

Note: Typically, the trigger criteria used with Distributed Delete is Execute On Delete.
Controlling pending transfer information

This section describes the Pending Distributed Operations window, which eases your administration of data transfer flow and helps you track errors. The Pending Distributed Operations window lists up to the first 200 operations that are waiting to be processed.
Using the pending distributed operations window

You can use the Pending Distributed Operations window to: View distributed operations. Remove distributed operations.
To view pending distributed operations

1 In the Server window, select the server for which you want to view pending
distributed operations by clicking it.

2 Choose File > Pending Distributed Operations.
The Pending Distributed Operations window appears, as shown in the following figure.
Administering BMC Remedy DSO Figure 4-12: Pending Distributed Operations window
3 From the Sort By field list, select the column by which you want to sort
pending distributed operations:

Request ID Form Type Status Pending Since Pool Request identifier Name of the form from which the operation was executed Operation typetransfer, update, return, or delete Operation status Amount of time the request has been pending Pool name to which the distributed operation is assigned
To remove pending distributed operations

1 In the Pending Distributed Operations window, select the Request ID
number of the operation you want to remove.

WARNING: Operations that are deleted using the Remove button are removed completely and will not be re-attempted.
2 Click Remove, and then click OK to verify that you want to remove the
selected operations. If the Transfer Status or Update Status field is present on the form, the request status field appears as Canceled.
Controlling pending transfer information
91
3 Click Refresh to update the list of pending items and then click Close.
How errors affect pending distributed operations

The Distributed Server Option reads entries from the distributed pending list and performs the specified operation (transfer, update, return, or delete) for each request. DSO checks for new entries: When an internal signal mechanism triggered by workflow alerts the DSO to check for new entries. Automatically at two minutes past every hour, ensuring that all new entries will be processed in case the internal signal mechanism fails. If the operation is successful, or if it fails with a non-recoverable error, the request is removed from the distributed pending list. If the mapping fails with a recoverable error, for example, an unavailable target server, the Distributed Server Option periodically retries the request according to the following time scale: Every 5 minutes for the first 30 minutes Every 30 minutes after the initial 30 minutes and up to 24 hours Every hour after the initial 24 hours If you specify values in the Try for Maximum of Hours/Minutes fields in the Options tab of the Distributed Mapping window, and the request reaches the specified time limit, the request is removed from the distributed pending list. This occurs even if one or more retries was not attempted. If the Transfer Status or Update Status field is present on the form, the request status field appears as Timeout.
Note: By default, the system allows three minutes of connection time for processing each distributed operation. This might be an insufficient amount of time in some situations, and might cause pending distributed operations to fail. For information about changing this setting, see Configuring the RPC timeout setting on page 45.
Chapter
Creating Distributed Server Option workflow

This chapter demonstrates how to organize and perform each of the major distributed operationstransfers, updates, returns, and deletes. The examples in this chapter assume you are a manager at Acme Industries, mapping forms between two geographically distinct servers, sanfrancisco and chicago. The following topics are provided: Basic distributed operations (page 94) Distributed transfers (page 95) Distributed updates (page 100) Distributed returns (page 101) Distributed deletes (page 103) For discussions of advanced topics, such as chaining transfers to more than two servers, see Appendix A, Advanced topics.
Creating Distributed Server Option workflow
93
Basic distributed operations

Each of the following sections is a start-to-finish example of how the basic distributed operations are implemented for Acme Industries. These mappings are from a server named sanfrancisco to a server named chicago.
Note: The procedures in this chapter assume you have already licensed servers sanfrancisco and chicago for distributed operations and that you have created applicable forms on each server.
Assume you are a manager (with administrator privileges and a fixed license) at the West Coast plant in San Francisco, California. Acme Industries recently opened another plant in Chicago, Illinois, and you need to set up data transfer for two forms between the data servers in San Francisco and Chicago. In the examples in this chapter, you will set up distributed operations between the bug tracking form on server sanfrancisco and the bug tracking form on server chicago. Acme Industries makes custom office furniture that is distributed to, and returned from, vendors such as office supply stores. Products that are returned to the vendors for various faults are entered into the Acme bug tracking forms. Information about the vendors is stored in Acmes customer information forms. The products Acme manufactures and repairs are: Prize Desks Prize Printer Stands Choice Desk Chairs Superior Side Chairs Prize products are manufactured and repaired in San Francisco; Choice and Superior products are manufactured and repaired in Chicago. All request IDs created on server sanfrancisco use an AW prefix (to denote Acme West), and all request IDs created on server chicago use an AE prefix (to denote Acme East).
94 Chapter 5Creating Distributed Server Option workflow
Distributed transfers
To perform a distributed transfer operation, you must create a distributed mapping plus a filter (or escalation) with a Distributed Transfer action on the From server. In this section, you will define identical distributed mappings on both servers, which is required for the distributed update and return operation, shown in the next section, to work. To continue with the previous example, there are three steps to define a distributed transfer between the Acme West Bug Tracking form on server sanfrancisco (in San Francisco, California) and the Acme East Bug Tracking form on server chicago (in Chicago, Illinois).
Step 1 Adding distributed fields to your forms on page 95. Step 2 Creating distributed mappings on page 96. Step 3 Creating a filter on page 98.
After you complete these steps, a bug request made in Acme West for Choice Desk Chairs or Superior Side Chairs is automatically transferred to Acme East.
Adding distributed fields to your forms

The distributed fields you specify for your forms will contain the data that is transferred to other servers.
To add distributed fields

1 Establish forms (and servers) to be mapped:
From Server: sanfrancisco From Form: Acme West Bug Tracking To Server: chicago To Form: Acme East Bug Tracking
2 Log on tosanfranciscoand chicagoservers using BMC RemedyAdministrator. 3 For each server, select the Forms server object. 4 Open the appropriate bug tracking form for each server.
On server sanfrancisco, open the Acme West Bug Tracking form. On server chicago, open the Acme East Bug Tracking form.
95
5 Choose Form > Distributed Fields.
The Distributed Fields window appears.

6 Select the following information in the Distributed Fields window. a In the Distributed Fields field, select Basic. b Clear the Add as Hidden Fields check box. c Click OK. 7 Rearrange the added distributed fields on the form, if necessary, and save the
form.
Creating distributed mappings

The distributed mappings you create for your forms will determine which fields on the From form will supply data to which fields on the To form.
To create distributed mappings

1 On each server, choose File > New Server Object. 2 Select Distributed Mapping from the New Server Object list and click OK.
The Distributed Mapping window appears.

3 Fill in the Basic tab of this Distributed Mapping window with the
information in the following figure.
Administering BMC Remedy DSO Figure 5-1: Create Distributed Mapping windowBasic tab
4 Fill in the Options tab of this window with the information in the following
figure.
97
BMC Remedy Action Request System 7.0 Figure 5-2: Create Distributed Mapping windowOptions tab
5 On the Transfer tab, in the Mapping Method field, select the Like Field IDs
option button.
6 On the Return tab, in the Mapping Method section, select the Like Field IDs
option button.
7 Save the distributed mapping.
Creating a filter
You create a filter containing a DSO action, which causes data to be transferred.
To create a filter
1 In the server window, select the From server by clicking it.
In this example, the From server is sanfrancisco.

2 Choose File > New Server Object.

3 In the New Server Object window, select Filter and click OK.
The Create Filter window appears.

4 In the Basic tab, select the Form Name and select the Execute On criterion as
shown in the following figure:

Figure 5-3: Create Filter windowBasic tab
5 Examine the request specified in the Run If field. The condition is interpreted
as the product name does not begin with the letter P. This qualification states that the filter action should be executed when the condition is met by a request into Acme West Bug Tracking.
99
6 In the If Action tab, select DSO Action from the New Actions list.
Distributed Transfer, Distributed Return, and Distributed Delete sections appear on the form.
7 Select the Distributed Transfer option button.
If you want to use a default mapping, leave the Mapping, To Server, or To Form fields blank.
8 Click Add Action or Modify Action and save the filter. 9 Test the mapping.
To test the mapping in this example, open BMC Remedy User and enter data into the Acme West Bug Tracking form. All entries submitted for products Choice Desk Chair and Superior Side Chair immediately transfer to the Acme East Bug Tracking form. The request on server sanfrancisco is data only.
Distributed updates
The previous distributed transfer mapping can be set so that when a request that was transferred to Acme East Bug Tracking (in Chicago) is modified, the original copy in Acme West Bug Tracking (in San Francisco) is also updated. Ownership of the request remains in Chicago. The mapping should be defined as shown in Distributed transfers on page 95. Because updates are automatic, the main control over their occurrence is the When to Update list in the Options tab of the Distributed Mapping window. Use this list to assign if or when you want updates to the original request to occur. No additional work is necessary to implement the update. Only entries that were transferred from Acme West Bug Tracking with the transfer mode specified Data + Ownership will be updated by Acme East Bug Tracking. If you transfer data-only copies of entries to Acme East, those copies cannot be modified in the Acme East Bug Tracking form.
Note: To perform a distributed update operation, you must create a compatible distributed mapping on the To server for distributed updates to occur.
Distributed returns
As discussed in Using distributed returns on page 26, returns must be requested. The following distributed return procedure lets you set the distributed transfer mapping (defined in Distributed transfers on page 95) so that entries that were initially transferred to Acme East through a distributed transfer will be returned with ownership from Acme East Bug Tracking to Acme West Bug Tracking after the request is fixed. Define the mapping as shown in Distributed transfers on page 95. The main control for the occurrence of returns is a filter action on the system from which the return is being generated (typically, the To form defined in the mapping). If you set the Run If criteria as a change in the assigned status to Fixed, the return should occur after the bug status is changed to Fixed.
Note: To perform a distributed return operation, you must create a distributed mapping plus a filter or escalation with a Distributed Transfer action on the From server. On the To server, you must create a compatible distributed mapping plus a filter or escalation with a Distributed Return action.
The following procedure assumes that you are already logged on to the sanfrancisco and chicago servers in BMC Remedy Administrator.
To define a distributed return operation

1 In a BMC Remedy Administrator window, select the To server.
In this example, the To server is chicago.

2 Choose File > New Server Object.

3 In the New Server Object window, select Filter and click OK.

4 Fill in the Basic tab of the Filter window with the information in the following
figure.
Distributed returns
101
BMC Remedy Action Request System 7.0 Figure 5-4: Create Filter windowBasic tab
5 Examine the request specified in the Run If field. The condition is interpreted
as the status for the bug is fixed. This qualification states that the filter action should be executed when the condition is met by a modification of a request to Acme East Bug Tracking.
6 In the If Action tab, select DSO Action from the New Actions list.
DSO Action fields appear in the window.

7 Select the Distributed Return option button. 8 Click Add Action or Modify Action to add the Distributed Return filter
action to the Current Actions list. Because Distributed Return is the only filter action needed, you do not need to create any more filter actions for this mapping.
9 Save the filter and test the mapping.
To test the mapping, open BMC Remedy User and update the assigned status on entries in the form Acme East Bug Tracking that were previously transferred from Acme West Bug Tracking. All entries modified to Fixed from another status should be returned, with ownership, to Acme West Bug Tracking. You should now be able to modify the request on sanfrancisco. The request on chicago becomes an independent data-only copy.
Distributed deletes
When the master copy of a distributed request is deleted, all copies in the active ownership chain are also deleted. In Distributed transfers on page 95, you set up a transfer of entries from Acme West Bug Tracking to Acme East Bug Tracking. If you delete the master copy of a request in Acme East Bug Tracking, the original copy in Acme West Bug Tracking is also deleted. However, the AR System does not delete copies of entries in either Acme West Bug Tracking or Acme East Bug Tracking that are not in the active ownership chain. The following procedure describes the distributed delete operation, which lets you delete these data-only copies.
To define a distributed delete operation

1 In a BMC Remedy Administrator window, select server chicago. 2 Choose File > New Server Object.

3 In the New Server Object window, select Filter.

4 In the Basic tab of the Filter window enter the information in the following
figure.
Distributed deletes
103
BMC Remedy Action Request System 7.0 Figure 5-5: Create Filter windowBasic tab
No information is needed in the Run If field.

5 In the If Action tab of the Filter window, select from the New Actions list.
The DSO Action section displays Distributed Transfer, Distributed Return, and Distributed Delete options.
6 Select Distributed Delete and enter the values from the following figure into
the enabled fields.
Administering BMC Remedy DSO Figure 5-6: Create Filter windowIf Action tab
7 Click Add Action or Modify Action to add the Distributed Delete filter action
to the Current Actions list.

8 Save the filter.
Based on this Distributed Delete action, when a request is deleted from Acme West Bug Tracking, the request with the same ID in the form Acme East Bug Tracking on server chicago is deleted.
Distributed deletes
105
Appendix
Advanced topics
This appendix includes demonstrations of variable environments you can use with the Distributed Server Option. The following topics are provided: Setting up chained distributed transfers (page 108) Broadcast distributed transfers (page 115) Chained operations and broadcast operations both take place among multiple servers. An example of a chained operation occurs when server sanfrancisco transfers a request to server chicago, and subsequently server chicago transfers the request to server toronto. An example of a broadcast operation occurs when server sanfrancisco transfers the same request to two servers, chicago and toronto. You should spend some time considering the overhead that might be involved in both the implementation and maintenance of these features. When data is distributed among more than two sites, your troubleshooting effort might increase exponentially. The examples in this appendix assume you are a manager (or an administrator) at Acme Industries. You are mapping forms between the three servers located in San Francisco, Chicago, and Toronto. The procedures in this appendix build upon the previous chapters requirements. They assume that you have already licensed a server toronto for distributed operations.
Advanced topics
107
Setting up chained distributed transfers

You can set up a distribution environment involving more than two locations in which the servers are chained from one to another, creating a staggered distribution effect. For example, you can define a mapping (on sanfrancisco) that sends a request from server sanfrancisco to server chicago and a subsequent mapping (on chicago) that sends the same request from chicago to toronto. A transfer will occur when someone using the Acme West Bug Tracking form creates or modifies a bug request for Choice Desk Chairs or Superior Side Chairs. You will also define a distributed transfer between form Acme East Bug Tracking on server chicago and Acme Canada Bug Tracking on server toronto. A chained transfer will occur when a request regarding a Superior Side Chair is transferred into the Acme East Bug Tracking form on chicago.
Special considerations for chained distribution

When attempting a chained distributed operation, remember the following special considerations.
Deleting requests
Users can only delete the master copy or independent copies of a request. When the master copy of a request is deleted, requests in the active ownership chain are also deleted. You can use the Distributed Delete filter action to delete requests that are outside the active ownership chain, or you can use ardist to clear the Master Flag. For more information about distributed deletes, see Distributed deletes on page 103. For more information about ardist, see Appendix B, Distributed Server Administration program.
Controlling returns
To control returns, you can create a filter that will look for a condition in which Data + Ownership is the Transfer Mode. This filter action takes the transferred request and executes another mapping specified in the filter action. The filter action then returns the request to the From form defined in the Transfer mapping.
108 Appendix AAdvanced topics
Controlling updates
To control updates, select a value other than No Update in the When to Update field of the Distributed Mapping window. Any changes made to a request in the To form of a mapping are sent back as updates to the From form in the mapping.
Avoiding infinite loops

Do not transfer requests with ownership if the duplicate request ID action specified on the mapping is overwrite. The combination of transferring ownership and overwriting existing requests in a chained environment can create an infinite loop. The system protects you against infinite loops by providing automatic loop detection. Chained distribution is one circumstance when you want to override the loop protection in the AR System. To shut down loop protection, perform the following procedure.
To override loop detection

1 In BMC Remedy Administrator, open the Filter window or Escalation
window that defines the Distributed Transfer action or the Distributed Return action.
2 Click the If Action tab. 3 In the If Action tab of the Filter window or Escalation window, select DSO
Action from the New Action list or select an existing DSO Action from the Current Actions list. The Distributed Transfer, Distributed Return, and Distributed Delete actions appear in the DSO Action section of the window.
4 For a new action, Select Distributed Transfer or Distributed Return. 5 Select the Distributed Mapping Override Loop Detection check box. 6 Click Add Action or Modify Action.
The Distributed Delete action is added to the Current Actions window.

109
WARNING: If you shut down loop protection, you risk creating infinite loops and overwriting the original record in a distributed transfer operation or a distributed return operation.
Creating multiple chains

Each distributed mapping lets you define two locations. If you want to transfer requests between more than two locations, you can chain mappings together. Suppose you have three mappings: From toronto to sanfrancisco From sanfrancisco to chicago From chicago to toronto To have requests made in Acme Canada Bug Tracking (toronto) transferred to Acme East Bug Tracking (chicago), where those products are maintained and repaired, you could link together the mapping from toronto to sanfrancisco and the mapping from sanfrancisco to chicago, thus creating a mapping chain. In this way, you identify where the request starts (toronto) and where the request stops (chicago). You should create a separate mapping chain each time you have a different starting and stopping place. For example, to have requests that are made in Acme West Bug Tracking (sanfrancisco) transfer to Acme Canada Bug Tracking (toronto), create another mapping chain linking the mapping from sanfrancisco to chicago and the mapping from chicago to toronto together, and so on. By creating separate mapping chains you are able to transfer requests between more than two locations and avoid the looping problem that could occur if you created one mapping chain from sanfrancisco to chicago, chicago totoronto,andtorontotosanfrancisco,anddistributedcopieswithownership.
Defining a chained distributed transfer

The following figure is an example of the flow of a chained distributed transfer.
Figure A-1: Chained distributed transfer example
Original
1
Transfer
Copy
Transfer
Copy
1 2 3
The original bug tracking request is on server sanfrancisco. The request is transferred to server chicago. The request is transferred to server toronto.
The following procedure sets up the chained distributed transfer shown in the figure on page page 111. You will define a distributed transfer between form Acme West Bug Tracking on server sanfrancisco and Acme East Bug Tracking on server chicago.
To define a chained distributed transfer

1 Verify that you have created the Acme West Bug Tracking form on server
sanfrancisco, and the Acme East Bug Tracking form on server chicago, and
that you have added basic distributed fields to both forms.
111
For information about adding distributed fields to forms, see Working with distributed fields on forms on page 50.
2 On server toronto, create a form like the Acme West Bug Tracking form
(with basic distributed fields), and name it Acme Canada Bug Tracking.
3 Verify that appropriate distributed mappings and filters have been created on
sanfrancisco and chicago, according to the procedures in Distributed
transfers on page 95. The distributed operation in step 4, which follows, defines a Data+Ownership transfer between Acme West Bug Tracking and Acme East Bug Tracking that occurs when the product name on the Acme West Bug Tracking form does not begin with the letter P.
4 Create new distributed mappings on both chicago and toronto. a Configure the Basic tab in the Distributed Mapping window with the
information in the following figure:

Figure A-2: Create Distributed Mapping windowBasic tab
b In the Options tab, enter the information in the following figure:

Figure A-3: Create Distributed Mapping windowsOptions tab
c In the Transfer tab, in the Mapping Method field, select Like Field IDs. d In the Return tab, in the Mapping Method section, select Like Field IDs. e Save the distributed mapping. 5 Create a new filter on chicago. a Fill in the Basic tab of the Filter window with the information in the
following figure:
113
BMC Remedy Action Request System 7.0 Figure A-4: Create Filter windowBasic tab
b The qualification states that the filter action should be executed when the
product name on the Acme East Bug Tracking form begins with the letter S.
c In the If Actions tab of this Filter window, select DSO Action from the
New Actions list.

d Select Distributed Transfer. e Select Override Loop Detection. f Click Add Action or Modify Action to add the Distributed Transfer filter
action to the Current Actions list.

g Save the filter.
6 Test the chained mapping by creating some requests for the Prize Desk,
Choice Desk Chair, and the Superior Side Chair on form Acme West Bug Tracking. Requests for both kinds of chairs should transfer to Acme East Bug Tracking (chicago), while only the Superior Side Chair requests should transfer to Acme Canada Bug Tracking (toronto).
Broadcast distributed transfers

You can set up a distributed environment involving more than two locations. In this environment, one server broadcasts copies of a request to multiple recipients. Broadcast-style distributions are typically used to propagate forms, such as remote knowledge bases, from one central source. Ownership does not transfer with the requests, and the distributed copies do not update the original request. For example, if you define a mapping on sanfrancisco that sends a dataonly copy of a request from server sanfrancisco to server chicago, you must also define a mapping on sanfrancisco that sends another data-only copy of the same request from sanfrancisco to toronto. If you try to broadcast copies of requests with ownership, the transfer specified by the first filter action executes successfully. All remaining transfers to other servers, specified by subsequent filter actions, will result in error messages because ownership was transferred off the From server during the first filter action.
Tip: Use one or more DSO pools when performing broadcast distributed operations. Doing so allows many of the transfers in the broadcast to occur simultaneously instead of one at a time.
The following section provides procedures for setting up a broadcast distributed transfer using BMC Remedy Administrator. This distributed transfer sends requests made to the Acme Product Info Archive form on sanfrancisco to Acme Product Info Archive forms on servers chicago and toronto.
115
The following figure is an example of the flow of such a broadcast transfer.

Figure A-5: Broadcast distributed transfer example
Original
Transfer Copy Copy
1 2
The original request is on server sanfrancisco. Copies of the request are transferred to servers chicago and toronto.
To set up a broadcast distributed transfer

1 Define a distributed mapping named Acme ProdInfoArch W-> E between the
Product Info Archive forms on sanfrancisco and chicago. The steps for this procedure are covered in Specifying a distributed transfer on page 84. When you create your distributed transfer, make sure you use the following values in these fields:
Tab Options Field Name When to Update Transfer Mode Value
No Update Data Only
2 Define a distributed mapping named Acme ProdInfoArch W-> T between the
Product Info Archive forms on sanfrancisco and toronto. The steps for this procedure are covered in Specifying a distributed transfer on page 84. When you create your distributed transfer, make sure you use the following values in these fields:
Tab Options Field Name When to Update Transfer Mode Value
No Update Data Only
3 Create one Distributed Transfer filter with two separate actions to execute on
the conditions Submit and Modify, using the following names. No qualification is necessary.
Action 1 Action 2
Acme ProdInfoArch W to E Acme ProdInfoArch W to T
You should use the same filter to transfer requests from sanfrancisco to chicago and from sanfrancisco to toronto. Simply define the transfers as separate filter actions, which execute in order when the criteria on sanfrancisco is met.
4 Test the broadcast by making some requests into the Acme Product Info
Archive on sanfrancisco. Data-only copies of the requests should appear in the Acme Product Info Archive forms on chicago and toronto.
Using broadcast transfers to manage DSO from a central location

You can use DSO broadcast transfers to manage your DSO implementation from a central location. By broadcasting DSO mappings to other AR System servers that participate in transfers and returns, you help make sure that the appropriate mappings are available where and when they need to be. For example, from the server sanfrancisco, you can manage your DSO implementation on chicago and toronto. To do so, you create distributed mappings for the Distributed Mapping and Distributed Pools forms on the server sanfrancisco. Then, you broadcast them to the servers chicago and toronto.
117
To use broadcast transfers to manage DSO from a central location

1 On the AR System server sanfrancisco, define a distributed mapping named
Distributed Mapping--sanfrancisco to chicago between the Distributed Mapping forms on sanfrancisco and chicago. The steps for this procedure
are covered in Specifying a distributed transfer on page 84. When you create your distributed transfer, make sure you use the following values in these fields:
Tab Basic Field Name From Server Name From Form Name To Server Name To Form Name Options When to Update Transfer Mode Transfer Return Mapping Method Mapping Method Value
sanfrancisco Distributed Mapping chicago Distributed Mapping immediately Data Only Like Field IDs Like Field IDs
2 Define a distributed mapping named Distributed Mapping--sanfrancisco

to toronto between the Distributed Mapping forms on sanfrancisco and toronto.
The steps for this procedure are covered in Specifying a distributed transfer on page 84. When you create your distributed transfer, make sure you use the following values in these fields:
Tab Basic Field Name From Server Name From Form Name To Server Name To Form Name Options When to Update Transfer Mode Value
sanfrancisco Distributed Mapping toronto Distributed Mapping immediately Data Only
Tab Transfer Return
Field Name Mapping Method Mapping Method
Value
Like Field IDs Like Field IDs
3 Create one Distributed Transfer filter with two separate actions to execute on
the conditions Submit and Modify, using the following names. No qualification is necessary.
Action 1 Action 2
Distributed Mapping--sanfrancisco to chicago Distributed Mapping--sanfrancisco to toronto
You should use the same filter to transfer requests from sanfrancisco to chicago and from sanfrancisco to toronto. Simply define the transfers as separate filter actions, which execute in order when the criteria on sanfrancisco is met.
4 Test the broadcast by making creating or modifying a Distributed Mapping
on sanfrancisco. Data-only copies of the requests should appear in the Distributed Mapping forms on chicago and toronto.
5 Create distributed mappings to broadcast entries amongst the Distributed
Pool forms on the various servers. Repeat steps 1-5 for the Distributed Pools form.
119
Appendix
Distributed Server Administration program

The ardist program is a special purpose utility that lets you override five of the key reserved fields used for distributed operations that cannot otherwise be changed. For example, in a unique permutation of a standard mapping, you can use the ardist program to rename the source form or the target form.
WARNING: The ardist program is not used to distribute data, and should not be considered a command line version of the Distributed Server Option.
The following table presents command line arguments used by the ardist program to override specific fields used in distributed operations. The five uppercase arguments (-C, -M, -P, -R, -L) are flags; you should not assign values to them. If you use both the uppercase and lowercase arguments on the same command line, such as -m 1 -M, the setting to NULL is used.
Value Description
-C -c -d
Sets the From form to NULL. This argument serves as a flag; do not assign a value to it. Sets the From form to name specified. This argument is useful if you change the name of the source form. Runs the program in debug mode, printing debug information to the terminal. This argument serves as a flag; do not assign a value to it. For more information see the Error Messages guide. The ID of the request to be modified.
-e
Distributed Server Administration program
121
Value Description
-i -L -l -M -m -P -p -R -r -s -x
The installation directory for AR System. Sets the From pool to NULL. This argument serves as a flag; do not assign a value to it. Sets the name of the DSO pool used in the distributed operation. Use this argument if the name of the DSO pool is changed. Sets the Master Flag to NULL. This argument serves as a flag; do not assign a value to it. Sets the Master Flag to the value specified (1 = Yes, 0 = No). This argument is useful if your transfer gives you zero or multiple masters. Sets the From mapping to NULL. This argument serves as a flag; do not assign a value to it. Sets the name of the From mapping. Use this argument if the name of the mapping changed. Sets the From server to NULL. This argument serves as a flag; do not assign a value to it. Sets the From server name. Use this argument if the name of the server changed. The name of the form containing requests to modify. The name of the server containing the form (-s) that has requests to modify.
122 Appendix BDistributed Server Administration program
Overwriting basic fields example

The following procedure example maps a request from the Acme West Bug Tracking II form to the Acme East Bug Archive form (residing on server chicago) by way of mapping Acme W to E Problem Archiving, which is executed on server sanfrancisco. (The master flag value is set to NULL.)
1 In Windows, open a DOS session. In UNIX, skip to step 3. 2 Change to the <ar_install_dir> directory containing ardist. 3 At the command prompt, type:
ardist-i<server_install_dir>-c"AcmeWestBugTrackingII"-e<request_ID>-M-p "AcmeW->EProblemArchiving"-rsanfrancisco-s"AcmeEastBugArchive"-xchicago
Overwriting basic fields example
123
124 Appendix BDistributed Server Administration program
Index
A
access control, licensing 32 advanced distributed fields 16 AR System servers, configuration local 34 remote 41 archiving with DSO, example 13 ardist program, overwriting basic fields example 123 creating distributed mappings 60 distributed pools 80 DSO actions in filters and escalations 82 log files 46 custom mappings 72
D
data patterns 67 data types, mapping 15 data+ownership transfers 22, 67 data-only copies deleting 89 transfers, defined 22 debug trace mode 46 default mappings concept 15 creating 63 defining mappings 6077 deleting data-only copies 89 distributed delete operation 89 distributed fields 51, 89, 103 distributed mappings 62 pending operations 91 port numbers 43 RPC program numbers 43 distributed deletes example 28, 103 execution criteria 28 operation 89
B
basic distributed fields 16 basic properties of distributed mappings 63 broadcast distributed transfers 115119 using to manage DSO 117
C
chained distributed transfers 108115 chains, ownership 21 Change History tab 77 configuring AR System server, local 34 AR System server, remote 41 DSO for load balancing 45 DSO with a hardware load balancer 45 host names 44 RPC timeout 45 copy+delete transfers, defined 22 copying distributed mappings 61 distributed pools 82
Index
125
distributed fields See also distributed operations See also distributed pools See also distributed returns See also distributed servers See also distributed transfers See also distributed updates adding 51 advanced 16 basic 16 defined 16 deleting 51 full 16 overview 16 updating 50 distributed knowledge base example 13 Distributed Mapping window Change History tab 78 using 57, ??77 distributed mappings allowing a server group 63 basics 63 copying 61, 82 creating 60 custom 72 default 15, 84 defining 6077 deleting 62 enabling 63 enforce pattern matching 67 history data 16 like field IDs 71 like field names 71 matching qualifications 19 opening 61 overriding settings 16, 23 require required fields 68 return 74 selection criteria 84 transferring 69, 72 types 50 updating packing lists 60 using matching qualifications 68 using request IDs 68
distributed operations examples 93 overview 20 ownership 21 pending 45, 92 pools 18 setting up 29 timeout setting 45 transfers 20 Distributed Pool window 79 distributed pools concept 14, 18 creating 78 distributed operations and 87, 88 DSO actions and 87, 88 example 14 execution 18 updating distributed fields 50 distributed returns example 101 execution criteria 26 mappings 74 using 88 Distributed Server Option managing from a central location 117 required forms 15 uses 12 using broadcast transfers to manage 117 Distributed Server user 39 distributed servers assigning dedicated RPC program numbers 34 configuring remote AR System servers 41 configuring the local server 34 debugging 46 DSO archival function example 13 host name, configuring 44 overview 12 password security 39 settings 33 upgrading previous versions 43 uses 12 using with server groups 13
126 Index
distributed transfers broadcast environment 115 chained environment 108115 example 95100 mapping methods 71 overview 20 ownership 21 status 56 Transfer tab 69 types 22 distributed updates example 25, 100 frequency 66 generation 24 DSO Local Server Password field 41 duplicate request IDs actions 44, 67 avoiding loops during overwrites 21, 109 prevention 19 duplicate request IDs, handling 19
firewalls See also RPC program numbers distributed server configuration 34 using distributed servers behind 36 forms, required 15 From Form Name list 64 From Server Name list 64 From Server names, configuring 44 full distributed fields 16
H
help, setting 76 hiding fields 54 history changing 77 mapping 16 host names, configuring 44
I
identification. See request IDs independent copy transfers, defined 22
E
enabling mappings 63 See also distributed mappings Enforce Pattern Matching check box 67 error messages, duplicate request IDs 19 examples ardist program, overwriting basic fields 123 distributed deletes 103 distributed returns 101 distributed transfers 95100 distributed updates 100 workflow 93
K
knowledge base example 13
L
licenses access control 32 types 32 licensing requirements 49 Like Field IDs 71 Like Field Names 71 load balancing configuring DSO for 45 hardware load balancer 45 local AR System server configuration 34 log files 46 loop detection, overriding 21, 109
F
field IDs, used in transfer definitions 71 field names, used in transfer definitions 71 fields distributed 16, 51 hiding 54 making visible 54 unmapped 45, 73 filters, using in DSO actions 82
M
managing DSO from a central location 117 mappings. See distributed mappings master copy 14 matching qualifications 19 matching source and destination requests 19
Index
127
O
opening distributed mappings 61 overriding loop detection 109 mapping settings 16, 23 ownership chains 21 concept 21 master copy 14
RPC timeout, configuring 45
S
server groups allowing in a distributed mapping 63 using with DSO 13 servers. See distributed servers setting help 76 status transfer 56 update 56
P
packing lists, updating 60 password security, Remedy Distributed server local 39 remote 41 pending operations 91 pools, distributed 18 port numbers assigning to a local AR System server 36 assigning to a remote AR System server 41 removing from configuration files 43
T
To Form Name list 64 To Server Name list 64 transfer status 56 transfers broadcast distributed 115119 chained distributed 108115 distributed 95 types of licenses 32
Q
qualifications, matching 19, 68
U
unmapped fields identifying 73 set to NULL 45 update status 56 updating distributed fields 50 upgrading AR System servers 43 user, Distributed Server 39
R
remote AR System server configuration 41 request IDs configuring overwrite behavior 44 duplicates 67 duplicates, handling 19 duplicates, preventing 19 site-specific prefixes 19 using in distributed operations 18, 68 request IDs, duplicates overwriting 19 Require Required Fields menu 68 required forms 15 retry interval frequency 56 setting 68 RPC program numbers assigning 3436, 41 removing from configuration files 43 sockets 34
W
workflow examples 93
128 Index
*96485* *96485* *96485* *96485*
*58469*

Remedy DSO

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Remedy DSO

Uploaded by

Copyright:

Available Formats

BMC Remedy Action Request System 7.

Administering BMC Remedy DSO

May 2006 Part No: 58469

BMC Software, Inc.

Using the distributed server environment . . . . . . . . . . . . . 11

BMC Remedy Action Request System 7.0

Configuring the distributed server . . . . . . . . . . . . . . . . 33

Implementing the Distributed Server Option . . . . . . . . . . . 49

Administering BMC Remedy DSO

Creating Distributed Server Option workflow . . . . . . . . . . . 93

Advanced topics . . . . . . . . . . . . . . . . . . . . . . . . 107

Distributed Server Administration program . . . . . . . . . . . 121

BMC Remedy Action Request System 7.0

BMC Remedy Action Request System 7.0

Installing Getting Started

Form and Application Objects

Workflow Objects Configuring

Administering BMC Remedy DSO

Title Database Reference

Procedures for configuring the BMC Remedy Mid Tier. Administrators

BMC Remedy Action Request System 7.0

Learn about the AR System Developer Community

Why should you participate in the Developer Community?

How do you access the Developer Community?

Using the distributed server environment

Using the distributed server environment

BMC Remedy Action Request System 7.0

Overview of the Distributed Server Option

Using the Distributed Server Option

12 Chapter 1Using the distributed server environment

Administering BMC Remedy DSO

Using DSO with server groups

Using the Distributed Server Option

BMC Remedy Action Request System 7.0

Managing the exchange of information

14 Chapter 1Using the distributed server environment

Administering BMC Remedy DSO

Using Distributed Server Option forms

Using distributed mappings

Managing the exchange of information

BMC Remedy Action Request System 7.0

Using distributed fields

16 Chapter 1Using the distributed server environment

Administering BMC Remedy DSO

Distributed field group Basic

To Mapping From Mapping To Request ID To Form To Server

Managing the exchange of information

BMC Remedy Action Request System 7.0

Using distributed pools

Using request IDs

18 Chapter 1Using the distributed server environment

Administering BMC Remedy DSO

Preventing duplicate request IDs

Handling duplicate request IDs

Matching source and destination requests

Managing the exchange of information

BMC Remedy Action Request System 7.0

See Specifying distributed mapping options on page 65.

Defining distributed operations

Using distributed transfers

20 Chapter 1Using the distributed server environment

Administering BMC Remedy DSO

Ownership and ownership chains