White Paper

BMC Service Request Management 2.0 Architecture

December, 2007

www.bmc.com

Contacting BMC Software
You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information about the company, its products, corporate offices, special events, and career opportunities.

United States and Canada
Address BMC SOFTWARE INC 2101 CITYWEST BLVD HOUSTON TX 77042-2827 USA Telephone 713 918 8800 or 800 841 2031 Fax 713 918 8000

Outside United States and Canada
Telephone (01) 713 918 8800 Fax (01) 713 918 8000

If you have comments or suggestions about this documentation, contact Information Design and Development by email at doc_feedback@bmc.com.

© Copyright 2007 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. ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce (OGC), and is registered in the U.S. Patent and Trademark Office. It is used here by BMC Software Inc., and is used here under license from and with the permission of OGC. BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restricted rights notices included in this documentation.

Restricted rights legend
U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC Software, Inc., 2101 CityWest Blvd., Houston, TX 77042-2827, USA. Any contract notices should be sent to this address.

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

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

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

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

Before contacting BMC Software
Have the following information available so that Customer Support can begin working on your issue immediately:

Product information — — — Product name Product version (release number) License number and password (trial or permanent)

Operating system and environment information — — — — — Machine type Operating system type, version, and service pack System hardware configuration Serial numbers Related software (database, application, and communication) including type, version, and service pack or maintenance level

■ ■ ■

Sequence of events leading to the problem Commands and options that you used Messages received (and the time and date that you received them) — — — Product error messages Messages from the operating system, such as file system full Messages from related software

License key and password information
If you have a question about your license key or password, contact Customer Support through one of the following methods:

E-mail customer_support@bmc.com. (In the Subject line, enter SupID:<yourSupportContractID>, such as SupID:12345.) In the United States and Canada, call 800 537 1813. Outside the United States and Canada, contact your local support center for assistance. Submit a new issue at http://www.bmc.com/support_home.

Contents
Bridging the front office and the back office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 New employee hire scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Key information for the New Hire scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Defining and building the BMC SRM solution versus execution . . . . . . . . . . . . . 11 Catalog definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 RPD model (request, process, data mapping). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Request definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Process definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Data mapping definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Putting it all together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 BMC SRM Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Catalog architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Process definition template architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Data mapping architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Supporting consoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Execution of a run-time service request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 RPD model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Service request architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Supporting consoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Back-office fulfillment system integrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Back-office templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Incident Management integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Change Management integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Work Order Management integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Service Request Management permission model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Licensing model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Appendix A Terminology 99

Contents BMC Software, Inc.

1

2

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

White Paper

BMC Service Request Management 2.0 Architecture
This document provides an architectural overview and description of how the primary components of the BMC Service Request Management (BMC SRM) system are connected and related to each other. Also, to clarify the system architecture, the document discusses how specific features of the BMC SRM work to help clarify the system architecture. For comprehensive details about a particular feature, see the BMC SRM administration and configuration guides. A service desk is often overloaded with standard requests, limiting the ability of the Information Technology (IT) department to focus on critical incidents and restore critical services for the business. To improve efficiency, the IT department must allow the users to request new services, and then let them track the status of their requests directly. For the IT department to achieve maximum efficiency, requests must be submitted in an ordered and structured manner. Often, however, the IT department’s users are not familiar enough with the internal structure of the IT department to make requests in a way that is either efficient or orderly. This is the role of the BMC SRM application. Figure 1 shows a typical user to IT department back-office relationship

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

3

White Paper

Figure 1: User to IT department back-office relationship

BMC SRM gives the IT department the ability to define offered services, publish those services in a web-based catalog, and automate the fulfillment of those services for their user base. With BMC SRM, users can help themselves, which reduces the number of requests received at the service desk. This reduction lets the IT department focus on more mission-critical activities, such as resolving incidents related to service failures and restoring critical services.
Figure 2: User to back-office workflow
Self Service Interface
End Users Service Providers

Service Request Management

Back Office Service Fulfillment
• • • • Change Management Incident Management Work Orders Custom Fulfillment

4

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Many standard requests often originate from within the IT department. To further improve the service efficiency of the IT department, BMC SRM lets the IT department define a unified and simple front end for both users and other IT employees. BMC Remedy IT Service Management 7.x (ITSM 7.x) applications come with a very basic interface and are designed to support a one-dimensional view of the services offered by the IT department. In the ITSM 7.x Requestor Console, a single request maps to exactly one fulfillment request. The BMC SRM system is a far more comprehensive front-office interface solution. BMC SRM supersedes the Requestor Console and offers a multidimensional view of the IT department back-office applications by letting you organize them to apply a unified process to satisfy user requests. The following list summarizes the BMC SRM features that enhance the front-office interface to the IT department service offerings.
!

A full featured catalog, which includes the following characteristics:
! ! ! ! ! !

Title and description Turnaround time Price and cost Three-tiered categories for ease of navigation Level grouping Start and stop dates

! ! !

Support for deployment approval Auditing More context rich user interface, which includes the following characteristics:
! ! ! !

Support for actionable metrics Support for configurable notifications Additional role-based consoles More robust searching capabilities, which includes the following search types: word-based or string-based, browse, direct access

! ! ! !

Multi-step process support More comprehensive support for data mapping to back-office systems Entitlement Enhanced integrations with the following processes and applications:
! ! ! !

Approval process More complete BMC Service Level Management integration First order integration with BMC Atrium CMDB New fulfillment system (work orders)

5 BMC Software, Inc.

White Paper

Bridging the front office and the back office
BMC SRM acts as a bridge between the front office and the back office. Those who benefit most from the BMC SRM system are the users in the front office and the service providers supporting the fulfillment operations. The user is presented with a simplified web-based catalog interface to search. The service catalog definition not only provides the user with descriptions of the services being offered, it also establishes:
! ! !

Who is entitled to access entries in the catalog. What approvals are required. Service level agreements.

Figure 3: BMC SRM engine components
External System(s)

Self Service Interface
End Users

Service Providers

Service Request Management

Service Request

Execution of SR Process SR Process Definition

Back Office Service Fulfillment
• • • • Change Management Incident Management Work Orders Custom Fulfillment

Service Catalog

Approvals

Notifications

Service Level Management

When the catalog entry is selected, the related form is completed and then submitted. A service request is then initiated along with the associated supporting process. Using the BMC SRM interface, the user can easily track the progress made by the back office and also have access to bidirectional communication with the service providers. BMC SRM also offers a programmable interface to allow external applications to submit requests. In addition to supporting users who submit requests by way of the BMC SRM system, the business managers of those users can also manage, approve, monitor, and report on those requests by way of the Business Manager and Approval Consoles.

6

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Service providers benefit by receiving coordinated requests that support the end-toend fulfillment process, which leads to the efficient resolution of the user’s service request.
Figure 4: Roles supporting end-to-end solution
Business Manager External System(s)

Self Service Interface
End Users

Request Coordinator

Service Providers

Service Request Management

Service Request

Execution of SR Process SR Process Definition

Back Office Service Fulfillment
• • • • Change Management Incident Management Work Orders Custom Fulfillment

Service Catalog

Approvals

Notifications

Service Level Management

Business Relationship Manager

Service Catalog Manager

Bridging the front office and the back office BMC Software, Inc.

7

White Paper

Also responsible for the development and maintenance of the service catalog are the business relationship manager, the service catalog manager, and the service request coordinator. A single individual can perform more than one of these roles, as described in Table 1.
Table 1: Service catalog developers and maintainers Role Business relationship manager Responsibility The business relationship manager works closely with both the business and the IT department to define the service request requirements (for example, the services that are required, a reasonable turnaround time for a service, or a reasonable price that the business is willing to pay). The service catalog manager is responsible for creating and managing the SRDs and, specifically, the fulfillment process definitions within the service catalog. The person in this role works closely with the business relationship manager to create and implement the requests from the business (for example, defining that a certain request requires a certain type of specific process). The service request coordinator (Service Request Agent in ITIL terminology) is responsible for troubleshooting requests that are exceptions to the normal process. However, service request coordinators do not work on the requests themselves; that responsibility belongs to the back-office fulfillment provider. Service request coordinators are members of the front-line support staff. This is an optional role.

Service catalog manager

Service request coordinator

New employee hire scenario
The section provides a generic scenario to help illustrate how the concepts and components of the BMC SRM system tie together and to provide a consistent example throughout. This scenario is only one of many possible scenarios that are supported by the BMC SRM solution. However, it offers a basic framework that is common in most scenarios. The ACME Company has determined that the process of preparing the office infrastructure for a new employee is very inefficient. After the new employee signs and returns the offer-of-employment letter, the assigned HR representative uses the BMC SRM system to complete the following steps:
1 Search for and select the New Employee Setup service listed in the catalog. 2 Provide the required information in the setup request form. The most important

pieces of information needed for this process are: Employee name

!

8

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

! ! !

Start date Office and building location Floor plan for the furniture setup

3 Submit the request.

As a result of the request:
a The Facilities department proceeds with setting up the office by cleaning it,

setting up furniture, and so on.

b The IT department enables the ports in the office. c The Security department issues an access card. d The IT department takes a desktop system from inventory and installs it in the

office.

After interviewing each of the process fulfillment organizations, ACME Company determines that the process described in this scenario requires a lead time of three days to complete.

New employee hire scenario BMC Software, Inc.

9

White Paper

Key information for the New Hire scenario
The following tables summarize the key information that defines this particular request definition catalog entry.
Table 2: Request definition Title New Employee hire Description Entitlement Turnaround time 3 Days

This service request is intended HR Managers to support the process of hiring a new employee. This entails completing the final background check, issuing a badge to be picked up at the front desk of the building their office is located in, cleaning and setting up their office, enabling the ports, and installing a new standard desktop system. Contact the Human Resources department at 1-800-New-Hire if you have any questions about this process.

Table 3: Process definition Sequence 1 2 3 Task Background check and issue badge Set up office Enable ports Install new desktop Fulfillment organization Security Facilities IT IT Supporting application Work Order Work Order Incident Management Change Management

Table 4: Data mapping Data mapping HR Input Employee Name Start Date Office and Building Floor Plan Fulfillment organization application fields Security - WO Requested for Special type field special type field N/A Facilities - WO Requested for Special type field Special type field Special type field IT - IM IT - CM requested for requested for custom field custom field N/A required start date notes N/A

10

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Defining and building the BMC SRM solution versus execution
The BMC SRM solution comprises the following stages:
! !

Definition Runtime

In the definition stage, you define and build a catalog entry. The catalog entry consists of two parts:
! !

Service request definition (SRD) Service request process definition (PD)

The run-time stage comes after you build the catalog entry, when it is deployed and made available to users.
Figure 5: BMC SRM Solution stages

The user’s interaction with the BMC SRM interface (searching, selecting, providing information, and submitting the request) is part of the run-time stage of the BMC SRM solution. When the SRD is initiated, the corresponding process definition is also initiated as part of the run-time stage. As a result, multiple SRs and process definition instances can be generated from a single SRD and PD template (PDT) pairing (for information about process definition templates, see “Process definition” on page 13).

New employee hire scenario BMC Software, Inc.

11

White Paper

Figure 6: Definition versus execution

Automated Tools

Service Request Management System

Service Request Definition • Title • Description • Nav. Categories • Entitlement • Approvals

Service Request • End User Console • Activity Log • SLA’s • Surveys • Approvals

Process Definition
AOT AOT AOT

Instantiation of Process Def.
AOI AOI

AOT

AOI

Definition

Execution

Catalog definition
This section discusses the RPD model and explains the RPD model components:
! ! !

Request definition Process definition Data mapping definitions

RPD model (request, process, data mapping)
Request, process, and data mapping (RPD) are the three primary components needed to define a catalog entry. To complete the definition of a catalog entry, you must:
! ! !

Define the request characteristics. Build the supporting process. Establish data mapping between front-office input and back-office systems.

After these three components are defined, built, and connected together, the new catalog entry can be deployed and made available to entitled users.
12 BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Request definition
Title Approval Service Request Def. 1 Description SLA

The Service request definition (SRD) is a primary component to complete a catalog entry. The SRD captures and defines how the business or user interacts with the given catalog entry. The Request Definition table (see Table 2 on page 10) in the New Employee Hire scenario captures the type of information that would be part of the SRD.

The following list contains other information types that make up the SRD definition:
!

Additional keywords to be associated with a given SRD when searching the catalog. Navigational categories used to organize how the user can browse the catalog to find a given catalog entry. The cost and price associated with the service. The start and end dates for which the catalog entry is available to entitled users. The service levels that should be applied. What approval is required. Which process should be invoked to support the selected catalog entry. This component defines much of how a given catalog entry is presented to the user. After selected, the SRD also determines how the catalog entry is managed (with regard to SLAs and approvals) during runtime.

!

! ! ! ! !

Process definition
The process definition establishes how the requested work gets done by specifying who does what and when. A process definition template (PDT) provides a model for Work Order the values of who, what, and when. The PDT acts as a [Sec. Badge] container object that is composed of the step or steps needed to fulfill the related request. Each step is tied to a specific back-office fulfillment application where an Work Order Incident [Setup Office] [Enable Ports] individual service provider is assigned to do the work required by each step. These steps in BMC SRM are represented by and referred to as application object Change templates (AOTs). If multiple steps and AOTs are Request [Install Desktop] required, they are organized in a sequential order. The collection of these steps and AOTs, organized in a particular order for individuals to perform, is considered a process. This process is represented by and referred to as process definition templates (PDTs) in BMC SRM.
Process Definition

For example, the Process Definition table on page 10, lists four steps, the sequence in which they occur, who performs the step, and what application is used for each step.

Catalog definition BMC Software, Inc.

13

White Paper

Data mapping definition
Although the order in which you complete the request definition and process definition does not matter, you must perform the data mapping step last. This is because, the Office context in which front-office input data must be mapped to Location? the the back-office fulfillment application fields is not established until the SRD is linked to a process definition. Consequently, the SRD and process definition must first be built and connected before the data mapping step can be completed.

Data Mapping

In the New Employee Hire scenario, the data mapping table lists the information that is provided by Human Resources and to which field of each fulfillment application this data is mapped.

Putting it all together
After the SRD is defined (the R of the RPD model), the PD is defined (the P of the RPD model), and the two are connected. The data mapping can be established (the D of the RPD model) to complete the definition of a deployable catalog entry. You can think about this concept in the following equation form: (R + P + D) = Deployable Catalog Entry Figure 7 on page 15 provides a visual representation of the RPD model.

14

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 7: The RPD model

Title Approval Approval Service Request Def. 1 Description SLA

Data Mapping

Office Location?

Process Definition
Work Order
[Sec. Badge]

Work Order
[Setup Office]

Incident
[Enable Ports]

Change Request
[Install Desktop]

BMC SRM Framework
This section reviews the BMC SRM Framework that was introduced with the ITSM 7.x release. The BMC SRM Framework has remained intact with the release of BMC SRM 2.0. However, it has been extended and configured with additional support for an enhanced data mapping scheme. It has also been extended to support bidirectional communication with the back-office fulfillment applications required for BMC SRM 2.0. The framework comprises the following parts:
! ! !

Common Application Interface (CAI). process flow. data mapping constructs.

Catalog definition BMC Software, Inc.

15

White Paper

For a more comprehensive discussion of the BMC SRM Framework architecture, see the Common Application Interface section of the ITSM 7.x architecture document. This section limits the discussion to a high-level review of the design and the commands that were configured in the CAI to support the capabilities of BMC SRM 2.0. The process flow and data mapping constructs are discussed in more detail in later sections. The CAI accepts communication requests from other applications or systems in a predefined method. To accomplish this, after the request is received it is mapped to an existing command definition, the command is then constructed, and then it is finally executed. Figure 8 highlights each stage.
Figure 8: CAI high level design
Definition
1 2
ID App Registry Name Protocol

Construction
3

Execution
5

Event Data Values What

Command Content How
4

RuntimeJust Do It Command

Commands Command Direction Op. Type

Parameters Param Data Type

Done
Mode

The CAI is at the core of the BMC SRM Framework and is made up of the components that appear in the following tables.

16

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Table 5: CAI components—Definition or reference CAI component Application registry Form name
CAI:AppRegistry

Description Stores application interface information, such as interface form names, connection data, and the protocol. Command names for each integrating component. Stores the command parameters for the command of each integrating component. Defines the mapping between the command parameters and the backend application.

Commands Command parameters

CAI:Command CAI:CommandParam

Command parameter mapping

CAI:CommandParamMapping

Table 6: CAI components—run-time CAI component Events Form name
CAI:Event

Description Stores the run-time instance of a command event for each integrating component. Stores the event parameters for each integrating component.

