White Paper BMC Service Request Management 2 0 Architecture

www.bmc.com

White Paper

BMC Service Request Management 2.0 Architecture

December, 2007

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

Contacting BMC Software

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

United States and Canada

Address BMC SOFTWARE INC2101 CITYWEST BLVDHOUSTON TX 77042-2827 USA

Telephone 713 918 8800 or800 841 2031

Fax 713 918 8000

Outside United States and Canada

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

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

http://www.bmc.com

mailto:[email protected]

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 [email protected]. (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

http://www.bmc.com/support_home


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 [email protected]. (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.


http://www.bmc.com/support_home

Contents

Bridging the front office and the back office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6New employee hire scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Key information for the New Hire scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Defining and building the BMC SRM solution versus execution . . . . . . . . . . . . . 11

Catalog definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12RPD model (request, process, data mapping). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Request definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Process definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Data mapping definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Putting it all together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14BMC SRM Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Catalog architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Process definition template architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Data mapping architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Supporting consoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Execution of a run-time service request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63RPD model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Service request architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Supporting consoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Back-office fulfillment system integrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Back-office templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Incident Management integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Change Management integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Work Order Management integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Service Request Management permission model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Licensing model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Appendix A Terminology 99

Contents 1BMC Software, Inc.

2 BMC Service Request Management 2.0 Architecture BMC Software, Inc.

White Paper


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 3BMC 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

Serv

ice R

eque

st

Mana

gem

ent

Serv

ice R

eque

st

Mana

gem

ent

� Change Management� Incident Management� Work Orders� Custom Fulfillment

Back OfficeService Fulfillment



Self ServiceInterface

End Users


End Users



End Users

ServiceProvidersService

ProvidersService

Providers



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)

5BMC Software, Inc.

White Paper

Bridging the front office and the back officeBMC 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

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.

Serv

ice R

eque

st

Mana

gem

ent

Serv

ice R

eque

st

Mana

gem

ent





ServiceCatalog

Service LevelManagementApprovals Notifications Service LevelManagementApprovals Notifications


End Users


End Users



End Users


ProvidersService

Providers

Executionof SR

Process

Executionof SR

Process

Executionof SR

Process

SR Process Definition



ExternalSystem(s)External

System(s)

ServiceRequestServiceRequest



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

Serv

ice R

eque

st

Mana

gem

ent

Serv

ice R

eque

st

Mana

gem

ent





ServiceCatalog

Service LevelManagementApprovals Notifications Service LevelManagementApprovals Notifications

BusinessManagerBusinessManagerBusinessManager


End Users


End Users



End Users

RequestCoordinator

RequestCoordinator

BusinessRelationship

Manager

BusinessRelationship

Manager


ProvidersService

Providers

ServiceCatalogManager



Executionof SR

Process

Executionof SR

Process

Executionof SR

Process




ExternalSystem(s)External

System(s)

ServiceRequestServiceRequest

Bridging the front office and the back office 7BMC 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.

New employee hire scenarioThe 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

Table 1: Service catalog developers and maintainers

Role Responsibility

Business relationship manager

The business relationship manager works closely with both the business and the IT department to define the service request requirements (for example, the services that are required, a reasonable turnaround time for a service, or a reasonable price that the business is willing to pay).

Service catalog manager

The service catalog manager is responsible for creating and managing the SRDs and, specifically, the fulfillment process definitions within the service catalog. The person in this role works closely with the business relationship manager to create and implement the requests from the business (for example, defining that a certain request requires a certain type of specific process).

Service request coordinator

The service request coordinator (Service Request Agent in ITIL terminology) is responsible for troubleshooting requests that are exceptions to the normal process. However, service request coordinators do not work on the requests themselves; that responsibility belongs to the back-office fulfillment provider. Service request coordinators are members of the front-line support staff. This is an optional role.



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

White Paper

Key information for the New Hire scenarioThe following tables summarize the key information that defines this particular request definition catalog entry.

Table 3: Process definition

Table 4: Data mapping

Table 2: Request definition

Title Description Entitlement Turnaround time

New Employee hire This service request is intended 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.

HR Managers 3 Days

Sequence Task Fulfillment organization Supporting application

1 Background check and issue badge

Security Work Order

2 Set up office Facilities Work Order3 Enable ports IT Incident

ManagementInstall new desktop IT Change

Management

Data mapping Fulfillment organization application fields

HR Input Security - WO Facilities - WO IT - IM IT - CMEmployee Name Requested for Requested for requested for requested

forStart Date Special type field Special type field custom field required

start dateOffice and Building special type field Special type field custom field notesFloor Plan N/A Special type field N/A N/A



Defining and building the BMC SRM solution versus executionThe 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 11BMC Software, Inc.

White Paper

Figure 6: Definition versus execution

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

Serv

ice

Req

uest

Man

agem

ent S

yste

mService Request

Definition

� Title� Description� Nav. Categories� Entitlement� Approvals

ServiceRequest

� End User Console� Activity Log� SLA�s� Surveys� Approvals

Instantiationof Process Def.

ProcessDefinition

AOT AOTAOT

AutomatedTools

AutomatedTools

AOTAOT

AOTAOT

AOIAOIAOIAOI

AOIAOI

DefinitionDefinition ExecutionExecution



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

make up the SRD definition:! Additional keywords to be associated with a given SRD when searching the

catalog.

! Navigational categories used to organize how the user can browse the catalog to find a given catalog entry.

! The cost and price associated with the service.

! The start and end dates for which the catalog entry is available to entitled users.

! The service levels that should be applied.

! What approval is required.

! Which process should be invoked to support the selected catalog entry.

This component defines much of how a given catalog entry is presented to the user. After selected, the SRD also determines how the catalog entry is managed (with regard to SLAs and approvals) during runtime.

Process definitionThe process definition establishes how the requested work gets done by specifying who does what and when. A process definition template (PDT) provides a model for 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 specific back-office fulfillment application where an 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 templates (AOTs). If multiple steps and AOTs are 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.

Title

DescriptionS

LA

Approval

ServiceRequest

Def. 1

Title

DescriptionS

LA

Approval

ServiceRequest

Def. 1

Process DefinitionProcess Definition

ChangeRequest

[Install Desktop]

Work Order[Sec. Badge]

Work Order[Setup Office]

Incident[Enable Ports]

Catalog definition 13BMC Software, Inc.

White Paper

Data mapping definitionAlthough the order in which you complete the request definition and process definition does not matter, you must perform the data mapping step last. This is because, the context in which front-office input data must be mapped to 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 togetherAfter 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.

OfficeLocation?

Data MappingOffice

Location?

Data Mapping



Figure 7: The RPD model

BMC SRM FrameworkThis 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.


ChangeRequest

[Install Desktop]

Work Order[Sec. Badge]

Title

Description

SLA

Approval

ServiceRequest

Def. 1

Title

Description

SLA

Approval

ServiceRequest

Def. 1

Work Order[Setup Office]

Office Location?

Data MappingOffice

Location?

Data Mapping

Incident[Enable Ports]


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

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

Done

ID Name ProtocolApp Registry

Definition Construction Execution

Command Direction Op. TypeCommands

Param Data Type ModeParameters

What How Just Do ItEvent Data Values Command Content Runtime Command

2

3

4

51



Table 5: CAI components—Definition or reference

Table 6: CAI components—run-time

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

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 mapping

CAI:CommandParamMapping Defines the mapping between the command parameters and the backend application.

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.


White Paper

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

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.

CAI:Event

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

CAI:EventParam

EventGUID ParmName ParamValue ParamAttachmentValue ParamType ParamDataType

CAI:AppRegistry

U1 InstanceIDU2 AppRegistryName ApplicationName ApplicationInstanceID Protocol Connection Info Interface Form Names

CAI:Command

U1 Command Direction OperationType SelectionType

CAI:CommandParam

U1 CommandU1 CommandParam Type DataType Mode

CAI:CommandParamMapping

AppRegistryName Command CommandParam AppInterfaceFormName AppFieldName AppFieldID ParamType ParamDataType

SRMS/TMS

Push event and run-time data to event params (outbound)

FilterAPI Plugin

App Interface Form

Mapped Param

Push event and event params

Calls GetEntry to get event values

1. Register application

0. Create commands and command parameters

2. Map command parameters for each registered application

Definition

Construction

Execution (outbound)

AR Workflow

Browser

Launch



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

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

Service request definition life cycleAn 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

Draft

Deployed

Closed

Expired

RejectedPending

Request ForApproval

SR =More Information

Approved

Effective End Datereached

SR = Cancelled

SR= Cancelled

Note: SR means Status Reason

Service Request Definition Life Cycle

Approvalcanceled


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

Service request definition structureThe 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.

Status Status reason

In effectivedate range

SRDonline status

Description

Draft N/A N/A Initial state; SRD is being authored.

Request for Approval

N/A N/A Waiting for approval.

Pending More Information

N/A Need more information from the SRD submitter. Once information is provided, the SRD can be resubmitted for approval by changing the status to Request for Approval.

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 date

Available to users.

Deployed N/A Yes SRD has been manually taken offline.



Figure 11: Service request definition primary components

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 fieldsThe 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:ServiceRequest

Definition joinform

The SRD form is the primary form used as the interface for capturing and searching for the characteristics that make up the business definition of a Catalog Entry.It is a join form that is made up of a join between the SRD:ServiceRequestDefinition_Base form and the SRD:ServiceRequestDefinition_DispProp form.Join criteria�Instance ID of the Base form and the SRD_InstanceID of the Display Properties form.

SRD:ServiceRequest

Definition_Base form

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

ServiceRequestDefinitionEntitlement

Surveys

Service Level Management

PDT�s

DataMapping

FoundationElements

Audit Logs

Work Info

ServiceRequest

Application Configurations


White Paper

Table 8: SRD:ServiceRequestDefinition_Base form

SRD:ServiceRequest

Definition_DispProp

form

The SRD Display Property form contains the localized strings for the following fields that follow on the SRD.

Join data label Source data Field name Field ID Type

Account Number SRD_Account Number 302793700 CharacterAttachment SRDAttachmentField 302906200 AttachmentBusiness Service SRD_BusinessService 302793400 CharacterCompany SRD_LocationCompany 301453000 CharacterCompany Survey Enabled SurveyEnabled 302844800 CharacterCoordinator Group ServiceRequest

CoordinatorGroup10002506 Character

Create Business Process CreateBusinessProcess 302858800 SelectionCustom Template Custom_Template 302825800 CharacterCustomer First Name RequestedByFirstName 1000000019 CharacterCustomer Last Name RequestedByLastName 1000000018 CharacterEffective End Date EffectiveEndDate 240000014 DateEffective Start Date EffectiveStartDate 240000013 DateExpected Cost SRD_Expected Cost 302783800 CurrencyHot List HotList 302897800 SelectionProcess Template PDT_Name 302876900 CharacterRC Manager Company RequestCatalogManager_

Company301251902 Character

RC Manager Name RequestCatalogManager_FullName

301251901 Character

Request Frequency Request Frequency 302771600 IntegerRequest Type SRD_Request Type 301438012 SelectionSR Needs Approval UseApprovalEngFlag_SRD 302896600 SelectionStatus SRD_Status 7 SelectionStatus Reason Status_Reason 1000000150 SelectionSurvey Configuration SurveySelection 302839500 SelectionSurvey Name SurveyName 302903400 CharacterSurvey Status SurveyStatus 302903500 SelectionSystem Request SystemRequest 302785000 SelectionTurnaround Time SRD_TurnaroundTimeX 302793500 Integer

Table 9: SRD:ServiceRequestDefinition_DispProp form


Category 1 Category1 1000000063 CharacterCategory 2 Category2 1000000064 CharacterCategory 3 Category3 1000000065 CharacterDescription SRD_Description 301244800 Character



Key related components and featuresInformation 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

Instructions SRD_Instructions 302823600 CharacterKeywords SRD_Aliases 302771500 CharacterLevel SRD_Level 302793100 CharacterLocale SRD_Locale 160 CharacterPrice SRD_Price 302793000 CurrencySR Instance ID SRD_InstanceID 302162700 CharacterTitle SRD_Title 301244700 Character

Table 9: SRD:ServiceRequestDefinition_DispProp form (Continued)


NTE:SYS-NT Process Control

Create entry to notify catalog manager

SRD Entry IDSRD Number

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

SRD:CFG DefinitionNumGenerator

Create an entry to get new SRD Number

CTM:People

COM:CompanyCatalog Manager Company

Location CompanyCustomer Company

instanceId

SRS:CFGCustomForm

FK:instanceId=Custom_CFG_Form_InstanceId

CTM:Support Group

Assignee Group(Request Coordinator Group)

SRM:Navigational Category

Navigational Category 1, 2, 3

SYS:Menu Items

SRD_Level

SRDInstanceID

SRM:Request FK:SRDInstanceID=InstanceID

Original Request ID

SRD:AuditLog FK:Original Request ID=Request ID

Catalog ManagerCustomer

InstanceIdPDT_Name

SRM:ProcessDefinitionTemplate

FK:PDT_InstanceID=InstanceIdPDT_Name=PDT_Name

Assoc1InstanceIDAssoc2InstanceID

SRM:Associations

FK:Assoc2InstanceID=InstanceId

FK:InstanceID=Assoc1InstanceID

SurveyInstanceIDSRDInstanceID

SRM:SurveyAssociations

InstanceId

SRM:ConfigSurveyQuestions

FK:SRDInstanceID=SurveyAssocInstanceID

FK:SurveyInstanceID=InstanceId

SRDED instanceId2

SRD:SRDEntitlementDefinition

Entitlement Criteria � SRD_Number,

Nav Cat 1,2,3,Level

ParentInstanceID

SRM:UniqueQuestionList

ParentInstanceID

SRM:SourceToTargetDataAssociationsFK:InstanceID=

ParentInstanceID

FK:InstanceID=ParentInstanceID

associationTypeId'="SVT_SRD_RELATE"instanceId1instanceId2

SLM:Association

FK:InstanceID=instanceId2

InstanceId

SLM:ServiceTarget

FK:instanceId1=InstanceId

SRD:CFG Settings

Get setting for approval

SRDED instanceId2

SRD:SRDED PED Associations

FK:InstanceId=SRDED instanceId2

InstanceIDRequest ID (Field 1 for join form)SRD_Number (auto-generated)SRD_Request_ID (Request ID from base)Navigational Category 1Navigational Category 2Navigational Category 3SRD_LevelCustom_CFG_Form_InstanceIdPDT_InstanceIDPDT_NameSurveyAssocInstanceID

SRD:ServiceRequestDefinition

InstanceIDBusinessServiceInstanceIdSRD_BusinessServiceBusinessProcess_ InstanceIdBusinessProcess_ ReconIdSandbox_DatasetIDCustom_CFG_Form_InstanceId

SRD:ServiceRequestDefinition_base

SRD_StatusSRD_TitleSRD_DescriptionSRD_LocaleSRD_InstanceIDSRD_AliasesTakeSRDOfflineFlagSRD_LevelSRD_InstructionsdeletedSRD_PriceNavigation Tier1Navigation Tier2Navigation Tier3

SRD:ServiceRequestDefinition_DispProp

Join: InstanceID=SRD_InstanceID


White Paper

Navigationalcategories

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

Figure 13: High-level view of navigational categories

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


Navigational Category 1, 2, 3










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.


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.



Figure 15: Entitlement, conceptual view

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.

SRDED instanceId2

SRD:SRDEntitlementDefinition

Entitlement Criteria � SRD_Number,

Nav Cat 1,2,3,Level

SRDED instanceId2

SRD:SRDED PED Associations

FK:InstanceId=SRDED instanceId2









White Paper

Figure 16: Entitlement definition

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

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.

Service Request DefinitionEntitlement Definition

(SRDED)

PeopleEntitlement Definition

(PED)

ARGroups

CTM:PeopleIndividual, Location

SRDefinition

Entitlement Definition

$PED instanceId1$ = 'InstanceId'

SRD:EntitlementDefinition_join

$InstanceId$ = 'SRDED instanceId2'P: SRD:SRDEDAssociation_join

Status PED Advanced Qual Name InstanceId Everyone Entitlement PED ID Entitlement Group IDS: ENT:PeopleEntitlementDefinition

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

Status SRDED instanceId2 Request ID PED instanceId1/SRDED instanceId2

S: SRD:SRDED PED Associations



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

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.

$Permission Group ID$ = 'Permission Group ID'

ENT:SYS Entitlement Group User Join

Remedy Login ID Person ID/Permission Group ID Permission Group ID People Permission Group ID InstanceId

P: ENT:SYS People Entitlement Groups

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


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.

Workinformation

The work information form is used as an activity log. The catalog manager or administrator can provide notes for each SRD. The work information that is tracked as part of the SRD is linked by a foreign key that is stored with each record.

Figure 19: Work Info entity relationships

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/aDescription 1000000000 Character 100Detailed Description 1000000151 Character 0Number of Attachments 1000000365 Integer n/aNumber of URLs 1000002264 Integer n/a

SRD Entry IDSRD Number

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










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.

Request Number 1000000829 Character 15SRD Number 1000000182 Character 45Status 7 Selection n/aTotal Time Spent 1000000731 Integer n/aURL01 1000002261 Character 255URL02 1000002262 Character 255URL03 1000002263 Character 255Work Log Date 1000002134 Date and Time n/aWork Log ID 1 Character 15Work Log Submit Date 1000000157 Date and Time n/aWork Log Submitter 1000000159 Character 254Work Log Type 1000000170 Selection n/aWork Order Number 1000000967 Character 15WorkLog Action Completed

1000002401 Selection n/a

WorkLog Action Status 1000002369 Selection n/a

Table 10: SRD:WorkInfo data fields (Continued)



White Paper

Figure 20: Survey entity relationships

SurveyInstanceIDSRDInstanceID

SRM:SurveyAssociations

InstanceId

SRM:ConfigSurveyQuestions

FK:SRDInstanceID=SurveyAssocInstanceID

FK:SurveyInstanceID=InstanceId










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

Table 12: SRM:ConfigSurveyQuestions form

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.


InstanceID 179 Character 38RequestID 1 Character 15SRDInstanceID 302814500 Character 38SurveyInstanceID 302841800 Character 38


Company 1000000001 Character 254InstanceID 179 Character 38Question Type 300794000 Character 30Question1 260000000 Character 255Question2 260000001 Character 255Question3 260000002 Character 255Question4 260000003 Character 255SRD_ID 302797800 Character 20Survey Name1 302838900 Character 255SurveyLocale 302839000 Character 255SurveyType 302841700 Character 25Topic 300563100 Character 255


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

Table 13: Custom form parts

Custom form part Description

Connection fields and workflow

The connection fields and workflow are the �plumbing� that supports the seamless connection with the BMC SRM Provide Information stage of the request submission process.

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 workflow

On a custom form, custom fields are all the other new fields and workflow added to store, manipulate, and present information to the user. These fields and workflow are additive and are not required to interact at all with the BMC SRM connection and mapped fields of the custom form.

Custom Fields

ConnectionFields

MappedFields

Custom Fields

ConnectionFields

MappedFields



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

Primary Forms and Data FieldsThis 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.

instanceId

SRS:CFGCustomForm

FK:instanceId=Custom_CFG_Form_InstanceId









White Paper

Table 14: SRS:CFGCustomForm form

Data Field Name Field ID Type Description

Location Company 1000000001 Character Tenant companyTemplate 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 FieldsSystem for password reset 302983800 Character Name of System.Type your new password 302984000 Character Enter New Password for

SystemRe-type your new password 302984100 Character Compare value to originally

type passwordConcatenateFields 302984400 Character Field used to combine dataAvailable data fields mapped to service request Mapped to SR field

CategoryTier1 1000000063 Character CategoryTier1CategoryTier2 1000000064 Character CategoryTier2CategoryTier3 1000000065 Character CategoryTier3DateRequired 301429600 Date and

TimeDate Required

Request Type 301438012 Selection Request TypeSCODescription 301417500 Character SCO DescriptionSR_NotesComments 301528400 Character SR_NotesCommentsSRWiz_RequesterMiddleName 301563800 Character SRWiz_RequesterMiddle

NameSRWizRequestedForCompany 301454800 Character SRWizRequestedFor

CompanySRWizRequestedForEmail 301455200 Character SRWizRequestedForEmailSRWizRequestedForFirstName 301455000 Character SRWizRequestedForFirst

NameSRWizRequestedForLastName 301454900 Character SRWizRequestedForLast

Name



SRWizRequestedForPhone 301455100 Character SRWizRequestedForPhoneSRWizRequesterCompany 301442500 Character SRWizRequesterCompanySRWizRequesterEmail 301425700 Character SRWizRequesterEmailSRWizRequesterFirstName 301425500 Character SRWizRequesterFirstNameSRWizRequesterLastName 301425300 Character SRWizRequesterLastNameSRWizRequesterPhone 301425600 Character SRWizRequesterPhoneSR Type Field 1 300070001 Character SR Type Field 1SR Type Field 2 300070002 Character SR Type Field 2SR Type Field 3 300070003 Character SR Type Field 3SR Type Field 4 300070004 Character SR Type Field 4SR Type Field 5 300070005 Character SR Type Field 5SR Type Field 6 300070006 Date and

TimeSR Type Field 6

SR Type Field 7 300070007 Date and Time

SR Type Field 7

SR Type Field 8 300070008 Integer SR Type Field 8SR Type Field 9 300070009 Integer SR Type Field 9Supporting connection fields

Control Buttons

btn_Submit 300978700 Control Submit RequestClose_btn 350100012 Control Close Custom form Dialogz3Btn_SaveAsDraftSRD 302897100 Control Execute Save As Draft

settingsSystem fields

Current user ID for the system

302983900 Character Supported By Workflow

Custom_CFG_form_InstanceID 302825900 Character Supported By WorkflowCustomformName 3000010 Character Supported By WorkflowCustomformServer 3000020 Character Supported By WorkflowExpected Date 302791600 Date and

TimeSupported By Workflow

Expected DateTime 302811200 Date and Time

Supported By Workflow

InstanceID 179 Character Supported By WorkflowLoggedInUserName 301354000 Character Supported By WorkflowRequest Number 1000000829 Character Supported By WorkflowServiceCatalogInstanceID 301303200 Character Supported By WorkflowSR_TurnaroundTimeUnits 302793600 Selection Supported By WorkflowSRD_TurnaroundTimeX 302793500 Integer Supported By WorkflowSRDTitle 301417400 Character Supported By Workflow

Table 15: SRM:CustomformDisplayOnly (Continued)



White Paper

SRInstanceID 301368700 Character Supported By WorkflowSRStatus 302933200 Selection Supported By WorkflowTitleFromSRD 302829600 Character Supported By Workflowz1D HolidayTag 250000054 Character Supported By Workflowz1D WorkdayTag 250000051 Character Supported By Workflowz1D_Action 301311700 Character Supported By Workflowz1D_Char01 301325300 Character Supported By Workflowz1D_CommunicationSource 10001854 Character Supported By Workflowz1D_FullName 301308600 Character Supported By Workflowz1D_Integer 302767400 Integer Supported By Workflowz1D_OperationID 301443200 Character Supported By Workflowz1D_ParentObjectKeyword 300363000 Character Supported By Workflowz1D_RequestedForInstanceID 301465800 Character Supported By Workflowz1D_RequesterInstanceID 301443100 Character Supported By Workflowz1D_TmpInteger1 301638000 Integer Supported By Workflowz1D_WorkInfoDate 10001846 Date and

TimeSupported By Workflow

z1D_WorkInfoDetails 10001826 Character Supported By Workflowz1D_WorkInfoSecureLog 10001828 Selection Supported By Workflowz1D_WorkInfoSummary 10001825 Character Supported By Workflowz1D_WorkInfoType 10001824 Character Supported By Workflowz1D_WorkInfoViewAccess 10001829 Selection Supported By Workflowz2AF_WorkInfoAttachment 301712900 Attachmen

tSupported By Workflow

z2AP_WorkInfoAttachment 10001827 Attachment Pool


z2PH_DebugHolder 300037600 Page Holder


zTmpHeader 301168000 Character Supported By Workflow

Table 15: SRM:CustomformDisplayOnly (Continued)




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

Configurablenotifications

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

Original Request ID

SRD:AuditLog FK:Original Request ID=Request ID









White Paper

Figure 24: Configurable notifications entity relationships

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


Create entry to notify catalog manager










Figure 25: Approvals entity relationships

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.

SRD:CFG Settings

Get setting for approval









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

Service Request Definition

APR:SYS-ApprovalDefinition

Approval Engine

AP:Detail

AP:Signature

1. Set Status = Rquest forApproval

3. Approval engine createsentries in AP:Detail and

AP:Signature forms

2. Check to see if approval ofthis SRD is required. If so,make a call to the Approval

Engine

Submitting a Service Request Definition (SRD) for approval

Criteria forApproval

APR:Approver Lookup(Approval Mappings)

Approvers



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

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 levelmanagement

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

Approval Central

Service Request Definition

Approval Engine

AP:Process Definition

1. SRD is Approved orRejected

2. Approval engine checksrules to see what needs tobe done for Approved or

Rejected items

3. Approval Engine updatesSRD with data based on

Set Fields actions definedin AP:Rules

AP:Rules

Approving a Service Request Definition item using Approval Central


White Paper

Figure 28: Service level management entity relationships

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

associationTypeId'="SVT_SRD_RELATE"instanceId1instanceId2

SLM:Association

FK:InstanceID=instanceId2

InstanceId

SLM:ServiceTarget

FK:instanceId1=InstanceId










! Minutes

! Impact Cost

! Business Entity

! Measurement Criteria Template

For more information about BMC Service Level Management, see theBMC Service Level Management 7.0 User�s Guide and the BMC Service Level Management Architecture white paper. Primary formsThis 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 AtriumCMDB

The service catalog manager, when creating SRDs, can search and associate a business service from the BMC Atrium Configuration Management Database (CMDB) with the SRD. The ability to create a business process record when the SRD becomes deployed is also supported. Both the DatasetID and the Reconciliation Job Name fields must be set in the SRD:Settings form. The Create Business Process flag on the SRD also must be checked to enable this functionality.In addition to creating a business process, a relationship is also created between the business process and the business service.Figure 29 illustrates the relationships that are established with the BMC Atrium CMDB after the SRD is deployed.

Figure 29: Relations between a deployed SRD and the BMC Atrium CMDB

CMDB IntegrationSandbox_DatasetID - the sandbox and RE Job Name come from SRM:CFG RulesReconId comes from Business Service CI entry from BMC.CORE:BMC_BusinessServiceBusiness Process ReconId is generated by SRD

InstanceIDSRD_TitleBusinessServiceInstanceIdSRD_BusinessServiceBusinessProcess _ InstanceIdBusinessProcess _ ReconIdSandbox_DatasetIDReconciliation Job Name


InstanceIdName = (SRD_Title)DatasetIdReconciliationIdentitySourceLocation = "BMC.SRMS"SerialNumber = (SRD InstanceId)Company

BMC.CORE:BMC_BusinessProcess

InstanceIdNameDatasetIdReconciliationIdentity

BMC.CORE:BMC_BusinessService

FK:BusinessProcess_InstanceId

FK:BusinessServiceInstanceId

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

BMC.CORE:BMC_Dependency

InstanceIDBusinessServiceInstanceIdSRD_BusinessServiceBusinessProcess _ InstanceIdBusinessProcess _ ReconIdSandbox_DatasetID


Destination.InstanceId=InstanceId

Source.InstanceId=InstanceId

SRD_Title


Job NameRECommand=Start

RE:Job Operation


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










Process definition template architectureThe 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 Object Template Pool

Application ObjectTemplate

AO: Work OrderName: Issue BadgeID: 123Regid: R324


AO: Change RequestName: Install DesktopID: 175Regid: R214


AO: Work OrderName: Setup OfficeTID: 183Regid: R124


AO: IncidentName: Enable PortsID: 223Regid: R457





















TT Task TemplateAssociationsFlows X TT Task TemplateAssociationsFlows X

Associate Registry Attribute AOI CarryID ID Name Field Question? Predefined Default OverA R214 Contact Name N/A Request For None NoB R215 Location Location Location? None None YesC R216 Priority Priority Priority None Low YesD R457 Contact Name N/A Request For None No

ValuesQuestions


ValuesQuestions

Application Registry

Registry Application AOT AOI Local /ID Object Name Name Remote

R214 Change-NA ChTmplate CHReq LocalR457 Incident IncTmplate Incident RemoteR234 Change-AP ChTmplate CHReq Remote

RegistryID Interface Cmd Sync 1 2

R214 ARS None Poll None NoneR457 DSO DSO Init.Req. X YR234 DSO DSO Subscribe W Q

Parameters






Parameters

Work OrderTemplate

Name: Set Up OfficeID: 183Assign To: Group

IncidentTemplate

Name: Enable PortsID: 223Assign To: Group

Work OrderTemplate

Name: Issue BadgeID: 123Assign To: Group TTTT TT

Change RequestTemplate

Name: Install DesktopID: 175Assign To: Indiv.

TT

Back Office Applications



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

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






























TT Task TemplateAssociationsFlows X TT Task TemplateAssociationsFlows X


ValuesQuestions


ValuesQuestions






Parameters






Parameters

Work OrderTemplate

Name: Set Up OfficeID: 183Assign To: Group

IncidentTemplate

Name: Enable PortsID: 223Assign To: Group

Work OrderTemplate

Name: Issue BadgeID: 123Assign To: Group TTTT TT

Change RequestTemplate

Name: Install DesktopID: 175Assign To: Indiv.

TT

Back Office Applications


AO: Work OrderName: Issue BadgeID: 123Regid: R324 1





AO: Work OrderName: Issue BadgeID: 123Regid: R324 1


AO: IncidentName: Enable PortsID: 223Regid: R214 2





AO: IncidentName: Enable PortsID: 223Regid: R214 2


AO: Work OrderName: Setup OfficeTID: 183Regid: R124 2





AO: Work OrderName: Setup OfficeTID: 183Regid: R124 2


AO: Change RequestName: Install DesktopID: 175Regid: R457 3


AO: Change RequestName: Install DesktopID: 175Regid: R457 3

Process Def.Template

ContainerObject

Process Def.Template

ContainerObject

A

D

B

C

Serv

ice

Req

uest

Man

agem

ent S

yste

m Service RequestDefinition


ServiceRequest



ProcessDefinition


AOT AOTAOT

AutomatedTools

AutomatedTools

AOTAOT

AOTAOT

AOIAOIAOIAOI

AOIAOI



Figure 33: PDT entity relationships

SRD relationship to PDTPDTs 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.

$InstanceId$ = 'PDT_InstanceID'SRM:ProcessDefinitionTemplate

Request Frequency PDT_ID InstanceId CompanyP: SRM:ProcessDefinitionTemplate_Base

PDT_InstanceID PDT_Description NavigationTier1 InstanceId

S: SRM:ProcessDefinitionTemplate_DispProp

PDT_Locale Request Type Status VersionNumber

PDT_Name


White Paper

Figure 34: SRD relationship to PDT

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.

InstanceIdPDT_Name


FK:PDT_InstanceID=InstanceIdPDT_Name=PDT_Name


SRM:Associations


FK:InstanceID=Assoc1InstanceID










Figure 35: AOT entity relationships

Primary forms and data fieldsThis 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.

Instance ID

CAI:AppRegistry

Instance IDAppRegistry Instance IDTemplateName

SRM:AppTemplateBridge

Instance IDAssoc1 Instance IDAssoc2 Instance ID

SRM:Associations

Instance IDPDT_Name


FK:Assoc2 Instance ID=Instance ID

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

InstanceIDPDT_InstanceID


FK:Instance ID=AppRegistry Instance ID

FK:Assoc1 Instance ID=InstanceID

FK:Instance ID=PDT_InstanceID


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

! SRM:ProcessDefinitionTemplate_DispProp contains the localized strings for the fields on the PDT. Table 17: SRM:ProcessDefinitionTemplate_DispProp form

! SRM:AppTemplateBridge contains the records that represent the AOTs. The following table contains a detailed description of the data fields on the form.

Join data label Source Data field name

Field ID Type

Company Company 301453000 CharacterInstanceID InstanceID 179 CharacterPDT_ID PDT_ID 1 CharacterRequest_Frequency Request_Frequency 302771600 CharacterRequest_Type Request_Type 301438012 SelectionStatus Status 7 SelectionVersionNumber VersionNumber 301307300 Character

Join data label Source Data field name

Field ID Type

Category1 NavigationalTier1 1000000063 CharacterPDT_Description PDT_Description 301244800 CharacterPDT_Locale PDT_Locale 160 CharacterPDT_Name PDT_Name 301244700 Character

Table 18: SRM:AppTemplateBridge form


AOTID 1 Character 15AppRegistryInstanceID 301287600 Character 40AppRegistryName 301289000 Character 254Assignee Groups 112 Character 255Company 301453000 Character 60InstanceID 179 Character 40Name 301287500 Character 254Protocol 301405400 Selection n/aServer 301286600 Character 255Status 7 Selection n/aTemplate Name 1000001437 Character 254TemplateInstanceID 301287400 Character 80



Data mapping architectureAfter 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.

TemplateRequestID 301289100 Character 24TemplateSummary 8 Character 254Type 300062100 Character 36URL 302911400 Character 255

Table 18: SRM:AppTemplateBridge form (Continued)



White Paper

Figure 36: Data mapping

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

SRD

PDTPDT

Registry

MasterField List

1TD - 1

1TD - 2

1TD - 3

2TD - 4

3TD - 4

3TD - 5

Target Data

3TD - 6

1TD - 1

1TD - 2

1TD - 3

2TD - 4

3TD - 4

3TD - 5

Target Data

3TD - 6

TD - 1TD - 2TD - 3

TD - 4

TD - 4

TD - 5

TD - 6

TD - 1TD - 2TD - 3

TD - 4

TD - 4

TD - 5

TD - 6

AOT1

AOT2

AOT3

AOT1

AOT2

AOT3

QuestionsLibraryWho Me?

What Time?When, Today?

How Much?Location?Where?

QuestionsLibraryWho Me?

What Time?When, Today?

How Much?Location?Where?

Ignore

IgnoreDefault

Ignore

IgnoreDefault

MappedData

MappedData



Figure 37: SRD to data mapping relationship

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.

ParentInstanceID


ParentInstanceID


ParentInstanceID










White Paper

Figure 38: SRD relationship to data mapping

Target data master listAssociated 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.

ParentInstanceID


ParentInstanceID


ParentInstanceID











Figure 39: Target data master list

AOT target dataOne 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.

z1S_instanceIdApplication IDQuestionDescriptionFieldForAnswerMappedFieldIDPrepopulateModePrepopulateValueTypePrepopulateValuePrepopulateValueLookupKeywordRequiredByAppO-LenCharFlagActionModeExposedToTemplate

SRM:AppTargetData

Instance ID

CAI:AppRegistry

FK:Instance ID=Application ID




SRM:Associations

Instance IDPDT_Name










White Paper

Figure 40: AOT Target data

PDT target data rollupThe 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.


SRM:AppTargetData

Instance ID

CAI:AppRegistry


Instance IDAssoc1 Instance IDAssoc2 Instance IDActionModeDefaultValueExposed

SRM:AppTargetDataAssociations

FK:Assoc2 Instance ID=z1S_instanceId





SRM:Associations

Instance IDPDT_Name











Figure 41: PDT target data rollup

Questions and target data mappingThe 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.


SRM:AppTargetData

Instance ID

CAI:AppRegistry









SRM:Associations

Instance IDPDT_Name


PDT_InstanceIDAOTPDT_AssocInstanceIDTargetDataInstanceIDAOTInstanceID

SRM:AppTargetDataRollup





FK:Instance ID=AOTInstanceID


FK:Instance IDAOTPDT_AssocInstanceID




FK:z1S_instanceId=TargetDataInstanceID


White Paper

Figure 42: Questions and target data mapping

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


SRM:AppTargetData

Instance ID

CAI:AppRegistry









SRM:Associations

Instance IDPDT_Name


PDT_InstanceIDAOTPDT_AssocInstanceIDTargetDataInstanceIDAOTInstanceID

SRM:AppTargetDataRollup



Instance IDParentInstanceIDAOTAssociationInstanceIDAppObjectTemplateInstanceIDTargetDataInstanceIDTDSourceInstanceIDUniqueQuestionInstanceIDMapTargetToDefault Value

SRM:SourceToTargetDataAssociations





FK:Instance ID=AOTAssociationInstanceID

FK:Instance ID=AppObjectTemplateInstanceID

FK:Instance ID=AOTInstanceID


FK:Instance IDAOTPDT_AssocInstanceID


InstanceIDParentInstanceIDDIDInstanceIDOrderRequiredDefault Value


InstanceIDFormNameServerFieldID

SRM:MasterDataMappingList




instanceIdQuestion TextCategoryAnswerFormatAnswerFieldTypeDeveloperName

SRM:QuestionsLibrary

FK:InstanceID=TDSourceInstanceID

FK:InstanceID=UniqueQuestionInstanceID


FK:instanceId=DIDInsatnceID



Supporting consolesThis section describes the consoles.

Application Administration ConsoleThe 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 Configuration

SRS:ServiceRequestHTML

Survey Configuration SRM:ConfigSurveyQuestions

Application Configuration

Define Application Field SYS:Form Field Selection

Define Application Object Template


Define Application Target Data SRM:AppTargetData

Define Question Library SRM:QuestionsLibrary

Approval Approval Mappings APR:Approver Lookup

Entitlement Entitlement Group Management

ENT:Entitlement Groups

Entitlement Management ENT:Entitlement Console

On Behalf of Management OBO:On Behalf Of Console

Navigational Categories

Navigational Categories SRM:Navigational Category

Request Entry Management

Browse for Service Details SRM:CategoryDetails/View: CategoryDetails

Default Console Preferences SRS:DefaultPreferences

Service Request Definition Image Management

SRM:CategoryDetails/View: ImageMapping

Service Request Image Configuration

SRS:ServiceRequestImages

Service Request Search Exclusion String

SRS:ServiceRequestQueryExclusions

Service Level Management

Service Target Defaults INT:SLMSRS:ConfigServiceTarget:Defaults

Work Order Rules WOI:CFG Rules

Work Order Template WOI:Template


White Paper

Service Catalog Manager ConsoleThe 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

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.

1

2

3



Figure 44: Catalog manager console—searching and viewing PDTs

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

1

2

3

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

White Paper

Figure 45: Service request 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 modelThe 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.

Serv

ice

Req

uest

Man

agem

ent S

yste

m Service RequestDefinition


ServiceRequest



ProcessDefinition

AOT AOTAOT

AutomatedTools

AutomatedTools

AOTAOT

AOTAOT

AOIAOIAOIAOI

AOIAOI

ExecutionExecution



Figure 46: The RPD model

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

SR life cycleWhen 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.

Definition� Service Request Definition� Process Definition Templates

� PDT�s� AOT�s

� Data Mapping� Questions� Target Data

Runtime Execution� Service Request� Provide Information / Data

� Questions� Responses

� Process Definition Instance� PDI�s� AOI�s

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


White Paper

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.

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.

Table 20: SR life cycle (Continued)

Status or Status Reason Description



Figure 47: Legal state transition support for the service request

Table 21 defines all the possible state transitions.State transitions

Draft

In Review

Waiting Approval

Pending

Rejected

Planning

In Progress

CompletedCancelled

Closed

Need more info

Need more info

Cancelled by SR Coordinator

SR doesn�t need approvalSR needs

approval

User cancels request

Automatically closed

Re-open

Table 21: State transitions

Dra

ft

In Revi

ew

Pend

ing

Wai

ting

App

rova

l

Plan

ning

In

Prog

ress

Com

plet

ed

Reje

cted

Canc

elle

d

Clos

ed

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 NoWaiting Approval No No Yes2 - Yes No No Yes Yes No Planning No No Yes2 No - Yes Yes3 No Yes No In Progress No No Yes2 No No - Yes No Yes No


White Paper

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

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 -

Table 21: State transitions (Continued)

Dra

ft

In Revi

ew

Pend

ing

Wai

ting

App

rova

l

Plan

ning

In

Prog

ress

Com

plet

ed

Reje

cted

Canc

elle

d

Clos

edInstanceIdRequest NumberRequest IDSRDInstanceID

SRM:Request

InstanceID


FK:SRDInstanceID=InstanceID

Service Request InstanceID

SRM:Process

FK:Service Request InstanceID=InstanceId


SRM:Associations



SRInstanceID

SRM:AppInstanceBridgeFK:SRInstanceID=

InstanceId

CTM:Region

Region/Site Group/Site

SIT:Site Group

SIT:SiteCTM:People

COM:Company

CTM:Support Group


NavigationalCategory 1, 2, 3

Request CoordinatorRequested ByRequested For

SRInstanceID

SRM:WorkInfo

FK:SRInstanceID=InstanceId

Originating_Request_InstanceID

SRM:Survey

FK:Originating_Request_InstanceID=InstanceId

WOI:Work Order

HPD:Help Desk

CHG:Infrastructure Change


ApplicationInstanceID

SLM:EventSchedule

SLA_Reference InstanceID

SLM:Measurement

FK:ApplicationInstanceID=InstanceId

FK:SLA_Reference InstanceID=InstanceId

SRInstanceID

Custom Forms


SRInstanceID

SRM:QuestionResponseFK:SRInstanceID=

InstanceId

Original Request ID

SRM:SR_AuditLog

FK:Original Request Id=Request ID

APR:SYS-Approval Definition

Get approval definition

SRM:CFG Rules

Get auto-close, survey, etc.


Create entry to notify

Custom Form

QuestionResponses

Service LevelManagement

NavigationalCategories

FoundationData References

Configuration Data

Auditing Data

Work Info

FulfillmentApplications

ApplicationObject

Instances

Service RequestDefinition Process

DefinitionInstancesSurveys

ServiceRequest



Primary form and data fieldsThis 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/aActual Duration 300798302 Integer n/aActual Start Date 1000000348 Date and Time n/aAnticipated Approval Date 1000001214 Date and Time n/aAnticipated Completion Date 1000001182 Date and Time n/aAnticipated Duration 300798301 Integer n/aAnticipated Start Date 300354902 Date and Time n/aAOI Entry ID 301720300 Character 15Approval Date 303018300 Date and Time n/aApproval Phase Name 1000003143 Character 60Approval Process Name 301236000 Character 255Approval Status 1000003264 Selection n/aApproved Date 1000001184 Date and Time n/aAssigned Support Company 1000000251 Character 254Assigned Support Organization 1000000014 Character 60Assignee 10010413 Character 254Assignee Groups 112 Character 255Category 1 1000000063 Character 60Category 2 1000000064 Character 60Category 3 1000000065 Character 60CI_Name 200000020 Character 254Closed Date 302904200 Date and Time n/aCompany 1000000082 Character 254Company Group Name 301438710 Character 254Completion Date 1000002195 Date and Time n/aConcate_ Status_StatusReason 302830300 Character 255Cost Center 1000000188 Character 25Customer Company 1000003299 Character 254Customer Company Group Name 301438720 Character 254Customer Cost Center 300890300 Character 25Customer Department 1000003301 Character 60Customer First Name 1000003297 Character 30Customer Full Name 1000000025 Character 128Customer Internet E-mail 1000003302 Character 255


White Paper

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

Table 22: SRM:Request (Continued)




Region 200000012 Character 60RejectApprovalStatusReason 1000003219 Character 30Request Manager 1000000218 Character 69Request Manager Login 1000000408 Character 254Request Number 1000000829 Character 15Request Type 301438012 Selection n/aRequired Date 1000001181 Date and Time n/aService Location Address 1000000038 Character 255Service Type 1000000099 Selection n/aServiceRequestApproval 301248900 Selection n/aSite 260000001 Character 60Site City 1000000004 Character 60Site Country 1000000002 Character 60Site Group 200000007 Character 60SiteID 1000000074 Character 15Site State Province 1000000003 Character 60Site Street 1000000037 Character 90Site Zip or Postal Code 1000000039 Character 15SLA Responded 301788100 Selection n/aSLM Status 1000003009 Selection n/aSolutionRequestID 301710700 Character 38SR Type Field 1 300070001 Character 0SR Type Field 2 300070002 Character 80SR Type Field 3 300070003 Character 80SR Type Field 4 300070004 Character 254SR Type Field 5 300070005 Character 254SR Type Field 6 300070006 Date and Time n/aSR Type Field 7 300070007 Date and Time n/aSR Type Field 8 300070008 Integer n/aSR Type Field 9 300070009 Integer n/aSR_Actual_TurnaroundTime 303044300 Integer n/aSR_Expected_TurnaroundTime 303051400 Integer n/aSRD_Level 302793100 Character 100SRD_Number 302849400 Character 15SRD_TurnaroundTimeUnits 302793600 Selection n/aSRD_TurnaroundTimeX 302793500 Integer n/aSRDInstanceID 301303200 Character 38Status 7 Selection n/a




White Paper

Key related componentsFigure 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

Status_Reason 1000000150 Selection n/aSubmitter GroupID 1000001255 Character 50SuccInstanceNumCol 1000005875 Column n/aSummary 301244700 Character 255SurveyAssocInstanceID 302883500 Character 38TitleFromSRD 302829600 Character 255



InstanceIdRequest NumberRequest IDSRDInstanceID

SRM:Request

InstanceID




SRM:Process



SRM:Associations



SRInstanceID


InstanceId

CTM:Region


SIT:Site Group

SIT:SiteCTM:People

COM:Company

CTM:Support Group




SRInstanceID

SRM:WorkInfo


Originating_Request_InstanceID

SRM:Survey

FK:Originating_Request_InstanceID=InstanceId

WOI:Work Order

HPD:Help Desk




SLM:EventSchedule


SLM:Measurement



SRInstanceID

Custom FormsFK:SRInstanceID=

InstanceId

SRInstanceID


InstanceId

Original Request ID

SRM:SR_AuditLog


APR:SYS-Approval Definition

Get approval definition

SRM:CFG Rules

Get auto-close, survey, etc.


Create entry to notify



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

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.


Assignee Groups 112 Character 255Case Description 230000008 Character 128Comment 1 260000020 Character 0Comment 2 260000021 Character 0Comment 3 260000022 Character 0Comment 4 260000023 Character 0Company 1000000001 Character 254InstanceID 179 Character 38Last_Surveyed_Date 301694700 Date n/aPersonID 1000001021 Character 15Question 1 260000000 Character 255Question 1 Rating 260000010 Integer n/aQuestion 2 260000001 Character 255Question 2 Rating 260000011 Integer n/aQuestion 3 260000002 Character 255Question 3 Rating 260000012 Integer n/aQuestion 4 260000003 Character 255Question 4 Rating 260000013 Integer n/aRequest Type* 301438012 Selection n/aStatus* 7 Selection n/aSurveyID 1 Character 15Survey Name1 302838900 Character 255Survey_e-Mail_Address 301693800 Character 50


White Paper

Figure 50: Custom forms

Questions andresponses

When completing a service request, the defined questions established as part of the SRD definition appear in the Provide Information tab. For each question, there are multiple response field formats. Based on the definition in the questions library, the appropriate format is displayed.

Figure 51: Questions and responses entity relationships

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.


SRM:Request

SRInstanceID

Custom Forms



SRM:Request

SRInstanceID


InstanceId



Figure 52: Storage of SR questions and responses during runtime

Navigationalcategories

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

SRM:QuestionList_Join

SRM:DataInputDefinition SRM:UniqueQuestionListDIDInstanceID

ParentInstance ID

SRM:QuestionResponse SRM:RequestSR InstanceId = InstanceID

Definition Level

Transaction Level


SRS:Service Request Console

'ParentInstanceID' = $DVF_SelectedSRDInstanceId$

SRS:SRC:SubmitQuestionResponseSRInstanceID = z1D_SRInstanceId

SRS:SRC:SaveAsDraftSRS:SRC:SaveServiceRequest

z1D_SRInstanceId


White Paper

Figure 53: Navigational categories

Foundationdata

references

The service request leverages the ITSM Foundation components to provide information that is critical to the routing and resolution of issues by the back-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.


SRM:Request





Figure 54: Foundation data references

Configurationforms

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

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


SRM:Request

CTM:Region


SIT:Site Group

SIT:SiteCTM:People

COM:Company

CTM:Support Group



White Paper

Figure 55: Audit logging

Workinformation

(activity log)

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

Figure 56: Work information (activity log)


SRM:Request

Original Request ID

SRM:SR_AuditLog



SRM:Request

SRInstanceID

SRM:WorkInfo




Servicerequest

definition

The service request is initiated from the selected SRD, and the SRD instance ID is used as the primary foreign key on the SR to maintain the relationship to the originating SRD.

Figure 57: Service request definition

Processcomponents

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


SRM:Request

InstanceID




White Paper

Figure 58: Process components entity relationships

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.


SRM:Request


SRM:Process



SRM:Associations



SRInstanceID


InstanceId



Figure 59: Initiating the process definition template

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.

SRM:Request

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

2. On Modifyz1D_Command = �CREATE�

SRD:ServiceRequestTemplateBuilder

SRD:ProcessDefinitionTemplate

SRD:Process SRM:AppInstanceBridge

3. Create PDI 4. Create AOIs,

5. On Modify 'zTmpCommand' = "CREATEFLOW"

SRM:AppInstanceFlow

6. Create flow


White Paper

Figure 60: AO functional processes

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

Fulfillmentapplications

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

Application Object Instance

(SRM:AppInstanceBridge)

SRM:QUTBaseJoinAppRegJoin

SRM:AppTargetData

CAI:AppRegistry

SRM:TDAOTAssocTD_Join


SRM:AppTargetData

SRM:SourceTDDataMapping_Join


SRM:SourceAppTargetData_Join


1. Pulls the default from target data

3. Pulls the data from the TD mapping on SRD

2. Pulls the default from theassociation between AOT and TD



Figure 61: Fulfillment entity relationships

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 levelmanagement

The service targets for a given service request are established during the definition stage of the SRD. During the execution stage, the SLAs are managed by the SLM:EventSchedule and the SLM:Measurement forms.


SRM:Request

WOI:Work Order

HPD:Help Desk




White Paper

Figure 62: Service level management entity relationships

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


SRM:Request


SLM:EventSchedule


SLM:Measurement





Service Request consoleThe 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.

2

1

3


White Paper

The following table summarizes the purpose and supporting structures of each tab view.Table 24: Tab view purpose and supporting structures

Data visualization fieldAlthough 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.

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

fields5 Display details of catalog entry HTML View Field (1)6 Display summary of SR prior to being

submittedHTML View Field (2)

7 Review and manage submitted requests

Table and HTML view field (3)



Figure 64: DVF plugin architecture

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

Client

DVF

AR System Mid-Tier

Plug-in Container

Controller

SRMS DVF Plug-in

Service Layer

Services Views

TopCategoriesBrowserService ServiceCategoriesBrowserService ListServiceRequestsService ApplicationImageService

TopCategoriesView ServicCategoriesView ServiceRequestListView NoDataFoundView

Data-Mapper Layer

Repositories

TopCategoriesRepository CategoriesRepository ServiceRequestsRepository FavoriteServiceRequestsRepository ApplicationImageRepository

Resource Loaders

ClasspathResourceLoader PluginDefinitionResourceLoader ClasspathTemplateLoader

AR SystemApplication Server

Data


White Paper

Business Manager ConsoleThe 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

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.

31

2

4



Service Request Coordinator ConsoleThe 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

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.

1

2

3


White Paper

InterfacesThere 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

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.

Form Interface form Web service Web service operation

SRM:Request SRM:RequestInterface

SRM_RequestInterface_WS

Request_Modify_ServiceRequest_Query_ServiceRequest_QueryList_Service

SRM:RequestInterface_Create

SRM_RequestInterface_Create_WS

Request_Submit_Service



Back-office fulfillment system integrationsThe 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

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.


CAI:Events CAI:EventsInterface CAI:EventsInterface_WS

Events_Modify_ServiceEvents_Query_ServiceEvents_QueryList_Service

CAI:EventsInterface_Create

CAI:EventsInterface_Create_WS

Events_Submit_Service

CAI:Event Params CAI:EventParamsInterface

CAI:EventParamsInterface_WS

EventParams_Modify_ServiceEventParams_Query_ServiceEventParams_QueryList_Service

CAI:EventParamsInterface_Create

CAI:EventParamsInterface_Create_WS

EventParams_Submit_Service

Back-office fulfillment system integrations 91BMC Software, Inc.

White Paper

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

Back-office templatesAll 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).

