remedy dso

7/30/2019 remedy DSO

1/130

M a y 2 0 0 6

P a r t N o : 5 8 4 6 9

BMC Rem edy Action Request System 7.0

Adm inistering BM C Rem edy DSO


2/130

BMC Sof tw are, Inc.www. bmc. com

Cop yright 19912006 BMC Software, In c. All rights reserved.

BMC, the BMC logo, all oth er BMC pr od uct or service nam es, BMC Software, the BMC Software logos, andall other BMC Software produ ct or service nam es, are registered tradem arks or tradem arks of BMC

Software, Inc. All other trad emar ks belong t o th eir respective com panies.

BMC Software, Inc., considers inform ation included in th is docum entation to be prop rietary andconfidential. Your use of this inform ation is subject to the term s and con ditions of the applicable end u serlicense agreem ent or n ond isclosure agreem ent for the pro duct an d the pr oprietary and restricted rightsnot ices included in this docum entation .

For license inform ation abo ut the O penSource files used in th e licensed p rogram , please readOpenSour ceLi censes. pdf . This file is in th e\ Doc folder of the distribution CD -ROM and in the

docum entation download portion of the product down load page.

Restricted Righ ts Leg end

U.S. Governm ent Restricted Rights to Com pu ter Software. UN PUBLISHED - - RIGH TS RESERVED U ND ER THE

CO PYRIGH T LAWS OF TH E UNITED STATES. Use, du plication, or d isclosure of any data an d com pu ter software by the

U.S. Governm ent is subject to restrictions, as app licable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS

252.227-7014, DFARS 252.227-7015, and D FARS 252.227-7025, as amend ed from time to tim e. Contr actor/M anu facturer is

BMC Software, Inc., 2101 CityWest Blvd., Hou ston, TX 77042-2827, USA. Any contract no tices shou ld be sent to t his addr ess.

Conta cting UsIf you n eed technical suppo rt for this produ ct, cont act Custom er Sup port b y em ail at suppor t @r emedy . com.If you have com m ents or suggestions about th is docum entation , cont act Information D evelopm ent byemail at doc_f eedback@bmc. com.

This edition app lies to version 7.0 of the licensed program .
http://www.bmc.com/mailto:[email protected]:[email protected]:[email protected]:[email protected]://www.bmc.com/


3/130

Contents 3

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Aud ien ce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

AR System doc um ents . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Learn about the AR System D eveloper Com mu nity . . . . . . . . . . . . 10

Wh y should you participate in the Developer Com m un ity? . . . . . . . . 10H ow do you access the Developer Com m un ity? . . . . . . . . . . . . . 10

Chapter 1 Using the distr ibuted server environment . . . . . . . . . . . . . 11

Ove rview of the D istributed Server Op tion . . . . . . . . . . . . . . . . 12

U sing the D istributed Server Op tion . . . . . . . . . . . . . . . . . . . 12

Using DSO with server group s . . . . . . . . . . . . . . . . . . . . 13

Man aging the exchange of inform ation . . . . . . . . . . . . . . . . . . 14

Using Distribu ted Server Op tion form s. . . . . . . . . . . . . . . . . 15

Using distribu ted m app ings . . . . . . . . . . . . . . . . . . . . . 15

Usin g distr ibu ted fields . . . . . . . . . . . . . . . . . . . . . . . 16

Usin g distr ibu ted po ols . . . . . . . . . . . . . . . . . . . . . . . 18

Usin g req uest IDs . . . . . . . . . . . . . . . . . . . . . . . . . . 18

D efining distributed op eration s . . . . . . . . . . . . . . . . . . . . . 20

Using distribu ted tran sfers . . . . . . . . . . . . . . . . . . . . . . 20

Using distribu ted up dates . . . . . . . . . . . . . . . . . . . . . . 24

Using distribu ted retu rn s . . . . . . . . . . . . . . . . . . . . . . 26

Using distribu ted deletes . . . . . . . . . . . . . . . . . . . . . . . 28

Ove rview of setting up distributed op eration s . . . . . . . . . . . . . . . 29


4/130

4 Contents

BMC Remed y Action Request System 7.0

Chapter 2 Licensing DSO . . . . . . . . . . . . . . . . . . . . . . . . . . 31

O verview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Chapter 3 Conf iguring the distributed server . . . . . . . . . . . . . . . . 33Setting up the local and remo te D SO servers . . . . . . . . . . . . . . . 34

Con figur ing a local AR System server . . . . . . . . . . . . . . . . . 34

Con figur ing a rem ote AR System server . . . . . . . . . . . . . . . . 41

U pgrading previou s versions of AR System . . . . . . . . . . . . . . . . 43

Specifying a D SO ho st nam e for distributed m appings . . . . . . . . . . . 44

Co nfiguring overwrite behavior for dup licatereque st ID s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Co nfiguring the RPC timeo ut setting . . . . . . . . . . . . . . . . . . 45

Co nfiguring D SO for load balancing . . . . . . . . . . . . . . . . . . . 45

U sing debu g trace m od e to create log files . . . . . . . . . . . . . . . . 46

Chapter 4 Implement ing the Distr ibuted Server Opt ion . . . . . . . . . . . 49

W orking with distributed fields on forms . . . . . . . . . . . . . . . . . 50

Using th e distribu ted fields wind ow . . . . . . . . . . . . . . . . . . 50

W orking with distributed m appings . . . . . . . . . . . . . . . . . . . 57

Using th e distribu ted m app ing wind ow . . . . . . . . . . . . . . . . 57

Creat ing and m odifyin g distribu ted m app ings . . . . . . . . . . . . . . 60

Specifying distribu ted m app ing basics . . . . . . . . . . . . . . . . . 63

Specifying distribu ted m app ing opt ions . . . . . . . . . . . . . . . . 65Specifying distribu ted m app ing tran sfers . . . . . . . . . . . . . . . . 69

Specifying distributed m apping returns . . . . . . . . . . . . . . . . . 74

Settin g distribu ted m app ing help . . . . . . . . . . . . . . . . . . . 76

Viewing and m odifying distributed m apping change history . . . . . . . . 77

W orking with distributed po ols . . . . . . . . . . . . . . . . . . . . . 78

Using th e distribu ted poo l wind ow . . . . . . . . . . . . . . . . . . 79Creat ing and deleting distribu ted poo ls. . . . . . . . . . . . . . . . . 79

Mo difying distribu ted poo l objects . . . . . . . . . . . . . . . . . . 81

U sing filters and escalation s for D SO actions . . . . . . . . . . . . . . . 82

Creat ing DSO action s in filters an d escalation s . . . . . . . . . . . . . 82

Creatin g DSO actions . . . . . . . . . . . . . . . . . . . . . . . . 84


5/130

Contents 5

Adm inistering BM C Remedy D SO

Co ntrolling pen ding transfer inform ation . . . . . . . . . . . . . . . . 90

Using the pend ing distributed operations window . . . . . . . . . . . . 90

H ow erro rs affect pen din g distribu ted operation s . . . . . . . . . . . . 92

Chapter 5 Creat ing Distr ibuted Server Opt ion workflow . . . . . . . . . . . 93

Basic distributed op eration s . . . . . . . . . . . . . . . . . . . . . . 94

D istribute d transfers . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Addin g distribu ted fields to your form s . . . . . . . . . . . . . . . . 95

Creat ing distribu ted m app ings . . . . . . . . . . . . . . . . . . . . 96

Creatin g a filter . . . . . . . . . . . . . . . . . . . . . . . . . . . 98D istribute d up dates . . . . . . . . . . . . . . . . . . . . . . . . . . 100

D istribute d returns . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1

D istribute d dele tes. . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3

Appendix A Advanced topics . . . . . . . . . . . . . . . . . . . . . . . . 107

Setting up chain ed distribu ted transfers . . . . . . . . . . . . . . . . . 108

Special con sideration s for chain ed distribu tion . . . . . . . . . . . . 108

Definin g a chain ed distribu ted tran sfer . . . . . . . . . . . . . . . . 111

Broad cast distribu ted transfers . . . . . . . . . . . . . . . . . . . . . 115

Using broad cast tran sfers to m anage DSO from a central location . . . . 117

Appendix B Distributed Server Administrat ion program . . . . . . . . . . . 121

Ove rwriting basic fields exam ple . . . . . . . . . . . . . . . . . . . . 123

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125


6/130

6 Contents



7/130

Preface 7

Preface

Important: The com patibility information listed in th e prod uct

docu m entation is subject to ch ange. See the com patibility matrix at ht t p: /

/ suppor t web. r emedy. comfor the latest, most com plete inform ation abou t