Event parameters

CAI:EventParam

Figure 9 illustrates how these components relate to each other in support of the CAI design.

Catalog definition BMC Software, Inc.

17

White Paper

Figure 9: How components relate in support of the CAI design
Definition
1. Register application CAI:AppRegistry 2. Map command parameters for each registered application CAI:CommandParamMapping

U1 U2

InstanceID AppRegistryName ApplicationName ApplicationInstanceID Protocol Connection Info Interface Form Names

AppRegistryName Command CommandParam AppInterfaceFormName AppFieldName AppFieldID ParamType ParamDataType

0. Create commands and command parameters CAI:CommandParam CAI:Command

U1

Command Direction OperationType SelectionType

U1 U1

Command CommandParam Type DataType Mode

CAI:Event CAI:EventParam EventGUID Event Source Target SourceAppRegistryInstanceID AOIGUID AppInterfaceFormName TargetConnectionInfo RtnCode RtnMsgCode RtnMsg MaxRetries RetryCounter

Construction

EventGUID ParmName ParamValue ParamAttachmentValue ParamType ParamDataType Push event and run-time data to event params (outbound)

SRMS/TMS
Calls GetEntry to get event values

Execution (outbound)

FilterAPI Plugin
Push event and event params App Interface Form

AR Workflow Launch

Browser

Mapped Param

The commands configured in the CAI are the key for BMC SRM. These commands determine how to communicate with the back-office fulfillment applications and how those back-office fulfillment solutions communicate with BMC SRM. For a list of the commands that support this bidirectional communication, see the BMC SRM 2.0 Administration Guide.

18

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Catalog architecture
This section provides information about specific areas of the architecture.

Service request definition
This section discusses various aspects of the Service Request Definition (SRD).

Service request definition life cycle
An SRD has various states that indicate its position in the life cycle. By default, approval is required for certain state transitions. Generally, a new SRD starts in the Draft state and becomes visible for selection by users only when it is in the Deployed state, and then only within the specified effective dates. The SRD entry also must be Active to be available for selection. After an SRD is in the Closed state, it cannot be deployed and becomes inaccessible to the service requesters. The following diagram shows the life cycle of an SRD entry. For more information about preparing SRDs for deployment, see the BMC SRM 2.0 Administration Guide.
Figure 10: SRD life cycle
Service Request Definition Life Cycle

Draft SR = More Information Approval canceled

Pending

Request For Approval Approved

Rejected

SR= Cancelled Deployed Effective End Date reached

SR = Cancelled

Expired

Closed

Note: SR means Status Reason

Catalog definition BMC Software, Inc.

19

White Paper

Whether an SRD is available for selection from the catalog by users is based on both the SRD status and the effective dates defined for the SRD. The following table provides a summary of the relationship between the SRD states and the effective date range.
Table 7: Relationship between SRD states and effective date range Status Status reason In effective date range N/A N/A N/A SRD online status Description

Draft Request for Approval Pending

N/A N/A More Information

Initial state; SRD is being authored. Waiting for approval. Need more information from the SRD submitter. Once information is provided, the SRD can be resubmitted for approval by changing the status to Request for Approval. SRD was rejected. SRD Approved; Has not reached effective start date. Future effective start date not set. End state; no longer available to Users. Available to users. Available to users. SRD has been manually taken offline.

Rejected Deployed

N/A N/A

N/A No

Expired Closed Deployed Deployed Deployed

N/A Cancelled N/A N/A N/A

No N/A Yes No end date Yes

Service request definition structure
The SRD is supported by and linked to a variety of information. Some of the information that defines the SRD is linked by way of a “foreign key,” which is related to the SRD by way of an association table and stored directly on one of the base forms.

20

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 11: Service request definition primary components
Application Configurations

Service Request Work Info Audit Logs

Foundation Elements

Entitlement

Service Request Definition
Service Level Management

Data Mapping

PDT’s Surveys

Figure 11 presents the main components related to the SRD. The actual SRD is a join form that consists of two base forms. The primary base form— SRD:ServiceRequestDefinition_Base—stores information that makes up the core definition of the SRD and is not displayed to the user. This form is not localized. The secondary base form—SRD:ServiceRequestDefinition_DispProp—stores information from the SRD that can be visible to the user and therefore subject to being localized. The resulting join form—SRD:ServiceRequestDefinition— establishes a one-to-many relationship between the base information and the multiple languages that might be defined for each display record.

Primary forms and data fields
The following tables contain only the primary forms making up supporting, referenced component architecture structures. The fields listed in the tables are only a subset of the key fields that clarify the purpose of the referenced form. SRD:Service Request Definition join form The SRD form is the primary form used as the interface for capturing and searching for the characteristics that make up the business definition of a Catalog Entry. It is a join form that is made up of a join between the SRD:ServiceRequestDefinition_Base form and the SRD:ServiceRequestDefinition_DispProp form.
Join criteria—Instance ID of the Base form and the SRD_InstanceID of the Display Properties form.

SRD:Service Request Definition_ Base form

The Service Request Definition Base form contains the core SRD information that is not influenced by localization. Table 8 contains a full description of the form.

Catalog definition BMC Software, Inc.

21

White Paper

Table 8: SRD:ServiceRequestDefinition_Base form Join data label Account Number Attachment Business Service Company Company Survey Enabled Coordinator Group Create Business Process Custom Template Customer First Name Customer Last Name Effective End Date Effective Start Date Expected Cost Hot List Process Template RC Manager Company RC Manager Name Request Frequency Request Type SR Needs Approval Status Status Reason Survey Configuration Survey Name Survey Status System Request Turnaround Time Source data Field name
SRD_Account Number SRDAttachmentField SRD_BusinessService SRD_LocationCompany SurveyEnabled ServiceRequest CoordinatorGroup CreateBusinessProcess Custom_Template RequestedByFirstName RequestedByLastName EffectiveEndDate EffectiveStartDate SRD_Expected Cost HotList PDT_Name RequestCatalogManager_ Company RequestCatalogManager_ FullName Request Frequency SRD_Request Type UseApprovalEngFlag_SRD SRD_Status Status_Reason SurveySelection SurveyName SurveyStatus SystemRequest SRD_TurnaroundTimeX

Field ID 302793700 302906200 302793400 301453000 302844800 10002506 302858800 302825800 1000000019 1000000018 240000014 240000013 302783800 302897800 302876900 301251902 301251901 302771600 301438012 302896600 7 1000000150 302839500 302903400 302903500 302785000 302793500

Type Character Attachment Character Character Character Character Selection Character Character Character Date Date Currency Selection Character Character Character Integer Selection Selection Selection Selection Selection Character Selection Selection Integer

SRD:Service Request Definition_ DispProp form

The SRD Display Property form contains the localized strings for the following fields that follow on the SRD.
Table 9: SRD:ServiceRequestDefinition_DispProp form Join data label Category 1 Category 2 Category 3 Description Source data Field name
Category1 Category2 Category3 SRD_Description

Field ID 1000000063 1000000064 1000000065 301244800

Type Character Character Character Character

22

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Table 9: SRD:ServiceRequestDefinition_DispProp form (Continued) Join data label Instructions Keywords Level Locale Price SR Instance ID Title Source data Field name
SRD_Instructions SRD_Aliases SRD_Level SRD_Locale SRD_Price SRD_InstanceID SRD_Title

Field ID 302823600 302771500 302793100 160 302793000 302162700 301244700

Type Character Character Character Character Currency Character Character

Key related components and features
Information can be related to the SRD in a variety of ways. It can be related by a foreign key, an association, queried data, or through a combination of these. Each component covered in this section specifies the way in which the information is related and the key forms required to support this relationship.
Figure 12: Key related components
Create entry to notify catalog manager NTE:SYS-NT Process Control Create an entry to get new SRD Number SRD:CFG DefinitionNumGenerator

SRS:CFGCustomForm instanceId

SRM:Navigational Category Navigational Category 1, 2, 3

SYS:Menu Items

SRD:CFG Settings

SRD_Level

Get setting for approval

FK:instanceId= Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition SRM:Request SRDInstanceID FK:SRDInstanceID= InstanceID InstanceID Request ID (Field 1 for join form) SRD_Number (auto-generated) SRD_Request_ID (Request ID from base) Navigational Category 1 Navigational Category 2 Navigational Category 3 SRD_Level Custom_CFG_Form_InstanceId PDT_InstanceID PDT_Name SurveyAssocInstanceID Catalog Manager Customer CTM:People

SRD:WorkInfo SRD Entry ID SRD Number

Catalog Manager Company Location Company Customer Company

COM:Company

FK: SRD Number=SRD_Number, SRD Entry ID=SRD_Request_ID

Assignee Group (Request Coordinator Group)

CTM:Support Group

SRD:AuditLog Original Request ID

FK:Original Request ID= Request ID Entitlement Criteria – SRD_Number, Nav Cat 1,2,3, Level

FK:InstanceID= ParentInstanceID Join: InstanceID=SRD_InstanceID SRD:ServiceRequestDefinition _base InstanceID BusinessServiceInstanceId SRD_BusinessService BusinessProcess_ InstanceId BusinessProcess_ ReconId Sandbox_DatasetID Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition _DispProp SRD_Status SRD_Title SRD_Description SRD_Locale SRD_InstanceID SRD_Aliases TakeSRDOfflineFlag SRD_Level SRD_Instructions deleted SRD_Price Navigation Tier1 Navigation Tier2 Navigation Tier3 FK:InstanceID= ParentInstanceID

SRM:UniqueQuestionList ParentInstanceID

SRD:SRDEntitlement Definition SRDED instanceId2 FK:InstanceId= SRDED instanceId2 SRD:SRDED PED Associations SRDED instanceId2

SRM:SourceToTargetData Associations ParentInstanceID

FK:InstanceID= Assoc1InstanceID

SRM:Associations Assoc1InstanceID Assoc2InstanceID FK:Assoc2InstanceID=InstanceId SRM:ProcessDefinition Template InstanceId PDT_Name

SRM:SurveyAssociations SurveyInstanceID SRDInstanceID FK:SurveyInstanceID=InstanceId SRM:ConfigSurveyQuestions InstanceId

FK:SRDInstanceID= SurveyAssocInstanceID

FK:InstanceID=instanceId2 SLM:Association associationTypeId'="SVT_SRD_RELATE" instanceId1 instanceId2

FK:instanceId1=InstanceId SLM:ServiceTarget InstanceId FK:PDT_InstanceID=InstanceId PDT_Name=PDT_Name

Catalog definition BMC Software, Inc.

23

White Paper

Navigational categories

The navigational categories are used to organize entries in the catalog and to provide the user with structured access to all of the items they are entitled to see. Navigational categories can be three levels deep and entries can be represented at any level. For example, if the only grouping was for all hardware-related catalog entries, when you define those SRDs, you would set Category 1 to Hardware and the fields for Category 1 and Category 2 would remain blank.
Figure 13: High-level view of navigational categories
SRM:Navigational Category Navigational Category 1, 2, 3

SRD:ServiceRequestDefinition InstanceID Request ID (Field 1 for join form) SRD_Number (auto-generated) SRD_Request_ID (Request ID from base) Navigational Category 1 Navigational Category 2 Navigational Category 3 SRD_Level Custom_CFG_Form_InstanceId PDT_InstanceID PDT_Name SurveyAssocInstanceID

Join: InstanceID=SRD_InstanceID SRD:ServiceRequestDefinition _base InstanceID BusinessServiceInstanceId SRD_BusinessService BusinessProcess_ InstanceId BusinessProcess_ ReconId Sandbox_DatasetID Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition _DispProp SRD_Status SRD_Title SRD_Description SRD_Locale SRD_InstanceID SRD_Aliases TakeSRDOfflineFlag SRD_Level SRD_Instructions deleted SRD_Price Navigation Tier1 Navigation Tier2 Navigation Tier3

After you define the SRD, the navigational category values are searched for in the BMC SRM:NavigationalCategory form and stored on the SRD form. The available navigational category definitions are listed on the Custom Configuration tab of the Application Administration console. The navigational category form gives the administrator the ability to create, modify, and delete navigational category associations as well as the ability to relate these navigational categories to companies. An entry is created in the BMC SRM:NavigationalCategory form when a Category 1, Category 2, or Category 3 relationship is defined. Category 1 and Status are required fields. A category relationship is automatically related to the Global company if no company relationship is specified.

24

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

The following actions occur when a category relationship is created:
!

An entry is created in BMC SRM:NavCatCompanyModuleAssoc when the category is related to a company. This entry captures the category-to-company relationship. Category tag values are set to their category values. The tags exist for internationalization support. An entry is created in the BMC SRM:CategoryReference form for each Category 1, Category 2, and Category 3 level that is created. This entry captures the company, category, and display property for the category. An entry is created in SRS:ConsoleMenuValue for each Category 1 that is created.

!

!

!

Catalog definition BMC Software, Inc.

25

White Paper

Figure 14: Detailed view of navigational categories

Entitlement

The Entitlement Subsystem enforces rules that determine who is allowed to see what. In the context of BMC SRM, who is defined as an individual, group, location, or company. The what is defined as a specific SRD or group of SRDs. The grouping can be defined either by the level or navigational category fields. In the New Employee Hire scenario, the who is the group of people who are members of the Human Resources Group. The what is the New Employee Hire SRD. There is also an option to create a custom qualification to define the who based on any field on the CTM:People form, or the what based on the any field on the SRDServiceRequestDefinition form.

26

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 15: Entitlement, conceptual view

SRD:ServiceRequestDefinition InstanceID Request ID (Field 1 for join form) SRD_Number (auto-generated) SRD_Request_ID (Request ID from base) Navigational Category 1 Navigational Category 2 Navigational Category 3 SRD_Level Custom_CFG_Form_InstanceId PDT_InstanceID PDT_Name SurveyAssocInstanceID

SRD:SRDEntitlement Definition SRDED instanceId2 FK:InstanceId= SRDED instanceId2 SRD:SRDED PED Associations SRDED instanceId2

Entitlement Criteria – SRD_Number, Nav Cat 1,2,3, Level

Join: InstanceID=SRD_InstanceID SRD:ServiceRequestDefinition _base InstanceID BusinessServiceInstanceId SRD_BusinessService BusinessProcess_ InstanceId BusinessProcess_ ReconId Sandbox_DatasetID Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition _DispProp SRD_Status SRD_Title SRD_Description SRD_Locale SRD_InstanceID SRD_Aliases TakeSRDOfflineFlag SRD_Level SRD_Instructions deleted SRD_Price Navigation Tier1 Navigation Tier2 Navigation Tier3

As shown in Figure 16, each entitlement qualification is made up of two parts. The what portion of the qualification for BMC SRM is called the service request definition entitlement definition (SRDED). The who portion of the qualification is referred to as the people entitlement definition (PED). The PED and SRDED together define an entitlement rule or definition.

Catalog definition BMC Software, Inc.

27

White Paper

Figure 16: Entitlement definition

Entitlement Definition
Service Request Definition Entitlement Definition (SRDED) People Entitlement Definition (PED)

SR Definition

CTM:People Individual, Location

AR Groups

The entitlement definition rule or definition is represented by the SRD:EntitlementDefinition_join join form. This is a three-way join between SRD:SRDEntitlementDefinition, SRD:SRDEDEDAssociations and ENT:PeopleEntitlementDefiniton. This relationship is illustrated in Figure 17.
Figure 17: Entitlement definition rule relationships
SRD:EntitlementDefinition_join $PED instanceId1$ = 'InstanceId'

P: SRD:SRDEDAssociation_join $InstanceId$ = 'SRDED instanceId2' S: ENT:PeopleEntitlementDefinition Entitlement Group ID Entitlement PED ID Everyone InstanceId Name PED Advanced Qual Status

P: SRD:SRDEntitlementDefinition Category Tag1 Category Tag2 Category Tag3 Entitlement Definition ID EntitlementQualification InstanceId SRD_Number Status

S: SRD:SRDED PED Associations PED instanceId1/SRDED instanceId2 Request ID SRDED instanceId2 Status

This three way join supports the many-to-many relationship between the SRDED and the PED. One SRD entitlement definition can be related to multiple people entitlement definitions. For example, Mary, Bill, and all the engineers at the Houston regional office (three PEDs) are entitled to select and submit a service request for access to the test lab in Building 3.

28

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Likewise, a single person entitlement definition can be related to multiple SRD entitlement definitions. For example, Bill is entitled to select and submit a service request for access to the Building 3 test lab and select and submit any catalog entry that has the navigational Category 1 field set to Hardware (two SRDEDs). BMC SRM also introduces a new type of group called entitlement groups. Although it is ultimately supported by the base BMC Remedy AR User and Group forms, additional forms have been added to facilitate the creation and maintenance of these entitlement groups. Members of these groups are selected from the registered users in the CTM:People form. Figure 18 illustrates the relationship between these forms.
Figure 18: Relationship between ENT:SYS Entitlement Group User Join form and groups

