You are on page 1of 177

BMC Remedy IT Service Management 7.

Architecture

October 2006

Copyright 19912006 BMC Software, Inc. All rights reserved.


BMC, the BMC logo, all other BMC product or service names, BMC Software, the BMC Software logos, and all other
BMC Software product or service names, are registered trademarks or trademarks of BMC Software, Inc. All other
trademarks belong to their respective companies.
BMC Software, Inc., considers information included in this documentation to be proprietary and confidential. Your use of
this information is subject to the terms and conditions of the applicable end user license agreement or nondisclosure
agreement for the product and the proprietary and restricted rights notices included in this documentation.
Restricted Rights Legend
U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE
COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by
the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013,
DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time.
Contractor/Manufacturer is BMC Software, Inc., 2101 CityWest Blvd., Houston, TX 77042-2827, USA. Any contract
notices should be sent to this address.
Contacting Us
If you need technical support for this product, contact Customer Support by email at support@remedy.com. If you have
comments or suggestions about this documentation, contact Information Development by email at
doc_feedback@bmc.com.
This edition applies to version 7.0 of the licensed program.

BMC Software, Inc.

www.bmc.com

Contents
Introduction ............................................................................................................. 9
ITSM suite description........................................................................................ 9
Features and benefits....................................................................................... 10
ITSM suite architecture.................................................................................... 11
Service Desk process....................................................................................... 11
Change management process .......................................................................... 12
Asset and Configuration Management process ............................................... 13
Conceptual architecture................................................................................... 14
Architecture philosophy .................................................................................. 15
Common application models........................................................................... 17
Foundation architecture ....................................................................................... 27
Reference data ................................................................................................... 27
Infrastructure model ........................................................................................ 27
Foundation components.................................................................................... 27
Company ......................................................................................................... 28
Location .......................................................................................................... 28
Organization.................................................................................................... 30
People.............................................................................................................. 31
Support groups ................................................................................................ 33
Categorization ................................................................................................. 34
Notification Engine ......................................................................................... 36
Assignment...................................................................................................... 37
BMC Remedy Change Management architecture ............................................. 41
Process flows ...................................................................................................... 41
Initiate and record ........................................................................................... 42
Review and authorize...................................................................................... 43
Plan and schedule............................................................................................ 43
Implement ....................................................................................................... 44
Complete and close ......................................................................................... 44
ERDs................................................................................................................... 44
Associations .................................................................................................... 44
Linking ............................................................................................................ 46
Lookup ............................................................................................................ 47

Associated information ERD .......................................................................... 48


Linked data...................................................................................................... 49
Data lookup ..................................................................................................... 51
Comprehensive ERD....................................................................................... 53
Main forms......................................................................................................... 54
Change calendar ................................................................................................ 54
Architectural overview.................................................................................... 55
Executive dashboard ......................................................................................... 59
Architectural overview.................................................................................... 60
Subsystem integration....................................................................................... 61
Requester Console........................................................................................... 61
Cost Management............................................................................................ 61
SLM ................................................................................................................ 61
BMC Atrium CMDB....................................................................................... 62
Interfaces............................................................................................................ 63
Interface forms ................................................................................................ 63
Web services ................................................................................................... 63
Permission model............................................................................................... 66
BMC Remedy Asset Management architecture ................................................. 67
Process flows ...................................................................................................... 68
User interface..................................................................................................... 68
Asset Management and the BMC Atrium CMDB.......................................... 69
Reconciliation ID ............................................................................................ 69
Sandbox........................................................................................................... 70
ERD .................................................................................................................... 70
Asset Management full ERD .......................................................................... 71
Asset Management system forms ..................................................................... 73
Software license management .......................................................................... 74
AST:LicenseMgmtIncludeClass ..................................................................... 76
AST:ConfigLicenseMgmt............................................................................... 76
AST:LicenseMgmtEngine............................................................................... 78
AST:LicenseMgmtException.......................................................................... 78
AST:ManageLicenseMgmtException............................................................. 78

Procurement ...................................................................................................... 79
Contracts ......................................................................................................... 80
Warranty contracts .......................................................................................... 81
Support contracts............................................................................................. 82
Lease contracts ................................................................................................ 83
Maintenance contracts..................................................................................... 84
Software contracts........................................................................................... 85
Standard configurations ................................................................................... 85
Outages............................................................................................................... 86
Schedules ............................................................................................................ 88
Subsystem integration ..................................................................................... 88
Interfaces............................................................................................................ 90
BMC Atrium CMDB API ............................................................................... 90
Interface Forms ............................................................................................... 90
Web Services................................................................................................... 90
Permission model............................................................................................... 91
BMC Atrium CMDB permission model ......................................................... 91
Asset Management roles ................................................................................. 91
Mapping of Asset Management roles to BMC Atrium CMDB roles.............. 91
Row-level security .......................................................................................... 92
Mapping of Asset Management roles to Asset Management functions .......... 92
BMC Remedy Service Desk architecture ............................................................ 94
High-level process flow ..................................................................................... 94
BMC Remedy Incident Management .............................................................. 95
Process flows................................................................................................... 96
Design overview.............................................................................................. 97
Main forms ...................................................................................................... 97
Subsystem integration ..................................................................................... 99
ERD............................................................................................................... 105
Interfaces ....................................................................................................... 106
Licensing model ............................................................................................ 107
Permission model .......................................................................................... 108
BMC Remedy Problem Management............................................................ 108
Problem investigation.................................................................................... 108
Known error management............................................................................. 109
Solutions database......................................................................................... 109

Process flows................................................................................................. 109


Main forms .................................................................................................... 110
ERD............................................................................................................... 112
Interfaces ....................................................................................................... 116
ITSM 7.0 subsystems........................................................................................... 117
Command Automation Interface ................................................................... 117
Overview ....................................................................................................... 117
ERD............................................................................................................... 118
Interfaces ....................................................................................................... 126
Permission model .......................................................................................... 127
Contract Management .................................................................................... 127
ERD............................................................................................................... 128
Interfaces ....................................................................................................... 128
Permission model .......................................................................................... 128
Costing Management ...................................................................................... 129
ERD............................................................................................................... 131
Licensing model ............................................................................................ 131
Permission model .......................................................................................... 131
Definitive Software Library ........................................................................... 132
Architectural overview.................................................................................. 133
Primary components of the DSL................................................................... 133
ERDs ............................................................................................................. 134
Interfaces ....................................................................................................... 137
Web services ................................................................................................. 138
Permission model .......................................................................................... 140
Requester Console and SRMS framework.................................................... 140
Requester Console......................................................................................... 141
SRMS framework.......................................................................................... 144
Task Management System.............................................................................. 157
Architectural overview.................................................................................. 158
Instantiation................................................................................................... 159
Association model......................................................................................... 162
Dependency model: flow mechanism ........................................................... 165
Sequencing (Basic) mode.............................................................................. 167
Data exchange model: variable pool ............................................................. 169
Complete example......................................................................................... 172
ERD............................................................................................................... 173

Interfaces ....................................................................................................... 174


Web services ................................................................................................. 174
Permission model .......................................................................................... 175

Introduction
This document provides the technical details around the applications and
subsystems that comprise the BMC Remedy IT Service Management (ITSM) suite.
It covers architectural details, data models, and key workflow structures to provide
an understanding of how the ITSM applications suite works as individual products,
as well as integrated in a suite.
The applications, subsystems, and foundation data covered in this document are:
Applications

BMC Remedy Service Desk


BMC Remedy Incident Management
BMC Remedy Problem Management

BMC Remedy Change Management

BMC Remedy Asset Management

Subsystems

Command Automation Interface

Contract Management

Definitive Software Library (DSL)

Costing Management

Requester Console and SRMS framework

Task Management System (TMS)

Foundation data

Company

People

Location

Categorizations

ITSM suite description


The BMC Remedy IT Service Management product portfolio streamlines the
processes around IT service desk, asset management, change management, and
service level management, and also enables you to link your business services and
IT infrastructure to help you manage the impact of technology changes on business
and business changes on technologyin real time and into the future. In addition,
you can define and measure service levels, understand and optimize the user
experience, balance current and future infrastructure investments, and view

potential impact on the business using a real-time service model. All of this helps
you manage what matters to deliver Business Service Management (BSM).

Features and benefits


With the BMC Remedy IT Service Management product portfolio, you can:
Align business and IT

Translate business objectives into IT services by facilitating a dialog to define


what the business needs, and get agreement on the specific services and service
levels that IT will deliver to address those needs.

Manage assets to optimize business value by making sure your assets are
supporting business-critical IT services, according to agreed-upon service
levels.

Increase the responsiveness of IT organizations to the business by providing


dynamic service views and service models showing how a single event can
impact crucial business services.

Based on business needs and priorities, proactively manage service levels for
mission critical services delivered by IT operations through real-time
management of service level agreements.

Integrate real-time IT and business impact information, including route cause


data, into incident tickets for improved user value.

Provide visibility into your infrastructure

Rapidly discover what physical and logical elements (servers, routers, switches,
databases, gateways, web servers, application servers) and dependencies that
comprise an application infrastructure.

Quickly discover which underlying IT resources are causing business service


slow downs or outages.

Manage IT and service information at an enterprise scale with secure


distributed roles and responsibilities.

Allow for the identification of chronic bottlenecks and service-impacting


problems and workflow processes.

Provide real-time event consolidation, processing, and integration with existing


tools and help desks, and notification for consolidated control across the entire
IT computing enterprise.

Enhance customer satisfaction

10

Facilitate the creation and maintenance of a service model by not only


discovering the components and relationships of enterprise application
infrastructures, but also by watching for changes and proposing updates to the
service models accordingly.

Enable staff with interactive notification, escalation, and resolution capabilities


using remote devices to make sure IT and business issues are addressed quickly
and efficiently.

Show how the IT assets and staff resources perform against contracted service
levels.

Define, measure, and manage the quality of service experienced by a group of


users.

ITSM suite architecture


The ITSM suite is designed with an overall architecture in mind. Each application
in the suite must work as a standalone application, and also must integrate
seamlessly and provide additional value when other products in the suite are
installed.
The diagram that follows describes that typical data flow supported by the ITSM
suite. Users initiate the process using the Requester Console. The Requester
Console lets users pick what they want to ask for without understanding if the
fulfillment mechanism for that request is an incident or a change request.
Depending on what a user asks for, the Requester Console routes the request to the
incident management process or the change management process.

Service Desk process


The Service Desk process includes the process flows required to resolve outages
and keep the customer working at the appropriate level, as defined by the
companies Service Level Agreements (SLAs). Two processes support the Service
Desk: Incident Management and Problem Management.
When starting at the Requester Console, the incident management process is one
branch the flow can go through. Incident Management 7.0 is compliant with the
ITIL definition of being a process whose main purpose is to get the user back up
and running. To support that concept there are several interactions that help achieve
that goal.
If the Service Level Management (SLM) application is installed, Service Level
Agreements (SLAs) and Operational Level Agreements (OLAs) can get attached to
the incident, based on who is making the request, the urgency of the issue, and the
business services that are being affected by the issue.
Incident Management uses the knowledge database to provide the technician
working the issues with information about like issues that might help resolve the
problem as quickly as possible.
Incident Management also comes with, and tightly integrates with the BMC
Atrium CMDB, to provide a repository for the configuration items (CIs) in the
organization. CIs can be related to the incident to indicate where the issue is

11

happening. You can use the BMC Service Impact manager to look at possible root
causes, and to determine the level of response and resolution required.
While the incident management process is designed to resolve outages and get the
customer working as quickly as possible; for some issues, a root cause might not be
determined. For those issues, a problem investigation can be initiated. The problem
investigation provides the constructs for determining the root cause, tracking it as a
known error, and making determinations if the error is something that should be
corrected in the environment using a change request, or if a work-around can be
provided that can be used instead.
Incident Management and Problem Management can also be processes initiated
outside of a requester. For example, Incident Management can be integrated with
the BMC Service Impact Manager or the BMC Event Manager to automatically
generate incidents based on events in the infrastructure. For an integration with
Service Impact Manager, the event can be correlated to the business services that
are being affected, and generate incidents with the appropriate CIs related for
resolution.
Problem Management can also be initiated using a proactive problem management
approach, where the environment is viewed for trends by reporting. Problem
investigations are then generated.

Change management process


The change management process manages changes in the infrastructure. They can
be large scale changes such as upgrading a set of vital systems, or smaller changes
such as setting up new employees.
The change management process is designed to be open to handle the many
different types of processes that an organization might have.
The process includes three layers of approvals that use the BMC Remedy Action
Request System (AR System) Approval Server as the engine to manage approvals.
The change management process also integrates with the time management
functionality in the underlying AR System platform to view conflicts between a
scheduled change and other changes in the organization.
Integrations that the change management process uses include:

BMC Atrium CMDB, to handle targeting of CIs for changes, and


understanding their relationships with other CIs and business services.

12

BMC Service Impact Manager, to provide an insight into the risk of making a
change, and the systems and business processes that will be affected.

BMC Atrium CMDB, to integrate the change management process with


Configuration Management for pushing changes to the infrastructure.

Asset and Configuration Management process


The combination of the BMC Atrium CMDB and the Asset Management
application provides the model for doing Asset and Configuration Management
within it the ITSM suite.
The configuration management process provides the model for maintaining the
Configuration Items (CIs) that are important to the business, and controlling the
updates that have occurred to those CIs in the Change Management process.
Asset Management processes provide mechanisms to manage schedules, contracts,
procurement, depreciation, and chargebacks.
Primary integrations with Asset Management are at the BMC Atrium CMDB level.
BMC Discovery solutions populate the BMC Atrium CMDB with information
about the CIs in the infrastructure, and their relationships. The BMC Atrium
CMDB also provides a federated integration model to link CIs to other applications,
such as the BMC Service Impact Manager and other third-party products.
Diagram of the ITSM suite architecture

13

Primary ITSM
Apps

General Flow
End
Users

Supporting
Applications

Request
Console

Change
Management

Service Level
Management

Incident
Management

Asset
Management

DSL

Problem
Management

Knowledge

(Known Error)

BMC Atrium
CMDB

Problem
Management
(Investigation)

Conceptual architecture
The overall architecture of the ITSM suite can be separated into three layers:

User subsystem

Back-office primary systems

Supporting subsystems

The top layer consists of systems that provide the interface to users, such as the
Requester Console. The Requester Console is designed as a subsystem for users to
create requests that interface with a back-office system, such as Incident
Management or Change Management
The back-office primary systems are the main applications: Incident Management,
Change Management, Problem Management, and Asset Management. These
systems contain logic and user interfaces specific to those application areas.

14

The final layer consists of supporting subsystems. This common set of subsystems
supports the back-office systems. Subsystems contain generic logic that is specific
to a subsystems function, without embedding functionality from other applications
that use its services.

Back Office
Primary Systems

End User
Subsystem

Examples of subsystems include Task Management System, Costing Management,


Contract Management, and so on.

Request
Console
SRMS Framework
CAI
ITSM Foundation

Change
Management

Asset
Management

Incident
Management

Problem
Management

BMC Atrium CMDB

BMC Atrium CMDB

BMC Atrium CMDB

BMC Atrium CMDB

Task Management

DSL

Task Management

Cost Subsystem

DSL

Cost Subsystem

Cost Subsystem

ITSM Foundation

Cost Subsystem

ITSM Foundation

ITSM Foundation

Knowledge

SLM

SLM

ITSM Foundation

Supporting
Subsystems

SLM

Task
Management
Subsystem

Location
Organization
People
Support Groups
Categorizations
Notification Engine

Cost
Management
Subsystem

Definitive
Software Library
[DSL]

CAI

ITSM
Foundation

ITSM Foundation

Common Automation
Interaction
[CAI]

ITSM Foundation

ITSM Foundation

Architecture philosophy
Definitions of architectural concepts are key to a successful enterprise application
development. They provide the guiding principals for how applications are
designed and developed. The ITSM 7.0 suite of applications follows a strict set of
principals based on a component development model.
The following types of architectural structures are used in the ITSM 7.0 suite:

Systems

Subsystems

15

Subsystem candidates

Shared components

Foundation elements

Systems

An application or system provides a higher level theme of functionality that is


functional by itself, and can in part be made up of and supported by several
subsystems. Examples include Change Management, Asset Management, Incident
Management, and so on.
Subsystems

Subsystems are self-contained, modular, and extendable systems of functionality,


with well-defined and documented interfaces designed to support higher level
systems. Examples include Task Management System, Approval Server,
Assignment Engine, and so on.
Subsystem candidates

A subsystem in development is architected and designed to be modular and support


the characteristics of being a subsystem but without currently meeting the required
rules of being a subsystem.
The required rules for a subsystem include fully developed interfaces encapsulation
as a deployable application, and so on. A subsystem candidate is the first stage of
becoming a formal subsystem to be leveraged in a current release. An example is
the Service Request Management System (SRMS) framework.
Shared components

Segments of workflow and forms can be easily leveraged to perform a common


operation. A shared component serves as a template for a foundation of
functionality that will serve as a child to a parent system or subsystem. Examples
include Yes and No prompt dialog boxes, message confirmation dialog boxes, the
advanced qualification bar, and so on.
Foundation elements

The foundation is comprised of infrastructure workflow and reference data. These


are they primary components that are shared across the applications in the ITSM
suite. These are analogues the key structures that make up a building. You need to
have a strong foundation to build on. The foundational elements in the ITSM suite
make up the key structural and data elements that are needed to build strong
enterprise applications.
Reference data
Shared required data structures can be leveraged across different systems.
Examples include categorization, company data, multi-tenancy model, and ITSM
system forms.

16

Infrastructure model
The infrastructure model can be thought of as the plumbing structure of how things
fit together. Examples include the Notification Engine, association model,
Deployable Application structure, tenancy model, and so on.

Common application models


Deployable application structure

The AR System platform provides the structural component used in the ITSM 7.0
applications to define the deployable application architectural structure.
Deployable applications provide functions that support a component architectural
model. These functions are covered in following sections:

Licensing enforcement

Encapsulation of permissions

Definition of entry points

Ability to import and export as a whole component

Deployable applications are used to wrap each of the different systems and
subsystems that are provided in ITSM 7.0 applications.
Deployable applications contain the following systems and subsystems:
Systems

Incident Management (licensed)

Problem Management (licensed)

Change Management (licensed)

Asset Management (licensed)

Subsystems

Costing Management (licensed)

Task Management System

Definitive Software Library (DSL)

Change Management Dashboards (licensed)

Application Administration Console

Reporting Console

Requester Console

Helper

Foundation elements

17

Foundation sub-elements, such as message boxes and so on

Site

Company

Product catalog

Licensing model

The licensing model has been extended in ITSM 7.0 to add application-level
licenses and user-level licenses. All licenses in the ITSM 7.0 suite of applications
are enabled by the deployable application model described previously.
Application-level licenses
Application licenses provide access to the forms that make up an application. If an
application-level license is not applied to the AR System server, the forms are not
accessible using user clients. This makes user licensing a requirement for importing
data into the applications.
Application-level licenses are enabled for the main applications provided in the
ITSM suite. In addition, application-level licenses are required for the Change
Management Dashboard and the Costing Management subsystems.
User-level licenses
ITSM 7.0 supports Fixed and Floating licensing models for users of the licensed
applications. The ITSM suite supports a model that requires a license (in addition to
any required permissions) to modify records in the application. There are no license
requirements for submitting data into the system; however, there are permission
requirements.
Fixed licensing is a named license that gets assigned to a particular user.
Floating licensing is a pool of licenses that is assigned to a set of users. Users take
up tokens when they log in to an application, and hold on to those tokens while they
are working with the forms in that application. Tokens are released when a user
logs off or a system timeout is reached.
Permission model

The ITSM suite has built a specific philosophy into how the model was designed
for the ITSM suite.
Main concepts defined include:

Abstraction using roles

Common roles
Viewer
User

18

Master
Administrator

Predefined permission groups to support the roles

User access using support groups

Functional roles

Abstractions using roles


Roles are provided by the AR System deployable application model. Roles are
defined within the context of a deployable application. Forms and client-side
workflow in a deployable application have roles defined for permissions instead of
physical permission groups that users are assigned to.
Permissions are enabled for a user by mapping the physical permission groups that
are provided with the applications to the roles that the permission groups should
belong to. By doing this the underlying systems and subsystems can change and
control their permission models without affecting how other applications integrate
with them. This also allows other applications outside of the ITSM suite to
integrate with ITSM systems and subsystems. Customers can also build their own
sets of permissions groups to map into the systems and subsystems.
Common roles
To simplify and provide commonality amongst the applications, each system and
subsystem provides a common set of roles. The system or subsystem can extend
these roles for other specific purposes as needed.
The common roles are:

ViewerProvides the ability to view data in a system or subsystem, but not to


modify data.

UserProvides the ability to modify data, based on support group access.

MasterProvides the ability to modify any record.

AdministratorProvides the ability to configure the system or subsystem.

Predefined permission groups


To support this model, the applications provide predefined explicit permission
groups that map to roles for each of the systems and subsystems.
Also, as shipped, these permission groups are also mapped to the appropriate roles
that are needed from the underlying subsystems. For example, all roles that require
costing data access are mapped to the Financial User role. This predefined
configuration makes it simpler to configure permissions in the application, while
still providing the underlying control.
To enable an easy mapping mechanism, the AR System computed group is used.
Computed groups let you define which groups make up the definition of a group.

19

For example, the following computed group is used to define including all users for
each application in the Cost User role.

User access using support groups