what is officially supp ort ed.

Carefully read th e system requirem ents for your particular operating

system, especially the n ecessary patch requ irem ents.

Audience

This guide for adm inistrators who are responsible for setting up andm aintain ing the BMC Remed y Distribu ted Server O ption .

As the adm inistrator, you shou ld be familiar with BMC Rem edy User an d

BMC Remedy Adm inistrator client to ols. It is also helpful to h ave an

un derstanding of how to adm inister distributed applications.

This guide assum es that you are familiar with th e inform ation con tained in

the following help systems and m anuals:

BM C Rem edy User H elp

Configuring

Form and A pplication O bjects

W orkflow O bjects

Concepts
http://supportweb.remedy.com/http://supportweb.remedy.com/http://supportweb.remedy.com/http://supportweb.remedy.com/


8/130

8 Preface


AR System docum ents

The following table lists docum entat ion available for AR System p rod uct s.

Un less otherwise not ed, online docum entation in Adobe Acrobat ( PDF)

form at is available on AR System pro du ct installation CD s, on the Cu stomer

Sup por t site (suppor t web. r emedy. com), or both.

You can access produ ct Help throu gh each pr odu cts H elp m enu o r by

clicking on H elp links.

Tit le Descript ion AudienceConcepts Overview of AR System architecture and features with

in-depth examples; includes inform ation abou t other

AR System prod ucts as well as a com prehen sive glossary

for th e entire AR System docum entation set.

Everyone

In stallin g Procedures for installing AR System . Adm inistrators

Getting Started Intro duces topics that are usually only learned when first

startin g to use the system, includin g logging in, searching

for objects, and so on .

Everyone

Form and Application O bjects Describes comp on ents necessary to b uild applications in

AR System , includ ing applications, fields, form s, and

views.

Developers

W orkflow O bjects Con tains all of the workflow inform ation. Developers

Configuring Con tains inform ation about con figuring AR Systemservers and clients, localizing, im portin g and exporting

data, and archiving data.

Administrators

In sta llin g an d A dm in isterin g

BM C Rem edy M id T ier

Contains inform ation about the m id tier, including m id

tier installation and configuration , and web server

configuration.

Administrators

In tegra ting with Plu g-in s an d

T hird-Party Products

Discusses integrat ing AR System with extern al system s

using plug-ins and other p rodu cts, including LDAP,OLE, and ARDBC.

Administrators

/Develo pers

Optim izing and

Troubleshooting

Server adm inistratio n to pics and techn ical essays related

to m onitoring and m aintaining AR System for the

pur pose of optim izing perform ance and troubleshooting

problems.

Administrators
http://supportweb.remedy.com/http://supportweb.remedy.com/


9/130

AR System document s 9

Adm inistering BM C Remedy D SO

Dat abase R eferen ce Database adm inistration t opics and rules related to ho w

AR System in teracts with specific databases; includ es an

overview of the data d ictionar y tables.

Administrators

A dm in isterin g BM C Rem edy

DSO

Server adm inistration and procedu res for im plemen ting

a distributed AR System server environm ent with the

BMC Rem edy Distributed Server Op tion (D SO) .

Administrators


Flashboards

Flashboards adm inistration and pr ocedures for creating

and m odifying flashboar ds and flashboards com pon ents

to display and m onitor AR System inform ation.

Administrators

/Pr ogram m ers

C API Reference Information about AR System data structures, C API

function calls, and O LE support .

Administrators

/Pr ogram m ers

C API Q uick Reference Quick reference to C API function calls. Adm inistrators

/Pr ogram m ers

Java A PI* Inform ation about Java classes, meth ods, and variables

that integrate with AR System.

Administrators

/Pr ogram m ers


Em ail Engine

Procedur es for installing, configuring, and using the

BMC Remedy Email Engine.

Administrators

Error M essages List and expand ed description s of AR System error

messages.

Administrators

/Pr ogram m ers

M aster Index Com bined index of all books. Everyone

Release N otes Inform ation about new features list, com patibility lists,

internat ional issues, and open and fixed issues.

Everyone

BMC Rem edy User H elp Procedures for using BMC Rem edy User. Everyone

BMC Rem edy Im port H elp Procedures for using BMC Rem edy Im port. Adm inistrators

BMC Remedy Adm inistrator

Help

Procedur es for creating and m odifying an AR System

application for tracking data an d p rocesses.

Administrators

BMC Rem edy Alert H elp Procedures for using BMC Rem edy Alert. Everyone

BMC Remedy Mid T ier

Con figuration Too l Help

Procedures for configuring the BMC Remedy Mid Tier. Administrators

*. A JAR file containin g the Java API docum entation is installed with th e AR System server.

Typically, it is stor ed in C: \ Pr ogr am Fi l es\ AR Sys t em\ Ar ser ver \ Api \ doc\ ar doc70. j ar on

Windows and/ usr / ar // api / doc/ ar doc70. j ar on UN IX.

Tit le Descript ion Audience


10/130

10 Preface


Learn about t he AR System Developer Com m unity

If you are interested in learning m ore abou t AR System, looking for an

opp ortu nity to collaborate with fellow AR System developers, and searchingfor additional resour ces that can benefit your AR System solution , then th is

on line global com m un ity sponsored by BMC Rem edy is for you.

In th e Developer Com m un ity, you will find collaboration too ls, prod uct

inform ation, resou rce links, user grou p inform ation, and b e able to pro vide

BMC Remed y with feedback.

The D eveloper Com m un ity offers the following too ls and information :

Community message board

Community Downloads

AR System Tips & Tricks

Com m un ity recom mend ed resources

Product inform ation

User Experience Design t ips

Why should you participate in th e D eveloper Com m unity?

You can benefit from participating in the Developer Co m m un ity for the

following r easons:

The com m un ity is a direct result of AR System developer feedback.

BMC Remedy pro vides un suppo rted applications and utilities by way of

Com m un ity Down loads, an AR System application.

BMC Rem edy posts the latest AR System p rod uct inform ation in th e

Developer Com m un ity to keep you up to d ate.

It is an op por tun ity to directly imp act produ ct direction thr ou gh online

and em ail surveys.

Its free!

How do you access the D evelop er Com m unity?

Go to suppor t web. r emedy. com, and click the D eveloper C om m un ity link.
http://supportweb.remedy.com/http://supportweb.remedy.com/


11/130

Using the distribut ed server environm ent 11

Chapter

1Using t he dist r ibu t ed serverenvi ronment

The BMC Remed y Distributed Server O ption (DSO) lets you tran sfer data

between forms on different servers whether th e servers are on th e sam e host

or on p hysically different h osts. Th is op tion is available on both W indowsand UN IX servers, and is configured thro ugh BMC Remedy Adm inistrator.

The following topics are provided :

Overview of the Distributed Server O ption ( page 12)

Using the Distributed Server Option ( page 12)

Man aging the exchange of inform ation (page 14)

Defining distributed o perations (page 20)

Overview of setting up d istributed o perations (page 29)

Note: Before using the Distribut ed Server Op tion , you shou ld be fam iliar

with the features and functions of both BMC Rem edy User and BMC

Remedy Adm inistrator. If you are no t yet fam iliar with the AR System ,

review BMC Remed y User help, the Concepts guide, the Configuring guide,th e Form and A pplication O bjects guide and th e W orkflow O bjects guide

before contin uing.


12/130

12 Chapter 1 Using the distributed server environm ent


Overview of the D istribu ted Server Opt ion

To un derstand the function o f the D istributed Server Option , imagine that

your com pany is run ning AR System in a single-server environm ent alltransaction s that ru n o n th e client m achines exchan ge data with on e server.

All data on that server is cur rent, m eaning that it is never u pdated from

sources other th an its conn ected clients.

You add a site with AR System on a different server, so you n eed a solut ion

that lets you exchange data between similar o r d ifferent forms on the two

servers, and that keeps requests on both system s current. Th e Distributed

Server O ption helps you configure and m aintain th ese data exchanges, andestablishes tim e intervals for data transfer, up date, and retur n.

Note: The D istributed Server O ption in p re5.0 versions of AR System was a

separate service. Start ing with version 5.0, DSO is nota separate service

it has its own execu table file, which is included in t he AR System Server

and is started by ar moni t or . Upgrading to a version o f 5.0 or later r emo ves

th is service.

Using the D istributed Server Op tion

The D istributed Server O ption has m any uses. These include, but ar e not

lim ited to:

Transferring requ ests to th e location at which th ey can b e pr ocessed.

For example, you r com pan y services office fur n iture. Desks are repaired in

San Francisco, and chairs are repaired in Ch icago. When someon e in San