ENT:SYS Entitlement Group User Join $Permission Group ID$ = 'Permission Group ID'

P: ENT:SYS People Entitlement Groups InstanceId People Permission Group ID Permission Group ID Person ID/Permission Group ID Remedy Login ID

S: ENT:SYS-Access Permission Grps Company InstanceId Navigation Menu01 Navigation Menu04 Permission Group Permission Group ID Request ID Status

Primary Forms

This section provides a description of the primary forms.
!

SRD:EntitlementDefinition_join provides a consolidated view of the

entitlement definition rule. Both sides of the who can see which model is available to support the entitlement enforcement process. Both sides pull together the data that is needed for the entitlement process and can leverage that data by workflow on the ENT:Entitlement Generate QUAL/CACH form. PED Instance ID from SRD:SRDEDAssociation_join. Instance ID on ENT:PeopleEntitlementDefinition (PED).

The join criteria for this form are:
! ! !

SRD:SRDED PED Associations forms. It is an intermediate join to support the three way join required to produce the SRD:EntitlementDefinition_join form.

SRD:SRDEDAssociation_join joins the SD:SRDEntitlementDefinition and

The join criteria for this form are:
! ! !

Instance ID from SRD:SRDEntitlementDefinition (SRDED). SRDED Instance ID on SRD:SRDED PED Associations.

SRD:SRDEntitlementDefinition stores the SRDED part of the entitlement rule. The SRDED rule can contain any field from the SRD.

Catalog definition BMC Software, Inc.

29

White Paper SRD:SRDED PED Association holds the entitlement association record between

!

SRDED and PED. Data is pushed from the Entitlement Console to this form.

!

the Entitlement Rule. The PED Rule can contain any field from the CTM:People form. Work information The work information form is used as an activity log. The catalog manager or administrator can provide notes for each SRD. The work information that is tracked as part of the SRD is linked by a foreign key that is stored with each record.
Figure 19: Work Info entity relationships
SRD:ServiceRequestDefinition InstanceID Request ID (Field 1 for join form) SRD_Number (auto-generated) SRD_Request_ID (Request ID from base) Navigational Category 1 Navigational Category 2 Navigational Category 3 SRD_Level Custom_CFG_Form_InstanceId PDT_InstanceID PDT_Name SurveyAssocInstanceID

ENT:PeopleEntitlementDefinition This regular form stores the PED part of

SRD:WorkInfo SRD Entry ID SRD Number

FK: SRD Number=SRD_Number, SRD Entry ID=SRD_Request_ID

Join: InstanceID=SRD_InstanceID SRD:ServiceRequestDefinition _base InstanceID BusinessServiceInstanceId SRD_BusinessService BusinessProcess_ InstanceId BusinessProcess_ ReconId Sandbox_DatasetID Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition _DispProp SRD_Status SRD_Title SRD_Description SRD_Locale SRD_InstanceID SRD_Aliases TakeSRDOfflineFlag SRD_Level SRD_Instructions deleted SRD_Price Navigation Tier1 Navigation Tier2 Navigation Tier3

The following table describes the primary work information form, SRD:WorkInfo data fields. Work information is an activity log for updates or any related information that is relevant to a given SRD.
Table 10: SRD:WorkInfo data fields Data field name
Attachment Pool Description Detailed Description Number of Attachments Number of URLs

Field ID 400005900 1000000000 1000000151 1000000365 1000002264

Type Attachment Pool Character Character Integer Integer

Length n/a 100 0 n/a n/a

30

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Table 10: SRD:WorkInfo data fields (Continued) Data field name
Request Number SRD Number Status Total Time Spent URL01 URL02 URL03 Work Log Date Work Log ID Work Log Submit Date Work Log Submitter Work Log Type Work Order Number WorkLog Action Completed WorkLog Action Status

Field ID 1000000829 1000000182 7 1000000731 1000002261 1000002262 1000002263 1000002134 1 1000000157 1000000159 1000000170 1000000967 1000002401 1000002369

Type Character Character Selection Integer Character Character Character Date and Time Character Date and Time Character Selection Character Selection Selection

Length 15 45 n/a n/a 255 255 255 n/a 15 n/a 254 n/a 15 n/a n/a

Surveys

Surveys provide the ability to send a survey to the requestor of a service request after the service request is closed. A default survey can be set up for each company and each survey definition can have a different set of four questions for each SRD. Surveys are related to SRDs by way of a foreign key pairing between the SRD and the survey question form, which is stored in the Survey Association table.

Catalog definition BMC Software, Inc.

31

White Paper

Figure 20: Survey entity relationships

SRD:ServiceRequestDefinition InstanceID Request ID (Field 1 for join form) SRD_Number (auto-generated) SRD_Request_ID (Request ID from base) Navigational Category 1 Navigational Category 2 Navigational Category 3 SRD_Level Custom_CFG_Form_InstanceId PDT_InstanceID PDT_Name SurveyAssocInstanceID

Join: InstanceID=SRD_InstanceID SRD:ServiceRequestDefinition _base InstanceID BusinessServiceInstanceId SRD_BusinessService BusinessProcess_ InstanceId BusinessProcess_ ReconId Sandbox_DatasetID Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition _DispProp SRD_Status SRD_Title SRD_Description SRD_Locale SRD_InstanceID SRD_Aliases TakeSRDOfflineFlag SRD_Level SRD_Instructions deleted SRD_Price Navigation Tier1 Navigation Tier2 Navigation Tier3

SRM:SurveyAssociations SurveyInstanceID SRDInstanceID FK:SurveyInstanceID=InstanceId SRM:ConfigSurveyQuestions InstanceId

FK:SRDInstanceID= SurveyAssocInstanceID

32

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

The following tables describe the the data fields on theses survey forms:
!

SRM:SurveyAssociations is an association table that supports the many-tomany relationship between a configured set of survey questions and a given SRD. SRM:ConfigSurveyQuestions maintains the set of four configured questions that can be defined as the default for all SRDs for a given company or tied to a specific SRD.

!

Table 11: SRM:SurveyAssociations form Data field name
InstanceID RequestID SRDInstanceID SurveyInstanceID

Field ID 179 1 302814500 302841800

Type Character Character Character Character

Length 38 15 38 38

Table 12: SRM:ConfigSurveyQuestions form Data field name
Company InstanceID Question Type Question1 Question2 Question3 Question4 SRD_ID Survey Name1 SurveyLocale SurveyType Topic

Field ID 1000000001 179 300794000 260000000 260000001 260000002 260000003 302797800 302838900 302839000 302841700 300563100

Type Character Character Character Character Character Character Character Character Character Character Character Character

Length 254 38 30 255 255 255 255 20 255 255 25 255

Custom forms

Custom forms allow you to create a more robust data entry screen during the Provide Information stage of the service request submission process. Custom forms offer a very powerful and flexible alternative to the basic ten configurable questions that are made available by default with a standard SRD. Some reasons for leveraging a custom form are:
!

The need for more information from the user than can be satisfied with ten questions. The need to use table fields to support a more intuitive interaction model. The need to establish dependencies between data fields. In other words, the information in one field or question might affect what options are available in another field or question.

! !

Catalog definition BMC Software, Inc.

33

White Paper

! !

The need to perform data validation. The need to look up information from other sources.

Any kind of BMC Remedy AR System form (Regular, Display Only, Vendor, View, Join, and so on) can be used as a custom form. As a result, you have the entire capability of the AR System at your disposal to develop the interaction model that best fits your need in accomplishing your primary goal of getting information required to support the submission of a request. The BMC SRM architecture model allows for the resulting custom form to seamlessly plug into the service request submission interaction model at the Provide Information stage. This is accomplished by organizing the custom form into the following parts: connection fields and workflow, mapped fields, and custom fields and workflow, as shown in Figure 21 and described by Table 13.
Figure 21: Custom fields conceptual overview

Custom Fields

Connection Fields

Mapped Fields

Table 13: Custom form parts Custom form part Connection fields and workflow Mapped fields Description The connection fields and workflow are the “plumbing” that supports the seamless connection with the BMC SRM Provide Information stage of the request submission process. The mapped fields are pre-defined fields that are set up to transfer data from the custom form to specific, established fields on the initiated SR. You can then map to this data through fields on the back-office interface forms. On a custom form, custom fields are all the other new fields and workflow added to store, manipulate, and present information to the user. These fields and workflow are additive and are not required to interact at all with the BMC SRM connection and mapped fields of the custom form.

Custom fields and workflow

34

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

You can use the following custom forms provided with the application as templates for creating new custom forms. The SRM:CFGCustom form is used to store the custom form related to a specific SRD, which is linked by way of a foreign key.
Figure 22: Custom forms entity relationships
SRS:CFGCustomForm instanceId

FK:instanceId= Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition InstanceID Request ID (Field 1 for join form) SRD_Number (auto-generated) SRD_Request_ID (Request ID from base) Navigational Category 1 Navigational Category 2 Navigational Category 3 SRD_Level Custom_CFG_Form_InstanceId PDT_InstanceID PDT_Name SurveyAssocInstanceID

Join: InstanceID=SRD_InstanceID SRD:ServiceRequestDefinition _base InstanceID BusinessServiceInstanceId SRD_BusinessService BusinessProcess_ InstanceId BusinessProcess_ ReconId Sandbox_DatasetID Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition _DispProp SRD_Status SRD_Title SRD_Description SRD_Locale SRD_InstanceID SRD_Aliases TakeSRDOfflineFlag SRD_Level SRD_Instructions deleted SRD_Price Navigation Tier1 Navigation Tier2 Navigation Tier3

Primary Forms and Data Fields This section describes the primary forms and data fields related to custom forms.
!

SRS:CFGCustomForm—SRS:CFGCustomForm registers the custom forms to be

used as part of the Provide Information stage of submitting a service request. Selection of the custom form is done while defining the SRD. available to illustrate how custom forms work. The display only form is used to illustrate how information does not have to be stored with the form when using custom fields. The information from the custom fields in this case is transferred to mapped fields and then passed back to the SR.

!

SRM:CustomformDisplayOnly is one of the sample custom forms that are

Catalog definition BMC Software, Inc.

35

White Paper

Table 14: SRS:CFGCustomForm form Data Field Name
Location Company Template Name

Field ID 1000000001 302826000

Type Character Character

Description Tenant company Name displayed in selection menu from SRD Name of the custom form Server where the custom form resides Indication of if this registry record is active or inactive Locale of registry entry

Form Name Server Status

302826200 301286600 7

Character Character Selection

Locale

160

Character

Table 15: SRM:CustomformDisplayOnly Data field name Custom Fields
System for password reset Type your new password Re-type your new password ConcatenateFields

Field ID 302983800 302984000 302984100 302984400 1000000063 1000000064 1000000065 301429600 301438012 301417500 301528400 301563800 301454800 301455200

Type Character Character Character Character Character Character Character Date and Time Selection Character Character Character Character Character Character Character

Description Name of System. Enter New Password for System Compare value to originally type password Field used to combine data CategoryTier1 CategoryTier2 CategoryTier3 Date Required Request Type SCO Description SR_NotesComments SRWiz_RequesterMiddle Name SRWizRequestedFor Company SRWizRequestedForEmail SRWizRequestedForFirst Name SRWizRequestedForLast Name

Available data fields mapped to service request Mapped to SR field
CategoryTier1 CategoryTier2 CategoryTier3 DateRequired Request Type SCODescription SR_NotesComments SRWiz_RequesterMiddleName SRWizRequestedForCompany SRWizRequestedForEmail

SRWizRequestedForFirstName 301455000 SRWizRequestedForLastName

301454900

36

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Table 15: SRM:CustomformDisplayOnly (Continued) Data field name
SRWizRequestedForPhone SRWizRequesterCompany SRWizRequesterEmail SRWizRequesterFirstName SRWizRequesterLastName SRWizRequesterPhone SR Type Field 1 SR Type Field 2 SR Type Field 3 SR Type Field 4 SR Type Field 5 SR Type Field 6 SR Type Field 7 SR Type Field 8 SR Type Field 9

Field ID 301455100 301442500 301425700 301425500 301425300 301425600 300070001 300070002 300070003 300070004 300070005 300070006 300070007 300070008 300070009

Type Character Character Character Character Character Character Character Character Character Character Character Date and Time Date and Time Integer Integer

Description SRWizRequestedForPhone SRWizRequesterCompany SRWizRequesterEmail SRWizRequesterFirstName SRWizRequesterLastName SRWizRequesterPhone SR Type Field 1 SR Type Field 2 SR Type Field 3 SR Type Field 4 SR Type Field 5 SR Type Field 6 SR Type Field 7 SR Type Field 8 SR Type Field 9

Supporting connection fields Control Buttons
btn_Submit Close_btn z3Btn_SaveAsDraftSRD

300978700 350100012 302897100

Control Control Control

Submit Request Close Custom form Dialog Execute Save As Draft settings Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Catalog definition 37

System fields
Current user ID for the system

302983900

Character Character Character Character Date and Time Date and Time Character Character Character Character Selection Integer Character

Custom_CFG_form_InstanceID 302825900 CustomformName CustomformServer Expected Date Expected DateTime InstanceID LoggedInUserName Request Number ServiceCatalogInstanceID SR_TurnaroundTimeUnits SRD_TurnaroundTimeX SRDTitle

3000010 3000020 302791600 302811200 179 301354000 1000000829 301303200 302793600 302793500 301417400

BMC Software, Inc.

White Paper

Table 15: SRM:CustomformDisplayOnly (Continued) Data field name
SRInstanceID SRStatus TitleFromSRD z1D HolidayTag z1D WorkdayTag z1D_Action z1D_Char01 z1D_CommunicationSource z1D_FullName z1D_Integer z1D_OperationID z1D_ParentObjectKeyword

Field ID 301368700 302933200 302829600 250000054 250000051 301311700 301325300 10001854 301308600 302767400 301443200 300363000 301443100 301638000 10001846 10001826 10001828 10001825 10001824 10001829 301712900 10001827 300037600 301168000

Type Character Selection Character Character Character Character Character Character Character Integer Character Character Character Character Integer Date and Time Character Selection Character Character Selection

Description Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow Supported By Workflow

z1D_RequestedForInstanceID 301465800 z1D_RequesterInstanceID z1D_TmpInteger1 z1D_WorkInfoDate z1D_WorkInfoDetails z1D_WorkInfoSecureLog z1D_WorkInfoSummary z1D_WorkInfoType z1D_WorkInfoViewAccess z2AF_WorkInfoAttachment z2AP_WorkInfoAttachment z2PH_DebugHolder zTmpHeader

Attachmen Supported By Workflow t Attachmen Supported By Workflow t Pool Page Holder Character Supported By Workflow Supported By Workflow

38

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Audit Log

By default, AR System level auditing is enabled on the Service Request Definition form for the following fields:
! ! ! ! ! ! !

SRD Status Status Reason Locale Locale Status Effective End Date Price Level

The SRD:AuditLog table records are related to an SRD by way of a foreign key (Request ID).
Figure 23: Audit log entity relationships
SRD:ServiceRequestDefinition InstanceID Request ID (Field 1 for join form) SRD_Number (auto-generated) SRD_Request_ID (Request ID from base) Navigational Category 1 Navigational Category 2 Navigational Category 3 SRD_Level Custom_CFG_Form_InstanceId PDT_InstanceID PDT_Name SurveyAssocInstanceID FK:Original Request ID= Request ID

SRD:AuditLog Original Request ID

Join: InstanceID=SRD_InstanceID SRD:ServiceRequestDefinition _base InstanceID BusinessServiceInstanceId SRD_BusinessService BusinessProcess_ InstanceId BusinessProcess_ ReconId Sandbox_DatasetID Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition _DispProp SRD_Status SRD_Title SRD_Description SRD_Locale SRD_InstanceID SRD_Aliases TakeSRDOfflineFlag SRD_Level SRD_Instructions deleted SRD_Price Navigation Tier1 Navigation Tier2 Navigation Tier3

Configurable notifications

Notifications are generally managed by the Foundation Notification Engine subsystem. This is a rules-based system where the conditions of what triggers a notification in the NTE:SYS-NT process control form are defined and managed . For more information about the Foundation Notification Engine subsystem, see the ITSM 7.x Architecture white paper.

Catalog definition BMC Software, Inc.

39

White Paper

Figure 24: Configurable notifications entity relationships
Create entry to notify catalog manager NTE:SYS-NT Process Control

