ARS 7.5 - Concepts Guide

BMC Remedy Action Request System 7.5.
00
Concepts Guide
January 2009
www.bmc.com
Contacting BMC Software
You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information
about the company, its products, corporate offices, special events, and career opportunities.
United States and Canada
Address BMC SOFTWARE INC Telephone 713 918 8800 or Fax 713 918 8000
2101 CITYWEST BLVD 800 841 2031
HOUSTON TX 77042-2827
USA
Outside United States and Canada
Telephone (01) 713 918 8800 Fax (01) 713 918 8000
If you have comments or suggestions about this documentation, contact Information Design and Development by email at
doc_feedback@bmc.com.
© Copyright 1991–2009 BMC Software, Inc.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent
and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and
logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the
property of their respective owners.
IBM, DB2, and AIX are trademarks or registered trademarks of International Business Machines Corporation in the United States, other
countries, or both.
Linux is the registered trademark of Linus Torvalds.
®
IT Infrastructure Library is a registered trademark of the Office of Government Commerce and is used here by BMC Software, Inc.,
under license from and with the permission of OGC.
ITIL® is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the
U.S. Patent and Trademark Office, and is used here by BMC Software, Inc., under license from and with the permission of OGC.
Oracle is a registered trademark of Oracle Corporation.
Sun, Solaris, Java, JavaServer, and JSP are trademarks or registered trademarks of Sun Microsystems, Inc., in the U.S. and other countries.
UNIX is the registered trademark of The Open Group in the US and other countries.
BMC Software 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 for the product and the proprietary and restricted
rights notices included in this documentation.
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.
Customer Support
You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer
Support by telephone or email. To expedite your inquiry, please see “Before Contacting BMC Software.”
Support website
You can obtain technical support from BMC Software 24 hours a day, 7 days a week at
http://www.bmc.com/support_home. From this website, you can:
■ Read overviews about support services and programs that BMC Software offers.
■ Find the most current information about BMC Software products.
■ Search a database for problems similar to yours and possible solutions.
■ Order or download product documentation.
■ Report a problem or ask a question.
■ Subscribe to receive email notices when new product versions are released.
■ Find worldwide BMC Software support center locations and contact information, including email addresses, fax
numbers, and telephone numbers.
Support by telephone or email

In the United States and Canada, if you need technical support and do not have access to the Web, call 800 537 1813 or
send an email message to customer_support@bmc.com. (In the Subject line, enter
SupID:<yourSupportContractID>, such as SupID:12345.) Outside the United States and Canada, contact
your local support center for assistance.
Before contacting BMC Software

Have the following information available so that Customer Support can begin working on your issue immediately:
■ Product information
— Product name
— Product version (release number)
— License number and password (trial or permanent)
■ Operating system and environment information
— Machine type
— Operating system type, version, and service pack
— System hardware configuration
— Serial numbers
— Related software (database, application, and communication) including type, version, and service pack or
maintenance level
■ Sequence of events leading to the problem
■ Commands and options that you used
■ Messages received (and the time and date that you received them)
— Product error messages
— Messages from the operating system, such as file system full
— Messages from related software
License key and password information
If you have a question about your license key or password, contact Customer Support through one of the following
methods:
■ E-mail customer_support@bmc.com. (In the Subject line, enter SupID:<yourSupportContractID>,
such as SupID:12345.)
■ In the United States and Canada, call 800 537 1813. Outside the United States and Canada, contact your local support
center for assistance.
■ Submit a new issue at http://www.bmc.com/support_home.
Contents
Preface 7
AR System documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapter 1 About AR System 11

What is AR System?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Example of a service desk solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
AR System adaptability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
AR System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
AR System clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
AR System mid tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
AR System server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Database servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Heterogeneous environment provides flexibility. . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Distributed environments provide scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Application components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
How application components work together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Administrator responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Developer responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Programmer responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Chapter 2 Forms and applications 25

About AR System forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Types of forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Form views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Using fields in forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Characteristics common to all fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Core fields in a regular form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Attaching menus to fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Bundling forms into applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Localizing applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Chapter 3 Workflow 35
Workflow in general and in AR System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
How workflow components differ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Events versus time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Client versus server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Contents 5
Collections of workflow components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Workflow actions and execution options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Workflow actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Workflow execution options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Workflow qualifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Keywords in qualifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Chapter 4 Access control 47

About access control in AR System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
User and group access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Types of access control groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Additive permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Membership in multiple groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Role-based access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Multitiered access control model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
How licensing affects access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Chapter 5 Extending AR System 55

AR System foundation products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
BMC Atrium products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
AR System–based solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Other BMC products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Integration with third-party products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Chapter 6 Putting it all together 59

