White Paper BMC Service Request Management 2 0 Architecture

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 Telephone 713 918 8800 or Fax 713 918 8000
2101 CITYWEST BLVD 800 841 2031
HOUSTON TX 77042-2827
USA
Outside United States and Canada
Telephone (01) 713 918 8800 Fax (01) 713 918 8000
If you have comments or suggestions about this documentation, contact Information Design and Development by email at
doc_feedback@bmc.com.
© Copyright 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 1
BMC Software, Inc.
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 3

BMC Software, Inc.
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
Service
Self Service Providers
Interface
End Users
Back Office
Service Fulfillment
Service Request
Management
• Change Management
• Incident Management
• Work Orders
• Custom Fulfillment

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)
Service
Interface
End Users
Back Office
Service Fulfillment
Execution
Service Request
Service of SR
Management
Request Process • Change Management

• Work Orders
SR Process • Custom Fulfillment
Definition
Service
Catalog
Service Level
Approvals Notifications
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.

BMC Software, Inc.
Service providers benefit by receiving coordinated requests that support the end-to-
end 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)
Service
Interface Request
Coordinator
End Users
Back Office
Service Fulfillment
Execution
Service Request
Service of SR
Management
Request Process • Change Management

• Work Orders
SR Process • Custom Fulfillment
Definition
Service
Catalog
Service Level
Approvals Notifications
Management
Business Service
Relationship Catalog
Manager Manager
Bridging the front office and the back office 7