SRD:ServiceRequestDefinition InstanceID Request ID (Field 1 for join form) SRD_Number (auto-generated) SRD_Request_ID (Request ID from base) Navigational Category 1 Navigational Category 2 Navigational Category 3 SRD_Level Custom_CFG_Form_InstanceId PDT_InstanceID PDT_Name SurveyAssocInstanceID

Join: InstanceID=SRD_InstanceID SRD:ServiceRequestDefinition _base InstanceID BusinessServiceInstanceId SRD_BusinessService BusinessProcess_ InstanceId BusinessProcess_ ReconId Sandbox_DatasetID Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition _DispProp SRD_Status SRD_Title SRD_Description SRD_Locale SRD_InstanceID SRD_Aliases TakeSRDOfflineFlag SRD_Level SRD_Instructions deleted SRD_Price Navigation Tier1 Navigation Tier2 Navigation Tier3

Subsystem integrations
This section describes the subsystem integrations. Approvals BMC SRM uses the AR System approval engine to manage approvals of SRDs and leverages those supporting forms of the ITSM foundation that are prefixed with APR:. The approval rules for SRDs are established by way of the Application Administration Console. The SRD settings form is used to determine whether the approval engine rules should be used to determine the approvers. The approval rules can apply to a specific company or be defined as Global and applicable to all companies.

40

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 25: Approvals entity relationships
SRD:CFG Settings

Get setting for approval

SRD:ServiceRequestDefinition InstanceID Request ID (Field 1 for join form) SRD_Number (auto-generated) SRD_Request_ID (Request ID from base) Navigational Category 1 Navigational Category 2 Navigational Category 3 SRD_Level Custom_CFG_Form_InstanceId PDT_InstanceID PDT_Name SurveyAssocInstanceID

Join: InstanceID=SRD_InstanceID SRD:ServiceRequestDefinition _base InstanceID BusinessServiceInstanceId SRD_BusinessService BusinessProcess_ InstanceId BusinessProcess_ ReconId Sandbox_DatasetID Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition _DispProp SRD_Status SRD_Title SRD_Description SRD_Locale SRD_InstanceID SRD_Aliases TakeSRDOfflineFlag SRD_Level SRD_Instructions deleted SRD_Price Navigation Tier1 Navigation Tier2 Navigation Tier3

NOTE
See the SRM 2.0 Administration Guide for a more comprehensive description of the approval features that are available the SRM Solution.

NOTE
On an SRD-by-SRD basis, a flag is available to determine whether approvals as defined in SRD:CFGSettings should be applied.

Catalog definition BMC Software, Inc.

41

White Paper

Figure 26 illustrate the process flow of an SRD if the approval engine is used to determine approvers.
Figure 26: Submitting an SRD for approval
Submitting a Service Request Definition (SRD) for approval

Service Request Definition

1. Set Status = Rquest for Approval 2. Check to see if approval of this SRD is required. If so, make a call to the Approval Engine

Criteria for Approval

Approval Engine

AP:Detail APR:SYS-Approval Definition Approvers 3. Approval engine creates entries in AP:Detail and AP:Signature forms

AP:Signature

APR:Approver Lookup (Approval Mappings)

42

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Approvals are managed by way of the Approval Console, which applies the flow as shown in the following diagram.
Figure 27: Approving an SRD item using approval central
Approving a Service Request Definition item using Approval Central

Approval Central

1. SRD is Approved or Rejected

Approval Engine

2. Approval engine checks rules to see what needs to be done for Approved or Rejected items

Service Request Definition

3. Approval Engine updates SRD with data based on Set Fields actions defined in AP:Rules

AP:Process Definition

AP:Rules

In addition to the SRD:CFGSettings form, the following join forms are used to support the integration of the SRD with the approval engine:
! SRD:ServiceRequestDefinitionApDetail ! SRD:ServiceRequestDefinitionAPDetailSignature ! SRD:ServiceRequestDefinitionApproverLookup

Service level management

The BMC Service Level Management application is used to manage all service level agreement requirements. If BMC Service Level Management is installed, service targets can be established at the time the SRD is defined for all service requests initiated from a given SRD. These service requests also are subject to any general service level agreement rules that have been established by way of the BMC Service Level Management console. The two primary forms used to capture and relate a given service level agreement to an SRD are the SLM:Association form and the SLM:ServiceTarget forms.

Catalog definition BMC Software, Inc.

43

White Paper

Figure 28: Service level management entity relationships
SRD:ServiceRequestDefinition InstanceID Request ID (Field 1 for join form) SRD_Number (auto-generated) SRD_Request_ID (Request ID from base) Navigational Category 1 Navigational Category 2 Navigational Category 3 SRD_Level Custom_CFG_Form_InstanceId PDT_InstanceID PDT_Name SurveyAssocInstanceID

Join: InstanceID=SRD_InstanceID SRD:ServiceRequestDefinition _base InstanceID BusinessServiceInstanceId SRD_BusinessService BusinessProcess_ InstanceId BusinessProcess_ ReconId Sandbox_DatasetID Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition _DispProp SRD_Status SRD_Title SRD_Description SRD_Locale SRD_InstanceID SRD_Aliases TakeSRDOfflineFlag SRD_Level SRD_Instructions deleted SRD_Price Navigation Tier1 Navigation Tier2 Navigation Tier3

FK:InstanceID=instanceId2 SLM:Association associationTypeId'="SVT_SRD_RELATE" instanceId1 instanceId2

FK:instanceId1=InstanceId SLM:ServiceTarget InstanceId

The BMC Service Level Management integration with BMC SRM helps the catalog manager, for example, to easily define what cost should be incurred when the goal is not met. The catalog manager could also define milestone templates and action templates that can be triggered when a certain percentage of the goal is complete, or not met at all. A simplified interface has been provided from the SRD to establish new service targets. The INT:SRMSLM:ConfigServiceTarget:Defaults form is used to facilitate this simplified process or interface by storing predefined field defaults that can be loaded into the service target definition, thereby speeding up the service target definition process. As part of configuring the BMC SRM system, service target defaults can be established for the Service Target Title. The default value for the Service Target Title is generated using data from the SRD. During cross launch, BMC SRM passes the SRD ID and title information to BMC Service Level Management, which is used for the SVT Title. This applies to the following values:
! ! !

Goal Type Status Hours

44

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

! ! ! !

Minutes Impact Cost Business Entity Measurement Criteria Template

For more information about BMC Service Level Management, see the BMC Service Level Management 7.0 User’s Guide and the BMC Service Level Management Architecture white paper. Primary forms This section describes the primary forms.
!

SLM:Association contains the associations between SRD and service targets. This association table supports the system’s ability to search for and view events, conditions, actions, and objects associated with a given rule. SLM:Service Target defines measurements against a specified goal. INT:SRMSLM:ConfigServiceTarget:Defaults lets the user call on predefined

! !

field defaults that can be loaded into the service target definition, thereby speeding up the service target definition process.

BMC Atrium CMDB

The service catalog manager, when creating SRDs, can search and associate a business service from the BMC Atrium Configuration Management Database (CMDB) with the SRD. The ability to create a business process record when the SRD becomes deployed is also supported. Both the DatasetID and the Reconciliation Job Name fields must be set in the SRD:Settings form. The Create Business Process flag on the SRD also must be checked to enable this functionality. In addition to creating a business process, a relationship is also created between the business process and the business service. Figure 29 illustrates the relationships that are established with the BMC Atrium CMDB after the SRD is deployed.
Figure 29: Relations between a deployed SRD and the BMC Atrium CMDB
CMDB Integration Sandbox_DatasetID - the sandbox and RE Job Name come from SRM :CFG Rules ReconId comes from Business Service CI entry from BMC.CORE:BMC_BusinessService Business Process ReconId is generated by SRD

BMC.CORE:BMC_BusinessService InstanceId Name DatasetId ReconciliationIdentity

Destination.InstanceId=InstanceId

SRD:ServiceRequestDefinition InstanceID SRD_Title BusinessServiceInstanceId SRD_BusinessService BusinessProcess _ InstanceId BusinessProcess _ ReconId Sandbox_DatasetID Reconciliation Job Name

FK:BusinessServiceInstanceId

BMC.CORE:BMC_Dependency Destination.ClassId' = "BMC_BUSINESSSERVICE" Destination.InstanceId' Name = "DEPENDENCY" Source.ClassId = "BMC.CORE:BMC_BUSINESSPROCESS" Source.InstanceId Source.InstanceId=InstanceId

BMC.CORE:BMC_BusinessProcess FK:BusinessProcess_InstanceId InstanceId Name = (SRD_Title) DatasetId ReconciliationIdentity SourceLocation = "BMC.SRMS" SerialNumber = (SRD InstanceId) Company

SRD:ServiceRequestDefinition _base InstanceID BusinessServiceInstanceId SRD_BusinessService BusinessProcess _ InstanceId BusinessProcess _ ReconId Sandbox_DatasetID

SRD:ServiceRequestDefinition _DispProp SRD_Title

RE:Job Operation Job Name RECommand=Start

Catalog definition BMC Software, Inc.

45

White Paper

Assignment

BMC SRM assignment uses the BMC Remedy Assignment Engine. The supporting assignment data that the Assignment Engine uses is part of the installation. This BMC SRM assignment data is seen in the Assignment Engine Administration Console under the following tabs:
! ! !

Process Forms Rules

The ASGPID (Assignee Group ID) value is pulled from the CFG:Assignment form and is used to establish the required foreign key link on the SRD. From this value the assignee person can be derived using the Assignment Engine.
Figure 30: Assignment entity relationships
CFG:Assignment

Reference for Assignee Group

SRD:ServiceRequestDefinition InstanceID Request ID (Field 1 for join form) SRD_Number (auto-generated) SRD_Request_ID (Request ID from base) Navigational Category 1 Navigational Category 2 Navigational Category 3 SRD_Level Custom_CFG_Form_InstanceId PDT_InstanceID PDT_Name SurveyAssocInstanceID

Join: InstanceID=SRD_InstanceID SRD:ServiceRequestDefinition _base InstanceID BusinessServiceInstanceId SRD_BusinessService BusinessProcess_ InstanceId BusinessProcess_ ReconId Sandbox_DatasetID Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition _DispProp SRD_Status SRD_Title SRD_Description SRD_Locale SRD_InstanceID SRD_Aliases TakeSRDOfflineFlag SRD_Level SRD_Instructions deleted SRD_Price Navigation Tier1 Navigation Tier2 Navigation Tier3

46

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Process definition template architecture
The process definition template and the application object template are structures designed to encode the fulfillment process of an associated SRD. AOTs are “stubs” that know how to interact bidirectionally with integrated fulfillment systems. They also act as the conduit to map defaulted data and information provided by the user to specific fields on the interface forms of the back-office fulfillment systems. In addition, these stubs are used to model the logical steps in a fulfillment process. PDTs act as container objects that consist of AOTs and other PDTs and establish the dependency and sequence of each step and stub in the process. There are several other structures of BMC SRM that make PDTs and AOTs available with the capability to encode the fulfillment process. The application registry of BMC SRM identifies the key characteristics of back-office applications required to support a seamless integration. BMC SRM 2.0 is integrated with the Change Management, Incident Management, and Work Order Management applications by default. The following diagram illustrates the relationship of all of the key components involved in supporting the encoding of the fulfillment process with PDTs.
Figure 31: Key components supporting encoding of the fulfillment process with PDTs

Application Registry
Registry Application AOT AOI Local / ID Object Name Name Remote R214 Change-NA ChTmplate CHReq Local R457 Incident IncTmplate Incident Remote R234 Change-AP ChTmplate CHReq Remote
Registry ID R214 R457 R234 Interface ARS DSO DSO Cmd Sync None Poll DSO Init.Req. DSO Subscribe Parameters 1 2 None None X Y W Q

Process Definition

Application Object Template Pool
Application Object Template AO: Work Order Name: Issue Badge ID: 123 Regid: R324 Application Object Template AO: Work Order Name: Setup Office TID: 183 Regid: R124 Application Object Template AO: Change Request Name: Install Desktop ID: 175 Regid: R214 Application Object Template AO: Incident Name: Enable Ports ID: 223 Regid: R457

Questions
Associate ID A B C D Registry Attribute ID Name R214 Contact R215 Location R216 Priority R457 Contact AOI Values Field Question? Predefined Default Name N/A Request For None Location Location? None None Priority Priority None Low Name N/A Request For None Carry Over No Yes Yes No

Back Office Applications
Work Order Template Name: Issue Badge ID: 123 Assign To: Group TT Work Order Template Name: Set Up Office ID: 183 Assign To: Group Change Request Template Name: Install Desktop ID: 175 Assign To: Indiv. Incident Template Name: Enable Ports ID: 223 Assign To: Group

TT

TT

TT

Flows

X

Associations

TT Task Template

Catalog definition BMC Software, Inc.

47

White Paper

In the application object template pool there are a set of stubs that have been defined to interact with Change Management, Work Order Management, and Incident Management. Figure 32, shows that there are templates for each application where a stub can be created. When building a process, these stubs are used to define the order of each step in the process.
Figure 32: Restoring a database as a change request

Automated Tools

Process Def. Template

A

Service Request Management System

Application Registry
Registry Application AOT AOI Local / ID Object Name Name Remote R214 Change-NA ChTmplate CHReq Local R457 Incident IncTmplate Incident Remote R234 Change-AP ChTmplate CHReq Remote
Registry ID R214 R457 R234 Interface ARS DSO DSO Cmd Sync None Poll DSO Init.Req. DSO Subscribe Parameters 1 2 None None X Y W Q

Process Definition

Service Request Definition • Title • Description • Nav. Categories • Entitlement • Approvals

Service Request • End User Console • Activity Log • SLA’s • Surveys • Approvals

Container Object
B
Application Object Template AO: Work Order Name: Issue Badge ID: 123 Regid: R324

1

Process Definition
AOT AOT AOT

Instantiation of Process Def.
AOI AOI

C

Application Object Template AO: Work Order Name: Setup Office TID: 183 Regid: R124

Application Object Template AO: Incident Name: Enable Ports ID: 223 Regid: R214

Application Object Template Pool
Application Object Template AO: Work Order Name: Issue Badge ID: 123 Regid: R324 Application Object Template AO: Work Order Name: Setup Office TID: 183 Regid: R124 Application Object Template AO: Change Request Name: Install Desktop ID: 175 Regid: R214 Application Object Template AO: Incident Name: Enable Ports ID: 223 Regid: R457

2

2

AOT

AOI

D

Application Object Template AO: Change Request Name: Install Desktop ID: 175 Regid: R457

Questions
Associate ID A B C D Registry Attribute ID Name R214 Contact R215 Location R216 Priority R457 Contact

3

AOI Values Field Question? Predefined Default Name N/A Request For None Location Location? None None Priority Priority None Low Name N/A Request For None

Carry Over No Yes Yes No

Back Office Applications
Work Order Template Name: Issue Badge ID: 123 Assign To: Group TT Work Order Template Name: Set Up Office ID: 183 Assign To: Group Change Request Template Name: Install Desktop ID: 175 Assign To: Indiv. Incident Template Name: Enable Ports ID: 223 Assign To: Group

TT

TT

TT

Flows

X

Associations

TT Task Template

After that operation is complete, a change request to reset a database server and a work order to reset a network hub is executed. After those operations are complete, an incident is generated to load passwords. As discussed in “RPD model (request, process, data mapping)” on page 12, to invoke this process, it must be associated with an SRD. When the SRD is deployed, it is available for selection from the catalog by entitled users.

Process definition template structure
The PDT is a join form that is made up of two base forms. The primary base form (SRM:ProcessDefinitionTemplate_Base) stores information that makes up the core definition of the PDT and is not displayed to the user. This form is not localized. The secondary base form (SRM:ProcessDefinition_DispProp) stores information from the PDT that is visible to the user. This form can be localized. The resulting join form (SRM:ProcessDefinitionTemplate) establishes a one-to-many relationship between the base information and the multiple languages that might be defined for each display record.

48

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 33: PDT entity relationships
SRM:ProcessDefinitionTemplate $InstanceId$ = 'PDT_InstanceID'

P: SRM:ProcessDefinitionTemplate_Base Company InstanceId PDT_ID Request Frequency Request Type Status VersionNumber

S: SRM:ProcessDefinitionTemplate_DispProp InstanceId NavigationTier1 PDT_Description PDT_InstanceID PDT_Locale PDT_Name

SRD relationship to PDT
PDTs are related to one or more SRDs by way of an association table and more directly by way of a foreign key. Recording the relationship in the association table supports other join forms used to facilitate the data mapping functions and catalog definition interaction model.

Catalog definition BMC Software, Inc.

49

White Paper

