Concepts 7603

BMC Remedy Action Request System 7.6.
03
Concepts Guide
August 2010
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 2101 CITYWEST BLVD HOUSTON TX 77042-2827 USA Telephone 713 918 8800 or 800 841 2031 Fax 713 918 8000
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 19912010 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, AIX, DB2, and Informix 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. The information included in this documentation is the proprietary and confidential information of BMC Software, Inc., its affiliates, or licensors. Your use of this information is subject to the terms and conditions of the applicable End User License agreement for the product and to the proprietary and restricted rights notices included in the product 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. 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.
Contents
Preface 7
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 AR System documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Chapter 1 About BMC Remedy Action Request System 11 12 12 13 14 16 18 18 19 20 20 21 23 24 25 25 27 28 29 30 31 32 33 33 34 35 35
What is AR System?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of a service desk solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AR System adaptability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AR System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AR System clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AR System mid tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AR System server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Database servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heterogeneous environment provides flexibility. . . . . . . . . . . . . . . . . . . . . . . . . . . Distributed environments provide scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How application components work together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Administrator responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Developer responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Programmer responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 2 Forms and applications
About AR System forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types of forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Form views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reports based on form data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types of fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Characteristics common to all fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Core fields in a regular form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Field menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forms in applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Localized applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
Chapter 3
Workflow
37
Workflow in general and in AR System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Types of workflow components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Workflow based on events versus time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Workflow running on clients versus servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Collections of workflow components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Workflow actions and execution options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Workflow actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Workflow execution options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Workflow qualifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Keywords in qualifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Chapter 4 Access control 49
About access control in AR System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 User and group access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Types of access control groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Additive permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Membership in multiple groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Role-based access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Multitiered access control model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Access control levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 How licensing affects access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 License types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Chapter 5 Extending AR System 59
AR System foundation products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 BMC Atrium products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 AR Systembased solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Other BMC products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Integration with third-party products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Chapter 6 An example BMC Remedy AR System application 63
About the wild animal park . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Goals of the animal tracking application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Analyzing data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Analyzing workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Defining business rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Mapping business rules to workflow components . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Considering integrations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Putting the example application to work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Example applicationA tiger is acquired . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Example applicationThe tiger is injured. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Example applicationThe tiger is traded to another zoo . . . . . . . . . . . . . . . . . . . . 71
Concepts Guide
Appendix A Index
Glossary
75 91
Contents
Concepts Guide
Preface
This guide discusses core concepts of BMC Remedy Action Request System (AR 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.
Audience
This guide 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), or both. You can access product help through each products Help menu or by clicking Help links.
Title Concepts Guide
1
Description
Audience
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. Instructions for installing AR System. Information about the development of AR System applications, including an introduction to using BMC Remedy Developer Studio. Administrators Developers2
Installation Guide Introduction to Application Development with BMC Remedy Developer Studio
Preface
BMC Remedy Action Request System 7.6.03
Title
Description
Audience Developers
Form and Application Objects Information about AR System applications and their user 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. Information about configuring AR System servers and clients, localizing, importing and exporting data, and archiving data. Administrators
Configuration Guide
BMC Remedy Mid Tier Guide Information about configuring the mid tier, setting up applications for the mid tier, and using applications in browsers. Integration Guide
Administrators
Administrators/ Instructions for integrating AR System with external systems by using web services, plug-ins, and other products, Developers/ Programmers3 including LDAP, OLE, and ARDBC. Information about monitoring and maintaining AR System Administrators/ and AR System applications to optimize performance and Developers/ solve problems. Programmers Database administration topics and rules related to how AR System interacts with specific databases; includes an overview of the data dictionary tables. Information about implementing a distributed AR System server environment with BMC Remedy Distributed Server Option (DSO). Administrators/ Developers/ Programmers Administrators
Optimizing and Troubleshooting Guide Database Reference
BMC Remedy Distributed Server Option Guide BMC Remedy Flashboards Guide C API Reference C API Quick Reference Java API
Instructions for creating, modifying, and administering Administrators/ flashboards to display and monitor AR System information. Developers Information about AR System data structures, C API function calls, and OLE support. Quick reference to C API function calls.

Programmers Programmers
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. 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. Instructions for configuring and using BMC Remedy Email Administrators Engine. Descriptions of AR System error messages. Administrators/ Developers/ Programmers Everyone Administrators
Java Plug-in API
BMC Remedy Email Engine Guide Error Messages Guide
Master Index BMC Remedy Approval Server Guide
Combined index of all books. Instructions for using BMC Remedy Approval Server to automate approval and signature processes in your organization.
Concepts Guide
AR System documents
Title Release Notes Release Notes with Known Issues BMC Remedy User Help BMC Remedy Developer Studio Help BMC Remedy Data Import Help BMC Remedy Alert Help BMC Remedy Mid Tier Configuration Tool Help BMC Remedy Browser Help
1
Description Information about new features, compatibility, and international issues.
Audience Everyone
Information about new features, compatibility, international Everyone issues, installation planning, and open issues. Instructions for using BMC Remedy User. Instructions for using BMC Remedy Developer Studio to develop AR System forms, workflow objects, and applications. Instructions for using BMC Remedy Data Import. Instructions for using BMC Remedy Alert. Instructions for configuring BMC Remedy Mid Tier. Instructions for using AR System forms in browsers. Everyone Developers
Administrators Everyone Administrators Everyone
The full title of each guide includes BMC Remedy Action Request System 7.6.03 (for example, BMC Remedy Action Request System 7.6.03 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
10
Concepts Guide
Chapter
About BMC Remedy Action Request System

This chapter introduces BMC Remedy Action Request System (AR System) architecture and application components and explains how they fit together to address your organizations needs. The following topics are provided:
! ! ! ! ! !
What is AR System? (page 12) AR System architecture (page 14) Application components (page 21) Administrator responsibilities (page 24) Developer responsibilities (page 25) Programmer responsibilities (page 25)
Chapter 1 About BMC Remedy Action Request System
11
What is 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. 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. With sufficient planning, even workflowintensive procedures can be automatically maintained in an orderly manner.
Example of a service desk solution

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 employees problem. Ramonas printer would not work, so she logged in to her companys AR System 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 Ramonas 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.
12
Concepts Guide
What is AR System?
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.
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
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.
13
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 that includes the client tier, the mid tier, the server tier, and the data tier.
!
Client tierContains 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 tierContains components and add-in services that run on a web server, enabling users to view applications on the web. Server tierContains 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 BMC Remedy Flashboards server) and the C and Sun Java plug-in servers with plug-ins. Data tierContains 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.
14
Concepts Guide
Figure 1-2: AR System architecture
15
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 Browsers Platform Provide a user interface to AR System applications through the mid tier Provides a Windows-based user interface to AR System applications Windows Description Can be used for these functions:
!
! ! !
BMC Remedy User
Submitting, searching for, and modifying requests Charting data Generating reports Receiving and responding to AR System notifications Performing administrative tasks such as license management and AR System server configuration
BMC Remedy Alert
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.
16
Concepts Guide
Developer clients
The developer clients are used to create, modify, and extend AR System applications:
Developer client BMC Remedy Developer Studio Description Used to create and modify all the components of an AR System application, such as forms and workflow elements. 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. 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
BMC Remedy Data Import
BMC Remedy Migrator
with other BMC applications, see the BMC Remedy Migrator Release Notes on the Customer Support website (http://www.bmc.com/support).
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.
17
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).
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).
Server groups
To provide scalability and increase reliability, you can connect a group of AR System servers to the same database and manage them as a unit by configuring a server group. Server groups act as a single server to support the applications that they run. Servers in the server group 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.
18 Concepts Guide
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). 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.
19
Heterogeneous environment provides flexibility

Because the multiple layers of AR System are independent of one another, you can combine operating system platforms to fulfill different functions. The heterogeneous environment enables you to mix and match client and server platforms. 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 on page 21, 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.
20
Concepts Guide
Application components
Figure 1-3: AR System in a distributed environment
AR System provides extensive authoring capabilities for applications built for web and Windows environments. 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. This section introduces the main components of an AR System application.
!
FormThe 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 employees 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 on page 22. See Chapter 2, Forms and applications.
21
Figure 1-4: Console application viewed in a browser
MenuMenus 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 Field menus on page 34. WorkflowWhile forms provide the mechanism to structure data capture and menus offer options for specific field data, additional componentsactive links, filters, and escalationsact 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 linkAn 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.
22
Concepts Guide
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.
!
FilterA 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.
EscalationAn 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

