bmc® remedy® it service management 7.0 archetecture

BMC® Remedy® IT Service Management 7.0

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 [email protected]. If you have comments or suggestions about this documentation, contact Information Development by email at [email protected].

This edition applies to version 7.0 of the licensed program.

BMC Software, Inc. www.bmc.com

mailto:[email protected]

mailto:[email protected]

http://www.bmc.com/

3

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

4

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

5

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

6

Process flows................................................................................................. 109 Main forms.................................................................................................... 110 ERD............................................................................................................... 112 Interfaces ....................................................................................................... 116

ITSM 7.0 subsystems........................................................................................... 117 Command Automation Interface ................................................................... 117

Overview....................................................................................................... 117 ERD............................................................................................................... 118 Interfaces ....................................................................................................... 126 Permission model .......................................................................................... 127

Contract Management .................................................................................... 127 ERD............................................................................................................... 128 Interfaces ....................................................................................................... 128 Permission model .......................................................................................... 128

Costing Management ...................................................................................... 129 ERD............................................................................................................... 131 Licensing model ............................................................................................ 131 Permission model .......................................................................................... 131

Definitive Software Library ........................................................................... 132 Architectural overview.................................................................................. 133 Primary components of the DSL................................................................... 133 ERDs ............................................................................................................. 134 Interfaces ....................................................................................................... 137 Web services ................................................................................................. 138 Permission model .......................................................................................... 140

Requester Console and SRMS framework.................................................... 140 Requester Console......................................................................................... 141 SRMS framework.......................................................................................... 144

Task Management System.............................................................................. 157 Architectural overview.................................................................................. 158 Instantiation................................................................................................... 159 Association model ......................................................................................... 162 Dependency model: flow mechanism ........................................................... 165 Sequencing (Basic) mode.............................................................................. 167 Data exchange model: variable pool ............................................................. 169 Complete example......................................................................................... 172 ERD............................................................................................................... 173

7

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

9

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

10

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.

11

• 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

12

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.

13

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

14

RequestConsole

IncidentManagement

AssetManagement

ChangeManagement

ProblemManagement(Investigation)

Primary ITSMApps

BMC AtriumCMDB

Service LevelManagementService LevelManagement

EndUsers

EndUsers Supporting

Applications

DSLKnowledge

ProblemManagement

(Known Error)

General Flow…

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.

15

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.

ITSM Foundation

CAI

SRMS Framework

RequestConsole

SLM

ITSM Foundation

Cost Subsystem

DSL

BMC Atrium CMDB

AssetManagement

SLM

ITSM Foundation

Cost Subsystem

DSL

BMC Atrium CMDB

AssetManagement

Knowledge

ITSM Foundation

Cost Subsystem

BMC Atrium CMDB

ProblemManagement

Knowledge

ITSM Foundation

Cost Subsystem

BMC Atrium CMDB

ProblemManagement

SLM

ITSM Foundation

Cost Subsystem

DSL

Task Management

BMC Atrium CMDB

ChangeManagement

SLM

ITSM Foundation

Cost Subsystem

DSL

Task Management

BMC Atrium CMDB

ChangeManagement

SLM

ITSM Foundation

Cost Subsystem

Task Management

BMC Atrium CMDB

IncidentManagement

SLM

ITSM Foundation

Cost Subsystem

Task Management

BMC Atrium CMDB

IncidentManagement

ITSM Foundation

CAI

TaskManagementSubsystem

ITSM Foundation

CAI

TaskManagementSubsystem

ITSM Foundation

CostManagementSubsystem

ITSM Foundation

CostManagementSubsystem

ITSM Foundation

DefinitiveSoftware Library

[DSL]

ITSM Foundation

DefinitiveSoftware Library

[DSL]

End

Use

rSu

bsys

tem

Bac

k O

ffice

Prim

ary

Sys

tem

sS

uppo

rting

Sub

syst

ems Common Automation

Interaction[CAI]

Notification EngineCategorizationsSupport Groups

PeopleOrganization

Location

ITSMFoundation

Notification EngineCategorizationsSupport Groups

PeopleOrganization

Location

ITSMFoundation

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

16

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

17

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

18

• 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

19

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

20

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.

21

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.

22

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.

23

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

24

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.

25

Overview console(contains table pointing to

Vendor form)

Vendor form (based on

SHR:ARDBCForm)

HPD:Helpdesk

CHG:Infrastructure Change

TMS:Task

ARDBC plug-in

1. Query vendor form to populate a table on the

console

2. Querying vendor form triggers ARDBC plug-in

6. Results are displayed in the table

3. ARDBC plug-in uses cached information on forms to

consolidate and field mappings from these forms to the Vendor

form

ARDBC plug-in also constructs a qualification for each form to

query, based on field mapping configuration information

4. ARDBC plug-in queries forms and retrieves results

5. ARDBC plug-in consolidates results lists

and returns vales to Vendor form

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.

26

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.

Incident

Target RequestTarget HPD:Associations

27

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

28

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.

29

ERD

SIT:Site Alias

SIT:Site Group Logical Assoc

SIT:Site Zone (Deprecated)

SIT:Site SIT:Site Company Association

COM:Company

CTM:Region SIT:Site Group

*

1* 1

*

11 * *

*

*

1*

1*

1

30

Organization Organization describes the role the company component plays in the foundation.

ERD

COM:Company Alias COM:Company

CTM:Region SIT:Site Group CTM:People Organization

CTM:Support Group Shift CTM:Support Group CTM:Support Group Alias

CTM:Support Group On-Call

CFG:Approver Lookup

CTM:Support Group Assignments

SIT:Site Alias

SIT:SiteSIT:Site Group Logical Assoc

SIT:Site Zone (Deprecated)

SIT:Site Company Association

* 1

1

*

*

*

*

*

1

*

1 *1

*

1

*

* 1

1

*

* *

*

1* 1

1

*

1

1

31

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.

COM:CompanyCompanyCompany IDCompany Type

CTM:Support GroupCompanySupport Organization Support GroupSupport Group ID Support Group Role

< Business Holidays Tag >< Business Workdays Tag >

SIT:SiteSiteSite ID (system generated)

Address Details (comprised of):StreetCountryState/ProvinceCityZip/Potal CodeTime Zone

COM:Company Alias

Company AliasCompany ID Primary Alias

CTM: Support Group Alias

Support Group AliasSupport Group IDPrimary Alias

SIT:Site Alias

Site AliasSite ID Primary Alias

SIT:Site Group Logical Assoc

CompanySite GroupSite Group Type ("Logical")Site ID

SIT:Site Zone (ITSP 4.0)DEPRECATED IN 7.0

Site ZoneSite ID

CTM:Support Group Shift

Support Group Shift NameSupport Group ID


Default Assignment Group IDSupport Group ID


Support Group IDOn-Call Paging TypePager Service Provider

Pager Phone Number (comprised of):CC PagerArea PagerLocal PagerPIN Pager

Pager E-mailRemedy Login IDBusiness Holidays TagBusiness Workdays Tag

CTM:RegionCompanyRegion

SIT:Site GroupCompanyRegionSite GroupSite Group Type

SIT:Site Company Association

CompanyRegionSite GroupSite ID

CTM:People Organization

CompanyOrganizarionDepartment

1

1

CFG:Approver Lookup

Approver Login IDApproval TypeApproval For

N

1

N N

N

N 1 1

N

N

N

N

N

1 1

1

N

NN

N

N

N

N

1

32

ERD

CTM:People

User