Interface Form

External Application

Creates Interface record using webservice Processes

incoming parameters

SRM

General Flow

Data flow direction

Main System Form



Figure 68: Populating field 1 where an overlap exists

Incident Management integrationTwo 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).These operations can be invoked by accessing these interface forms directly. Access to these forms also support interactions using web services. Figure 69 shows how an external application integrates with Incident Management.

Field 1:Field 2:Field 3:Field 4:Field 5:TempId:

Incident FormField 1:Field 2:Field 3:Field 4:Field 5:TempId:

Incident FormInterfaceField 1:Field 2:Field 3:Field A:Field B:TempId:

InterfaceField 1:Field 2:Field 3:Field A:Field B:TempId:

Field 1:Field 2:Field 3:Field 4:Field X:TempId:

Incident TemplateField 1:Field 2:Field 3:Field 4:Field X:TempId:

Incident Template


Incident TemplateField 1:Field 2:Field 3:Field 4:Field X:TempId:

Incident Template


Incident Template AField 1:Field 2:Field 3:Field 4:Field X:TempId:

Incident Template A


IncidentAOI

[New Employee]

Title

Description

SLA

Approval

ServiceRequest

New Emp.

Title

Description

SLA

Approval

ServiceRequest

New Emp.

CommandAutomation

Interface

