BMC Remedy Action Request System 7.0 Configuring

Transcription

1 BMC Remedy Action Request System 7.0 Configuring May 2006 Part No: 58466

2 Copyright BMC Software, Inc. All rights reserved. BMC, the BMC logo, all other BMC product or service names, BMC Software, the BMC Software logos, and all other BMC Software product or service names, are registered trademarks or trademarks of BMC Software, Inc. All other trademarks belong to their respective companies. BMC Software, Inc., considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable end user license agreement or nondisclosure agreement for the product and the proprietary and restricted rights notices included in this documentation. For license information about the OpenSource files used in the licensed program, please read OpenSourceLicenses.pdf. This file is in the \Doc folder of the distribution CD-ROM and in the documentation download portion of the product download page. Restricted Rights Legend U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section , DFARS , DFARS , DFARS , and DFARS , as amended from time to time. Contractor/Manufacturer is BMC Software, Inc., 2101 CityWest Blvd., Houston, TX , USA. Any contract notices should be sent to this address. Contacting Us If you need technical support for this product, contact Customer Support by at If you have comments or suggestions about this documentation, contact Information Development by at This edition applies to version 7.0 of the licensed program. BMC Software, Inc.

3 Contents Preface Audience AR System documents Learn about the AR System Developer Community Why should you participate in the Developer Community? How do you access the Developer Community? Chapter 1 BMC Remedy Action Request System 7.0 architecture AR System architecture overview BMC Remedy mid tier AR System server AR System and web services Creating and publishing a web service Consuming a web service Scalability Mid tier scalability AR System server scalability Working with a portmapper service in AR System Windows and portmapper services Configuring clients through environmental variables Contents 3

4 BMC Remedy Action Request System 7.0 Chapter 2 Obtaining and activating licenses Licensing overview License keys Contacting Customer Support Licensing a new AR System server Manually applying license keys Transferring server licenses to other servers Exporting licenses Importing licenses Chapter 3 Setting user preferences User preferences and customizations Local preferences Centralized preferences Creating a preference server Configuring clients to use a preference server Setting centralized preferences on Windows clients AR System User Preference form fields Common fields General tab Display tab (BMC Remedy User only) Color tab (BMC Remedy User only) Confirmation tab Report tab Logging tab Locale tab File tab (BMC Remedy User only) Advanced tab Home Page tab Alert tab Recent tab Edit tab Window tab Misc tab Web tab Setting centralized preferences on web clients Contents

5 Configuring Chapter 4 Defining your user base Licensing users License types Viewing user information Releasing floating licenses License pools Adding and modifying user information Allowing guest users Special submitter mode Validating password information Setting up an authentication alias User Name Alias Authentication String Alias Unique user logins Chapter 5 Configuring servers and clients Configuring AR System servers Server information Platform tab Server information Timeout tab Server information Licenses tab Server information Configuration tab Server information Log Files tab Server information Database tab Server information Server Ports and Queues tab Server information Connection Settings tab Server information Currency Types tab Server Information External Authentication tab Server information Advanced tab Server information Source Control tab Server information Server Events tab Configuring a server for development or production cache mode Configuring multiple servers Configuring multiple servers on one machine Configuring multiple servers to access the same database Running servers as part of a group Contents 5

6 BMC Remedy Action Request System 7.0 Running a stand-alone AR System server on Windows Configuring firewalls with AR System servers Configuring clients for AR System servers Configuring a server to use plug-ins Configuring the AR System server for external authentication (AREA) Configuring a mail server Configuring a server for alerts Configuring and using the AR System Server Administration plug-in Configuring AR System to use the Server Administration application Administering your server from AR System clients Chapter 6 Working with the alert system Alert system architecture Alert Events form Viewing alerts CleanupAlertEvents escalation Managing registered users Working with versions of the AR System prior to 5.x Upgrading the server but not the clients Upgrading or installing clients but not the server Enabling alerts on the Web Chapter 7 Importing data into AR System forms Understanding the import process Understanding data mapping Understanding preferences Preparing to import Defining BMC Remedy Import preferences Importing data Using a saved mapping file Using the import log file AR XML data All other data types Contents

7 Configuring Chapter 8 Using full text search Overview of full text search Accruing and weighting results with FTS Sorting requests by weight Using the Ignore Words List Who can perform a full text search? Using FTS Performing a search in a field indexed for FTS Searching for word stems Using wildcards Using the QBE method Using the advanced search bar method Adding a form search field to a form Parametric full text search Search strategies Search issues Limitations of FTS Administering FTS Selecting fields for FTS indexing Full text search indexing Indexing for attachments Multiple languages and attachment file formats Reindexing FTS configuration options Debugging FTS FTS logging Upgrading FTS Assigning FTS licenses to users Defining a field for FTS in the Field Properties window Estimating the size of the FTS index Displaying FTS weight in a results list Contents 7