CTM:SupportGroup

CTM:Support Group Association

CTM:SupportGroupFunctionalRole

CTM:People Worklog AST:AssetPeople

CMDB Classes

FIN:CostCenterAssociation

FIN:ConfigCostCentersRepository

CTM:People Permission Groups

1

*

Data Access*

*

Application Permissions

NTE:CFG-NotificationEvents

*

*

*

**

*

*

1

*

*

1

1

1

1

*

*

Combination of Support Group and Person ID

*

*

Company

Region

Site Group

Site

Organization

Department

Support Organization

Support Group

Company

Region

Site Group

Site

Organization

Department

Support Organization

Support Group

- A person belongs to a Company and location- A Support Staff belongs to a Support Group

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

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

CI Associations- associate to CIs with type: uses, manages, supports, owns

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

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

Login and Licensing Information

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

Permission Groups- for Support Staff only- allows users access to various modules

Financials- Cost centers (multiples)

- Hourly rate, Accounting code

33

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 groupP

Organization

Support company

34

Support Group ERD

COM:Company

CTM:Support Group Shift CTM:Support Group CTM:Support Group Alias


CFG:Approver Lookup


1

*

1 *1

*

1

*

* 1

1

*

1

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.

35

Operational categorization

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:ProductCompanyAssociation PCT:Product Model/Version

PCT:ProductModelVersionPatch

PCT:ProductAlias

1 *

*

*

*

*

1

*

1

Operational categorization

CFG:Service Catalog CFG:Service Catalog Association

1 *

36

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.

CFG:Service Catalog

Categorization IDCategorization Tier 1Categorization Tier 2Categorization Tier 3DescriptionStatus

CFG:Service Catalog Assoc

Categorization IDCompanyStatus

N1

37

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

38

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.

39

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.

40

ERD

Assignment Engine

Phase 2

Phase 1

Request Form

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.

41

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

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.

SLM

ITSM Foundation

Cost Subsystem

DSL

Task Management

BMC Atrium CMDB

ChangeManagement

SLM

ITSM Foundation

Cost Subsystem

DSL

Task Management

BMC Atrium CMDB

ChangeManagement

42

C hange M anagem ent P rocess

C h a n g e A p p ro v e r

C h a n g e

Im p le m e n te r

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

(S u b je c tM a tte r

E x p e rt)

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

O th e rS e rv ic e S u p p o rt/

D e liv e ry P ro c e s s e s

C h a n g e R e q u e s te r

1 C hang e

In itiation and R ecord ing

3C hange

P lann ing and Schedulin g 5

C hang e C om pletion an d

C lo su re

C onfigu ration M anagem ent

Problem M anagem ent Incident

M anagem ent R equ est M anagem ent

4C hange

Im p lem entatio n

, I .

2 R eview and

Au th orize

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.

43

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

44

• 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

45

(PBM:Problem Investigation, CFG:Broadcast, and TMS:Task forms) can be represented in an association table.

Change RecordCID: 23

ASID CID Description Status Other DataT653 23 Task 12 WIP XB21 23 Broadcast 1 Active YB83 23 Broadcast 2 Active Z

P242 23 Problem A Open A

Assocation Table

CFG:BroadcastBID: B83BID: B21

PBM:Prob. Inv.PID: P242

TMS: TaskTID: T653



ASID CID Description Status Other DataT653 23 Task 12 WIP XB21 23 Broadcast 1 Active YB83 23 Broadcast 2 Active Z

P242 23 Problem A Open A

Assocation Table



PBM:Prob. Inv.PID: P242PBM:Prob. Inv.

PID: P242

TMS: TaskTID: T653TMS: 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.

46

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.



CHG:CR AuditAID: 523 Fkey: 23

AID: 284 Fkey: 23

CHG:CR AuditAID: 523 Fkey: 23

AID: 284 Fkey: 23

CHG:WorkLogWID: 523 Fkey: 23

WID: 284 Fkey: 23

CHG:WorkLogWID: 523 Fkey: 23

WID: 284 Fkey: 23

CFG:RemindersRID: 295Fkey: 23

RID: 841Fkey: 23

CFG:RemindersRID: 295Fkey: 23

RID: 841Fkey: 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:RequestRID: R46

SRM:RequestRID: R46

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

47

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.

48

Change Record

Tier 1: HardwareTier 2: DesktopTier 3: Disk

CID: 23

Tier 1: Tier 2: Tier 3:

CATID Tier 1 Tier 2 Tier 3635 Hardware Desktop Disk243 Hardware Laptop Memory902 Hardware Server CPU Card

Categories

Change Record

Tier 1: HardwareTier 2: DesktopTier 3: Disk

CID: 23

Tier 1: Tier 2: Tier 3:

CATID Tier 1 Tier 2 Tier 3635 Hardware Desktop Disk243 Hardware Laptop Memory902 Hardware Server CPU Card

Categories

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

49

The following ER diagram illustrates how these primary data elements can be related to the change request by way of the association forms (shaded).

LDAP

Asset Management

Problem Management

Incident Management


CHG:Associations

TMS:Task TMS:TaskGroup

TMS:Associations

FIN:Costs FIN:Association

TMS:LDAPUser

TMS:LDAPGroup

PBM:Problem Investigation

AST:*

PDL:SoftwareLibraryItem

PBM:Known Error

PBM:Knowledge Database

AST:Configuration

AST: CI Unavailability

HPD:Help Desk


ERD for CHG:Infrastructure Change - Associations

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

• Auditing

• Risk information

• Factors • Questions

50

• Reminders

• Impacted areas

• Work-related information

• Effort tracking

• Tasks

• Task • Task Group

• User requests

• Broadcasts

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


CHG:Infra. Change Effort

Log

CHG:WorkLog

Foreign Key: Infrastructure Change ID

TMS:Task

TMS:TaskGroup

Foreign Key: RootRequestID

CHG:ChangeRiskFactors

CHG:ChangeRiskFactorQuestionL

ookupCFG:Reminders

CHG:Impacted Areas

CHG:Change Request Audit

SRM:Request

TMS:FlowBuilder TMS:Flow TMS:SummaryData

Foreign Key: SRInstanceID

Foreign Key: Instance ID

CFG:Broadcasts

51

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

52

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


CTM:People

CTM:Region

COM:Company CTM:Support Group

Region/Site Group/Site

Requested ByRequested For

ManagerAssignee

Implementer

CFG:Service Catalog

PCT:Product Catalog

Operational Category

Product Category

SIT:Site Group

SIT:Site

53

Comprehensive ERD

LDAP

Asset Management

Problem Management

Incident Management


CHG:Associations

TMS:Task

TMS:TaskGroup

TMS:Associations

FIN:Costs

FIN:Association

TMS:LDAPUser

TMS:LDAPGroupPBM:Problem Investigation

AST:*


PBM:Known Error

PBM:Knowledge Database

AST:Configuration


HPD:Help Desk


CHG:Infra. Change Effort

LogCHG:WorkLog

CHG:ChangeRiskFactors

CHG:ChangeRiskFactorQuestionL

ookupCFG:Reminders

CHG:Impacted Areas

CHG:Change Request Audit

TMS:FlowBuilder

TMS:Flow

TMS:SummaryData

Foreign Key: Infrastructure Change ID

TMS:Task

TMS:TaskGroup

Foreign Key: RootRequestID

SRM:Request Foreign Key: SRInstanceID

CTM:Region


CFG:Service Catalog

PCT:Product Catalog


Product Category

SIT:Site Group

