BMC® Remedy® IT Service Management 7.0 Archetecture

BMC® Remedy® IT Service Management 7.
Architecture
October 2006
Copyright 1991–2006 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
3
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
4
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
5
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
Contract Management .................................................................................... 127
ERD............................................................................................................... 128
Interfaces ....................................................................................................... 128
Costing Management ...................................................................................... 129
ERD............................................................................................................... 131
Licensing model ............................................................................................ 131
Definitive Software Library ........................................................................... 132
Architectural overview.................................................................................. 133
Primary components of the DSL................................................................... 133
ERDs ............................................................................................................. 134
Interfaces ....................................................................................................... 137
Web services ................................................................................................. 138
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
6
Interfaces ....................................................................................................... 174
Web services ................................................................................................. 174
7
8
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 technology—in 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
9
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

• 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.
10
• 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 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 handle targeting of CIs for changes, and
understanding their relationships with other CIs and business services.
• BMC Atrium CMDB, to integrate the change management process with
Configuration Management for pushing changes to the infrastructure.
12
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
General Flow… Primary ITSM
Apps
End
Users Supporting
Applications
Request
Console
Change Service Level Incident

Management Management 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 subsystem’s function, without embedding functionality from other applications
that use its services.
Examples of subsystems include Task Management System, Costing Management,

Contract Management, and so on.
Subsystem
Request
End User
Console
SRMS Framework
CAI
ITSM Foundation
Primary Systems
Change Asset Incident Problem

Back Office
Management Management Management 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
ITSM Foundation SLM SLM

SLM
Task Cost Definitive Common Automation

ITSM
Subsystems
Management Management Software Library Interaction

Supporting
Foundation
Subsystem Subsystem [DSL] [CAI]
Location CAI ITSM Foundation ITSM Foundation
Organization
People ITSM Foundation
Support Groups
Categorizations
Notification Engine
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:
• Viewer—Provides the ability to view data in a system or subsystem, but not to

modify data.
• User—Provides the ability to modify data, based on support group access.
• Master—Provides the ability to modify any record.
• Administrator—Provides 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 plug-
in, 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 6. Results are displayed in

populate a table on the the table
console
Vendor form
(based on
SHR:ARDBCForm)
2. Querying vendor form 5. ARDBC plug-in

triggers ARDBC plug-in consolidates results lists
and returns vales to
Vendor form
ARDBC plug-in
4. ARDBC plug-in queries

3. ARDBC plug-in uses cached forms and retrieves results
information on forms to
consolidate and field mappings
from these forms to the Vendor
form
HPD:Helpdesk
ARDBC plug-in also constructs a
qualification for each form to CHG:Infrastructure Change
query, based on field mapping
configuration information
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
HPD:Associations Target
Incident 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.
• Sites identify unique physical locations and are associated with one or more
companies.
• The Company field and Site field are required on all ticket forms.
• Workflow can be defined to any level of the Location structure.
28
ERD
SIT:Site Alias
SIT:Site Group Logical Assoc SIT:Site SIT:Site Company Association
* 1111 * *
SIT:Site Zone (Deprecated) *
*
*
COM:Company
11
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
11
*
* * *
CTM:Region SIT:Site Group CTM:People Organization
CTM:Support Group Shift 1 CTM:Support Group CTM:Support Group Alias
* 1 11 1 *
1
CTM:Support Group Assignments *
CTM:Support Group On-Call
*
*
CFG:Approver Lookup
SIT:Site Alias
SIT:Site Group Logical Assoc 1 SIT:Site SIT:Site Company Association
* 11 * *
SIT:Site Zone (Deprecated) *
30
N
1
COM:Company Alias COM:Company
N 1 1
Company Alias Company
Company ID Company ID
Primary Alias Company Type
1
N N N
SIT:Site Group CTM:People

CTM:Region Organization
Company
Company Region Company
Region Site Group Organizarion
Site Group Type Department
CTM:Support Group Shift

N N CTM: Support Group Alias
Support Group Shift Name N
Support Group ID
CTM:Support Group Support Group Alias
Support Group ID
Company Primary Alias
1 Support Organization 1
Support Group
Support Group ID
Support Group Role
CTM:Support Group CTM:Support Group On-Call
Assignments N < Business Holidays Tag >
< Business Workdays Tag >
Support Group ID
Default Assignment Group ID On-Call Paging Type
Support Group ID 1 Pager Service Provider
Pager Phone Number (comprised of):

N N CC Pager
Area Pager
Local Pager
CFG:Approver Lookup PIN Pager
SIT:Site Alias
Approver Login ID Pager E-mail
N Approval Type Remedy Login ID
Site Alias
Approval For Business Holidays Tag
Site ID
Business Workdays Tag
Primary Alias
SIT:Site
SIT:Site Group Logical Site SIT:Site Company
Site ID (system generated)
Assoc Association
N 1 N N
Address Details (comprised of):
Company Company
Street
Site Group Region
Country
Site Group Type ("Logical") Site Group
State/Province
Site ID Site ID
City
Zip/Potal Code
Time Zone N
SIT:Site Zone (ITSP 4.0)

DEPRECATED IN 7.0 N
1
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 individual’s contact information, their organization, and
location structures information.
31
ERD
Support Group Functional Roles

