76729401 BMC Remedy Action Request System 7-5-00 Concepts Guide

www.bmc.com

BMC Remedy Action Request System 7.5.00

Concepts Guide

January 2009

If you have comments or suggestions about this documentation, contact Information Design and Development by email at [email protected].

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 INC2101 CITYWEST BLVDHOUSTON TX 77042-2827 USA

Telephone 713 918 8800 or800 841 2031

Fax 713 918 8000

Outside United States and Canada

Telephone (01) 713 918 8800 Fax (01) 713 918 8000

Copyright 19912009 BMC Software, Inc.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners.

IBM, DB2, and AIX are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.

Linux is the registered trademark of Linus Torvalds.

IT Infrastructure Library is a registered trademark of the Office of Government Commerce and is used here by BMC Software, Inc., under license from and with the permission of OGC.

ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office, and is used here by BMC Software, Inc., under license from and with the permission of OGC.

Oracle is a registered trademark of Oracle Corporation.

Sun, Solaris, Java, JavaServer, and JSP are trademarks or registered trademarks of Sun Microsystems, Inc., in the U.S. and other countries.

UNIX is the registered trademark of The Open Group in the US and other countries.

BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restricted rights notices included in this documentation.

Restricted rights legendU.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.

YoSu

Su

Yoht

Su

In senSuyo

Be

Ha

Customer Support

u can obtain technical support by using the Support page on the BMC Software website or by contacting Customer pport by telephone or email. To expedite your inquiry, please see Before Contacting BMC Software.

pport website

u can obtain technical support from BMC Software 24 hours a day, 7 days a week at tp://www.bmc.com/support_home. From this website, you can:

Read overviews about support services and programs that BMC Software offers.Find the most current information about BMC Software products.Search a database for problems similar to yours and possible solutions.Order or download product documentation.Report a problem or ask a question.Subscribe to receive email notices when new product versions are released.Find worldwide BMC Software support center locations and contact information, including email addresses, fax numbers, and telephone numbers.

pport by telephone or email

the United States and Canada, if you need technical support and do not have access to the Web, call 800 537 1813 or d an email message to [email protected]. (In the Subject line, enter pID:, such as SupID:12345.) Outside the United States and Canada, contact ur local support center for assistance.

fore contacting BMC Software

ve 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

If yme

License key and password information

ou have a question about your license key or password, contact Customer Support through one of the following thods:

E-mail [email protected]. (In the Subject line, enter SupID:, such as SupID:12345.)

In the United States and Canada, call 800 537 1813. Outside the United States and Canada, contact your local support center for assistance.

Submit a new issue at http://www.bmc.com/support_home.

CCore fields in a regular form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Attaching menus to fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Bundling forms into applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Localizing applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Chapter 3 Workflow 35

Workflow in general and in AR System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36ontents

Preface 7

AR System documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Chapter 1 About AR System 11

What is AR System?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Example of a service desk solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12AR System adaptability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

AR System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14AR System clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15AR System mid tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17AR System server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Database servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Heterogeneous environment provides flexibility. . . . . . . . . . . . . . . . . . . . . . . . . . . 19Distributed environments provide scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Application components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20How application components work together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Administrator responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Developer responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Programmer responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Chapter 2 Forms and applications 25

About AR System forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Types of forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Form views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Using fields in forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Characteristics common to all fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Contents 5

How workflow components differ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Events versus time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Client versus server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6Collections of workflow components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Workflow actions and execution options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Workflow actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Workflow execution options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Workflow qualifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Keywords in qualifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Chapter 4 Access control 47

About access control in AR System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48User and group access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Types of access control groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Additive permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Membership in multiple groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Role-based access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Multitiered access control model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51How licensing affects access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Chapter 5 Extending AR System 55

AR System foundation products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56BMC Atrium products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57AR Systembased solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Other BMC products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Integration with third-party products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Chapter 6 Putting it all together 59

About the wild animal park . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Goals of the animal tracking application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Planning and design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Analyzing data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Analyzing workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Defining business rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Mapping business rules to workflow components . . . . . . . . . . . . . . . . . . . . . . . . . . 62Considering integrations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Planning and design decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Decisions about forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Decisions about access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Decisions about business rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Decisions about workflow components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Putting the application to work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65A tiger is acquired . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65The tiger is injured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67The tiger is traded to another zoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Glossary 71

Index 85Concepts Guide

PA

T

C

In

Introduction to Application Development with BMC Remedy Developer Studio

Information about the development of AR System applications, including an introduction to using BMC Remedy Developer Studio.

Developers2

FoG

Wrm and Application Objects uide