SIT:Site

CTM:People

COM:Company

CTM:Support Group

Foreign Key: Instance ID


ManagerAssignee

Implementer

CFG:Broadcasts

54

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.

55

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.

56

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.

57

AR System mid tier

CCM Calendar

AR API

Browser

CalendarClient Runtime

Script

CalendarPlugin

RequestDispatcher

EventDispatcher

Renderer

Model

Plug-in Container

BMC Atrium CMDB API

CSS Files

JavaScript Files

58

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

59

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

60

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

The Change Management Dashboard component consists of three forms:

• CFB:CCMFlashboard

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

• CFB:FlashboardData

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

• CFB:FlashboardUserView

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

61

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.

62

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.

63

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.

64

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.

65

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.

66

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:

67

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 enterprise configuration items (CIs)—and their changing relationships—throughout the entire asset life cycle. Asset Management tracks contracts, financial costs, software licenses, outage indicators, and more for the CI information stored within the BMC Atrium CMDB 2.0 application.

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

SLM

ITSM Foundation

Cost Subsystem

DSL

BMC Atrium CMDB

AssetManagement

SLM

ITSM Foundation

Cost Subsystem

DSL

BMC Atrium CMDB

AssetManagement

68

Process flows

ITSM configuration management process overview

Asse

t man

ager

Con

figur

atio

n au

dito

rSe

rvic

e su

ppor

t,se

rvic

e de

liver

y,an

d ot

her

rela

ted

proc

esse

s

1Configuration management

planning

2Configuration identification

3Configuration specifications

4Configuration control

Change Management

5Configuration

audit and verification

Incident Management

ChangeManagement

CMDB

Incident Management

Change Management

© 2004 BMC Software, Inc. All rights reserved.

AssetManagement

AssetManagement

RFC

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.

69

Object1 : AST:ComputerSystem

BMC:CORE:BMC_ComputerSystem

Join

User Interface Forms (Joins)

BMC Atrium CMDB Class Forms

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.

70

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

71

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

72

Asset Management ERD

Integrated Systems

Contracts

AST:AssetSupport

AST:AssetWarranty

AST:AssetSoftware

AST:Asset Lease

AST:AssetMaintenance

UI Joins on top of CMDB

CMDB Classes

AST:ImpactedAreas AST:CI Unavailability AST:CMDB Associations

HPD:Help Desk

PBM:Problem Investigation

PBM:Known Error


TMS:Task

FIN:CostAssociation AST:AssetCost AST:WorkInfo AST:AssetPeopleAST:Schedule Assocations

AST:ScheduleCriteria FIN:Costs CTM:People

1

*

* *

*

*

**

*

*

*

1

1

*

1

*

*

*

1

**

1

1

1

*

*

73

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.

74

Component Form Comments

Main Asset Extensions AST:AssetMaintenance_ Maintenance extension to the contract subsystem.

Main Asset Extensions AST:AssetSoftware Join between the software license extension and the contract subsystem to display software contracts.

Main Asset Extensions AST:AssetSoftware_ Software license extension to the contract subsystem.

Main Asset Extensions AST:AssetSupport Join between the support contract extension and the contract subsystem to display support contracts.

Main Asset Extensions AST:AssetSupport_ Support contract extension to the contract subsystem.

Main Asset Extensions AST:AssetWarranty Join between the warranty contract extension and the contract subsystem to display warranty contracts.

Main Asset Extensions AST:AssetWarranty_ Warranty contract extension to the contract subsystem.

Main Asset Extensions AST:AssetCost Stores depreciation schedules.

Main Asset Extensions AST:AssetCostDepreciationHeader Stores the details about the type of deprecation models being used.

Asset Purchasing AST:PurchaseLineItem Line items for the purchase orders and requisitions.

Asset Purchasing AST:PurchaseOrder The holder of the purchase order.

Asset Purchasing AST:PurchaseRequisition Holds the details on the purchase requisition.

Asset Purchasing AST:PurchaseReturn Holds the return orders.

Software license management The software license component of Asset Management is designed to automatically link software instances with the contracts that describe the licenses that have been purchased for those software instances.

The link is based on the normalization of the software instances by using the definitive software library (DSL) and the underlying product dictionary that is

75

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.

AST:Contract_PD_Relationship

Product IDProduct Instance IDModel/Version IDPMVInstance ID

Contract IDContract Instance ID

ProductCompanyAssociation Instance ID

AST:AssetSoftware (Join)

Contract Instance ID

PDL:Product Dictionary (Join)

PMVInstance IDProductCompanyAssociation Instance ID

AST:ProductDictionarySearch

76

BMC:BMC_AssetBase

Discovery

AST:ConfigLicenseMgmt

AST:LicenseMgmtEngine

AST:Contract_PD_Relationship

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.

77

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.

78

Field Description

Support Company, Support Organization, Group

Fields to indicate what support group is defined as the notification group for the given configuration rule.

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

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

AST:ManageLicenseMgmtException A join form between the AST:LicenseMgmtException and BMC:BMC_AssetBase forms. This form serves as the primary user interface for users to manage records that are unsuccessfully processed by the License Management Engine. This user interface is accessed from the Asset Management Console by clicking the Manage Contracts link under General Functions, and then selecting License Management Exception.

Nightly escalations evaluate records in this form for action:

1. If Status = Completed and Exception Decision = Process CI, then process the CI through the License Management Engine for relating to a contract. This action assumes that an asset administrator has made sure that a licensable product has been linked to a contract so that the License Management Engine can successfully process the CI.

2. If Status = Completed and Exception Decision = Delete, then the exception is deleted. This means that the asset administrator has determined that the CI does not need to have contracts related to it.

Only users with Asset Admin permissions can access this form.

Row-level locking by the Company field has been implemented on this form. The Company field controls who can see exception records. If you have unrestricted access defined in the People form, then you can search for all records.

79

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.

80

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:PurchaseLineItem

AST:PurchaseOrder AST:PurchaseRequisition

AST:PurchaseReturn

AST:PurchaseRequisitonWorklog

1

*

FK: Order Instance ID1

*

FK: Requisition Instance ID

0..1 0..1

FK: Line Item Instance ID

1 *

FK: Requisition Instance ID

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.

81

• 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

CTR:ContractBase

AST:AssetWarranty

Join Between AST:Warranty_ and CTR:ContractBase

CTM:People

1 *

FK:CompanyName

AST:WorkLog

CTR:ContractPayments

AST:CMDB Associations

*

*

FK: Instance ID

**

FK: Instance ID

*

*

«subsystem»BMC Atrium

CMDB Forms**

Reconciliation ID

1*

Child Contracts

Shaded box = Contract subsystem provided

COM:Company*

*

FK: Serveral Companies Names

82

Support contracts

CTR:ContractBase

AST:AssetSupport

Join Between AST:Support_ and CTR:ContractBase

CTM:People

1 *

FK:CompanyName

AST:WorkLog



*

*

FK: Instance ID

**

FK: Instance ID

*

*

«subsystem»CMDB Forms

**

Reconciliation ID

1*

Child Contracts


COM:Company*

*


83

Lease contracts

CTR:ContractBase

AST:AssetLease

Join Between AST:Lease_ and CTR:ContractBase

CTM:People

1*

FK:CompanyName

AST:WorkLog



*

*

FK: Instance ID

**

FK: Instance ID

*

*

«subsystem»Top Package::CMDB Forms

**

Reconciliation ID

1*

Child Contracts


COM:Company*

*