Company - for Support Staff only
- e.g. Change Manager, Support Group
Manager Attributes
Region Organization Support Organization - General Information: Name, VIP
- IT/Skills, Access IDs, Travel
Profiles
Site Group Department Support Group
Site Financials
- Cost centers (multiples)
- A person belongs to a Company and location - Hourly rate, Accounting code
- A Support Staff belongs to a Support Group
CI Associations
Permission Groups - associate to CIs with type: uses,
- for Support Staff only manages, supports, owns
- allows users access to various
modules
Approval Mapping
Login and Licensing - for Support Staff only
- Approval mapping for Change and
Information User Change Management
- stores Login ID and password
- Fixed/Floating/Read license Notification Preference
- for Support Staff only
- System pre-defined and User-
defined notification preference
based on events
Application Permissions
CTM:People
1 *
Data Access
1
*
* *
* *
* * * *
*
CTM:People Worklog CTM:Support Group Association AST:AssetPeople FIN:CostCenterAssociation CTM:People Permission Groups NTE:CFG-NotificationEvents
* 1 1 *
1 1 *
CTM:SupportGroup
FIN:ConfigCostCentersRepository User
CMDB
Combination of Support Group and Person ID Classes
CTM:SupportGroupFunctionalRole
32
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 P
33
Support Group ERD
COM:Company
CTM:Support Group Shift 1 CTM:Support Group CTM:Support Group Alias
* 1 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 Model/Version
PCT:ProductModelVersionPatch
Operational categorization
CFG:Service Catalog CFG:Service Catalog Association
1 *
35
CFG:Service Catalog
Categorization ID CFG:Service Catalog Assoc

Categorization Tier 1 1 N
Categorization Tier 2
Categorization Tier 3 Categorization ID
Description Company
Status 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 user’s 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 back-
end 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.
• Number of Tickets Assigned rules assigns the record based on the person who
has the lowest number of records assigned.
• Round Robin assigns the record to the next person in line.
• 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.
38
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:
• Event—Type of assignment this assignment record is created for.
• Assignment—Support group that this assignment record would assign the
ticket.
• Criteria—Criteria matching the tickets to find the assignment records.
• System—Identifies if this assignment record is “enabled” for such systems.
• 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.
40
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 system’s rule form:
• Incident Management—HPD:CFG Rules (Configure Incident Rules)
• Change Management—CHG:CFG Rules (Configure Change Rules)
• Problem Management, Knowledge, Known Error—PBM:CFG Rules
(Configure Problem Rules)
• Task Management System subsystem—TMS: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 system’s respective rule forms.
BMC Remedy Change Management architecture