Francisco creates a broken chair requ est, the requ est can be autom atically

tran sferred to a server in Ch icago. If the r equest n eeds a specialists

attention, for exam ple, ripped uph olstery, the r equest can be tr ansferred

to a different server that h and les uph olstery repairs.

Tran sferring requ ests between regions in a 24-hou r, seven- days-per- week

customer sup port environm ent. You can configure th e Distributed Server

Op tion to autom atically forward open prob lem requests to the next site at

the close of the b usiness day in the curren t r egion.


13/130

Using th e Distribut ed Server Opt ion 13

Adm inistering BM C Rem edy D SO

For exam ple, your com pan y has customer sup por t centers in San

Francisco, Paris, and Tokyo. You can forward op en requ ests from San

Francisco to Tokyo at th e end o f the San Fran cisco bu siness day, when it

is early in Tokyos next business day. In t ur n, op en requests can be

forwarded from Tokyo to P aris at the end of the To kyos business day.

Th is app roach h elps alleviate down t ime.

Creating a d istributed knowledge base, so that pro blem -solving

inform ation is accessible from any location.

For exam ple, you can create filters or escalations that in struct th e

Distributed Server O ption to forward requests closed on one server to all

oth er servers in the environm ent. All servers have access to the p rob lem -solving inform ation an d solutions con tained in the closed r equests.

Archiving o ld requ ests.

Th is featu re is helpful if you have a server ded icated to ar chival functions

in your environ m ent. Closed requ ests can be sent to th e archive server and

stored in on e place. Addition ally, archiving closed requ ests frees up m ain

servers for users who n eed access to the inform ation for rep orts or otherresour ce-inten sive tasks.

Using D SO w ith server group s

Using DSO with a server grou p provides autom atic failover capab ility for

tran sfer operation s typically restricted to o ne server.

To u se DSO in a server group environm ent, you configure your server grou pas described in Configuring. Then, when you create a distributed m apping

and you specify a server (belonging to a server group ) from which the

tran sfers will originat e, you also specify whether any server in th e grou p can

send t he tr ansfer. See Specifying d istributed m apping basics on page 63.

Note: For distribu ted retu rns, distributed deletes and u pdates within an

own ership chain , you canno t use a server group as the target you m ust

specify a server explicitly. Such a mappin g will only work for th e specified

server an d will no t m ake use of the server group in t he event of a system

failure.


14/130



M anaging th e exchang e of information

The BMC Remedy Distribut ed Server O ption pro vides a mu ltithreaded

process that lets you cop y AR System requ ests between servers and keeprequ ests synchron ized across mu ltiple servers, even if tho se servers are

geographically d ispersed.

You can m anage the exchange of infor m ation in the following ways:

Creating distributed m appings between forms.

Distribut ed m appings are mo st comm only used to link fields with like

field ID s or field n am es between sim ilar or different form s. You can alsouse distributed m appings to create custom m appings that link a selection

of similar or different fields, or th at link a single field to m ultiple fields.

Distributed m appings define how data is transferred from on e form to

anoth er, how frequen tly up dates are processed, and how conflicts in

distribut ed o perations are resolved.

Adding distributed fields to forms.

Adding distributed fields to form s lets you m anage distributed m apping in

ownership-based tran sfers. The th ree grou ps of distribu ted fields basic,

full, and ad vanced provide different levels of con tro l over d istribu ted

mappings.

Defining distributed po ols to h and le specific DSO wo rkflow action s.

Distributed poo ls let the DSO pr ocess man y distributed o perations

sim ultan eously. You can cr eate distribu ted po ols and assign DSO actionsto t hese poo ls for parallel processing, which m inim izes delays and

significantly increases the outp ut of distribu ted operation s when D SO

activity is heavy. For m ore inform ation abo ut creating an d wo rking with

distribu ted po ols, see Wor king with distribut ed pools on page 78.

Assigning unique request ID prefixes.

Althou gh requ est IDs are no t DSO-specific, the ability to tailor th e form atof request IDs is an im por tant feature for d istributed operations. Setting

up un ique requ est IDs p revent s dup licate requests on d ifferent servers,

and lets you specify what action will be taken sho uld a du plicate request

occur.

Ad i i i BM C R d D SO


15/130

M anaging the exchange of information 15


Using D istribut ed Server Option form s

After licensing, the Distributed Server Op tion au tom atically add s th ree

requ ired form s. The following list describes each type of form :

D istributed Mapping form D efines and m aintains parameter an d d ata

cont rol values of specific distribu ted m app ings.

D istributed Pending form M aintains a queue of pend ing distributed

transfers, updates, returns, and deletes.

D istributed Poo l form Defines and m aintain s definition s of specific

distributed poo ls.

You can tran sfer entries in the D istributed M apping and Distribu ted Pool

form s to their coun terparts on rem ote servers, using the instru ction s in t his

docum entation for m apping any form s.

WARNING: Do not m odify or d elete these form s.

Using distributed m app ings

Con figuring m appings for a d istributed operation is an im por tant first step

toward designing a distribu ted system. Map pin gs are created as objects on

the server and stored on the Distribut ed Mapp ing form . The m apping

definition includ es resolving du plicate request IDs and han dling certain d ata

contro ls, such as transfer m ode, up date, and retry intervals.By specifying m ultiple m app ings between two form s, you can explicitly

choose the type of m apping app rop riate for each situation.You can also

specify default mappings if the AR System find s mu ltiple mapp ings

app licable to th e specified tr ansfer criteria.

Con figurin g mappings is a simp le process if you are tran sferring data

between two iden tical form s. If you are tran sferrin g data between different

form s, you n eed to determ ine which fields are m app ed to specific fields (an d

in som e cases, which m ultiple fields are map ped to single fields) in the

target form .

You also n eed to con sider t he results of map ping fields of un equal size or

m app ing fields con taining different d ata types, such as a character field

m app ed to a d ate or tim e field. If a sou rce field type exceeds the limitation s

of a target field t ype, for example, the field length , the distribu ted operation

will result in an erro r.

BMC Remed y Action Request System 7 0


16/130



Wh en creating the filter or escalation th at triggers a distribut ed op eration ,

you can specify which m app ing to u se, or let th e system select a default

m app ing. You can also override th e details of a mapping for a par ticular

distribu ted op eration before it occurs by assigning values in th e distributed

fields that you add to th e form s. For m ore inform ation abou t overriding

m app ing settings, see Overriding map ping settings on a per-r equest basis

on page 23.

For mo re inform ation about m appings, see Creating and m odifying

distributed mappings on p age 60.

Using d istributed fieldsYou m ust add distributed fields to form s to m anage ownership-based

transfers. You can override m uch of the m appings definition by adding

distributed fields directly into your d istributed forms. For inform ation abo ut

own ership-b ased transfers, see Using distributed tran sfers on p age 20.

Note: For information abou t ownership , see Owner ship and own ershipchains on page 21.

You can add three group s of distribu ted fields to your forms to sup por t

distribu ted operation sBasic, Full, and Advanced . The following list

describes each type:

Basiclets you m ake transfers with ownership. The Distribu ted ServerOp tion sets the values for th ese fields.

For example, if you want to kno w where a request cam e from , you can

review the From Form and From Server fields for in form ation.

Fullin cludes the Basic fields. Gives you greater con tro l over the choice

of map pings when a possible conflict between m app ings exists, and it

provides m apping history inform ation . You set som e of these fields, and

the system sets oth ers.

For exam ple, if you wan t to kn ow where a requ est was tran sferred , you can

review the To Mapp ing, To Form , and To Server fields for inform ation.

Advancedincludes the Basic and Full fields. Lets you override t he

settings previously defined for a m apping in t he D istribut ed Map ping

window.



17/130



For examp le, if you want t o override the m ethod of distributed transfer

operations from d ata-only to data+own ership, you can m odify the

Transfer M ode d istributed field. For inform ation abou t u sing distributed

fields to alter a m apping for a particular distribut ed op eration, see

Creating DSO action s in filters and escalations on page 82.

The following tab le shows the d istribu ted fields available for each grou p.

Table 1-1: Distributed field groups and associated field names

Distributed field group Field nam e

Basic Transfer status

Update status

Master flag

From Request ID

From Form

From Server

From Pool

Full To Mappin g

From Mapping

To Request ID

To Form

To Server

Advanced Mapping H istory

Current Form

Cur rent Server

When to Update

Transfer Mode

Du plicate Request ID Action

Max time to retry

Enforce Pattern M atching

Require Required Fields

Matchin g Q ualification

BMC Remed y Action Request System 7 0


18/130



For instru ction s about adding d istributed fields, and for descriptions o f each