HelloWorld

See You

Later

123

123 123

HelloWorldLater

HelloWorldLater


White Paper

Figure 69: Integrating an external application with Incident Management

InterfacesThe following table describes the Incident Management integration interfaces.Table 27: Incident Management integration interfaces

Change Management integrationTwo 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).These operations can be invoked by accessing these interface forms directly. Access to these forms also supports interactions using web services.

HPD:IncidentInterface(Staging form) HPD:Help Desk

External application

Creates staging record using Help Desk Submit web

serviceProcesses incoming

parameters

Creates Help Desk record and Work Log

record

ITSM

Help desk ticket submit

Data flow direction

HPD:Work Log

Association forms

Creates an association with a CI if a CI name

is specified


HPD:HelpDesk HPD:IncidentInterface

HPD_IncidentInterface_WS

HelpDesk_Modify_ServiceHelpDesk_Query_ServiceHelpDesk_QueryList_Service

HPD:IncidentInterface_Create

HPD_IncidentInterface_Create_WS

HelpDesk_Submit_Service



InterfacesThe following table describes the Change Management integration interfaces.

Work Order Management integrationTwo 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.


CHG:InfrastructureChange

CHG:ChangeInterface

CHG:ChangeInterface _WS

Change_Modify_ServiceChange_Query_ServiceChange_QueryList_Service