The Change Management application is designed to establish a standardized change
Change process to allow IT organizations to make quick decisions on risk, and assess the
Management impact of changes made to the production environment. The Change Management
BMC Atrium CMDB features introduce efficiency and increase productivity by minimizing error-prone
Task Management processes and providing visibility to key performance indicators (KPIs). Features
DSL also include metrics to determine if established service level agreements (SLAs) are
Cost Subsystem 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
r
e
e
g t 1
n s
e
u C hang e
a
h q In itiatio n a n d
C e R ec o rd in g
R
re
e tn
g e 4
n m
a Change
h le
C p Im p lem e n ta tio n
m
I
e
e r
n te 3
g ta
i
s M )t Change
s r
e P la n n in g an d
A tc p
e S c h e d u lin g
g je
b
x
E 5
n u 2 C hang e
a
h S R e vie w a n d
C ( C o m p letio n an d
A u th o riz e C lo su re
re
g
a
n
a
M
e
g
n
a
h
C
e re
g v
n o
a
h r
p
C p
A
/
tr s
o e
p s
p s P ro b lem In c id e n t R e q u es t
u e
S c M anagem ent M anagem ent M anagem ent
e o
c r
P
i
v
r y
re
e
S v
r li C o n fig u ra tio n M a n a g e m e n t
e
h e
D
t
O
,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 User’s 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
• Cost information
48
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
TMS:LDAPGroup Database
Asset Management
AST:Configuration
PDL:Software
LibraryItem
AST: CI
CHG:Associations
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
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 CFG:Reminders
ookup
SRM:Request
CHG:ChangeRisk CHG:Impacted
Factors Areas
CHG:Infra.
Foreign Key: Change Effort
SRInstanceID Log CFG:Broadcasts
TMS:Task CHG:WorkLog
Foreign Key: CHG:Infrastructure Foreign Key:

RootRequestID Infrastructure Change ID
Change
TMS:TaskGroup
Foreign Key:
Instance ID
TMS:FlowBuilder TMS:Flow TMS:SummaryData
50
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
looked up and stored as local data on the change request.
CTM:Support
COM:Company CTM:People
Group
Requested By
Requested For
Manager
Assignee
Implementer
Operational Category
CFG:Service
Catalog
CHG:Infrastructure
Change PCT:Product
Product Category
Catalog
Region/Site Group/Site
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 AST:*
CHG:Infrastructure
Change
PBM:Knowledge
Database TMS:TaskGroup
FIN:Costs
TMS:Task
FIN:Association CHG:Associations TMS:Associations
COM:Company
Requested By CTM:Support
Requested For Group
Manager
Assignee
Implementer
CTM:People
Foreign Key: CHG:Infrastructure

SRM:Request
SRInstanceID Change Operational Category CFG:Service
Catalog
Product Category
PCT:Product
Catalog
Region/Site Group/Site
Foreign Key: Foreign Key: Foreign Key: CTM:Region

Infrastructure Change ID Instance ID RootRequestID
SIT:Site Group
CHG:Change CFG:Broadcasts TMS:Flow TMS:Task
Request Audit
SIT:Site
CHG:ChangeRisk
FactorQuestionL CFG:Reminders
ookup TMS:FlowBuilder
TMS:TaskGroup
CHG:ChangeRisk CHG:Impacted
Factors Areas
TMS:SummaryData
CHG:Infra.
Change Effort CHG:WorkLog
Log
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 Event
Dispatcher Dispatcher
CSS Files Renderer
JavaScript
Files
Model
BMC Atrium CMDB API 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-in’s 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 server-
side 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
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:
• 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

The Asset Management application lets IT professionals track and manage
Asset enterprise configuration items (CIs)—and their changing relationships—throughout
Management the entire asset life cycle. Asset Management tracks contracts, financial costs,
BMC Atrium CMDB
software licenses, outage indicators, and more for the CI information stored within
DSL the BMC Atrium CMDB 2.0 application.
Cost Subsystem
ITSM Foundation As part of the BMC Remedy ITSM Suite, Asset Management is integrated with
SLM 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
CMDB
Asset manager
1
2 3
Configuration 4
Configuration Configuration
management Configuration control
identification specifications
planning
5
Configuration
audit and
verification
Configuration auditor
and other related processes
RFC
Service support,
service delivery,
Asset Change Incident Asset Incident Change Change

Management Management Management Management Management Management 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 CMDB Classes AST:AssetSupport

1
1
* 1
1 AST:AssetWarranty
* *
*
AST:ImpactedAreas AST:CI Unavailability AST:CMDB Associations

AST:AssetSoftware
* *
* * * * *
AST:Asset Lease
AST:Schedule Assocations FIN:CostAssociation AST:AssetCost AST:WorkInfo AST:AssetPeople
1 * *
AST:AssetMaintenance
1 * *
AST:ScheduleCriteria FIN:Costs 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
display support contracts.
Main Asset Extensions AST:AssetSupport_ Support contract extension

Main Asset Extensions AST:AssetWarranty Join between the warranty

contract extension and the
display warranty contracts.
Main Asset Extensions AST:AssetWarranty_ Warranty contract extension

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 AST:AssetSoftware (Join)
Model/Version ID
PMVInstance ID Contract Instance ID
Contract ID
Contract Instance ID
ProductCompanyAssociation 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
• Contains configurable rules for the License Management Engine.
• Users with Asset Config permission can access this form.
• It can also be accessed from the Application Administration Console.
76
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 CI’s 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, Fields to indicate what support group is defined as the notification group
Support Organization, for the given configuration rule.
Group
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:PurchaseRequisition—Holds the details about the requisition and the

user who is requesting the items. It also "drives" the process for getting the
requisition approved.
• AST:PurchaseOrder—Holds all of the orders that have been generated.
• AST:PurchaseLineItem—Holds 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:PurchaseReturn—Holds 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:PurchaseRequisitonWorkLog—Contains the work notes that have been
attached to the requisition.
AST:PurchaseOrder AST:PurchaseRequisitionFK: Requisition Instance IDAST:PurchaseRequisitonWorklog
1 *
1 1
FK: Order Instance ID FK: Requisition Instance ID
* *
AST:PurchaseLineItem FK: Line Item Instance ID AST:PurchaseReturn
0..1 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:
• CTR:ContractPayments—Provides information about the payments made

against a contract.
• AST:WorkLog—Tracks work notes against a contract.
80
• CTM:People—Holds the contacts for a contract.
• Relationship table AST:CMDB Associations to the BMC Atrium CMDB
forms—Links contracts to CIs.
Warranty contracts
FK: Serveral Companies Names * COM:Company
FK: Instance ID CTR:ContractPayments
FK: Instance ID AST:WorkLog
* * *
*
Child Contracts AST:AssetWarranty FK:CompanyName CTM:People

1
*
1 *
Join Between AST:Warranty_ and CTR:ContractBase

* Reconciliation ID
AST:CMDB Associations «subsystem»
BMC Atrium
* CMDB Forms
* *
CTR:ContractBase
Shaded box = Contract subsystem provided
81
Support contracts
* * *
*
Child Contracts AST:AssetSupport FK:CompanyName CTM:People

1
*
1
*
Join Between AST:Support_ and CTR:ContractBase
* Reconciliation ID
AST:CMDB Associations
«subsystem»
* CMDB Forms
* *
CTR:ContractBase
82
Lease contracts
* * *
*
Child Contracts AST:AssetLease FK:CompanyName CTM:People

1
*
1
*
Join Between AST:Lease_ and CTR:ContractBase
*
AST:CMDB AssociationsReconciliation ID
«subsystem»
* Top Package::CMDB Forms
* *
CTR:ContractBase
*
End Of Lease Support CHG:Infrastructure Change
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
* * *
*
Child Contracts AST:AssetMaintenance FK:CompanyName CTM:People

1
* 1
*
Join Between AST:Maintenance_ and CTR:ContractBase
*
AST:CMDB AssociationsReconciliation ID
«subsystem»
* *
CTR:ContractBase
84
Software contracts
* * *
*
Child Contracts AST:AssetMaintenance FK:CompanyName

1 CTM:People
1
*
*
Join Between AST:Maintenance_ and CTR:ContractBase
* AST:CMDB AssociationsReconciliation ID
«subsystem»
* *
CTR:ContractBase
AST:Keys and Versions
Licenseable Product
AST:Contract PD Relationship PDL:Product Dictionary
* *
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
AST:CI Unavailbility
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
The following subsystems are used by Asset Management:
• Cost Management
• Service Level Management
• BMC Atrium CMDB
88
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 form—Provides the mechanism for querying data in
the Asset Management purchase order system.
Web Services
AST:PurchaseOrderInterface_WS form—Provides 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 View—On every class attribute with View permissions.

• CMDB Data Change—On 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 Viewer—Read access to CI data in Asset Management.
• Asset User—Read 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 Administrator—Read/write access to CI data in Asset Management.
• Purchasing User—Read/write access to purchasing data in Asset Management.
• Receiving User—Read/write access to receiving functionality in Asset
Management.
Mapping of Asset Management roles to BMC Atrium

CMDB roles
• CMDB Data View—Mapped to Asset Viewer and Asset User.
• CMDB Data Change—Mapped to Asset Admin.
• Write Security—Mapped 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 Asset Asset User Asset Purchasing Receiving

Management Admin role role Viewer User role User role
component role
Manage CIs Write access Read access Read No access No access

to all CIs and access
functions Write access to
CIs the user
supports.
Includes ability to
create:
• Contracts
• Configurations
• Relationships
• Costs
• Schedules
• Outages
• Returns
• Activities
• Impacted
areas
Manage Access to all No access from No No access No Access
Inventory inventory Asset access from Asset from Asset
functions Management from Management Manage-
console Asset console ment
Manage- console
ment
console
92
component role
Manage Write access No access from No No access No access

Contracts to all Asset access
contracts Management from
console Asset
Manage-
Write access ment
from CIs the user console
supports
Read
access
from CI
forms
Manage Access to all No access from No No access No access

Configurations configuration Asset access
functions Management from
console Asset
Manage-
Read access ment
Write access console
from CIs the user Read
supports access
Read
access
from CI
forms
Manage Costs Access to all No access from No No access No access

cost Asset access
console Asset
Manage-
Read access ment
supports access
Read
access
from CI
forms
Bulk Updates Access to No access No No access No access

bulk update access
functions
93
component role
Schedules Access to all No access from No No access No access

scheduling Asset access
console Asset
Manage
Read access ment
supports access
Read
access
from CI
forms
Purchasing No access No access No Write access No access

Console access to purchase
requisitions
(including line
items) that
are assigned
to the user’s
support group
Write access
to purchase
orders
Receiving No access No access No No access Access to

Console access 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, user-
submitted 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
Change
Incident Known Management
Problem
Management Error To
Investigation
Process Management Correct
Errors
Notified of Notified of Notified of

Completed Fix Completed Fix Completed Fix
BMC Remedy Incident Management

Incident management’s primary goal is to get the user back to work as soon as
possible after an incident.
Incident
Management
Incidents can enter the system manually or automatically. Users can create
BMC Atrium CMDB
incidents using the Requester Console. The Requester Console provides users a
Task Management
simple interface for entering and managing their requests. Incident Management
Cost Subsystem
ITSM Foundation
integrates with the Requester Console to provide this interface. Support technicians
SLM
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
Incident
Yes recording Self correcting? Yes
closure
(Classification)
<Function>
Incident Incident Auto No

detected Detected?
Identification and
recording Investigation and Resolution and Incident
No
(Classification and diagnosis recovery Ccosure
initial support)
ITSM manual incident management process overview
Resolution /
Customer
Incident Web
Workaround
Detected Self-Help
Validation
Incident Assignee Incident Assignee
1
Call to Incident
(Tier 1)
Service Desk Detection and 5

Recording Resolution / Incident
Workaround Closure
Validated and
4 Accepted
Incident Resolution and
Recorded Recovery
(Tier 2/3/n)
2 Resolution /
Classification Workaround
and Initial No Available Found
Support Resolution /
Event Monitoring Workaround 3
Incident Detected Investigation
and Diagnosis
Incident Queue
(Optional)
Manager
Manager
Incident
Other Service Support /
Delivery Processes
Capacity /
Request Change Problem Problem Problem Change Problem
Availability
Management Management Management Management Management Management Management
Management
Configuration Management
Service Level Management
96
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.
The following subsystems are used by Incident Management:
• 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 HPD:IncidentInterface_Create

C eate
Events CAI:Events
Get HPD:IncidentInterface
Application Object
Event 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
Problem Management
Lookup Data PBM: Problem

Investigation
PCT:Product Catalog
PBM: Known Error
CFG:Service Catalog
PBM: Knowledge
HPD:Help
SIT:Site Database
Desk
Asset Management/
CMDB
:
CTM:People Organization
AST: CI
HPD:Association Unavailability
BMC:*
CMDB Classes
CFG: Broadcast
FIN: Costs FIN: Association HPD:Help Desk Association
CFG: Broadcast
Foreign Key: HPD:HelpDesk_AuditLogSystem

Request ID
(See Note) CTM:People

TMS: Associations
(See Note) CTM:Company
TMS:Task
Foreign Key:
Incident Number HPD:ImpactedAreas
(See Note) CTM:Support Group
Foreign Key:
Incident Number 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
- 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 Association
External forms
application with a CI if a CI name
is specified
Creates staging HPD:IncidentInterface

HPD:Help Desk
record using Help (Staging form)
Desk Submit web Processes Creates Help Desk
service incoming record and Work Log
parameters record
HPD:Work Log
Data flow direction
Interface forms
• HPD:IncidentInterface_Create—Interfaces with the HPD:Help Desk form
to create incident tickets.
• HPD:IncidentInterface—Self-join of HPD:Help Desk form for query and

modify operations.
Web services
• HelpDesk_QueryList_Service—Queries for multiple tickets in the
HPD:HelpDesk form.
• HelpDesk_Modify_Service—Modifies a ticket in the HPD:HelpDesk form.
• HelpDesk_Query_Service—Queries for tickets in the HPD:HelpDesk form.
• HelpDesk_Submit_Service—Submits 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 is focused on finding the root cause of an issue in the IT
Problem infrastructure, and working to correct that known error.
Management
BMC Atrium CMDB
Problem Management has three main components:
Cost Subsystem
ITSM Foundation • Problem investigation
Knowledge
• Known error management
• 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:
• Known errors—Describe the root cause.

• Knowledge solution entries—Describe how to work around the issue and
potentially other incidents or problems to investigate.
108
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
ITSM Problem Management Process Overview
Requester
Investigation
Initiated
Problem Assignee
3
8
Problem
5 Knowledge
Investigation
Known Error Identification
and Diagnosis
Identification and Recording
and Recording
6
9
Known Error
Knowledge
Classification
1 4 Validation and
and 7
Problem Problem Publication
Assessment Known Error
Identification, Resolution and
Resolution and
Recording and
Problem Manager
Closure
Classification Closure
2
Review
Other Service Support /
Delivery Processes
Change
Incident Incident Change Implemented Incident
Management Management Management 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 Incident Management PBM: Problem

Investigation
PCT:Product Catalog HPD: Help Desk
PBM: Known Error
CFG:Service Catalog
Solution
PBM:
Database
SIT:Site
Asset Management/
CMDB
:
AST: CI
PBM: Associations
Unavailability
BMC:*
CMDB Classes
Problem
PBM: CFG: Broadcast
FIN: Costs FIN: Association Investigation Association
CFG: Broadcast
Foreign Key: PBM:Problem_AuditLogSystem

Request ID

TMS: Associations
TMS:Task
Foreign Key:
Incident Number PBM:ImpactedAreas
Foreign Key:
PBM:Work Log
Incident Number
112
CTM:People
- Manager
- Assignee
- Requester
CTM:Company
- Requester Company
- Mannger Support Company
- Vendor Company
company)
CTM:Support Group
- Requester Support Group
- Manager Support Group
113
Change Management
:Infrastructure
CHG::
Change
Problem Management

