Using the MDR Launcher

This article contains the following topics:
casm1401
HID_Using the MDR Launcher
This article contains the following topics:
The MDR Launcher
One of the main purposes for implementing CMDB is to aggregate data from multiple data sources (known as MDRs). However, a CI must always include a reference back to its MDR origin.
CMDB provides facilities for importing and loading CIs and also for associating the CIs with their origins. To view a CI in the CMDB, use the MDR Launcher. When you use the MDR Launcher for this purpose, you can return seamlessly to the CI-originating system. See the following diagram.
BCMDB--r12.1--IG_MDR_1_Diagram
BCMDB--r12.1--IG_MDR_1_Diagram
Using the MDR Launcher, it is possible to implement a “closed loop” change management process such as the following one:
  1. Create a change record.
  2. Implement the change.
  3. Verify the change by checking the MDR source.
  4. To indicate that the change has been made, update the CMDB.
From a Problem Management process perspective, you can use the MDR Launcher in the following way:
  1. Detect a problem.
  2. Determine the severity and pervasiveness of the problem. To determine what dependent CIs are affected, use the CI relationship data.
  3. Determine possible causes of the problem by researching provider CIs.
  4. Perform an in-depth analysis if necessary using the detailed information available in the MDR. To take corrective action, use the MDR.