CHG:Infrastructure Change*

*

End Of Lease Support

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.

84

Maintenance contracts

CTR:ContractBase


Join Between AST:Maintenance_ and CTR:ContractBase

CTM:People

1*

FK:CompanyName

AST:WorkLog



*

*

FK: Instance ID

**

FK: Instance ID

*

*


**

Reconciliation ID

1*

Child Contracts


COM:Company*

*


85

Software contracts

CTR:ContractBase


Join Between AST:Maintenance_ and CTR:ContractBase

CTM:People1

*

FK:CompanyName

AST:WorkLog



*

*

FK: Instance ID

**

FK: Instance ID

*

*


**

Reconciliation ID

1*

Child Contracts


COM:Company*

*


AST:Keys and Versions

AST:Contract PD Relationship PDL:Product Dictionary

*

*

Licenseable Product

* *

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

86

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.

87

AST:CI Unavailbility

Business Time Shared Entity

CMDB Classes

1

*

1

1

88

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

AST:Schedule Criteria

CHG:Template

*

*

1

1

1 1

Subsystem integration The following subsystems are used by Asset Management:

• Cost Management

• Service Level Management

• BMC Atrium CMDB

89

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.

90

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.

91

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.

92

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

Mapping of Asset Management roles to Asset Management functions The following table maps Asset Management roles to Asset Management functions.

Asset Management component

Asset Admin role

Asset User role

Asset Viewer role

Purchasing User role

Receiving User role

Manage CIs Write access to all CIs and functions

Read access

Write access to CIs the user supports. Includes ability to create:

• Contracts

• Configurations

• Relationships

• Costs

• Schedules

• Outages

• Returns

• Activities

• Impacted areas

Read access

No access No access

Manage Inventory

Access to all inventory functions

No access from Asset Management console

No access from Asset Manage-ment console


No Access from Asset Manage- ment console

93


Asset Admin role

Asset User role

Asset Viewer role


Receiving User role

Manage Contracts

Write access to all contracts


Write access from CIs the user supports


Read access from CI forms

No access No access

Manage Configurations

Access to all configuration functions


Read access



Read access


No access No access

Manage Costs Access to all cost functions


Read access



Read access


No access No access

Bulk Updates Access to bulk update functions

No access No access

No access No access

94


Asset Admin role

Asset User role

Asset Viewer role


Receiving User role

Schedules Access to all scheduling functions


Read access



Read access


No access No access

Purchasing Console

No access No access No access

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

Write access to purchase orders

No access

Receiving Console

No access No access No access

No access Access to receiving functions

BMC Remedy Service Desk architecture Service Desk enables IT to respond quickly and efficiently to conditions that disrupt critical services by automating incident and problem management processes. Service Desk acts as a single point of contact for user requests, 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.

95

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.

IncidentManagement

Process

End UserRequest

ProblemInvestigation

KnownError

Management

ChangeManagement

To CorrectErrors

Notified ofCompleted 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.

Incidents can enter the system manually or automatically. Users can create incidents using the Requester Console. The Requester Console provides users a simple interface for entering and managing their requests. Incident Management integrates with the Requester Console to provide this interface. Support technicians at the service desk can also manually enter incidents using the HPD:Help Desk form. Several functions are provided to make entering incidents easier, including templates, scripts, and automation.

Incidents can also be created automatically. The Incident Management application provides integration interfaces that allow external applications to create, modify, and query data in the Incident Management database. The integration between the BMC Service Impact Manager and Incident Management is an example of an

SLM

ITSM Foundation

Cost Subsystem

Task Management

BMC Atrium CMDB

IncidentManagement

SLM

ITSM Foundation

Cost Subsystem

Task Management

BMC Atrium CMDB

IncidentManagement

96

external application that integrates with Incident Management to generate incidents based on events in the service model.

Process flows

<Process Name>

<Fun

ctio

n>

Yes

NoResolution and

recovery

Identification and recording

(Classification and initial support)

Investigation and diagnosis

N o

Yes

IncidentCcosure

Incident detected

ITSM manual incident management process overview

ITSM auto-detect incident management process overview

Self correcting?

Incident Auto Detected?

Identification and recording

(Classification)

Incidentclosure

Inci

dent

M

anag

er

Inci

dent

Que

ue

Man

ager

(O

ptio

nal)

Inci

dent

Ass

igne

e (T

ier

2/3/

n)In

cide

nt A

ssig

nee

(Tie

r 1)

Oth

er S

ervi

ce S

uppo

rt /

Del

iver

y P

roce

sses

Cus

tom

er

1Incident

Detection and Recording

2Classification

and Initial Support

3Investigation

and Diagnosis

5Incident Closure

4Resolution and

Recovery

Incident Detected

Web Self-Help

Call to Service Desk

Event MonitoringIncident Detected

IncidentRecorded

Request Management

Configuration Management

Capacity / Availability

Management

Change Management

ProblemManagement

Change Management

ProblemManagement

ProblemManagement

ProblemManagement

Resolution /Workaround

Validation

No AvailableResolution / Workaround

Resolution / Workaround

Found

Resolution / WorkaroundValidated and

Accepted

Service Level Management

97

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.

98

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.

99

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

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

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

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

Subsystem integration The following subsystems are used by Incident Management:


• Task Management System

• Cost Management

• Service Level Management (SLM)

• BMC Atrium CMDB

100

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.

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.

C eate

Get

or Set

Requester Console

Application Object

Events

CAI:EventParams holds the field mapping when

incident communicates with the SRMS framework

Event

CAI:Events

HPD:IncidentInterface_Create

HPD:IncidentInterface

HPD:Help Desk

SRMS framework

101

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

Service Desk

Problem Management

Ad-hoc creation only

Incident Management

TMS:Tasks

TMS

102

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.

103

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.

104

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.

105

ERD

Asset Management/CMDB

Problem Management

Change Management

HPD:Help Desk

HPD:Association

TMS:Task

TMS: Associations

FIN: Costs FIN: Association CFG: BroadcastCFG: Broadcast Association

PBM: Problem Investigation

BMC:*CMDB Classes

PBM: Known Error

PBM: Knowledge Database

:


HPD:Help Desk

HPD:HelpDesk_AuditLogSystemForeign Key:Request ID

CTM:People

CTM:Company

HPD:ImpactedAreasForeign Key:

Incident Number

(See Note)

(See Note)

Lookup Data

PCT:Product Catalog

CFG:Service Catalog

CTM:Support Group

HPD:Work LogForeign Key:

Incident Number

(See Note)

SIT:Site



106

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

CTM:CompanyUsed 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 GroupUsed in various contexts, key back is the login ID for each of these areas:- Owner Support Group- Assignee Support Group

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

107

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

HPD:IncidentInterface(Staging form) HPD:Help Desk

External application

Creates staging record using Help Desk Submit web

serviceProcesses incoming

parameters

Creates Help Desk record and Work Log

record

ITSM

Help desk ticket submit

Data flow direction

HPD:Work Log

Association forms

Creates an association with a CI if a CI name

is specified

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.

108

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 infrastructure, and working to correct that known error.

Problem Management has three main components:

• Problem investigation

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

Knowledge

ITSM Foundation

Cost Subsystem

BMC Atrium CMDB

ProblemManagement

Knowledge

ITSM Foundation

Cost Subsystem

BMC Atrium CMDB

ProblemManagement

109

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

Pro

blem

Man

ager

Pro

blem

Ass

igne

eO

ther

Ser

vice

Sup

port

/ D