Investigation
PBM: Known Error
CFG:Service Catalog
Solution
PBM:
Database
SIT:Site
Asset Management/
BMC Atrium CMDB
:
Known Error AST: CI

PBM:
Associations Unavailability
BMC:*
CMDB Classes
FIN: Costs FIN: Association

PBM: Known Error CFG: Broadcast
CFG: Broadcast
Association

Request ID

TMS: Associations
TMS:Task
Foreign Key:
Incident Number PBM:Known Error Work Log
114
CTM:People
- Manager
- Assignee
- Vendor
CTM:Company
- Mannger Support Company
- Vendor Company
company)
CTM:Support Group
- Manager Support Group
115
Change Management
:Infrastructure
CHG::
Change
Problem Management

Investigation
PBM: Known Error
CFG:Service Catalog
Solution
PBM:
Database
SIT:Site
Asset Management/
BMC Atrium CMDB
:
Solution AST: CI
PBM:
Associations Unavailability
BMC:*
CMDB Classes
Solution
PBM:
FIN: Costs FIN: Association Database

Request ID
Foreign Key: CTM:People

TMS: Associations Assingee
Foreign Key:
CTM:Company
Assignee Company
TMS:Task
Foreign Key:
CTM:Support Group
Support Group
Foreign Key:
Incident Number PBM:Solution Work Log
Interfaces
• PBM:ProblemInterface_Create
• PBM:ProblemInterface
116
• 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 Construction Execution
1 Event
What Data Values 3 Command
HowContent 5 RuntimeJust
Command
Do It
2 4
App Registry
ID Name Protocol
Commands
Command Direction Op. Type
Parameters
Done
Param Data Type Mode
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 name—Name 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 plug-
in 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
1 . Register registered
CAI : AppRegistry CAI :CommandParamMappin
U1 InstanceID AppRegistryName
U2 AppRegistryName Command
ApplicationName CommandParam
ApplicationInstanceID AppInterfaceFormName
Protocol AppFieldName
Connection Info AppFieldID
Interface Form Names ParamType
ParamDataType
0 . Create commands and
command paramters
CAI :CommandParam
CAI : Command
U1 Command U1 Command
U1 CommandParam
Direction
OperationType Type
SelectionType DataType
Mode
CAI : Event Construction