This section uses the Example of a service desk solution on page 12 to illustrate how the components of an AR System application work together. In the example, when Ramona entered her telephone number into the Telephone # field, the following sequence occurred, as illustrated in Figure 1-5 on page 24:
Step 1 An active link searched the Employee form to retrieve the name, configuration,
and location associated with the telephone number.

Step 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 Ramonas printer was not working.
Step 3 Becky fixed the problem. Step 4 Becky changed the status of the request, and a filter notified Ramona that her
problem was solved.
23
Figure 1-5: Automated workflow example
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.
Administrator responsibilities
Typically, AR System administrators are responsible for some or all of these tasks:
! ! ! !
Installing AR System software Defining their organizations 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
24
Concepts Guide
Developer responsibilities
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 organizations 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
25
26
Concepts Guide
Chapter
Forms and applications
This chapter describes forms and how forms are used in applications. It also describes localization features for applications. The following topics are provided:
! ! ! ! !
About AR System forms (page 28) Types of fields (page 32) Field menus (page 34) Forms in applications (page 35) Localized applications (page 35)
Chapter 2
27
About AR System forms

Forms are the foundation of AR System. A form captures and displays information and a set of forms can be grouped into an applications. For example, a service desk form captures information needed to fix a users 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 Types of fields on page 32). Some fields can have attached menus that help users fill in the form (see Field menus on page 34).
Figure 2-1: Example AR System form
28
Concepts Guide
Each form in an application is like a template to capture or present information. 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. 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
Types of forms
You can create the following types of forms, as illustrated in Figure 2-3 on page 30:
Form type Regular Display-only Description 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. 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. 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. 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. These forms enable users to connect to external data sourcessuch as text files, spreadsheets, or database tables residing on local or remote serversthrough an ARDBC plug-in. Some programming is required to connect to the data source.
Join
View
Vendor
Chapter 2
29
Figure 2-3: Types of AR System forms
Form views
A view is a visual representation of a form. To reuse a form for diverse groups while accommodating each groups 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.
30
Concepts Guide
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) 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
When creating form views, you can

! ! !
Reports based on form data

Using the AR System Reporting Console, which provides a single interface for all reporting functions, users can create and run nicely formatted reports based on the data stored in AR System forms. The new Web report type is supported by reporting components that are installed with BMC Remedy Mid Tier. In addition, users can use the traditional AR System reports or Crystal Reports, a reporting package that you can integrate with AR System. Users can also use the Reporting Console to run existing Web reports, AR System reports, and Crystal reports, including those defined by others or installed with BMC applications if they have the necessary permissions.
Chapter 2
31
Types of fields
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 Data Description 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 fields default value. Whether fields are indexed for faster searches.
Table Attachment View
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. Attaches files to requests. 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. Augments AR System with HTML-based contentsuch as web pages, flashboards, and other graphicsthat can interact with the fields parent form through workflow. 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.
Data visualization Application list
Horizontal and vertical navigation Control Panel
Enables users to navigate to the correct screen in an application quickly and easily. Triggers active links. Control fields include buttons, menu items, and toolbar buttons. 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. Adds boxes, lines, and text to enhance the visual appearance of forms.
Trim
32
Concepts Guide
Types of fields
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.
! !
Core fields in a regular form

A regular form automatically contains these core fields.
! ! ! ! ! ! ! ! !
Request IDUnique tracking number assigned to each request by AR System. SubmitterLogin name of the user who submits a request. Create DateDate and time that a request is created. Assigned ToPerson assigned to handle the request. Last Modified ByUser who last modified the request. Modified DateDate and time that the request was last modified. StatusCurrent status of the request. Short DescriptionBrief description of the request. Status HistoryTime the requests 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, Core fields, page 428.
Chapter 2
33
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 users view and change their labels, location, and appearance. The following table shows the meaning of the field label styles:
Style Bold Italic Plain Description Field requires a valuedefault, user-entered, or from workflow when a user submits a request. Field is automatically populated by AR System. Field is optional. Users can enter information in it or leave it empty.
Field menus
Field menus help users enter data and 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 Character Description 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. 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. 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. 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. 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.
File
Search
SQL
Data dictionary
34
Concepts Guide
Forms in applications
Forms in 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 in the application. Sometimes a single form can contain all of an applications functionality. For example, a small application that tracks product defects can use a single defecttracking 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 applications 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.
Localized 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 systems 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 forms user interface Separator symbol for decimal numbers that include a fraction Separator symbol for numbers greater than 999
Chapter 2 Forms and applications 35
! !
! !
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 users 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, Localizing AR System applications, page 531.
36
Concepts Guide
Chapter
Workflow
This chapter describes the workflow components of AR System. The following topics are provided:
! ! ! ! !
Workflow in general and in AR System (page 38) Types of workflow components (page 38) Collections of workflow components (page 40) Workflow actions and execution options (page 40) Workflow qualifications (page 46)
For detailed information about workflow, see the Workflow Objects Guide.
Chapter 3 Workflow
37
Workflow in general and in AR System

The function of workflow is to process the data captured in forms in accordance with your business needs. In AR System, workflow automates your companys processes through the use of active links, filters, and escalations. In general, workflow can be defined as the set of processes that your company uses to run itselffor example, tracking defects or administering employee benefits. You use the workflow components of AR System 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. 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 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)
! ! !
Types of workflow components

This table summarizes how and where you use filters, active links, and escalations:
Component Active link Filter Escalation Triggered by Events Events Time Where action is performed Client Server Server
38
Concepts Guide
Types of workflow components
Workflow based on 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, whereas escalations implement time-based business rules. 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 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.
Workflow running on clients versus servers

Active links are executed on the client side in response to actions that users perform in forms, whereas filters and escalations are executed on the server. 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. Filters and escalations implement business rules by examining newly created or changed requests and taking actionssuch as changing data in the request, creating other requests, or sending notificationsbased 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.
Chapter 3 Workflow
39
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
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. 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 on page 41.
40
Concepts Guide
Figure 3-2: Example of workflow with qualification
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 , Types of workflow actions, page 75.
Action Change Field Description Changes the appearance of fields. For example, a Change Field action can perform one or more of these actions:
! !
Active link Filter

+
Escalation
! !
! ! !
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 fields 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.
Chapter 3 Workflow
41
Action Message
Description 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.
Active link Filter

+ +
Escalation
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. 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.
+
Open Window
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 users desktop.
42
Concepts Guide
Action Service
Description 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. 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.
Active link Filter

+ +
Escalation
+
Set Fields
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, Defining workflow execution options, page 37.
Execution option Button/Menu Field Gain Focus Display Hover on Field Hover on Data Hover on Label Lose Focus Menu Choice Modify Description Executes when a user selects the button or menu item associated with the active link. Executes when a user or a Change Field action moves the cursor to a field. Executes after a request is loaded into a form but before the request appears in the Details pane. Executes when a user hovers the mouse pointer over a field, field data, or a field label. To display tooltips, use a Hover execution option to trigger a Message action. Executes when a user or a Change Field action moves the cursor out of a field. Executes when a user chooses an item from a character menu associated with a specified field. 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. Enables filters to be called by the Service action. Active link Filter
+ + + +
+ + + +
Service
Chapter 3 Workflow
43
Execution option Submit
Description 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). Executes when a user updates a tables contents by loading the field, sorting, refreshing, or displaying the previous or next part (chunk) of the table. 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.
Active link Filter

+ +
Table Refresh
Window Open
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 users 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 users 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.
44
Concepts Guide
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.
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 escalations qualification. If it finds any, the server runs the escalations primary (if) actions for each matching request. If no requests meet the qualification, the server runs the escalations alternative (else) actions, if any, once. Figure 3-3 illustrates how escalations work.
Figure 3-3: How escalations work
Chapter 3 Workflow
45
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
Qualifications in active links, filters, and escalations enable 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 on page 45.
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.
46
Concepts Guide
Workflow qualifications
Keywords in 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 are used to build qualifications. 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, Keywords, page 215.
Chapter 3 Workflow
47
48
Concepts Guide
Chapter
Access control
This chapter describes access control in AR System. The following topics are provided:
! ! ! ! !
About access control in AR System (page 50) User and group access (page 50) Role-based access (page 52) Multitiered access control model (page 53) How licensing affects access control (page 56)
Chapter 4
Access control
49
About access control in AR System