Figure 34: SRD relationship to PDT
SRD:ServiceRequestDefinition InstanceID Request ID (Field 1 for join form) SRD_Number (auto-generated) SRD_Request_ID (Request ID from base) Navigational Category 1 Navigational Category 2 Navigational Category 3 SRD_Level Custom_CFG_Form_InstanceId PDT_InstanceID PDT_Name SurveyAssocInstanceID

Join: InstanceID=SRD_InstanceID SRD:ServiceRequestDefinition _base InstanceID BusinessServiceInstanceId SRD_BusinessService BusinessProcess_ InstanceId BusinessProcess_ ReconId Sandbox_DatasetID Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition _DispProp SRD_Status SRD_Title SRD_Description SRD_Locale SRD_InstanceID SRD_Aliases TakeSRDOfflineFlag SRD_Level SRD_Instructions deleted SRD_Price Navigation Tier1 Navigation Tier2 Navigation Tier3

FK:InstanceID= Assoc1InstanceID

SRM:Associations Assoc1InstanceID Assoc2InstanceID FK:Assoc2InstanceID=InstanceId SRM:ProcessDefinition Template InstanceId PDT_Name

FK:PDT_InstanceID=InstanceId PDT_Name=PDT_Name

Application object template
Since application object templates (AOTs) are designed to work with a specific fulfillment application, they are directly tied to specific applications recorded in the application registry. An AOT can also be used as part of multiple process definitions. Therefore, their relationship to the PDTs is managed by way of the SRM:Association table, which permits the many-to-many data model that exists between AOTs and PDTs. The SRM:AppTemplateBridge form is used to store what has been referred to as AOTs.

50

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 35: AOT entity relationships
CAI:AppRegistry Instance ID SRD:ServiceRequestDefinition InstanceID PDT_InstanceID

SRM:ProcessDefinitionTemplate Instance ID PDT_Name FK:Instance ID=PDT_InstanceID

FK:Assoc1 Instance ID=Instance ID FK:Assoc2 Instance ID=Instance ID

FK:Instance ID= AppRegistry Instance ID

SRM:Associations Instance ID Assoc1 Instance ID Assoc2 Instance ID FK:Assoc1 Instance ID=InstanceID

FK:Assoc2 Instance ID=Instance ID

SRM:AppTemplateBridge Instance ID AppRegistry Instance ID TemplateName

Primary forms and data fields
This section describes the process definition template primary forms and data fields.
!

SRM:ProcessDefinitionTemplate contains the records that represent the process definition templates. It is a join form that brings together the SRM:ProcessDefinitionTemplate_Base form and the SRM:ProcessDefinitionTemplate_DispProp form.

The following are the join criteria:
! ! !

Instance ID of the base form PDT_InstanceID of the Display Properties form

SRM:Associations is primarily a cross-reference form used to support the

many-to-many relationships of the SRM definition architecture. This includes associations between PDTs and AOTs, SRDs, PDIs (run-time instance of the PDT), AOIs (run-time instance of the AOI), and service requests.

Catalog definition BMC Software, Inc.

51

White Paper SRM:ProcessDefinitionTemplate_Base: contains the core PDT information

!

that is not influenced by localization. The following table contains a detailed description of the data fields on the form.

Table 16: SRM:ProcessDefinitionTemplate_Base form Join data label Company InstanceID PDT_ID Request_Type Status VersionNumber
!

Source Data field name
Company InstanceID PDT_ID

Field ID 301453000 179 1 301438012 7 301307300

Type Character Character Character Character Selection Selection Character

Request_Frequency Request_Frequency 302771600
Request_Type Status VersionNumber

for the fields on the PDT.

SRM:ProcessDefinitionTemplate_DispProp contains the localized strings Table 17: SRM:ProcessDefinitionTemplate_DispProp form Join data label Category1 PDT_Description PDT_Locale PDT_Name Source Data field name
PDT_Description PDT_Locale PDT_Name

Field ID

Type Character Character Character Character

NavigationalTier1 1000000063

301244800 160 301244700

!

SRM:AppTemplateBridge contains the records that represent the AOTs. The

following table contains a detailed description of the data fields on the form.
Field ID 1 301287600 301289000 112 301453000 179 301287500 301405400 301286600 7 1000001437 301287400 Type Character Character Character Character Character Character Character Selection Character Selection Character Character Length 15 40 254 255 60 40 254 n/a 255 n/a 254 80

Table 18: SRM:AppTemplateBridge form Data field name
AOTID AppRegistryInstanceID AppRegistryName Assignee Groups Company InstanceID Name Protocol Server Status Template Name TemplateInstanceID

52

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Table 18: SRM:AppTemplateBridge form (Continued) Data field name
TemplateRequestID TemplateSummary Type URL

Field ID 301289100 8 300062100 302911400

Type Character Character Character Character

Length 24 254 36 255

Data mapping architecture
After an SRD is associated with a process definition template, the context has been established to support mapping data provided by the user to data fields of the integrated back-office systems. The fields and the data mapped to them are referred to as target data. This identifies the intended destination of the information provided from the front office (BMC SRM). The values of the target data can also be defaulted, which is an advantage in reducing the amount of information the user has to manually provide. For each application in the registry, there is a master list of target data fields that correspond to the fields on the application’s specified interface form. The list of these fields, their characteristics, and default values are stored in the SRM:AppTargetData form. AOTs are also associated with an application in the registry. As part of the definition of an AOT, the administrator can select which of the target data fields can be overwritten, either by responses to questions from the user or by alternate default values. For example, suppose that there are 28 relevant fields on the interface form for the Incident Management system. If an AOT is set up for the Incident Management system, there are 28 records in the SRM:AppTargetData table that represent target data fields. When the AOT is defined, it can be configured to expose any of the 28 target data fields available to be populated when included as part of a PDT. In Figure 36, AOT1 has been defined to make target data fields 1, 2, and 3. AOT2 has exposed field 4 and AOT3 has exposed fields 4, 5, and 6.

Catalog definition BMC Software, Inc.

53

White Paper

Figure 36: Data mapping

SRD

Questions Library
Who Me? What Time? When, Today? How Much? Location? Where?

PDT
AOT1 AOT2 AOT3
TD - 1 TD - 2 TD - 3

Target Data
1TD - 1 1TD - 2

TD - 4

1TD - 3 2TD - 4 3TD - 4

Ignore

TD - 4 TD - 5 TD - 6

3TD - 5 3TD - 6

Ignore Default

Registry Master Field List

Mapped Data

So, when the PDT is associated to an SRD, questions can be mapped to the these fields and the responses from the user will supersede whatever the default values were in the master target data list for these fields. Questions are set up as separate entities and can be mapped to any of the target data fields. The question entity is made up of both text and a response format. The text portion of the question entity is simply the question or prompt presented to the user (for example, what building do you require access to? or describe in detail your issue). The response format for each question can be free-form text, a restricted selection list, a character field supported by a menu, and so on. The question entities are stored and maintained in the SRM:QuestionsLibrary form. After the context is provided by associating an SRD to a PDT, a question entity can be associated to a target data field, which establishes a mapping between the response to the question and a field on the back-office interface form.

Data mapping structures
The following sections contain entity relationship (ER) diagrams that describe the forms that support the data mapping between default values and questions to the target data fields of the back-office interface forms.

SRD relationship to data mapping
At the highest level, the two primary forms that are linked to the SRD and support the data mapping process are SRM:UniqueQuestionsList and SRM:SourceToTargetDataAssociations.

54

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 37: SRD to data mapping relationship

SRD:ServiceRequestDefinition InstanceID Request ID (Field 1 for join form) SRD_Number (auto-generated) SRD_Request_ID (Request ID from base) Navigational Category 1 Navigational Category 2 Navigational Category 3 SRD_Level Custom_CFG_Form_InstanceId PDT_InstanceID PDT_Name SurveyAssocInstanceID SRM:UniqueQuestionList ParentInstanceID

FK:InstanceID= ParentInstanceID Join: InstanceID=SRD_InstanceID SRD:ServiceRequestDefinition _base InstanceID BusinessServiceInstanceId SRD_BusinessService BusinessProcess_ InstanceId BusinessProcess_ ReconId Sandbox_DatasetID Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition _DispProp SRD_Status SRD_Title SRD_Description SRD_Locale SRD_InstanceID SRD_Aliases TakeSRDOfflineFlag SRD_Level SRD_Instructions deleted SRD_Price Navigation Tier1 Navigation Tier2 Navigation Tier3 FK:InstanceID= ParentInstanceID

SRM:SourceToTargetData Associations ParentInstanceID

For a given SRD that is associated to a PDT, a set of relevant questions from the questions library can be linked. The links of these questions that are unique to a given SRD are maintained in the SRM:UniqueQuestionsList table. The links that establish the mapping of the target data to the corresponding unique question are stored in the SRM:SourceToTargetDataAssociations table. A more comprehensive view of the data mapping structures can be broken down into four primary segments:
!

Target Data Master List—the master list of target data fields for a given

back-office application.

!

given AOT.
!

Exposed Target Data Fields—the subset of target data fields exposed for a

PDT Target Data—the rollup of all target data fields associated with AOTs that are part of a PDT definition.

!

mappings.

Source to Target Data Mapping—the questions library and target data

Catalog definition BMC Software, Inc.

55

White Paper

Figure 38: SRD relationship to data mapping

SRD:ServiceRequestDefinition InstanceID Request ID (Field 1 for join form) SRD_Number (auto-generated) SRD_Request_ID (Request ID from base) Navigational Category 1 Navigational Category 2 Navigational Category 3 SRD_Level Custom_CFG_Form_InstanceId PDT_InstanceID PDT_Name SurveyAssocInstanceID SRM:UniqueQuestionList ParentInstanceID

FK:InstanceID= ParentInstanceID Join: InstanceID=SRD_InstanceID SRD:ServiceRequestDefinition _base InstanceID BusinessServiceInstanceId SRD_BusinessService BusinessProcess_ InstanceId BusinessProcess_ ReconId Sandbox_DatasetID Custom_CFG_Form_InstanceId SRD:ServiceRequestDefinition _DispProp SRD_Status SRD_Title SRD_Description SRD_Locale SRD_InstanceID SRD_Aliases TakeSRDOfflineFlag SRD_Level SRD_Instructions deleted SRD_Price Navigation Tier1 Navigation Tier2 Navigation Tier3 FK:InstanceID= ParentInstanceID

SRM:SourceToTargetData Associations ParentInstanceID

Target data master list
Associated with the application registry (CAI:AppRegistry) is the master list of fields for the interface of a given application. As an example, in addition to the application registry recording the application name of Change Management, it also lists the corresponding interface form. All of the related and relevant fields on the interface form for the Change Management system are listed in the SRM:AppTargetData form along with the characteristics of the field and, if applicable, the default value. The master list of target data fields for a given application in the registry is related by way of a foreign key.

56

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 39: Target data master list
CAI:AppRegistry Instance ID SRM:AppTargetData z1S_instanceId Application ID QuestionDescription FieldForAnswer MappedFieldID PrepopulateMode PrepopulateValueType PrepopulateValue PrepopulateValueLookupKeyword RequiredByApp O-LenCharFlag ActionMode ExposedToTemplate

FK:Instance ID=Application ID

FK:Instance ID= AppRegistry Instance ID SRM:AppTemplateBridge Instance ID AppRegistry Instance ID TemplateName FK:Assoc2 Instance ID=Instance ID SRM:Associations Instance ID Assoc1 Instance ID Assoc2 Instance ID SRD:ServiceRequestDefinition FK:Assoc1 Instance ID=InstanceID InstanceID PDT_InstanceID

FK:Assoc1 Instance ID=Instance ID FK:Assoc2 Instance ID=Instance ID SRM:ProcessDefinitionTemplate Instance ID PDT_Name

FK:Instance ID=PDT_InstanceID

AOT target data
One of the features of an AOT is the ability to identify a subset of target data fields to expose to the user interface. These exposed fields can then be mapped to questions, ignored, reset to a more current default value, or populated with values from the service request at the time it is initiated. The SRM:AppTargetDataAssociation form provides the relationship required to support the many-to-many relationship that exists between AOTs and Target Data fields for a given a application interface form. In other words, a given AOT can have many target data fields associated with it and a target data field can be related to multiple AOTs. As a result an association table is used to support this many-to-many relationship.

Catalog definition BMC Software, Inc.

57

White Paper

Figure 40: AOT Target data
CAI:AppRegistry Instance ID SRM:AppTargetData z1S_instanceId Application ID QuestionDescription FieldForAnswer MappedFieldID PrepopulateMode PrepopulateValueType PrepopulateValue PrepopulateValueLookupKeyword RequiredByApp O-LenCharFlag ActionMode ExposedToTemplate FK:Assoc2 Instance ID=z1S_instanceId SRM:AppTargetDataAssociations Instance ID Assoc1 Instance ID Assoc2 Instance ID ActionMode DefaultValue Exposed FK:Instance ID= AppRegistry Instance ID FK:Assoc1 Instance ID=Instance ID SRM:AppTemplateBridge Instance ID AppRegistry Instance ID TemplateName FK:Assoc2 Instance ID=Instance ID SRM:Associations Instance ID Assoc1 Instance ID Assoc2 Instance ID SRD:ServiceRequestDefinition FK:Assoc1 Instance ID=InstanceID InstanceID PDT_InstanceID

FK:Instance ID=Application ID

FK:Assoc1 Instance ID=Instance ID FK:Assoc2 Instance ID=Instance ID SRM:ProcessDefinitionTemplate Instance ID PDT_Name

FK:Instance ID=PDT_InstanceID

PDT target data rollup
The PDT acts as the container object for managing the sequential process flows of the fulfillment systems. Each step in the fulfillment process is represented by an AOT and maps to a back-office application that it interacts with. The exposed target data of each AOT in a PDT must be rolled up into a single list of targets for which the data source must be mapped. As a result, the SRM:AppTargetDataRollup form stores the relationships between the AOT, the exposed target data field, and the PDT that the AOT is related to. This table functions as a cross-reference association table that ultimately supports the mapping of data from the user interaction to the target data fields of the corresponding back-office applications.

58

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 41: PDT target data rollup
CAI:AppRegistry Instance ID SRM:AppTargetData z1S_instanceId Application ID QuestionDescription FieldForAnswer MappedFieldID PrepopulateMode PrepopulateValueType PrepopulateValue PrepopulateValueLookupKeyword RequiredByApp O-LenCharFlag ActionMode ExposedToTemplate FK:Assoc2 Instance ID=z1S_instanceId SRM:AppTargetDataAssociations Instance ID Assoc1 Instance ID Assoc2 Instance ID ActionMode DefaultValue Exposed FK:Instance ID= AppRegistry Instance ID FK:Assoc1 Instance ID=Instance ID SRM:AppTemplateBridge FK:Instance ID= AOTInstanceID Instance ID AppRegistry Instance ID TemplateName FK:Assoc2 Instance ID=Instance ID SRM:AppTargetDataRollup PDT_InstanceID AOTPDT_AssocInstanceID TargetDataInstanceID AOTInstanceID FK:Instance ID AOTPDT_AssocInstanceID SRM:Associations Instance ID Assoc1 Instance ID Assoc2 Instance ID SRD:ServiceRequestDefinition FK:Assoc1 Instance ID=InstanceID InstanceID PDT_InstanceID

FK:Instance ID=Application ID

FK:z1S_instanceId= TargetDataInstanceID

FK:Assoc1 Instance ID=Instance ID FK:Assoc2 Instance ID=Instance ID SRM:ProcessDefinitionTemplate FK:Instance ID=PDT_InstanceID Instance ID PDT_Name

FK:Instance ID=PDT_InstanceID

Questions and target data mapping
The remaining structures are designed to support the mapping of the data provided as part of the user interaction process to the exposed target data fields of the back-office applications. One method for populating the rolled-up target data fields of a given PDT is by mapping questions from the questions library (SRM:QuestionsLibrary). A subset of questions must first be selected as candidates for mapping to the target data fields. This subset of questions for a given SRD and PDT definition is stored in the SRM:UniqueQuestionsList form. The exposed target data fields can either be mapped to questions, a new default value, values from the service request when it is initiated, or simply ignored as part of the mapping process. The definition of the mapping for each of these fields is supported by the SRM:MasterDataMappingList and SRM:SourceToTargetDataAssociations forms. The SRD:QuestionTargetDataMapping dialog box provides the user interface for completing this mapping operation.

Catalog definition BMC Software, Inc.

59

White Paper