CAI :EventParam
EventGUID
Event
Source EventGUID
Target ParmName
SourceAppRegistryInstanceI
ParamValue
AOIGUID
ParamAttachmentValue
AppInterfaceFormName ParamType
TargetConnectionInf ParamDataType
RtnCode
RtnMsgCode Push event and run time
- data to
RtnMsg event params (outbound )
MaxRetries
RetryCounter SRMS
framework/TMS
Calls GetEntry to
Execution (outbound) get event values
AR System
Filter API Plug-in workflow
Push event and event Launch

params
App Interface Form

Browser
Mapped Param
120
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

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

params
App Interface Form Browser
Mapped Param
122
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 command’s 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 plug-
Service Request in returns
status to
CAI:Events
form
CAI:Events
2. When an entry is
created in the CAI:Events
form, the CAI plug-in is
called
CAI:EventParams
4. When a request
3. The CAI plug-in
is added to the
creates an entry in the
queue, a signal is
request queue and
issued to wake up a
returns Status =
thread in the thread
Running to CAI Events
pool to process the
form
Main Plug-in request. CAI Plug-in
Request queue
code Thread Pool
5. CAI plug-in
creates Change
Request and/or
Incident
HPD:HelpDesk
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.
Operation Form
Base form Operation description name Interface 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 Op Create

event parameters
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 data-
flow 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 Asset Management Access

Management permission group
permission group
Contract View Only Asset Viewer Read
Contract Full Access Asset User, Asset Admin Write
Contract Administrator - Write

(reserved for future use) N/A
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
Calling System Form FIN:Cost

Calling System Identifier
Cost Center
Cost Type
Cost Record Instance ID
Description
Amount
Association Type
Units
Primary
Date Incurred
Informational
Instance ID
Allocation
Filter API
FIN:CostAssociationJoin
FIN:ChargeBacks
Populated using a filter API

process with cost data and
cost center allocations from
Calling System Table
FIN:Cost . Used for chargeback
Identifier 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:
Viewer—Can only view cost data.
User—Can add costs.
Manager—Can 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
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 System to System