Support groups play a primary role in the permission model for ITSM 7.0. If a user
is a member of a user role, the definition of what records they can modify is based
on if that record has been assigned to one of their support groups. For example, if
users are in the Incident User role and are members of the Hardware support group,
they can only modify incidents that are assigned to the Hardware support group.
They can view other incidents, but they will not be able to modify those incidents.
Functional roles
Functional roles are not permission groups, but are enforced by workflow. For
example, the Manager or Approver role within a support group provides additional
privileges within the application functions. Based on your support group, you can
have different functional roles. For example, in the Hardware support group,
someone can be defined as a manager, but in the Software support group that
person might just be a member.
Multi-tenancy model

Multi-tenancy defines who has access to what data on a row-level basis. For
example, in a service provider environment a single application might be used by
multiple companies, with the data for each company hidden from other companies
using that application.

20

In ITSM 7.0, multi-tenancy is defined using companies. Companies are defined as


operating companies, and users are associated to these operating companies to
define their access rights. A user is associated to a company through the People
form, shown here:

A user can manage multiple companies by adding more companies to the Access
Restrictions list. If a user needs to manage all companies, access can be set to
Unrestricted.
Implementation of multi-tenancy
The services provided by the AR System platform are primary to the
implementation of multi-tenancy. AR System enables you to control access to data
based on permission groups, and determine if those permission groups have access
to individual rows of data. This implementation uses a special set of fields that hold
the list of permission groups that have access to a row. The ITSM suite uses field
ID 112 to enable this feature, although other field IDs are available on the
AR System server and are used by the BMC Atrium CMDB.
This special field 112 is populated on main application forms based on the
companies that are picked to access that record. For example, when you select the
contact and classification companies on the Incident form, workflow updates field
112 values with the group IDs that have been assigned to those companies. For
child records, such as the tasks or costs associated to an incident, the tenancy
information is passed down from the parent.

21

After field 112 is populated, any query to AR System displays only rows of data
that a user has permissions to, based on their permissions, and the permissions in
field 112.
Integration model

One of the main architectural requirements for the ITSM suite is that all systems
and subsystems must provide defined interfaces for integration purposes. These
interfaces abstract the applications that integrate with the systems and subsystems
from the inner workings and from differences in versions.
The common model for interface forms is to use display-only forms to manage the
creation of records and relationships, and to use join forms to manage queries and
modify actions.
BMC strongly recommends that all integrations to Incident Management, Problem
Management, Change Management, Task Management System, and Costing
Management go through the provided interface forms. This will abstract any future
integration from underlying changes to those systems and subsystems.
In addition to the interface forms, web services are provided for most of the
applications. The web services interfaces are a layer on top of the interface forms,
and provide basic create, modify, and query capability to the applications and
subsystems.
For more information about using interface forms and web services, see BMC
Remedy IT Service Management 7.0 Integrations white paper.
Console structures

Consoles are the main user interface to the ITSM 7.0 applications. Two types of
consoles are provided: application-specific consoles that provide application
specific functionality, and common consoles that are used across applications.
Each ITSM application has a console that is focused on the support technician and
a console for the manager. The main difference between these role-based consoles
is the layout and the addition of high-level overviews for managers using of graphs
and charts.
The common consoles include an overview console that combines assigned work
from all applications into one view, and a requester console that is focused on the
users.
Application consoles
Each application console has two views. One focused on the support technician,
and one on the manager. In addition, the Change Management console also
provides the ability to change the support console to focus the work on tasks or
change requests.

22

Overview Console
The overview console provides a view of work assigned across multiple
applications. For example, if users wants to see all incidents, problems, and tasks
assigned to them, they can view them in the overview console.
This implementation uses an ARDBC AR System plug-in to provide a consolidated
view of all assigned work from data sources in multiple applications without using
replication of data or complex SQL views that bypass APIs.
The plug-in architecture is data-driven. Configuration forms define how the plug-in
is set, including which forms to query, which fields to map to the table field, and a
ARDBC form that performs the query.
ARDBC plug-in data setup:

SHR:ARDBCForms

SHR:ARDBC_OverviewConsoleTemplate

SHR:ARDBCFields

Ticket types:

Change

Incident

Problem Investigation

Known Error

Knowledge

CI Unavailability

Purchase Requisition

23

ARDBC plug-in initialization process


ARDBC plug-in is loaded by
the AR System server. This
triggers the ARDBC
initialization functions to run.

ARDBC plug-in queries


SHR:ARDBCForms to get a list of
forms available for use with this plugin, and caches this information.

ARDBC plug-in queries


SHR:ARDBCnumLookup form to get status
mapping between ConsolidatedStatus on
Vendor form and individual forms.

For each form, ARDBC plug-in queries


SHR:ARDBCCFields form to get a list of
fields to retrieve from each form, and the
mapping of those fields to the Vendor
form. This information is also cached.

24

Overview console
(contains table pointing to
Vendor form)
1. Query vendor form to
populate a table on the
console

6. Results are displayed in


the table

Vendor form
(based on
SHR:ARDBCForm)

5. ARDBC plug-in
consolidates results lists
and returns vales to
Vendor form

2. Querying vendor form


triggers ARDBC plug-in

ARDBC plug-in

3. ARDBC plug-in uses cached


information on forms to
consolidate and field mappings
from these forms to the Vendor
form
ARDBC plug-in also constructs a
qualification for each form to
query, based on field mapping
configuration information

4. ARDBC plug-in queries


forms and retrieves results

HPD:Helpdesk
CHG:Infrastructure Change
TMS:Task

Relationship Model

All ITSM 7.0 applications use the same basic structure for relationships between
each application. The structure is based on each application having a relationship
table that shows information in the context of that application while looking out to
the other applications it is integrating with. When a relationship is created between
two applications, two relationship records are created, one in each of the
applications relationship tables, showing the context from that application to the
other application.

25

Incident

HPD:Associations

Target

Target Request

Work Info model


Work logs are components used to track work history. They replace the work diary fields
that were used in previous versions of the ITSM applications.

Each work entry is stored as a separate record in an AR System form. This


approach allows for easier reporting and searching of the Work Info entries
associated with any particular record.
Each Work Info entry can contain up to five different attachments. The attachments
can be associated with the work notes, which results in the attachments being tied
to the record. This provides context to the attachments, and makes it easier to find
them. It also allows for unlimited attachments to be associated to any particular
record.
The work log system also allows for locking records, making records public or
hidden, and categorizing the records.
On a per-application basis, each application uses a separate work log form, but uses
the same structure and workflow around the form. This offloads the processing of
Work Info records to forms that are specific to each application.

26

Foundation architecture
The ITSM Foundation contains data structures and services that are common to all
applications in the ITSM suite.
The Foundation consists of two different concepts: reference data and the
infrastructure model. Think of the foundation as the architecture of a building. The
infrastructure model is analogous to the pipes and electrical wiring, while the
reference data is analogous to the things flowing through the pipes and wires, such
as water and electricity.
Consider the following definitions and examples of foundation components in the context of
how the ITSM applications are built.

Reference data
Data structures and subsystems are shared by many different systems. This data is
central to the running of the application. Examples include People, Companies,
Categories, and so on.

Infrastructure model
Think of the infrastructure model as the plumbing structure, as how things fit
together. Examples include the Notification Engine, association model, Deployable
Application structure, tenancy model, and so on.

Foundation components
The ITSM foundation provides a repository for the following data structures used
by each ITSM application:

Company (tenancy definition and external company definition)

Organization

Location

People

Support groups

Categorization

27

Company
Company is a primary data structure in the ITSM foundation. This structure has the
following two main purposes:
Tenancy definition

Tenancy refers to how data and rules are partitioned within the ITSM applications.
For example, a company might have two different business units that use the
Incident Management application. Each business unit has its own definitions of
data, categorizations, assignment rules and approval rules, and wants to make sure
that this data is not intermixed.
Tenancy allows you to define the partitions between the two business units and
enforce the data level permissions around who can access what data. In this
example, a company would be created for each business unit to define the desired
partitioning of rules and data.
So, a primary function of the company data structure in the ITSM Foundation is to
define those tenants to be used by the ITSM applications. This function of company
is used to define both how the application will partition the data, and the rules for
the application, based on different distinct users of the application.
Business units are one example of partitioning. If you need to partition the data and
the rules of the applications, based on individual business units, then different
companies would be defined for each business unit.
External company definition

You can also use the company definition to define other types of companies that are
used in the application, such as manufacturers, suppliers, and so on, as defined and
used in the Asset Management application.

Location
The location structure within the ITSM applications has a four-tired data model,
where the second and third tires can be optional (the fourth tier, however, is
required). In effect, the data model can be two, three, or four tiers. The Company
field makes up the first tier, Region is the second tier, and Site Group is the third
tier, and Site is the forth tier (where Sites are physical locations with mailing
addresses such as buildings). It is important to note that when creating the location
structures, the regions and site groups will be used to group sites within a company.
Therefore, it is important to have a list of the sites within a company, and then
determine if regions and site groups will be required to arrange the sites in an
organized manner that can be used for reporting purposes.

The Company field and Site field are required on all ticket forms.

28

Sites identify unique physical locations and are associated with one or more
companies.

Workflow can be defined to any level of the Location structure.

ERD
SIT:Site Alias
*
SIT:Site Group Logical Assoc

SIT:Site
*

111
1

SIT:Site Company Association


*

SIT:Site Zone (Deprecated)

*
*

*
COM:Company

1
1
1

CTM:Region

*
SIT:Site Group

29

Organization
Organization describes the role the company component plays in the foundation.
ERD
COM:Company Alias

COM:Company
*

1
1
1

CTM:Region

SIT:Site Group

CTM:People Organization

CTM:Support Group Shift


*

CTM:Support Group

CTM:Support Group Alias


1 1
1

1
*

CTM:Support Group Assignments

CTM:Support Group On
-Call
*
CFG:Approver Lookup

SIT:Site Alias
*
1

SIT:Site Group Logical Assoc


*

SIT:Site Zone (Deprecated)

30

11

SIT:Site

SIT:Site Company Association


*

N
1

COM:Company

COM:Company Alias
N

Company Alias
Company ID
Primary Alias

Company
Company ID
Company Type

1
N

Company
Region
Site Group
Site Group Type

Company
Region

Company
Organizarion
Department

Support Group Shift Name


Support Group ID

CTM: Support Group Alias


N

CTM:Support Group
1

CTM:Support Group
Assignments

CTM:People
Organization

SIT:Site Group

CTM:Region

CTM:Support Group Shift

Company
Support Organization
Support Group
Support Group ID
Support Group Role

Support Group Alias


Support Group ID
Primary Alias
1

CTM:Support Group On-Call

< Business Holidays Tag >


< Business Workdays Tag >

Default Assignment Group ID


Support Group ID

Support Group ID
On-Call Paging Type
Pager Service Provider

CFG:Approver Lookup
SIT:Site Alias

Pager E-mail
Remedy Login ID
Business Holidays Tag
Business Workdays Tag

Approver Login ID
Approval Type
Approval For

N
Site Alias
Site ID
Primary Alias

Pager Phone Number (comprised of):


CC Pager
Area Pager
Local Pager
PIN Pager

SIT:Site
Site
Site ID (system generated)

SIT:Site Group Logical


Assoc
N
Company
Site Group
Site Group Type ("Logical")
Site ID

SIT:Site Zone (ITSP 4.0)


DEPRECATED IN 7.0

Address Details (comprised of):


Street
Country
State/Province
City
Zip/Potal Code
Time Zone

SIT:Site Company
Association
Company
Region
Site Group
Site ID
N

Site Zone
Site ID

People
The People structure within the ITSM applications includes several forms that are
primarily accessed through the CTM:People form. The main form (or parent form),
People, is used to store an individuals contact information, their organization, and
location structures information.

31

ERD
Support Group Functional Roles
- for Support Staff only
- e.g. Change Manager, Support Group
Manager

Company

Region

Organization

Site Group

Department

Attributes
- General Information: Name, VIP
- IT/Skills, Access IDs, Travel
Profiles

Support Organization

Support Group

Financials

Site

- Cost centers (multiples)


- Hourly rate, Accounting code

- A person belongs to a Company and location


- A Support Staff belongs to a Support Group

CI Associations

Permission Groups

- associate to CIs with type: uses,


manages, supports, owns

- for Support Staff only


- allows users access to various
modules

Approval Mapping
- for Support Staff only
- Approval mapping for Change and
User Change Management

Login and Licensing


Information
- stores Login ID and password
- Fixed/Floating/Read license

Notification Preference
- for Support Staff only
- System pre-defined and Userdefined notification preference
based on events

*
Application Permissions

CTM:People
1

*
1

Data Access

*
*

CTM:People Worklog

*
CTM:Support Group Association

*
AST:AssetPeople

*
FIN:CostCenterAssociation

CTM:People Permission Groups

*
CTM:SupportGroup

1
FIN:ConfigCostCentersRepository

Combination of Support Group and Person ID

CTM:SupportGroupFunctionalRole

32

CMDB
Classes

*
User

NTE:CFG-NotificationEvents

Support groups
Support groups play an important role in the ITSM 7.0 application infrastructure.
They are used to define groupings of back-office staff, based on their skills.
Support groups are also used as the initial assignment for a incident, problem, or
change request.

The Support structure can differ from the organization structure.

A support staff member can belong to many support groups.

Vendor support groups can be defined to support external assignment of tickets.

The Support Group role must be specified for information only; there is no
associated workflow.

ERD

From a data model standpoint, the Support Group model is based on the
COM:Company form to hold the support company data, and the
CTM:SupportGroup form to hold the definition of the support group. The
relationships are defined using query menus on the CTM:SupportGroup form. The
Organization value is an attribute on the CTM:SupportGroup form. The menu that
displays the organizational values performs a query against the CTM:Support
Group form to display the available organizations.

Support company

Organization
Support group

33

Support Group ERD


COM:Company

*
1

CTM:Support Group Shift


*

CTM:Support Group

CTM:Support Group Alias


11
1

1
CTM:Support Group Assignments

CTM:Support Group On
-Call
*
CFG:Approver Lookup

CTM:SupportGroup form

Categorization
The categorization structure in ITSM 7.0 is primary to many different functions.
Categorization structures are broken into two distinct components: operational
categorization and product categorization.

34

Operational c ategorization
The operational categorization structure is a three-tier structure defined for
categorization of what work is being done for a particular incident, problem, known
error, change request, or task.
This structure is also used to qualify reporting in the system, qualify how groups
and support staff get assigned, and routing of approvals.
Product categorization
ERD

Product categorization
PCT:Product Catalog

PCT:ProductAlias
1

1
*
*

*
PCT:ProductCompanyAssociation

PCT:Product ModelVersion
/

1
*
PCT:ProductModelVersionPatch

Operational categorization
CFG:Service Catalog

CFG:Service Catalog Association


1

35

CFG:Service Catalog

Categorization ID
Categorization Tier 1
Categorization Tier 2
Categorization Tier 3
Description
Status

CFG:Service Catalog Assoc


1

Categorization ID
Company
Status

Notification Engine
The Notification Engine provides a back-end workflow model for defining which
notifications should be sent, based on different events in the application.
Support staff use the NTE:CFG-NotificationPreferences form to define which
notifications they want to receive. This is exposed on the People form. Included
predefined notifications can be turned on or off in the user interface.
Design

The following diagram describes the flow of the Notification Engine. The
Notification Engine is built using AR System workflow.
Calling applications pass information into the NTE:SYS:NT Process Control form,
indicating the application, who the notification should go to, and information about
the parent record. The workflow process determines if the notification is for a
group or an individual.
Individual processing gets the users notification preferences, ticket information, a
message from the message catalog, and then send the notification.
Group processing expands the group list to individuals, and then runs the same
individual process as described previously. The key difference is that the expansion
is pushed asynchronously to not have a performance affect on the calling
application, and is sent using escalation processing.

36

Process flow

Assignment
The assignment architecture for the ITSM suite is based on a two-phase concept.
The first phase is assignment of the support group; the second phase is assigning
the support technician using load balancing technology built into the Assignment
Engine.
Design

Phase 1: Support groups


The support group assignment phase is done using AR System workflow on backend tables.
The workflow looks into the CFG:Assignment form to determine the group to
assign, using four different inputs:

Organization

Location

Operational categorization

Product categorization

37

The CFG:Assignemnt form also defines the events in which the assignment should
occur. These events are based on the calling applications assignment needs. For
example, the Change Management application requires assignment for the change
assignee and the change manager.
Assignment rules are partitioned based on the tenancy that has been defined. Each
operating company can have its own set of assignment rules.

Phase 2: Individual Assignment


Individual assignment is done in phase 2, using the Assignment Engine.
Assignment rules are provided to support Number of Tickets Assigned, Round
Robin and Capacity process rules.

Round Robin assigns the record to the next person in line.

38

Number of Tickets Assigned rules assigns the record based on the person who
has the lowest number of records assigned.

Capacity uses a formula of the number of tickets assigned and a capacity factor
to determine total capacity, and assigns the record to the user with the lowest
capacity rating.

Assignment process definition:

The following qualification is used to find the set of people to apply load balancing
rules on:
($Assigned Group ID$ = 'Support Group ID') AND ('Profile
Status' = "Enabled") AND ('Assignment Availability' = "Yes")
AND ('Assignment Availability 2' = "Yes")

This query looks at the CTM:Ppl Search-SupportGrpAssoc form to find the


appropriate list of people based on the above qualification.

39

ERD

Request Form

Phase 2
Phase 1

Assignment Engine
CFG:Assignment

There are two phases in the assignment process. Group assignment is handled
within the application using CFG forms; individual assignment uses the
Assignment Engine.
Group assignment workflow:

Workflow referencing the CFG:Assignment form.

CFG:Assignment has four main areas:


EventType of assignment this assignment record is created for.
AssignmentSupport group that this assignment record would assign the
ticket.
CriteriaCriteria matching the tickets to find the assignment records.
SystemIdentifies if this assignment record is enabled for such systems.

40

On ticket submission and modification, workflow executes to reference the


CFG:Assignment form to find the support group to be assigned, based on
information on the ticket.

Individual assignment:

Before individual routing occurs through the Assignment Engine, a support


group must already be assigned.

The Assignment Engine routes tickets to individuals within the support group
using process rules of Round Robin, Number of Tickets, or Capacity.

Predefined rules and process are included with the product and are not intended
for user configuration (that is, it is a customization activity for professional
services, application administrators, or Assignment Engine administrators).

Each application is preconfigured for the Assignment Engine, using Round


Robin and the following systems rule form:
Incident ManagementHPD:CFG Rules (Configure Incident Rules)
Change ManagementCHG:CFG Rules (Configure Change Rules)
Problem Management, Knowledge, Known ErrorPBM:CFG Rules
(Configure Problem Rules)
Task Management System subsystemTMS:AssignmentConfiguration

On ticket submission or modification, workflow executes to use the Assignment


Engine to perform individual assignment routing, based on the process configured
in the systems respective rule forms.

BMC Remedy Change Management architecture


Change
Management
BMC Atrium CMDB
Task Management
DSL
Cost Subsystem

The Change Management application is designed to establish a standardized change


process to allow IT organizations to make quick decisions on risk, and assess the
impact of changes made to the production environment. The Change Management
features introduce efficiency and increase productivity by minimizing error-prone
processes and providing visibility to key performance indicators (KPIs). Features
also include metrics to determine if established service level agreements (SLAs) are
being met.

ITSM Foundation
SLM

Process flows
Information Technology Infrastructure Library (ITIL) is the foundation for
achieving the goals of the Change Management application. The following process
flow diagram illustrates the union between the ITIL process and Change
Management functionality.

41

C h a n g e M a n a g e m e n t P ro c e s s
e
g
n
a
h
C

r
e
t
s
e
u
q
e
R

e
g
n
a
h
C

r
e
t
n
e
m
e
l
p
m
I

e
e
n
g
i
s
s
A
e
g
n
a
h
C

r
e
t
t
a
M
t
c
e
j
b
u
S
(

1
C hang e
In itiatio n a n d
R ec o rd in g

4
Change
Im p lem e n ta tio n

3
Change
P la n n in g an d
S c h e d u lin g

)
t
r
e
p
x
E

2
R e vie w a n d
A u th o riz e

5
C hang e
C o m p letio n an d
C lo su re

r
e
g
a
n
a
M
e
g
n
a
h
C
e
g
n
a
h
C

r
e
v
o
r
p
p
A

/
t
r
o
p
p
u
S
e
c
i
v
r
e
S
r
e
h
t
O

s
e
s
s
e
c
o
r
P
y
r
e
v
i
l
e
D

P ro b lem
M anagem ent

In c id e n t
M anagem ent

R e q u es t
M anagem ent

C o n fig u ra tio n M a n a g e m e n t

,I

The Change Management process has five primary stages:

Initiate and record

Review and authorize

Plan and schedule

Implement

Complete and close

Each stage can consist of sub-processes to support putting the change on hold or
getting approval to move to the next stage. These sub-processes can be configured
in Change Management to be applicable at each of the primary stages. The
following sections give a brief description of each of the primary stages and the
features that support each stage. See the BMC Remedy IT Service Management 7.0
Configuration Guide for more information about configuring the system and the
BMC Remedy IT Service Management 7.0 Change Management Users Guide for
additional details about features that support each stage of the Change Management
process.

Initiate and record


This is the initial stage of the change management process and focuses on recording
the purpose of the change request, and on obtaining additional required information
needed to classify and route the request.

42

The primary sources of change requests are:

Problem Management, including the known error feature of Problem


Management

Incident Management

Service Request Management

The key features available in Change Management designed to facilitate this stage
of the process include:

Requester console interface

Auto assignment at the group and individual level

Support for multi-tier classification (product and operational catalogs)

Review and authorize


Once the initial request has been submitted, the next logical stage is review and
authorize. The purpose of this stage is for the change manager to assess the change
request, provide any additional information to add more context, and if required
initiate the corresponding approval process. This stage acts as the initial filter to
determine if the change request should continue to the next stage in the process.
The features in Change Management designed to facilitate this stage of the process
include:

Manager console

Risk assessment

Support for relating CIs from BMC Atrium CMDB

Integration to BMC Remedy Approval Server

Request acknowledgement flag

Plan and schedule


Once the change request has been approved for work to begin, the next stage is to
plan resources and schedules to ensure minimal impact to the production
environment. Once the planning and scheduling are complete, the change request is
subject to another approval process.
The features available in Change Management designed to facilitate this stage of
the process include:

Change calendar

Costing (budgeted)

Scheduling

Integration with Approval Server

43

Change templates

Integration to Task Management System


Task templates
Task viewer

Implement
This stage consists of executing against the plan and getting the work done.
The features available in Change Management designed to facilitate this stage of
the process include:

Support console

Task viewer

Costing (actual)

Work info

Complete and close


This is the final stage of a change request and indicates either that the change
request has been completed successfully or that is was canceled. All of the actual
data elements (time, cost, and so on) are rolled up and recorded.

ERDs
Many pieces of information support the change management process. This section
identifies the primary entities that are related to Change Management. First, some
common terms are defined to help classify how information is related to a change
request. You can relate data to a change request in three ways: association, linking,
and lookup.

Associations
Data that is associated is supported by a table that maintains a subset of information
for each record being associated to the change request. This information can come
from a variety of sources and is typically managed in other systems or subsystems.
This information can also be related to more than one change request. For example,
configuration items (CIs) are maintained and managed in the BMC Atrium CMDB.
When CIs are associated to a change request, a subset of information is stored as a
record in an association table and is kept in sync with the original record.
The subset of data typically includes a unique reference to the original record, a
brief description, and the status or equivalent representation of the condition of the
related data item. Again, the characteristic of an association table is that it is a
generic table that can contain related information from a variety of sources. The
following illustration provides an example of how information from three sources

44

(PBM:Problem Investigation, CFG:Broadcast, and TMS:Task forms) can be


represented in an association table.

Change Record
CID: 23

Assocation Table
ASID CID Description Status Other Data
T653 23 Task 12
WIP
X
B21 23 Broadcast 1 Active
Y
B83 23 Broadcast 2 Active
Z
P242 23 Problem A
Open
A

PBM:Prob. Inv.
PID: P242

CFG:Broadcast
BID: B83
BID: B21

TMS: Task
TID: T653
The association table is generally exposed using a table field on the request form.
The following illustration shows the association table in the Relationships tab of the
Change form.

45

Linking
Data that is linked uses foreign keys to establish a relationship to the parent
record. The change request acts as the parent record for most of the information that
is linked to it. This means that the unique change request ID or GUID is stored on
the related records. This is effective when the related data is normalized and
supports a parent child relationship.
Note: A GUID is a globally unique identifier. GUIDs are automatically generated
by the AR System server.
The following diagram illustrates how records in the
CHG:ChangeRequest_AuditLogSystem, CFG:Reminders, and CHG:WorkLog
forms are linked to the Change record by storing the unique change ID of 23 on
each of the related records in the corresponding forms.

Change Record
CID: 23

CHG:CR Audit
AID: 523

Fkey: 23

CFG:Reminders

AID: 284

Fkey: 23

Fkey: 23

RID: 295

Fkey: 23

RID: 841

CHG:WorkLog
WID: 523

Fkey: 23

WID: 284

Fkey: 23

In one case, the change request is the child record of the parent record. In this case,
the unique request ID would be stored as a data item on the corresponding change
request, as shown in the following illustration.

SRM:Request
RID: R46

Change Record
CID: 23

Fkey: R46

The difference between this way of relating information and association is that
there is no additional database table and the table field will contain only

46

information from one source. Despite this difference, a set of linked data will also
be represented in a table field on the Change form, as shown in the following
example.

Lookup
Data that is looked up is pulled into the record by storing a local copy of the
information that is being looked up on the record. In general, this data is not kept in
sync with the original source. However, integrity checks might be performed to
make sure that the data stored on the record is still a legitimate reference. For
example, when categorization information is looked up and stored on the change
request, if the original record is modified such that the categorization information
stored on the change request form is no longer valid, the following error message
appears if you attempt to update this change request:
The operational categorization information is invalid for
the specified company, <company name>. Use the menus to
select this information.

The following diagram illustrates information being looked up from the Categories
table and being stored on the Change record in fields Tier1, Tier2, and Tier3.

47

Change Record
CID: 23

Tier 1: Hardware
Tier 2: Desktop
Tier 3: Disk

Categories
CATID Tier 1
Tier 2
Tier 3
635 Hardware Desktop
Disk
243 Hardware Laptop Memory
902 Hardware Server CPU Card

Associated information ERD


The following items can be related to change requests by way of associations:
Incident Management items

Problem Management items


Investigation records
Known errors
Knowledge entries

Asset Management items


Configuration items
Outages

Other change requests

Definitive Software Library (DSL) items

Software library item

Tasks
Task
Task Group

LDAP
User instance
Group instance

48

Cost information

The following ER diagram illustrates how these primary data elements can be
related to the change request by way of the association forms (shaded).
ERD for CHG:Infrastructure Change - Associations

Incident Management
HPD:Help Desk

Problem Management
PBM:Problem
Investigation

LDAP
PBM:Known Error
TMS:LDAPUser

PBM:Knowledge
Database

TMS:LDAPGroup

Asset Management
AST:Configuration
PDL:Software
LibraryItem
CHG:Associations

AST: CI
Unavailability

CHG:Infrastructure
Change
AST:*

FIN:Costs

FIN:Association

CHG:Infrastructure
Change

TMS:Associations

TMS:Task

TMS:TaskGroup

Linked data
The following items can be linked to change requests:

Auditing

Risk information
Factors
Questions

49

Reminders

Impacted areas

Work-related information

Effort tracking

Tasks
Task
Task Group

User requests

Broadcasts

The following ER diagram illustrates how these primary data elements can be
linked to the change request by the foreign key indicated. Note that in one case, the
change request is linked as a child of the SRM:Request records.
CHG:Change
Request Audit

CHG:ChangeRisk
FactorQuestionL
ookup

CFG:Reminders

CHG:ChangeRisk
Factors

CHG:Impacted
Areas

SRM:Request

Foreign Key:
SRInstanceID

TMS:Task

CHG:Infra.
Change Effort
Log

CHG:WorkLog

Foreign Key:
RootRequestID

CHG:Infrastructure
Change

Foreign Key:
Infrastructure Change ID

TMS:TaskGroup

Foreign Key:
Instance ID

TMS:FlowBuilder

50

TMS:Flow

TMS:SummaryData

CFG:Broadcasts

Data lookup
The following items can be looked up and referenced on change requests:

Operational categories
Tier 1
Tier 2
Tier 3

Product categories
Tier 1
Tier 2
Tier 3
Product Name
Model/Version
Manufacturer

Supporting resources
Requested By
Requested For
Manager
Assignee
Implementer

Locations
Region
Site Group
Site

51

The following ER diagram illustrates how these primary data elements can be
looked up and stored as local data on the change request.

COM:Company

CTM:Support
Group

CTM:People

Requested By
Requested For
Manager
Assignee
Implementer

Operational Category

CHG:Infrastructure
Change
Product Category

Region/Site Group/Site

CFG:Service
Catalog

PCT:Product
Catalog

CTM:Region

SIT:Site Group

SIT:Site

52

Comprehensive ERD
Incident Management
LDAP
HPD:Help Desk
Asset Management

TMS:LDAPUser

AST:Configuration
Problem Management
TMS:LDAPGroup
PBM:Problem
Investigation

AST: CI
Unavailability

PDL:Software
LibraryItem
PBM:Known Error

CHG:Infrastructure
Change

AST:*

PBM:Knowledge
Database

TMS:TaskGroup

FIN:Costs
TMS:Task

FIN:Association

CHG:Associations

TMS:Associations
COM:Company

Requested By
Requested For
Manager
Assignee
Implementer

CTM:Support
Group

CTM:People

CHG:Infrastructure
Change

Foreign Key:
SRInstanceID

SRM:Request

Operational Category

CFG:Service
Catalog

Product Category
PCT:Product
Catalog
Region/Site Group/Site
Foreign Key:
Infrastructure Change ID

Foreign Key:
Instance ID

Foreign Key:
RootRequestID

CTM:Region

SIT:Site Group
CHG:Change
Request Audit

CFG:Broadcasts

TMS:Flow

TMS:Task
SIT:Site

CHG:ChangeRisk
FactorQuestionL
ookup

CFG:Reminders

CHG:ChangeRisk
Factors

CHG:Impacted
Areas

TMS:FlowBuilder

TMS:TaskGroup

TMS:SummaryData
CHG:Infra.
Change Effort
Log

CHG:WorkLog

53

Main forms
The following table lists the main Change Management forms:
Form name

Type

Description

CHG:ChangeAPDetailSignature

Join

Supports integration to the Approval Server.

CHG:ChangeInterface

Join

Interface form for query and modify operations.

CHG:Associations

Regular

Stored related information.

CHG:ChangeInterface_Create

Regular

Interface form used for create operations.

CHG:CostAllocation

Regular

Supports integration to Cost Management subsystem.

CHG:Infrastructure Change

Regular

Primary Change Request form.

CHG:Template

Regular

Change Request Template form.

CHG:WorkLog

Regular

Maintains Work Log entries associated with change


requests.

Change calendar
The CCM change calendar is a high-level console for managing CCM change
activities, intended to be used by enterprise-level CIOs and members of change
approval boards. From the calendar, these users can see a holistic picture of
changes occurring in the enterprise, as well as associated business activities or
events. Some of this information comes from Change Management and other
information through referencing objects in the BMC Atrium CMDB. Aided by
links to investigative and analysis tools, users will be able to better understand the
risk and impact of changes and to plan and make better decisions about changes,
considering the interdependencies that are made more visible through the calendar
console.
The calendars primary view is a calendar-like schedule display that shows a
focused view of related change requests, when they are scheduled to begin and end,
and related business activities and events.
A user can select criteria to limit change requests and business activities to view,
that is, filter the view. By changing these filtering criteria, a user can focus on the
items of interest. High-risk changes are highlighted. A user can drill down from any
change request or business activity to see more detailed information about the item.
This view is primarily for change approval board members.

54

Architectural overview
An architectural diagram and a brief description of the primary components are
included in this document only as a reference for how the data visualization field
must be leveraged to enable this functionality. It is important to note that the
underpinnings of how this functionality works. You should not customize this
functionality.
The change calendar is an AR System application component built with AR System
mechanisms where possible and with custom components where augmenting
functionality is required. The change calendar consists of a primary form and a
number of subsidiary forms for user dialogs and administration. Although the
change calendar is only required to be viewable by a browser client, building on
forms also enables viewing through BMC Remedy User.
The change calendar is intended for members of a change advisory board (CAB),
usually during a CAB meeting. As such, it is not required to scale to large numbers
of concurrent users. However, it must scale in its ability to handle large numbers of
change requests. This influences aspects of the design in an attempt to balance the
needs of users for a useful visual display of change request data with the need to
access all the data with reasonable performance.

55

The change calendar requires functionality not provided by the base AR System
platform. It displays change requests and scheduled business events similar to a
project management application displaying activities and tasks as a Gantt chart. In
this way, it differs from standard calendars found in personal productivity
applications. It can represent requested changes that take multiple days to execute
and show dependencies between changes in a more understandable way using a
Gantt chart representation. The calendar view is an AR System form view in which
the activities schedule and other custom controls are integrated into an
AR System form as a Data Visualization field. The calendar uses a plug-in API.
The Change Calendar plug-in consists of a set of Java and JavaScript components.
The Java components run in the AR System mid tier in the plug-in container as
add-on components running in the same web application context as the mid tier.
The mid tier deployment includes an additional JAR file after the Change
Management application is deployed.
Except for the plug-in interface to the plug-in container, the calendar charting
functionality is written as an embedded web application with no dependencies on
the mid tier other than those exposed through the plug-in container.

56

Browser
Calendar
Client Runtime
Script

AR System mid tier


Plug-in
Container

CCM Calendar
Calendar
Plugin

Request
Dispatcher

CSS Files

JavaScript
Files

BMC Atrium CMDB API

Event
Dispatcher

Renderer

Model

AR API

57

The Change Calendar web tier uses a component-based Model-View-Controller


(MVC) architecture. It consists of several components:

Calendar plug-in
This component provides the glue between the calendar and the AR System
form that contains it. It implements the interface that enables its rendered
content and behavior to be embedded in an AR System form as a Data
Visualization field. This is a new field type in AR System 7.0. Data
Visualization fields that delegate rendering to an associated plug-in registered
with the plug-in service.

Request Dispatcher
The Calendar plug-in delegates work to one of two controllers: Request
Dispatcher and Event Dispatcher. The Request Dispatcher controller dispatches
requests for the calendar view or for associated resources, such as CSS
stylesheet files, JavaScript files, and images. The plug-in delegates handling of
calls by the plug-in container to its processRequest method to a Request
Dispatcher. It acts much as a Servlet: examining the HTTP request, identifying
the action requested, extracting request parameters, and delegating the
rendering of the response to the appropriate view object. This controller
accesses data that matches the request parameters, and encapsulates it in a
model object that it passes to the view for rendering.

Event Dispatcher
The Event Dispatcher controller is delegated to handle events forwarded to the
plug-in by the plug-in container from the plug-ins browser client JavaScript.
Such events are used by the calendar to perform in-place updating of the
HTML page rendered in the Data Visualization field in the host AR System
form. Similar to the Request Dispatcher, the Event Dispatcher controller
retrieves the needed data and passes it as the model to the appropriate view
component for rendering. The Event Dispatcher implements a JavaScript and
XML (AJAX) style of web page updating. However, the format of the data sent
to the web server and returned as structured to be simple and efficient to
process in the browser. A simple structured string is sent from the browser, as
required by the plug-in interface. The return value is a string representation of a
serialized JavaScript object that can be deserialized by script in the browser
receiving the reply.

Renderers
The Request Dispatcher delegates the schedule chart construction, the
thumbnail calendar control, and the activity summary to view objects, which
then implements the renderer interface. View objects, in turn, accesses a model
object to get change request or business event properties. A number of
renderers render just a part of the composite view sent to the browser, such as
header-cells that label each day along the top of the calendar. These can be
thought of as sub-view renderers. Composite view renderers aggregate a set of
sub-views into a complete view (HTML page).

58

Chart model
Model classes encapsulate change request or business event data fetched from
the Change Management database. The model delegates data access to data
source adaptors, which call either the AR System API or the BMC Atrium
CMDB API to access data. All business rules are executed in the model.

Browser client
Think of the V in MVC as consisting of two parts: server-side view
components called renderers, and client-side web page components that proxy
the server-side components. The client runs in a browser and is a combination
of HTML and JavaScript (sometimes called DHTML) that manipulates the
HTML DOM and handles event-driven interactions with the user and the host
Data Visualization field and its owning AR System form. Proxies for serverside view and model objects are implemented in JavaScript. CSS is used
extensively to both lay out the page and to control how it looks. Since the Data
Visualization field that hosts it is implemented as an IFRAME element, a full
page is delivered to the browser.

Executive dashboard
The primary goal of the Change Management Dashboard is to help executive users
understand the trends relating to change configuration management, and to take
appropriate action to balance the flow. A dashboard view presents a set of metrics
or statistics that give a snapshot of the state of the change management process. A
user has a choice of which statistics to view. The user can select criteria that
focuses the view on the desired perspective, and can indicate how far back to look
at the data. Example statistics are the history of planned and unplanned changes
over one or several time ranges, the number of authorized changes over the last
week or month, the success rate of changes made for the last thirty days, and a
summary of costs of changes over the last fifty changes made. The CIO is the
primary user of this dashboard view.

59

Architectural overview
CCM Executive Dashboard is developed using AR System Flashboard objects. The
CCM Dashboard is configurable, enabling executive users to select appropriate
flashboards to display on the Change Flashboard screen, along with a time period
that applies to all flashboards. This gives executives the flexibility to see what they
want.
The Change Management Dashboard component consists of three forms:

CFB:CCMFlashboard
This display form is divided into four sections: Overall Health, Customer Data,
Financials, and Operational Efficiency. Each section displays flashboards
related to these categories. The data displayed on the flashboard is gathered
from entries in the CHG:Infrastructure Change form.

CFB:FlashboardData
This is a back-end form used to save flashboard data. This form will save each
flashboard name, and metadata about each flashboard, such as the qualification,
to facilitate dynamic filtering.

CFB:FlashboardUserView
With this form, users can configure the default flashboards that are displayed.

60

Subsystem integration
The following subsystems are used by Change Management:

Requester Console

Cost Management

Service Level Management (SLM)

BMC Atrium CMDB

Requester Console
The requester console provides the front-end interface for users into the Change
Management application.
The integration:

Uses the SRMS framework in the Requester Console to create change requests.

Updates change information using the work log.

Has an interface back from the change to the request that is stored in the
Requester Console.

Updates the status of the request to match the status of the change request, and
makes visible Work Info entries.

The Requester Console interacts with Change Management using the Change
Management interface forms.

Cost Management
Change Management uses the Cost Management subsystem to track costs
associated with Change Requests.
The integration uses the common cost creation dialog box that is provided by the
Cost Management subsystem. The table field on the CHG:Infrastructure Change
form integrates with the FIN:CostAssociatonJoin form to display cost data related
to an incident.

SLM
Change management integrates with the SLM application to provide service level
definitions for resolution and response time for change requests.
When SLM is installed, a tab on the CHG:Infrastructure Change form is enabled,
showing the service targets and milestones that are associated to an Change
Request.

61

In addition to the user interface integration, the Change Management application


also ties into the definition structure of SLM. SLM has a plug-in architecture for
helping users define terms and conditions, and measurements for a service target.
Change Management provides a user interface for this SLM plug-in architecture to
make it simpler for users to build qualifications using a query-by-example (QBE)
model.

BMC Atrium CMDB


Change management integrates to the BMC Atrium CMDB using relationship
tables. From the Change Management user interface, users can search for CIs and
relate CIs to an incident.

62

Interfaces
Interfaces to Change Management include interface forms and web services.
For more information, see the BMC Remedy IT Service Management 7.0
Integrations white paper.

Interface forms
Two interface forms for Change Management support basic create, modify, and
query operations:

CHG:ChangeInterface_Create
This is a regular form and interfaces with the primary Change form,
CHG:Infrastructure Change. This interface form is the integration point for
external systems to create new change requests.

CHG:ChangeInterface
This form is a self-join form of the primary Change Management form,
CHG:Infrastructure Change. This interface form is the integration point for
external systems to query or modify change requests.

These interface forms contain all necessary fields from the base change request
form, CHG:Infrastructure Change, 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).
All of 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.

Web services
The submit, modify, and create operations are also supported using web services.
The following three diagrams illustrate how the create (submit), modify, and
query/query list operations are supported.
Create operation

For a create operation, a record is submitted to the CHG:ChangeInterface_Create


form and the command CREATE is supplied in the zID_Action field along with
any other relevant data values mapped to the exposed data fields. This triggers a
series of filters to process the record and stage it to be submitted to the base change
management form, CHG:Infrastructure Change.

63

After the record has been successfully created in the base Change Management
form, the new ID is returned.
An escalation will clean up and delete old staged create records from the
CHG:Interface_Create table and form.
Modify operation

For modify operations, the self-join form CHG:ChangeInterface is used. The record
ID of the change request to be updated is required.

64

In addition, when using web services to update all of the fields on the Change
Request form must be updated. Any field with a value of Null is set to a Null value.
Query and query list operations

The self-join form CHG:ChangeInterface is also used for the query operation. The
record ID or a query list qualification is required to retrieve either an individual
change request or a list of requests.

65

Permission model
In ITSM 7.0, permissions have two levels: AR System permission groups, such as
Change User, Change Submit, and Change Master, and functional roles. The
AR System permission group is not as relevant for the ITSM applications because
the ITSM applications use the General Access permission group across fields on
the forms. These groups are primarily used to provide functionality that a group can
access. For example, Change Submit will have less functionality compared to
Change User. All functionality based on permissions is implemented through
workflow. Functional roles enable the functionality to be further refined within a
permission group. Again, this is implemented through workflow.
The following example shows the difference between a person having Change User
permission with no functional role compared with having functional roles:

66

If a user has Change User permission with no role, this person has access to almost
everything (including the risk compute button, costing, and the calendar) on the
Change form, but has the following restrictions:

Limited ways to move from one status to the next. This user does not have
access to the states between Request for Change to Scheduled and also cannot
close out the request.

Cannot reassign the change manager and change assignee. Can manually
reassign the change implementer.

Cannot modify the effort logs for the change manager and change assignee, but
can create and delete the entries for change manager and change assignee.

If a user has Change User permission with Change Assignee role, this person has
the following restrictions:

Cannot reassign the change manager. Can manually reassign the change
assignee and implementer.

Cannot modify the effort logs for the change manager, but can create and delete
the entries for the change manager.