8 BMC Remedy Action Request System 7.0 Appendix A Working with the Request ID field Working with the Request ID field Changing the next available ID for new requests Changing the Request ID field length or prefix Preserving existing Request ID field values Changing existing Request ID field values to a new format Updating the Request ID field in other AR System tables Appendix B AR System configuration files ar ar.conf (ar.cfg) ardb.conf (ardb.cfg) armonitor.conf (armonitor.cfg) Appendix C AR System server components and external utilities AR System server components arforkd (UNIX only) armonitor (armonitor.exe) arplugin (arplugin.exe) arserverd (arserver.exe) External utilities arcache (arcache.exe) arreload (arreload.exe) arsignal (arsignal.exe) Appendix D Date and time formats Short date formats Long date formats Day formats Time formats Additional characters Contents

9 Configuring Appendix E Working with the Server Events form Understanding the Server Events form How the Server Events form is created Types of events you can record Viewing the server changes you recorded Using server events in workflow Appendix F Using Business Time in the AR System server Overview Architecture How Business Time 2.0 works Scheduling a time segment Understanding levels Creating non-conflicting segments Defining a business time segment Understanding time segment entity associations Understanding time segment shared entities Using offset hours in Business Time Business Time commands Parameters Application commands Business Segment-Entity Association commands Application-Get-Next-Recurrence-Time Using the old Business Time forms Scheduling workdays Scheduling holidays Defining business hours using offset hours Old Business Time commands Migrating Workdays and Holidays to the Business Time Segment form Debugging tips for Business Time Appendix G Using the Assignment Engine Overview Assignment Engine Process Assignment Engine Administration Console Contents 9

10 BMC Remedy Action Request System 7.0 Auto-assignment methods Preparing for the auto-assignment process Fields to add to the assignee form Fields to add to the request form Adding assignment forms Adding assignment processes Adding assignment rules Setting sequencing for rules Turning on log and trace files Index Contents

11 Preface Important: The compatibility information listed in the product documentation is subject to change. See the compatibility matrix at /supportweb.remedy.com for the latest, most complete information about what is officially supported. Carefully read the system requirements for your particular operating system, especially the necessary patch requirements. Audience This guide is written for administrators who are responsible for setting up and maintaining the BMC Remedy Action Request System (AR System ). The guide is intended to aid new and current administrators of AR System. If you are a current AR System administrator, this guide enhances the ease of use and performance of your AR System environment. If you are a new AR System administrator, this guide helps you create an effective and efficient AR System environment. Preface 11

12 BMC Remedy Action Request System 7.0 Before you explore the topics in this guide, make sure that you understand the terms and concepts discussed in the Optimizing and Troubleshooting guide, which contains all the required information for setting up and administering a basic AR System environment. Your knowledge of basic administrative AR System tasks is crucial for successful implementation of the strategies discussed in this guide. You must know how to use AR System, including BMC Remedy Administrator, BMC Remedy User, and BMC Remedy Import. See the Installing guide, the Form and Application Objects guide, and the Workflow Objects guide for additional information. AR System documents The following table lists documentation available for AR System products. Unless otherwise noted, online documentation in Adobe Acrobat (PDF) format is available on AR System product installation CDs, on the Customer Support site (supportweb.remedy.com), or both. You can access product Help through each product s Help menu or by clicking on Help links. Title Description Audience Concepts Overview of AR System architecture and features with in-depth examples; includes information about other AR System products as well as a comprehensive glossary for the entire AR System documentation set. Everyone Installing Procedures for installing AR System. Administrators Getting Started Introduces topics that are usually only learned when first starting to use the system, including logging in, searching for objects, and so on. Everyone Form and Application Objects Describes components necessary to build applications in AR System, including applications, fields, forms, and views. Developers Workflow Objects Contains all of the workflow information. Developers Configuring Contains information about configuring AR System servers and clients, localizing, importing and exporting data, and archiving data. Administrators 12 Preface

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