field, see Working with distributed fields on form s on page 50.

Using d istribut ed poolsDistribu ted po ols, like distribu ted m app ings, are created as objects on the

server, and stored o n the D istributed Pools form . Distributed pools let you

use m ultiple pools (threads) to accurately process pendin g distributed

operations du ring periods of heavy distribu ted activity. You can define

several pools and associate each DSO oper ation with a p ool.

All pendin g DSO operation s within each p ool are executed in order.Therefore, you m ust consider the interdepen dencies between t he form s

within an application all distributed operations associated with on e form,

and on interdepend ent form s, should use the sam e pool to m ake sure the

ord er of execut ion is correct.

You can u se different p ools for un related distributed o perations, or when

send ing data-on ly or independ ent copies of requests to different

destinations.

For exam ple, you r system is experiencing heavy distribu ted activity, and you

have mu ltiple data-only or independ ent copy tran sfers pending from

different applications. Because these operations d o n ot need to b e com pleted

in a p articular or der, you can assign th em to d ifferent poo ls.

You can designate on e poo l as the d efault poo l, or u se the default poo l

created by the system . If you do no t create any distribu ted pools, or assign anoperation to a pool that d oes not exist, the pend ing distributed o peration is

han dled by the default poo l. For inform ation abou t creating, mo difying, and

deleting distribut ed pool ob jects, see Working with distributed p ools on

page 78.

Using req uest IDs

Perhaps the mo st impo rtan t comp on ent of a request in a distributed

environm ent is the request ID . Like the nam e of a person, th is is the piece of

data you will most likely use to identify and track ind ividu al requests, and it

shou ld be un ique. Requ ests entered on the same server will have different

requ est IDs. Requests ent ered on two differen t servers can h ave the sam e

requ est ID, causing conflicts when r equests are tran sferred o r shared b etween

the servers.



19/130


d ste g C e edy SO

The D istributed Server O ption offers different m ethods for avoiding and

addressing duplicate request ID s. You can assign prefixes to r equests ent ered

on different servers, or, if you choose no t to u se prefixes, specify in th e

Distributed Mapp ing wind ow how a du plicate request ID should be

addressed.

Preventing dup licate request IDs

The best way to avoid having du plicate requ est IDs in your distributed

environment is to assign site-specific prefixes to r equests. For exam ple, you

m ight ad d a p refix ofSAN to requests created on server sanf r anci sco,

creating an ID o f SAN00004598. For m ore information abou t assigningprefixes to AR System requ est IDs, see the Dat abase R eference guide.

Hand ling dup licate request IDs

If you choo se not t o u se site-specific request ID pr efixes, duplicate request

IDs m ight b e generated. In some cases you m ight wan t th e newer version of

a request to overwrite the older version, bu t in other cases, you m ight wan t

to keep all copies of a requ est.

The D istributed Server O ption perform s one of the following actions when

du plicate request IDs occur:

Generates an error m essage and do es no t perform the tran saction.

Creates a new request ID for th e newer copy.

Overwrites the o lder copy of the r equest with t he n ewer cop y.

By default, the overwrite action up dates on ly the map ped fields on th e target

requ est, bu t you can con figure th is action to replace all fields on the tar get

request. For m ore inform ation, see Configuring overwrite behavior for

du plicate request IDs on page 44.

You should d etermine how you will hand le duplicate request IDs for all you r

m app ings, and if possible treat all m app ings the same. Using differen tdu plicate requ est ID strategies can cause adm inistrative problem s when

tracking data.

M atching source and destinat ion requests

By default, DSO u ses requ est IDs to m atch sou rce requests with destination

requ ests. You can, however, use other m atchin g qualifications based on fields

in the source and target form s.



20/130


y q y

Using m atching qu alifications is useful when , for examp le, you h ave existing

data in the source and d estination form s and you do n ot want to u se special

request ID p refixes to distinguish en tries created in on e form from anot her.

In th is case, you specify a data field other t han requ est ID to u niqu ely ident ify

each entry. AR System uses that data field to m atch a d estination r equest (if

on e exists) with the sou rce request.

Note: A unique ind ex shou ld be created on the data field used to u niqu ely

identify one request from anoth er.

See Specifying distributed m apping option s on page 65.

Defining distributed operations

You can perform four pr imary types of data transaction s using the

Distribu ted Server Op tion: transfers , updates , returns, and deletes. The

m ain d ifferences amon g these operations are ho w th ey are initiated (by filters

or escalations, or au tom atically by the system) an d how own ership of a

requ est is treated.

In th e figures in this section , the forms th at are darker in color r epresent the

request that h as ownership after th e operation h as been com pleted. For

sample scenarios of how to perform each of these operations, see Chapter 5,

Creating Distributed Server Option workflow.

Using d istributed transfers

A distributed transfer tran smits inform ation from on e server to anoth er, and

occurs when you ent er or change inform ation in a form . When a requ est is

created or m od ified, the entry triggers workflow to create a copy of the

inform ation and t hen tran sfer it to anoth er form . The transfer m ight include

the en tire requ est and all its in form ation , or just specific data. A transfer isno t auto m atically generated; you m ust create one by defining a m apping and

creating a filter or escalation to p erform the transfer.

Before you begin im plementing th e Distribut ed Server O ption , determin e

how m uch contr ol you need o ver th e data being transferred. Ask yourself the

following qu estion s:

Shou ld one server own m aster cop ies of the r equests being transferred, or

should all copies be independ ent o f one anoth er?



21/130

Defining distributed operations 21

H ow often shou ld I upd ate requests on m y server?

H ow will I han dle dup licate request IDs?

Will I need to override the map ping contro l settings on a per-requ est

basis?

Ow nership and ow nership chains

Ownership plays a large par t in distributed operations , because having

ownership of a request lets you m ake mod ifications to the inform ation.

Typically, you will transfer a requ est with own ership to a server th at can

add ress the request directly. Mod ifications can on ly be made in the requestwith ownership.

Wh en own ership is transferred with a requ est, you create an ownership

chain. The active o wnership chain begins with the r equest that h as

ownership, and extends to th ose requests from which ownership was

transferred.

For examp le, you have a requ est with own ership on server sanf r anci sco, but

the issue m ust be add ressed from server chi cago. You t ran sfer that r equest

with ownership to server chi cagoyou transfer ownership so that chi cago

users can m ake necessary m odification s to th e request. Depending on your

workflow con figur ation s, server sanf r anci sc o m ight receive up dates of the

changes made o n server chi cago through a distributed upd ate operation.

Server sanf r anci sco canno t, however, m ake mo difications to th e request

un less the request is return ed with ownership thr ough a distributed retu rn

operation.

Note: The com bination o f transferring ownership and overwriting existing

requests in a ch ained environm ent can create an infinite loo p . To perform

a chained d istributed transfer, you m ust enable the O verride Loop

Detection option in the filter that p erforms the tran sfer. For m ore

inform ation, see Avoiding infinite loop s on page 109.



22/130


Types of distribu ted transfer ope rations

Four types of transfer o perations enable you to m anage your requests on

m ultiple servers.

Data-only

Data+Ownership

Independent Copy

Copy+Delete

Data-only

Data-only transfers let you t ransfer a r equest to an oth er server, most

typically for archiving and as futur e inform ation resour ces. Because data-

on ly copies do n ot ho ld ownership, they cann ot be m odified and cann ot

begin an ownership chain.

Data+Ownership

D ata+ Ow nership transfers let you transfer a r equest with o wnership to

anoth er server so that u sers on the target server can m ake necessary

m od ification s. Because a request with ownership is con sidered a m aster copy,

you can m ake mo difications that will be up dated o n all copies of the request

within the ownership chain.

Independent copy

Independ ent co py transfers are like data-on ly tran sfers because they are

transferred withou t ownership and d o no t receive upd ates from th e mastercopythey are outside of the ownership chain. You can m odify independ ent

copies, which can start new own ership chains of their own .

Copy+Delete

Copy+Delete transfers let you tran sfer an independ ent copy of a requ est to a

specified server, and t hen delete the original request.

Wh en d efining you r m appings for t hese transfer op erations, consider what

kind of data you are transferring. Dynam ic data, such as an entry in a bu g

tracking form , is often m odified at the site to which it is transferred. Th is type

of data can be tran sferred in a d ata+o wnership tran sfer.

Static data, such as custom er biograph ical inform ation , is probab ly no t

m odified at th e site to wh ich it is transferred, and can be tr ansferred as a data-

on ly or indepen dent copy.



23/130


Overriding m app ing settings on a per-request basis

Som etimes ind ividual tran sfers require you to use an existing m apping, but