BMC Software, Inc.
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 Responsibility
Business The business relationship manager works closely
relationship with both the business and the IT department to
manager 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).
Service catalog The service catalog manager is responsible for
manager 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).
Service request The service request coordinator (Service Request
coordinator 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.
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

BMC Software, Inc.
! 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 9

BMC Software, Inc.
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 Description Entitlement Turnaround
time
New Employee hire This service request is intended HR Managers 3 Days
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 Task Fulfillment organization Supporting

application
1 Background check and Security Work Order
issue badge
2 Set up office Facilities Work Order
3 Enable ports IT Incident
Management
Install new desktop IT Change
Management
Table 4: Data mapping
Data mapping Fulfillment organization application fields

HR Input Security - WO Facilities - WO IT - IM IT - CM
Employee Name Requested for Requested for requested for requested
for
Start Date Special type field Special type field custom field required
start date
Office and Building special type field Special type field custom field notes
Floor Plan N/A Special type field N/A N/A

BMC Software, Inc.
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 11

BMC Software, Inc.
White Paper
Figure 6: Definition versus execution
Automated
Tools
Service Request Service

Service Request Management System
Definition Request
• Title • End User Console
• Description • Activity Log
• Nav. Categories • SLA’s
• Entitlement • Surveys
• Approvals • Approvals
Process Instantiation
Definition of Process Def.
AOT
AOT AOT 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.

BMC Software, Inc.
Request definition
The Service request definition (SRD) is a primary
Title component to complete a catalog entry. The SRD captures
and defines how the business or user interacts with the
Approval
Service
given catalog entry. The Request Definition table (see
SLA
Request
Def. 1 Table 2 on page 10) in the New Employee Hire scenario
captures the type of information that would be part of the
Description 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
Process Definition work gets done by specifying who does what and when.
A process definition template (PDT) provides a model for
Work Order
[Sec. Badge]
the values of who, what, and when. The PDT acts as a
container object that is composed of the step or steps
needed to fulfill the related request. Each step is tied to a
Work Order Incident specific back-office fulfillment application where an
[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
Request
templates (AOTs). If multiple steps and AOTs are
[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.
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 13
BMC Software, Inc.
White Paper
Data mapping definition

Although the order in which you complete the request
Data Mapping 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.
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.

BMC Software, Inc.
Figure 7: The RPD model
Title
Approval
Service
SLA
Request
Def. 1
Data Mapping
Description
Office
Location?
Process Definition
Work Order
[Sec. Badge]
Work Order Incident

[Setup Office] [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.
BMC Software, Inc.
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 Construction Execution
1 Event
What Data Values 3 Command
HowContent 5 RuntimeJust
Command
Do It
2 4
App Registry
ID Name Protocol
Commands
Command Direction Op. Type
Parameters
Done
Param Data Type 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.

BMC Software, Inc.
Table 5: CAI components—Definition or reference
CAI component Form name Description

Application registry CAI:AppRegistry Stores application interface
information, such as interface
form names, connection data,
and the protocol.
Commands CAI:Command Command names for each
integrating component.
Command parameters CAI:CommandParam Stores the command
parameters for the command
of each integrating
component.
Command parameter CAI:CommandParamMapping Defines the mapping between
mapping the command parameters and
the backend application.
Table 6: CAI components—run-time
CAI component Form name Description

Events CAI:Event Stores the run-time instance of
a command event for each
integrating component.
Event parameters CAI:EventParam Stores the event parameters for
each integrating component.
Figure 9 illustrates how these components relate to each other in support of the
CAI design.
BMC Software, Inc.
White Paper
Figure 9: How components relate in support of the CAI design
Definition 2. Map command parameters for each

1. Register application registered application
CAI:AppRegistry CAI:CommandParamMapping
U1 InstanceID AppRegistryName
U2 AppRegistryName Command
ApplicationName CommandParam
ApplicationInstanceID AppInterfaceFormName
Protocol AppFieldName
Connection Info AppFieldID
Interface Form Names ParamType
ParamDataType
0. Create commands and
command parameters
CAI:Command CAI:CommandParam
U1 Command U1 Command
Direction U1 CommandParam
OperationType Type
SelectionType DataType
Mode
CAI:Event Construction
CAI:EventParam
EventGUID
Event
Source EventGUID
Target ParmName
SourceAppRegistryInstanceID ParamValue
AOIGUID ParamAttachmentValue
AppInterfaceFormName ParamType
TargetConnectionInfo ParamDataType
RtnCode
RtnMsgCode Push event and run-time data to
RtnMsg event params (outbound)
MaxRetries
RetryCounter
SRMS/TMS
Calls GetEntry to
Execution (outbound) get event values
FilterAPI Plugin AR Workflow
Push event and event Launch

params
App Interface Form 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.

BMC Software, Inc.
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
Request For
Pending
Approval Rejected
Approved
SR= Cancelled
Deployed Effective End Date
reached
SR = Cancelled Expired
Closed
Note: SR means Status Reason
BMC Software, Inc.
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 In SRD Description

reason effective online status
date
range
Draft N/A N/A Initial state; SRD is
being authored.
Request for N/A N/A Waiting for approval.
Approval
Pending More N/A Need more
Information information from the
SRD submitter. Once
information is
provided, the SRD
can be resubmitted
for approval by
changing the status to
Request for
Approval.
Rejected N/A N/A SRD was rejected.
Deployed N/A No SRD Approved; Has

not reached effective
start date.
Expired N/A No Future effective start
date not set.
Closed Cancelled N/A End state; no longer
available to Users.
Deployed N/A Yes Available to users.
Deployed N/A No end Available to users.

date
Deployed N/A Yes SRD has been
manually taken
offline.
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.

BMC Software, Inc.
Figure 11: Service request definition primary components
Application Configurations
Service
Request
Foundation
Elements
Work Info
Audit Logs
Service
Request Data
Mapping
Entitlement
Definition
PDT’s
Surveys
Service Level Management
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 The SRD form is the primary form used as the interface for capturing and
Request searching for the characteristics that make up the business definition of a Catalog
Definition join Entry.
form 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 The Service Request Definition Base form contains the core SRD information that
Request is not influenced by localization. Table 8 contains a full description of the form.
Definition_
Base form
BMC Software, Inc.
White Paper
Table 8: SRD:ServiceRequestDefinition_Base form
Join data label Source data Field name Field ID Type

Account Number SRD_Account Number 302793700 Character
Attachment SRDAttachmentField 302906200 Attachment
Business Service SRD_BusinessService 302793400 Character
Company SRD_LocationCompany 301453000 Character
Company Survey Enabled SurveyEnabled 302844800 Character
Coordinator Group ServiceRequest 10002506 Character
CoordinatorGroup
Create Business Process CreateBusinessProcess 302858800 Selection
Custom Template Custom_Template 302825800 Character
Customer First Name RequestedByFirstName 1000000019 Character
Customer Last Name RequestedByLastName 1000000018 Character
Effective End Date EffectiveEndDate 240000014 Date
Effective Start Date EffectiveStartDate 240000013 Date
Expected Cost SRD_Expected Cost 302783800 Currency
Hot List HotList 302897800 Selection
Process Template PDT_Name 302876900 Character
RC Manager Company RequestCatalogManager_ 301251902 Character
Company
RC Manager Name RequestCatalogManager_ 301251901 Character
FullName
Request Frequency Request Frequency 302771600 Integer
Request Type SRD_Request Type 301438012 Selection
SR Needs Approval UseApprovalEngFlag_SRD 302896600 Selection
Status SRD_Status 7 Selection
Status Reason Status_Reason 1000000150 Selection
Survey Configuration SurveySelection 302839500 Selection
Survey Name SurveyName 302903400 Character
Survey Status SurveyStatus 302903500 Selection
System Request SystemRequest 302785000 Selection
Turnaround Time SRD_TurnaroundTimeX 302793500 Integer
SRD:Service The SRD Display Property form contains the localized strings for the following
Request fields that follow on the SRD.
Definition_ Table 9: SRD:ServiceRequestDefinition_DispProp form
DispProp
form
Category 1 Category1 1000000063 Character
Description SRD_Description 301244800 Character

BMC Software, Inc.
Table 9: SRD:ServiceRequestDefinition_DispProp form (Continued)

Instructions SRD_Instructions 302823600 Character
Keywords SRD_Aliases 302771500 Character
Level SRD_Level 302793100 Character
Locale SRD_Locale 160 Character
Price SRD_Price 302793000 Currency
SR Instance ID SRD_InstanceID 302162700 Character
Title SRD_Title 301244700 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 Create an entry to get

SRS:CFGCustomForm SRM:Navigational SRD:CFG catalog manager new SRD Number
SYS:Menu Items
Category Settings
instanceId NTE:SYS-NT SRD:CFG
Navigational Category Process Control DefinitionNumGenerator
SRD_Level Get setting for approval
1, 2, 3
FK:instanceId=
Custom_CFG_Form_InstanceId
SRD:ServiceRequestDefinition
Catalog Manager
CTM:People
Customer
SRM:Request InstanceID
FK:SRDInstanceID=
InstanceID Request ID (Field 1 for join form)
SRDInstanceID SRD_Number (auto-generated)
SRD_Request_ID (Request ID from base) Catalog Manager Company
Navigational Category 1 Location Company COM:Company
SRD:WorkInfo Navigational Category 2 Customer Company
FK: SRD Number=SRD_Number, Navigational Category 3
SRD Entry ID SRD Entry ID=SRD_Request_ID SRD_Level
SRD Number Custom_CFG_Form_InstanceId Assignee Group CTM:Support
PDT_InstanceID
(Request Coordinator Group) Group
PDT_Name
SurveyAssocInstanceID
SRD:AuditLog FK:Original Request ID=
Request ID SRM:UniqueQuestionList
Original Request ID FK:InstanceID=
Entitlement ParentInstanceID
Criteria – SRD_Number, ParentInstanceID
Nav Cat 1,2,3, Join: InstanceID=SRD_InstanceID
SRD:SRDEntitlement
Definition Level
SRD:ServiceRequestDefinition SRD:ServiceRequestDefinition
SRDED instanceId2 _base _DispProp SRM:SourceToTargetData
FK:InstanceID= Associations
FK:InstanceId= InstanceID SRD_Status ParentInstanceID
SRDED instanceId2 BusinessServiceInstanceId SRD_Title ParentInstanceID
SRD_BusinessService SRD_Description
BusinessProcess_ InstanceId SRD_Locale
SRD:SRDED PED
BusinessProcess_ ReconId SRD_InstanceID
Associations
Sandbox_DatasetID SRD_Aliases
Custom_CFG_Form_InstanceId TakeSRDOfflineFlag SRM:Associations
SRDED instanceId2 FK:InstanceID=
SRD_Level
Assoc1InstanceID
SRD_Instructions Assoc1InstanceID
deleted Assoc2InstanceID
FK:SRDInstanceID= SRD_Price
SRM:SurveyAssociations Navigation Tier1
SurveyAssocInstanceID FK:Assoc2InstanceID=InstanceId
Navigation Tier2
SurveyInstanceID Navigation Tier3
SRM:ProcessDefinition
SRDInstanceID Template
InstanceId
FK:SurveyInstanceID=InstanceId FK:InstanceID=instanceId2 PDT_Name
FK:instanceId1=InstanceId
SRM:ConfigSurveyQuestions SLM:Association FK:PDT_InstanceID=InstanceId

SLM:ServiceTarget PDT_Name=PDT_Name
associationTypeId'="SVT_SRD_RELATE"
InstanceId
instanceId1 InstanceId
instanceId2
BMC Software, Inc.
White Paper
Navigational The navigational categories are used to organize entries in the catalog and to
categories 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
InstanceID
Request ID (Field 1 for join form)
SRD_Number (auto-generated)
SRD_Request_ID (Request ID from base)
Navigational Category 1
SRD_Level
PDT_InstanceID
PDT_Name
Join: InstanceID=SRD_InstanceID
_base _DispProp
InstanceID SRD_Status
BusinessServiceInstanceId SRD_Title
Custom_CFG_Form_InstanceId 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.

BMC Software, Inc.
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.
BMC Software, Inc.
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.

BMC Software, Inc.
Figure 15: Entitlement, conceptual view
InstanceID
SRD_Level
PDT_InstanceID
PDT_Name
Entitlement
Criteria – SRD_Number,
Nav Cat 1,2,3, Join: InstanceID=SRD_InstanceID
SRD:SRDEntitlement
Definition Level
SRDED instanceId2 _base _DispProp
FK:InstanceId=
SRDED instanceId2
SRD:SRDED PED
Associations
SRDED instanceId2
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.
BMC Software, Inc.
White Paper
Figure 16: Entitlement definition
Entitlement Definition
Service Request Definition People
Entitlement Definition Entitlement Definition
(SRDED) (PED)
SR CTM:People AR
Definition Individual, Location 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 S: SRD:SRDED PED Associations

Category Tag1 PED instanceId1/SRDED instanceId2
Category Tag2
Request ID
Category Tag3
Entitlement Definition ID SRDED instanceId2
EntitlementQualification Status
InstanceId
SRD_Number
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.

BMC Software, Inc.
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 S: ENT:SYS-Access Permission Grps

InstanceId Company
InstanceId
People Permission Group ID
Navigation Menu01
Permission Group ID Navigation Menu04
Person ID/Permission Group ID Permission Group
Remedy Login ID 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.
The join criteria for this form are:
! PED Instance ID from SRD:SRDEDAssociation_join.
! Instance ID on ENT:PeopleEntitlementDefinition (PED).
! SRD:SRDEDAssociation_join joins the SD:SRDEntitlementDefinition and
SRD:SRDED PED Associations forms. It is an intermediate join to support the three
way join required to produce the SRD:EntitlementDefinition_join form.
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.
BMC Software, Inc.
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.
! ENT:PeopleEntitlementDefinition This regular form stores the PED part of
the Entitlement Rule. The PED Rule can contain any field from the CTM:People
form.
Work The work information form is used as an activity log. The catalog manager or
information 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
InstanceID
SRD:WorkInfo Navigational Category 2
FK: SRD Number=SRD_Number, Navigational Category 3
SRD Entry ID SRD Entry ID=SRD_Request_ID SRD_Level
SRD Number Custom_CFG_Form_InstanceId
PDT_InstanceID
PDT_Name
_base _DispProp
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 Field ID Type Length
Attachment Pool 400005900 Attachment Pool n/a
Description 1000000000 Character 100
Detailed Description 1000000151 Character 0
Number of Attachments 1000000365 Integer n/a
Number of URLs 1000002264 Integer n/a

BMC Software, Inc.
Table 10: SRD:WorkInfo data fields (Continued)

Request Number 1000000829 Character 15
SRD Number 1000000182 Character 45
Status 7 Selection n/a
Total Time Spent 1000000731 Integer n/a
URL01 1000002261 Character 255
Work Log Date 1000002134 Date and Time n/a
Work Log ID 1 Character 15
Work Log Submit Date 1000000157 Date and Time n/a
Work Log Submitter 1000000159 Character 254
Work Log Type 1000000170 Selection n/a
Work Order Number 1000000967 Character 15
WorkLog Action 1000002401 Selection n/a
Completed
WorkLog Action Status 1000002369 Selection 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.
BMC Software, Inc.
White Paper
Figure 20: Survey entity relationships
InstanceID
SRD_Level
PDT_InstanceID
PDT_Name
_base _DispProp
SRD_Level
SRD_Instructions
deleted
FK:SRDInstanceID= SRD_Price
SRM:SurveyAssociations Navigation Tier1
Navigation Tier2
SurveyInstanceID Navigation Tier3
SRDInstanceID
FK:SurveyInstanceID=InstanceId
SRM:ConfigSurveyQuestions
InstanceId

BMC Software, Inc.
The following tables describe the the data fields on theses survey forms:
! SRM:SurveyAssociations is an association table that supports the many-to-
many 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

InstanceID 179 Character 38
RequestID 1 Character 15
SRDInstanceID 302814500 Character 38
SurveyInstanceID 302841800 Character 38
Table 12: SRM:ConfigSurveyQuestions form

Company 1000000001 Character 254
Question Type 300794000 Character 30
Question1 260000000 Character 255
SRD_ID 302797800 Character 20
Survey Name1 302838900 Character 255
SurveyLocale 302839000 Character 255
SurveyType 302841700 Character 25
Topic 300563100 Character 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.
BMC Software, Inc.
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 Mapped
Fields Fields
Table 13: Custom form parts
Custom form part Description

Connection fields and The connection fields and workflow are the “plumbing” that
workflow supports the seamless connection with the BMC SRM Provide
Information stage of the request submission process.
Mapped fields 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.
Custom fields and On a custom form, custom fields are all the other new fields
workflow 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.

BMC Software, Inc.
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=
InstanceID
SRD_Level
PDT_InstanceID
PDT_Name
_base _DispProp
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.
! SRM:CustomformDisplayOnly is one of the sample custom forms that are
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.
BMC Software, Inc.
White Paper
Table 14: SRS:CFGCustomForm form
Data Field Name Field ID Type Description

Location Company 1000000001 Character Tenant company
Template Name 302826000 Character Name displayed in
selection menu from
SRD
Form Name 302826200 Character Name of the custom
form
Server 301286600 Character Server where the
custom form resides
Status 7 Selection Indication of if this
registry record is
active or inactive
Locale 160 Character Locale of registry
entry
Table 15: SRM:CustomformDisplayOnly

Data field name Field ID Type Description
Custom Fields
System for password reset 302983800 Character Name of System.
Type your new password 302984000 Character Enter New Password for
System
Re-type your new password 302984100 Character Compare value to originally
type password
ConcatenateFields 302984400 Character Field used to combine data
Available data fields mapped to service request Mapped to SR field
CategoryTier1 1000000063 Character CategoryTier1
DateRequired 301429600 Date and Date Required
Time
Request Type 301438012 Selection Request Type
SCODescription 301417500 Character SCO Description
SR_NotesComments 301528400 Character SR_NotesComments
SRWiz_RequesterMiddleName 301563800 Character SRWiz_RequesterMiddle
Name
SRWizRequestedForCompany 301454800 Character SRWizRequestedFor
Company
SRWizRequestedForEmail 301455200 Character SRWizRequestedForEmail
SRWizRequestedForFirstName 301455000 Character SRWizRequestedForFirst
Name
SRWizRequestedForLastName 301454900 Character SRWizRequestedForLast
Name

BMC Software, Inc.
Table 15: SRM:CustomformDisplayOnly (Continued)

SRWizRequestedForPhone 301455100 Character SRWizRequestedForPhone
SRWizRequesterCompany 301442500 Character SRWizRequesterCompany
SRWizRequesterEmail 301425700 Character SRWizRequesterEmail
SRWizRequesterFirstName 301425500 Character SRWizRequesterFirstName
SRWizRequesterLastName 301425300 Character SRWizRequesterLastName
SRWizRequesterPhone 301425600 Character SRWizRequesterPhone
SR Type Field 1 300070001 Character SR Type Field 1
SR Type Field 6 300070006 Date and SR Type Field 6
Time
SR Type Field 7 300070007 Date and SR Type Field 7
Time
SR Type Field 8 300070008 Integer SR Type Field 8
SR Type Field 9 300070009 Integer SR Type Field 9
Supporting connection fields
Control Buttons
btn_Submit 300978700 Control Submit Request
Close_btn 350100012 Control Close Custom form Dialog
z3Btn_SaveAsDraftSRD 302897100 Control Execute Save As Draft
settings
System fields
Current user ID for the 302983900 Character Supported By Workflow
system
Custom_CFG_form_InstanceID 302825900 Character Supported By Workflow
CustomformName 3000010 Character Supported By Workflow
CustomformServer 3000020 Character Supported By Workflow
Expected Date 302791600 Date and Supported By Workflow
Time
Expected DateTime 302811200 Date and Supported By Workflow
Time
InstanceID 179 Character Supported By Workflow
LoggedInUserName 301354000 Character Supported By Workflow
Request Number 1000000829 Character Supported By Workflow
ServiceCatalogInstanceID 301303200 Character Supported By Workflow
SR_TurnaroundTimeUnits 302793600 Selection Supported By Workflow
SRD_TurnaroundTimeX 302793500 Integer Supported By Workflow
SRDTitle 301417400 Character Supported By Workflow
BMC Software, Inc.
White Paper
Table 15: SRM:CustomformDisplayOnly (Continued)

SRInstanceID 301368700 Character Supported By Workflow
SRStatus 302933200 Selection Supported By Workflow
TitleFromSRD 302829600 Character Supported By Workflow
z1D HolidayTag 250000054 Character Supported By Workflow
z1D WorkdayTag 250000051 Character Supported By Workflow
z1D_Action 301311700 Character Supported By Workflow
z1D_Char01 301325300 Character Supported By Workflow
z1D_CommunicationSource 10001854 Character Supported By Workflow
z1D_FullName 301308600 Character Supported By Workflow
z1D_Integer 302767400 Integer Supported By Workflow
z1D_OperationID 301443200 Character Supported By Workflow
z1D_ParentObjectKeyword 300363000 Character Supported By Workflow
z1D_RequestedForInstanceID 301465800 Character Supported By Workflow
z1D_RequesterInstanceID 301443100 Character Supported By Workflow
z1D_TmpInteger1 301638000 Integer Supported By Workflow
z1D_WorkInfoDate 10001846 Date and Supported By Workflow
Time
z1D_WorkInfoDetails 10001826 Character Supported By Workflow
z1D_WorkInfoSecureLog 10001828 Selection Supported By Workflow
z1D_WorkInfoSummary 10001825 Character Supported By Workflow
z1D_WorkInfoType 10001824 Character Supported By Workflow
z1D_WorkInfoViewAccess 10001829 Selection Supported By Workflow
z2AF_WorkInfoAttachment 301712900 Attachmen Supported By Workflow
t
z2AP_WorkInfoAttachment 10001827 Attachmen Supported By Workflow
t Pool
z2PH_DebugHolder 300037600 Page Supported By Workflow
Holder
zTmpHeader 301168000 Character Supported By Workflow

BMC Software, Inc.
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
InstanceID
SRD_Level
PDT_InstanceID
PDT_Name
SRD:AuditLog FK:Original Request ID=
Request ID
Original Request ID
_base _DispProp
SRD_Level
SRD_Instructions
deleted
SRD_Price
Navigation Tier1
Navigation Tier2
Navigation Tier3
Configurable Notifications are generally managed by the Foundation Notification Engine

notifications 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.
BMC Software, Inc.
White Paper
Figure 24: Configurable notifications entity relationships
Create entry to notify

catalog manager
NTE:SYS-NT
Process Control
InstanceID
SRD_Level
PDT_InstanceID
PDT_Name
_base _DispProp
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.

BMC Software, Inc.
Figure 25: Approvals entity relationships
SRD:CFG
Settings
Get setting for approval
InstanceID
SRD_Level
PDT_InstanceID
PDT_Name
_base _DispProp
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.
BMC Software, Inc.
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
1. Set Status = Rquest for

Approval
Service Request Definition
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
Approvers 3. Approval engine creates

APR:SYS-Approval entries in AP:Detail and
Definition
AP:Signature forms
AP:Signature
APR:Approver Lookup
(Approval Mappings)

BMC Software, Inc.
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
1. SRD is Approved or
Rejected
Approval Central
2. Approval engine checks

rules to see what needs to
be done for Approved or
Approval Engine Rejected items
AP:Process Definition
3. Approval Engine updates
Service Request Definition
SRD with data based on
Set Fields actions defined
in AP:Rules
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 The BMC Service Level Management application is used to manage all service
management 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.
BMC Software, Inc.
White Paper
Figure 28: Service level management entity relationships
InstanceID
SRD_Level
PDT_InstanceID
PDT_Name
_base _DispProp
SRD_Level
SRD_Instructions
deleted
SRD_Price
Navigation Tier1
Navigation Tier2
Navigation Tier3
FK:InstanceID=instanceId2
FK:instanceId1=InstanceId
SLM:Association
SLM:ServiceTarget
associationTypeId'="SVT_SRD_RELATE"
instanceId1 InstanceId
instanceId2
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

BMC Software, Inc.
! 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 The service catalog manager, when creating SRDs, can search and associate a
CMDB 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
Destination.InstanceId=InstanceId
InstanceId
Name
DatasetId BMC.CORE:BMC_Dependency
SRD:ServiceRequestDefinition FK:BusinessServiceInstanceId
ReconciliationIdentity
Destination.ClassId' = "BMC_BUSINESSSERVICE"
InstanceID Destination.InstanceId'
SRD_Title Name = "DEPENDENCY"
BusinessServiceInstanceId Source.ClassId =
SRD_BusinessService BMC.CORE:BMC_BusinessProcess "BMC.CORE:BMC_BUSINESSPROCESS"
BusinessProcess _ InstanceId Source.InstanceId
FK:BusinessProcess_InstanceId
BusinessProcess _ ReconId InstanceId
Sandbox_DatasetID Name = (SRD_Title)
Reconciliation Job Name Source.InstanceId=InstanceId
DatasetId
ReconciliationIdentity
SourceLocation = "BMC.SRMS"
SerialNumber = (SRD InstanceId)
Company
RE:Job Operation
_base _DispProp
Job Name
InstanceID SRD_Title RECommand=Start
BusinessServiceInstanceId
SRD_BusinessService
BusinessProcess _ InstanceId
BusinessProcess _ ReconId
Sandbox_DatasetID
BMC Software, Inc.
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
InstanceID
SRD_Level
PDT_InstanceID
PDT_Name
_base _DispProp
SRD_Level
SRD_Instructions
deleted
SRD_Price
Navigation Tier1
Navigation Tier2
Navigation Tier3

BMC Software, Inc.
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 Process Definition
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 Parameters
ID Interface Cmd Sync 1 2
R214 ARS None Poll None None
R457 DSO DSO Init.Req. X Y
R234 DSO DSO Subscribe W Q
Application Object Template Pool

Application Object Application Object
Template Template
AO: Work Order AO: Change Request
Name: Issue Badge Name: Install Desktop
ID: 123 ID: 175
Regid: R324 Regid: R214

Template Template Questions
AO: Work Order AO: Incident Associate Registry Attribute AOI Values Carry
Name: Setup Office Name: Enable Ports ID ID Name Field Question? Predefined Default Over
ID: 223 A R214 Contact Name N/A Request For None No
TID: 183
B R215 Location Location Location? None None Yes
C R216 Priority Priority Priority None Low Yes
D R457 Contact Name N/A Request For None No
Back Office Applications

Work Order Work Order Change Request Incident
Template Template Template Template
Name: Issue Badge Name: Set Up Office Name: Install Desktop Name: Enable Ports
ID: 123 ID: 183 ID: 175 ID: 223
Assign To: Group TT Assign To: Group Assign To: Indiv. Assign To: Group
TT TT TT
Flows X Associations TT Task Template
BMC Software, Inc.
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
Application Registry Process Definition Service Request Service

Definition Request
Process Def.
Template A
Registry Application AOT AOI Local /
Container • Description • Activity Log
ID Object Name Name Remote
Object • Nav. Categories • SLA’s
R214 Change-NA ChTmplate CHReq Local
R457 Incident IncTmplate Incident Remote Application Object • Entitlement • Surveys
R234 Change-AP ChTmplate CHReq Remote B Template
AO: Work Order
Name: Issue Badge
Registry Parameters ID: 123
ID Interface Cmd Sync 1 2 Regid: R324 1 Process Instantiation
R214 ARS None Poll None None
R457 DSO DSO Init.Req. X Y Definition of Process Def.
R234 DSO DSO Subscribe W Q
C Template Template
AOT
AOT AOT AOI AOI
AO: Work Order AO: Incident

Name: Setup Office Name: Enable Ports
Application Object Template Pool TID: 183 ID: 223 AOT AOI
Regid: R124 2 Regid: R214 2
Template Template
AO: Work Order AO: Change Request Application Object
Name: Issue Badge Name: Install Desktop D Template
ID: 123 ID: 175
Regid: R324 Regid: R214 AO: Change Request
Name: Install Desktop
ID: 175
Application Object Application Object Regid: R457 3
Template Template Questions
AO: Work Order AO: Incident Associate Registry Attribute AOI Values Carry
Name: Setup Office Name: Enable Ports ID ID Name Field Question? Predefined Default Over
ID: 223 A R214 Contact Name N/A Request For None No
TID: 183
B R215 Location Location Location? None None Yes
C R216 Priority Priority Priority None Low Yes
D R457 Contact Name N/A Request For None No
Back Office Applications

Work Order Work Order Change Request Incident
Template Template Template Template
Name: Issue Badge Name: Set Up Office Name: Install Desktop Name: Enable Ports
ID: 123 ID: 183 ID: 175 ID: 223
Assign To: Group TT Assign To: Group Assign To: Indiv. 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.

BMC Software, Inc.
Figure 33: PDT entity relationships
SRM:ProcessDefinitionTemplate
$InstanceId$ = 'PDT_InstanceID'
P: SRM:ProcessDefinitionTemplate_Base S: SRM:ProcessDefinitionTemplate_DispProp
Company InstanceId
InstanceId NavigationTier1
PDT_ID PDT_Description
Request Frequency PDT_InstanceID
Request Type PDT_Locale
Status PDT_Name
VersionNumber
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.
BMC Software, Inc.
White Paper
Figure 34: SRD relationship to PDT
InstanceID
SRD_Level
PDT_InstanceID
PDT_Name
_base _DispProp
Custom_CFG_Form_InstanceId TakeSRDOfflineFlag SRM:Associations
FK:InstanceID=
SRD_Level
Assoc1InstanceID
SRD_Instructions Assoc1InstanceID
deleted Assoc2InstanceID
SRD_Price
Navigation Tier1 FK:Assoc2InstanceID=InstanceId
Navigation Tier2
Navigation Tier3
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.

BMC Software, Inc.
Figure 35: AOT entity relationships
CAI:AppRegistry
Instance ID
InstanceID
PDT_InstanceID
FK:Instance ID=PDT_InstanceID
Instance ID
PDT_Name
FK:Assoc1 Instance ID=Instance ID

FK:Instance ID= SRM:Associations

AppRegistry Instance ID
FK:Assoc1 Instance ID=InstanceID
Instance ID
Assoc1 Instance ID
Assoc2 Instance ID
SRM:AppTemplateBridge
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.
BMC Software, Inc.
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 Source Data field Field ID Type

name
Company Company 301453000 Character
InstanceID InstanceID 179 Character
PDT_ID PDT_ID 1 Character
Request_Frequency Request_Frequency 302771600 Character
Request_Type Request_Type 301438012 Selection
Status Status 7 Selection
VersionNumber VersionNumber 301307300 Character
! SRM:ProcessDefinitionTemplate_DispProp contains the localized strings

for the fields on the PDT.
Table 17: SRM:ProcessDefinitionTemplate_DispProp form
Join data label Source Data field Field ID Type

name
Category1 NavigationalTier1 1000000063 Character
PDT_Description PDT_Description 301244800 Character
PDT_Locale PDT_Locale 160 Character
PDT_Name PDT_Name 301244700 Character
! SRM:AppTemplateBridge contains the records that represent the AOTs. The

following table contains a detailed description of the data fields on the form.
Table 18: SRM:AppTemplateBridge form
AOTID 1 Character 15
AppRegistryInstanceID 301287600 Character 40
AppRegistryName 301289000 Character 254
Assignee Groups 112 Character 255
Name 301287500 Character 254
Protocol 301405400 Selection n/a
Server 301286600 Character 255
Template Name 1000001437 Character 254
TemplateInstanceID 301287400 Character 80

BMC Software, Inc.
Table 18: SRM:AppTemplateBridge form (Continued)

TemplateRequestID 301289100 Character 24
TemplateSummary 8 Character 254
Type 300062100 Character 36
URL 302911400 Character 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.
BMC Software, Inc.
White Paper
Figure 36: Data mapping
SRD Questions
Library
Who Me?
What Time?
PDT When, Today?
TD - 1 How Much?
AOT1 TD - 2 Location?
Target Data
TD - 3 1TD - 1 Where?
1TD - 2
AOT2 TD - 4 1TD - 3
2TD - 4
Ignore
3TD - 4
TD - 4 3TD - 5 Ignore
AOT3 TD - 5 3TD - 6 Default
Registry TD - 6
Master Mapped
Field List 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.

BMC Software, Inc.
Figure 37: SRD to data mapping relationship
InstanceID
SRD_Level
PDT_InstanceID
PDT_Name
SRM:UniqueQuestionList
FK:InstanceID=
ParentInstanceID
ParentInstanceID
_base _DispProp SRM:SourceToTargetData
InstanceID SRD_Status ParentInstanceID
BusinessServiceInstanceId SRD_Title ParentInstanceID
SRD_Level
SRD_Instructions
deleted
SRD_Price
Navigation Tier1
Navigation Tier2
Navigation Tier3
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.
! Exposed Target Data Fields—the subset of target data fields exposed for a
given AOT.
! PDT Target Data—the rollup of all target data fields associated with AOTs that
are part of a PDT definition.
! Source to Target Data Mapping—the questions library and target data
mappings.
BMC Software, Inc.
White Paper
Figure 38: SRD relationship to data mapping
InstanceID
SRD_Level
PDT_InstanceID
PDT_Name
FK:InstanceID=
ParentInstanceID
ParentInstanceID
_base _DispProp SRM:SourceToTargetData
InstanceID SRD_Status ParentInstanceID
BusinessServiceInstanceId SRD_Title ParentInstanceID
SRD_Level
SRD_Instructions
deleted
SRD_Price
Navigation Tier1
Navigation Tier2
Navigation Tier3
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.

BMC Software, Inc.
Figure 39: Target data master list
CAI:AppRegistry SRM:AppTargetData
Instance ID z1S_instanceId
Application ID
QuestionDescription
FieldForAnswer
MappedFieldID
FK:Instance ID=Application ID PrepopulateMode
PrepopulateValueType
PrepopulateValue
PrepopulateValueLookupKeyword
RequiredByApp
O-LenCharFlag
ActionMode
ExposedToTemplate
FK:Instance ID=
Instance ID
TemplateName
SRM:Associations
Instance ID SRD:ServiceRequestDefinition
Assoc1 Instance ID FK:Assoc1 Instance ID=InstanceID
Assoc2 Instance ID InstanceID
PDT_InstanceID
Instance ID
PDT_Name
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.
BMC Software, Inc.
White Paper
Figure 40: AOT Target data
Application ID
QuestionDescription
FieldForAnswer
MappedFieldID
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=
Instance ID
TemplateName
SRM:Associations
Instance ID SRD:ServiceRequestDefinition
PDT_InstanceID
Instance ID
PDT_Name
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.

BMC Software, Inc.
Figure 41: PDT target data rollup
Application ID
QuestionDescription
FieldForAnswer
MappedFieldID
PrepopulateValue
FK:z1S_instanceId= PrepopulateValueLookupKeyword
TargetDataInstanceID RequiredByApp
O-LenCharFlag
ActionMode
ExposedToTemplate
SRM:AppTargetDataAssociations
Instance ID
Assoc1 Instance ID
Assoc2 Instance ID
ActionMode
DefaultValue
Exposed
FK:Instance ID=
Instance ID
FK:Instance ID= AppRegistry Instance ID
AOTInstanceID TemplateName
SRM:AppTargetDataRollup
SRM:Associations
FK:Instance ID
PDT_InstanceID
AOTPDT_AssocInstanceID Instance ID SRD:ServiceRequestDefinition
AOTPDT_AssocInstanceID
TargetDataInstanceID
AOTInstanceID
PDT_InstanceID
FK:Instance ID=PDT_InstanceID FK:Instance ID=PDT_InstanceID
Instance ID
PDT_Name
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.
BMC Software, Inc.
White Paper
Figure 42: Questions and target data mapping
CAI:AppRegistry SRM:AppTargetData SRM:QuestionsLibrary
Instance ID z1S_instanceId instanceId

Application ID Question Text
QuestionDescription Category
FieldForAnswer SRM:MasterData AnswerFormat
MappedFieldID MappingList AnswerFieldTypeDeveloper
FK:Instance ID=Application ID PrepopulateMode Name
PrepopulateValueType InstanceID
PrepopulateValue FormName
FK:z1S_instanceId= PrepopulateValueLookupKeyword Server
FK:z1S_instanceId= FieldID
TargetDataInstanceID RequiredByApp
O-LenCharFlag
ActionMode
ExposedToTemplate FK:instanceId=DIDInsatnceID
FK:InstanceID=TDSourceInstanceID
SRM:AppTargetDataAssociations SRM:SourceToTargetDataAssociations
Instance ID Instance ID
Assoc1 Instance ID ParentInstanceID
Assoc2 Instance ID AOTAssociationInstanceID InstanceID
FK:InstanceID=
ActionMode AppObjectTemplateInstanceID ParentInstanceID
UniqueQuestionInstanceID
DefaultValue TargetDataInstanceID DIDInstanceID
Exposed TDSourceInstanceID Order
UniqueQuestionInstanceID Required
FK:Instance ID= MapTargetTo Default Value
AppRegistry Instance ID Default Value
FK:Instance ID=
Instance ID AppObjectTemplateInstanceID
FK:Instance ID= AppRegistry Instance ID
AOTInstanceID TemplateName FK:InstanceID= FK:InstanceID=
ParentInstanceID ParentInstanceID
FK:Instance ID=
SRM:AppTargetDataRollup
SRM:Associations AOTAssociationInstanceID
FK:Instance ID
PDT_InstanceID
AOTPDT_AssocInstanceID Instance ID SRD:ServiceRequestDefinition
AOTPDT_AssocInstanceID
AOTInstanceID
PDT_InstanceID
FK:Instance ID=PDT_InstanceID FK:Instance ID=PDT_InstanceID
Instance ID
PDT_Name
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 pre-
populated 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.

BMC Software, Inc.
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 Sub-tree option Supporting form

Advanced Application Settings SRM:ApplicationSettings
Configure Custom Form Data SRS:CFGCustomForm
Rules SRM:CFG Rules
SRD Setting SRD:CFG Settings
Service Request HTML SRS:ServiceRequestHTML
Configuration
Survey Configuration SRM:ConfigSurveyQuestions
Application Define Application Field SYS:Form Field Selection
Configuration Define Application Object SRM:AppTemplateBridge
Template
Define Application Target Data SRM:AppTargetData
Define Question Library SRM:QuestionsLibrary
Approval Approval Mappings APR:Approver Lookup
Entitlement Entitlement Group ENT:Entitlement Groups
Management
Entitlement Management ENT:Entitlement Console
On Behalf of Management OBO:On Behalf Of Console
Navigational Navigational Categories SRM:Navigational Category
Categories
Request Entry Browse for Service Details SRM:CategoryDetails/View:
Management CategoryDetails
Default Console Preferences SRS:DefaultPreferences
Service Request Definition SRM:CategoryDetails/View:
Image Management ImageMapping
Service Request Image SRS:ServiceRequestImages
Configuration
Service Request Search SRS:ServiceRequestQueryExcl
Exclusion String usions
Service Level Service Target Defaults INT:SLMSRS:ConfigServiceTar
Management get:Defaults
Work Order Rules WOI:CFG Rules
Work Order Template WOI:Template
BMC Software, Inc.
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
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.

BMC Software, Inc.
Figure 44: Catalog manager console—searching and viewing PDTs
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 63

BMC Software, Inc.
White Paper
Figure 45: Service request execution
Automated
Tools
Service Request Service

Definition Request
• Description • Activity Log
• Nav. Categories • SLA’s
• Entitlement • Surveys
Process Instantiation
Definition of Process Def.
AOT
AOT AOT 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.

BMC Software, Inc.
Figure 46: The RPD model
Definition Runtime Execution

– Service Request Definition – Service Request
– Process Definition Templates – Provide Information / Data
• PDT’s • Questions
• AOT’s • Responses
– Data Mapping – Process Definition Instance
• Questions • PDI’s
• Target Data • 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 Description
Draft Initial state or user saves draft of SR.
In Review 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.
Pending
More Information SR agent needs additional information.
System Error Indicates a system error occurred with AOI.
Waiting Approval SR is going through the approval process.
Planning AOIs are created but no work has started on the AOIs.
In Progress SR is being implemented; at least one of the back-end
application requests is in progress.
Completed
With Issues SR is completed but one or more AOIs has been cancelled or
rejected.
Successful All AOIs have completed successfully.
Rejected SR was rejected after being sent through the approval process.
Cancelled

BMC Software, Inc.
White Paper
Table 20: SR life cycle (Continued)

Status or Status Reason Description
By User The user has cancelled the SR. This operation cancels the SR
and sends a signal to the AOIs that the SR has been cancelled.
By Provider One or more back-end AOIs have been cancelled; SR
coordinator is notified.
Closed
Successful Closed automatically without any problems. Based on survey
results.
With Issues Closed automatically but with some problems. Based on
survey results.
System 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 Cancelled SR has been closed.
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.

BMC Software, Inc.
Figure 47: Legal state transition support for the service request
Draft
In Review
SR doesn’t
need approval
Cancelled by SR SR needs
Coordinator approval
Rejected Waiting Approval
User cancels
request
Need more info

Planning
Pending
Need more info

In Progress
Re-open
Completed
Cancelled
Automatically
closed
Closed
Table 21 defines all the possible state transitions.State transitions

Table 21: State transitions
Completed
Cancelled
Approval
Planning
Rejected
Progress
Pending
Waiting
Review
Closed
Draft
In
In
Draft - Yes1 No No No No No No Yes No

In Review No - No Yes Yes No No No Yes No
Pending No No - Yes Yes No No No Yes No
2
Waiting Approval No No Yes - Yes No No Yes Yes No
2 3
Planning No No Yes No - Yes Yes No Yes No
In Progress No No Yes2 No No - Yes No Yes No

BMC Software, Inc.
White Paper
Table 21: State transitions (Continued)
Completed
Cancelled
Approval
Planning
Rejected
Progress
Pending
Waiting
Review
Closed
Draft
In
In
Completed No No Yes No No No - No No Yes
Rejected Yes No No Yes No No No - Yes No
Cancelled No No No No No Yes No No - Yes
Closed No No No No No No No No No -
1For ad hoc requests waiting for SR coordinator action.

2Pending more information.
3If the back-end application status transitions from New to Completed, Rejected,
or Closed, an SR can transition from Staged to Completed.
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

FK:Assoc2InstanceID=
Service Request SRD:ServiceRequest

SRM:Associations
InstanceId
Definition Process
Definition
InstanceID Assoc1InstanceID
Assoc2InstanceID
SRM:Survey
Definition SRM:Process
Surveys
Originating_Request_InstanceID
FK:SRDInstanceID=
InstanceId Instances
Service Request InstanceID
InstanceID
FK:Originating_Request_InstanceID=
InstanceId
SRM:Request Application
FK:Service Request InstanceID=
InstanceId
Custom Form
Custom Forms
SRInstanceID
FK:SRInstanceID= InstanceId
Object
FK:SRInstanceID=
SRM:AppInstanceBridge
InstanceId Request Number
InstanceId
Request ID SRInstanceID
SRDInstanceID
Instances
Question
SRM:QuestionResponse
FK:SRInstanceID= FK:SRInstanceID=
Service
InstanceId InstanceId WOI:Work Order
Responses
SRInstanceID
Fulfillment HPD:Help Desk
Applications CHG:Infrastructure
Request
FK:ApplicationInstanceID = FK:SRInstanceID= Change
SLM:EventSchedule InstanceId InstanceId
ApplicationInstanceID
SRM:WorkInfo
Service Level FK:SLA_Reference InstanceID=

InstanceId
Work Info
FK:Original Request Id=
SRInstanceID
Request ID
Management
SLM:Measurement
Navigational
Category 1, 2, 3
Request Coordinator
Region/Site Group/Site
SRM:SR_AuditLog
SLA_Reference InstanceID
Requested By
Requested For Auditing Data Original Request ID
SRM:Navigational
COM:Company CTM:Region
Category
Navigational CTM:Support
Foundation
SIT:Site Group
Categories Data References

Group
CTM:People SIT:Site
Configuration Data
Get approval definition Get auto-close, survey, etc. Create entry to notify
APR:SYS-
NTE:SYS-NT
Approval SRM:CFG Rules
Process Control
Definition

BMC Software, Inc.
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
Actual Cost 300354900 Currency n/a
Actual Duration 300798302 Integer n/a
Actual Start Date 1000000348 Date and Time n/a
Anticipated Approval Date 1000001214 Date and Time n/a
Anticipated Completion Date 1000001182 Date and Time n/a
Anticipated Duration 300798301 Integer n/a
Anticipated Start Date 300354902 Date and Time n/a
AOI Entry ID 301720300 Character 15
Approval Date 303018300 Date and Time n/a
Approval Phase Name 1000003143 Character 60
Approval Process Name 301236000 Character 255
Approval Status 1000003264 Selection n/a
Approved Date 1000001184 Date and Time n/a
Assigned Support Company 1000000251 Character 254
Assigned Support Organization 1000000014 Character 60
Assignee 10010413 Character 254
Category 1 1000000063 Character 60
CI_Name 200000020 Character 254
Closed Date 302904200 Date and Time n/a
Company Group Name 301438710 Character 254
Completion Date 1000002195 Date and Time n/a
Concate_ Status_StatusReason 302830300 Character 255
Cost Center 1000000188 Character 25
Customer Company 1000003299 Character 254
Customer Company Group Name 301438720 Character 254
Customer Cost Center 300890300 Character 25
Customer Department 1000003301 Character 60
Customer First Name 1000003297 Character 30
Customer Full Name 1000000025 Character 128
Customer Internet E-mail 1000003302 Character 255

BMC Software, Inc.
White Paper
Table 22: SRM:Request (Continued)

Customer Last Name 1000003298 Character 30
Customer Location Company 1000003310 Character 254
Customer Middle Name 300890310 Character 30
Customer Organization 1000003300 Character 60
Customer Phone Number 1000003306 Character 50
Customer Region 200000013 Character 60
Customer Site 200000015 Character 60
Customer Site Group 200000014 Character 60
Customer SiteID 1000003503 Character 15
CustomFormName 302826200 Character 254
CustomFormServer 301286600 Character 254
Department 200000006 Character 60
Estimated Cost 300354901 Currency n/a
Expected Cost 302783800 Currency n/a
Expected Date 302791600 Date and Time n/a
First Name 1000000019 Character 30
Form Name 301086200 Character 38
Impact 1000000163 Selection n/a
Internet E-mail 1000000048 Character 255
Last Name 1000000018 Character 30
Location Company 1000000001 Character 254
Mail Station 1000000036 Character 30
Manufacturer (2) 1000002270 Character 254
Middle Name 300810110 Character 30
Offering Description 1000000000 Character 0
Organization 1000000010 Character 60
Phone Number 1000000056 Character 50
Price 302793000 Currency n/a
Priority 1000000164 Selection n/a
Product Cat Tier 1(2) 1000001270 Character 60
Product Cat Tier 2 (2) 1000001271 Character 60
Product Cat Tier 3 (2) 1000001272 Character 60
Product Model and Version (2) 1000002269 Character 254
Product Name (2) 1000002268 Character 254
Reason Code_Assignee 301324000 Character 255
Reason Code_Manager 301323900 Character 255
Received Date 303051500 Date and Time n/a

BMC Software, Inc.

Region 200000012 Character 60
RejectApprovalStatusReason 1000003219 Character 30
Request Manager 1000000218 Character 69
Request Manager Login 1000000408 Character 254
Request Number 1000000829 Character 15
Request Type 301438012 Selection n/a
Required Date 1000001181 Date and Time n/a
Service Location Address 1000000038 Character 255
Service Type 1000000099 Selection n/a
ServiceRequestApproval 301248900 Selection n/a
Site 260000001 Character 60
Site City 1000000004 Character 60
Site Country 1000000002 Character 60
Site Group 200000007 Character 60
SiteID 1000000074 Character 15
Site State Province 1000000003 Character 60
Site Street 1000000037 Character 90
Site Zip or Postal Code 1000000039 Character 15
SLA Responded 301788100 Selection n/a
SLM Status 1000003009 Selection n/a
SolutionRequestID 301710700 Character 38
SR Type Field 1 300070001 Character 0
SR Type Field 6 300070006 Date and Time n/a
SR Type Field 7 300070007 Date and Time n/a
SR Type Field 8 300070008 Integer n/a
SR Type Field 9 300070009 Integer n/a
SR_Actual_TurnaroundTime 303044300 Integer n/a
SR_Expected_TurnaroundTime 303051400 Integer n/a
SRD_Level 302793100 Character 100
SRD_Number 302849400 Character 15
SRD_TurnaroundTimeUnits 302793600 Selection n/a
SRD_TurnaroundTimeX 302793500 Integer n/a
SRDInstanceID 301303200 Character 38

BMC Software, Inc.
White Paper

Status_Reason 1000000150 Selection n/a
Submitter GroupID 1000001255 Character 50
SuccInstanceNumCol 1000005875 Column n/a
Summary 301244700 Character 255
SurveyAssocInstanceID 302883500 Character 38
TitleFromSRD 302829600 Character 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
InstanceId
SRD:ServiceRequest
SRM:Associations
Definition
InstanceID Assoc1InstanceID
Assoc2InstanceID
SRM:Process
SRM:Survey
Originating_Request_InstanceID InstanceId
FK:SRDInstanceID=
InstanceID
FK:Originating_Request_InstanceID=
InstanceId
SRM:Request InstanceId
Custom Forms
FK:SRInstanceID= InstanceId SRM:AppInstanceBridge
SRInstanceID InstanceId Request Number FK:SRInstanceID=
Request ID InstanceId SRInstanceID
SRDInstanceID
FK:SRInstanceID= FK:SRInstanceID=
InstanceId InstanceId WOI:Work Order
SRInstanceID
HPD:Help Desk
CHG:Infrastructure
FK:ApplicationInstanceID = FK:SRInstanceID= Change
SLM:EventSchedule InstanceId InstanceId
SRM:WorkInfo
FK:SLA_Reference InstanceID=
SRInstanceID
InstanceId FK:Original Request Id=
Request ID
Navigational Region/Site Group/Site
Category 1, 2, 3
SLM:Measurement Request Coordinator SRM:SR_AuditLog
Requested By
SLA_Reference InstanceID Requested For Original Request ID
SRM:Navigational
Category
CTM:Support
SIT:Site Group
Group
CTM:People SIT:Site
Get approval definition Get auto-close, survey, etc. Create entry to notify
APR:SYS-
NTE:SYS-NT
Approval SRM:CFG Rules
Process Control
Definition

BMC Software, Inc.
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

Case Description 230000008 Character 128
Comment 1 260000020 Character 0
Last_Surveyed_Date 301694700 Date n/a
PersonID 1000001021 Character 15
Question 1 260000000 Character 255
Question 1 Rating 260000010 Integer n/a
Request Type* 301438012 Selection n/a
Status* 7 Selection n/a
SurveyID 1 Character 15
Survey Name1 302838900 Character 255
Survey_e-Mail_Address 301693800 Character 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.

BMC Software, Inc.
White Paper
Figure 50: Custom forms
SRM:Request
Custom Forms
FK:SRInstanceID= InstanceId
SRInstanceID InstanceId Request Number
Request ID
SRDInstanceID
Questions and When completing a service request, the defined questions established as part of
responses 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
FK:SRInstanceID=
InstanceId
SRInstanceID
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.

BMC Software, Inc.
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:UniqueQuestionList

SRM:QuestionList_Join
ParentInstance ID
Navigational Navigational categories are carried over from the SRD and stored on the Service
categories 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.

BMC Software, Inc.
White Paper
Figure 53: Navigational categories
SRM:Request
InstanceId
Request Number
Request ID
SRDInstanceID
Navigational
Category 1, 2, 3
SRM:Navigational
Category
Foundation The service request leverages the ITSM Foundation components to provide
data information that is critical to the routing and resolution of issues by the back-
references office 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.

BMC Software, Inc.
Figure 54: Foundation data references
SRM:Request
InstanceId
Request Number
Request ID
SRDInstanceID
Region/Site Group/Site
Request Coordinator
Requested By
Requested For
CTM:Support
SIT:Site Group
Group
CTM:People SIT:Site
Configuration When a service request is initiated, there is workflow that performs lookups
forms 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.

BMC Software, Inc.
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 Work information records provide updates to a given service request after it is
information initiated. This information is linked to the service request by storing the SR
(activity log) 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

BMC Software, Inc.
Service The service request is initiated from the selected SRD, and the SRD instance ID is
request used as the primary foreign key on the SR to maintain the relationship to the
definition originating SRD.
Figure 57: Service request definition
SRD:ServiceRequest
Definition
InstanceID
FK:SRDInstanceID=
InstanceID
SRM:Request
InstanceId
Request Number
Request ID
SRDInstanceID
Process Process definition instances and application object instances are the run-time
components instances of the process definition templates and application templates that are
associated with the selected SRD.

BMC Software, Inc.
White Paper
Figure 58: Process components entity relationships
InstanceId
SRM:Associations
Assoc1InstanceID
Assoc2InstanceID
SRM:Process
InstanceId

SRM:Request InstanceId
InstanceId SRM:AppInstanceBridge
FK:SRInstanceID=
Request Number
InstanceId SRInstanceID
Request ID
SRDInstanceID
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.

BMC Software, Inc.
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”
SRD:ProcessDefinition
3. Create PDI 4. Create AOIs,
Template
5. On Modify
'zTmpCommand' = "CREATEFLOW"
SRM:AppInstance
SRD:Process
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.

BMC Software, Inc.
White Paper
Figure 60: AO functional processes
Application Object
Instance
(SRM:AppInstanceBridge)
1. Pulls the default 2. Pulls the default from the 3. Pulls the data from
from target data association between AOT and TD the TD mapping on SRD
SRM:QUTBaseJoinApp SRM:TDAOTAssocTD SRM:SourceTDData

RegJoin _Join Mapping_Join
SRM:AppTargetData SRM:MasterData
SRM:AppTargetData
Associations MappingList
SRM:SourceAppTarget
Data_Join
SRM:MasterData
MappingList
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.
! SRM:AppInstanceBridge stores the initialization of the Application Object
Template and is referred to as the application object instance record.
Subsystem integrations
Fulfillment As a result of integrating with back-office fulfillment applications a link to the
applications 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.

BMC Software, Inc.
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.
The following join forms were created to integrate the approval engine with the
SRM:Request 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 The service targets for a given service request are established during the
management definition stage of the SRD. During the execution stage, the SLAs are managed by
the SLM:EventSchedule and the SLM:Measurement forms.

BMC Software, Inc.
White Paper
Figure 62: Service level management entity relationships
SRM:Request
InstanceId
Request Number
Request ID
SRDInstanceID
FK:ApplicationInstanceID=
SLM:EventSchedule 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.

BMC Software, Inc.
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
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.

BMC Software, Inc.
White Paper
The following table summarizes the purpose and supporting structures of each
tab view.
Table 24: Tab view purpose and supporting structures
Tab Function Primary supporting structures

1 Browse Service Categories Data Visualization Field (1)
2 Browse Sub Categories Data Visualization Field (1)
3 Display Search Results List Data Visualization Field (1)
4 Present SRD specific questions Character, radio, check box, integer
fields
5 Display details of catalog entry HTML View Field (1)
6 Display summary of SR prior to being HTML View Field (2)
submitted
7 Review and manage submitted Table and HTML view field (3)
requests
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.

BMC Software, Inc.
Figure 64: DVF plugin architecture
Client
DVF
AR System Mid-Tier
Plug-in Container
Controller
SRMS DVF Plug-in
Service Layer
Services Views
TopCategoriesBrowserService TopCategoriesView
ServiceCategoriesBrowserService ServicCategoriesView
ListServiceRequestsService ServiceRequestListView
ApplicationImageService NoDataFoundView
Data-Mapper Layer
Repositories Resource Loaders

TopCategoriesRepository ClasspathResourceLoader
CategoriesRepository PluginDefinitionResourceLoader
ServiceRequestsRepository ClasspathTemplateLoader
FavoriteServiceRequestsRepository
ApplicationImageRepository
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.

BMC Software, Inc.
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
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.

BMC Software, Inc.
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
3
1
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.

BMC Software, Inc.
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 Interface form Web service Web service operation

SRM:Request SRM:Request SRM_Request Request_Modify_Service
Interface Interface_WS Request_Query_Service
Request_QueryList_Service
SRM:Request SRM_Request Request_Submit_Service
Interface_Create Interface_
Create_WS
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.

BMC Software, Inc.
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 Interface form Web service Web service

operation
CAI:Events CAI:EventsInterface CAI: Events_Modify_
EventsInterface_ Service
WS
Events_Query_
Service
Events_QueryList
_Service
CAI:Events CAI: Events_Submit_
Interface_Create EventsInterface_ Service
Create_WS
CAI:Event Params CAI: CAI: EventParams_
EventParams EventParams Modify_Service
Interface Interface_WS
EventParams_
Query_Service
EventParams_
QueryList_
Service
CAI: CAI: EventParams_
EventParams EventParams Submit_Service
Interface_Create Interface_Create_
WS
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 91

BMC Software, Inc.
White Paper
Figure 67: Integration flow to interface BMC SRM with back-office fulfillment systems
General Flow
SRM
External
Application
Interface Form Main System Form

Creates Interface
record using
webservice Processes
incoming
parameters
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).

BMC Software, Inc.
Figure 68: Populating field 1 where an overlap exists
Title
Approval
Service
SLA
Request
New Emp.
Description
Interface Incident Form
Process Definition Field 1: Hello Field 1: Hello
Field 2: World Field 2: World
Incident Command
Field 3: Field 3: Later
AOI Automation
[New Employee] Interface Field A: Field 4:
Field B: Field 5:
TempId: 123 TempId: 123
Incident Template
Incident Template
Incident
Field 1: Template A
Field 1:
FieldField
2: 1: See You
Field 2:
FieldField
3: 2:
Field 3:
FieldField
4: 3: Later
Field 4:
FieldField
X: 4:
Field X:
TempId:
Field X:
TempId:
TempId: 123
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,
HPD:Help Desk. This interface form is the integration point for external systems
to create new incident tickets.
! 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).
Access to these forms also support interactions using web services. Figure 69
shows how an external application integrates with Incident Management.

BMC Software, Inc.
White Paper
Figure 69: Integrating an external application with Incident Management
Help desk ticket submit
ITSM
Creates an association Association
External
with a CI if a CI name forms
application
is specified
Creates staging HPD:IncidentInterface

HPD:Help Desk
record using Help (Staging form)
Desk Submit web Processes Creates Help Desk
service incoming record and Work Log
parameters record
HPD:Work Log
Data flow direction
Interfaces
The following table describes the Incident Management integration interfaces.
Table 27: Incident Management integration interfaces
Form Interface form Web service Web service operation

HPD:HelpDesk HPD: HPD_Incident HelpDesk_Modify_Service
Incident Interface_ HelpDesk_Query_Service
Interface WS
HelpDesk_QueryList_Service
HPD: HPD_Incident HelpDesk_Submit_Service
Incident Interface_
Interface_ Create_WS
Create
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,
CHG:InfrastructureChange. This interface form is the integration point for
external systems to create new change requests.
! CHG:ChangeInterface T belongs to the primary Change Management form,
CHG:InfrastructureChange. This self-join, interface form is the integration point
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).
Access to these forms also supports interactions using web services.

BMC Software, Inc.
Interfaces
The following table describes the Change Management integration interfaces.
Form Interface form Web service Web service
operation
CHG: CHG: CHG: Change_Modify_
InfrastructureChange Change ChangeInterface Service
Interface _WS
Change_Query_
Service
Change_QueryList_
Service
CHG: CHG: Change_Submit_
ChangeInterface ChangeInterface Service
_ _
Create Create_WS
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.

BMC Software, Inc.
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
Query
Create Modify
Query List
WOI:WorkOrderInterface_Create WOI:WorkOrderInterface
(Work Order Form) (Work Order Form)
WOI:WorkOrder
(Work Order Primary Form)
WOI:Template
(Work Order 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
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.

BMC Software, Inc.
Table 28: SRM request management permission model
Types of BMC SRM roles

BMC SR
users
BMC SRMcatalog
administrator
Unknown user
Entitlement
Registered
Business
manager
SR user
manager
manager
BMC SRM
User
Consoles
Request Entry Console Yes Yes Yes Yes Yes Yes Yes
Business Manager Console No No No Yes No No No
SR Coordinator Console No No Yes No No No No
Catalog Manager Console No No No No No Yes No
2
App. Admin Console No No No No Yes No Yes
Functions
Create or Modify SR for Self Yes Yes Yes Yes Yes Yes Yes
Reopen Requests Yes Yes Yes Yes Yes Yes Yes
Close Requests Yes Yes Yes Yes Yes Yes Yes
View broadcasts Yes Yes Yes Yes Yes Yes Yes
Surveys Yes Yes Yes Yes Yes Yes Yes
Add more information Yes Yes Yes Yes Yes Yes Yes
Cancel Requests Yes Yes Yes Yes Yes Yes Yes
Approve Requests No No Yes Yes Yes Yes Yes
Create or Modify SR for Others No No Yes Yes No No No
Cancel Others Requests No No Yes Yes No No No
1
Define Entitlement Rules No No No No Yes Yes Yes
Reports No No Yes Yes No Yes No
BMC SRM Admin. and Config. No No No No No No Yes
Access
Create or Modify SRDs No No No No No Yes No
System Level Trouble Shooting No No Yes No No No Yes
1
Create or modify entitlement rules through the Entitlement tab on the SRD form.
2
Access to Entitlement configuration only.
Service Request Management permission model 97

BMC Software, Inc.
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.

BMC Software, Inc.
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 Acronym Description

Application object AOI Instantiation of an AOT during its execution phase.
instance
Application object AOT Interface to a back-end application that is needed to
template fulfill a service request.
Back-office fulfillment BOFA Any application used by a service organization that
application is used to fulfill a service request.
Command automation CAI Subsystem designed to support bi-directional
interface communication between applications and other
systems.
People entitlement PED Defines who has access to deployed SRD’s in the
definition catalog.
Process definition PDI Instantiation of a PDT during its execution phase.
instance
Process definition PDT Defines the process that supports the related Service
template Request Definition.
Request, process, data RPD The primary components required to define a
mapping catalog entry.
Service request SR 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.
Service request SRD The definition of a service that is available for users
definition to request through the service catalog.
Service request SRDED Definition of what SRD’s are accessible.
definition entitlement
definition
Service request SRM The process of managing information technology
management services to meet the customer’s requirements.
Target data TD Data that is mapped to fields on a registered
interface form.
Licensing model 99
BMC Software, Inc.
White Paper
100 Terminology
BMC Software, Inc.
*86808*
*86808*
*86808*
*86808*
*86808*

White Paper BMC Service Request Management 2 0 Architecture

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

White Paper BMC Service Request Management 2 0 Architecture

Încărcat de

Drepturi de autor:

Formate disponibile

White Paper

BMC Service Request

© Copyright 2007 BMC Software, Inc.

Restricted rights legend

Support by telephone or email

Before contacting BMC Software

Bridging the front office and the back office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

BMC Service Request Management

This document provides an architectural overview and description of how the

BMC Service Request Management 2.0 Architecture 3

Figure 1: User to IT department back-office relationship

Figure 2: User to back-office workflow

4 BMC Service Request Management 2.0 Architecture

Many standard requests often originate from within the IT department. To

Bridging the front office and the back office

Figure 3: BMC SRM engine components

Request Process • Change Management

6 BMC Service Request Management 2.0 Architecture

Figure 4: Roles supporting end-to-end solution

Request Process • Change Management

Bridging the front office and the back office 7

New employee hire scenario

8 BMC Service Request Management 2.0 Architecture

New employee hire scenario 9

Key information for the New Hire scenario

Table 3: Process definition

Sequence Task Fulfillment organization Supporting

Table 4: Data mapping

Data mapping Fulfillment organization application fields

10 BMC Service Request Management 2.0 Architecture

Defining and building the BMC SRM solution versus execution

Figure 5: BMC SRM Solution stages

New employee hire scenario 11

Figure 6: Definition versus execution

Service Request Service

RPD model (request, process, data mapping)

12 BMC Service Request Management 2.0 Architecture

Data mapping definition

Putting it all together

14 BMC Service Request Management 2.0 Architecture

Figure 7: The RPD model

Work Order Incident

BMC SRM Framework

For a more comprehensive discussion of the BMC SRM Framework architecture,

Figure 8: CAI high level design

Definition Construction Execution

16 BMC Service Request Management 2.0 Architecture

Table 5: CAI components—Definition or reference

CAI component Form name Description

Table 6: CAI components—run-time

CAI component Form name Description

Figure 9: How components relate in support of the CAI design

Definition 2. Map command parameters for each

FilterAPI Plugin AR Workflow

Push event and event Launch

18 BMC Service Request Management 2.0 Architecture

Service request definition

Figure 10: SRD life cycle

Service Request Definition Life Cycle

Note: SR means Status Reason

Status Status In SRD Description

Deployed N/A No SRD Approved; Has

Deployed N/A No end Available to users.