Configuring 700

BMC® Remedy® Action Request System® 7.
0
Configuring
May 2006
Part No: 58466
Copyright 1991–2006 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
AR System documents . . . . . . . . . . . . . . . . . . . . . . . . . 12
Learn about the AR System Developer Community . . . . . . . . . . . . 14
Why should you participate in the Developer Community? . . . . . . . . 14
How do you access the Developer Community? . . . . . . . . . . . . . 15
Chapter 1 BMC Remedy Action Request System 7.0 architecture . . . . . . . 17

AR System architecture overview . . . . . . . . . . . . . . . . . . . . 18
BMC Remedy mid tier . . . . . . . . . . . . . . . . . . . . . . . . 20
AR System server . . . . . . . . . . . . . . . . . . . . . . . . . . 21
AR System and web services . . . . . . . . . . . . . . . . . . . . . . 25
Creating and publishing a web service . . . . . . . . . . . . . . . . . 25
Consuming a web service . . . . . . . . . . . . . . . . . . . . . . 26
Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Mid tier scalability . . . . . . . . . . . . . . . . . . . . . . . . . 26
AR System server scalability . . . . . . . . . . . . . . . . . . . . . 27
Working with a portmapper service in AR System . . . . . . . . . . . . . 35
Windows and portmapper services . . . . . . . . . . . . . . . . . . 36
Configuring clients through environmental variables . . . . . . . . . . . 36
Contents 3
BMC Remedy Action Request System 7.0
Chapter 2 Obtaining and activating licenses . . . . . . . . . . . . . . . . . 37

Licensing overview . . . . . . . . . . . . . . . . . . . . . . . . . . 38
License keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Contacting Customer Support . . . . . . . . . . . . . . . . . . . . 39
Licensing a new AR System server . . . . . . . . . . . . . . . . . . . . 40
Manually applying license keys . . . . . . . . . . . . . . . . . . . . . 41
Transferring server licenses to other servers . . . . . . . . . . . . . . . 42
Exporting licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Importing licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Chapter 3 Setting user preferences . . . . . . . . . . . . . . . . . . . . . 47

User preferences and customizations. . . . . . . . . . . . . . . . . . . 48
Local preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Centralized preferences . . . . . . . . . . . . . . . . . . . . . . . . 49
Creating a preference server . . . . . . . . . . . . . . . . . . . . . 50
Configuring clients to use a preference server . . . . . . . . . . . . . . 51
Setting centralized preferences on Windows clients. . . . . . . . . . . . 55
AR System User Preference form fields . . . . . . . . . . . . . . . . . . 55
Common fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
General tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Display tab (BMC Remedy User only) . . . . . . . . . . . . . . . . . 66
Color tab (BMC Remedy User only) . . . . . . . . . . . . . . . . . . 67
Confirmation tab . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Report tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Logging tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Locale tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
File tab (BMC Remedy User only) . . . . . . . . . . . . . . . . . . . 76
Advanced tab . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Home Page tab . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Alert tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Recent tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Edit tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Window tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Misc tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Web tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Setting centralized preferences on web clients . . . . . . . . . . . . . . . 102
4 Contents
Configuring
Chapter 4 Defining your user base . . . . . . . . . . . . . . . . . . . . . 103

Licensing users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
License types . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Viewing user information . . . . . . . . . . . . . . . . . . . . . . . 105
Releasing floating licenses . . . . . . . . . . . . . . . . . . . . . . . 107
License pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Adding and modifying user information . . . . . . . . . . . . . . . . . 108
Allowing guest users . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Special submitter mode . . . . . . . . . . . . . . . . . . . . . . . . 115
Validating password information . . . . . . . . . . . . . . . . . . . . 116
Setting up an authentication alias . . . . . . . . . . . . . . . . . . . . 116
User Name Alias . . . . . . . . . . . . . . . . . . . . . . . . . 116
Authentication String Alias . . . . . . . . . . . . . . . . . . . . . 120
Unique user logins. . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Chapter 5 Configuring servers and clients . . . . . . . . . . . . . . . . . 123

Configuring AR System servers . . . . . . . . . . . . . . . . . . . . . 124
Server information—Platform tab . . . . . . . . . . . . . . . . . . 126
Server information—Timeout tab . . . . . . . . . . . . . . . . . . 128
Server information—Licenses tab . . . . . . . . . . . . . . . . . . 130
Server information—Configuration tab . . . . . . . . . . . . . . . 132
Server information—Log Files tab . . . . . . . . . . . . . . . . . . 141
Server information—Database tab. . . . . . . . . . . . . . . . . . 146
Server information—Server Ports and Queues tab . . . . . . . . . . . 149
Server information—Connection Settings tab . . . . . . . . . . . . . 154
Server information—Currency Types tab . . . . . . . . . . . . . . . 159
Server Information—External Authentication tab . . . . . . . . . . . 162
Server information—Advanced tab . . . . . . . . . . . . . . . . . 167
Server information—Source Control tab . . . . . . . . . . . . . . . 171
Server information—Server Events tab . . . . . . . . . . . . . . . . 176
Configuring a server for development or production cache mode . . . . . . 178
Configuring multiple servers . . . . . . . . . . . . . . . . . . . . . . 179
Configuring multiple servers on one machine . . . . . . . . . . . . . 179
Configuring multiple servers to access the same database . . . . . . . . 181
Running servers as part of a group. . . . . . . . . . . . . . . . . . 185
Contents 5
Running a stand-alone AR System server on Windows . . . . . . . . . . . 194

Configuring firewalls with AR System servers . . . . . . . . . . . . . . . 195
Configuring clients for AR System servers . . . . . . . . . . . . . . . . 196
Configuring a server to use plug-ins . . . . . . . . . . . . . . . . . . . 197
Configuring the AR System server for external authentication (AREA). . . . 199
Configuring a mail server. . . . . . . . . . . . . . . . . . . . . . . . 202
Configuring a server for alerts. . . . . . . . . . . . . . . . . . . . . . 202
Configuring and using the AR System Server Administration plug-in . . . . 204
Configuring AR System to use the Server Administration application . . . 204
Administering your server from AR System clients . . . . . . . . . . . 204
Chapter 6 Working with the alert system . . . . . . . . . . . . . . . . . 211

Alert system architecture . . . . . . . . . . . . . . . . . . . . . . . . 212
Alert Events form . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Viewing alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
CleanupAlertEvents escalation . . . . . . . . . . . . . . . . . . . . . 214
Managing registered users . . . . . . . . . . . . . . . . . . . . . . . 215
Working with versions of the AR System prior to 5.x. . . . . . . . . . . . 215
Upgrading the server but not the clients . . . . . . . . . . . . . . . 215
Upgrading or installing clients but not the server . . . . . . . . . . . 215
Enabling alerts on the Web . . . . . . . . . . . . . . . . . . . . . . . 216
Chapter 7 Importing data into AR System forms . . . . . . . . . . . . . . 219

Understanding the import process. . . . . . . . . . . . . . . . . . . . 220
Understanding data mapping . . . . . . . . . . . . . . . . . . . . 220
Understanding preferences . . . . . . . . . . . . . . . . . . . . . 221
Preparing to import . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Defining BMC Remedy Import preferences . . . . . . . . . . . . . . . . 225
Importing data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Using a saved mapping file . . . . . . . . . . . . . . . . . . . . . . . 243
Using the import log file . . . . . . . . . . . . . . . . . . . . . . . . 244
AR XML data . . . . . . . . . . . . . . . . . . . . . . . . . . 245
All other data types . . . . . . . . . . . . . . . . . . . . . . . . 245
6 Contents
Configuring
Chapter 8 Using full text search . . . . . . . . . . . . . . . . . . . . . . 247

Overview of full text search . . . . . . . . . . . . . . . . . . . . . . . 248
Accruing and weighting results with FTS . . . . . . . . . . . . . . . 249
Sorting requests by weight . . . . . . . . . . . . . . . . . . . . . 249
Using the Ignore Words List . . . . . . . . . . . . . . . . . . . . 249
Who can perform a full text search? . . . . . . . . . . . . . . . . . . . 250
Using FTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Performing a search in a field indexed for FTS. . . . . . . . . . . . . 251
Searching for word stems . . . . . . . . . . . . . . . . . . . . . 259
Using wildcards . . . . . . . . . . . . . . . . . . . . . . . . . 259
Using the QBE method . . . . . . . . . . . . . . . . . . . . . . 260
Using the advanced search bar method . . . . . . . . . . . . . . . . 261
Adding a form search field to a form . . . . . . . . . . . . . . . . . 261
Parametric full text search . . . . . . . . . . . . . . . . . . . . . 262
Search strategies . . . . . . . . . . . . . . . . . . . . . . . . . 263
Search issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Limitations of FTS. . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Administering FTS . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Selecting fields for FTS indexing. . . . . . . . . . . . . . . . . . . 265
Full text search indexing . . . . . . . . . . . . . . . . . . . . . . 266
Indexing for attachments. . . . . . . . . . . . . . . . . . . . . . 266
Multiple languages and attachment file formats . . . . . . . . . . . . 267
Reindexing . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
FTS configuration options . . . . . . . . . . . . . . . . . . . . . 269
Debugging FTS . . . . . . . . . . . . . . . . . . . . . . . . . . 271
FTS logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Upgrading FTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Assigning FTS licenses to users . . . . . . . . . . . . . . . . . . . . . 276
Defining a field for FTS in the Field Properties window . . . . . . . . . . 277
Estimating the size of the FTS index . . . . . . . . . . . . . . . . . 278
Displaying FTS weight in a results list . . . . . . . . . . . . . . . . 279
Contents 7
Appendix A Working with the Request ID field . . . . . . . . . . . . . . . . 281

Working with the Request ID field . . . . . . . . . . . . . . . . . . . 282
Changing the next available ID for new requests . . . . . . . . . . . . 283
Changing the Request ID field length or prefix . . . . . . . . . . . . 285
Preserving existing Request ID field values . . . . . . . . . . . . . . 286
Changing existing Request ID field values to a new format . . . . . . . 286
Updating the Request ID field in other AR System tables . . . . . . . . 296
Appendix B AR System configuration files . . . . . . . . . . . . . . . . . . 299

ar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
ar.conf (ar.cfg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
ardb.conf (ardb.cfg) . . . . . . . . . . . . . . . . . . . . . . . . . . 341
armonitor.conf (armonitor.cfg) . . . . . . . . . . . . . . . . . . . . . 343
Appendix C AR System server components and external utilities . . . . . . . 345

AR System server components . . . . . . . . . . . . . . . . . . . . . 346
arforkd (UNIX only) . . . . . . . . . . . . . . . . . . . . . . . 346
armonitor (armonitor.exe) . . . . . . . . . . . . . . . . . . . . . 346
arplugin (arplugin.exe) . . . . . . . . . . . . . . . . . . . . . . 347
arserverd (arserver.exe) . . . . . . . . . . . . . . . . . . . . . . 348
External utilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
arcache (arcache.exe) . . . . . . . . . . . . . . . . . . . . . . . 350
arreload (arreload.exe). . . . . . . . . . . . . . . . . . . . . . . 354
arsignal (arsignal.exe) . . . . . . . . . . . . . . . . . . . . . . . 356
Appendix D Date and time formats . . . . . . . . . . . . . . . . . . . . . 359

Short date formats . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Long date formats . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Day formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Time formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Additional characters . . . . . . . . . . . . . . . . . . . . . . . . . 363
8 Contents
Configuring
Appendix E Working with the Server Events form . . . . . . . . . . . . . . 365

Understanding the Server Events form . . . . . . . . . . . . . . . . . . 366
How the Server Events form is created . . . . . . . . . . . . . . . . 366
Types of events you can record . . . . . . . . . . . . . . . . . . . 368
Viewing the server changes you recorded . . . . . . . . . . . . . . . 370
Using server events in workflow . . . . . . . . . . . . . . . . . . . . . 384
Appendix F Using Business Time in the AR System server . . . . . . . . . . 385

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
How Business Time 2.0 works. . . . . . . . . . . . . . . . . . . . . . 388
Scheduling a time segment . . . . . . . . . . . . . . . . . . . . . . . 390
Understanding levels . . . . . . . . . . . . . . . . . . . . . . . 390
Creating non-conflicting segments . . . . . . . . . . . . . . . . . 390
Defining a business time segment . . . . . . . . . . . . . . . . . . 390
Understanding time segment entity associations . . . . . . . . . . . . 396
Understanding time segment shared entities . . . . . . . . . . . . . 397
Using offset hours in Business Time 2.0 . . . . . . . . . . . . . . . . . 399
Business Time commands . . . . . . . . . . . . . . . . . . . . . . . 399
Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Application commands . . . . . . . . . . . . . . . . . . . . . . . 402
Business Segment-Entity Association commands . . . . . . . . . . . . 407
Application-Get-Next-Recurrence-Time . . . . . . . . . . . . . . . . 408
Using the old Business Time forms . . . . . . . . . . . . . . . . . . . 409
Scheduling workdays . . . . . . . . . . . . . . . . . . . . . . . 409
Scheduling holidays . . . . . . . . . . . . . . . . . . . . . . . . 412
Defining business hours using offset hours . . . . . . . . . . . . . . 416
Old Business Time commands . . . . . . . . . . . . . . . . . . . . 417
Migrating Workdays and Holidays to the Business Time Segment form . . . 419
Debugging tips for Business Time . . . . . . . . . . . . . . . . . . . . 420
Appendix G Using the Assignment Engine . . . . . . . . . . . . . . . . . . 423

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Assignment Engine Process . . . . . . . . . . . . . . . . . . . . . . . 425
Assignment Engine Administration Console . . . . . . . . . . . . . . . 425
Contents 9
Auto-assignment methods . . . . . . . . . . . . . . . . . . . . . . . 427

Preparing for the auto-assignment process . . . . . . . . . . . . . . . . 428
Fields to add to the assignee form . . . . . . . . . . . . . . . . . . 428
Fields to add to the request form . . . . . . . . . . . . . . . . . . 429
Adding assignment forms . . . . . . . . . . . . . . . . . . . . . . . 430
Adding assignment processes . . . . . . . . . . . . . . . . . . . . . . 434
Adding assignment rules . . . . . . . . . . . . . . . . . . . . . . . . 436
Setting sequencing for rules . . . . . . . . . . . . . . . . . . . . 438
Turning on log and trace files . . . . . . . . . . . . . . . . . . . . . . 439
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
10 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 is written for administrators who are responsible for setting up
and maintaining the BMC® Remedy® Action Request System®
(AR System®). The guide is intended to aid new and current administrators
of AR System. If you are a current AR System administrator, this guide
enhances the ease of use and performance of your AR System environment.
If you are a new AR System administrator, this guide helps you create an
effective and efficient AR System environment.
Preface 11
Before you explore the topics in this guide, make sure that you understand
the terms and concepts discussed in the Optimizing and Troubleshooting
guide, which contains all the required information for setting up and
administering a basic AR System environment. Your knowledge of basic
administrative AR System tasks is crucial for successful implementation of
the strategies discussed in this guide.
You must know how to use AR System, including BMC Remedy
Administrator, BMC Remedy User, and BMC Remedy Import. See the
Installing guide, the Form and Application Objects guide, and the Workflow
Objects guide for additional information.
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 product’s Help menu or by
clicking on Help links.
Title Description Audience

Concepts 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.
Installing Procedures for installing AR System. Administrators
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.
Form and Application Objects Describes components necessary to build applications in Developers
AR System, including applications, fields, forms, and
views.
Workflow Objects Contains all of the workflow information. Developers
Configuring Contains information about configuring AR System Administrators
servers and clients, localizing, importing and exporting
data, and archiving data.
12 Preface
Configuring

Installing and Administering Contains information about the mid tier, including mid Administrators
BMC Remedy Mid Tier tier installation and configuration, and web server
configuration.
Integrating with Plug-ins and Discusses integrating AR System with external systems Administrators
Third-Party Products using plug-ins and other products, including LDAP, /Developers
OLE, and ARDBC.
Optimizing and Server administration topics and technical essays related Administrators
Troubleshooting to monitoring and maintaining AR System for the
purpose of optimizing performance and troubleshooting
problems.
Database Reference Database administration topics and rules related to how Administrators
AR System interacts with specific databases; includes an
overview of the data dictionary tables.
Administering BMC Remedy Server administration and procedures for implementing Administrators
DSO a distributed AR System server environment with the
BMC Remedy Distributed Server Option (DSO).
Administering BMC Remedy Flashboards administration and procedures for creating Administrators
Flashboards and modifying flashboards and flashboards components /Programmers
to display and monitor AR System information.
C API Reference Information about AR System data structures, C API Administrators
function calls, and OLE support. /Programmers
C API Quick Reference Quick reference to C API function calls. Administrators
/Programmers
Java API * Information about Java classes, methods, and variables Administrators
that integrate with AR System. /Programmers
Administering BMC Remedy Procedures for installing, configuring, and using the Administrators
Email Engine BMC Remedy Email Engine.
Error Messages List and expanded descriptions of AR System error Administrators
messages. /Programmers
Master Index Combined index of all books. Everyone
Release Notes Information about new features list, compatibility lists, Everyone
international issues, and open and fixed issues.
BMC Remedy User Help Procedures for using BMC Remedy User. Everyone
BMC Remedy Import Help Procedures for using BMC Remedy Import. Administrators
AR System documents 13

BMC Remedy Administrator Procedures for creating and modifying an AR System Administrators
Help application for tracking data and processes.
BMC Remedy Alert Help Procedures for using BMC Remedy Alert. Everyone
BMC Remedy Mid Tier Procedures for configuring the BMC Remedy Mid Tier. Administrators
Configuration Tool Help
*.
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.
14 Preface
Configuring
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.
It’s free!
How do you access the Developer Community?

Go to supportweb.remedy.com, and click the Developer Community link.
Learn about the AR System Developer Community 15

16 Preface
Chapter
1 BMC Remedy Action Request

System 7.0 architecture
This section discusses the overall architecture of AR System 7.0 and provides
a conceptual overview of the components of the AR System.
The following topics are provided:
AR System architecture overview (page 18)
AR System and web services (page 25)
Scalability (page 26)
Working with a portmapper service in AR System (page 35)
BMC Remedy Action Request System 7.0 architecture 17

AR System architecture overview

AR System is based on a client/server architecture and includes three
functional environments:
Presentation—The presentation piece of AR System is responsible for
presenting services and displaying data to clients through various
interfaces. These interfaces include:
browsers
cell phones
PCs
Personal Data Assistants (PDAs)
BMC Remedy User
BMC Remedy Administrator
API programs
All these interfaces enable you to access AR System. Clients can be thought of
as consumers of services that the AR System server provides.
Business processing—This portion of the architecture includes:
The mid tier
The AR System server
Servers such as the Distributed Server Option (DSO), and Approval
Server
The Enterprise Integration Engine (EIE)
Web services
The business processing piece of AR System is responsible for providing
services to clients and processing the data entered through clients.
Applications that reside within the business processing environment act as
liaisons for the clients and the database, enforcing the rules of your
business processes.
18 Chapter 1—BMC Remedy Action Request System 7.0 architecture

Configuring
Data storage—The data storage element contains the actual data for the
system. AR System supports DB2, Informix, Oracle, Sybase, and
Microsoft SQL databases. For each of the relational databases, tables
owned by other systems can also be referenced as if they were owned by
AR System. Also, ARDBC plug-ins can be created and configured to allow
access to data stored outside the database as if it were located within tables
that are owned by AR System.
Figure 1-1 depicts the relationship among the components that reside within
each of the functional environments of the AR System architecture. Notice
that no definitive starting and ending point separates the three
environments, because their functions sometimes overlap.
Figure 1-1: AR System architecture
Wireless
Browser Clients
Clients
Windows Palm OS
Clients Client
Presentation
Internet
Services
1. Reporting Mid-Tier
2. Flashboards
3. ...
Sync
Support
Programs Business
Processing
Services
1. Approval
2. DSO
3. Application
AR System Server
Servers
4. ...
ARDBC Data
Plug-in
Storage
AR System Other
Non-AR System Non-Database
Database Database Data Sources
AR System architecture overview 19

Within these three functional environments, several system components

work together to provide power, flexibility, and scalability. The rest of this
section focuses on two of those components, the mid tier and the AR System
server, and the interaction between them.
For more information about the AR System architecture, see the Concepts
guide.
BMC Remedy mid tier

The mid tier serves as a client of the AR System server and as a server to the
browser. The mid tier enables you to view AR System applications on the web
and access the AR System server from a web server. It also provides
instructions to the browser in the form of document markup and
downloadable scripts. These instructions describe how to present application
data and how to interact with the user.
The mid tier leverages a Java servlet engine and includes a collection of
servlets that are plugged in to the web server to serve forms, images, and
other resources. The servlet engine facilitates communication between the
browser and the web server. It provides components and add-in services that
run on the web server.
The web server manages the transfer of all HTML content to the browser.
Infrastructure components, such as servlets and other services (special Java
classes), translate client requests and interpret responses from the AR System
server.
Unlike BMC Remedy User, a browser is a generic client that has no inherent
knowledge of any application that might run within it. By acting as an
interpreter, the mid tier allows a browser to become a fully functional
AR System client.
The main components of the mid tier infrastructure are:
Web server—A server that receives requests for a web page and maps the
uniform resource locator (URL) to a local file or servlet on the host server.
The server then loads the content and serves it across the network to the
user’s browser.
JSP engine—An engine that handles the .jsp files and the basic request
and response interface in the browser environment.
JSP servlets—A small piece of Java code, often translated from a .jsp file,
that runs on a web server.

Configuring
JAVA API—An API that is used to communicate with the AR System

server. The object model provides a set of classes representing the data
structures and functions of the API. The Server Proxy class encapsulates
all communication with AR System servers and provides connection
pooling for performance and scalability.
BMC Remedy Mid Tier Configuration Tool—A tool that enables you to
set properties for the mid tier. It is accessible through a .jsp file in a
browser using a separate login. The properties submitted from the
Mid Tier Configuration Tool are stored in memory for quick retrieval and
are written to a file called config.properties for persistence between web
server restarts.
Properties that can be set using the Mid Tier Configuration Tool include
the list of AR System servers to access, the session time-out interval,
directory locations, Reporting Tool options, logging, Flashboards, log
setting, Home Page server settings, and user authentication for web
services.
For more information about mid tier settings, see the Installing and
Administering BMC Remedy Mid Tier guide.
AR System server
The AR System server processes all the data entered by a client. As the
workflow engine between the client and the database server, the AR System
server writes data into the database when an AR System request is created,
and retrieves that data when a client requests it. The server verifies that a user
has permission to perform each transaction that is requested, thereby
enforcing any access control that you have defined as part of an application.
The server also evaluates the data in the database with each transaction to
determine whether workflow is triggered.
The AR System server has no direct user interface. Clients, such as the
mid tier, BMC Remedy User, and other applications, communicate with
AR System by means of a well-defined application program interface (API).
Both a C interface and a Java interface are available. The API uses remote
procedure calls (RPCs) to communicate with the server.
When a client submits a request to the server, the request enters through the
API, goes through access control and data validation, filter processing, and
then transactions are committed to the data repository as appropriate.

The main components of the AR System server architecture are:

Application program interface (API)—A set of functions and data
structures that provide application programmers with access to the full
functionality of a product. Developers can create clients written in C or
Java. The AR System API is documented in the C API Reference guide and
the Action Request System Java API HTML pages.
Access control and data validation—A security feature in which
AR System administrators limit the access users have to forms, to specific
fields within a form, to specific functions within the system, and to data
stored within the system.
Alerts—A client program that functions as a “desktop pager.” This
component within the AR System server supports desktop pages such as
flashing icons, audible beeps, sound files, and message windows. For
example, it can display a message alerting help desk personnel that a new
problem has been assigned to them.
For more information about alerts, see Chapter 6, “Working with the alert
system,” and BMC Remedy Alert help.
Filters—Actions performed on the AR System server, which is the portion
of the software that controls the flow of requests to an underlying
database. As a request is processed by the server, the filter actions take
place. Filters allow you to implement constraints, make decisions, and
take action when operations are performed on data stored in AR System.
Escalations—Actions performed on the server at specified times or time
intervals. They are automated, time-based processes that search for
requests that match certain criteria and take action based on the results of
the search.
AR System Filter (ARF) Plug-In API—A filter that offers a programming
interface that is directly invoked by filter workflow. This provides a
flexible and efficient mechanism for communicating with various
applications or web services. Use of plug-ins reduces system overhead.
ARF plug-ins also apply to escalations.
For more information about plug-ins, see the C API Reference guide.

Configuring
AR System External Authentication (AREA)—A process that accesses

network directory services and other authentication services to verify user
login name and password information. When you use the AREA plug-in,
you do not need to maintain duplicate user authentication data in the
AR System directories because the AR System server can access user
identification information and user passwords at many locations.
For more information about plug-ins, see the Integrating with Plug-ins and
Third-Party Products guide and the C API Reference guide.
View form—A form that allows AR System to point to and access data in
an existing database table created outside AR System. The table can be
located in the same database or in any other database accessible from the
current AR System database.
For information about creating and using view forms, see the Form and
Application Objects guide.
Vendor form—A form that allows AR System to access arbitrary external
data sources through the use of an ARDBC (AR System Database
Connectivity) plug-in. This type of form provides for easy integration with
external data without replicating the data.
For information about creating and using external forms, see the Form
and Application Objects guide.
Database servers—The AR System uses standard relational databases for
storing and retrieving data. Architecturally, the database server is a set of
processes that are completely separate from the AR System server
processes. Physically, the database server processes can be running on the
same computer as the AR System server or on a different computer. The
database server can be run on any platform that the particular database
supports.
Figure 1-2 depicts the infrastructure of the AR System server.

Figure 1-2: AR System server infrastructure
User
API
Access Control and

External AREA Data Validation Alerts
Processes
Plug-In
Escalations
Filters
External
Processes
Filter API
Web Plug-In
Services
Sybase MSSQL Oracle Informix DB2 View Vendor
Plug-In

Configuring
AR System and web services

Web services allow AR System functionality to be available over the web
(publishing), and enable AR System applications to access third-party
applications. For both publishing and consuming web services, you establish
a base form to which the information is set, or through which the
information is pushed to other forms or applications. You must map the
AR System fields on a base form to input or output parameters of a web
services operation. A field can participate as either an input parameter, an
output parameter, or both. You can map AR System fields to a simple flat
document or to a complex hierarchical document involving parent and child
relationships.
Creating and publishing a web service

A web service is created and modified in BMC Remedy Administrator using
the web services graphical user interface. Publishing web services makes
AR System operations available over the Internet or an intranet.
Web services that are published in AR System can be simple, such as creating
a record in the AR System database, or more complex, such as processing a
purchase order that spans across multiple AR System forms.
Each web service consists of the following resources:
A base form on which it operates. You specify this form when you create
the web service. For web services that span across multiple AR System
forms, the base form is the master form.
A list of Create, Get, or Set operations. When you create a web service, by
default, it has four named operations: OpCreate, OpGet, OpList, and
OpSet. You can have more than one operation of the same type, or you can
have no operations of a particular type.
A mapping that specifies how individual elements of incoming and
outgoing XML documents are mapped to fields and forms of the
AR System. These are essentially the input and output parameters of the
web service.
An association with XML Schema (.xsd file). Global elements and complex
types referred to in the schema can be used in mappings associated with
operations.
AR System and web services 25

Consuming a web service

You can use an external web service by creating a Web Service Set Fields filter
action to enter data from the web service into a base form. You can then view
the form in an AR System client.
For more information about creating and publishing web services, see the
Integrating with Plug-ins and Third-Party Products guide.
Scalability
Scalability is a feature in both the mid tier and the AR System server.
Mid tier scalability

The strategy for processing and serving browser-client requests is based on
several components. These components work together to take input from the
client and compute a response that the user sees in the browser as Dynamic
HTML (DHTML). These mid tier components do not run in a separate
proprietary process, but in the JSP engine using standard web protocols.
The use of JSP servlets makes the mid tier scalable in the following ways:
Multiple threads connecting to a servlet can handle many concurrent
users.
Common web-server mechanisms and practices can be used for scaling
and load balancing.
The JSP engine, which is a plug-in of the web server, runs in the same
process as the web server, so network calls are not needed for the two to
communicate.
Use of mid tier and user caches of AR System definitions require fewer
trips to the AR System server to retrieve them. In addition, use of browser
caching has led to data size reductions, which in turn reduces bandwidth
requirements.
Additionally, the architecture supports server clusters, or web farms that are
hardware setups in which several physical web servers share the load directed
to one logical server (one IP address). In a web farm, a load balancer receives
requests and sends them to whichever physical server has the most resources
available to handle them.

Configuring
AR System server scalability

The AR System multithreaded server is scalable from a single thread
performing all server functions to multiple threads, each performing specific
functions. The threads adapt to the configuration parameters defined, and
they distribute the load. You determine what amount of operating system
resources to dedicate to AR System.
The multithreaded architecture uses two concepts—queues and threads—as
shown in Figure 1-3. The following sections describe how these queues and
threads function in the AR System server.
Scalability 27
Figure 1-3: Multithreaded server architecture
Browser AR System AR System Client

Client Administrator Client API Programmer
Mid-Tier
Dispatcher
Flash-
Escalation Admin Fast List Private Alert
boards
Queue Queue Queue Queue Queues Queue
Queue
390603 390619 390600 390620 390635 390601
390621-390634
390636-390669
390680-390694
Worker Worker Worker Worker Worker Worker Worker
Thread Threads Thread Threads Threads Threads Threads
Note: The number of

worker threads for fast,
list, and private queues
can be increased to
the maximum number
of connections your
database and hardware
can support.
Database

Configuring
Queues
A queue is a meeting point where remote procedure calls (RPCs) wait to be
handled by the worker threads that process the RPCs. When a queue is
created, it automatically starts the minimum number of threads specified for
its thread type. The default for this setting is 1. For more information, see
“Threads” on page 32.
There are seven types of AR System queues. Each queue has an RPC program
number associated with it, as outlined in the following table.
Queue type RPC program number

Admin 390600
Alert 390601
Escalation 390603
Flashboards 390619
Fast 390620
List 390635
Private 390621–390634, 390636–390669, 390680–
390694
Note: Administration, alert, escalation, Flashboards, fast, and list queues use
a fixed RPC program number. Private queues, however, can be configured
to use any RPC program number within the ranges of RPC program
numbers reserved for private queues.
The following sections describe the different types of queues.

References to the configuration file apply to the configuration file specific to
your system. The configuration file for Windows is ar.cfg. For UNIX, this file
is ar.conf.
Administration queue
The administration (admin) queue is the only AR System queue that can
perform every operation within the system. It performs all administrative
restructuring operations, guaranteeing the serialization and integrity of all
restructuring operations. This queue can have only one thread.
Scalability 29
All servers include an admin queue, which is the default server setting.
Because an admin queue has a single thread available to handle requests, a
server that has only an admin queue (and no fast or list queues) functions as
a single-threaded server. While the admin queue handles all administrative
functions, it can also perform the functions of all other queues if no other
queues are configured. If no other queues are configured, all requests are
placed in the admin queue.
Alert queue
The alert queue handles all alerts that are sent to registered clients. The alert
queue handles only internal requests, not requests from outside the
AR System server. The threads in this queue do not open database
connections, so they do not use many resources.
The minimum thread count for the alert queue is 1. If the server is supporting
Remedy Notifier 4.x clients, set a maximum of 5 alert threads because those
client versions cannot handle more than 5 simultaneous connection
requests. If the server is supporting Remedy Notifier 3.x or earlier clients, set
a maximum of 1 alert thread because those client versions do not correctly
handle simultaneous connection requests.
To configure an alert queue, see “Defining queues and configuring threads”
on page 153.
Escalation queue
All servers automatically create an escalation queue unless Disable
Escalations is configured. (For more information, see “Configuring multiple
servers to access the same database” on page 181.) The escalation queue
handles only internal requests, not requests from outside the AR System
server. It handles escalations specified by the administrator and performs all
escalation processing. Like the admin queue, the escalation queue has only
one thread.
Flashboards queue
The Flashboards queue is a private queue that is automatically created if your
system has a Flashboards license. The queue supports all functionality of the
Flashboards product to make sure that there is dedicated access without
overwhelming the other queues in your system.

Configuring
Fast queue
The fast queue handles the operations that generally run to completion
quickly without blocking access to the database. The fast queue handles all
server operations, except for:
Administrative operations that restructure the database. These operations
use the administration queue.
The ARExport, ARGetListEntry, ARGetListEntryWithFields, and
ARGetEntryStatistics, and other API calls (which use the list queue).
See the C API Reference guide for more information about API calls.
One or more threads can serve the fast queue if a fast queue is configured. To
configure a fast queue, see “Defining queues and configuring threads” on
page 153.
List queue
The list queue handles AR System operations that might require significant
time, block access to the database, or both. Examples of these operations
include ARExport, ARGetListEntry, ARGetListEntryWithFields, and
ARGetEntryStatistics.
One or more threads can serve the list queue if a list queue is configured. To
configure a list queue, see “Defining queues and configuring threads” on
page 153.
Private queues
Administrators can also create private queues for specific users who need
dedicated access. For example, you might create a private queue for a user
who is performing critical operations that you do not want blocked by other
users. Private queues guarantee a certain bandwidth dedicated to clients
using these queues.
Private queues support all operations except restructuring operations.
Restructuring operations are supported only by the administration queue
(see “Administration queue” on page 29). To configure a private queue, see
“Defining queues and configuring threads” on page 153.
Each private queue can be supported by one or more threads. To connect a
user to a private queue, see “Configuring clients for AR System servers” on
page 196.
Scalability 31
Threads
The term thread is short for “thread of execution.” Threads allow the server
to process concurrent client requests. Each thread within the multithreaded
server can carry out a client request before returning to the queue to process
the next one. Start only as many threads as your database and system
resources can reasonably support. The total number of threads cannot
exceed the number of database connections that are available to the
AR System server.
All threads within a process share network and system resources; therefore,
consider carefully the available resources of your network when establishing
the minimum and maximum thread settings for your server queues.
There are three types of AR System threads:
Dispatcher
Worker
Thread manager
The following sections describe the different types of threads.
Dispatcher thread
The dispatcher thread routes requests to the appropriate queues. This thread
receives connection requests from clients. The dispatcher thread then places
the requests into the appropriate queue where each request can be handled
by one of multiple worker threads.
Every call that the dispatcher thread receives is assigned an RPC ID that can
be used to identify the call from the time the call is placed into a queue until
a response is sent to the client.
In general, the dispatcher thread uses the following logic to dispatch calls:
If no other queues are defined, the dispatcher thread routes all requests to
the admin queue. If, however, fast and list queues are created in addition
to the admin queue, the dispatcher routes client requests according to the
type of operation being performed. If private queues are created, the
dispatcher directs the call to the appropriate private queue based on the
RPC program number of the request.
A request is routed to the appropriate queue based on its RPC program
number. For example, a call that has RPC program number 390600 is
routed to the admin queue.

Configuring
If a call with RPC program number 390620 (fast) or 390635 (list) is

received and there is no fast or list queue, the dispatcher thread routes the
call to the admin queue. If there is only a list queue, the dispatcher thread
places the call in that queue. If there is only a fast queue, the dispatcher
thread directs the call to that queue. If there are both fast and list queues,
the dispatcher routes the call to the appropriate queue based on the call
number.
If a call is received with RPC program number 390601 (previously
supported by the Notification server, which has now been merged with the
AR System server), the dispatcher routes the call to the fast queue.
If a call is received with an RPC program number other than those
specified for admin, fast, list, and Flashboards queues, the dispatcher
identifies the call as destined for a private queue. If a private queue
supporting the RPC program number exists, the dispatcher thread routes
the call to that queue. If no private queue exists but there is a fast or list
queue, the call is routed to the appropriate queue based on its RPC
program number. If there is no fast or list queue, the call is routed to the
admin queue.
The escalation and alert queues do not receive calls from the dispatcher.
Worker threads
Worker threads respond to the RPCs that have been dispatched to individual
queues. Each queue creates one or more worker threads. The worker threads
within a queue are identical and can handle any request. Only the worker
thread started by the admin queue, however, can handle calls that modify
definitions or server configuration settings.
Upon startup, each thread creates a connection to the database that it uses
throughout its existence. If the thread is unable to establish a connection, it
terminates itself, notifying the queue that no more threads are to be started.
The database connection is dedicated to the thread, even when that particular
thread is not busy.
Any available worker thread can remove the request from the queue, read the
request, process it, and return results to the client before returning to the
queue to respond to another request. When a request is placed in a queue and
no existing threads are available to handle it, a new thread is started until the
queue reaches the maximum number of threads allowed for its thread type.
Scalability 33
Thread manager
The thread manager is responsible for ensuring that a thread is restarted if it
dies.
Determining how many threads you need

A major benefit of a multithreaded server is not having “fast” operations held
up behind a slow “list” operation. Deciding how many fast and list threads
you need depends on your particular setup and situation. For example, not
specifying enough list threads might mean you have idle fast threads but an
overloaded list queue.
Another consideration is that list threads require more memory than fast
threads. For example, a complicated query might require a great deal of
memory at a given moment. A few of these large queries can temporarily
exhaust your system resources.
To determine how many threads of each type you need, start by examining
the types of API calls in your API log file. If your system processes many fast
operations, you might decide to increase the number of fast threads. A
different rule of thumb is to specify a larger maximum of list threads than fast
threads, simply because fast operations are generally performed more quickly
than list operations.
Do not specify an artificially high number of maximum threads because the
threads would essentially get in one another’s way by consuming resources
that other threads need. To set the number of minimum and maximum
threads, see “Server information—Server Ports and Queues tab” on
page 149.

Configuring
Working with a portmapper service in AR System

A portmapper functions as a “directory” of services and the ports on which
those services are running. Processes can opt to register or not register their
location with a portmapper. A common reason for not registering with a
portmapper is security.
If an AR System server is registered with a portmapper, your clients do not
need to know what port the server is listening on because the clients can
identify the port using the portmapper and direct API calls to the appropriate
TCP port. If a server is not registered with a portmapper, you need to assign
a TCP port number to that server. Otherwise, the system must search for an
open port to communicate on each time the server is restarted. Your clients
will not know where to find your AR System server because the port might
be different if the AR System server is restarted.
Registering with a portmapper and assigning TCP port numbers are not
mutually exclusive options. You can do both. If you specify a particular port
for a server and register the server with a portmapper, clients within the
firewall do not need to be configured to access the specified port number.
If the AR System server is not registered with a portmapper:
Client processes must be able to identify the port to communicate on to
contact the server. For more information about configuring ports for the
client, see “To configure Windows clients to avoid using a portmapper”
on page 196.
Macros that a UNIX User tool runs as part of an escalation or filter run
process will not be able to find the server. To fix this, register the server
with a portmapper. You can also use the runmacro utility, which has a
command-line port setting.
For more information, see “Configuring clients through environmental
variables” on page 36.
The client/server interaction still requires the use of RPC when specific
ports are used.
Working with a portmapper service in AR System 35

Windows and portmapper services

Because many Windows environments do not have a portmapper service,
one is provided with the AR System server. If you already have a portmapper,
AR System registers with it if requested. If not, you can specify that the
AR System Portmapper service needs to be started and used as the
portmapper for the system.
There is no AR System Portmapper for UNIX because all UNIX operating
systems include a portmapper as a standard feature.
Configuring clients through environmental variables

When using a client on a UNIX server, you can connect to the AR System or
to a private server at a specific TCP port by setting the AR TCP Port variable.
The following strategies require that all servers that the client uses are on the
same port.
For the C shell, use the following commands to set ARTCPPORT:
% setenv ARTCPPORT <TCP_Port_Number>
% aruser &
For the Bourne shell, use the following commands to set ARTCPPORT:
% ARTCPPORT=<TCP_Port_Number>; export ARTCPPORT
% aruser &
For an API program, you can set variables through a shell or from within the
program. For more information, see the C API Reference guide.

Chapter
2 Obtaining and activating

licenses
This section provides information about licensing. The following topics are
provided:
Licensing overview (page 38)
Licensing a new AR System server (page 40)
Manually applying license keys (page 41)
Transferring server licenses to other servers (page 42)
Exporting licenses (page 43)
Importing licenses (page 45)
Obtaining and activating licenses 37

Licensing 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. Additional
AR System server options, such as the Distributed Server Option (DSO) and
Flashboards, require a separate, additional license.
In addition to server and server option licenses, AR System has user licenses.
The four kinds of user licenses you can use to access the AR System server are:
read, restricted read, fixed write, and floating write.
The base AR System product, after being licensed with the AR System server
license, comes with three Fixed Write licenses, unlimited Read licenses, and
unlimited Restricted Read licenses. To purchase additional user Fixed Write
licenses and user Floating Write licenses, contact your BMC Remedy Product
sales representative or an authorized reseller.
You can evaluate the AR System without purchasing or activating any
licenses. You are limited, however, to a maximum of 2000 records per form.
If you plan to install any AR System application that requires a license key
(for example, Flashboards), 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. All licenses now issued are multi server
licenses.
For information about licensing applications that you create using BMC
Remedy products, see the Integrating with Plug-ins and Third-Party Products
guide.
For information about licensing server groups, see “Licensing server groups”
on page 187.
38 Chapter 2—Obtaining and activating licenses

Configuring
License keys
A license key consists of an encrypted character string to initialize or enable
the use of AR System as specified in the license key. This key allows you to
enable functionality and allows users to access the AR System and authorize
the type of access for each user. Two key pieces of information in your
License Key are:
Site Name—A string that is used to link all available licenses together. For
this reason, each license on each of your servers must use the same,
numeric site name.
Host ID —A value that ties your license keys to a specific machine.
The license key you receive establish the number of users authorized to access
the AR System installed on the server and the type of access granted to such
users (for example, fixed write license or floating write license). The key also
establishes the site name and host ID. You then use this key to apply or add
the licenses for AR System servers, server options, and users.
Note: License key generation includes a high level of security. Do not make
changes to the license file. The AR System server manages this file and will
make changes to it as needed.
Make a backup copy of your license file so that if it becomes corrupted,

you can restore your licenses by importing your backup copy using the
Add/Remove Licenses window in BMC Remedy Administrator.
Otherwise, you must reapply for licenses to BMC Remedy Customer
Support.
Contacting Customer Support

Use one of the following methods to contact Customer Support:
Access the Customer Support product licensing website
http://supportweb.remedy.com.
Send an email to Customer Support at support@remedy.com.

Call Customer Support or your local support center (see the Support
website http://supportweb.remedy.com for numbers).
Licensing overview 39
Licensing a new AR System server

When you license a new product, you first obtain a license from Customer
Support and then apply the license using BMC Remedy Administrator.
To obtain a new license

1 Access the Customer Support website at http://supportweb.remedy.com.
2 Enter your single sign-on information from your web profile, and select
License Request.
3 Choose the appropriate site for requesting a new license.
An online form is displayed.
4 Supply the following information:
Support Contract ID—The identifier for your site.
Purchase Order number—The P.O. provides information about your
product features.
Email address—The address to which you want the licenses sent.
Host ID—The unique identifier for your AR System server.
5 Click Submit.
After you submit your information, Customer Support will send you an
email with the new license key or an email requesting additional required
information. If you do not receive the email within one working day, contact
Customer Support.
6 Save the license file.
To apply a new license

1 Log in to BMC Remedy Administrator.
2 In the Server window, select the server to license.
3 Choose File > Licenses > Add/Remove Licenses.
The Add/Remove Licenses window opens.
4 Import your new license file that you received from Customer Support; see
“Importing licenses” on page 45.
The system automatically loads your new licenses.

Configuring
Contact Customer Support if you cannot add the license file with BMC
Remedy Administrator or if you see the following error message:
Invalid AR Server license file. (ARERR 466)
Manually applying license keys

You can enter license keys manually for AR System 7.0 using the Add/
Remove Licenses dialog box. You cannot, however, apply AR System 6.0 and
later license keys to AR System 5.x servers or conversely, apply AR System 5.x
license keys to AR System 6.0 and later servers.
To apply license keys manually

Figure 2-1: The Add/Remove Licenses window
Manually applying license keys 41

4 Enter the license key information for the first license into the fields. Copy the
license information precisely.
5 Click Add License.
A dialog box is displayed confirming your license has been granted.
6 Click OK.
The license information is listed in the Add/Remove Licenses window.
7 Repeat steps 4 and 5 for each license key.
8 Close the Add/Remove Licenses window.
The server creates the new license file for you.
Transferring server licenses to other servers

When you transfer an AR System server license from one server to another,
you need to obtain a new license file from Customer Support, apply it to the
new server, and then delete the licenses from your old server. With the new
license file, the old and new servers can run in parallel for 60 days before the
licenses from your old server expire.
To obtain and apply the new license

1 Install AR System on the new server.
3 In the Server window, select the new server to which you want to transfer the
license.
4 Export your licenses.
See “Exporting licenses” on page 43.
5 Obtain a new license file.
When you receive your new license file from Customer Support, proceed
with the following steps.
7 In the Server window, select the new server.

Configuring
9 Import your new license file, make sure the Overwrite License check box is
cleared. See “Importing licenses” on page 45.
The system automatically loads your new licenses.
Contact Customer Support if you cannot import the license file or if you see
the following error message:
Invalid AR Server license file. (ARERR 466)
To delete the old license

2 In the Server window, select the new server.
4 Select the server license that was transferred to the new server.
5 Click Delete License to remove the server license.
Exporting licenses
You can export your licenses to a directory to provide a backup copy, or to
provide a repository when sending a copy of your licenses to BMC Remedy
Customer Support for an upgrade or overwrite. You have to export all the
licenses; you cannot select specific licenses to export.
To export AR System licenses

Exporting licenses 43
Figure 2-2: The Add/Remove Licenses window
4 Click Export Licenses.

The Save As dialog box opens.
5 Navigate to the directory where you want to save the license.
6 Enter a file name in the File name field.
7 Click Save.
The licenses are saved in a .lic file.

Configuring
Importing licenses
You can use the following procedure to import an AR System license file that
you receive from Customer Support.
To import AR System licenses

3 Click Import Licenses.
The Import License window opens.
Figure 2-3: Import License window
4 Navigate to the location of the license file that you want to import.
5 Check the Overwrite licenses box if you are overwriting all your licenses.
WARNING: Select this check box only if you are renewing all your licenses.
This option deletes all existing licenses and adds only new ones. If you
delete your existing licenses accidentally, you must reapply to BMC
Remedy Support for new licenses.
6 Click the file name to add it to the File Name field.
Importing licenses 45
7 Click Open.
Your license file is imported to the default license directory. License
information is automatically added to the Add/Remove Licenses window
and any duplicate or incorrect licenses are removed.

Chapter
3 Setting user preferences
This section discusses options for setting user and administrator preferences
locally and on the server (centralized). The following topics are provided:
User preferences and customizations (page 48)
Local preferences (page 49)
Centralized preferences (page 49)
AR System User Preference form fields (page 55)
Setting centralized preferences on web clients (page 102)
Setting user preferences 47

User preferences and customizations

Users can set individual preferences for the behavior and display
characteristics of each client. These preferences can be stored locally (on the
client machine) or centrally (on a designated preference server).
Users who log in to BMC Remedy User can choose to use local or centralized
preferences. Centralized preferences help users who want to have the same
settings and customizations available when they use multiple machines.
Local preferences are used when no preference server is designated or
available. Regardless of whether centralized or local preferences are used,
multiple users can use the same client machine with individual preferences
and customizations. For more information, see “Setting centralized
preferences on Windows clients” on page 55.
For multiple users on a single machine, you need to set up separate user
accounts by creating individual Home directories. For more information
about the content and format of files in the Home directory, see BMC
Remedy User help. For information about setting up user accounts, see the
client installation section in the Installing guide.
Users logging in to web clients must use centralized preferences to store
preferences. See “Setting centralized preferences on web clients” on page 102
for more information.
48 Chapter 3—Setting user preferences

Configuring
Local preferences
Local preferences are saved on the user’s computer in the local ar.ini file.
To use localized preferences

1 Open BMC Remedy User.
2 Enter your login information and specify (none) in the Preference Server field
on the Login window.
Your preferences are saved to your local ar.ini file.
Note: There is no synchronization between local and centralized preferences;

local preferences are not stored on your preference server. Similarly, the
system does not update your ar.ini file when you set your centralized
preferences.
Centralized preferences
To use centralized preferences, create at least one preference server during
the login procedure, configure clients to log in to the preference server, and
install the preference forms during server installation. Web clients can also
access the web view of the AR System User Preference form.
If you did not install preference forms during installation, after you log in,
your local ar.ini file is used to determine your preferences.
If you have not installed the preference forms, and subsequently want to use
centralized preferences, you can import the definition files. There are three
preference forms, and all three must be loaded on the preference server for
centralized user preferences to function properly. For more information
about these forms, see “Creating a preference server” on page 50.
Local preferences 49
Creating a preference server

To create a preference server, install or import the following forms and
associated objects:
Form Purpose and Content

User Preference Stores preferences for BMC Remedy User, BMC Remedy
form Alert (if installed), and web clients. This form has two views:
Standard view—Displays every field on the form, and has
all the preferences that you can set for the web and BMC
Remedy User, including the Request ID, Modified Date,
and Last Modified By fields. Administrators have access to
every user entry for this form.
Web view—Displays web preference fields (that is the
preferences used by the web).
User Central File For BMC Remedy User only, stores copies of locally stored
form customized files such as saved searches, favorite forms,
macros, reports, customized field defaults, and user data
files. Note that recently used forms, guides, applications, and
requests are stored in the AR System User Preference form.
Administrator Stores preferences for BMC Remedy Administrator and
Preference form BMC Remedy Import. By default, this form has
administrator permissions only. You might want to set
subadministrator permissions by following the procedures
in the Form and Application Objects guide.
Display preferences and the list of login servers are shared
with BMC Remedy User and are stored in the AR System
User Preference form.
For information about installing centralized preference forms, see the

Installing guide. For information about importing forms and other server
objects, see the Form and Application Objects guide.

Configuring
Configuring clients to use a preference server

To use centralized preferences in BMC Remedy User, users must specify a
preference server during login by selecting the server from the list in the
Preference Server field of the Login dialog box.
For web clients, the administrator specifies preference servers.
Administrators can specify the names of preference servers during the
mid tier installation, or they can specify these servers later by using BMC
Remedy Mid Tier Configuration Tool. For more information, see the
Installing and Administering BMC Remedy Mid Tier guide. Also, see the
online help for BMC Remedy User, BMC Remedy Administrator, BMC
Remedy Alert, and BMC Remedy Mid Tier Configuration Tool.
Make sure that users can modify their entries on the preference forms. To do
this, assign a write license to every centralized preference user, or set the
Submitter Mode on the server to Locked, which allows users to modify
requests without a write license. For more information, see “Adding and
modifying user information” on page 108 and “Special submitter mode” on
page 115.
Establishing a mandatory preference server

As an AR System administrator, you can designate a mandatory preference
server that stores the system preference information. This configurable server
setting provides a mechanism to enforce the use of centralized preferences
across an organization.
To enable a mandatory preference server

2 Select the server that will be used to store preferences.
3 Choose File > Server Information.
4 Click the Advanced tab.
Centralized preferences 51
Figure 3-1: Server Information window—Advanced tab
5 Select the appropriate Preference Server Option:

User Defined—This option allows the user to determine whether or not
to use a preference server.
Use This Server—This option designates the current server as the
preference server. (The preference forms must be available)
Use Other Server—This option designates the current server as a non-
preference server and indicates that there is another server on the system
that is set with Use This Server.
Important: If Use This Server or Use Other Server is selected, the local
preferences are disabled. The system will attempt to connect to the
designated preference server. If no preference server is found, the default
preference values are used instead of the local ar.ini file.

Configuring
For more information about the effects of these choices, see “Behaviors
associated with preference server configuration” on page 53.
6 Click OK.
Behaviors associated with preference server

configuration
To use centralized preferences in BMC Remedy User, users must specify a
preference server during login by selecting the server from the list in the
Preference Server field of the Login dialog box.
Different behaviors will occur depending on the server settings you
configure.
If you choose User Defined as the Preference Server Option on the Advanced
tab of the Server Information window, the following behaviors can occur:
User action Behavior

The user leaves the The local preferences are used (ar.ini file).
Preference Server field
blank
The user specifies a valid The system connects to the preference server, and the Accounts list is updated
preference server to reflect the list of servers that are specified on the Server List setting.
The user specifies an The local preferences are used (ar.ini file).
invalid preference server
Centralized preferences 53
If you choose Use This Server or Use Other Server as the Preference Server ,
the following behaviors can occur:
User action Behavior

The user leaves the The system searches the Accounts list for a server that is designated as a
Preference Server field preference server. If one is found, the server name is written to the Preference
blank Server field of the Login dialog box. In addition, the accounts list is updated
to reflect the list of servers that are specified on the Server List setting for that
preference server.
Note: The user will receive this warning: 50176—A preference server has
been selected based on the Administrator settings.
If no preference server is available, the default preference values are used and
no session specific changes to the preferences are stored. (Local preferences
are disabled)
The user specifies a valid The system connects to the preference server and the Accounts list is updated
preference server to reflect the list of servers that are specified on the Server List setting for that
preference server.
The user specifies an The system searches the accounts list for a server that is designated as a
invalid preference server preference server. If one is found the server name is written to the Preference
Server field of the Login dialog box. In addition, the accounts list is updated
to reflect the list of servers that are specified on the preference server.
Note: The user will receive this warning: 50174—The preference server
specified is invalid. Another preference server has been
selected.
If no preference server is available, the default preference values are used and
no session specific changes to the preferences are stored. (Local preferences
are disabled.)
The user will receive this warning: 50175 -- The preference server
specified is invalid. User preferences will not be used.

Configuring
Setting centralized preferences on Windows clients

User and administrator preferences can be set using the following client
tools:
For BMC Remedy User and BMC Remedy Alert, preference settings are
accessed through the Tools > Options menu, and are stored in the
AR System User Preference form.
For BMC Remedy Administrator and BMC Remedy Import, preference
settings are accessed through the File > Preferences menu, and are stored
in the BMC Remedy Administrator Preference form.
In BMC Remedy User, users can also create and save customizations such as
reports, macros, favorite forms, user data, custom field defaults, and saved
searches. All these customizations are stored locally on the client, but they
can be uploaded to and downloaded from the AR System Central File form
for centralized access.
Preferences can be set in BMC Remedy User to synchronize local and central
copies by uploading or downloading files manually or automatically, such as
when the user logs in. Before selecting a synchronization method, users need
to consider the number of customizations, the frequency of changes, and
whether central or local copies of files are likely to be the most current.
For more information about creating customizations, and downloading and
uploading custom files, see BMC Remedy User help.
You can also set the value of the fields in the User Preferences form using the
PERFORM-ACTION-SET-PREFERENCErun processcommand.SeeWorkflowObjects
guide for more details.
AR System User Preference form fields

The following tables list the fields in the AR System User Preference form.
Common fields
These fields reside in the non-page field portion of the AR System User
Preference form. These fields affect both BMC Remedy User and the mid tier.
AR System User Preference form fields 55

Figure 3-2: AR System User Preferences form—common fields
Field Name Description

Login Name The user’s login name. Lets the administrator create, search
for, and modify preferences for a specific user by entering
that user’s login name in this field.
Users can search for and modify their own preference
records.
The default setting is $USER$.
Short Description Lets the administrator create, search for, and modify
preferences based on a value in this field.
The default setting is Preference entry for $USER$.
Create Date The date the record was created. This field is display-only.
Modified Date The date the record was last modified. This field is display-
only.
Last Modified By The login name of the user who last modified the record.
This field is display-only.
Request ID The request ID of the record. This field is display-only.
Assigned To Not used.
Status Not used.

Configuring
General tab
Figure 3-3: AR System User Preferences form—General tab

General tab—Application area

Group Name Field Name Description BMC Web
Remedy client
User
On Startup Maximize Defines whether the BMC Remedy User main X
AR System User window fills the entire screen when it is opened.
Prompt For Defines whether you are prompted for a user X
Login name and password each time you log in.
If you select No, the user name and password
you enter are saved and used to log in
automatically the next time BMC Remedy User
is started.
You are still prompted for a login regardless of
this setting if any of these conditions exists:
The administrator has enforced required
login.
You are using BMC Remedy User on a
computer other than his or her own.
A user account with a directory path for your
Home folder on you local machine has not
been specified in the Users dialog box.
Note: If you select No as the Prompt for Login
option and you were the last user to log in,
other users accessing BMC Remedy User
from that machine are logged in
automatically under your user name.
On Exit Save Window Defines whether, the next time you open BMC X
Workspace Remedy User, the workspace appears as it was
when you closed it, including the windows that
were open, their size and position.
Note: If you have a window workspace saved,
BMC Remedy User will load that workspace
when you open BMC Remedy User regardless
of how you have this preference set. If you do
not want a workspace loaded, you must select
Yes to save the workspace, close all forms,
and exit BMC Remedy User. Then, open
BMC Remedy User and check No for Save
Window Workspace.

Configuring

Remedy client
User
Server Server Login Defines which servers BMC Remedy User X
List connects to. To change this list, open BMC
Remedy User and choose Tools > Accounts to
display the Account dialog box.
Advanced Corresponds to the Advanced Server Properties X
Server Option option in the Account dialog box. To see the
Account dialog box, open BMC Remedy User
and choose Tools > Accounts.
The options are:
No—Clears the Advanced Server Properties
check box in the Account dialog box.
Yes—Selects the Advanced Server Properties
check box in the Account dialog box. If you
select Yes, the TCP and RPC columns will be
displayed in the Account dialog box. These
are used for setting the TCP port number or
private server number for a specific server.


Remedy client
User
Search Path Designates the directories where you can access X X
custom reports and macros. The path is
typically the <user's_home_directory>/arHome/
arcmds directory.
To change the search path, enter the entire
directory name for the directory to which you
want access.
To specify more than one directory, separate
each directory name with a semicolon. You can
specify any directory to which you have access.
Note: If you delete all directories from your
search path, you are not able to access any
custom reports or macros.
Num Items in By default, the number of recently used items is X
Recently Used set to 5. You can specify from 4 to 9 items. This
List setting applies to these menu lists in BMC
Remedy User:
File > Recent New Forms—Displays a list of
the most recently used forms in New mode.
File > Recent Search Forms—Displays a list
of the most recently used forms in Search
mode.
File > Recent Requests—Displays a list of
the most recent requests.
File > Recent Entry Points—Displays a list
of the most recent entry points.
Actions > Recent Searches—Displays a list
of the most recently used searches.

Configuring
General tab—Form area

Remedy client
User
On New Defines the action a form opened in New mode X X
takes when accessed multiple times. The
options are:
Set Fields to Default Values—(Default)
Designates that fields on new forms are filled
with default values when a new form is
opened or when a form is reset after a request
is submitted.
Keep Previous Field Values—Designates
that fields on new forms are filled with the
previously used values when that form is
reset after a request is submitted.
Clear All Fields—Designates that all fields on
new forms are cleared when a new form is
opened or when a form is reset after a request
is submitted.
Clear—Designates that when no option is
selected, the default (Set Fields to Default
Values) is used.


Remedy client
User
On Search Defines the action a form opened in Search X X
mode takes when accessed multiple times. The
options are:
Set Fields to Default Values—Designates
that fields on search forms are filled with
default values after you perform a search,
display the records in modify or display
mode, and then return to the search form
without closing the form.
Keep Previous Field Values—Designates
that fields on search forms are filled with
previously used values after you perform a
search, display the records in modify or
display mode, and then return to the search
form without closing the form.
Clear All Fields—(Default) Designates that
all fields on search forms are clear after you
perform a search, display the records in
modify or display mode, and then return to
the search form without closing the form.
Clear—Designates that when no option is
selected, the default (Set Fields to Default
Values) is used.
Show Result Defines whether you view only the results list X X
List Only after every search. If you select No, you will
view the results list and a detail pane after every
search.
Limit Number Defines whether the number of search results X X
of Items returned is limited. The options are:
Returned No—(Default) All results are returned.
Yes—The number specified on the User
Preference form is returned. When you select
Yes, you can specify the number of search
results returned. (If you choose No, this field
is disabled.) The default value is 1000. This
preference can be overridden by the Max
Entries Returned by GetList server setting in
the Configuration tab of the Server
Information window. AR System will use the
lesser of the two values.

Configuring

Remedy client
User
On Open Show Advanced Defines whether to show the advanced search X X
Search Bar bar when a new window is opened.
Maximize Defines whether a form is maximized when it is X
Window opened.
If you select No, the form fills only a portion of
the BMC Remedy User window.
Diary Field Show Most Defines the order in which entries appear in the X X
Recent First diary field of a form. The options are:
Yes—Diary entries are listed in descending
order by date, starting with the most recent
entry.
No—(Default) Diary entries are listed in
ascending order by date, starting with the
earliest entry.
Default—See No.


Remedy client
User
Field Menu Display As Designates how field menus are displayed. The X X
options are:
Default—See Popup Menus.
Popup menus—(Default) Display menus in
standard popup menus. Hierarchical menus
are displayed with arrows indicating that you
must move to the right to view lower-level
menu selections. Large menus can cause
display problems.
List boxes—Display menus in tree views.
Choose this option if you need to display
large menus.
Smart menus—Display menus in standard
popup menus except when the menu exceeds
four levels or the total number of menu items
exceeds 200. In this case, the menu is
displayed as a list box.
Clear—Display menus in standard popup
menus. Hierarchical menus are displayed
with arrows indicating that you must move
to the right to view lower-level menu
selections. Large menus can cause display
problems.
Field Menu Expand at Determines whether the field menus are X
Startup expanded when the menu is opened. The
options are:
Yes—All levels of the menu are displayed
when the menu is opened.
No—Only the first level is displayed when
the menu is opened.

Configuring

Remedy client
User
Pane Layout For BMC Remedy User only, defines position X
of the Results List and the Details Pane. The
options are:
Default—See Top.
Right—Results List on the right; Details Pane
on the left.
Left—Results List on the left; Details Pane on
the right.
Top—(Default) Results List on the top;
Details Pane on the bottom.
Bottom—Results List on the bottom; Details
Pane on the top.
Clear—Results List on the top; Details Pane
on the bottom.
Flat Look On Designates whether forms have a flat or 3-D X
Forms look. The options are:
No—Use shadows to give the form a 3-D
feel.
Yes—Do not use shadows. This gives the
form a “flat” appearance.

Display tab (BMC Remedy User only)

The Display tab displays values you specify on the Display tab in the Options
dialog box for fonts associated with the following BMC Remedy User field
types:
Edit Field Menu List Node

Push Button Menu List Leaf
Radio Button Header Text (I)
Option Field Header Text (II)
Required Field Header Text (III)
System Field Note Text
Results Pane Detailed Text
Query List
Figure 3-4: AR System User Preferences form—Display tab

Configuring
Color tab (BMC Remedy User only)

The Color tab displays colors associated with the following BMC Remedy
User window types:
New Customize View

Search Customize Field Default
Display Results List
Modify Dialog Window
Modify All
Figure 3-5: AR System User Preferences form—Color tab
In addition, the Use Background Color field designates whether the default
colors or the color codes defined on the Tools > Options tab are used to
display BMC Remedy User windows. The options are:
No—Default Color is selected on the Color tab in the Options window in
BMC Remedy User.
Yes—Color codes defined on the Color tab in the Options window in
BMC Remedy User are used to display windows.

Confirmation tab
Figure 3-6: AR System User Preferences form—Confirmation tab

Configuring

Remedy client
User
Confirm After Creating a Defines whether there is a confirmation after a X X
New Request new request. The options are:
No—(Default) The entry is submitted
without verification.
Yes—A dialog box appears after the form is
submitted to verify the submitted entry and
the entry ID.
When Deleting Defines whether there is a confirmation when X
a Report you attempt to delete a report. The options are:
No—(Default) The report is deleted without
verification.
Yes—A dialog box appears when you
attempt to delete a report.
a Saved Search you attempt to delete a saved search. The
options are:
No—(Default) The saved search is deleted
without verification.
attempt to delete a saved search.
a Macro you attempt to delete a macro. The options are:
No—(Default) The macro is deleted without
verification.
attempt to delete a macro.

Report tab
Figure 3-7: AR System User Preferences form—Report tab

Remedy client
User
Default Margins Left Margin Defines the number of blank characters X X
Right Margin from the left or right edge of the page. The
default for the left and right margin is 0
characters.
Top Margin Defines the number of blank lines from X X
Bottom Margin the top or bottom edge of the page. The
default value for the top and bottom
margin is 1 line.
* N/A = The setting does not apply to BMC Remedy User or the web client. The setting applies to activities
such as logging or other clients (such as BMC Remedy Alert).

Configuring

Remedy client
User
Default Column Titles Defines the default characters to separate X X
Separators Column column titles, columns, or requests,
respectively. By default, column titles are
Request
separated by hyphens (-), and columns
and requests are separated by a blank
space.
You can use any of these special
characters:
\b (backspace)
\n (return)
\t (tab)
\\ (backslash)
\<nnn> (ASCII character)
Note: You cannot use the Tab key to

create tabs, but you can use the special
tab character to include a tab in the
separator.
Default Page Orientation Defines whether the default page is in X X
Size Portrait or Landscape mode.
Use printer default Designates whether the default page size X X
page size should correspond to the default printer
page size.
Lines Per Page Designates how many lines of text are X X
printed on each page. The default value is
66.
Chars Per Line Designates how many characters are X X
printed on each line. The default value is
80.


Remedy client
User
Misc Default Column Title Per Designates a default value for how often X X
column titles appear in a report. The
options are:
6—Column titles appear for each
request in the report.
7—Column titles appear for each page
in the report.
8—No default.
Page Break Per Designates a default value for how often X X
page breaks occur in a report. The options
are:
6—Page breaks occur after each request
in the report.
7—Page breaks occur after each page in
the report.
8—No default.
ODBCReportDot Indicates whether the ODBC driver N/A* N/A*
should replace the dot in Crystal Report
field names. The options are:
No—(Default) Do not replace the dot.
Yes—Replace the dot.
Enable Report to Indicates whether the Enable Report to X
Application Application check box is selected on the
Reports tab in the Options window in
BMC Remedy User.

Configuring
Logging tab
Figure 3-8: AR System User Preferences form—Logging tab

Remedy client
User
Client Macro Designates whether use of macros on the client X
is logged.
Active Links Designates whether use of active links on the X X
client is logged.
Extended Log Obsolete.
Server API Designates whether use of APIs on the server is X X
logged.
Filter Designates whether use of filters on the server is X X
logged.
Database Designates whether activity on the database is X X
logged.
Global Global Logging Designates whether global logging is enabled. X
Enabled
Log File Path Defines the path to the log file. X X

Locale tab
Figure 3-9: AR System User Preferences form—Locale tab

Configuring

Remedy client
User
Locale User Locale Designates the language displayed on the user’s X X
system, in the format <language_Country>,
where language is the language code (such as fr
for French or en for English), and Country is the
two-letter country code (such as FR for France
or US for United States). Some sample entries
are:
en_US—English (United States)
fr_BE—French (Belgium)
fr_CA—French (Canada)
zh_HK—Chinese (Hong Kong)
zh_CN—Simplified Chinese
ja_JP—Japanese (Japan)
This field is clear by default.
Time Zone Defines the time zone displayed on the user’s X X
system. Select a time zone from the menu, for
example, Asia/Tokyo, America/New York, or
Europe/Paris.
Any ICU (International Component for
Unicode) format is accepted. This field is clear
by default.
Display Date/ Defines the format in which the date and time X
Time Style appear. According to Windows format, the
(BMC Remedy options are:
User) Short
Long
Custom
This setting is platform-independent and will
not automatically be the same as preferences set
in BMC Remedy User, or as any preferences set
in the Windows Control Panel. Use a
predefined Windows format.
The default is Short.


Remedy client
User
Locale Custom Date/ Defines the custom Date/Time length format. X
(continued) Time Format This field is active only when Custom is selected
(BMC Remedy from the Display Date/Time Style menu list.
User) To customize separators and other options, use
a predefined Windows format or a customized
Windows format.
Currency The type of currency to be applied for this X X
locale (for example, USD for United States
dollars).
If currency is specified here, it overrides the
administrator-defined Initial Currency Type in
the field properties dialog box. If there is a
default value for this field, it overrides the User
Preference and the Initial Currency Type.
File tab (BMC Remedy User only)

Figure 3-10: AR System User Preferences form—File tab

Configuring
You can specify the conditions under which you want to upload and
download types of preference files to and from the preference server.
File types
You can specify options for downloading and uploading the following file
types:
Macro
AR SystemReport
Crystal Report
Search
Data File
Customize Default Field
See BMC Remedy User help for information about uploading and
downloading preference files.
Download actions
For each file type, you can specify the following actions for downloading:
On Login—Automatically download all files of the selected type when you
log in.
On Demand—Download files only when they have been accessed.
Manual—Manually download files, or download files of the selected type
by choosing Tools > Manage > Files > Download.
Upload actions
For each file type, you can specify the following actions for uploading and
downloading:
Immediate Save—Immediately upload the file after it is created or
modified.
On Relogin or Exit—Automatically upload all files of the selected type
when you log in or exit.
Manual—Manually download files, or upload files of the selected type by
choosing Tools > Manage > Files > Upload.

Advanced tab
Figure 3-11: AR System User Preferences form—Advanced tab

Configuring

Remedy client
User
Form Default Form Defines the view to be used as the default for all X
View forms. Ask your AR System administrator for
the name you should enter here, or leave this
field blank.
Note: If you enter a view name that does not
exist, AR System determines which view best
fits. This might not be the default view.
Open Window Defines the extension to be used as the default X
View Extension for all forms that are opened from other forms.
Ask your administrator for the name you
should enter, or leave this field blank.
Note: If you enter an extension that does not
exist, AR System determines which view best
fits. This might not be the default view.
Display Hidden Defines which forms are available. The options X
Forms (Admin) are:
No—Only those forms that have been
designated as visible are available.
Yes—All forms are available, whether
designated as hidden or visible.
Note: This option is available only if you are
logged in as an administrator or
subadministrator to an active server.
Table Fields Refresh Content Defines whether the data in a table field is X X
on Display refreshed automatically every time a form is
displayed.
Note: You can refresh the table manually by
clicking on it when you want to check for
changes.


Remedy client
User
Report Server Defines the name of the server where the X X
following reporting forms reside:
ReportType
ReportCreator
Report
ReportSelection
The server name also serves as the home for
report definition files created. This entry is
necessary when the server that stores the
reporting forms is different from the server that
stores the data to be reported on. This field is
blank by default.
Preview Report Specifies whether to preview reports in BMC X
Remedy User or a different program you
specify. The options are:
No—Displays reports in BMC Remedy User.
Yes—Display reports using the program
specified in the Report-Use this program to
preview field.
Use this Specifies the program to be used to preview X
program to standard BMC Remedy User reports.
preview
ODBC Use Defines whether to replace special characters X
Underscores with underscores when running reports.
This is important if you are running Crystal
Reports and there are field names or form
names in your reports that contain special
characters. Choose Yes to use underscores.

Configuring

Remedy client
User
Result View Alert Sort Displays the last column on which you sorted a X
result or alert list. You can specify a value in this
field.
Sort Criteria Displays the value set when you choose X
Actions > Sort Options and specify values. You
can set sort options on a per-form basis.
AR System AR System Reserved for future use. N/A* N/A*
Reserved Reserved

Home Page tab

Figure 3-12: AR System User Preferences form—Home Page tab

Configuring

Remedy client
User
Home Page AR Server Designates the name of the server on which X X
your Home Page resides.
For more information about configuring home
page preferences, see the Form and Application
Objects guide.
Form Name Designates the name of the form to be used as X X
the default Home Page when the user logs in.
For more information about configuring home
page preferences, see the Form and Application
Objects guide.
Object List Defines to what degree the Object List is X
enabled.
Enable, Show All—The Object List lists all
the applications, guides, and forms on the
servers to which you are logged in.
Enable, Show Only Entry Points—The
Object List lists only those entry points for
which you have permissions.
Disable—Access to the Object List is not
possible. The File > Open > Object List menu
item and toolbar button are disabled.
Open Home Controls whether the Home Page is opened X X
Page automatically after login to BMC Remedy User.
Automatically

Alert tab
Figure 3-13: AR System User Preferences form—Alert tab

Remedy client
User
When I start my Auto start Designates whether to start BMC Remedy Alert N/A* N/A*
computer AR System when you start your computer.
Alert
On Startup Prompt For Designates whether to prompt the user for N/A* N/A*
Login (Alert login information when Alert is started. The
only) options are:
No—The user name and password you enter
are saved and used to log you in
automatically the next time BMC Remedy
Alert is started.
Yes—You must enter your user name and
password each time you start BMC Remedy
Alert.
Display Alert Designates whether to display summary N/A* N/A*
Summary information when Alert is started.

Configuring

Remedy client
User
Listen Port Port Number Designates the port on which to listen for alerts. N/A* N/A*
The Listen Port is used in conjunction with
Advanced Server Properties settings in the
Accounts dialog box to configure BMC
Remedy Alert to function outside of a firewall.
Logging Enabled Designates whether logging should occur for N/A* N/A*
Logging Alert.
If Yes, Logging Designates the path and name of the log file. N/A* N/A*
Path By default, alert log files are stored with a .log
file extension.
Misc OLE Timeout Designates how long the OLE Transaction N/A* N/A*
Timeout is for BMC Remedy Alert. OLE is used
to open the Alert list in BMC Remedy User.
Open Alert List Designates which application should be used to X X
using open the Alert List. The options are:
AR System User
Web
Server Designates the server to be used to open the N/A* N/A*
Alert list.


Remedy client
User
On Startup Display Alert Designates whether to pop up alert N/A* N/A*
Message information when received.
Flash Icon Designates whether to flash the Alert icon when N/A* N/A*
a new alert is received.
Beep Designates whether to beep when a new alert is N/A* N/A*
received.
Play Wav File Designates whether to play a .wav file when a N/A* N/A*
new alert is received.
Wav File Designates the .wav file to play if the P lay Wav N/A* N/A*
File option is set to Yes.
Run Process Designates whether to run a process when a N/A* N/A*
new alert is received.
Run Process Designates the process to run if previous option N/A* N/A*
File is set to Yes.

Configuring
Recent tab
Figure 3-14: AR System User Preferences form—Recent tab
Field Name Description BMC Web

Remedy client
User
Recent Forms A list of recent forms opened in BMC Remedy User. X
Recent Tickets A list of recent requests opened in BMC Remedy User. X
Recent Applications, A list of recent applications or guides opened in BMC X
Guides, etc. Remedy User.
Recent Entry Points A list of recent entry points opened in BMC Remedy User. X

Edit tab
Figure 3-15: AR System User Preferences form—Edit tab

Remedy client
User
Table Field Table Field Information about a table field that AR System X
Column Width saves when you change the size of columns in
the table field, including the server name, form
name, table field ID, column ID, and the size of
the column.
Table Field Stores column order preference. X
Column Order
Table Field Not used. N/A* N/A*
Column Sort

Configuring

Remedy client
User
Schema Column Width Information about a results list that AR System X
saves when you change the column size in a
results list.
Column Order Information about a results list that AR System X
saves when you change the order of columns in
a results list.
Grid Height Parameter set in Customize View mode by X
choosing Layout > Grid Size and specifying a
value.
Grid Width Parameter set in Customize View mode by X
choosing Layout > Grid Size and specifying a
value.
App Specifies whether to display extra field name X
Development and ID information in the field Help text.
Mode Values are:
1—Display the extra field information.
0—(Default) Do not display the extra field
information.


Remedy client
User
Menu Position Menu window position. The options are: X
Default—See Center.
Left—Left of where menu icon clicked.
Center—(Default) Center of BMC Remedy
User window.
Right—Right of where menu icon clicked.
Screen Center—Center of screen.
Max Size Base The upper limit for the number of items a X
Menu menu can have. Used for currency and edit
field menus.
Items Per Obsolete. N/A* N/A*
Column
List Position List-menu window position. The options are: X
Default—See Center.
Left—Left of where menu icon clicked.
Center—(Default) Center of BMC Remedy
User window.
Right—Right of where menu icon clicked.
Screen Center—Center of screen.
List Menu Width of the list menu window. X
Width
List Menu Height of the list menu window. X
Height
List Indent Space in pixels on left before list items in list X
menu.
Items When smart menus is selected, the number of X
Threshold items where menus change from popup to list
menus.
Level Threshold When smart menus is selected, the number of X
levels where menus change from popup to list
menus.

Configuring

Remedy client
User
Edit Diary Field Diary Width Diary editor window width. X
Diary Height Diary editor window height. X
Edit Text Field Text Width Text editor window width. X
Text Height Text editor window height. X

Window tab
Figure 3-16: AR System User Preferences form—Window tab

Configuring

Remedy client
User
Window Size Window Obsolete. This parameter is included for X
Position backward compatibility only. If a value for this
parameter is specified from a previous version
of BMC Remedy User, it is converted to the
Window Workspace Position parameter and
saved.
Window Used by BMC Remedy User to save X
Workspace information about how the window workspace
Position is set up and how to restore it. This value is set
when the Save Window Workspace option is
selected.
Pick/Selection Selection List window position. X
List
Window Count The number of New Search or New Request X
windows to be opened when BMC User starts.
This number is updated when you select Save
Windows Workspace under Tools > Options >
On Exit. The positions of these windows are
stored in the Window Workspace Position
field.
Toolbars Summary Coded information about toolbars. X
Bar0 Coded information about toolbars. X

Misc tab
Figure 3-17: AR System User Preferences form—Misc tab

Remedy client
User
Open Dialog Placement Coded location of the File > Open > Object List X
menu option in BMC Remedy User.
Active Page Current tab in File > Open > Object List menu X
option in BMC Remedy User.
Shortcut Dir Indicates the directory to use when creating a X
shortcut. This value is used when you select an
item from the Open Object List and right-click
to create a shortcut or when you right-click a
results list and choose Send To > Desktop.
&All Coded column widths of All, Find, Favorites, X
&Find and Recent that appear when you choose the
Fa&vorites File > Open > Object List menu option in BMC
&Recent Remedy User.
Fi&nd Not currently used.

Configuring

Remedy client
User
Performance These preferences relate to how BMC Remedy X
User caches forms. Definitions (form and
related workflow) are loaded into memory
from the .arf and .arv cache files and retained
as long as these files are current. This allows
subsequent loads of the same form to load
more rapidly since the definitions do not have
to be re-read from the disk each time.
To reduce the amount of memory being used,
several checks are made periodically to see if
definitions can be removed from the memory
cache. During these checks, the following
calculation is performed:
Duration Since Last Used = Current
Time - Time Definition Last Used
Max Age In If the Duration Since Last Used value is greater X
Minutes than the preference set for Max Age In Minutes,
the form definition can be removed from the
memory cache.
Min Age In If the Duration Since Last Used value is greater X
Minutes than the preference set for Min Age In Minutes,
the form definition can be removed from the
memory cache.
If the system is approaching the memory limit
(Percent of Memory), the Duration Since Last
Used value is taken in conjunction with the
Min Age In Minutes value to determine
whether the definition can be removed from
the memory cache.
Usage Each time a form is opened, the system X
Threshold increments a usage count. As the memory limit
is approached, the Usage Threshold value is
compared to the usage count to determine if
the definition can be removed from the
memory cache.


Remedy client
User
Performance Percent Of This value represents a memory threshold. It is X
(continued) Memory compared to the percent of memory being used
for the memory cache to determine if the
memory limit is reached. This check is used in
conjunction with the Usage Threshold and the
Min Age In Minutes values.
App Response DDE Application Response Timeout in BMC X
Timeout Remedy User.
Transaction DDE Transaction Timeout in BMC Remedy X
Timeout User.
RPC Timeout RPC Timeout for submits in BMC Remedy X
Normal User.
RPC Timeout RPC Timeout Long queries in BMC Remedy X
Long User.
RPC Timeout RPC Timeout for extra long operations in BMC
Extra Long User.
View Show Macro Designates whether the macro bar is displayed X
Bar when BMC Remedy User starts.
Show Status Bar Designates whether the status bar is displayed X
when BMC Remedy User starts.
Show Toolbar Designates whether the toolbar is displayed X
when BMC Remedy User starts.
Disable Web Designates whether items under BMC Remedy X
Help on the Web under the main Help menu in BMC
Remedy User are disabled.
Save Window Designates whether to save information about X
On Close open New and Search windows in BMC
Remedy User when you close the tool.
Query On Designates whether you can initiate a query by X
Return pressing the ENTER key in the Request ID field.

Configuring

Remedy client
User
View Close After Designates whether to close a New window X
(continued) Submit after submit in BMC Remedy User.
Show Lang DLL Obsolete.
Not found
Step Size Obsolete.
Result Open On Designates which panes open when you X
Double-Click double-click a record in a results view. The
options are:
Value greater than zero—Open the form
with a results pane and a detail pane.
0 (Zero)—Open the form with only a detail
pane.

Web tab
Figure 3-18: AR System User Preferences form—Web tab

Remedy client
User
Report Crystal Report Designates an application for viewing Crystal X
Viewer Reports. The options are:
Java (using browser JVM)
Java (using Java Plug-in)
ActiveX
Netscape Plug-in
HTML with frames
HTML without frames (the default)
Clear (The system takes the default value that
the administrator sets.)

Configuring

Remedy client
User
Alert Refresh Interval Defines the interval, in minutes, that passes X
between queries to the Alert Events form. The
default value is 0.
The alert list displays the user’s alerts by
querying the Alert Events form that contains
the user’s alerts.
Alert Servers Defines which servers contribute alerts to a X
web-based alert list. The administrator can
enter the server names to retrieve alerts from
this field. The server names must be separated
by the comma ( , ) delimiter.


Remedy client
User
Date/Time Text Display Date/ Defines the format in which the date and time X
Time Style appear. The options are:
(Web) Short
Long
Custom
The formats adhere to the ICU (International
Component for Unicode) format.
The format is platform-independent and will
not automatically be the same as preferences set
in BMC Remedy User, or as any preferences set
in the Windows Control Panel. Use a
predefined ICU format or customize an ICU
format to set web view Date/Time appearances.
The default is Short.
Custom Date If you select Custom from the Display Date/ X
Format Time Style (Web) menu, select the format of
date strings to be displayed in your browser.
You can add a forward slash (/), dash (-) or a
period (.) as separators. This field is clear by
default.
For more information about date formats, see
Appendix D, “Date and time formats.”
Custom Time If you select Custom from the Display Date/ X
Format Time Style (Web) menu, select the format of
time strings to be displayed in your browser.
You can add a semicolon (:), dash (-), or a
period (.) as separators. This field is clear by
default.
For more information about time formats, see
Appendix D, “Date and time formats.”

Configuring

Remedy client
User
Accessibility Accessible Designates whether an accessible mode applies X X
Mode to the current view and if so, which mode. The
options are:
Default—No accessible mode used.
Screen Magnifier/Low Vision—View is
accessed with a screen magnification device.
Use the magnifier supplied with your
operating system.
Screen Reader/No Vision—View is accessed
using screen reader software.
Accessible Designates the type of nonvisual feedback that
Message applies to workflow for this view. The options
are:
No Action—No messages are shown for
accessibility. Active link message actions of
the type Accessible are ignored.
Message Action—Displays accessibility
messages defined by the active link message
action of type Accessible.
All Actions—Displays accessibility messages
to reflect visual changes on the page as well as
accessible messages defined by an active link
message action of the type Accessible.
Accessibility messages are displayed for
visual changes caused by Change Field and
Set Field active link actions, and other user
actions such as table refresh. These messages
reflect the visual changes that the user would
have experienced otherwise.
If a field is hidden, changes caused by these
actions are ignored.
Note: These options are not used in the BMC
Remedy Mid Tier 6.3 and later.


Remedy client
User
Session Session Designates the number of minutes after which X
Timeout in a session times out. The default is 90 minutes.
Minutes You can set the session timeout for longer than
90 minutes for a specific user, and this setting
will override the session timeout in the General
Settings page of BMC Remedy Mid Tier
Configuration Tool.
Setting centralized preferences on web clients

Web client users can set preferences by opening the AR System User
Preference form and submitting changes. For information about the User
Preference form on the web, see the Installing and Administering BMC
Remedy Mid Tier guide.

Chapter
4 Defining your user base
This section provides instructions for managing information about your

AR System users. The following topics are provided:
Licensing users (page 104)
Viewing user information (page 105)
Releasing floating licenses (page 107)
License pools (page 108)
Adding and modifying user information (page 108)
Allowing guest users (page 113)
Special submitter mode (page 115)
Validating password information (page 116)
Setting up an authentication alias (page 116)
Unique user logins (page 122)
Defining your user base 103

Licensing users
When creating users, you must assign a license type to each user. The type of
license a user has determines the user’s ability to access AR System objects
and to perform tasks.
License types
There are four kinds of licenses you can use to access the AR System server:
read, restricted read, fixed write, and floating write. With the exception of
restricted read licenses, users can access AR System from only one IP address
at a time. After you have logged out of one machine, you might need to wait
a short time to make sure your status is cleared before using the same login
name to access another machine.
A user who is blocked from access can perform a license take-over through a
message dialog box. This was added to address instances where someone
forgets to log off a client at a different location. Only one license take-over is
allowed every fifteen minutes for all users on the system.
The following table summarize the important license elements as they relate
to access control.
License type Description

Read Enables users to search and display existing requests.
Administrators can configure the AR System server to enable
users to submit new requests and modify or save data in
existing requests. (See “Special submitter mode” on
page 115.)
Restricted Read Allows users to search the AR System forms and submit new
requests but does not allow users to modify existing requests
under any conditions. It does, however, allow the same login
account to access the AR System from multiple IP addresses
simultaneously, such as when browsing a knowledge base or
completing on-line surveys.
104 Chapter 4—Defining your user base

Configuring
License type Description

Fixed Write Includes all the capabilities of a Read license, and also
enables users to modify and save data for existing requests
based on the groups to which the user belongs. AR System
administrators and subadministrators must have a Fixed
Write license. Other AR System users who consistently need
to modify requests must also have Fixed Write licenses.
A user cannot be assigned the same Fixed Write license more
than three times in one week. If this limitation is exceeded,
the user must wait one week from the first assignment of the
Fixed Write license before it can be assigned again.
Floating Write Includes all the capabilities of a Read license, and also
enables users to modify and save data for existing requests
based on the groups to which the user belongs. Floating
Write licenses can be used by multiple users, one user at a
time. This type of license is designed for users who
occasionally need to modify and save data for existing
requests.
Viewing user information

The Manage User Licenses dialog box displays information about the
registered and current users on the selected server.
The registered user information displayed in the Manage User License
window is the information that was submitted for each user in the User form.
See “Adding and modifying user information” on page 108 for more
information.
Viewing user information 105

To display user license information

1 In the Server window, choose File > Licenses > Manage User Licenses to view
the Manage User Licenses Information window in BMC Remedy
Administrator.
Figure 4-1: License information
2 From the License Category option list, select one of the following options:
Server—Displays information about typical AR System licenses such as
AR System server, User licenses, and BMC Remedy Application licenses.
Application—Displays information about licenses for applications
created by ISVs (Integration System Vendors).
3 From the Category option list, select the appropriate license category:
Current licenses— For each user currently connected to AR System,
displays the name of the user, the type of AR System license assigned, the
connect time during the current session, the time that the user last
accessed the server during this session, and the floating write license pool.
Registered licenses—For all users known to AR System, displays the name
of the user, the type of AR System license assigned, the default notification
mechanism, and the email address.
4 To display all users for the selected licenses category, select the appropriate
license type from the menu.

Configuring
The Write License Pool column shows the name of the current group (pool)
from which the user’s Floating Write license has been acquired. At another
time, if a license has been acquired from a different pool to which the user
belongs, that pool name is displayed.
5 Click Close.
Releasing floating licenses

Users who work with a floating license are subject to a time-out interval,
which determines the amount of time before the floating license is released
automatically when the user does not perform any actions against the server.
Administrators can terminate a user’s session only one time in a 24-hour
period.
To release a floating license

1 In BMC Remedy Administrator, open the server window.
2 Choose File > License > Manage User Licenses to view the Manage User
Licenses window.
3 From the Category option list, select Current Licenses.
4 From the License Type list, select Floating.
A list of users with the selected license type appears.
5 From the list of active users, select the appropriate user.
6 Click Release User.
The license token held by that user is released. Another user can take the
token and start working. If the original user returns, the user will not be able
to get back into the system if no “tokens” are available.
Note: If you release a Fixed or Read license, this procedure removes the user
from the list of current users; there is no effect on the user’s ability to
connect to the server. The next time the user accesses the server, the user’s
license information reappears.
7 Click Close.
Releasing floating licenses 107

License pools
A license pool consists of a number of floating licenses reserved for a group,
subject to the number of floating licenses available in the database. When a
member of a group logs in, a license from the license pool for that group is
granted. When the user has finished with the license, it is released back into
the pool.
If there are no licenses available in the pool, a check is made to see if the user
is a member of any other group that has a license pool. If there are no licenses
available in any pool the user is a member of, a check is made for floating
licenses not associated with any pool. A user is never granted a floating
license from a pool of which he is not a member.
License pools allow you to give priority to a group that needs licenses more
urgently. The group with the smallest group ID has the highest priority.
When a non-reserved floating license becomes available, it is granted to the
next user who needs it, regardless of the priority of that user’s access to the
system.
You specify the number of licenses reserved for a group in the Group form in
BMC Remedy User. For more information about User groups, see the Form
and Application Objects guide and “Adding and modifying user information”
that follows.
Adding and modifying user information

In AR System, you can have registered users and guest users. Each type of
user has different privileges within the system, as is discussed in the following
sections.
You enter data in the User form to define the components that work together
to determine each user’s access to AR System: login name, password, group
membership, and license type. You also define alert information for each
user in this form.
To grant a user permission for AR System objects, add the user to the groups
to which access will be given. To make a user part of a group, choose the
appropriate group from the Group List menu in the User form. (Multiple
group names in the Group List field are separated by spaces.) You can select
from the reserved AR System groups. For more information about groups,
see the Form and Application Objects guide.

Configuring
Figure 4-2: User form in new mode
The following table lists the key fields in the User form.
Field Description
Login Name Identifying name that the user enters into the User Name field
when logging in to AR System. The name can be the same or
different than the user name by which this user is known to the
underlying operating system.
Password Identifying password that the user enters when logging in to
AR System. This field is limited to 29 characters.
The Password field is encrypted into the database using a one-way
hash (SHA1), so unauthorized users cannot retrieve passwords in
clear text, for example, to log in to applications. To enhance
system security, select a password that is different from one used
for another purpose.
If unsecure passwords are needed for applications, store the
password in a character field rather than the Password field
(field 102).
If the password field is left blank, the AR System server will not
validate the password with the user’s Windows or UNIX
password, unless you configure the server to cross-reference a
blank password. For more information, see “Server
information—Configuration tab” on page 132.
Adding and modifying user information 109

Field Description
Group List Lists the access control groups to which the user belongs. If you
leave this field empty, the user will have only basic Submitter,
Assignee, Assignee Group, or Public permissions. Specify groups
by name or ID, as defined in the Group form, when entering
groups in the Group list.
User permissions are determined in the Group List field of the
User form. If you later change the Group ID for a group, the users
originally assigned to the group are still attached to the old ID. If
there is no group with the old ID, these users lose access to any
AR System object for which they do not have permission through
another group.
This field is limited to 4000 bytes, including expanded strings.
Computed Displays the name of any computed group to which the User is a
Group List member. The members of a computed group are calculated by the
server based on the groups that the User belongs to. This is a
display-only field, and the field ID is 121.
To search in this field in a query-by-example, enter the ID
number of a computed group in the Computed Group List field.
In the following examples:
The ID for Computed Group 1 is 5678
The ID for Computed Group 2 is 6789
To enter more than one computed group ID, include semicolons
after each ID. You must enter the computed group IDs in the
same order in which the names appear in the Computed Group
List field when the user’s record is displayed.
You can also use the Advanced Search bar with the LIKE operator.
Include the semicolon with the complete ID.
To search for users who are members of Computed Group 1,
enter:
‘Computed Group List’ LIKE “%5678;%”
You can also enter a partial ID for the computed group. To search
for users who are members of both Computed Group 1 and
Computed Group 2, enter:
‘ComputedGroupList’LIKE“%56%”AND‘ComputedGroupList’LIKE
“%89%”

Configuring
Field Description
Full Name Full name of a user. By default, this name appears in the Results
pane of the User form when users perform a search operation.
License Type Type of license that the user is assigned: Read, Restricted Read,
Fixed, or Floating. The default is Read. See “License types” on
page 104 for further descriptions of these types.
Full Text For use with older versions of AR System server.
License Type
Default Notify Method by which the user is notified for Notify filter and
Mechanism escalation actions when User Default is specified. The default
setting on the User form is Alert.
Email Address Email address used to notify the user if email is the notify method.
Instance ID Field used with BMC Remedy Applications. Do not delete this
field.
Object ID Field used with BMC Remedy Applications. Do not delete this
field.
Application The name of the application and the appropriate license type. For
Licenses example, Help Desk User Fixed, where Help Desk is the name of
the application and User Fixed is the type of license.
Use the following procedures to create, modify, or delete AR System users

and to allow users to change their information.
You can apply the three Fixed Write licenses included with AR System to new
users.
To create new users

1 Log in to BMC Remedy User.
Enter your user name and password into the Login dialog box, and click OK.
If you are the first administrator to log in, you must log in as Demo and leave
the password field empty. (AR System user names are case-sensitive, which
means that you must type Demo, not demo or DEMO.)
During initial installation, the Demo user is installed without a required
password. To keep AR System secure, add a password for this user as soon as
possible.
2 Open the User form in New mode.
Adding and modifying user information 111

3 Enter information in the appropriate fields, as described in the previous

table.
4 Save your changes.
If adding the user causes you to exceed your license agreement, an error
message appears.
To modify user information

1 Open the User form in Search mode.
2 Choose Actions > Search to retrieve a list of currently defined users.
3 Select the appropriate user from the list.
4 Modify information in the appropriate fields.
WARNING: Do not modify the Demo user’s Fixed Write license or

Administrator group membership until you have created another
Administrator user first, or you will lose administrator privileges.
To delete users
4 Choose Actions > Delete.
A confirmation box appears to verify that you want to delete the selected
users.
5 Click OK.
WARNING: Do not delete the Demo user until you have created another
Administrator user first, or you will lose administrator privileges.

Configuring
To allow users to change user record information

1 In BMC Remedy Administrator, make the User form’s Assigned To field
visible. (By default, the field is hidden.)
a Double-click the Assigned To field to open the field Properties dialog box.
b In the Display tab, clear the Hidden check box.
2 In the User form, give the Assignee group Change permission for the
Password, Default Notify Mechanisms, or Email Address fields.
3 In the User form, give public “visible” permissions.
For information about defining field properties and field permissions, see the
Form and Application Objects guide.
5 Log in to BMC Remedy User as an administrator.
The Assigned To field is visible in the User form.
9 In the User form, copy the Login name to the Assigned To field to make the
user the Assignee.
By using the Assignee group, you allow the user to modify the user’s
password, default notification mechanism, or email address.
You can also make the user the Submitter by entering the same name in the
Login name field and in the Creator field.
Allowing guest users

AR System includes a setting that enables you to permit users who are not
recognized users (that is, not listed in the User form) to have access to BMC
Remedy User as a member of the Public Group. Allowing guest users can
involve as many as three settings, depending on whether you want the user
only to log in to BMC Remedy User or also to submit new requests and
modify existing requests for which the guest user is the original submitter.
Allowing guest users 113

To allow guest users

1 In BMC Remedy Administrator, select a server to administer.
3 Click the Configuration tab.
4 Select the Allow Guest Users check box.
The guest user can log in to BMC Remedy User and access all the AR System
objects for which the Public group has permission.
5 Click OK.
6 To allow the guest user to create new requests, complete the following steps
for each field in which you would expect a value to be supplied:
a Open the form in BMC Remedy Administrator.
b Double-click the field to open the Field Properties window.
c Click the Permissions tab.
d Select the Allow Any User to Submit check box.
The guest user can assign a value to the field even though the guest user
does not belong to a group with Change permission for the field.
e Save your changes.
7 To enable guest users to modify an existing request for which they are the
submitter (in the Submitter field), complete the following steps:
a Choose File > Server Information.
The Server Information window appears.
b Click the Licenses tab.
c From the Submitter Mode option list, select Locked.
The guest user can modify all existing requests, where the guest user is the
original submitter, without a write license for fields that have Change
access for the Submitter group. For more information about the special
submit setting, see the “Special submitter mode” on page 115.
d Click OK.
e Restart the AR System server.

Configuring
Special submitter mode

AR System contains a setting that allows users to modify requests that they
initially submitted even if they do not have a write license. To enable this
feature, set the Submitter Mode option to Locked in the Licenses tab of the
Server Information dialog box, and then restart AR System server.
Figure 4-3: Setting Submitter Mode in Server Information dialog box
Set Submitter
Mode to Locked.
The Submitter Mode options are:

Locked—Allows users who have their name in the Submitter field to
modify requests without a write license. This does not apply to users with
a Restricted Read license who cannot modify requests under any
circumstances. In the locked submitter mode, after the entry is submitted,
the value in the Submitter field cannot be changed.
Changeable—Requires users to have a write license to change any record,
including requests for which they are the submitter.
Special submitter mode 115

Validating password information

The AR System server can validate the password entered by the user against
their Windows or UNIX login password instead of maintaining a password
that is AR System specific. To allow this, you must:
Make sure that the AR System user name and the operating system user
name are identical. Leave the Password field in the User form blank. (See
the column “Field” on page 109.)
In BMC Remedy Administrator, select the Cross Ref Blank Password
check box in the Configuration tab of the Server Information dialog box.
(For more information about password configuration, see “Server
information—Configuration tab” on page 132.)
Where supported, the operating system password validation feature enables
the operating system to set the following password policies (which are not
covered by the AR System password manager):
Aging—Determines how quickly a password expires.
Lockout periods—Limits the number of incorrect logins a user can enter
before getting locked out.
Length—Sets a consistent password length.
Setting up an authentication alias

An authentication alias allows you to use an alternate user name (User Name
Alias) or an authentication string (Authentication String Alias) when the
operating system or an AR System external authentication (AREA) plug-in is
performing the authentication. The User Name Alias and the Authentication
String Alias operate independently of one another, so you can use both or
either one alone.
User Name Alias

A User Name Alias is a secondary account name associated with a user and is
only for authentication purposes. The user's primary account name (the
login name) entered into the User Name field of the Login dialog box of
AR System clients, is used for all other purposes. If a User Name Alias is
defined, the AR System server will use it to authenticate the user and
password.

Configuring
The User Name Alias is applicable in the following situations:

When you want the user’s full name to be used as the AR System login
instead of the user’s computer account name. The system uses the alias
when authenticating the user.
When a user’s name changes, that user can log in to the AR System using
the new name but continue to use the same computer account name for
authentication purposes.
When a user’s computer account or domain name is subject to changes.
Leveraging an alias allows the user to continue using the same user name
to log in throughout the changes.
Configuring the User Name Alias

To configure a User Name Alias, add a character field to the User form in
BMC Remedy Administrator and name it Authentication Login Name. The
information in this field is accessed when the user logs in to an AR System
client and the following conditions apply:
Cross-Reference Blank Password is configured on the AR System server
(see “Cross Ref Blank Password” on page 165).
The Password field on the User form is empty.
One of the following external authentication methods is used:
An AREA plug-in
A Windows Domain server (when the AR System server is running on
a Windows platform)
A UNIX password resolution (when the AR System server is running
on a UNIX platform)
Setting up an authentication alias 117

Figure 4-4: Login dialog box
Relates to the value

in the
Authentication
Login Name field on
the User form.
The Authentication Login Name field on the User form interacts with the
User Name field in the Login dialog box according to the following rules:
If the Authentication Login Name field is present on the User form, the
value contained in this field is used for authentication instead of the name
entered in the User Name field in the Login dialog box.
For backwards compatibility, if the Authentication Login Name field is
not present on the User form, or the value in this field is NULL, then the
user is authenticated with the information entered in the User Name field
in the Login dialog box.
These rules apply to all AR System clients, including those accessing an
AR System server using C or Java APIs.
Properties of the Authentication Login Namefield on

the User form
In BMC Remedy Administrator, set the properties of the Authentication
Login Name field as shown in the following table:
Field Property Field
Name Authentication Login Name
Field ID 117
Data Type Character
Database Length 30

Configuring
You can set any permissions, including whether the values are optional or
required. You can also create workflow to populate and validate the values in
this field.
Important: Caution is recommended when setting permissions. Typically,

the values in this field should be set only by an administrator, or by using
workflow.

Authentication String Alias

When an Authentication String Alias is defined, it overrides any entry in the
Login dialog box of the AR System client. The Authentication String Alias
can be used to identify the correct authentication domain for the user.
Use the Authentication String Alias in the following situations:
When users belong to specific authentication domains and you do not
want to require users to enter an authentication string when they log in.
When a user’s computer account or domain name is subject to changes.
Leveraging an Authentication String Alias allows the user to continue
using the same user name to log in throughout the changes.
Configuring the Authentication String Alias

To configure an Authentication String Alias, add a character field to the User
form in BMC Remedy Administrator and name it Authentication String. The
information in this field is accessed when the user logs in to an AR System
client and the following conditions apply:
Cross-Reference Blank Password is configured on the AR System server
(see “Cross Ref Blank Password” on page 165).
The Password field on the User form is empty.
One of the following external authentication methods is used:
An AREA plug-in
A Windows Domain server (when the AR System server is running on
a Windows platform)
A UNIX password resolution (when the AR System server is running
on a UNIX platform)

Configuring
Figure 4-5: Login dialog box
Relates to the value in

the Authentication
String field on the User
form.
The Authentication String Alias field on the User form interacts with the
Authentication field in the Login dialog box according to the following rules:
The value in the Authentication String field on the User form is used
instead of the entry in the Authentication field in the Login dialog box.
For backwards compatibility, if the Authentication String Alias field is not
present on the User form, or the value in this field is NULL, then the
information entered in the Login dialog box is used for authentication.
These rules apply to all AR System clients, including those accessing an
AR System server using C or Java APIs.
Properties of the Authentication String field on the User

form
In BMC Remedy Administrator, set the properties of the Authentication
String field as shown in the following table:
Field Property Field
Name Authentication String
Field ID 118
Data Type Character
Database Length 255
You can set any permissions, including whether the values are optional or
required. You can also create workflow to populate and validate the values in
these fields.

Important: Caution is recommended when setting permissions. Typically,

the values in this field should be set only by an administrator, or by using
workflow.
Unique user logins

In AR System 6.3, it was possible to have multiple users with the same user
name but different passwords log in at the same time.
AR System 7.0 does not allow multiple users with the same user name if you
use the User form for authentication. If, however, you use external
authentication, multiple users with the same user name can log in only if they
belong to the same groups. (In the cache, only one session is created, and this
session will be used for both users.)
If you are upgrading to AR System 7.0 from a 6.3 system where you allow
multiple users with the same user name but different passwords, the
AR System upgrade scripts will fail and will generate a message suggesting
that you correct the multiple user name problem.

Chapter
5 Configuring servers and clients
This section discusses configuring servers and client to work with AR System.
Configuring AR System servers (page 124)
Configuring a server for development or production cache mode
(page 178)
Configuring multiple servers (page 179)
Running a stand-alone AR System server on Windows (page 194)
Configuring firewalls with AR System servers (page 195)
Configuring clients for AR System servers (page 196)
Configuring a server to use plug-ins (page 197)
Configuring the AR System server for external authentication (AREA)
(page 199)
Configuring a mail server (page 202)
Configuring a server for alerts (page 202)
Configuring and using the AR System Server Administration plug-in
(page 204)
For information about the mid tier and BMC Remedy Mid Tier
Configuration Tool, see the Installing and Administering BMC Remedy Mid
Tier guide.
Configuring servers and clients 123

Configuring AR System servers

Every AR System server has a variety of configuration settings that control
how the server works and how it interacts with users. Configuration settings
are specific for each server.
Use the Server Information dialog box in BMC Remedy Administrator to
display information about the currently selected server and to set server
options. You must be an administrator to make changes in this dialog box.
The Server Information dialog box includes both display-only fields and
fields in which you can set options. If you do not set an option for a field, the
default value applies.
The following table lists the tabs in the Server Information dialog box. The
information provided in each tab is described in the sections that follow.
Although we strongly recommend that you use BMC Remedy Administrator
to change server settings, you can change settings manually in the server
configuration file (ar.cfg for Windows or ar.conf for UNIX).
Tab Information Section

Platform Displays information about the “Server information—
platform on which the selected Platform tab” on
server is running. page 126
Timeouts Sets various timeouts for the “Server information—
currently selected server. Timeout tab” on
page 128
Licenses Displays the type and number of “Server information—
AR System licenses on a server. You Licenses tab” on
also set the Submitter Mode in this page 130
tab.
Configuration Sets configuration options. “Server information—
Configuration tab” on
page 132
Log Files Sets debugging modes for the “Server information—
system. Log Files tab” on
page 141
124 Chapter 5—Configuring servers and clients

Configuring
Tab Information Section

Database Displays information about the “Server information—
database that the selected server Database tab” on
communicates with. You also define page 146
a database password and
configuration file location in this
tab.
Server Ports and Configures AR System to “Server information—
Queues communicate with client tools, Server Ports and Queues
services, and other servers on the tab” on page 149
network. Displays information
relevant to the user of the multiple
threads in the AR System server.
Connection Enables you to configure passwords “Server information—
Settings used between the AR System server Connection Settings
and its external subsystems. tab” on page 154
Currency Types Specifies currency types available in “Server information—
AR System. Currency Types tab” on
page 159
External Sets parameters necessary for “Server Information—
Authentication AR System to authenticate users to External Authentication
external systems. tab” on page 162
Advanced Sets parameters related to “Server information—
AR System efficiency, security, Advanced tab” on
localization, and server statistics. page 167
Source Control Sets source control integration “Server information—
within AR System. Source Control tab” on
page 171
Server Events Sets the options for logging internal “Server information—
server changes. Server Events tab” on
page 176
Configuring AR System servers 125

Server information—Platform tab

Use the Platform tab to view information about the platform on which the
selected server is running.
To display platform information about the currently selected server

1 Open the server window.
2 Select a server to administer.
4 Click the Platform tab.
Figure 5-1: Server Information window—Platform tab

Configuring
5 Edit the options, as needed:
Field Description
Server Version Displays the version number of the AR System software on the
server. This value corresponds to the $VERSION$ keyword.
Server Displays the folder (directory) where the AR System server is
Directory installed on the server system.
Hardware Displays the hardware platform on which the server is running.
This value corresponds to the $HARDWARE$ keyword.
Operating Displays the operating system software version running on the
System server system. This value corresponds to the $OS$ keyword.
Server Name Defines an alias that is always interpreted as the current server.
Alias An alias allows you to use a functional name for a server rather
than a machine name (for example, ACME or HelpDesk). Do not
enter a fully qualified domain name. An alias makes it easier to
move workflow between machines.
Entering an alias in this field does not automatically assign an
alias to the server. The network environment must reflect a
change to the server name before entering the alias name in this
field. The alias name must be a valid host name on your network.
Accordingly, you might need to update DNS, your host files, NIS,
and so on.
After you make all your changes to the server environment, users
can log in to BMC Remedy User using the new server alias, just
like any other server name.
See your network operating system documentation for
information about creating an alias for the server.
Server Time Displays the current time on the server (in the local time zone).
6 Click Apply.

Server information—Timeout tab

Use the Timeouts tab to set the timeouts for the currently selected server.
To set timeouts
4 Click the Timeouts tab.
Figure 5-2: Server Information window—Timeouts tab

Configuring
Group Name Field Name Description

Process Timeout Prevents a server from being blocked when a process requested
(seconds) in a Set Fields filter or escalation action does not return a value
soon enough. The server waits a specified interval and then
returns with a $NULL$ value even if the process has not been
completed.
Enter a number from 1 through 60 seconds. The default is 5.
Specifying long intervals can cause an increase in response time
for users.
Alert Send Sets the time limit (in seconds) allowed for making contact with
Timeout (seconds) alert clients. Two attempts are made to deliver an alert and if the
second attempt fails, the alert registration is removed. The
default is 7 seconds.
Filter API RPC Sets the time limit (in seconds) allowed for the Filter API RPC
Timeout (seconds) to respond to the server’s request. The default is 60 seconds. The
minimum is zero (0), the maximum is 300.
Floating License Write Sets a time limit (in hours) for how long a Floating Write license
Timeout (hours) remains reserved if the user is not accessing AR System.
When using Floating Write licenses, a “token” is reserved while
the user is connected to the server. If the user does not perform
an AR System operation for the period of time specified in this
field, the license is automatically released back to the pool of
available licenses. The client tool must acquire a license for the
user again when the next licensable operation occurs.
Enter a number from 1 through 99 hours. The default is 2.
Full Text Search For use with older versions of AR System server.
Currency Ratio Client Refresh Sets the interval (in minutes) that clients (for example, BMC
Cache Refresh Interval Remedy User and the Web) use when refreshing currency
Interval (minutes) conversion ratios stored on the server. This refresh action makes
sure that calculations for functional currencies are up to date.
6 Click Apply.

Server information—Licenses tab

Use the Licenses tab to display information about the type and number of
AR System licenses on a server. You can also set the Submitter Mode in this
tab.
To display server license information and set the submitter mode

4 Click the Licenses tab.
Figure 5-3: Server Information window—Licenses tab

Configuring

Server License Type Displays the license type of the server.
Fixed Write Displays the total number of Fixed Write licenses on the
Licenses server.
Floating Write Displays the total number of Floating Write licenses on the
Licenses server.
Fixed Full Text Displays the total number of Fixed Full Text Search licenses.
Licenses
Floating Full Text Displays the total number of Floating Full Text Search
Licenses licenses.
Max Forms Allowed Displays the number of forms your license allows you to
on Server create on the server. If this field reads Unlimited, you can
create as many forms as you want.
AR System Displays the AR System identifier code attached to the server
Server ID license.
Submitter Mode Defines the conditions under which submitters can modify
the requests they initially submit (that is, where their names
are in the Submitter field). Choose one of the following
options:
Locked—Users can modify requests they submit without a
write license. This does not apply to users with a Restricted
Read license who cannot modify requests under any
circumstances. In the locked submitter mode, after the
entry is submitted, the value in the Submitter field cannot
be changed.
Changeable—(Default) Users must have a write license to
modify requests.
Note: Changes to the Submitter Mode settings do not take
effect until the server is stopped and restarted.
6 Click Apply.

Server information—Configuration tab

Use the Configuration tab to set administrative options.
To set configuration options

Figure 5-4: Server Information window—Configuration tab

Configuring

Users Prompted Defines the login procedure for BMC Remedy User. The
for Login options are:
By Preference—(Default) Users can select which of the two
login options they prefer in BMC Remedy User. For more
information, see BMC Remedy User help.
Once Only—Users must log in to BMC Remedy User only
the first time they start the application. User and password
information is stored in the Windows registry.
Always—Users must log in to BMC Remedy User every time
it is started. No user or password information is stored in the
user registry.
If you select Once Only or Always, the Always Prompt for
Login preference in BMC Remedy User is disabled and the
user must comply with the option selected here. If a user
accesses servers with different login settings, the login
requirements for the strictest server are enforced.
You cannot specify this setting for BMC Remedy Alert.
Max Entries Limits how many database entries are returned from a search.
Returned by For example, setting the maximum entries to 50 would return
GetList a maximum of 50 entries, even if more entries satisfied the
search qualification. The AR System warns users that the
search matched more entries than the administrator allows to
be retrieved. If users specify a maximum in their preferences,
the lesser of these two values is used. A value of zero (0)
specifies no limit (the default).


Server Table Field For server-side table fields, this number determines the
Chunk Size number of entries (or size of the chunk) that the server
retrieves at one time from the database and stores in-memory
to process during filter or filter guide actions. The server then
retrieves, stores, and processes the next chunk until all the
rows have been processed. Entering a value of zero (0) causes
the server to retrieve an unlimited number of rows. The
default is 1000 rows.
Entering a low value in this field causes the server to process
smaller chunks, which keeps the server memory usage down,
but results in slower processing because the server needs to
access the database many times, especially for large tables.
Entering a high value causes the server to retrieve and process
large chunks of data and access the database fewer times. This
results in higher performance at the cost of memory use.
Server Language Displays the language and character set of the machine on
which the server is running.
User Email Identifies the sender of email notifications.
Notifies From The default sender for email notifications is ARSystem. To
specify another user name, enter that name in this field. The
name must match the name you use in the AR System Email
Configuration Form for notifications. For more information
about configuring a mailbox for notifications, see the
Administering BMC Remedy Email Engine guide.

Configuring

Minimum API Specifies the oldest API version with which the server will
Version communicate.
The corresponding API and AR System versions are as follows:
API 12 and AR System 7.0
API 4 and AR System 3.0 and 3.1
If you set the minimum API version to 12, clients prior to
version 7.0 will not be able to communicate with the
AR System 7.0 or later server. If you set the API version to 0 or
none, all clients will be able to communicate with the server.
For information about setting passwords to increase security,
see “Server information—Connection Settings tab” on
page 154.
Max Number of Enter the maximum number of consecutive bad password
Password attempts a user is allowed. If you enter 3, the user has 3 chances
Attempts to log in. If all 3 attempts have bad passwords, the user account
will be marked as INVALID.
The allowed values for this field are 0 and all positive integers.
A value of 0 turns feature off. This setting can also be set with
the Max-Password-Attempts option in the ar.conf
(ar.cfg) file.


Next Request ID Enter a positive number (up to 1000) to allocate NextIDs in
Block Size blocks rather than one at a time. Allocating in blocks increases
performance during a create operation.
The default value is 1. If 0 or a negative number (for example,
-1) is used, the server will use the default value of 1.
You do not need to restart the server for the change to take
effect. The option is started immediately.
Warning: The use of this configuration setting might result in
unpredictably large NextID sequence gaps. The likelihood of
this occurring increases with the use of multiple servers that
share a database. The AR System server will not malfunction
due to this gap and should not be considered a defect.
Default Home Enter the path to a Home Page to be used system wide as the
Form default home page for this server when a user logs in.
This default Home form is only used if one of the following
statements is true:
This server is designated as the server for the Home Page in
the AR System User Preference form.
This server is designated as the server on the Home Page
Settings page in BMC Remedy Mid Tier Configuration
Tool. See the Installing and Administering BMC Remedy Mid
Tier guide for more information.
No Home Page is specified in the AR System User
Preference form. (You can also set this in the Options dialog
box in BMC Remedy User.)
Note: If the Home form is deleted, this field is cleared and you
must re-enter a default Home Page.

Configuring

Allow Guest Users Defines whether AR System permits access to guest users, who
are not registered users of the system, to log in.
If the check box is selected (the default), guest users can log in
and perform the following tasks:
View all forms and fields for which the Public group has
Visible permission.
Execute all active links for which the Public group has
permission.
View all fields for which the guest user is the submitter or
assignee, if the Submitter Group or Assignee Group has
View permission for the field.
Submit new requests if the fields on a form have the Allow
Any User to Submit check box selected, as described in the
Modify all fields for which the guest user is the submitter, if
the Submitter Group has Change permission for the field
and if the Submitter Mode is Locked, as described in “Server
information—Licenses tab” on page 130.
Give Guest Users Defines whether guest users will receive a restricted read
Restricted Read license when they log in to AR System. If this option is not
selected, guest users will receive a read license.
Allow Unqualified Defines whether the server accepts unqualified searches
Searches (searches for which no search criteria are specified). If the
check box is:
Selected—(Default) All database searches are allowed.
Cleared—You force users to enter a search criteria when
performing queries.
Note: Consider restricting unqualified searches to prevent the
performance penalty of retrieving and returning large
blocks of data due to accidental, unqualified searches to the
database.


Administrator- Enables you to allow only administrators and
Only Mode subadministrators to access AR System. Users who are not
administrators or subadministrators cannot perform any
AR System operations. This is useful during system
maintenance.
By default, this option is not selected.
Administrator-Only Mode can be set by administrators only,
not subadministrators. After an administrator sets this option,
subadministrators can access only forms for which they have
permission.
Disable Archive Disables the archive operations on the server. You can disable
one server operating with one database, but in the case of
multiple servers attached to the same database, you can disable
all servers except one to prevent conflicts.
For more information about archiving, see the Form and
Application Objects guide.
If the Server Groups check box is selected, this setting is
ignored. Server groups can be configured in the AR System
Server Group Operation Ranking form to make sure that only
one server performs the operation. See “Running servers as
part of a group” on page 185.
Development Enables a cache mode that is optimized for developing
Cache Mode applications and where user operations might be delayed
when changes are made to forms and workflow.
If the check box is not selected (the default), development
cache mode is disabled, and the server is operating in
production cache mode.
For more information, see “Configuring a server for
development or production cache mode” on page 178.

Configuring

Disable Admin Disables certain operations performed only by administrators
Operations and subadministrators, which enable you to control changes
to the database by disabling administrator operations. You can
disable one server operating with one database, but in the case
of multiple servers attached to the same database, you can
disable all servers except one to prevent conflicts. If the check
box is:
Selected—Administrators cannot perform operations that
affect the server’s data dictionary.
Cleared—(Default) Administrators can perform their usual
operations including all data dictionary restructuring
operations.
Disable Enables you to stop escalations being run on the server. You
Escalations can disable one server operating with one database, but in the
case of multiple servers attached to the same database, you can
disable all servers except one to prevent conflicts.
Disable Alerts Enables you to prevent alert messages from being sent to users
when an alert event is entered in to the system. No threads will
run in the Alert Queue. This setting is acknowledged only at
startup, so any changes will not take effect until the server is
restarted.


Verify Alert Users This indicates whether the server needs to check its list of
registered alert clients to determine if they are listening and
ready to receive alert messages. As this setting is acknowledged
only at server startup, any changes will not take effect until the
server is restarted. Selecting this option can result in a large
amount of network activity at server startup. If the check box
is:
Selected—The server will verify the list of clients. If the
clients are not listening, they will be removed from the list of
registered clients.
Cleared—(Default) The server will not perform the
verification.
Regardless of the setting, if a subsequent alert message is sent
to a client that is not listening, they will be removed from the
list of currently registered clients at that time.
Enable Multiple Allows multiple roles, groups, and user names to be stored in
Assign Groups the row-level security Assignee Group field (ID 112) and in
dynamic group fields (ID 60000-69000). This enables multiple
users, or users from multiple groups, to access the same entry
(as in the sample qualification,
'Assignee Group' = “;50;51;-90;’Mary Manager’;”).
If the check box is not selected (the default), only one role,
group, or user name can be stored.
Server Group A flag that indicates whether the server is a member of a server
Member group.
Disallow Non Select this check box to restrict server access to Unicode-safe
Unicode Clients clients.
Note: This option applies to all BMC Remedy clients except
for BMC Remedy Administrator and BMC Remedy Alert.
Note: This check box is visible only for AR System 7.0 servers
or later. Also, for 7.0 servers, if the server uses a
non-Unicode database, the check box will be disabled.
6 Click Apply.

Configuring
Server information—Log Files tab

Use the Log Files tab to set one or more of the debugging modes shown in
Figure 5-5 on page 142. In debug trace mode, AR System creates log files
containing information about system activity.
After being activated, logging starts immediately. You can activate logging at
any time.
WARNING: Do not keep logging turned on continuously. Log files can

consume increasing amounts of disk space as messages accumulate unless
you limit the log file size. Monitor your disk resources carefully while
logging is active.
You can enter a location other than the default location (<ar_install_dir>/
db on UNIX and <ar_install_dir>\Arserver\Db on Windows), and a
name for each of the log files created in debug mode. You can also specify the
same location and file for multiple types of logging to write all the data logged
to a single file.
Note: You can also set debug modes for active links, macros, API calls,
databases, and filters in BMC Remedy User through the Logging tab in the
Options dialog box. When a check box is selected, a log file with the name
specified in the Log File Path will contain all logging information. The file
is stored in the default folder (for example, \Home) unless you change it.
You can also use the log information to analyze the active links used in
guides. Log files are enabled in BMC Remedy User because that is where
active links and macros run.
For more information about the debug trace modes and log files, see the
Optimizing and Troubleshooting guide.
To set log files

4 Click the Log Files tab.

Figure 5-5: Server Information window—Log Files tab
5 Select the check box next to each appropriate debug trace mode.
You can select all, some, or no log files. The File Name field is disabled until
you select the related check box. After you select a logging mode, you can
specify a different file name.

Configuring
Important: When naming log files, do not use special characters (such as a
forward slash (/) or a question mark (?). Use alphanumeric characters
only.

API Logs information about all API calls made by all clients.
Information is logged on entry and exit of every API call. The
default log file name is arapi.log.
Distributed If you are licensed for the Distributed Server Option, logs
Server information about distributed server activity. Information
includes the distributed operations that were attempted and
whether the operation was successful. The default log file name
is ardist.log.
Escalation Logs information about escalation activity. Information
includes the escalations that executed, whether the escalation
qualification found any matches, and any escalation actions
taken. The default log file name is arescl.log.
Filter Logs information about filter activity for each operation.
Information includes the filters that attempted to execute and
all filter actions performed. The default log file name is
arfilter.log.
SQL Logs SQL commands sent to the database. Information is logged
for each SQL command issued, including a time stamp and the
user name of the user performing the operation. The default log
file name is arsql.log.
Thread Logs information about threads that are being started and
restarted on the server. The default log file name is
arthread.log.
User Logs information about connection activity for each user.
Information includes whether the user is able to obtain a
license and when each floating license is released. This enables
you to keep an audit trail of user activity to help you determine
if you need more floating licenses. The default log file name is
aruser.log.
Alert Logs detailed information about user registration and on the
generation and delivery of alerts. The default log file name is
aralert.log.


Plug-In Server Logs the events of plug-ins that AR System uses. The default log
file name is arplugin.log. For more information about using
plug-ins, see the C API Reference guide.
ARFORK On UNIX systems, logs all arforkd activity (a process that
(UNIX only) reduces the amount of memory an AR System server uses when
forking new processes). This file is not subject to the maximum
file size specified in the Maximum Log-File Size field.
Server Group Logs information about server group activity. Records
information about the starting and stopping of operations, the
evaluation of other servers, and the timing of each event.
Full Text Search Logs information about full text search indexer activity. The
default log file name is arftindx.log.
6 Specify the level of logging for the plug-in server.
Plug-in logging Description

level value
Off No log information printed.
Severe Only severe messages are printed.
Warning Severe and warning messages are printed
Info Status, severe, and warning messages are printed.
Config Configuration, status, severe, and warning messages
are printed.
Fine Internal exceptions.
Finer Trace logs that log tasks as they are executed within the
system.
Finest Code-level information.
All All log information is printed.
7 From the Log-File Creation field, choose one of the following options:
Create Backup—Creates new log files, and the contents of the previous log
files are written to <logname>.bak files.
Append to Existing—Log files and their contents are preserved, and new
information is appended to them.

Configuring
8 From the Client-Side Logging Group list, select the group that will be able to
use logging options in AR System clients. Logging options are disabled
(grayed out) for users who are not members of this group.
For more information about the client logging, see the Optimizing and
Troubleshooting guide.
9 In the Maximum Log-File Size field, enter the maximum size (in bytes) for
the log file.
A value of 0 (the default) specifies no limit. Except for 0, the log file size
cannot be set to less than 4096 because that could be the length of one single
log line.
When the log file reaches the maximum, new information wraps to the top
of the file, overwriting the old information. If you do not specify a maximum
size limit, you run the risk of running out of disk space on your system.
This setting does not apply to the arforkd.log file.
10 Select the logging options.
Select the Buffer Logged Lines option to buffer logged lines instead of
having them immediately written to disk.
Select the Log Per Thread option to create per-thread log files.
Selecting these options decreases the impact to AR System performance
when logging is enabled. For more information, see the Optimizing and
Troubleshooting guide.
11 Click Apply.

Server information—Database tab

Use the Database tab to view and configure information about the database
that you are using.
To display and update information about the database

4 Click the Database tab.
Figure 5-6: Server Information window—Database tab
The information displayed on this tab varies depending on the relational

database you have installed.

Configuring

Database Type Displays the type of database that the AR System server is
using.
Database Home (For UNIX only) Displays the directory path of the underlying
database that the AR System server is using.
Database Name Displays the name of the database created for AR System
within the underlying database server.
Database Version Displays the version of the database that the AR System server
is using.
Database User Displays the user name that AR System uses to access the
Name database.
Database (For Sybase, Oracle, Microsoft SQL Server, or DB2 databases
Password only) Enables you to define the password used by AR System
for access to the database. The existing password is not
displayed.
Enter a value in the Database Password field to change the
password.
The default database password created by AR System is
AR#Admin#. If you changed the password and do not
remember it, or if you have changed it outside of AR System
and need to reflect the change within AR System, log in to the
database as the database administrator and change it back to
the default. If the encrypted password is in the ar.conf
configuration file, delete it from there.
Database Displays the contents of the ardb configuration file used by the
Configuration advanced AR System feature that appends clauses to the SQL
File statements that create tables and indexes.
For more information about the ardb file, see Appendix B,
“AR System configuration files.”


Request ID Uses (For Microsoft SQL Server, Sybase, and DB2 databases only)
Clustered Index Indicates whether AR System will create the Request ID field as
a clustered index to boost performance.
By default, the check box is selected.
Store CLOB In- (For Oracle databases only) Defines the Oracle CLOB storage.
Row The default value of this setting is F, and new CLOBs will be
“out row.”
If the setting is set to T, all CLOBs to be created are “in row.”
6 Click Apply.

Configuring
Server information—Server Ports and Queues tab

Use the Server Ports and Queues tab to set server ports and RPC numbers as
needed to communicate with other servers, clients, and services on the
network. The Server Queue region on this tab allows you to configure server
queues and threads as appropriate for your server, taking advantage of the
multithreaded design of AR System.
Assigning TCP port numbers to AR System servers

You assign one TCP port number for the AR System server. All initial contact
with the server is through a single port. If you run multiple servers on the
same machine, each server must use a unique port.
Clients must be configured with the server port number to enable server
access without the use of a portmapper. If you do not allow the server to
register with a portmapper, you must assign a TCP port number for the
AR System server. For more information about configuring clients, see
“Configuring clients for AR System servers” on page 196.
Do not assign port numbers that conflict 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 one of the following commands at the
command-line prompt:
UNIX—rpcinfo -p
Windows—netstat -a
If you do not check available ports, you might assign port numbers that
conflict with other applications, and your servers might not start as expected.
Client tools can use ports 0–65535.
On UNIX, port numbers within the range 1–1024 are available only for use
by the superuser, and many of these numbers are reserved.
To set server ports and queues

4 Click the Server Ports and Queues tab.

Figure 5-7: Server Information window—Server Ports and Queues tab

Configuring
5 Edit the options as needed:

Server TCP/IP Port Defines the TCP/IP port number for the AR System server.
Allows clients to have access to the server without a
portmapper.
When set to zero (0), which is the default, the port is
assigned by the portmapper.
Note: If you set the Server TCP/IP Port field to a value less
than 1024, older clients will not be able to connect. For
older clients, choose a value greater than 1024.
Distributed Server Enabled if you have BMC Remedy Distributed Server
RPC Program Option (DSO). Specifies the default RPC program number
Number for the AR System server queue used by distributed servers.
This enables you to direct DSO traffic to private queues. For
more information, see the Administering Remedy DSO
guide.
Alert Outbound The specific TCP port to which the server binds when
Port sending alert messages to registered clients. If multiple alert
threads are started, the number represents the starting port
number in a consecutive range of numbers available for use
by the alert threads. If no port number is specified, or if zero
(0) is entered, the server is randomly assigned an available
port by the portmapper.


Register with If the check box is:
Portmapper Selected—The AR System server and the plug-in server
are registered with AR System Portmapper. The server is
registered immediately if not previously registered.
AR System clients can get the port number of the
AR System server and the plug-in server from AR System
Portmapper.
Cleared—The AR System server and the plug-in server
are not registered with AR System Portmapper. If the
server was previously registered, this option removes the
registration. AR System clients cannot get the port
number of the AR System server and the plug-in server
from the portmapper.
If you are running multiple servers on a single machine, you
can select the Register with Portmapper option for one
server only.
Server Queue Enables you to define server queues specific to your needs.
Click the Type column and choose the type of server queue
(private, fast, list, or alert) from the list.
If you select a private server queue, click the RPC Program
Number column to choose an RPC program number from
the list. Fast, list, and alert server queues are automatically
assigned a default program number.
For most types of server queues, you can specify a minimum
and maximum number of threads. If you do not specify a
number, the system defaults to one minimum and one
maximum thread per server queue.
For more information, see “Defining queues and
configuring threads” on page 153.
6 Click Apply.
7 Restart the server for the changes to take effect.
Note: To change the port number that the AR System server uses when
communicating with the plug-in server, you must edit the Plugin-Port
option of the ar.cfg (ar.conf) file, and restart the server. For more
information, see “Plugin-Port2” on page 332.

Configuring
Defining queues and configuring threads

All servers include an Admin queue; it is the default server setting and cannot
be configured. The Admin queue can have only one thread at any time.
When you define additional server queues, AR System automatically assigns
corresponding RPC program numbers or provides ranges of RPC program
numbers, and you define the minimum and maximum number of threads
for each alert, fast, list, and private server queue that you are using. To add
server queues and configure threads, perform the following procedure.
To add server queues and configure threads

1 In BMC Remedy Administrator, select a server and choose File > Server
Information.
The Server Information dialog box appears.
2 In the Server Information dialog box, click the Server Ports and Queues tab.
Figure 5-8: Entering server queue information
3 In the Server Queue box, click in the Type column. When the list appears,
choose a Fast, List, Alert, or Private server.
If you select a Fast server, the RPC Program Number 390620 is
automatically assigned.
If you select a List server, the RPC Program Number 390635 is
automatically assigned.
If you select an Alert server, the RPC Program Number 390601 is
automatically assigned. If an Alert server is not specified, the Alert Queue
automatically starts one thread.
If you select a Full Text Indexer server, the RPC Program Number 390602
is automatically assigned.

If you select a Private server, a list appears in the RPC Program Number
column. Choose an RPC program number from the following ranges:
390621–390634, 390636–390669, 390680–390694.
4 In the Min Threads field, enter the minimum number of threads that you
want started at startup.
The default is 1.
5 In the Max Threads field, enter the maximum number of threads that your
system will be allowed to start.
The default is 1. When all the existing worker threads are in use, the system
starts additional threads as needed until the maximum number is reached.
These additional threads remain active until the server is rebooted.
6 Click Apply.
Note: If you have removed a queue or decreased the maximum number of

threads for a queue, restart the server for the changes to take effect.
Server information—Connection Settings tab

The Connection Settings tab enables you to add an extra layer of security by
configuring connection settings for the AR System Application Service, the
Mid Tier Service, Plug-In Service, and by both remote and local Distributed
Servers (if DSO is installed).
To set connection settings

4 Click the Connection Settings tab.

Configuring
Figure 5-9: Server Information window—Connection Settings tab
Tab Name Field Name Description

Application Service Specifies the password that AR System application services
Password (such as AR System Approval Server) will use to access the
AR System server.
Asterisks in the field indicate that a password has been
defined.
If you are running a 7.0 server, you must enter a password.
Mid-Tier Specifies the password that the mid tier will use to access
Administration the AR System server.
Password If you are running a 7.0 server, you must enter a password.


Proxy server settings Used in the Web Services feature when you are configuring
for Java VM a plug-in with Internet access through a proxy server. Enter
the following text in this field:
-Dhttp.proxySet=true
-Dhttp.proxyHost=<host_name>
-Dhttp.proxyPort=<port_number>
Plug-In Server Local Password Sets a plug-in server password, if applicable.

If this option is specified, arplugin will accept
connections only from AR System servers that have been
configured to use the same password set in the Plug-In
Server Target Password field.
If this option is not specified, arplugin will accept
connections from AR System servers that have not been
configured to use a Plug-In Server Target Password.
Plugin Default Specifies the number of seconds within which the Plug-in
Timeout server must respond to the AR System server before an
error is returned.
Target Connection Defines the name and port number for the plug-in server.
Settings The server name and port number create a unique entry.
Therefore, if the user modifies an existing server name or
port number, the password will be cleared. If the user
chooses to remove the password for a particular entry, the
user can specify a server name and port number with no
password for that entry. The next time the user displays the
table, the entry will not be displayed.

Configuring

DSO Server Local Password Specifies the password that a DSO server will use to access
this AR System server.
If you are running a 7.0 server, you must enter a password.

Local RPC Program Specifies the RPC program number that DSO will use to
Number access the AR System server. If you leave the field blank,
DSO will access any other user using fast and list queues.
You can specify a private queue to define all DSO traffic to
use that private queue to isolate the operations of DSO and
interactive users.
Target Connection Sets the DSO remote server name and password (if
Settings applicable) that the DSO server will use when accessing
other AR System servers. If the user modifies the server
name, the Password column will be cleared.
Enter the information as follows:
1 Enter the remote DSO server name.
2 Enter a password in the Password column. (Leave the
password blank if you do not want to specify a password,
or if you want to clear the existing password.)
3 Select an RPC program number that will be used when
interacting with the specified server (optional). If you
leave the field blank, a value of zero will be entered, and
access to the server will default to using the fast and list
queues.
4 Enter a port number for the specified server (optional). If
you leave the field blank, a value of zero will be entered,
and the system will use a portmapper on the specified
server to locate the AR System server TCP port number.


Remote Workflow Local Password Sets a password used to access the current server when
workflow from another server references the current server.
By defining a password, you require that only workflow
defined on another server to access this server must have a
password defined. This protects the server from outbound
access.
Target Connection Sets a workflow password used to access the specified

Settings remote server when any workflow references the remote
server. If the remote server has specified a workflow
password, you must register that server and password, or
you cannot access that server through workflow.
Note: If you are creating passwords for the Application Service and DSO
server, you can set the minimum API version to 9 to make sure that secure
5.1 and above servers cannot communicate with servers running previous
AR System versions. For information about setting the API version, see
“Server information—Configuration tab” on page 132.
6 Click Apply.
7 Restart the AR System server for the Connection Settings to take effect.

Configuring
Server information—Currency Types tab

Use the Currency Types settings to specify the currency types that are
accessible in BMC Remedy Administrator. These currency types
(represented by three-character abbreviations such as USD) are stored in the
AR System Currency Codes form. The types appearing in the Currency
Types tab are those marked as active in the Currency Codes form. When you
add or remove currency types in the Server Information dialog box, the
AR System configuration file (ar.cfg or ar.conf) is updated with your
changes.
For more details about currency types, see the Form and Application Objects
guide.
To set currency types

4 Click the Currency Types tab.

Figure 5-10: Server Information window—Currency Types tab

Configuring
Group Name Description

Choose Default Allowable currency types are types that are valid entries in a
Allowable Types currency field. These currency types are visible in menus or
lists in BMC Remedy Administrator and in client screens.
From the list in the left column, select a currency type, and
click Add. Your selection will be added to the table on the
right, which shows the three-character currency type and
the default decimal precision level for that currency type.
For example, the currency type USD has a default of two
decimals of precision. You can modify this precision level by
entering a new value in the Precision column. For example,
to specify four decimals of precision, enter 4.
To remove a currency type, select it and click Remove.
Choose Default You must also specify the functional currencies that will be
Functional Types stored as part of the field value. When a request is submitted
that includes a currency value, the server converts that value
to a functional currency type and stores it.
You must include at least one functional currency type.
There is no limit to the number of functional currency types
you can specify; however, adding more than five currency
types might have an adverse effect on server performance.
From the list in the left column, select a functional currency
type, and click Add. Your selection will be added to the table
on the right, which shows the three-character currency type
and the default decimal precision level for that currency
type. For example, the currency type USD has a default of
two decimals of precision. You can modify this precision
level by entering a new value in the Precision column. For
example, to specify four decimals of precision, enter 4.
To remove a currency type, select it and click Remove.
6 Click Apply.

Server Information—External Authentication tab

Use the External Authentication tab to specify values for parameters
necessary for AR System to authenticate users with external systems.
To set external authentication parameters

4 Click the External Authentication tab.
Figure 5-11: Server Information window—External Authentication tab

Configuring

External Enables an external authentication (AREA) server. The RPC
Authentication program number for the plug-in service is 390695. Entering no
Server RPC value or zero (0) disables authentication using an AREA service,
Program Number and the AR System server will access the operating system for
authentication purposes.
Note: You must have an AREA server built and prepared before
you set the RPC Socket number here. See the C API Reference
guide for information.
For more information about how to set up an external
authentication server, see “Configuring a server to use plug-ins”
on page 197. For information about configuring an AREA
LDAP plug-in, see the Integrating with Plug-ins and Third-Party
Products guide.
External RPC Sets the time limit (in seconds) within which the Plug-in server
Authentication must respond to the AR System server when making external
Server Timeout authentication (AREA) calls before an error is returned.
(seconds) If this is set to zero (0), the AR System server uses the default of
30 seconds.
Need To Sync Sets the interval for periodically invoking the AREA server’s
AREANeedToSyncCallback() call. If this option is set to zero
(0), the AR System server does not invoke the call to the external
authentication server. The default is 300 seconds.
For more information about the external authentication server,
see “Configuring a server to use plug-ins” on page 197, and the
C API Reference guide.


Authenticate Defines how AR System validates a user who has no record in
Unregistered the User form.
Users When a user logs in to AR System, the server attempts to
validate the user against registered users (users who are listed in
the User form). If a match is found, that user definition and the
permissions specified in the matching User record are used. If
no match is found, AR System continues to attempt to validate
the user or stops the validation process depending on whether
this option is selected. If the check box is:
Selected, and External Authentication is not configured—
(Default on UNIX servers) On a UNIX server, AR System
searches the /etc/passwd file or NIS password map for a
match. If a match is found, the user is considered a valid user
(not a guest) of the system. The UNIX group specification
from the file or NIS is retrieved, and the user is considered a
member of the AR System group whose Group ID matches
the UNIX group.
On a Windows server, the AR System authenticates to the
default domain. The optional authentication string entered
by the user when logging in is used as the Windows domain
name for authentication purposes.
On Windows servers, the user is considered a member of the
group whose Group ID is 0.
Selected, and External Authentication is configured—
AR System sends a request to the external authentication
server to authenticate the user. If a match is found, the user is
considered a valid user (not a guest user) of the system. For
more information, see “Configuring a server to use plug-ins”
on page 197.
The authentication string entered by the user when logging in
is passed to the external authenticator for its use.
Cleared—(Default on Windows servers)AR System stops the
validation process and manages the user as a guest user if
Allow Guest Users is enabled.
For information about configuring external authentication, see
“To set server ports and queues” on page 149.
Ignore Excess Enables AR System to authenticate a user when any single LDAP
Groups group to which the user belongs matches an AR System group.

Configuring

Cross Ref Blank Defines how AR System authenticates a user whose User form
Password record has no password. When a user logs in, AR System
searches its own database for that user. If the user has a
password, the system uses it. If the Password field is empty, and
the check box is:
Selected—AR System attempts to validate the password
against one of the following items:
An external authenticator if one is configured
The password in the Windows server domain
The UNIX server’s /etc/passwd file
Cleared—(Default) AR System concludes that an empty
password field means that the user has no password.
In the Login window, users will see an Authentication field. If
your AR System server is running on Windows, the contents of
this field are used as a domain name when the server
authenticates the user with the operating system. If the server is
instead configured to use an external authenticator, the
contents of this field are passed to the authenticator. See
“Setting up an authentication alias” on page 116 for more
information about authentication aliases.
Authenication You specify the order in which the different authentication
Chaining Mode processes are considered at log in.
Default—Disables authentication chaining.
ARS - AREA—AR System attempts to authenticate the user
using the User form, and then the AREA plug-in.
AREA - ARS—AR System attempts to authenticate the user
using the AREA plug-in, and then the User form.
ARS - OS- AREA—AR System attempts to authenticate the user
using the User form, then Windows or UNIX authentication,
and then the AREA plug-in.
ARS - AREA - OS—AR System attempts to authenticate the
user using the User form, then the AREA plug-in, and then
Windows or UNIX authentication.


Group Mapping In previous releases of AR System, the names of LDAP
groups had to match the names of AR System groups for a
user to be authenticated. With AR System 7.0, you can
map LDAP groups to AR System groups. You use the
Group Mapping table on the External Authentication tab
in the Server Information window to map LDAP groups
to AR System groups.
LDAP Group The name of LDAP group you want to map to the AR group in
Name the same row of the Group Mapping table.
AR Group Name The name of AR group you want to map to the LDAP group in
the same row of the Group Mapping table.

Configuring
Server information—Advanced tab

Use the Advanced tab to create settings for performance and security.
To set advanced options

Figure 5-12: Server Information window—Advanced tab

5 Edit the options as needed:

Maximum Filters for Defines the number of filters that can be performed in an
an Operation operation. The default and recommended number is 10000.
Increase this number at your own risk only if you reach a
limit in your system and you have verified that your
workflow is valid.
Maximum Stack of Defines the maximum number of nested filters and filter
Filters guides that will execute to prevent recursive actions on the
server. The default and recommended number is 25.
Increase this number at your own risk only if you reach a
limit in your system and you have verified that your
workflow is valid.
Maximum Line Defines the maximum line length that can be in an email. If
Length in Email a single line of the message is over this length, a return is
automatically inserted. Limits the line length of emails
passed through the mail server to protect users from
excessively long lines. The default is 1024.
Default Web Path Defines the base URL to the mid tier and is used by clients
such as BMC Remedy Alert and Flashboards.
The URL looks like this:
http://<host_name>/<context_path>
Where:
host_name is the name of the server (for example,
eng.remedy.com).
context_path is the URL context path of the AR System
application registered with the servlet engine. This is set
up during installation. The default value is arsys.
If your company has multiple domains, use a fully qualified
path name.
Email Notifications Defines the URL shortcut that appears in email
Web Path notifications.
If this field is left blank, the Default Web Path is used. (The
Email Notifications Web Path field is available because the
Default Web Path is specified for other applications like
flashboards, and it might be different from the mid tier web
path for opening requests in a notification.)
If your company has multiple domains, use a fully qualified
path name.

Configuring

Security Active Link Run Security feature that allows you to define the only directory
Process Directory in which active link processes can execute.
If no directory is specified, active link processes can run
from any directory. Otherwise, specify which directory the
Run Process action can run from, for example, c:\arsys.
Active Link Run Security feature that allows you to define which shell is the
Process Shell parent of an active link server process. If no path is specified,
(UNIX servers only) administrators can specify any shell.
Otherwise, specify which type of shell the Run Process
action can use, for example, /bin/csh.
Allow arcache and If selected, allows the administrator to use the arcache and
arreload arreload utilities. For more information, see “arcache
(arcache.exe)” on page 350 and “arreload (arreload.exe)” on
page 354. The default is selected.
Localized Error Localize Server Allows the administrator to enable or disable localization of
Messages the server. If the check box is:
Selected—The server is localized and is enabled for such
tasks as searching entries in localized forms, or using
AR System Message Catalog to load the message. Clients
are enabled to display localized messages, but clients such
as BMC Remedy User still have local catalogs, such as the
user.dll. You must select the Localize Server check box
to see localized error messages.
Cleared—(Default) The server is not localized. Such tasks
as searching localized forms and the localization of
messages are disabled. The server does not make use of the
AR System Message Catalog form and messages are
shown from the error catalog. The default message is
displayed.
Catalog Form Name Displays the name of the form the server uses to resolve
error messages when “Localize Server” is selected. For more
information about Localized Error Messages Catalog form,
see the Form and Application Objects guide.


Server Statistics Server Recording Specifies how the server records server statistics. Select one
Mode of the following options:
Off—(Default) Do not record server statistics.
Cumulative Queue—Record a cumulative statistic that is
a combination of all the queue statistics.
Cumulative and Individual Queue—Record a cumulative
statistic that is a combination of all the queue statistics as
well as statistics of each queue individually.
Information is recorded in the Server Statistics form, which
is installed when you install AR System. For more
information, see the Optimizing and Troubleshooting guide.
Recording Interval Defines how often the server records server statistics. The
(seconds) default is 60 seconds.
Remember that one (Cumulative Queue) or more
(Cumulative and Individual Queue) entries are recorded in
the Server Statistics form during each interval. If you have a
short interval, many records will be created. This can have
an effect on the performance of the system and the size of the
database if you configure with too short an interval.

Configuring

Server Group Server Group Names If the server belongs to a server group, enter the name of the
group in this field. This setting is shared by all servers in the
server group.
Check Interval Defines how often the server communicates with other
servers in the group. Each server can register its own status,
determine if any server is delinquent, establish the
parameters needed for sending signals, and determine
operational responsibilities. The default is 30 seconds, the
minimum value is 10 seconds, and there is no maximum
value. This setting is shared by all servers in the server group,
and when it is changed, all the AR System servers in the
group must be restarted.
Preference Server Preference Server Select where you want user preferences should be read from.
Option The options are:
User Defined—The user can choose whether to use a
preference server, and this server might or might not be
used depending on whether the Centralized Preference
forms are defined.
Use This Server—The user must use a preference server,
and this server is an available preference server.
Use Other Server—The user must use a preference server,
and this server is not available as a preference server. This
allows the specification that a preference server must be
used, but that this one cannot be used for this purpose.
6 Click Apply.
Server information—Source Control tab

Use the Source Control tab to configure source control (SC) within the
AR System by creating or selecting SC projects. Administrators can also set
the level of SC integration they want, for example, Enforced or Advisory
mode. Here you define specific options for your SC system as well as create,
add, and open SC projects. How SC is integrated with AR System differs
based upon which SC application you use. You will find the SC feature
especially helpful in moving applications from development to production.

To use SC with AR System, you must understand the details of your SC

application and database. Different SC applications will have slightly
different feature sets, creating slightly different implementations with
AR System. For specific information, see your SC application
documentation.
For a detailed discussion on SC issues, see the Integrating with Plug-ins and
Third-Party Products guide.
Note: You must install and configure your SC system before implementing
SC with AR System. The recommended method of SC integration is
installing and running the SC client instead of editing paths in the system
registry. A correct installation of the SC client must work properly with
AR System. When using the SC system, make sure that you have enabled
integration and that you have installed the SC clients.
To configure source control

4 Click the Source Control tab.

Configuring
Figure 5-13: Server Information window—Source Control tab

Enable Source Defines if SC within AR System is activated. If this option is
Control Integration selected, you can configure SC software (for example,
Microsoft Visual SourceSafe or PVCS Version Manager)
with AR System.

Mode Sets one of the following modes:

Enforced—System strictly enforces SC version control
on AR System objects; for example, check-out and check-
in. Enforced integration causes BMC Remedy
Administrator to prompt developers to check out the
object when it is modified. If the system is in Enforced
mode, you cannot modify and save an object if you do not
check it out from SC first.
Enforced mode extends also to group permissions and
bulk update operations. Developers cannot modify
objects if they are not first checked out in SC.
Advisory—System warns user when SC version control is
not satisfied with respect to check-out and check-in, but
still allows a developer to update AR System. When a
developer checks in an object, the SC system is updated
only if BMC Remedy Administrator gets exclusive access
to the SC system. If the system is in Advisory mode, you
can modify and save an object without having it checked
out from the SC and updating the Checked Out To
property on AR System server. The system will prompt
you with a warning but still allows you to proceed with
your modifications.
Comments Required Defines whether comments are needed when checking in
in Check In system objects.
Comments Required Defines whether comments are needed when checking out
in Check Out system objects.
Provider Name Lists the SC software installed on your system. You can
choose different SC software for different projects.
Project Name Opens a project dialog box to select a project and location
to enter into SC.
6 To activate Source Code Control integration in AR System, complete the

following steps:
a Click the Enable Source Control Integration check box.
The SC options in the Source Control tab become activated.
b Choose the Enforced or Advisory Mode option to define the level of SC
integration you want with AR System.
c Choose to add optional check-in or required check-out comments to SC.

Configuring
SC comments can be optional with AR System. However, if you select to

have comments required, you must enter them each time you check in or
check out an object.
d From the Provider Name list, choose your SC system.
WARNING: Choose an SC system and stay with it. Do not mix SC systems.
Otherwise, you run the risk of introducing inconsistencies within the
AR System server environment.
e Click Browse to create or open an SC project.

Depending on which SC application you integrate with AR System,
different actions occur. For example:
With Microsoft Visual SourceSafe, you must log in to SourceSafe, then
open or create a SourceSafe project.
With PVCS Version Manager, you create or open an SC project.
The contents of the read-only Project Name field provide information
used only for internal server processes.
The last project opened in the Source Control tab is the current project
displayed in the BMC Remedy Administrator client. If you are in an
environment with multiple developers, make sure you are all using the
correct project.
7 Click Apply.
Your settings are saved to the server. They define the current information for
all AR System administrators and AR System application developers
connected to the system. You can use the SC features as needed.
When you create an SC project in AR System, you can check into SC any
object that appears in the New Server Object dialog box of BMC Remedy
Administrator, except for distributed pools, distributed mappings, and
groups.

Server information—Server Events tab

Use the Server Events tab to select the server activities that you want to log.
When you select specific server events, those events are logged in to the
Server Events form, thereby making server-related changes available to
workflow and API programs. For information about the Server Events form,
viewing recorded server events, and using server events in workflow, see
Chapter E, “Working with the Server Events form.”
To set options for server events

4 Click the Server Events tab.
Figure 5-14: Server Information window—Server Events tab

Configuring

Server Events Form Specifies the name of the form that is populated with
information about specific server events. AR System
automatically generates this form, and the form is defined
from a unique combination of AR System reserved fields.
Only one Server Events form per server is allowed.
The default name is Server Events; you can rename the form,
as needed.
Server Event Type Server Cache Determines the objects for which changes are recorded in the
Changes Server Events form. Select the check box next to any of the
following events to log changes to these objects:
Active Link
Container
Escalation
Field
Filter
Import
Menu
Form
View
User/Group Determines whether to log additions, modifications, or
Changes deletions to Users or Groups in the User or Group form, or
any user or group changes using the access control utilities
arcache and arreload. Changes will be recorded in the
Server Events form.
Server Setting Determines if an entry is created in the Server Events form as
Changes a result of the ARSetServerInfo call.
Alert Client Determines if an entry is created in the Server Events form as
Registration a result of BMC Remedy Alert logs to the AR System server.
Archive Determines if an entry is created in the Server Events form as
a result of archiving data to an archive form.
Server Group Determines if an entry is created in the Server Events form as
Actions a result of server group activities.
6 Click Apply.

Configuring a server for development or production

cache mode
There are two cache modes that you can set for your server operation,
development cache mode and production cache mode. Production mode is
the default and is appropriate where there are a large number of application
users.
In development mode, the admin thread for API calls does not copy the cache
but locks incoming threads out of the existing cache and waits for threads
currently using the cache to complete their operations before performing
changes. The thread will not release the cache until the end of the API call.
No time is spent copying the cache so operations have a smaller memory
footprint and are performed faster than in production mode. Development
mode is intended for servers whose main purpose is application
development. It is unsuitable for servers with a large number of application
users in a production environment because the operations of those users will
be blocked when forms and workflow are changed, especially when many
structures are changed, such as when importing an application.
You must restart the AR System when both setting and clearing the
development cache mode.
To set development cache mode

4 Select the Configuration tab.
5 Select the Development Cache Mode check box.
6 Restart the AR System server for this setting to take effect.
If your server has been set to development mode and you want to reset it to
production mode, use the following procedure.
To set production cache mode


Configuring

4 Select the Configuration tab.
5 Clear the Development Cache Mode check box.
6 Restart the AR System server for this setting to take effect.
Configuring multiple servers

You can configure multiple servers to run on a single host machine. You can
also configure multiple servers on independent host machines to access the
same database. These distinct features are discussed in the following sections.
To learn more about installing multiple servers, see the Installing guide.
Important: Server group functionality is not supported for multiple servers

on one machine.
Configuring multiple servers on one machine

The ability to run multiple servers on a single host machine offers the
following advantages:
It provides a cost-effective solution by allowing you to support more
customers with less hardware.
It enables mutually exclusive groups of users to access separate AR System
servers on a single host machine.
It provides the option to use a single high-end system for production,
development, and test.
Each server connects to a different database, as shown in Figure 5-15, and
each server must have a separate license.
Configuring multiple servers 179

Figure 5-15: Configuring multiple servers on one machine
Host
Server
Server
For more information about licensing, see the Installing guide.

Additional servers are installed the same way you install your original
AR System server. You must run the AR System server installer again for each
additional server you want to run on the host machine. For information
about installing servers, see the Installing guide.
The following information highlights the configuration parameters
necessary to support multiple servers on one machine. While you might have
configured these parameters during installation, the steps are noted here for
verification and troubleshooting purposes.
Before assigning port numbers, remember these tips:
Only one server can be registered with a portmapper if you are configuring
multiple servers to run on one machine.
You must assign unique port numbers for each server.
Do not assign port numbers that conflict with port numbers used by other
applications or other programs running on your system. You can find out
which port numbers are already registered by using the rpcinfo -p
command (UNIX) or the netstat -a command (Windows) at the
command-line prompt. If you do not check available ports, you could
assign port numbers that conflict with other applications, and your servers
might not start as expected.

Configuring
On UNIX, port numbers within the range 1–1024 are only available for use
by the superuser, and many of these numbers are reserved.
Client tools can use ports 0–65535.
To assign port numbers using BMC Remedy Administrator

1 Log in to each server using BMC Remedy Administrator.
2 Select the server, and choose File > Server Information.
The Server Information dialog box appears.
3 Click the Server Ports and Queues tab.
4 In the Server TCP/IP Port field, enter the number that you want to use for the
server port. See “Server information—Server Ports and Queues tab” on
page 149 for more information.
5 Select the Register with Portmapper check box as appropriate to determine
the Portmapper option.
6 For every server, manually set the Multiple-ARSystem-Servers option to
True in the ar.cfg file or ar.conf file.
For general information about the files or for specific information about this
particular option, see Appendix B, “AR System configuration files.”
7 Click Apply.
8 Restart the server for the changes to take effect.
Note: To change the port number that the AR System server uses when
communicating with the plug-in server, edit the Plugin-Port option of the
ar.cfg (ar.conf) file, and restart the server. For more information, see
“Plugin-Port2” on page 332.
Configuring multiple servers to access the same database

The ability to configure multiple servers to share the same AR System
database, as shown in Figure 5-16, offers the following advantages:
It enables you to use multiple servers to access multiple applications from
a single high-performance database sharing the same data.
It gives you one point of database management.

It provides easy backup and replication at the database level.

It increases scalability by increasing the bandwidth that can be applied to
a single data set.
Figure 5-16: Multiple servers accessing the same AR system database
Host Host Host
Server Server
During installation, you will be prompted to specify a database for each

server as well as database login information and database settings. You will
want to specify the same information for each case, making sure you choose
the upgrade option for the second and subsequent servers. For more
information about installing multiple servers, see the Installing guide.
The following procedure highlights configuration options that are available
to protect your data when running multiple servers against the same
database.

Configuring
Configuring multiple servers to access the same

database
When running multiple servers against a single database, you can configure
the following options to protect your data:
Disable Administrator Operations—Disabling administrator operations
(such as CreateSchema, SetSchema, and CreateField) is necessary when
you run multiple servers against the same database. To prevent more than
one server from updating a form when another server is using that form,
you can disable administrator operations in the Server Information dialog
box, Configuration tab.
Only one AR System server in this configuration should have
administrator operations enabled.
Disable Escalations—To prevent workflow conflicts between multiple
servers that are attached to the same database, you can disable escalations.
Only one AR System server in this configuration should have escalations
enabled.
Disable Archive—To prevent workflow conflicts between multiple servers
that are attached to the same database, you can disable archiving.
Only one AR System server in this configuration should have archiving
enabled.
Note: If a specific server is a member of a server group, the settings for

Disable Archive, Disable Admin Operations, and Disable Escalations are
ignored for that server.
Server Groups—If the servers are designated as members of a server

group, they self-regulate. You can configure the servers in the AR System
Server Group Operation Ranking form to choose preferences for which
server owns the operations.They self-regulate to make sure that only one
server performs an operation. See “Running servers as part of a group” on
page 185.
The server group functionality is not supported when multiple servers are
installed on the same machine.

Server Events—Record server events such as cache changes, user and

group changes, and alert client registrations. A filter that uses the arsignal
utility executes upon cache, user, and group changes, and notifies other
servers to reload their cache. A filter that executes upon Alert client
registration notifies other servers to update their internal Alert user
information. If the servers are designated as members of a server group,
server events do not need to be recorded.
You need to disable these options on all but one server in the set of servers
accessing the same database. Only one server needs to perform administrator
operations and perform escalations. This server must have filters applied to
its server events form when using the arsignal utility to notify the other
servers of changes to the cache. For more information about arsignal, see
“arsignal (arsignal.exe)” on page 356.
To configure BMC Remedy Alert to work in this environment, you must
create a filter to notify all other AR System servers in the cluster of alert
registration events. An alert registration event occurs when a BMC Remedy
Alert tool logs in to an AR System server. The filter you must create will
execute a Run Process that uses the arsignal utility to notify other
AR System servers of the registration event. Without this filter, other
AR System servers in the cluster would be unaware of these registration
events.
To enable BMC Remedy Alert to recognize all the AR System servers in the
cluster, version 5.1 or higher of BMC Remedy Alert must be used. In
addition, the AR System server IP addresses must be mapped to each other.
For example, if you have three AR System servers—A, B, and C—in the
cluster, add the following lines to the ar.conf (ar.cfg) file for server A:
Map-IP-Address <Server_B_IP_Address> <Server_A_IP_Address>
Map-IP-Address <Server_C_IP_Address> <Server_A_IP_Address>
To configure options for multiple servers accessing the same database

1 Open a server window.
2 Select the appropriate server in the Server Window.
3 Choose File > Server Information from the menu bar.
5 Decide which server in the set will perform administrator operations.
a Enable Administrator Operations on this server.
b Configure your system to notify companion servers of structure changes.

Configuring
c Enable the required server events in the Server Events tab of the Server
Information dialog box.
6 For companion servers, perform the following steps:
a Disable Administrator Operation.
All Administrator operations with the exception of logging and setting
ports will be disabled. See “Server information—Configuration tab” on
page 132 for more information.
b Disable all the server events in the Server Events tab of the Server
information dialog box.
7 Decide which server in the set will perform Archive or Escalation functions.
a For this server, enable the required function.
b For companion servers, disable the required function.
These functions will not be disabled until you restart the server. See “Server
information—Configuration tab” on page 132 for more information.
Running servers as part of a group

You can create a server group to manage servers collectively. A server group
consists of two or more servers designated as part of a server group that share
the same database. Servers that belong to the same group can share floating
licenses and provide backup for a set of operations that is allowed to run on
only one server at a time. Critical operations have greater availability because
you can configure any server in the group to back up another server’s
operations.
Important: Server group functionality is not supported for multiple servers

on one machine.
Servers in a group can back up the following operations:

Administration
Approval Server
Archive
Assignment Engine
Business Rules Engine

DSO
BMC Remedy Email Engine
Escalation
Flashboards
To configure server groups, you must complete the following tasks:
Step 1 Install the initial server with the database.
Step 2 For subsequent servers, choose the same database when installing the servers
in a server group, and select the Share database option. See “Installing servers
as members of a server group” on page 187.
Step 3 License the servers appropriately. See “Licensing server groups” on page 187.
Step 4 In BMC Remedy Administrator, designate:
Server membership for each server in the group. See “To specify a server
as a member of a group” on page 187.
A server group name. See “To set the server group name” on page 188.
The time interval that servers use to check whether another server is still
online, known as the check interval. See “To set the server check interval”
on page 188.
(Optional) A log file to record server group activity. See “To set the server
group log file” on page 189.
(Optional) Whether you want server group activity to be recorded in the
Server Events form. See “To log server group activity in the Server Events
form” on page 190.
Step 5 In BMC Remedy User, determine the settings for individual servers in the
group. See “AR System Server Group Operation Ranking form” on page 191
and “To designate server settings in BMC Remedy User” on page 191.
Use the following procedures to perform these server group tasks.

Configuring
Installing servers as members of a server group

To install servers as members of a server group, during installation, choose
the Share option:
For UNIX, enter the s option at the appropriate prompt to share a
database.
For Windows, select the Share option in the Existing Database dialog box.
If you do not select the Share option for a server at installation and
subsequently want to make that server a member of a server group, modify
the ar.conf (ar.cfg) file to point the server to the database used for the
server group.
Licensing server groups

The following license types have special considerations for server groups:
User floating licenses
Application floating licenses
Each server group is issued a set of licenses that is specific to the server group.
Each individual license is for a specific server, but has a group tag that
associates it with a server group. The number of floating licenses must be the
same on each server in the server group. Any server that is a member of a
group will only accept licenses that have the tag for that group; a server that
is not a member of the group will not accept a license that has a server group
tag.
Each time a user seeks a license from a server that belongs to a server group,
it triggers a system check to see how many licenses the group has available
and how many are currently in use. A license is granted to the user only if the
number of licenses for the server group as a whole is not exceeded. A user
accessing multiple servers in the server group will use only one license.
To specify a server as a member of a group

3 Open the Server Information dialog box (File > Server information).
Figure 5-17: Server Group Member selection in the Server Information dialog box,

Configuration tab
5 Select the Server Group Member check box.

6 Click OK to close the Server Information dialog box.
7 Restart the AR System server for the change to take effect.
To set the server group name

Figure 5-18: Setting the server group name in the Server Information dialog box
5 In the Server Group Name field, enter the name of the group to which the
server belongs.
This can be any name of your choice; make sure that you use the same name
when tagging the floating licenses. Names can be as long as 80 characters,
including spaces, and must have no special characters. You can include
double-byte characters, but avoid using numbers at the beginning of the
name.
To set the server check interval


Configuring
Figure 5-19: Setting the check interval in the Server Information dialog box
5 In the Check Interval field, enter how often you want the server to check the
status of other servers in the group.
The default check interval is 30 seconds, the minimum value is 10 seconds,
and there is no maximum value. If you change this value after a server group
is running, you must restart all the AR System servers.
The information shared between servers in the group includes:
The current server’s own status.
Whether any server is delinquent.
The parameters needed for sending signals.
Information about operational responsibilities.
For an explanation of delinquency and rankings, see “To designate server
settings in BMC Remedy User” on page 191.
To set the server group log file

Information tracked in the log file includes the starting and stopping of
operations, the evaluation of other servers, and the timing of each event.
Figure 5-20: Server Group entry in the Server Information dialog box, Logging tab
5 Select the Server Group check box.

6 Enter a path to the log file if you do not want to use the default.
To log server group activity in the Server Events form

4 Click the Server Events tab.
Figure 5-21: Server Group entry in the Server Information dialog box, Server Events
tab
5 Select the Server Group Actions check box.

For more information about server group settings in the Server Information
dialog box, see the following sections:
“Server information—Configuration tab” on page 132
“Server information—Advanced tab” on page 167
“Server information—Log Files tab” on page 141
“Server information—Server Events tab” on page 176
Establishing a server name for the servers in a server

group
By default, a server in a server group uses a fully qualified server name with
domain to identify itself, for example, myserver.remedy.com. Other servers
in the group use this name to communicate. You can change the name by
adding the following line to the server’s configuration file:
Server-Connect-Name: myservername
This name must be resolvable by DNS and is used exactly as specified. If a

common server alias is specified, you must set this configuration option. See
“Server-Connect-Name2” on page 335.

Configuring
If you change the name of one of the servers in a server group after the server
is established as a member, remove all references to the previous server name.
See “To remove a server from a server group or to remove all references to an
old server name” on page 193.
AR System Server Group Operation Ranking form

The AR System Server Group Operation Ranking form is automatically
created when you specify a server as a member of a group and restart the
AR System server. This form is created only one time, when the first server is
specified as a group member and the server is restarted.
When the form is created, it is populated with default entries. For the first
server in a server group, the default entries establish that server as the first
choice for operation ownership for each operation. Subsequent servers have
default entries with a null ranking that serve as placeholders for easy
modification. Default entries for operations that do not run in your
environment should be removed or have a null ranking. If an operation
requires a license and the license is not present, no default entry will be
created for that operation.
Figure 5-22: AR System Server Group Operation Ranking form
To designate server settings in BMC Remedy User

1 Log in to BMC Remedy User.
2 Open a new AR System Server Group Operation Ranking form.
Make sure that you review the existing default entries in the AR System
Server Group Operation Ranking form before creating new ones.

3 In the Operation field, select the operation for which you want to determine
the settings.
4 In the Server field, enter or select the name of the server.
All servers that are members of the server group will be listed in the menu.
When adding entries for servers not already in the group, enter the fully
qualified server name or the name that was established in the configuration
file. See “Establishing a server name for the servers in a server group” on
page 190.
5 In the Rank field, enter the ranking for the specified operation for the server.
The servers for any one operation are ranked lowest to highest; a value of 1
indicates the server that will be chosen first to perform the operation.
Ranking numbers do not need to be consecutive, but avoid duplicate
numbers. A value of null will result in the server ignoring the entry. If an
operation has no server designated with a valid rank, it will not run on any of
the servers in the group.
6 Enter a delinquent threshold value for the server.
The delinquent threshold is the number of times the specified server has not
reported its status before the next server in the ranking takes responsibility
for the operation. The interval time is set in BMC Remedy Administrator in
the Advanced tab of the Server Information dialog box.
7 Save the AR System Server Group Operation Ranking form.
8 Restart the AR System server for the change to take effect.
Note: When specifying Approval Server or Business Rules Engine operations,

give these the same ranking as the Administration operation. These
operations need to run on the same AR System server as the
Administration operation.
For example, if you select Administration in the Operation field and 2 in

the Rank field on the AR System Server Group Operation Ranking form
on the witherspoon.remedy.com server, make sure to select Approval
Server in the Operation field and 2 in the Rank field using the same form
on the same server.

Configuring
To remove a server from a server group or to remove all references to

an old server name
1 For removing a server only—In the Configuration tab of the Server
Information dialog box, clear the Server Group Member check box.
2 Remove all the entries for the server name in the AR System Server Group
Operation Ranking form.
3 Restart one of the servers in the server group.
The server that you restarted will remove all the server group references for a
server that does not have any ranking entries.
Choosing a method for server group signaling

By default, a server in a server group notifies other members of the group of
activities using a combination of the ARSignal utility and information posted
in the database. Alert user registration and application activity (for example,
DSO) are communicated with ARSignal; all other activity such as form
changes, escalation time changes, and user changes are communicated with
database postings.
The database method is preferred because it reduces server activity when
definition changes are communicated between servers. You can, however,
choose the ARSignal method for all types of activity. With this method, other
servers are notified of changes immediately, and there is no delay in
resynchronization or updating definitions. To set the ARSignal
communication option, add the following line to the server’s configuration
file:
Server-Group-Signal-Option: T
You can set this option for each server in the server group independently.
You should set all servers to use the same method. See also “Server-
Group-Signal-Option2” on page 336.
Server group communication with BMC Remedy Email

Engine
If the port number (RMIPort) for email administration in BMC Remedy
Email Engine is changed from the default, set the AR System server
configuration in ar.cfg or ar.conf to the same port number. This enables
the server to communicate email administration information to BMC
Remedy Email Engine during server group processing.

The syntax is as follows:

Server-Group-Email-Admin-Port: 2020
Server group communication with BMC Remedy

Flashboards
If the port number (RMIRegistryPort) for flashboards administration in the
Flashboards server is changed from the default, set the AR System server
configuration in ar.cfg or ar.conf to the same port number. This enables
the server to communicate flashboards administration information to the
Flashboards server during server group processing.
The syntax is as follows:
Server-Group-Flashboards-Admin-Port: 2021
Running a stand-alone AR System server on Windows

On Windows, you can run a stand-alone AR System server, which is
disconnected from the network (for example, on a laptop computer).
To run a stand-alone AR System server

1 Open the C:\WINNT\system32\drivers\etc\hosts file (or the drive on
which Windows server is installed).
2 Enter the following alias entry:
<IPAddress> <local_host_name>.<domain_name> <local_host_name>
For example:
174.21.8.109 coyote.acme.com coyote
Many configurations of Windows require you to remove all DNS servers

when running as a stand-alone server. This avoids long pauses caused by the
Windows networking software trying to communicate with the network
during AR System interaction. Write down what you removed so that you
can add it back when reconnecting to the network.
3 Save the file.
4 Shut down and restart the system.
The AR System server will now also function when disconnected from the
network.

Configuring
Configuring firewalls with AR System servers

This section describes the connections required to connect to an AR System
server through a firewall, without using a portmapper. A firewall is a security
system that acts as a protective boundary between a network and the outside
world. In the following figure, the BMC Remedy User client connects to a
specific port of the AR System server. When the user makes a request of the
AR System server, the response is returned on the same TCP connection that
makes the request. (BMC Remedy Administrator and BMC Remedy User use
the same port to talk to the AR System server; therefore, they are configured
the same way for firewalls.)
When the AR System server determines an alert is required, it sends the alert
message to BMC Remedy Alert using TCP on the outbound port specified in
the configuration, as shown in Figure 5-23. For more information about
setting ports, see “Server information—Server Ports and Queues tab” on
page 149.
Figure 5-23: Transmitting through a firewall
Firewall
Remedy
User
AR System
server
Remedy
Alert
ALERT
Outbound Port
Inbound Port
TCP Call
Configuring firewalls with AR System servers 195

To enable these connections through the firewall, the AR System server and
the client must be configured to communicate on the proper ports:
AR System server—The AR System administrator assigns a specific port
number in the Server TCP/IP Port box as described in “Assigning TCP
port numbers to AR System servers” on page 149.
Client—The administrator or user configures the Advanced Server
Properties in the Accounts dialog box as described in “To configure
Windows clients to avoid using a portmapper” on page 196. This informs
the clients of the location on the firewall through which they can connect
to AR System servers.
Configuring clients for AR System servers

When servers are configured to run on specific TCP ports, the clients need to
be configured to match.
Important: The specifics of your firewall configuration vary from

manufacturer to manufacturer. Ask the network and security
professionals at your company for more information.
For more information about TCP port numbers, see “Assigning TCP port
numbers to AR System servers” on page 149.
To access private AR System queues, client machines must either set the
appropriate RPC and TCP values in the Accounts dialog box, or have the
ARRPC and ARTCPPORT environment variables set. Port 111 is used for
Portmapper, and it can be blocked for requests coming through the firewall.
Internal requests are be affected by this rule since Register-With-
Portmapper: T is the default configuration setting of the portmapper. The
BMC Remedy User accounts list should have the port number entered for the
AR System server. See the discussion in “Configuring a server to use plug-
ins” on page 197.
You can set these ports in the Advanced Server Properties of the Accounts
dialog box as the following section explains.
To configure Windows clients to avoid using a portmapper

1 In BMC Remedy User, choose Tools > Account to open the Account dialog
box.

Configuring
Figure 5-24: Account dialog box
Advanced Server
Properties check box
2 Select the Advanced Server Properties check box to view the advanced port
columns. Otherwise, you see only the first two columns.
3 Click in one of the following columns and type the port number or the
private server number to which you want to connect:
TCP—Represents the port number of the specified AR System server.
RPC—Represents the program number of a private server, if you are using

one.
4 Click OK.
5 Log in again to activate these changes.
Configuring a server to use plug-ins

You might want to use plug-ins for:
AR System database connectivity (ARDBC)—Used to create an
AR System vendor form to access external data. For information about
vendor forms, see the Integrating with Plug-ins and Third-Party Products
guide.
AR System external authentication (AREA)—Used to resolve user
accounts against directory services.
AR System filters (ARF)—Used to make a call from workflow to external
services, and capture returned data.
Configuring a server to use plug-ins 197

The AR System supports the plug-in service and API, but if you have
problems with a specific plug-in, contact the plug-in service provider for
assistance.
For more information about creating ARDBC, AREA, or ARF plug-ins, see
the Integrating with Plug-ins and Third-Party Products guide and the C API
Reference guide.
To configure a server to use plug-ins

1 Modify the following settings in the ar.conf file (on UNIX) or the ar.cfg file
(on Windows):
Plugin (page 329)
Number of threads, for example:

Plugin-ARDBC-Threads (page 330)
Plugin-AREA-Threads (page 330)
Plugin-Filter-API-Threads (page 330)
Plugin-Log-Level (page 331)

Plugin-Port (page 332)
Server-Plugin-Alias (page 337)
Server-Plugin-Default-Timeout (page 337)
These settings are described in Appendix B, “AR System configuration files.”

2 Modify the plug-in target password (page 154).
3 Modify the plug-in log file settings (page 141).

Configuring
Configuring the AR System server for external

authentication (AREA)
After you have installed an AREA plug-in, you can set up the AR System
server to use external authentication.
Users can be authenticated externally in three ways. (Two of the three
authentication methods use the authentication string described in the C API
Reference guide. See also “Setting up an authentication alias” on page 116.)
Depending on your system and configuration, users can be authenticated:
To the operating system (UNIX only)—The AR System server
authenticates to the operating system. Currently, the authentication string
has no effect when authenticating to a UNIX operating system.
To the server domain (Windows)—The AR System server authenticates
to the Windows server domain. If a value has been entered in the
Authentication String field, that value will be used as the domain name to
which the AR System server will authenticate.
To the AREA service—If you have configured external authentication to
an AREA service, the user name, password, and authentication values
entered will be provided to the AREA service.
Before configuring external authentication for an AREA service, you must
configure your server to use plug-ins, as described in “Configuring a server
to use plug-ins” on page 197. You must also start the plug-in service, as
described in Appendix C, “AR System server components and external
utilities.”
After the service is started, you must set up the server for external
authentication as described in the following procedure.
Configuring the AR System server for external authentication (AREA) 199

To configure the AR System server for external authentication

1 In BMC Remedy Administrator, select a server, open the Server Information
dialog box, and then click the External Authentication tab.
2 To enable authentication using an AREA service, set the External
Authentication Server RPC Program Number to 390695.
Entering 390695 enables authentication using an AREA service. Entering no
value or zero (0) disables authentication using an AREA service.
If you enter zero, the AR System server makes no attempt to communicate
with the AREA server.
3 Set the RPC and SYNC time-outs for External Authentication.
External Authentication Timeout (seconds) is the amount of time within
which the AREA server must respond to a call from the Plug-in server before
an error is returned. The options are:
RPC—Used when making calls to the AREA server. If set to zero (0), the
AR System server will not invoke the call to the external authentication
server. The default is 30 seconds.
Need To Sync—The interval for periodically invoking the AREA server’s
AREANeedToSyncCallback() call. If set to zero (0), the AR System server
will not invoke the call to the external authentication server. The default is
300 seconds.
4 Select one or both of the following settings:
Authenticate Unregistered Users—Specifies that all users in the User
form can log in and be authenticated internally; users not in the form will
be authenticated externally. If this option is cleared, AR System stops the
validation process and manages the user as a guest user.
Cross Ref Blank Password—Specifies that all users in the User form can
log in and be authenticated externally if the Password field in the form is
left blank for that user. If Cross Ref Blank Password is cleared, a blank
Password field in the User form is treated as no password for that user.
5 Optionally, specify an authentication chaining mode.
Mode Description
Off Disables authentication chaining.
ARS - AREA AR System attempts to authenticate the user using the User
form, and then the AREA plug-in.

Configuring
Mode Description
AREA - ARS AR System attempts to authenticate the user using the AREA
plug-in, and then the User form.
ARS - OS- AREA AR System attempts to authenticate the user using the User
form, then Windows or UNIX authentication, and then the
AREA plug-in.
ARS - AREA - OS AR System attempts to authenticate the user using the User
form, then the AREA plug-in, and then Windows or UNIX
authentication.
Note: For more information about authentication options, see Integrating

with Plug-ins and Third-Party Products guide.
6 Specify Group Mapping options:

Ignore Excess Groups—Specifies that authentication requires that, for a
given user, at least one LDAP group must match an AR System group (not
all groups must match). The non-matching groups will be ignored. If this
option is cleared, authentication occurs only when each LDAP group
matches an AR System group.
Group Mapping—Specifies mappings between LDAP groups and
AR System groups. This eliminates the need for one-to-one matches
between LDAP and AR System groups. If you do not map groups, each
LDAP group must have an exact AR System group match.
Tip: For maximum benefit, use Ignore Excess Groups and Group Mapping
together.
7 Save your settings.

The settings you specify persist across server restarts.
Configuring the AR System server for external authentication (AREA) 201

Configuring a mail server

To configure a server to process requests sent through email and to
send email notifications on Windows
1 Install BMC Remedy Email Engine.
2 Configure the AR System server for use with BMC Remedy Email Engine.
3 Set up email for requests and searches. This includes the following tasks:
a Establish an email address.
b Set up the mail server.
c Configure additional mailboxes to be used in your organization.
d Start the mail process.
4 Configure email for notifications by creating a notification mailbox.
For more information about installing BMC Remedy Email Engine, see the
Installing guide. For information about configuring BMC Remedy Email
Engine, see the Administering BMC Remedy Email Engine guide.
Configuring a server for alerts

To enable users to receive alerts from the server through BMC Remedy Alert,
you need to configure your server.
The earlier Notification Server command-line configuration options are not
available in AR System 5.0 or later. To configure your server for alerts, use
BMC Remedy Administrator as described in the following procedure.
To configure a server to send alerts

1 In BMC Remedy Administrator, select the server you want to configure, and
open the Server Information dialog box.
2 Click the Server Ports and Queues tab, and perform the following steps:
a In the Alert Outbound Port field, enter the port number that the server
will use when sending alerts.
If you enter zero (0), the server will use random port selection.

Configuring
b Configure the Alert queue to adjust the minimum and maximum threads.
For more information, see “Server information—Server Ports and Queues
tab” on page 149.
3 Click the Timeouts tab, and in the Alert Send Timeout (seconds) field, enter
the number of seconds the server will wait during connection attempts
before timing out.
4 Click the Configuration tab, and perform the following steps:
a Select the Verify Alert Users check box to have the server verify at boot-up
time that each of the users it thinks is registered is still running and
listening for alert messages.
b Select the Disable Alerts check box to have the server refrain from sending
alert messages when alert events are entered into the system.
5 If you want the server to translate IP addresses before sending alert messages
to users, edit the Map-IP-Address option in the ar.conf file, see “Map-IP-
Address2” on page 326.
The AR System Server Administration plug-in allows you to view and modify
the same AR System server information you would typically see in BMC
Remedy Administrator using AR System forms you access from BMC
Remedy User or from BMC Remedy Mid Tier.
This document contains the following sections:
Important: The AR System server on which this plug-in is installed must be

licensed.
Configuring a server for alerts 203

Configuring and using the AR System Server

Administration plug-in
The AR System Server Administration plug-in consists of a library file and a
deployable application. It is installed as part of the AR System server
installation. This section discusses configuring your AR System server to use
the Server Administration application and administering your AR System
server from AR System clients.
Configuring AR System to use the Server Administration

application
By default, deployable applications are imported in the Maintenance state.
When an application is in the Maintenance state, only members of the
Administrator group have permissions to use it. Before you change an
deployable application’s state from Maintenance to Test or Production, you
must map groups to roles to give users access to the application.
There are two roles defined in the AR System Administration application:
The AR System Admin Server Manager role is applied to the Server
Information form and the Delete Licenses button on the Add/Remove
Licenses form. Only users who belong to groups mapped to this role will
have access to these items.
The AR System Admin User Manager role is applied to Manage User
Licenses form. Only users who belong to groups mapped to this role will
have access to this form.
For more information about roles, groups, and application states, see the
Administering your server from AR System clients

You use the AR System Administration Console form to administer your
AR System server from an AR System client.
To administer your server

1 Open BMC Remedy User or BMC Remedy Mid Tier.

Configuring
2 Open the AR System Administration: Console form.

The AR System Administration: Console form displays links to various
administration forms.
Figure 5-25: AR System Administration Console
3 Click one of the following options:

(Under General area) Server Information to display the Server
Information form. See “Server Information form” on page 205.
(Under General area) Add/Remove licenses to display the Add/Remove
Licenses form. See “Add/Remove Licenses Form” on page 208.
(Under Application area) License Review to display the Manage User
Licenses form. See “Manage User Licenses Form” on page 209.
Note: The other links on this form are to forms that are already present in
your environment. The console provides a single location from which you
can access all the system forms in your environment.
Server Information form

When you click the Server Information button on the AR System
Administration: Console, the Server Information form appears.
Configuring and using the AR System Server Administration plug-in 205

Figure 5-26: Server Information form
The Server Information form contains the same tabs and fields and functions
the same as the BMC Remedy Administrator Server Information window.
See the Configuring AR System guide for more information.
Server Information form usage notes

This section provides notes on how to use the Server Information form.
Changing your server name alias
If you change your server name alias, make sure you supply the alias to the
DNS or enter the alias name in your hosts file. Otherwise, your AR System
server will not be able to connect to the plug-in server.
Specifying a password in a table
The edit masked option is not supported in tables on forms. Therefore, when
you type a new Password in the Password column in the tables on the
Connection Settings tab, they will be visible. Saved passwords will display as
masked. You can, however, type a masked password in any password
character fields.
Adding new entries to tables
To add a new entry in a table, you need only click in the empty space below
the last entry in the table and enter your data.

Configuring
Changing the number of rows in tables

By default, there are 10 rows available in these tables, including any rows
already filled in.
You can add more empty rows to a table by modifying the table qualification
‘RequestID’=”xxx”, where xxx is the number of rows you want in your table.
For example, see the table Selected Allowable Currencies on the Currency
Types tab. This table has been modified to have 20 rows by default.
Figure 5-27: Server Information—changing the number of table rows
Specifying source control information

On the Source Control tab, you cannot select a provider name or browse for
a project name. You must type these values in their respective fields. If you
need to use the select or browse capabilities, use BMC Remedy
Administrator.

Figure 5-28: Server Information—source control information
Type source
control
information
here.
Add/Remove Licenses Form

When you click the Add/Remove Licenses button on the AR System
Administration Console, the Add/Remove Licenses form appears.

Configuring
Figure 5-29: Add/Remove Licenses form
The Add/Remove Licenses form contains the same tabs and fields and
functions the same as the Add/Remove Licenses dialog box in BMC Remedy
Administrator.
Add/Remove Licenses form usage notes

When you are adding a new licence and you specify a date in the Issue Date
or Expire Date fields, use the AR System format appropriate for your locale.
Manage User Licenses Form

When you select License Review under the Application section in the
AR System Administration Console, the Manage User Licenses form
appears.

Figure 5-30: Manage User Licenses form
The Manage User Licenses form contains the same fields and functions the
same as the Manage User Licenses dialog box in BMC Remedy
Administrator.

Chapter
6 Working with the alert system
The alert system engages when a filter or escalation Notify action sends a
notification through the alert mechanism. This section describes the alert
system. The following topics are provided:
Alert system architecture (page 212)
Alert Events form (page 213)
Viewing alerts (page 214)
CleanupAlertEvents escalation (page 214)
Managing registered users (page 215)
Working with versions of the AR System prior to 5.x (page 215)
Enabling alerts on the Web (page 216)
For information about other methods of notification delivery, see the

Workflow Objects guide.
Working with the alert system 211

Alert system architecture

The alert system consists of the following components:
AR System server
Alert Events form
Alert list on BMC Remedy User or the Web
BMC Remedy Alert, an optional Windows program that informs users
when they receive new alerts (This program should not be confused with
the overall Alert system.)
Figure 6-1 shows how the alert architecture is structured.
Figure 6-1: Alert architecture
Creates and processes

AR System alert events through the
Alert Events form.
ALERT
Remedy User Remedy Alert Web Browser
Creates and processes Informs users when Displays alert list and
alert events through new alerts arrive. source requests.
the Alert Events form.
Note: Versions of AR System before 5.0 used a separate Notification server,

but now all alerts are processed on the AR System server. For information
about backwards compatibility, see “Working with versions of the
AR System prior to 5.x” on page 215.
For information about configuring servers for alerts, see “Configuring a

server for alerts” on page 202.
212 Chapter 6—Working with the alert system

Configuring
Tip: If you use BMC Remedy Alert on Windows, you might receive
unnecessary “Server is busy” pop-up messages. This is due to limitations
in Microsoft's COM implementation. To avoid this problem, set the OLE
Timeout user preference under the Desktop section of the ar.ini file. For
example:
OLE Timeout = 60 seconds
The default for the OLE timeout is 30 seconds. You might want to try a
longer timeout value.
Alert Events form

If you choose Alert as the notification method when creating a Notify action
for filter or escalation, alerts are recorded as new requests in the Alert Events
form (Figure 6-2) when that workflow executes.
Figure 6-2: Alert events form
The Alert Events form is automatically installed on your server. This form
contains the alert message details and identification information about the
source request.
The Alert Events form and its original fields cannot be deleted. To make the
feature more powerful, you can add new fields and workflow to the form.
Alert Events form 213

Users do not interact directly with this form; they receive alerts through the
alert list in BMC Remedy User or through the Web.
Viewing alerts
The alert list in BMC Remedy User or on the Web displays alerts from
multiple servers. The alert list queries the Alert Events form on servers in to
which the user is logged for BMC Remedy User. For web clients, the alert list
queries servers that are configured in the mid tier. For more information, see
“Enabling alerts on the Web” on page 216.
Users can manage the alert list, and open the source request. They can view
alerts in the following ways:
In BMC Remedy User, choose Tools > View Alerts.
In a browser, display a form that contains an alert list field. This method
requires special configuration. For more information, see “Enabling alerts
on the Web” on page 216.
From BMC Remedy Alert, open the alert list in BMC Remedy User or the
browser. For information about BMC Remedy Alert, see BMC Remedy
Alert help.
If a web user has access to multiple forms that have alert list fields, BMC
Remedy Alert uses the first of those forms that appear in its form list.
Therefore, if the user has permission to multiple forms, you cannot always
predict which form will be used. To solve this issue, you can create multiple
forms with alert fields if every group in the system can access only one of the
forms. This option allows you to create forms with different workflow and
different fields for different groups.
CleanupAlertEvents escalation
The CleanupAlertEvents escalation is automatically created with the Alert
Events form. If enabled, this escalation deletes all alerts that are older than 30
days and are unread.
Initially, the CleanupAlertEvents escalation is disabled. You can enable it and
customize it according to your needs. If you do not need the escalation, you
can delete it from the server.

Configuring
Managing registered users

For the alert system, the AR System server maintains a list of registered users
in memory and a backup copy in the database (in the alert_user table). All
persistent information is stored in the database, so you can back up and
replicate the environment easily.
Versions of AR System prior to 5.0 kept this information in the nfylogin and
nfylogu files.
Working with versions of the AR System prior to 5.x

Be aware of the following implications when you upgrade clients or servers.
Upgrading the server but not the clients

An upgraded AR System server can service previous notification clients such
as Remedy Notifier. It supports the RPC calls that older clients make. When
an older notification client registers to receive notifications, the server
queries the Alert Events form for any unsent notifications. The AR System
server sends alerts (notifications) to the client in the same format that the
older notification server did.
When using Remedy Notifier to log in to a 5.x AR System server, the user
must select the Ntfy Svr option of the Accounts dialog box, even though there
is no Notification server. If a specific Ntfy TCP port is specified, it should be
the same as the port number for the AR System server. If you are going
through a firewall, also specify a listen port within the notification client, as
needed.
Upgrading or installing clients but not the server

When new BMC Remedy Alert clients are installed, they cannot connect to
previous Notification servers. The users must install Remedy Notifier to
receive notifications from servers prior to 5.0. If necessary, Remedy Notifier
and BMC Remedy Alert can be run on the same machine in a mixed
environment.
Managing registered users 215

Enabling alerts on the Web

Users who receive alerts can open the alert list on the Web instead of in BMC
Remedy User. To enable alerts on the Web, you must provide a web-based
alert list, and you must set (or instruct users to set) certain user preferences.
You can also install BMC Remedy Alert on Windows clients for additional
functionality.
An Alert List form is automatically installed with your server installation.
You can add this form to your web-based applications, or create your own
alert list for the Web as described in the following procedure.
To create and publish a web-based alert list

For more information about how to perform each of the following steps, see
the Form and Application Objects guide and the Installing and Administering
BMC Remedy Mid Tier guide.
1 Create a regular form on one server in your AR System installation where the
mid tier is also installed.
2 Add an alert list field to the form.
3 Make this form accessible on the Web through a URL.
Alternately, users can open the alert list form from BMC Remedy Alert. For
more information, see “To install BMC Remedy Alert and configure web
settings (optional)” on page 217.
To enable a preference server for the Web

1 Make sure that one server in your AR System installation is defined as a
preference server.
For more information about preferences, see Chapter 3, “Setting user
preferences,” and the Installing guide.
2 Under General Settings in the BMC Remedy Mid Tier Configuration Tool,
enter the name of the preference server used by alert system users.
See BMC Remedy Mid Tier Configuration Tool help for more information.

Configuring
To configure user preference values for alerts on the Web

1 Open the AR System User Preferences form in BMC Remedy User.
2 For each user, set the following preferences.
These preferences are available on the Web view or on the Web tab of the
Default Administrator view of this form. For more information about
centralized preferences, see “Setting centralized preferences on web clients”
on page 102.
a In the Alert Servers field, enter the name of each server (separated by
commas) from which users receive alerts.
Alerts from these servers will be visible in the Web-based alert list. Users
do not need to be logged in to these servers to receive alerts or to display
the originating request.
b In the Refresh Interval field, enter the number of minutes between each
automatic refresh of the alert list. A setting of 0 indicates no refresh
interval.
Each server specified under Alert Servers will be queried for new alerts,
and these alerts will be displayed in the Web-based alert list.
To install BMC Remedy Alert and configure web settings (optional)

1 Install BMC Remedy Alert on Windows clients, according to the procedures
in the Installing guide.
See BMC Remedy Alert help for information about BMC Remedy Alert.
2 Start BMC Remedy Alert and open the Options dialog box according to the
procedures in BMC Remedy Alert help.
3 In the Alerts tab, select Open Alert List Using Web.
4 In the Server field, enter the name of the AR System server containing the
alert list form.
5 In BMC Remedy Administrator, open the server specified in step 4.
6 Open the Server Information window and select the Advanced tab.
7 In the Default Web Path field, specify the URL for the mid tier, such as
http://<host>/<contextpath>.
For example, if your host name is myserver and you used default settings
when installing the mid tier, the default web path is http://myserver/arsys.
Enabling alerts on the Web 217

When the user clicks the Open Alert List button in BMC Remedy Alert, the
system locates the form containing the alert list field on the server specified
in step 4, and opens it in the browser. If more than one form on the server
has an alert list field, the system opens the first form that it finds.

Chapter
7 Importing data into AR System

forms
BMC Remedy Import is a separate tool installed with BMC Remedy

Administrator and is designed to load data from a source file into an
AR System form. A command line interface is also available for both
Windows and UNIX. See Integrating with Plug-ins and Third-Party Products
for information about AR System client CLIs.
Understanding the import process (page 220)
Preparing to import (page 222)
Defining BMC Remedy Import preferences (page 225)
Importing data (page 237)
Using a saved mapping file (page 243)
Using the import log file (page 244)
Note: This section explains how to import data. BMC Remedy Import does
not import object definitions to a server. For information about exporting
and importing definitions, see the Form and Application Objects guide.
Importing data into AR System forms 219

Understanding the import process

The import process loads data from a file into an AR System form. To import
data into a form, you must create a mapping that determines which pieces of
data to import into which fields on the target form (mapping), and configure
BMC Remedy Import to handle the import appropriately. This section
describes import concepts, and provides instructions for preparing to import
and performing an import operation.
Understanding data mapping

Mapping takes place during the import process. You can map all fields in a
data file to all fields in a form, or you can map fields individually. You must
map data the first time you import a specific data file into a specific form.
You can also define fallback mappings, which are default mappings that
direct the BMC Remedy Import response if a data mapping problem occurs
during an import. Fallback mappings are used when the data value is invalid
for the destination form field type. For example, if there is a problem while
mapping a value, the fallback mapping for the field is used, if one is defined.
If there is no fallback mapping, an error is generated. If there is a fallback
mapping and the fallback mapping fails, errors are generated on the original
failed mapping, not the fallback mapping.
The fallback mapping is not used when the error can only be detected by the
AR System server, such as when the data is not an acceptable value. For
example, the fallback mapping is not used if the data value is outside the
range set for the form field, or if a required field has a NULL value.
You can save mappings for future use. If you regularly perform a particular
import, saving the mapping saves time and reduces errors, because you load
the mapping file instead of entering the mapping values again. When you
save a mapping, all of the following import information is saved: the form
name, the server the form resides on, the data file name, fallback mappings,
and preferences.
220 Chapter 7—Importing data into AR System forms

Configuring
Understanding preferences
Preferences determine tool behavior such as how BMC Remedy Import is
displayed on the screen, and import behavior such as how BMC Remedy
Import resolves conflicts during an import operation.
Preferences can be stored in either of two locations. If you have access to a
preference server, preferences are stored in the AR System Administrator
Preference form on the preference server. If you do not use a preference
server, preferences are stored in the ar.ini file.
When you perform an import, the current preferences will determine how
BMC Remedy Import handles your data. You should verify that the current
preferences are appropriate for the import being performed before you map
the data or save the mapping file. This is important because the preferences
are set in the mapping file when you save it.
When you load a saved mapping file, the preferences specified in the
mapping file take effect. In other words, while a saved mapping file is loaded,
BMC Remedy Import reads preferences from the mapping file instead of the
ar.ini file or the preference server. The next time you log in to BMC Remedy
Import, the preferences from the ar.ini file or the preference server are
restored.
If you change preferences while you have a mapping file loaded, you must
save the mapping file again to save the new preferences for that mapping.
For more information about local and central preferences, see Chapter 3,
“Setting user preferences.”
Understanding the import process 221

Preparing to import
Before you import data into AR System with BMC Remedy Import, complete
the following tasks:
Define BMC Remedy Import preferences. Preferences are saved together
with data mappings (if you save your mappings), so set the preferences
before you save the mapping. See “Defining BMC Remedy Import
preferences” on page 225.
You might want to set different preferences for different import
operations. In that case, open the source data file and the target form first,
and then specify preferences for that particular import. Save the mapping
file according to step 10 on page 242 to save the preferences for that
particular import.
Make sure that there is adequate space where the import log file will reside.
BMC Remedy Import writes error messages and failed records to a log,
which can become quite large. See “Using the import log file” on page 244
for more information. The default import log path is
<ar_home_dir>\import.log. To specify another path, see “To define
desktop preferences” on page 226.
Make sure that there is adequate space in the database into which the
records will be imported. Contact your database administrator for
assistance.

Configuring
Export the source data to a file compatible with BMC Remedy Import.
Complete all edits on the data file before you start BMC Remedy Import.
Do not edit the data file between the time you open BMC Remedy Import
and the time you start the actual import operation. The following table
describes the supported data types.
File Format Information

AR Export (.arx) Default AR System data file type.
Created in BMC Remedy User or the artext utility
designed primarily for localization. To create an
AR Export file, see BMC Remedy User help, or see
the Form and Application Objects guide for
information about artext.
AR XML (.xml) XML file conforming to the AR XML data
specification. Contains several elements that are
required for AR System use. See the C API Reference
guide for more information.
Created in BMC Remedy User or the artext utility
designed primarily for localization. To create an AR
XML file, see BMC Remedy User help, or see the
Form and Application Objects guide for information
about artext.
XML files created outside AR System must conform
to the AR XML data specification. Data exported to
the AR XML file type in BMC Remedy User
conforms to this specification. For more
information, see the Installing and Administering
BMC Remedy Mid Tier guide.
Preparing to import 223

File Format Information

CSV (.csv) Comma-separated value file.
Created in BMC Remedy User, another application,
or the artext utility designed primarily for
localization. For information about exporting a CSV
file in BMC Remedy User, see BMC Remedy User
help. For information about creating a CSV file with
artext, see the Form and Application Objects guide.
Carriage returns are treated as the end of the record.
ASCII (.asc) Generic ASCII file, created in BMC Remedy User
with particular settings, or in another application. To
export an ASCII file from BMC Remedy User, see
BMC Remedy User help.
To use ASCII data obtained from a non-AR System
source, save the data with a unique separator string of
up to 32 characters in length. Use \t for tab, \b for
backspace, and \\ for \. Use this separator string
when you open a data file to import, as described in
step d on page page 239.
Carriage returns are treated as the end of the record.
Note: You will not be able to import .asc data that
uses special characters as column separators.
Unique separator strings should not appear in any
of the field names as well as the data. This will
prevent problems with incorrect numbers of fields
when importing.
Note: When an attachment is exported in AR Export format (*.arx) or

AR XML format (*.xml), a directory is created to store the attachment. The
attachment directory is created in the same directory as the *.arx or .xml
file. The file name is appended with an integer time stamp, like this: myfile_
917732184.arx. The .arx or .xml file contains the directory name and the
names of the attachment files in it. If duplicate names exist, prefixes are
added to the attachment names to create unique file names. Attachments
cannot be used with CSV and ASCII file types.

Configuring
Defining BMC Remedy Import preferences

Preferences define important tool behaviors, described in the following table.
For best results, verify that the settings are appropriate before you import
data. Preferences are saved with the data mappings when you save a mapping
file.
Preference Function
Desktop Defines the appearance and behavior of BMC
Remedy Import.
Duplicate Request ID Defines how BMC Remedy Import processes
records that contain request IDs, which duplicate
those already in the form.
Error Handling Defines how records that contain errors are
processed.
Data Defines how data and values contained in the
source data file are processed.
Date/Time Defines the date and time format of the data in the
source data file.
Confirmations Defines the warnings, messages, and alerts
displayed during imports.
To use preferences from a saved mapping file, see “Using a saved mapping
file” on page 243.
All preferences are defined in the Preferences dialog box, as described in the
following procedure. Additional procedures describe how to set each
preference.
To access the BMC Remedy Import preferences dialog box

1 Start BMC Remedy Import.
The main BMC Remedy Import window appears.
2 Choose File > Preferences.
The Preferences window appears (Figure 7-1 on page 226).
Defining BMC Remedy Import preferences 225

Figure 7-1: BMC Remedy Import Preferences dialog box—Desktop tab
3 Follow the remaining procedures in this section to set preferences.
To define desktop preferences

1 Select the Desktop tab in the Preferences dialog box, and set the following
preferences:
Maximize Application If the check box is:

Cleared (default)—The application window opens
to the same size and position it was when it was last
closed.
Selected—The application window is maximized
when you start the application.
Show Status Bar If the check box is:
Selected (default)—A status bar is displayed at the
bottom of the application window, showing the
progress of the current operation.
Cleared—The status bar is hidden.
Show Tool Bar If the check box is:
Selected (default)—A toolbar containing buttons
that correspond to various menu selections is
displayed.
Cleared—The toolbar is hidden.

Configuring
Save Window Position If the check box is:

and Size on Close Selected (default)—The application window opens
to the same size and position it was when it was last
closed.
Cleared—The application window opens to the
default size and position.
AR Path This path identifies the directory where mappings are
saved, <ar_home_dir>\arcmds by default. You can
browse to a directory or enter the path manually.
Multiple paths must be separated with a semicolon (;).
Paths specified here are populated in the Save Mapping
dialog box. See Figure 7-10 on page 242.
Import Log File This path identifies the directory and file name of the
BMC Remedy Import log,
<ar_home_dir>\arimport.log by default. Error
details and records that fail during import are written
to this log. Failed records are those that cannot be
imported for some reason. The log file identifies these
records along with error messages. See “Using the
import log file” on page 244 for information.
You can only specify one import log in this field.
However, each import can use a separate log. To
specify a different log for each import, save a mapping
for the import, which saves this path. When you begin
an import, specify the log for the new import and save
a mapping for the new import. When you load a
mapping, the import log path you specified will direct
BMC Remedy Import to write to the specified log.
Mappings are defined in the section “Understanding
data mapping” on page 220.
Reset Log File at Login If the check box is:
Selected (default)—The import log is cleared each
time you start BMC Remedy Import.
Cleared—New entries are appended to the existing
file. The file can grow quite large.
2 Continue with the remaining procedures to set additional preferences, or

click OK to close the Preferences dialog box.

To define duplicate request ID preferences

1 Select the Duplicate Request ID tab in the Preferences dialog box.
Figure 7-2: BMC Remedy Import Preferences dialog box—Duplicate Request ID tab
2 Set the following preferences:
Generate New ID for All Default setting.

Records New request IDs are assigned to all requests in the data
file, whether or not any IDs are duplicates. This
preference also generates request IDs for records that
do not already have them, for example, in a CSV file
created outside AR System.
Reject Duplicate Records Entries are imported using their existing IDs. If an ID is
already in use, an error is generated. The error is
processed according to your preferences. See “To define
error handling preferences” on page 229.
Generate New ID for Entries are imported using their existing IDs. If a record
Duplicate Records with the same ID already exists in the database, a new
ID is generated for the imported record with the
duplicate ID.

Configuring
Replace Old Record with Entries are imported using their existing IDs. If a
New Record duplicate ID exists, the entire database record is
overwritten with the record being imported. You must
map the required core fields with this option. If
required core fields are not mapped, the server will
reject the records. For information about mapping, see
“Importing data” on page 237. For information about
core fields, see Chapter 7, “Importing data into
AR System forms.”
Update Old Record with Entries are imported using their existing IDs. If a
New Record’s Data duplicate ID exists, only the fields being imported are
replaced, merging the record.
Note: If you choose this option, BMC Remedy Import
actually deletes the record and then reinserts it to
perform the “update.”
This setting also automatically makes all required fields
that are not core fields optional. See “To define data
preferences” on page 232 for more required field
preferences. For information about core fields, see
Chapter 7, “Importing data into AR System forms.”

To define error handling preferences

1 Select the Error Handling tab in the Preferences dialog box.

Figure 7-3: BMC Remedy Import Preferences dialog box—Error Handling tab
2 Set the following preferences:
Alert User with Popup Interrupts the import and displays an error message
Dialog (default). The message contains three choices.
Yes—Skips the problem record, writes the error and
the record data to the import log, and continues to
import remaining records.
Yes to All—Skips all problem records that generate
the same error, writes the error and the records to
the import log, and continues to import remaining
records.
Stop Import—Stops the import and prompts you
to copy all remaining data to the import log.
See “Using the import log file” on page 244 for more
information.
Skip Bad Records Skips problem records without displaying an error
message, and continues with the import.

Configuring
Try Fallback Mapping If a mapping generates an error, BMC Remedy Import

before Alerting User uses the fallback mapping specified in the Fallback
Mappings preferences. If the fallback mapping also
generates an error, a message is displayed. The error is
generated against the original mapping error. Errors
are not generated against fallback mappings. Refer
also to “To define error handling preferences” on
page 229.
Import Records with Too Defines how AR System imports records that contain
Many Fields more fields than described by the field titles in the data
file. The system checks each record individually. If the
check box is:
Cleared (default)—The problem records are not
imported and an error is generated. The error is
processed according to your preferences. See “To
define error handling preferences” on page 229.
Selected—The problem records are imported and
the extra fields are ignored.
Import Records with Too Defines how AR System imports records that contain
Few Fields fewer fields than described by the field titles in the data
file. The system checks each record individually. If the
check box is:
Cleared (default)—The problem records are not
imported and an error is generated. The error is
Selected—The problem records are imported with
NULL values in the missing fields.


To define data preferences

1 Select the Data tab of the Preferences dialog box.
Figure 7-4: BMC Remedy Import Preferences dialog box—Data tab
Note: These settings are affected by field attributes set when fields are
defined. See the Form and Application Objects guide.

Configuring
2 Choose one of the following options for character fields:
Remove leading and If the check box is:

trailing spaces and tabs Cleared (default)—Values are imported exactly as
they appear in the data file.
Selected—All leading and trailing white space is
removed from each field imported.
Truncate strings exceeding If the check box is:
field limit Cleared (default)—Fields whose contents are too
long generate an error. The error is processed
according to your preferences. See “To define error
handling preferences” on page 229.
Selected—Fields that are too long are truncated.
Disable fields' pattern Defines if pattern matching is enforced by the server
matching during import during the import operation. If the check box is:
Cleared (default)—Records are rejected by the
server if data in the field does not match the
specified pattern. An error is generated. The error is
Selected—Records are imported, even if the data in
a field does not match the specified pattern.
3 For required fields that are not core fields, choose the following option:
Make required fields Defines required fields that are not core fields as
optional during import optional during the import operation. If the check
box is:
Cleared (default)—All required fields are treated as
required. If a required field has a NULL value, an
error is generated. The error is processed according
to your preferences. See “To define error handling
preferences” on page 229.
Selected—Required fields that are not core fields
are not enforced. NULL values are allowed in
required fields.


To define date and time preferences

1 Select the Date/Time tab of the Preferences dialog box.
Figure 7-5: BMC Remedy Import Preferences dialog box—Date/Time tab
BMC Remedy Import accepts short or long date formats in the data file, and
ignores leading zeros.
2 Select the appropriate options.
Calendar Type The default Gregorian calendar is the only choice.

Short Date Format If you select:
M/d/yyyy—12/31/05 (default) is displayed.
d/M/yy—31/12/05 is displayed.
yy/M/d—05/12/31 is displayed.
The sample text shows how the selected format
appears. The component order is based on the
Regional Settings in the Windows Control Panel.
Separator Defines the separator character between the month,
(Date Format) day, and year, with a slash (/) as the default. You can
use any character that is not part of the field
separator string for the data file. The sample text
shows the appearance.

Configuring
Long Date Format If you select:

dddd, MMMM d, yyyy—Tuesday, December 31,
2004 is displayed.
dddd, d MMMM, yyyy—Tuesday, 31 December,
2004 is displayed.
dddd, yyyy MMMM d—Tuesday, 2004 December
31 is displayed.
dddd, MMMM dd, yyyy (the default)—Tuesday,
December 31, 2004 is displayed.
The sample text shows the appearance. The
component order is based on the Regional Settings
in the Windows Control Panel.
12 Hr Tracks in the 12-hour clock (default setting).
24 Hr Tracks in universal time.
AM/PM position Enabled for 12 Hr only. If you select:
Suffix (the default)—The symbol is positioned
after the time string (for example, 10:23:47 AM).
Prefix—The symbol is positioned before the time
string (for example, AM 10:23:47).
AM symbol Enabled for 12 Hr only. Defines the symbol that will
indicate morning.
PM symbol Enabled for 12 Hr only. Defines the symbol that will
indicate afternoon.
Separator Defines the time format separator between the
(Time Format) hours, minutes, and seconds, with a colon (:) as the
default. You can use any character that is not part of
the field separator string for the data file. The sample
text shows the appearance.
3 Continue with the remaining procedure to set additional preferences, or click

OK to close the Preferences dialog box.

To define confirmation message preferences

1 Click the Confirmations tab of the Preferences dialog box.
Figure 7-6: BMC Remedy Import Preferences dialog box—Confirmations tab
2 Select the appropriate options:
Confirm before deleting If the check box is:

all Mappings Selected (default)—Confirmation message appears
when you click Delete All in either the Import
window or Fallback Mappings dialog box.
Cleared—No confirmation message.
Confirm before losing If the check box is:
Mappings Selected (default)—You will be prompted to save
your work each time you select a new form or file or
exit BMC Remedy Import without first saving.
Cleared—No prompt.

Configuring

Fallback Mappings Selected (default)—You will be prompted to save
your work each time you create a fallback mapping,
and select a new form or file, or exit BMC Remedy
Import without first saving.
Cleared—No prompt.
New Mapping Value Selected (default)— Confirmation message appears
whenever you add or modify a mapping value
without clicking Add or Modify before exiting the
window or starting the import.
Cleared—No confirmation message.
3 Click OK.
Importing data
Importing data into a form involves loading a data file and a target form,
defining preferences for the import, and mapping data. To import data into
a form, you must have Change permissions for the fields to which you want
to import data. For system fields such as Create-date, you must be the
administrator or subadministrator of the form.
The following procedure provides instructions for each step of the process.
To import data
1 Start BMC Remedy Import.
2 Log in, if necessary, according to your defined preferences.
The BMC Remedy Import window appears.
Importing data 237

Figure 7-7: BMC Remedy Import window
3 Choose File > Open Form.

The Open Form dialog box appears.
4 From the Form Name list, select the destination form into which you want to
import the data.
5 Click OK.
The destination form field names appear in the Form Fields list.
6 Choose File > Open Data File.
The Open Data File dialog box appears.
Figure 7-8: Open Data File dialog box

Configuring
7 Identify the data file to import.

a From the Files of Type field list, select the file format.
Selecting All Files displays all data files, whether or not the formats are
valid import types. Selecting a data file with an invalid import format
generates an error.
b Navigate to the target data file and select it.
The file appears in the File Name field.
c If you chose CSV or ASCII as the file type, choose a title handling option:
If the first line of data contains titles, leave the File Contains Field Titles
check box selected so that BMC Remedy Import will not convert the titles
into data.
If the first line of data does not contain titles, clear this check box.
The check box is disabled for other file types.
d For ASCII format, enter the separator string you used when you created
the ASCII data file in the Field Separator field.
ASCII files must be generated with specific settings to be compatible with
BMC Remedy Import. See BMC Remedy User help for information about
separator strings.
e Click Open.
The fields from the data file are loaded.
Note: If the data file contains duplicate field titles, an error is generated. If the
data is .arx or .xml format, the field titles will appear as their field IDs. If
the data file is .csv or .asc format, the fields will display with an appended
number, as follows, <field_title> [1], <field_title> [2], and so forth.
8 Specify how the data in the source file will map to the fields in the destination
form:
Map all data file fields to form fields.
Map individual data file fields to form fields.
To map all data file fields, click Add All in the BMC Remedy Import
window.
Importing data 239

BMC Remedy Import matches data fields to form fields as follows:

AR Export or AR XML—Field IDs are matched first, and then field names
are matched for fields without matching IDs.
CSV or ASCII—Only field names are matched.
Be aware of the following tips when mapping all data file fields:
Make sure that all fields map correctly. If necessary, resolve unmatched or
incorrectly matched fields by mapping those fields individually.
If the matching is partially successful, all possible matches are added. To
complete the mapping, map remaining fields individually.
If no matches are found and no entries are left in the Form Fields list, an
error is generated. You can delete existing mappings and map fields
individually, or start the import with the partial mapping.
If no fields are mapped, an error is generated, and you must load a
mapping or map fields manually.
To map individual data file fields, perform the following steps:
a From the Form Fields list, select the destination field.
b In the Mapping Values section, select Import Fields or Keywords from the
selection menu.
A list of the fields in the data file or a list of keywords is displayed,
depending on your choice.
c Choose one of the following options:
From the Import Fields list, select the data field to map to the
destination field that you selected in step a. The field name appears in
the Mapping Value field.
From the Keywords list, select the keyword to map to the destination
field that you selected in step a. You can also type field names,
keywords, or any constant string into the Mapping Value field.
For example, suppose you select the Create Date field in the Form Fields
list, and you want each record in the destination form to have today’s
date as the value in the Create Date field. You would choose Keywords
as the mapping value, and then choose DATE in the Mapping Values
list. The resulting value in the destination form is the date of the import.
For more information about keywords, see the Workflow Objects guide.

Configuring
d Click Add to create the mapping.

e Repeat these steps for each field to be mapped.
Note: Map the Request ID field of the destination form. If you do not map
this field, you must set the Duplicate ID preference to Generate New IDs
for All Records, or you will receive errors.
9 Specify default field values, by defining fallback mappings, if desired.

a Choose Mapping > Define Fallback.
The Fallback Mappings dialog box appears, displaying the destination
form fields and a list of keywords.
Figure 7-9: Fallback Mappings dialog box
b From the Form Fields list, select the field for which you want to define a
fallback mapping.
The selected field appears in the Form Field field.
c Choose one or more keywords by performing one of the following actions:
Select a keyword from the Keywords list.
Enter a string or keyword into the Fallback Mapping Value field.
Importing data 241

Enter multiple keywords by separating each value with a space or other

character.
d Click Add.
The mapping is added to the list. You can edit or delete one or more
mappings using the Modify, Delete, and Delete All buttons.
10 Optionally, save the mapping.
a Choose Mapping > Save Mapping.
The Save Mapping dialog box appears, as shown in Figure 7-10 on
page 242.
b Enter a name in the Mapping Name field.
c Enter the mapping directory in the Path field, by selecting a directory from
the list (the AR Path defined in the Desktop preferences), selecting Browse
to choose a directory, or typing a path.
d Optionally, enter a description of the mapping in the Help Text field.
Figure 7-10: Save Mapping dialog box
e Optionally, select the Save Log Filename check box.

When you select this box, the log specified in this procedure is set in the
Import Log File field in the Desktop preferences when you load this
mapping.
f Click OK to create the mapping.
You are now ready to start the import.
11 Choose Import.
A confirmation dialog box appears.

Configuring
12 Click Yes to start the import.

A status window appears, listing the number of records processed. Each
record in the data file generates a single request in the destination form.
If errors occur, the type of messages you receive depends on the error
handling preferences you set. See “To define error handling preferences” on
page 229.
After the import ends, a results message appears and the import log is
updated. You can use your imported data. To inspect the log, see “Using the
import log file” on page 244.
Note: You can stop the import before it ends. You are prompted to copy
unprocessed records to the log. There must be enough disk space in the
import log partition to copy the records.
Using a saved mapping file

If you have saved a mapping file from a previous import, you can load that
mapping file instead of entering mapping information again.
Mappings save the BMC Remedy Import preferences currently set at the time
the mapping is created, so if you load a mapping file, BMC Remedy Import
will use the preferences that were set when you saved the mapping file. You
can change preferences as needed and save the mapping file again.
The next time you start BMC Remedy Import, the preferences you set for the
application are restored.
BMC Remedy Import reads and writes mappings in PC format, with CR LF
at the end of each line.
To load a mapping
1 Choose Mapping > Load Mapping.
The Load Mapping dialog box appears.
Using a saved mapping file 243

Figure 7-11: Load Mapping dialog box
2 From the Search Path field, select the directory that contains the mapping.
Selecting All lists all saved mappings and their directories.
3 From the Mappings list, select the mapping.
The directory containing the selected mapping appears in the Mapping Path
field.
4 Click OK.
The mapping is loaded into the Import window, the Fallback Mappings
dialog box, and Preferences dialog box.
Using the import log file

BMC Remedy Import writes errors to the import log, whether or not you set
error messages to display on screen. The default path is
<ar_home_dir>\arimport.log, however, you can specify another directory or
file name in the preferences. See “To define desktop preferences” on
page 226.
The import log contains more detail than displayed messages. With AR
Export, CSV, and ASCII file types, failed records are also written intact to the
import log. You can convert the import log to a data file that you can import.
See the following sections for details.

Configuring
AR XML data
To write XML (*.xml) data from AR XML records to the import log, you
must use the Alert User with Popup Dialog preference setting, as described
in “To define error handling preferences” on page 229. This setting stops the
import and copies the records to the file.
You can inspect the import log file to determine which records caused errors,
and make corrections in the original AR XML data file. You can then import
the corrected AR XML data file. With AR XML files, XML data from the
record is written to the log file, but the structure of the record is not retained
in a way that allows the log file to be converted to an import file.
All other data types

After the import is complete, open the import log to identify problems. You
can then either correct the data in the log and convert the log to a data file
that you can import, or correct the original data file and import the file again.
If you edit the original data file, delete any data that was imported
successfully during the original import from the file to avoid creating
duplicate entries.
To import data from the import log

1 If the import is not complete, stop the import and copy the remaining
records to the import log.
2 Open the import log (<ar_home_dir>\arimport.log by default).
3 Remove all nondata information (all lines except DATA lines) from the import
log. For CSV and ASCII file types, go to step 5.
4 For AR Export (.arx) file types only: Copy the following lines of code from
the data file to the import log (these lines appear at the beginning of the data
file): FORM, FIELD, FLD-ID, DTYPES
5 Save the edited import log as an AR Export (*.arx) file.
6 Import this AR Export (*.arx) file.
Using the import log file 245


Chapter
8 Using full text search
This section discusses the capabilities, performance, and administration of

the full text search (FTS) feature. The following topics are provided:
Overview of full text search (page 248)
Who can perform a full text search? (page 250)
Using FTS (page 250)
Limitations of FTS (page 264)
Administering FTS (page 265)
Upgrading FTS (page 274)
Assigning FTS licenses to users (page 276)
Defining a field for FTS in the Field Properties window (page 277)
Note: Full text search is an optional feature that you can purchase for the
AR System server.
Using full text search 247

Overview of full text search

Full text search (FTS) is an important and useful feature of AR System. FTS
is typically much faster than using the native database searching functionality
when searching in a long text field. It is also the only method available in
AR System for searching text within attached documents.
A benefit of FTS is that you can make use of your knowledge base. For
example, FTS enables you to access your company’s history of solving
problems, which are sometimes stored in long text fields or attachments.
With the FTS option, you can easily search through long text fields to find
solutions to related problems. You might even want to redesign forms to
require users to enter data into diary or long text fields. You can then build
up a knowledge base that helps you learn from previous experience.
FTS provides quick and consistent access to AR System requests for which
you are searching. The FTS accrue operator presents the best solutions to
your search first by using a weighted order. The accrue operator enables you
to use multiple search terms in a search; for example, computer, PC, and error
number 3794. Requests that contain the most search terms appear higher on
the list (if ordered in descending order of weight) and are more likely to
contain the information for which you are looking. In contrast, if a database
OR search yielded 20 requests, you must look through all 20 requests because
you would not know which requests contain what information. For more
information, see “Accruing and weighting results with FTS” on page 249.
FTS solves many problems that users encounter when performing database
searches, including:
Searching long text and attachment fields. The FTS option enables you to
index character, diary, and attachment fields for searching, and then
matches entries from those fields against the search criteria you specify.
Like database indexes, an FTS index can greatly decrease the time required
for a database search.
Improving search performance by searching large volumes of data. FTS
organizes text in a way that typically provides quicker access than
relational databases.
Defining how the server interprets wildcards to customize search
performance to your specific needs.
Performing case-insensitive searches. Administrators can enable or
disable case sensitivity.
248 Chapter 8—Using full text search

Configuring
Ranking search results according to their relevance to the search criteria.

The more relevant a search result is, the higher the weight assigned to it
will be. For more information, see “Accruing and weighting results with
FTS” on page 249.
Accruing and weighting results with FTS

Weighting the results of an accrue search is a powerful FTS feature. FTS does
not limit you to searches for keywords in fields indexed for FTS. You also can
use a special accrue operator (the LIKE operator with comma-separated
words, for example) to cause AR System to accrue and retrieve from the
database all requests that contain any or all of the comma-separated words.
Requests that are retrieved in an accrue operation are assigned a weight by
the FTS engine. Weight is a number that varies from 0 to 100. With weight,
AR System can sort requests in a results list using a “the more, the better”
approach. If you set the Field Sort Order in BMC Remedy User to include
WEIGHT in descending order, the more search terms found in a request, the
higher in the list it appears in the set of retrieved requests. The closer Weight
is to 100, the better it matches the search criteria.
For more information about modifying results list attributes to include FTS
weights, see “Displaying FTS weight in a results list” on page 279.
Sorting requests by weight

In BMC Remedy User, if WEIGHT has been added to the results list for a
form, users can sort the requests that are retrieved by FTS by weight in
descending or ascending order by selecting WEIGHT and the sort order in
the Field Sort Order window. For more information about setting the sort
order, see BMC Remedy User help.
Using the Ignore Words List

You can configure the FTS engine to ignore frequently used words (such as
and, the, because, and so on) or words that you do not want indexed. Adding
entries to the Ignore Words List saves space in the FTS index and speeds up
text searches. The FTS option comes with a default set of ignored words that
you can modify as needed.
Overview of full text search 249

Accrue searches that contain words from the Ignore Words List do not find
any matching AR System requests for those words. However, the accrue
search retrieves requests for the other search terms. For restrictions on FTS,
see “Limitations of FTS” on page 264.
Note: The Ignore Words List is different for each supported language.
Who can perform a full text search?

Users must have a fixed or floating FTS license to use the FTS capability. FTS
licenses are separate from AR System read/write licenses.
If users are assigned a fixed FTS license, they can always perform a search
in a field indexed for FTS.
If users are assigned a floating FTS license but one is not currently
available, they receive a warning the first time they perform a database
operation in BMC Remedy User. The system uses the search capabilities
of the underlying database (to the degree available). Upon a subsequent
search, when a floating license becomes available, an affected user is
alerted with a note and can perform a search by using the FTS capability.
For more information about who can use full text search, see “Assigning FTS
licenses to users” on page 276.
Using FTS
FTS is transparent to users who have an FTS license (fixed or floating). If
there is at least one FTS fixed or floating license in the AR System server, full
text indexing will be activated.
If an FTS license is available and the field is indexed for FTS, then FTS is
used.
If an FTS license is unavailable or the field is not indexed for FTS,
AR System uses the search capability of the underlying database. Under
these conditions, attachment fields will have only their names searched.
Field permission-related behavior for FTS fields is the same for non-FTS
fields.

Configuring
Users enter search criteria in the same way, whether they are using FTS or
not, with the exception of accrual searches.
Performing a search in a field indexed for FTS

In most cases, performing a qualified search on a field indexed for FTS
returns results consistent with a database search. Users can still use the search
strings and search patterns with which they are already familiar. FTS offers
additional benefits. For example, if your database does not support case-
insensitive searches, FTS can provide that capability. Unlike some databases,
the FTS engine enables you to index and search large text fields for any words
in the entire field. Users will notice enhanced search performance with large
text fields because of this indexing capability. Also, FTS enables you to index
attached documents, allowing the contents of supported document types to
be searched quickly and efficiently.
The search method used by the FTS engine depends on the following factors:
The original search criteria as entered by the user
The QBE match settings of the field
The FTS Search Options setting of the server
The type of full text index created for the field
FTS uses these factors to determine the final search criteria. Succeeding
factors override preceding factors. For example, if a user includes a leading
wildcard as part of a full text search, but the FTS Search Options setting is set
to Ignore Leading Wild Card, FTS ignores the wildcard entered by the user.
See “How QBE settings affect FTS” on page 260 for more information.
The FTS engine uses the final search criteria to search the contents of all
requests indexed for that field, and it uses one of three search methods:
Word or Phrase search
Accrue search
Literal search
Note: All the following examples use FTS in the Advanced Search Bar, not
QBE. They assume that the FTS Search Option is set to Query Unchanged.
Using FTS 251

Word or Phrase search

During a word or phrase search, the FTS engine finds requests that contain
the specified word or phrase in the field. To perform a word or phrase search,
use double-quotation marks around the words you want to search for. The
syntax for the search qualification is:
<field> LIKE "<word1> <word2> <…wordN>"
For example, if you want to search for the phrase “firewall blocked”, type:
<field> LIKE "firewall blocked"
With this example, a full text search will find requests with the phrase
“firewall blocked” with the search for blocked expanded to the word stem
block with any of its variants.
Note: The use of wildcards in a Word or Phrase search affects how stemming
is used. For more information about stemming, see “Searching for word
stems” on page 259.
The following table outlines the expected search results using a word or
phrase search.
Qualification Example data Matches

<field> LIKE “firewall firewall blocks access x
blocked”
firewall will block access
firewall blocking my x
access
firewall blocked her x
access
firewall did not block
access
have the firewall block x
access
firewall is not working
try blocking his access

Configuring

<field>LIKE“%firewallblock%” firewall blocks access x
firewall will block
access
access
access
access
access
<field>LIKE“%firewallblocks%” firewall blocks access x

firewall blocking my access
firewall blocked her

access
access
have the firewall block
access
Using FTS 253


<field> LIKE “blocks” firewall blocks access x
firewall will block access x
access
access
firewall did not block x
access
access
try blocking his access x

<field> LIKE %blocks%” firewall blocks access x
firewall will block
access
firewall blocking my
access
access
access
access
Accrue search
During an accrue (OR) search, the FTS engine finds requests that contain any
of the specified words in a field, instead of matching a string of characters.
The FTS engine matches the pattern of the characters specified in the search.
To perform an accrue search, use double quotation marks around the words
you want to search for, separating the words with a comma. The comma is
the accrue operator. The syntax for the search qualification is:
<field> LIKE "<word1>,<word2>, <...wordN>”

Configuring
For example, if you wanted to search for the words “firewall” and “blocked,”
enter:
<field> LIKE “firewall,blocked”
With this example, a full text search will find requests with any occurrence of
the words firewall or blockedwith the search for blockedexpanded to the word
stem block with any of its variants.
Note: You can use the accrue operator only with fields indexed for FTS.
Using the same operator for a field that is not indexed for FTS causes the
AR System server to search for the literal string with a database search.
The following table shows the expected search result using an accrue search.
<field> LIKE firewall blocks access x
“firewall,blocking”
firewall blocking my access x
firewall blocked her access x
firewall did not block access x
have the firewall block access x
firewall is not working x

try blocking his access x
<field> LIKE firewall blocks access x
“firewall,blocked%”
firewall blocking my access x
firewall blocked her access x
firewall did not block access x
have the firewall block access x

Using FTS 255

Literal search
Unlike accrue or word/phrase searches (which are word-based), the FTS
engine uses a literal search to find requests that match the string of characters
based on the contents of the entire field. Literal searches are possible only if
the field has been indexed for literal searching and if it is, only literal
searching is possible, not accrue or word/phrase searches. This type of
searching is useful mainly for performing case-insensitive searching on short
character fields, like name fields, with a very small set of requests matching
the search criteria. However, you can add either a leading or trailing wildcard
to increase the scope of a literal search. If you use both a leading and trailing
wildcard, a literal search becomes the equivalent of a word/phrase search.
The syntax for the search qualification is:
<field> LIKE “<string_to_be_searched_for>”
For example, to search for the word “firewall,” enter:

<field> LIKE “firewall”
With this example, a full text search will find requests where the entire
content of the field is firewall (or Firewall if searching with case insensitivity).
The following table outlines the expected search results using a literal search.

<field> LIKE “firewall” firewall blocks access
access
access
access
access

Configuring

<field> LIKE “firewall will firewall blocks access
block access”
firewall will block x
access
access
access
access
access

<field> LIKE “%firewall%” firewall blocks access x
access
access
access
access
Using FTS 257


<field> LIKE “firewall%” firewall blocks access x
firewall will block x
access
access
access
access
access
<field> LIKE “blocks” firewall blocks access
firewall will block

access
access
access
access
access

Configuring

<field> LIKE “%blocks%” firewall blocks access x
firewall will block
access
access
access
access
access
Searching for word stems

The FTS engine handles searching for common variations of word stems. For
example, performing a word search with the term “block” will return
requests with:
block
blocks
blocked
blocking
Searching with “blocking” will return the same set of requests, provided that
wildcards are not used. If the search term is “%blocking%”, only requests
containing “blocking” will be returned.
Using wildcards
You can also use the percent sign (%) wildcard for any type of search to
broaden the set of matching requests. For example searching with the term
“%fire" will return requests with “fire” and “backfire”. Searching with
“fire%" will return requests with “fire" and “firewall”. Searching with
“%fire%” will return all combinations.
Using FTS 259

Using the QBE method

Searches performed by the QBE method are affected by the QBE Match
property for the field. If the property is not set to Equal, appropriate
wildcards will be added to the search terms automatically. If the property is
set to Equal, you must add the appropriate wildcards to the search terms.
Note: Attachments cannot be searched with the QBE method unless a special
Form Search field is present on the form. For more information, see
“Adding a form search field to a form” on page 261.
How QBE settings affect FTS

Enter a query by example (QBE) in any field indexed for FTS, according to
the following syntax:
left,center,right
However, be aware that the property settings influence how an accrue search
works, as shown in the following table.
QBE Match property setting Effect on search criteria

Anywhere %left,center,right%
BMC Remedy User adds wildcards to the start
and end of the search. The server makes a special
interpretation of these search criteria for a full
text search and places a leading and trailing
wildcard around each search term. For example:
%left%,%center%,%right%

Configuring
QBE Match property setting Effect on search criteria

Leading left,center,right%
BMC Remedy User adds a wildcard to the end of
the search. The server makes a special
interpretation of these search criteria for a full
text search and places a trailing wildcard after
each search term. For example:
left%,center%,right%
Equal left,center,right
BMC Remedy User does not add any wildcards
to the search string, but it uses the EQUAL (=)
operator instead of the LIKE operator. This has
no effect on the server’s full text search.
Using the advanced search bar method

Searches performed by the advanced search bar method are affected by the
FTS Search Options setting for the server. Otherwise, the search qualification
is exactly as specified.
Adding a form search field to a form

The AR System has a special reserved field that can be used on a form to
provide a shortcut method for specifying expanded FTS qualifications. If a
display-only field with field ID 178 is added to a form, that field can be used
to search all full text indexed fields on a form with an expanded OR search.
For example, if fields Description and Worklog on a form have been indexed
for FTS and the user performs a QBE search by supplying the search term
“firewall” in field 178, the qualification generated will be:
'Description' LIKE "firewall" OR 'Worklog' LIKE "firewall"
On a form where a single attachment field is the only field indexed for FTS,
this feature can also be used as a method for providing a QBE search for the
attachment field. Otherwise, only the advanced search bar method is
available for searching attachments.
Important: Use caution when labeling this field, so users do not get the
impression that using this field will search all fields on the form. The
feature searches only fields indexed for FTS.
Using FTS 261

Note: This feature is available only from version 7.0 or later clients. For
environments with pre-7.0 clients, it is recommended that you hide this
field for those clients using client-side workflow when $VERSION$ < " 7"
(there is an intentional blank space in front of the 7). If the field is visible
and used in pre-7.0 clients, the qualification will not be sent to the server
(unbeknownst to users), potentially resulting in an unqualified query.
Also, for users without a full search text license, the AR System server will
return an error if a qualification is provided in this field.
Parametric full text search

Returning a large result set is a common issue with a search system. With a
parametric full text search, a user can restrict the search criteria by
combining FTS and non-FTS fields in a search. This feature helps the server
filter out irrelevant entries and dramatically reduce the size of the result set.
This can be accomplished by providing search terms in multiple fields for a
QBE search or specifying an advanced search like the following example:
:<FTSfield> LIKE "firewall" AND 'Create Date' >= "01/01/06"
This advanced search bar search will return all entries that contain the search
term “firewall” and were created on or after January 1, 2006.

Configuring
Search strategies
When searching field for which FTS is enabled, consider the following tips
and strategies:
Make your searches as specific as possible. The more qualified your
searches are, the better the indexes can be utilized to return only the most
relevant entries. A smaller result set will produce a quicker response time.
Remove common words from accrue searches. For example, if you use the
accrue operator with five search terms and the search yields hundreds of
requests, delete the most generic terms from the search criteria to focus
your search on a smaller result set.
When using the advanced search bar, group references for FTS fields at the
beginning of the search criteria.
Search issues
Keep the following issues in mind when creating searches:
Full text searches that involve a field reference to the right of the relational
operator are not supported. A warning message occurs which indicates that
the query was treated as a database query instead of an FTS query. The
presence of ‘Target’ in the following example returns the warning message if
the Short Description field is indexed for FTS:
'Short Description' LIKE 'Target' + "ing"
If there are no variables to the right of the LIKE keyword in the statement,
FTS handles the search. For example:
'Short Description' LIKE "block" + "ing"
In this example, the search is handled by FTS because the two known values
(“block” and “ing”) are combined to form one known value (blocking).
Using FTS 263

Limitations of FTS
Limits to performing a full text search include:
In accrue searches, you cannot search for most punctuation marks
because they are treated as word separators.
In accrue searches, do not use words from the Ignore Words List. For
example, if the word the is in the Ignore Words List, searching on the
phrase the, database, request in the Short Description field might return
requests with the word the in them, but it is not used in the search itself.
For additional information about the Ignore Words List, see “Using the
Ignore Words List” on page 249.
In searches that use FTS, submitted or modified requests might not appear
immediately in the results list if you are searching on a field enabled for
FTS. There is sometimes a short delay from the time the request is
submitted or modified in the database to the time that the request is
available for searching in the FTS index.
On a server running in the English locale in the ISO-8859-1 character set,
words can contain only the following characters, if they are to be indexed
under FTS:_ABCDEFGHIJKLMNOPQRS
TUVWXYZabcdefghijklmnopqrstuvwxyz0123456789$%#@.
On a server running a locale of other Western European languages in the
ISO 8859-1 character set, words can contain only the following characters,
if they are to be indexed under FTS:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghij
klmnopqrstuvwxyzäöüßÄÖÜåÅ>>øØàÀáÁâÂèÈéÉëËêÊìÌíÍïÏîÎòÒóÓùÙ
úÚñÑûÛçÇôÔýÝðÐãÃõÕÞþ€0123456789$%#@.

Configuring
Administering FTS
This section describes how to administer FTS in AR System.
Note: Using FTS in a server group requires you to perform additional

configuration.
Selecting fields for FTS indexing

You can only index character, diary, and attachment fields for FTS. Index
only fields that are frequently searched, such as work diaries and descriptions
of problems, especially if the underlying database does not support searches
of these fields.
For example, you could perform a search for one or more keywords in a diary
field that would retrieve and weigh all AR System requests that describe how
to solve a problem suggested by those keywords. You would perform a search
on keywords or phrases such as:
Forms, tools, screens, and hardware and software products
Descriptions of problems or solutions
Other areas of interest
When you define a field as indexed for FTS, it might take some time before
that field is available for searching if there are existing entries in the form.
Indexing a field can take several hours, depending on the amount of data in
that field, the system load, and other factors. While a field is being indexed
for FTS, you can still do non-FTS searches on that field if the underlying
relational database permits it. To index a field for FTS, see “Defining a field
for FTS in the Field Properties window” on page 277.
For each field that you index for FTS, the amount of disk space required for
the FTS index can grow significantly. To estimate approximately how much
space is required for your FTS index, see “Estimating the size of the FTS
index” on page 278.
Do not define fields for FTS during normal production hours, especially if
you have many AR System requests in your database. Indexing uses database
and AR System server resources, which can have a significant impact on the
performance of your system.
Administering FTS 265

Full text search indexing

AR System uses the arserverd process (arserver.exe on Windows) to insert
or delete data in the FTS indexes. Threads from the Full Text Indexing queue
perform the indexing. This queue has one thread by default and more threads
can be configured if desired. For more information, see “Defining queues
and configuring threads” on page 153.
The indexing mechanism is based on an offline model, where indexing tasks
are recorded in a system table (ft_pending) in the database during the
originating transaction. The originating transaction typically involves a
create entry, set entry, merge entry, or delete entry operation on a form where
a field indexed for full text search exists.
A full text dispatcher thread processes the indexing tasks in real-time on a
first-in, first-out basis, queuing them for indexing threads to process. There
is no scheduled indexing task like there might be in a traditional search
system. As a result of this indexing model, the performance of the originating
transaction is affected only marginally by inserting the indexing task record
into the system table, and is not subject to delays associated with full text
indexing. However, the data might not be immediately available for
searching. The size of the delay depends on the size of the indexing queue and
the availability of system resources to perform the indexing.
If indexing is disabled by the administrator, indexing tasks are still recorded,
preserving the changes for later inclusion when indexing is enabled.
Indexing for attachments

Indexing for attachments is selected on a per-field basis, not by attachment
pool. Therefore, it is possible to index only some of the attachment fields in
a pool. The advantage to indexing only some of the attachment fields can be
found in the choice of designating (and appropriately naming) “buckets” for
attachments that are likely to have value when indexed, as opposed to those
that will not. The system will attempt to index any attachment that gets
placed into an attachment field indexed for FTS. Attachments with
unsupported data formats will not be indexed successfully. By guiding users
to place attachments in the appropriate “buckets,” the system can be spared
unnecessary processing.

Configuring
Note: If you index an attachment that has an unsupported format,

AR System only indicates that occurrence in the Full Text Indexer log. For
more information about this log, see the Optimizing and Troubleshooting
guide.
Multiple languages and attachment file formats

With some special considerations for attachment fields, the full text feature
can index any content where the character set is compatible with the
AR System server’s character set. If the AR System server is running as a
Unicode server, the full text feature has no restriction on the encoding format
of the data content. Content in multiple languages can be indexed and
searched.
With a non-Unicode AR System server, the data content must be compatible
with the server’s character set. When indexing and searching attachments
with common formats, such as Microsoft Office documents and PDF
documents, the full text feature can process the data without a dependency
on the server’s character set. For plain text files, the full text feature requires
that the server recognize the character set of the data.
Reindexing
Most of the time, you should not have to rebuild your FTS indexes because
the AR System server periodically optimizes them after AR System requests
are added, changed, or deleted. If you make changes to your Ignore Words
List, you will need to rebuild the FTS indexes (reindex). See “Full text search
indexing” on page 266.
If you change the Case Sensitivity setting, you will need to rebuild the FTS
indexes, and the reindexing is started automatically when the change is saved.
To rebuild the index for a specific field, you must deselect the field for
indexing on the Database Properties tab of the Field Properties window, save
the change, reselect the field for indexing, and save the change.
Note: After upgrading FTS from version 6.0 or earlier, you must reindex FTS
to complete the FTS index upgrade process.

Time required to rebuild a set of indexes

Do not rebuild indexes during normal production hours. Because reindexing
rebuilds your entire set of FTS indexes from scratch, it can take a long time,
depending on the following factors:
The number of fields selected for full text search
The amount of data in each field indexed for FTS in each AR System
request
The system load
Whether your indexes are on NFS-mounted or local directories
For more information about locating your FTS indexes, see “Estimating the
size of the FTS index” on page 278.
After modifying the Ignore Words List

When you modify the Ignore Words List and do not reindex, your changes
affect only entries that are inserted, deleted, or modified after that time. For
example, if you added network to the Ignore Words List, the FTS index
ignores the word network only for AR System requests added or modified
from this time forward. However, the FTS index with the word network
would still exist for all requests created before the Ignore Words List was
modified.
When you reindex all the fields in all your forms that are currently flagged as
indexed for FTS, you create a new FTS index that then ignores the word
network in all requests. To change the Ignore Words List, see “Using the
Ignore Words List” on page 249.
Note: After modifying the Ignore Words List and before reindexing,
automatic index optimization will not work because the search engine
detects that the Ignore Words List has changed. This does not affect the
integrity of the index, but error messages will be produced by the search
engine and recorded in the error log. Do not take any actions as a result of
these errors, other than reindexing.

Configuring
FTS configuration options

This section outlines the configuration options for FTS from the Full Text
Search tab of the Server Information window.
Figure 8-1: Full Text Search configuration options
The following options are available:

Disable Full Text Searching—Controls whether or not the server uses the
full text search engine for searching. When disabled, the server uses the
search capability of the underlying database, whether or not a user has a
full text license.
FTS Collection Directory—The location in the file system where search
engine index files are stored.
FTS Configuration Directory—The location in the file system where
search engine configuration files are stored.

FTS Temp Directory—The location in the file system where search engine
temporary files are stored. This directory needs to be periodically cleaned
of the temporary files that accumulate.
Indexing Failure Recovery Interval—Defines the number of minutes the
server waits between periodic attempts to index entries that failed to index
for an unexpected reason in a prior attempt. The default value is 60
minutes.
Temporary Table Threshold—During the processing of search results, the
server will create a temporary table if the number of FTS matches reaches
this value. If the number of FTS matches is under this value, the server will
use the SQL IN operator for a query on an existing table. The default value
is 200.
Complex Search Threshold—During the processing of search results, the
server will combine results from sub-queries to arrive at the final result set.
If the number of rows created during processing exceeds this value, the
server will return an error message indicating the search is too complex.
The default value is 1,000,000.
Indexer Optimization Threshold—The number of additions,
modifications, or deletions that must occur before the server will optimize
an index. The default value is 1000. The minimum value is 10.
Optimization improves the time it takes to search with an index, but can
be an intensive operation.
Case Sensitivity—Defines whether full text searching is case sensitive or
case insensitive. This setting affects all fields indexed for full text search
and affects how the indexes are built. Therefore, changes to this setting
will trigger an automatic reindex. The default value is case insensitive.
Search Options—Defines how the server modifies qualifications received
from the client. The choices are:
Force Leading & Trailing Wildcards
Ignore Leading & Trailing Wildcards
Ignore Leading Wildcard
Remove Leading & Trailing Wildcards
Query Unchanged (default)

Configuring
Reindex—Initiates the reindexing of all fields selected for full text

indexing. This check box will be disabled if a reindex is in progress. The
dialog box must be redisplayed for the check box to become active
following completion of the reindexing.
Disable Full Text Indexer—Controls whether or not the server processes
indexing tasks that are pending. When disabled, indexing tasks are still
recorded for processing at a later time when indexing is enabled.
Ignore Words List—Defines which words are ignored during indexing.
When this button is clicked, a dialog box appears, from which you can add
words or upload a text file from your computer that contains a list of
words.
Debugging FTS
All debug tracing for full text indexing is logged in the <ar_install_dir>/db/
arftindx.log file. See “Full text index logging” for information about how
to turn on this logging. Entries in this log file represent the operations
performed by the full text dispatcher and indexing threads, including the
commands sent to the search engine for modifying the indexes.
All debug tracing for full text searching is logged in the <ar_install_dir>/
db/arsql.log file, sharing the file with database logging. See “SQL logging”
on page 272 for information about how to turn on this logging. Entries in this
log file that represent search engine activity are prefixed with FTS:. All other
entries represent database
FTS logging
There are two types of logging you can use to help you analyze FTS-related
processing: full text index logging and SQL logging.
Full text index logging

Full text index logging records all full text indexing operations, but not full
text searching operations. When you enable full text index logging,
descriptions of all indexing operations are recorded to the log file.
To enable indexing logging

1 In BMC Remedy Administrator, select a server to administer and choose
File > Server Information.

Select the Full Text Index

check box.
3 Select Full Text Index check box.

4 In the File Name field, specify a log file name. The default log file name is
arftindx.log. The File Name is disabled until you select the related check
box.
5 Click OK.
SQL logging
AR System SQL logging records all full text searching operations, but not full
text indexing operations. When you enable SQL logging, descriptions of all
FTS operations are recorded to the SQL log file.

Configuring
To enable SQL logging

1 In BMC Remedy Administrator, select a server to administer and choose
File > Server Information.
Select the SQL

check box.
3 Select the SQL check box.

4 In the File Name field, specify a log file name. The default log file name is
arsql.log.The File Name is disabled until you select the related check box.
5 Click OK.

Upgrading FTS
Upgrading of the full text search option from AR System version 6.0 and
earlier is a complete replacement that involves the following tasks:
Installing the new search engine and designating key directories for search
engine files.
Obtaining new full text search licenses of types BMC Remedy AR FTS
Fixed and BMC Remedy AR FTS Floating.
Determining if any attachment fields are appropriate for full text search
and selecting those fields for indexing.
Reviewing the fields already selected for indexing. After the search engine
is installed and licenses are in place, a list can be generated by turning on
Full Text Indexer logging, restarting the AR System server, and viewing
the configuration information at the beginning of the log file. A review is
important to verify that existing selections add searching value to your
system. Those that do not should not be text-indexed, to save system
resources.
Building new indexes that are compatible with the new search engine by
reindexing all fields selected for full text search. This might take a
considerable amount of time.
Removing files associated with the previous search engine. The following
files and directories from your previous FTS installment can be removed.
Important: Be sure to back up existing directories and files before removing

them.
The <AR Server installation directory>\ ftindex subdirectory
The <AR Server installation directory>\common\arfts or <AR

Server installation directory>\Arserver\common\arfts
subdirectory
The <AR Server installation directory>\Arserver\common\_nti40
subdirectory
The following files in the <AR
Server installation directory>\db or
<AR Server installation directory>\Arserver\db :
arftp.lst

Configuring
arftinp.lst
The following files in the <AR Server installation directory> or <AR

Server installation directory>\bin or <AR Server installation
directory> \common\*\bin:
loc_xlt.*
xlt_fn.*
vdk200.*
arservftd or arfts.exe
Upgrading FTS 275

Assigning FTS licenses to users

To perform a full text search, users must be assigned a fixed or floating FTS
license. You specify the type of license that users have through their request
in the User form, as you would with their AR System write licenses.
To license a user for FTS

1 Open the User form in BMC Remedy User.
2 Search the database for the user who you want to license for FTS and open a
window.
Figure 8-4: User form
3 Select the Full Text License Type option for the type of FTS license that you
want the user to have, whether fixed or floating.
4 Click Save.
If you issued the user a fixed FTS license, a confirmation message appears.
5 Click OK to acknowledge the message.
If you do not have an available FTS license, or you do not have FTS capability,
you will receive an error message.

Configuring
Defining a field for FTS in the Field Properties window

Use the Field Properties window to create an FTS index of text in character,
diary, or attachment fields. Do not define fields for FTS during normal
production hours, especially if you have many AR System requests in the
forms for which you are defining FTS fields.
Note: The Index For FTS check box does not appear for servers that are not
licensed for the FTS option or for field types that are not valid for full text
search.
To define a field for FTS

1 Open the Field Properties window.
2 Click the Database tab.
Figure 8-5: Database tab in Field Properties window
3 Select the Index For FTS check box.
Defining a field for FTS in the Field Properties window 277

4 Select the Literal Index check box if the field is defined for literal (whole field)
searching. The search engine builds a different type of index for this type of
searching, so it must be specified at design time. The literal index option is
available only for character fields of 32767 or fewer characters.
AR System begins to index the field for FTS.
The FTS index for a field is automatically updated and does not require
manual administration when you create, delete, or modify requests.
Estimating the size of the FTS index

Place the FTS index in a directory that has sufficient disk space. The directory
must be large enough to accommodate at least two times the amount of data
that is indexed for FTS. For example, if the total amount of data in all fields
you want to be indexed for FTS in all forms is 100 MB, then at least 200 MB
of disk space is required for the indexes. This example of determining the size
of an FTS index is an approximation only.
To estimate the size of the FTS index

Use this procedure to determine approximately how much disk space is
occupied by the FTS index.
1 Estimate the size of text in your database.
For example, take a small sample of requests and calculate the average size of
data in the field. Then multiply this average by the number of AR System
requests to derive the size of text in your database.
2 Use a minimum number of 2 as a multiplier.
The ratio of the size of the FTS index to source text can differ widely based
on, for example, the size of your Ignore Words List.
If the estimated size of text is 100 MB, the FTS index occupies at least 200 MB
of disk space: 100 MB * 2.0 = 200 MB as the lower boundary of the FTS index
and 100 MB * 2.5 = 250 MB as the upper boundary.

Configuring
Displaying FTS weight in a results list

In the Results List Fields tab of the Form Properties dialog box, you can
configure results lists to display the FTS weight for all requests retrieved.
To display FTS weight in a results list:

1 In BMC Remedy Administrator, open the form for which you want to define
the results list format.
2 Choose Form > Form Properties.
The Form Properties dialog box appears.
Figure 8-6: Form Properties dialog box
3 Click the Results List Fields tab.

4 From the Fields in Form list, select WEIGHT.
5 If necessary, specify a Separator and Width.
6 Click Add.
7 Click OK to save your results list definition.
Defining a field for FTS in the Field Properties window 279

The Weight field displays the weighted value of retrieved AR System requests
when you create a results list in BMC Remedy User. If sorted by descending
weight, the requests are listed in order, based in a relevance factor calculated
by the search engine.
8 Save the form.

Appendix
A Working with the Request ID

field
Follow the procedures in this section to improve the performance or enhance

the security of your AR System environment.
Working with the Request ID field (page 282)
Note: These procedures address the most commonly requested AR System

technical information. For access to the complete set of AR System
technical information and procedures, visit the Customer Support website
at http://www.remedy.com.
Working with the Request ID field 281

Working with the Request ID field

Every form defined in AR System contains a set of core fields. The Request
ID field is one of those core fields and has a unique field ID of 1. You can
change the label of this field to something other than Request ID, but the field
ID will always remain 1.
The Request ID field contains a character string that holds a unique index for
each request. The form of this string is an optional prefix, which can consist
of any alphanumeric characters, followed by a 0-padded numeral (for
example, HD0000000000001). The length of the Request ID field must be either 1
or between 5 and 15 characters, inclusive. Specifying a length of 1 causes
leading zeroes to be stripped from the value in the Request ID. The prefix can
be as long as the total length of the field less five characters.
When new requests are submitted, AR System generates a new ID for the
request by appending the next available ID to the prefix, if a prefix is
specified. Then, AR System increments the next available ID in preparation
for the next request to be submitted.
The Request ID field contains a unique number sequence. Create other fields
to contain information that is specific to your site instead of using the
Request ID field. Overloading the Request ID field with other information
can restrict your ability to control this data and limits the flexibility of
searches on the data.
Sometimes, it is necessary to work with the Request ID value or the Request
ID field in the database. The following section contains these topics:
“Changing the next available ID for new requests” on page 283.
“Changing the Request ID field length or prefix” on page 285.
“Preserving existing Request ID field values” on page 286.
“Changing existing Request ID field values to a new format” on page 286.
“Updating the Request ID field in other AR System tables” on page 296.
282 Appendix A—Working with the Request ID field

Configuring
Changing the next available ID for new requests

You can change the next available ID when creating new AR System requests.
This ID is used to automatically generate the unique index number that is
attached to each AR System request. Under some conditions, you might need
to reset the next available ID. For example, you might need to establish
different ranges for a similar form on two different servers, or you might
need to reserve a range of numbers for later use.
Note: Do not change the next available ID to a number lower than the
greatest existing ID. The Request ID field value must be unique within
AR System, and resetting the ID to a lower number could conflict with
existing Request ID field values. If you try to submit a request with an
existing ID, AR System will return an error and prevent the request from
being submitted until the conflict is resolved.
If you must change the next available ID, make the change when the system
is not in use to avoid conflicts with users who are submitting new requests.
Changing the next available ID for SQL databases
To change the next available ID for a form in an SQL database

1 Stop AR System server.
2 Using any front-end tool that allows direct access to an SQL database, log in
as a user with write access to the AR System tables.
3 Connect to the AR System table area.
4 Find the Request ID field for the form you want to modify.
5 Update the next available ID.
6 Restart the AR System server.
Example SQL database procedures

The following sections are examples of how to change the next available ID
for DB2 Universal, Informix, Oracle, and Microsoft SQL and Sybase
databases. In these examples, the next available ID for a form named ZZZ is
changed from the current value of 1291 to a new value of 25000.

DB2 Universal database example

>open DB2 command center
Connect to AR System.
>select name, nextId from arschema where name = 'ZZZ';
NAME NEXTID
--- -------
ZZZ 1291
1 row(s) retrieved.
>update arschema set nextId = 25000 where name = 'ZZZ';
1 row(s) updated.
Informix database example
% dbaccess - -
>database ARSystem;
Database selected.
>select name, nextId from arschema where name = 'ZZZ';
name nextId
ZZZ 1291
1 row(s) retrieved.
>update arschema set nextId = 25000 where name = 'ZZZ';
1 row(s) updated.
><Control-C>
Oracle database example
% sqlplus
Enter user-name: ARAdmin
Enter password: <password> (AR#Admin# by default.)
SQL>select name, nextId from ARAdmin.arschema where name ='ZZZ';
NAME NEXTID
------------------------------ ----------
ZZZ 1291
SQL>update ARAdmin.arschema set nextId = 25000 where name = 'ZZZ';
1 row updated.
SQL>Commit;
commit complete
SQL>exit
Microsoft SQL Server and Sybase database example
% isql -Usa
Password: <password>
1>use ARSystem
2>go
1>select name, nextId from arschema where name = 'ZZZ'
2>go
name nextId
ZZZ 1291

Configuring
------------------------------ ----------
(1 row affected)
1>update arschema set nextId = 25000 where name = 'ZZZ'
2>go
(1 row affected)
1>exit
Changing the Request ID field length or prefix

After using a form for a while, you might need to change the prefix or length
of the Request ID field, the key field in a form. Often, this change can be made
and existing requests can retain the format used previously. However, you
might need to convert existing Request ID field values to match the new
prefix or length. This section offers background information and procedures
to help you make changes to the Request ID.
To change the length of the request ID field

1 Log in to BMC Remedy Administrator as a user with administrator access.
2 Open the form you want to alter.
3 Double-click the Request ID field.
The Field Properties dialog box appears.
4 Click the Database tab and specify the desired length in the Input Length
field.
Note: The length of the Request ID field must be either 1 or between 5 and
15 characters, inclusive. If you specify 1, leading zeroes are stripped from
the value the Request ID field. If you specify a prefix for the Request ID
field, the field must be at least five characters greater than the prefix.
5 Save the changes to the form.
To change the prefix of the request ID field

1 Log in to BMC Remedy Administrator as a user with administrator access.
2 Open the form you want to alter.
3 Double-click the Request ID field.
The Field Properties dialog box appears.
4 Click the Attributes tab.

5 Specify the desired prefix in the Default Value field.
Note: The Request ID field must be between 5 and 15 characters in length. If

you specify a prefix for the Request ID field, the field length must be at
least five characters greater than the prefix.
6 Save the changes to the form.
Preserving existing Request ID field values

You might want to preserve the existing Request ID field values of your
AR System requests for the following reasons:
Backward compatibility—You might have cross-references that see
requests by the Request ID field value.
History—The Request ID field values were created with the old format,
and there is no need for change.
Design—The design of your AR System calls for periodic change to the
Request ID field. For example, you might use the current year as a prefix
for the Request ID field.
No data—No requests have been submitted, so there are no Request ID
fields to be converted.
Changing existing Request ID field values to a new format

You might want to change the values of existing Request ID fields for your
AR System requests for any of the following reasons:
Consistency—All the Request ID field values for a form follow the same
format. If the format changes, all the requests change to match the format.
Design—The design of your AR System has changed, and this design
references the new format of the Request ID field. This is usually a change
of the length of the field from a default setting of 15 to something shorter,
and you need to eliminate the extra leading zeros.
This section explains two methods of updating existing Request ID field
values:
“Using an AR Export (.arx) file” on page 287.
“Using SQL commands to shorten the Request ID field” on page 289.

Configuring
After implementing one of the strategies in this section, read “Updating

status history tables” on page 296 and “Updating attachment tables” on
page 297.
WARNING: Back up your database before performing the actions described in

this section to make sure your original data is saved if there is a failure
during the update.
Using an AR Export (.arx) file

You can edit AR Export (.arx) files regardless of the database underlying
your AR System. You can use the .arx strategy or a different strategy that
bypasses AR System to operate directly in the database.
To change the existing Request ID field format through an AR Export

file
1 In BMC User, open the form you want to change.
2 Choose Tools > Reporting.
The Report dialog box appears.
3 Choose Report > New or double-click << New Style >>.
The Properties - << New Style >> dialog box opens.
4 Click Add All to add all the fields to the report style.
5 Select the Request ID field under Selected Fields and move it to the top of the
list.
6 Choose Report > Export To > File and use .arx format to save all the data for
the form to a file.
7 Close the Report dialog box.
8 Edit the file to change the format of the Request ID field. See “Editing the .arx
file” on page 288.
9 In BMC User, delete all requests in the form.
10 Close BMC User.
11 Open BMC Remedy Import.

12 Choose File > Open Import File.

The Open Import File dialog box appears.
13 Select the file you edited, and click Open.
14 Choose File > Open Form.
The Open Form dialog box appears.
15 Select the form you want to change and click OK.
16 Click Add All.
17 Choose File > Preferences.
The Preferences dialog box appears.
18 Click the Data tab. Disable fields’ pattern matching and make required fields
optional during import by selecting the check boxes.
19 Click the Duplicate Request ID tab, and select the Reject Duplicate Record
option.
20 Click OK to close the Preferences dialog box.
21 Choose Import to start the import process.
Editing the .arx file
After the first few header lines, the remaining lines in the .arx file have the
following format:
DATA "000000000000001" "<other_data>" 1 "<other_data>"
where <other_data> is data from the form.

The Request ID field always follows the keyword DATA. In this example, the
Request ID field has no prefix and is 15 characters in length. Use a text editor,
such as WordPad, to convert the format of the Request ID field.
The following procedures show how you can shorten a Request ID field with
a length of 15 characters to 10 characters and add a prefix of ABC.
To edit the .arx file in Windows

1 Open the .arx file in a text editor that has a Find/Replace command with a
feature for matching case (for example, WordPad).

Configuring
2 Use the Find/Replace command to search for DATA "00000000.
Note: This command contains 8 zeros. Five of these represent the difference
between the original length of 15 characters and the new length of 10
characters. The other 3 zeros represent the spaces to be replaced by ABC.
3 Use the match case feature.

4 Replace all instances of DATA "00000000 with DATA "ABC.
5 Save the changes to the file.
To edit the .arx file in UNIX

1 Open the file in a text editor.
2 Type the following command:
g /^DATA "00000000/s//DATA "ABC/
3 Save and close the file.
Using SQL commands to shorten the Request ID field

Only administrators running AR System with an SQL database can update
existing request ID field values by directly accessing the SQL database. The
syntax for direct access is different for each SQL database that AR System
supports. These commands are described in the examples in this section.
To use the methods described in this section, you must be familiar with basic
commands in the SQL command interface. SQL commands bypass
AR System completely. If you bypass AR System, verify that all data is valid
when you are finished.
Tip: Create a practice table in your database and practice the commands you
will issue to make sure that you are issuing the correct commands. Make
sure you back up your database or all the relevant tables.
Note: When you change the length of the Request ID field in a database table,
all related database tables, such as status history tables (H Tables), and
Attachment tables (B Tables and BC Tables) must also be updated.

Important: Stop AR System before you attempt any database modifications.
Finding the name of the table

Before you can shorten the request ID field value, you must find the table
holding the form being changed. To find the table name, you must know the
schema ID and, in some cases, the field ID of the field to be changed.
To find the table name, follow these basic steps:
Step 1 Find the correct schema ID for your form.
Step 2 Find the correct field ID for your field, if necessary.
Step 3 Construct the name of the table using the schema ID and field ID you found
in the previous steps.
To find the correct schema ID for your form

Perform the following query:
Select SchemaId, name from arschema order by 2
This query returns a list of schema IDs and associated form names.
To find the correct field ID (after you know the schema ID)
Perform the following query. This example assumes that the schema ID is
43:
Select FieldId, FieldName from field where SchemaId = 43
This query returns a list of field IDs and associated field names.

Configuring
To construct the name of a table from schema ID and field ID

Use the schema ID, field ID, and information in the following table to
construct your table name.
Table A-1: AR System table name constructs
Table name Description

T<schema_ID> A table that contains the data in your form. A
table named T43 indicates that 43 is the schema
ID.
T<schema_ID>C<field_ID> (Oracle only) Used for backward compatibility
with forms created using AR System versions
prior to 4.5. It is a table that contains long text and
diary data. For example, a table named
T43C536870924 indicates that 43 is the schema ID
and 536870924 is the field ID. In many cases, there
will be more than one long text or diary field on
the form.
H<schema_ID> A table that contains the Status History
information for your form. A table named H43
indicates that 43 is the schema ID. For more
information about the status history table, see the
Database Reference guide.
B<schema_ID> A table that contains a list of all the attachments
and related information for each record in your
form. A table named B43 indicates that 43 is the
schema ID. For more information about the
attachment tables, see the Database Reference
guide.
B<schema_ID>C<field_ID> A table that contains the actual Binary objects for
attachment fields in your form. A table named
B43C536870924 indicates that 43 is the schema ID
and 536870924 is the field ID. In this example, the
field ID for the attachment field is 536870924. In
some cases, there will be more than one
attachment field on the form.

Note: For T<schema_ID> and B<schema_ID> tables, the request ID column of

the table is always named C1. For the H<schema_ID> tables,
T<schema_ID>C<field_ID> tables, and B<schema_ID>C<field_ID> tables, the
Entry ID column is equivalent to the C1 column.
Changing existing Request ID field value format when the

Request ID has a prefix
The following examples assume that the table is named T43, that the prefix is
HD, and that the field size (including the prefix) will be 8 characters. The 6
represents the number of characters to keep, starting from the right side of
C1. C1 is originally 15 characters long. Make sure that the number of characters
in your prefix plus the second parameter in the RIGHT function is equal to the
new size of the C1 field.
DB2 database To add a prefix to the T<schema_ID> table, use the following syntax:
examples update T43 set C1 = 'HD' || RIGHT(C1, 6)
To add a prefix to the B<schema_ID> table, use the following syntax:

update B43 set C1 = 'HD' || RIGHT(C1, 6)
For the H<schema_ID> table, use the following syntax:

update H43 set entryId = 'HD' || RIGHT(entryId, 6)
For the B<schema_ID>C<field_ID> tables, use the following syntax:

update B43C536870924 set entryId = 'HD' || RIGHT (entryId, 6)
Informix In the following examples, the request ID is being shortened from 15 to 8

database characters. The prefix HD is concatenated to the last 6 characters in the string,
examples consisting of positions 10 through 15.
Note that for Informix databases, you must log in as the root user.
To add a prefix to the T<schema_ID> table, use the following syntax:
update T43 set C1 = 'HD'||C1[10,15]

update B43 set C1 = 'HD'||C1[10,15]

update H43 set entryId = 'HD'||entryId[10,15]

Configuring

update B43C536870924 set entryId = 'HD'||entryId[10,15]
Note: In the functions C1[10,15] and entryId[10,15], the 10 represents the

starting position of the characters to keep and 15 represents the ending
position.
Oracle To add a prefix to the T<schema_ID> table, use the following syntax:
database update T43 set C1 = 'HD'||substr(C1,10,6);
examples
update B43 set C1 = 'HD'||substr(C1,10,6);

update H43 set entryId = 'HD'||substr(entryId,10,6);

update B43C536870924 set entryId = 'HD'||substr(entryId,10,6);
For the T<schema_ID>C<field_ID> tables, use the following syntax:

update T43C536870924 set entryId = 'HD'||substr(entryId,10,6);
Note: In the functions substr(C1,10,6) and substr(entryId,10,6), the 10

represents the starting position of the characters to keep and the 6 is the
number of characters to keep.
Microsoft SQL To add a prefix to the T<schema_ID> table, use the following syntax:
Server and update T43 set C1 = "HD"+ RIGHT(C1, 6)
Sybase
database To add a prefix to the B<schema_ID> table, use the following syntax:
examples update B43 set C1 = "HD" + RIGHT(C1, 6)

update H43 set entryId = "HD" + RIGHT(entryId, 6)

update B43C536870924 set entryId = "HD" + RIGHT (entryId, 6)

Changing existing Request ID field value format when the

Request ID does not have a prefix
The following examples assume that the table is named T43 and that the field
size will be 8 characters. The 8 represents the number of characters to keep,
starting from the right side of C1. C1 is originally 15 characters long. Make
sure that the number of characters in the second parameter in the RIGHT
function is equal to the new size of the C1 field and that the sum of the two
numeric values in the SUBSTR function is 16 (1 greater than the original length
of C1).
DB2 database To add a prefix to the T<schema_ID> table, use the following syntax:
examples updcolate T43 set C1 = RIGHT(C1, 8)

update B43 set C1 = RIGHT(C1, 8)

update H43 set entryId = RIGHT(entryId, 8)

update B43C536870924 set entryId = RIGHT (entryId, 8)
Informix For Informix databases, you must log in as the root user.
database
In the following examples, the Request ID is being shortened from 15 to 8
examples
characters. The request ID will consist of the last 8 characters in the string,
consisting of positions 8 through 15.
To add a prefix to the T<schema_ID> table, use the following syntax:
update T43 set C1 = C1[8,15]

update B43 set C1 = C1[8,15]

update H43 set entryId = entryId[8,15]

update B43C536870924 set entryId = entryId[8,15]
Note:In the functions C1[8,15]and entryId[8,15], the 8 represents the starting

position of the characters to keep and 15 represents the ending position.

Configuring
Oracle To add a prefix to the T<schema_ID> table, use the following syntax:
database update T43 set C1 = substr(C1,8,8);
examples
update B43 set C1 = substr(C1,8,8);

update H43 set entryId = substr(entryId,8,8);

update B43C536870924 set entryId = substr(entryId,8,8);
For the T<Schema_ID>C<field_ID> tables, use the following syntax:

update T43C536870924 set entryId = substr(entryId,8,8);
Note: In the functions substr(C1,8,8) and substr(entryId,8,8), the first 8

represents the starting position of the characters to keep, and the second 8
is the number of characters to keep.
Microsoft SQL To add a prefix to the T<schema_ID> table, use the following syntax:
Server and update T43 set C1 = RIGHT(C1, 8)
Sybase
database To add a prefix to the B<schema_ID> table, use the following syntax:
examples update B43 set C1 = RIGHT(C1, 8)

update H43 set entryId = RIGHT(entryId, 8)

update B43C536870924 set entryId = RIGHT (entryId, 8)
Using SQL commands to lengthen the Request ID field value
The format for all the supported databases is the same for lengthening the
Request ID field format as with shortening the Request ID field format. See
“Using SQL commands to shorten the Request ID field” on page 289 for
hints about how to run the SQL interface, how to find the name of the table
to be changed, and how to exit the SQL interface.
Note: The maximum length allowed for the Request ID field is 15 bytes.

In the following example, the length of the field is restored to 15 characters

from the current 10 characters by adding 5 leading zeros to the existing value
of the Request ID field and assigning the resulting 15-character string to the
Request ID field. When you have determined the name of the table (T43 in the
example), issue the one of the following commands at the prompt:
DB2
% update T43 set C1 = '00000' ||C1
Informix
% update T43 set C1 = '00000' || C1
Oracle
% update T43 set C1 = '00000' || C1
Sybase and Microsoft SQL Server

% update T43 set C1 = '00000' + C1
If you want to add a prefix, specify the prefix as part of the string to be added.
For example, if you want to expand to 15 characters and add a prefix of ABC,
use 'ABC00' instead of '00000' in the preceding example.
Updating the Request ID field in other AR System tables

When you change the Request ID in a main data table, you must also
consider whether you need to make a similar change to the status history
table and attachment tables.
Updating status history tables

Status History information is stored in a separate table. This table uses the
Request ID field as the link to the main table. Accordingly, you use the same
procedure to change the Request ID field values in the status history table as
you do in other tables.
To update the status history table, use the commands described in the
previous examples, substituting H43 for T43 and entryId for C1. For more
information, see “AR System table name constructs” on page 291.
For more information about the status history table, see the Database
Reference guide.

Configuring
Updating attachment tables

Attachment information is stored in two tables, the Attachment Details table
and the Attachment Data table. The Attachment Details table holds
attachment characteristics, such as the name and size of the attachment, and
the Attachment Data table holds the actual attachment. These tables also use
the Request ID field as the link to the main table. Accordingly, you use the
same procedure to change the Request ID field values in the status history
table as you do in other tables.
The Attachment Details table is named with a B followed by the schema ID
(for example, B3). The Attachment Data table is named with a B followed by
the schema ID, followed by C, followed by the attachment field ID. For
example, the Attachment Data table might be called B7C536870920, where 7
is the schema ID, and 536870920 is the attachment field ID.
The column holding the Request ID in the Attachment Details table is named
C1, and in the Attachment Data table, it is named entryId. To update the
Request ID field in the attachment tables, use the commands described in the
previous examples, substituting the appropriate table name, and using C1 or
entryId for the Request ID. For more information, see “AR System table
name constructs” on page 291.
For more information about attachment tables, see the Database Reference
guide.


Appendix
B AR System configuration files
This section contains information about the AR System configuration files.

Each file name is listed by its UNIX name. Where it is different, the Windows
equivalent is listed in parentheses after the UNIX name.
ar (page 300)
ar.conf (ar.cfg) (page 300)
ardb.conf (ardb.cfg) (page 341)
armonitor.conf (armonitor.cfg) (page 343)
AR System configuration files 299

ar
Description The ar file contains the list of AR System servers to which the client tools
(BMC Remedy User, BMC Remedy Administrator, BMC Remedy Alert, and
BMC Remedy Import) connect if no servers are specified on startup. The
ARGetListServer function uses this file to return a list of available servers.
The format of this file consists of two fields separated by a space or tab:
<server-name> <server-information-list>
The <server-name> parameter is the name of the server machine. The name
is resolved to a network address by using the name resolution strategy of the
local machine. The <server-information-list> parameter identifies the server
as an AR System server (AR) as well as the TCP port and RPC program
numbers, as applicable.
Lines with a pound sign (#) in column 1 are treated as comments and are
ignored.
Synopsis UNIX—$ARCONFIGDIR/ar
Windows—<ar_home_dir>\ar
Environment ARCONFIGDIR
UNIX only—Specifies the directory where the ar.conf file and other
AR System configuration files are stored. This directory defaults to
<ar_install_dir>/conf if you do not set this variable.
Examples The following directory file registers two server machines as AR System
servers:
# Directory file for AR System servers
remedy AR
server2 AR;;3030;;390600
The example includes the TCP port and RPC program numbers for server2.
ar.conf (ar.cfg)
Description The ar.conf (UNIX) or ar.cfg (Windows) file contains AR System server
configuration changes and is dynamically created when you install
AR System server. When you make a server configuration change in BMC
Remedy Administrator, the configuration parameters and their new values
appear in the configuration file.
300 Appendix B—AR System configuration files

Configuring
Any process can retrieve configuration information from the ar.conf (ar.cfg)
file by using the ARGetServerInfo function. You can modify the information by
using the ARSetServerInfo function. Updates made using ARSetServerInfo
take effect immediately. Manual changes to the file do not take effect until the
AR System server process is restarted or signaled to reread the configuration
file with arsignal -c.
Synopsis UNIX—<ar_install_dir>/conf/ar.conf
Windows—<ar_install_dir>\Conf\ar.cfg
Options The format of this file consists of two fields separated by a space or tab:
<parameter> <value>
Each parameter represents a particular configuration option. The associated

value represents the current setting for that option. All numeric values are in
a base 10 system. The available configuration options (and the valid settings
for each) are described in the following table.
Lines that do not begin with one of these options are ignored.
Lines with a pound sign (#) in column 1 are treated as comments and
ignored.
The following table lists the options available for the ar.conf (UNIX) or ar.cfg
(Windows) file. All options can be set by using BMC Remedy Administrator
unless otherwise denoted by the table’s footnotes.
Note: All parameters in the configuration file might be updated manually.

Entries are case a space sensitive so be careful when making any manual
updates to this file.
ar.conf (ar.cfg) 301

Table B-1: ar.conf (ar.cfg) file options
Option Description
Active-Link-Dir The directory where active link server run processes are stored. Only commands
located in the specified directory can be run. This is a security feature that makes
sure clients or API programs can use only a safe set of server processes.
Active-Link-Shell (UNIX only) A shell that will be the parent of any active link server process. This
parameter causes the server to start the shell with the specified process as a
parameter. This is a security feature. The specified shell might be a security shell
that verifies a path, or runs with a user ID other than the one that the server uses.
For example, if the server runs as root and an administrator specified a shell that
runs as a lower user privilege, an active link will invoke the shell that runs as a
user, instead of as root.
You can also set this parameter in the Advanced tab of the Server Information
dialog box. See “Configuring AR System servers” on page 124 for more
information about the Server Information dialog box.
Admin-Only-Mode A setting indicating that only administrators and subadministrators can access
the server. Valid values for this option are T and F. The default is F (not in admin-
only mode).
Alert-Check-Users Tells the AR System server to check all registered alert user connections at startup
time. This might slow the startup process, but it removes all inaccessible
connections. Valid values for this option are T and F. The default is F (do not check
alert users).
Alert-Log-File The name of the file to use if alert tracing is turned on (see “Debug-mode” on
page 314). This argument is expressed as the full path name.
Alert-Outbound-Port The specific TCP port to which the AR System server binds when sending alerts.
If more than one worker thread is running in the alert queue, this setting
represents the starting port number in a range of consecutive port numbers that
are assigned in sequence to the threads.
Alert-Send-Timeout Sets the time limit (in seconds) allowed for making contact with alert clients. Two
attempts are made to deliver an alert and if the second attempt fails, the alert
registration is removed. The default time limit is 7 seconds.
Allow-Backquote-In- Allows the server to run a process with a backquote in the process name or in its
Process-String arguments. Valid values are T and F. The default is F.
1
Options you can view (but not set) using BMC Remedy Administrator.
2
Options you cannot set or view using BMC Remedy Administrator.

Configuring
Option Description
Allow-Guest-Users A flag indicating whether the AR System server accepts guest users. Guest users
are users not registered with AR System in a User form. If allowed, guest users
have no permissions but can perform some basic operations. Guest users can
submit requests to forms for which permission has been given to the Public group
and fields have been defined as allowing any user to submit. If not allowed,
unregistered users have no access to the system. Valid values for this option are T
and F. The default value is T (allow guest users).
Allow-Unqual-Queries A flag indicating whether the AR System server allows unqualified searches.
Unqualified searches are ARGetListEntry or ARGetListEntryWithFields
calls in which the qualifier parameter is either NULL or has an operation value of
zero (AR_COND_OP_NONE). These searches can cause performance problems
because they return all requests for a given form. (This operation is especially
problematic for large forms.) Valid values for this option are T and F. The default
value is T (allow unqualified searches).
Alternate-Approval- Specifies whether the Approval Server will listen for the AR System server's signal
Reg2 directly (F) or listen for the application dispatcher to signal (T).
Only one server process should be listening for the signal from the AR System
server. By default, the Approval Server knows to listen for the AR System server's
signal. When you are running the application dispatcher, you want the dispatcher
to listen for the AR System server, and you want the dispatcher to send a different
signal to the Approval Server.
If your application that relies upon the application dispatcher, make the following
changes:
Set Alternate-Approval-Reg to T.
Add apsvcdsp to the armonitor.cfg/armonitor.conf file so the dispatcher
is started.
API-Log-File The name of the file to use if API tracing is turned on (see “Debug-mode” on
Application-Enable2 A flag that indicates whether to create the Application Pending form to support
Application-Command syntax even if there is no Approval Server license. Valid
values are T and F. The default is F (no Application Pending form is created).
Approval-Defn-Check- The interval (in seconds) at which the Approval Server will check for changed or
Interval2 updated data in the data definition forms.
Approval-Log-File2 Full path of the Approval Server log file.
1 Options you can view (but not set) using BMC Remedy Administrator.
2 Options you cannot set or view using BMC Remedy Administrator.

Option Description
Approval-Notify2 Specifies the approval notifications configured from the Server Settings dialog
box. There is an Approval-Notify entry for each ID. The syntax is as follows:
Approval-Notify: <ID> <value>
Do not be make these changes in the ar.cfg (ar.conf) file. From the
AP:Administration form, click the Server Settings link to open a dialog box with
configuration settings for the Approval Server.
Approval-RPC-Socket2 Specific RPC Program Number the Approval Server uses when contacting
AR System. This allows you to define a specific AR System server that the
Approval Server can use privately.
Approval-Web-Doc-Dir2 Virtual path to web document directory for the Approval Server.
ARDBC-LDAP-Base-DN2 Specifies a base DN to be used instead of the root DN as the starting point for
discovering vendor tables when you are designing vendor forms. For example:
ARBDC-LDAP-Base-Dn: CN=Users, DC=ldapesslab,DC=com
ARDBC-LDAP-Cache-TTL2 Specifies the time limit (in seconds) that data will remain cached. Set to 0 for no
time limit. The default value is 60 seconds.
ARDBC-LDAP-Cache- Specifies the size limit (in bytes) for the cache. Set to 0 for no size limit. The
MaxSize2 default is 32768 bytes.
ARDBC-LDAP-Cert-DB2 The directory name of the certificate database. The cert7.db and key3.db
certificate database files are located in this directory. If the directory is not
specified, the LDAP plug-in will look under the AR System installation directory
for these files.
The path in this option is used only when ARDBC-LDAP-UsingSSL is set to T.
ARDBC-LDAP-Cert-Name2 For future use. This option is not yet implemented.
ARDBC-LDAP-Connect- Specifies the number of seconds that the plug-in will wait for a response from the
Timeout2 directory service before it fails. The minimum value is 0, in which case the
connection must be immediate. The maximum value is the External-
Authentication-RPC-Timeout setting.
If the ARDBC-LDAP-Connect-Timeoutsetting is not specified, the default value is set
to the value of External-Authentication-RPC-Timeoutsetting (the default is 40
seconds).
For example, to set the connection timeout for the ARDBC LDAP plug-in to 5
seconds:
ARDBC-LDAP-Connect-Timeout: 5

Configuring
Option Description
ARDBC-LDAP-Drop- This option is obsolete in version 7.0 and later.
Large-Values2
ARDBC-LDAP-Hostname2 The host name of the system on which the directory service is running. If the host
name is not specified, the ARDBC LDAP plug-in will use localhost as the host
name. For example:
ARDBC-LDAP-Hostname: server1.eng.remedy.com
2 For future use. This option is not yet implemented.
ARDBC-LDAP-Key-DB
ARDBC-LDAP-Key- For future use. This option is not yet implemented.
Password2
ARDBC-LDAP-Page-Size2 This parameter configures thepagesize in the pagedResultsControlof the ARDBC

LDAP plug-in search request. It specifies the number of entries to be returned in
a single page from the external directory server in the set of results to the client
when processing a search request containing the pagedResultsControl.
The maximum value for this parameter is 100,000 and the minimum value is 100.
The default value is 10,000 if there is no value set.
The syntax for this parameter is as follows:
ARDBC-LDAP-Page-Size: <int>
For example:
ARDBC-LDAP-Page-Size: 1000
For information about ARDBC LDAP, see the Integrating with Plug-ins and
Third-Party Products guide.
ARDBC-LDAP-Port2 The port number on which the directory service is listening for clients.
ARDBC-LDAP-Time- Maps date and time data into one of several formats that various LDAP
Format2 servers recognize.
Valid values are as follows:
0—Generalized Time Format – YYYYMMDDHHMMSSZ
This format is recognized by all LDAP servers and is recommended.
1—AD Generalized Time Format – YYYYMMDDHHMMSS.0Z
This format is only recognized by Microsoft Active Directory servers.
2—UTC Time Format – YYMMDDHHMMSSZ
This is a historical format and does not indicate the century. It is not
recommended.
2 Options you cannot set or view using
BMC Remedy Administrator.

Option Description
ARDBC-LDAP-Use-Cache2 Activates caching of search requests. The values are T and F.
After a cache is enabled, search requests issued via the ARDBC Plugin will be
cached. Subsequent matching search requests will be satisfied from the cache.
ARDBC-LDAP-User-DN2 The distinguished name (DN) of the user account that the ARDBC LDAP plug-
in will use to search and modify the contents of the directory service. For
example:
ARDBC-LDAP-User-DN: server1\admin
2
ARDBC-LDAP-UsingSSL Establishes a secure socket layer (SSL) connection to the directory service. The
values are T and F.
If you use LDAP over SSL, then you must also specify the file name of the
certificate database used to establish the connection.
AREA-LDAP-Bind- The password of the user account that the AREA LDAP plug-in will use to find
Password2 the user object using the User Search filter. If the Distinguished Name is not
specified, the AREA LDAP plug-in will use an anonymous login to find the user
object.
If the target directory service does not allow anonymous access, then you must
specify a Distinguished Name and Password; otherwise, the plug-in will be unable
to determine the distinguished name of the user.
AREA-LDAP-Bind-User2 The distinguished name (DN) of the user account that the AREA LDAP plug-in
will use to find the user object using the User Search filter. If the DN is not
specified, the AREA LDAP plug-in will use an anonymous login to find the user
object.
If the target directory service does not allow anonymous access, then you must
specify a Distinguished Name and Password; otherwise, the plug-in will be unable
to determine the distinguished name of the user.
An example of this option is:
AREA-LDAP-Bind-User: ldapesslab\admin
2
AREA-LDAP-Cert-DB The directory name of the certificate database. The cert7.db and key3.db
certificate database files are located in this directory. If the directory is not
specified, the LDAP plug-in will look under the AR System installation directory
for these files. This path is used only when ARDBC-LDAP-UsingSSL is set to T.
AREA-LDAP-Chase- Enables automatic referral chasing by LDAP client. By default, referrals are not
Referral2 chased. The options are T and F. This option is for Microsoft Active Directories
only.

Configuring
Option Description
AREA-LDAP-Connect- Specifies the number of seconds that the plug-in will wait to establish a
Timeout2 connection with the directory service. The minimum value is 0, in which case the
connection must be immediate. The maximum value is the External-
Authentication-RPC-Timeout setting.
If the AREA-LDAP-Connect-Timeout setting is not specified, the default value is
set to the value of External-Authentication-RPC-Timeout setting (the
default is 40 seconds).
For example, to set the connection timeout for the AREA LDAP plug-in to 5
seconds, enter:
AREA-LDAP-Connect-Timeout: 5
2
AREA-LDAP-Email The name of the attribute that specifies the email address of the user. This
attribute corresponds to the Email Address field in AR System User form. If the
attribute is not specified, the specified default or a system default is applied.
AREA-LDAP-Email- The value that the AREA LDAP plug-in uses if the AREA-LDAP-Email parameter
Default2 is not specified nor has no value for the user.
AREA-LDAP-Group-Base2 The base of LDAP directory to search the groups from.
The following keywords are used to substitute runtime parameters into this
option. Note that the backwards slash (\) is necessary.
$\USER$—The user's login name.
$\DN$—The user's distinguished name. This applies only to the Group Base
Name and Group Search Filter. It does not apply to the User Base name and
User Search filter.
$\AUTHSTRING$—The value that users enter into the Authentication String
field at the time they log in.
$\NETWORKADDR$—The IP address of the AR System client accessing the
AR System server.
AREA-LDAP-Group- Default groups to which the user belongs if no group information is available
Default2 from the directory service. If there are multiple groups, use a semicolon to
separate one from another.

Option Description
AREA-LDAP-Group- The LDAP search filter used to locate the groups to which this user belongs.
Filter2
$\DN$—The user's distinguished name. This only applies to the Group Base
Name and Group Search Filter. It does not apply to the User Base Name and
User Search Filter.
$\AUTHSTRING$—The value that users enter into the Authentication String
field at the time they log in.
AR System server.
AREA-LDAP-Hostname2 The host name of the system on which the directory service is running. If left
blank, the AREA LDAP plug-in will use localhost as the host name.
AREA-LDAP-Lic2 The name of the attribute that specifies the type of write license issued. This
attribute corresponds to the License Type field in the AR System User form. If the
AREA-LDAP-LicApp2 The name of the attribute that specifies the type of Application license issued. If
the attribute is not specified, the specified default or a system default is applied.
AREA-LDAP-LicApp- The value the AREA LDAP plug-in uses if the AREA-LDAP-LicApp attribute is not
Default2 specified or has no value for the user.
AREA-LDAP-Lic- The value the AREA LDAP plug-in uses if the AREA-LDAP-Lic attribute is not
AREA-LDAP-LicFTS2 The name of the attribute that specifies the type of Full Text Search (FTS) license
issued. This attribute corresponds to the Full Text License field in the AR System
User form. If the attribute is not specified, the specified default or a system default
is applied.
AREA-LDAP-LicFTS- The value the AREA LDAP plug-in uses if the AREA-LDAP-LicFTS attribute is not
1
2

Configuring
Option Description
AREA-LDAP-LicMask2 The attribute that specifies the license mask. The bits of the binary format of the
specified integer indicate how to mask the license information returned from the
AREA LDAP plug-in. The integers are:
0—No licenses returned from the AREA LDAP plug-in are used.
1—Write license from the plug-in is used.
2—Full Text Search (FTS) license from the plug-in is used.
3—Write license and FTS license from the plug-in are used.
4—Reserved license from the plug-in is used.
5—Reserved license and Write license from the plug-in are used.
6—FTS License and Reserved license from the plug-in are used.
7—Write license, FTS license, and Reserved license from the plug-in are used.
If the license is not used from the plug-in, then the license information in the
user's User entry is used.
AREA-LDAP-LicMask- The value the AREA LDAP plug-in uses if the AREA-LDAP-LicMask attribute is
Default2 not specified or has no value for the user.
AREA-LDAP-LicRes12 The name of the attribute that specifies the type of Reserved license issued. If the
AREA-LDAP-LicRes1- The value the AREA LDAP plug-in uses if the AREA-LDAP-LicRes1 attribute is
Default2 not specified or has no value for the user.
AREA-LDAP-Notify- The name of the attribute that specifies the default notification mechanism for
Meth2 the user. This attribute corresponds to the Default Notification Mechanism field
in the AR System User form. If the attribute is not specified, the specified default
or a system default is applied.
AREA-LDAP-Notify- The value the AREA LDAP plug-in uses if the AREA-LDAP-Notify-Meth
Meth-Default2 attribute is not specified or has no value for the user.
AREA-LDAP-Port2 The port number on which the directory service is listening for clients.
2
AREA-LDAP-Use-Groups Retrieves the group information from the LDAP server. If this parameter is not
set, the group information from AR System Group form is used.

Option Description
AREA-LDAP-User-Base2 The user base in the LDAP directory to search for the user.
User Search Filter.
$\AUTHSTRING$—The user enters into the Authentication String field at the
time they log in.
AR System server.
AREA-LDAP-User- The LDAP search filter used to locate the user in the directory from the base that
Filter2 the AREA-LDAP-User-Base option specifies.
User Search Filter.
$\AUTHSTRING$—The value that the user enters into the Authentication
String field at the time they log in.
AR System server.
AREA-LDAP-UseSSL2 Establishes a secure socket layer (SSL) connection to the directory service. The
values are T and F.
If you use LDAP over SSL, then you must also specify the file name of the
certificate database used to establish the connection.
1
2

Configuring
Option Description
ARF-Java-Class-Path2 The path to .jar files. If you install JRE after the AR System server, add the
following lines to your ar.cfg (ar.conf) file:
ARF-Java-Class-Path: C:\Program Files\AR System\arapi51.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\axis.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\log4j-core.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\websvc51.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\wsdl4j.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\xercesImpl.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\xmlParserAPIs.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\commonslogging.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\jaxrpc.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\tt-bytecode.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\saaj.jar;
#ARF-Java-VM-Options: -Dhttp.proxySet=true -Dhttp.proxyHost=zermatt -
Dhttp.proxyPort=3129
Plugin: WebService.dll
Also, if you install JRE after the AR System server, add the JRE directory to your
PATH, for example:
C:\Program Files\JavaSoft\JRE\1.3.1_03\bin\hotspot
ARF-Java-VM-Options2 The Java command options for a virtual machine (VM). The options are
documented in the Javadocs.
Arfork-Log-File The name of the file to use if arforkd tracing is turned on (see “Debug-mode”
on page 314). This argument is expressed as the full path name. This file is not
subject to the maximum file size specified in the Max-Log-File-Size option.
Authentication- This parameter enables the administrator to use more than one type of
Chaining-Mode authentication on the same system.
The values for Authentication-Chaining-Mode are as follows:
0—Use the default behavior as in releases prior to 6.3.
1—Use internal authentication as the primary method; then use external
authentication via the AREA plug-in as the secondary method.
2—Use external authentication via the AREA plug-in as the primary method;
then use internal authentication as the secondary method.
If the Authentication-Chaining-Mode is set to a value of 1 or 2, the Authenticate-
Unregistered-Users parameter will be ignored.
If the Crossref-Blank-Password parameter is enabled, and Authentication-
Chaining-Mode is set to a value of 1 or 2, users who have a blank password in their
User record will be permitted to log in to the system without a password (that is,
a NULL password).

Option Description
Cache-Mode Enables a cache mode that is optimized for developing applications and where
user operations might be delayed when changes are made to forms and workflow.
A value of 1 turns on development cache mode; a value of 0 (zero) turns off
development cache mode; the server is in production mode. If there is no entry in
the ar.cfg (ar.conf) file, development cache mode is off. The following example
shows development cache mode on:
Cache-Mode: 1
Cancel-Query-Option2 Allows control over whether cancel query functionality of user tool is enabled.
Valid settings are 0 (inactive) and 1 (active). The default is 1.
Changed-By-Another- A setting indicating whether the system will check if an entry has been changed by
Check another user since you retrieved the entry. If you attempt to save modifications to
an entry, you will receive a warning and must confirm the save. Valid values for
this option are T and F. The default is T (perform the check and issue a warning).
Clustered-Index A setting indicating whether indexes for the database are clustered. Valid values
for this option are T and F. The default is T (use a clustered index). You must set
this configuration before you start the AR System server.
Create-Entry- Number of times to retry an ARCreateEntry() during deadlock situations.
DeadLock-Retries2 Integer value.
Create-Entry- Delay, in seconds, between each retry of a deadlocked ARCreateEntry(). Integer
DeadLock-Retries- value.
Delay2
Crossref-Blank- A flag indicating how the system responds when a user’s login name is not
Password assigned a password in the User form. Valid values for this option are T and F. The
default value is F (blank passwords not cross-referenced). If set to T, the system
attempts to validate the password in the Windows server domain (or through the
External Authentication API if external authentication is turned on) or against
the UNIX server /etc/passwd file. This option enables you to manage group
membership and other support information with AR System, while still
managing passwords with the /etc/passwd file (UNIX) or the server domain
security model (Windows).
Currency-Ratio- Number of seconds between each refresh of Currency Field values.
Client-Refresh-
Interval2
DB2-Database-Alias The DB2 database alias name for the AR System database.
1

Configuring
Option Description
DB2-Free-Lob-Locator- Indicates how often DB2 frees the LOB locator (Large OBject locator). The
Frequency2 default value is 50, which results in the LOB locator being freed after every 50
LOBs have been loaded. The recommended value for AR System
application is 5.
DB2-Server-Name The name of the DB2 database server.
Dbhome-directory1 UNIX only—The home directory for the underlying database (applicable for SQL
databases only). This argument is expressed as the full path name.
Db-Case-Insensitive1 Oracle Only. Enables certain case-insensitivity functionality within Oracle
database. Requires you to restart the AR System server.
Important: If this option is set to True, AR System on Oracle performs a full-table
scan and does not use indexes, even if you search only for the request ID (C1-
field). Almost every statement from AR System makes a full table scan in the
Oracle database, which can cause performance problems.
Db-Character-Set2 Initializes an internal variable that the server uses for various purposes, such as
adjusting the database's short column size so that the number of characters in a
datum does not exceed the number of bytes in the database field. Another use for
the variable is to inform the ARGetServerInfo request
AR_SERVER_INFO_DB_CHAR_SET. (The installer sets the Db-Character-Set value.)
The values of this field are as follows:
Unicode (UTF-16)—UTF-16 UCS-2
Unicode (UTF-8)—UTF-8
Db-Connection- Number of times the AR System Server will retry a lost connection to the
Retries2 database. The default is 100.
Db-Max-Attach-Size2 The maximum size (in bytes) for attached files in the Oracle RDBMS. The default
value is 2 GB. The maximum value allowed is limited by your server operating
system and configuration.
Db-Max-Text-Size2 The maximum size allowed for long character text data in Oracle, SQL Server, and
Sybase databases. For Oracle databases, this value is also used for memory
allocation during the processing of long text data; therefore, you must use it
conservatively. The default for an Oracle database is 1 MB. For SQL Server and
Sybase, the default is 2,147,483,647 bytes. The maximum value allowed for either
database is 2,147,483,647 bytes.

Option Description
Db-name1 For Oracle, the name of the tablespace that ARServer will use.
For all other supported databases, the name of the underlying SQL database. The
default value is ARSystem.
Db-password The database password associated with the ARSystem database and table space
(applicable for Sybase, MS SQL, and Oracle DB2 databases only). The password
can be modified by using the ARSetServerInfo function and is stored in encrypted
form. If you change the password manually, specify this option by using clear text,
and change the password by using BMC Remedy Administrator to encrypt it.
Db-user1 The user name that AR System uses to access the underlying database (Oracle,
Sybase, or MS SQL). The default is ARAdmin.
Debug-GroupId The group name to which a user must belong to allow logging options such as
API, Database, and Filter logging to be turned on in AR System clients. Logging
options are disabled for users who are not members of the specified group. The
group names can be Public, Administrator, Sub Administrator, or Browser. You
can also set this option in the Client-Side Logging Group field on the Log Files
tab.
Debug-mode A bitmask indicating the server debug modes. Each bit has a corresponding value.
To activate one bit, supply its value for the Debug-mode option. To activate two or
more bits, add the values, and supply the total. (For example, to activate bits 1 and
3, use the number 5 because bit 1 has a value of 1, and bit 3 has a value of 4.) To
deactivate a bit, subtract its value from the Debug-mode total.
Bit 1 (Value=1)—Turns on SQL tracing for the arserverd process (applicable
for SQL databases only). The default file for SQL tracing is arsql.log (located
in the directory specified for the Server-directory option). You can override
this default by using the SQL-Log-File option.
Bit 2 (Value=2)—Turns on filter tracing for the arserverd process. The
default file for filter tracing is arfilter.log (located in the directory specified
for the Server-directory option). You can override this default by using the
Filter-Log-File option.
Bit 3 (Value=4)—Turns on user tracing for the arserverd process. The
default file for user tracing is aruser.log (located in the directory specified for
the Server-directory option). You can override this default by using the
User-Log-File option.
1
2

Configuring
Option Description
Debug-mode Bit 4 (Value=8)—Turns on escalation tracing for the arserverd process. The
(continued) default file for escalation tracing is arescl.log (located in the directory specified
Escalation-Log-File option.
Bit 5 (Value=16)—Turns on API tracing for the arserverd process. The
default file for API tracing is arapi.log (located in the directory specified for
API-Log-File option.
Bit 6 (Value=32)—Turns on thread tracing for the arserverd process. The
default file for thread tracing is arthread.log (located in the directory specified
Thread-Log-File option.
Bit 7 (Value=64)—Turns on alert tracing for the arserverd process. The
default file for alert tracing is aralert.log (located in the directory specified
Alert-Log-File option.
Bit 8 (Value=128)—Turns on arforkd tracing for the arserverd process.
The default file for arforkd tracing is arforkd.log (located in the directory
specified for the Server-directory option). You can override this default by
using the arfork-Log-File option.
Bit 9 (Value=256)—Turns on server group tracing for the arserverd process.
The default file for server group tracing is arsrvgrp.log (located in the
directory specified for the Server-directory option). You can override this
default by using the Server-Group-Log-File option.
Bit 16 (Value=32768)—Turns on distributed server tracing for the arservdsd
process (applicable for Distributed Server Option only). The default file for
distributed server tracing is ardist.log (located in the directory specified for
Distrib-Log-File option.
Bit 17 (Value= 65536)—Turns on Approval Server tracing. Specify the location
for the log file arapprov.log using the AP: Admin-Server Settings form, accessed
from the Approval Menu > Server Settings command.
Bit 18 (Value=131072)—Turns on plug-in tracing for the arserverd process.
The default file for plug-in tracing is arplugin.log (located in the directory
specified for the Server-directory option). You can override this default by
using the Plugin-Log-File option.
1

Option Description
Default-Allowable- Default allowable currency types used for Currency fields in clients.
Currencies2
Default-Functional- Default functional currency types used for Currency fields in clients.
Currencies2
Default-Order-By2 The default value to order search results. Valid values are T and F. T indicates that
there is a default order, which is to sort by entry ID. F indicates that there is no
default order and no order clause is added to the command if there is not a
specific sort order specified. The default is T (apply default sort order).
Default-Web-Path The URL to the directory path for the default web server pointing to the
AR System server.
Delay-Recache-Time2 The number of seconds before making the latest cache available to all threads.
Valid values for this option are 0 to 180 seconds. The minimum is 0, which means
every API call will get the latest cache (that is, the cache will be copied for every
administrator call). Setting the option to 0 causes slower performance for cache
operations. The default value is 5 seconds.
Disable-Admin-Ops A flag that indicates whether administrator operations are allowed on the server.
The values for this option are 0 (disabled) and 1 (enabled). The default is 0.
If the Server Groups check box is selected, this setting is ignored. Server groups
can be configured in the AR System Server Group Operation Ranking form to
make sure that only one server performs the operation. See “Running servers as
Disable-Alerts Prevents alerts from being sent when alert events are created. Valid values for this
option are T and F. The default is F (alerts are enabled). If the parameter is set to
T, no threads are started in the alert queue and no alerts are sent. Changes to this
setting do not take effect until the server is restarted.
Disable-Archive2 Allows archive to be disabled (T) or enabled (F) when the server starts up.
1
2

Configuring
Option Description
Disable-Client- Restricts time-consuming operations (such as reporting) during busy times,
Operation2 improving the overall performance. This option can be set to certain times of the
day. It can also exclude users of specific groups so that they are not blocked from
performing the specified operation. For example, you can allow only the
administrator to perform reporting during busy hours.
The syntax for this option is:
Disable-Client-Operation: <tag_number_to_disable> [[<start_time>]-
[<stop_time>]] [<group_ID_list>]
The tag number is defined in the ar.h file. To specify start and stop times, enter
them in 24-hour format (hh:mm). The times are include times. For example, 00:00-
13:59 disables from midnight until 1:59 p.m.
The group_ID_list is a list of none, one, or multiple group IDs delimited by
spaces. To specify the groups to exclude, enter the group ID. For example:
Disable-Client-Operation: 1 13:00-17:59 1
The second and third sections are optional and are delineated by spaces. For
example, if you did not specify a start or stop time, the syntax would look like this:
Disable-Client-Operation: 2 18:00- 10
To start disabling operations from midnight until 6:00 a.m. excepting group 10,
enter:
Disable-Client-Operation: 2 -6:00 10
If there is no argument for the second section, the option disables the operations
from the client all the time. If there is no argument for the third section (users to
exclude), then all users from that client cannot run the operations.
You can specify multiple Disable-Client-Operation lines.
1
2

Option Description
Disable-Client- Following are the Disable-Client-Operation tag numbers
Operation2 1—AR System clients prior to the 5.0 version
(continued) 2—BMC Remedy Administrator
3—BMC Remedy User
4—BMC Remedy Import
5—Distributed Server Option
6—AR System ODBC
7—Approval Server
8—AR System web server (waserver)
9—Mid tier (version 5.0 and later)
10—Palm Pilot
11—Flashboards
12—Flashboards mid tier
13—Enterprise integration
14—arreload
15—arcache
16—ardist
17—runmacro
18—armaild, armailex (pre-5.1)
19—arimportcmd
20—Report creator plug-in
21—BMC Remedy Alert
4000—Driver (sample program)
4001—Distributor of application
4002—arhelp
4003—arjanitor
4004—armenu
4005—arstruct
4006—artext
4007—arsqled
4008—archgsel
1
2

Configuring
Option Description
Disable-Escalations A flag that indicates whether escalations are allowed on the server. The values for
this option are T and F. The default is F.
If the Server Groups check box is selected, this setting is ignored. Server groups
can be configured in the AR System Server Group Operation Ranking form to
make sure that only one server performs the operation. See “Running servers as
Disable-User-Cache- Prevents unauthorized users from attempting to use User Cache commands.
Utilities Valid values for this option are T and F. The default is F (cache utilities are
enabled). If the parameter is set to T, then the arreload and arcache utilities are
disabled for the AR System server.
Distrib-Log-File The name of the file to use if distributed server tracing is turned on (see “Debug-
mode” on page 314). This argument is expressed as the full path name.
Distributed-RPC- The specific AR System server to use for the distributed server. By default, the
Socket distributed server runs in the queues like any other user.
DSO-Cache-Check- Sets the number of seconds between DSO checks for changes to the source and
Interval2 target forms.
DSO-Error-Retry- Determines the behavior within the DSO process for retrying after an error. The
Option2 settings are as follows:
0 (the default): Retry standard connection and transmission errors.
1: Never retry after any type of error.
2: Always retry regardless of the type of error.
3: Retry standard connection and transmission errors plus database errors.
For example:
DSO-Error-Retry-Option: 2
2
DSO-Host-Name The name for the current machine for DSO use. This setting allows for an alias for
the current machine within Distributed Mapping distributions.
DSO-Local-RPC-Socket2 The RPC program number that DSO uses. This setting is optional.
DSO-Mark-Pending- A flag indicating if the DSO will stop the processing of a pending list in case it fails
Retry-Flag2 to contact a busy AR System server after retrying one time. Valid values are T and
F.
DSO-Max-Pending- Defines the limit for the number of Distributed Pending form records that DSO
Records-Per-Query2 will read in a single database query. The lower limit is 1, and there is no upper
limit. If this configuration item is not present, the default value is 1000.

Option Description
DSO-Merge-DupID- Defines what action the server will perform if a duplicate entry ID is found on the
Overwrite2 target AR System server. Valid values are T and F. If set to T, mapped fields are
updated, and unmapped fields are set to NULL.
DSO-Polling-Interval2 Defines the intervals (in seconds) at which the DSO will check the Distributed
Pending form for pending distributed operations. This is used as a backup in case
there are no signals from AR System workflow. The value can be an integer
between 15 and 7200. If you set the value to 0, DSO will set the polling interval to
15 seconds (the lowest value); if you set the value at an integer greater than 7200,
DSO will set the polling interval to the maximum of 7200 seconds. The DSO
polling interval feature is disabled as a default. For more information about
Distributed Server Operations (DSO), see the Administering BMC Remedy DSO
guide.
DSO-Target-Connection Defines the information for the target AR System server. The following format is
used:
DSO-Target-Connection: <server_name>:<RPC_number> <port_number>
DSO-Target-Password The password used to access the target AR System server through the distributed
server. The following format is used:
DSO-Target-Password: <server_name>:<encrypted_password>
2
DSO-Timeout-Normal Defines the timeout the DSO applies during communication with the AR System
server. It overrides the default timeout value and can be an integer between 60
and 21600 (in seconds), representing a range from 1 minute to 6 hours. If the
value is set out of range, the closest integer to that value will be applied. If no value
is entered, the default value (120 seconds) is used.
DSO-User-Password The password for the local distributed server user.
Email-Import-Form-By- Specifies whether email forms are imported by default when the AR System server
Default2 is started up. Valid values are True (T) and False (F). A value of T means that email
forms will be imported by default when the AR System server is restarted; a value
of F means that the forms will not be imported by default. The default is T.
Email-Notify-From2 The sender name to use for filter-generated email notifications where no subject
is specified. This value is limited to 29 characters.
Email-Timeout2 Sets the maximum amount of time that arserverd waits for a return value from
sendmail. This parameter was valid in versions 4.5.1 through 5.0.1, but was made
obsolete with the introduction of the Email Engine in version 5.1.0 of AR System.

Configuring
Option Description
Encrypt-Data- An integer value indicating the encryption algorithm. If you switch to a new
Encryption-Algorithm2 algorithm, client connections using the old algorithm automatically perform a
key exchange to create keys that correspond to the new algorithm. The default is
0 (zero), RCA encryption, 128-bit key.
Encrypt-Public-Key- The encryption algorithm of the public key. BMC Remedy Encryption products
Algorithm2 use the RSA algorithm for public key cryptography. RSA is a public-key
cryptosystem that uses modular arithmetic and elementary number theory to do
certain computations.
The public key is used in the data encryption key negotiation. This key
negotiation occurs at the beginning of the API session and when the data
encryption keys expires.
The settings are:
4—A 512-bit RSA key. This is the default for standard security.
5—A 1024-bit RSA key. This is the default for performance security.
6—A 2048-bit RSA key. This is the default for premium security.
All lower-level encryption technologies are available in higher security level
products. For example, the Premium Security product includes the encryption
algorithms of Performance Security and Standard Security.
Encrypt-Public-Key- An integer value (in seconds) indicating the amount of time for the duration of
Expire2 the public key. After expiration, the server creates a new public key. The default
is 86400 seconds (24 hours).
Encrypt-Security- An integer value indicating whether encryption is on or off. The values are as
Policy2 follows:
0: Encryption between the client and server is allowed, but not required.
1: Encryption between the client and server is required; unencrypted
communication is not allowed.
2 (the default): Encryption between the client and server is disabled.
Encrypt-Session-Hash- The size of the hash table that holds the encrypted session information. The
Entries2 default is 509, there is no maximum.
Encrypt-Symmetric- An integer value (in seconds) indicating the amount of time for the duration of
Data-Key-Expire2 the data encryption key. After expiration, if necessary, a new key exchange occurs.
The default is 2700 seconds (45 minutes).
Escalation-Log-File The name of the file to use if escalation tracing is turned on (see “Debug-mode”
on page 314). This argument is expressed as the full path name.

Option Description
External- A bit mask that allows you to specify the return data capabilities for the current
Authentication- AREA plug-in. This setting does not control the AREA plug-in, it merely
Return-Data- describes the behavior of the plug-in, allowing for server optimization.
Capabilities2 Acceptable values are as follows:
Bit 1 (Value=1)—No email address will be provided.
Bit 2 (Value=2)—No notify mechanism will be provided.
Bit 3 (Value=4)—No group identifiers will be provided.
Bit 4 (Value=8)—No license information will be provided.
Bit 5 (Value=16)—No notification user validation should occur.
The default is 0, meaning the server will attempt to retrieve this information from
AREA. A value of 7 will allow the server to potentially reduce the number of
AREA related calls during notification processing.
A value of 16 will allow the server to avoid using AREA for notification user
validation and information retrieval. Use this setting for sites using a form of
AREA that applies user names as email addresses and where there is no benefit to
accessing an authentication database.
External- The RPC socket number on which an external authentication server awaits
Authentication-RPC- requests for authentication. The default value is 0 (external authentication will
Socket not be used).
The RPC program number for the arplugin service is 390695.
External- The RPC timeout (in seconds) used when making calls to the authentication
Authentication-RPC- (AREA) server. The default value is 30 seconds.
Timeout
External- The internal timeout (in seconds) the AR System server uses to periodically
Authentication-Sync- invoke the external authentication server’s AREANeedToSyncCallback()
Timeout function, which instructs the AR System server to renew its internally stored user
information in the event there are changes made to the source used to
authenticate users. A 0 value means that the AR System server will not invoke the
call to the external authentication (AREA) server. The default value is 300
seconds.
Filter-Api-Timeout Indicates the time limit (in seconds) allowed for the Filter API RPC to respond to
the server’s request before returning an error. The minimum value is 0, and the
maximum is 300. The default is 60 seconds.
Filter-Log-File The name of the file to use if filter tracing is turned on (see “Debug-mode” on

Configuring
Option Description
Filter-Max-Stack The maximum number of levels of recursion allowed for a given operation. The
data modification performed by an AR_FILTER_ACTION_FIELDPfilter action might
trigger a second set, or level, of filters, one of which might trigger filters a third
level down and so on. This option limits the number of times such recursion can
happen, preventing the server crash that would occur if the recursion continued
indefinitely. The default value is 25.
Filter-Max-Total The maximum number of filters that the server will execute for a given operation.
The default value is 10000.
Flush-Log-Lines A flag to indicate whether you want the logged lines to be buffered instead of
written directly to disc. Valid values are T and F. Set to F if you want to buffer the
logged lines. The default value is T (the logged lines will be written to disc).
GetListEntry-Server- Returns the GetListEntry date formatted on the server instead of on the client.
Date-Format2 This option is used mainly for backward compatibility purposes. Valid values are
T and F. The default value is F (format dates on client).
Guest-Restricted-Read Defines whether guest users will receive a restricted read license when they log in
to AR System. If this option is not selected, guest users will receive a read license.
The values are true (T) and false (F).
GUID-Prefix2 The character string used as a prefix for GUID strings that are generated by filters.
Homepage-Form The path to a Home page to be used system wide as the default Home page for the
current server when a user logs in.
This default Home page will only be used if:
The current server is designated as the server for the Home page in the
AR System User Preference form, or
The current server is designated as the Home page server on the General
Settings page in BMC Remedy Mid Tier Configuration Tool (see the Installing
and Administering BMC Remedy Mid Tier guide for more information) and
No Home page is specified in the AR System User Preference form (you can
also set this in the Options dialog box in BMC Remedy User).
Note: If the Home page is deleted, this field is cleared, and the default Home page
will need to be re-entered.
Informix-DBServer- The name of the server where the underlying database is located (applicable for
Name1 Informix databases only).
Informix-Relay- Specifies the environment setting for the path for the Informix relay module
Module1 (applicable for Informix databases only).

Option Description
Informix-TBConfig1 The name of the configuration file for the underlying database (applicable for
Informix databases only). The default name is onconfig.
Init-Form 2 Specifies a form that will be opened every time any client logs into the system.
Workflow might be specified to record details of the login or to deny access based
on various parameters. Without this parameter, it would be necessary to attach
the workflow to every single form defined on the system.
Internal-User-Info- The number of shared, linked lists that hold all user-related information. This
Hash-Lists2 number must be represented in a power of 2. The default setting is 128, the
minimum number is 2, and there is no maximum number defined.
Note: AR System does not check to make sure that the number defined in the
ar.conf/ar.cfg file is in a power of 2; therefore, unexpected behaviors of the
AR System server might occur if the number is not in a power of 2.
Internal-User- The amount of time the AR System server waits before terminating expired user
Instance-Timeout2 instances. The default setting is 1 hour, the maximum is 2 hours, and the
minimum is 30 minutes.
The IP-Name parameter can be used for servers with variable length domains or for
servers on machines with multiple internet addresses. For example, to allow
connection to a machine named tix as tix, tix.company.com, or
tix.eng.company.com, an administrator would have three IP-Name entries,
one for each of the connection names.
To allow connection to a machine with multiple internet addresses like
tix.company.com, tix.biggercompany.com, and tix.evenbigger.com, an
administrator would create an IP-Name entry for each of those names.
1
2

Configuring
Option Description
IP-Name A parameter used to specify that a server has multiple names. The parameter can
appear in the ar.conf (ar.cfg) file more than one time.
When checking workflow and connections against itself, the server will compare
its server name, host name, IP aliases, and any names given by the IP-Name
parameter to the name passed to it. If the name matches any of those, the server
will conclude that the workflow or connection is for itself.
The IP-Name parameter can be used for servers with variable length domains or
for servers on machines with multiple internet addresses. For example, to allow
connection to a machine named tix as tix, tix.company.com, or
tix.eng.company.com, an administrator would have three IP-Name entries,
one for each of the connection names.
To allow connection to a machine with multiple internet addresses like
tix.company.com, tix.biggercompany.com, and tix.evenbigger.com, an
administrator would create an IP-Name entry for each of those names.
License-Timeout The number of hours the AR System server waits before disconnecting inactive
users. If a user is holding a floating write license token, the system also frees the
token at this time. The default value is two hours.
Localized-Server Indicates whether the server is running in localized support mode. If it is not, the
server does not search for or use localized strings. If localized support mode is
running, localized messages are used, if present. The values for this option are T
and F. The default is F (not localized).
Locked-Workflow-Log- Causes the server to record locked workflow actions in workflow logs. These
Mode2 actions are always written as encrypted strings.
Log-File-Append A flag that indicates whether to create a separate *.bak file or to append to the
existing log file. Valid values for this option are T and F. A value of F creates a
*.bak file; T indicates that new log information be appended to the existing file.
The default is F.
1
2

Option Description
Map-IP-Address2 The specific IP address mappings for alerts to work through firewalls where
Network Address Translation is enabled (NAT). You must set up a mapping for
each client machine that has access through the firewall where the client IP
address is translated from an internal address to a valid external address. In
addition, a mapping is required for the ARServer IP address if the host where
ARServer resides is also translated.
For example, the following figure maps AR System server and BMC Remedy
Alert. The Alert client comes through the firewall and the address changes from
10.5.119.83 to a valid public IP address of 123.45.67.89. The server address
changes from 123.45.55.90 to 10.26.55.65 on the other side of the firewall.
Figure B-1: Mapping IP addresses through a firewall
AR System
server
Firewall Firewall table
of IP addresses
123.45.67.89 10.5.119.83
ALERT
Client
123.45.55.90 10.26.55.65 10.5.119.83
123.45.55.90
Internal table of
IP address mappings
Map-IP-Address: 10.5.119.83 123.45.67.89
Map-IP-Address: 123.45.55.90 10.26.55.65
Here is a multiple line example:

Map-IP-Address: 123.45.67.89 10.5.119.83
Map-IP-Address: 123.45.55.90 10.26.55.65
Max-Entries-Per-Query The maximum number of requests returned by a single search. Because users can
also specify the maximum number of requests returned (through Search
Preferences in the AR System User Preferences form or the Options dialog box in
BMC Remedy User), the actual maximum is the lower of these two values. The
default value is no (server-defined) maximum.
1
2

Configuring
Option Description
Max-Log-File-Size The maximum size in bytes for system log files. If the maximum is reached, the
logging cycle starts over at the beginning of the file, overwriting existing
information. The default value is 0 (no limit). This option does not apply to the
Arfork-Log-File.
Max-Notify-Mail-Line- Maximum number of bytes that can be used in a single line of a mail notification.
Len2
Max-Password-Attempts Sets the maximum number of consecutive bad password retries a user is allowed
to make. If this option is set to 3, the user has 3 chances to log in. If all 3 attempts
have bad passwords, the user account will be marked as INVALID.
The allowed values for this option are 0 and all positive integers. A value of 0 turns
feature off, and any positive integer sets the limit.
Mid-Tier-Service- Specifies the password that administrators will need to access the mid tier.
Password
Minimum-API-Version Specifies the oldest API version with which the server will communicate. The
default value is 0, which means that the server will communicate with all API
versions. If the client’s API version is less than the specified value, the server will
refuse to talk with the client, and the client will receive a decode error. The API
version for release 7.0 is 12.
Multiple-ARSystem- A flag indicating whether you want to run multiple servers on one host machine.
Servers Valid values for this option are T and F. To run multiple servers, you must set this
option to T in the configuration file for each server you are running. The default
value is F (you are not running multiple servers on one machine).
Note: If you set this option to T and are running previous versions of AR System
applications, such as DSO or the Approval Server, those applications will not
work. You must upgrade your applications if you want them to work with this
option.
Multiple-Assign- Defines whether multiple assignee groups will be stored in row-level security
Groups2 Field 112. This enables users from multiple groups to access the same entry. In the
past, only one group could be stored in Field 112. Valid values for this option are
T and F. The default value is T (allow multiple groups).
Next-ID-Commit2 When the system generates the next ID number for a record in the database, it
performs a new commit transaction if this parameter is set to True. If the
parameter is set to False, the transaction to generate the next ID is included as
part of the create entry transaction. Set the value to True to increase efficiency and
for debugging. The default is False.

Option Description
Next-ID-Block-Size Allocates next IDs in blocks rather than one at a time. Allocating in blocks
increases performance during a create operation.
Edit the Next-ID-Block-Size value to a positive number (up to 1000), for example:
Next-ID-Block-Size: 50
The default value is 1. If 0 or a negative number (for example, -1) is used, the
server will use the default value of 1.
You do not need to restart the server for the change to take effect. The option is
started immediately.
To disable this option, set the value of Next-ID-Block-Size to 1, or remove the
parameter from the configuration file.
Note: This setting is always disabled on the Distributed Pending form so that DSO
can operate correctly.
Warning: The use of this configuration setting might result in unpredictably
large NextID sequence gaps. The likelihood of this occurring increases with the
use of multiple servers that share a database. The AR System server will not
malfunction due to this gap and should not be considered a defect.
Oracle-Bulk-Fetch- Defines the number of the rows of data fetched at a time from the result set when
Count2 querying an Oracle database. The minimum is 1, the maximum is 100, and the
default is 50. The higher the value, the more memory is used during data retrieval.
Oracle-Cursor- Specifies the database setting that matches the setting in the Oracle initialization
Sharing2 file (initARS.ora if the AR System database SID is ARS).
If the initARS.ora file includes the line CURSOR_SHARING=FORCE, use FORCE as
the value for this option also to indicate an Oracle setting to the AR System server.
If your Oracle database is set for SIMILAR, use the similar option:
Oracle-Cursor-Sharing: SIMILAR
1
2

Configuring
Option Description
Oracle-Dblink- Enables the support of remote databases with different character sets. You can
Character-Set2 enter this parameter any number of times in the configuration file for multiple
view forms on different remote databases with different link names. The syntax is
as follows:
Oracle-Dblink-Character-Set: <linkname> <charset>
For example:
Oracle-Dblink-Character-Set: eng.remedy.com shift-jis
The <linkname> should exactly match LINK in the phrase
OWNERNAME.TABLENAME@LINK in the table name of the View form on the remote
database.
Supported character sets are utf-8, utf-16, ucs-2, euc, and shift-jis.
For more information about view forms, see the Form and Application Objects
guide.
Oracle-Search-On- Defines whether CLOBs can be searched. Valid values are T and F. If the option is
Clob2 set to T, when the search is performed, the qualification can include all the diary
fields and character fields that are stored in the database as CLOB columns.
Including these fields affects performance, and indexes cannot be used for this
type of query. If the option is set to F, these fields are not included. CLOBs can use
the operator LIKE, but not =. The default is F (do not allow search on CLOBs).
Oracle-SID1 The system ID for the underlying database (applicable for Oracle databases only).
Oracle-Clob-Storage- Controls the Oracle CLOB storage. The default value of this setting is F, and new
In-Row CLOBs will be “out of row.”
If the setting is set to T, all CLOBs to be created are “in row.”
1
Oracle-Two-Task The two-task environment setting for the underlying database (applicable for
Oracle databases only).
Per-Thread-Logging A flag indicating whether you want to create per-thread log files. Valid values are
T and F. If set to T, per-thread log files will be created. The default value is F (off).
Plugin2 File name of one or more plug-ins that the plug-in service will load. The file name
of the DLL or shared object is provided. The file name might be an absolute file
name or might be relative to the AR System installation directory. You can have
as many Plugin: lines in the ar.conf (ar.cfg) file as needed, but only one file
name can be listed for each occurrence of the option.

Option Description
Plugin-ARDBC-Threads2 The number of threads that are dedicated to handling ARDBC requests from the
AR System server. Optionally, you can specify a maximum number of threads, as
shown in the following example:
Plugin-ARDBC-Threads: <minimum number of threads>
[<maximum number of threads>]
To specify a minimum of 3 threads and a maximum of 10, the syntax is:
Plugin-ARDBC-Threads: 3 10
By default, 1 thread is initiated if this option is not specified. The plug-in service
will increase the number of threads for a given plug-in if there is sufficient
demand up to the “maximum number of threads.”
Plugin-AREA-Threads2 One can specify the number of threads that are dedicated to handling AREA
requests from the AR System server. Optionally, you can specify a maximum
number of threads, as shown in the following example:
Plugin-AREA-Threads: <minimum number of threads>
[<maximum number of threads>]
Plugin-AREA-Threads: 3 10
Plugin-Disable- Specifies whether the plug-in service will accept calls from a remote server. Valid
Remote2 values are T and F. If the option is set to T, the plug-in service accepts calls only
from an AR System server running on the local machine. The default is F (allow
calls from a remote server).
Plugin-Filter-API- One can specify the number of threads that are dedicated to handling AR System
Threads2 Filter API requests from the AR System server. Optionally, you can specify a
maximum number of threads, as shown in the following example:
Plugin-Filter-API-Threads: <minimum number of threads> [<maximum
number of threads>]
Plugin-Filter-API-Threads: 4 10
1
2

Configuring
Option Description
Plugin-Log-File The name of the file to use if plug-in tracing is turned on (see “Debug-mode” on
Plugin-Log-Level A setting that determines the level of detail for log messages. Valid values are as
follows. The values represent the amount of log information that is printed. The
lower the value, the more information that is included.
ARPLUGIN_OFF (Value=10000)—No log information is printed.
ARPLUGIN_SEVERE (Value=1000)—Only severe messages are printed. This is
the default value if no log level is specified.
ARPLUGIN_WARNING (Value=900)—Severe and warning messages are printed.
ARPLUGIN_INFO (Value=800)—Status, severe, and warning messages are
printed.
ARPLUGIN_CONFIG (Value=700)—Configuration, status, severe, and warning
messages are printed.
ARPLUGIN_FINE (Value=600)—Internal exceptions.
ARPLUGIN_FINER (Value=500)—Trace logs that log tasks as they are executed
within the system.
ARPLUGIN_FINEST (Value=400)—Code-level information.
ARPLUGIN_ALL (Value=100)—All log information is printed.
Plugin-Loopback- The RPC socket number for the private server queue to which loopback plug-in
RPC-Socket2 API calls should be directed. The acceptable values are in the following ranges:
390621–390634, 390636–390669, and 390680–390694.
Loopback plug-ins (like the Report Creator plug-in) that make calls back into
AR System, will use this value to determine the queue to request. By default, the
API calls that the plug-in makes are directed to a queue that corresponds with the
call type. To be effective, the server must be configured to have the designated
private queue for this setting.
Plugin-Password If this option is specified, arplugin will accept connections only from AR System
servers that have been configured to use the same password by way of the
Server-Plugin-Target-Password attribute.
If this option is not specified, arplugin will accept connections from AR System
servers that have not been configured to use a password.
1
2

Option Description
Plugin-Path2 Specifies the search path used to load a plug-in. The path will be appended to the
current value of LD_LIBRARY_PATH (AIX, Linux, Solaris), SHLIB_PATH (HPUX),
or PATH (WINNT). You can list more than one Plugin-Path; each path is
appended in the order it appears in the configuration file. The syntax is:
Plugin-Path: <path-name>[<delimiter><path-name>]
with no spaces between the delimeter and the path.
For example:
UNIX
Plugin-Path: /usr/ar/bin:/usr/ar/common/xyz
Windows
Plugin-Path: C:\Program Files\AR System\arserver;C:\Program
Files\AR System\common\xyz
Plugin-Port2 The port number on which the plug-in service will wait for incoming requests.
Preference-Server- Specifies if users are forced to use centralized preferences. Following are the
Option preference server settings:
1—Users can choose to use a preference server, if a preference server is
available.
2—Users must use the specified preference server.
3—Users must use a preference server, but they cannot use this server as a
preference server. If users choose a server that is not a preference server, a
warning is returned.
Private-RPC-Socket The specific RPC program number that determines the type of queue to which
requests will be routed, as well as the number of threads running on that queue.
RE-Log-File-Location2 The location of the Reconciliation Engine's log file.
Read-Only-Tran-Off2 Causes AR System not to create database transactions when only reading data.

Configuring
Option Description
Record-Server-Events Specifies the server events that you want to log. When you enter a value for
specific server events, those events are logged in the Server Events form, thereby
making server-related changes available to workflow and API programs. Enter the
values separated by semicolons as in the following example:
Record-Server-Events: 4;8;9;12;14;
For information about the Server Events form, viewing recorded server events,
and using server events in workflow, see Chapter E, “Working with the Server
Events form.”
Enter the following values for the events you want to record:
1—Form
2—Field
3—Menu
4—Filter
5—Import
6—Active Link
7—Escalation
8—View
9—Container
10—User
11—Group
12—Server Setting
13—Alert Client Registration
14—Archive
15—Server Group Actions
Register-With- This setting can be used to prevent the AR System server from registering with a
Portmapper portmapper. This feature is to be used in conjunction with setting specific ports
to enable you to run servers on machines that do not have a portmapper. Valid
values are T and F. The default is T (register with portmapper).
No more than one server should attempt to register with AR System Portmapper
in an environment with multiple servers on one machine.
Remedy-App-Service- Specifies, in encrypted form, the password that AR System application services
Password such as AR System Approval Server will use to access the AR System server.

Option Description
RPC-Non-Blocking-IO2 This parameter enables the AR System on compliant systems to receive remote
procedure calls in a non-blocking mode. Without this setting, the server must
receive an entire RPC header before processing a different one. With this setting,
the system can process multiple headers at the same time. Set this parameter to T
(TRUE) and then restart your AR System server to run in RPC non-blocking
mode. The default for this parameter is F (FALSE); use the following syntax to set
to TRUE:
RPC-Non-Blocking-IO: T
This functionality is not supported on Windows and Linux operating systems.
The advantages of RPC-Non-Blocking-IO mode are as follows:
Prevents remote attackers from disabling RPC services.
Prevents invalid or corrupt packets from temporarily disabling the arserverd
service.
Important: The following patches must be installed to enable your system to use
this feature. If these patches are not installed, you will see either an error message,
or most of your RPC calls will be blocked.
HP
PHNE_29210 - HPUX 11.0
PHNE_29211 - HPUX 11i
Solaris
108993-38 - Solaris 8
113319-19 - Solaris 9
IBM
Does not specify a specific patch number. There might be multiple file sets
required. (If you do not obtain an IBM patch, there is a possibility that your server
could crash.)
Fix for Authorized Problem Analysis Report (APAR) IY61602 - AIX 5.3
Fix for APAR IY61409 - AIX 5.2

Configuring
Option Description
Save-Login A value indicating whether users must log in to client tools. Allows users to save
a previous login of their choice.
0—Controlled by user (default setting).
1—Do not force a login that is controlled by the administrator.
2—Force login that is controlled by the administrator.
This option does not apply to the mid tier.
SCC-Comment-Checkin An integer value (0 or 1) indicating whether a source code control integration
requires you to enter a comment at checkin time. The default value is 0 (no
comment is required).
SCC-Comment-Checkout An integer value (0 or 1) indicating whether a source code control integration
requires you to enter a comment at checkout time. The default value is 0 (no
comment is required).
SCC-Enabled An integer value (0 or 1) indicating whether a source code control system is being
used with AR System. The default value is 0 (source code is disabled).
SCC-Integration-Mode An integer value (0 or 1) indicating the level of source code control integration.
A 0 value means Advisory. A 1 value means Enforced. The default is 0. For more
information about these modes, see “Server information—Source Control tab”
on page 171.
SCC-Provider-Name The name of the Source Code Control Provider name; for example, Visual Source
Safe.
SCC-Target-Dir A character string for the source code control system target directory. If none is
present, this value is NULL. This string is limited to 255 characters.
Server-Connect-Name2 An option for changing the name of a server in a server group. By default, a server
in a server group uses a fully qualified server name with domain to identify itself.
Others servers in the group use this name to communicate. Add the following line
to change the server name:
Server-Connect-Name: myservername
If a common server alias is specified, the Server-Connect-Name option is
required.
This name must be resolvable by DNS and is used exactly as specified. For more
information, see “Running servers as part of a group” on page 185.
Server-directory1 The data directory for AR System, expressed as a full path name. This directory
contains support files and log files for the AR System server.

Option Description
Server-Group-Email- Establishes the port number (RMIPort) for email administration in BMC
Admin-Port2 Remedy Email Engine. If the port number in BMC Remedy Email Engine is
changed from the default, set this AR System server configuration to the same
port number to allow the server to communicate email administration
information to BMC Remedy Email Engine during server group processing.
For example:
Server-Group-Email-Admin-Port: 2020
Server-Group- Establishes the port number (RMIRegistryPort) for flashboards administration in

Flashboards-Admin- the Flashboards server. If the port number in BMC Remedy Flashboards is
Port2 changed from the default, set this AR System server configuration to the same
port number to allow the server to communicate flashboards administration
information to the Flashboards server during server group processing.
For example:
Server-Group-Flashboards-Admin-Port: 2021
Server-Group-Log-File The name and location of the server group trace log file. The default is
arsrvgrp.log. For example, the file location might be:
c:\temp\servgroup.log.
Server-Group-Member A flag that indicates whether the server is a member of a server group. Valid values
are T and F. The default is F.
Server-Group-Signal- Indicates the method that a server uses to notify other servers in the group that
Option2 definition cache changes have occurred. If the value for this option is set to T, the
server uses arsignal to cause cache (definition) changes in other server group
members. If the value for this option is set to F (the default), a server indicates that
definition changes have occurred by posting signals in the database. The signal is
read by other servers in the group at their preset check intervals. Because of an
intentional delay used to avoid multiple recaches, the servers will not recache
until after a check interval cycle in which there are no new recache signals. The
database posting method reduces server activity, but does not react as quickly as
the arsignal method. For more information, see “Running servers as part of a
group” on page 185.

Configuring
Option Description
Server-Name An alias that is always interpreted as the current server. The option is used in
multiple server installations to differentiate servers. If you specify a value for
Server-Name, type that value after the -h option when you use the arreload
command-line utility.
If you have a value for Server-Name, and you use arreload without the -h
option and the Server-Name value, arreload will use the default server name
rather than the name specified by Server-Name.
The Server-Name value is not fully qualified. For example, type alpha instead of
alpha.remedy.com.
Note: If you are running in a server group and you use a common server alias, you
must also define the Server-Connect-Name option. See “Server-
Connect-Name2” on page 335.
Server-Plugin-Alias2 When the AR System server performs a call to a plug-in service, it must determine
if the plug-in name is an alias. Aliases can be used to direct the AR System server
to access a plug-in service that is running on a different host or is listening at a
specific port number. The syntax for this option is as follows:
Server-Plugin-Alias:
<alias_name>
<real_name>
<host_name>[:<port_number>]
Workflow (that is, references to AR Filter API and ARDBC plug-ins) references a
plug-in name. This name can be an alias to a real plug-in running on a specific
host at a given port number. This allows you to locate a plug-in on a remote host
or to run more than one instance of a plug-in on one host. For example, to run
the RMDY.ARDBC.XML plug-in on the remote host foo at port number 12345, you
would add the following text to your ar.cfg:
Server-Plugin-Alias: RMDY.ARDBC.XML RMDY.ARDBC.XML foo:12345
Note that the alias and real plug-in names can be identical if you are simply
locating the plug-in on a remote host. If you want to run more than one instance
of the plug-in on the same or different hosts, you would create different aliases
that reference the same plug-in running on their respective hosts.
Server-Plugin- The number of seconds within which the plug-in service must respond to the call
Default-Timeout before an error is returned. The minimum value is 0, and the maximum is 600.
The default is 60 seconds.
Server-Plugin-Target- The AR System server uses the specified password whenever communicating with
Password a plug-in service running at the host name and port number specified. The syntax
for this option is as follows:
Server-Plugin-Target-Password: <host_name>:<port_number>:
<encrypted_password>

Option Description
Server-Side-Table- For server-side table fields, this number determines the number of entries (or size
Chunk-Size of the chunk) that the server will retrieve at one time from the database and store
in memory to process during filter or filter guide actions. The server then
retrieves, stores, and processes the next chunk until all the rows have been
processed. Entering a value of zero (0) will cause the server to retrieve an
unlimited number of rows. The default is 1000 rows.
Entering a low value in this field causes the server to process smaller chunks,
which keeps the server memory usage down but results in slower processing
because the server will need to access the database many times, especially for large
tables. Entering a high value will cause the server to retrieve and process large
chunks of data and access the database fewer times. This results in higher
performance at the cost of memory use.
Server-Stats-Rec- Defines (in seconds) how often the server will record server statistics. The default
Interval is 60 seconds.
Server-Stats-Rec-Mode The server statistics recording mode determines what is written to the server
statistics form. There are three modes designated by the following numerical
values:
0—Indicates that recording is off. (This is the default.)
1—Indicates that the server records only the cumulative queue statistics.
Cumulative statistics are the sum of all the individual queue statistics.
2—Indicates that the server records both the cumulative queue statistics and
the individual queue statistics. One entry will be written for the cumulative
statistics and a separate entry will be written for each queue.
You can read the statistics in the Server Statistics form, which is installed when
you install AR System. For more information, see the Optimizing and
Troubleshooting AR System guide.
Set-Process-Timeout The number of seconds the AR System server waits before ending a Set Fields
process that has not completed. Valid values for this option are 1 through 60. The
default value is 5 seconds.
SQL-Log-File The name of the file to use if SQL tracing is turned on (see “Debug-mode” on
SQL-Secure-Connection A flag that indicates what type of authentication to use to connect AR System to
an MSSQL database. Set this flag to T to use Windows Authentication or to F to
use SQL Authentication. This flag is valid only if you are using an MSSQL
database.
1
2

Configuring
Option Description
SQL-Server-Set-ANSI- Causes the server to issue a SET ANSI_NULLS ON command.
Defaults2
Submitter-Mode A setting indicating whether the Submitter field can be changed and whether the
submitter of a request must have a write license to modify it. Valid values for this
option are 1 (locked) and 2 (changeable). The default value is 2.
In locked mode, the Submitter field cannot be changed after submission, and, if
the Submitter group has change permission, the request can be modified by
submitters with a read or write license, but not by users with a restricted read
license.
In changeable mode, the Submitter field can be changed after submit, but the
submitter must have a write license to modify the request (if the Submitter group
has change permission).
Suppress-warnings2 A series of zero or more message numbers (separated by spaces) that identify the
informational or warning messages that the system should suppress. Can be used
to suppress server warnings and notes only.
Sybase-Character-Set1 The alternate character set to use for communications between AR System and
the underlying database (applicable for Sybase databases only).
Sybase-Server-Name1 The logical server name of the underlying database (applicable for Sybase and MS
SQL databases only). The default name is SYBASE.
System-Logging- A bit mask that sets logging options for the operating system. Acceptable values
Options2 are as follows:
Bit 1 (Value=1) Suppress logging to the system log file.
A value of 0 indicates normal system logging and is the default.
TCD-Specific-Port The specific TCP port to use for the arserver process. The dispatcher is randomly
assigned to an available port if you do not specify this option. Note that TCD
stands for transaction control daemon.
Thread-Debug-mode Turns on thread logging.
Thread-Log-File The name of the file to use if thread tracing is turned on (see “Debug-mode” on
1
2

Option Description
Two-Digit-Year- An integer that specifies the cutoff year for interpreting a two-digit year as a four-
Cutoff2 digit year. For example, if the two-digit cutoff year is 2040, a two-digit year would
fall between 1941 and 2040. A date of 1/1/55 would be interpreted as 1/1/1955 and
a date of 1/1/30 would be interpreted as 1/1/2030.
If a two-digit year cutoff is not specified, a rolling two-digit year is used. Two-
digit years would then be interpreted as the years between the current year plus
29 years and the current year minus 70 years. For example, if the current year is
2002, two-digit years would be interpreted as years between 1922 and 2031.
Use-Password-File For Windows—A flag indicating whether the Windows domain service is used to
validate users not registered with AR System. If so, users in the Windows domain
are considered valid users of AR System and are assigned to the Public group.
Valid values are T and F. The default value is F (do not use domain service). This
is set in the Configuration tab of BMC Remedy Administrator using the
Authenticate Unregistered Users check box.
For UNIX—A flag indicating whether the /etc/passwd file is used to validate users
not registered with AR System. If so, users in /etc/passwd are considered valid
users of AR System and are assigned to a group identified by the UNIX group ID.
Valid values for this option are T and F. The default value is F (use password file).
User-Log-File The name of the file to use if user tracing is turned on (see “Debug-mode” on
XML-VUI-Export- A flag indicating whether to export localized views when forms are exported in
Default-Is-Localized2 XML definition format. Valid values for this option are T and F. The default is F.
1
2
Examples The following configuration file identifies two directory locations:

# Configuration file for AR System server
Server-directory: /usr/ar/db
Dbhome-directory: /usr/SQL-DB
The location of the data directory for this server is /usr/ar/db. The location of
the SQL database files is /usr/SQL-DB.

Configuring
ardb.conf (ardb.cfg)
Description The ardb.conf (ardb.cfg) file contains SQL clauses that an administrator can
append to the SQL statements issued by AR System when a form, field, or
index is created or modified.
Create the ardb.conf file in your configuration directory, which is the conf
directory of the ar_install_dir. On UNIX, the directory can be changed by
setting the ARCONFIGDIR environment variable.
When you create a form, field, or index, AR System references the ardb
configuration file for clauses to append to the SQL statement. If it finds no
matching information, AR System creates the form, field, or index as it
would normally. If it finds matching information, it appends the specified
clause to the SQL statement that creates the form, field, or index.
WARNING: AR System does not verify that the SQL clauses specified in your
ardb configuration file are correct or safe. AR System merely attaches the
SQL clause to the statement used when a form or index is created. Because
you can append any valid SQL clause (the entire clause must exist on one
line in the file because no new-line characters are allowed) to the CREATE
statement for a form, field, or index, use this feature wisely.
The format of this file is organized by forms.
To create an ardb.conf file
1 Type a line for the name of the form and a line for the clause you want added
to the CREATE statement, as follows:
Form: <form_name>
Clause: <clause>
Note: When you use BMC Remedy Administrator to change the name of a
form, the ardb configuration file is edited automatically to match the new
name.
2 Include field clause information below the applicable form information.

a Add a field line with an open brace.
Field {
ardb.conf (ardb.cfg) 341

Include a space between Field and the open brace.

b Add a line for the field ID.
Id: <field_ID>
c Add a line for the SQL clause.

Clause: <clause>
d Place the closing brace on its own line below the clause line.
3 Include index clause information.
a Add an index line with an open brace.
Index {
Include a space between Index and the open brace.

b Add a line for the field IDs in the index.
Id: <index_ID>
If an index contains multiple fields, add several field ID lines before the
clause for that index.
c Add a line for the SQL clause.
Clause: <clause>
Clauses you specify for the tables of a form are not attached automatically
to any index you create for that form. You must specify the clause in the
index clause. For example, if you specify that a form is to reside in a
specific part of your database, and you want an index for that form to
reside in the same space, you must specify the clause for both the form and
index.
d Place the closing brace in a line of its own below the clause line for the
index.
The file looks something like this:
Form: <form_name>
Clause: <clause>
Field {
Id: <field_ID>
Clause: <clause>
}
Index {
Id: <index_ID>
Id: <index_ID>
Clause: <clause>
}

Configuring
Leading spaces in the ardb configuration file are ignored, so you might want
to add them to keep your file organized.
When you create or update the ardb.conf file, the changes do not take place
immediately—changes occur when the table (or index) is restructured.
Synopsis Windows—<ar_config_dir>\Conf\ardb.cfg
Examples The following example shows ardb configuration file information for the HD-
Answer form on an Oracle database. The tables for the HD-Answer form will
build on segment two. The indexes include the Submitter (ID 2), Status (ID
7), and Assigned To (ID 4) fields. The clauses for the indexes instruct the
database to leave 70 percent of each index free for updates and insertions.
Form:HD-Answer
Clause:TABLESPACE seg2
Field {
Id:536870913
Clause: NOT FOR REPLICATION
}
Index {
Id:2
Id:7
Clause:PCTFREE 70
}
Index {
Id:4
Clause:PCTFREE 70
}
armonitor.conf (armonitor.cfg)
Description The armonitor.conf (armonitor.cfg) file is read by the armonitor
(armonitor.exe) binary, which executes the commands listed in the
configuration file.
Synopsis UNIX—/etc/arsystem/<server_name>/armonitor.conf
Windows—<ar_install_dir>\Conf\armonitor.cfg
Options The format of this file consists of two types of entries. One type of entry is two
fields, separated by a space or tab:
<parameter> <value>
armonitor.conf (armonitor.cfg) 343

Each parameter represents a particular configuration option. The associated

value represents the current setting for that option. All numeric values are in
a base 10 system. The available configuration options (and the valid settings
for each) are described in the following sections. Lines that do not begin with
one of these options are ignored.
The other type of entry is a command issued by armonitor to start various
server processes. Lines with a pound sign (#) in column 1 are treated as
comments and ignored.
The valid parameter entries are listed in the following table.
Table B-2: armonitor parameters
Option Description
Environment- Defines environment values established for armonitor. You can include many
variable instances of the Environment-variable option in the armonitor.conf
(armonitor.cfg) file. Before initiating any processes, armonitor will set any
values specified through this option in its environment. Then, any processes that
armonitor initiates will inherit these values. This is a platform-independent way of
defining environment variables.
An example of the format for this option is:
Environment-variable: ARDATEONLY=MM/dd/yyyy
Monitor-directory Defines the directory of the armonitor. Initially, the installer creates this value, and
the value is the same as the installation directory.
SNMP-Agent-Enabled This setting permits the armonitor to start the Remedy SNMP Agent and to
establish a link to it. Set to T to enable the Remedy SNMP Agent.

Appendix
C AR System server components

and external utilities
This section contains information about some AR System server executables

and three external utilities. Each item is listed by its UNIX name. If there is a
Windows equivalent, it is listed in parentheses after the UNIX name.
AR System server components (page 346)
External utilities (page 350)
AR System server components and external utilities 345

AR System server components
arforkd (UNIX only)

Description The arforkd process reduces the amount of memory an AR System server
uses when forking new processes as a result of filters that run processes, set
fields to values returned from processes, or send email notifications. This
small process runs new processes on behalf of the server. The AR System
server starts the arforkd process and restarts the arforkd process if it dies.
The ar.conf file contains configuration information for arforkd. For more
information about this file, see “ar.conf (ar.cfg)” on page 300.
armonitor (armonitor.exe)
Description The armonitor process starts and restarts the AR System server, AR System
plug-in server, distributed server, and processes specified in the
armonitor.conf (UNIX) or armonitor.cfg (Windows) file. On Windows, it is
typically started from the Services panel. If you need to start armonitor
manually, you must specify -m as a command line argument.
If a process terminates, armonitor restarts the server. If the server dies more
than four times within 30 seconds, armonitor will give up restarting that
server.
Synopsis UNIX—armonitor -c <full_path_to_armonitor_config_file> -s <server_name>

Windows—armonitor -c <full_path_to_armonitor_config_file> -m
Options You can specify the following options on the command line:
-c
Causes the monitor to load information from the configuration file

armonitor.conf (armonitor.cfg).
-m
Windows only—Runs the process in manual mode, not as a Windows

service. If you run the process in a DOS window, you must use the -m
option.
346 Appendix C—AR System server components and external utilities

Configuring
-s
UNIX only—Name of the server that you specify at the time of

installation. This can be used to identify a monitor process when
multiple monitors are running on the same host.
arplugin (arplugin.exe)
Description The arplugin process executes the plug-in service, which implements and
deploys several server-side APIs. The armonitor process initiates arplugin.
Synopsis arplugin [-i <install_directory>] [-m] [-s <server_name>]
Options You can specify the following options on the command line:
-i
Specifies the directory where the AR System server was installed.

-m

option.
-s
Specifies the server name that contains the plug-in.
Environment ARINSTALLDIR
The directory where the AR System server was installed. The -i option takes
precedence over this environment variable.
UNIX—The default is /usr/ar.
Windows—The default is taken from the Windows Registry. If the install
location was not added to the Windows Registry when the AR System server
was installed, the default is then C:\arservdb.
ARCONFIGDIR
The directory where the ar.conf (ar.cfg) configuration file is stored. The
default is in the conf subdirectory of the AR System server installation
directory (/usr/ar/conf on UNIX and C:\Program Files\AR System\Conf
on Windows).
AR System server components 347

arserverd (arserver.exe)
Description The arserverd process (UNIX) or arserver.exe executable (Windows)
represents the main part of AR System. It handles all interactions between
clients and the database, making all access to the system dependent on this
process.
Although this process can be started manually on both platforms, it is most
often started with armonitor. On the UNIX platform, arserverd can be
started manually by using the command <ar_install_dir>/bin/arsystem
Start. On Windows or UNIX, if the process is shut down (whether
accidentally or purposely), you can restart it at any time.
In UNIX, sending a SIGUSR1 signal causes arserverd to reread all
configuration files. Sending a SIGHUP signal causes it to reread the
configuration files and reset all cached structure information. Generally,
these signals are only sent after performing a manual repair or restore
operation. However, neither causes any damage or adversely affects users
currently accessing AR System.
Synopsis arserverd [-s <server_name>] [-i <install_directory>]

[-l <license_directory>] [-m]
Options You can specify the following options in any order on the command line:
-i
Specifies the directory where the AR System server was installed.

-l
Specifies the directory where the arsystem.lic license file is stored.

-m

option.
-s
Name of the server you specified during the installation of AR System.
The directory where the ar.conf (ar.cfg) configuration file is stored. The
default is in the conf subdirectory of the AR System server installation
directory (<install_directory>/conf on UNIX and <install_directory>\conf on
Windows).

Configuring
ARDATE
The date format used by the program.

UNIX only—This value consists of a string of operators as defined by the
strftime library call (some combinations appear successfully, but cannot be
translated for input). If you do not set this variable, the system uses the date
format for the language specified by the LANG environment variable.
Windows only—This value consists of a string of operators as defined by
Regional Settings. If you do not set this variable, the system uses the date
format specified in the Regional Settings of the user account that runs the
service.
ARDATEONLY
The date format used by the program.

strftime library call. (Some combinations are displayed successfully but
cannot be translated for input.) If you do not set this variable, the system uses
the date format for the language specified by the LANG environment variable.
service.
ARTIMEONLY
The time format used by the program.

strftime library call. (Some combinations are displayed successfully but
cannot be translated for input.) If you do not set this variable, the system uses
the date format for the language specified by the LANG environment variable.
service.
Files UNIX
<ar_install_dir>/conf/ar or $ARCONFIGDIR/ar
<ar_install_dir>/conf/ar.conf or $ARCONFIGDIR/ar.conf
/etc/arsystem/<server_name>/arsystem.lic
/etc/services
AR System server components 349

Windows
<ar_install_dir>Conf\ar.cfg
C:Program Files\Common Files\arsystem\licenses\<server_name>
\arsystem.lic
<win_sys_dir>\drivers\etc\services
External utilities
arcache (arcache.exe)
Description The arcache utility executes the AR System interface that lets you update an
entry in the access control cache for a user or group, and lets you distribute
your change to the specified AR System servers. This program is generally
used in a multiple server environment with centralized access control. The
program is also used for error recovery in a single server environment.
Filters that execute on submit and modify to the User and Group forms are
typically used to run this program. Changes to those forms update the local
cache automatically. The filters make sure that all changes to user or group
information are distributed across the system.
If the server is running on a specific port and arcache cannot obtain the port
information from the portmapper, you must set the ARTCPPORT variable. For
example, if the port number is 2020, type the following command at a DOS
prompt:
set ARTCPPORT=2020
At a UNIX prompt, type:

setenv ARTCPPORT 2020
Synopsis arcache {-U|-G}{a|d} -e <entryId> [-g <groupList>] [-i <groupId>]

[-c <groupCategory>] [-q <“computed_group_qualification”>]
[-t<groupType>][-lw<writeLicense>][-m<mailAddress>][-n<name>][-p<password>]
[-s <server_name>] [-x <notifyMech>] [-d] [-u <authentication alias name>]
[-r <authentication alias string>]
Options You can specify the following options in any order on the command line:
-e
Specifies the Request ID associated with the user or group in the access
control cache (required). If you are adding a new user or group, you can
specify any value that does not already exist in the cache.

Configuring
-g
Specifies the set of groups to which the user belongs (applicable for
adding or updating users only). Group membership defines the
permissions the user has in the system. Use the group ID to identify
each group (separated by semicolons). Special group IDs are 1
(Administrator), 2 (Customize), and 5 (Subadministrator). For
example, if the group ID for the Technical Support group is 43, and you
want to assign the user to the Customize and Technical Support groups,
specify this option as -g "2;43;".
-G
Specifies the type of group cache operation. Valid values for this option
are a (add new or update existing group) and d (delete existing group).
The -G and -U options are mutually exclusive.
-i
Specifies the group ID (applicable for adding or updating groups only).

-c
Specifies the group category. Valid values for this option are 0 (regular
group), 1 (dynamic group), or 2 (computed group). The default value
is 0.
-q
Specifies the qualification for a computed group only. Specify this

option as "\ "A\ " OR 121 ", "121 OR ‘Demo’ ".
-t
Specifies the group type (applicable for adding or updating groups

only). Valid values for this option are 0 (none), 1 (view only), or 2 (view/
change). The default value is 0.
-lw
Specifies the type of write license to assign (applicable for adding or

updating users only). Valid values for this option are 0 (read), 1 (fixed),
or 2 (floating). The default value is 0.
-m
Specifies the default email address for sending messages (applicable for
adding or updating users only).
External utilities 351

-n
Specifies the name of the user or group (required for add operations,
recommended for delete operations).
-p
Specifies the password to assign (applicable for adding or updating

users only).
-s
Specifies the name of an individual AR System server to distribute your

change to. This option is required.
-U
Specifies the type of user cache operation. Valid values for this option
are a (add new or update existing user) or d (delete existing user). The -
U and -G options are mutually exclusive.
-x
Specifies the default alert mechanism to use (applicable for adding or

updating users only). Valid values for this option are 0 (none), 1
(notifier), or 2 (email). The default value is 1.
-d
Runs the program in debug mode. Messages that detail the progress of
each operation being performed are printed to stdout. Use this mode to
diagnose problems with the arcache process only.
-u
Specifies the user name of the authentication alias.

-r
Specifies the authentication string of the authentication alias.

See “Setting up an authentication alias” on page 116 for more
information about authentication aliases.

Configuring
Examples Add a new user, Sam Johnson, to the access control cache of all AR System
servers. Use 000000000000104 as the Request ID, samj@remedy.com as the
default email address, and notifier as the default alert mechanism. The
syntax is as follows:
arcache -Ua -e000000000000104 -n "Sam Johnson"-m "samj@remedy.com"
-x 1
No password or group membership is specified for this user.

Add an admin user with a fixed license. The syntax is as follows:
arcache -Ua -eTEMP999 -lw 1 -n "TEMPADMIN"-p"" -s bentley -g "1;"
To add a group ID, group type, and specify a computed group with a
qualification, the syntax is as follows:
arcache -Ga -e000000000000106 -n "TEMPADMIN" -i 8989 -t 2 -c 2
-q "\ "Administrator\ " OR ‘Sunnyvale’ "
Note: You can disable arcache with a setting in the ar.conf (ar.cfg) file.
When the setting is active you can still run arcache, but it has no effect on
the server, and the cache does not get flushed. For more information, see
“Disable-User-Cache-Utilities” on page 319.
Files UNIX—$ARCONFIGDIR/ar
Windows—Uses a ServerList Registry value.

arreload (arreload.exe)
Description The arreload utility executes the AR System interface that enables you to
empty the access control cache on one or more AR System servers and reload
it from a particular User or Group form.
If you experience problems with permissions or behaviors in the Group or
User form, the cache might need to be emptied and reloaded. Run arreload to
reload the cache.
This process must run on the AR System server where the source form is
located (the source machine). It deletes cached requests on the specified
target machines and reloads the cache from the form on the source machine,
synchronizing the cache with the available users and groups defined in the
User and Group forms.
If the server is running on a specific port and arreload cannot obtain the port
information from portmapper, you must set the ARTCPPORT variable. For
example, if the port number is 2020, type the following command at a DOS
prompt:
set ARTCPPORT=2020
At a UNIX prompt, type:

setenv ARTCPPORT 2020
Synopsis arreload -a <“adminUser”> {-u|-g} <“schema”> [-f]

[-p <“adminPassword”>] [-s <“server_name”>]
[-h <“Server-Name_value”>][-d]
Options You can specify the following options in any order on the command line.
Specify attributes within double quotes:
-a
Specifies a user with Administrator permission on the target servers

(required).

Configuring
-f
Deletes all user or group requests from the cache on the specified target
machines before reloading from the source machine. The arreload
utility deletes requests submitted by the source machine only if you do
not specify this option. In multithreaded server environments where
access control is being managed remotely (using arcache), the existing
cache requests might have been submitted from different machines.
Specifying this option causes requests submitted from any server other
than the source machine to be lost from the cache of the target
machines because all requests are deleted from the cache, regardless of
their source. Specifying this option has no effect if access control is
being managed locally (that is, the local machine is the only server
submitting requests to the cache), unless the server has been renamed
or moved to a different machine. In that case, this option is useful for
clearing out obsolete definitions that are no longer recognized as being
related to the local server, and would otherwise not be removed. This
helps avoid duplicate records that can corrupt the cache.
-g
Specifies the name of the source form for reloading group requests
(required if you do not specify the -u option).
-h
Specifies the name of the server if you have added a Server-Name value in
the ar configuration file. If you have a value for Server-Name, and you use
arreload without the -h option, arreload will use the default server name
rather than the name specified by Server-Name.
-p
Specifies the password for the user specified by the -a option (required
if a password is defined for that user).
-s
Specifies the name of an individual AR System server on which to

reload the cache. This option is required.
-u
Specifies the name of the source form for reloading user requests
(required if you do not specify the -g option).

-d
Runs the program in debug mode. Messages are printed to stdout and
detail the progress of each operation being performed. Use this mode
to diagnose problems with the arreload process only.
AR System configuration files are stored. If you do not set this variable, this
directory defaults to <ar_install_dir>/conf.
Examples Connect as Admin (using the password fun4me) and delete all user requests
from the access control cache of all AR System servers. Reload the cache on
all machines from the User form on the current machine. An example
follows, the attributes are enclosed in double quotes:
arreload -u “User” -a “Admin” -p “fun4me” -f
Reload the cache on all machines from the Group form and the User form on
the current machine. An example follows, the attributes are enclosed in
double quotes:
arreload -u “User” -g “Group” -a “Admin” -p “fun4me” -f -d
Note: You can disable arreload with a setting in the ar.conf (ar.cfg) file. When
the setting is active you can still run arreload, but it has no effect on the
server, and the cache does not get flushed.
Files UNIX—$ARCONFIGDIR/ar
arsignal (arsignal.exe)
Description The arsignal utility forces an AR System server to load or reload
information. The process can be run on any machine.
Synopsis arsignal {-c|-g|-l|-a} <server_name>[:port][sigArgument]

The server name identifies the server that is to reload information. If a TCP
port is to be specified as well (needed if the server does not register with
AR System Portmapper), it is appended to the server name, separated by a
colon. The string sigArgument is applicable when using the -a option.

Configuring
Options You can specify one of the following options:

-c
Causes the server to reload information from its configuration file

ar.conf (ar.cfg).
-g
Causes the server to reload group and data dictionary information from
the database.
-l
Causes the server to reload license information.

-a
Causes the server to update internal Alert user information using the
details provided in sigArgument. For more information, see the BMC
Remedy white paper, “Using a Hardware Load Balancer with AR System
<version number> Servers.” White papers are available from the
Customer Support website at http://supportweb.remedy.com.


Appendix
D Date and time formats

Short date formats (page 360)
Long date formats (page 361)
Day formats (page 362)
Time formats (page 362)
Additional characters (page 363)
Date and time formats 359

Short date formats

The following table lists all the available Short Date Formats in the
AR System User Preference form.
Short Date Format Description Examples

MM/dd/yyyy Month, Day, Year (leading zero for single-digit months, leading 01/01/2005
zero for single-digit days, four-digit year) 01/15/2005
MM/dd/yy Month, Day, Year (leading zero for single-digit months, leading 01/01/05
zero for single-digit days, two-digit year) 01/15/05
MM/d/yyyy Month, Day, Year (leading zero for single-digit months, four- 01/1/2005
digit year) 01/15/2005
MM/d/yy Month, Day, Year (leading zero for single-digit months, two- 01/1/05
M/dd/yyyy Month, Day, Year (leading zero for single-digit days, four-digit 1/01/2005
year) 1/15/2005
M/dd/yy Month, Day, Year (leading zero for single-digit days, two-digit 1/01/05
year) 1/15/05
M/d/yyyy Month, Day, Year (four-digit year) 1/1/2005

1/15/2005
M/d/yy Month, Day, Year (two-digit year) 1/1/05
1/15/05
dd/MM/yyyy Day, Month, Year (leading zero for single-digit days, leading zero 01/01/2005
for single-digit months, four-digit year) 15/01/2005
dd/MM/yy Day, Month, Year (leading zero for single-digit days, leading zero 01/01/05
for single-digit months, two-digit year) 15/01/05
dd/M/yyyy Day, Month, Year (leading zero for single-digit days, four-digit 01/1/2005
year) 15/1/2005
dd/M/yy Day, Month, Year (leading zero for single-digit days, two-digit 01/1/05
year) 15/1/05
d/MM/yyyy Day, Month, Year (leading zero for single-digit months, four- 1/01/2005
d/MM/yy Day, Month, Year (leading zero for single-digit months, two- 1/01/05
d/M/yyyy Day, Month, Year (four-digit year) 1/1/2005

15/1/2005
360 Appendix D—Date and time formats

Configuring
Short Date Format Description Examples

d/M/yy Day, Month, Year (two-digit year) 1/1/05
15/1/05
yyyy/MM/dd Year, Month, Day (four-digit year, leading zero for single-digit 2005/01/01
months, leading zero for single-digit days) 2005/01/15
yyyy/MM/d Year, Month, Day (four-digit year, leading zero for single-digit 2005/01/1
months) 2005/01/15
yyyy/M/dd Year, Month, Day (four-digit year, leading zero for single-digit 2005/1/01
days) 2005/1/15
yyyy/M/d Year, Month, Day (four-digit year) 2005/1/1

2005/1/15
yy/MM/dd Year, Month, Day (two-digit year, leading zero for single-digit 05/01/01
months, leading zero for single-digit days) 05/01/15
yy/MM/d Year, Month, Day (two-digit year, leading zero for single-digit 05/01/1
months) 05/01/15
yy/M/dd Year, Month, Day (two-digit year, leading zero for single-digit 05/1/01
days) 05/1/15
yy/M/d Year, Month, Day (two-digit year) 05/1/1

05/1/15
Long date formats

The following table contains a complete list of the available Long Date
Formats that can be selected in the AR System User Preference form.
Format Example
dd MMMM, yyyy 01 January, 2005
dd MMMM, yy 01 January, 05
dd MMM, yyyy 01 Jan, 2005
dd MMM, yy 01 Jan, 05
d MMMM, yyyy 1 January, 2005
d MMMM, yy 1 January, 05
d MMM, yyyy 1 Jan, 2005
d MMM, yy 1 Jan, 05
MMMM dd, yyyy January 01, 2005
Long date formats 361

Format Example
MMMM dd, yy January 01, 05
MMMM d, yyyy January 1, 2005
MMMM d, yy January 1, 05
MMM dd, yyyy Jan 01, 2005
MMM dd, yy Jan 01, 05
MMM d, yyyy Jan 1, 2005
MMM d, yy Jan 1, 05
Day formats
The following table lists the available era formats in AR System User
Preference form.
Day Format Description Examples
EEEE Long day format. The day is Friday, Thursday.
displayed in full.
EEE Short Day format, three characters Fri, Thu.
only.
Time formats
The following table lists the available time formats available in the AR System
User Preference form.
Time Format Description Examples
h:mm:ss a Time in 12-hour format (no leading 1:23:45 AM, 10:23:45 PM
zero for single digit hours)
hh:mm:ss a Time in 12-hour format (leading 01:23:45 AM, 10:23:45 PM
H:mm:ss Time in 24-hour format (no leading 1:23:45, 22:23:45
HH:mm:ss Time in 24-hour format (leading 01:23:45, 22:23:45

Configuring
Additional characters
If you need to include additional characters in your custom date or time
display, include them in single quotes.:
Format Example
‘Date’ MM/dd/yy Date 01/01/05
‘Time’ hh:mm:ss a Time 01:23:45 AM
Additional characters 363


Appendix
E Working with the Server Events

form
The Server Events form enables you to capture server-related activities and
use them in workflow and API programs. You can select the server events
that you want to record, search and view the returned entries, and create
workflow to notify companion servers and interested clients of server
changes that could them.
Understanding the Server Events form (page 366)
Using server events in workflow (page 384)
For information about setting Server Event options, see “Server
information—Server Events tab” on page 176.
Working with the Server Events form 365

Understanding the Server Events form

The Server Events form captures the server changes that you record. You use
the Server Events form to notify other servers of cache changes if multiple
servers are sharing the same database, it can also notify interested clients of
cache changes and user or group events. For more information, see “Using
server events in workflow” on page 384.
Note: You might find server events especially helpful in a load-balanced

environment. However, with the server groups feature introduced in the
6.0 release, you will not need to use server events as part of the mechanism
for communicating between servers in a load-balanced environment.
For AR System 5.1 servers, see the Using a Hardware Load Balancer with
AR System 5.1 Servers whitepaper.
ForAR System 6.0 servers, see the Using a Hardware Load Balancer with
AR System 6.0 Servers whitepaper.
The options on the Server Events tab of the Server Information dialog box
enable you to specify which activities you want to record to the form. For
more information about selecting Server Events options, see “Server
information—Server Events tab” on page 176.
The Server Events form is similar to other AR System forms. You can add
additional fields and workflow to it, but you cannot delete the five reserved
fields, which are discussed in the following section.
How the Server Events form is created

The Server Events form is created automatically by the server and contains
five reserved fields:
800 AR_RESERV_SVR_EVENT_TYPE
801 AR_RESERV_SVR_EVENT_CAUSE
802 AR_RESERV_SVR_EVENT_DETAILS_1
366 Appendix E—Working with the Server Events form

Configuring
These five fields distinguish the Server Events form from all other forms.
There can be only one Server Events form in the AR System database;
therefore, only one form contains the five reserved fields specific to the Server
Events form: 800, 801, 802, 803, 804.
There are two primary instances in which a Server Events form can be
created.
Case 1: When the server starts, the server will create the Server Events form
automatically if the form does not already exist in the AR System database.
If you delete the Server Events form, the server will automatically
regenerate the form the next time the server is started.
Case 2: If you create your own Server Events form, you will need to supply
default values with the correct data type for the required core fields. If the
Server Events form already exists and you try to create a form with the five
reserved fields, the server will return an error when you try to save the
form. Error checking will not allow the existence of more than one Server
Events form.
The Server Events form can be viewed and modified using BMC Remedy
Administrator or driver. You can also rename the Server Events form.
However, if any of the five reserved fields are removed, the form will no
longer be a valid Server Events form.
Understanding the Server Events form 367

Types of events you can record

Various types of server events can be recorded, including server object, user,
group, server-setting, and alert changes.
Server event types

The #define statements for the event types in ar.h are:
#define AR_SVR_EVENT_CHG_SCHEMA 1
#define AR_SVR_EVENT_CHG_FIELD 2
#define AR_SVR_EVENT_CHG_CHARMENU 3
#define AR_SVR_EVENT_CHG_FILTER 4
#define AR_SVR_EVENT_CHG_IMPORT 5
#define AR_SVR_EVENT_CHG_ACTLINK 6
#define AR_SVR_EVENT_CHG_ESCAL 7
#define AR_SVR_EVENT_CHG_VUI 8
#define AR_SVR_EVENT_CHG_CONTAINER 9
#define AR_SVR_EVENT_CHG_USERS 10
#define AR_SVR_EVENT_CHG_GROUPS 11
#define AR_SVR_EVENT_CHG_SVR_SETTINGS 12
#define AR_SVR_EVENT_CHG_ALERT_USERS 13
#define AR_SVR_EVENT_ARCHIVE_DONE 14
#define AR_SVR_EVENT_SERVGROUP_ACTION 15
These numbers are meaningful when you are viewing the events recorded in
the Server Events form. For more information, see “Viewing the server
changes you recorded” on page 370.
Server object changes

Server object changes are changes to forms, filters, active links, escalations,
fields, VUIs, char menus, and containers. The AR System server will record
the API calls that caused the server object change. The AR System server will
record the server object change event type into the Event Type field and the
RPC call number of the API call in the Cause field. The information recorded
in the Event Details field depends on the server object. For example, when a
form is modified, the form name is recorded in the Event Details field. For a
complete listing of what is recorded in the Event Details field as well as the
API calls that are recorded based on corresponding event types and causes,
see Table E-1 on page 372.

Configuring
User/Group changes
When users or groups are added, modified, or deleted, an event is logged in
the Server Events form.
For user changes, the user change event type is logged in the Event Type field,
the event cause (user added, modified, or deleted) is logged in the Event
Cause field, and the entry ID and name of the user is recorded in the Event
Details field.
For group changes, the group change event type is recorded in the Event
Type field, the event cause (group added, modified, or deleted) is recorded in
the Event Cause field, and the entry ID and name of the group is recorded in
the Event Details field.
For a complete list of user and group changes, see Table E-2 on page 374.
User and group changes are recorded in the following cases:
User added, modified, or deleted using the User or Group form
User or group changes using the arcache utility
User or group changes using the arreload utility
Server setting changes

All changes to server configurations are logged in the Server Events form. The
server settings change event will be recorded in the Event Type field. The
numeric value of the server option (AR_SERV_INFO_XX) will be recorded in the
Event Cause field. (For more information about the different AR_SERV_INFO_XX
options, see the C API Reference Guide.) The datatype and value of the input
argument to the SetServerInfo call will be recorded in the Event Details field.
For server options that configure passwords, the password will be replaced by
an arbitrary number of asterisks for security purposes.
For a complete list of server setting changes, see Table E-3 on page 376.
Alert registration activity

When Alert users are registered or deregistered, an event is logged in the
Server Events form.
For a complete list of alert setting changes, see “Viewing alert registration
activity” on page 381.

Archive activity
When an archive activity is performed, an event is logged in the Server Events
form.
For a complete list of archive changes, see “Viewing archive activity” on
page 382.
Server group actions

When a server group action is performed (for example, a server in a server
group fails and another server takes over), an event is logged in the Server
Events form.
For a complete list of server group changes, see “Viewing server group
actions” on page 383.
Viewing the server changes you recorded

When you open the Server Events form in BMC Remedy User to search or
view the entries that have been recorded, you will see numbers and raw data
in the fields. You will not see textual descriptions explaining the data
returned for each of the four reserved fields. For example, if you recorded the
server events associated with adding a new user, a search on the Server Events
form will look similar to the screen in Figure E-1.

Configuring
Figure E-1: Adding a user
Only the numeric values for Event Type and Event Cause are returned, and
only a brief description is provided in the Event Details field. Use the tables
that follow to look up the description that corresponds to the type number
and cause number of the server event for which you need information.
Viewing server object changes

For object changes, the event type can be 1 through 9, depending on the type
of object change being recorded. The following information appears in the
fields on the Server Events form when an object change is recorded:
Event Type: 1 to 9
Event Cause: RPC call number of the API call
Event Details 1: Contents depend on the server object being recorded
Request ID: The unique number assigned to identify the entry
Event Date: Time and date that the event occurred
Submitter: User who caused the server object event

In the Event Details 1 field, the object names recorded for the Set calls are the
names of the objects before the Set operation. Therefore, if an ARSetSchema call
renames the form from AA to BB, AA will be the form name recorded in the
Event Details field for the server event.
For “Set” API calls, if the name of the object is changed, the Event Details 2
field will contain the old name of the object, and the Event Details 1 field will
contain the new name. If the name is not changed by the Set call, the Event
Details 2 field will contain a NULL datatype.
In the Event Details fields, semicolons separate multiple items. There are no
spaces after the semicolon, and the spaces after the semicolon in the table
below were added for display clarity. The string recorded in the Event Details
fieldscanhavemaximumlengthsof255bytes(AR_MAX_SVR_EVENT_DETAILS),not
including the NULL. If the value to record in the Event Details fields exceed
the maximum, the value will be truncated.
Table E-1: Server object changes
Type Cause Cause Event Details 1 Event Details 2 Event Details 3

Description
1 8 ARSetSchema form name old form name
1 9 ARCreateSchema form name
1 10 ARDeleteSchema form name
2 13 ARSetField field ID; field name form name old field name
2 14 ARCreateField field ID; field name form name
2 43 ARDeleteField field ID; field name form name
2 56 ARDeleteMultiple field ID; field
Fields ID;…; field ID
3 17 ARSetCharMenu menu name old menu name
3 18 ARCreateCharMenu menu name
3 19 ARDeleteCharMenu menu name
4 22 ARSetFilter filter name old filter name
4 23 ARCreateFilter filter name
4 24 ARDeleteFilter filter name
5 35 ARImport

Configuring
Table E-1: Server object changes

Description
6 39 ARSetActiveLink active link name old active link
name
6 40 ARCreateActiveLink active link name
6 41 ARDeleteActiveLink active link name
7 49 ARSetEscalation escalation name old escalation

name
7 50 ARCreateEscalation escalation name
7 51 ARDeleteEscalation escalation name
8 63 ARSetVUI vui ID; vui name form name old vui name
8 64 ARCreateVUI vui ID; vui name form name
8 65 ARDeleteVUI vui ID; vui name form name
9 75 ARSetContainer container name old container
name
9 76 ARCreateContainer container name
9 77 ARDeleteContainer container name
Viewing user changes

For user changes, the event type will always be 10. The following information
appears in the fields on the Server Events form when a user change is
recorded:
Event Type: 10
Event Cause: User added (0), modified (1), or deleted (2)
Event Details 1: Entry ID of the user and the user login name
Event Details 2: Unused
Request ID: The unique number assigned to identify a particular request
Submitter: User who caused the user change event

Viewing group changes

For group changes, the event type will always be 11. The following
information appears in the fields on the Server Events form when a group
change is recorded:
Event Type: 11
Event Cause: Group added (0), modified(1), or deleted(2)
Event Details 1: Entry ID of the group and the group name
Submitter: User who caused the group change event
On the User form, the value in the Event Details 1 field for the user login
name is the value that is in reserved Field 101. For the Group form, the value
for the group name is the value that is in reserved Field 105.
When the user login name or group name is modified, the name recorded in
the Event Details 1 field is the name after it is modified. For example, if an
ARSetEntry is called to change the user’s login name from YY to ZZ, ZZ will be
recorded as the user’s login name in the Event Details 1 field.
below were added for display clarity.
Table E-2: User and group changes
Type Cause Cause Description Event Details 1

10 0 User added entry ID; user login name
10 1 User modified entry ID; user login name
10 2 User deleted entry ID; user login name
11 0 Group added entry ID; group name
11 1 Group modified entry ID; group name
11 2 Group deleted entry ID; group name

Configuring
Viewing server setting changes

For server setting changes, the event type will always be 12. The following
information appears in the fields on the Server Events form when a server
setting change is recorded:
Event Type: 12
Event Cause: The numeric value of the server option AR_SVR_INFO_XX
Event Details 1: The input datatype and input value to the SetServerInfo
call (For more information, see “Datatypes values” on page 381.)
Submitter: User who called SetServerInfo
For the following server options, the input password will be replaced with an
arbitrary number of asterisks before storing it in the Event Details 1 field:
AR_SERVER_INFO_DB_PASSWORD,
AR_SERVER_INFO_DSO_USER_PASSWD,
AR_SERVER_INFO_DSO_TARGET_PASSWD,
AR_SERVER_INFO_APP_SERVICE_PASSWD,
AR_SERVER_INFO_MID_TIER_PASSWD,
AR_SERVER_INFO_PLUGIN_PASSWD,
AR_SERVER_INFO_PLUGIN_TARGET_PASSWD
The datatype is included in the Event Details 1 field because AR_DATA_TYPE_NULL

will not have a value, only the datatype.
spaces after the semicolon, and the spaces after the semicolon in the
following table were added for display clarity.

An AR Import API call can result in many server object changes, but this
event will be recorded as one server event. Therefore, even though one
Import call can add or modify several forms, filters, and active links, the
server will record these changes as an Import object change event, and the
Cause field will contain the RPC call number of ARImport.
Table E-3: Server setting changes

12 5 AR_SERVER_INFO_ALLOW_GUESTS datatype; value
12 6 AR_SERVER_INFO_USE_ETC_PASSWD datatype; value
12 7 AR_SERVER_INFO_XREF_PASSWORDS datatype; value
12 8 AR_SERVER_INFO_DEBUG_MODE datatype; value
12 10 AR_SERVER_INFO_DB_PASSWORD datatype; value
12 15 AR_SERVER_INFO_SET_PROC_TIME datatype; value
12 16 AR_SERVER_INFO_EMAIL_FROM datatype; value
12 17 AR_SERVER_INFO_SQL_LOG_FILE datatype; value
12 18 AR_SERVER_INFO_FLOAT_TIMEOUT datatype; value
12 20 AR_SERVER_INFO_UNQUAL_QUERIES datatype; value
12 21 AR_SERVER_INFO_FILTER_LOG_FILE datatype; value
12 22 AR_SERVER_INFO_USER_LOG_FILE datatype; value
12 28 AR_SERVER_INFO_MAX_ENTRIES datatype; value
12 31 AR_SERVER_INFO_ESCALATION_LOG_ datatype; value
FILE
12 33 AR_SERVER_INFO_SUBMITTER_MODE datatype; value
12 34 AR_SERVER_INFO_API_LOG_FILE datatype; value
12 37 AR_SERVER_INFO_FTEXT_TIMEOUT datatype; value
12 45 AR_SERVER_INFO_DS_RPC_SOCKET datatype; value
12 46 AR_SERVER_INFO_DS_LOG_FILE datatype; value
12 47 AR_SERVER_INFO_SUPPRESS_WARN datatype; value
12 50 AR_SERVER_INFO_SAVE_LOGIN datatype; value
12 57 AR_SERVER_INFO_CACHE_LOG_FILE datatype; value
12 59 AR_SERVER_INFO_THREAD_LOG_FILE datatype; value

Configuring

12 65 AR_SERVER_INFO_TCD_TCP_PORT datatype; value
12 66 AR_SERVER_INFO_DSO_DEST_PORT datatype; value
12 78 AR_SERVER_INFO_NFY_TCP_PORT datatype; value
12 79 AR_SERVER_INFO_FILT_MAX_TOTAL datatype; value
12 80 AR_SERVER_INFO_FILT_MAX_STACK datatype; value
12 81 AR_SERVER_INFO_DEFAULT_ORDER_BY datatype; value
12 82 AR_SERVER_INFO_DELAYED_CACHE datatype; value
12 83 AR_SERVER_INFO_DSO_MERGE_STYLE datatype; value
12 84 AR_SERVER_INFO_EMAIL_LINE_LEN datatype; value
12 85 AR_SERVER_INFO_EMAIL_SYSTEM datatype; value
12 86 AR_SERVER_INFO_INFORMIX_RELAY_MOD datatype; value
12 87 AR_SERVER_INFO_PS_RPC_SOCKET datatype; value
12 88 AR_SERVER_INFO_REGISTER_ datatype; value
PORTMAPPER
12 89 AR_SERVER_INFO_SERVER_NAME datatype; value
12 90 AR_SERVER_INFO_DBCONF datatype; value
12 92 AR_SERVER_INFO_AP_RPC_SOCKET datatype; value
12 93 AR_SERVER_INFO_AP_LOG_FILE datatype; value
12 94 AR_SERVER_INFO_AP_DEFN_CHECK datatype; value
12 95 AR_SERVER_INFO_MAX_LOG_FILE_SIZE datatype; value
12 96 AR_SERVER_INFO_CLUSTERED_INDEX datatype; value
12 97 AR_SERVER_INFO_ACTLINK_DIR datatype; value
12 98 AR_SERVER_INFO_ACTLINK_SHELL datatype; value
12 99 AR_SERVER_INFO_USER_CACHE_UTILS datatype; value
12 100 AR_SERVER_INFO_EMAIL_TIMEOUT datatype; value
12 102 AR_SERVER_INFO_ENCRYPT_AL_SQL datatype; value
12 103 AR_SERVER_INFO_SCC_ENABLED datatype; value
12 104 AR_SERVER_INFO_SCC_PROVIDER_NAME datatype; value


12 105 AR_SERVER_INFO_SCC_TARGET_DIR datatype; value
12 106 AR_SERVER_INFO_SCC_COMMENT_ datatype; value
CHECKIN
12 107 AR_SERVER_INFO_SCC_COMMENT_ datatype; value
CHECKOUT
12 108 AR_SERVER_INFO_SCC_INTEGRATION_ datatype; value
MODE
12 109 AR_SERVER_INFO_EA_RPC_SOCKET datatype; value
12 110 AR_SERVER_INFO_EA_RPC_TIMEOUT datatype; value
12 111 AR_SERVER_INFO_USER_INFO_LISTS datatype; value
12 112 AR_SERVER_INFO_USER_INST_TIMEOUT datatype; value
12 113 AR_SERVER_INFO_DEBUG_GROUPID datatype; value
12 115 AR_SERVER_INFO_EA_SYNC_TIMEOUT datatype; value
12 114 AR_SERVER_INFO_APPLICATION_AUDIT datatype; value
12 117 AR_SERVER_INFO_SVR_SEC_CACHE datatype; value
12 118 AR_SERVER_INFO_LOGFILE_APPEND datatype; value
12 119 AR_SERVER_INFO_MINIMUM_API_VER datatype; value
12 120 AR_SERVER_INFO_MAX_AUDIT_LOG_FILE_SIZE datatype; value
12 121 AR_SERVER_INFO_CANCEL_QUERY datatype; value
12 122 AR_SERVER_INFO_MULT_ASSIGN_GROUPS datatype; value
12 123 AR_SERVER_INFO_ARFORK_LOG_FILE datatype; value
12 124 AR_SERVER_INFO_DSO_PLACEHOLDER_ datatype; value
MODE
12 126 AR_SERVER_INFO_DSO_SOURCE_SERVER datatype; value
12 125 AR_SERVER_INFO_DSO_POLLING_ datatype; value
INTERVAL
12 128 AR_SERVER_INFO_DSO_TIMEOUT_NORMAL datatype; value
12 130 AR_SERVER_INFO_ENC_DATA_KEY_EXP datatype; value
12 131 AR_SERVER_INFO_ENC_PUB_KEY_EXP datatype; value
12 133 AR_SERVER_INFO_ENC_SEC_POLICY datatype; value

Configuring

12 134 AR_SERVER_INFO_ENC_SESS_H_ENTRIES datatype; value
12 132 AR_SERVER_INFO_ENC_DATA_ENCR_ALG datatype; value
12 135 AR_SERVER_INFO_DSO_TARGET_ datatype; value
CONNECTION
12 137 AR_SERVER_INFO_ORACLE_QUERY_ON_ datatype; value
CLOB
12 140 AR_SERVER_INFO_LOCALIZED_SERVER datatype; value
12 141 AR_SERVER_INFO_SVR_EVENT_LIST datatype; value
12 142 AR_SERVER_INFO_DISABLE_ADMIN_ datatype; value
OPERATIONS
12 143 AR_SERVER_INFO_DISABLE_ datatype; value
ESCALATIONS
12 144 AR_SERVER_INFO_ALERT_LOG_FILE datatype; value
12 145 AR_SERVER_INFO_DISABLE_ALERTS datatype; value
12 146 AR_SERVER_INFO_CHECK_ALERT_USERS datatype; value
12 147 AR_SERVER_INFO_ALERT_SEND_TIMEOUT datatype; value
12 148 AR_SERVER_INFO_ALERT_OUTBOUND_ datatype; value
PORT
12 151 AR_SERVER_INFO_DSO_USER_PASSWD datatype; value
12 152 AR_SERVER_INFO_DSO_TARGET_PASSWD datatype; value
12 153 AR_SERVER_INFO_APP_SERVICE_PASSWD datatype; value
12 154 AR_SERVER_INFO_MID_TIER_PASSWD datatype; value
12 155 AR_SERVER_INFO_PLUGIN_LOG_FILE datatype; value
12 156 AR_SERVER_INFO_SVR_STATS_REC_MODE datatype; value
12 157 AR_SERVER_INFO_SVR_STATS_REC_ datatype; value
INTERVAL
12 158 AR_SERVER_INFO_DEFAULT_WEB_PATH datatype; value
12 159 AR_SERVER_INFO_FILTER_API_RPC_ datatype; value
TIMEOUT
12 160 AR_SERVER_INFO_DISABLED_CLIENT datatype; value
12 161 AR_SERVER_INFO_PLUGIN_PASSWD datatype; value


12 162 AR_SERVER_INFO_PLUGIN_ALIAS datatype; value
12 163 AR_SERVER_INFO_PLUGIN_TARGET_ datatype; value
PASSWD
12 164 AR_SERVER_INFO_REM_WKFLW_PASSWD datatype; value
12 165 AR_SERVER_INFO_REM_WKFLW_TARGET_ datatype; value
PASSWD
12 166 AR_SERVER_INFO_EXPORT_SVR_OPS datatype; value
12 167 AR_SERVER_INFO_INIT_FORM datatype; value
12 168 AR_SERVER_INFO_ENC_PUB_KEY_ALG datatype; value
12 169 AR_SERVER_INFO_IP_NAMES datatype; value
12 170 AR_SERVER_INFO_DSO_CACHE_CHK_ datatype; value
INTERVAL
12 171 AR_SERVER_INFO_DSO_MARK_PENDING_ datatype; value
RETRY
12 172 AR_SERVER_INFO_DSO_RPCPROG_NUM datatype; value
12 173 AR_SERVER_INFO_DELAY_RECACHE_TIME datatype; value
12 174 AR_SERVER_INFO_DFLT_ALLOW_CURRENCIES datatype; value
12 175 AR_SERVER_INFO_CURRENCY_INTERVAL datatype; value
12 176 AR_SERVER_INFO_ORACLE_CURSOR_SHARE datatype; value
12 179 AR_SERVER_INFO_DFLT_FUNC_CURRENCIES datatype; value
12 180 AR_SERVER_INFO_EMAIL_IMPORT_FORM datatype; value
12 181 AR_SERVER_INFO_EMAIL_AIX_USE_OLD_EMAIL datatype; value
12 182 AR_SERVER_INFO_TWO_DIGIT_YEAR_CUTOFF datatype; value
12 183 AR_SERVER_INFO_ALLOW_BACKQUOTE_IN_ datatype; value
PROCESS
12 184 AR_SERVER_INFO_DB_CONNECTION_RETRIES datatype; value
12 189 AR_SERVER_INFO_HOMEPAGE_FORM datatype; value
12 190 AR_SERVER_INFO_DISABLE_FTS_INDEXER datatype; value
12 191 AR_SERVER_INFO_DISABLE_ARCHIVE datatype; value
12 192 AR_SERVER_INFO_SERVERGROUP_MEMBER datatype; value

Configuring

12 193 AR_SERVER_INFO_SERVERGROUP_LOG_FILE datatype; value
12 194 AR_SERVER_INFO_FLUSH_LOG_LINES datatype; value
12 195 AR_SERVER_INFO_SERVERGROUP_INTERVAL datatype; value
12 196 AR_SERVER_INFO_JAVA_VM_OPTIONS datatype; value
12 197 AR_SERVER_INFO_PER_THREAD_LOGS datatype; value
12 199 AR_SERVER_INFO_SSTABLE_CHUNK_SIZE datatype; value
12 202 AR_SERVER_INFO_SERVERGROUP_NAME datatype; value
12 204 AR_SERVER_INFO_LOCKED_WKFLW_LOG_MODE datatype; value
Datatypes values
The following are datatype values for the Server Events form. For example,
for server setting changes, the Event Details 1 field records the datatype and
value. The datatype is recorded as 0, 2, and 4, corresponding to the datatypes
in the following table.
Datatype Description #define in ar.h

0 NULL AR_DATA_TYPE_NULL
2 Integer AR_DATA_TYPE_INTEGER
4 Character String AR_DATA_TYPE_CHAR
Viewing alert registration activity

For alert registration activity, the event type will always be 13. The following
information appears in the fields on the Server Events form when an alert
change is recorded:
Event Type: 13
Event Cause: User registered for alerts (102), user deregistered for alerts
(103)
Event Details 1: User login name, IP address of machine user logs into,
and other details.


Submitter: User who caused the alert change event
Table E-4: Alert registration activity

13 102 User logs in to alert Operation type tag (R);
client byte length of user name;
user name; registration
time; IP address of client;
client port; actual client IP
address; server IP address
that client expected;
registration flag; client
version; client codeset
13 103 User logs out from Operation type tag (U);
alert client byte length of user name;
user name; IP address of
client; client port; client
version
Viewing archive activity

For archive activity, the event type will always be 14. The following
information appears in the fields on the Server Events form when an archive
change is recorded:
Event Type: 14
Event Cause: Copy to archive only (1), delete from source only (2), Copy
to archive and delete from source (3)
Event Details 1: Source form name
Event Details 2: Details of the activity
Event Details 3: Destination form name

Configuring

Submitter: User who caused the archive change event
Table E-5: Archive activity

Description
14 1 Copy to archive only Source form name Error code; Destination form
Number of entries name
copied to archive
14 2 Delete from source only Source form name Error code; Destination form
Number of entries name
deleted from
source
14 3 Copy to archive and Source form name Error code; Destination form
delete from source Number of entries name
copied to archive
and deleted from
source
Viewing server group actions

For server group actions, the event type will always be 15. The following
information appears in the fields on the Server Events form when a server
group activity is recorded:
Event Type: 15
Event Cause: Failover (1), relinquish (2), takeover (3)
Event Details 1: Server performing action
Event Details 2: Name of operation
Event Details 3: Other server
Submitter: User who caused the server group action event

Table E-6 describes specific details of server group actions.

Table E-6: Server group actions

Description
15 1 Server in group fails Server that an Name of the Server that an
over an operation operation is failing operation operation is failing
over to. involved. over from.
15 2 Server in group is Server that is Name of the Server that is
relinquishing an relinquishing an operation expected to take
operation operation. involved. over a relinquished
operation.
15 3 Server in group takes Server that is taking Name of the Null
over an unowned over an unowned operation
operation. operation. involved.
Using server events in workflow

Recording server events enables you to communicate internal (non-data)
server changes to processes outside the server and to use workflow to notify
companion servers or interested clients of changes that affect them.
You can create workflow that will be triggered when a server event is
recorded. For example, you might want to create a filter that fires when an
entry is submitted to the Server Events form indicating that an object change
has occurred. The filter should execute a Run Process action that runs the
arsignal program to force a companion AR System server to reload its
cache. The filter should have one such action for each companion server.
So, if you wanted to make server “foo” reload its cache, you would construct
the filter run process action as follows:
arsignal -g foo
If foo were running on specific port 2033, then the action would be
constructed as follows:
arsignal -g foo:2033
For more information about arsignal, see “arsignal (arsignal.exe)” on

page 356.

Appendix
F Using Business Time in the

AR System server
Business time in AR System is the ability to define periods of availability and

unavailability, workdays, and holidays to calculate business schedules using
AR System commands.
Overview (page 386)
Architecture (page 386)
How Business Time 2.0 works (page 388)
Scheduling a time segment (page 390)
Using offset hours in Business Time 2.0 (page 399)
Business Time commands (page 399)
Using the old Business Time forms (page 409)
Migrating Workdays and Holidays to the Business Time Segment form
(page 419)
Debugging tips for Business Time (page 420)
Using Business Time in the AR System server 385

Overview
AR System 7.0 is introducing version 2.0 of Business Time. This version
enables you to define periods of time as available or unavailable. Business
time can be defined using time segments that can be workdays, holidays, or
any other activity that occurs in a business environment.
The AR System business time functionality is applicable to global enterprises
with multiple regional centers:
Businesses can use the availability function to block periods of time by
region. For example, a customer might want to make certain functions
unavailable for Japanese offices during Golden Week in Japan.
Businesses can use the Business Time function according to their own
rules for shift work during work days and during holidays. The customer
can define the different shifts (for example, the evening shift and the
morning shift) and the holidays to capture their work environment.
Different offices can set up different holiday and break schedules. A
central administrator can enter and manage business time and holidays
for all international locations in different time zones.
Architecture
The Business Time Segment form is the main business time form and is used
to define segments of time. These time segments can then be used to define
any kind of activity.
If you used the Business Time Holidays and Business Time Workdays forms
in prior releases, you can still use them to define holidays and workdays with
the old set of Business Time commands. However, in Business Time 2.0, all
activities (including holidays and workdays) are defined in the Business Time
Segment form. A new set of commands work off the time segments defined
in the Business Time Segment form.
The “offset” that was previously available in the Business Time Workdays
form is now available in the Business Time Segment form. The functionality
provided by the old Business Time commands (Add, Subtract, and Diff) will
also be provided by the 2.0 Business Time commands; however, all future
enhancements will happen only to Business Time 2.0.
The Business Segment-Entity Association form associates an entity to one or
more time segments in the Business Time Segment form.
386 Appendix F—Using Business Time in the AR System server

Configuring
Following is a summary of forms you can use to define Business Time 2.0:
Business Time Segment—Defines time segment as available or
unavailable, optionally on a one-time or a recurring basis.
Business Time Shared Entity—Stores detailed information about the
entity used in the Business Segment-Entity Association form. An entity is
a generic object such as an asset, categorization, or location.
Create an entity only if you need to associate a time segment to it. Once an
entity is created, it can be reused from there on. (You do not need to create
a new one.)
Business Segment-Entity Association—Stores associations between
entities (such as assets, change requests, and groups, individuals,
companies, and locations) and activities that apply to those objects. It
associates records in the Business Time Segment and Business Time
Shared Entity forms in a many-to-many fashion.
Business Segment-Entity Association_Join—Used for query purposes.
Acts as a join form between the following forms:
Business Segment-Entity Association
Business Time Segment
Business Time Shared Entity-Entity Association_Join_Join—Used for
query purposes. Acts as a join form between the following forms:
Business Time Shared Entity
Business Segment-Entity Association_Join
These forms contain fields with IDs that AR System recognizes. You can
change the name of the forms, but do not make copies of them because the
AR System server will not be able to find the correct form for finding business
schedules.
You can use the following forms with the old Business Time commands:
Business Time Workdays—Defines a weekly schedule with four time
segments.
Business Time Holidays—Defines holidays, which can be entire days or a
time segment within a day.
Figure F-1 shows the relationships between these forms.
Architecture 387
Figure F-1: Forms used to schedule time in AR System
Business Time 2.0 Old Business Time forms

Scheduling Business
Scheduling Workdays
Business Time Time Segments
Shared Entity-Entity Business Time
Association_Join_Join Business Segment- Workdays form
Entity Association_Join
join form
Scheduling Holidays
Business Time Business Segment- Business Time
Business Time
Shared Entity form Entity Association Segment form
Holidays form
form
Note: If you upgrade your Business Time objects from version 5.0, delete the
filter BusWk:ValidateTimes02. This filter is not intended for use on
AR System versions 5.1 and later.
How Business Time 2.0 works

The Business Time Segment form represents a window of time, which can be
described as a one time activity (which can span multiple days) or a recurring
activity (which cannot span multiple days; it must be scheduled within a 24-
hour period).
An object in the Business Segment-Entity Association form can be associated
with:
One or more entries in the Business Time Segment form
Optionally, one or more entries in the Business Time Shared Entity form
In Business Time 2.0, time segments are defined using “levels.” Levels 1 and
2 are special levels. Level 1 time segments are treated as workdays (available
time), and Level 2 time segments are treated as holidays (unavailable time).
If no Level 1 time segments are defined, then all days are considered available.
To define business time and implement it in your AR System application,
you must:

Configuring
Step 1 Define any combination of time segments, business hours, and business
holidays.
If defining workdays, make sure available time segments are defined at

Level 1. If defining holidays, make sure unavailable time segments are
defined at Level 2. Define other time segments at Level 3 and above.
Step 2 Add business time commands to workflow in your application.
Step 3 Test the application.
Using the list of Time Segment IDs, Workday IDs, and Holiday IDs, the
Business Time component in AR System builds a list of available and
unavailable time windows for every day in the list of IDs.
For example, consider an entity that has a Workday schedule from 8:00 a.m.
to 5:00 p.m., and two activities associated with it. The first time segment
defines an available time window at a Level 3 from 10:00 a.m. to 2:00 p.m.,
and the second time segment defines an unavailable time window at Level 4
from 1:00 to 4:00 p.m. The Business Time component in AR System
computes the final time window list for a day as shown in the following
figure.
Figure F-2: Workday and activities for one day
Level
6
4 Time Seg. 2 (1 to 4 p.m.)
3 Time Seg. 1 (10 a.m. to 2 p.m.)
1 Workday (8 a.m. to 5 p.m.)

5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 Time
Final list
= Available time = Unavailable time
The application commands described in “Business Time commands” on

page 399 work from the final list.
How Business Time 2.0 works 389

Scheduling a time segment

The Business Time Segment form stores availability, level, date and time
ranges, and recurrence information about a time segment. You can add an
entry to this form to schedule a business time segment for an entity in an
AR System application, such as an asset or a change request, or a group,
individual, company, or location.
Understanding levels
Levels define a priority between different time segments, and a higher level
time segment takes precedence over lower-level time segments. Levels can be
from 1 to 1000.
Levels 1 and 2 have special meaning. Level 1 time segments are “available”
and can be used to define workdays. Level 2 time segments are “unavailable”
and can be used to define holidays. Other time segments at Level 3 and above
can be either “available” or “unavailable.”
For all Business Time commands, a higher-level time segment takes
precedence over lower-level time segments, except for the Application-Bus-
Time2-Get-Free-Window command. See “Application-Bus-Time2-Get-Free-
Window” on page 404 for more information.
For time segments that are the same level, the order of overlapping activities
is not guaranteed. The business component in AR System will determine the
final list for these time segments in the order they are retrieved.
Creating non-conflicting segments

Levels are used to determine the order in which overlapping or non-
overlapping time segments will take effect. In Figure F-2 on page 389,
Time Segment 2 is at a higher level than Time Segment 1. Hence, in the final
list, the time window 1:00 p.m. to 2:00 p.m. is defined as unavailable.
Defining a business time segment

You can create one-time time segment or a recurring time segment as
described in the following procedures:
“To define a one-time time segment” on page 391
“To define a recurring time segment” on page 394

Configuring
To define a one-time time segment

1 Open the Business Time Segment form in new mode.
Figure F-3: Business Time Segment form, One Time tab
2 In the ID field, enter a unique identifier. Use this identifier to reference the
time segment in workflow.
The identifier can be non-unique in special cases. For more information, see
“Migrating Workdays and Holidays to the Business Time Segment form” on
page 419.
3 In the Description field, enter a description for the time segment.
4 In the Availability field, select Available or Unavailable.
Scheduling a time segment 391

5 For the Enable option, select Yes to enable the time segment.
Do not select Yes if you want to temporarily disable the time segment.
6 In the Level field, select a level.
Business Schedule Activities have a default level of 3, but this level can be
changed to a number from 1 through 1000.
If the schedules for two activities or business hours and holidays conflict, the
event with the highest number takes priority.
See “Creating non-conflicting segments” on page 390 for more information
about levels.
7 In the Category field, enter a description for the category.
This field helps determine what type of schedule time segment the item is (for
example, blackout, maintenance, and so on.) Although it is not a required
field, it can help you categorize your time segments.
8 In the Action field, select one of the following options:
Note: You must add items to the Non-Conflicting Activities field to find
conflicting items. If you do not, the time segment you originally entered
will be used. See step 14 on page 394 for more information.
Create as Described—Creates the scheduled time segment without

checking to determine if there is a conflict in the Start Date and Time, and
End Date and Time, with that of another scheduled time segment. This
option creates a time segment with a status of Published. It applies to both
One Time and Recurring duration types.
Create Next Free—Finds the next free date and time and automatically
creates the scheduled time segment, making sure that there is no other
conflicting time slot. If the specified Start Date and Time, and End Date
and Time are not available, the time segment is scheduled for the next
available time slot. This option creates a time segment with a status of
Published. It applies only to the One Time duration type.
Find Next Free—Finds the next free time slot based on the Start Date and
Time and the End Date and Time, and puts the value into the Next Free
Date/Time field. This option creates a time segment with a status of Draft.
It applies only to the One Time duration type.

Configuring
Note: When this action is chosen, the AR System business time subsystem
finds the next free time and creates an entry in the Business Time Segment
form. If this entry is not needed, select Remove, and an escalation will
delete it.
Publish—Changes the status from Draft to Published, so the time

segment can be used by business time application commands.
Remove—Mark the scheduled time segment to be deleted in an escalation
that runs nightly.
Draft—Changes the status from Published to Draft so changes can be
made to the time segment. (You cannot change a record after it is
published. First, move it to Draft and save it. Then, make your changes.)
As described in each of the previous bullets, when you select an Action, the
status of Draft, Published, or Remove appears in the read-only Status field. A
status of Draft indicates that the time segment can be modified, but not used
by business time application commands until the status changes to
Published.
9 In the Duration Type field, select One time to create a single occurrence of
the time segment.
To create a recurring business time segment, see “To define a recurring time
segment” on page 394.
10 Enter the starting and ending dates and times for the duration of the time
segment.
If your day ends at midnight, select the End of Day check box. Then, any
value in the End Time field will be ignored, and the day will end at midnight.
11 In the Earliest Start Time field, enter earliest preferred start time for which to
schedule the time segment.
The search for a start time will start with the Start Date and Start Time and
find the first available time with the specified duration. If no time slot is
found within the same day, it will continue to the next day, starting after the
Earliest Start Time. If this field is blank, the search for the next available time
will continue from 12:00 a.m. of the next day if necessary.
12 In the Latest End Time field, enter latest preferred time by which the time
segment should end.

13 In the End Date Search Range field, enter the last date to search for an
available time slot within the specified Start Date and End Date. (The default
is the End Date plus six months.)
The Start Date Search Range field is set to the Start Date and Start Time.
14 In the Non Conflicting Activities field, enter the IDs of the Business Times
Workdays, Business Time Holidays, and Business Time Segment definitions
to check for schedule conflicts.
15 To find the next available time slot, click in the Next Free Date/Time field and
press ENTER.
This field is used only with the Find Next Free action.
The next free period for the time segment appears in the Next Free Date/
Time field. If the value is the same as the Start Date and Start Time, that time
is available. If the time is different, the original time that was specified for the
Start Date/Time was not available and the value represents the earliest
available time.
16 If this time slot is not acceptable:
a Save the form.
b Select the Find Next Free option.
c Search for the next free time slot.
17 Save the form.
To define a recurring time segment

1 Complete steps 1 through 8 from “To define a one-time time segment” on
page 391.
2 Select the Recurring option for the Duration Type.
The Recurrence Definition tab appears on the form.

Configuring
Figure F-4: Business Time Segment form—Recurrence Definition tab
3 Select start and end dates and times.

For recurring activities, the Start Date and End Date fields determine the
range of the recurrence, and the Start Time and End Time determine the
duration of the time segment.
If your day ends at midnight, select the End of Day check box. Then, any
value in the End Time field will be ignored, and the day will end at midnight.
4 Select the Recurrence Type, and specify the recurrence as dictated by the tab
that appears when you select the option. (All the options accept a start date
and return the next date.)
Specified dates—A semicolon separated list of dates, such as 12/24/05;12/
25/05.

Daily—Every specified number of days, such as every four days.

Weekly—Every specified number of weeks on a specified day, such as
every three weeks on Tuesday and Thursday.
Monthly
Specified day of every specified month, such as the 24th day every three
months.
Specified week day of a specified number of months, such as the second
Tuesday every three months. This could also be used to define quarterly
activities.
Yearly
Specified day of the month, such as every fifth day of April.
Every specified week day of a month, such as every second Tuesday of
April.
5 Save the form.
Understanding time segment entity associations

The Business Segment-Entity Association form stores associations between
the Business Time Shared Entity form and the Business Time Segment form.

Configuring
Figure F-5: Business Segment-Entity Association form
The Business Segment-Entity Associations form contains the following

primary fields:
Entry ID—An identifier for an entity to which the time segment is being
applied, such as an asset or a change request.
Entry Owner ID—An identifier for the parent object owner of the entity.
Enables you to see who was the original owner to determine if you have
the ability to make a change to the association.
Time Segment ID—A time segment name that was defined on the
Business Time Segment form. For more information, see “Scheduling a
time segment” on page 390.
Assignee Groups—Groups specified on Business Time Segment form. For
more information, see “Scheduling a time segment” on page 390.
Understanding time segment shared entities

The Business Time Shared Entity form stores logical references to a
scheduled time segment. An entity can define any generic object.
Only one entity of the same type can exist in this form. Once an entity is
created, you must reuse the existing copy in the entity from this form.

Figure F-6: Business Time Shared Entity form
The Business Segment-Entity Association form contains the following

primary fields:
Entry Type—Used to classify the type of entity that is being created.
Depending on this value, it determines how the values are mapped to the
Attributes fields. For example, if you have Entity Type as Category, then
you can map Attribute1 to store Category 1, Attribute 2 to store Category
2, Attribute3 to store Category 3, and so on.
POID—Contains the Parent Object Instance ID field. It is used to
reference any desired generic object. Typically, it references the Instance
ID of the parent object.
Attribute fields—Includes a set of 10 generic attributes that can be used to
describe an entity. Any character values can be mapped into these fields to
describe an entity.

Configuring
Using offset hours in Business Time 2.0

The Business Time Segment form includes an offset field, which is used
under certain circumstances to adjust for the time zone differences between
the client and the server. All Business Time 2.0 commands are executed on
the server, and they take in and return timestamp values.
Timestamp values are in GMT time; therefore, they are time zone sensitive.
For cases when the client and server are on different time zones, if the
conversion of the date and time to a timestamp happens on the client (such
as with active links), then the offset should be set to the time zone difference
between the server and the client. If the conversion happens on the server,
then no offset is required.
For cases where the time segment spans across midnight (as specified in
“Defining business hours using offset hours” on page 416 for old Business
Time commands), do not use offsets.
Because “One Time” time segments can span multiple days, these time
segments can span midnight. “Recurring” time segments cannot span
midnight; therefore, you should create multiple time segments—one that
goes to midnight one day, and another that starts from midnight to the next
day.
The first Level 1 offset will be considered and applied to all the time segments
in the application commands. Offsets on time segments at other levels are
ignored.
Business Time commands

In addition to defining recurrence activities, business hours, and business
holidays, you must use commands to enable Business Time in your
AR System application. Business Time functionality is available within the
Set Fields workflow actions, and it uses the $PROCESS$ syntax to run an
internal process within the server to perform the calculation.
The command arguments are positional in the syntax used to run the
processes. You can omit trailing arguments. However, if you want to set a
later argument, you must supply the arguments that come before the one you
want to set. If you want to pass a parameter, simply enter "" in its place.
Using offset hours in Business Time 2.0 399

You can create the following business time calculations:

Application commands
“Application-Bus-Time2-Add” on page 402
“Application-Bus-Time2-Diff” on page 403
“Application-Bus-Time2-Subtract” on page 403
“Application-Bus-Time2-Get-Next-Window” on page 404
“Application-Bus-Time2-Get-Free-Window” on page 404
Business Segment-Entity Association commands
“Application-Bus-Time2-Assoc-Add” on page 407
“Application-Bus-Time2-Assoc-Diff” on page 407
“Application-Bus-Time2-Assoc-Subtract” on page 407
“Application-Bus-Time2-Assoc-Get-Next-Window” on page 408
“Application-Bus-Time2-Assoc-Get-Free-Window” on page 408
“Application-Get-Next-Recurrence-Time” on page 408
Old Business Time commands
“Application-Bus-Time-Add” on page 417
“Application-Bus-Time-Diff” on page 418
“Application-Bus-Time-Subtract” on page 418
Note: Business Time commands work only with Date/Time fields (not Date
fields).
Parameters
The following list describes the parameters for the Business Time commands.
Each parameter must be set apart in double quotation marks.
BusinessTimeSegmentName—Identifier indicating which entry in the
Business Time Segment form contains a definition for the activity to use
for this calculation. You can specify multiple business activity names.
Omitting this value specifies that no business activity is used for this
calculation.

Configuring
Duration—Specifies the size of the time segment in seconds. Specify zero

to return the next time segment.
EarliestStartTime—Working in conjunction with the
LatestStartTime, specifies the time range within which the free window
should exist. (The Duration parameter must be less than this range.) The
specified duration must be less than this range. For example, if the earliest
time is 4:00 p.m. and the latest end time is 10:00 p.m., then a window is
returned that is duration seconds long and starts after 4:00 p.m., even if
there is a window exists that is before 4:00 p.m. If the duration is greater
than the specified time range, no value is returned. If the
EarliestStartTime is not specified, the default of 0 hours (the beginning
of the day) is used.
EndTime—Ending time of the interval of which to calculate the difference.
EndTimeRange—A date and time value that defines the end of a search for
a time window.
Entity—Can be an asset, individual, group, company, location, or
anything you want to link a schedule to.
HolidayScheduleName—For old Business Time commands, an identifier
indicating which entry in the Business Time Holidays form contains a
definition for the holiday schedule to use for this calculation. Omitting
this value specifies no holidays.
LatestEndTime—Working in conjunction with the EarliestStartTime,
specifies the time range within which the free window should exist. (The
Duration parameter must be less than this range.) The specified duration
must be less than this range. For example, if the earliest time is 4:00 p.m.
and the latest end time is 10:00 p.m., then a window is returned that is
duration seconds long and starts after 4:00 p.m., even if there is a window
exists that is before 4:00 p.m. If the duration is greater than the specified
time range, no value is returned. If the LatestEndTime is not specified, the
default of 24 hours (midnight) is used.
Level—An integer value indicating the level of the time segment to be
scheduled. The value can be an integer from 1 through 1000.
Amount—An integer value of 0 or greater that specifies an amount of time
to offset the start time by. If not specified, Amount defaults to 1. 0 can be
used to indicate the next available time. For example, if your open hours
are 8:00 a.m. to 5:00 p.m. and the Start Time in Application-Bus-Time2-
Add, Application-Bus-Time2-Assoc-Add, and Application-Bus-Time-
Add commands is 7:00 a.m., the return value is 8:00 a.m.
Business Time commands 401

In previous versions, Amount was known as Offset.

Amount_Units—Unit of time. It can be set to 1 for seconds, 2 for minutes,
3 for hours, or 4 for days. Any other setting will revert to hours (3).
StartTime—Starting time to which to add business time.
StartTimeRange—A date and time value that defines the start of a search
for a time window.
WindowFlag—A bitmask value with:
Bit 0—Indicates the beginning of an available or unavailable time

segment. It takes a value of 0 for an unavailable segment, and 1 for an
available segment.
Bit 1—Indicates whether to retrieve all or just one segment. If the value
is 0, it retrieves one segment. If the value is 1, it retrieves all of the
segments between the start and end times. The value returned in this
case is a semicolon separated list of values.
WorkdayScheduleName—For old Business Time commands, an identifier
indicating which entry in the Business Time Workdays form contains a
definition for the work schedule to use for this calculation. Omitting this
value specifies open 7 days a week, 24 hours a day.
Application commands
Application-Bus-Time2-Add
The Application-Bus-Time2-Add command performs a business time
calculation by starting with the start time and resulting in a new time that
adds the requested offset. The command returns a timestamp representing
the time calculated. Use this command to recalculate time into the future.
Use the following syntax for the Application-Bus-Time2-Add calculation:
Application-Bus-Time2-Add “<StartTime>” [“<Amount>”
[“<Amount_Units>” [“<BusinessTimeSegmentName1>”
“<BusinessTimeSegmentName2>”… ]]]
The StartTime parameter is required in this command. This parameter must

be a value such as a field reference ($<Field_Name>$). Other fields are
optional and use the default value if not provided. You can specify multiple
business activity names.

Configuring
For example, add one day by using the following calculation:

$PROCESS$ Application-Bus-Time2-Add “$<Field_Name>$” “<Amount>”
“<Amount_Units>”
This adds one day to the value that currently resides in Field Name. Show
Field Name as StartTime. Set the offset unit to 4, representing days, and set
the offset to 1, thus adding one day into the calculation. The final syntax
looks like:
$PROCESS$ Application-Bus-Time2-Add “$8/26/2004$” “1” “4”
Application-Bus-Time2-Diff
The Application-Bus-Time2-Diff command performs a business time
calculation by computing the difference between the start time and the end
time. The return is an integer representing the difference in seconds. Use this
command to compare two different times (start time and end time) to get the
actual business time.
Use the following syntax for the Application-Bus-Time2-Diff calculation:
Application-Bus-Time2-Diff “<StartTime>” “<EndTime>”
[“<HolidayScheduleName>” [“<BusinessTimeSegmentName1>”
“<BusinessTimeSegmentName2>”… ]]
The StartTime and EndTime parameters are required in this command.

Other fields are optional and will default if not provided. You can specify
multiple business activity names.
Application-Bus-Time2-Subtract
The Application-Bus-Time2-Subtract performs a business time calculation
by starting with the start time and resulting in a new time that subtracts the
requested offset. The command returns a timestamp representing the time
calculated. Use this command to recalculate time in the past.
Use the following syntax for the Application-Bus-Time2-Subtract
calculation:
Application-Bus-Time2-Subtract “<StartTime>” [“<Amount>”
“<BusinessTimeSegmentName2>”… ]]]
The StartTime parameter is required in this command. Other fields are

optional and will use the default value if not provided. You can specify

Application-Bus-Time2-Get-Next-Window
The Application-Bus-Time2-Get-Next-Window command returns the start
of the next available or unavailable time segment that is <Duration> seconds
long. If <Duration> is 0 (the default), the command returns either the start of
available time segment or the start of unavailable the time segment.
Additionally, depending on the <WindowFlag>, the command will return one
time segment or all the time segments between <StartTimeRange> and
<EndTimeRange>.
Use the following syntax for the Application-Bus-Time2-Get-Next-Window

calculation:
Application-Bus-Time2-Get-Next-Window “<StartTimeRange>”
“<EndTimeRange>” [“<Duration>”] [“<WindowFlag>”]
[“<BusinessTimeSegmentName1>” “<BusinessTimeSegmentName2>”… ]
Application-Bus-Time2-Get-Free-Window
The Application-Bus-Time2-Get-Free-Window command returns the start
of the next available or unavailable free time segment at the same level or a
higher level that is <Duration> seconds long. A free time segment at Level
<Level> and Duration <Duration> is one where no other time segment at the
same or higher level as <Level> overlaps, or starts or ends in the <Duration>
of this time segment. After a free time segment is obtained, it can be created
as available or unavailable. The default value for duration is 0. If <Duration>
is 0, it returns the next available time segment.
Use the following syntax for the Application-Bus-Time2-Get-Free-Window
calculation:
Application-Bus-Time2-Get-Free-Window “<StartTimeRange>”
“<EndTimeRange>” [“<Level>”] [“<Duration>”]
[“<EarliestStartTime>”] [“<LatestEndTime>”]
[“<BusinessTimeSegmentName1>” “<BusinessTimeSegmentName2>”… ]
The command works by considering all Business Time Segments at a certain

level or above and treats them as unavailable, regardless of whether they are
available or unavailable. If Level 1 and 2 time segments are present, then they
are always considered and are taken as available and unavailable, respectively.
Example 1
Application-Bus-Time2-Get-Window "7/12/05 11:00:00 AM" "7/15/05
3:00:00 PM" 2 3600 "" "" "" "Work1" "Act1" "Act2" "Act3"

Configuring
Consider an entity that has the following conditions:

Work1 has the following Workday schedule:
Available: Wednesday through Friday, 8:00 a.m. to 5:00 p.m.

Unavailable: Wednesday through Friday, 12:00 a.m. to 8:00 a.m. and
5:00 p.m. to Midnight
Unavailable: Saturday through Tuesday, whole days
Act1 defines an available time window at a Level 3 from 10:00 a.m. to 2:00
p.m. on 7/13/05.
Act2 defines an unavailable time window at Level 3 from 7:00 a.m. to 9:00
a.m. on 7/13/05.
Act3 defines an unavailable time window at Level 6 from 1:00 p.m. to 4
p.m. on 7/13/05.
A free window of duration 3600 seconds (1 hour) is required. There is no
Earliest Start Time or Latest End Time.
Figure F-7 shows the return value for Get-Free-Window for a specific day.
The two Final lists show the final time window that Get-Free-Window will
use in case a free window is required at Level 2 or at Level 4.
For Level 2, the free window is available from 9:00 a.m. to 10:00 a.m. and
from 3:00 p.m. to 4:00 p.m. Get-Free-Window will return 1121270400
(July 13, 2005, 9:00 a.m.).
For Level 4, the free window is available from 8:00 a.m. to 12:00 p.m. and
from 3:00 p.m. to 4:00 p.m. Get-Free-Window will return 112166800 (July 13,
2005, 8:00 a.m.).

Figure F-7: Application-Bus-Time2-Get-Free-Window command example
Level
6
4 Time Seg. 2 (7 to 9 a.m.) Time Seg. 3 (1 to 4 p.m.)
3 Time Seg. 1 (10 a.m. to 2 p.m.)
1 Workday (8 a.m. to 5 p.m.)

5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 Time
Level 2 Final list

Level 4 Final list
= Available time = Unavailable time
Example 2
3:00:00 PM" 2 3600 "11:00:00 AM" "" "" "Work1" "Act1" "Act2" "Act3"
In the example, if the Earliest Start Time for Level 2 was 11:00 a.m., then the
return value at Level 2 will be 1121292000 (July 13, 2005, 3:00 p.m.).
Example 3
3:00:00 PM" 2 3600 "5:00:00 AM" "2:00:00 PM" "" "Work1" "Act1"
"Act2" "Act3"
If the Earliest Start Time was 5:00 a.m. (or if it is not specified), and if the
Latest End Time was 2:00 p.m., then the return value at Level 2 will be
1121270400 (July 13, 2005, 9:00 a.m.).
Example 4
If the duration required was 2 hours, then for Level 2, "" is returned.

Configuring
Example 5
If the Level is 4 and the duration is 7200 seconds, then 1121266800

(July 13, 2005, 8:00 a.m.) is returned.
Business Segment-Entity Association commands

If the Business Segment-Entity Association form contains entries for time
segments, you can use the following commands in place of the Application
commands described in the previous section.
The following commands contain EntityID parameters, so that you do not
need to query the Business Segment-Entity Association form and call the
previous Application commands.
Application-Bus-Time2-Assoc-Add
Use the following syntax for the Application-Bus-Time2-Assoc-Add
calculation:
Application-Bus-Time2-Assoc-Add “<StartTime>” [“<Amount>”
“<BusinessTimeSegmentName2>”… [-e "EntityID1" "EntityID2"… ]]]]
Application-Bus-Time2-Assoc-Diff
Use the following syntax for the Application-Bus-Time2-Assoc-Diff
calculation:
Application-Bus-Time2-Assoc-Diff “<StartTime>” “<EndTime>”
[“<BusinessTimeSegmentName1>” “<BusinessTimeSegmentName2>”… [-e
"EntityID1" "EntityID2"… ]]
Application-Bus-Time2-Assoc-Subtract
Use the following syntax for the Application-Bus-Time2-Assoc-Subtract
calculation:
Application-Bus-Time2-Assoc-Subtract “<StartTime>” [“<Amount>”
“<BusinessTimeSegmentName2>”… [-e "EntityID1" "EntityID2"… ]]]]

Application-Bus-Time2-Assoc-Get-Next-Window
Use the following syntax for the Application-Bus-Time2-Assoc-Get-Next-
Window calculation:
Application-Bus-Time2-Assoc-Get-Next-Window “<StartTimeRange>”
“<EndTimeRange>” “<Duration>”“<WindowFlag>”
Application-Bus-Time2-Assoc-Get-Free-Window
Use the following syntax for the Application-Bus-Time2-Assoc-Get-Free-
Window calculation:
Application-Bus-Time2-Assoc--Get-Free-Window
“<StartTimeRange>” “<EndTimeRange>” “<Level>”
“<Duration>”“<EarliestStartTime>” “<LatestEndTime>”
Application-Get-Next-Recurrence-Time
Recurrence is defined by a set of fields in the range from 2300 to 2341 and
contains recurrence patterns. These fields can be defined on any form, and
the Application-Get-Next-Recurrence-Time command is provided to get
the next time. For all the recurrence time calculations, ICU library functions
are used.
The Application-Get-Next-Recurrence-Time command performs a
recurrence time calculation by starting with the start time and finding
recurrence times based on the specified recurrence definition name. The
return value is a semicolon-separated list of dates (in seconds).
The command syntax is as follows:
Application-Get-Next-Recurrence-Time <FormName> <StartTime>
<RecurrenceDefinitionName>
The options for these recurrence time calculations are as follows:

<FormName>—Form that contains the recurrence fields, such as the
Business Time Segment form.
<StartTime>—Starting time to which to add business time.

Configuring
<RecurrenceDefinitionName>—Identifier indicating which entry in the

AR System Recurrence Definition form contains a definition for the
recurrence schedule to use for this calculation.
Following is an example of the command with $PROCESS$:
$PROCESS$ Application-Get-Next-Recurrence-Time "Business Time
Segment" "4/14/04 10:30:00 AM" "weekly"
weekly is an entry in the form that contains the recurrence fields, such as the
Business Time Segment form. The weekly entry is defined as Wednesday and
Friday, every 3 weeks.
The return value is 8456890, which corresponds to 4/16/04 10:30:00 AM.
Calling Application-Get-Next-Recurrence-Time again returns
8345345;834999, corresponding to 4/21/04 10:30:00 AM and 4/23/04
10:30:00 AM.
Note: Recurrence information for scheduled activities is stored in the

Business Time Segment form, which contains a set of fields with field IDs
in the range of 2300 to 2341 that contain recurrence patterns. The
Application-Get-Next-Recurrence-Time application command is used
with this form to get the next available time. You can optionally create a
custom form with field IDs in the range of 2300 to 2341 to contain
recurrence patterns, and specify that custom form in the Application-
Get-Next-Recurrence-Time application command.
Using the old Business Time forms
Scheduling workdays
The Business Time Workdays form stores the day-to-day availability of each
of your groups and individuals, and a record of your company or location’s
business hours.
Business time in AR System is calculated on the AR System server where the
start and end times on any given day must be in the range of 0–24 hours. Any
business time outside this range is considered invalid.
To define business hours

1 Open the Business Time Workdays form.
Using the old Business Time forms 409

The General tab appears. Here you can specify a unique identifier for a
workday definition and the list of open and close times for workdays you are
defining.
Figure F-8: Business Time Workdays form
2 In the Name field, enter a unique identifier. Use this identifier to reference
this schedule in all business hours calculations.
3 In the Submitter field, enter the name of the user who submitted the first
version of this schedule.
4 Use the Change History field to track structural or administrative changes to
the definition.
5 In the Help Text field, enter the purpose of the schedule.
6 (Optional) In the Offset Hours field, enter the number of hours you want to
offset from the time on the server.
Use the Offset Hours field to adjust a client business time to a server business
time. An example of a special case is a valid business time on the client that is
several time zones away from the server. The time on the client becomes
invalid on the server if it crosses midnight after the time zone adjustment.

Configuring
For more information, see “Using offset hours in Business Time 2.0” on
page 399.
7 Click the Time Schedules tab.
Figure F-9: Business Time Workdays form, Time Schedules tab
8 Enter the appropriate hours in the time blocks.

AR System allows up to four individual time segments to be defined in the
Time Schedules tab. You can enter up to four multiple non-overlapping time
blocks for hours of operation in a single 24-hour period.
You can span midnight by showing the day as split between two days (for
example, a shift spanning Tuesday and Wednesday). For example, End 4 on
Tuesday has a time of 11:59:59 p.m., and Start 1 on Wednesday has a time of
12:00:00 a.m.
Time segments must be ascending, non-overlapping within a day. Figure F-9
shows an End time one second before the Start of the next time segment. (If
Offset Hours is used, the time segments must be non-overlapping before the
offset hours are applied.)

Note: Create separate schedules for Daylight Savings Time as needed based
on locale and conventions for that locale.
9 Save the form.
Business hours with a one-hour gap

This scenario occurs when a one-hour lunch break is scheduled in the work
day. Use the Time Schedule Start and End times to specify that the business
is open from 9:00:00 a.m. to 12:00:00 p.m. and from 1:00:00 p.m. until
5:00:00 p.m., indicating a one-hour closed time. Enter the information as
shown in Figure F-10.
Figure F-10: Business hours with one hour gap
Scheduling holidays
Use the Business Time Holidays form to define all scheduled holidays and
other non-working days. A holiday can be either a full day or a few hours.
Keep in mind that, due to shift work, holidays might span over midnight.
To set holiday times

1 Open the Business Time Holidays form.
2 Click the Holiday Definition tab.

Configuring
Figure F-11: Business Time Holidays form
3 In the Schedule Name field, enter the unique identifier for this holiday
schedule. Use this identifier to reference this schedule in all business hours
calculations.
Important: Enter the same name that you entered in the Name field of the
Business Time Workdays.
4 In the Holidays field, list the holidays that make up the holiday schedule.
Enter holiday time as <date>,<start time>,<end time>. For example,
07/4/04,9:00:00 a.m.,5:00:00 p.m. is a holiday that starts at 9:00:00 a.m.
on
7/4/04 and ends at 5:00:00 p.m. on the same day.
Separate the dates by pressing Enter or by inserting semicolons between the
dates. There is no limit to the number of dates that can be specified in this list.
The holiday entry cannot span across midnight, and the Start time must be
less than End time. Holiday time uses the offset hours from the Workday
schedule.
Only short date/time format is currently supported in the Business Time
Holidays form. Long date formats (such as January 1, 2005) are not currently
supported.

The dates are interpreted on the server and follow the server formatting rules.
If clients are configured for other date formats and the dates entered in the
Business Time Holidays form are entered in a client format that is
incompatible with the server format, they will not be correctly interpreted as
holidays, or they might be interpreted as a different day than was planned.
Note: The ARDATE format is not currently supported in Business Time

Holidays form.
5 Click the Administrative Information tab.

The Holiday ID field contains the AR System ID for this schedule. The
Change History field is used to track structural or administrative changes to
the schedule.
6 In the Help Text field, enter the purpose of the schedule.
7 Save the form.
Tips for entering dates and times

The following sections offer tips to help you properly enter dates and times
into the Business Time Holidays form.
Entering dates for an international server
When the server resides internationally, it recognizes the short date format of
the server. For example, the German Business Time Holiday value would be
entered dd.mm.yy, which matches the date convention of the locale.
No start time
To indicate a holiday without listing a start time, use the following format:
date,,end time
For example:
7/4/04,,5:00:00 p.m.
In this case, the start time defaults to 12:00:00 a.m.

No end time
To indicate a holiday without listing an end time use the following format:
date, start time
For example:

Configuring
7/26/04, 2:00:00 p.m.
In this case, the end time defaults to 12:59:59 p.m.

No start time and no end time
To indicate a holiday that lasts the entire 24-hour day, use the following
format:
date
For example:
7/26/04
In this case, the start time defaults to 12:00:00 a.m. and end time defaults to
12:59:59 p.m.
Adjusting the time across midnight
The implementation of business time calculations requires that Start Time be
earlier than End Time. However, when a holiday schedule crosses midnight,
such as when Start Time is 10:00:00 p.m. and End Time is 6:00:00 a.m., you
must adjust the holiday schedule:
To adjust using Holidays time, enter the start time as one day and enter
the end time on the next day. It would look like:
12/25/04,10:00:00 p.m.,11:59:59PM;12/26/04,12:00:00 a.m.,6:00:00
a.m.
Or:
12/25/04,10:00:00 p.m.,11:59:59 p.m.
12/26/04,12:00:00 a.m.,6:00:00 a.m.
To adjust using Offset Hours, take your original Start/End time, minus the
value from Offset Hours in the Business Time Workdays form to get the
adjusted time. You can use either a positive offset, which moves the times
earlier, or a negative offset, which moves the times later. The offset does
not have to be unique. You can choose any value as long as the adjusted
times fall into the 0- to 24-hour range. For example, if a holiday starts at
10:00:00 p.m. on 12/25/04 and ends at 6:00:00 a.m. on 12/26/04, you can
supply an offset of three hours to adjust the holiday time to start on
12/26/04 at 1:00:00 a.m. and end at 9:00:00 a.m. This adjusted time is
entered into the Holidays field following the format:
12/26/04,1:00:00 a.m.,9:00:00 a.m.

Note: The offset hours is specified in Business Time Workdays as part of a

workday schedule.
Defining business hours using offset hours

The Business Time Workdays form includes an Offset Hours field that allows
you to calculate business hours into the single 0-24 hour range required by
the AR System server.
Business time in AR System is calculated on the server. It has a requirement
of start and end times in the range of 0-24 hours. So an invalid business time
must be adjusted using this Offset Hours field. A special case could be a valid
business time on the client that is several time zones away from the server.
This time on the client might become invalid on the server if it crosses
midnight after the time zone adjustment. So you must also use the Offset
Hours field in this situation.
Setting a positive offset moves the time earlier; a negative offset moves it later.
Unique offset times are not required. Any adjusted range defined with the
offset hours is valid in the AR System server as long as it falls into a single 0-
24 hour range. Make sure to use the Scheduling Diary field to document how
the offset adjustment is made, for future tracking purposes.
You will find the Offset Hours field useful in the following situations:
Business hours that span over midnight.
For example, a business’s Open Time is 10:00:00 p.m. and its Close Time
is 6:00:00 a.m. Use the Offset Hours feature to specify a negative offset (-3
offset hours). This action recalculates the opening and closing times into
an adjusted 0-24 hour range required by the AR System server: 1:00:00
a.m. becomes the new Open Time and 9:00:00 a.m. the new Close Time.
On the other hand, you could have specified a positive offset of 7 hours to
adjust your business hours to a new Open Time of 3:00:00 p.m. and a new
Close Time of 11:00:00 p.m.
Business hours that span midnight due to different time zones for the
server and the client.

Configuring
For example, a business’s Open Time is 9:00:00 a.m. and its Close Time is
5:00:00 p.m. However if the server is ahead of the client by 12 hours, the
business time of the client will be 9:00:00 p.m. and 5:00:00 a.m. The time
zone setting of the client would create an invalid business time calculation
because its schedule spans over midnight. Here you would specify a
positive offset number if the server is behind the client, or a negative offset
number if the server is ahead of the client.
In this example, use the Offset Hours feature to define a negative offset (-
12 offset hours). This action recalculates the time zone differences of the
client to an 0-24 adjusted range that is required by the AR System server.
The client’s Open Time becomes 9:00:00 a.m. and its Close Time 5:00:00
p.m.
Business hours that span midnight with different time zones.
In this circumstance, you have to derive the offset hour by considering
both factors. The goal is to specify the offset hours to adjust the Open and
Close Time to 0 to 24-hour range on server.
For example, the server is 6 hours behind the client in a different time
zones. On the client, the schedule is 8:00.00 p.m. and 4:00.00 a.m. Specify
a positive offset number (6), because the server is behind the client, to
adjust 8:00.00 p.m. and 4:00.00 a.m. on the client to be 8:00.00 p.m. and
4:00.00 a.m. on server. Then use 5 to adjust to the following calculation: 8
p.m. - 5 = 3 p.m., and 4 a.m. - 5 = 11 p.m. Considering both together, the
final calculated offset is 6 + 5 = 11.
Old Business Time commands

The following commands were used in the old Business Time scheme. If you
use the old Business Time forms, you can use these commands, but they will
not work with Business Time 2.0
Application-Bus-Time-Add
The Application-Bus-Time-Add command performs a business time
calculation by starting with the start time and resulting in a new time that
adds the requested offset. The command returns a timestamp representing
the time calculated. Use this command to recalculate time into the future.
Use the following syntax for the Application-Bus-Time-Add calculation:

Application-Bus-Time-Add “<StartTime>” [“<Amount>”

[“<Amount_Units>” [“<HolidayScheduleName>”
[“<WorkdayScheduleName>”]]]]
The StartTime parameter is required in this command. This parameter must

be a value such as a field reference ($<Field_Name>$). Other fields are
optional and use the default value if not provided. You can specify multiple
business activity names.
For example, add one day by using the following calculation:
$PROCESS$ Application-Bus-Time-Add “$<Field_Name>$” “<Amount>”
“<Amount_Units>”
This adds one day to the value that currently resides in Field Name. Show
Field Name as StartTime. Set the offset unit to 4, representing days, and set
the offset to 1, thus adding one day into the calculation. The final syntax
looks like:
$PROCESS$ Application-Bus-Time-Add “$8/26/2004$” “1” “4”
Application-Bus-Time-Diff
The Application-Bus-Time-Diff command performs a business time
calculation by computing the difference between the start time and the end
time. The return is an integer representing the difference in seconds. Use this
command to compare two different times (start time and end time) to get the
actual business time.
Use the following syntax for the Application-Bus-Time-Diff calculation:
Application-Bus-Time-Diff “<StartTime>” “<EndTime>”
[“<HolidayScheduleName>” [“<WorkdayScheduleName>”]]
The StartTime and EndTime parameters are required in this command.

Other fields are optional and will default if not provided. You can specify
Application-Bus-Time-Subtract
The Application-Bus-Time-Subtract performs a business time calculation
by starting with the start time and resulting in a new time that subtracts the
requested offset. The command returns a timestamp representing the time
calculated. Use this command to recalculate time in the past.
Use the following syntax for the Application-Bus-Time-Subtract
calculation:

Configuring
Application-Bus-Time-Subtract “<StartTime>” [“<Amount>”

[“<Amount_Units>” [“<HolidayScheduleName>”
[“<WorkdayScheduleName>”]]]]
The StartTime parameter is required in this command. Other fields are

optional and will use the default value if not provided. You can specify
Migrating Workdays and Holidays to the Business Time

Segment form
Following are tips you can use when migrating your Business Time
Workdays and Holidays to the Business Time Segment form.
When migrating Workdays, remember:
All workdays become a Weekly Recurrence time segment.
Time segments require a Start Date and End Date that define the
recurrence range. Since Workdays do not have a range, make sure that the
Start Date and End Date fields represent a large range.
Workdays can have up to 4 shifts. Each shift is now a time segment. These
time segments can have the same IDs.
Set the Level to 1 for all time segments.
Select the End of Day check box to indicate the end of the day instead of
11:59:59 p.m.
The ID field on the Business Time Segment form is the same as the Tag
field on the Business Time Workdays form.
If the Workday form has an offset and if multiple time segments
correspond to this workday entry, apply the offset to only one time
segment.
When migrating Holidays, remember:
Use the Specific Dates tab in the Business Time Segment form to specify a
list of dates (with the same time range). Make sure that the Start Date and
End Date are in that list of dates.
Set the Level to 2.
If holidays have been defined with different start and end times, then
different time segments must be created. They can all have the same IDs.
Migrating Workdays and Holidays to the Business Time Segment form 419
Select the End of Day check box to indicate the end of the day instead of
11:59:59 p.m.
The ID field on the Business Time Segment form is the same as the Tag
field on the Business Time Holidays form.
Debugging tips for Business Time

The following table lists some common errors that users encounter when
getting started with business time functionality in the AR System server.
Problem Solution
You receive an error The error could be caused by a problem with the command name:
indicating that a process Check the spelling (including capitalization) of the command.
could not be run.
If running from an active link, did you specify to run the process on the
If from a filter, this error server (@servername: or @@: before the command name)?
would be logged in the
arerror.log file.
If from an active link, you
are likely getting a NULL
value or might be an error.
You are receiving errors The error could be caused by any of these problems:
about not being able to find Check the spelling of the schedule and activity names you specified, and
the workday or holiday entry make sure that corresponding names are in the Business Time Holidays,
you specified. Business Time Workdays, or Business Time Segment form.
Make sure you are using a holiday schedule name for holidays, a workday
schedule name for workdays, and an ID for scheduled activities.
Check the order of your parameters. Remember that all the parameters
are positional. You cannot omit parameters before the holiday or
workday identifiers.
Check the arguments for spaces. If there are spaces in an argument, you
must quote the value, or the value will be read as multiple arguments.
Check arerror.log to see if there is a report of a problem with the
Business Time Holidays or Business Time Workdays forms. As noted
above, the server finds these forms based on the presence of the key fields
that are present on these forms. If it finds two forms with the same fields,
it does not know which form is the correct one. You must delete the extra
copies of these forms to get back to a single instance of each.

Configuring
Problem Solution
You are not getting a result Several issues could be causing this problem:
from the program or you are Make sure you are using the Set Fields $PROCESS$ syntax, not the Run
getting a result you do not Process action. There is a return from this process, so you must use the
expect. action syntax expecting a return.
Use filter or active link logging to report on the workflow. Is the filter or
active link firing? If it is, what does the command line look like? Did you
forget quotes around arguments that contain spaces? Do you have all the
arguments in the correct order? Did you leave out one or more
arguments? The arguments are positional. You can leave the optional
ones off the end, but if you supply them, they must all be present up to
the last parameter you want to supply.
Check the parameters; for example, the units parameter is a code for the
difference function. Are you using the code that matches the units you
want? Do you have the start and end time in the correct order for the
parameters? Do you have the holiday schedule name before the workday
schedule name?
Check the Offset Hours settings in the Business Time Workdays form.
Have you used the proper offset value? Are the calculated values correct
for your business? Do the results fall into a adjusted 0–24 hour range, or
do they span over midnight? For more information, see “Scheduling
workdays” on page 409.
Debugging tips for Business Time 421


Appendix
G Using the Assignment Engine
The Assignment Engine is installed with AR System. By following a simple

process, you can automatically assign users to specific requests.
Overview (page 424)
Assignment Engine Process (page 425)
Assignment Engine Administration Console (page 425)
Auto-assignment methods (page 427)
Preparing for the auto-assignment process (page 428)
Adding assignment forms (page 430)
Adding assignment processes (page 434)
Adding assignment rules (page 436)
Turning on log and trace files (page 439)
Using the Assignment Engine 423

Overview
Using processes instead of workflow, the Assignment Engine enables you to
automatically assign requests to individuals. When you install the
Assignment Engine, the following forms are installed:
Form name in BMC Remedy Form name in BMC Remedy User
Administrator
ASE:Administration Assignment Engine Administration
ASE:AssignAssoc_AssignForm ASE:AssignAssoc_AssignForm
ASE:AssignAssoc_AssignRules ASE:AssignAssoc_AssignRules
ASE:Assignment Association ASE:Assignment Association
ASE:Assignment Process Assignment Processes
ASE:Assignment Rules Assignment Rules
ASE:AssignmentDetail Assignment Details
ASE:DialogYesNo A dialog box; not listed in the Object List.
ASE:Form Information Assignment Forms
ASE:LocalizedString_MenuItems A menu; not listed in the Object List.
ASE:ProcessRuleForm ASE:ProcessRuleForm
ASE:SearchRulesDialog A dialog box; not listed in the Object List.
To set up assignments, you will need to use only a few of these forms, and
they are discussed in the following sections.
424 Appendix G—Using the Assignment Engine

Configuring
Assignment Engine Process

Following is the process to integrate the Assignment Engine with your
application:
Step 1 Create a form that holds the assignees. (For simple applications, you could
use the User form to hold this information.) Add the appropriate
Assignment Engine fields on this form. (See page 428.)
Step 2 In the request form to which you want to assign users, create the fields that
the Assignment Engine will set on assignment. (See page 428.)
Step 3 Register the assignee and request forms to the Assignment Engine. (See
page 430.)
Step 4 Create processes for assignments. (See page 434.)
Step 5 Create rules for assignments. (See page 436.)
Assignment Engine Administration Console

You use the Assignment Engine Administration Console to set up auto-
assignment processes, forms, and rules.
Assignment Engine Process 425

Figure G-1: Assignment Engine Administration Console
The Assignment Engine Administration Console has three tabs:

Processes—Shows the list of processes that the Assignment Engine can
use. Each process has a Process Name.
Each process consists of a request form and a set of sequential rules—all
of which you enter by following the procedures outlined in the following
sections.
Forms—Shows all the forms that are registered with the Assignment
Engine. If you want to see the forms that are used by a specific process,
select the process name from the Show For Process list; all the forms used
by that selected process appear. The Forms tab also has a Related Processes
table that shows the process for the form you select from the table. If the
form is used in more than one process, the Related Processes table shows
all the processes it is used in.

Configuring
Rules—Shows all the rules that are in the Assignment Engine. If you want
to see the rules that are used by a specific process, select the process name
from the Show For Process list; all the rules used by that selected process
appear. The Rules tab also has a Related Processes table that shows the
process for the rule you select from the table. If the rule is used in more
than one process, the Related Processes table shows all the processes it is
used in.
Auto-assignment methods
The assignment method determines who is assigned to an issue when more
than one person matches the qualification and can be assigned the issue. The
following assignment methods can be specified in an assignment rule to
automatically assign an issue when more than one person matches the
qualification:
Round Robin—Assigns the issue to the person who has gone the longest
since receiving an assignment.
Load Balance by Number—Assigns the issue to the person who has the
fewest number of issues currently assigned.
Load Balance by Capacity—Assigns the issue to the person who has the
largest unused capacity. For example, if person A is currently assigned 5
issues and has a capacity rating of 10, and person B is currently assigned 8
issues and has a capacity rating of 20, person B has a relatively lighter load
and will be selected (8/20 < 5/10).
If two or more people qualify for an issue, the first person retrieved from the
database is used.
Auto-assignment methods 427

Preparing for the auto-assignment process

To begin the auto-assignment process, you must have the following types of
forms identified:
Assignee form—Contains data about people or groups to whom you want
to assign requests. A single process can have multiple assignee forms.
Request form—Is used to assign a request. An example might be a Help
Desk form to which Support representatives are assigned tickets.
Fields to add to the assignee form

The assignee form must contain specific fields that the Assignment Engine
will use to run its processes.
Add the following fields to the assignee form. (The following names
correspond with the fields on the Assignment Form. You can use different
names, but be sure to choose the appropriate field when choosing fields on
the Assignment Form form.)
Assignee Unique ID—A field that contains a unique identifier that
distinguishes assignees one from another. This can be a GUID field. For
more information about GUID fields, see the Form and Application
Objects guide.
Instead of creating this field, you can use the Request ID field (ID 1) as the
unique identifier. Then, you can add the following optional fields to this
form:
Assignee Group Unique ID—The unique instance ID for the assignee
group.
Assignee Name/Login—The name of the assignee.
Assignee Delivery Method—A field used to store the method to notify
the assignee of the assignment.
Number Assigned—An Integer field used to obtain and set the current
number of assigned issues for each possible assignee. This field is required
only if you use the Load Balance by Number or the Load Balance by
Capacity auto-assignment method.
Capacity Rating—A Decimal field used to obtain the capacity rating for
each possible assignee. This field is required only if you use the Load
Balance by Capacity auto-assignment method.

Configuring
Last Assigned Time—An Decimal field used to obtain the last time an
issue was assigned to each possible assignee, and to set the last assigned
time for the successful assignee. This field is required only if you use the
Round Robin auto-assignment method.
Last Assigned Time—A Date/Time field used to obtain the last date and
time an issue was assigned to each possible assignee, and to set the last
assigned time for the successful assignee. This is an optional field.
Fields to add to the request form

The request form must contain specific fields that the Assignment Engine
will use to run its processes.
Add the following field to the request form:
Assignee Unique ID—A character field where the selected assignee’s ID
will be written.
Optionally, you can add the following fields:
Assignee ID Field—An optional second ID field used to store the Entry ID
of the successful assignee.
Assignee Form—A field that stores the name of the assignee form.
Return Code Field—A field used to store the code for success or failure of
the assignment. This field can be used for debugging purposes.
Return Code Description—A field used to store the successful
Assignment Rule ID and the Assignment Qualification ID if the
assignment was successful, or an error code if the assignment failed. This
field can be used for debugging purposes.
Reason Code Field—An obsolete field that is no longer used.
To prepare for the auto-assignment process

1 Create an assignee form. (Tip: You can also use the User form.)
2 On the assignee form, create the fields discussed in “Fields to add to the
assignee form” on page 428.
Hide the fields that you do not want users to see.
3 On the request form, create the fields discussed in “Fields to add to the
request form” on page 429.
Preparing for the auto-assignment process 429

Hide the fields that you do not want users to see.
Adding assignment forms

Before setting up the assignment process, you must set up the assignee and
request forms to which the process will apply.
To add an assignee assignment form

1 Open the Assignment Engine Administration Console.
2 Click the Forms tab.
Figure G-2: Assignment Engine Console—Forms tab
3 Click Create to create assignee or request forms, or click Search to search for
assignment forms.
The Assignment Engine Forms dialog box appears.

Configuring
Figure G-3: Assignment Engine Forms dialog box
4 From the Form Name menu list, select the assignee or request form for which
you want to build the assignment process.
5 In the Display Name field, enter a display name for the form you selected.
The display name will appear in the Form Name column on the Forms tab.
6 For Form Type, select Request form or Assignee form (depending on what
you chose in step 4).
The Request form is the form that is requesting the assignment, while the
Assignee form is the form contains the assignee information.
7 From the Status field menu, select Active.
If you do not want to use the form at this time, select Inactive.
8 Optionally, specify a Locale for this assignment form.
Note: If the Localize Server option (in BMC Remedy Administrator) is not
selected, then all records will appear, regardless of the client's locale.
Assuming that it is selected, some rules apply. See the Form and
Application Objects guide and the Configuring guide.
Adding assignment forms 431

9 In the Assignee Group Permissions field, select the group to which you want
to give access.
10 On the Common Fields tab, enter the Assignee Unique ID.
This is the unique identifier for the assignee (an individual user). For
example, you might choose Request ID or Assignee ID.
11 Complete the optional fields:
a Assignee Group Unique ID—Specify the unique instance ID for the
assignee group.
b Assignee Name/Login—Login name or full name of the assignee, for
example, Login Name or Assigned Person.
c Assignee Delivery Method—Field in the assignee form used to store the
method to notify the assignee of the assignment.
If you specified Assignee Form for the Form Type, go to step 13 on page 433.
12 If you specified Request Form for the Form Type, click the Request Form
Fields tab and enter information in the fields, which are described on
page 429.
Figure G-4: Assignment Engine Forms field—Request Form Fields tab

Configuring
Go to step 14 on page 433.

13 If you specified Assignee Form for the Form Type, click the Assignee Form
Fields tab and enter information in the fields, which are described on
page 428.
Note: Make sure that you specify a different Form Name and Display Name
for the assignee forms.
Figure G-5: Assignment Engine Forms field—Assignee Form Fields tab
14 Click Save.
Adding assignment forms 433

Adding assignment processes

After you set up the assignee and request forms and define rules, you are
ready to add assignment processes to the Assignment Engine.
To add an assignment process

Figure G-6: Assignment Engine Console
2 Click the Processes tab, and click Create.

The Process Definition form appears.

Configuring
Figure G-7: Process Definition form
3 In the Process Name field, enter a descriptive name for the process.
4 In the Request Form field, select a form that creates the requests to which you
want to assign users.
5 Optionally, enter a description of the process.
6 Click Create to create a new rule.
See “Adding assignment rules” on page 436 for more information.
7 Specify a sequence for the rules.
The rules will apply according to the order in which they appear. See “Setting
sequencing for rules” on page 438.
Note: The order of the rule in the process matters; that is, the rules that are
most specific should be at the top of your list because the Assignment
Engine goes through the rules from top to bottom and makes an
assignment when it finds a match.
Adding assignment processes 435

8 Make sure that the Status is set to Active.

9 Click Save.
10 Follow steps 3 through 9 to create other processes.
Adding assignment rules

All assignment processes must have rules defined. A process can have
multiple rules in sequential order.
Because rules can be shared for use by multiple assignment processes,
modifying a rule affects all assignment processes associated with it.
Note: Unrelating a rule from a process removes its relationship with the
assignment process, but retains the rule for use by other assignment
processes.
To add an assignment rule

1 Open the process for which you want to add a rule.
For more information about processes, see “Adding assignment processes”
on page 434.
2 In the Process Definition form, click Create.
To modify a rule, select the rule and click View.
The Assignment Rule dialog box appears.

Configuring
Figure G-8: Assignment Rule dialog box
3 Enter information in the required fields:

a In the Rule Name field, enter a rule name.
b In the Assignee Form field, select an assignee form.
The Request form field contains the form references in the Process
Definition form.
The rules that you define fill in the assignment-related fields on the
request and assignee forms. These request and assignee forms are external
to the Assignment Engine and part of a separate application. The only
requirement for these forms is that they have the necessary fields on them
to be read and written from the Assignment Engine software. The
requirements around these fields vary, depending on which Assignment
Engine rule methods are used.
c Make sure that Status is set to Active.
d In the Assignment method field, select an assignment method. See “Auto-
assignment methods” on page 427.
Adding assignment rules 437

4 Enter qualification for the assignment rule.

A qualification string is a specified set of conditions used to make the
automatic assignment. The Assignment Engine applies the qualification
defined here to attempt to assign a request to an assignee.
The easiest way to build your qualification string is to select the keywords,
and form fields directly from the bar and lists. When you choose items
directly from the lists, the correct syntax is automatically entered. You can
also type the information directly into the qualification string field.
If you are modifying an existing rule, you might see an existing qualification
that you can modify.
5 Click Save.
Setting sequencing for rules

Rules are used according to the order in which they are sequenced. If the first
rule is valid, then that rule is used for the process. If the first rule is not valid,
then the Assignment Engine process will attempt to use the second rule, and
so on.
To specify sequencing for the rules

2 From the Process tab, select the process for which you want to sequence rules.
3 Click View.
The Process Definition dialog box appears.
4 Perform either of the following actions:
If there are defined rules for the process, select the rule that you want to
re-order.
If there are no defined rules for the process, click Create to create new rules
(see “Adding assignment rules” on page 436). Select the rule that you want
to re-order.
5 Use the arrow keys to order the rules in the sequence in which you want the
Assignment Engine to use them.
6 Click Save, then click Close.

Configuring
Turning on log and trace files

You can turn on log and trace files for the Assignment Engine through the
following options in the ar.conf (ar.cfg) file:
AE-Log-File—Full path name of the log file.
AE-Log_File_Size—Size of the log file in MB.
AE-Log—Specify ON or OFF to turn logging on or off.
AE-Trace-File—Full path name of the trace file.
AE-Trace_File_Size—Size of the trace file in MB.
AE-Trace—Specify ON or OFF to turn tracing on or off.
Turning on log and trace files 439


Index
A alerts (continued)
access control mapping through firewalls 326
group list 110 mid tier 216
User form 108 queue 30
accrue operator registration activity, with server events 369
full text search 248 server architecture and 22
accrue searches 254 time-out 129
accruing results with FTS 249 verifying users who receive 140
active links, run process directory and shell 169 viewing 214
activity, business web-based, list 216
creating 391 alias for server name 127
viewing associations 396, 397 allowing
adding guest users 113, 137
assignment forms 430 unqualified searches 137
assignment rules 436 API
admin queue 29 architecture and 22
administrator operations, disabling 139 log file 143
Administrator Preference form 50 version 135
administrator-only mode 138 appending to existing log file 144
advisory mode, source control 174 Application Licenses field 111
aging passwords 116 application services password 155
Alert Events form 213 AR Export file 287–289
alerts ar file 300
See also Remedy Alert AR System Portmapper
alert client registration 184 overview 35
architecture 212 registering 152
configuring server 202 AR System server
disabling 139 configuring 124
escalation 214 ID 131
log file 143 scalability 27
Index 441
AR System server (continued) ARF plug-in API 22

transferring licenses 42 arfilter.log 143
Windows stand-alone 194 arforkd
AR System Server Group Operation Ranking log file 144
form 191 utility 346
AR System User Central File form 50 arftindx.log 272
AR System User Preference form armonitor utility 346
Advanced tab 78 armonitor.conf (armonitor.cfg) file
Alert tab 84 overview 343
Color tab 67 arplugin utility 347
common fields 55 arplugin.log 144
Confirmation tab 68 arreload utility 169, 354, 369
Display tab 66 arserverd (arserver) utility 348
Edit tab 88 arserverdprocess 266
File tab 76 arsignal utility 184, 356
General tab 58 arsql.log 143, 273
Home Page tab 82 arthread.log 143
Locale tab 74 aruser.log 143
Logging tab 73 assignee groups 140
Misc tab 94 assigning TCP port numbers 149
overview 50 assignment
Recent tab 87 forms, adding 430
Report tab 70 rules
setting preferences for the web 102 creating 436
Web tab 98 sequencing 438
Window tab 92 Assignment Engine
ar.conf (ar.cfg) file 300 Administration Console 425
ar.ini file 49 Forms tab 426
aralert.log 143 methods 427
arcache utility 169, 350, 369 Processes tab 426
architecture rules
AR System 18 creating 436
AR System server 21 Rules tab 427
mid tier 20 attachment tables
architecture, alert 212 data 297
archive activity, with server events 370 details 297
archiving attachments
disabling 138 importing and exporting (import tool) 224
ardb.conf (ardb.cfg) file indexing for 266
overview 341 multiple languages and file formats 267
SQL warning 341 authenticating unregistered users 164
AREA authentication alias 116
configuring server 199 Authentication field, Login dialog box 121, 165
overview 23 Authentication Login Name field, User form 117,
RPC program number 163, 200 118
442 Index
Configuring
Authentication String Alias Application-Bus-Time-Subtract

configuring 120 command 403, 418
overview 120 Application-Get-Next-Recurrence-Time
Authentication String field, User form 120, 121 command 408
auto-assignment, working with command syntax 399
adding debugging tips 420
assignment forms 430 examples
Assignment Engine Console 425 one hour gap 412
methods 427 forms 387
rules holidays
creating 436 adjust time across midnight 415
sequencing 438 dates and times, entering 414
holiday time, using 412
B international server 414
backup log file 144 no end time 414
backward compatibility no start and end time 415
Remedy Alert, working with versions of no start time 414
AR System before 5.0 215 holidays form, setting dates in 412
blank password 116 how it works 388
buffer logged lines 145 migrating 419
business activity offset hours, using with 399
creating 391 overview 386
viewing associations 396, 397 Business Time Holidays form 387
business hours, defining business time Business Time Segment form 387
business hours, defining 409 Business Time Shared Entity form 387
Business Segment-Entity Association form 387 Business Time Shared Entity-Entity
Business Segment-Entity Association_Join Association_Join_Join 387
form 387 Business Time Workdays form 387
business time
Application-Bus-Time-Add command 402, C
417 cache
Application-Bus-Time-Assoc-Add changes 177
command 407 refresh interval for currency ratio 129
Application-Bus-Time-Assoc-Diff centralized preferences 49
command 407 changes
Application-Bus-Time-Assoc-Get-Free-Wind object 368, 371
ow command 408 server cache 177
Application-Bus-Time-Assoc-Get-Next-Wind server objects 369
ow command 408 server settings 369
Application-Bus-Time-Assoc-Subtract user and group 177, 369
command 407 viewing 370
Application-Bus-Time-Diff command 403, check interval, server groups 171
418 CleanupAlertEvents escalation 214
Application-Bus-Time-Get-Next-Window clients, configuring TCP port numbers 196
command 404 client-side, logging group 145
Index 443
CLOB storage 148, 329 D

clustered index used with Request ID 148 data
comments in source control 174 import file formats 223
computed groups importing records, methods of 228–229
overview 110 importing, procedure for 237–243
searching in User form 110 mapping for import 220
config.properties file 21 mapping with saved files 243
configuration files mapping, default path for 227
ar 300 preparing to import 222
ar.conf (ar.cfg) 300 reloading 356
ardb.conf (ardb.cfg) 341 Remedy Import, using to import 219
armonitor.conf (armonitor.cfg) 343 database servers 23
config.properties 21 databases
configuration options for full text search 269 attachment tables 297
Configuration Tool configuration file 147
alert system and 216 password 147
configuring Request ID and 283
AREA server 199 server information 146
clients 36, 51, 53, 196 status history table 296
databases 147 UNIX directory 147
firewalls 195 user name 147
mail server 202 version 147
multiple servers 179 databases, searching 248
servers datatype values, Server Events form 381
for alerts 202 date format 359
information 132 dates in business time holidays form, using 412
for plug-ins 197 debug modes
threads 153 trace mode 141
Windows clients and portmapper 196 using log files 141
consoles default
Assignment Engine Administration 425 home form 136
creating web path 168
Server Events form 366 Default Notify Mechanism field 111
cross-reference blank password 109, 165, 200 deleting
currency ratio, cache refresh interval 129 Demo user 112
currency types users 112
default allowable types 161 Demo user
default functional types 161 deleting 112
server settings 159 initial installation 111
user preferences 76 disabling
current licenses 106 administrator operations 139
customer support, contacting 39 alerts 139
customizing environment 48 archive 138
escalations 139
dispatcher thread 32
444 Index
Configuring
Distributed Server Option. See DSO FTS, defining for 277

DSO indexing 265, 277
configuration file options 319, 320 preserving existing values 286
local server password 157 Request ID and 282
log file 143 reserved for Server Events 366
remote server password 157 files
import log 244
E import types 223
email importing, data formats for 223
line length 168 files, configuration
notifications 134 ar 300
reserved field for address 111 ar.conf (ar.cfg) 300
email server 202 ardb.conf (ardb.cfg) 341
enforced mode, source control 174 armonitor.conf (armonitor.cfg) 343
entries returned by GetList 133 Filter API RPC time-out 129
environment filters
AR System architecture 18 log file 143
customizing 48 maximum 168
variables 36 process time-out 129
error messages, localizing 169 firewalls 195
escalations fixed write license 105, 131
CleanupAlertEvents 214 Flashboards
disabling 139 queue 30
log file 143 floating licenses
process time-out 129 information displayed 131
estimating FTS index size 278 releasing 107
Event Details fields 375 time limit 129
events recorded in Server Events form 368 write 105
events, server 176 form search field, adding 261
export file 287 formats
exporting importing data files 223
attachments 224 forms
external authentication (AREA) Administrator Preference form 50
configuring server 199 Alert Events 213
defined 23 AR System Server Group Operation
RPC program number 163, 200 Ranking 191
time-out 163 assignment forms, adding 430
business time 387
F Request ID and 282
fallback mappings 220 Server Events 177, 366, 375
fast queue 31 server, maximum number 131
fields User 108
changing existing value 286 User Central File 50
changing length 285–286 User Preference 50
Event Details 375
Index 445
forms (continued) groups (continued)

vendor 23 computed, in User form 110
view 23 multiple assignee 140
Forms tab 426 viewing changes 374
FTS weight, displaying 279 guest users, allowing 113, 137
FTS. See full text search
Full Name field (user) 111 H
full text index logging 271 hardware platform 127
full text search Home page
accrue operator 248 default home form 136
accruing results 249 form for mid tier 83
administering 265 form for Remedy User 83
capabilities 248, 264 server
configuration options 269 for mid tier 83
criteria 251 for Remedy User 83
debugging 271
defining fields 277 I
disk space and 278 IBM DB2 database
fields, indexing 265, 277 Request ID and 283
Ignore Words List 249, 264 Ignore Words List
indexes 251, 278 rebuilding index 268
licenses 250, 276 searches, using in 264
limits 264 using 249
logging 271 Import License window 45
method 251 importing
overview 248 data in to AR System 220
QBE settings 260 data mapping and 220
results list, formatting 279 data, preparing 222
results, weighting 249 data, procedure for 237–243
sorting records by weight 249 fallback mappings for 220
sorting requests by weight in Remedy process 220
User 249 records, methods of 228–229
time required to rebuild index 268 indexes
upgrading FTS 274 fields 277
using 250 FTS size, estimating 278
full text searches full text search 251, 265
indexing for attachments 266 Ignore Words List 268
multiple languages and attachment files 267 time required to rebuild FTS 268
information 409
G Informix database
GetList 133 Request ID and 283
Group List field 110 in-row storage, Oracle database 148, 329
groups Instance ID field 111
changes 177, 369 issues, when creating searches 263
client-side logging 145
446 Index
Configuring
J load balance
Java API 21 by capacity assignment method 427
JSP engine 20 by number assignment method 427
load-balanced environment, using with server
K events 366
keys, license 39 local preferences 49
local server password, DSO. See DSO
L locale 75
licenses localizing error messages 169
Add/Remove Licenses window 40 log files
applying alert 143
manually 41 API 143
new 40 append to existing 144
current 106 arforkd 144
exporting 43 backup 144
fixed write 105, 131 buffer logged lines 145
floating write 105, 131 data import log 227, 244
full text search 250, 276 Distributed Server 143
Import Licenses window 45 escalation 143
importing 45 filter 143
keys 39 log per thread 145
license pools 108 options 142
Manage User Licenses window 106 plug-in 144
maximum number of forms 131 server groups 144, 189
multiserver 38 server information 141
obtaining new 40 settings 141
overview 38 SQL 143
pools 108 threads 143
read 104 trace mode 141
registered users 106 users 143
releasing floating 107 log per thread 145
restricted read 104, 111 logging in
server groups 187 authentication alias 116
server information 130 Authentication field 121
submitter mode 131 User Name field 118
tab in Server Information dialog box 130 user prompt 133
transferring server 42 logging, full text index 271
types 38, 104, 111, 131 Login dialog box, authentication alias 118
user 105 Login Name field, User form 109
limitations logins, unique 122
full text search 264
list queue 31 M
literal search 256 Manage User License dialog box 105
mandatory preference server 51
Index 447
mapping data notifications (continued)

fields 239 Remedy Alert 213
import preferences and 228–229 server 212
overview 220 time-out 129
saved files and 243 web-based alerts 216
max forms allowed on server 131 Notify action 213
maximum
entries returned by GetList 133 O
filters for an operation 168 object changes 368
line length in email 168 server settings 369
log-file size 145 viewing server changes 371
stack of filters 168 Object ID field 111
methods offset hours, using with business time 399
auto-assignment 427 operating system 127
Microsoft SQL Server database operations, preventing 138
Request ID and 283 Oracle database
mid tier CLOB storage 148, 329
administration password 155 Request ID and 283
setting
home page 83 P
preferences 102 parametric full text search 262
web-based alerts 216 password
migrating business time 419 number of retries 327
modes Password field in User form 109
administrator-only 138 passwords
debugging 141 administering 154
server records 170 aging in operating system validation 116
source code 174 application service password 155
submitter 115, 130, 131 blank 116, 200
modifying character limit in Password field 109
Ignore Words List (FTS) 268 Cross Ref Blank Password option 116
multiple assign groups 140 database 147
multiple servers 149, 179 Demo 111
multithreaded servers DSO local server 157
architecture 27 DSO remote server 157
queues 29–31 length for operating system validation 116
RPC program numbers 29 length limit in Password field in User
threads 32, 34 form 109
multi-tier architecture 18 lockout periods for operating system 116
modifying by users 113
N Password field in User form 109
next available Request ID, changing 283 plug-in server password 156
notifications security 109, 116
email 134 validating 165
ports 151
448 Index
Configuring
passwords (continued) $PROCESS$

validating operating system 116 business time 399
workflow server 158 commands 399
performance tuning process time-out 129
request ID uses clustered index 148 Processes tab 426
unqualified searches 137 properties
permission types 110 indexing for FTS 277
plug-ins
AR System filter plug-in API 22 Q
configuring server 197 QBE settings 260
log file 144 queries. See searches
server password 156 queues
pool admin 29
license 108 configuring threads 153
port numbers. See TCP port numbers fast 31
portmapper list 31
See also Remedy Portmapper overview 29–31
dependency, removing 196 private 31
ports server 149, 152
notification 151 server statistics 170
server 149
preference servers R
mandatory 51 read license 104, 111
preferences rebuilding FTS indexes 267
See also AR System User Preference form recording events 368
centralized 49 recording interval, statistics 170
forms 50, 55 recurrence
local 49 options 409
mid tier 102 overview 386
Remedy Import 225–237 registered
server 50, 51, 53 licenses 106
setting with client tools 55 users 108
synchronization 49, 55 registered users in Remedy Alert, managing 215
user 48, 55 registering with portmapper 152
web clients 102 Remedy Alert 22
Windows clients 55 See also alerts
prefixes backward compatibility 215
lengthening 295 installing 217
shortening 292 overview 213
preventing user operations 138 Remedy Configuration Tool
private queues 31 architecture 21
private servers Remedy Import
adding 197 data mapping 220
operations supported 31 fallback mappings 220
Index 449
Remedy Import (continued) S

import log file 227, 244 scalability
importing data and 237–243 AR System server 27
preferences, defining 225–237 mid tier 26
Remedy User scheduling workdays 409
licensing user, full text search 276 searches
search results, order 249 accrue 254
sorting requests by weight (FTS) 249 for computed groups 110
weight (FTS) in results list, displaying 279 How QBE settings affect FTS 260
Remedy User, setting home page 83 Ignore Words List, using in 264
Remote Procedure Call (RPC). See RPC program literal 256
numbers parametric full text search 262
remote server password, DSO 157 search issues 263
removing. See deleting search strategies 263
Request ID field unqualified 137
changing length or prefix 285–286 Word or Phrase 252
changing value 286 security
number 283 Demo password 111
preserving existing values 286 guest users 113
working with 282 passwords 109, 116
request ID uses clustered index 148 settings 169
Request ID, changing next available 283 sequencing, rules 438
requests server cache, changes 177
processing 33 server events
restarting threads 34 alert client registration 177
routing to appropriate queues 32 archive 177
submitter mode 115, 131 multiple servers using same database 184
reserved fields server groups 177
Server Events 366 server setting changes 177
restricted read license 104 settings 176
retries for passwords 327 types 177
Round Robin, assignment method 427 using with load-balanced environment 366
RPC program numbers Server Events form 365
AR RPC number 197 automatic generation 366
external authentication server 163, 200 creation 366
fixed 29 datatype values 381
setting 149 event types 368
rules events that can be recorded 368
assignment 436 server setting changes 375
sequencing 438 specifying 177
Rules tab 427 using 366
run process directory 169 workflow and 384
server group actions, with server events 370
450 Index
Configuring
server groups server utilities (continued)

AR System Server Group Operation Ranking arreload 354
form 191 arserverd (arserver) 348
check interval, setting 171, 188 arsignal 356
communicating with Remedy Email servers
Engine 193 alerts, configuring for 202
communicating with Remedy AR System
Flashboards 194 architecture 21
configuration file options 335, 336 transferring license 42
group name, setting 171, 188 architecture 27
installing members 187 AREA 199
licensing 187 cache changes 177
log file, setting 144, 189 configuring
logging in Server Events form 190 clients 196
multiple servers accessing same database 183 for plug-ins 197
operations 185 multiple servers 179
overview 185 configuring threads 153
ranking servers in 191 database 23
removing a server 193 directory 127
server name 190 language 134
signaling 193 license type 131
specifying a server as a member 140, 187 mail 202
specifying operations for servers 192 maximum forms allowed 131
server information multiple 149, 179
advanced 167 multiple servers sharing same database 181
configuration 132 name alias 127
currency types 159 name in server groups 190
database 146 Notification 212
licenses 130 object changes 369, 371
log files 141 server 368
overview 124 ports 149
password administration 154 preference 50, 51, 53
platform 126 private 31
server events 176 processing concurrent requests 32
server ports 149 queue 29–31, 152
source control 171 ranking for server groups 191
timeouts 128 report server 80
Server Information dialog box 124 See also server cache
server recording mode 170 server groups 185
server statistics 170 stand-alone 194
server utilities statistics 170
arcache 350 TCP/IP port 151
arforkd 346 time zone 127
armonitor 346 version 127
arplugin 347 web 20
Index 451
web servers threads

servlets 20, 26 configuring 153
settings dispatcher 32
log files 141 log file 143
QBE 260 notification 151
server information 124 processing requests 33
sort restarting 34
records by weight 249 routing requests 32
source control types of 32–33
advisory and enforced modes 174 worker 29, 33
comments required in check in 174 time and date settings in AR System 385
SQL time format 359
ardb configuration file warning 341 time zone 127
log file 143 timeouts 128
SQL commands trace modes, debugging log files 141
Request ID field prefix, lengthening 295 types of licenses 38, 104
Request ID field prefix, shortening 292
SQL logging 272 U
stand-alone server, Windows and AR System 194 unique user logins 122
starting armonitor utility 346 UNIX
statistics, recording server 170 database directory 147
status history table 296 email notifications 134
stems, word 259 UNIX servers, starting 346
strategies for full text searching 263 unqualified searches 137
submitter mode option 131 unregistered users, authenticating 164
submitter, special access mode 115 upgrading FTS 274
Sybase database URL
Request ID and 283 base to mid tier 168
syntax User form
business time commands 399 Authentication Login Name field 117, 118
Authentication String field 120, 121
T guest users 113
table types, database user information 108
attachment details 297 user name alias
status history 296 configuring 117
tabs overview 116
Forms 426 User Name field, user name alias 118
Processes 426 users
Rules 427 alert 140
TCP port numbers authenticating 164
AR TCP Port 197 changes 177, 369
assigning 149 customizing preferences 48
configuring clients 196 defined 108
TCP/IP port 151 deleting 112
thread manager 34 Demo user 112
452 Index
Configuring
users (continued) web-based alerts 216

email notifies from 134 weight
full name field 111 results with FTS 249
guest 113, 137 sorting records by 249
license information 105 weight, FTS 279
log file 143 wildcards
names 109 full text search 260
operations, preventing 138 wildcards, in full text searches 259
permissions 110 Windows servers
prompted for login 133 data reload 356
registered, in Remedy Alert 215 starting 346
viewing changes 373 Word or Phrase search 252
web 102 word stems 259
utilities worker threads 29, 33
arcache 350 workflow
arforkd 346 logging 145
armonitor 346 Server Events form and 384
arplugin 347 server password 158
arreload 354 write licenses
arserverd (arserver) 348 fixed 105
arsignal 356 floating 105, 107
V
validating passwords 165
variable, environment 36
vendor form 23
verifying alert users 140
view form 23
viewing
alerts 214
group changes 374
server changes 370
server object changes 371
user changes 373
W
web
See also mid tier
centralized preferences 102
default path 168
Remedy Configuration Tool for mid tier 21
server
definition 20
web services
architectural overview 25
Index 453
454 Index
*58466*
*58466*
*58466*
*58466*
*58466*

Configuring 700

Uploaded by

Document Information

Original Description:

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

Configuring 700

Uploaded by

Copyright:

Available Formats

BMC® Remedy® Action Request System® 7.

Restricted Rights Legend

This edition applies to version 7.0 of the licensed program.

BMC Software, Inc.

Chapter 1 BMC Remedy Action Request System 7.0 architecture . . . . . . . 17

Chapter 2 Obtaining and activating licenses . . . . . . . . . . . . . . . . . 37

Chapter 3 Setting user preferences . . . . . . . . . . . . . . . . . . . . . 47

Chapter 4 Defining your user base . . . . . . . . . . . . . . . . . . . . . 103

Chapter 5 Configuring servers and clients . . . . . . . . . . . . . . . . . 123

Running a stand-alone AR System server on Windows . . . . . . . . . . . 194

Chapter 6 Working with the alert system . . . . . . . . . . . . . . . . . 211

Chapter 7 Importing data into AR System forms . . . . . . . . . . . . . . 219

Chapter 8 Using full text search . . . . . . . . . . . . . . . . . . . . . . 247

Appendix A Working with the Request ID field . . . . . . . . . . . . . . . . 281

Appendix B AR System configuration files . . . . . . . . . . . . . . . . . . 299

Appendix C AR System server components and external utilities . . . . . . . 345

Appendix D Date and time formats . . . . . . . . . . . . . . . . . . . . . 359

Appendix E Working with the Server Events form . . . . . . . . . . . . . . 365

Appendix F Using Business Time in the AR System server . . . . . . . . . . 385

Appendix G Using the Assignment Engine . . . . . . . . . . . . . . . . . . 423

Auto-assignment methods . . . . . . . . . . . . . . . . . . . . . . . 427

Important: The compatibility information listed in the product

Carefully read the system requirements for your particular operating

Title Description Audience

Title Description Audience

Title Description Audience

Learn about the AR System Developer Community

Why should you participate in the Developer Community?

How do you access the Developer Community?

Learn about the AR System Developer Community 15

1 BMC Remedy Action Request

BMC Remedy Action Request System 7.0 architecture 17

AR System architecture overview

18 Chapter 1—BMC Remedy Action Request System 7.0 architecture

Figure 1-1: AR System architecture

AR System architecture overview 19

Within these three functional environments, several system components

BMC Remedy mid tier

20 Chapter 1—BMC Remedy Action Request System 7.0 architecture

JAVA API—An API that is used to communicate with the AR System

AR System architecture overview 21

The main components of the AR System server architecture are:

22 Chapter 1—BMC Remedy Action Request System 7.0 architecture

AR System External Authentication (AREA)—A process that accesses

AR System architecture overview 23

Figure 1-2: AR System server infrastructure

Access Control and

Sybase MSSQL Oracle Informix DB2 View Vendor

24 Chapter 1—BMC Remedy Action Request System 7.0 architecture

AR System and web services

Creating and publishing a web service

AR System and web services 25

Consuming a web service

Mid tier scalability

26 Chapter 1—BMC Remedy Action Request System 7.0 architecture

AR System server scalability

Figure 1-3: Multithreaded server architecture

Browser AR System AR System Client

Note: The number of

28 Chapter 1—BMC Remedy Action Request System 7.0 architecture

Queue type RPC program number

The following sections describe the different types of queues.

30 Chapter 1—BMC Remedy Action Request System 7.0 architecture