AR System 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. 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 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 Server Form (or table) Field (or column) Active link and active link guide Request (or row)
AR System uses a multitiered approach to control access at these points:

! ! ! ! !
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.)
50
Concepts Guide
User and group access
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. You can also configure a hierarchical relationship between groups to allow the parent group to inherit the permissions of the child group. AR System has predefined groups that perform specific functions (see Types of access control groups on page 51). 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.
Types of access control groups

This table lists the types of access control groups:
Type of access control group Explicit Description A group to which you must assign users. Predefined groups1
! ! !
Custom groups2 Any regular and computed groups that you create. 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.
Administrator Sub Administrator Customize
Implicit
A group to which a user automatically (or implicitly) belongs by virtue of the contents of 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 2
! ! ! !
Public Submitter Assignee Assignee Group
Any dynamic groups that you create. Dynamic groups use the contents of special fields to determine group membership.
AR System provides these access control groups. You must add these access control groups to your system.
Chapter 4
Access control
51
For more information, see the Form and Application Objects Guide, Defining access control, page 19.
Additive permissions
Access control in AR System is additive. This means that each user in AR System starts out with no access permissions. Administrators 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 caseby-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
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 and are then associated with groups on the server where the application is deployed.
52
Concepts Guide
Multitiered access control model
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 applications object permissions for each server.
NOTE
For simplification, user access is usually described 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.

AR System uses a multitiered approach to control data access. At each access level, a users permissions are checked. If access is permitted, the user proceeds to the next level. If access is denied at any point except active links and active link 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 users ability to access a request depends on whether he belongs to a group that has access to the Request ID field.
Chapter 4
Access control
53
Figure 4-2: Access control in AR System
54
Concepts Guide
Access control levels

The access control model comprises the following levels:
Access level AR System server Description 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, Allowing guest users, page 63. Form As an administrator, you give groups access to forms according to each groups 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. Static permissions inheritance and dynamic permissions inheritance properties control access to the form for parent groups. 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. 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. 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. 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.
Field
Active link
Request
Chapter 4
Access control
55
How licensing affects access control

In addition to obtaining a license to run the AR System server and other components, you must specify a license type for each AR System user.
NOTE
AR System includes a setting that enables you to permit users who are not recognized users to access to AR System applications as a member of the Public Group. For more information, see User and group access on page 50. Although licensing is not a component of access control, licensing can affect a users 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.
License types
You can assign the types of user licenses listed in this table:
License Read Description 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. 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. Restricted Read licenses do enable the same login account to access AR System from multiple IP addresses simultaneously.
Restricted Read
56
Concepts Guide
How licensing affects access control
License Fixed
Description 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. When a user who is assigned a Floating license logs in to AR System, she is given a Read license. When she attempts to perform a modify or submit operation, AR System checks for an available Floating license, and the following occurs:
!
If a Floating license is available, the user is granted write access to requests. She retains write access until the Floating license is released (for more information, see Releasing floating licenses on page 53). If no Floating 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, Licensing AR System, page 35.
Chapter 4
Access control
57
58
Concepts Guide
Chapter
Extending AR System
The core AR System productclients (BMC Remedy Developer Studio and BMC Remedy User), mid tier, and AR System serveris 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. The following topics are provided:
! ! ! ! !
AR System foundation products (page 60) BMC Atrium products (page 61) AR Systembased solutions (page 61) Other BMC products (page 62) Integration with third-party products (page 62)
Chapter 5
Extending AR System
59
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 20 and the BMC Remedy Distributed Server Option Guide. BMC Remedy Encryption Security productsEnable the AR System server and its clients to communicate securely over a network by encrypting the messages sent between them.
!
BMC Remedy Encryption Standard Security is built into the BMC Remedy products. Optional BMC Remedy Encryption Performance Security and BMC Remedy Encryption Premium Security 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 Security 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 Security 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, Using full text search, page 293. BMC Remedy MigratorProvides 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).
60
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 Systembased 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 pre-integrated 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 Systembased solutions
The following BMC Remedy solutions for IT service and customer relationship management are based on AR System:
!
BMC Remedy IT Service Management (ITSM) SuiteOffers 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 ManagementEnables 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 ManagementGives 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.
Chapter 5
Extending AR System
61
Other BMC products

Many other BMC productssuch as BMC Atrium Orchestrator, BMC Service Impact Manager, and BMC Performance Managerintegrate 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).
62
Concepts Guide
Chapter
An example BMC Remedy AR System application

This chapter brings together the basic concepts of AR System by showing how a sample organizationa wild animal parkmight 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. The following topics are provided:
! ! ! !
About the wild animal park (page 64) Goals of the animal tracking application (page 64) Considerations (page 65) Putting the example application to work (page 68)
Chapter 6 An example BMC Remedy AR System application
63
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.
! ! !
All these goals relate to tracking animals throughout their life at the park, as shown in Figure 6-1 on page 65.
64
Concepts Guide
Considerations
Figure 6-1: Animal tracking overview
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, including data analysis, workflow analysis, identifying the business rules to be enforced, mapping the business rules to workflow components, and considering whether any integrations are required.
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 analyze the data by answering these questions:
! !
What types of data do they need to capture? How is this data stored in their current system (for example, in a legacy database or in paper forms)?
Chapter 6 An example BMC Remedy AR System application 65
! !
What forms (main and supporting) and fields need to be created? Should they include menus on the forms and, if so, which kinds are most appropriate to help staff members fill in fields?
The staff determines that they need these forms (shown in Figure 6-2) to capture information:
!
Animal formContains detailed information about each animal. The staff considers using panel fields to organize the form modularly, keeping related fields together. Species Info formContains details about a particular species, such as feeding requirements, life span, medical needs, and whether it is endangered. This is a supporting form. Feeding formContains information about each animals feeding schedule. Enclosure formContains information about the number and types of animals each enclosure can hold and so forth. Medical History formContains the complete medical history of each animal. Former Resident formContains information about animals that no longer reside in the park.
! !
! !
Figure 6-2: Forms for animal tracking application
66
Concepts Guide
Considerations
Analyzing workflow
Next, the staff considers the parks 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? 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.
Some of the AR System groups or roles that the park needs are:
! ! ! ! !
Appropriate permissions will be assigned to each group or role according to the information that they need to access.
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? 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.
Business rules for the park include:

! !
67
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? A filter to notify animal handlers whenever an animal needs to be moved. Active links that help users fill out forms. An escalation to enforce the rule that animals must be checked by a veterinarian within 24 hours of arrival. An escalation to notify keepers when an animal has not been fed within one hour of its scheduled feeding time.
Some of the workflow components that the park needs are:

! ! !
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.
! !
Putting the example application to work

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.
Example applicationA tiger is acquired

This section describes an example in which the hypothetical wild animal park acquires a tiger. This scenario illustrates a complete process, but not every component of the process is discussed in detail.
68
Concepts Guide
As shown in Figure 6-3 on page 70, 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 choicein this case, enclosure 16and 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.
69
Figure 6-3: Active link and filter in the animal tracking application
1
Dialog Box Enclosure Form Animal Form
Name Type Status Assigned to Enclosure
Karuna Sumatran Tiger New 16
Number
Active Link lists all enclosures and their capacity.
Status Full Full Available Available
Habitat Waterhole Steppe Jungle Steppe
4 5 16 20
List Enclosures
Cancel
Continue
3
User submits request.
2
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 tigers arrival."
TIP
This example is similar to moves, adds, and changes (MAC) in an employee services application.
Example applicationThe tiger is injured

This section describes an example in which the tiger at the hypothetical wild animal park is injured. This scenario illustrates a complete process, but not every component of the process is discussed in detail. One morning when the keepers are making their daily rounds, they notice that the tiger, 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 on page 71. 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.
70
Concepts Guide
Figure 6-4: Table field in the animal tracking application
During the prototyping phase, staffers had to open the Medical History form separately to learn about Karunas 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.
TIP
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.
Example applicationThe tiger is traded to another zoo