A user with Change User permission and a Change Manager role has access to all
functionality.
A Change Master is someone who has the access of a person with Change User
permission and Change Manager functional role across different support groups. A
Change Manager can also define approval mappings and change templates for his
or her support group.
A person with Change User permission (with or without a functional role) can work
only on the change requests that are assigned to his or her support groups. A person
with Change Master permission can work on any change request that he or she can
access, whether or not the change request belongs to the support group that the
request is assigned to.

BMC Remedy Asset Management architecture


Asset
Management
BMC Atrium CMDB
DSL

The Asset Management application lets IT professionals track and manage


enterprise configuration items (CIs)and their changing relationshipsthroughout
the entire asset life cycle. Asset Management tracks contracts, financial costs,
software licenses, outage indicators, and more for the CI information stored within
the BMC Atrium CMDB 2.0 application.

Cost Subsystem
ITSM Foundation
SLM

As part of the BMC Remedy ITSM Suite, Asset Management is integrated with
BMC Remedy Service Desk (which contains the BMC Remedy Incident
Management and BMC Remedy Problem Management applications), BMC
Remedy Change Management, and BMC Service Level Management, and offers
flexibility to support customized business processes.

67

Process flows
ITSM configuration management process overview

1
Configuration
management
planning

2
Configuration
identification

3
Configuration
specifications

4
Configuration control

5
Configuration
audit and
verification

Service support,
service delivery,
and other related processes

Configuration auditor

Asset manager

CMDB

RFC

Asset
Management

Change
Management

Incident
Management

Asset
Management

Incident
Management

Change
Management

Change
Management

2004 BMC Software, Inc. All rights reserved.

User interface
The user interface for Asset Management has two components. Components that
are specific to Asset Management are the user interfaces for the consoles and the
non-BMC Atrium CMDB forms. In addition, a generic user interface is on top of
the BMC Atrium CMDB. This user interface exposes the BMC Atrium CMDB data
to a user interface that connects the BMC Atrium CMDB data to other aspects of
Asset Management and other applications in the ITSM suite.
The BMC Atrium CMDB user interface is provided with all of the ITSM
applications. In the absence of the Asset Management application, this user
interface provides a view into the BMC Atrium CMDB so that CIs can be tracked
and related to other ITSM applications. When Asset Management is installed, the
user interface is extended to also contain links to specific Asset Management
functionality, such as contracts, depreciation, and procurement.

68

User Interface Forms (Joins)

Object1 : AST:ComputerSystem

Join

BMC Atrium CMDB Class Forms


BMC:CORE:BMC_ComputerSystem

Asset Management and the BMC Atrium CMDB


Asset Management is tightly integrated with the BMC Atrium CMDB as the
underlying data model to store details about the configuration items that are being
managed by Asset Management, and their relationships.
The BMC Atrium CMDB supports the concepts of reconciliation IDs and sandbox
functionality. This affects the overall structure of how data flows and is related to
other data in the ITSM suite.

Reconciliation ID
The BMC Atrium CMDB is structured as a model where data can be partitioned
across multiple data sets. For example, one dataset can hold raw data that is
discovered by a discovery tool, and another dataset can hold data that describes
future states of a CI. In each of these datasets you might have a different view of a
CI, and the data being stored about that CI. The BMC Atrium CMDB uses the
reconciliation ID to identify a CI in the same way across multiple datasets. When a
CI is identified by the reconciliation engine, it assigns a reconciliation ID to the CI.
Since the reconciliation ID is the only identifier that can define a particular CI, that
value is used to relate a CI to other data in the ITSM suite, such as incidents,
problems, and change requests. To view a snapshot of a CI in a particular dataset,
the ITSM applications provides mechanisms to define the dataset that a user wants
to view. These mechanisms are included in the query qualification that is used to
find a CI in the BMC Atrium CMDB.

69

Sandbox
Datasets are not only used to store raw discovery data, they are also used in the
system to be a flow through mechanism for updating the golden datasets of CI
data in the BMC Atrium CMDB. This flow through mechanism provides a layer of
control over what data is updated in the golden dataset in the BMC Atrium CMDB.
Reconciliation rules control what data is allowed to be updated and from what
source.
Asset Management provides a way to configure the system so that any updates to
an CI go through the sandbox dataset, and are reconciled against other data in the
system prior to being updated in the golden dataset. This keeps users from updating
data in the Asset Management application that should not be updated in the
production BMC Atrium CMDB.
The flow of the dataset workflow is as follows:

ERD
The Asset Management application key data model components are from the BMC
Atrium CMDB. The BMC Atrium CMDB provides the data model for all of the CIs
tracked by Asset Management.
In addition to the data that is stored and managed in the BMC Atrium CMDB for
CIs, Asset Management also provides additional data tables and structures to track

70

asset-specific data. These include contracts, purchasing, and standard


configurations. Following is a full ERD showing a typical asset interface on top of
the CMDB Computer System class, and how it relates to other data being stored by
Asset Management.

Asset Management full ERD


The BMC Atrium CMDB is built around a core data model with extensions. Asset
Management extends the BMC Atrium CMDB with additional classes and
attributes that are specific to Asset Management. You can find these in the CMDB
Data console by looking at the name spaces. Find the Asset Management
extensions in the CMDB Class Manager. You can see in the following Class
Manager Console that three classes are that are added by Asset Management to the
BMC Atrium CMDB data model.
Class Manager Console

71

Asset Management ERD

UI Joins on top of CMDB

Contracts

1
1
1

CMDB Classes

*
*

AST:ImpactedAreas

AST:AssetSupport

AST:AssetWarranty

AST:CI Unavailability

AST:CMDB Associations
AST:AssetSoftware
*

AST:Schedule Assocations

FIN:CostAssociation

AST:AssetCost

*
AST:WorkInfo

*
AST:Asset Lease

AST:AssetPeople

AST:ScheduleCriteria

FIN:Costs

AST:AssetMaintenance

CTM:People

Integrated Systems
HPD:Help Desk

PBM:Problem Investigation

*
*

PBM:Known Error

CHG:Infrastructure Change

TMS:Task

72

Asset Management system forms


Component

Form

Comments

Main Asset Extensions

AST:AssetPeople

Manages relationships
between the CI and the
CTM:People form.

Main Asset Extensions

AST:BMC Atrium CMDB Associations

Manages relationships
between CIs and ITSM
forms.

Main Asset Extensions

AST:Inventory Transactions

Stores the inventory


transactions.

Main Asset Extensions

AST:InventoryQuantity

Stores the inventory


quantity.

Main Asset Extensions

AST:CI Unavailability

Tracks outages against a CI


that are scheduled or
unscheduled.

Main Asset Extensions

AST:Impacted Areas

Tracks the locations that are


affected by this CI having an
outage.

Main Asset Extensions

AST:Schedule Association

Manages the relationships


between a schedule and the
CIs this schedule is for.

Main Asset Extensions

AST:Schedule Criteria

Defines the schedules.

Main Asset Extensions

AST:Configuration

Defines the standard


configurations.

Main Asset Extensions

AST:AUD_AssetAssociations

Association table used to


link standard configurations
to the deployed CIs.

Main Asset Extensions

AST:AdditionalData

Lets you add name and


value pairs data to a CI.

Main Asset Extensions

AST:AssetLease

Join between the lease


extension and the contract
subsystem to display
leases.

Main Asset Extensions

AST:AssetLease_

Lease extension to the


contract subsystem.

Main Asset Extensions

AST:AssetMaintenance

Join between the


maintenance extension and
the contract subsystem to
display maintenance
contracts.

73

Component

Form

Comments

Main Asset Extensions

AST:AssetMaintenance_

Maintenance extension to
the contract subsystem.

Main Asset Extensions

AST:AssetSoftware

Join between the software


license extension and the
contract subsystem to
display software contracts.

Main Asset Extensions

AST:AssetSoftware_

Software license extension


to the contract subsystem.

Main Asset Extensions

AST:AssetSupport

Join between the support


contract extension and the
contract subsystem to
display support contracts.

Main Asset Extensions

AST:AssetSupport_

Support contract extension


to the contract subsystem.

Main Asset Extensions

AST:AssetWarranty

Join between the warranty


contract extension and the
contract subsystem to
display warranty contracts.

Main Asset Extensions

AST:AssetWarranty_

Warranty contract extension


to the contract subsystem.

Main Asset Extensions

AST:AssetCost

Stores depreciation
schedules.

Main Asset Extensions

AST:AssetCostDepreciationHeader

Stores the details about the


type of deprecation models
being used.

Asset Purchasing

AST:PurchaseLineItem

Line items for the purchase


orders and requisitions.

Asset Purchasing

AST:PurchaseOrder

The holder of the purchase


order.

Asset Purchasing

AST:PurchaseRequisition

Holds the details on the


purchase requisition.

Asset Purchasing

AST:PurchaseReturn

Holds the return orders.

Software license management


The software license component of Asset Management is designed to automatically
link software instances with the contracts that describe the licenses that have been
purchased for those software instances.
The link is based on the normalization of the software instances by using the
definitive software library (DSL) and the underlying product dictionary that is

74

provided with the DSL. This enforces consistency when software instances
populate the BMC Atrium CMDB.
Contracts are tied to the appropriate DSL entries for the software. When a software
instance is generated, the system checks if there is a contract associated with that
type of software. If so, a relationship is automatically created to that software. The
system also automatically decrements the number of available licenses. If there are
no licenses available, or if a contract is not found for software that requires a
contract, an exception entry is created. The exception entry can then be assigned to
the asset manager to determine a course of action, which might mean purchasing
new licenses, harvesting existing licenses, and so on. The exception is managed by
the system until there are an appropriate number of licenses available to keep the
contract in compliance.
The following diagrams describe the flow and forms that comprise the software
license management component of Asset Management.

PDL:Product Dictionary (Join)


PMVInstance ID
ProductCompanyAssociation Instance ID

AST:ProductDictionarySearch

AST:Contract _PD_Relationship
Product ID
Product Instance ID
Model/Version ID
PMVInstance ID
Contract ID
Contract Instance ID
ProductCompanyAssociation Instance ID

AST:AssetSoftware (Join)
Contract Instance ID

75

Discovery

AST:ConfigLicenseMgmt

BMC:BMC_AssetBase

AST:Contract_PD_Relationship

AST:LicenseMgmtEngine

PDL:Product Dictionary

Contract/Asset
Relationship form
(AST:CMDB
Association)

AST:LicenseMgmtIncludeClass

Contains a list of CI classes that are used by the AST:ConfigLicenseMgmt


form to limit the CI classes processed by the License Management Engine.

The user interface to add to this list is exposed as a table field in the
AST:ConfigLicenseMgmt form.

A list of classes is predefined and shipped with the product.

AST:ConfigLicenseMgmt

Users with Asset Config permission can access this form.

76

Contains configurable rules for the License Management Engine.

It can also be accessed from the Application Administration Console.

The following table describes the fields in this form.


Field

Description

Status

Enables or disables the rule.

Company

Specifies which company uses this rule. A global rule applies for all
companies.

Repository

Specifies the data repository the License Management Engine should use
to for a lookup to match the CIs product categorization. In ITSM 7.0, only
DSL is supported. DHS is included for future implementation.

Include Classes table

Allows for a list of classes to be added to the configuration record. The


License Management Engine processes only CI Classes that are included
in the configuration and ignores classes that are not listed.

Create Exception

When set to Yes, creates an exception record for CIs for which no
matching contracts were found.

DataSetID

Contains the name of the reconciled dataset this rule applies to. If left
NULL, it assumes the rule applies to all datasets.

Notify Group?

Yes or No flag to indicate whether a notification should be sent to the


configured support group when a CI exception has been created. A
notification is sent once per night (escalation process). Only one
notification is sent per configured rule, that is, you might have many CI
exceptions per rule but only one notification is sent for that rule.

77

Field

Description

Support Company,
Support Organization,
Group

Fields to indicate what support group is defined as the notification group


for the given configuration rule.

AST:LicenseMgmtEngine
Back-end form that process incoming software CI records (reconciled) from
BMC:BMC_AssetBase. This form relates the CI to appropriate contracts when
rules in the AST:ConfigLicenseMgmt form are verified.

AST:LicenseMgmtException
A record is created in this back-end form when CIs were not successfully related to
contract. Records are created here only if configured to do so in the
AST:ConfigLicenseMgmt form.

AST:ManageLicenseMgmtException
A join form between the AST:LicenseMgmtException and BMC:BMC_AssetBase
forms. This form serves as the primary user interface for users to manage records
that are unsuccessfully processed by the License Management Engine. This user
interface is accessed from the Asset Management Console by clicking the Manage
Contracts link under General Functions, and then selecting License Management
Exception.
Nightly escalations evaluate records in this form for action:
1. If Status = Completed and Exception Decision = Process CI,
then process the CI through the License Management Engine for relating to a
contract. This action assumes that an asset administrator has made sure that a
licensable product has been linked to a contract so that the License
Management Engine can successfully process the CI.
2. If Status = Completed and Exception Decision = Delete, then the exception is
deleted. This means that the asset administrator has determined that the CI does
not need to have contracts related to it.
Only users with Asset Admin permissions can access this form.
Row-level locking by the Company field has been implemented on this form. The
Company field controls who can see exception records. If you have unrestricted
access defined in the People form, then you can search for all records.

78

Procurement
Asset Management contains a procurement process that handles the full process
from requisition to order, to receiving and returns.
The procurement process starts with a requisition. Requisitions are requests from
users for the things they want to purchase. Attached to a requisition is a set of line
items. These line items define each of the individual items that need to be
purchased. The requisition provides the processes around getting the line items
priced correctly and getting the appropriate approvals needed before orders can be
sent to vendors.
After the requisition is approved and the line items are priced, then the appropriate
orders are automatically generated. The orders are generated based on the vendors
for each of the line items. One order is created for each vendor, with the appropriate
line items attached.
From a data model standpoint, the line items are shared between the requisition and
the orders generated from that requisition.
When orders are received, the line items are updated with the received value, After
all line items are received the order is considered closed. Once all of the orders
generated from a requisition are received, the requisition is considered closed.

79

The main forms that make up the procurement component are:

AST:PurchaseRequisitionHolds the details about the requisition and the


user who is requesting the items. It also "drives" the process for getting the
requisition approved.

AST:PurchaseOrderHolds all of the orders that have been generated.

AST:PurchaseLineItemHolds each of the line items. The line items are


shared between the requisition and the order. The line items also contain the
information about if the item has been received. If ordered in bulk quantities,
the line items show how much has been received and how much is outstanding.

AST:PurchaseReturnHolds any returns that might have been made and


gives the reason why. It helps generate the appropriate documentation for the
vendor to be able to return the item, and also is tracked as part of the order.

AST:PurchaseRequisitonWorkLogContains the work notes that have been


attached to the requisition.

AST:PurchaseRequisition Requisition Instance ID


AST:PurchaseRequisitonWorklog
FK:

AST:PurchaseOrder

1
1

1
FK: Requisition Instance ID

FK: Order Instance ID

AST:PurchaseLineItem

FK: Line Item Instance ID


0..1

AST:PurchaseReturn

0..1

Contracts
Asset Management extends the contract subsystem to provide detailed contract
functionality for Lease, Warranty, Support, Maintenance, and Software License
Management.
Each type of contract also has relationships with the following forms:

80

CTR:ContractPaymentsProvides information about the payments made


against a contract.
AST:WorkLogTracks work notes against a contract.

CTM:PeopleHolds the contacts for a contract.

Relationship table AST:CMDB Associations to the BMC Atrium CMDB


formsLinks contracts to CIs.

Warranty contracts
*

FK: Serveral Companies Names

COM:Company

CTR:ContractPayments

FK: Instance ID
*

AST:WorkLog

FK: Instance ID
*

Child Contracts

AST:AssetWarranty
1
*

*
FK:CompanyName
1

CTM:People

Join Between AST:Warranty_ and CTR:ContractBase


*

AST:CMDB Associations
*

Reconciliation ID

subsystem
BMC Atrium
CMDB Forms

CTR:ContractBase

Shaded box = Contract subsystem provided

81

Support contracts

FK: Serveral Companies Names

COM:Company

CTR:ContractPayments

FK: Instance ID
*

AST:WorkLog

FK: Instance ID
*

Child Contracts

AST:AssetSupport
1
*

*
CTM:People

FK:CompanyName
1

Join Between AST:Support_ and CTR:ContractBase


*

AST:CMDB Associations
*

CTR:ContractBase

Shaded box = Contract subsystem provided

82

Reconciliation ID

subsystem
CMDB Forms

Lease contracts
FK: Serveral Companies Names

COM:Company

CTR:ContractPayments

FK: Instance ID
*

AST:WorkLog

FK: Instance ID
*

Child Contracts

AST:AssetLease
1
*

CTM:People

FK:CompanyName
1
*

Join Between AST:Lease_ and CTR:ContractBase


*

Reconciliation ID
AST:CMDB Associations
*

subsystem
Top Package::CMDB Forms

CTR:ContractBase
*
End Of Lease Support

CHG:Infrastructure Change
*

Shaded box = Contract subsystem provided

In addition to the basic structure of the Support and Warranty contracts, Lease
contracts also have a tie to the Change Management application to provide support
for end of lease activities.

83

Maintenance contracts
*

FK: Serveral Companies Names

COM:Company

CTR:ContractPayments

FK: Instance ID
*

AST:WorkLog

FK: Instance ID
*

Child Contracts

1
*

AST:AssetMaintenance FK:CompanyName

CTM:People

1
*

Join Between AST:Maintenance_ and CTR:ContractBase


*

Reconciliation ID
AST:CMDB Associations
*

CTR:ContractBase

Shaded box = Contract subsystem provided

84

subsystem
Top Package::CMDB Forms

Software contracts

FK: Serveral Companies Names

COM:Company

CTR:ContractPayments

FK: Instance ID
*

AST:WorkLog

FK: Instance ID
*

Child Contracts

1
*

AST:AssetMaintenance FK:CompanyName
1

CTM:People

Join Between AST:Maintenance_ and CTR:ContractBase


*

Reconciliation ID
AST:CMDB Associations
*

CTR:ContractBase

subsystem
Top Package::CMDB Forms

AST:Keys and Versions


*

Licenseable Product
PDL:Product Dictionary

AST:Contract PD Relationship
*

Shaded box = Contract subsystem provided

Software contracts provide additional relationships to the PDL:ProductDictionary


to represent the normalized product names to link to this contract when they are
entered in the BMC Atrium CMDB. The Software License Management
functionality handles that linkage (see Software License Management section).

Standard configurations
Standard configurations define what type of software or hardware a particular
group is entitled to. The configurations are stored in the AST:Configuration form.
This form has a header component that describes the configuration and a line item

85

component that describes each of the components (hardware or software) that make
up this standard configuration.
Standard configurations functionality is integrated with Change Management to
facilitate the procurement process. The standard configuration can be compared
with what is available in inventory to determine which items are available and
which need to be procured.

Outages
The Asset Management application provides a data model of storing planned or
unplanned outages against a CI. This information is stored in the AST:CI
Unavailability form. Scheduled outages automatically generate time segments in
the AR System Business Time subsystem. This information is then made available
to the change management process and other processes to understand when
scheduled outages have been made against a particular CI.
The outage model is also where Service Level Targets are integrated into the Asset
Management application. Information about service targets that have been defined
for a particular CI and the status of those service targets is shown on the SLM tab.

86

CMDB
Classes

1
*
AST:CI Unavailbility

1
Business Time Shared Entity

87

Schedules
The Asset Management application provides a model for defining two different
types of schedules: Maintenance Schedules and Audit Schedules. The definition
of these schedules defines time periods in which maintenance, or audits need to
be done for a particular CI, or set of CIs. The information about the schedule is
stored in the AST:ScheduleCriteria form. The relationship to the CI is stored in the
AST:Schedule Association form. The schedules also integrate with the Change
Management application to manage the tasks and scheduling of the required
maintenance and audits.

BMC
Atrium
CMDB
classes
*
*
AST:Schedule Association

CHG:Template
1

1
AST:Schedule Criteria

Subsystem integration
The following subsystems are used by Asset Management:

Service Level Management

88

Cost Management

BMC Atrium CMDB

Cost Management

Asset Management uses the Cost Management subsystem to track costs associated
with CIs.
This integration uses the common cost creation dialog box that is provided by the
Cost Management subsystem. The table fields on CI user interface forms integrate
with the FIN:CostAssociatonJoin form to display cost data related to an CI.
SLM

Asset management integrates with the SLM application to provide service level
definitions for uptime related service targets associated with a CI.
When SLM is installed, a tab is enabled on AST:CI Unavailability form, showing
service targets and milestones that are associated to a CI.

When you define a Service Target against a CI, a user interface shows the values
that are tailored to the integration with Asset Management outages functionality.

89

Interfaces
Asset Management provides a set of interfaces that can be used to integrate with the
Asset Management application. These interfaces include the BMC Atrium CMDB
API, for creating, modifying, and deleting CIs and relationships.

BMC Atrium CMDB API


This API provides a defined and documented interface for creating, modifying, and
deleting configuration items and their relationships.

Interface Forms
AST:PurchaseOrderInterface formProvides the mechanism for querying data in
the Asset Management purchase order system.

Web Services
AST:PurchaseOrderInterface_WS formProvides the web service interface to
query data from Asset Management purchasing forms.

90

Permission model
BMC Atrium CMDB permission model
BMC Atrium CMDB 2.0 provides the following additions.
Addition of two new AR System computed groups for view data in the CMDB.

CMDB Data View.

CMDB Data Change.

Addition of two new AR System roles:

CMDB Data ViewOn every class attribute with View permissions.

CMDB Data ChangeOn every class attribute with Change permissions.

Additional existing permissions:

Read Security (dynamic group)On every class attribute with View


permissions.

Write Security (dynamic group)On every class attribute with Change


permissions.

Assign Group (field 112)On the RequestId with View permissions.

These permissions are mapped to the following roles that are defined for Asset
Management as a deployable application:

Asset Management roles

Asset ViewerRead access to CI data in Asset Management.

Asset UserRead access to CI data in Asset Management with the ability to


modify CI data that has been related to one or more super groups that are
associated to the Asset Management user.

Asset AdministratorRead/write access to CI data in Asset Management.

Purchasing UserRead/write access to purchasing data in Asset Management.

Receiving UserRead/write access to receiving functionality in Asset


Management.

Mapping of Asset Management roles to BMC Atrium


CMDB roles

CMDB Data ViewMapped to Asset Viewer and Asset User.

CMDB Data ChangeMapped to Asset Admin.

Write SecurityMapped to support group permissions.

91

Row-level security
Row-level locking is set at the Company level for all Asset Management forms. All
child records inherit the tenants of the parents associated with them. For individual
CI records, the tenancy is set by the value in the Company field on the CI, and by
the Used by, and Supported By people and groups associated to the CI.

Mapping of Asset Management roles to Asset


Management functions
The following table maps Asset Management roles to Asset Management functions.
Asset
Management
component

Asset
Admin role

Asset User
role

Asset
Viewer
role

Purchasing
User role

Receiving
User role

Manage CIs

Write access
to all CIs and
functions

Read access

Read
access

No access

No access

No
access
from
Asset
Management
console

No access
from Asset
Management
console

No Access
from Asset
Management
console

Write access to
CIs the user
supports.
Includes ability to
create:
Contracts
Configurations
Relationships
Costs
Schedules
Outages
Returns
Activities
Impacted
areas

Manage
Inventory

92

Access to all
inventory
functions

No access from
Asset
Management
console

Asset
Management
component

Asset
Admin role

Asset User
role

Asset
Viewer
role

Purchasing
User role

Receiving
User role

Manage
Contracts

Write access
to all
contracts

No access from
Asset
Management
console

No
access
from
Asset
Management
console

No access

No access

No access

No access

No access

No access

No access

No access

Write access
from CIs the user
supports

Read
access
from CI
forms
Manage
Configurations

Access to all
configuration
functions

No access from
Asset
Management
console
Read access
Write access
from CIs the user
supports

No
access
from
Asset
Management
console
Read
access
Read
access
from CI
forms

Manage Costs

Access to all
cost
functions

No access from
Asset
Management
console
Read access
Write access
from CIs the user
supports

No
access
from
Asset
Management
console
Read
access
Read
access
from CI
forms

Bulk Updates

Access to
bulk update
functions

No access

No
access

93

Asset
Management
component

Asset
Admin role

Asset User
role

Asset
Viewer
role

Purchasing
User role

Receiving
User role

Schedules

Access to all
scheduling
functions

No access from
Asset
Management
console

No
access
from
Asset
Manage
ment
console

No access

No access

Write access
to purchase
requisitions
(including line
items) that
are assigned
to the users
support group

No access

Read access
Write access
from CIs the user
supports

Read
access
Read
access
from CI
forms

Purchasing
Console

No access

No access

No
access

Write access
to purchase
orders
Receiving
Console

No access

No access

No
access

No access

Access to
receiving
functions

BMC Remedy Service Desk architecture


Service Desk enables IT to respond quickly and efficiently to conditions that
disrupt critical services by automating incident and problem management
processes. Service Desk acts as a single point of contact for user requests, usersubmitted incidents, and infrastructure-generated incidents.

High-level process flow


The service desk is made up of two distinct processes under ITIL: the incident
management process and the problem management process.

94

While the incident management process focuses on getting users up and running,
problem management focuses on determining the root cause, and using the change
management process to correcting the root cause of the problem.
End User
Request

Incident
Management
Process

Notified of
Completed Fix

Change
Management
To
Correct
Errors

Known
Error
Management

Problem
Investigation

Notified of
Completed Fix

Notified of
Completed Fix

BMC Remedy Incident Management


Incident
Management
BMC Atrium CMDB
Task Management
Cost Subsystem
ITSM Foundation
SLM

Incident managements primary goal is to get the user back to work as soon as
possible after an incident.
Incidents can enter the system manually or automatically. Users can create
incidents using the Requester Console. The Requester Console provides users a
simple interface for entering and managing their requests. Incident Management
integrates with the Requester Console to provide this interface. Support technicians
at the service desk can also manually enter incidents using the HPD:Help Desk
form. Several functions are provided to make entering incidents easier, including
templates, scripts, and automation.
Incidents can also be created automatically. The Incident Management application
provides integration interfaces that allow external applications to create, modify,
and query data in the Incident Management database. The integration between the
BMC Service Impact Manager and Incident Management is an example of an

95

external application that integrates with Incident Management to generate incidents


based on events in the service model.

Process flows

ITSM auto-detect incident management process overview


<Process Name>
Identification and
recording
(Classification)

<Function>

Yes

Incident
detected

Yes

Incident Auto
Detected?

Incident
closure

Resolution and
recovery

Self correcting?

Incident
Ccosure

No

Identification and
recording
(Classification and
initial support)

No

Investigation and
diagnosis

Incident
Detected

Call to
Service Desk

Resolution /
Workaround
Validation

Web
Self-Help

1
Incident
Detection and
Recording

4
Resolution and
Recovery

Incident
Recorded
2
Classification
and Initial
Support
Event Monitoring
Incident Detected

No Available
Resolution /
Workaround

Resolution /
Workaround
Validated and
Accepted

5
Incident
Closure

Resolution /
Workaround
Found
3
Investigation
and Diagnosis

Other Service Support /


Delivery Processes

Incident
Manager

Incident Queue
Incident Assignee Incident Assignee
Manager
(Tier 2/3/n)
(Tier 1)
(Optional)

Customer

ITSM manual incident management process overview

96

Capacity /
Availability
Management

Request
Management

Change
Management

Problem
Management

Problem
Management

Configuration Management
Service Level Management

Problem
Management

Change
Management

Problem
Management

Design overview
The Incident Management application follows the guidelines described in this
document for how systems should be developed. It is encapsulated in a deployable
application to provide the ability to abstract the permission model and to provide
for licensing.

Main forms
The main forms used in the Incident Management application are:
HPD:Help Desk

This form is the main repository for incidents. All incidents are stored in this form,
and all workflow around the lifecycle of an incident is associated with this form.
This form also provides the main user interface for support technicians who work
the details of an incident.

HPD:Template

The HPD:Template form provides the repository for incident templates. Incident
templates provide the ability to quickly fill in common data for common incident
types.

97

HPD:Template Associations

This form stores the relationships between a template and a CI. Templates provide
functionality to let you relate a template to a particular CI from the BMC Atrium
CMDB. This is useful if the template is against a service CI or a business process
CI.

98

HPD:TemplateSPGAssoc

This form provides the repository for the associations between a template and the
support groups that can use the template. Workflow shows only templates based on
a user being in a support group that is mapped to the templates the user wants to
use.

HPD:Worklog

This form is the repository for work log entries for the Incident Management
application. The tables on the HPD:Help Desk form look up information from this
table.
HPD:Impacted Areas

This form holds the relationship between an incident and the areas affected by the
incident. Impacted areas describe the location from the location structures that are
affected by an incident. This table can be populated by pulling the information from
a related CI, or by adding additional affected areas to the incident.
HPD:Associations

This form is the main association table for the Incident Management application. It
holds the relationships in the context of Incident Management.

Subsystem integration
The following subsystems are used by Incident Management:

Requester Console

Task Management System

Cost Management

Service Level Management (SLM)

BMC Atrium CMDB

99

Requester Console

The Requester Console provides the front-end interface for users into the Incident
Management application. The integration:

Uses the SRMS framework in the Requester Console to create incidents.

Updates incident information using the work log.

Has an interface back from the incident to the request that is stored in the
Requester Console.

Updates the status of the request to match the status of the incident, and makes
visible Work Info entries.

The following diagram describes the flow from the Requester Console to Incident
Management. The Requester Console interacts with Incident Management using the
Incident Management interface forms.
Requester Console

SRMS framework
C eate
Events

HPD:IncidentInterface_Create

CAI:Events
Get

Application Object
Event

HPD:IncidentInterface

or Set

CAI:EventParams holds the field mapping when


incident communicates with the SRMS framework

HPD:Help Desk

Task Management System

The Task Management System subsystem provides the ability to track specific
tasks that are required to resolve an incident. The integration to TMS provides the
ability to create ad hoc tasks.
From the Incident Management user interface, the integration is to the
TMS:AssocSummaryDataJoin form, which is a join between the TMS:Association
form and the TMS:SummaryData form. See the Task Management System section
for the TSM ERD.

100

Tasks are created in the TMS:Tasks forms. In ITSM 7.0, only integration for ad hoc
tasks is supported.

Service Desk

Incident Management

Problem Management

Ad-hoc creation only


TMS

TMS:Tasks

101

Cost Management

Incident Management uses the Cost Management subsystem to track costs


associated with incidents.
The integration uses the common cost creation dialog box that is provided by the
Cost Management subsystem. The table field on the HPD:Help Desk form
integrates with the FIN:CostAssociatonJoin form to display cost data related to an
incident.
SLM

Incident Management integrates with the SLM application to provide service level
definitions for resolution and response time for incidents.
When SLM is installed, a tab on the HPD:Help Desk form is enabled, showing the
service targets and milestones that are associated to an incident.

102

In addition to the user interface integration, the Incident Management application


also ties in to the definition structure of SLM. SLM has a plug-in architecture for
helping users define terms and conditions, and measurements for a service target.
Incident Management provides a user interface for this SLM plug-in architecture to
make it simpler for users to build qualifications using a query-by-example (QBE)
model.

103

BMC Atrium CMDB

Incident Management integrates with the BMC Atrium CMDB using relationship
tables. From the Incident Management user interface, users can search for CIs and
relate CIs to an incident.
When Asset Management is installed, this integration is extended by prompting
users to create outages against CIs they are relating to the incident. The outage data
is stored in the Asset Management application database, with relationships created
back to the incident.

104

ERD

Change Management

CHG:Infrastructure Change

Problem Management

Lookup Data

PBM Problem
:
Investigation

PCT:Product Catalog
PBM Known Error
:

CFG:Service Catalog

SIT:Site

PBM Knowledge
:
Database

HPD:Help
Desk

Asset Management/
CMDB
:

CTM:People Organization

AST: CI
Unavailability

HPD:Association

BMC:*
CMDB Classes

FIN: Costs

FIN: Association

CFG: Broadcast
Association

HPD:Help Desk

Foreign Key:
Request ID

TMS: Associations

(See Note)

(See Note)

CFG: Broadcast

HPD:HelpDesk_AuditLogSystem

CTM:People

CTM:Company

TMS:Task

Foreign Key:
Incident Number

(See Note)

Foreign Key:
Incident Number

HPD:ImpactedAreas

CTM:Support Group

HPD:Work Log

105

CTM:People
Used in various contexts, key back is the login ID
for each of these areas:
- Customer
- Contact
- Owner
- Assingee
- Vendor Contact

CTM:Company
Used in various contexts, key back is the
company name for each of these areas:
- Customer Company
- Contact Company
- Owner Support Company
- Assingee Support Company
- Vendor Company
- Company (also known as the operational
company)
CTM:Support Group
Used in various contexts, key back is the login ID
for each of these areas:
- Owner Support Group
- Assignee Support Group

Interfaces
Incident Management provides a set of interfaces that can be used to integrate with
the Incident Management application. These interfaces include a set of AR System
forms that provide the ability to create, query, and modify incidents. They also
include web services interfaces that are built on top of these forms to provide a
mechanism to interface with the Incident Management application using web
services.

106

The following interface flow diagram shows the basic flow of how an external
application would integrate with Incident Management.

Help desk ticket submit

ITSM
Creates an association
with a CI if a CI name
is specified

External
application

Creates staging
record using Help
Desk Submit web
service

HPD:IncidentInterface
(Staging form)
Processes
incoming
parameters

Association
forms

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

Data flow direction

Interface forms

HPD:IncidentInterface_CreateInterfaces with the HPD:Help Desk form


to create incident tickets.

HPD:IncidentInterfaceSelf-join of HPD:Help Desk form for query and


modify operations.

Web services

HelpDesk_QueryList_ServiceQueries for multiple tickets in the


HPD:HelpDesk form.

HelpDesk_Modify_ServiceModifies a ticket in the HPD:HelpDesk form.

HelpDesk_Query_ServiceQueries for tickets in the HPD:HelpDesk form.

HelpDesk_Submit_ServiceSubmits a ticket in the HPD:HelpDesk form.

Licensing model
Incident Management licensing is enabled using the Deployable Application
mechanism in AR System.

107

Incident Management requires the following application-level and user-level


licenses:

Incident Management application license

Incident User fixed or floating user license for modifications on the HPD:Help
Desk form

Financial application license to access costing data

BMC Atrium CMDB application license to access the BMC Atrium CMDB

Permission model
The permission model of the Incident Management application has five basic roles:

Incident Viewer

Incident User

Incident Master

Incident Submitter

Incident Config

BMC Remedy Problem Management


Problem
Management
BMC Atrium CMDB
Cost Subsystem

Problem Management is focused on finding the root cause of an issue in the IT


infrastructure, and working to correct that known error.
Problem Management has three main components:

Knowledge

Problem investigation

Known error management

ITSM Foundation

Solution database

Problem investigation
The problem investigation module of Problem Management is focused on
determining the root cause of an infrastructure problem.
The results of a problem investigation are:

108

Known errorsDescribe the root cause.


Knowledge solution entriesDescribe how to work around the issue and
potentially other incidents or problems to investigate.

Known error management


Known error management uses the results from the problem investigation on the
root cause of an issue and provides the process around determining the fix for the
known error.
A known error management process could have one of the following results:

A change request to implement the desired fix.

Closing the known error as an accepted issue, with updates to the knowledge
database with steps to avoid the issue.

Solutions database
The solutions database provides a simple repository of potential solutions to
infrastructure issues. These might be workarounds or solutions to use in helping
users get around an issue. The data from the solutions database becomes an input
into a full knowledge management system with the use of the full BMC Knowledge
Management solution.

Process flows

Investigation
Initiated

Other Service Support /


Delivery Processes

Problem Manager

Problem Assignee

Requester

ITSM Problem Management Process Overview

3
Problem
Investigation
and Diagnosis

1
Problem
Identification,
Recording and
Classification

8
Knowledge
Identification
and Recording

5
Known Error
Identification
and Recording

4
Problem
Resolution and
Closure

6
Known Error
Classification
and
Assessment

7
Known Error
Resolution and
Closure

9
Knowledge
Validation and
Publication

2
Review

Incident
Management

Incident
Management

Change
Management

Change
Implemented

Incident
Management

Configuration
Management
(Mgmt Reports)

2004 BMC Software, Inc. All rights reserved.

109

Main forms
This section describes the main forms used in Problem Management.
Problem investigation

PBM:Problem Investigation
This form is the repository for problem investigations. The problem investigation
lifecycle and processes around problem investigations are driven off this form. This
form is the main user interface for support technicians who work on problem
investigations
PBM:Investigation Associations
This form provides the repository for associations between problem investigations
and other records. It holds the context of the record being displayed.
PBM:Investigation Effort Log
This form provides a repository for the effort that has been put into determining the
root cause of a problem. It tracks the amount of time by user.

PBM:Investigation Work Log


This form provides the repository of work log entries associated with individual
problem investigations.

110

Known error management

PBM:Known Error
This form is the repository for known error records. The known error management
lifecycle and processes around known errors are driven off this form. This form is
the main user interface for support technicians who work on known errors.
PBM:Known Error Associations
This form provides the repository for associations between known errors and other
records. It holds the context of the record being displayed.
PBM:Known Error Work Log
This form provides the repository of work log entries associated with individual
known errors.
Solutions database

PBM:Solution Database
This form is the repository for solution records. Solution lifecycle and processes
around solutions are driven off this form. It is the main user interface for support
technicians who work on solutions.
PBM:Solutions DB Alias
This form provides the repository for search keywords that are associated with a
particular solution. This information is available from solution search dialog boxes
to allow users to search by keywords.
PBM Solutions DB Associations
This form provides the repository for associations between solutions and other
records. It holds the context of the record being displayed.

111

ERD
Change Management
:Infrastructure
CHG:
:
Change

Problem Management

Lookup Data

PCT:Product Catalog

Incident Management

HPD:

PBM Problem
:
Investigation

Help Desk
PBM Known Error
:

CFG:Service Catalog
PBM
:

SIT:Site

Solution
Database
Asset Management/
CMDB
:

CTM:People Organization

AST: CI
Unavailability

PBM Associations
:

BMC:*
CMDB Classes

FIN: Costs

FIN: Association

PBM:

Problem
Investigation

CFG: Broadcast
Association

Foreign Key:
Request ID

TMS: Associations

(See Note)

(See Note)

CFG: Broadcast

PBM:Problem_AuditLogSystem

CTM:People

CTM:Company

TMS:Task

Foreign Key:
Incident Number

(See Note)

Foreign Key:
Incident Number

112

PBM:ImpactedAreas

CTM:Support Group

PBM:Work Log

CTM:People
Used in various contexts, key back is the login ID
for each of these areas:
- Manager
- Assignee
- Requester

CTM:Company
Used in various contexts, key back is the
company name for each of these areas:
- Requester Company
- Mannger Support Company
- Assingee Support Company
- Vendor Company
- Company (also known as the operational
company)

CTM:Support Group
Used in various contexts, key back is the login ID
for each of these areas:
- Requester Support Group
- Assignee Support Group
- Manager Support Group

113

Change Management
:Infrastructure
CHG:
:
Change

Problem Management

Lookup Data

PCT:Product Catalog

Incident Management

HPD:

PBM Problem
:
Investigation

Help Desk
PBM Known Error
:

CFG:Service Catalog

PBM
:

SIT:Site

Solution
Database
Asset Management/
BMC Atrium CMDB
:

CTM:People Organization

PBM
:

Known Error
Associations

AST: CI
Unavailability

BMC:*
CMDB Classes

FIN: Costs

FIN: Association

PBM: Known Error

CFG: Broadcast
Association

Foreign Key:
Request ID

TMS: Associations

(See Note)

CFG: Broadcast

PBM:Problem_AuditLogSystem

CTM:People

(See Note)

CTM:Company

(See Note)

CTM:Support Group

TMS:Task

Foreign Key:
Incident Number

114

PBM:Known Error Work Log

CTM:People
Used in various contexts, key back is the login ID
for each of these areas:
- Manager
- Assignee
- Vendor

CTM:Company
Used in various contexts, key back is the
company name for each of these areas:
- Mannger Support Company
- Assingee Support Company
- Vendor Company
- Company (also known as the operational
company)

CTM:Support Group
Used in various contexts, key back is the login ID
for each of these areas:
- Assignee Support Group
- Manager Support Group

115

Change Management
:Infrastructure
CHG:
:
Change

Problem Management

Lookup Data

Incident Management

HPD:

PCT:Product Catalog

PBM Problem
:
Investigation

Help Desk
PBM Known Error
:

CFG:Service Catalog

PBM
:

SIT:Site

Solution
Database
Asset Management/
BMC Atrium CMDB
:

CTM:People Organization

PBM
:

Solution
Associations

AST: CI
Unavailability

BMC:*
CMDB Classes

FIN: Costs

FIN: Association

PBM:

Solution
Database

Foreign Key:
Request ID

Foreign Key:
Assingee

TMS: Associations

PBM:Problem_AuditLogSystem

CTM:People

Foreign Key:
Assignee Company

CTM:Company

Foreign Key:
Support Group

CTM:Support Group

TMS:Task

Foreign Key:
Incident Number

Interfaces

116

PBM:ProblemInterface_Create
PBM:ProblemInterface

PBM:Solution Work Log

PBM:KnownErrorInterface

PBM:SolutionsInterface

ITSM 7.0 subsystems


This section describes subsystems used by ITSM applications.

Command Automation Interface


The Task Management System (TMS) provides tasking capabilities to the Change
Management, Problem Management, and Incident Management applications, and
integrates with the BMC Configuration Management system using the Common
Automation Interface (CAI). The Service Request Management System (SRMS)
framework support the Requester Console, which is the front-end user interface for
Change Management and Incident Management. TMS and SRMS use the CAI to
communicate with ITSM applications.
The CAI subsystem provides a common infrastructure that can be shared across
applications including ITSM 7.0 applications and BMC Configuration
Management. The functionality of CAI is based on the current implementation for
SRMS framework command events and the requirements of TMS. The CAI
consists of three major blocks that result in event delivery to the target applications.
For ITSM 7.0, CAI is a back-end component that does not provide a front-end user
interface. Additional user dialogs can be created for each integrated component to
push data into the CAI forms.

Overview
This section provides an overview of TMS.
Definition phase: Application registration and command
definition

Application registration defines the integration attributes to the external systems,


such as application name, connection information, and interface form names.
Command definition describes the commands and the command parameters for
each integrated component. For example, the Requester console has defined a set of
commands for interaction with back-end applications. In TMS, a set of commands
is defined for interaction with BMC Configuration Management. In addition, the
CAI can include command parameter mappings to the registered applications.
Construction phase: Instantiation of the command definition
as events

Command events are instantiated based on the command definitions. The event is
constructed using the specific command name, and the command parameter values
are populated by the integrated components. For example, when the SRMS

117

framework needs to create a new back-end application request, it pushes a new