Figure 42: Questions and target data mapping
CAI:AppRegistry Instance ID SRM:AppTargetData z1S_instanceId Application ID QuestionDescription FieldForAnswer MappedFieldID PrepopulateMode PrepopulateValueType PrepopulateValue PrepopulateValueLookupKeyword RequiredByApp O-LenCharFlag ActionMode ExposedToTemplate FK:Assoc2 Instance ID=z1S_instanceId SRM:AppTargetDataAssociations Instance ID Assoc1 Instance ID Assoc2 Instance ID ActionMode DefaultValue Exposed FK:Instance ID= AppRegistry Instance ID FK:Assoc1 Instance ID=Instance ID SRM:AppTemplateBridge Instance ID AppRegistry Instance ID TemplateName FK:Instance ID= AppObjectTemplateInstanceID FK:InstanceID= ParentInstanceID FK:InstanceID= ParentInstanceID SRM:SourceToTargetDataAssociations Instance ID ParentInstanceID AOTAssociationInstanceID AppObjectTemplateInstanceID TargetDataInstanceID TDSourceInstanceID UniqueQuestionInstanceID MapTargetTo Default Value SRM:UniqueQuestionList FK:InstanceID= UniqueQuestionInstanceID InstanceID ParentInstanceID DIDInstanceID Order Required Default Value SRM:QuestionsLibrary instanceId Question Text Category AnswerFormat AnswerFieldTypeDeveloper Name

FK:Instance ID=Application ID

SRM:MasterData MappingList InstanceID FormName Server FieldID

FK:z1S_instanceId= TargetDataInstanceID

FK:z1S_instanceId= TargetDataInstanceID

FK:InstanceID=TDSourceInstanceID

FK:instanceId=DIDInsatnceID

FK:Instance ID= AOTInstanceID

FK:Assoc2 Instance ID=Instance ID SRM:AppTargetDataRollup PDT_InstanceID AOTPDT_AssocInstanceID TargetDataInstanceID AOTInstanceID FK:Instance ID AOTPDT_AssocInstanceID SRM:Associations Instance ID Assoc1 Instance ID Assoc2 Instance ID FK:Instance ID= AOTAssociationInstanceID SRD:ServiceRequestDefinition FK:Assoc1 Instance ID=InstanceID InstanceID PDT_InstanceID

FK:Assoc1 Instance ID=Instance ID FK:Assoc2 Instance ID=Instance ID SRM:ProcessDefinitionTemplate FK:Instance ID=PDT_InstanceID Instance ID PDT_Name

FK:Instance ID=PDT_InstanceID

Primary forms
The following list describes the primary forms.
!

SRM:AppTargetData contains the list of target data that corresponds to a field on the back-office request form. It has the link to only the back-end field and prepopulated definition. SRM:AppTargetDataAssociations stores the association entries between

!

target data and AOTs.

! !

SRM:AppTargetDataRollup contains the rolled up TD for the PDT. SRM:QuestionsLibrary contains the list of questions; a question contains only a representation definition such as question text and answer format. SRM:UniqueQuestionList contains the unique list of questions for the SRD. SRM:MasterDataMappingList stores the list of form-field ID pairs for question

! !

and form options; for questions, the field IDs are hard-coded. This form supports only fields from the SR form.

!

SRM:SourceToTargetDataAssociations stores the list of TD for the SRD and

maps to target type (Question, SR form or Pre-Defined Value or flag to ignore) to the unique question list and pointer to master data mapping list.

60

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Supporting consoles
This section describes the consoles.

Application Administration Console
The Application Administration Console provides the structure to support configuring and administering the BMC SRM system. The following table lists all of the BMC SRM configuration options and the supporting forms under the Custom Configurations tab of the Application Administration Console.
Table 19: BMC SRM configuration options and support forms Parent menu item Advanced Sub-tree option Application Settings Configure Custom Form Data Rules SRD Setting Service Request HTML Configuration Survey Configuration Application Configuration Define Application Field Define Application Object Template Define Question Library Approval Entitlement Approval Mappings Entitlement Group Management Entitlement Management On Behalf of Management Navigational Categories Request Entry Management Navigational Categories Browse for Service Details Default Console Preferences Service Request Definition Image Management Service Request Image Configuration Service Request Search Exclusion String Service Level Management Work Order Service Target Defaults Rules Work Order Template Supporting form
SRM:ApplicationSettings SRS:CFGCustomForm SRM:CFG Rules SRD:CFG Settings SRS:ServiceRequestHTML SRM:ConfigSurveyQuestions SYS:Form Field Selection SRM:AppTemplateBridge

Define Application Target Data SRM:AppTargetData
SRM:QuestionsLibrary APR:Approver Lookup ENT:Entitlement Groups ENT:Entitlement Console OBO:On Behalf Of Console SRM:Navigational Category SRM:CategoryDetails/View: CategoryDetails SRS:DefaultPreferences SRM:CategoryDetails/View: ImageMapping SRS:ServiceRequestImages SRS:ServiceRequestQueryExcl usions INT:SLMSRS:ConfigServiceTar get:Defaults WOI:CFG Rules WOI:Template

Catalog definition BMC Software, Inc.

61

White Paper

Service Catalog Manager Console
The Service Catalog Manager Console is the primary console used to manage the creation and maintenance of both SRDs and PDTs. The SRS:ServiceCatalogManagerConsole form is a dialog box, and is divided into three functional areas: The left column of the console (area 1 in Figure 43) establishes the context for the console, supporting basic functions (reports, broadcasts, and setting preferences) and for navigating to other consoles. The top portion of the console (area 2 in the following illustration) supports searching for SRDs or PDTs. The bottom portion of the console (area 3 in the following illustration) contains the search results. There are two views or modes available for this panel. One is dedicated to searching and viewing the SRDs; the other is for PDTs. The context is set by way of the Console Focus menu in the navigation bar. These two views are managed by a page holder field that is both tabless and borderless.
Figure 43: Service Catalog Manager Console—searching and viewing SRDs

2

1

3

The SRD view is part of the Request Definition tab and is supported by a table field of the SRD:ServiceRequestDefinition form and lists all the SRDs that satisfy the specified search criteria. To the right of this table field, there is also a view field that contains the details of the selected SRD. It is in HTML format. The process definition view is part of the Process tab and is supported by a table field on the SRM:ProcessDefinitionTemplate form. It lists all the PDTs that satisfy the specified search criteria.

62

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 44: Catalog manager console—searching and viewing PDTs

2

1

3

The details of the process definition are displayed in the process tree, which reflects the sequence of the AOTs and PDTs that define the fulfillment process. It also lists the related SRD. A page holder field to the right of the PDT table partitions this information. The process tree is part of the Process tab and contains a table field for the join form SRM:SR_L6_PDIsAOIs. The associated SRD is part of the Request Definition tab and is displayed by way of a table field for the SRD:ServiceRequestDefinitionServiceCatalogAssociation form and a view field that contains details of the SRD. It appears in HTML format.

Execution of a run-time service request
This section focuses on the execution of a service request during runtime. The assumption is that definitions have been completed for the catalog, and users can search and select the SRDs that they are entitled to view.

Execution of a run-time service request BMC Software, Inc.

63

White Paper

Figure 45: Service request execution

Automated Tools

Service Request Management System

Service Request Definition • Title • Description • Nav. Categories • Entitlement • Approvals

Service Request • End User Console • Activity Log • SLA’s • Surveys • Approvals

Process Definition
AOT AOT AOT

Instantiation of Process Def.
AOI AOI

AOT

AOI

Execution
Just as service requests are derived from deployed SRDs in the catalog, a process definition instance (PDI) is initiated from the PDT associated with the selected SRD.

RPD model
The RPD model also applies to the run-time side of the BMC SRM system. The first step during runtime is to search for and then select a catalog entry that ultimately becomes a service request (R). The next stage in the process is to provide information that is passed to the back-end fulfillment applications. This satisfies the data mapping portion of the model (D). Finally, the initiation of the process (P) is executed. Therefore, the SR is the run-time version of the SRD. The run-time version of the PDT is the PDI. See Figure 46 on page 65 for an illustration of this mapping. As part of the process definition, the run-time version of AOT is the application object instance (AOI). Finally, the run-time version of the data mapping definitions is presented as part of the Provide Information stage of submitting a service request.

64

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 46: The RPD model

Definition – Service Request Definition – Process Definition Templates
• PDT’s • AOT’s

Runtime Execution – Service Request – Provide Information / Data
• Questions • Responses

– Data Mapping
• Questions • Target Data

– Process Definition Instance
• PDI’s • AOI’s

Service request architecture
The following sections focus on the overall architecture of the components that support the execution of a service request.

SR life cycle
When a SR is selected and submitted it has its own life cycle that reflects each of the stages in the fulfillment process. Table 20 describes each of these stages. These stages are also coordinated with the back-office fulfillment applications. For more information about how Change Management, Incident Management, and the status of work orders are reconciled with the stages of the service request, see the BMC Remedy IT Service Management 7.x Configuration Guide.
Table 20: SR life cycle Status or Status Reason Draft In Review Description Initial state or user saves draft of SR. For ad hoc requests waiting for SR coordinator action; all requests go into this state, but only ad hoc requests remain in this state and wait for SR coordinator action. SR agent needs additional information. Indicates a system error occurred with AOI. SR is going through the approval process. AOIs are created but no work has started on the AOIs. SR is being implemented; at least one of the back-end application requests is in progress. SR is completed but one or more AOIs has been cancelled or rejected. All AOIs have completed successfully. SR was rejected after being sent through the approval process.

Pending More Information System Error Waiting Approval Planning In Progress Completed With Issues Successful Rejected Cancelled

Execution of a run-time service request BMC Software, Inc.

65

White Paper

Table 20: SR life cycle (Continued) Status or Status Reason By User By Provider Closed Successful With Issues System Closed automatically without any problems. Based on survey results. Closed automatically but with some problems. Based on survey results. Closed automatically by the system based on the number of days the SR has been in an end state (completed or cancelled). The number of days to wait before closing SR is configurable. No survey completed. Cancelled SR has been closed. Description The user has cancelled the SR. This operation cancels the SR and sends a signal to the AOIs that the SR has been cancelled. One or more back-end AOIs have been cancelled; SR coordinator is notified.

Cancelled

Figure 47 on page 67 illustrates the state transition support for the service request. All of these transitions are driven by operations and are not manually invoked. For example, the transition from either Planning or Pending to In Progress is automatically triggered by events that occur when the back-office applications send commands indicating that they have moved into an In Progress state.

66

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 47: Legal state transition support for the service request

Draft

In Review SR doesn’t need approval

Cancelled by SR Coordinator

SR needs approval

Rejected

Waiting Approval

User cancels request Need more info Planning Pending

Need more info In Progress Re-open

Cancelled

Completed Automatically closed

Closed

Table 21 defines all the possible state transitions.State transitions
Table 21: State transitions In Progress Completed Cancelled Waiting Approval Planning Rejected Pending

In Review

Draft In Review Pending Planning In Progress

No No No No

Yes1 No No No No

No No Yes
2 2

No Yes Yes No No

No Yes Yes Yes No

No No No No -

No No No No
3

No No No Yes No No

Yes No Yes No Yes No Yes No Yes No Yes No

Waiting Approval No

Yes

Yes Yes Yes

Yes2

Execution of a run-time service request BMC Software, Inc.

Closed 67

Draft

White Paper

Table 21: State transitions (Continued) In Progress Completed Cancelled No No Waiting Approval Planning Rejected Pending

In Review

Completed Rejected Cancelled Closed
1For

No Yes No No

No No No No

Yes No No No

No Yes No No

No No No No

No No No

No No

No No No

Yes No Yes -

Yes No

ad hoc requests waiting for SR coordinator action. more information. 3If the back-end application status transitions from New to Completed, Rejected, or Closed, an SR can transition from Staged to Completed.
2Pending

Service request structure
The service request is a single regular form and has a variety of data types related to it as part of its life cycle. Figure 48 highlights the data that can be directly or indirectly connected to the service request. The following sections provide a more detailed view and a description of how the referenced information is related to the service request. For more information about these features, see the BMC Service Request Management 2.0 Guide for Administrators and Users.
Figure 48: Data that can be connected to the service requested
Service Request Definition
InstanceID SRM:Survey FK:Assoc2InstanceID= InstanceId SRM:Associations Assoc1InstanceID Assoc2InstanceID SRD:ServiceRequest Definition

Surveys
Custom Forms

Originating_Request_InstanceID

FK:Assoc1InstanceID= InstanceId FK:SRDInstanceID= InstanceID

Process Definition Instances
SRM:Process

Service Request InstanceID

FK:Originating_Request_InstanceID= InstanceId

Custom Form
SRInstanceID SRInstanceID

SRM:Request InstanceId Request Number Request ID SRDInstanceID

FK:Service Request InstanceID= InstanceId FK:SRInstanceID= InstanceId

FK:SRInstanceID= InstanceId

Question Responses
SRM:QuestionResponse SLM:EventSchedule

Application Object Instances
SRInstanceID CHG:Infrastructure Change

SRM:AppInstanceBridge

FK:SRInstanceID= InstanceId

FK:ApplicationInstanceID = InstanceId

ApplicationInstanceID

Service Level Management
SLM:Measurement SLA_Reference InstanceID

Service Request
Request Coordinator Requested By Requested For

FK:SRInstanceID= InstanceId

FK:SRInstanceID= InstanceId

Fulfillment Applications Work Info
SRInstanceID SRM:WorkInfo

WOI:Work Order

HPD:Help Desk

FK:SLA_Reference InstanceID= InstanceId Navigational Category 1, 2, 3

FK:Original Request Id= Request ID Region/Site Group/Site

Auditing Data
Original Request ID CTM:Region

SRM:SR_AuditLog

Navigational Categories

SRM:Navigational Category

COM:Company

CTM:Support Group

Foundation Data References
SIT:Site Group SIT:Site

CTM:People

Configuration Data
Get approval definition APR:SYSApproval Definition Get auto-close, survey, etc. SRM:CFG Rules

Create entry to notify

NTE:SYS-NT Process Control

68

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

Closed Yes

Draft

BMC Service Request Management 2.0 Architecture

Primary form and data fields
This section describes the primary form, SRM:Request (which is a regular form) and its data fields. This form stores service requests initiated from a selected SRD.
Table 22: SRM:Request Data field name
Actual Cost Actual Duration Actual Start Date Anticipated Approval Date Anticipated Completion Date Anticipated Duration Anticipated Start Date AOI Entry ID Approval Date Approval Phase Name Approval Process Name Approval Status Approved Date Assigned Support Company Assigned Support Organization Assignee Assignee Groups Category 1 Category 2 Category 3 CI_Name Closed Date Company Company Group Name Completion Date Concate_ Status_StatusReason Cost Center Customer Company Customer Company Group Name Customer Cost Center Customer Department Customer First Name Customer Full Name Customer Internet E-mail

Field ID 300354900 300798302 1000000348 1000001214 1000001182 300798301 300354902 301720300 303018300 1000003143 301236000 1000003264 1000001184 1000000251 1000000014 10010413 112 1000000063 1000000064 1000000065 200000020 302904200 1000000082 301438710 1000002195 302830300 1000000188 1000003299 301438720 300890300 1000003301 1000003297 1000000025 1000003302

Type Currency Integer Date and Time Date and Time Date and Time Integer Date and Time Character Date and Time Character Character Selection Date and Time Character Character Character Character Character Character Character Character Date and Time Character Character Date and Time Character Character Character Character Character Character Character Character Character

Length n/a n/a n/a n/a n/a n/a n/a 15 n/a 60 255 n/a n/a 254 60 254 255 60 60 60 254 n/a 254 254 n/a 255 25 254 254 25 60 30 128 255

Execution of a run-time service request BMC Software, Inc.

69

White Paper

Table 22: SRM:Request (Continued) Data field name
Customer Last Name Customer Location Company Customer Middle Name Customer Organization Customer Phone Number Customer Region Customer Site Customer Site Group Customer SiteID CustomFormName CustomFormServer Department Estimated Cost Expected Cost Expected Date First Name Form Name Impact InstanceID Internet E-mail Last Name Location Company Mail Station Manufacturer (2) Middle Name Offering Description Organization Phone Number Price Priority Product Cat Tier 1(2) Product Cat Tier 2 (2) Product Cat Tier 3 (2) Product Model and Version (2) Product Name (2) Reason Code_Assignee Reason Code_Manager Received Date

Field ID 1000003298 1000003310 300890310 1000003300 1000003306 200000013 200000015 200000014 1000003503 302826200 301286600 200000006 300354901 302783800 302791600 1000000019 301086200 1000000163 179 1000000048 1000000018 1000000001 1000000036 1000002270 300810110 1000000000 1000000010 1000000056 302793000 1000000164 1000001270 1000001271 1000001272 1000002269 1000002268 301324000 301323900 303051500