This section describes an example in which the tiger, named Karuna, at the hypothetical wild animal park is transferred to a different zoo. This scenario illustrates a complete process, but not every component of the process is discussed in detail. 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 parks female tigers. They decide to trade Karuna, and a staffer changes Karunas 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 on page 72.
71
Figure 6-5: Notifications in the animal tracking application
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 Karunas 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
72
Concepts Guide
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.
TIP
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.
73
74
Concepts Guide
Glossary
This glossary defines common terms used with AR System.
access control administrator default
An AR System security feature used to limit the access that users have to forms, to specific fields or records in a form, to workflow, and to specific functions in the system. See also group, permission, role, user.
access point
The value that AR System developers assign to a field when designing a form. Users can override the administrator default by assigning their own default or by entering a different value. See also user default.
Administrator group
A form or guide in an application that is used as an interface to other applications or workflow, such as in Push Fields or Call Guide actions. When creating workflow that references forms and guides, a developer can identify access points.
active link
One of several special access control groups that AR System provides. Members of this group have full and unlimited access to AR System, including unlimited ability to create definitions and to access and modify data. See also explicit group, Sub Administrator group.
advanced search bar
A workflow component that causes an AR System client to perform specific operations in response to specific user actions. Active links are generally employed to help users interact with the system. They run on the client computer or on the mid tier.
active link guide
The row of buttons, the Search Criteria field, and the Fields menu list that appear at the bottom of the Details pane when users click the Advanced search button in a browser or the View > Advanced Search Bar menu in BMC Remedy User. Use this bar to specify complex search criteria.
alert
An ordered sequence of active links that accomplishes a specific operation. Active link guides can lead users through a task (like a wizard) or can be used as subroutines to accomplish common tasks. See also filter guide.
administrator
An individual responsible for the management of AR System, including installing AR System software and maintaining AR System by adding and deleting users, groups, and roles; backing up AR System servers; importing data from other systems; and so on.
A message from an AR System server or other program to notify a user that certain events such as a request being submitted or progress being made in resolving a requesthave occurred. You can use BMC Remedy Alert, an optional Windows program, to notify users when they receive alerts
alert list
The list of alerts belonging to a user. The list can be displayed in a browser or in BMC Remedy User.
Glossary
75
allowable currency type
AR System client
A currency type that appears in the currency field menu. Users can use only allowable currency types when entering currency values. See also currency data type, functional currency type.
ancestor group
The AR System programs that enable users to access an AR System server. AR System clients include BMC Remedy Developer Studio, BMC Remedy User, the web client (mid tier), BMC Remedy Data Import, and BMC Remedy Alert.
AR System database connectivity (ARDBC)
In a hierarchical group relationship, a parent group or the parent group of a parent group. See also child group, dynamic permissions inheritance, hierarchical groups, parent group, and static permissions inheritance.
API
A mechanism by which the AR System server uses a plug-in to access data stored outside the AR System database as if it were in AR System.
AR System external authentication (AREA)
See application programming interface (API).

application
A group of forms and associated workflow related to a business function, such as Employee Care or Service Desk. An application is a server object in BMC Remedy Developer Studio. See also deployable application, local application.
application list field
A mechanism by which the AR System server can access and use authentication services from outside the AR System environment. A plug-in is used to access the external subsystem.
AR System ODBC driver
A field that displays entry points. See also entry point, entry point guide, form entry point, home page.
application programming interface (API)
A connectivity solution that enables AR System to communicate with ODBC (Open Database Connectivity) clients. ODBC is an SQL-based communication standard developed by Microsoft.
AR System server
A set of functions or classes that provides application programmers with access to the full functionality of a product. The AR System C API is documented in the C API Reference, and the Java API is documented in the Java API HTML documentation.
application state
The AR System program that processes all data entered by a client. The AR System server is the workflow engine between client and database. It also verifies that a user has permission to perform each action, thereby enforcing any access control defined in an application.
ARDBC
The development state of a deployable application, such as Test or Production. Roles can be mapped to different groups based on application state to limit access to the application during testing or modification. See also deployable application, group, role.
AR System
See AR System database connectivity (ARDBC).

AREA
See AR System external authentication (AREA).

Assignee group
See BMC Remedy Action Request System (AR System).
One of several special access control groups that AR System provides. The user whose name is in the Assigned To field of a request automatically belongs to this implicit group for that request. See also Assignee Group group, dynamic group, implicit group, Submitter group.
76
Concepts Guide
Glossary
Assignee Group group
BMC Remedy Email Engine
One of several special access control groups that AR System provides. If the Assignee Group field in a request contains a user name, that user is automatically a member of this group for that request. If the Assignee Group 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.
attachment data type
A server-based module provided with AR System that communicates with both the AR System server and an email server. Email Engine receives email messages and can parse and interpret the messages to execute specific instructions on an AR System form. It also sends email messages to AR System and directs notifications as a result of filters and escalations.
BMC Remedy Flashboards
The data type used for fields that hold files. This type enables you to store text, graphics, audio, or video attachments in the database.
attachment pool field
A real-time visual monitoring tool that can show the state of service operations, warn about potential problems, and collect and display trend data.
BMC Remedy Mid Tier Configuration Tool
A field that contains one or multiple related attachment fields associated with a request.
BMC Remedy Action Request System (AR System)
Adaptable client/server software that provides a foundation for creating applications that can automate, track, and manage a wide variety of business processes.
BMC Remedy Alert
The tool used to configure and manage the mid tier portion of AR System. See also mid tier.
BMC Remedy User
The AR System client through which an alert can be sent to a user. See also notification.
BMC Remedy Approval Server
The AR System client in which users enter and track requests through the resolution process. Users can also search the database, generate reports, and modify existing requests. (Alternatively, the mid tier enables you to perform these tasks in a browser. See mid tier.)
broadcast distributed transfer
A module in AR System that routes forms to generate the appropriate signoff signatures. This module also creates an audit trail for authorizing AR System application forms.
BMC Remedy Data Import
The AR System client tool used to transfer data records from an archive file into a form.
BMC Remedy Developer Studio
A distributed operation in which one source server simultaneously or consecutively transfers data-only copies of requests to multiple target servers. See also Distributed Server Option (DSO).
button field
The AR System client used by AR System developers to develop applications. Use this client to create and change object definitions and to set access permissions that determine which users and groups can view or modify each form or specific parts of a form.
A field on a form that a user can click to execute an active link. A button, image, or hyperlink can represent a button field. See also toolbar button.
chained distributed transfer
A distributed operation in which a request is transferred from a source server to a target server and then transferred from that target server to another server. See also Distributed Server Option (DSO).
Glossary
77
change flag
container
A status flag set when the contents of a field or form are altered. A change flag can be polled or disabled by workflow.
character data type
The data type used for fields that contain alphanumeric text.
character field
The underlying data structure for guides and applications. A component of AR System used to store collections of objects. Used as the basic storage structure for applications, active link guides, filter guides, and packing lists.
control data type
An AR System data field that holds alphanumeric characters. You can attach a menu or a file system browser to character fields or fill them with default text.
character menu
The data type for fields that execute active links. These fields do not contain data.
control panel
A form used as a centralized entry point from which users choose the business tasks they want to accomplish.
core field
A menu that provides assistance with filling in values for a field. A character menu can be attached to any character field. See also dynamic menu.
child group
One of a set of basic fields common to all AR System regular forms. These fields cannot be removed from a regular form.
currency code
In a hierarchical group relationship, any group that has a parent group defined. Where allowed by the permissions inheritance properties, this gives the parent group the same access permissions to the object as the child group. See also ancestor group, child group, dynamic permissions inheritance, hierarchical groups, parent group, and static permissions inheritance.
client
The three-letter code that represents a currency type, such as USD for United States dollars.
currency data type
See AR System client.

client tier
The data type used for fields containing currency data. Currency data is stored in four parts: a decimal value, a currency code, a conversion date, and one or more functional (converted) currency values. Each part can be viewed or searched by users or accessed by workflow. See also allowable currency type, functional currency type, currency code.
Customize group
The architectural level in which AR System clients operate in the multitiered system.
command-line option
A parameter used to specify an operation or option to AR System programs and utilities when they are run.
computed group
One of several special access control groups that AR System provides. This group grants users the right to customize their form layout in BMC Remedy User. See also explicit group.
data field
An explicit group whose membership is based on the memberships of other explicit groups. See also explicit group, group.
A field that stores data in the database. Data fields include character, date, time, date/time, diary, integer, real, decimal, selection, attachment, and currency.
data-only copy
In a distributed environment, a read-only copy of a request that is not part of an active ownership chain and cannot create a new ownership chain. See also independent copy, ownership chain, DSO server.
78 Concepts Guide
Glossary
data tier
deployable application
The architectural level that contains data and communicates with the AR System server. The data can be stored in a text file, spreadsheet, or database that is part of or separate from AR System.
data type
An application that uses permissions based on roles and that is easily portable to other servers. See also application, local application, role.
Details pane
The property of a field that determines the characteristics of the field and what type of information (if any) the field can contain.
data visualization field
The part of the main window in a browser or in BMC Remedy User that displays fields for entering or viewing data.
Developer Studio
See BMC Remedy Developer Studio.