event record with the command name, SRM_OUT_CREATE_APP_REQUEST
(CreateAppRequest). It also pushes the event parameters for template ID and
service request ID using the appropriate run-time values. In TMS, when it needs to
construct a URL string to interact with BMC Configuration Management, TMS
specific workflow creates the appropriate event with the run-time parameter values
and formats the URL string accordingly. CAI provides the form structure and
generic workflow for command instantiation. Each integrating component must
implement the workflow to handle its specific commands.
Execution phase: Event delivery

The mechanism that delivers the command events to the target system depends on
the protocol used. For AR protocol, where the target is another AR System
application, the CAI event plug-in can be used. This plug-in creates the appropriate
records as specified in target information of the event. For URL protocol,
workflow sets the URL string to the appropriate view field for the browser. CAI
provides the generic event plug-in and each integrating component must implement
the workflow to handle the invocation of the plug-in, or use specific workflow for
the delivery. For ITSM 7.0, AR and URL protocols are supported.
Definition
1

Construction

Event Data Values


What

Command Content
How

Execution
5

RuntimeJust Do It
Command

2
ID

App Registry
Name
Protocol

Command

Param

Commands
Direction Op. Type

Parameters
Data Type

Done
Mode

ERD
A diagram of CAI follows that outlines the three phases for outbound commands:
definition, construction, and execution. Each event must have the following field
values:
Command nameName is defined in the command definition, with specific
naming convention.

118

TargetKeyword (SRMS, TMS, APP)APP means back-end application.


SourceKeyword (SRMS, TMS, APP)
Direction (Inbound or Outbound)Outbound means an event sent by SRMS
framework or TMS to APP.
Type (Create, Update, Get)Create means an entry will be created as part of the
event delivery. Update means an entry will be updated; Get means an entry will be
queried.
Depending on the command type, the CAI plug-in will create, update, or query an
entry from the interface form for all outbound commands. In general, the CAI plugin can be used by all events of AR protocol, and is most useful in scenarios where
dynamic fields are used. In ITSM 7.0, the SRMS framework is the only component
that invokes the CAI plug-in. TMS uses all URL-based commands and has
workflow that constructs the URL string based on the event parameters.

119

Definition

2 . Map command paramters for each


registered

1 . Register
CAI : AppRegistry

U1
U2

CAI :CommandParamMappin

InstanceID
AppRegistryName
ApplicationName
ApplicationInstanceID
Protocol
Connection Info
Interface Form Names

AppRegistryName
Command
CommandParam
AppInterfaceFormName
AppFieldName
AppFieldID
ParamType
ParamDataType

0 . Create commands and


command paramters
CAI : Command

U1

Command
Direction
OperationType
SelectionType

CAI :CommandParam

U1
U1

Command
CommandParam
Type
DataType
Mode

Construction

CAI : Event
CAI :EventParam
EventGUID
Event
Source
Target
SourceAppRegistryInstanceI
AOIGUID
AppInterfaceFormName
TargetConnectionInf
RtnCode
RtnMsgCode
RtnMsg
MaxRetries
RetryCounter

Execution (outbound)

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

SRMS
framework/TMS
Calls GetEntry to
get event values

Filter API Plug-in


Push event and event
params
App Interface Form

Mapped Param

120

AR System
workflow
Launch

Browser

The inbound events should be created in the event and event param forms by the
back-end applications. Workflow must be implemented to process the command
events by the target application, such as TMS. The workflow qualification should
be based on the values of TargetKeyword and Event.
For example:
TargetKeyword = SRMS
Event = SRMS_IN_APP_REQUEST_RESOLVED

121

The following high-level diagram shows the flow of inbound commands. In this
diagram, the Target is SRMS and the Source is APP, which means a back-end
AR System application.
Definition

2. Map command paramters for each


registered application

1. Register application
CAI:AppRegistry

U1
U2

CAI:CommandParamMapping

InstanceID
AppRegistryName
ApplicationName
ApplicationInstanceID
Protocol
Connection Info
Interface Form Names

AppRegistryName
Command
CommandParam
AppInterfaceFormName
AppFieldName
AppFieldID
ParamType
ParamDataType

0. Create commands and


command paramters
CAI:CommandParam
CAI:Command

U1

Command
Direction
OperationType
SelectionType

U1
U1

Command
CommandParam
Type
DataType
Mode

Construction

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

Execution (outbound)

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

SRMS/TMS

Calls GetEntry to
get event values

FilterAPI Plug-in
Push event and event
params
App Interface Form

Mapped Param

122

AR System workflow
Launch

Browser

Component Design

Forms and plug-in


The CAI consists of the following forms and plug-in:

CAI:AppRegistry

CAI:Command

CAI:CommandParam

CAI:Event

CAI:EventParam

CAI:CommandParamsMapping

CAI:DefineCommandParameters

CAI:Plugin Registry

Filter API plug-in, caieventcmd.dll

All forms in CAI are back-end forms and each integrating component must provide
its own user interface for user updates to these forms. TMS contains front-end
forms that use workflow to push TMS data to the CAI:AppRegistry form.
CAI:AppRegistry
This form stores application interface information, such as interface form names,
connection data, and the protocol. Each integrating component, such as TMS, must
provide the user interface and workflow for updates to this form.
CAI:Command, CAI:CommandParam
These forms store command names and command parameters for each integrating
component. There is a one-to-many relationship between a command and a
command parameter. A command parameter cannot be used by more than one
command. Naming conventions must be used to allow generic qualifications for
event process filters, as in the following listed for the SRMS framework and for
TMS.
SRM_IN_[COMMAND_NAME]SRM inbound command.
SRM_OUT_[COMMAND_NAME]SRM outbound command.
TMS_IN_[COMMAND_NAME]TMS inbound command.
TMS_OUT_[COMMAND_NAME]TMS outbound command.
For localization considerations, command parameter names must use all uppercase
letters and with no spaces.

123

CAI:Event, CAI:EventParam
These forms store the event and related parameters. Each integrating component
must implement specific filter workflow to process its specific commands. Guides
should be used whenever possible to minimize undesirable filters being executed.
The following table shows naming standards and workflow order:
Component

Filter prefix name

Filter order range

CAI

CAI:

100-199

SRM

INT:CAISRM:

200-399

TMS

INT:CAITMS:

400-599

CAI

CAI:

900-999

Some exceptions might be required for certain filter order numbers. For example,
some CAI filters might fall between SRM and TMS range.
Each event record has a version number, which allows for compatibility between
different CAI and integrating components versions.
Workflow that processes the event should always set the Return Code field to
indicate success or failure.
CAI:CommandParamsMapping
This form defines the mapping between the command parameters and the backend
application. It also maps the fields to a command parameter, such as mapping a task
ID from the TMS:Task form, to a parameter in the generated URL. A command
parameter can be mapped to more than one backend application. The
SRMS_OUT_CREATE_APP_REQUEST commands command parameter,
APP_REQUEST_GUID, for example, is used by both Incident Management and
Change Management.
CAI:DefineCommandParameters
This is a front-end form used for adding commands and command parameters. It is
accessed from the Application Administration Console. Choose Foundation >
Advanced Options > Command Automation Interface - Define Command
Parameters.
CAI:Plugin Registry
To increase performance, the private queue and number of threads to be used for
the CAI plug-in are defined using this form. To use this feature, you must define a
private queue using BMC Remedy Administrator, and then update the CAI Plug-in
Registry with the queue number and number of threads.

124

Flow diagram

The following diagram illustrates the flow when interacting with the CAI.

1. Event is created in CAI:Events


form; parameters are pushed to
CAI:EventParams form

6. CAI plugin returns


status to
CAI:Events
form

Service Request

CAI:Events
2. When an entry is
created in the CAI:Events
form, the CAI plug-in is
called
CAI:EventParams

Main Plug-in
code

3. The CAI plug-in


creates an entry in the
request queue and
returns Status =
Running to CAI Events
form
Request queue

4. When a request
is added to the
queue, a signal is
issued to wake up a
thread in the thread
pool to process the
request.

CAI Plug-in
Thread Pool

5. CAI plug-in
creates Change
Request and/or
Incident

HPD:HelpDesk

CHG:Infrastructure Change

125

Interfaces
CAI plug-in

The primary purpose of the CAI plug-in is to transmit events to other back-end
applications. Due to the dynamic nature of the field mappings for each command,
and because it is not possible to use workflow to push values to dynamic fields, the
CAI plug-in provides a mechanism to dynamically map data to fields. For example,
the command to create a back-end request consists of dynamic field values that can
be mapped to any field on the back-end interface forms. Additionally, the CAI
plug-in helps address issues that arise with incompatible permission models.
The following inbound and outbound commands are supported by the Filter API:
Command

Direction

Filter API
action

CreateAppRequest

Outbound

CREATE

GetAppRequestInfo

Outbound

GET

CancelAppRequest

Outbound

UPDATE

UpdateAppRequestWorkLog

Outbound

UPDATE

ActivateAppRequest

Outbound

UPDATE

AppRequestInProgress

Inbound

UPDATE

AppRequestResolved

Inbound

UPDATE

AppRequestCancelled

Inbound

UPDATE

UpdateSRWorkLog

Inbound

UPDATE

Decrypt Password

Outbound

DECRYPT

Web services

The web service setup for the CAI is a complex web service, which means it is
made up of multiple components and presented as a single interface. The two CAI
components: CAI:Events and CAI:EventParameters, are defined as a single web
service.

126

The following table summarizes the names of the operations, the base form the
operations function against, and the name and form types of the supporting
AR System forms that serve as the interface to these areas of the CAI.

Base form

Operation description

Operation
name

Interface form*

Form
type

CAI:Events (root)

Query individual event

OpGet

CAI:Events (root)

Regular

CAI::EventParams

Query list of entries

OpGetList

CAI::EventParams

Regular

Create CAI event and CAI


event parameters

Op Create

Note: The web services for these functions are directly connected to the base forms
using an XSD file. In a future release, an abstraction layer will be introduced in
front of these base forms to act as the primary interface for external systems.
This will enable making the maintenance and code updates to enhance
functionality of the CAI transparent to any external integrations. In addition, this
abstraction layer will make it easier to maintain backwards compatibility for
subsequent releases.

Permission model
The CAI has the Command Event Master role, which by default is mapped to the
Command Event Master group, and can be granted to users using the People form.
Only users in this group and AR System administrators can access the CAI forms
and update certain fields on them. For implementation of event error handling,
integrating applications must have the same group and role mapping.
For remote access using AR protocol, the remote AR System login must have
permission to create and update to the interface forms specified in the AppRegistry
form. Similarly, for the back-end application to send inbound commands to the
remote front-end application, such as TMS, the TMS AR System login must have
permission to create records in the event and event parameters forms. See the dataflow diagram for the integration points.

Contract Management
The Contract Management subsystem provides a generic contract for tracking basic
contract information and lifecycle. This system is used by Asset Management and
Service Level Management as a basis for their specific definitions of a contract.

127

ERD
Application specific contracts

Join

Contract Management subsystem


CTR:ContractBase

CTR:ContractPayments

CTR:ContractAuditLogSystem

Interfaces
The Contract Management subsystem provides the underlying data and process
model for basic contract management. Applications extend the basic data model by
creating a join on top of the CTR:ContractBase form. This join includes a form that
contains data specific to the application and basic contract information.
This structure is used in the Asset Management and BMC Service Level
Management (SLM) applications.

Permission model
Contract Management permission groups are defined as computed groups in the
Group form.
Each Contract permission group is mapped to an Asset permission group to support
the deployable application functionality. To remove specific users from the
computed group, remove the Asset Management groups for each Contract
permission group to make each Contract permission group stand alone.

128

Each Contract Management permission group is mapped to an Asset Management


permission group, as shown in the following table.
Contract
Management
permission group

Asset Management
permission group

Access

Contract View Only

Asset Viewer

Read

Contract Full Access

Asset User, Asset Admin

Write

Contract Administrator (reserved for future use)

N/A

Write

Costing Management
The Costing Management subsystem provides functions required by the ITSM suite
for management of cost data. The costing model has two components: tracking of
costs, and chargeback calculations and reporting.
Each application uses Costing Management to track the costs related to the records
in the application. For example, Incident Management uses Costing Management to
track the various costs associated to incidents.
Asset Management also uses the chargeback functionality in Costing Management.
Chargebacks are roll ups of the costs that have been incurred over a period and
involved in the various cost centers in a company. The chargeback component of
Costing Management generates chargeback entries, lets the financial manager make
appropriate adjustments to the costs, and generates invoices to be sent out to the
individual cost centers.
Costing Management is designed to be completely standalone. The main form,
FIN:Costs, holds individual cost data. The relationships to the main records use
associations in the FIN:Associatons table. Costing Management also provides a join
between the FIN:Costs and FIN:Assocaitons tables to provide the query interface
for use by applications that integrate with the subsystem. This join is used by table
fields in ITSM applications.
The chargeback functionality is enabled by a filter API application. It is driven by
data in the chargeback forms that define the cost centers, how the cost centers are
allocated, and the dates for running chargeback reports. The result of the API run is
a set of chargeback entries. The chargeback functionality provides an adjustment
user interface that is used to adjust the chargeback costs, and a reporting user
interface to run invoices.
The costing forms and workflow are encapsulated in a deployable application. This
provides the ability to license and abstract the roles for the subsystem.
Costing Management has clearly defined interfaces for integration, with a
programmatic interface used for creating and modifying data. Users can also create

129

and update data through a common user interface dialog box. The functionality of
this interface is driven by flags that are passed in. These flags control which
templates are available, the ability to regenerate costs, and the ability to lock down
costs.

Calling System Interaction


Calling
System

Interface Form
Functions:
Creating Automatic Cost Entries
Updating Automatic Costs
Lock Cost Entries
Copy Cost Record
Request 112 update on Associated Costs

130

ERD
Base Data Model
FIN:Association
FIN:Cost

Calling System Form


Calling System Identifier
Cost Record Instance ID
Association Type
Primary
Informational
Allocation

Cost Center
Cost Type
Description
Amount
Units
Date Incurred
Instance ID

FIN:CostAssociationJoin

Filter API

FIN:ChargeBacks

Calling System Table


Identifier

Populated using a filter API


process with cost data and
cost center allocations from
FIN:Cost . Used for chargeback
reporting.

Licensing model
The Costing Management subsystem requires an application-level license. This
license is provided with all ITSM applications. A user license is also required for
the chargeback component of the subsystem. This license is required for making
adjustments to the chargeback functionality.

Permission model
Roles

The roles defined for the costing subsystem are:


ViewerCan only view cost data.
UserCan add costs.
ManagerCan update and manage the chargeback process.

131

Definitive Software Library


The ITIL definition of the Definitive Software Library (DSL) is a library where the
definitive authorized versions of all software Configuration Items (CIs) are stored
and protected. It is a physical library or storage repository where master copies of
software versions are placed. This logical storage area might consist of one or more
physical software libraries or file stores.
In short, the DSL is a repository of authorized and approved software available to
be deployed to the production environment. It contains or provides a reference to
the golden images.
The BMC implementation of the DSL was designed around these principles and is
structured to:

Be the centralized store of authorized software package information.

Ensure consistency between Change Management and Configuration


Management.

Normalize entries in the BMC Atrium CMDB.

Keep asset information in the BMC Atrium CMDB accurate.

The following is the Definitive Software Library Console. It is used to manage the
contents of the DSL.

132

Architectural overview
The DSL is instrumental in normalizing the names of software items maintained in
the BMC Atrium CMDB or discovered in the production environment. Acting as
the single source for these names, many components of the ITSM environment
interact with the DSL, as illustrated in the following high-level architecture
diagram.
Change Manager
Change Assignee

System to System
Interaction

Asset Management

Data Interaction

Software License Mgmt


Approvals

Change Management
Change Request
Product Lookup
DSL Reference
Related CI Targets

CMDB
Configuration
Discovery
Definitive
Software
Library
Policy
Manager

Task
Management
System
Command
Automation
Interface

Task Implementer

Deployment
Manager

Common Management Services

Primary components of the DSL


The four primary components of the DSL model are:

Product Dictionary (PD)A Product Dictionary entry represents the


normalized name of an application or software item that has been authorized to
be available for release to the production environment. The normalized name of
an application or software item consists of the product name, manufacturer,
version, and patch.

Associated filesA list of files that are executed or referenced in support of


the application.

Software Library Items (SLIs)Location or storage of media.

Suite definitionApplication suites are bundles of software and can consist of


one or more entries in the Product Dictionary. For example, the Microsoft
Office is suite consists of the software items Word, Excel, PowerPoint, and
Outlook. Suites are represented as entries in the Product Dictionary.

133

The following diagram provides a high-level illustration of how these components


are organized as part of the DSL.

The Definitive Software Library (DSL)


Product Dictionary

Product Name
Version
Patch
Manufacturer

Software Library Item


S/W Library Item
Software
location
Location
information
Information
Suites
Products
related
Related
to a Suite
suite
Files
List of
related
Related
files
Files

The Product Dictionary is the parent object in the DSL. The Software Library Item
to Suite cross-reference and related files table are all children of the Product
Dictionary. A DSL entity is defined by the Product Dictionary record and all the
corresponding related information stored in the Software Library Item, suites, and
files table.

ERDs
The following ER diagram represents the data model of the BMC DSL. The items
in blue are unique to the DSL model. The items in white are part of the ITSM
foundation and are shared by ITSM applications.

134

ModelVersionPatch
-PIID
+PMVIID
+PatchLastBuildIn
1
D

Company
- CIID
+ Company
+ Type

Product
- PIID
+ CIType
+ ProductCat
1
+ ProductCat
2
+ ProductCat
3

Version
-VIID
+ PIID
+ PMV State
+ Product Name
+ Manufacturer

n
n

ProductCompany
-A
PIID
+ CIType
+ ProductCat
1
+ ProductCat
2
+ ProductCat
3

.
1

1
1

ProductModelVersion
- VIID
- PIID
+ CIType
+ ProductCat
1
+ ProductCat
2
+ ProductCat
3
+ PMV State
+ Product Name
+ Manufacturer

ProductDictionary
n
-VIID
-PIID
+CIType
1
+ProductCat
1
+ProductCat
2
+ProductCat
3
+PMV State
+Product Name
+Manufacturer

n
Suite
_PD Lookup

Legend
Foundation Objects

SLI

-SLIIID
+VIID
+Description
+Type
+State
+Location

PV_Files Lookup
+VIID
+FileID

Attachments
-Attachment
+DSL IID
IID
+Description
+Attachment

+SuiteIID
+VIID
Vendor Version
- VVIID
+ Description
+ VersionString
+ ComponentNam

ProductDictionaryPatc
h
-PMVIID
-ProductIID
-PatchIID
-.
-.
-.

n
Files
-FIID
+Name
+FileSize
+CRC
+TimeStamp

PD/DSL Objects
Only required fields are represented
.

The fields to be represented in a Product Dictionary entry depend on the fields


currently in the PCT:Product Catalog form and additional fields needed to support
data from a third-party vendor.
The PCT:ProductCatalog and PCT:Product Model/Version forms include DSL
specific fields. The join of these two records is the intermediate form
PDL:ProductModelVersion.
PDL:ProductDictionary is the join between the PDL:ProductModelVersion and
PCT:ProductCompanyAssociation forms.
PDL:ProductDictionaryPatch is the join between the PDL:ProductDictionary and
PCT:ModelVersionPatch forms.
PCT:ModelVersionPatch is the normalization of the patch information to the
CFG:ModelVersion form.
PDL:ProductDictionaryPatch is the table used to represent the Product Dictionary
entries in the DSL console.

135

PCT:ModelVersionPatch
PK
PCT:Product Catalog
PK

PCT:ProductCompanyAssoc

Instance ID

PK
Add DSL Fields

ProductID
CI Class
ProductCatTier 1
ProductCatTier 2
ProductCatTier 3
Product Name
Manufacturer
Price
Product 's Image

Product Name
Model Version
PatchLastBuildID
MainExeID
MainExeName

InstanceID
ProductIID
Company

JOIN

Origin
IsSuite

JOIN

PDL:ProdDictionaryPatch
PK

PDL:ProductModelVersion
PCT:Product Mod/Version

PK

Add DSL Fields

Instance ID
PMV ID
Product IID
ProdMod Vers
PMV State
Product Name
Manufacturer
PatchLastBuildID
ManufacturerPartNo
GeneralAvailDT
DiscAvailDT
DiscSupportDT
PreReleaseDate

Product ID
PMV ID
ProductIID
ProdModVer
PMV State
ProductName
.....
OS
Locale
Platform
VersionMajor
VersionMinor
VersionBuild
VersionMaint

GUID
OS
Locale
Platform
VersionMajor
VersionMinor
VersionBuild
VersionMaint
ManufacturerID

VersionIID
ProductID
CI Class
ProductCatTier 1
ProductCatTier 2
ProductCatTier 3
ProductName
Manufacturer
ManufacturerID
GUID
OS
Origin
IsSuite
Locale
Platform
PMV State
ProductName

InstanceID

PatchIID
ProductID
CI Class
ProductCatTier 1
ProductCatTier 2
ProductCatTier 3
ProductName
Manufacturer
ManufacturerID
GUID
OS
MainExeID
MainExeName
Origin
IsSuite
Locale
Platform
ProductID
PMV State
ProductName

JOIN

PDL:ProductDictionary
PK

PK

Instance ID

Data example
Model/Version Patch
VIID

Patch

PA1

2.3

V3

PA2

1.0

V1

Product
Company
Association

PatchIID

V2

Company/Manufacturer

PA3

0.0