eliv

ery

Proc

esse

sR

eque

ster

1Problem

Identification, Recording and Classification

2Review

3Problem

Investigation and Diagnosis

4Problem

Resolution and Closure

Investigation Initiated

Change Management

5Known ErrorIdentification

and Recording

6Known Error Classification

and Assessment

7Known Error

Resolution and Closure

Incident Management

ChangeImplemented

© 2004 BMC Software, Inc. All rights reserved.

8Knowledge

Identification and Recording

9Knowledge

Validation and Publication

Incident Management

Incident Management

ConfigurationManagement

(Mgmt Reports)

110

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.

111

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.

112

ERD

Incident Management

Asset Management/CMDB

Problem Management

Change Management

PBM: ProblemInvestigation

PBM: Associations

TMS:Task

TMS: Associations



BMC:*CMDB Classes

PBM: Known Error

PBM:SolutionDatabase

:


CHG:::InfrastructureChange

HPD: Help Desk

PBM:Problem_AuditLogSystemForeign Key:Request ID

CTM:People

CTM:Company

PBM:ImpactedAreasForeign Key:

Incident Number

(See Note)

(See Note)

Lookup Data

PCT:Product Catalog

CFG:Service Catalog

CTM:Support Group

PBM:Work LogForeign Key:

Incident Number

(See Note)

SIT:Site


113

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

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

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

114

Incident Management

Asset Management/BMC Atrium CMDB

Problem Management

Change Management

PBM: Known Error

PBM: Known Error Associations

TMS:Task

TMS: Associations



BMC:*CMDB Classes

PBM: Known Error

PBM: SolutionDatabase

:



HPD: Help Desk


CTM:People

CTM:Company(See Note)

(See Note)

Lookup Data

PCT:Product Catalog

CFG:Service Catalog

CTM:Support Group

PBM:Known Error Work LogForeign Key:

Incident Number

(See Note)

SIT:Site


115

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

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

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

116

Incident Management

Asset Management/BMC Atrium CMDB

Problem Management

Change Management

PBM: Solution Database

PBM: SolutionAssociations

TMS:Task

TMS: Associations

FIN:Costs FIN: Association


BMC:*CMDB Classes

PBM: Known Error

PBM: SolutionDatabase

:



HPD: Help Desk


CTM:People

CTM:CompanyForeign Key:Assignee Company

Foreign Key:Assingee

Lookup Data

PCT:Product Catalog

CFG:Service Catalog

CTM:Support Group

PBM:Solution Work LogForeign Key:

Incident Number

Foreign Key:Support Group

SIT:Site


Interfaces • PBM:ProblemInterface_Create

• PBM:ProblemInterface

117

• 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

118

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.

Done

ID Name ProtocolApp Registry

Definition Construction Execution

Command Direction Op. TypeCommands

Param Data Type ModeParameters

What How Just Do ItEvent Data Values Command Content Runtime Command

2

3

4

51

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.

119

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.

120

CAI : Event

EventGUID Event Source Target SourceAppRegistryInstanceIAOIGUID AppInterfaceFormNameTargetConnectionInfRtnCode RtnMsgCode RtnMsg MaxRetries RetryCounter

CAI :EventParam

EventGUIDParmNameParamValueParamAttachmentValue ParamTypeParamDataType

CAI : AppRegistry

U 1 InstanceID U 2 AppRegistryName

ApplicationName ApplicationInstanceIDProtocol Connection Info Interface Form Names

CAI : Command

U 1 Command Direction OperationType SelectionType

CAI :CommandParam

U1 CommandU1 CommandParam

TypeDataTypeMode

CAI :CommandParamMappin

AppRegistryNameCommandCommandParamAppInterfaceFormName AppFieldNameAppFieldIDParamTypeParamDataType

SRMS framework/TMS

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

Filter API Plug-in

App Interface Form

Mapped Param

Push event and event params

Calls GetEntry to get event values

1 . Register

0 . Create commands and command paramters

2. Map command paramters for each registered

Definition

Construction

Execution (outbound) AR System workflow

Browser

Launch

121

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

122

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.

CAI:Event

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

CAI:EventParam

EventGUID ParmName ParamValue ParamAttachmentValue ParamType ParamDataType

CAI:AppRegistry

U1 InstanceIDU2 AppRegistryName ApplicationName ApplicationInstanceID Protocol Connection Info Interface Form Names

CAI:Command

U1 Command Direction OperationType SelectionType

CAI:CommandParam

U1 CommandU1 CommandParam Type DataType Mode

CAI:CommandParamMapping

AppRegistryName Command CommandParam AppInterfaceFormName AppFieldName AppFieldID ParamType ParamDataType

SRMS/TMS

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

FilterAPI Plug-in

App Interface Form

Mapped Param

Push event and event params

Calls GetEntry to get event values

1. Register application

0. Create commands and command paramters

2. Map command paramters for each registered application

Definition

Construction

Execution (outbound)

AR System workflow

Browser

Launch

123

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.

124

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.

125

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

Service Request

Main Plug-in code

CAI:EventParams

CAI:Events

HPD:HelpDesk


1. Event is created in CAI:Events form; parameters are pushed to

CAI:EventParams form

2. When an entry is created in the CAI:Events

form, the CAI plug-in is called

3. The CAI plug-in creates an entry in the

request queue and returns Status =

Running to CAI Events form

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

Incident

CAI Plug-inThread Pool

Request queue

4. When a request is added to the

queue, a signal is issued to wake up a thread in the thread pool to process the

request.

6. CAI plug-in returns status to

CAI:Events form

126

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.

127

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

Base form Operation description Operation name Interface form*

Form type

CAI:Events (root) Query individual event OpGet CAI:Events (root) Regular

CAI::EventParams Query list of entries OpGetList CAI::EventParams Regular

Create CAI event and CAI event parameters

Op Create

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

Permission model The CAI has the Command Event Master role, which by default is mapped to the Command Event Master group, and can be granted to users using the People form. Only users in this group and AR System administrators can access the CAI forms and update certain fields on them. For implementation of event error handling, integrating applications must have the same group and role mapping.

For remote access using AR protocol, the remote AR System login must have permission to create and update to the interface forms specified in the AppRegistry form. Similarly, for the back-end application to send inbound commands to the remote front-end application, such as TMS, the TMS AR System login must have permission to create records in the event and event parameters forms. See the 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.

128

ERD

CTR:ContractBase CTR:ContractPayments

Application specific contracts

Join

CTR:ContractAuditLogSystem

Contract Management subsystem

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.

129

Each Contract Management permission group is mapped to an Asset Management permission group, as shown in the following table.

Contract Management permission group

Asset Management permission group

Access

Contract View Only Asset Viewer Read

Contract Full Access Asset User, Asset Admin Write

Contract Administrator - (reserved for future use) N/A

Write

Costing Management The Costing Management subsystem provides functions required by the ITSM suite for management of cost data. The costing model has two components: tracking of costs, and chargeback calculations and reporting.

Each application uses Costing Management to track the costs related to the records in the application. For example, Incident Management uses Costing Management to track the various costs associated to incidents.

Asset Management also uses the chargeback functionality in Costing Management. Chargebacks are roll ups of the costs that have been incurred over a period and involved in the various cost centers in a company. The chargeback component of Costing Management generates chargeback entries, lets the financial manager make appropriate adjustments to the costs, and generates invoices to be sent out to the individual cost centers.