dialog box
A field that provides a way to augment AR System with HTML-based contentsuch as web pages, flashboards, and other graphicsthat can interact with the fields parent form through workflow.
date data type
A window displayed to users that must be responded to before users can continue filling out a form. To create a dialog box, use an active link action.
diary data type
The data type used for fields containing date values. Date values can range from January 1, 4713 B.C.E., to January 1, 9999 C.E. Date values are stored as the number of days from the beginning of the date fields range. For example, January 1, 2009, is stored as the number 2454833 because it is 2,454,833 days after the first day in the date range. See also date/time data type.
date/time data type
The data type used for a field in which you can capture a history of the actions taken for a request. The field stores character data. It is an append-only field, and each addition is stamped with the time, date, and name of the user who enters it.
display-only field
A temporary field for which no space is allocated in the database. See also global field.
display-only form
The data type used for fields containing date/ time timestamp values. Values can range from January 1, 1970, to January 17, 2038. See also date data type, time data type.
decimal data type
A type of form containing display-only fields. Display-only forms are used to create control panels and dialog boxes.
distributed delete
The data type used for fields containing fixedpoint numbers.

default
See administrator default, user default.

default mapping
A distributed operation that removes a copy of a request from an AR System server. If the master copy of a request is deleted, all copies of the request in the associated ownership chain are also deleted. See also Distributed Server Option (DSO).
distributed fields
The mapping used by DSO when the DSO action in a filter or escalation does not specify a mapping. The Default Mapping field in the Distributed Mapping editor is used to designate default mappings. See also Distributed Server Option (DSO).
Fields that must be added to an AR System form to enable DSO to perform ownership transfers from and to the form. The three groups of distributed fields (basic, full, and advanced) provide different levels of control over distributed operations. See also Distributed Server Option (DSO).
Glossary
79
distributed mappings
distributed transfer
Objects on an AR System server that define how data is transferred from one form to another. Distributed mappings are used with DSO filter and escalation actions. They are created in the Distributed Mapping editor and stored in the Distributed Mapping form. See also Distributed Server Option (DSO).
distributed operations
A distributed operation that sends information from a source form on one server to a target form on another server or on the same server. The transfer can include all or some of the data in the request. See also Distributed Server Option (DSO).
distributed update
Operations performed by DSO to manage data transfers, updates, returns, and deletes in a distributed environment. See also distributed delete, distributed return, Distributed Server Option (DSO), distributed transfer, distributed update.
distributed pools
A distributed operation that refreshes a copy of a request when the master copy in an ownership chain is modified. See also Distributed Server Option (DSO).
DSO
See Distributed Server Option (DSO).

DSO actions
Objects on an AR System server that enable DSO to process multiple distributed operations simultaneously and to ensure that interrelated operations of pending distributed items occur in the correct order. Distributed pools are created in the Distributed Pool editor and stored in the Distributed Pool form. See also Distributed Server Option (DSO).
distributed return
Actions configured in filters or escalations to trigger distributed transfers, returns, and deletes when specified criteria are met in a form. See also distributed delete, distributed return, Distributed Server Option (DSO), distributed transfer.
DSO server The arservdsd process (UNIX) and the serverds.exe program (Windows) that
A distributed operation that returns an updated request with ownership to the originating server. Distributed returns are triggered by workflow on the server that returns the request. See also Distributed Server Option (DSO).
Distributed Server
manage distributed operations. See also Distributed Server Option (DSO).

duplicate request IDs
The name of the internal AR System user that performs all distributed operations for the DSO server. See also DSO server.
Distributed Server Option (DSO)
Matching request IDs that occur in a distributed operation when a request transferred from a source server has the same request ID as a request on the target server. DSO provides several ways to handle this issue. See also request ID.
An AR System server component that transfers data among forms on physically separate servers or on the same server. DSO requires a separate usage license. See also DSO server.
80
Concepts Guide
Glossary
dynamic group
escalation
One of several special access control groups that developers can create in the Group form by using a group ID from 6000060999. If a dynamic group field (a field whose field ID is the same as the dynamic group ID) contains a user name, that user is a member of that dynamic group. If the dynamic group field contains a group name, all users in that group are members of the dynamic group. If it contains a role name, all members of the groups mapped to that role are members of the dynamic group. See also Assignee Group group, group, implicit group, role.
dynamic menu
A workflow component that searches at specified times or intervals for requests matching certain criteria and that performs specified operations on the matching requests. Escalations are generally used to find records that have violated business rules or processes and then to take the appropriate action. They run on the AR System server.
event
A menu populated at run time when users click a search menu icon. The source of the menu items is determined by values in other fields on the form on which the menu appears. See also search menu.
dynamic permissions inheritance
An occurrence in AR System that can trigger other events or workflow. Examples include user interactions with a form (such as opening windows, tabbing from field to field, switching row focus, and so on), state transitions of requests, or any condition that arises while a request is manipulated.
explicit group
A form property that controls access to requests by any ancestor group of a group granted dynamic access to the request. See also ancestor group, child group, hierarchical groups, parent group, and static permissions inheritance.
email engine
A group to which users are assigned or that is computed from other groups, such as Administrator and Customize. See also computed group, group, implicit group.
export
See BMC Remedy Email Engine.

entry
See request.
entry point
1. The BMC Remedy Developer Studio command that writes definitions of objects such as forms, filters, active links, and mail templatesto a file. 2. To write object definitions to a file by using BMC Remedy Developer Studio or the export command-line interface. 3. To write data entries to a file by using the reporting feature in BMC Remedy User. See also import.
field
A link on the home page that users click to start a task (such as creating a request) or to open a console (such as AR System Administration Console). See also entry point guide, form entry point, home page.
entry point guide
The main component of an AR System form. AR System field types include data, table, panel, active link control (buttons, menu items, and toolbar buttons), attachment pool, view, and trim.
field ID
An entry point that starts a guide so that a user can complete a task. See also entry point, form entry point, home page.
An integer that identifies a field throughout AR System. Every field in a form must have a field ID that is unique in that form. Field IDs can be assigned manually by AR System developers or automatically by AR System. After a field ID is assigned, it cannot be changed.
Glossary
81
field label
form
A name that describes a fields purpose. Intended to be displayed to users.

field name
A unique character identifier assigned to each field. The name can be changed at any time as long as the new name is unique.
file menu
A collection of fields that represents a request in AR System. AR System developers can define and change the fields and workflow associated with a form. An AR System application can include many forms. In AR System APIs, forms are called schemas. See also request.
form action field
A menu with items retrieved from a text file containing a formatted character menu.
filter
A workflow component that tests every server transaction for certain conditions and responds to the conditions by taking specific actions. Filters are generally used to check and enforce business rules and processes. They run on the AR System server.
filter API
One of a set of special fields that perform predefined operations in browsers for Webbased applications. The fields include Submit, Query, Modify, and the Search Bar.
form entry point
An entry point that opens a form in a particular mode, such as Search or New, so that a user can complete a task. See also entry point, entry point guide, home page.
form view
An AR System plug-in API that enables inline access during filter and escalation processing to extended servers. See also plugin.
filter guide
An ordered sequence of filters that accomplishes a specific operation. Filter guides can be used as a subroutine to accomplish common tasks. See also active link guide, filter.
fixed license
The screen layout for a form that appears in the Details pane of a browser or BMC Remedy User. AR System developers can create and name multiple form views, which can be further modified by users in the Customize group. Developers can include or hide different fields in various form views, and they can create form views for particular locales or user roles.
FTS
A license permanently assigned to a user, enabling the user to access the licensed feature at any time. See also floating license, write license.
floating license
See full text search (FTS).