CIID

Name

State

C0

-Global-

--

C1

...
MS

WA

PIID

Company

VIID

PIID

PatchIID

C2

...
Dell

TX

PD1

-Global-

V2

...
PA1

PA1

PD2

-Global-

V3

PA2

PA2

PD3

-Global-

V1

PA3

PA3

Product Dictionary (Join)


PIID

PD1
PD2

CIID
C1
C1

Origin
rd

3 Party
3rd Party

VIID

PD1
PD2

Product Catalog Base


PIID

ProductDictionaryPatch
(Join)

Name

CIID

V2

Word

C0

V3

Excel

C0

PD3

V1

Outlook

C0

PD4

... ... ... ...


V4
Office

Is Suite
No
No

Product Model/Version
(Join)

PD3

C1

3rd Party

No

PIID

VIID

PD4

C1

3rd Parth

Yes

PD1

V2

C0

Name
Word

PD2
PD3
Model/Version Base
VIID

PIID
PD3
... ... ...
PD1
... ... ...
PD2

4.2

V4

... ... ...


PD4

Office

FIID

SuiteIID

Location

SLI1

...
PA1

Shelf

F3

SLI2

PA2

Shelf

SLI3

PA3

Disk

V2

PDIID

PD4

PIID

F1

VIID
Suite Mapping

SLIID

PD3

V1

3.0

V3

V4

Outlook

4.0

V2

V1

Excel

Version

V1

PD4

F
V3

Software Library Item

Files Lookup

... has .../... has ...


PD4
PD2
PD4

PD1
Files

KBVersion
VVID

Version

KB1

1.0

...KB2 .../... has ...


has
1.3

136

Name

File Size

F1

Word.exe

3784

F2

F
Excel.exe

1816

F3

6.0

FIID

Outlk.exe

2590

Interfaces
Three interface tables support submit, modify, and query operations performed by
external systems.
The following are the interface (staging) forms for the DSL:

PDL:SLIInterface_CreateStaging form that interfaces to the


PDL:SoftwareLibraryItem form. This form is used for creating Software
Library Item entries.

PDL:SLIInterfaceSelf-join form of the PDL:SoftwareLibraryItem form. This


form is used for query and modify operations.

PDL:PDInterfaceSelf-join form of the PDL:Product Dictionary form. This


form is used for query and modify operations.

The interface (staging) forms contain all necessary fields from the interface form
that will be input from an external source.

137

Software Library Item submit

ITSM
External
application

Creates staging
record using
Product
Dictionary web
service

PDL:SLIInterface_Create
(staging form)

PDL:SoftwareLibraryItem

Processes
incoming
parameters

Data flow direction

Web services
Web services interfaces allow for programmatic access to the individual
applications and subsystems.

Product Dictionary
The following functions enable web service operations for the PDL:Product
Dictionary form using the PDL:PDInterface interface form:
PD_QueryList_ServiceQueries using a qualification statement for
multiple Product Dictionary entries in the PDL:ProductDictionary form.
PD_QueryListFields_ServiceQueries specifying field values to search on
for multiple Product Dictionary entries in the PDL:ProductDictionary form.

Product Dictionary Patch


The following functions enable web service operations for the PDL:Product
Dictionary Patch form using the PDL:PDPInterface interface form:
PDP_QueryList_ServiceQueries using a qualification statement for
multiple Product Dictionary Patch entries in the
PDL:ProductDictionaryPatch form.
PDP_QueryListFields_ServiceQueries specifying field values to search
on for multiple Product Dictionary patch entries in the
PDL: ProductDictionaryPatch form.

138

Software Library Item


The following functions enable web service operations for the
PDL:SoftwareLibraryItem using the PDL:SLIInterface interface form:
SLI_Modify_ServiceModifies a Software Library Item entry in the
PDL:Software Library Item form.
SLI_Query_ServiceQueries for a Software Library Item entry in the
PDL:Software Library Item form.
SLI_QueryList_ServiceQueries using a qualification statement for
multiple Software Library Items in the PDL:Software Library Item form.
SLI_QueryListFields_ServiceQueries specifying fields values to search
on for multiple Software Library Items in the PDL:Software Library Item
form.

The following function enables web service operations for the


PDL:SoftwareLibraryItem using the PDL:SLIInterface_Create interface form:

PDL_SLI_Submit_Service
Creates a Software Library Item entry in the PDL:Software Library Item form.

The following table summarizes web services information:

Base form and type

Operation
description

PDL:Product Dictionary
Patch

Query list of
entries

PD_QueryList_Service

PDL:PDInterface

PD_QueryListFields_Service

Query list of
entries

PDP_QueryList_Service

Query field list

Self-join

Interface form

Query field list

PDL:Product Dictionary

Operation name

PDP_QueryListFields_Service

Create SLI

PDL_SLI_Submit_Service

PDL:SLIInterface_Create

Modify SLI

SLI_Modify_Service

PDL:SLIInterface

Query for
specific SLI

SLI_Query_Service

Query for list


of SLIs

SLI_QueryList_Service

Query field list

SLI_QueryListFields_Service

PDL:PDPInterface

Self-join

PDL:SoftwareLibraryItem
Regular
Self-join

139

Permission model
DSL has the following permissions:

Level 1DSL Administrator: Access to add and modify Product Dictionary


and Software Library Item definitions.

Level 2DSL User: View access to Product Dictionary and Software Library
item definitions.

Requester Console and SRMS framework


The Requester Console is supported by the Service Request Management System
(SRMS) framework, which implements the service request component for
integration to the back-end Change Management and Incident Management ITSM
7.0 applications. The service request entity serves as a bridge and is not designed to
be managed by service desk personnel. It is a slave to the back-end change
request or incident with its lifecycle completely driven by the back-end. The base
form, SRM:Request, is hidden, except for system troubleshooting when it fails to
communicate with the back-end. The Requester Console is the front-end entry point
for users to submit requests.

Requester
Console
Request object
Obj t
SRMS framework
Framework

OR
Change
Management

140

Incident
Management

Requester Console
The Requester Console is a simplified interface for users to submit change requests
and incidents, similar to the Requester interface in ITSM 6.0. This allows users to
submit requests into the system from a single console, without having to directly
access the Change Management or Incident Management consoles. The targeted
audience is non-IT user requesters.

Architectural overview

The Requester Console uses the existing framework designed for SRMS, which
provides a structured mechanism to integrate back-end applications, such as
Change Management and Incident Management. A set of user interfaces is targeted
for user requesters to submit, view, and update their requests. It also provides
configuration entry points for the SRMS framework on the Application
Administration Console and exposes the framework Service Request form for
troubleshooting. The Request Console is a separate deployable application, but is
dependent on the SRMS framework and does not function independently. It
requires Change Management or Incident Management to be installed. User
requests are managed completely by the back-end applications in the form of a
change request or an incident. The service request entity is not intended to be
managed by support personnel, except for system trouble-shooting. The Requester
Console is a user interface component to the SRMS framework and the integration

141

components from the back-end applications or other systems, like Service Level
Management (SLM) is to the SRMS framework.
Primary components

This section focuses on the components of the Request Console and their function
in enabling the front-end interactions. Two categories of forms support the
Requester Console: configuration and runtime. Configuration forms are accessed
using the Application Administration Console, and are designed to maintain data
that affects the behavior of the Requester Console. Runtime forms serve two
purposes: as the interface, or to capture data from users when they use the
Requester Console.
Category

Component

Description

Configuration

SRM:ApplicationSettings

Contains records to determine the settings for the


Requester Console and the SRMS framework.
This data includes settings to:
Specify the server tenancy mode.
Allow unknown users.
Supply default submit data for unknown users.
Supply default request ID text.
Enable the Requester Console.
Supply AR System logins for access to Change
Management and Incident Management.
This form has one entry and it can be modified, but not
deleted. No additional entries are allowed.

Configuration

SRM:CFG Rules

Contains records to determine the service request rules by


company. These rules include settings for auto-close,
survey, and individual auto-assignment.

Configuration

SRM:ConsolePreferences

Stores preferences for console behavior.

Configuration

SRM:ConfigSurveyQuestions

Stores the survey questions that are associated to a


request when it reaches the Complete state. A survey
can be set up by Request Type (Incident or Change), and
by Company, including Global, which is applied to all
companies. One to five survey questions can be
configured.

Configuration

Requester
Console:SummaryDefinition

The summary definitions provide the menu items for the


Summary menu in the New Request form. It predefines the
summary text, operational categorization values, and the
type of back-end request (change or incident). These
values are used to create service requests, which then
create the back-end requests, depending on the request
type. Each summary record must be unique by Summary
and Company fields, using filter workflow validation.

142

Category

Component

Description

Runtime

Requester
Console:RequestConsole

Serves as the entry point for users and supports their


primary interactions. It provides the user interface for
submitting and viewing requests.

Runtime

SRM:ServiceRequestWizard

The Request Wizard provides a simplified interface for


users to create and submit a request. This form is a
display-only dialog box in which users provide required
information to complete the request.

Runtime

SRM:Request

The Requester Console submits a record into the SRMS


framework form, SRM:Request, when creating a new
request. The SRMS framework implements the workflow
and logic to create the back-end change request or
incident for the Submit action on the SRM:Request form.
The SRMS framework also synchronizes the data and
status with Change Management or Incident Management.
The Requester Console only displays the information for
the user requesters.

Runtime

SRM:WorkInfo

Contains information associated with the user request,


which could be attachments or general text summaries.
Users can view Work Info entries using buttons on the
Requester Console.

143

Category

Component

Description

Runtime

SRM:Survey

When a request reaches a Complete status, a survey is


generated. Required information from the request is
pushed into the SRM:Survey form to create a new survey.
Filters on the Survey form get the questions from the
SRM:ConfigSurveyQuestions form, based on input
parameters from the SRM:Request form.
Survey data model diagram
1. New request
submitted

2. Creates
incident

4. Completed
request

3. Incident
resolves

Survey
rules

5. Survey sent

SRMS framework
The SRMS framework provides a bridge between the front-end user requests and
the back-end operations. In ITSM 7.0, integrations are implemented to Change
Management and Incident Management. However, the SRMS framework provides
a structure that can be connected to any other open back-end solution.
The design of the SRMS framework is based on the following goals:

Act as a bridge between the Requester Console front-end interface and Change
Management and Incident Management back-end applications.

144

Segment front-end transactions from back-end transactions.

Support synchronization between the front-end interface and back-end object


life-cycle.

Establish a foundation to support integration to back-end systems.


Integrate to Change Management and Incident Management as the back-end
applications.
Provide a mechanism for establishing field mappings between the request
entity and change request or incident, for request creation.
Provide CAI as a bi-directional communication mechanism for back-end
integrations.

Integrate with SLM for requester-focused service level agreements (SLA)


tracking.

Architectural overview

The architecture contains the following modules:

SRMS administration

Summary definition

Service request

Associations

Flows

Application object templates

Application object instances

Additional questions and answers.

A simplified model has been implemented for ITSM 7.0. A request maps to a single
back-end application request. A one-to-one relationship between the request and the
back-end object will trigger the fulfillment process. However, the SRMS
framework is architected to support a more comprehensive and flexible model, with
the use of the flow, association, and question components. These components will
be more fully leveraged in a future release of the Service Request Management
solution.
Following is a top-level diagram that shows the dependency and integration points.
Note that Change Management and Incident Management are integrated with the
SRMS framework, but are dependent on the CAI, which is the mechanism that
communicates with the SRMS framework.
One of the primary uses of the SRMS framework in ITSM 7.0 is to provide a means
for bi-directional synchronization between the front-end request and its related
back-end application request. The SRMS framework includes command and
command parameter definitions stored in the CAI:Command and
CAI:CommandParam forms as part of SRMS framework configuration data. These
event commands are used to communicate to the back-end applications for request
creation, updates, and synchronization activity. The type of information being
synchronized includes status updates and work log activities.

145

Change Management and Incident Management integration


Change Management and Incident Management use SRMS framework command
events to communicate to and from the Requester Console using the CAI
component. Areas where these components are used include the following
examples:
From the SRMS framework to:

Create change requests or incident requests.

Send work info entries.

Cancel or reopen requests.

From Change Management and Incident Management to the Requester Console to:

Update request status (In Progress, Completed, Canceled, or Rejected).

Send Work Info entries.

Update request assignee and manager data.

Update SLM response status.

For Outbound commands, the SRMS framework communicates with Change


Management and Incident Management through the interface forms. For Inbound
commands from Change Management and Incident Management, the CAI:Events
and CAI:EventParams forms are used for all updates. However, the service request
interface form is used for inbound create service request commands.
SLM integration
Integration to SLM is linked to the SRMS framework SRM:Request form for SLA
tracking to requesters. Milestone and action templates are provided for notifications
to SLA owners when the goal is close to being missed. SLA owner values come
from the back-end change request (from change managers) or incident (from
incident owners).
Note: The SRM:Request form does not assign owners to the request.
Primary components

The Requester Console and the SRMS framework are divided into three major
areas: configuration, definition, and execution.

146

In the configuration area, summary definitions are set up to communicate with


the back-end application requests. For Change Management 7.0 and Incident
Management 7.0, two system configuration forms must be pre-populated to
work with the Requester Console front-end.
In the definition area, summary definitions are established to determine whether
a change request or incident back-end application request will be instantiated
when the request is submitted. The request object has additional associations to

service level agreements. For more information about definition options, see
the BMC Remedy IT Service Management 7.0 Configuration Guide.

In the execution area, requests for a summary definition are handed off to the
SRMS framework and the back-end application objects are instantiated to
fulfill the request. The application objects are managed by the respective backend application system with their own life cycle. The request has a simple life
cycle with additional associations to service level agreements.

The following table lists the primary components that support the SRMS
framework:
Component

Description

SRM:Request

Request form

SRM:AppTemplateBridge

The Application Object Template stores information about the back-end


application request and acts as a stub in the definition area of the SRMS
framework. It is used to instantiate an Application Object Instance when a
definition is selected as a request during the execution phase.

SRM:AppInstanceBridge

The Application Object Instance is instantiated when a summary definition


is selected as a request. It stores information about the back-end
application request and its status information. The status includes status
values that affect the lifecycle of the service request. The status transition
is triggered by certain actions or events from users or from the system.
This is a back-end form and is accessible only by AR System
administrators.

CAI:AppRegistry

This form is used to register back-end applications that are integrated with
the SRMS framework. It contains the template form name, the request
form name, and connection data, such as server name, login, and
password.

CAI:Commands

Command list form.

CAI:CommandParams

Parameter list form.

CAI:CommandParamsMapping

To facilitate communication between the SRMS framework and back-end


applications, mappings must be defined between SRMS framework
command parameters and back-end application specific fields. This
mapping is defined per registered application in the Application Registry
for each command parameter.

CAI:Events

The events table is used to communicate SRMS framework related


events, such as back-end application request creation notifications or
status changes.

CAI:EventParams

Stores the parameters for event command instances

srmeventcmd.dll

Event Command Filter API (binary).

Mapping data to the back-end applications is required for the SRMS framework to
create back-end requests and to send update information. All mapping data is

147

shipped with Change Management and Incident Management as part of the system
configuration and should not be changed.
Data is included to:

Register the back-end application with the CAI component


(CAI:AppRegistry)Contains access information to the back-end application.
For AR System applications, it also contains the form names for template,
interface, and instance forms.

Register application fields (SYS:Form Field Selection)Identifies application


fields from the application interface form for question template mappings and
command parameter configuration.

Configure command parameters (CAI:CommandParamsMapping)Maps


fields from the application interface form to SRMS framework command
parameters. The mapping definition is used by the SRMS framework when
sending events to the back-end application interface form. The command
parameter values are copied to the fields specified by the field ID in the
mapping.

Define additional questions (SRM:QuestionTemplate).

Configure question template mapping from SRMS framework fields to backend requests for request submission.

ERDs

In the following ERD diagrams, the arrows point to the form that stores the foreign
keys. For example, ARInstanceID (called out as FK:SRInstanceID) from the
SRM:Request form is stored on the HPD:Help Desk, CHG:Infrastructure Change,
SRM:WorkInfo and SRM:AppInstanceBridge forms. The SolutionRequestID from
the PBM:Solution Database form is stored on the SRM:Request form.

148

PBM:Solution
Database

SRM:AppInstanceBridge

SRM:Survey
FK:SRInstanceID
FK:SolutionRequestID

RQC:Summary
Definition

FK:TitleInstanceID

FK:Originating_Request_InstanceID

FK:SRInstanceID

SRM:WorkInfo

SRM:Request
FK:SRInstanceID
Region/Site Group/Site

Operational Category
Requested By
Requested For
Manager
Assignee

CFG:Service
Catalog

HPD:Help Desk
CHG:Infrastructure
Change

COM:Company

CTM:Region

CTM:Support
Group

SIT:Site Group

CTM:People

SIT:Site

149

The following diagram illustrates how the SRM:AppistnaceBridge form is used to


relate event commands with the corresponding request and the change request or
incident records.

FK:SRInstanceID

SRM:AppInstanceBridge

FK:SR_KnoweldgeDatabaseID

FK:AOIGUID

PBM:Solution
Database

HPD:Help Desk
FK:AppRequestInstanceID

CAI:Events

SRM:Request

CHG:Infrastructure
Change

FK:EventGUID

CAI:EventParams

Integration Flow

The request object is the main artifact associated with the execution phase of
SRMS. A user can submit a request using the Requester Console wizard.
After the request is submitted, based on the selected summary definition, a backend application request is created and the field values are pushed according to
question template mapping. The summary definition defines the summary text,
categorization values, and request type, which is either Change or Incident.
Instantiation
Instantiation refers to creation of back-end requests and related SRMS framework
objects when a request is submitted. When the request is created from the
Requester Console, it is either a Change or Incident request type. By definition,
only one Application Object Instance is created. The Application Object Instance
has a one-to-one relationship to the request and is instantiated on the Submit action.
When a request is submitted and the Request Type is Change or Incident, the
following occurs from filters on Submit action for the SRM:Request form:
1. A lookup of the Change Management or Incident Management application in
the CAI:AppRegistry form is executed by a fixed application instance ID value.
This value is from the SHARE:ApplicationProperties form.
2. An Application Object Instance record is created with the CM or IM registry
instance ID, and SR instance ID with CREATE command and flag ADHOC.

150

ADHOC means create the Application Object Instance and the back-end
request.
3. The Application Object Instance has filters that execute upon the CREATE
command to create the back-end change request or incident. Connection
information and interface form names are looked up in the CAI:AppRegistry
form and copied to the Application Object Instance record.
4. The Event SRM_OUT_CREATE_APP_REQUEST event is created in the
CAI:Event form and relevant values from SR fields and command parameters
are created in the CAI:EventParams form.
5. A filter is executed on the Event form, which triggers the CAI plug-in to send
the event to the back-end application.
6. The CAI plug-in sets the return code and message on the Event record.
If the return code is updated to OK, a filter is executed on the Event form,
which triggers a status change on the Application Object Instance sender to
Created. The Request status is set to Staged. If the application request
requires activation (New Request Activate = Yes), the
SRM_OUT_ACTIVATE_APP_REQUEST event command is created in the
CAI:Event form.
If the return code is updated to Error, a filter is executed on the Event form
that triggers action field on Application Object Instance to
EVENT_ERROR. This triggers the Modify filter on the Application Object
Instance form to set the SR App Event status field to ERROR. Notification
is sent to users in the Request Master group when an error occurs.
The Application Object instance queries secondary forms to build the event
commands. These forms include the CAI:Command,
CAI:CommandParamsMapping, and SRM:QUTJoinSRGJoin forms.

151

The following diagram shows the instantiation process:


Request instantiation diagram
SRM:AppInstanceFlow (NOT
USED in RQC)
Service Request Instance ID
SRM:AppInstanceBridge
Predecessor Instance ID
Successor Instance ID (AOI)

1. Tells Start Flow to


start work.

SRM:Request

7. Sets return code = <OK, Warning, Error>


Return msg = warning or error msg

Service Request Instance ID


SCO Instance ID
2. Create successor AOI

SRM:AppInstanceBridge

3. Create event
and event
param entries.

Service Request Instance ID


AOI Instance ID
Application Registry Instance ID
Flow information
Question-response
linked to service request.
SRM:Service
RequestQuestionAssociation
(NOT USED in RQC)
AOI Instance ID
Question Response Instance ID

When SR status = New;


status reason = AI Creation,
Create the event and event
params.

CAI:Event

Field-value pairs come from


question-response pair.

Service Request Instance ID


Question Instance ID
Question
Answer

CAI Plugin

5. CreateEntry to application interface


Field-value pair linked to event

SRM:QuestionResponse
(NOT USED in RQC)

4. FilterAPI invoked

Event Instance ID
Event Type=CreateAppRequest
AOI GUID=<AOI Instance ID>
SRMS Server=<SRMS server name>
App GUID=<Application ID >
App Server=<Application server name>
App Interface form = <App interface form
name>
Source=SRMS
Return code = empty
Return msg = empty

CAI:EventParams
Event Instance ID
Param Name=<field id>
Param Value=
Type=<In, Out Qual>
Data Type=<Character, Attach>

App interface entry field values


come from event params
Application Interface
(ChangeInterface_Create)

6. Submit to application instance


(if app interface != app instance form)

CAI:AppRegistry
Registry Instance ID=
Registry Name=
Description=
App Template Form=
App Template View Form
=
App Instance Form=
App Interaction Form=
Access Mode=<Local, Remote>
Server=
Login/password=

Application Instance
(CHG:Infrastructure Change)