Type Character Character Character Character Character Character Character Character Character Character Character Character Currency Currency Date and Time Character Character Selection Character Character Character Character Character Character Character Character Character Character Currency Selection Character Character Character Character Character Character Character Date and Time

Length 30 254 30 60 50 60 60 60 15 254 254 60 n/a n/a n/a 30 38 n/a 38 255 30 254 30 254 30 0 60 50 n/a n/a 60 60 60 254 254 255 255 n/a

70

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Table 22: SRM:Request (Continued) Data field name
Region RejectApprovalStatusReason Request Manager Request Manager Login Request Number Request Type Required Date Service Location Address Service Type ServiceRequestApproval Site Site City Site Country Site Group SiteID Site State Province Site Street Site Zip or Postal Code SLA Responded SLM Status SolutionRequestID SR Type Field 1 SR Type Field 2 SR Type Field 3 SR Type Field 4 SR Type Field 5 SR Type Field 6 SR Type Field 7 SR Type Field 8 SR Type Field 9 SR_Actual_TurnaroundTime SR_Expected_TurnaroundTime SRD_Level SRD_Number SRD_TurnaroundTimeUnits SRD_TurnaroundTimeX SRDInstanceID Status

Field ID 200000012 1000003219 1000000218 1000000408 1000000829 301438012 1000001181 1000000038 1000000099 301248900 260000001 1000000004 1000000002 200000007 1000000074 1000000003 1000000037 1000000039 301788100 1000003009 301710700 300070001 300070002 300070003 300070004 300070005 300070006 300070007 300070008 300070009 303044300 303051400 302793100 302849400 302793600 302793500 301303200 7

Type Character Character Character Character Character Selection Date and Time Character Selection Selection Character Character Character Character Character Character Character Character Selection Selection Character Character Character Character Character Character Date and Time Date and Time Integer Integer Integer Integer Character Character Selection Integer Character Selection

Length 60 30 69 254 15 n/a n/a 255 n/a n/a 60 60 60 60 15 60 90 15 n/a n/a 38 0 80 80 254 254 n/a n/a n/a n/a n/a n/a 100 15 n/a n/a 38 n/a

Execution of a run-time service request BMC Software, Inc.

71

White Paper

Table 22: SRM:Request (Continued) Data field name
Status_Reason Submitter GroupID SuccInstanceNumCol Summary SurveyAssocInstanceID TitleFromSRD

Field ID 1000000150 1000001255 1000005875 301244700 302883500 302829600

Type Selection Character Column Character Character Character

Length n/a 50 n/a 255 38 255

Key related components
Figure 49 identifies the primary forms and systems related to the service request when it is initiated and illustrates the means by which they are connected.
Figure 49: Primary forms and systems related to the service request at initiation
FK:Assoc2InstanceID= InstanceId SRD:ServiceRequest Definition InstanceID SRM:Associations Assoc1InstanceID Assoc2InstanceID SRM:Process FK:Assoc1InstanceID= InstanceId FK:SRDInstanceID= InstanceID Service Request InstanceID

SRM:Survey Originating_Request_InstanceID

FK:Originating_Request_InstanceID= InstanceId Custom Forms SRInstanceID FK:SRInstanceID= InstanceId SRM:Request InstanceId Request Number Request ID SRDInstanceID FK:Service Request InstanceID= InstanceId FK:SRInstanceID= InstanceId SRM:AppInstanceBridge SRInstanceID

SRM:QuestionResponse SRInstanceID

FK:SRInstanceID= InstanceId

FK:SRInstanceID= InstanceId

WOI:Work Order HPD:Help Desk

SLM:EventSchedule ApplicationInstanceID

FK:ApplicationInstanceID = InstanceId

FK:SRInstanceID= InstanceId

CHG:Infrastructure Change

SRM:WorkInfo FK:SLA_Reference InstanceID= InstanceId Navigational Category 1, 2, 3 FK:Original Request Id= Request ID Region/Site Group/Site Request Coordinator Requested By Requested For SRInstanceID

SLM:Measurement SLA_Reference InstanceID

SRM:SR_AuditLog Original Request ID

SRM:Navigational Category

COM:Company

CTM:Region

CTM:Support Group

SIT:Site Group

CTM:People

SIT:Site

Get approval definition APR:SYSApproval Definition

Get auto-close, survey, etc.

Create entry to notify

SRM:CFG Rules

NTE:SYS-NT Process Control

72

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

The following sections provide a brief description for each related item. Surveys When a service request is initiated, if the SRD from which the SR was derived was configured to generate a survey, a record in the SRM:Survey form is created and linked to the SR by way of instance IDs, which are used as a foreign key. There is only one survey record for each SR. Primary data fields This section describes the primary data fields in the SRM:Survey form. This regular form stores surveys that are submitted by users.
Table 23: SRM:Survey form field descriptions Data field name
Assignee Groups Case Description Comment 1 Comment 2 Comment 3 Comment 4 Company InstanceID Last_Surveyed_Date PersonID Question 1 Question 1 Rating Question 2 Question 2 Rating Question 3 Question 3 Rating Question 4 Question 4 Rating Request Type* Status* SurveyID Survey Name1 Survey_e-Mail_Address

Field ID 112 230000008 260000020 260000021 260000022 260000023 1000000001 179 301694700 1000001021 260000000 260000010 260000001 260000011 260000002 260000012 260000003 260000013 301438012 7 1 302838900 301693800

Type Character Character Character Character Character Character Character Character Date Character Character Integer Character Integer Character Integer Character Integer Selection Selection Character Character Character

Length 255 128 0 0 0 0 254 38 n/a 15 255 n/a 255 n/a 255 n/a 255 n/a n/a n/a 15 255 50

Custom forms

If a regular custom form (one that stores data) has been set up to support the Provide Information stage of the service request submission process, the custom form has a field on it that is used to store the SR instance ID. This allows the link for the information stored with the custom form to be referenced later by the fulfillment applications.

Execution of a run-time service request BMC Software, Inc.

73

White Paper

Figure 50: Custom forms
SRM:Request FK:SRInstanceID= InstanceId InstanceId Request Number Request ID SRDInstanceID

Custom Forms SRInstanceID

Questions and responses

When completing a service request, the defined questions established as part of the SRD definition appear in the Provide Information tab. For each question, there are multiple response field formats. Based on the definition in the questions library, the appropriate format is displayed.
Figure 51: Questions and responses entity relationships
SRM:Request InstanceId Request Number Request ID SRDInstanceID SRM:QuestionResponse SRInstanceID FK:SRInstanceID= InstanceId

As illustrated in the following diagram, during the run-time stage, when an SR is being submitted, both questions and responses are stored in the SRM:QuestionResponse and related to the SR by way of the SR instance ID as a foreign key.

74

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 52: Storage of SR questions and responses during runtime
SRS:Service Request Console

SRS:SRC:SubmitQuestionResponse SRInstanceID = z1D_SRInstanceId SRS:SRC:SaveAsDraft SRS:SRC:SaveServiceRequest z1D_SRInstanceId

Transaction Level

'ParentInstanceID' = $DVF_SelectedSRDInstanceId$

SRM:QuestionResponse

SR InstanceId = InstanceID

SRM:Request

Definition Level

SRM:DataInputDefinition

DIDInstanceID SRM:QuestionList_Join

SRM:UniqueQuestionList

ParentInstance ID

SRD:ServiceRequestDefinition

Navigational categories

Navigational categories are carried over from the SRD and stored on the Service request at the time it is initiated. This information is available on the SR and can be referenced directly if there are reports that must factor in how a given SR was categorized in the catalog at the time it was selected.

Execution of a run-time service request BMC Software, Inc.

75

White Paper

Figure 53: Navigational categories
SRM:Request InstanceId Request Number Request ID SRDInstanceID

Navigational Category 1, 2, 3

SRM:Navigational Category

Foundation data references

The service request leverages the ITSM Foundation components to provide information that is critical to the routing and resolution of issues by the backoffice fulfillment systems. This would include individual characteristics such as location, company, name, contact info, and so on, for the people related to the SR, such as the SR coordinator, who the SR was requested for, who it was requested by, and so on. This information is actually stored on the service request.

76

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 54: Foundation data references
SRM:Request InstanceId Request Number Request ID SRDInstanceID

Region/Site Group/Site Request Coordinator Requested By Requested For

COM:Company

CTM:Region

CTM:Support Group

SIT:Site Group

CTM:People

SIT:Site

Configuration forms

When a service request is initiated, there is workflow that performs lookups against both the SRD and the supporting configuration forms that establish how the resulting SR is to be managed. If approvals are enabled, APR:Sys-ApprovalDefinition determines which approval process applies. The SRM CFG Rules forms define what the conditions are for automatically closing the SR after a specific period of time, whether a survey should be generated, and so on. The NTE:SYS-NTProcessControl form is referenced to determine which notifications should be going out and to whom.

Audit logging

The AR System server audit functionality that has been leveraged for the BMC SRM audit functionality. For a detailed description of the AR System server audit functionality, see BMC Remedy Action Request System 7.1.00: Form and Application Objects. The SRM:SR_AuditLog form is used to capture the audit records for the service request and uses the SR instance ID as a foreign key to link to the corresponding service request.

Execution of a run-time service request BMC Software, Inc.

77

White Paper

Figure 55: Audit logging
SRM:Request InstanceId Request Number Request ID SRDInstanceID

FK:Original Request Id= Request ID SRM:SR_AuditLog Original Request ID

Work information (activity log)

Work information records provide updates to a given service request after it is initiated. This information is linked to the service request by storing the SR instance ID on the corresponding SRM:WorkInfo record. This information is then passed on to the back-office fulfillment applications. The Change, Incident, and Work Order Management systems all have similar work order structures that store the service request work info updates.
Figure 56: Work information (activity log)
SRM:Request InstanceId Request Number Request ID SRDInstanceID

FK:SRInstanceID= InstanceId SRM:WorkInfo SRInstanceID

78

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Service request definition

The service request is initiated from the selected SRD, and the SRD instance ID is used as the primary foreign key on the SR to maintain the relationship to the originating SRD.
Figure 57: Service request definition
SRD:ServiceRequest Definition InstanceID

FK:SRDInstanceID= InstanceID

SRM:Request InstanceId Request Number Request ID SRDInstanceID

Process components

Process definition instances and application object instances are the run-time instances of the process definition templates and application templates that are associated with the selected SRD.

Execution of a run-time service request BMC Software, Inc.

79

White Paper

Figure 58: Process components entity relationships
FK:Assoc2InstanceID= InstanceId SRM:Associations Assoc1InstanceID Assoc2InstanceID SRM:Process FK:Assoc1InstanceID= InstanceId Service Request InstanceID

SRM:Request InstanceId Request Number Request ID SRDInstanceID

FK:Service Request InstanceID= InstanceId FK:SRInstanceID= InstanceId SRM:AppInstanceBridge SRInstanceID

When the service request is initiated, the corresponding process definition template is also initiated along with all of the related AOTs and PDTs. Figure 59 illustrates this initialization process.

80

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 59: Initiating the process definition template

SRM:Request

1. Triggers: On Submit, On Modify 'zTmpCommand' = "CREATECHILD"

SRD:ServiceRequestTemplate Builder

2. On Modify z1D_Command = “CREATE”

3. Create PDI

SRD:ProcessDefinition Template

4. Create AOIs,

SRD:Process

5. On Modify 'zTmpCommand' = "CREATEFLOW"

SRM:AppInstance Bridge

6. Create flow

SRM:AppInstance Flow

The AOI object stores information about the back-office fulfillment application interface form required to interact with it. As it is being initiated, it also acts as the primary mechanism to consolidate the user input with any default values or data from other front-office sources according to defined mapping rules for a given SRD.

Execution of a run-time service request BMC Software, Inc.

81

White Paper

Figure 60: AO functional processes
Application Object Instance (SRM:AppInstanceBridge)

1. Pulls the default from target data

2. Pulls the default from the association between AOT and TD

3. Pulls the data from the TD mapping on SRD

SRM:QUTBaseJoinApp RegJoin

SRM:TDAOTAssocTD _Join SRM:AppTargetData Associations

SRM:SourceTDData Mapping_Join SRM:MasterData MappingList SRM:SourceAppTarget Data_Join SRM:MasterData MappingList

SRM:AppTargetData

CAI:AppRegistry

SRM:AppTargetData

After initiated, the AOI not only manages communication between the SR and the corresponding back-office fulfillment application, by way of the CAI, it also maps the different state transitions of the back-office fulfillment applications to a single high-level service request status. Primary forms This section describes the two primary forms:
! SRM:Process

stores the instantiation of the process definition template and is referred to as the process definition instance record. stores the initialization of the Application Object Template and is referred to as the application object instance record.

! SRM:AppInstanceBridge

Subsystem integrations
Fulfillment applications As a result of integrating with back-office fulfillment applications a link to the initiated service request is established. The service request instance ID is passed as data to the supporting interface form of the back-office fulfillment application by way of the AOI and CAI.

82

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 61: Fulfillment entity relationships
SRM:Request InstanceId Request Number Request ID SRDInstanceID FK:SRInstanceID= InstanceId

WOI:Work Order HPD:Help Desk CHG:Infrastructure Change

Approvals

The approval engine is used to manage approvals of the initiated service requests (SRs) in the same way it does for SRDs. The approval rules for SRs are established by way of the Application Administration Console. Whether the rules of the approval engine are applied to a given SR is determined by a flag on the SRD.
SRM:Request

The following join forms were created to integrate the approval engine with the form:

! SRM:ServiceRequestApDetail ! SRM:ServiceRequestApDetailSignature ! SRM:RequestApproverLookup

All filters created to retrieve the approval process name and start the approval engine are attached to the SRM:Request form and begin with the prefix SRM:REQ:Approval_XXX. Service level management The service targets for a given service request are established during the definition stage of the SRD. During the execution stage, the SLAs are managed by the SLM:EventSchedule and the SLM:Measurement forms.

Execution of a run-time service request BMC Software, Inc.

83

White Paper

Figure 62: Service level management entity relationships
SRM:Request InstanceId Request Number Request ID SRDInstanceID

SLM:EventSchedule ApplicationInstanceID

FK:ApplicationInstanceID= InstanceId

FK:SLA_Reference InstanceID= InstanceId

SLM:Measurement SLA_Reference InstanceID

The SLM:EventSchedule form is used to track the time for executing a time-based milestone. Each record in this form has a timestamp indicating when a milestone should execute. It is related to a service request by the SR instance ID. An escalation monitors the entries in this form to make sure the milestones execute at the correct time. When the milestone executes, the entry in SLM:EventSchedule is deleted. The SLM:Measurement form tracks the measurement records and the performance of a service target for a given SR. It records the latest service target status and the latest status. Assignment When a service request is initiated, the assignment group ID is passed from the SRD. This key identifier is used as a parameter call to the Assignment Engine. Based on the applicable rules defined in the Assignment Engine for the selected SRD, the appropriate assignment process and rule are applied, and the assignment fields used to identify the SR coordinator are populated.

Supporting consoles
SRM provides three run-time consoles designed to support the business manager and the service request coordinator. Each console is designed and organized to facilitate the functions required by each role. For additional details about how these functions work, see the BMC SRM Application Administration Guide and the BMC Service Request Manager 2.0 Configuration Guide.

84

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Service Request console
The Service Request Console is the interface for a user to browse the catalog, search for a particular catalog entry, review the detailed description of a catalog entry, select and then submit a service request, and monitor the status of previously submitted requests. The console layout is designed to facilitate these functions. There are three areas of the Service Request Console that support these operations. Two of these areas provide functionality that is persistent and always available. The third area is the display area.
Figure 63: Request console

1

2

3

Area 1 in Figure 63 acts as the console header and is dedicated to displaying the user name or the person the user is submitting requests on behalf of, and to support the search text function of the console. Area 2 runs down the left side of the console. This area supports the following functions:
! ! ! ! ! !

Viewing broadcasts. Displaying the metrics of the current active service requests. Direct access to specific catalog entries. Navigation between browsing the catalog and monitoring submitted requests. Setting preferences. Providing feedback.

Area 3 of the Service Request Console is the display area, which is managed by a tabed, borderless page holder with seven tabs. Six of the seven tabs support the catalog browse, search, and service request submission process.

Execution of a run-time service request BMC Software, Inc.

85

White Paper

The following table summarizes the purpose and supporting structures of each tab view.
Table 24: Tab view purpose and supporting structures Tab 1 2 3 4 5 6 7 Function Browse Service Categories Browse Sub Categories Display Search Results List Present SRD specific questions Display details of catalog entry Display summary of SR prior to being submitted Review and manage submitted requests Primary supporting structures Data Visualization Field (1) Data Visualization Field (1) Data Visualization Field (1) Character, radio, check box, integer fields HTML View Field (1) HTML View Field (2) Table and HTML view field (3)