full text search (FTS)
A license temporarily allocated to a user who requests a license and who is designated as a floating license user. If no floating license is available at the time of the user request, the user must wait until one becomes available. See also fixed license, write license.
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 method available in AR System for searching text within documents attached to requests.
function
A named procedure that performs a distinct operation in AR System. The AR System C API has a set of functions used to accomplish AR System tasks. Additionally, AR System contains table functions that you can use in workflow to perform mathematical operations on table data.
82
Concepts Guide
Glossary
functional currency type
hierarchical groups
An alternative currency type to which the value in a currency field is converted. Values for functional currencies are calculated according to currency conversion ratios maintained in a form on the server. Functional currency values are stored as part of the data in the currency field. Users can search for and view them. Workflow can access them. See also currency data type, allowable currency type.
global field
Groups that are related by assigning the Parent Group field in the Group form. The hierarchy consists of a parent group and one or more child groups. A child group can also be a parent to another child group. See also ancestor group, child group, dynamic permissions inheritance, parent group, and static permissions inheritance.
home page
A display-only field whose value is the same across all forms that contain the field as long as the user is logged in. See also window-scoped global field.
group
A category in AR System used to define user access to form fields and functions. AR System defines several special groups: Public, Administrator, Sub Administrator, Customize, Submitter, Assignee, and Assignee Group. You can define additional groups through the Group form. See also access control, explicit group, implicit group, computed group, dynamic group, permission, role, user.
Group form
A form that lists entry points. The entry points are displayed in an application list field. In BMC Remedy User, the home page form can be configured to open on user login by default. In browsers, users enter or click a link to a home page URL. See also entry point, application list field, entry point guide, form entry point.
image object
An image stored in the AR System database along with information defining the image as an AR System object. If you use the same image in more than one location, such as the background for a related set of forms, you store the image once as an image object and then include it by reference in form view and field display properties.
implicit group
The form in which you can create, modify, and delete explicit groups and assign floating licenses to them. See also explicit group, license.
guest user
Unregistered user with a limited set of capabilities (can submit and possibly review requests). An administrator can specify whether unregistered users are allowed at your site.
GUID field
A group to which users are automatically assigned according to the contents of certain fields in a request, such as Submitter and Assignee. See also dynamic group, explicit group, group.
import
A field that is automatically populated with a globally unique identifier (GUID) when a request is saved.
guide
1. The BMC Remedy Developer Studio command that transfers object definitions from an export file to the current server. 2. The BMC Remedy Data Import command that transfers one or more data entries from an archive file to a form. See also export.
independent copy
See active link guide and filter guide.

hidden field
A field on a form that is not visible to a user.
A modifiable copy of a distributed request that is not part of an ownership chain. Independent copies cannot receive updates from the master copy, but they can start new ownership chains. See also Distributed Server Option (DSO), ownership chain.
Glossary 83
integer data type
main form
The data type used for fields that contain numeric values from 2147483647 to 2147483647. The range for a field can be limited by an AR System developer.
join form
A form that users interact with directly. An application can have more than one main form. Main forms are sometimes called primary forms or consoles.
main window
A type of form that contains information from two or more AR System forms. Although join forms function similarly to regular forms, they do not store data. A join form references data stored in the forms used to create the join form.
keyword
The BMC Remedy User window that displays a form in the Details pane and, optionally, the results of a search in the Results pane and prompt text in the prompt bar. The main window includes a menu bar and optional status bar, toolbar, and macro bar.
mapping
A variable whose value is defined by AR System. For example, $USER$ represents the name of the user currently logged in. Keywords can be used in qualifications for searches, search menus, workflow, and macros or to specify a value in the Set Fields action for active links, filters, and escalations.
license
See distributed mappings.

mapping history
See fixed license, floating license, read license, restricted read license, write license.
local application
Records stored in a forms Mapping History distributed field. A mapping history record is created each time that a distributed transfer occurs. The record includes the date and time of transfer, source request ID, source form, source server, and mapping name. See also Distributed Server Option (DSO).
master copy
An application that uses permissions based on groups and that is intended for use on a limited number of servers. See also application, deployable application, role.
macro
The copy of a distributed request that has ownership. See also Distributed Server Option (DSO).
Master Flag
A set of operations in BMC Remedy User recorded for later execution. Macros are useful for automating frequently used or complex operations.
macro bar
A basic distributed field that indicates whether a distributed request is the master (has ownership). See also Distributed Server Option (DSO).
mid tier
The row of buttons below the menu bar in BMC Remedy User that provides easy access to commonly used macro commands. Macro commands are also available from the Tools menu.
mail template
A component of AR System consisting of addin services that communicate between AR System servers and various clients. BMC Remedy User can communicate directly with AR System servers. Browsers, however, must use the mid tier to communicate with AR System servers.
navigation field
A template used to submit a request by email. The export command can be used to generate templates from an existing form.
A field that enables users to navigate through screens in an application quickly and easily.
84
Concepts Guide
Glossary
notification
panel holder field
A message to a user from workflow. Notifications can be sent by various mechanisms, including alerts and email. See also alert, email engine.
object modification log
A feature of the AR System server that logs all changes made to an object and that can save a copy of an object in a definition (.def) file each time that the object is changed.
object reservation
A field that contains one or more panel fields. Panel holders enable groups of fields to be organized and displayed in the same area of a form. They manage various panel layouts, including tabbed, collapsible, splitter, and accordion. See also panel field.
parent group
A feature of the AR System server and BMC Remedy Developer Studio used to prevent others from modifying objects that are in use.
ODBC
See AR System ODBC driver.

operator
Any explicit group that has a defined hierarchical relationship to another group (the child group) through the Parent Group field in the group form. Where allowed by the permissions inheritance properties, the parent group inherits the permissions assigned to the child group for the object. See also ancestor group, child group, dynamic permissions inheritance, hierarchical groups, and static permissions inheritance.
pending distributed item
A function that is used to define advanced searches or to build qualifications.

ownership
In a distributed environment, the ability to update a request in an ownership chain. Ownership can be transferred from the original request to a copy, and ownership can be returned. See also Distributed Server Option (DSO), independent copy, ownership chain.
ownership chain
A distributed operation waiting to be performed. Pending operations typically occur because a specified transfer interval has not been met or because network or server problems exist in a distributed environment. Pending distributed items are listed in the Distributed Pending form. Failed pending distributed items are listed in the Distributed Pending Errors form. See also Distributed Server Option (DSO).
permission
A series of distributed requests representing a history of transfers with ownership. See also Distributed Server Option (DSO), independent copy, mid tier.
packing list
A set of associated server objects that can be viewed as a work space in the server window or used in external utilities.
page field
The property setting that controls who can view and change individual fields on a form and who can access certain types of objects, including active links, active link guides, and applications. See also access control, group, role, user.
plug-in
See panel field.

panel field
A type of field that acts as a container in which related fields can be grouped. A panel field can stand alone or be managed by a panel holder field. In previous releases, called a page field. See also panel holder field.
An auxiliary program that works with the AR System server to enhance its capabilities. A plug-in is a dynamically linked library (DLL) on Microsoft platforms, a shared library on UNIX platforms, or a Java archive (JAR) on all platforms. The plug-in server loads plug-ins at run time.
Glossary
85
plug-in server
request
A server that loads and executes plug-ins. The plug-in server is a companion to the AR System server. It loads the ARDBC, AREA, or filter API plug-ins at run time.
pools
See distributed pools.