Change Assignee Asset Management
Interaction
• Software License Mgmt Data Interaction
• Approvals
Change Management •…
Change Request
• Product Lookup
• DSL Reference
• Related CI Targets
CMDB
Configuration
Discovery
Definitive
Software
Library
Policy Deployment
Task Manager Manager
Management
System
Command
Automation Common Management Services
Task Implementer Interface
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 files—A list of files that are executed or referenced in support of
the application.
• Software Library Items (SLIs)—Location or storage of media.
• Suite definition—Application 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 Software
S/W Library
Library
Item
Item
• Patch
Software
• Manufacturer
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
Company -PIID
1 +PMVIID
- CIID ProductCompany . ProductDictionaryPatc SLI
+PatchLastBuildIn 1
+ Company -A
PIID D h
-PMVIID -SLIIID
+ Type nn 1
+ CIType -ProductIID +VIID
+ ProductCat1 -PatchIID +Description
+ ProductCat2 ProductDictionary -. +Type
+ ProductCat3 n -. 1 n +State
-VIID
-. +Location
-PIID
+CIType
n 1
Product 1 +ProductCat1
+ProductCat2 1 1
- PIID ProductModelVersion
1 +ProductCat3
+ CIType - VIID +PMV State
+ ProductCat1 n n
- PIID +Product Name
+ ProductCat2
+ CIType 1 +Manufacturer
+ ProductCat3 PV_Files Lookup
+ ProductCat1 Attachments
+ ProductCat2 +VIID -Attachment
+ ProductCat3 +FileID +DSL
IID IID
n
+ PMV State +Description
+ Product Name +Attachment
+ Manufacturer
n
Version
-VIID
n
+ PIID n n
+ PMV State
+ Product Name
+ Manufacturer Suite_PD Lookup Files
+SuiteIID -FIID
+VIID +Name
+FileSize
Legend +CRC
Vendor Version
+TimeStamp
- VVIID Foundation Objects
+ Description
+ VersionString PD/DSL Objects
+ ComponentNam
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 Instance ID
PCT:Product Catalog PCT:ProductCompanyAssoc Product Name
PK Instance ID PK InstanceID Model Version PDL:ProdDictionaryPatch
PatchLastBuildID
ProductID Add DSL Fields MainExeID PK PatchIID
ProductIID
CI Class Company MainExeName
ProductCatTier 1 ProductID
ProductCatTier 2 CI Class
Origin JOIN JOIN JOIN ProductCatTier 1
ProductCatTier 3
IsSuite ProductCatTier 2
Product Name
Manufacturer ProductCatTier 3
Price ProductName
Product 's Image PDL:ProductDictionary Manufacturer
ManufacturerID
PK VersionIID GUID
PDL:ProductModelVersion OS
ProductID MainExeID
PCT:Product Mod/Version Add DSL Fields PK InstanceID CI Class MainExeName
ProductCatTier 1 Origin
PK Instance ID Product ID ProductCatTier 2 IsSuite
PMV ID ProductCatTier 3 Locale
PMV ID GUID ProductIID ProductName Platform
Product IID OS ProdModVer Manufacturer ProductID
ProdMod Vers Locale PMV State ManufacturerID PMV State
PMV State Platform ProductName GUID ProductName
Product Name VersionMajor ..... OS
Manufacturer VersionMinor OS Origin
PatchLastBuildID VersionBuild Locale IsSuite
ManufacturerPartNo VersionMaint Platform Locale
GeneralAvailDT ManufacturerID VersionMajor Platform
DiscAvailDT VersionMinor PMV State
DiscSupportDT VersionBuild ProductName
PreReleaseDate VersionMaint
Data example
Model/Version Patch
VIID PatchIID Patch

Company/Manufacturer
V2 PA1 2.3
CIID Name State Product
Company V3 PA2 1.0 ProductDictionaryPatch
Association (Join)
C0 -Global- --
V1 PA3 0.0
... PIID Company VIID PIID PatchIID
C1 MS WA
V2 ...
PA1 PA1
... PD1 -Global-
C2 Dell TX
PD2 -Global- V3 PA2 PA2
Product Dictionary (Join)
PD3 -Global- V1 PA3 PA3
PIID VIID Name CIID
Product Catalog Base
PD1 V2 Word C0
PIID CIID Origin Is Suite
PD2 V3 Excel C0
rd
PD1 C1 3 Party No
PD3 V1 Outlook C0
Product Model/Version
PD2 C1 3rd Party No
(Join) ... ... ... ...
PD4 V4 Office C0
PD3 C1 3rd Party No PIID VIID Name
Files Lookup Software Library Item
PD4 C1 3rd Parth Yes PD1 V2 Word
VIID FIID SLIID PIID Location
F
PD2 V3 Excel
Suite Mapping ...
V2 F1 SLI1 PA1 Shelf
PD3 V1 Outlook
SuiteIID PDIID SLI2 PA2 Shelf
Model/Version Base V1 F3
PD4 V4 Office PD4 PD3
SLI3 PA3 Disk
VIID PIID Version ... has .../... has ...
PD4 PD2
V1 PD3 4.0
PD4 PD1
V2 ...PD1
... ... 3.0
...PD2
... ... Files
V3 4.2 KBVersion
...PD4
... ... FIID Name File Size
V4 6.0 VVID Version
F1 Word.exe 3784
KB1 1.0
F
...KB2
has .../... has F2 Excel.exe 1816
1.3 ...
F3 Outlk.exe 2590
136
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_Create—Staging form that interfaces to the

PDL:SoftwareLibraryItem form. This form is used for creating Software
Library Item entries.
• PDL:SLIInterface—Self-join form of the PDL:SoftwareLibraryItem form. This
form is used for query and modify operations.
• PDL:PDInterface—Self-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 PDL:SLIInterface_Create