About the wild animal park . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Goals of the animal tracking application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Planning and design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Analyzing data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Analyzing workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Defining business rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Mapping business rules to workflow components . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Considering integrations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Planning and design decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Decisions about forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Decisions about access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Decisions about business rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Decisions about workflow components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Putting the application to work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A tiger is acquired . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
The tiger is injured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
The tiger is traded to another zoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Glossary 71
Index 85
6 Concepts Guide
Preface
BMC Remedy Action Request System (AR System) is the foundation for a wide
range of business solutions, from service desk call tracking to inventory
management to integrated systems management.
This guide discusses core concepts of AR System. It is primarily for new
administrators who will use AR System to create or modify applications. Other
audiences, including business managers and persons evaluating and prototyping
applications based on AR System, might also find this guide helpful. Procedures,
performance, and other topics are documented in the books listed in the following
section.
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 DVDs, on the Customer Support
website (http://www.bmc.com/support_home), or both.
You can access product help through each product’s Help menu or by clicking
Help links.
Title Description Audience

1
Concepts Guide Overview of AR System architecture and features; includes Everyone
information about add-on products that extend AR System
functionality and a comprehensive glossary for the entire
AR System documentation set.
Installation Guide Instructions for installing AR System. Administrators
Introduction to Application Information about the development of AR System Developers2
Development with BMC applications, including an introduction to using BMC
Remedy Developer Studio Remedy Developer Studio.
Form and Application Objects Information about AR System applications and their user Developers
Guide interface components, including forms, fields, views,
menus, and images.
Workflow Objects Guide Information about the AR System workflow objects (active Developers
links, filters, and escalations) and how to use them to create
processes that enforce business rules.
Preface 7
BMC Remedy Action Request System 7.5.00

Configuration Guide Information about configuring AR System servers and Administrators
clients, localizing, importing and exporting data, and
archiving data.
BMC Remedy Mid Tier Guide Information about configuring the mid tier, setting up Administrators
applications for the mid tier, and using applications in
browsers.
Integration Guide Instructions for integrating AR System with external Administrators/
systems by using web services, plug-ins, and other products, Developers/
including LDAP, OLE, and ARDBC. Programmers3
Optimizing and Information about monitoring and maintaining AR System Administrators/
Troubleshooting Guide and AR System applications to optimize performance and Developers/
solve problems. Programmers
Database Reference Database administration topics and rules related to how Administrators/
AR System interacts with specific databases; includes an Developers/
overview of the data dictionary tables. Programmers
BMC Remedy Distributed Information about implementing a distributed AR System Administrators
Server Option Guide server environment with BMC Remedy Distributed Server
Option (DSO).
BMC Remedy Flashboards Instructions for creating, modifying, and administering Administrators/
Guide flashboards to display and monitor AR System information. Developers
C API Reference Information about AR System data structures, C API Programmers
function calls, and OLE support.
C API Quick Reference Quick reference to C API function calls. Programmers
Java API Information about Sun™ Java™ classes, methods, and Programmers
variables that integrate with AR System. For the location of
the JAR file containing this online documentation, see the
information about the Java API in the Integration Guide.
Java Plug-in API Information about Java classes, methods, and variables used Programmers
to write plug-ins for AR System. For the location of the JAR
file containing this online documentation, see the
information about plug-ins in the Integration Guide.
BMC Remedy Email Engine Instructions for configuring and using BMC Remedy Email Administrators
Guide Engine.
Error Messages Guide Descriptions of AR System error messages. Administrators/
Developers/
Programmers
Master Index Combined index of all books. Everyone
BMC Remedy Approval Instructions for using BMC Remedy Approval Server to Administrators
Server Guide automate approval and signature processes in your
organization.
Release Notes Information about new features, compatibility, and Everyone
international issues.
Release Notes with Open Information about new features, compatibility, international Everyone
Issues issues, installation planning, and open issues.
BMC Remedy User Help Instructions for using BMC Remedy User. Everyone
8 Concepts Guide
AR System documents

BMC Remedy Data Import Instructions for using BMC Remedy Data Import. Administrators
Help
BMC Remedy Alert Help Instructions for using BMC Remedy Alert. Everyone
BMC Remedy Mid Tier Instructions for configuring BMC Remedy Mid Tier. Administrators
Configuration Tool Help
1
The full title of each guide includes BMC Remedy Action Request System 7.5.00 (for
example, BMC Remedy Action Request System 7.5.00 Concepts Guide).
2
Application developers who use BMC Remedy Developer Studio.
3
C and Java programmers who write plug-ins and clients for AR System.
Preface 9
10 Concepts Guide
Chapter
1 About AR System
Every company, whether it makes bicycles or provides worldwide

telecommunications services, has its own business needs and processes. BMC
Remedy Action Request System (AR System) enables you to automate many
business processes without learning a programming language or complex
development tools.
This chapter introduces AR System architecture and application components and
explains how they fit together to address your organization’s needs.
The following topics are provided:
What is AR System? (page 12)
AR System architecture (page 14)
Application components (page 20)
Administrator responsibilities (page 23)
Developer responsibilities (page 23)
Programmer responsibilities (page 23)

What is AR System?
AR System is a professional development environment that
Leverages the best practices of the IT Infrastructure Library® (ITIL®)
Provides a foundation for Business Service Management (BSM) solutions
Using AR System, nonprogrammers can build powerful business workflow
applications and deploy them simultaneously in web, Windows, UNIX®, and
Linux® environments.
Applications built with AR System can automatically track anything that is
important to the processes in your enterprise. Companies use AR System
applications to track such diverse items as stock trades, benefits data, inventory
assets, spare parts, and order fulfillment. One of the most common uses of
AR System is to automate internal service desks. The following example illustrates
a service desk solution in which AR System solves an employee’s problem.
Example of a service desk solution

Ramona’s printer would not work, so she logged in to her company’s service desk
portal and entered information about the problem. The system automatically
offered several knowledge base articles that might apply to her problem, but none
resolved the issue for her.
Ramona then opened a service desk request through the portal to get further
assistance from the IT department. When she entered her phone number into the
blank request form on her screen, details of her configuration and location
automatically appeared in the form. Ramona filled in the remaining details about
her problem and submitted the request. She immediately received a message
informing her that the case had been assigned to Becky.
Becky was automatically paged and used her computer to review the problem.
Using her knowledge of similar problems, she fixed the printer and marked the
case closed. Ramona was then notified that the problem was fixed.
If Ramona’s problem had been an emergency that was not handled within an hour,
the system would have automatically paged the appropriate support personnel
and sent an email message to Ramona, informing her of the request status.
In this example, AR System automated the offer of knowledge base articles, the
entry of information in the form, the assignment notification, the paging system,
the closure notification, and the emergency response.
A service desk application and other ready-to-use AR System applications are
available from BMC and its partners (see Chapter 5, “Extending AR System”). You
can also create your own custom solutions.
12 Concepts Guide
What is AR System?
AR System adaptability
AR System strikes a balance between hard-coded applications, which are typically
inflexible, and development toolkits, which often require extensive technical
knowledge and time to use. Instead, AR System provides a platform from which
even nonprogrammers can modify ready-to-use BMC applications or create
custom applications to fit their unique enterprise.
Figure 1-1: AR System adaptability

Ready-to-use
Development tools
applications
AR System provides a platform
on which a rich collection of ready-
to-use applications can run. It
also provides the customization
power traditionally associated
with development tools.
AR System
Adaptable applications
Perhaps the best way to understand the adaptability of AR System is through an

example. Paul owns a small video store and installs AR System to help track
inventory. Initially, he builds a simple application that has one form. The form
collects the video title, rating, format, number of copies, and rental fee. When his
business grows and he needs to track employees, he adds a form that collects the
employee number, salary, start date, training, and time card.
Next, Paul links his application to a credit/debit verification system by using the
AR System open application programming interface (API). Later, he adds an order
tracking and purchasing application to automatically order items through web
services. He then creates a website to enable customers to order movies and pay
rental fees online, and to store their rental history in a knowledge base. He further
automates the system to provide proactive movie suggestions based on this rental
history.
Thanks to the rapid growth of his business and the flexible, adaptable architecture
of AR System, Paul opens new stores in cities across the country. He links all the
stores into one system and uses real-time graphic flashboards to track his entire
operation. Paul can track incidents, inventory, employee information, order
processing, and customer satisfaction from his office, and he can easily extend or
modify his system whenever changes occur in his organization.

AR System architecture
AR System is based on a multitiered client/server architecture:
Client tier—Contains AR System clients. Most clients present information to
application users and receive input from them, but the tools for migration and
application development are also clients.
Mid tier—Contains components and add-in services that run on a web server,
enabling users to view applications on the web.
Server tier—Contains the AR System server, which controls workflow
processes and access to databases and other data sources in the data tier. This
tier also contains server-side applications (such as Approval Server,
Email Engine, and the Flashboards server) and the C and Sun Java plug-in
servers with plug-ins.
Data tier—Contains database servers and other data sources that can be
accessed by the AR System server. The database server acts as the data storage
and retrieval engine.
Figure 1-2: AR System architecture
Client tools are

Client used to access,
Tier manage, and build
applications.
Browser Desktop
applications
The mid tier lets you

Mid access the AR System
Tier Mid Tier and
server from a browser
and makes web
Web services services accessible.
The AR System
Server server runs
Tier applications
AR System server and workflow.
It also enforces
business logic.
The data tier

Data holds data that
Tier applications
create and
manipulate.
AR System Other Other data
database databases sources
14 Concepts Guide
AR System clients
AR System clients can be broadly divided into user clients and developer clients.
User clients
The user clients use standard interfaces for their respective environments:
User client Platform Description

Browsers Provide a user Can be used for these functions:
interface to Submitting, searching for, and modifying
AR System requests
applications Charting data
through the
mid tier
Generating reports
Receiving and responding to AR System
BMC Remedy User Provides a
notifications
Windows-based
user interface to Performing administrative tasks such as
AR System license management and AR System server
applications configuration
BMC Remedy Alert Windows Sometimes considered a “desktop pager,” this

client notifies users about events by flashing an
icon, beeping, playing a sound file, running a
process, or opening a message window. For
example, it can display a message (an alert) to
notify service desk personnel that a reported
problem has been assigned to them.
Note: A similar functionality is available
through browsers. In browsers, alerts are
displayed in the Alert List form, which can be
refreshed automatically at specified intervals
or manually at any time.

Developer clients
The developer clients are used to create, modify, and extend AR System
applications:
Developer client Description

BMC Remedy Developer Studio Used to create and modify all the components of an
AR System application, such as forms and workflow
elements.
BMC Remedy Data Import Used to load external data into AR System forms. For
example, employee information can be extracted
from a human resources application and loaded into
the People form as a batch process, eliminating the
need to retype data. This client is also used to import
AR System data from one AR System server to
another.
BMC Remedy Migrator Used to migrate applications, objects, and data
between servers, servers and files, or files. This client
reduces the difficulty and time required to
synchronize AR System servers in development and
production environments.
Note: For limitations on using BMC Remedy Migrator
with other BMC applications, see the BMC Remedy
Migrator Release Notes on the Customer Support
website (http://www.bmc.com/support_home).
Integration clients
BMC and its partners also offer the following tools for expanding the capabilities
of core AR System. These tools act as clients of AR System.
BMC Atrium Integration Engine (AIE)
BMC Remedy Knowledge Management
Network management platform integration accessories
Systems management integration utilities
See Chapter 5, “Extending AR System.”
16 Concepts Guide
AR System mid tier

BMC Remedy Mid Tier translates client requests, interprets responses from the
server, handles web service requests, and runs server-side processes that provide
AR System functionality to web clients. For example, unlike BMC Remedy User, a
browser is a generic client that has no inherent knowledge of applications that run
in it. By acting as an interpreter, the mid tier enables a browser to become a fully
functional AR System client.
The mid tier requires a supported Sun JavaServer™ Pages (JSP™) engine. For
example, you can install the Apache Tomcat servlet engine with the mid tier. For a
list of other supported JSP engines, see the BMC Remedy compatibility matrixes
on the Customer Support website (http://www.bmc.com/support_home).
AR System server
The AR System server processes all data entered through a client. As the workflow
engine between client and database, the server writes data to the database when a
request is created and retrieves data from the database when a client requests it.
The server verifies that a user has permission to perform each transaction, thereby
enforcing any access control defined in an application. The server also
continuously evaluates the data in the database and each transaction to determine
whether the server should perform workflow. The server might also perform
workflow on a timed basis. See Chapter 3, “Workflow.”
The AR System server communicates with the mid tier, AR System clients, and
external applications by means of a well-defined API. The server is available for
each of these operating systems:
Hewlett Packard HP-UX
IBM® AIX®
Linux (Red Hat and Novell SuSE)
Microsoft Windows Server
Sun Microsystems Solaris™
NOTE
For the most accurate information about supported platforms and software, always
see the BMC Remedy compatibility matrixes on the Customer Support website
(http://www.bmc.com/support_home).
Server groups
To provide scalability and increase reliability, you can connect a group of servers
to the same database and manage them as a unit. Servers in a group act as a single
server to support the applications that they run. They can be configured to spread
the load of shared services, and they can provide backup to each other to ensure
that those services are always available.

Database servers
AR System uses standard relational databases to store and retrieve data.
Architecturally, the database server processes are completely separate from the
AR System server processes. Physically, the database server processes can run on
the same computer as the AR System server or on a different computer.
Because the AR System server manages all workflow, applications are
independent of the database. Therefore, applications created on an AR System
server running one type of database can easily be moved to a server running a
different type of database. BMC provides a simple export/import utility for this
purpose.
AR System can use any of these database platforms:
IBM DB2®
IBM Informix Dynamic Server
Microsoft SQL Server
Oracle®
Sybase ASE
NOTE
For the most accurate information about supported platforms and software, always
see the BMC Remedy compatibility matrixes on the Customer Support website
(http://www.bmc.com/support_home).
AR System workflow components can search for records (requests) in the

AR System database and act on the results of the search. Clients can use the
following types of searches:
Query-by-example (QBE)
Advanced search
Predefined
Recent
An administrator can create and store searches that are commonly performed by
users. A user can define personal searches for forms to which the user has access.
AR System can also work with data stored in external databases and other data
sources that are not managed by AR System. AR System accesses these data
sources through view forms. In addition, AR System can use AR System database
connectivity (ARDBC) to work with data not stored in databases as if the data were
locally owned.
18 Concepts Guide
Heterogeneous environment provides flexibility

Because the multiple layers of AR System are independent of one another, you can
combine platforms to fulfill different functions. The heterogeneous environment
enables you to mix and match clients and servers. For example:
BMC Remedy Developer Studio on a computer running Windows can manage
forms on a UNIX or Linux server.
Browsers can use a Windows-based mid tier to access forms on a UNIX server.
An AR System server on Windows can interact with a database on UNIX.
Distributed environments provide scalability

Use BMC Remedy Distributed Server Option (DSO) to build large-scale,
distributed environments that behave like a single virtual system. DSO enables
you to share common information among servers and to keep that information
consistent. For example, as illustrated in Figure 1-3, you can transfer copies of a
request to other servers and ensure that any changes made to the copies are also
made to the original request. The way that you define the processes for
transferring information is similar to the way that you define business processes
for an application. First, managers at each site must agree on what information to
transfer from one application to another, what conditions drive transfers, and
which sites control the ability to update a record. An administrator at each site then
uses DSO to implement these decisions.
Figure 1-3: AR System in a distributed environment
AR System AR System
Clients Clients
Transfer
Update
AR System Server AR System Server

Tokyo New York
with Distributed Server Option with Distributed Server Option
(Owner of Request)

Application components
Applications developed with BMC Remedy Developer Studio are fully
customizable and extensible. You can add your own fields, objects, and templates
to any application, whether it was created by you, purchased from BMC, or
acquired from a third party. AR System provides extensive authoring capabilities
for applications built for web and Windows environments.
This section introduces the main components of an AR System application.
Form—The main AR System application component that users interact with is a
form. Each form is composed of fields. A field can be a unit of information, such
as an employee’s last name, or it can be a visual element, such as a line or a box.
You can design different field arrangements, or views, of forms for different user
functions. When a user fills in the fields and saves the data, the system creates a
request to track. In database terms, each request is a record.
You can bundle related forms into an application. For example, a human
resources application might include forms for basic employee data, health
benefits, and salary information. You can deploy the application to multiple
servers to make it accessible to employees in different locations. You can also
display your application on the web to allow access from a browser on any
platform, as shown in Figure 1-4. See Chapter 2, “Forms and applications.”
Figure 1-4: Console application viewed in a browser
20 Concepts Guide
Application components
Menu—Menus are lists that you create to guide the user in entering information
in fields on forms. A menu can contain all possible values for a field, or it can
contain some possible values, enabling users to enter text that is not on the
menu. You can design dynamic menus, which change their contents based on
the data already entered in the form. See “Attaching menus to fields” on
page 32.
Workflow—While forms provide the mechanism to structure data capture and
menus offer options for specific field data, additional components—active links,
filters, and escalations—act on the data to automate business processes, or
workflow. These components trigger actions in response to execution options that
you define. In AR System, workflow generally refers to the operations triggered
by these components, but AR System also addresses the broader meaning of
workflow, which consists of the processes that your organization uses to run
itself. See Chapter 3, “Workflow.”
Active link—An active link is an action or group of actions performed on the
client. Active links are triggered by user actions in a form. They can be used
to perform a variety of tasks, such as giving quick responses during data entry
and auto-filling fields. For example, an active link can verify a value entered
in the Employee ID field of a request and then pull information from a
supporting People form to fill in other fields on the request, such as Requestor
Name, Department, and Phone Number, dramatically reducing the time
required for support staff to fill out a request.
An active link guide is a group of active links. Because active link guides run
on a client, they can augment training by leading users through the steps
necessary to fill in one or more forms to accomplish a specific task. For
example, when an employee clicks a Request Business Cards button on a
human resources form, an active link guide might open a business cards form
and then display input instructions, field by field, until the card request is
complete and ready to submit. Active link guides can also be used as
subroutines to accomplish common tasks.
Filter—A filter is an action or group of actions performed on the AR System
server. Filters are used to enforce business rules and to ensure system and
data integrity. As the server processes a request, the filters associated with
that form and action evaluate the data in the request. For example, you can
verify the values in a completed form by using a filter to compare them
against your business rules and return an error if the request violates any of
those rules.
A filter guide is a group of filters that can be used as a subroutine in workflow.
Because filter guides run on the server, they cannot be used like active link
guides to lead users through a form.
Escalation—An escalation is an action or group of actions performed on the
server at specified times or time intervals. Basically, an escalation is an
automated, time-based process that searches for requests that match certain
criteria at specified times and takes actions based on the results of the search.
For example, an escalation can trigger AR System to notify the next level of
management if a problem is not assigned to a technician within one hour of
submission.

How application components work together

In the example on page 12, when Ramona entered her telephone number into the
Telephone # field, the following sequence occurred, as illustrated in Figure 1-5:
1 An active link searched the Employee form to retrieve the name, configuration,
and location associated with the telephone number.
2 After Ramona finished entering information into the form and submitted it, filters
triggered an external paging system integrated with AR System to notify Becky
that Ramona’s printer was not working.
3 Becky fixed the problem.
4 Becky changed the status of the request, and a filter notified Ramona that her
problem was solved.
Figure 1-5: Automated workflow example
Problems Form
1
Active link
Telephone # 555-1212
Employee Form
Name
Name Ramona
Configuration
Configuration PC
Location
Location B2
Status
2 Data entry finished
Filters fire When Status

4 becomes "solved,"
a filter notifies
Ramona
Becky paged
.
3 Problem solved
If the situation had been flagged as an emergency and no one was assigned to the
request within an hour, an escalation would have paged all required support
personnel, and a filter would have sent Ramona an email message informing her
of the status of her request.
22 Concepts Guide
Administrator responsibilities
Administrator responsibilities
Typically, AR System administrators are responsible for some or all of these tasks:
Installing AR System software
Defining their organization’s work processes and business rules
Determining how to allocate server and database resources
Managing AR System access control by assigning permissions for AR System
applications and their components
Maintaining AR System by adding and deleting users, groups, and roles;
backing up AR System servers; importing data from other systems; and so on
Developer responsibilities
Typically, AR System developers are responsible for some or all of these tasks:
Creating an AR System application that reflects a set of work processes and
business rules, or working with a consultant to create an application
Localizing an AR System application for use in other languages or countries
Modifying an AR System application to reflect changes in the organization’s
work processes
Programmer responsibilities
Typically, AR System programmers are responsible for some or all of these tasks:
Writing plug-ins and custom clients that use the AR System C API, Java API, or
Java plug-in API
Integrating external applications with AR System

24 Concepts Guide
Chapter
2 Forms and applications
Forms are the foundation of AR System. Forms can be grouped into applications.
This chapter describes forms and how forms are used in applications. It also
describes localization features for applications.
About AR System forms (page 26)
Using fields in forms (page 29)
Attaching menus to fields (page 32)
Bundling forms into applications (page 33)
Localizing applications (page 33)

About AR System forms

A form captures and displays information. For example, a service desk form
captures information needed to fix a user’s computer problem. A purchase
requisition form captures the information needed to purchase an item. Figure 2-1
illustrates an AR System form.
Each form contains fields. Some fields, known as data fields, capture a certain type
of information, such as a user name or problem details, and have their own set of
rules about who can view or modify that information (see “Using fields in forms”
on page 29). Some fields can have attached menus that help users fill in the form
(see “Attaching menus to fields” on page 32).
Figure 2-1: Example AR System form
Each form in an application is like a template. When a user opens a form to perform
a task, the template is presented to help the user complete the task. When the form
is filled in and submitted to AR System, the system creates a request, also known as
a record in database terms.
26 Concepts Guide
About AR System forms
Users can create, modify, or search for requests if they have appropriate access
permissions (see Chapter 4, “Access control”). Users can also create reports based
on requests that match their search criteria. They can use the AR System native
reporting capability or Crystal Reports, a reporting package that you can integrate
with AR System.
Forms are stored as tables in the database. Each data field on the form corresponds
to a column in the table. A request corresponds to a row (or record) in the table.
Figure 2-2: A form from the view of the database

Field
Help Desk Form (column)
Request ID Submitter Problem Impact Assigned To Status

000056 Adrian Web pages load slowly Low Paul Assigned
Request
(row) 000032 Rachel Printer not working Medium Laura Closed
000019 Cynthia Can't send email High Rob Work in progress
000092 Steve Network is down High Laura Escalated
000018 Hannah Need more memory Medium Paul Closed
Types of forms
You can create the following types of forms, as illustrated in Figure 2-3:
Form type Description

Regular Information submitted through and displayed in regular forms is stored in database tables.
These forms are typically the main forms in applications. They are also called data forms.
Display-only These forms contain display-only fields that enable users to accomplish specific tasks. These
forms are typically used to create control panels, which are launch points from which users
choose other tasks. Display-only forms can also be used to create dialog boxes, which prompt
users as they fill out a form. Display-only forms do not contain data, so no database tables
are associated with them.
Join These forms are composed of fields from two or more existing forms. Join forms are useful
when you have information in multiple forms that you want to display in a single form. Join
forms do not contain data, so they have no database tables associated with them. The data is
contained in the underlying forms that make up the join form.
View These forms enable users to connect to database tables created outside of AR System. These
forms enable you to bring data from other applications that is stored in a database into
AR System without replication or programming.
Vendor These forms enable users to connect to external data sources—such as text files, spreadsheets,
or database tables residing on local or remote servers—through an ARDBC plug-in. Some
programming is required to connect to the data source.

Figure 2-3: Types of AR System forms
Information displayed in regular forms

is stored in AR System database tables.
Regular Form
Field 1
Field 2
Field 3
AR System database
Display-only forms are used to create dialog
boxes, control panels, and consoles. They have
no database table associated with them.
Service Console Display-Only Form
New Request Search Requests
You can merge information from

two forms into a join form. Form
Field 1
Join Form Field 2
Field 3
Field 1
Field 2
Field A Form
Field A
Field B
Field B
AR System
Field C database
View forms are used to connect to database

tables that were not created by AR System.
View Form
Field 1
Field 2
Field 3
Database external to AR System
Vendor forms are used to connect to external

data sources—such as text files, spreadsheets,
or database tables residing on local or remote
servers—through an ARDBC plug-in.
Vendor Form
Field 1
Database external to AR System
Field 2
Field 3
ARDBC plug-in
Other data sources
28 Concepts Guide
Using fields in forms
Form views
A view is a visual representation of a form. To reuse a form for diverse groups
while accommodating each group’s unique needs, you can create a different view
of the form for each group. This enables you to customize the interface of an
AR System application so that each group sees the system as its own.
You can create as many views of a form as you need. For example, you can provide
views customized according to the following criteria:
Users’ roles (requesters, managers, and so forth)
Size of the screen (for example, laptop or desktop)
Language or locale (for example, Brazilian Portuguese)
When creating form views, you can
Change the layout of the form
Use different fields in different views
Tailor views to provide the best result in the target display environment, such
as browsers
Use terminology or language specific to the group using the view

Fields enable you to control how information is captured and displayed in forms.
You can include the following types of fields in forms:
Field type Description

Data Contains data values stored in database tables. You can set these characteristics of data
fields:
Whether users can access the field and, if so, whether they can only view the field or
also change its contents.
The type of data that the field can contain (such as characters, integers, dates, or times).
The amount of information that the field can contain (field length).
Whether the field is visible or hidden.
Whether the field is enabled or disabled.
Whether the field is required, optional, or display-only. (A display-only field is a
temporary field for which no space is allocated in the database.)
Where the field appears on the form.
How the field is displayed (for example, its label and physical appearance).
How information is entered into the field (for example, by typing or by selecting items
from a list or a menu).
The field’s default value.
Whether fields are indexed for faster searches.
Table Displays data from other requests in the context of the current request. Table field styles
are list view, tree view, cell-based, results list, and alert list.

Field type Description

Attachment Attaches files to requests.
View Provides a browser window in a form. The browser can display any URL, HTML
content, or file format (including contents of attachments) that is compatible with a
browser.
Data visualization Augments AR System with HTML-based content—such as web pages, flashboards, and
other graphics—that can interact with the field’s parent form through workflow.
Application list Displays a list of entry points. An entry point is a link that users click to open forms on the
correct server in the required mode (New or Search).
AR System automatically generates the contents of the application list. The entry points
that a user sees in the list are only those to which the user has access.
Any form that contains an application list field can be used as a home page. A home page
is a single point of access into AR System.
Horizontal and Enables users to navigate to the correct screen in an application quickly and easily.
vertical navigation
Control Triggers active links. Control fields include buttons, menu items, and toolbar buttons.
Panel Organizes other fields on forms into smaller containers that can be hidden when not
needed. Panel fields can have various formats, such as tabbed, collapsible, splitter, and
accordion.
Trim Adds boxes, lines, and text to enhance the visual appearance of forms.
You can add as many fields as you need to a form (within the limits of your
database) to capture and display the information required by your application.
You can use workflow to manipulate the attributes of fields. For example, you can
set permissions for a group of trim fields or active link control fields so that they
are inaccessible to certain groups of users, or you can add tabs in a panel field that
are visible to some users (such as managers or support staff) but not to others.
Characteristics common to all fields

All fields in AR System share these characteristics:
They can be disabled (dimmed) or hidden.
They have a unique field ID and field name.
They can be used in workflow.
They can have context-sensitive help associated with them to help users learn
more about them.
Their display properties (including their location on a form and their
appearance) can be changed.
Permissions can be set to specify which users can access them.
AR System automatically records their history, including their owner (the user
who created them), the user who last modified them, and the date and time that
they were last modified.
30 Concepts Guide
Core fields in a regular form

A regular form automatically contains these core fields, as shown in Figure 2-4:
Request ID—Unique tracking number assigned to each request by AR System.
Submitter—Login name of the user who submits a request.
Create Date—Date and time that a request is created.
Assigned To—Person assigned to handle the request.
Last Modified By—User who last modified the request.
Modified Date—Date and time that the request was last modified.
Status—Current status of the request.
Short Description—Brief description of the request.
Status History—Time the request’s status was last changed and who changed
it. This field does not appear in forms. To view the information in this field,
users must display a request and choose View > Status History.
These fields provide basic capabilities that most application designers need. For
more information, see the Form and Application Objects Guide.
AR System has templates for blank forms and forms with core fields. You cannot
delete core fields from a form created with them, but you can hide them from a
user’s view and change their labels, location, and appearance.
Figure 2-4: New regular form with core fields
The following table shows the meaning of the field label styles:
Style Description
Bold Field requires a value—default, user-entered, or from workflow—
when a user submits a request.
Italic Field is automatically populated by AR System.
Plain Field is optional. Users can enter information in it or leave it empty.

Attaching menus to fields

Use menus to help users enter data and to ensure that the data is consistent. You
can attach a menu to any character field (character fields are data fields that hold
alphanumeric characters). Menus can be statically defined, dynamically built by
searching AR System databases and external databases, or read from text files
written by other applications.
Menus are separate objects stored independently of a form. This means that you
can create a single menu and use it for multiple forms and for multiple fields in one
form.
AR System defines these types of menus:
Menu type Description

Character Stored and maintained as a list of items in AR System. These menus
are useful for fields that have a predefined series of choices that
change infrequently. They can have submenus.
File Contains items that are created and maintained in a plain text file. The
file can be stored on the system where BMC Remedy User is running
or on the AR System server. File menus are convenient when you do
not want to store the data in the AR System database. To change a file
menu, simply update the file; the changes are applied when the menu
is refreshed. File menus can have submenus.
Search Retrieves information from requests stored in AR System databases.
The information is used to build a menu dynamically in the current
form. Search menus are often used when the choices in a menu depend
on values entered in fields on the current form.
SQL Also retrieves information from databases, but the databases can be
outside AR System. When you access an SQL menu, AR System uses
an SQL query to extract the data and then generates the menu from
that data.
Data dictionary Retrieves lists of fields and forms from an AR System server. These
menus are useful for creating special configuration interfaces. They
are generally not used to help users perform their work.
32 Concepts Guide
Bundling forms into applications
Bundling forms into applications

An AR System application is a server object that contains references to one or more
forms. When an application references a form, AR System automatically includes
all the workflow and other components (such as menus) associated with the form.
Sometimes a single form can contain all of an application’s functionality. For
example, a small application that tracks product defects can use a single defect-
tracking form to capture and display all required information.
Most applications, however, need several forms to capture, track, and organize
information. One or more forms make up the application’s main forms (sometimes
called primary forms) that users interact with directly. Often, the main form is a
console that serves as a navigation and information center. The application can also
have other forms, called supporting forms, which supply information needed by the
main forms.
You can create the following types of applications:
Deployable applications are designed to be used in multiple server
environments. These applications use permissions based on roles defined in the
application. When the application is deployed, the administrator maps the roles
to groups on the local server. Other features available to deployable applications
include the ability to gather statistics about the application and to map the same
role to different groups for different application states, such as test or
production.
Local applications use permissions based on groups defined on the local server.
Therefore, these applications are usually used on a single server.
For information about groups and roles, see Chapter 4, “Access control.”
Localizing applications
Localization is the process of customizing an application for use in various
languages, countries, and cultures. AR System provides an internationalized
environment for building, testing, and localizing applications.
A locale describes the language, country setting, and other characteristics of the
local system’s user interface. You can create an AR System application to run in a
particular locale, or you can make your application simultaneously available in
multiple locales.

The development environment enables you to localize all aspects of the user
interface:
Language used for labels, messages, help text, reports, menus, and any other
words that are part of a form’s user interface
Separator symbol for decimal numbers that include a fraction
Separator symbol for numbers greater than 999
Format for dates and times
Layout, colors, and images
You can store each localized version of a form as a view. Therefore, the same
application can provide separate user interfaces (views) for British English,
Australian English, Mexican Spanish, and Peruvian Spanish.
NOTE
Although the user interface is tailored to each user’s locale, the data and workflow are
the same for all users. Therefore, you need to agree on the language for the data
before the application is made available.
The localization features are automatic for the user and easy to implement for the
application builder. To localize an application for a given locale, an administrator
need create views only for that locale and add corresponding messages to the
message catalog. Utilities are available to assist with this work. See the Form and
Application Objects Guide.
34 Concepts Guide
Chapter
3 Workflow
Forms, with the help of menus, capture the crucial data needed to run your
business. Processing that data in accordance with your business needs is the
function of workflow. You use workflow components—active links, filters, and
escalations—to enforce business rules in a variety of ways, including notifying
people of events, escalating problems to a higher level, automatically routing
information, and checking whether key data is correctly entered.
This chapter describes the workflow components.
Workflow in general and in AR System (page 36)
How workflow components differ (page 36)
Collections of workflow components (page 38)
Workflow actions and execution options (page 38)
Workflow qualifications (page 44)
For detailed information about workflow, see the Workflow Objects Guide.
Workflow in general and in AR System

In general, workflow can be defined as the set of processes that your company uses
to run itself—for example, tracking defects or administering employee benefits.
In AR System, workflow automates your company’s processes through the use of
active links, filters, and escalations. For example, if your organization decides that
purchase orders for amounts above a certain level need director approval, you can
design workflow that allows only correctly approved purchase orders to be
automatically forwarded to the purchasing department.
You define AR System workflow by specifying the actions that active links, filters,
and escalations should perform under specified circumstances. The circumstances
are called execution options. You can create workflow components for a single form,
or you can share workflow components with multiple forms. (Workflow
components cannot exist independently of forms.)
Some of the actions that workflow components can take to automate processes and
ease data entry include
Overriding user-entered values by changing them to values that you specify
Manipulating a form (for example, enabling or disabling fields, or changing
menus associated with fields)
Checking for errors
Opening new windows for data entry or display
Communicating with users by means of onscreen messages or notifications sent
by email, BMC Remedy Alert, or other methods
Running an active link guide or a filter guide as a subroutine (a predefined
sequence of commands)
For a list of actions, see “Workflow actions” on page 39.
How workflow components differ

This table summarizes how and where you use workflow components:
Component Triggered by Where action is performed

Active link Events Client
Filter Events Server
Escalation Time Server
36 Concepts Guide
How workflow components differ
Events versus time

Filters and active links are triggered by events, such as a user action or a change in
the state of some data. For example, a filter can notify a support manager whenever
a request is submitted with a priority of High or Critical. The submission of the
request is the event. Other events that can trigger filters are updating, deleting, and
retrieving requests. Actions that can trigger active links include opening or closing
a window, displaying a request, clicking a button on a form, pressing Enter when
the cursor is in a field, or selecting a menu item.
Escalations implement time-based business rules. They are triggered by the passage
of time. The trigger (or execution option) can be either absolute time, such as
“every day at 2:00 p.m.,” or a time interval, such as “one hour between escalation
runs.” For example, an escalation can warn a group of users that in one hour their
manager will be notified that a problem has been unsolved for too long.
Client versus server

Active links are executed on the client side in response to actions that users
perform in forms. For example, active links can change how a form looks or
behaves, validate data entered by users, or use data in a form to find other data for
the form.
Unless an active link queries the AR System server for information or runs a
process on the server, it can complete its operation without sending a request to
the server. This capability helps decrease overall network traffic and improves the
performance of an application.
In contrast, filters and escalations are executed on the server. They implement
business rules by examining newly created or changed requests and taking
actions—such as changing data in the request, creating other requests, or sending
notifications—based on the new data and the business rules. For example, if your
business wants to avoid handling purchase orders that are not properly approved,
you can create a filter that stops AR System from processing such purchase orders
after they are submitted to the server and then notifies the requester accordingly.
Actions associated with filters and escalations take place after the transaction is
transferred to the server for processing. Then, processing can return to the client,
where more active link actions can take place.
NOTE
API calls to the server trigger filters but not active links. If a business rule must be
fired on any input (including user input and input from an integrated process
using an API), the business logic must be in both an active link and a filter.
Collections of workflow components

You can collect active links and filters and run them as procedures. These
collections are called active link guides and filter guides.
The workflow components in guides are organized in a processing sequence.
Using guides enables you to give a name to a set of workflow operations that
accomplish a specific task.
In addition, interactive or navigational active link guides can interact with users by
requesting information and then waiting for input. This enables you to create tasks
that guide users through application processes in a way similar to wizards.
Workflow actions and execution options

The basic questions about workflow are “What can I do, and when can I do it?” The
actions that workflow can take are the what, and the execution options are the when.
For example, users could click a button labeled Display My Active Cases to display
a list of all requests assigned to the user.
Figure 3-1: Example of basic workflow
Execution option Action

occurs
User clicks Display My List displays all requests

Active Cases button. assigned to the user.
You can refine execution options by specifying a qualification that must be met
before an action is taken. Qualifications are often required to ensure that workflow
actions apply only to certain requests. In addition, carefully designed
qualifications make workflow components more efficient and powerful. See
“Workflow qualifications” on page 44.
You can specify a primary action and an alternative action. If an operation meets
the qualification, the primary (“if”) action is performed; if not, the alternative
(“else”) action is performed, as shown in Figure 3-2.
Figure 3-2: Example of workflow with qualification
Primary action:
Execution option Qualification: Met First Name, Extension,
occurs Last Name field and Email Address
is filled in. fields are filled in from
a supporting form.
User presses Enter
in Last Name field.
Not met
Alternative action:
Message displays
“Fill in last name.”
38 Concepts Guide
Workflow actions
The following table lists some of the actions that active links, filters, and escalations
can perform. For a complete list, see the Workflow Objects Guide.
Action Description Active link Filter Escalation

Change Field Changes the appearance of fields. For example, a +
Change Field action can perform one or more of
these actions:
Moves the cursor or keyboard focus to a field.
Hides or displays a field. For example, an active
link might hide all fields related to telephone
problems when users report network problems.
Changes a field’s accessibility to read-only,
read/write, or disabled.
Changes the color of a field label or trim text.
Changes the menu attached to a character field.
For example, if a form for scheduling a meeting
has a field for the building, the menu of meeting
rooms attached to the meeting room field might
change to match the specified building.
Refreshes the data in a table field.
Changes the label of a field.
Expands or collapses a collapsible panel field.
Close Window Closes the current window. +
Message Prompts with advice, gives reactive information, + +
warns of a particular situation, or presents an error
message and stops the processing of current
workflow.
Active links execute on the client, so they can
display messages immediately. For example, when
users fill in a particular field, an active link could
warn that a related field must be filled in first.
Active link messages can appear in different
display formats, such as a dialog box, the Prompt
Bar, or a tooltip.
Filters execute on the server, so they are useful for
checking entire transactions and sending error
messages or informational messages. For example,
a filter could display a message indicating that the
support staff has been notified about a problem.
Notify Sends event notifications to users or groups by + +
email, BMC Remedy Alert, or a custom
mechanism, such as a Windows service that pages
users. For example, a filter might notify support
staff when they are assigned a request. Or an
escalation might notify the service department
when an asset warranty has expired.
Action Description Active link Filter Escalation

Open Window Opens a window of any type in the client. The +
action can open a New window and load some
default data. Or it can open a Modify window with
requests matching a specified qualification.
This action can also open a dialog box. Data can be
passed between the dialog box and the window
that calls it. Processing of active links from the
calling window is suspended until the dialog box
interaction is completed.
Push Fields Changes the values of fields in another request to + + +
the values in the current request (that is, it “pushes”
the values from the current request to another
request). This action can also change the value to a
keyword or a function.
You can use Push Fields to set values in related
requests or to create requests that are associated
with the current one. For example, you can use this
action to create multiple work orders for a
telephone connection, a network address, and new
furniture when an employee is hired.
Run Process Runs a separate process (program) on the server for + + +
filters and escalations or on the Windows client or
server for active links. For example, a filter can send
a page, or an active link can launch a browser on a
user’s desktop.
Service Works with an AR System web service to obtain + + +
external services or with a Set Fields filter action to
consume an internal AR System service.
Set Fields Sets fields on a form to specified values. For + + +
example, a filter can automatically set the Status
field to Assigned every time a name is entered into
the Assigned To field.
The value set in a field can be static (always the
same), a keyword value, or a value retrieved from
another data source.
40 Concepts Guide
Workflow execution options

Execution options determine when workflow runs. For active links and filters, you
specify what event triggers the workflow; for escalations, you specify the
execution schedule for the workflow. For all workflow components, you can refine
the execution option by adding a qualifying statement that tells the system which
set of actions to run if the additional criteria are met and which set to run if the
criteria are not met.
Active link and filter execution options

The following table lists examples of execution options for active links and filters.
For a complete list, see the Workflow Objects Guide.
Execution option Description Active link Filter

Button/Menu Field Executes when a user selects the button or menu item +
associated with the active link.
Gain Focus Executes when a user or a Change Field action moves the +
cursor to a field.
Display Executes after a request is loaded into a form but before the +
request appears in the Details pane.
Hover on Field Executes when a user hovers the mouse pointer over a field, +
Hover on Data field data, or a field label. To display tooltips, use a Hover
execution option to trigger a Message action.
Hover on Label
Lose Focus Executes when a user or a Change Field action moves the +
cursor out of a field.
Menu Choice Executes when a user chooses an item from a character menu +
associated with a specified field.
Modify Executes after a user modifies an existing request but before + +
the request is sent to the AR System server (for active links)
or to the database (for filters). An active link with this
execution option does not run during a Modify All
operation.
Service Enables filters to be called by the Service action. +
Submit Executes after a user submits a new request but before the + +
request is sent to the AR System server (for active links) or to
the database (for filters).
Table Refresh Executes when a user updates a table’s contents by loading +
the field, sorting, refreshing, or displaying the previous or
next part (chunk) of the table.
Window Open Executes when a user opens a form or dialog box or changes +
a form to a different mode. This is especially useful for
establishing initial environments. It executes before any data
is loaded into the window.
Execution options and user actions

Some execution options depend on how a user interacts with fields on the form.
For example, if the user does not click a particular button, that active link does not
fire (the user “controls” whether the active link fires). Use “user-controlled”
execution options to provide additional helpful information, such as a list of
nearby printers.
Active links that are not under a user’s control, however, fire whenever the user
finishes a task. That is, if the user follows the normal steps, from opening a window
through closing the window, the active links not under explicit user control always
fire. (Of course, if a user does not submit or modify the request, the active links that
fire on Submit or Modify do not execute.) Use execution options that are not
controlled by users to ensure that consistent, complete data is maintained
regardless of whether users perform certain actions. For example, to guarantee that
every submitted request includes the host name, an active link could retrieve the
host name of the client and copy it into a field in the form whenever a request is
submitted.
Execution order of active links and filters
Active link execution options have an implicit order in relation to one another and
to the interaction between the client and server. You can use this order to control
when the active link runs. For example:
If field values were required for workflow processing before a request is
displayed, you would set them on Window Open. However, to set any values
that you want the user to see when a request is displayed, you would use the
Display execution option.
An active link that runs on Window Open might check the user’s permission to
open a Modify All window and, if the user does not have permission, generate
an error message, preventing the window from opening.
More than one active link or filter can run on the same execution option. In this
case, you can specify the order that you want it to fire in relation to the other active
links or filters. One reason to do so is that the output of one active link can affect
another active link. By carefully ordering a group of active links, you can perform
very complex operations.
When active links and filters are bundled into guides, execution order within the
guides is ignored. Instead, workflow executes in positional order within a guide.
This enables a guide procedure to run without affecting the order of workflow
outside the guide.
42 Concepts Guide
Escalation execution options

In contrast to active links and filters, which react to events, escalations respond to
the passage of time. You can trigger an escalation at a specific time, such as every
Monday at 6 a.m., or at a time interval, such as eight hours after each run of the
escalation.
When the specified time arrives, the server searches for requests in the database
that meet the escalation’s qualification (see “Workflow qualifications” on
page 44). If it finds any, the server runs the escalation’s primary (“if”) actions for
each matching request. If no requests meet the qualification, the server runs the
escalation’s alternative (“else”) actions, if any, once. Figure 3-3 illustrates how
escalations work.
Figure 3-3: How escalations work
Business rule: If a high-priority request is not assigned within 3 hours, notify a manager.
Escalation execution option: Run the escalation every hour on the hour.
Escalation qualification: Priority = High
Assigned = No
Current Time – Create Time >= 3 hours
Escalation primary (“if”) action: Notify manager about problem request.
1 p.m.
Request A Status
Priority = High Request B Status
Escalation runs. Primary action
Assigned = No Priority = High
Submitted 2.5 hrs ago Assigned = No occurs?
Submitted 1.5 hrs ago No
2 p.m.
Request A Status
Priority = High Request B Status
Escalation runs. Primary action
Assigned = No Priority = High
Submitted 3.5 hrs ago Assigned = No occurs?
Submitted 2.5 hrs ago Yes: Manager is
notified about
Request A status.
2:05 p.m.
Manager assigns
Request A to
Yucheng Wong.
3 p.m.
Request A Status
Priority = High Primary action
Escalation runs. Request B Status
Assigned = Yes occurs?
Priority = High
Submitted 4.5 hrs ago Yes: Manager is
Assigned = No
Submitted 3.5 hrs ago notified about
Request B status.
An alternative (“else”) action for the example in Figure 3-3 might be to notify the
manager that all requests comply with the assignment rule. This action would run
only if no requests meet the escalation qualification.
Workflow qualifications
Specifying a qualification when you create an active link, filter, or escalation
enables you to define the data condition that causes the workflow component to
take action. You can use qualifications to check values in fields, the amount of time
that has passed since a specified event occurred, and many other factors. For
example, a qualification might check whether the priority of a request is High or
Critical or whether the day is a weekend day.
Qualifications with active links and filters work differently from qualifications
with escalations:
Active link and filter qualifications control which actions, if any, are run for the
current request. For example, an active link can run actions whenever a specific
field is filled in (execution option), or it can run actions whenever the field is
filled in and the value in the field is invalid (qualification).
Escalations are run whenever the scheduled time arrives. The qualification is an
essential part of most escalations, not simply a refinement. It determines the
requests on which the primary (“if”) escalation actions are run. Without a
qualification, the primary actions are run on every request (record) in the form
to which the escalation is attached. For example, if an escalation simply sent a
notification every hour (execution option), the notification would be
meaningless. A meaningful escalation, however, might check every hour
(execution option) whether three or more hours have elapsed since a request
was submitted and the request is unassigned (qualification), and then send a
notification listing the unassigned requests to a manager. If no requests meet the
qualification, the escalation might specify alternative (“else”) actions that are
executed once, such as sending the manager a notice that all requests comply
with the assignment rule. For an illustration of how qualifications are used in
escalations, see Figure 3-3.
For filters, the qualification can check the value of a field in the database, in the
current transaction, or both. This makes it possible to check whether the value of
the field is changing. For example, if you have a business rule that service desk
requests can be closed only if they have been fixed, a filter could check all
transactions that change the status of a request to Closed. If the database value of
the status is Fixed, the request can be modified; otherwise, the change is not
allowed.
44 Concepts Guide
Workflow qualifications
Keywords in qualifications
Keywords are used to build qualifications. A keyword is a variable whose value is
defined by AR System. Keyword names are uppercase and enclosed in dollar
signs. For example, $USER$ represents the name of the user who is currently
logged in, $TIMESTAMP$ represents the current date and time, and $OPERATION$
represents the operation currently in progress.
Keywords can be used almost anywhere a qualification can be defined or a value
specified:
Defining qualifications for search menus and for workflow. For example,
workflow can check the value of the keyword $OS$ to ensure that the operating
system can run a process that you specify in workflow.
Specifying a value in the Set Fields action.
Defining searches and macros.
For a complete list of keywords, see the Workflow Objects Guide.
46 Concepts Guide
Chapter
4 Access control
Keeping information secure can be a major undertaking in client/server

environments. It is sometimes a balancing act for administrators. You want to
rigorously control who can access data, yet you do not want security to be so
complex that it intrudes on your user community or is difficult for you to
implement or maintain.
AR System enables you to meet these seemingly opposing security goals. It
provides a rich set of features that protect your data from unauthorized access. In
addition, it has a logical, multitiered access control structure that is
straightforward for you to implement and for users to understand.
This chapter describes access control in AR System.
About access control in AR System (page 48)
User and group access (page 48)
Role-based access (page 50)
Multitiered access control model (page 51)
How licensing affects access control (page 53)

About access control in AR System

AR System enables you to control which users can access data and perform certain
actions such as modifying a request or triggering an active link. User access is
determined by these conditions:
The groups users belong to
The licenses users are granted
AR System uses a multitiered approach to control access at these points:
Server
Form (or table)
Field (or column)
Active link and active link guide
Request (or row)
This approach provides a wide range of control over data access, enabling you to
restrict access broadly at the highest levels (server and form) and narrowly at the
request and field levels. Because you can refine your data access criteria so
precisely, you can use a single form for many different purposes simply by setting
the appropriate permissions.
User and group access

Individuals who need to access AR System are registered as users by an
administrator. The administrator then assigns the users to access control groups.
Each access control group is defined for a particular server. An access control
group has permissions that determine whether and how its members can access
application components, such as forms, requests, fields, active links, and active
link guides. (Administrators can also set default permissions for each component
type so that whenever they create a component, selected groups automatically
have access to it.)
Users are assigned to groups according to their need to access information. For
example, you might create a group called Employee Services Staff whose members
are permitted to view and change only certain fields in an Employee Information
form. You might have another group called Employee Services Managers whose
members are permitted to view and change all fields in the Employee Information
form, including salary information.
AR System has predefined groups that perform specific functions (see “Types of
access control groups” on page 49). In addition, you can create any number of
custom groups in AR System to enforce access control. You can also permit
unregistered users to access AR System as guests. Guests are members of the
predefined Public group.
48 Concepts Guide
User and group access
Types of access control groups

This table lists the types of access control groups:
Type of access
control group Description Predefined groups1 Custom groups2
Explicit A group to which you must Administrator Any regular and computed groups that
assign users. Sub Administrator you create.
Customize Regular groups are groups to which you
assign a specific list of users.
Computed groups are groups to which
users are assigned based on their
memberships in groups included in an
expression. For example, you can create
a computed group definition such as
(A AND B) OR C AND NOT D. This
computed group includes users who are
members of both groups A and B, or
members of group C, but not members
of group D.
Implicit A group to which a user Public Any dynamic groups that you create.
automatically (or Submitter Dynamic groups use the contents of
implicitly) belongs by Assignee special fields to determine group
virtue of the contents of membership.
Assignee Group
certain fields in a request.
You cannot assign users to
implicit groups.
All users are members of
Public. You use the other
types of implicit groups to
control access to requests
(row-level database
access).
1
AR System provides these access control groups.
2
You must add these access control groups to your system.
For more information, see the Form and Application Objects Guide.
Additive permissions
Access control in AR System is additive. This means that each user in AR System
starts out with no access permissions. Administrators then add users to access
control groups as needed. In this way, AR System implements strict access control:
administrators must make a conscious decision to add users to groups on a case-
by-case basis.

Membership in multiple groups

Users often belong to multiple groups in an organization. They inherit permissions
from each of the groups to which they belong.
If a group has permission to access a form, field, request, active link, or active link
guide and a user belongs to that group, the user has access, even if the user belongs
to other groups that do not have access.
Figure 4-1: How permissions work
Erin is a member
of three groups.
Graphics Browser Public

Support group group
group
Permission Permission No
to change to view permission
Short Description field
Because Erin belongs to a group with permission

to change the Short Description field on the
Graphics Tools form, she can change the field
even though she belongs to other groups that
do not have change permission.
Role-based access
In deployable applications, access permissions are based on roles. Like groups,
roles have permissions to access forms, fields, active links, and so on. Unlike
groups, however, roles are defined for an application (groups are defined for a
server).
Roles make deployable applications easy to install on a variety of servers. You
assign users to groups and then associate the groups with roles This enables you
to install an application on servers that have different groups without redefining
the application’s object permissions for each server.
NOTE
For simplification, the following sections discuss user access in terms of group
permissions. In deployable applications, which use role permissions, user access is
ultimately determined by which groups are mapped to which roles.
50 Concepts Guide
Multitiered access control model
Multitiered access control model

AR System uses a multitiered (hierarchical) approach to control data access. At
each level in this hierarchy, a user’s permissions are checked. If access is permitted,
a “gate” opens that allows the user to proceed to the next level. If access is denied
at any point except active links and links guides (workflow), the user cannot
proceed. (If access is denied at workflow, the user might be able to proceed, but his
data access capabilities will be limited.)
For example, if a user is denied access to a form, the user cannot see any fields
associated with the form. For another example, a user’s ability to access a request
depends on whether he belongs to a group that has access to the Request ID field.
Figure 4-2: Access control in AR System
Authenticate
user
AR System
server
Validate form
permissions
Form
Last Name
Forms First Name
Email Address
Validate form
element permissions
Active links Name
and active
link guides Fields
Validate request
permissions
Requests

The access control model comprises the following levels:
Access level Description

AR System server Users must pass an initial checkpoint when they start an AR System client, such as a
browser or BMC Remedy User. At this point, users must enter a valid user name, a
password, and, as an option, an authentication string. AR System servers check the user
name, password, and authentication string each time a client requests a transaction,
such as when opening a form or changing a field.
Note: If your AR System server is configured to allow guest users, such users can log in
to the server without a valid user name or password. See the Configuration Guide.
Form As an administrator, you give groups access to forms according to each group’s need to
view or change information in the form. Visible access enables users to access a form from
the Object List. Hidden access makes a form available only through workflow. If a group
is not given access to a form, members of that group cannot view the form or change the
requests that it contains.
Field You can control access to each field on a form, including nondata fields such as trim
fields, table fields, and active link control fields. You can make a field visible to users or
hide the field so that it is accessible only through workflow. For data fields, you also
specify whether a group can only view field information or also change it. If a group
cannot access a field, the field does not appear when members of the group open the
form.
Active link In addition to controlling access to form and field data, you can control access to active
links, which trigger a variety of workflow actions. For example, you might allow
support staff to trigger several active links appropriate to their work but not allow other
users to trigger those active links.
Groups do not automatically have access to the field associated with an active link. You
must grant them access to the active link and to the field. For active links that fire when
users click a button or choose a menu item, the users must have access to both the button
or menu item and the active link to trigger the active link.
Active link guide When you create an active link guide, you specify the groups that have access to it. To
access an active link guide, a user must have permission to each active link in the guide
and to the guide itself. If a user has access to all active links in a guide but not to the
guide, the guide does not appear.
Request You can strictly control who can access requests associated with a form. For example,
you might want only managers to access requests with confidential employee
information. Or you might provide an outsourcing service in which you use AR System
as the central service desk for several companies, and you do not want one company to
see requests from another company.
52 Concepts Guide
How licensing affects access control
How licensing affects access control

Although licensing is not a component of access control, licensing can affect a
user’s ability to perform an operation that you grant her permission to perform.
For example, if a user is a member of a group that has Change permission to a field
but you did not give her the appropriate write license, she cannot change the field.
You can assign the types of user licenses listed in this table:
License Description
Read Enables users to search for and display requests within their assigned permissions.
Administrators can configure the AR System server to enable users with Read licenses to
submit requests and to modify requests that they submit.
Restricted Read Enables users to search for and display requests within their assigned permissions.
Administrators can configure the AR System server to enable users with Restricted Read
licenses to submit requests. But users with Restricted Read licenses cannot modify any
requests, including their own.
It does, however, allow the same login account to access AR System from multiple IP
addresses simultaneously, such as when you browse a knowledge base or complete online
surveys.
Fixed Includes all the capabilities of a Read license, and also enables users (based on the
permissions of the groups to which they belong) to modify and save requests that they did
not submit. AR System administrators and subadministrators must have a Fixed license.
Other AR System users who consistently need to modify requests must also have Fixed
licenses.
A fixed write license is associated with a user name and is always “reserved” for that user.
Users who have a fixed write license can access the AR System server at any time.
Floating Includes all the capabilities of a Read license, and also enables users to modify and save
data for requests that they did not submit based on the groups to which they belong.
Multiple users can use the same Floating licenses, one user at a time: they are available on
a first-come, first-served basis. This type of license is designed for users who occasionally
need to modify and save requests.
A user with a Floating license is temporarily logged in to AR System with a Read license.
When a search, modify, or submit is performed, AR System checks for an available
Floating license. If a license is available, the user is granted write access to requests. If no
licenses are available, the user is notified and continues to use the Read license until a
Floating license becomes available.
Generally, Floating licenses are shared by all AR System users. You can, however, define
license pools to reserve a set of Floating licenses for a group of users. This enables you to
prioritize the availability of Floating licenses. For example, you can allocate a number of
licenses to department managers to make sure that they can immediately approve
essential requests. Users who do not belong to this group cannot acquire any of the
reserved licenses.
An AR System server provides three fixed write licenses and unlimited read and
restricted read licenses. You can purchase additional fixed write licenses and
floating write licenses from BMC or from an authorized reseller.
For more information about licensing, see the Configuration Guide.

54 Concepts Guide
Chapter
5 Extending AR System
The core AR System product—clients (BMC Remedy Developer Studio and BMC
Remedy User), mid tier, and AR System server—is the foundation for the BMC
Remedy product line. Beyond the core environment, BMC offers add-on products
that provide additional services and capabilities. This chapter provides brief
overviews of these products.
In addition, third parties have developed a wide range of products for integration
with AR System. Some of the most popular integration areas are discussed in this
chapter.
AR System foundation products (page 56)
BMC Atrium products (page 57)
AR System–based solutions (page 57)
Other BMC products (page 58)
Integration with third-party products (page 58)

AR System foundation products

These BMC Remedy products add functionality to the core AR System
environment:
BMC Remedy Distributed Server Option (DSO)—Enables you to send and
receive data from forms that reside on physically separate servers. See
“Distributed environments provide scalability” on page 19 and the BMC Remedy
Distributed Server Option Guide.
BMC Remedy Encryption products—Enable the AR System server and its
clients to communicate securely over a network by encrypting the messages sent
between them. Standard BMC Remedy Encryption is built into the BMC
Remedy products. Optional BMC Remedy Encryption Performance and BMC
Remedy Encryption Premium are sold separately. The optional encryption
products provide a higher level of security than standard encryption. They also
enable you to comply with Federal Information Processing Standards (FIPS)
200. All BMC Remedy Encryption products use third-party encryption
technology software developed by the OpenSSL Project for use in the OpenSSL
toolkit (http://www.openssl.org/). See the BMC Remedy Encryption Guide.
BMC Remedy Full Text Search (FTS)—Provides a search mechanism that is
typically much faster than the native database searching functionality for
searching in long text fields. It is also the only search method available in
AR System for searching text within documents attached to requests. See the
Configuration Guide.
BMC Remedy Migrator—Provides a fast, easy way to move forms and
applications between AR System servers, servers and files, or files. This tool
helps you transfer data and workflow objects from a development environment
to a production server, while ensuring the integrity of all migrated changes. See
the BMC Remedy Migrator Guide.
NOTE
For limitations on using BMC Remedy Migrator with other BMC applications, see
the BMC Remedy Migrator Release Notes on the Customer Support website (http://
www.bmc.com/support_home).
56 Concepts Guide
BMC Atrium products
BMC Atrium products

Together, AR System and BMC Atrium Core provide the foundation for BMC
Business Service Management (BSM) solutions.
The following AR System–based BMC Atrium Core components address the best
practices for configuration management. They also support IT Infrastructure
Library (ITIL)–defined processes, such as change and service management.
BMC Atrium Configuration Management Database
BMC Atrium Integration Engine
BMC Product Catalog
The following BMC Atrium applications, though not based on AR System,
provide powerful visualization, decision support, and data discovery capabilities.
They are preintegrated with BMC solutions for BSM and ready to use out of
the box.
BMC Analytics for BSM
BMC Dashboards for BSM
BMC Discovery Solution
For more information, see the BMC Software website at http://www.bmc.com.
AR System–based solutions
The following BMC Remedy solutions for IT service and customer relationship
management are based on AR System:
BMC Remedy IT Service Management (ITSM) Suite—Offers a complete,
integrated solution to technology life cycle management. Its applications
compress business cycles with custom routing of approvals and consistent
enforcement of business rules. The suite includes
BMC Remedy Asset Management
BMC Remedy Change Management
BMC Remedy Service Desk (includes BMC Remedy Incident Management
and BMC Remedy Problem Management)
BMC Service Level Management
BMC Service Request Management—Enables IT to define its services, publish
them in a Service Catalog, and give users self-service options, which reduce the
requests that must be handled by service desk support staff.
BMC Remedy Knowledge Management—Gives call center support staff easy
access to a vast array of information needed to resolve problems.
For more information, see the BMC Software website at http://www.bmc.com.

Other BMC products

Many other BMC products—such as BMC Atrium Orchestrator, BMC Service
Impact Manager, and BMC Performance Manager—integrate with AR System or
applications based on AR System. Together, these products provide a complete
solution to Business Service Management (BSM).
For more information about BSM from BMC, see the BMC Software website at
http://www.bmc.com.
Integration with third-party products

AR System is designed to be used with third-party products to create an integrated
solution. Popular areas in which third parties have integrated their products with
AR System are
Web services
Network and system management
Computer telephony, including automated call distribution (ACD) and
integrated voice response (IVR)
Asset/inventory management
Groupware
Legacy management
Report writers
Remote access
Fax/pager/email
Knowledge bases
Accessibility for disabled AR System users
AR System is an open system with several well-defined interfaces for linking to
other products. For an in-depth discussion about integrating with third-party
products, see the Integration Guide.
For the latest information about products that have been integrated with
AR System, see the Customer Support website (http://www.bmc.com/
support_home).
58 Concepts Guide
Chapter
6 Putting it all together
In previous chapters, you learned about important AR System concepts: forms,

menus, workflow components, and integrations with other products. Now that
you know the pieces of the puzzle, you need to understand how to put them
together to form a useful whole.
This chapter brings those concepts together by showing how a sample
organization—a wild animal park—might plan and design an AR System
application. Like any business, the park needs to take a systematic approach to
automating its processes. This chapter walks you through the planning process
that the hypothetical park staff uses to evaluate and address its business needs.
As you will see, you can create AR System applications to track any kind of asset
allocation or business process. With sufficient planning, even workflow-intensive
procedures can be automatically maintained in an orderly manner.
About the wild animal park (page 60)
Goals of the animal tracking application (page 60)
Planning and design considerations (page 61)
Planning and design decisions (page 63)
Putting the application to work (page 65)

About the wild animal park

For many years, the wild animal park grew successfully with paper-based record
keeping combined with isolated computer-based procedures. Recently, however,
employees noticed a number of redundant or inefficient processes, so the park staff
decided to use AR System to automate the following processes:
Tracking and managing animals associated with the park
Tracking and managing public relations, such as attendance statistics, public
inquiries, membership renewals, and group tour information
Tracking and managing the maintenance of on-site visitor facilities, including
snack bars, restrooms, first-aid stations, and park transit systems
Managing the botanical gardens adjacent to the park
This chapter focuses on the first application, managing and tracking animals.
Goals of the animal tracking application

The park needs to accomplish these goals with the animal tracking application:
Track the type and number of animals grouped together in enclosures.
Track births, deaths, acquisitions, trades, and sales.
Track daily observations of each animal, including behavior and medical
condition.
Track the complete medical history of each animal, including preventive care
such as dental work, vaccinations, and parasite checks.
Track animal feeding.
Immediately alert the veterinary staff about medical emergencies.
Alert the animal handlers if any animal escapes its enclosure.
60 Concepts Guide
Planning and design considerations
All these goals relate to tracking animals throughout their life at the park, as shown
in Figure 6-1.
Figure 6-1: Animal tracking overview
Loss of animals through

trade, sale, or death
Acquisitions or births Care and feeding

of new animals of animals
Planning and design considerations

After defining the application goals, the staff begins more detailed planning. This
section discusses various questions that any organization needs to consider to
create a useful application. The following section, “Planning and design decisions”
on page 63, discusses the answers to these questions.
NOTE
The planning and design process is thoroughly covered in the “BMC Remedy
AR System 7.x: Application Requirements Analysis, Design, and Development”
course offered by BMC. See http://www.bmc.com/education.

Analyzing data
As the park staff members begin to plan their animal management application,
they think about the types of data that they need to capture. They also ask
themselves how this data is stored in their current system (for example, in a legacy
database or in paper forms).
After determining the kind of data that they need to capture and how that data
interrelates, the staff can determine what forms (main and supporting) and fields
need to be created. They also need to decide whether to include menus on the
forms and, if so, which kinds are most appropriate to help staff members fill in
fields.
Analyzing workflow
Next, the staff considers the park’s current organizational processes:
What are the processes?
What are the stages or steps of each process?
Which groups of people participate in the processes?
To manage, access, and track the processes, what information do the groups
need?
Defining business rules

After examining their business processes, the staff members also consider their
business rules, the fundamental policies that govern day-to-day life at the park. The
rules frequently provide the basis for making important decisions. For example,
one of the rules might be that every animal must be checked by a veterinarian
within 24 hours of arrival. If the rule is broken, that might indicate a need to hire
more medical staff or to increase clinic capacity.
Questions about business rules include
What conditions and events require decisions and actions?
What should happen when various conditions or events occur?
What is the flow of information through the existing systems?
Mapping business rules to workflow components

Next, the park determines how to translate its business workflow (rules and
processes) into AR System workflow components:
Which processes can be accomplished by using active links?
When would it make more sense to use a filter?
What types of escalations are needed to enforce business rules? For example,
an escalation might be used to enforce the rule that animals must be checked by
a veterinarian within 24 hours of arrival.
62 Concepts Guide
Planning and design decisions
Considering integrations
The staff considers what other software products or databases must initially be
integrated into the application and what future integrations are desirable:
The staff must be able to enter data while they are out in the park, perhaps using
handheld devices.
Future integration with a sister zoo must be possible.
Integration with an international database of endangered species is also
necessary, partly to locate new individual animals that can contribute to the
gene pool at the park.
Eventually, the staff might want to integrate information about the botanical
gardens at the park, although this could be maintained separately.
Planning and design decisions

Based on their research, the park staff makes the following decisions about the
types of forms needed to capture data, the groups of people that must use
AR System, and the workflow components that they would put in place to
automate their processes.
Decisions about forms

The staff determines that they need these forms (shown in Figure 6-2 on page 64)
to capture information:
Animal form—Contains detailed information about each animal. The staff
considers using panel fields to organize the form modularly, keeping related
fields together.
Species Info form—Contains details about a particular species, such as feeding
requirements, life span, medical needs, and whether it is endangered. This is a
supporting form.
Feeding form—Contains information about each animal’s feeding schedule.
Enclosure form—Contains information about the number and types of animals
each enclosure can hold and so forth.
Medical History form—Contains the complete medical history of each animal.
Former Resident form—Contains information about animals that no longer
reside in the park.

Figure 6-2: Forms for animal tracking application
Species Info Form

A
B Feeding Form
C A
D B
C
Enclosure Form
Medical History Form
A
A
B
B
C
C
Animal Form
D
A
B Former Resident Form
C A
D B
C
Decisions about access control

Some of the AR System groups or roles that the park needs are
Veterinarians, who provide health care for the animals.
Animal handlers, who provide day-to-day care for the animals.
Curators, who handle acquisitions and transfers.
Horticulturists, who maintain the animals’ naturalistic habitats.
Researchers, who conduct animal-related studies.
Appropriate permissions will be assigned to each group or role according to the
information that they need to access.
Decisions about business rules

Business rules for the park include
Animals will be not be kept in temporary enclosures longer than 48 hours.
Specially trained animal handlers will be notified immediately if a dangerous
animal escapes.
Every animal must be checked by a veterinarian within 24 hours of arrival.
64 Concepts Guide
Putting the application to work
Decisions about workflow components

Some of the workflow components that the park needs are
A filter to notify animal handlers whenever an animal needs to be moved.
Active links that help users fill out forms.
An escalation to notify keepers when an animal has not been fed within one
hour of its scheduled feeding time.

After the planning and design process, the park develops an application that
covers its diverse requirements. When staff members begin using the application,
they note which features work well and which ones need adjustment. Developers
make changes to the application based on that feedback.
Each of the following scenarios illustrates a complete process, but not every
component of the process is discussed in detail. For example, enough detail might
be given about the function of one workflow component to enable you to make
assumptions about other components.
A tiger is acquired
As shown in Figure 6-3 on page 66, when a Sumatran tiger named Karuna is
obtained, a staffer fills in the Animal form, and then clicks a button called List
Enclosures. An active link opens a dialog box displaying the Enclosure form with
a table field that lists enclosure information, including availability and habitat. The
staffer can double-click any enclosure in the list to get more information.
Next, the staffer selects an appropriate choice—in this case, enclosure 16—and
submits the request. A filter notifies the Animal Handlers group and sends a
message to inform the staffer that the appropriate persons have been notified. In
addition, the Status field changes from New to Move Pending.
During trial runs of the system, the application developer realizes that the animal
handlers are frequently away from their computers and rarely check email. The
developer integrates the application with a paging program and has the filter
notify the handlers about new animals with a page. Handlers can then use their cell
phones to get information about their assigned tasks.
Gary from Animal Handlers receives a page that says a new tiger must be moved
from the temporary cages to enclosure 16.
After he transfers the tiger, Gary changes the Status field from Move Pending to
Permanent. When he saves his changes, workflow components create new
requests in related forms and notify the Veterinarian group and the Animal
Handlers group to begin the care and feeding of the new animal. These requests
and notifications illustrate one way of handling work orders in AR System.

Figure 6-3: Active link and filter in the animal tracking application
1
Dialog Box
Enclosure Form
Animal Form
Number Status Habitat
Name Karuna Active Link 4 Full Waterhole
lists all enclosures
Type Sumatran Tiger and their capacity. 5 Full Steppe
Status New List 16 Available Jungle
Enclosures
Assigned to 16 20 Available Steppe
Enclosure
Cancel Continue
3
User submits 2
request.
User chooses Enclosure 16,
clicks Continue, and "16" is
entered.
Filter
Action 1.
Notify Animal Handlers group via email:
"New Sumatran tiger must be transferred
to Enclosure 16."
Action 2.
Notify Submitter: "Animal handlers have
been informed of tiger’s arrival."
Similar process, different application

This process is similar to moves, adds, and changes (MAC) in an employee services
application.
66 Concepts Guide
The tiger is injured

One morning when the keepers are making their daily rounds, they notice that
Karuna has been injured, so they notify the veterinarians. A veterinarian looks at
the Animal form and checks a table field that contains data from the Medical
History form, as illustrated in Figure 6-4. She discovers that Karuna has no history
of serious injury or illness.
To be treated, Karuna must be tranquilized and moved to the veterinary hospital
for surgery. He has been tranquilized before without incident as indicated by the
Tranquilizer Notes field on the Animal form, so the veterinarian computes the
dosage and sets out with several animal handlers to bring in the tiger.
Figure 6-4: Table field in the animal tracking application

Animal Form Name
Name Karuna Reason
Tranquilizer Notes Standard dosage Date Tranquilized?
No side effects
Description
Reason Date Tranq.? Desc.
Injury 1/5/97 Y Leg Vet Drugs used
Checkup 6/17/97 N Regular Vet's Note
Surgery 10/4/98 Y Dental
During the prototyping phase, staffers had to open the Medical History form
separately to learn about Karuna’s record with tranquilizers. The veterinary staff
pointed out that they wanted that important information readily available during
an emergency. So the Tranquilizer Notes field was added to the Animal form, and
a filter that executes on Submit was added to post a message to the veterinarians,
reminding them to update the Tranquilizer Notes if necessary.

This process is similar to handling a customer call in a technical support
application. The technical support representatives might decide that they need
important information about a customer on a main form rather than on a
supporting form.

The tiger is traded to another zoo

After several years, the animal park determines that it should have a different male
tiger to maintain genetic diversity in its tiger population. By examining a database
maintained by zoos worldwide, the staff discovers a tiger that is available and has
no common ancestors with Karuna or with the park’s female tigers. They decide to
trade Karuna, and a staffer changes Karuna’s status from Permanent to Trade
Pending, thereby triggering the same notification filter that was used when
Karuna arrived. This time, it notifies the animal handlers to move Karuna to a
temporary cage, as shown in Figure 6-5.
Figure 6-5: Notifications in the animal tracking application
Main Form
Animal Form
User changes Status
Name Karuna to "Trade Pending"
and submits request.
Type Sumatran Tiger
Status Trade Pending Action 1.

Notify Animal Handlers group via
pager: "Karuna must be transferred
to temporary cage."
Action 2.
Notify Submitter: "Animal handlers have
been informed of tiger's transfer."
68 Concepts Guide
After Karuna leaves the park, his status is changed to Traded. When the changed
request is submitted, a filter uses a Push Fields action to move all of Karuna’s data
from the Animal form to the Former Resident form, as shown in Figure 6-6.
Figure 6-6: Push Fields action used in the animal tracking application
User changes Status

to "Traded" and
submits request.
Main Form Main Form
Animal Form Action: Former Resident Form

Push Fields
Name Karuna Karuna Name
Type Sumatran Tiger Sumatran Tiger Type
Status Traded Traded Status
Supporting Form All medical history

stays "current" rather
Medical History Form than being archived.
Name Karuna

Name Karuna

Name Karuna
The Medical History form is not archived or changed because the staff might, at
any point, want information from the medical records. For example, they might
want information about all tiger surgeries performed at the park.

This process is similar to retiring an asset in an asset management application: you
need to track the problem history of an asset during its active use and after its
retirement.

70 Concepts Guide
Glossary
access control administrator default

An AR System security feature used to limit The value that AR System developers assign
the access that users have to forms, to specific to a field when designing a form. Users can
fields or records in a form, to workflow, and to override the administrator default by
specific functions in the system. See also assigning their own default or by entering a
group, permission, role, user. different value. See also user default.
access point Administrator group
A form or guide in an application that is used One of several special access control groups
as an interface to other applications or that AR System provides. Members of this
workflow, such as in Push Fields or Call group have full and unlimited access to
Guide actions. When creating workflow that AR System, including unlimited ability to
references forms and guides, a developer can create definitions and to access and modify
identify access points. data. See also explicit group, Sub Administrator
active link
group.
A workflow component that causes an advanced search bar
AR System client to perform specific The row of buttons, the Search Criteria field,
operations in response to specific user actions. and the Fields menu list that appear at the
Active links are generally employed to help bottom of the Details pane when users click
users interact with the system. They run on the Advanced search button in a browser or in
the client computer or on the mid tier. BMC Remedy User. Use this bar to specify
active link guide
complex search criteria.
An ordered sequence of active links that alert
accomplishes a specific operation. Active link A message from an AR System server or other
guides can lead users through a task (like a program to notify a user that certain events—
wizard) or can be used as subroutines to such as a request being submitted or progress
accomplish common tasks. See also filter guide. being made in resolving a request—have
administrator
occurred. You can use BMC Remedy Alert, an
An individual responsible for the optional Windows program, to notify users
management of AR System, including when they receive alerts
installing AR System software and alert list
maintaining AR System by adding and The list of alerts belonging to a user. The list
deleting users, groups, and roles; backing up can be displayed in a browser or in
AR System servers; importing data from other BMC Remedy User.
systems; and so on.
Glossary 71
allowable currency type AR System database connectivity (ARDBC)

A currency type that appears in the currency A mechanism by which the AR System server
field menu. Users can use only allowable uses a plug-in to access data stored outside the
currency types when entering currency AR System database as if it were in
values. See also currency data type, functional AR System.
currency type. AR System external authentication (AREA)
API A mechanism by which the AR System server
See application programming interface (API). can access and use authentication services
application from outside the AR System environment. A
A group of forms and associated workflow plug-in is used to access the external
related to a business function, such as subsystem.
Employee Care or Service Desk. An AR System ODBC driver
application is a server object in BMC Remedy A connectivity solution that enables
Developer Studio. See also deployable AR System to communicate with ODBC
application, local application. (Open Database Connectivity) clients. ODBC
application list field is an SQL-based communication standard
A field that displays entry points. See also developed by Microsoft.
entry point, entry point guide, form entry point, AR System server
home page. The AR System program that processes all
application programming interface (API) data entered by a client. The AR System server
A set of functions or classes that provides is the workflow engine between client and
application programmers with access to the database. It also verifies that a user has
full functionality of a product. The AR System permission to perform each action, thereby
C API is documented in the C API Reference, enforcing any access control defined in an
and the Java API is documented in the Java application.
API HTML documentation. ARDBC
application state See AR System database connectivity (ARDBC).
The development state of a deployable AREA
application, such as Test or Production. Roles See AR System external authentication (AREA).
can be mapped to different groups based on Assignee group
application state to limit access to the One of several special access control groups
application during testing or modification. that AR System provides. The user whose
See also deployable application, group, role. name is in the Assigned To field of a request
AR System automatically belongs to this implicit group
See BMC Remedy Action Request System for that request. See also Assignee Group group,
(AR System). dynamic group, implicit group, Submitter group.
AR System client Assignee Group group
The AR System programs that enable users to One of several special access control groups
access an AR System server. AR System that AR System provides. If the Assignee
clients include BMC Remedy Developer Group field in a request contains a user name,
Studio, BMC Remedy User, the web client that user is automatically a member of this
(mid tier), BMC Remedy Data Import, and group for that request. If the Assignee Group
BMC Remedy Alert. field contains a group name, all users in that
group are automatically members of the
group. See also Assignee group, dynamic group,
implicit group, Submitter group.
72 Concepts Guide
Glossary
attachment data type BMC Remedy Mid Tier Configuration Tool

The data type used for fields that hold files. The tool used to configure and manage the
This type enables you to store text, graphics, mid tier portion of AR System. See also mid
audio, or video attachments in the database. tier.
attachment pool field BMC Remedy User
A field that contains one or multiple related The AR System client in which users enter and
attachment fields associated with a request. track requests through the resolution process.
BMC Remedy Action Request System (AR System) Users can also search the database, generate
Adaptable client/server software that reports, and modify existing requests.
provides a foundation for creating (Alternatively, the mid tier enables you to
applications that can automate, track, and perform these tasks in a browser. See mid tier.)
manage a wide variety of business processes. broadcast operation
BMC Remedy Alert A distributed operation in which one source
The AR System client through which an alert server simultaneously transfers data-only
can be sent to a user. See also notification. copies of requests to two or more target
servers.
BMC Remedy Approval Server
A module in AR System that routes forms to button field
generate the appropriate signoff signatures. A field on a form that a user can click to
This module also creates an audit trail for execute an active link. A button, image, or
authorizing AR System application forms. hyperlink can represent a button field. See
also toolbar button.
BMC Remedy Data Import
The AR System client tool used to transfer chained operation
data records from an archive file into a form. A distributed request operation in which one
source server transfers a request to a target
BMC Remedy Developer Studio server, and the target server in turn transfers
The AR System client used by AR System the request to another server. This operation is
developers to develop applications. Use this used in environments containing three or
client to create and change object definitions more servers.
and to set access permissions that determine
which users and groups can view or modify change flag
each form or specific parts of a form. A status flag set when the contents of a field or
form are altered. A change flag can be polled
BMC Remedy Email Engine or disabled by workflow.
A server-based module provided with
AR System that communicates with both the character data type
AR System server and an email server. Email The data type used for fields that contain
Engine receives email messages and can parse alphanumeric text.
and interpret the messages to execute specific character field
instructions on an AR System form. It also An AR System data field that holds
sends email messages to AR System and alphanumeric characters. You can attach a
directs notifications as a result of filters and menu or a file system browser to character
escalations. fields or fill them with default text.
BMC Remedy Flashboards character menu
A real-time visual monitoring tool that can A menu that provides assistance with filling
show the state of service operations, warn in values for a field. A character menu can be
about potential problems, and collect and attached to any character field. See also
display trend data. dynamic menu.
Glossary 73
client Customize group

See AR System client. One of several special access control groups
client tier that AR System provides. This group grants
The architectural level in which AR System users the right to customize their form layout
clients operate in the multitiered system. in BMC Remedy User. See also explicit group.
command-line option data field
A parameter used to specify an operation or A field that stores data in the database. Data
option to AR System programs and utilities fields include character, date, time, date/time,
when they are run. diary, integer, real, decimal, selection,
attachment, and currency.
computed group
An explicit group whose membership is based data-only copy
on the memberships of other explicit groups. In a distributed environment, a read-only
See also explicit group, group. copy of a request that is not part of an active
ownership chain and cannot create a new
container ownership chain. See also independent copy,
The underlying data structure for guides and ownership chain, distributed server.
applications. A component of AR System
used to store collections of objects. Used as the data tier
basic storage structure for applications, active The architectural level that contains data and
link guides, filter guides, and packing lists. communicates with the AR System server.
The data can be stored in a text file,
control data type spreadsheet, or database that is part of or
The data type for fields that execute active separate from AR System.
links. These fields do not contain data.
data type
control panel The property of a field that determines the
A form used as a centralized entry point from characteristics of the field and what type of
which users choose the business tasks they information (if any) the field can contain.
want to accomplish.
data visualization field
core field A field that provides a way to augment
One of a set of basic fields common to all AR System with HTML-based content—such
AR System regular forms. These fields cannot as web pages, flashboards, and other
be removed from a regular form. graphics—that can interact with the field’s
currency code parent form through workflow.
The three-letter code that represents a date data type
currency type, such as USD for United States The data type used for fields containing date
dollars. values. Date values can range from January 1,
currency data type 4713 B.C.E., to January 1, 9999 C.E. Date
The data type used for fields containing values are stored as the number of days from
currency data. Currency data is stored in four the beginning of the date field’s range. For
parts: a decimal value, a currency code, a example, January 1, 2009, is stored as the
conversion date, and one or more functional number 2454833 because it is 2,454,833 days
(converted) currency values. Each part can be after the first day in the date range. See also
viewed or searched by users or accessed by date/time data type.
workflow. See also allowable currency type,
functional currency type, currency code.
74 Concepts Guide
Glossary
date/time data type distributed delete

The data type used for fields containing date/ A distributed operation that removes a
time timestamp values. Values can range from request from AR System. In a distributed
January 1, 1970, to January 17, 2038. See also environment, a copy of a request can be
date data type, time data type. deleted on one server if the master copy is
decimal data type deleted on another server. See also Distributed
The data type used for fields containing fixed- Server Option (DSO).
point numbers. distributed fields
default Fields that can be added to an AR System
See administrator default, user default. form to manipulate certain mapping controls.
The number and type of fields added to a form
default mapping are determined by the mapping type selected.
The mapping selected by Distributed Server See also Distributed Server Option (DSO).
Option if AR System finds multiple mappings
that apply to the specified transfer criteria. distributed mappings
Objects on a DSO server that enable users to
deployable application specify how data from one form is transferred
An application that uses permissions based on to another. Users specify the forms and fields
roles and that is easily portable to other involved, how frequently updates are
servers. See also application, local application, processed, the return values, if any, and how
role. conflicts in distributed operations are
Details pane resolved. Distributed mappings are used with
The part of the main window in a browser or DSO filter and escalation actions. See also
in BMC Remedy User that displays fields for Distributed Server Option (DSO).
entering or viewing data. distributed operation actions
Developer Studio Operations that control the action taken when
See BMC Remedy Developer Studio. filter or escalation criteria are met in a form.
dialog box See also distributed delete, distributed return,
A window displayed to users that must be Distributed Server Option (DSO), distributed
responded to before users can continue filling transfer.
out a form. To create a dialog box, use an distributed pools
active link action. Objects on a server that enable interrelated
diary data type operations of pending requests to occur in the
The data type used for a field in which you can correct order, especially during periods when
capture a history of the actions taken for a the rate of incoming requests exceeds the
request. The field stores character data. It is an processing rate. See also Distributed Server
append-only field, and each addition is Option (DSO).
stamped with the time, date, and name of the distributed return
user who enters it. A distributed operation that returns the latest
display-only field copy of a request with ownership to the
A temporary field for which no space is requesting server. See also Distributed Server
allocated in the database. See also global field. Option (DSO).
display-only form distributed server
A type of form containing display-only fields. An AR System server that exists within a
Display-only forms are used to create control multiserver, distributed environment. See
panels and dialog boxes. also Distributed Server Option (DSO).
Glossary 75
Distributed Server dynamic menu

The name of the user performing all A menu populated at run time when users
operations for DSO. See also Distributed Server click a search menu icon. The source of the
Option (DSO). menu items is determined by values in other
Distributed Server Option (DSO) fields on the form on which the menu appears.
An AR System server component that sends See also search menu.
and receives data from forms on physically email engine
separate servers. DSO requires a separate See BMC Remedy Email Engine.
usage license. See also distributed server. entry
distributed transfer See request.
A distributed operation that transmits entry point
information from one server to another. In a A link on the home page that users click to
distributed environment, a request can be start a task (such as creating a request) or to
transferred to one server when it is created or open a console (such as AR System
modified on another. The transfer can include Administration Console). See also entry point
the entire request or just specific data. See also guide, form entry point, home page.
Distributed Server Option (DSO).
entry point guide
distributed update An entry point that starts a guide so that a user
A distributed operation that refreshes a copy can complete a task. See also entry point, form
of a request on one server when the master entry point, home page.
copy on another server is modified. See also
Distributed Server Option (DSO). escalation
A workflow component that searches at
duplicate request IDs specified times or intervals for requests
Matching request IDs that occur in a matching certain criteria and that performs
distributed operation when a request specified operations on the matching requests.
transferred from the source server has the Escalations are generally used to find records
same request ID as a request on the target that have violated business rules or processes
server. Distributed Server Option provides and then to take the appropriate action. They
several ways to handle this issue. See also run on the AR System server.
request ID.
event
dynamic group An occurrence in AR System that can trigger
One of several special access control groups other events or workflow. Examples include
that developers can create in the Group form user interactions with a form (such as opening
by using a group ID from 60000–60999. If a windows, tabbing from field to field,
dynamic group field (a field whose field ID is switching row focus, and so on), state
the same as the dynamic group ID) contains a transitions of requests, or any condition that
user name, that user is a member of that arises while a request is manipulated.
dynamic group. If the dynamic group field
contains a group name, all users in that group explicit group
are members of the dynamic group. If it A group to which users are assigned or that is
contains a role name, all members of the groups computed from other groups, such as
mapped to that role are members of the Administrator and Customize. See also
dynamic group. See also Assignee Group group, computed group, group, implicit group.
group, implicit group, role.
76 Concepts Guide
Glossary
export filter guide

1. The BMC Remedy Developer Studio An ordered sequence of filters that
command that writes definitions of objects— accomplishes a specific operation. Filter
such as forms, filters, active links, and mail guides can be used as a subroutine to
templates—to a file. 2. To write object accomplish common tasks. See also active link
definitions to a file by using BMC Remedy guide, filter.
Developer Studio or the export command-line fixed license
interface. 3. To write data entries to a file by A license permanently assigned to a user,
using the reporting feature in BMC Remedy enabling the user to access the licensed feature
User. See also import. at any time. See also floating license, write
field license.
The main component of an AR System form. floating license
AR System field types include data, table, A license temporarily allocated to a user who
panel, active link control (buttons, menu requests a license and who is designated as a
items, and toolbar buttons), attachment pool, floating license user. If no floating license is
view, and trim. available at the time of the user request, the
field ID user must wait until one becomes available.
An integer that identifies a field throughout See also fixed license, write license.
AR System. Every field in a form must have a form
field ID that is unique in that form. Field IDs A collection of fields that represents a request
can be assigned manually by AR System in AR System. AR System developers can
developers or automatically by AR System. define and change the fields and workflow
After a field ID is assigned, it cannot be associated with a form. An AR System
changed. application can include many forms. In
field label AR System APIs, forms are called schemas. See
A name that describes a field’s purpose. also request.
Intended to be displayed to users. form action field
field name One of a set of special fields that perform
A unique character identifier assigned to each predefined operations in browsers for Web-
field. The name can be changed at any time as based applications. The fields include Submit,
long as the new name is unique. Query, Modify, and the Search Bar.
file menu form entry point
A menu with items retrieved from a text file An entry point that opens a form in a
containing a formatted character menu. particular mode, such as Search or New, so
filter that a user can complete a task. See also entry
A workflow component that tests every server point, entry point guide, home page.
transaction for certain conditions and form view
responds to the conditions by taking specific The screen layout for a form that appears in
actions. Filters are generally used to check and the Details pane of a browser or BMC Remedy
enforce business rules and processes. They User. AR System developers can create and
run on the AR System server. name multiple form views, which can be
filter API further modified by users in the Customize
An AR System plug-in API that enables in- group. Developers can include or hide
line access during filter and escalation different fields in various form views, and
processing to extended servers. See also plug- they can create form views for particular
in. locales or user roles.
Glossary 77
FTS Group form

See full text search (FTS). The form in which you can create, modify, and
full text search (FTS) delete explicit groups and assign floating
A search mechanism that is typically much licenses to them. See also explicit group, license.
faster than the native database searching guest user
functionality for searching in long text fields. Unregistered user with a limited set of
It is also the only method available in capabilities (can submit and possibly review
AR System for searching text within requests). An administrator can specify
documents attached to requests. whether unregistered users are allowed at
function your site.
A named procedure that performs a distinct GUID field
operation in AR System. The AR System C A field that is automatically populated with a
API has a set of functions used to accomplish globally unique identifier (GUID) when a
AR System tasks. Additionally, AR System request is saved.
contains table functions that you can use in guide
workflow to perform mathematical See active link guide and filter guide.
operations on table data.
hidden field
functional currency type A field on a form that is not visible to a user.
An alternative currency type to which the
value in a currency field is converted. Values home page
for functional currencies are calculated A form that lists entry points. The entry points
according to currency conversion ratios are displayed in an application list field. In
maintained in a form on the server. Functional BMC Remedy User, the home page form can
currency values are stored as part of the data be configured to open on user login by
in the currency field. Users can search for and default. In browsers, users enter or click a link
view them. Workflow can access them. See to a home page URL. See also entry point,
also currency data type, allowable currency type. application list field, entry point guide, form entry
point.
global field
A display-only field whose value is the same image object
across all forms that contain the field as long An image stored in the AR System database
as the user is logged in. See also window-scoped along with information defining the image as
global field. an AR System object. If you use the same
image in more than one location, such as the
group background for a related set of forms, you
A category in AR System used to define user store the image once as an image object and
access to form fields and functions. then include it by reference in form view and
AR System defines several special groups: field display properties.
Public, Administrator, Sub Administrator,
Customize, Submitter, Assignee, and implicit group
Assignee Group. You can define additional A group to which users are automatically
groups through the Group form. See also assigned according to the contents of certain
access control, explicit group, implicit group, fields in a request, such as Submitter and
computed group, dynamic group, permission, role, Assignee. See also dynamic group, explicit
user. group, group.
78 Concepts Guide
Glossary
import macro bar

1. The BMC Remedy Developer Studio The row of buttons below the menu bar in
command that transfers object definitions BMC Remedy User that provides easy access
from an export file to the current server. 2. The to commonly used macro commands. Macro
BMC Remedy Data Import command that commands are also available from the Tools
transfers one or more data entries from an menu.
archive file to a form. See also export. mail template
independent copy A template used to submit a request by email.
In a distributed environment, a modifiable The export command can be used to generate
copy of a request that is not part of the active templates from an existing form.
ownership chain. See also date data type, main form
ownership chain, distributed server. A form that users interact with directly. An
integer data type application can have more than one main
The data type used for fields that contain form. Main forms are sometimes called
numeric values from –2147483647 to primary forms or consoles.
2147483647. The range for a field can be main window
limited by an AR System developer. The BMC Remedy User window that displays
join form a form in the Details pane and, optionally, the
A type of form that contains information from results of a search in the Results pane and
two or more AR System forms. Although join prompt text in the prompt bar. The main
forms function similarly to regular forms, they window includes a menu bar and optional
do not store data. A join form references data status bar, toolbar, and macro bar.
stored in the forms used to create the join mapping
form. The parameters for a particular distributed
keyword operation, such as To and From servers and
A variable whose value is defined by forms, data control issues, and field-to-field
AR System. For example, $USER$ represents mapping definitions. See Distributed Server
the name of the user currently logged in. Option (DSO).
Keywords can be used in qualifications for mapping history
searches, search menus, workflow, and A history tracking record created when a
macros or to specify a value in the Set Fields distributed operation occurs. This record
action for active links, filters, and escalations. includes the date and time of transfer, source
license request ID, source form, source server, and the
See fixed license, floating license, read license, mapping name.
restricted read license, write license. master copy
local application The copy of a distributed request that
An application that uses permissions based on currently has ownership.
groups and that is intended for use on a master flag
limited number of servers. See also application, A Yes/No flag indicating whether a
deployable application, role. distributed request is the master (has
macro ownership).
A set of operations in BMC Remedy User
recorded for later execution. Macros are
useful for automating frequently used or
complex operations.
Glossary 79
mid tier packing list

A component of AR System consisting of add- A set of associated server objects that can be
in services that communicate between viewed as a work space in the server window
AR System servers and various clients. or used in external utilities.
BMC Remedy User can communicate directly page field
with AR System servers. Browsers, however, See panel field.
must use the mid tier to communicate with
AR System servers. panel field
A type of field that acts as a container in which
navigation field related fields can be grouped. A panel field
A field that enables users to navigate through can stand alone or be managed by a panel
screens in an application quickly and easily. holder field. In previous releases, called a page
notification field. See also panel holder field.
A message to a user from workflow. panel holder field
Notifications can be sent by various A field that contains one or more panel fields.
mechanisms, including alerts and email. See Panel holders enable groups of fields to be
also alert, email engine. organized and displayed in the same area of a
object modification log form. They manage various panel layouts,
A feature of the AR System server that logs all including tabbed, collapsible, splitter, and
changes made to an object and that can save a accordion. See also panel field.
copy of an object in a definition (.def) file pending operation
each time that the object is changed. A distributed operation waiting to be
object reservation performed. Pending operations typically
A feature of the AR System server and BMC occur because a specified transfer interval has
Remedy Developer Studio used to prevent not yet been met or because network or
others from modifying objects that are in use. server-related problems exist in the
ODBC distributed environment. See also Distributed
See AR System ODBC driver. Server Option (DSO).
operator permission
A function that is used to define advanced The property setting that controls who can
searches or to build qualifications. view and change individual fields on a form
and who can access certain types of objects,
ownership including active links, active link guides, and
In a distributed environment, the ability to applications. See also access control, group, role,
update copies of a request that are in the user.
ownership chain. Ownership can be
transferred from the original request to a plug-in
copy, and ownership can be returned. See also An auxiliary program that works with the
distributed server. AR System server to enhance its capabilities.
A plug-in is a dynamically linked library
ownership chain (DLL) on Microsoft platforms, a shared library
In a distributed environment, a series of on UNIX platforms, or a Java archive (JAR) on
requests representing a history of transfers all platforms. The plug-in server loads
from a master copy of an original request and plug-ins at run time.
updates to the original request. See also date
data type, independent copy, distributed server.
80 Concepts Guide
Glossary
plug-in server request

A server that loads and executes plug-ins. The A collection of information that describes
plug-in server is a companion to the something, such as a user, a problem, or a
AR System server. It loads the ARDBC, service. When a form is filled in and submitted
AREA, or filter API plug-ins at run time. to AR System, the system creates a request. A
pools request is equivalent to a record in the
See distributed pools. database. In AR System APIs, requests are
called entries. See also form.
preference server
An AR System server that stores user request ID
preferences centrally in the AR System User A unique identifier generated by AR System
Preference form. for each request. See also Request ID field.
prompt bar Request ID field
The part of the main window in BMC Remedy A core field on a form that contains the request
User that displays instructions or useful ID. In join form entries, the Request ID field
information about the form it is attached to. contains the request ID for each of the
underlying forms, separated by a vertical bar.
Public group
One of several special access control groups reserved field
that AR System provides. Every user is A data field that has a predefined special
automatically a member of this group. purpose in AR System. If you add a reserved
field to a form, the field retains its special
qualification behavior and use.
A filter or search criterion including field
references, values, and arithmetical and restricted read license
relational operators used to determine how to A license that allows users to search
process a request or to find a set of data. AR System forms and submit requests but
does not allow users to modify requests under
query-by-example (QBE) any condition. It does, however, allow the
A method for visually describing a database same login to access AR System from multiple
search. An empty form is displayed, and the computers simultaneously. See also read
search conditions are entered in their license.
respective fields. AR System turns the visual
query into the command language, such as results list
SQL, required to query the database. A list of requests that match a search. Multiple
rows (or requests) in the results list that meet
read license specified criteria can be selected for further
A license that allows users to search processing.
AR System forms and to submit requests but
not to modify requests. See also restricted read Results pane
license, write license. The part of the form window in a browser or
in BMC Remedy User that displays the results
real data type of a search.
The data type used for fields that contain
floating-point numbers. The range and return
precision can be set by AR System developers. See distributed return.
regular form return mapping

A form used to manipulate and display data. In a distributed environment, the field-to-field
Regular forms and their contents are stored in mappings used when a request is returned.
database tables created, owned, and managed See also Distributed Server Option (DSO).
by the AR System server.
Glossary 81
role server group

In a deployable application, a configuration A group of AR System servers configured to
that defines access to form fields and server share the same database. See also AR System
objects. Roles are defined in the Role Mapping server.
form and then mapped to groups on the server tier
server on which the application is installed. The architectural level consisting of the
Different groups can be mapped to the same AR System server that controls access to the
role for each development state of the data and any supporting services called or
application. See also access control, application used by the AR System server.
state, deployable application, group, permission,
Roles form, user. Simple Object Access Protocol (SOAP)
The primary transport protocol for messages
Roles form shared by applications in web services. SOAP
The form in which roles are created and is an XML-based packaging format for the
mapped to groups for each application state. transferred information. It contains a set of
See also application state, group, role. rules for translating applications and
schema platform-specific data types into XML.
See form. SQL menu
search A menu whose items are based on data
The process by which users display a subset of retrieved from a direct SQL command to a
requests according to search criteria that they SQL database.
define. status bar
search menu The part of a main window in an AR System
A menu whose items are based on data client that displays instructions or useful
retrieved from a search of an AR System form. information to the user.
See also dynamic menu. Status field
Section 508 The core field in which AR System tracks the
A law that requires U.S. federal agencies’ various stages of the resolution process for a
electronic and information technology to be request.
accessible to people with disabilities (visual, status history
motor, and auditory impairments). A field that displays information about the
selection data type progress of a request.
The data type used for fields with a set of subadministrator
mutually exclusive options. Multiple options A member of the Sub Administrator group.
are displayed as option (radio) buttons or as a
list. A single option can be displayed as a Sub Administrator group
check box. One of several special access control groups
that AR System provides. Members of this
selection list group have limited administrative access to
A list that appears when an active link AR System as defined by an administrator.
performs a search that returns more than one See also Administrator group, explicit group.
request.
server
See AR System server, BMC Remedy Approval
Server, distributed server, plug-in server,
preference server.
82 Concepts Guide
Glossary
Submitter group transfer

One of several special access control groups A distributed operation that sends a copy of a
that AR System provides. The user whose request with or without ownership from one
name is in the Submitter field on a request server to another.
automatically belongs to this implicit group transfer mapping
for that request. See also Assignee group, In a distributed environment, the field-to-field
Assignee Group group, implicit group. mappings used when a request is sent from
supporting form one server to another. See also Distributed
A form that supplies information needed by Server Option (DSO).
another form. See also main form. transfer mode
table field In a distributed environment, one of four
A field that displays data from other requests types of transfer mappings that determines
in the current request. A table field can appear whether the copy of the request is sent with
in a list view format (with rows and columns), ownership and whether the original is
a tree view format, or a cell-based format. deleted. See also Distributed Server Option
task
(DSO).
A shortcut or link created in BMC Remedy trim data type
User that enables users to quickly open a The data type of fields that enhance a form’s
specific form, search, application, or active usability and appearance. Trim includes lines,
link guide. boxes, text, and URL links. These fields do not
time data type
contain data.
The data type used for fields containing time update
values. Time values are stored as the number See distributed update.
of seconds from 12:00:00 a.m. See also date/ user
time data type. Any person with permission to access
toolbar AR System. See also access control, group,
1. Standard: In BMC Remedy User, the row of permission.
buttons below the menu bar that provides user default
easy access to commonly used menu A value for a field that a user can predefine. A
commands. In a browser, toolbar buttons user default overrides an AR System
along the top of the form provide the developer default in BMC Remedy User. See
equivalent functionality of menus and also administrator default.
toolbars in BMC Remedy User. 2. Form-
User form
specific: A separate toolbar with additional
The form in which users are added to
icons that can appear on certain forms.
AR System and in which each user’s group
toolbar button membership, login, and license information
An icon for a menu item that triggers an active are specified.
link. See also button field.
variable
tooltip A data element that changes according to
A brief informational message displayed conditions.
when a user interacts with an object—such as
a table row, attachment, or field label—on the
screen. A tooltip is displayed by hovering the
mouse over an area on a form or by clicking an
object such as a button.
Glossary 83
vendor form workflow

A form used to connect to external data 1. A set of business processes used to run a
sources—such as text or spreadsheet data company. 2. The automation of business
residing on local or remote servers—through processes through actions performed by
an ARDBC plug-in. See also AR System active links, filters, and escalations.
database connectivity (ARDBC). write license
view A license that allows a user to modify and
See form view. save data in existing requests, subject to field
view field and form permission settings. See also fixed
A field that provides a browser window in a license, floating license, read license, restricted
form. Can be used to display a URL, the read license.
contents of an attachment, direct HTML text, XML Schema or XML Schema Definition (XSD)
or content formatted by a template. A means of defining the structure, content,
view form and semantics of XML documents.
A form used to connect to database tables not
created by AR System.
view user interface (VUI)
A structure that contains information about a
single form view.
web client
A browser communicating with the
AR System server through the mid tier.
web service
An object that enables messages to be sent to
and received from an application over a
network (Internet or intranet), using standard
Internet technologies. It uses a combination of
protocols such as HTTP and XML that are
platform independent.
Web Service Description Language (WSDL)
An XML-based language used to define web
services and how to access them.
wildcard
A character that represents other characters in
a search. For example, in search statements in
character and diary fields, users can specify
wildcards to match single characters, strings,
or characters in a range or set.
window-scoped global field
A display-only field whose value remains the
same across requests in the same window as
long as the window is open. See also global
field.
84 Concepts Guide
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index
A Apache Tomcat 17
API calls, workflow and 37
access control application list fields 30
about 47 application programming interfaces. See API
groups, about 48 applications
groups, membership 50 about 20, 33
groups, types 49 animal tracking example 59
hierarchical 51 components 20
licensing and 53 deployable 33
multitiered 51 entry points 30
permissions, additive 49 forms and 33
role-based 50 local 33
users and 48 localizing 33
actions AR System database connectivity (ARDBC)
about workflow 38, 39 database servers and 18
Change Field 39 architecture, AR System 14
Close Window 39 ARDBC. See AR System database connectivity
if/else 38, 43, 44 asset management products 57
Message 39 Assigned To field 31
Notify 39 Assignee access control group 49
Open Window 40 Assignee Group access control group 49
Push Fields 40 attachment fields 30
Run Process 40
Service 40
Set Fields 40 B
active links BMC Analytics for BSM 57
about 21 BMC Atrium applications 57
API calls and 37 BMC Atrium CMDB 57
execution options 41 BMC Atrium Core 57
execution order 42 BMC Atrium Integration Engine 16, 57
guides 38 BMC Atrium Orchestrator 58
user-controlled execution options 42 BMC Dashboards for BSM 57
adaptability, AR System 13 BMC Discovery Solution 57
additive permissions 49 BMC Performance Manager 58
Administrator access control group 49 BMC Product Catalog 57
administrators, responsibilities 23 BMC Remedy Alert 15
AIE 16 BMC Remedy Asset Management 57
Alert List form 15 BMC Remedy Change Management 57
alert list tables 29 BMC Remedy Data Import 16
alerts 15 BMC Remedy Developer Studio 16
analytics 57 BMC Remedy Distributed Server Option 19, 56
animal tracking example application 59
Index 85
BMC Remedy Encryption Performance 56 consoles, applications and 33

BMC Remedy Encryption Premium 56 control fields 30
BMC Remedy Encryption products 56 control panels 27
BMC Remedy Incident Management 57 core AR System 55
BMC Remedy IT Service Management Suite 57 core fields 31
BMC Remedy Knowledge Management 16, 57 Create Date field 31
BMC Remedy Mid Tier. See mid tier custom access control groups 49
BMC Remedy Migrator 16, 56 customer support 3
BMC Remedy Problem Management 57 Customize access control group 49
BMC Remedy Service Desk 57
BMC Remedy User 15
BMC Service Impact Manager 58 D
BMC Service Level Management 57 dashboards 57
BMC Service Request Management 57 data
BMC Software, contacting 2 fields 26
browsers, AR System user interface 15 importing 16
BSM 12, 57, 58 tier, AR System 14
Business Service Management 12, 57, 58 working with external 18
button fields 30 data dictionary menus 32
Button/Menu Field execution option 41 data fields 29
data forms 27
C data visualization fields 30
database servers 18
cell-based tables 29 databases
Change Field action 39 forms in 27
change management products 57 platforms for AR System 18
character menus 32 deployable applications 33
client tier, AR System 14 developer clients 16
client-based workflow 37 Developer Studio 16
clients developers, responsibilities of AR System 23
AR System 15 dialog boxes 27
architectural tier 14 discovery products 57
BMC Atrium Integration Engine 16 display-only fields 29
BMC Remedy Alert 15 display-only forms 27
BMC Remedy Data Import 16 distributed computing environments 19
BMC Remedy Developer Studio 16 Distributed Server Option 19, 56
BMC Remedy Knowledge Management 16 documentation, AR System 7
BMC Remedy Migrator 16 DSO. See Distributed Server Option
BMC Remedy User 15 dynamic groups 49
browser-based 15
developer 16
integration 16 E
user 15 else actions 38, 43, 44
Windows-based 15 encryption
Close Window action 39 performance 56
CMDB 57 premium 56
components standard 56
application 20 engines
example of how they work 22 JavaServer Pages 17
workflow 36 JSP 17
computed groups 49 servlet 17
configuration management database 57 entry points 30
86 Concepts Guide
environments, computing fields (continued)

distributed 19 database table columns and 27
heterogeneous 19 display-only 29
mixed 19 label styles 31
escalations menu items 30
about 21 navigation 30
execution options 43 panel 30
events, triggering workflow with 37 table 29
examples toolbar buttons 30
animal tracking application 59 trim 30
application components at work 22 types 29
AR System adaptability 13 view 30
service desk solution 12 file menus 32
execution options filters
about workflow 36, 38, 41 about 21
active link 41 API calls and 37
Button/Menu Field 41 execution options 41
escalation 43 execution order 42
event-triggered 37 guides 38
filter 41 FIPS 56
Gain Focus 41 Fixed licenses 53
Hover 41 Floating licenses 53
Lose Focus 41 forms
Menu Choice 41 about 20, 26
Modify 41 Alert List 15
Service 41 applications and 33
Submit 41 consoles 33
Table Refresh 41 data 27
time-triggered 37 database tables and 27
user-controlled 37, 42 display-only 27
Window Open 41 fields 26
execution order home pages 30
active link 42 join 27
filter 42 main 33
explicit access control groups 49 menus 21
extending AR System 55 primary 33
external data, working with 18 regular 27
supporting 33
types 27
F vendor 27
Federal Information Processing Standards (FIPS) 56 view 18, 27
fields views 20, 29
about 26 foundation products, AR System 56
application list 30 FTS 56
attachment 30 Full Text Search 56
button 30
character 32
common characteristics 30
control 30
core 31
data 26, 29
data visualization 30
Index 87
G L
Gain Focus execution option 41 label styles, field 31
groups Last Modified By field 31
access control 48 licenses
computed 49 access control and 53
dynamic 49 Fixed 53
explicit 49 Floating 53
implicit 49 pools 53
local applications and 33 Read 53
membership in access control 50 Restricted Read 53
regular 49 list view tables 29
server 17 local applications 33
guides locale 33
active link 38 localizing applications 33
filter 38 Lose Focus execution option 41
H M
help desk products 57 main forms 33
heterogeneous computing environments 19 membership, access control group 50
hierarchical access control 51 Menu Choice execution option 41
home pages 30 menu item fields 30
horizontal navigation fields 30 menus
Hover execution options 41 about 21, 32
character 32
data dictionary 32
I file 32
if actions 38, 43, 44 search 32
implicit access control groups 49 SQL 32
importing data 16 Message action 39
incident management products 57 mid tier
Information Technology Infrastructure Library 12 about 17
integrating with other products 16, 55 AR System architecture and 14
ITIL 12 Migrator 16
ITSM 57 mixed computing environments 19
Modified Date field 31
Modify execution option 41
J multitiered access control 51
JavaServer Pages engines 17
join forms 27
JSP engines 17
N
navigation fields 30
navigation, consoles and 33
K Notify action 39
keywords 45
knowledge management products 16, 57 O
Open Window action 40
OpenSSL Project 56
operating systems, AR System server 17
88 Concepts Guide
P servers (continued)
groups 17
panel fields 30 operating systems for AR System 17
performance encryption 56 Service action 40
permissions. See access control service desks
pools, license 53 example solution 12
predefined access control groups 49 products 57
premium encryption 56 Service execution option 41
primary forms 33 service level management products 57
problem management products 57 service request management products 57
Product Catalog 57 servlet engines 17
product support 3 Set Fields action 40
Public access control group 49 Short Description field 31
Push Fields action 40 SLM 57
solutions 57
SQL menus 32
Q SRM 57
qualifications 44 Standard BMC Remedy Encryption 56
query-by-example (QBE) searches 18 Status field 31
Status History field 31
Sub Administrator access control group 49
R Submit execution option 41
Submitter access control group 49
Read licenses 53
Submitter field 31
records 20, 26
support, customer 3
regular forms 27
supporting forms 33
regular groups 49
Request ID field 31
requests
about 20
T
creating 26 table fields 29
database table rows and 27 Table Refresh execution option 41
Restricted Read licenses 53 tables, database 27
results list tables 29 technical support 3
roles third-party products and AR System 58
access control and 50 tiers, AR System architecture 14
deployable applications and 33 time, triggering workflow by 37
Run Process action 40 toolbar button fields 30
tree view tables 29
trim fields 30
S
search menus 32
searches
U
about 18 user clients 15
FTS 56 user interfaces, AR System
query-by-example (QBE) 18 browser 15
server tier 14 Windows 15
server-based workflow 37 users
servers controlling execution options 42
AR System 17 users, access control and 48
database 18
database platforms 18
Index 89
V
variables, keyword 45
vendor forms 27
vertical navigation fields 30
view fields 30
view forms 18, 27
views, form 20, 29
W
Window Open execution option 41
Windows, AR System user interface 15
workflow
See also actions, execution options
about 21, 35
actions 38, 39
AR System and 36
client-based 37
components compared 21, 36
event-triggered 37
execution options 36, 38, 41
guides 38
server-based 37
time-triggered 37
90 Concepts Guide
*94160*
*94160*
*94160*
*94160*
*94160*

ARS 7.5 - Concepts Guide

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

ARS 7.5 - Concepts Guide

Diunggah oleh

Hak Cipta:

Format Tersedia

BMC Remedy Action Request System 7.5.

© Copyright 1991–2009 BMC Software, Inc.

Restricted rights legend

Support by telephone or email

Before contacting BMC Software

Chapter 1 About AR System 11

Chapter 2 Forms and applications 25

Chapter 4 Access control 47

Chapter 5 Extending AR System 55

Chapter 6 Putting it all together 59

Title Description Audience

Title Description Audience

Title Description Audience

Every company, whether it makes bicycles or provides worldwide

Chapter 1 About AR System 11

Example of a service desk solution

Figure 1-1: AR System adaptability

Perhaps the best way to understand the adaptability of AR System is through an

Chapter 1 About AR System 13

Figure 1-2: AR System architecture

Client tools are

The mid tier lets you

The data tier

User client Platform Description

BMC Remedy Alert Windows Sometimes considered a “desktop pager,” this

Chapter 1 About AR System 15

Developer client Description

AR System mid tier

Chapter 1 About AR System 17

AR System workflow components can search for records (requests) in the

Heterogeneous environment provides flexibility

Distributed environments provide scalability

Figure 1-3: AR System in a distributed environment

AR System Server AR System Server

Chapter 1 About AR System 19

Figure 1-4: Console application viewed in a browser

Chapter 1 About AR System 21

How application components work together

Figure 1-5: Automated workflow example

2 Data entry finished

Filters fire When Status

Chapter 1 About AR System 23

2 Forms and applications

Chapter 2 Forms and applications 25

About AR System forms

Figure 2-1: Example AR System form

Figure 2-2: A form from the view of the database

Request ID Submitter Problem Impact Assigned To Status

Form type Description

Chapter 2 Forms and applications 27

Figure 2-3: Types of AR System forms

Information displayed in regular forms

Service Console Display-Only Form

New Request Search Requests

You can merge information from

View forms are used to connect to database

Database external to AR System

Vendor forms are used to connect to external

Other data sources

Using fields in forms

Field type Description

Chapter 2 Forms and applications 29

Field type Description

Characteristics common to all fields