preference server
A collection of information that describes something, such as a user, a problem, or a service. When a form is filled in and submitted to AR System, the system creates a request. A request is equivalent to a record in the database. In AR System APIs, requests are called entries. See also form.
request ID
An AR System server that stores user preferences centrally in the AR System User Preference form.
prompt bar
A unique identifier generated by AR System for each request. See also Request ID field.
Request ID field
The part of the main window in BMC Remedy User that displays instructions or useful information about the form it is attached to.
Public group
A core field on a form that contains the request ID. In join form entries, the Request ID field contains the request ID for each of the underlying forms, separated by a vertical bar.
reserved field
One of several special access control groups that AR System provides. Every user is automatically a member of this group.
qualification
A filter or search criterion including field references, values, and arithmetical and relational operators used to determine how to process a request or to find a set of data.
query-by-example (QBE)
A data field that has a predefined special purpose in AR System. If you add a reserved field to a form, the field retains its special behavior and use.
restricted read license
A method for visually describing a database search. An empty form is displayed, and the search conditions are entered in their respective fields. AR System turns the visual query into the command language, such as SQL, required to query the database.
read license
A license that allows users to search AR System forms and submit requests but does not allow users to modify requests under any condition. It does, however, allow the same login to access AR System from multiple computers simultaneously. See also read license.
results list
A license that allows users to search AR System forms and to submit requests but not to modify requests. See also restricted read license, write license.
real data type
A list of requests that match a search. Multiple rows (or requests) in the results list that meet specified criteria can be selected for further processing.
Results pane
The data type used for fields that contain floating-point numbers. The range and precision can be set by AR System developers.
regular form
The part of the form window in a browser or in BMC Remedy User that displays the results of a search.
return
See distributed return.
A form used to manipulate and display data. Regular forms and their contents are stored in database tables created, owned, and managed by the AR System server.
86
Concepts Guide
Glossary
role
server group
In a deployable application, a configuration that defines access to form fields and server objects. Roles are defined in the Role Mapping form and then mapped to groups on the server on which the application is installed. Different groups can be mapped to the same role for each development state of the application. See also access control, application state, deployable application, group, permission, Roles form, user.
Roles form
A group of AR System servers configured to share the same database. See also AR System server.
server tier
The architectural level consisting of the AR System server that controls access to the data and any supporting services called or used by the AR System server.
Simple Object Access Protocol (SOAP)
The form in which roles are created and mapped to groups for each application state. See also application state, group, role.
schema
The primary transport protocol for messages shared by applications in web services. SOAP is an XML-based packaging format for the transferred information. It contains a set of rules for translating applications and platform-specific data types into XML.
SQL menu
See form.
search
The process by which users display a subset of requests according to search criteria that they define.
search menu
A menu whose items are based on data retrieved from a direct SQL command to a SQL database.
static permissions inheritance
A menu whose items are based on data retrieved from a search of an AR System form. See also dynamic menu.
Section 508
A law that requires U.S. federal agencies electronic and information technology to be accessible to people with disabilities (visual, motor, and auditory impairments).
selection data type
An object property that controls whether the ancestor groups of a group in the permission list of the object are granted the same access to the object as the group in the permission list. See also ancestor group, child group, dynamic permissions inheritance, hierarchical groups, and parent group.
status bar
The data type used for fields with a set of mutually exclusive options. Multiple options are displayed as option (radio) buttons or as a list. A single option can be displayed as a check box.
selection list
The part of a main window in an AR System client that displays instructions or useful information to the user.
Status field
The core field in which AR System tracks the various stages of the resolution process for a request.
status history
A list that appears when an active link performs a search that returns more than one request.
server
A field that displays information about the progress of a request.

Sub Administrator group
See AR System server, BMC Remedy Approval Server, DSO server, plug-in server, preference server.
One of several special access control groups that AR System provides. Members of this group have limited administrative access to AR System as defined by an administrator. See also Administrator group, explicit group.
Glossary
87
subadministrator
tooltip
A member of the Sub Administrator group.

Submitter group
One of several special access control groups that AR System provides. The user whose name is in the Submitter field on a request automatically belongs to this implicit group for that request. See also Assignee group, Assignee Group group, implicit group.
supporting form
A brief informational message displayed when a user interacts with an objectsuch as a table row, attachment, or field labelon 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.
transfer
See distributed transfer.

transfer mode
A form that supplies information needed by another form. See also main form.
table field
A field that displays data from other requests in the current request. A table field can appear in a list view format (with rows and columns), a tree view format, or a cell-based format.
task
In a distributed environment, one of four types of distributed transfers (data only, data + ownership, independent copy, copy + delete) that determine whether the copy of the request is sent with ownership and whether the original is deleted. See also Distributed Server Option (DSO).
trim data type
A shortcut or link created in BMC Remedy User that enables users to quickly open a specific form, search, application, or active link guide.
time data type
The data type of fields that enhance a forms usability and appearance. Trim includes lines, boxes, text, and URL links. These fields do not contain data.
update
The data type used for fields containing time values. Time values are stored as the number of seconds from 12:00:00 a.m. See also date/ time data type.
toolbar
See distributed update.

user
Any person with permission to access AR System. See also access control, group, permission.
user default
1. Standard: In BMC Remedy User, the row of buttons below the menu bar that provides easy access to commonly used menu commands. In a browser, toolbar buttons along the top of the form provide the equivalent functionality of menus and toolbars in BMC Remedy User. 2. Formspecific: A separate toolbar with additional icons that can appear on certain forms.
toolbar button
A value for a field that a user can predefine. A user default overrides an AR System developer default in BMC Remedy User. See also administrator default.
User form
The form in which users are added to AR System and in which each users group membership, login, and license information are specified.
variable
An icon for a menu item that triggers an active link. See also button field.
A data element that changes according to conditions.
88
Concepts Guide
Glossary
vendor form
workflow
A form used to connect to external data sourcessuch as text or spreadsheet data residing on local or remote serversthrough an ARDBC plug-in. See also AR System database connectivity (ARDBC).
view
1. A set of business processes used to run a company. 2. The automation of business processes through actions performed by active links, filters, and escalations.
write license
See form view.