MDR Terminology
The following terms are used in CMDB-MDR integration:
A management data repository (MDR) represents software or data that contains source information about a CI. An MDR generally contains more unrefined CI information than the CMDB, which contains a managed subset of that data.
An
MDR class
(MDR_CLASS) is used to group MDRs that CMDB processes similarly. Three special MDR classes include:
COHESION
,
GLOBAL
, and
cmdbf
.
An
MDR name
(MDR_NAME) is the name that an MDR uses to reference itself. Verify that the mdr_name and mdr_class value combination must be unique within your enterprise.
A Federated asset ID (FEDERATED_ASSET_ID) is a unique MDR identifier for a CI.
The different CI families typically use different respective MDRs as data providers. However, a single CI can have multiple MDR data providers. For example:
CI Family
MDR_CLASS
Contact
human resources system
telephone directory
single sign-on authentication system
Document
document management system
Air Conditioning
document management system
contract management system
air conditioning control system
Mainframe
tape management system
DASD management system
performance management system
job scheduler
Storage
storage management system
asset management system
Location
asset management system
education calendar
office directory
Network
network management systems
problem management system
There can be multiple MDRs in each MDR class, and each MDR can contribute data to multiple CIs. A given CI can receive data from zero or more MDRs. A CI also can have data contributed to it independently. Consider the following example: One mainframe CI has data that Disk Management System 1 donated. Another mainframe CI has data that Disk Management System 2 and Job Scheduler 2 donated. CMDB manages the relationships among CIs and all their related MDRs.
MDR Mapping
Every MDR has a unique way of identifying the CIs that it manages. Those identifiers are seldom synchronized across MDRs. For example, when referencing a specific Contact CI, different MDRs can use different identifiers. A national identity number, telephone number, license number, or Employee ID can identify the same person. The process of associating these disparate identifiers with the same unique identifier (UUID) maintained in the MDB is named
mapping
. Mapping occurs automatically when data is imported using GRLoader when the CI contains the <mdr_name> <mdr_class> and <federated_asset_id> tags. Mapping can also be accomplished manually through the Administration functions in the user interface. A CI that has no mappings that are associated with it is named
unfederated
. Every CI is automatically mapped to global MDRs using the UUID as the federated_asset_id.
MDR Launching
When you view a CI with the CMDB user interface, click buttons to launch an MDR user interface directly. One button per MDR mapping exists for the focus CI. To verify that a change request has completed successfully, use this launching. To obtain more information about a CI than the CMDB has collected, use this launching.
CMDBf Viewer
CA SDM provides the CMDBf Viewer with the results of CI federation across MDRs. From a CI Detail page, click CMDBf Viewer to see CI attributes of federated CMDBs and MDRs in parallel. On the Federated View page, you can click Retrieve to update the information from any of the federated MDRs. For better readability, CMDB metadata files can reconcile MDR attribute names and CMDB attribute names.
This feature requires MDRs that support Query. You configure the MDR CMDBf Endpoints to display their results on Federated View.
Define an MDR to CMDB
Before you use the CMDBf Viewer, define the MDR to CMDB.
Follow these steps:
  1. On the Administration tab, navigate to CMDB, MDR Management, MDR List.
  2. Click Create New.
    The Create New MDR Definition page appears.
  3. Complete the following fields:
    • Tenant
      Identifies the tenant owner of this MDR (if multi-tenancy is installed).
    • Button Name
      Specifies the button label to appear on the CI Detail page. This name must be unique for each MDR. Required for “launch in context” and CMDBf Viewer.
    • MDR Name
      Specifies the string to match the XML data that is sent in the mdr_name field. While the MDR can use any string, the host name is used frequently. This name together with the mdr_class form a unique name for the MDR. Required for “launch in context” and CMDBf Viewer.
    • MDR Class
      Specifies the class that must match the data that is sent in the mdr_class field in the XML. While this name can be anything, it must together with the mdr_name field form a unique identifier for the MDR. Global MDRs are defined with an MDR Class of GLOBAL.
      • CA Configuration Automation MDRs must specify an MDR class of COHESION, which automatically sets the Path, Parameters and URL to be Launched fields to the required CA Configuration Automation launch-in-context values.
      • CA Asset Portfolio Management r11.3.4 MDRs must specify an MDR name of APM and MDR class of GLOBAL, which sets the Path, Parameters, and URL to be Launched fields to the required CA Asset Portfolio Management r11.3.4 launch-in-context values.
      • CA APM r12.5 MDRs must specify an MDR name of ITAM and MDR class of GLOBAL, which sets the Path, Parameters, and URL to be Launched fields to the required CA APM 12.5 launch-in-context values.
      • For CMDBf Viewer, MDR Class must be cmdbf.
    • Active
      Denotes this MDR definition as active or inactive. The Inactive MDR definitions are logically deleted, but they can be made active again by using the Search utility.
    • Owner
      Specifies the contact responsible for this MDR.
    • Description
      Specifies a description in free-form text.
    • Hostname
      Specifies the host name, DNS name, or IP address of the host, which contains the web server. The web server is the one that hosts the web page to be launched. Required for “launch in context”.
    • Port
      Specifies the TCP/IP port that is used by the MDR web server to serve up web pages. Port 80 is the default. Required for “launch in context”.
    • Path
      Specifies the portion of the URL that precedes the question mark (?) character. This information can be obtained from your MDR documentation.
      • For mdr_class of Cohesion, the value is set automatically to "CAisd/html/cmdb_cohesion.html" and cannot be changed.
      • For mdr_name of APM and mdr_class of GLOBAL, the value is set automatically to apm/frmObject.aspx and cannot be changed.
      • For mdr_name of ITAM and mdr_class of GLOBAL, the value is set automatically to ITAM/Pages/Asset.aspx and cannot be changed.
    • Parameters
      Specifies the portion of the URL that follows the question mark (?) character. This information can be obtained from the MDR documentation.
      • For mdr_class of Cohesion, the value is set automatically to "hostname={hostname}+port={port}+family={family}+name={name}+secret={password}+federated_asset_id={federated_asset_id}". The value cannot be changed.
      • For mdr_name of APM and mdr_class of GLOBAL, the value is set automatically to ObjectID={cmdb_asset_id}&obj=11&FUNCTION=1&WinID=OBFRASSET{cmdb_asset_id}&WinContainerID=. The value cannot be changed.
      • For mdr_name of ITAM and mdr_class of GLOBAL, the value is set automatically to ParentClass=Asset&assetid={cmdb_asset_id}&TicketID={itam_ticketid}. The value cannot be changed.
    • Userid
      Specifies the MDR user logon, if necessary. This value is substituted into the URL wherever {userid} is found. If blank, userid defaults to whomever is signed on.
      For CA Configuration Automation, "Shared Secret" is the secret that is used to access CA Configuration Automation, if necessary. This value is substituted into the URL wherever {password} is found. For more information about defining the MDR, see the
       CA Configuration Automation Implementation documentation
      .
    • Shared Secret
      Specifies information that is shared between CMDB and the MDR. This value is substituted into the URL wherever {password} is found. For CA Configuration Automation MDRs, the value must match the value of the “com.cendura.security.oneclickauth.secret”. For more information about creating a shared secret, see "Integrating with CA CMDB" in the 
      CA Configuration Automation Implementation documentation
      . Required for CMDBf Viewer.
    • CMDBf Namespace
      Specifies the federated_asset_id that is passed to the query as a local ID. For CMDB, the value is http://cmdb.ca.com/r1.
    • CMDBf Timeout
      (Optional) Specifies time limit for CMDBf endpoint query. Default is ten (10) seconds.
    • URL to be Launched
      Default value of http://{hostname}:{port}/{path}?{parameters}. For some MDRs, it can be overridden if necessary to accommodate MDR-specific requirements. Required for "launch in context". 
      For mdr_name of APM and mdr_class of GLOBAL, the value is http://{hostname}:{port}/{path}?{parameters}
      For mdr_name of ITAM and mdr_class of GLOBAL, the value is http://{hostname}:{port}/{path}?{parameters}
      For mdr_class of Cohesion the default value is http://
      cmdb_hostname
      :
      cmdb_port
      /{path}?{parameters} 
      where:
      cmdb_hostname
       is the host name, DNS name, or IP address of the CMDB web server. Defaults to the current hostname that is accessing the CMDB web server.
      cmdb_port
       is the TCP/IP port of the CMDB web server. Defaults to the current port number used to access the CMDB web server.
      If you have enabled SSL support for CA Configuration Automation, set the URL to: http://hostname:port/{path}?{parameters}+https=yes
      For information about enabling CA Configuration Automation HTTPS support, see the CA Configuration Automation online help topic Creating the HTTPS Certificate and Enabling HTTPS.
    • CMDBf Endpoint
      Specifies the Query Service endpoint for the MDR. Required for CMDBf Viewer and retrieving updated MDR data. If you use CA CMDB as an MDR provider, the value is http://cmdb_hostname:cmdb_port/axis/services/QueryPort.
  4. Click Save.
    The MDR is defined.