change how one or m ore of the fun ctions defined in th e Distributed M apping

window is used for th e m apping. For exam ple, you have a mapp ing with t hestandard transfer m ode d efined as data-on ly, but for on e particular transfer

perform ed by that m apping, you n eed to send data andownership.

The D istributed Server O ption lets you add to any form distributed fields

that accept the same values as their coun terparts in the D istributed Mapp ing

window. In turn , when a user subm its or m odifies data in the form, the

workflow can assign values into t he distribu ted fields to overr ide the pr e-set

definitions in th e distributed m apping. In th e previous example, you wouldadd distributed fields to t he form in qu estion, and then select

Data+Ownership in the Transfer Mod e field.

Note: In th e figures in this section, th e forms th at are darker in color

represent the requ est that h as ownership after the operation has been

com pleted. For sample scenarios of how to perform each o f these

operations, see Chapter 5, Creating D istributed Server O ption

workflow.



24/130


Figure 1-1: Transfer f low

For mor e information about how the AR System determ ines m apping

criteria for a tr ansfer, see Creating DSO actions in filters and escalations onpage 82.

Using distributed up date s

A distributed update is used to keep all cop ies of a request within an

ownership chain curr ent with the m aster copy. Mo dified inform ation from

the request with own ership is sent t o all copies of a requ est within anown ership chain at a specified time int erval. Upd ates occur au tom atically,

depend ing on the up date option specified in the m apping.

Copy

Original

Bug tracking form on serversanfrancisco. Originalentry made here.

Entry transferred to serverchicago.

1

2

Transfer

1

2



25/130


For examp le, you have a broken keyboard , so you subm it a replacement

requ est on server sanf r anci sco. Because office equipm ent r eplacemen ts are

han dled by server chi cago, the requ est is transferred using a data+ ownership

distribut ed tran sfer operation (creating an ownership chain between

sanf r ancsi co an d chi cago). After the keyboar d has been replaced, the

request status is chan ged to Com pleted. Th is status chan ge triggers an up date

of the n ew inform ation back to server sanf r anci sco, upd ating their copy of

the requ est.

The D istributed Server O ption pro vides five option s to contr ol when

requests in an active ownership chain are up dated by m odifications to the

m aster copy. You can specify to en able upd ates im m ediately, once an hou r,

on ce daily, on a d istributed r eturn operation , or no t at all.

Variou s factors shou ld influence your determ ination of whether to u pd ate

a requ est.

If the m app ing you define is between two form s whose requests are static,

you pro bably do n ot n eed to up date you r copy, because the original and

the copy will remain u nchan ged after the tr ansfer.

If you an ticipat e that u sers at the o ther site will modify distribu ted

requests you m ake and th at you requ ire those mod ifications, then you will

want to up date your cop y.

If you decide you want to u pdate requ ests on your server, you m ust

determ ine the update interval. Som e changes to r equests will be so u rgent

that you will want t o see tho se chan ges imm ediately. Other chan ges that ar e

no t so imp ortan t can b e deferred to a greater interval, such as ho ur ly or d aily.In o ther cases, you m ight o nly want your copy upd ated when anot her site is

return ing ownership of the request to you.

The following figur e shows the basic flow of a distribu ted u pd ate.



26/130


Figure 1-2: Update flow

Using d istributed returnsA distributed return is used to send t he up dated requ est, with o wnership,

back to th e originating server. Distribu ted retur ns are tr iggered using a filter

or escalation o n th e server that sends the retu rning requ est.

Using the previous exam ple from the D istributed Upd ates section , you have

a broken keyboard , so you subm it a repair request on server sanf r anci sco.

Because office equipm ent r epairs are han dled by server chi cago, the requ est

is tran sferred u sing a d ata+own ership d istributed tran sfer operation

(creating an o wnership chain between servers sanf r ancsi co an d chi cago).

After th e keyboar d h as been fixed, the requ est statu s is chan ged to

Completed.

The original is then updated onserver sanfrancisco.

Bug tracking form owned by

server chicago. An entry isfirst modified here.

Update

1

2

1

2

Original

Copy



27/130


Server sanf r anci sco has requ ested, ho wever, that the request with

ownership be return ed to server sanf r anci sco after the status of the request

is chan ged to Com pleted. When th e statu s chan ge is m ade, workflow is again

triggered an d t he m odified requ est with own ership is transferred back to

server sanf r anci sco, leaving a data-o nly copy of the requ est on serverchi cago. The request can no w be m odified on server sanf r anci sco again, if

necessary.

The following figur e shows the basic flow of a distributed retu rn with

ownership.

Figure 1-3: Return flow

Original

Ownership is returned to serversanfrancisco.

Bug tracking request on server chicago.The return is triggered here.

1

2 Return

1

2

Copy



28/130


Using d istribut ed deletes

A distributed delete lets you d elete cop ies of a requ est. If you delete the

m aster copy in an active ownership chain , all cop ies of the requ est are deleted

within t he own ership chain. Addition al delete capabilities lets you deletespecific requ ests, including data-on ly requ ests. You m ust specify a separ ate

filter or escalation action to r un the D istribu ted Delete pro cess for each copy

of the requ est.

For m ore inform ation abou t ownership chains, see Ownership and

ownership chains on p age 21.

For exam ple, an em ployee finds that h is pho ne do es not work and subm its arepair requ est on server sanf r anci sco. Because telecom m unication services

are han dled by server chi cago, the requ est is transferred u sing a

data+ ownership distributed tran sfer operation ( creating an own ership chain

between servers sanf r ancsi co an d chi cago).

H owever, the em ployee later discovers that h is phon e is unp lugged, not

bro ken, and calls the service center to can cel the repair requ est. In stead of

changing the status of the request to Com pleted, the suppo rt p erson changesthe statu s to Can celed. Previously con figured workflow executes a

distributed delete operation when the status changes to Can celed, and deletes

the m aster copy of that requ est on server chi cago, as well as the cop y of that

request on server sanf r anci sco.

Note: All cop ies of a request within an own ership chain ar e deleted in a

distributed delete operation.



29/130

Overview of setting up distributed op erations 29

Overview of sett ing up distribut ed operations

To set u p distributed operations between similar o r d ifferent forms, follow

these basic steps, which are detailed in t his manual.

Step 1 License and start the Distributed Server Op tion o n every server involved in a

DSO tr ansfer.

Note: You d o need n ot to h ave DSO license on t arget server if it is no t sending

any respon se back to sour ce server.

Step 2 Determine which forms need to b e m apped to each other.

Step 3 Determ ine whether you will use distributed poo ls, based on the volum e of

distribu ted op eration s that will be pro cessed.

Step 4 Determ ine the amo un t of contr ol you n eed over the data being transferred.

Step 5 Decide which ownership and con tro l capab ilities you n eed and , if necessary,add th e approp riate fields to each form . For m ore inform ation, see Working

with distributed fields on form s on p age 50, and To specify or ch ange

distributed m apping transfer definitions on page 70.

Step 6 Using BMC Remedy Adm inistrato r, log in to all servers to be used in the

distributed operation .

Step 7 Select an app rop riate server, the Form s server object, and an ap plicable form ,

accordin g to the form s you selected in Step 2.

Step 8 Add distribu ted fields to each form using the Distribut ed Fields windo w,

depend ing on th e level of contro l decided on in step 4.

If you plan to tr ansfer requests with o wnership, you need to add ap pro priate

distribu ted fields to every sou rce and target form on each server. Repeat steps7 and 8 for each ap plicable form.

For m ore inform ation abou t d istribut ed fields, see Working with

distributed fields on form s on p age 50.



30/130


Step 9 Create a new D istributed M apping object on each server involved.

This object identifies the From and To servers and their correspon ding

form s, and specifies op tion s such as tran sfer of ownership an d frequency of

up dates. For m ore inform ation, and for d escriptions of the fields on each tabof the Distributed M apping window, see Creating and m odifying

distributed mappings on p age 60.

Step 1 0 Create a new D istributed Poo l object on each app licable server for each set

of related distribu ted op eration s, accord ing to your an alysis in step 3.

Each object defines a new poo l or th read within the D istributed Server

Op tion to han dle pending distributed op erations. After defining a po ol, youm ust associate DSO filter o r escalation actions with t he poo l. Assign all

related o perations to the sam e po ol, because operation s assigned to different

pools might execute out of the intend ed sequ ence.

For general inform ation abou t distributed p ools, see Using distributed

pools on page 18. For inform ation abo ut creating, m odifying, and deleting

distribu ted poo ls, see Working with distributed pools on page 78.

Step 1 1 Create a filter or escalation th at defines the con ditions un der which a d ata