CHG:ChangeInterface_Create

CHG:ChangeInterface _Create_WS

Change_Submit_Service


White Paper

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

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.

WOI:WorkOrder(Work Order Primary Form)

WOI:WorkOrderInterface_Create(Work Order Form)

WOI:WorkOrderInterface(Work Order Form)

WOI:Template(Work Order Form)

Create

Service Request[Integration]

QueryModify

Query List

CAI Interface System

The CAI Interface creates an �AppInstanceBridge� record where the workflow is kicked off. From here the �AppInstanceBridge� pushes data to the �WOI:WorkOrderInterfaceCreate� 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



Table 28: SRM request management permission model

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

Types of BMC SRusers

BMC SRM roles

Unknow

n us

er

Regist

ered

User

SR use

r

Busine

ssma

nage

r

Entitl

emen

t m

anag

er

BMC SR

Mcat

alog

manage

r

BMC SR

M ad

mini

stra

tor

ConsolesRequest Entry Console Yes Yes Yes Yes Yes Yes YesBusiness Manager Console No No No Yes No No NoSR Coordinator Console No No Yes No No No NoCatalog Manager Console No No No No No Yes NoApp. Admin Console No No No No Yes2 No YesFunctionsCreate or Modify SR for Self Yes Yes Yes Yes Yes Yes YesReopen Requests Yes Yes Yes Yes Yes Yes YesClose Requests Yes Yes Yes Yes Yes Yes YesView broadcasts Yes Yes Yes Yes Yes Yes YesSurveys Yes Yes Yes Yes Yes Yes YesAdd more information Yes Yes Yes Yes Yes Yes YesCancel Requests Yes Yes Yes Yes Yes Yes YesApprove Requests No No Yes Yes Yes Yes YesCreate or Modify SR for Others No No Yes Yes No No NoCancel Others Requests No No Yes Yes No No NoDefine Entitlement Rules No No No No Yes Yes1 YesReports No No Yes Yes No Yes NoBMC SRM Admin. and Config. Access