PDL:SoftwareLibraryItem
record using (staging form)
Product
Dictionary web Processes
service 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_Service—Queries using a qualification statement for
multiple Product Dictionary entries in the PDL:ProductDictionary form.
• PD_QueryListFields_Service—Queries 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_Service—Queries using a qualification statement for
multiple Product Dictionary Patch entries in the
PDL:ProductDictionaryPatch form.
• PDP_QueryListFields_Service—Queries 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_Service—Modifies a Software Library Item entry in the
PDL:Software Library Item form.
• SLI_Query_Service—Queries for a Software Library Item entry in the
PDL:Software Library Item form.
• SLI_QueryList_Service—Queries using a qualification statement for
multiple Software Library Items in the PDL:Software Library Item form.
• SLI_QueryListFields_Service—Queries 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:
Operation
Base form and type description Operation name Interface form
PDL:Product Dictionary Query list of PD_QueryList_Service PDL:PDInterface

entries
Self-join
Query field list PD_QueryListFields_Service
PDL:Product Dictionary Query list of PDP_QueryList_Service PDL:PDPInterface

Patch entries
Self-join
Query field list PDP_QueryListFields_Service
PDL:SoftwareLibraryItem Create SLI PDL_SLI_Submit_Service PDL:SLIInterface_Create

Regular
Self-join Modify SLI SLI_Modify_Service PDL:SLIInterface
Query for SLI_Query_Service

specific SLI
Query for list SLI_QueryList_Service

of SLIs
Query field list SLI_QueryListFields_Service
139
Permission model
DSL has the following permissions:
• Level 1—DSL Administrator: Access to add and modify Product Dictionary

and Software Library Item definitions.
• Level 2—DSL 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 Incident
Management Management
140
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.
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 The summary definitions provide the menu items for the
Console:SummaryDefinition 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
Runtime Requester Serves as the entry point for users and supports their
Console:RequestConsole 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
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 2. Creates

submitted incident
4. Completed 3. Incident
request 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:
• Segment front-end transactions from back-end transactions.

• Act as a bridge between the Requester Console front-end interface and Change
Management and Incident Management back-end applications.
• Support synchronization between the front-end interface and back-end object
life-cycle.
144
• 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.
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.
• 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
146
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 back-
end 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 back-
end 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
SRM:AppInstanceBridge
PBM:Solution
Database
SRM:Survey
FK:SRInstanceID
FK:SolutionRequestID FK:Originating_Request_InstanceID
RQC:Summary FK:SRInstanceID SRM:WorkInfo

FK:TitleInstanceID SRM:Request
Definition
FK:SRInstanceID
Region/Site Group/Site HPD:Help Desk

Operational Category
Requested By
Requested For CHG:Infrastructure
Manager Change
Assignee
CFG:Service
COM:Company CTM:Region
Catalog
CTM:Support
SIT:Site Group
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:Request
PBM:Solution
SRM:AppInstanceBridge FK:SR_KnoweldgeDatabaseID
Database
FK:AOIGUID
HPD:Help Desk
FK:AppRequestInstanceID CHG:Infrastructure
CAI:Events 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 back-
end 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
1. Tells Start Flow to Predecessor Instance ID
SRM:Request Successor Instance ID (AOI)
start work.
Service Request Instance ID 7. Sets return code = <OK, Warning, Error>
SCO Instance ID Return msg = warning or error msg
2. Create successor AOI
3. Create event
SRM:AppInstanceBridge and event CAI:Event 4. FilterAPI invoked
param entries.
Service Request Instance ID Event Instance ID
AOI Instance ID Event Type=CreateAppRequest
Application Registry Instance ID AOI GUID=<AOI Instance ID>
Flow information SRMS Server=<SRMS server name>
App GUID=<Application ID >
App Server=<Application server name>
Question-response
When SR status = New; App Interface form = <App interface form
linked to service request.
status reason = AI Creation, name>
Create the event and event Source=SRMS
SRM:Service CAI Plugin
params. Return code = empty
RequestQuestionAssociation Return msg = empty
(NOT USED in RQC)
AOI Instance ID
Question Response Instance ID
5. CreateEntry to application interface
Field-value pair linked to event App interface entry field values

come from event params
SRM:QuestionResponse Field-value pairs come from
CAI:EventParams
(NOT USED in RQC) question-response pair. Application Interface
(ChangeInterface_Create)
Service Request Instance ID Event Instance ID
Question Instance ID Param Name=<field id>
Question Param Value=
Answer Type=<In, Out Qual> 6. Submit to application instance
(if app interface != app instance form)
Data Type=<Character, Attach>
CAI:AppRegistry
Application Instance
Registry Instance ID= (CHG:Infrastructure Change)
Registry Name=
Description=
App Template Form=
App Template View Form=
App Instance Form=
App Interaction Form=
Access Mode=<Local, Remote>
Server=
Login/password=
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 back-
end 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 Filter API
In: Reg App Server, Event
Event GUID
SR GUID 4. Call Filter API Form, Event Param Form,
Event Command
AOI GUID Event GUID
2. Create outbound Event Status 7. Return code,
App Registry Rtn: Return Code, Return
create entry Protocol (AR) Return message
AOI Status Message
SRMS Server
App Instance GUID 8. Notify AOI that AOI GUID
App Instance ID command is done Reg App Server
App Instance Description Reg App Interface (Form) 5. AR API Call
App Instance Status 9. Update event App Instance GUID
App Instance Cost status=Complete Return Code
Return Message (Error) App Interface
3. Create the event parameters using …

the fields setup from command Template ID
Event Parameter SRMS Server
configuration and by using responses
to the questions to map the values into SR ID
the application interface/instance fields. Event GUID AOI GUID
Event Parameter GUID ...
Parameter Name
Parameter Value 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:
• Public—Hidden
• Request Master—Visible
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 Map to group Comments