tran sfer, retur n, or d elete will occur .

For a d iscussion of distribut ed op eration s triggered by filters and escalations,

see Using filters and escalation s for DSO actions on page 82.

Step 1 2 Op tionally, emp loy som e of the ad vanced fun ctions discussed in the

appendixes.

Un less otherwise no ted, exam ples in th is guide assum e you are m apping

between two servers. If you need to m aintain data integrity on m ore than two

servers, you can extend your u sage of the Distribu ted Server O ption by

incorpo rating additional servers into your environm ent. For inform ation

about using mor e than two servers in your distributed en viron m ent, see

Advanced topics on p age 107

Note: For functional examp les of setting up each distributed operation for

Acm e Ind ustries, a m anu facturer of custom office fur nitur e, see Chapter

5, Creating Distribu ted Server Op tion wor kflow.


31/130

Licensing DSO 31

Chapter

2Licensin g DSO

This chapter pro vides inform ation abou t licensing the AR System . The

following top ics are pr ovided:

Overview (page 32)


O i


32/130

32 Chapter 2 Licensing DSO

Overview

AR System licensing gran ts the full and legal use of AR System and is

necessary for p erform ing operations that chan ge or u pdate th e database (for

exam ple, up dating requests or record s). To ru n an un lim ited AR System

server at you r site, an AR System server license is requ ired. Ther e are

additional AR System server op tions , such as the Distribu ted Server Op tion

(DSO) and Flashboards th at requ ire a separate, additional license.

In ad dition t o 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 pro du ct, once licensed with the AR System server

license, comes with thr ee Fixed W rite licenses, un lim ited Read licenses, and

un lim ited Restricted Read licenses. You can pur chase addition al user Fixed

Wr ite licenses and u ser Floatin g Write licenses by con tacting your BMC

Remedy Pro du ct sales repr esent ative or an au thorized reseller.

You can evaluat e the Action Requ est System withou t pu rchasing oractivating any licenses. H owever, you are lim ited to a m aximu m of 2000

records per form .

If you plan t o install any AR System app lication that requ ires a license key

(for examp le, DSO) , you can o btain th e license key information for all you r

prod ucts at on e tim e. You can th en sub m it a single license key requ est to take

care of all you r application s at once.

For inform ation ab out obtaining an d activating AR System server, server

op tion , user, and ap plication licenses, see the Configuring guide.


33/130

Configuring the d istribut ed server 33

Chapter

3Conf igu r ing t he dist r ibu t edserver

This chap ter describes ho w to configure general settings for t he Distribu ted

Server Op tion . The following topics are provided :

Setting u p th e local and rem ote DSO servers (page 34)Up grading previous version s of AR System (page 43)

Specifying a DSO host n ame for d istributed m appings (page 44)

Con figuring overwrite behavior for du plicate request IDs (page 44)

Con figuring the RPC timeou t setting (page 45)

Con figuring DSO for load balancing (page 45)

Using debug trace m ode to create log files (page 46)For m ore inform ation abo ut Action Request System (AR System) server

m anagement, see the Configuring guide and the Optim izing and

Troubleshooting guide.


Set ting up the local and rem ote DSO servers


34/130

34 Chapter 3 Configuring th e distributed server

Set ting up the local and rem ote DSO servers

AR System 7.0 lets you con figure AR System servers involved in d istribu ted

operations with different RPC program n um bers, por t nu m bers, and

passwords th rou gh server inform ation settings.

Server inform ation settings for th is release of the Distribu ted Server Op tion

have changed. If you have upgraded from a p revious version , you r o riginal

settings are preserved and can be accessed th rou gh th e ar . cf g (Windows) or

ar . conf (U NIX) file. You m ight wan t to m igrate to th e new settings.

See theRelease N otes for upgrade instructions.

Configuring a local AR System server

If you want to configure com m un ication, firewall protection, and password

security, you m ust do so for th e local DSO server before configuring any

remo te DSO servers.

After you con figure the local AR System server, you en ter inform ation for

rem ote AR System servers. For m ore inform ation abou t configuring remot e

AR System servers, see Configur ing a rem ote AR System server on page 41.

Assigning a d edicated RPC program num ber to a local

server

Altho ugh u sing specific RPC program nu m bers is not r equired by the

Distribu ted Server Op tion , you m ight d ecide to assign specific RPC pro gram

nu m bers if you have a large environm ent with h eavy dat a traffic, or if you r

environ m ent has a large am oun t of distribution .

If you plan on using a specific RPC program nu m ber, it m ust be either 390600

(the Adm inistrator pr ogram n um ber) or in the following range: 390621 to

390634,390636 to 390669, or 390680 to 390694, the ran ge for pr ivate servers. Th e

distributed server uses the assigned pro gram n um ber for all comm un ication.

To assign t he Distributed Server O ption to a specific RPC program nu m ber,

con figure the AR System server to define at least one th read on the specified

private server pr ogram nu m ber. The Distributed Server O ption process does

no t con nect d irectly to t he database itself. This configur ation tells it which

AR System server queue to com m un icate with. In t he default configuration ,

the D istribu ted Server Opt ion p rocess joins the fast and list queues like any

other client.


This configuration setting sets the distribu ted server to use the RPC program


35/130

Setting up t he local and rem ote D SO servers 35

This con figuration setting sets the distribu ted server to use the RPC program

nu m ber for access to th e local server. To con figure rem ote servers, see

Configurin g a rem ote AR System server on p age 41.

To assign a dedicated RPC program n um ber to a local server

Note: The Private RPC pro gram n um ber m ust be added in the Server Ports

and Qu eues tab of the Server In formation dialog box before configuring

the DSO local RPC program n um ber.

1 In BMC Rem edy Adm inistrator, op en a server windo w and select the localserver.

2 Choo se File > Server In form ation.

The Server Inform ation windo w appears.

3 Select the Conn ection Settings tab.

4 On th e Conn ection Settings tab, click the DSO Server tab.

5 In th e Local RPC Program N um ber field, enter the RPC pro gram n um ber for

your local server, as shown in t he following figur e.


Figure 3-1: Server Information window , Connection Settings tab


36/130


g g

6 Click OK or Apply to save RPC pr ogram nu m ber settings.

If you r eassign the RPC pro gram n um ber while run ning the D istributedServer O ption , you will not lose any work an d th e changes are transparent to

the u ser. The AR System server, however, mu st be stopp ed and restarted as

described in Licensing DSO on page 31.

Running the Distributed Server Opt ion beh ind a firewall

You can ru n AR System servers behind a firewall by add ing a TCP/IP p ort

nu m ber in th e Server Po rts and Q ueu es window, as shown in th e following

figure.


Figure 3-2: Server Ports and Q ueues tab, TCP/IP Port field


37/130


To con nect to an other m achine behind th e firewall, you m ust specify the

Local Password an d the TCP/ IP Port n um ber for the m achine to which you

want to conn ect.


Figure 3-3: Connection Sett ings tab , Local Passwo rd and Local RPC Program Nu m berfields


38/130


fields

WARNING: Do n ot assign a port nu m ber that conflicts with port nu m bersused by oth er applications or oth er program s runn ing on your system . To

find ou t which port nu m bers are already in u se, use the

net st at - a command (Windows) or the r pci nf o - p command (UNIX)

at the com m and line pr om pt. If you do not check available por ts, you

m ight assign a p ort n um ber that conflicts with other applications, and

your servers might not start as expected.

To co nfigure Distributed Server Op tion to run beh ind a firewall

1 In BMC Rem edy Adm inistrator, op en a server windo w and select the local

server.


The Server Inform ation windo w appears.


3 Select the Server Port s and Qu eues tab.


39/130


4 In th e Server TCP/ IP Port field, enter th e port nu m ber u sed for th e local

server.

5 Click O K to save your settings.

For m ore inform ation abou t configurin g servers in the AR System

environm ent, see the Configuring guide. For inform ation abo ut registering

with a portm apper, see theIn sta llin g guide.

Configuring p assw ord security on the local D SO server

The D istributed Server O ption perform s all operations as the fixed u ser,Distributed Server. You are no t required to create a user n am ed Distributed

Server as it is aut om atically created b y AR System Server.

The D istributed Server u ser h as con trolled p erm issions an d a locked nam e,

but does not require any add itional licensing.

To con trol server comm un ication an d u ser access in Distributed Server

operation s, you will need to con figure passwords in BMC Rem edyAdmin istrator for both the local and rem ote distributed servers. By

configurin g passwords for both local and rem ote servers, you can limit which

servers can com m un icate with each oth er thr ough th e Distributed Server

Op tion, and pr event u nau thor ized access to AR System .