No No No No No No Yes

Create or Modify SRDs No No No No No Yes NoSystem Level Trouble Shooting No No Yes No No No Yes

Service Request Management permission model 97BMC Software, Inc.

White Paper

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



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 instance

AOI Instantiation of an AOT during its execution phase.

Application object template

AOT Interface to a back-end application that is needed to fulfill a service request.

Back-office fulfillment application

BOFA Any application used by a service organization that is used to fulfill a service request.

Command automation interface

CAI Subsystem designed to support bi-directional communication between applications and other systems.

People entitlement definition

PED Defines who has access to deployed SRD�s in the catalog.

Process definition instance

PDI Instantiation of a PDT during its execution phase.

Process definition template

PDT Defines the process that supports the related Service Request Definition.

Request, process, data mapping

RPD The primary components required to define a 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 definition

SRD The definition of a service that is available for users to request through the service catalog.

Service request definition entitlement definition

SRDED Definition of what SRD�s are accessible.

Service request management

SRM The process of managing information technology services to meet the customer�s requirements.

Target data TD Data that is mapped to fields on a registered interface form.

Licensing model 99BMC Software, Inc.

White Paper

100 Terminology BMC Software, Inc.

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

*86808*

White Paper BMC Service Request Management 2 0 Architecture

Documents

pdt instanceid instanceid pdt name pdt name

instance id application id

poll dso init

instance id pdt instanceid

measurement sla reference instanceid

effective date range

install desktop id

remote r214 change