Costing Management is designed to be completely standalone. The main form, FIN:Costs, holds individual cost data. The relationships to the main records use associations in the FIN:Associatons table. Costing Management also provides a join between the FIN:Costs and FIN:Assocaitons tables to provide the query interface for use by applications that integrate with the subsystem. This join is used by table fields in ITSM applications.

The chargeback functionality is enabled by a filter API application. It is driven by data in the chargeback forms that define the cost centers, how the cost centers are allocated, and the dates for running chargeback reports. The result of the API run is a set of chargeback entries. The chargeback functionality provides an adjustment user interface that is used to adjust the chargeback costs, and a reporting user interface to run invoices.

The costing forms and workflow are encapsulated in a deployable application. This provides the ability to license and abstract the roles for the subsystem.

Costing Management has clearly defined interfaces for integration, with a programmatic interface used for creating and modifying data. Users can also create

130

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

Interface Form Functions:

Creating Automatic Cost EntriesUpdating Automatic CostsLock Cost EntriesCopy Cost RecordRequest 112 update on Associated Costs

Calling System Interaction

131

ERD

FIN:Association

Calling System FormCalling System Identifier

Cost Record Instance ID

Association TypePrimaryInformationalAllocation

FIN:Cost

Cost CenterCost TypeDescriptionAmountUnitsDate IncurredInstance ID

Calling System Table

Identifier

FIN:CostAssociationJoin

FIN:ChargeBacks

Populated using a filter APIprocess with cost data andcost center allocations fromFIN:Cost . Used for chargeback reporting.

Filter API

Base Data Model

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.

132

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.

133

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

Change Management

Common Management Services

Task Management

System

CMDB

Definitive Software Library

Command Automation

Interface

DeploymentManager

Change Request

• Product Lookup• DSL Reference• Related CI Targets

Policy Manager

Change ManagerChange Assignee

Task Implementer

Asset Management

• Software License Mgmt• Approvals• …

System to System InteractionData Interaction

Configuration Discovery

Change Management

Common Management Services

Task Management

System

CMDBCMDB

Definitive Software Library

Command Automation

Interface

DeploymentManager

DeploymentManager

Change Request


Change Request


Policy Manager

Policy Manager

Change ManagerChange Assignee

Task Implementer

Asset Management


Asset Management


System to System InteractionData Interaction

Configuration Discovery

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.

134

The following diagram provides a high-level illustration of how these components are organized as part of the DSL.

The Definitive Software Library (DSL)

Product Dictionary

• Product Name • Version • Patch • Manufacturer

S/W Library Item Software Location

Information

Software Library Item Software location

information

Files List of

Related Files

Files List of

related files

Suites

Products Related

to a Suite

Suites

Products related

to a suite

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.

135

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

Product

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

Version

+VIID+FileID

PV_Files Lookup

-FIID+Name+FileSize+CRC+TimeStamp

Files

- CIID + Company + Type

Company

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

ProductModelVersion

+SuiteIID+VIID

Suite_PD Lookup

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

SLI

- VVIID + Description + VersionString + ComponentNam

Vendor Version

1

n

n 1

Legend

PD / DSL Objects Foundation Objects

Only required fields are represented.

n

n

n

n

n

1

-Attachment IID+DSL IID+Description+Attachment

Attachments

n

1

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

ProductCompany A

. n

1

-VIID-PIID+CIType+ProductCat1+ProductCat2+ProductCat3+PMV State+Product Name+Manufacturer

ProductDictionary

n

1

n

1

-PIID+PMVIID+PatchLastBuildID

ModelVersionPatch

-PMVIID-ProductIID-PatchIID-.-.-.

ProductDictionaryPatch1n

1 n

1

n

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.

136

PCT:Product Catalog

PK Instance ID

ProductIDCI ClassProductCatTier 1ProductCatTier 2ProductCatTier 3Product NameManufacturerPriceProduct 's Image

PCT:Product Mod/Version

PK Instance ID

PMV IDProduct IIDProdMod VersPMV StateProduct NameManufacturerPatchLastBuildIDManufacturerPartNoGeneralAvailDTDiscAvailDTDiscSupportDTPreReleaseDate

Add DSL Fields

OriginIsSuite

Add DSL Fields

GUIDOSLocalePlatformVersionMajorVersionMinorVersionBuildVersionMaintManufacturerID

PCT:ProductCompanyAssoc

PK InstanceID

ProductIIDCompany

PDL:ProductModelVersion

PK InstanceID

Product IDPMV IDProductIIDProdModVerPMV StateProductName.....OSLocalePlatformVersionMajorVersionMinorVersionBuildVersionMaint

PDL:ProductDictionary

PK VersionIID

ProductIDCI ClassProductCatTier 1ProductCatTier 2ProductCatTier 3ProductNameManufacturerManufacturerIDGUIDOSOriginIsSuiteLocalePlatformPMV StateProductName

JOINJOIN

PDL:ProdDictionaryPatch

PK PatchIID

ProductIDCI ClassProductCatTier 1ProductCatTier 2ProductCatTier 3ProductNameManufacturerManufacturerIDGUIDOSMainExeIDMainExeNameOriginIsSuiteLocalePlatformProductIDPMV StateProductName

PCT:ModelVersionPatch

PK Instance ID

Product NameModel VersionPatchLastBuildIDMainExeIDMainExeName

JOIN

Data example

PD1 V2 Word C0

PD2 V3 Excel C0

PD3 V1 Outlook C0... ... ... ...PD4 V4 Office C0

Product Dictionary (Join)

Software Library Item

SLI2 PA2 Shelf

SLI3 PA3 Disk

Product Company

Association

PD1 -Global-

PD2 -Global-

PD3 -Global-

Files Lookup

V2 F1

V1 F3

Suite Mapping

PD4 PD3... has .../... has ... PD4 PD2

PD4 PD1V1 PD3 4.0

... ... ... V2 PD1 3.0

... ... ... V3 PD2 4.2

... ... ... V4 PD4 6.0

Model/Version Base

PD1 C1 3rd Party No

PD2 C1 3rd Party No

PD3 C1 3rd Party No

PD4 C1 3rd Parth Yes

Product Catalog Base

Files

F1 Word.exe 3784FF2 Excel.exe 1816

Company/Manufacturer

C1 MS WA...C2 Dell TX

KBVersion

KB1 1.0

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

CIID Name State

PIID CIID Origin Is Suite

VIID PIID Version

FIID Name File Size

F3 Outlk.exe 2590

PIID Company

C0 -Global- --...

Product Model/Version (Join)

PD1 V2 WordFPD2 V3 Excel

PIID VIID Name

PD3 V1 Outlook

PD4 V4 Office

PIID VIID Name CIID

SuiteIID PDIID

Model/Version Patch

V2 PA1 2.3

V3 PA2 1.0

VIID PatchIID Patch

SLI1 PA1 Shelf

VIID FIID

VVID Version

SLIID PIID Location...

V1 PA3 0.0

ProductDictionaryPatch (Join)

V3 PA2 PA2

V1 PA3 PA3

V2 PA1 PA1

VIID PIID PatchIID

...

137

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.

138

PDL:SLIInterface_Create(staging form)

External application

Creates staging record using

Product Dictionary web

serviceProcesses incoming

parameters

ITSM

Software Library Item submit

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.

139

• 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:

Base form and type Operation description Operation name Interface form

PDL:Product Dictionary

Self-join

Query list of entries

PD_QueryList_Service PDL:PDInterface

Query field list PD_QueryListFields_Service

PDL:Product Dictionary Patch

Self-join