A server with password settings can tr ansfer inform ation t o a server that d oes

no t have password settings. A server withou t password settings, however,

canno t tr ansfer inform ation t o a server with password settings, un less thetarget con nection p assword is set for t hat server. Tha t is, tran sfers will no t

work if the target conn ection password does not m atch the settings on th e

destination server.

Note: Older clients will not ask for these passwords when talking to a n ewer

server. Newer clients talking with older servers will receive an ARERR 218

Ser ver i nf or mat i on associ at ed wi t h t hi s t ag cannot be r et r i evederror message.


Note: If you are creating password s for the App lication Service and DSO


40/130


Note: If you are creating password s for t he App lication Service and DSO

server, you can set the m inimu m API version to 10 to m ake sure th at

secure 7.0 servers canno t com m un icate with servers ru nn ing previous

AR System versions. For inform ation ab ou t setting the API version, seeth e Configuring guide.

To co nfigure passwo rd security for a local AR System server

1 In BMC Rem edy Adm inistrator, op en a server windo w and select the local

server.


3 From the Server Inform ation windo w, click the Con nection Settings tab, and

then click the DSO Server tab.

Figure 3-4: Connection Settings DSO Server tab


4 Enter t he password into t he Local Password field.


41/130


Note: The DSO Local Server Password can be an y strin g up to 30 characters.

5 Click O K.

You m ust stop and restart the AR System server for con nection settings to

take effect.

Configuring a rem ote AR System server

You can con figure all remo te servers with p assword secur ity, assign d edicated

RPC program n um bers, and assign TCP/IP po rt nu m bers using the

Con nection Settings tab of the Server Inform ation wind ow.

To co nfigure a rem ote AR System server for Distributed Server

Option o perations

1 In BMC Rem edy Adm inistrator, open a server wind ow and select a remo teserver.

2 Choo se File > Server In form ation to o pen t he Server Inform ation windo w.

3 Select the Conn ection Settings tab, and then click the DSO Server tab.

4 In the Tar get Con nection Settings pane, enter t he following information , if

applicable:

Server N am e

Password

RPC Program N um ber

Por t If the remo te target server is ru nn ing behind a firewall, you will

need to enter a port num ber.


Figure 3-5: Connection Settings DSO Server tab


42/130


5 Click OK or Apply.

6 Repeat th is pro cedure for each rem ote server.

Note: You m ust restart each AR System server for the con nection settings to

take effect.


Up grad ing p revious versions of AR System


43/130

Upg rading p revious versions of AR System 43

In versions of AR System prior to 5.1, you configure RPC program and por t

nu mb ers using the Di st r i but ed- RPC- Socket an d DSO- pr i vat e- dest - por t

settings. Now, you can con figur e these settings using BMC Remed yAdministrator as explained in Con figurin g a local AR System server on

page 34, but you will need to d elete the settings in t he ar . cf g (Windows) or

ar . conf (U NIX) file, or they will override settings mad e in BMC Remed y

Administrator.

After you up grade the AR System an d u se the n ew metho ds for setting the

RPC program an d po rt nu m bers, the Distributed Server RPC Program

Nu m ber field in the Server Inform ation wind ow will appear disabled.

To set RPC program nu m bers and p orts for local and rem ote servers, review

the pr ocedures that begin with Setting up t he local and rem ote DSO servers

on page 34.

To remo ve RPC program and po rt num ber settings from

con figuration files (W indow s)1 Open the ar . cf g file. The typical path is \ Conf \ ar . cf g.

2 Delete the Di st r i but ed- RPC- Socket an d DSO- pr i vat e- des t - por t settings.

3 Save the file.

4 Repeat this procedu re for each associated AR System server.

5 Stop and restart each applicable AR System server.

To remo ve RPC program and po rt num ber settings from

con figuration files ( U N IX)

1 Open the ar . conf file. The typical path is / conf / ar . conf .

2 Delete the Di st r i but ed- RPC- Socket an d DSO- pr i vat e- des t - por t settings.

3 Save the file.

4 Repeat this procedu re for each associated AR System server.

5 Stop and restart each applicable AR System server.


Specifying a DSO host nam e for distributed m appings


44/130


The DSO uses the default server n am e for th e From server, un less you specify

the DSO host nam e parameter. The DSO h ost nam e param eter will override

the From Server r eference in the filter DSO action an d D SO m apping. You

can configure th e AR System to u se the fully qualified dom ain nam e (FQDN )

or long nam e for d istributed operations, as required by some op erating

environ m ents. The DSO will place this nam e into th e From Server field, if

this field is on th e form .

See Wor king with d istributed fields on forms on p age 50 for m ore

inform ation abou t adding distributed fields to form s.

To specify a DSO ho st name for distributed m appings

1 Stop the Action Request System Server service.

2 Open the ar . cf g file (Wind ows) or ar . conf file (UN IX).

3 Enter the ho st nam e in th e following form at:

DSO- Hos t - Name: .

where is the short nam e of the From server, such as sanf r anci sco,

an d is the do m ain nam e of the From server, such as acme. com.

4 Save the ar . cf g file (Windo ws) or ar . conf file (UN IX).

5 Start the Action Requ est System Server service.

For m ore inform ation abou t server n am es in the Action Request System

environm ent, see the Configuring guide.

Configuring overw rite b ehavior for dup licate

request IDs

If you select the overwrite action for h and ling du plicate requ est IDs, the

default behavior u pdates on ly the m apped fields on the tar get r equest. You

can con figure th e overwrite action to overwrite the con tents of the target

request.

To con figure overwrite behavior fo r duplicate request ID s

1 Stop the Action Request System Server service.



3 Enter th e following flag to u pdate m apped fields and set u nm apped fields to

NULL:


45/130

Configuring the RPC tim eout setting 45

DSO- Mer ge- DupI D- Over wr i t e : T

4 Save the ar . cf g file (Wind ows) or ar . conf file (UN IX).5 Start the Action Requ est System Server service.

For m ore inform ation abou t strategies for h and ling du plicate requ est IDs,

see H andling du plicate request IDs on page 19.

Configuring th e RPC tim eout set ting

You can configure t he RPC tim eout setting for pend ing distributed

operations to accomm odate slow network conn ections or large am oun ts of

data. If you d o no t configu re this setting, the system u ses a default timeou t.

To configure the RPC timeo ut setting


2 Enter th e RPC tim eout flag in the following format:

DSO- Ti meout - Nor mal :

where t ime represents the num ber of seconds before a timeou t occurs.

The tim eout value m ust be an integer between 60 and 21600, which

configures the tim eout for p eriods ranging from 60 seconds to 6 ho urs.

3 Save the ar . cf g file (W ind ows) or ar . conf file (UNIX). You do n ot n eed torestart t he Action Request System Server service for th e setting to take effect.

Configuring DSO for load balancing

To con figure DSO for load balancing, in ad dition to the h ardware load

balancer, you m ust have multiple server machines using a single dat abase.

You can use server groups to con figure m ultiple server mach ines to use asingle d atabase.

In ad dition to allowing multiple servers to u se a single datab ase, using server

groups p rovides increased scalability and reliability, and allows several

servers to be m anaged as a un it. If you im plement server groups, there is no

further AR System configuration necessary to imp lem ent load balancing. See

the Configuring guide.


For m ore inform ation abou t configuring D SO for load balancing, see the

BMC Remedy white paper, Using a H ardware Load Balancer with AR System


46/130


6.0 Servers, which is located on the Cu stomer Sup por t website at ht t p: / /

suppor t web. r emedy. com.

Using debu g trace m ode to create log files

The D istributed Server Op tion includes a debug trace mo de. In debu g trace

m ode, distributed operation tracing is active and the AR System creates two

log files of distributed server activity. One log file is for the general

distribu ted server activity; the o ther is for t he d istribu ted p ool server activity.

You can activate logging at any t ime; logging will start im m ediately. Each log

file is flu shed and restarted wh en you restart t he Distribu ted Server Option

or wh en you r eactivate logging after it has been d eactivated. Wh en th is

occur s, the previou s log file is written to . bak.

You shou ld be aware that t his log file con sum es increasing amo un ts of disk

space as messages accum ulate. You cann ot lim it th e size of this log file, as you

can ot her log files, in the Server In formation window. You m ight want tom on itor your disk resour ces carefully while logging is active.

You can enter a location and n ame oth er than the default location and n am e

for the log files created in debu g mod e.

See the Opt im izing and T roubleshooting guide for mo re inform ation about

using log files; see th e Configuring guide for inform ation abou t setting debug

modes.

To set up d istributed server logging

1 In BMC Rem edy Adm inistrator, o pen a server window and select a server.