Information about AR System applications and their user interface components, including forms, fields, views, menus, and images.

Developers

orkflow Objects Guide Information about the AR System workflow objects (active Developersreface

BMC Remedy Action Request System (AR System) is the foundation for a wide range of business solutions, from service desk call tracking to inventory management to integrated systems management.

This guide discusses core concepts of AR System. It is primarily for new administrators who will use AR System to create or modify applications. Other audiences, including business managers and persons evaluating and prototyping applications based on AR System, might also find this guide helpful. Procedures, performance, and other topics are documented in the books listed in the following section.

R System documents The following table lists documentation available for AR System products.

Unless otherwise noted, online documentation in Adobe Acrobat (PDF) format is available on AR System product installation DVDs, on the Customer Support website (http://www.bmc.com/support_home), or both.

You can access product help through each products Help menu or by clicking Help links.

itle Description Audience

oncepts Guide1 Overview of AR System architecture and features; includes information about add-on products that extend AR System functionality and a comprehensive glossary for the entire AR System documentation set.

Everyone

stallation Guide Instructions for installing AR System. AdministratorsPreface 7

links, filters, and escalations) and how to use them to create processes that enforce business rules.

8BMC Remedy Action Request System 7.5.00

C

B

In

OT

D

BSe

BG

C

C

Ja

Ja

BG

E

M

BSe

R

RIs

B

Tonfiguration Guide Information about configuring AR System servers and clients, localizing, importing and exporting data, and archiving data.

Administrators

MC Remedy Mid Tier Guide Information about configuring the mid tier, setting up applications for the mid tier, and using applications in browsers.

Administrators

tegration Guide Instructions for integrating AR System with external systems by using web services, plug-ins, and other products, including LDAP, OLE, and ARDBC.

Administrators/Developers/Programmers3

ptimizing and roubleshooting Guide

Information about monitoring and maintaining AR System and AR System applications to optimize performance and solve problems.

Administrators/Developers/Programmers

atabase Reference Database administration topics and rules related to how AR System interacts with specific databases; includes an overview of the data dictionary tables.

Administrators/Developers/Programmers

MC Remedy Distributed rver Option Guide

Information about implementing a distributed AR System server environment with BMC Remedy Distributed Server Option (DSO).

Administrators

MC Remedy Flashboards uide

Instructions for creating, modifying, and administering flashboards to display and monitor AR System information.

Administrators/Developers

API Reference Information about AR System data structures, C API function calls, and OLE support.

Programmers

API Quick Reference Quick reference to C API function calls. Programmers

va API Information about Sun Java classes, methods, and 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.

Programmers

va Plug-in API Information about Java classes, methods, and variables used 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.

Programmers

MC Remedy Email Engine uide

Instructions for configuring and using BMC Remedy Email Engine.

Administrators

rror Messages Guide Descriptions of AR System error messages. Administrators/Developers/Programmers

aster Index Combined index of all books. Everyone

MC Remedy Approval rver Guide

Instructions for using BMC Remedy Approval Server to automate approval and signature processes in your organization.

Administrators

elease Notes Information about new features, compatibility, and international issues.

Everyone

elease Notes with Open sues

Information about new features, compatibility, international issues, installation planning, and open issues.

Everyone

MC Remedy User Help Instructions for using BMC Remedy User. Everyone

itle Description AudienceConcepts Guide

AR System documents

BH

B

BC

T1 The full title of each guide includes BMC Remedy Action Request System 7.5.00 (forexample, BMC Remedy Action Request System 7.5.00 Concepts Guide).2 Application developers who use BMC Remedy Developer Studio.3 C and Java programmers who write plug-ins and clients for AR System.

MC Remedy Data Import elp

Instructions for using BMC Remedy Data Import. Administrators

MC Remedy Alert Help Instructions for using BMC Remedy Alert. Everyone

MC Remedy Mid Tier onfiguration Tool Help

Instructions for configuring BMC Remedy Mid Tier. Administrators

itle Description AudiencePreface 9

10

BMC Remedy Action Request System 7.5.00Concepts Guide

Chapter

1 About AR SystemEvery company, whether it makes bicycles or provides worldwide telecommunications services, has its own business needs and processes. BMC Remedy Action Request System (AR System) enables you to automate many business processes without learning a programming language or complex development tools.

This chapter introduces AR System architecture and application components and explains how they fit together to address your organizations needs.

The following topics are provided:

What is AR System? (page 12) AR System architecture (page 14) Application components (page 20) Administrator responsibilities (page 23) Developer responsibilities (page 23) Programmer responsibilities (page 23)Chapter 1 About AR System 11

12


W

Exhat is AR System? AR System is a professional development environment that

Leverages the best practices of the IT Infrastructure Library (ITIL)

Provides a foundation for Business Service Management (BSM) solutions

Using AR System, nonprogrammers can build powerful business workflow applications and deploy them simultaneously in web, Windows, UNIX, and Linux environments.

Applications built with AR System can automatically track anything that is important to the processes in your enterprise. Companies use AR System applications to track such diverse items as stock trades, benefits data, inventory assets, spare parts, and order fulfillment. One of the most common uses of AR System is to automate internal service desks. The following example illustrates a service desk solution in which AR System solves an employees problem.

ample of a service desk solution Ramonas printer would not work, so she logged in to her companys 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.

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. Concepts Guide

What is AR System?

AR System adaptabilityAR 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.

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.

Ready-to-useapplications

AR SystemAdaptable applications

Development toolsAR System provides a platform on which a rich collection of ready-to-use applications can run. It also provides the customization power traditionally associated with development tools.Chapter 1 About AR System 13

14


AR System architecture AR System is based on a multitiered client/server architecture:

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 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.

Figure 1-2: AR System architecture

AR System server

Mid Tier and Web services

ClientTier

MidTier

ServerTier

DataTier

AR Systemdatabase

Otherdatabases

Other datasources

Desktopapplications Browser

The data tier holds data that applications create and manipulate.

The AR System server runs applications and workflow. It also enforces business logic.

The mid tier lets you access the AR System server from a browser and makes web services accessible.

Client tools are used to access, manage, and build applications.Concepts Guide

AR System architecture

AR System clients AR System clients can be broadly divided into user clients and developer clients.

User clients The user clients use standard interfaces for their respective environments:

User client Platform Description

Browsers Provide a user interface to AR System applications through the mid tier

Can be used for these functions: 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 User Provides a Windows-based user interface to AR System applications

BMC Remedy Alert Windows Sometimes considered a desktop pager, this client notifies users about events by flashing an icon, beeping, playing a sound file, running a process, or opening a message window. For example, it can display a message (an alert) to notify service desk personnel that a reported problem has been assigned to them.

Note: A similar functionality is available through browsers. In browsers, alerts are displayed in the Alert List form, which can be refreshed automatically at specified intervals or manually at any time. Chapter 1 About AR System 15

16

BMC Remedy Action Request System 7.5.00Developer clients The developer clients are used to create, modify, and extend AR System applications:

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.

Developer client Description

BMC Remedy Developer Studio Used to create and modify all the components of an AR System application, such as forms and workflow elements.

BMC Remedy Data Import Used to load external data into AR System forms. For example, employee information can be extracted from a human resources application and loaded into the People form as a batch process, eliminating the need to retype data. This client is also used to import AR System data from one AR System server to another.

BMC Remedy Migrator Used to migrate applications, objects, and data between servers, servers and files, or files. This client reduces the difficulty and time required to synchronize AR System servers in development and production environments.

Note: For limitations on using BMC Remedy Migrator with other BMC applications, see the BMC Remedy Migrator Release Notes on the Customer Support website (http://www.bmc.com/support_home).Concepts Guide


A

AR System mid tier BMC Remedy Mid Tier translates client requests, interprets responses from the server, handles web service requests, and runs server-side processes that provide AR System functionality to web clients. For example, unlike BMC Remedy User, a browser is a generic client that has no inherent knowledge of applications that run in it. By acting as an interpreter, the mid tier enables a browser to become a fully functional AR System client.

The mid tier requires a supported Sun JavaServer Pages (JSP) engine. For example, you can install the Apache Tomcat servlet engine with the mid tier. For a list of other supported JSP engines, see the BMC Remedy compatibility matrixes on the Customer Support website (http://www.bmc.com/support_home).

R System server The AR System server processes all data entered through a client. As the workflow engine between client and database, the server writes data to the database when a request is created and retrieves data from the database when a client requests it. The server verifies that a user has permission to perform each transaction, thereby enforcing any access control defined in an application. The server also continuously evaluates the data in the database and each transaction to determine whether the server should perform workflow. The server might also perform workflow on a timed basis. See Chapter 3, Workflow.

The AR System server communicates with the mid tier, AR System clients, and external applications by means of a well-defined API. The server is available for each of these operating systems:

Hewlett Packard HP-UX

IBM AIX

Linux (Red Hat and Novell SuSE)

Microsoft Windows Server

Sun Microsystems Solaris

NOTE For the most accurate information about supported platforms and software, always see the BMC Remedy compatibility matrixes on the Customer Support website (http://www.bmc.com/support_home).

Server groups To provide scalability and increase reliability, you can connect a group of servers to the same database and manage them as a unit. Servers in a group act as a single server to support the applications that they run. They can be configured to spread the load of shared services, and they can provide backup to each other to ensure that those services are always available. Chapter 1 About AR System 17

18


Database servers AR System uses standard relational databases to store and retrieve data. Architecturally, the database server processes are completely separate from the AR System server processes. Physically, the database server processes can run on the same computer as the AR System server or on a different computer.

Because the AR System server manages all workflow, applications are independent of the database. Therefore, applications created on an AR System server running one type of database can easily be moved to a server running a different type of database. BMC provides a simple export/import utility for this purpose.

AR System can use any of these database platforms:

IBM DB2

IBM Informix Dynamic Server

Microsoft SQL Server

Oracle

Sybase ASE

NOTE For the most accurate information about supported platforms and software, always see the BMC Remedy compatibility matrixes on the Customer Support website (http://www.bmc.com/support_home).

AR System workflow components can search for records (requests) in the AR System database and act on the results of the search. Clients can use the following types of searches:

Query-by-example (QBE)

Advanced search

Predefined

Recent

An administrator can create and store searches that are commonly performed by users. A user can define personal searches for forms to which the user has access.

AR System can also work with data stored in external databases and other data sources that are not managed by AR System. AR System accesses these data sources through view forms. In addition, AR System can use AR System database connectivity (ARDBC) to work with data not stored in databases as if the data were locally owned. Concepts Guide


H

Deterogeneous environment provides flexibility Because the multiple layers of AR System are independent of one another, you can combine platforms to fulfill different functions. The heterogeneous environment enables you to mix and match clients and servers. For example:

BMC Remedy Developer Studio on a computer running Windows can manage forms on a UNIX or Linux server.

Browsers can use a Windows-based mid tier to access forms on a UNIX server.

An AR System server on Windows can interact with a database on UNIX.

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

Figure 1-3: AR System in a distributed environment

AR SystemClients

AR System ServerTokyo

with Distributed Server Option(Owner of Request)

Transfer

Update

AR System ServerNew York

with Distributed Server Option

AR SystemClientsChapter 1 About AR System 19

20


Application components Applications developed with BMC Remedy Developer Studio are fully customizable and extensible. You can add your own fields, objects, and templates to any application, whether it was created by you, purchased from BMC, or acquired from a third party. AR System provides extensive authoring capabilities for applications built for web and Windows environments.

This section introduces the main components of an AR System application.

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. See Chapter 2, Forms and applications.

Figure 1-4: Console application viewed in a browserConcepts Guide

Application components 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 Attaching menus to fields on page 32.

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.

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. Chapter 1 About AR System 21

22


How application components work together In the example on page 12, when Ramona entered her telephone number into the Telephone # field, the following sequence occurred, as illustrated in Figure 1-5:

1 An active link searched the Employee form to retrieve the name, configuration, and location associated with the telephone number.

2 After Ramona finished entering information into the form and submitted it, filters triggered an external paging system integrated with AR System to notify Becky that Ramonas printer was not working.

3 Becky fixed the problem.

4 Becky changed the status of the request, and a filter notified Ramona that her problem was solved.

Figure 1-5: Automated workflow example

.

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.

1

2

3

4

Active link

Data entry finished

Problems FormTelephone #

Name

Configuration

Location

Status

Employee Form

Name

Configuration

Location

555-1212

Ramona

PC

B2

Becky paged

When Statusbecomes "solved,"

a filter notifiesRamona

Problem solved

Filters fireConcepts Guide

Administrator responsibilities

A

D

Pdministrator 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

eveloper 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

rogrammer 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 SystemChapter 1 About AR System 23

24


Chapter

2 Forms and applicationsForms are the foundation of AR System. Forms can be grouped into applications.

This chapter describes forms and how forms are used in applications. It also describes localization features for applications.


About AR System forms (page 26) Using fields in forms (page 29) Attaching menus to fields (page 32) Bundling forms into applications (page 33) Localizing applications (page 33)Chapter 2 Forms and applications 25

26


About AR System forms A form captures and displays information. 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 Using fields in forms on page 29). Some fields can have attached menus that help users fill in the form (see Attaching menus to fields on page 32).

Figure 2-1: Example AR System form

Each form in an application is like a template. When a user opens a form to perform a task, the template is presented to help the user complete the task. When the form is filled in and submitted to AR System, the system creates a request, also known as a record in database terms.Concepts Guide

About AR System forms

Ty

Fo

R

D

Jo

V

VUsers can create, modify, or search for requests if they have appropriate access permissions (see Chapter 4, Access control). Users can also create reports based on requests that match their search criteria. They can use the AR System native reporting capability or Crystal Reports, a reporting package that you can integrate with AR System.

Forms are stored as tables in the database. Each data field on the form corresponds to a column in the table. A request corresponds to a row (or record) in the table.

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

pes of forms You can create the following types of forms, as illustrated in Figure 2-3:

Help Desk Form

Request ID Submitter Problem Impact Assigned To Status000056 Adrian Web pages load slowly Low Paul Assigned000032 Rachel Printer not working Medium Laura Closed000019 Cynthia Can't send email High Rob Work in progress000092 Steve Network is down High Laura Escalated000018 Hannah Need more memory Medium Paul Closed

Field(column)

Request(row)

rm type Description

egular 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.

isplay-only These forms contain display-only fields that enable users to accomplish specific tasks. These forms are typically used to create control panels, which are launch points from which users choose other tasks. Display-only forms can also be used to create dialog boxes, which prompt users as they fill out a form. Display-only forms do not contain data, so no database tables are associated with them.

in 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.

iew 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.

endor 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.Chapter 2 Forms and applications 27

28

BMC Remedy Action Request System 7.5.00Figure 2-3: Types of AR System forms

Database external to AR System

Other data sources

AR Systemdatabase

Information displayed in regular forms is stored in AR System database tables.

Display-only forms are used to create dialog boxes, control panels, and consoles. They have no database table associated with them.

You can merge information from two forms into a join form.

Regular Form

AR System database

Database external to AR System

Field 1

Field 2

Field 3

Form

Field 1

Field 2

Field 3

Service Console Display-Only Form

New Request Search Requests

Form

Field A

Field B

Field C

View forms are used to connect to database tables that were not created by AR System.

Vendor FormField 1

Field 2

Field 3

View Form

Field 1

Field 2

Field 3

Join FormField 1

Field 2

Field A

Field B

Vendor forms are used to connect to external data sourcessuch as text files, spreadsheets, or database tables residing on local or remote serversthrough an ARDBC plug-in.

ARDBC plug-inConcepts Guide

Using fields in forms

Fo

U

Fi

D

Trm 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.

You can create as many views of a form as you need. For example, you can provide views customized according to the following criteria:

Users roles (requesters, managers, and so forth)

Size of the screen (for example, laptop or desktop)

Language or locale (for example, Brazilian Portuguese)

When creating form views, you can

Change the layout of the form

Use different fields in different views

Tailor views to provide the best result in the target display environment, such as browsers

Use terminology or language specific to the group using the view

sing fields in formsFields enable you to control how information is captured and displayed in forms. You can include the following types of fields in forms:

eld type Description

ata 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.

able 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.Chapter 2 Forms and applications 29

30


C

A

V

D

A

Hve

C

P

T

FiYou 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.

haracteristics 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.

ttachment Attaches files to requests.

iew 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.

ata visualization Augments AR System with HTML-based contentsuch as web pages, flashboards, and other graphicsthat can interact with the fields parent form through workflow.

pplication list Displays a list of entry points. An entry point is a link that users click to open forms on the correct server in the required mode (New or Search). AR System automatically generates the contents of the application list. The entry points that a user sees in the list are only those to which the user has access.Any form that contains an application list field can be used as a home page. A home page is a single point of access into AR System.

orizontal and rtical navigation

Enables users to navigate to the correct screen in an application quickly and easily.

ontrol Triggers active links. Control fields include buttons, menu items, and toolbar buttons.

anel 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.

rim Adds boxes, lines, and text to enhance the visual appearance of forms.

eld type DescriptionConcepts Guide

Using fields in forms

Core fields in a regular form A regular form automatically contains these core fields, as shown in Figure 2-4:

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.

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.

Figure 2-4: New regular form with core fields

The following table shows the meaning of the field label styles:

Style Description

Bold Field requires a valuedefault, user-entered, or from workflowwhen a user submits a request.

Italic Field is automatically populated by AR System.

Plain Field is optional. Users can enter information in it or leave it empty. Chapter 2 Forms and applications 31

32


Attaching menus to fieldsUse menus to help users enter data and to ensure that the data is consistent. You can attach a menu to any character field (character fields are data fields that hold alphanumeric characters). Menus can be statically defined, dynamically built by searching AR System databases and external databases, or read from text files written by other applications.

Menus are separate objects stored independently of a form. This means that you can create a single menu and use it for multiple forms and for multiple fields in one form.

AR System defines these types of menus:

Menu type Description

Character Stored and maintained as a list of items in AR System. These menus are useful for fields that have a predefined series of choices that change infrequently. They can have submenus.

File Contains items that are created and maintained in a plain text file. The file can be stored on the system where BMC Remedy User is running or on the AR System server. File menus are convenient when you do not want to store the data in the AR System database. To change a file menu, simply update the file; the changes are applied when the menu is refreshed. File menus can have submenus.

Search Retrieves information from requests stored in AR System databases. The information is used to build a menu dynamically in the current form. Search menus are often used when the choices in a menu depend on values entered in fields on the current form.

SQL Also retrieves information from databases, but the databases can be outside AR System. When you access an SQL menu, AR System uses an SQL query to extract the data and then generates the menu from that data.

Data dictionary Retrieves lists of fields and forms from an AR System server. These menus are useful for creating special configuration interfaces. They are generally not used to help users perform their work.Concepts Guide

Bundling forms into applications

B

Lundling forms into applicationsAn AR System application is a server object that contains references to one or more forms. When an application references a form, AR System automatically includes all the workflow and other components (such as menus) associated with the form.

Sometimes a single form can contain all of an applications functionality. For example, a small application that tracks product defects can use a single defect-tracking form to capture and display all required information.

Most applications, however, need several forms to capture, track, and organize information. One or more forms make up the 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.

ocalizing 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.Chapter 2 Forms and applications 33

34

BMC Remedy Action Request System 7.5.00The 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

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.Concepts Guide

Chapter

3 Workflow Forms, with the help of menus, capture the crucial data needed to run your business. Processing that data in accordance with your business needs is the function of workflow. You use workflow componentsactive links, filters, and escalationsto enforce business rules in a variety of ways, including notifying people of events, escalating problems to a higher level, automatically routing information, and checking whether key data is correctly entered.

This chapter describes the workflow components.


Workflow in general and in AR System (page 36) How workflow components differ (page 36) Collections of workflow components (page 38) Workflow actions and execution options (page 38) Workflow qualifications (page 44)

For detailed information about workflow, see the Workflow Objects Guide.Chapter 3 Workflow 35

36


W

Horkflow in general and in AR System 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.

In AR System, workflow automates your companys processes through the use of active links, filters, and escalations. For example, if your organization decides that purchase orders for amounts above a certain level need director approval, you can design workflow that allows only correctly approved purchase orders to be automatically forwarded to the purchasing department.

You define AR System workflow by specifying the actions that active links, filters, and escalations should perform under specified circumstances. The circumstances are called execution options. You can create workflow components for a single form, or you can share workflow components with multiple forms. (Workflow components cannot exist independently of forms.)

Some of the actions that workflow components can take to automate processes and ease data entry include

Overriding user-entered values by changing them to values that you specify

Manipulating a form (for example, enabling or disabling fields, or changing menus associated with fields)

Checking for errors

Opening new windows for data entry or display

Communicating with users by means of onscreen messages or notifications sent by email, BMC Remedy Alert, or other methods

Running an active link guide or a filter guide as a subroutine (a predefined sequence of commands)

For a list of actions, see Workflow actions on page 39.

ow workflow components differ This table summarizes how and where you use workflow components:

Component Triggered by Where action is performed

Active link Events Client

Filter Events Server

Escalation Time ServerConcepts Guide

How workflow components differ

Ev

Cents versus time Filters and active links are triggered by events, such as a user action or a change in the state of some data. For example, a filter can notify a support manager whenever a request is submitted with a priority of High or Critical. The submission of the request is the event. Other events that can trigger filters are updating, deleting, and retrieving requests. Actions that can trigger active links include opening or closing a window, displaying a request, clicking a button on a form, pressing Enter when the cursor is in a field, or selecting a menu item.

Escalations implement time-based business rules. They are triggered by the passage of time. The trigger (or execution option) can be either absolute time, such as every day at 2:00 p.m., or a time interval, such as one hour between escalation runs. For example, an escalation can warn a group of users that in one hour their manager will be notified that a problem has been unsolved for too long.

lient versus server Active links are executed on the client side in response to actions that users perform in forms. For example, active links can change how a form looks or behaves, validate data entered by users, or use data in a form to find other data for the form.

Unless an active link queries the AR System server for information or runs a process on the server, it can complete its operation without sending a request to the server. This capability helps decrease overall network traffic and improves the performance of an application.

In contrast, filters and escalations are executed on the server. They implement business rules by examining newly created or changed requests and taking 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 37

38


C

Wollections 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.

orkflow 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. See Workflow qualifications on page 44.

You can specify a primary action and an alternative action. If an operation meets the qualification, the primary (if) action is performed; if not, the alternative (else) action is performed, as shown in Figure 3-2.

Figure 3-2: Example of workflow with qualification

Execution optionoccurs

Action

User clicks Display MyActive Cases button.

List displays all requestsassigned to the user.

Qualification:Last Name field

is filled in.

Met

Not met

Alternative action:Message displaysFill in last name.

Primary action: First Name, Extension,

and Email Addressfields are filled in from

a supporting form. User presses Enterin Last Name field.

Execution optionoccursConcepts Guide

Workflow actions and execution options

W

A

C

C

M

Norkflow actionsThe following table lists some of the actions that active links, filters, and escalations can perform. For a complete list, see the Workflow Objects Guide.

ction Description Active link Filter Escalation

hange Field Changes the appearance of fields. For example, a Change Field action can perform one or more of these actions: Moves the cursor or keyboard focus to a field. Hides or displays a field. For example, an active

link might hide all fields related to telephone problems when users report network problems. Changes a 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.

+

lose Window Closes the current window. +

essage 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.

+ +

otify 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.

+ +Chapter 3 Workflow 39

40


O

P

R

Se

Se

Apen Window Opens a window of any type in the client. The action can open a New window and load some default data. Or it can open a Modify window with requests matching a specified qualification.This action can also open a dialog box. Data can be passed between the dialog box and the window that calls it. Processing of active links from the calling window is suspended until the dialog box interaction is completed.

+

ush 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.

+ + +

un 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.

+ + +

rvice 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.

+ + +

t Fields Sets fields on a form to specified values. For example, a filter can automatically set the Status field to Assigned every time a name is entered into the Assigned To field.The value set in a field can be static (always the same), a keyword value, or a value retrieved from another data source.

+ + +

ction Description Active link Filter EscalationConcepts Guide

Workflow actions and execution options

W

Ex

B

G

D

HHH

L

M

M

Se

Su

T

Workflow execution optionsExecution 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.

ecution option Description Active link Filter

utton/Menu Field Executes when a user selects the button or menu item associated with the active link.

+

ain Focus Executes when a user or a Change Field action moves the cursor to a field.

+

isplay Executes after a request is loaded into a form but before the request appears in the Details pane.

+

over on Fieldover on Dataover on Label

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.

+

ose Focus Executes when a user or a Change Field action moves the cursor out of a field.

+

enu Choice Executes when a user chooses an item from a character menu associated with a specified field.

+

odify 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.

+ +

rvice Enables filters to be called by the Service action. +

bmit 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).

+ +

able Refresh 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.

+

indow Open Executes when a user opens a form or dialog box or changes a form to a different mode. This is especially useful for establishing initial environments. It executes before any data is loaded into the window.

+Chapter 3 Workflow 41

42

BMC Remedy Action Request System 7.5.00Execution 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.

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. Concepts Guide

Workflow actions and execution optionsEscalation 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 (see Workflow qualifications on page 44). 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

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.

1 p.m.

Escalation runs. Primary actionoccurs? No

2 p.m.

2:05 p.m.

3 p.m.

Business rule: If a high-priority request is not assigned within 3 hours, notify a manager.Escalation execution option: Run the escalation every hour on the hour.Escalation qualification: Priority = High Assigned = No Current Time Create Time >= 3 hoursEscalation primary (if) action: Notify manager about problem request.

Request B StatusPriority = HighAssigned = NoSubmitted 1.5 hrs ago

Request A StatusPriority = HighAssigned = NoSubmitted 2.5 hrs ago

Escalation runs. Request B StatusPriority = HighAssigned = NoSubmitted 2.5 hrs ago

Request A StatusPriority = HighAssigned = NoSubmitted 3.5 hrs ago

Manager assignsRequest A to

Yucheng Wong.

Escalation runs. Request B StatusPriority = HighAssigned = NoSubmitted 3.5 hrs ago

Request A StatusPriority = HighAssigned = YesSubmitted 4.5 hrs ago

Primary actionoccurs?Yes: Manager is notified about Request A status.

Primary actionoccurs?Yes: Manager is notified about Request B status.Chapter 3 Workflow 43

44


Workflow qualifications Specifying a qualification when you create an active link, filter, or escalation enables you to define the data condition that causes the workflow component to take action. You can use qualifications to check values in fields, the amount of time that has passed since a specified event occurred, and many other factors. For example, a qualification might check whether the priority of a request is High or Critical or whether the day is a weekend day.

Qualifications with active links and filters work differently from qualifications with escalations:

Active link and filter qualifications control which actions, if any, are run for the current request. For example, an active link can run actions whenever a specific field is filled in (execution option), or it can run actions whenever the field is filled in and the value in the field is invalid (qualification).

Escalations are run whenever the scheduled time arrives. The qualification is an essential part of most escalations, not simply a refinement. It determines the requests on which the primary (if) escalation actions are run. Without a qualification, the primary actions are run on every request (record) in the form to which the escalation is attached. For example, if an escalation simply sent a notification every hour (execution option), the notification would be meaningless. A meaningful escalation, however, might check every hour (execution option) whether three or more hours have elapsed since a request was submitted and the request is unassigned (qualification), and then send a notification listing the unassigned requests to a manager. If no requests meet the qualification, the escalation might specify alternative (else) actions that are executed once, such as sending the manager a notice that all requests comply with the assignment rule. For an illustration of how qualifications are used in escalations, see Figure 3-3.

For filters, the qualification can check the value of a field in the database, in the current transaction, or both. This makes it possible to check whether the value of the field is changing. For example, if you have a business rule that service desk requests can be closed only if they have been fixed, a filter could check all transactions that change the status of a request to Closed. If the database value of the status is Fixed, the request can be modified; otherwise, the change is not allowed.Concepts Guide

Workflow qualifications

Keywords in qualificationsKeywords are used to build qualifications. A keyword is a variable whose value is defined by AR System. Keyword names are uppercase and enclosed in dollar signs. For example, $USER$ represents the name of the user who is currently logged in, $TIMESTAMP$ represents the current date and time, and $OPERATION$ represents the operation currently in progress.

Keywords can be used almost anywhere a qualification can be defined or a value specified:

Defining qualifications for search menus and for workflow. For example, workflow can check the value of the keyword $OS$ to ensure that the operating system can run a process that you specify in workflow.

Specifying a value in the Set Fields action.

Defining searches and macros.

For a complete list of keywords, see the Workflow Objects Guide. Chapter 3 Workflow 45

46


Chapter

4 Access control Keeping information secure can be a major undertaking in client/server environments. It is sometimes a balancing act for administrators. You want to rigorously control who can access data, yet you do not want security to be so complex that it intrudes on your user community or is difficult for you to implement or maintain.

AR System enables you to meet these seemingly opposing security goals. It provides a rich set of features that protect your data from unauthorized access. In addition, it has a logical, multitiered access control structure that is straightforward for you to implement and for users to understand.

This chapter describes access control in AR System.


About access control in AR System (page 48) User and group access (page 48) Role-based access (page 50) Multitiered access control model (page 51) How licensing affects access control (page 53)Chapter 4 Access control 47

48


A

Ubout access control in AR System AR System enables you to control which users can access data and perform certain actions such as modifying a request or triggering an active link. User access is determined by these conditions:

The groups users belong to

The licenses users are granted

AR System uses a multitiered approach to control access at these points:

Server

Form (or table)

Field (or column)

Active link and active link guide

Request (or row)

This approach provides a wide range of control over data access, enabling you to restrict access broadly at the highest levels (server and form) and narrowly at the request and field levels. Because you can refine your data access criteria so precisely, you can use a single form for many different purposes simply by setting the appropriate permissions.

ser and group access Individuals who need to access AR System are registered as users by an administrator. The administrator then assigns the users to access control groups.

Each access control group is defined for a particular server. An access control group has permissions that determine whether and how its members can access application components, such as forms, requests, fields, active links, and active link guides. (Administrators can also set default permissions for each component type so that whenever they create a component, selected groups automatically have access to it.)

Users are assigned to groups according to their need to access information. For example, you might create a group called Employee Services Staff whose members are permitted to view and change only certain fields in an Employee Information form. You might have another group called Employee Services Managers whose members are permitted to view and change all fields in the Employee Information form, including salary information.

AR System has predefined groups that perform specific functions (see Types of access control groups on page 49). In addition, you can create any number of custom groups in AR System to enforce access control. You can also permit unregistered users to access AR System as guests. Guests are members of the predefined Public group.Concepts Guide

User and group access

Ty

A

Tco

E

Impes of access control groups This table lists the types of access control groups:

1 AR System provides these access control groups.2 You must add these access control groups to your system.

For more information, see the Form and Application Objects Guide.

dditive permissions Access control in AR System is additive. This means that each user in AR System starts out with no access permissions. Administrators then add users to access control groups as needed. In this way, AR System implements strict access control: administrators must make a conscious decision to add users to groups on a case-by-case basis.

ype of access ntrol group Description Predefined groups1 Custom groups2

xplicit A group to which you must assign users. Administrator Sub Administrator Customize

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.

plicit 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).

Public Submitter Assignee Assignee Group

Documents

76729401 BMC Remedy Action Request System 7-5-00 Concepts Guide