Query list of entries

PDP_QueryList_Service PDL:PDPInterface

Query field list PDP_QueryListFields_Service


Regular

Create SLI PDL_SLI_Submit_Service PDL:SLIInterface_Create

Self-join Modify SLI SLI_Modify_Service PDL:SLIInterface

Query for specific SLI

SLI_Query_Service

Query for list of SLIs

SLI_QueryList_Service

Query field list SLI_QueryListFields_Service

140

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.

RequesterConsole

ChangeManagement

IncidentManagement

Request Obj t

SRMS Framework

OR

RequesterConsole

ChangeManagement

IncidentManagement

Request object

SRMS framework

OR

141

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

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

142

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

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

Category Component Description

Configuration SRM:ApplicationSettings Contains records to determine the settings for the Requester Console and the SRMS framework.

This data includes settings to:

• Specify the server tenancy mode.

• Allow unknown users.

• Supply default submit data for unknown users.

• Supply default request ID text.

• Enable the Requester Console.

• Supply AR System logins for access to Change Management and Incident Management.

This form has one entry and it can be modified, but not deleted. No additional entries are allowed.

Configuration SRM:CFG Rules Contains records to determine the service request rules by company. These rules include settings for auto-close, survey, and individual auto-assignment.

Configuration SRM:ConsolePreferences Stores preferences for console behavior.

Configuration SRM:ConfigSurveyQuestions Stores the survey questions that are associated to a request when it reaches the “Complete” state. A survey can be set up by Request Type (Incident or Change), and by Company, including Global, which is applied to all companies. One to five survey questions can be configured.

Configuration Requester Console:SummaryDefinition

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

143


Runtime Requester Console:RequestConsole

Serves as the entry point for users and supports their primary interactions. It provides the user interface for submitting and viewing requests.

Runtime SRM:ServiceRequestWizard The Request Wizard provides a simplified interface for users to create and submit a request. This form is a display-only dialog box in which users provide required information to complete the request.

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

Runtime SRM:WorkInfo Contains information associated with the user request, which could be attachments or general text summaries. Users can view Work Info entries using buttons on the Requester Console.

144


Runtime SRM:Survey When a request reaches a “Complete” status, a survey is generated. Required information from the request is pushed into the SRM:Survey form to create a new survey. Filters on the Survey form get the questions from the SRM:ConfigSurveyQuestions form, based on input parameters from the SRM:Request form.

Survey data model diagram

1. New request submitted

2. Creates incident

3. Incident resolves

4. Completed request

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.

145

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

• Integrate to Change Management and Incident Management as the back-end applications.

• Provide a mechanism for establishing field mappings between the request entity and change request or incident, for request creation.

• Provide CAI as a bi-directional communication mechanism for back-end integrations.

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

Architectural overview The architecture contains the following modules:

• SRMS administration

• Summary definition

• Service request

• Associations

• Flows

• Application object templates

• Application object instances

• Additional questions and answers.

A simplified model has been implemented for ITSM 7.0. A request maps to a single back-end application request. A one-to-one relationship between the request and the back-end object will trigger the fulfillment process. However, the SRMS framework is architected to support a more comprehensive and flexible model, with the use of the flow, association, and question components. These components will be more fully leveraged in a future release of the Service Request Management solution.

Following is a top-level diagram that shows the dependency and integration points. Note that Change Management and Incident Management are integrated with the SRMS framework, but are dependent on the CAI, which is the mechanism that communicates with the SRMS framework.

One of the primary uses of the SRMS framework in ITSM 7.0 is to provide a means for bi-directional synchronization between the front-end request and its related back-end application request. The SRMS framework includes command and command parameter definitions stored in the CAI:Command and CAI:CommandParam forms as part of SRMS framework configuration data. These event commands are used to communicate to the back-end applications for request creation, updates, and synchronization activity. The type of information being synchronized includes status updates and work log activities.

146

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

147

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

148

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:H elp 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.

149

SRM:RequestSRM:WorkInfo

SRM:AppInstanceBridge

CTM:Region


SIT:Site Group

SIT:SiteCTM:People

COM:Company

CTM:Support Group

FK:SRInstanceID

SRM:Survey

CFG:Service Catalog


RQC:SummaryDefinition

PBM:Solution Database

FK:SolutionRequestID


ManagerAssignee

FK:TitleInstanceID

HPD:Help Desk


FK:SRInstanceID

FK:Originating_Request_InstanceID

FK:SRInstanceID

150

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.


CAI:EventParams

CAI:Events

FK:EventGUID

FK:AOIGUID

PBM:Solution DatabaseFK:SR_KnoweldgeDatabaseID

SRM:RequestFK:SRInstanceID

FK:AppRequestInstanceID

HPD:Help Desk


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.

151

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.

152

The following diagram shows the instantiation process:

Request instantiation diagram

CAI:Event

CAI:EventParams

Event Instance IDParam Name=<field id>Param Value=Type=<In, Out Qual>Data Type=<Character, Attach>

Event Instance IDEvent Type=CreateAppRequestAOI GUID=<AOI Instance ID>SRMS Server=<SRMS server name>App GUID=<Application ID>App Server=<Application server name>App Interface form = <App interface form name>Source=SRMSReturn code = emptyReturn msg = empty

CAI:AppRegistry

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

Application Instance (CHG:Infrastructure Change)

Field-value pair linked to event

4. FilterAPI invoked

6. Submit to application instance (if app interface != app instance form)


Service Request Instance IDAOI Instance IDApplication Registry Instance IDFlow information

3. Create event and event

param entries.

SRM:Request

Service Request Instance IDSCO Instance ID

1. Tells Start Flow to start work.

SRM:QuestionResponse (NOT USED in RQC)

Service Request Instance IDQuestion Instance IDQuestionAnswer

Question-responselinked to service request.

Field-value pairs come from question-response pair.

When SR status = New; status reason = AI Creation, Create the event and event params.SRM:Service

RequestQuestionAssociation (NOT USED in RQC)

AOI Instance IDQuestion Response Instance ID

SRM:AppInstanceBridgeService Request Instance IDPredecessor Instance IDSuccessor Instance ID (AOI)

SRM:AppInstanceFlow (NOT USED in RQC)

2. Create successor AOI

CAI Plugin

Application Interface (ChangeInterface_Create)

5. CreateEntry to application interface

App interface entry field values come from event params

7. Sets return code = <OK, Warning, Error>Return msg = warning or error msg

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

153

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 GUIDStatusCost

AOI

SR GUIDAOI GUIDApp RegistryAOI StatusApp Instance GUIDApp Instance IDApp Instance DescriptionApp Instance StatusApp Instance Cost

Event Parameter

Event GUIDEvent Parameter GUIDParameter NameParameter Value

App Instance

...SRMS ServerSR IDAOI GUID...

Event

Event GUIDEvent CommandEvent StatusProtocol (AR)SRMS ServerAOI GUIDReg App ServerReg App Interface (Form)App Instance GUIDReturn CodeReturn Message (Error) App Interface

…Template IDSRMS ServerSR IDAOI GUID...

2. Create outbound create entry

3. Create the event parameters using the fields setup from command

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

4. Call Filter API

Filter APIIn: Reg App Server, Event Form, Event Param Form,

Event GUIDRtn: Return Code, Return

Message

5. AR API Call

7. Return code, Return message

6. Create/update/query entry in app instance

8. Notify AOI that command is done

9. Update event status=Complete

154

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 group or role

Map to group Comments

Summary Definition Config