MDR URL Definitions
The URL to be launched has the default value of http://{hostname}:{port}/{path}?{parameters}. If necessary, you can modify this expression to accommodate any MDR-specific requirements. The URL is required for "launch in context".
For mdr_name of APM or ITAM and mdr_class of GLOBAL, the default value is:
http://{hostname}:{port}/{path}?{parameters}
For mdr_class of Cohesion, the default value is:
http://cmdb_hostname:cmdb_port/{path}?{parameters}
  • cmdb_hostname
    The cmdb_hostname variable specifies the hostname, dnsname, or IP address of the CMDB web server. The variable defaults to the current hostname currently accessing the CMDB web server.
  • cmdb_port
    The cmdb_port variable specifies the TCP/IP port of the CMDB web server. The variable defaults to the current port number that is used to access the CMDB web server.
Include http=yes when you set the URL if you have enabled SSL support for CA Configuration Automation. See the following example:
http://hostname:port/{path}?{parameters}+https=yes
For information about enabling CA Configuration Automation HTTPS support, see the CA Configuration Automation online help.
MDR Launch URL
The MDR launch URL has the following default value:
http://{hostname}:{port}/{path}?{parameters}
You can modify this expression to accommodate any MDR-specific requirements. The URL is required for "launch in context."
  • For mdr_name of APM or ITAM and mdr_class of GLOBAL, the default value is:
    http://{hostname}:{port}/{path}?{parameters}
  • For mdr_class of Cohesion, the default value is:
    http://cmdb_hostname:cmdb_port/{path}?{parameters}
    • cmdb_hostname
      The cmdb_hostname variable specifies the host name, DNS name, or IP address of the CMDB web server. The variable defaults to the host name currently accessing the CMDB web server.
    • cmdb_port
      The cmdb_port variable specifies the TCP/IP port of the CMDB web server. The variable defaults to the current port number that is used to access the CMDB web server.
    Set the URL to include https=yes in the query string, if you have enabled SSL support for CA Configuration Automation. See the following example:
    http://hostname:port/{path}?{parameters}+https=yes
    For information about enabling CA Configuration Automation HTTPS support, see the Cohesion online help.
Defining Launch Parameters for URL Substitution
When defining an MDR, the following parameters can be used to construct its URL for display. These parameters are substituted with their appropriate values at run time. These variables must be specified in the fields that were described previously.
hostname
is the MDR host name from the MDR definition.
alarm_id
is the IP address of the selected CI.
federated_asset_ID
is the unique identifier of the selected CI in the MDR.
cmdb_asset_id
is the asset ID for the CI.
port
is the MDR port number from the MDR definition.
userid
is the user ID from the MDR definition. If blank, userid defaults to whomever is currently signed on.
password
is the shared secret from the MDR definition.
mdr_name
is the mdr_name from the MDR definition.
mdr_class
is the mdr_class from the MDR definition.
class
is the class of the selected CI.
family
is the family of the selected CI.
path
is the path as described in the MDR definition.
name
is the name of the selected CI.
model
is the model of the selected CI.
manufacturer
is the manufacturer of the selected CI.
itam_ticketid
is the ticket id to log in to CA APM.
Example: Launching an MDR
A CMDB user is looking at a Server CI named server1. Server1 has a map to an internally developed application that is named Comet. Comet uniquely identifies server1 as server:server1.
Comet is defined as an MDR with the following properties:
  • Hostname: CometServer
  • Port: 80
  • Path: index.php
  • Parameters: item={federated_asset_id}
  • Launch_url: http://{hostname}:{port}/{path}?{parameters}