Status Synchronization
The request object uses event commands to synchronize the status with the
application requests. The back-end application must send status-related events to
the SRMS framework by creating entries in the CAI:Events form. Workflow is
implemented in the sample application to illustrate this mechanism.
Interfaces

Create request interface


The SRM:RequestInterface_Create form is a regular form that is an interface form
for the SRM:Request form. It supports external systems in creating new requests
programmatically or by AR System workflow. For example, requests can be
created automatically when a change or incident request is created from the backend application using the SRM:RequestInterface_Create form. A function is
available using Change Management and Incident Management that allows the
back-end support user to generate a request object that is linked to the current
change request or incident. This allows the requester to access their requests from

152

the Requester Console, although the request was submitted from Change
Management or Incident Management support personnel. This is useful for requests
from users who do not have access to Change Management or Incident
Management.
CAI plug-in
The CAI plug-in is used to transmit SRMS framework events to back-end
applications. A plug-in is used due to the dynamic nature of the field mappings for
each command and the potential for incompatible permission models. For example,
the command to create a back-end request consists of dynamic field values that can
be mapped to any field on the back-end interface forms, where it is not possible to
use workflow to push values to dynamic fields. Additionally, if the back-end
application is on a remote server from the front-end application, such as the SRMS
framework, a different AR System login is required for the plug-in to log in to the
remote server. This login information must be specified in the per event record.
Outbound commands (such as CreateAppRequest)
Service Request
SR GUID
Status
Cost

Event

AOI
SR GUID
AOI GUID
App Registry
AOI Status
App Instance GUID
App Instance ID
App Instance Description
App Instance Status
App Instance Cost

2. Create outbound
create entry
8. Notify AOI that
command is done
9. Update event
status=Complete

3. Create the event parameters using


the fields setup from command
configuration and by using responses
to the questions to map the values into
the application interface/instance fields.

Event GUID
Event Command
Event Status
Protocol (AR)
SRMS Server
AOI GUID
Reg App Server
Reg App Interface (Form)
App Instance GUID
Return Code
Return Message (Error)

Event Parameter
Event GUID
Event Parameter GUID
Parameter Name
Parameter Value

4. Call Filter API


7. Return code,
Return message

Filter API
In: Reg App Server, Event
Form, Event Param Form,
Event GUID
Rtn: Return Code, Return
Message

5. AR API Call

App Interface

Template ID
SRMS Server
SR ID
AOI GUID
...
6. Create/update/query
entry in app instance
App Instance
...
SRMS Server
SR ID
AOI GUID
...

153

Permission model

The SRM:Request form has the following permissions:

PublicHidden

Request MasterVisible

SRM:Request contains levels of permissions:

Request Master

Assignee Group

Unrestricted Access

General Access

Submitter

The following tables lists the permission roles and groups for the SRMS framework
and the Requester Console.
Requester Console application permissions
AR System
group or role

Map to group

Comments

Summary
Definition Config

Summary Definition
Config Computed

Provides create, view, and modify access to Requester


Console:SummaryDefinition.
Note: General Access is needed for modify access.

N/A

Summary Definition

Base group for Summary Definition Config Computed.

Requester
Console Config**

Requester Console Config

This group is part of the Request Config Computed


group.
Provides create, view, and modify access to:
SRM:CFG Rules
SRM:Application Settings
SRM:ConfigSurveyOptions
Requester Console:SummaryDefinitions
Menu access to the Administrator Console for the
Requester Console.

Note: General Access is needed for modify access.

154

AR System
group or role

Map to group

Comments

Requester
Console
Master**

Requester Console
Master

This group is part of the Request Master Computed


group.
Provides access to:
View the SRM:Request form for troubleshooting.
CAI Event Dialog and retry events.
Create and view the work log from the Service Request
form.
Request Configuration

General Access

General Access**

Provides access to all general users who require modify


permission.

Unrestricted
Access

Unrestricted Access**

Bypasses row-level access for multi-tenancy. See


Assignee group.

Submitter*

N/A

Provides:
Row-level view access to SRM:Request records
submitted by that user from the Requester Console.
Create and view access to the work log from the
Service Request form.

Assignee Group*

N/A

Provides row-level access based on the Company field.


Applies to summary definitions and broadcast messages.

Public*

N/A

Provides access to the Requester Console and all the


related display forms.

Note: AR System Guest public users have access to global


summary definitions and broadcast messages.

155

SRMS framework application permissions


AR System
group or role

Map to group

Comments

Request Config**

Request Config Computed

Provides create, view, and modify access to:


SRM:CFG Rules
SRM:Application Settings
SRM:ConfigSurveyOptions
Requester Console:SummaryDefinitions
Menu access to Application Administration Console for
Requester Console.

Note: General Access is needed for modify access.


N/A

Request Config

Base group for Request Config Computed. Also part of


the Summary Definition Computed group.

Request
Master**

Request Master
Computed

Provides access to:


View the SRM:Request form for troubleshooting.
The CAI Event Dialog and retry events.
Create and view the work log from the Service Request
form.
Request configuration.

N/A

Request Master

Base group for Request Master Computed. Also part of


the Command Event Master Computed group.

General Access

General Access

Provides access to all general users who require modify


permission.

Unrestricted
Access

Unrestricted Access

Bypasses row-level access for multi-tenancy. See


Assignee Group.

Submitter*

N/A

Provides row-level access to SRM:Request records


submitted by that user ($USER$).

Assignee Group*

N/A

Provides row-level access based on the Company field.


Applies to SRM:Request records.

Public*

N/A

Provides general access. Access granted to this group is


granted to all users.

*Public, Submitter and Assignee Group are implied AR System groups; no Group
or Role entries are required.
**General Access and Unrestricted Access are foundation AR System groups.
These groups are shipped with the Foundation application.

156

SRMS framework computed groups


The SRMS framework uses computed groups for Request Config and Request
Master permissions so users can be granted Requester Console permissions instead
of using SRMS permissions directly.
Computed group

Comments

Request Config Computed

Computed group for Request Config


Equals Request Config or Requester
Console Config

Request Master Computed

Computed group for Request Master


Equals Request Master or Requester
Console Master

Requester Console computed groups


The Requester Console has one computed group for summary definition
configuration. This is set up to allow granting of summary definition permission to
Change Config or Incident Config permission indirectly.
Computed group

Comments

Summary Definition Config


Computed

Computed group for Summary Definition


Config.
Equals Summary Definition Config or
Request Config or Change Config or
Incident Config.

Task Management System


The primary goal of the Task Management System (TMS) subsystem is to provide
a mechanism to support repeatable processes. The result is improved productivity,
reduction in novice errors, and a clear way to define business processes.
The Task Management System introduced in ITSM 7.0 significantly enhances the
capability of the task operation of previous releases. In addition to the predecessor
and successor relationship, TMS supports branching and multiple paths, along with
data exchange between tasks. TMS also supports integration with external systems,
primarily using the Command Automation Interface (CAI) subsystem.
The following sections present the architectural structure of TMS. See the BMC
Remedy Task Management System 7.0 Administrators Guide for information about
user features, configuration, and administration of the system.

157

Architectural overview
The fundamental building blocks of TMS can be divided into two primary areas:
Definition and Execution/Runtime. Definition consists of templates that are
leveraged during runtime. When a template is selected to be executed, the template
and associated templates that are grouped with it are instantiated as a single unit.
This results in a single runtime instance of that template group. Following are
descriptions of the primary definition and runtime components of TMS.
Definition

Definition consists of a Container object task group, associations, flows, and


templates that establish the relationships and hierarchy between corresponding task
templates.
Component

Description

Task Group templates

The Container object is the parent object that manages related associations
and flows of its children objects.

Association templates

Associations define the task templates that are related to or grouped under the
Task Group template.

Task templates

Task templates define the purpose of tasks.

Flow templates

Flows determine the sequence and dependencies between the associated


task templates.
Execution/Runtime

Execution consists of the Container Object task group, associations, and flows that
establish the relationships and hierarchy between corresponding tasks. The process
to transform a task group template (the definition phase) to a task group (the
execution phase) is called instantiation. Therefore, the corresponding entities for
the templates defined during runtime are task groups, tasks, flows, and associations.
The Variable pool is a structure that facilitates information passing between tasks
and flows.
The following diagram provides a high-level view that illustrates typical
relationships among the TMS components previously defined.

158

Flows
Associations

Container
Object

Container
Object

Data Flows

Task Group
Container
[0]

Task Group
Template
[0]

OR
Application Object
Instance

Application Object
Template

Task
[A]

Task
Template
[A]

Application Object
Template

AND
Application Object
Instance

Application Object
Template

Task
Template
[B]

Task
[C]

Task
[B]

Task
Template
[C]

Application Object
Instance

Application Object
Template

Task
[D]

Task
Template
[D]

Name

Variable Pool

Application Object
Instance

Value

Scope

Location
Contact
Phone
Closed Tasks

Sunnyvale

Local

TBD
2

Feature Set
Related Items
Automated Tasks
Launch
Pass data betweenAOIs
Reference Other Form
Shared Work

Local
System

Instantiation
To facilitate planning for the task process, all tasks and task groups defined in the
definition are created in advance after a task group template is selected from the
definition set. This model is referred to as Instantiation.
In the Instantiation model, all potential tasks, task groups, and flows defined
between them are created in advance. This approach allows task owners to review
the whole process before the execution phase.

159

Definition

Execution

Task Group Template 1

TaskTemplate 1

F1

Task Template 2a

Task Group 1

F2

Task 1

F1

Task Template 2b

F2

Task 2a
F4

F3

Task Template 3a

TaskTemplate 3b

Task 2b

F4

F3

Task 3a

Task 3b

F6

F5

F6

F5
Task Template 4

All templates in this task group template are configured to be


executed in the order of flow F1 to F6.

Task 4

All tasks and task group and flow created in advance with
Status = Staged and State = Inactive
Parent Object starts the task process by activating the initial
task or task group.

The process remains inactive (Status = Staged AND State = Inactive), and no
work can be performed on these tasks except adding or changing the task attributes
such as the description, name, classification, and so on. The parent object starts the
process by activating the initial tasks or task groups.
The order of execution between tasks and task groups is enforced by the defined
flow. The successor tasks or task groups are activated (State = Active) when the
predecessor tasks and task group are completed.

160

Execution
Task Group 1

Task 1

F1

F2

Task 2a

Task 2b

F4

F3

Task 3a

Task 3b

F6

F5

Task 4

The first task or task group is activated and ready for agent
to work on while others are locked until the predecessors
are completed.

The defined flow between tasks and task group drives the process of activating or
marking bypass of the next or successor, tasks or tasks groups. Bypass is a
status that indicates a task did not execute because the flow is defined so the task or
task group were not required, and therefore not executed.

161

Execution
Task Group 1

Task 1
Closed/Success

F1

F2

Task 2a
Closed/Success

Task 2b
Closed/Failure

F4

F3

Task 3a
Closed/Success

Task 3b
Bypaased

F6

F5
Task 4
Closed/Success

Task 1 completed successfully.


Task 2a, and 2b are activated. 2a success, but 2b failed.
Task 3a, activated then closed/success, then task 4 activated.
Task 3b is marked bypassed, because Task 2b failed.

Association model
The Association model defines relationships between major entities. Associations
in TMS are ordered in a parent-child relationship. The associations are stored in
two tables: Association Template (definition), and Association (runtime). The [n-n]
reference indicates a many-to-many relationship. The [1 n] reference indicates a
one to many relationship.
The following associations are stored in the Associate Template table:

[n-n] Application Parent template to Task Group template.


An Application Parent template (for example, a change request template) can
be associated to multiple Task Group templates. An example is a change
request template having a planned task group template, an execute task group
template, and a verification task group template.

162

[n-n] Task Group template to Task Group template. In this case, the first one is
the parent and the second one is the child.
[n-n] Task Group template to Task template.

The following associations are stored in Associate table:

[1-n] Application Parent instance to Task Group.


Note: An example of an Application Parent Instance is a change request.

[n-n] Task Group to Task Group. In this case, the first one is the parent and the
second one is the child.
Note: This is an n-n relationship because a Task Group can be the parent of one
or more Task Groups and also a child of one or more Task Groups.

[1-n] Task Group to Task.

On foreign keys:

The Task Group has a foreign key to the Parent Application instance.

The Task has a foreign key to the Parent Application instance.

An association entry for these relationships on the Association table and foreign
keys are needed because foreign keys are used for a quick lookup and to support
direction, while the association entries are used to facilitate navigation.

163

AT1

AT3
AT2

164

ASSOC1

ASSOC3
ASSOC2

Dependency model: flow mechanism


The flow mechanism defines the sequence and dependency between task templates
within a task group template, and between tasks within a task group.
Flow is a configuration process to determine how a task or task group is carried out
at runtime. For example, tasks and tasks groups can be carried out sequentially or
simultaneously.
Flow is defined based on the association between a task and task group. Flow
cannot be established if there is no association. In other words, association is
what other instances are related to current instance, and flow is how these
instances are executed.
A flow consists of one or more flow relationship records. Each flow relationship
record is capped by an inbound and outbound task object. The task object is either a
task template (definition), task (runtime), task group template (definition), or a task
group (runtime). The inbound task object to a flow relationship record is called the
predecessor. The outbound task object to a flow relationship record is called the
successor.
When you define a task group template, you can establish how the associated task
group template and task templates relate to one another. This is called flow, and
determines the sequence in which task groups and tasks are generated at runtime.
A task or task group can be executed simultaneously or sequentially. When the
flow is defined as sequence, all predecessors must be completed before the
successor task or task group can start.
The flow is also determined by the outcome of the predecessor. The resulting
output can be stored in the variables. The values in these variables can then be used
by workflow to decide the behavior of the flow. For more information, see the
following Data exchange model: variable pool section.
For example, in the following illustration the flow, represented by the diamond,
indicates that if Task 1 is flagged as successful, then Task 2 is activated. Otherwise,
Task 3 is activated.
Task 1

Success

Fail

Task 2 Task 3

165

Task Group

Task 1

Task Group

Task 2

Task 1

Task 2

Task 3

Example 1

Task 3

Example 2

The flow in Example 1 indicates that Task 1 and Task 2 could be started
simultaneously, and Task 3 will be started only when both Task 1 and Task 2
complete.
The flow in Example 2 shows all three tasks are in sequence. Task 1 needs to
complete before Task 2 can start. Task 3 will start only when Task 2 completes.
The execution order between task and task group is known as flow, which dictates
how the task or task group are executed at runtime. The flow configuration is
evaluated along with other advance settings, such as conditions, actions, and
behavior, when the task is completed (State = closed, success, failed, or canceled).
These advanced settings are an integral part of TMS and can be complex to
configure if you need to apply a more simple model to transition between tasks. For
example, in the previous versions of the ITSM applications, the primary model for
transitioning between tasks was simply specifying an order in which the tasks
would execute. ITSM 7.0 has a model called Sequencing that focuses on setting
the order in which tasks are executed. This is only an abstraction of the advanced
settings. The flow objects are used but the sequencing model establishes a strict
definition of how the flow objects should be configured.
To clearly distinguish these two approaches of defining how tasks and task groups
flow, Sequencing (Basic) and Standard (Advanced) modes are used. The Advanced
mode exposes all the flow configuration options, whereas the Basic mode is defined
as sequencing.

166

Sequencing (Basic) mode


In the Sequencing mode, users do not have to define the flow between tasks or task
groups. Instead a sequence number is used to specify the order in which tasks or
tasks groups are executed. Using the sequence number allows users to define the
ordering between tasks quickly, without going deeply into TMS to create the flow
for tasks.
For example, change request users can add three tasks from the list in a task
template, and then specify the order in which they execute as 1, 2, and 3. This is
equivalent to configuring a successor and predecessor model as
Start Task1 Task2 Task3. Task1 will execute first, followed by Task2, and
finishing with Task3.
The sequence for each task or task group entered by users is converted to a flow
definition in TMS. In the previous example, when three tasks are ordered as 1, 2, 3,
three flows are created automatically as follows:
Flow#1 : Start

Task1

Flow#2: Task1

Task2

Flow#3. Task2

Task 3

In the order that the tasks and task groups are executed, there is no functional
difference between this flow definition and the sequence model implemented in
previous versions of ITSM. To apply a strict sequencing model, certain
configuration settings are fixed.
The Sequencing (Basic) mode has the following fixed settings on the flow object
that cannot be changed:

Evaluate if Predecessor Failure? No

Evaluate if Predecessor Canceled? Yes

Flow to Successor when All Complete

With these settings, all tasks and task groups in the same sequence must be
completed before the tasks or task groups in the next level in the sequence can
begin. For example, in the following illustration, task 4, 5, and 6 (at sequence level
2) are activated only if Task 1 and Task 2 (at sequence level 1) are completed.
Sequence 1

Task 1, Task 2

Sequence 2

Task 4, Task 5, Task 6

Sequence 3

Task 7, Task 8, Task 9

167

Default sequence

When the task or task group is added, the default sequence is the next available
sequence level. For example, in the illustration that follows, if a Task 10 is added to
the list of existing tasks, then it would be set at sequence level 4.
Sequence 1

Task 1, Task 2

Sequence 2

Task 4, Task 5, Task 6

Sequence 3

Task 7, Task 8, Task 9

Sequence 4

Task 10

Changing the sequence

After a task is added, you can change the ordering using the sequence number.
Increasing the sequence number moves the task down the list. Decreasing the
sequence number moves the task up the list.
During runtime, the following rules make sure of the integrity of the process flow:

The sequence cannot move to a prior sequence level that is completed.

The sequence level cannot be changed on an active or completed task.

You can change the sequence number using the up and down buttons, or by setting
the sequence number directly in the corresponding column on the table field.
Note: Passing data values between Tasks or Task Groups is not supported while in
the Sequencing (Basic) mode. The system does not stop users from setting the
variable for a task or task group while in this mode. There is, however, no
assurance that this will work because the sequence can be changed, and the logic
for passing the data and variables between them might no longer be valid.
During definition phase, sequence and dependency information is stored in the
Flow template. During the execution phase, the association information is stored in
a separate Flow table.

168

Data exchange model: variable pool


The variable pool is a way for tasks to exchange data. This allows tasks to return
information and have the information passed to other tasks. Unlimited named
variables can be defined in a central repository of variables (or variable pool). The
named variables can be attached to a task group template, task template, flow
template, task group, or a task and flow. These attached entities can access the
variable values and assign values to the variables. Data exchange occurs when the

169

same variable is shared among these entities, such as a task group template, task
template, flow template, and so on.
In the configuration phase for variables, an administrator defines the variable that
will be used by the system. The variable definition consists of the variable name
and scope.
Variable scope

Definition

Local

The variable is available to the parent application


instance.

Global

The variable is available across different parent


application instances.

System

The variable is available to the parent application


instance, but is managed and maintained by the system.

When the variable is defined, it can be mapped to the task group template, task
template, and the flow template.
When the variable is instantiated, it will contain the data value, in addition to the
name and scope definition. These variables can be mapped to the task group, task,
and flow.
These variable definitions are stored in the Variable Template form. The
instantiated variable is stored in the Variable form.
Both defined and instantiated mappings for variables are stored in the Variable
Mapping form. A variable mapping has a direction characteristic of inbound or
outbound. When the instantiated variable is mapped to a task, the task reads an
inbound variable when work is about to begin for a task. When a task is finished, it
writes the value of the mapped outbound variable to the variable pool.

170

171

Complete example
During instantiation of a task group template, the task group and associated tasks
are created, based on the task group template definition. The flows and variables for
the tasks are also created.

172

ERD
Following is the entity relationship diagram for TMS.

173

Interfaces
In TMS, the TMS:TaskInterface interface form supports performing updates and
queries of a task by external systems. This form is a self-join of the main task form
(TMS:Task).

Web services
Associated data of the main Task form is exposed using web services. In addition to
the TMS:TaskInterface Task interface form, the TMS:WorkInfo and
TMS:Relationships regular forms are also exposed using the web services interface.
The interface structure consists of three components: the parent object and two
child objects. The parent object is represented by the TMS:TaskInterface form. The
associated child objects are Work Info and Related Items. In web services, these
three objects are rendered and presented as a single entity using the complex
mapping definition based on an XSD file. This single web services entity supports
the following primary interface operations:
Objects

Operation

Scope

Function name

Task

Update

Individual

UpdateTaskOnly

Query

Individual

QueryTaskOnly

Update Related

Individual Work Info

UpdateTaskAndWorkInfo

Update Related

Multiple Work Info

UpdateTaskAndWorkinfo

Create Related

Individual Work Info

UpdateTaskAndWorkinfo

Query Related

Multiple Work Info

QueryTaskPlusWorkInfo

Task and
Relationships

Query Related

Multiple
Relationships

QueryTaskPlusRelationships

Task,
Relationships,
and Work Info

Query Related

Multiple
Relationships and
Work Info

QueryTaskPlusRelationshipsAndWorkInfo

Task and Work


Info

174

Permission model
TMS has four levels of accessibility:

Task Administrator (level 1)Controls template definition, with access to all


tasks and task groups.

Task Manager (level 2)Can perform task implementer functions and also
instantiate task group templates and task templates from the parent object. Can
also create and update all tasks that are associated with the parent object.

Task Implementer (level 3)Can update and work on tasks that are assigned to
him or her.

Task Viewer (level 4)Can view tasks in read-only mode.

175

Backmatter.fm Page 17 Sunday, October 15, 2006 11:47 AM

Backmatter.fm Page 18 Sunday, October 15, 2006 11:47 AM

*34756*
*34756*
*34756*
*34756*
*65743*