Data visualization field
Although there are three functions that are supported by a data visualization field (DVF), only one instance of the DVF is used. The Browse Service Categories, Browse Sub Categories, and Display Search Results List views are all presented using a single AR System DVF. The DVF display is implemented using a DVF plug-in, which uses a combination of Java code, JavaScript, and HTML to display content and communicate with the SRS:ServiceRequestConsole form (parent form). The DVF display is generated by the BMC Remedy AR System Mid Tier, which must be configured to download the DVF plugin from the AR System server. The DVF plugin and the parent form implement an interface for two-way communication. The parent form communicates with the DVF plugin using “set fields” actions to send action requests to the DVF, while the DVF plugin implements events that can be captured by the parent form. The SRM DVF plugin implements well-established architectural patterns for enterprise applications. The underlying pattern is the model-view-controller (MVC) pattern, which manifests in several ways. The plugin also implements the service layer, data-mapper layer, domain model, and repository patterns. The model part of MVC is implemented as a combination of services in the service layer and objects that model the SRM domain from the perspective of the DVF. The controller is the SRMS plug-in class and delegates requests to the event dispatchers. The view part is implemented by a set of view services in the service layer in combination with the client that renders them. The following diagram provides the high-level architecture of the DVF plugin.

86

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 64: DVF plugin architecture
Client DVF

AR System Mid-Tier Plug-in Container Controller SRMS DVF Plug-in

Service Layer Services TopCategoriesBrowserService ServiceCategoriesBrowserService ListServiceRequestsService ApplicationImageService Views TopCategoriesView ServicCategoriesView ServiceRequestListView NoDataFoundView

Data-Mapper Layer Repositories TopCategoriesRepository CategoriesRepository ServiceRequestsRepository FavoriteServiceRequestsRepository ApplicationImageRepository Resource Loaders ClasspathResourceLoader PluginDefinitionResourceLoader ClasspathTemplateLoader

AR System Application Server

Data

View fields
The Description and Summary views are presented using AR System view fields. The My Request view also contains a view field that is used to display the details of a specific request. The view fields are used to display static HTML that is stored as templates in the SRS:ServiceRequestHTML form. The HTML templates are retrieved from the SRS:ServiceRequestHTML form, using workflow, which in turn modifies the HTML template to display the user-specific data. The HTML in the view field is then rendered by the MidTier.

Execution of a run-time service request BMC Software, Inc.

87

White Paper

Business Manager Console
The Business Manager Console is intended to allow a group manager of request coordinators to oversee all request activities of that group.
Figure 65: Business Manager Console

2

1

3

4

This console is organized into four areas: navigation, search, results or details, and flashboards. The left navigation panel provides functionality that lets you:
! ! ! ! !

Set the console context by company and group. View broadcasts and service request metrics. Set preferences. Run reports. Launch other consoles.

Area 2 is dedicated to providing searching options within the established context of the specified company field and group selected. Area 3 contains the results of the context specified by the company, group, and the search criteria provided in area two. A table field is used to display the list of records and an HTML view field is used to present the details of the current selected service request. Area 4 contains a graphical representation of the results in a data visualization field defined for flashboards.

88

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Service Request Coordinator Console
The Service Request Coordinator Console is a monitoring station for the request assignees. They can use this console to search for requests that are assigned to themselves or other people in their support groups. The console is broken into three areas, the left panel, the search area at the top of the console, and the middle section of the console where the results of the search criteria are listed and additional details are provided.
Figure 66: Service Request Coordinator Console

2

1

3

Area 1, the navigation panel, lets the users specify the company to which they are assigned. There is a button that lets broadcasts be viewed. Below this are metrics that allow a quick scan of the outstanding requests for the current user. The quick links provide an easy way to change your request viewing perspective, perform specific functions, or launch other consoles. Area 2, is the search panel at the top of the console that permits searching of service requests based on either the request ID, summary, first name, and last name of the requestor. Area 3, is the results area of the console and is made up of two sections, the results list and the details related to the selected service request. These details are partitioned into three tabs. The first tab provides more descriptive information about the service request. The Work Info tab gives the user the ability to review the work info records added to the request. The Service Level tab shows the SLAs associated with the request and permits compliance monitoring at a high level.

Execution of a run-time service request BMC Software, Inc.

89

White Paper

Interfaces
There are two interface forms for service requests that support basic create, modify, and query operations:
!

SRM:RequestInterface_Create interfaces with the primary service request

form, SRM:Service Request. This interface form is the integration point for external systems to create new service requests.

!

SRM:RequestInterface belongs to the primary Change Management form, SR. This self-join, interface form is the integration point for external systems to query or modify service requests.

These interface forms contain all necessary fields from the base service request form, SRM:Service Request, that are required to support the reception of input from an external source. The command field, z1D_Action, is used where necessary to invoke the action that is requested by the external system (submit, modify, and create). These operations can be invoked by accessing these interface forms directly. Access to these forms has also been expanded to support interactions using web services. There are four basic operations that can be run through web services. These operations are supported by the underlying interface forms. They include a basic query and query lists, modify, and submit operations.
Table 25: SRM:Request web services and interface forms Form
SRM:Request

Interface form
SRM:Request Interface

Web service SRM_Request Interface_WS SRM_Request Interface_ Create_WS

Web service operation Request_Modify_Service Request_Query_Service Request_QueryList_Service Request_Submit_Service

SRM:Request Interface_Create

The basic query, query list, and modify operations leverage the SRM:ServiceRequest_Interface interface form, which is a self-join of the main SRM:ServiceRequest form. The basic query web service call requires a request ID as input. The matching entry is returned as the output. The Query List web service requires a qualification (for example, Status = New) and returns a list of matching entries as the output. The Modify web service requires the item instance ID as input as well as all other information that is to be modified. The matching record is modified with the values supplied on the input. The SRM:ServiceRequestInterface_Create form is based on the main application form and contains the necessary fields to support the Submit function. To use the Submit web service operation, you must set the z1D_Action field to “create.” You must set other required fields to create an entry in the main system form. The request ID of the created item is returned to the submit service.

90

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Back-office fulfillment system integrations
The Incident Management, Change Management, and Work Order applications all include a set of AR System forms that provide the ability to create, query, and modify requests in these back-office fulfillment applications. They also include web service interfaces that are built on top of these forms to provide external systems with a mechanism to programmatically interact with these back-office systems. BMC SRM is integrated with the Incident Management, Change Management, and Work Order systems by way of the CAI and these interface forms. The interface forms for the CAI not only support communication from BMC SRM to the back-office fulfillment applications but also from the back-office fulfillment applications to BMC SRM. The following table summarizes the interface structures used for the CAI.
Table 26: CAI interface structures Form
CAI:Events

Interface form

Web service

Web service operation Events_Modify_ Service Events_Query_ Service Events_QueryList _Service

CAI:EventsInterface CAI: EventsInterface_ WS

CAI:Events Interface_Create CAI:Event Params CAI: EventParams Interface

CAI: EventsInterface_ Create_WS CAI: EventParams Interface_WS

Events_Submit_ Service EventParams_ Modify_Service EventParams_ Query_Service EventParams_ QueryList_ Service

CAI: EventParams Interface_Create

CAI: EventParams Interface_Create_ WS

EventParams_ Submit_Service

Figure 67 illustrates the general flow for interfacing with the BMC SRM system as well as the flow used by BMC SRM to interface with the back-office fulfillment systems.

Back-office fulfillment system integrations BMC Software, Inc.

91

White Paper

Figure 67: Integration flow to interface BMC SRM with back-office fulfillment systems
General Flow

SRM
External Application

Creates Interface record using webservice

Interface Form Processes incoming parameters

Main System Form

Data flow direction

Back-office templates
All supported out-of-the-box back-office fulfillment applications (Change Management 7.0, Incident Management 7.0, and the Work Order application that is shipped with BMC SRM) support the use of templates. Templates are used by these applications to provide default values for key fields in the absence of more current data. BMC SRM has the ability to specify which template is to be used when creating a fulfillment request. In the event of an overlap of the fields to be populated by the selected template and the data supplied by BMC SRM, the BMC SRM fields take precedence. BMC SRM data supersedes the values provided by the template. Figure 68 illustrates how field 1 would be populated if there were an overlap between the template default value (See You) and the BMC SRM mapped data value (Hello).

92

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Figure 68: Populating field 1 where an overlap exists
Title Approval Approval Service Request New Emp. Description SLA

Interface
Command Automation Interface Field 1: Hello Field 2: World Field 3: Field A: Field B: TempId: 123

Incident Form
Field 1: Hello Field 2: World Field 3: Later Field 4: Field 5: TempId: 123

Process Definition
Incident AOI
[New Employee]

Incident Template Field 1: Field 1: Field 2: 1: See You Field Field 2: Field 3: 2: Field Field 3: Field 4: 3: Later Field Field 4: Field X: 4: Field Field X: TempId: X: Field TempId: TempId: 123

Incident Template Incident Template

A

Incident Management integration
Two interface forms for Change Management support basic create, modify, and query operations:
! HPD:HelpDeskInterface_Create

interfaces with the primary incident form, This interface form is the integration point for external systems to create new incident tickets.
HPD:Help Desk.

! HPD:HelpDeskInterface

belongs to the primary incident form, HPD:Help Desk. This self-join, interface form is the integration point for external systems to query or modify incident tickets.

These interface forms contain the necessary fields from the base incident form, HPD:Help Desk, required to support receiving input from an external source. The Command field, z1D_Action, is used where necessary to invoke the action that is requested by the external system (submit, modify, and create). These operations can be invoked by accessing these interface forms directly. Access to these forms also support interactions using web services. Figure 69 shows how an external application integrates with Incident Management.

Back-office fulfillment system integrations BMC Software, Inc.

93

White Paper

Figure 69: Integrating an external application with Incident Management
Help desk ticket submit

ITSM
External application Creates an association with a CI if a CI name is specified Association forms

Creates staging record using Help Desk Submit web service

HPD:IncidentInterface (Staging form) Processes incoming parameters

HPD:Help Desk Creates Help Desk record and Work Log record HPD:Work Log

Data flow direction

Interfaces
The following table describes the Incident Management integration interfaces.
Table 27: Incident Management integration interfaces Form
HPD:HelpDesk

Interface form
HPD: Incident Interface HPD: Incident Interface_ Create

Web service HPD_Incident Interface_ WS HPD_Incident Interface_ Create_WS

Web service operation HelpDesk_Modify_Service HelpDesk_Query_Service HelpDesk_QueryList_Service HelpDesk_Submit_Service

Change Management integration
Two interface forms for Change Management support basic create, modify, and query operations:
! CHG:ChangeInterface_Create

interfaces with the primary change form, This interface form is the integration point for external systems to create new change requests.
CHG:InfrastructureChange. CHG:InfrastructureChange. This self-join, interface form is the integration point

! CHG:ChangeInterface

T belongs to the primary Change Management form,

for external systems to query or modify change requests.

These interface forms contain the necessary fields from the base change request form, CHG:IinfrastructureChange, that are required to support the receipt of input from an external source. The Command field, z1D_Action, is used to invoke an action that is requested by the external system (for example, submit, modify, and create). These operations can be invoked by accessing these interface forms directly. Access to these forms also supports interactions using web services.

94

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Interfaces
The following table describes the Change Management integration interfaces.
Form Interface form Web service
CHG: ChangeInterface _WS

Web service operation Change_Modify_ Service Change_Query_ Service Change_QueryList_ Service

CHG: CHG: InfrastructureChange Change Interface

CHG: ChangeInterface _ Create

CHG: ChangeInterface _ Create_WS

Change_Submit_ Service

Work Order Management integration
Two interface forms for Work Order Management support basic create, modify, and query operations:
! WOI:WorkOrderInterface_Create

interfaces with the primary Work Order Management form, WOI:WorkOrder. This interface form is the integration point for external systems to create new work order requests.

! WOI:WorkOrderInterface

belongs to the primary Work Order Management form, WOI:WorkOrder. This self-join, interface form is the integration point for external systems to query or modify work order requests.

These interface forms contain the necessary fields from the base work order form, WOI:WorkOrder, that are needed for the receipt of input from an external source. The command field, z1D_Action, is used where necessary to invoke the action that is requested by the external system (for example, submit, modify, and create). These operations can be invoked by accessing these interface forms directly. The following diagram illustrates how these forms act as the interface between the service request, the CAI, and the Work Order Management system.

Back-office fulfillment system integrations BMC Software, Inc.

95

White Paper

Figure 70: How forms interface between service request, CAI, and Work Order system

Service Request [Integration ] The CAI Interface creates an “AppInstanceBridge” record where the workflow is kicked off. From here the “AppInstanceBridge” pushes data to the “WOI:WorkOrderInterfaceCreate” form

CAI Interface System

Create

Query Modify Query List

WOI:WorkOrderInterface_Create (Work Order Form)

WOI:WorkOrderInterface (Work Order Form)

WOI:WorkOrder (Work Order Primary Form)

When a Work Order is created and there is an associated Template, the data from the Template is pulled into the Work Order record

WOI:Template (Work Order Form)

Service Request Management permission model
There are two fundamental types of users supported by the BMC SRM: registered users and unknown users. Unknown users are defined as any user who attempts to access the BMC SRM system without having an entry in the CTM:People form and an entry in the AR System User form. Unknown users are supported in only single-tenancy mode and if the AR Guest User option is enabled. If unknown users are configured to have access to the BMC SRM system, they have access to the global public catalog entries. Registered users have entries in both the CTM:People and AR System User forms. Only registered users can function in the roles supported by the BMC SRM system.

96

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Table 28: SRM request management permission model Types of BMC SR users
Unknown user

BMC SRM roles

BMC SRMcatalog manager

Consoles Request Entry Console Business Manager Console SR Coordinator Console Catalog Manager Console App. Admin Console Functions Create or Modify SR for Self Reopen Requests Close Requests View broadcasts Surveys Add more information Cancel Requests Approve Requests Cancel Others Requests Define Entitlement Rules Reports Yes Yes Yes Yes Yes Yes Yes No No No No Yes Yes Yes Yes Yes Yes Yes No No No No No No No No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes No No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes No No No Yes Yes Yes Yes Yes Yes Yes Yes No No Yes No No No No Yes Yes Yes Yes Yes Yes Yes Yes No No Yes Yes No Yes No
1

Yes No No No No

Yes No No No No

Yes No Yes No No

Yes Yes No No No

Yes No No No Yes
2

Yes No No Yes No

Create or Modify SR for Others No

BMC SRM Admin. and Config. No Access Create or Modify SRDs No System Level Trouble Shooting No
1 2

Create or modify entitlement rules through the Entitlement tab on the SRD form. Access to Entitlement configuration only.

Service Request Management permission model BMC Software, Inc.

BMC SRM administrator

Entitlement manager

Registered User

Business manager

SR user

Yes No No No Yes Yes Yes Yes Yes Yes Yes Yes Yes No No Yes No Yes No Yes

97

White Paper

Licensing model
The licensing model for the BMC SRM solution is structured in two parts. There is the base application license that entitles a fixed number of users to access the BMC SRM solution and includes a fixed number of AR System licenses. The second part of the license model supports incremental licenses beyond those included with the base license. To determine the allocation of users supported by the base and incremental licenses, see the current licensing agreement.

98

BMC Service Request Management 2.0 Architecture BMC Software, Inc.

BMC Service Request Management 2.0 Architecture

Terminology
The following is a list of terms and acronyms that are commonly used in this white paper.
Table 29: Common terms and acronyms Term Application object instance Application object template Back-office fulfillment application Acronym AOI AOT BOFA Description Instantiation of an AOT during its execution phase. Interface to a back-end application that is needed to fulfill a service request. Any application used by a service organization that is used to fulfill a service request. Subsystem designed to support bi-directional communication between applications and other systems. Defines who has access to deployed SRD’s in the catalog. Instantiation of a PDT during its execution phase. Defines the process that supports the related Service Request Definition. The primary components required to define a catalog entry. A user request for information, advice, or services that can be fulfilled by back-office operational organizations and systems, such as Change Management, Incident Management, or Workorders. The definition of a service that is available for users to request through the service catalog. Definition of what SRD’s are accessible.

Command automation CAI interface People entitlement definition Process definition instance Process definition template Request, process, data mapping Service request PED PDI PDT RPD SR

Service request definition Service request definition entitlement definition Service request management Target data

SRD SRDED

SRM TD

The process of managing information technology services to meet the customer’s requirements. Data that is mapped to fields on a registered interface form.

Licensing model BMC Software, Inc.

99

White Paper

100

Terminology BMC Software, Inc.

*86808* *86808* *86808* *86808*
*86808*