In CMDB, when the user clicks Comet on the Attributes tab of the server1 CI, a web browser opens the following URL:
http://CometServer:80/index.php?item=server:server1
Parameters for URL Substitution
When defining an MDR, you can use the following parameters to construct its URL for display. These parameters are substituted with their appropriate values at runtime. These variables must be specified in the MDR field definitions.
  • {hostname}
    Specifies the MDR host name from the MDR definition.
  • {alarm_id}
    Specifies the IP address of the selected CI.
  • {federated_asset_ID}
    Specifies the unique identifier of the selected CI in the MDR.
  • {cmdb_asset_id}
    Specifies the asset ID for the CI.
  • {port}
    Specifies the MDR port number from the MDR definition.
  • {userid}
    Specifies the user ID from the MDR definition. If blank, userid defaults to whomever is currently signed on.
  • {password}
    Specifies the shared secret from the MDR definition.
  • {mdr_name}
    Specifies the mdr_name from the MDR definition.
  • {mdr_class}
    Specifies the mdr_class from the MDR definition.
  • {class}
    Specifies the class of the selected CI.
  • {family}
    Specifies the family of the selected CI.
  • {path}
    Specifies the path as described in the MDR definition.
  • {name}
    Specifies the name of the selected CI.
  • {model}
    Specifies the model of the selected CI
  • {manufacturer}
    Specifies the manufacturer of the selected CI
Example: Use Parameters for URL Substitution
A CMDB user is looking at a Server CI named server1. The Server CI has a map to an internally developed application that is known as Comet. Comet uniquely identifies server1 as server:server1.
Comet is defined as an MDR with the following properties:
  • Hostname: CometServer
  • Port: 80
  • Path: index.php
  • Parameters: item={federated_asset_id}
  • Launch_url: http://{hostname}:{port}/{path}?{parameters}
In CMDB, when the user clicks Attributes, Comet in the server1 CI, a web browser opens the following URL:
http://CometServer:80/index.php?item=server:server1
Federation Using GRLoader
When using GRLoader, the following XML tags must be populated in every CI in the XML document. These tags apply to every MDR family.
  • <mdr_name>
  • <mdr_class>
  • <federated_asset_id>
 
CA Configuration Automation automatically provides mdr_name, mdr_class and federated_asset_id.
if the XML tags are missing, “launch in context” is not possible. This is because, the origin of the CI cannot be determined.
To identify the source of a CI, you can modify the XML before it is input into GRLoader. You can use a text editor to modify the XML and make a global change. You can also program this task.
For more information about MDR identification and GRLoader, see the GRLoader XML topic. 
Federate a CI
If CIs are loaded into CMDB before their corresponding MDR is defined, they are unfederated. Unfederated means that the CIs are not yet connected to an MDR and they do not yet support “launch in context”.
Follow these steps:
  1. Define the required MDR.
  2. Do one of the following tasks:
    • Manually map the CI.
    • Rerun the CA Configuration Automation report which created the CI, specifying Allow update of existing CIs on the report. For more information about CA Configuration Automation Reports, see the
      CA Configuration Automation Product documentation
      .
  3. Rerun GRLoader, specifying the same input file that was used to create the CIs.
    The CMDB reconciliation engine merges the MDR information into the existing CIs.
  4. Create an XML document that describes the CI and its MDR and run GRLoader in Update mode.
    The CMDB reconciliation engine merges the new information into the existing CI. The existing CI is federated.