14 BMC Remedy Action Request System 7.0 Title Description Audience BMC Remedy Administrator Help Procedures for creating and modifying an AR System application for tracking data and processes. Administrators BMC Remedy Alert Help Procedures for using BMC Remedy Alert. Everyone BMC Remedy Mid Tier Procedures for configuring the BMC Remedy Mid Tier. Administrators Configuration Tool Help *. A JAR file containing the Java API documentation is installed with the AR System server. Typically, it is stored in C:\Program Files\AR System\Arserver\Api\doc\ardoc70.jar on Windows and /usr/ar/<server_name>/api/doc/ardoc70.jar on UNIX. 14 Preface

15 Learn about the AR System Developer Community Configuring If you are interested in learning more about AR System, looking for an opportunity to collaborate with fellow AR System developers, and searching for additional resources that can benefit your AR System solution, then this online global community sponsored by BMC Remedy is for you. In the Developer Community, you will find collaboration tools, product information, resource links, user group information, and be able to provide BMC Remedy with feedback. The Developer Community offers the following tools and information: Community message board Community Downloads AR System Tips & Tricks Community recommended resources Product information User Experience Design tips Why should you participate in the Developer Community? You can benefit from participating in the Developer Community for the following reasons: The community is a direct result of AR System developer feedback. BMC Remedy provides unsupported applications and utilities by way of Community Downloads, an AR System application. BMC Remedy posts the latest AR System product information in the Developer Community to keep you up to date. It is an opportunity to directly impact product direction through online and surveys. It s free! How do you access the Developer Community? Go to supportweb.remedy.com, and click the Developer Community link. Learn about the AR System Developer Community 15

16 BMC Remedy Action Request System Preface

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

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

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

20 BMC Remedy Action Request System 7.0 BMC Remedy mid tier Within these three functional environments, several system components work together to provide power, flexibility, and scalability. The rest of this section focuses on two of those components, the mid tier and the AR System server, and the interaction between them. For more information about the AR System architecture, see the Concepts guide. The mid tier serves as a client of the AR System server and as a server to the browser. The mid tier enables you to view AR System applications on the web and access the AR System server from a web server. It also provides instructions to the browser in the form of document markup and downloadable scripts. These instructions describe how to present application data and how to interact with the user. The mid tier leverages a Java servlet engine and includes a collection of servlets that are plugged in to the web server to serve forms, images, and other resources. The servlet engine facilitates communication between the browser and the web server. It provides components and add-in services that run on the web server. The web server manages the transfer of all HTML content to the browser. Infrastructure components, such as servlets and other services (special Java classes), translate client requests and interpret responses from the AR System server. Unlike BMC Remedy User, a browser is a generic client that has no inherent knowledge of any application that might run within it. By acting as an interpreter, the mid tier allows a browser to become a fully functional AR System client. The main components of the mid tier infrastructure are: Web server A server that receives requests for a web page and maps the uniform resource locator (URL) to a local file or servlet on the host server. The server then loads the content and serves it across the network to the user s browser. JSP engine An engine that handles the.jsp files and the basic request and response interface in the browser environment. JSP servlets A small piece of Java code, often translated from a.jsp file, that runs on a web server. 20 Chapter 1 BMC Remedy Action Request System 7.0 architecture

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

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

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

24 BMC Remedy Action Request System 7.0 Figure 1-2: AR System server infrastructure User API External Processes AREA Access Control and Data Validation Alerts Plug-In Escalations External Processes Web Services Filter API Plug-In Filters Sybase MSSQL Oracle Informix DB2 View Vendor Plug-In 24 Chapter 1 BMC Remedy Action Request System 7.0 architecture

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

26 BMC Remedy Action Request System 7.0 Consuming a web service Scalability Mid tier scalability You can use an external web service by creating a Web Service Set Fields filter action to enter data from the web service into a base form. You can then view the form in an AR System client. For more information about creating and publishing web services, see the Integrating with Plug-ins and Third-Party Products guide. Scalability is a feature in both the mid tier and the AR System server. The strategy for processing and serving browser-client requests is based on several components. These components work together to take input from the client and compute a response that the user sees in the browser as Dynamic HTML (DHTML). These mid tier components do not run in a separate proprietary process, but in the JSP engine using standard web protocols. The use of JSP servlets makes the mid tier scalable in the following ways: Multiple threads connecting to a servlet can handle many concurrent users. Common web-server mechanisms and practices can be used for scaling and load balancing. The JSP engine, which is a plug-in of the web server, runs in the same process as the web server, so network calls are not needed for the two to communicate. Use of mid tier and user caches of AR System definitions require fewer trips to the AR System server to retrieve them. In addition, use of browser caching has led to data size reductions, which in turn reduces bandwidth requirements. Additionally, the architecture supports server clusters, or web farms that are hardware setups in which several physical web servers share the load directed to one logical server (one IP address). In a web farm, a load balancer receives requests and sends them to whichever physical server has the most resources available to handle them. 26 Chapter 1 BMC Remedy Action Request System 7.0 architecture

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