The Server Inform ation window app ears

3 In t he Server Infor m ation win do w, click the Log Files tab, as shown in t hefollowing figure.


Figure 3-6: Server Information window Log Files tab
http://supportweb.remedy.com/http://supportweb.remedy.com/http://supportweb.remedy.com/http://supportweb.remedy.com/


47/130

Using debu g trace mode to create log files 47

4 Select the D istributed Server check box to enable debug trace m ode an d m ake

the File Nam e field available. You can specify a pat h an d file nam e for a

distribu ted server log file, or you can accept t he default path an d file nam e byleaving this field blank.

Important: Wh en n am ing log files, do notuse special characters (such as :

and / an d ?). Use alphan um eric characters only.

5 Click OK or Apply to activate distribu ted server logging.



48/130



49/130

Implem enting the Distributed Server Option 49

Chapter

4Im plem ent ing t he Dist r ibut edServer Opt ion

This chapter d escribes the steps you m ust follow to im plement a distributed

m apping using BMC Remedy Adm inistrator an d th en shows you h ow to

adm inister th e data tr ansfer flow between form s.

The following topics are provided :

Wor king with distribut ed fields on form s (page 50)

Wor king with distributed m appings (page 57)

Specifying distributed m apping retu rns (p age 74)

Wo rking with distributed po ols (page 78)

Using filters and escalations for DSO actions (page 82)Con trolling pend ing tran sfer inform ation (page 90)

Only users with p erm issions will be able to con figure th e Distribut ed Server

Op tion in BMC Rem edy Adm inistrator. See the Form and A pplication O bjects

guide for inform ation abo ut defining access contro l.

Important: You m ust obt ain a separate license for t he sour ce server in your

distributed en viron m ent, or the distributed m enu item s will no t appear inBMC Remedy Adm inistrator . For inform ation abou t licensing servers, see

Licensing DSO on page 31.

The target server does not need a DSO license if the target server is not

sendin g a respon se back to sour ce server.


Working w ith distributed fields on form s


50/130

50 Chapter 4 Implem enting the D istributed Server Option

This section discusses the Distribu ted Fields window, which is used to m od ify

differen t con figurat ions of reserved fields on form s. In m ost cases, the first

action you take when creating a distributed m apping is to decide whichform s you want to make d istributed that is, which on es will be

transferring som e or all of their d ata to form s on different m achines. A

nu m ber o f reserved fields can b e added to th e form s. These fields, described

in th is section, are u sed to sup por t various functions of the system .

WARNING: If you already have add ed distribu ted fields to you r form s in a

previou s version of the AR System , you m ust op en each form in BMC

Remedy Adm inistrator and re-ad d th e distribu ted fields. Th is will help

you m ake sur e that the n ew From Pool distribu ted field is also present on

you r form s.

Note: If a form used in a distributed server operation is archived, the

distribu ted fields will be cop ied to th e archive form bu t will not beup dated. You canno t add distribut ed fields to an archive form .

See Table 1-1 on page 17 for d istribu ted fields grou ped by level in th e

Distributed Fields window.

Using t he distributed fields w indowYou m ust, at a min imu m , add Basic distribu ted fields to all form s that will be

involved in t ran sfers with ownership. These distribut ed fields hold

inform ation used in request return and upd ate operations.

Use the Distribu ted Fields window, shown in Figure 4-2 on page 58, to:

Add d istribu ted fields to or delete distribu ted fields from a specified form .

You can also adjust th e levels of distribu ted fields on a form by changing

the distribut ed fields to a h igher or lower selection . For exam ple, if you

curren tly use Advanced fields on a form , you can op en th e Distributed

Fields windo w and select a lower op tion like Full or Basic.

Select th e views to which distribu ted fields are ad ded.

Con tro l whether ad ded d istributed fields will be visible to u sers.


To add and delete distributed fields

1 In BMC Rem edy Adm inistrator, o pen a server window and select a server.


51/130

Working w ith distributed fields on forms 51

A list of server objects appears.

2 Click th e Form s server object to see a list of available form s.

3 From the Form s list, doub le-click the form you want to open.

4 Choo se Form > Distribut ed Fields.

The Distribut ed Fields dialog box app ears, as sho wn in the following figure.

Figure 4-1: Distr ibuted Fields window


5 In th e Distribut ed Fields dialog box, select a Distribut ed Fields op tion . The

following t able shows available op tion s:


52/130


Distributed

Fields Opt ion

Description

N on e If you r form con tain s previou sly added distribu ted field s,

selecting Non e will delete all distribu ted fields. If your form

does not contain distributed fields and select No ne, you will not

be able to click OK to save your chan ges.

Basic Adds on ly th e distribu ted fields n ecessary for basic m app in g

funct iona lity an d establishing ownership. Values for th ese fields

are auto m atically set by the D istributed Server O ption.

Note: All the Basic fields are system- generated . Several of th e

fields are prot ected an d can only be overridden using the

ar di s t program , which is described in Appendix B,

Distributed Server Adm inistration p rogram .

The Basic fields are:

Transfer StatusSee Transfer and upd ate status on

page 55 for det ails.

Update StatusSee Transfer and update status on page 55

for det ails.

Master FlagA Yes/No flag that indicates whether this

request holds ownership.

From Request ID T he ID of the original request from wh ich

this copy was tran sferred.

From Form T he form from which this request wastransferred.

From Server The server from wh ich this request was

transferred.

From Po ol The distributed pool on the From server that

processed the distributed operation .


F ll U d f t t l h i f i h lti l

DistributedFields Opt ion

Description


53/130

Working w ith distributed fields on forms 53

Full Used for greater con trol over choice of m appin gs when mu ltiple

m appings exist from the same server and form b ased on

precedence. For m ore inform ation abou t precedence, see

Cont rolling distributed m apping selection.

Th e Full selection includ es all Basic fields, an d also th e following

fields:

To M appingIf this field is filled in , it tells DSO wh ich

m apping to use when transferring the request. If the m apping

specified in t his field does n ot exist or is disabled, th e

distributed operation will fail.From MappingTh e mapping that was used du ring a

transfer to create th is request. Only DSO can set th e value for

this field.

To Request ID Th e ID of the request to which the d ata was

tran sferred . On ly DSO can set th e value for this field.

To Form Th e form to which to tran sfer the request. The

DSO looks for a m apping based on this field an d th e To Server

field, if th ey have been set. If n o m app ing to th e specified form

exists, the distribu ted op eration will fail.

To ServerT he server to which to tr ansfer the requ est. The

DSO looks for a m apping based on th is field an d th e To Form

field, if th ey have been set. If no m app ing to t he specified

server exists, the d istribut ed op eration will fail.

Mapping H istoryA history-tracking record created at th e

time o f transfer. Includes the date an d tim e of transfer, sourceRequest ID, source form , sour ce server, and th e nam e of the

specific map pin g used. The result is a record o f all tran sfers to

this requ est. Only the DSO can set th e value for this field.

Note: This field is provided as an un lim ited-length character

field. If you set a maximu m field length for th is field, records

m ight be tru ncated.

Current Form Th e form in which the m aster copy of therequ est resides. On ly DSO can set the value for this field.

Current ServerTh e server on which the form with the

m aster cop y of the request resides. On ly DSO can set th e value

for th is field.


Ad vanced Used to o ver rid e cer ta in map pin g ch aract er ist ics o n a p er

DistributedFields Opt ion

Description


54/130


6 For form s with m ultiple views, select th e views from the Add N ew Fields to

Views pane. Distribu ted fields will be added to o r d eleted from th ese views.

If you do no t select individual views, the d istribu ted fields will be added to all

form views by default.

7 To add distributed fields as visible fields, clearthe Add as Hidd en Fields check

box. To add distribu ted fields as hidden fields, selectthe Add as H idden Fieldscheck box.

Ad vanced Used to o ver rid e cer ta in map pin g ch aract er ist ics o n a p er -

requ est basis. For exam ple, if you ent er a value in an Advanced

distribu ted field, that value will override th e characteristicsetting in the m apping used for the distributed o peration.

Th e Advanced selection in cludes all Basic and Fu ll fields, an d

also th e following fields:

When to U pdateThe frequency with which to up datethe or iginal request if a tran sferred cop y is up dated .

Transfer ModeType of transfer to perform . Valid

tran sfer types are Copy+Delete , D ata+Own ership, D ataOnly, and Independent Copy.

D uplicate Request ID ActionThe action th at will occur ifyou tr ansfer a request and th ere is already a request withthe same Request ID in the To form

Max Time to Retry

Enforce Pattern M atching

remedy dso

Documents