view field
A field that provides a browser window in a form. Can be used to display a URL, the contents of an attachment, direct HTML text, or content formatted by a template.
view form
A license that allows a user to modify and save data in existing requests, subject to field and form permission settings. See also fixed license, floating license, read license, restricted read license.
XML Schema or XML Schema Definition (XSD)
A means of defining the structure, content, 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.
Glossary
89
90
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
access control about 49 groups, about 50 groups, membership 52 groups, types 51 hierarchical 53 licensing and 56 multitiered 53 permissions, additive 52 role-based 52 users and 50 actions about workflow 40, 41 Change Field 41 Close Window 41 if/else 40, 45, 46 Message 42 Notify 42 Open Window 42 Push Fields 42 Run Process 42 Service 43 Set Fields 43 active links about 22 API calls and 39 execution options 43 execution order 44 guides 40 user-controlled execution options 44 adaptability, AR System 13 additive permissions 52 Administrator access control group 51 administrators, responsibilities 24 AIE 17 Alert List form 16 alert list tables 32 alerts 16 analytics 61 animal tracking example application 63 Apache Tomcat 18 API calls, workflow and 39 application list fields 32 application programming interfaces. See API applications about 21, 35 animal tracking example 63 components 21 deployable 35 entry points 32 forms and 35 local 35 localizing 35 AR System database connectivity (ARDBC) database servers and 19 architecture, AR System 14 ARDBC. See AR System database connectivity asset management products 61 Assigned To field 33 Assignee access control group 51 Assignee Group access control group 51 attachment fields 32
B
BMC Analytics for BSM 61 BMC Atrium applications 61 BMC Atrium CMDB 61 BMC Atrium Core 61 BMC Atrium Integration Engine 17, 61 BMC Atrium Orchestrator 62 BMC Dashboards for BSM 61 BMC Discovery Solution 61 BMC Performance Manager 62 BMC Product Catalog 61 BMC Remedy Alert 16 BMC Remedy Asset Management 61 BMC Remedy Change Management 61 BMC Remedy Data Import 17 BMC Remedy Developer Studio 17 BMC Remedy Distributed Server Option 20, 60
Index
91
BMC Remedy Encryption Performance 60 BMC Remedy Encryption Premium 60 BMC Remedy Encryption products 60 BMC Remedy Incident Management 61 BMC Remedy IT Service Management Suite 61 BMC Remedy Knowledge Management 17, 61 BMC Remedy Mid Tier. See mid tier BMC Remedy Migrator 17, 60 BMC Remedy Problem Management 61 BMC Remedy Service Desk 61 BMC Remedy User 16 BMC Service Impact Manager 62 BMC Service Level Management 61 BMC Service Request Management 61 BMC Software, contacting 2 browsers, AR System user interface 16 BSM 12, 61, 62 Business Service Management 12, 61, 62 button fields 32 Button/Menu Field execution option 43 consoles, applications and 35 control fields 32 control panels 29 core AR System 59 core fields 33 Create Date field 33 custom access control groups 51 customer support 3 Customize access control group 51
D
dashboards 61 data fields 28 importing 17 tier, AR System 14 working with external 19 data dictionary menus 34 data fields 32 data forms 29 data visualization fields 32 database servers 19 databases forms in 29 platforms for AR System 19 deployable applications 35 developer clients 17 Developer Studio 17 developers, responsibilities of AR System 25 dialog boxes 29 discovery products 61 display-only fields 32 display-only forms 29 distributed computing environments 20 Distributed Server Option 20, 60 documentation, AR System 7 DSO. See Distributed Server Option dynamic groups 51
C
cell-based tables 32 Change Field action 41 change management products 61 character menus 34 client tier, AR System 14 client-based workflow 39 clients AR System 16 architectural tier 14 BMC Atrium Integration Engine 17 BMC Remedy Alert 16 BMC Remedy Data Import 17 BMC Remedy Developer Studio 17 BMC Remedy Knowledge Management 17 BMC Remedy Migrator 17 BMC Remedy User 16 browser-based 16 developer 17 integration 17 user 16 Windows-based 16 Close Window action 41 CMDB 61 components application 21 example of how they work 23 workflow 38 computed groups 51 configuration management database 61 92 Concepts Guide
E
else actions 40, 45, 46 encryption performance 60 premium 60 standard 60 engines JavaServer Pages 18 JSP 18 servlet 18 entry points 32
environments, computing distributed 20 heterogeneous 20 mixed 20 escalations about 23 execution options 45 events, triggering workflow with 39 examples animal tracking application 63 application components at work 23 AR System adaptability 13 service desk solution 12 execution options about workflow 38, 40, 43 active link 43 Button/Menu Field 43 escalation 45 event-triggered 39 filter 43 Gain Focus 43 Hover 43 Lose Focus 43 Menu Choice 43 Modify 43 Service 43 Submit 44 Table Refresh 44 time-triggered 39 user-controlled 39, 44 Window Open 44 execution order active link 44 filter 44 explicit access control groups 51 extending AR System 59 external data, working with 19 fields (continued) database table columns and 29 display-only 32 label styles 34 menu items 32 navigation 32 panel 32 table 32 toolbar buttons 32 trim 32 types 32 view 32 file menus 34 filters about 23 API calls and 39 execution options 43 execution order 44 guides 40 FIPS 60 Fixed licenses 57 Floating licenses 57 forms about 21, 28 Alert List 16 applications and 35 consoles 35 data 29 database tables and 29 display-only 29 fields 28 home pages 32 join 29 main 35 menus 22 primary 35 regular 29 supporting 35 types 29 vendor 29 view 19, 29 views 21, 30 foundation products, AR System 60 FTS 60 Full Text Search 60
F
Federal Information Processing Standards (FIPS) 60 fields about 28 application list 32 attachment 32 button 32 character 34 common characteristics 33 control 32 core 33 data 28, 32 data visualization 32
G
Gain Focus execution option 43 groups access control 50 computed 51 Index 93
groups (continued) dynamic 51 explicit 51 implicit 51 local applications and 35 membership in access control 52 regular 51 server 18 guides active link 40 filter 40 licenses (continued) pools 57 Read 56 Restricted Read 56 list view tables 32 local applications 35 locale 35 localizing applications 35 Lose Focus execution option 43
M
main forms 35 membership, access control group 52 Menu Choice execution option 43 menu item fields 32 menus about 22, 34 character 34 data dictionary 34 file 34 search 34 SQL 34 Message action 42 mid tier about 18 AR System architecture and 14 Migrator 17 mixed computing environments 20 Modified Date field 33 Modify execution option 43 multitiered access control 53
H
help desk products 61 heterogeneous computing environments 20 hierarchical access control 53 home pages 32 horizontal navigation fields 32 Hover execution options 43
I
if actions 40, 45, 46 implicit access control groups 51 importing data 17 incident management products 61 Information Technology Infrastructure Library 12 integrating with other products 17, 59 ITIL 12 ITSM 61
J
JavaServer Pages engines 18 join forms 29 JSP engines 18
N
navigation fields 32 navigation, consoles and 35 Notify action 42
K
keywords 47 knowledge management products 17, 61
O
Open Window action 42 OpenSSL Project 60 operating systems, AR System server 18
L
label styles, field 34 Last Modified By field 33 licenses access control and 56 Fixed 57 Floating 57 94 Concepts Guide
P
panel fields 32 performance encryption 60 permissions. See access control pools, license 57
predefined access control groups 51 premium encryption 60 primary forms 35 problem management products 61 Product Catalog 61 product support 3 Public access control group 51 Push Fields action 42 Service execution option 43 service level management products 61 service request management products 61 servlet engines 18 Set Fields action 43 Short Description field 33 SLM 61 solutions 61 SQL menus 34 SRM 61 Standard BMC Remedy Encryption 60 Status field 33 Status History field 33 Sub Administrator access control group 51 Submit execution option 44 Submitter access control group 51 Submitter field 33 support, customer 3 supporting forms 35
Q
qualifications 46 query-by-example (QBE) searches 19
R
Read licenses 56 records 21, 29 regular forms 29 regular groups 51 Request ID field 33 requests about 21 creating 29 database table rows and 29 Restricted Read licenses 56 results list tables 32 roles access control and 52 deployable applications and 35 Run Process action 42
T
table fields 32 Table Refresh execution option 44 tables, database 29 technical support 3 third-party products and AR System 62 tiers, AR System architecture 14 time, triggering workflow by 39 toolbar button fields 32 tree view tables 32 trim fields 32
S
search menus 34 searches about 19 FTS 60 query-by-example (QBE) 19 server tier 14 server-based workflow 39 servers AR System 18 database 19 database platforms 19 groups 18 operating systems for AR System 18 Service action 43 service desks example solution 12 products 61
U
user clients 16 user interfaces, AR System browser 16 Windows 16 users controlling execution options 44 users, access control and 50
V
variables, keyword 47 vendor forms 29 vertical navigation fields 32 view fields 32 view forms 19, 29 views, form 21, 30
Index
95
W
Window Open execution option 44 Windows, AR System user interface 16 workflow See also actions, execution options about 22, 37 actions 40, 41 AR System and 38 client-based 39 components compared 22, 38 event-triggered 39 execution options 38, 40, 43 guides 40 server-based 39 time-triggered 39
96
Concepts Guide
*160829* *160829* *160829* *160829*

*160829*

Concepts 7603

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Concepts 7603

Enviado por

Direitos autorais:

Formatos disponíveis

BMC Remedy Action Request System 7.6.

Contacting BMC Software

United States and Canada

Outside United States and Canada

Restricted rights legend

Support by telephone or email

Before contacting BMC Software

License key and password information

BMC Remedy Action Request System 7.6.03

Optimizing and Troubleshooting Guide Database Reference

Java Plug-in API

BMC Remedy Email Engine Guide Error Messages Guide

Master Index BMC Remedy Approval Server Guide

Description Information about new features, compatibility, and international issues.

Administrators Everyone Administrators Everyone

BMC Remedy Action Request System 7.6.03

About BMC Remedy Action Request System

Chapter 1 About BMC Remedy Action Request System

BMC Remedy Action Request System 7.6.03

Example of a service desk solution

Chapter 1 About BMC Remedy Action Request System

BMC Remedy Action Request System 7.6.03

Figure 1-2: AR System architecture

Chapter 1 About BMC Remedy Action Request System

BMC Remedy Action Request System 7.6.03

BMC Remedy User

BMC Remedy Alert

BMC Remedy Data Import

BMC Remedy Migrator

See Chapter 5, Extending AR System.

Chapter 1 About BMC Remedy Action Request System

BMC Remedy Action Request System 7.6.03

AR System mid tier

Query-by-example (QBE) Advanced search Predefined Recent

Chapter 1 About BMC Remedy Action Request System

BMC Remedy Action Request System 7.6.03

Heterogeneous environment provides flexibility

Distributed environments provide scalability

Figure 1-3: AR System in a distributed environment

Chapter 1 About BMC Remedy Action Request System

BMC Remedy Action Request System 7.6.03

Figure 1-4: Console application viewed in a browser

How application components work together

and location associated with the telephone number.

problem was solved.

Chapter 1 About BMC Remedy Action Request System

BMC Remedy Action Request System 7.6.03

Figure 1-5: Automated workflow example

Chapter 1 About BMC Remedy Action Request System

BMC Remedy Action Request System 7.6.03

Forms and applications

Forms and applications

BMC Remedy Action Request System 7.6.03

About AR System forms

About AR System forms

Forms and applications

BMC Remedy Action Request System 7.6.03

Figure 2-3: Types of AR System forms

About AR System forms

When creating form views, you can

Reports based on form data

Forms and applications