group or role
Summary Summary Definition Provides create, view, and modify access to Requester
Definition Config Config Computed Console:SummaryDefinition.
Note: General Access is needed for modify access.
N/A Summary Definition Base group for Summary Definition Config Computed.
Requester Requester Console Config This group is part of the Request Config Computed
Console Config** 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.
154
group or role
Requester Requester Console This group is part of the Request Master Computed
Console Master group.
Master**
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 Unrestricted Access** Bypasses row-level access for multi-tenancy. See

Access 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

group or role
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.
N/A Request Config Base group for Request Config Computed. Also part of
the Summary Definition Computed group.
Request Request Master Provides access to:

Master** Computed
• 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 Unrestricted Access Bypasses row-level access for multi-tenancy. See

Access 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 group for Summary Definition

Computed 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 Administrator’s Guide for information about
user features, configuration, and administration of the system.
157
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
Container
Object
Object
Data Flows
Task Group
Task Group Container
Template [0]
[0]
Application Object
OR
Application Object Instance
Template
Task
Task [A]
Template
[A]
AND
Application Object Application Object
Application Object Application Object Instance Instance
Template Template
Task Task
Task Task [B] [C]
Template Template
[B] [C]
Feature Set
Application Object
Application Object
Instance
• Related Items
Template • Automated Tasks
Task
Task • Launch
[D]
Template • Pass data betweenAOI’s
[D] • Reference Other Form
• Shared Work
Name Value Scope

Location Sunnyvale Local
Contact
Phone TBD Local
Closed Tasks 2 System
Variable Pool
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
Task Group 1
TaskTemplate 1 F2
F1 F1 Task 1 F2
Task Template 2a Task Template 2b

Task 2a Task 2b
F4 F3
F4 F3
Task Template 3a TaskTemplate 3b

Task 3a Task 3b
F5 F6
F5 F6
Task Template 4
Task 4
All templates in this task group template are configured to be

executed in the order of flow F1 to F6. 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
F1 Task 1 F2
Task 2a Task 2b
F4 F3
Task 3a Task 3b
F5 F6
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
F1 F2
Closed/Success
Task 2a Task 2b
Closed/Success Closed/Failure
F4 F3
Task 3a Task 3b
Closed/Success Bypaased
F5 F6
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.
• [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.
162
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 ASSOC1 ASSOC3
AT2 ASSOC2
164
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 Group
Task 1 Task 2
Task 1
Task 2
Task 3 Task 3
Example 1 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
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 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
Task and Work Update Related Individual Work Info UpdateTaskAndWorkInfo

Info
Update Related Multiple Work Info UpdateTaskAndWorkinfo
Create Related Individual Work Info UpdateTaskAndWorkinfo
Query Related Multiple Work Info QueryTaskPlusWorkInfo
Task and Query Related Multiple QueryTaskPlusRelationships

Relationships Relationships
Task, Query Related Multiple QueryTaskPlusRelationshipsAndWorkInfo

Relationships, Relationships and
and Work Info 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
*65743*
*65743*
*65743*
*65743*
*65743*

BMC® Remedy® IT Service Management 7.0 Archetecture

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BMC® Remedy® IT Service Management 7.0 Archetecture

Uploaded by

Copyright:

Available Formats

BMC® Remedy® IT Service Management 7.

BMC Software, Inc.

Foundation architecture ....................................................................................... 27

BMC Remedy Change Management architecture ............................................. 41

BMC Remedy Asset Management architecture ................................................. 67

BMC Remedy Service Desk architecture ............................................................ 94

ITSM 7.0 subsystems........................................................................................... 117

ITSM suite description

Features and benefits

Provide visibility into your infrastructure

Enhance customer satisfaction

ITSM suite architecture

Service Desk process

If the Service Level Management (SLM) application is installed, Service Level

Incident Management uses the knowledge database to provide the technician

Problem Management can also be initiated using a proactive problem management

Change management process

The change management process is designed to be open to handle the many

Integrations that the change management process uses include:

Asset Management processes provide mechanisms to manage schedules, contracts,

Diagram of the ITSM suite architecture

Change Service Level Incident

Examples of subsystems include Task Management System, Costing Management,

Change Asset Incident Problem

Management Management Management Management

Task Management DSL Task Management Cost Subsystem

DSL Cost Subsystem Cost Subsystem ITSM Foundation

Cost Subsystem ITSM Foundation ITSM Foundation Knowledge

ITSM Foundation SLM SLM

Task Cost Definitive Common Automation

Management Management Software Library Interaction

Shared required data structures can be leveraged across different systems.

Common application models

Deployable applications provide functions that support a component architectural

Deployable applications contain the following systems and subsystems:

• Incident Management (licensed)

• Costing Management (licensed)

Application licenses provide access to the forms that make up an application. If an

Fixed licensing is a named license that gets assigned to a particular user.

Main concepts defined include:

• Abstraction using roles

The common roles are:

• Viewer—Provides the ability to view data in a system or subsystem, but not to

To support this model, the applications provide predefined explicit permission

To enable an easy mapping mechanism, the AR System computed group is used.

User access using support groups

The services provided by the AR System platform are primary to the

BMC strongly recommends that all integrations to Incident Management, Problem

The overview console provides a view of work assigned across multiple

This implementation uses an ARDBC AR System plug-in to provide a consolidated

ARDBC plug-in data setup:

ARDBC plug-in is loaded by

ARDBC plug-in queries

ARDBC plug-in queries

For each form, ARDBC plug-in queries

1. Query vendor form to 6. Results are displayed in

2. Querying vendor form 5. ARDBC plug-in

4. ARDBC plug-in queries

Work Info model

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

• Company (tenancy definition and external company definition)

External company definition

SIT:Site Group Logical Assoc SIT:Site SIT:Site Company Association