28 BMC Remedy Action Request System 7.0 Figure 1-3: Multithreaded server architecture Browser Client AR System Administrator Client AR System API Programmer Client Mid-Tier Dispatcher Escalation Queue Flashboards Queue Admin Queue Fast Queue List Queue Private Queues Alert Queue Worker Thread Worker Threads Worker Thread Worker Threads Worker Threads Worker Threads Worker Threads Note: The number of worker threads for fast, list, and private queues can be increased to the maximum number of connections your database and hardware can support. Database 28 Chapter 1 BMC Remedy Action Request System 7.0 architecture

29 Queues Configuring A queue is a meeting point where remote procedure calls (RPCs) wait to be handled by the worker threads that process the RPCs. When a queue is created, it automatically starts the minimum number of threads specified for its thread type. The default for this setting is 1. For more information, see Threads on page 32. There are seven types of AR System queues. Each queue has an RPC program number associated with it, as outlined in the following table. Queue type RPC program number Admin Alert Escalation Flashboards Fast List Private , , Note: Administration, alert, escalation, Flashboards, fast, and list queues use a fixed RPC program number. Private queues, however, can be configured to use any RPC program number within the ranges of RPC program numbers reserved for private queues. The following sections describe the different types of queues. References to the configuration file apply to the configuration file specific to your system. The configuration file for Windows is ar.cfg. For UNIX, this file is ar.conf. Administration queue The administration (admin) queue is the only AR System queue that can perform every operation within the system. It performs all administrative restructuring operations, guaranteeing the serialization and integrity of all restructuring operations. This queue can have only one thread. Scalability 29

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

31 Fast queue Configuring The fast queue handles the operations that generally run to completion quickly without blocking access to the database. The fast queue handles all server operations, except for: Administrative operations that restructure the database. These operations use the administration queue. The ARExport, ARGetListEntry, ARGetListEntryWithFields, and ARGetEntryStatistics, and other API calls (which use the list queue). See the CAPIReferenceguide for more information about API calls. One or more threads can serve the fast queue if a fast queue is configured. To configure a fast queue, see Defining queues and configuring threads on page 153. List queue The list queue handles AR System operations that might require significant time, block access to the database, or both. Examples of these operations include ARExport, ARGetListEntry, ARGetListEntryWithFields, and ARGetEntryStatistics. One or more threads can serve the list queue if a list queue is configured. To configure a list queue, see Defining queues and configuring threads on page 153. Private queues Administrators can also create private queues for specific users who need dedicated access. For example, you might create a private queue for a user who is performing critical operations that you do not want blocked by other users. Private queues guarantee a certain bandwidth dedicated to clients using these queues. Private queues support all operations except restructuring operations. Restructuring operations are supported only by the administration queue (see Administration queue on page 29). To configure a private queue, see Defining queues and configuring threads on page 153. Each private queue can be supported by one or more threads. To connect a user to a private queue, see Configuring clients for AR System servers on page 196. Scalability 31

32 BMC Remedy Action Request System 7.0 Threads The term thread is short for thread of execution. Threads allow the server to process concurrent client requests. Each thread within the multithreaded server can carry out a client request before returning to the queue to process the next one. Start only as many threads as your database and system resources can reasonably support. The total number of threads cannot exceed the number of database connections that are available to the AR System server. All threads within a process share network and system resources; therefore, consider carefully the available resources of your network when establishing the minimum and maximum thread settings for your server queues. There are three types of AR System threads: Dispatcher Worker Thread manager The following sections describe the different types of threads. Dispatcher thread The dispatcher thread routes requests to the appropriate queues. This thread receives connection requests from clients. The dispatcher thread then places the requests into the appropriate queue where each request can be handled by one of multiple worker threads. Every call that the dispatcher thread receives is assigned an RPC ID that can be used to identify the call from the time the call is placed into a queue until a response is sent to the client. In general, the dispatcher thread uses the following logic to dispatch calls: If no other queues are defined, the dispatcher thread routes all requests to the admin queue. If, however, fast and list queues are created in addition to the admin queue, the dispatcher routes client requests according to the type of operation being performed. If private queues are created, the dispatcher directs the call to the appropriate private queue based on the RPC program number of the request. A request is routed to the appropriate queue based on its RPC program number. For example, a call that has RPC program number is routed to the admin queue. 32 Chapter 1 BMC Remedy Action Request System 7.0 architecture

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

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

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