Summary Definition Config Computed

Provides create, view, and modify access to Requester Console:SummaryDefinition.

Note: General Access is needed for modify access.

N/A Summary Definition Base group for Summary Definition Config Computed.

Requester Console Config**

Requester Console Config This group is part of the Request Config Computed group.

Provides create, view, and modify access to:

• SRM:CFG Rules

• SRM:Application Settings

• SRM:ConfigSurveyOptions

• Requester Console:SummaryDefinitions

Menu access to the Administrator Console for the Requester Console. Note: General Access is needed for modify access.

155



Requester Console Master**

Requester Console Master

This group is part of the Request Master Computed group.

Provides access to:

• View the SRM:Request form for troubleshooting.

• CAI Event Dialog and retry events.

• Create and view the work log from the Service Request form.

• Request Configuration

General Access General Access** Provides access to all general users who require modify permission.

Unrestricted Access

Unrestricted Access** Bypasses row-level access for multi-tenancy. See Assignee group.

Submitter* N/A Provides:

• Row-level view access to SRM:Request records submitted by that user from the Requester Console.

• Create and view access to the work log from the Service Request form.

Assignee Group* N/A Provides row-level access based on the Company field. Applies to summary definitions and broadcast messages.

Public* N/A Provides access to the Requester Console and all the related display forms. Note: AR System Guest public users have access to global

summary definitions and broadcast messages.

156

SRMS framework application permissions



Request Config** Request Config Computed Provides create, view, and modify access to:

• SRM:CFG Rules

• SRM:Application Settings

• SRM:ConfigSurveyOptions

• Requester Console:SummaryDefinitions

Menu access to Application Administration Console for Requester Console. Note: General Access is needed for modify access.

N/A Request Config Base group for Request Config Computed. Also part of the Summary Definition Computed group.

Request Master**

Request Master Computed

Provides access to:

• View the SRM:Request form for troubleshooting.

• The CAI Event Dialog and retry events.

• Create and view the work log from the Service Request form.

• Request configuration.

N/A Request Master Base group for Request Master Computed. Also part of the Command Event Master Computed group.

General Access General Access Provides access to all general users who require modify permission.

Unrestricted Access

Unrestricted Access Bypasses row-level access for multi-tenancy. See Assignee Group.

Submitter* N/A Provides row-level access to SRM:Request records submitted by that user ($USER$).

Assignee Group* N/A Provides row-level access based on the Company field. Applies to SRM:Request records.

Public* N/A Provides general access. Access granted to this group is granted to all users.

*Public, Submitter and Assignee Group are implied AR System groups; no Group or Role entries are required.

**General Access and Unrestricted Access are foundation AR System groups. These groups are shipped with the Foundation application.

157

SRMS framework computed groups

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

Computed group Comments

Request Config Computed Computed group for Request Config

Equals Request Config or Requester Console Config

Request Master Computed Computed group for Request Master

Equals Request Master or Requester Console Master

Requester Console computed groups

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

Computed group Comments

Summary Definition Config Computed

Computed group for Summary Definition Config.

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

Task Management System The primary goal of the Task Management System (TMS) subsystem is to provide a mechanism to support repeatable processes. The result is improved productivity, reduction in novice errors, and a clear way to define business processes.

The Task Management System introduced in ITSM 7.0 significantly enhances the capability of the task operation of previous releases. In addition to the predecessor and successor relationship, TMS supports branching and multiple paths, along with data exchange between tasks. TMS also supports integration with external systems, primarily using the Command Automation Interface (CAI) subsystem.

The following sections present the architectural structure of TMS. See the BMC Remedy Task Management System 7.0 Administrator’s Guide for information about user features, configuration, and administration of the system.

158

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

Definition Definition consists of a Container object task group, associations, flows, and templates that establish the relationships and hierarchy between corresponding task templates.

Component Description

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

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

Task templates Task templates define the purpose of tasks.

Flow templates “Flows” determine the sequence and dependencies between the associated task templates.

Execution/Runtime Execution consists of the Container Object task group, associations, and flows that establish the relationships and hierarchy between corresponding tasks. The process to transform a task group template (the definition phase) to a task group (the execution phase) is called instantiation. Therefore, the corresponding entities for the templates defined during runtime are task groups, tasks, flows, and associations.

The Variable pool is a structure that facilitates information passing between tasks and flows.

The following diagram provides a high-level view that illustrates typical relationships among the TMS components previously defined.

159

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.

Container Object

Task Group Template

[0]

Application Object Template

Data Flows




Associations

Flows

Task Template

[B]

Task Template

[A]

Task Template

[C]

Task Template

[D]

Variable Pool

ContainerObject

Task GroupContainer

[0]

Application ObjectInstance



Task[B]


Task[A]

Task[C]

Task[D]

OR

AND

Feature Set • Related Items• Automated Tasks• Launch • Pass data between AOI’s• Reference Other Form • Shared Work

System2 Closed Tasks LocalTBD Contact

Phone LocalSunnyvaleLocationScopeValue Name



Container Object

Task Group Template

[0]


Data Flows




Associations

Flows

Task Template

[B]

Task Template

[A]

Task Template

[C]

Task Template

[D]

Variable Pool

ContainerObject

Task GroupContainer

[0]




Task[B]


Task[A]

Task[C]

Task[D]

OR

AND


Container Object Container Object

Task Group Template

[0]

Application Object Template Application Object Template

Data Flows




Associations

Flows

Task Template

[B]

Task Template

[A]

Task Template

[C]

Task Template

[D]

Variable Pool

ContainerObject

ContainerObject

Task GroupContainer

[0]




Task[B]


Task[A]


Task[A]

Task[C]

Task[D]

OR

AND






160

ExecutionDefinition

Task 1

Task 2a Task 2b

F1 F2

Task 3b

F4 F3

Task 3a

Task 4

F5 F6

TaskTemplate 1

Task Template 2a Task Template 2b

F1 F2

TaskTemplate 3b

F4 F3

Task Template 3a

Task Template 4

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

Task Group 1Task Group Template 1

All templates in this task group template are configured to be executed in the order of flow F1 to F6.

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.

161

Execution

Task 1

Task 2a Task 2b

F1 F2

Task 3b

F4 F3

Task 3a

Task 4

F5 F6

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

Task Group 1

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.

162

Execution

Task 1Closed/Success

Task 2aClosed/Success

Task 2bClosed/Failure

F1 F2

Task 3bBypaased

F4 F3

Task 3aClosed/Success

Task 4Closed/Success

F5 F6

Task Group 1

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.

163

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.

164

AT1

AT2

AT3 ASSOC1

ASSOC2

ASSOC3

165

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

166

Task 2

Task Group

Task 1

Task 3

Task 2

Task Group

Task 1

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.

167

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


168

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.

169

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

170

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.

172

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.

173

ERD Following is the entity relationship diagram for TMS.

174

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 Info

Update Related Individual Work Info UpdateTaskAndWorkInfo

Update Related Multiple Work Info UpdateTaskAndWorkinfo

Create Related Individual Work Info UpdateTaskAndWorkinfo

Query Related Multiple Work Info QueryTaskPlusWorkInfo

Task and Relationships

Query Related Multiple Relationships

QueryTaskPlusRelationships

Task, Relationships, and Work Info

Query Related Multiple Relationships and Work Info

QueryTaskPlusRelationshipsAndWorkInfo

175

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.

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

*65743**65743**65743**65743*

*65743*

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

bmc® remedy® it service management 7.0 archetecture

Documents