Example: Specify CI Location
To locate the CI you want to update, verify that the reconciliation engine is provided with enough information. In the following example, end tags are removed and spaces added for readability.
<ci> <name> server3 <mac_address> <serial_number> <asset_num> <dns_name> <mdr_name> mdr_one <mdr_class> Cohesion </ci>
Define Multiple MDRs to a CI Using GRLoader
You can define multiple MDRs to a CI by using GRLoader.
To define multiple MDRs to a single CI, the XML document can repeat the <ci> node. With each duplicated <ci> mode, specify a different mdr_name and mdr_class. In other words, each MDR can contribute its attributes independently of any other MDR that contributes data to the CI.
Example: Define Multiple MDRs to a CI
If MDR1 and MDR2 both contribute data to the server2 CI, the XML document looks something like the following example. In the example, end tags are removed and spaces added for readability.
<ci> <name> server2 <mdr_name>  mdr1 <mdr_class> Cohesion <diskspace> 500 gb <disktype>  SCSI-3 </ci> <ci> <name> server2 <mdr_name> mdr2 <mdr_class>Service Assure <sla> </ci>
CMDB reconciles the two previous CIs to the same CI and associates each MDR to that single CI.
The CIs can be imported in one or two runs of GRloader.
Map Between MDR CIs and CMDB CIs
After you define a CI manually using the File, New Configuration Item... option, manually define the mapping between this CI and the CI in the federated MDR. Associate a CI with an MDR in the following ways:
  • Editing the CI.
  • Using the Federated CI Mapping node on the CMDB Administration tab.
Follow these steps:
  1. To create a mapping by editing the CI, complete the following steps:
    1. Display the CI Detail page of the CI that you want to associate with an MDR.
    2. Click Edit.
    3. Display the Attributes tab.
    4. Click Add MDR.
      The CI is associated with the MDR.
  2. To create a mapping using the Federated CI Mapping page, complete the following steps:
    1. Click the CMDB Administration tab.
    2. Open the Management Data Repository node.
    3. Select the Federated CI Mapping node.
      The Federated CI Mapping List appears.
    4. Click Create New.
      The Create New Federated CI Mapping For page appears.
    5. Associate the CI with the MDR by completing the Federated CI Mapping fields:
      • CI Name
        Specifies the name to use to identify the configuration item.
      • Federated Asset ID
        Specifies the string identifier that is used by the source MDR to identify this CI. The MDR software determines the identifier.
      • MDR Name
        Specifies the name that identifies the MDR (and its MDR button).
      • Active
        Denotes whether this mapping is active or not. Mappings cannot be deleted, only inactivated.
    6. Click Save.
      The mapping between this CI and the CI in the federated MDR is defined.
How To Configure MDRs for CMDBf Viewer
To use the CMDBf Viewer, set up your federated MDR providers to point to the CMDBf query service, as follows:
  • External MDRs must provide a query service that can handle InstanceIdConstraint query.
  • Button Name, MDR Name, and MDR Class are required to show the CMDBf Viewer button on the CI Detail page.
  • MDR Class must be defined as
    cmdbf
  • For CMDB, CMDBf Namespace must be set to
    http://cmdb.ca.com/r1
    . For other CMDBs and MDRs, see the appropriate documentation.
  • Timeout is optional. Default is ten (10) seconds.
  • To display a working Retrieve button on the Federated View, define CMDBf Endpoint, Userid, and Shared Secret.
An existing CMDB system can be set up as a CMDBf provider by specifying an CMDBf Endpoint of "http://servername:port/axis/services/QueryPort" where:
  • hostname is the computer where CMDB is installed (localhost or computer name).
  • port is the port where CMDB is configured.
Launching the MDR Web Browser Interface
After a mapping between a CI and an MDR is created, a button is placed automatically on the Attributes tab. If multiple MDRs are associated with this CI, multiple buttons appear.
When you click an MDR button, a new page opens. The fully substituted MDR URL that is defined in the MDR definition appears on the page.
Example: Launch CA Cohesion
When a CI has been correctly associated with its MDR, a Cohesion button appears on the Attributes tab. If a button does not appear on the Attributes tab, review the mapping for the displayed CI. Verify that there is a mapping for this CI. Also verify that the target MDR has a URL that can be launched. Clicking the button to launch the MDR causes a new window to open. The window opens to the target URL to launch CA Cohesion.
CA Cohesion Integration
Consider the following items when integrating CA Configuration Automation with CMDB:
  • Integrating Cohesion with CMDB
    For information about Cohesion-CMDB integration, see the
    CA Configuration Automation Implementation documentation
    .
  • Importing CIs from a Cohesion MDR
    For information about how to import CIs from a Cohesion MDR, see the help in the CA Configuration Automation Report Templates tab.
  • Launch-in-Context for Cohesion MDRs
    For launch-in-context integration to work best with CA Configuration Automation, we recommend that you define the Cohesion MDR
    before
    running the Cohesion CMDB Report. You can define Cohesion MDR in the CMDB Administration tab.
    CA Configuration Automation does not support a unique Federated asset ID for NIC or File System CIs. Therefore, Cohesion does not support MDR Launcher for NIC or File System CIs. As a result, a Cohesion-based NIC or a File System CI does not display an MDR launch button even when it was imported successfully.