ca uim probe...the unified management portal (ump) uses liferay to provide a user-customizable...

Copyright ©2014 CA. All rights reserved. June 10, 20154

Technology Partner Program

CA UIM Probe

Development Supplement v1.1

Date: 06/01/2014 Version: 1.0



Contents

Introduction _________________________________________________________________ 4

Background ____________________________________________________________________________________ 4

Overview ____________________________________________________________________ 5

Architectural Overview ___________________________________________________________________________ 5

The CA UIM Communication Bus ___________________________________________________________________ 7

Publish / Subscribe (PubSub) _____________________________________________________________________ 9

Request / Response ____________________________________________________________________________ 9

NMS Access Control Model _______________________________________________________________________ 9

NMS Data Sets ________________________________________________________________________________ 10

Alarms _____________________________________________________________________________________ 10

Metrics (QoS) ________________________________________________________________________________ 11

Elements (CIs)________________________________________________________________________________ 11

Product Evolution ______________________________________________________________________________ 12

Concepts and Terminology _______________________________________________________________________ 13

Integration Details ___________________________________________________________ 14

Building a Probe _______________________________________________________________________________ 15

Supported Programming Languages _______________________________________________________________ 15

SDK Documentation ____________________________________________________________________________ 15

Code Wizard __________________________________________________________________________________ 15

Probe Configuration ____________________________________________________________________________ 15

Packaging ____________________________________________________________________________________ 16

CA UIM Web Archive ___________________________________________________________________________ 16

Creating Dashboards ____________________________________________________________________________ 16



List Views ____________________________________________________________________________________ 16

Performance Reports ___________________________________________________________________________ 17

Dashboard Packaging ___________________________________________________________________________ 17

Creating Custom Reports ________________________________________________________________________ 17

Submitting Probes to the Technology Partner Program ________________________________________________ 17

Releasing Products to the Archive Site ______________________________________________________________ 18

Appendix A – Integration FAQ __________________________________________________ 22



Introduction This document describes the best-practices model for integration of non-CA-developed monitor and control applications

into the CA UIM environment. It is intended as a primer for parties wishing to integrate their products into CA UIM. It

includes introductory materials on the technical aspects of the integration, as well as an overview the process for

effectively working with the CA UIM Engineering organization to manage the life-cycle aspects of the integration.

Background

CA UIM is a widely deployed product designed to monitor a wide range of technology as part of a service

assurance environment. CA UIM has a wide range of customers in both the medium Enterprise space, and in

the xSP Service Provider space. The xSP space is dynamic, and extremely diverse, with nearly as many different

models of service delivery as there are service providers.

Several attributes of the product make it an excellent fit for these service provider environments:

- Flexibility – The CA UIM product has been designed to offer extensive customer customization

capabilities. SPs can tailor the system extensively to meet their particular business model.

- Extensibility – CA UIM has a vast library of plug-in capabilities for managing most aspects of an IT

environment. These “probes” are quite simple to develop, allowing CA UIM to stay current with

most evolving technologies. Probes are often built by end-customers to monitor specialized or

internally developed components such as proprietary applications.

- Ease of Deployment – CA UIM’s delivery model has been traditionally focused on customer self-

deployment. Only the largest and most complex customers typically require professional services

assistance. CA UIM continues to enhance this aspect of the process, and with current releases, the

monitoring for thousands of servers can be deployed in an eight hour day.

- Scalability – CA UIM runs 24/7 in large environments that require the monitoring of tens of

thousands of servers.

- Access Control – CA UIM provides a rich “soft-tenancy” model that allows a service-provider to

allocate the elements under management to various “tenants.” These tenants are typically the

service-provider’s customers, but can also be used to segregate data among different user groups

(e.g. divisions) within an enterprise. The unique soft-tenancy model allows shared management of

elements between the SP customer (infrastructure user) and the service-provider (infrastructure

provider), a capability that is overlooked in many multi-tenancy systems.



- Sales Model – The CA UIM sales model is designed to align CA UIM revenue recognition with the

Service Provider’s revenue recognition. This allows CA UIM’s revenues to grow as the SP’s business

expands, and removes the need for a significant up-front investment on the part of the SP.

Traditionally, CA UIM probes have been developed in-house, or by end-customers. There are a few third-party

developed probes, but those have been supported on a one-off basis. Now the Partners will be developing

probes in the CA UIM environment. This document is a first step for formalizing the process of performing

these integrations, and for including their results in the library of CA UIM capabilities.

The next chapter introduces the concepts and architecture of CA UIM in order to provide the background

needed to begin the planning process.

Overview

Architectural Overview

The figure below provides a simplified view of the CA UIM Solution.

At the core of the Monitor is the CA UIM communication bus. This is a distributed bus that inter-connects all of

the components and sites comprising the Monitor deployment. It is an inter-network bus, in that it allows the

interconnection of multiple networks that do not normally have inherent connectivity, such as Service

Provider and SP Customer networks. The bus is presented in additional detail in a later section.

The bus interconnects CA UIM agents (also known as robots), which provide an operational environment for

probes. Probes are the work-horse of the Monitor environment. They interface directly to the Infrastructure-

Under-Management (IUM) via any available mechanism or protocol. They also report (via their agent) to the

rest of the Monitor environment over the bus. The bus provides protocols for control and configuration of

agents and probes, as well as for the probes to provide their data to the rest of the system. Over 120 types of

probe are currently available for interfacing to a wide range of infrastructure elements.

Probes typically belong to one of two broad categories: local probes or remote probes.

Local probes run within an agent on a server that is being monitored. They monitor various aspects of the

server, such as CPU, memory, disk, logs, processes, applications, virtualization, etc. The CA UIM agent (aka

robot) is available on nearly all of the popular host hardware and OS platforms for running local probes on

those platforms.

Remote probes live within a Remote Monitoring Station, a server that is considered part of the Management

Infrastructure (MI), and communicate to elements within the IUM using any available remote protocols.

Examples of such remote protocols include: SNMP, WMI, ICMP, Web Services, JDBC, and proprietary



protocols. There are no restrictions on the protocols used by these probes. They may, in fact, communicate to

an external agent or other component to retrieve information about IUM elements of which it has knowledge.

This allows a probe to provide information about a domain with which it has no direct contact, or to roll

information up from other management / monitoring components.

Liferay Portal

Nimsoft Service Components

Nimsoft Communication Bus (BUS)


Nimsoft Agent (Robot)

RemoteProbe

Remote Probe

Remote Probe


LocalProbe

Local Probe

Local Probe

NMS Server(s)

Remote Monitoring Station(s)

Infrastructure Under Management

Infrastructure Elements (e.g.

Servers, Devices, Apps, etc.)

Managed Server

UI Server (WASP)

Unified Management Portal (UMP)

Standard Portlets and Workspaces

Custom Dashboards

Custom Reports

Custom Portlets

Figure 1 – CA UIM Architecture Overview

The CA UIM provides a number of server-side components that sit on the bus and perform

system-wide functions. These server-side components are technically probes since anything on

the bus uses the probe Software Development Kit (SDK) to communicate. However, the term

probe is used to specifically refer to those components that are used to interact with the IUM.

Some examples of service components include:



CA UIM Alarm Server (NAS) – Listens on the bus for alarm messages generated by probes,

manages the state of each alarm, records the history of alarm progression in database

tables, and re-emits alarm state changes on the bus, which can be picked up by other

components.

Metric Data Engine (Data Engine) – Listens on the bus for metric (aka QoS) messages, and

logs the values into the metrics database, where they can be retrieved by other

components.

Web Application Server Probe (WASP) – Provides methods that make all forms of data

(provided by service components or probes) available to the user interface (UMP), and

other applications. Also provides mechanisms that allow the UMP to control and configure

the system.

Additionally there are many other service components that are described elsewhere. A broad understanding

of these service components is not necessary for the purposes of this document.

The Unified Management Portal (UMP) uses Liferay to provide a user-customizable portal for viewing

information from CA UIM as well as other allied products (e.g. CA UIM Service Desk and Cloud User Experience

Monitor (CUEM)). It provides a set of generalized portlets that can be used to visualize information from any

probe (as lists, charts, dashboards, reports, etc.), as well as more specialized portlets that are used for

configuration, specialized visualization, and other purposes.

The generalized portlets can be configured to provide “out-of-the-box” viewing and reporting for particular

probes or technologies. These configurations can be packaged along with the product and so that the

customer sees immediate value without having to develop their own views.

For more sophisticated applications, developers can provide their own custom portlets or reports that provide

specialized viewing or configuration support.

The CA UIM Communication Bus

A slightly deeper understanding of the CA UIM bus is useful for the developer of an integrated solution in order

to understand the deployment model under which their product will be delivered.

The bus can be thought of as an inter-network mesh that is composed of a component called the CA UIM hub.

The hub is the embodiment of the bus. It forwards messages appropriately to ensure that there is connectivity

between all probes (including service components) as needed. Typically, there is one or more hub at each point

of presence (e.g. site) within the infrastructure. The bus transparently extends across all of the networks and

sites where hubs exist within the deployment. It is further considered to extend to touch all of the agents

connected to those hubs. Figure 2 illustrates the nature of the bus.



Note that some of the connections between hubs are implemented as tunnels. The bus has a built in tunnel

capability that is typically used wherever hub interconnections span a public network environment, or where

they interconnect two otherwise disjoint networks. These may be used for the partner to provide CA UIM

temporary access to the environment to validate the submitted probe.

Figure 2 illustrates tunnels used to connect the service provider network to each of its customer sites. Tunnels

provide both data privacy (strong encryption) as well as forwarding between separate address spaces. The

connections between hubs can be in any topology, any number of hops, and any connection can be direct or

via a tunnel.


Nimsoft Communication Bus (BUS)


RemoteProbe

Remote Probe

Remote Probe


Agent

Hub



Agent

Hub

Hub Hub


RemoteProbe

Remote Probe

Remote Probe


LocalProbe

Local Probe

Local Probe

Managed Server

Service Provider

Customer Sites

TunnelTunnel Tunnels

Figure 2 – CA UIM Communication Bus

Note also, that each hub has built-in agent capabilities, so that probes can run directly on a machine running a

hub without an explicit agent on that machine.

The bus supports two distinct communication models:

Publish / Subscribe (PubSub)



Request / Response (Peer-to-Peer)

Publish / Subscribe (PubSub)

In the PubSub model, a probe publishes messages based-on a subject, while other probes may subscribe to a

given subject. Any number of probes may subscribe to the same subject, and any number of probes can

produce messages on the same subject. For example, many probes may publish alarms, while several different

service components may subscribe to alarms for varying purposes. In this way, the probes can publish their

data without regard for who is receiving it, and an additional subscriber can be added at any time without

affecting the publishers. Furthermore, the PubSub methods provide fault-tolerant, guaranteed delivery of

messages. They are stored at each hop before being acknowledged and deleted at the previous hop. If the

network connection or a given hub is temporarily down, the data will be forwarded as soon as the connection

is re-established. Additionally, agents and hubs can also connect to multiple other hubs to allow

communication to continue, even while a component or connection is down.

Request / Response

The Request / Response model is used for Peer-to-peer communication between probes and / or service

components. This is similar to any remote procedure protocol between processes, except that the bus

provides transparent routing of the messages across disjoint networks to provide a seamless management

“backplane.”

Messages sent over the bus are formatted as a PDS (Portable Data Stream) which is a CA UIM proprietary

binary form that allows construction of arbitrarily complex request / response messages containing structured

data, similar in concept to XML, but more compact for efficient transmission.

The specific protocols that probes need to implement will be discussed in later chapters.

NMS Access Control Model

Access to elements (i.e. Configuration Items – CIs) is controlled by a field known as the Origin. Origins are, by

default, determined by the agent in which the probe that discovered the element is running. Each agent can

be configured to report elements on a particular origin. It is also possible to configure the origin within a hub,

and all agents under that hub will report the same origin. The alarm_enrichment and qos_processor probes

can update the origin of a message before it is processed to allow for greater flexibility.

When a user is defined for CA UIM, he is defined in the context of an account, which can be thought of as a

user-group. This is commonly used, for example, by creating an account for each customer of a service

provider.

An account is assigned one or more origins, which determine the set of elements that a user within that

account is allowed to see. The account is also assigned an Access Control List (ACL), which is a set of

permissions that determine the account user’s rules of interaction. It determines the types of activities (e.g.

configuration, administration) that the user can perform.



In summary, the origins determine the account’s scope, while the ACL controls the actions that the user can

take within that scope.

Element

Origin

Account

Origin List

Access Control List

(ACL)

User

• User only sees elements that are tagged with one of the origins in the account’s origin list.

• User can only take actions allowed by the ACL.

ElementOrigin

Probe

• Probe advertises elements that are tagged with the origin configured for its agent or hub.

Figure 3 – NMS Access Control Model

NMS Data Sets

There are three NMS data sets that need to be understood by the developer:

Alarms

Metrics (QoS)

Elements (CIs)

Alarms

Alarms indicate an abnormal condition within the IUM. Alarms are asserted by probes when they detect an anomalous

situation, most commonly associated with a threshold crossing. They are also de-asserted (i.e. cleared) by these same

messages (with different parameters). Alarm messages are published on the bus, and are processed by the CA UIM

Alarm Server (NAS). The NAS converts the alarm messages from the probes into discrete alarms and re-publishes them

with individual topics for: Alarm New, Alarm Change and Alarm Close. It also writes alarms to the alarm database where



they can be queried. The alarm database includes tables for retrieving active alarms, as well as alarm history (each

change in alarm state is indicated).

Metrics (QoS)

Two types of QoS messages are sent by the probe: a QoS Definition message is sent by the SDK the first time a given QoS

data is sent by a probe during its run, while the QoS Data message is sent each time a new value is emitted by the probe.

These are received and processed by the Metric Data Engine (aka Data Engine), which writes the values to the metrics

database from where they are queried by various user-interface components. The metrics database presents each

metric as a time-value series, related to a given Metric Definition. A Metric Definition is identified by a probe as a

tripartite combination of “Source”, “Target”, and “QoS Name”. It is critical that the probe set these names so as to

uniquely identify the metric and its context. The target is usually an identifier for the system or component about which

the metric is a measurement (e.g. <hostname>/<disk name> for a disk measurement). The source usually refers to the

probe or external agent from which the measurement was taken. In the case of a transactional measurement such as a

response time, the source may refer to the system that initiated the transaction. The QoS Name uniquely identifies the

metric within the source and destination context. For example, a QoS Name for a disk might include “Utilization”,

“IO_Count”, etc.).

Elements (CIs)

The mechanism for a probe to advertise discovered elements is in the midst of a transition. The current mechanism will

be supported for several releases before it is fully replaced by the new probe framework mechanisms.

It is required that a probe advertise its elements -- UMP portlets utilize this information, so the probe must provide this

information.

Two types of element can be exposed today:

Devices

Configuration Items (CIs)

Devices represent the probes view of an IP addressable element within its scope. These devices are identified by a single

IP address that must be used consistently within the probe to avoid duplicate devices being advertised. The Discovery

Server, one of the core service components, will attempt to resolve multiple devices from different probes into a single

computer system element by matching the IP address and origin of the device. At the user-interface level, only

computer systems are seen, the devices only represent one facet of the computer system, as seen by a particular probe.

Note that computer systems are used to represent network devices such as routers and switches, as well as general

purpose servers or desktops.

A probe implicitly advertises a computer system when it includes an optional device IP address in an alarm or metric

message. There are currently no explicit mechanisms for advertising devices. It is always a side effect of sending a metric

or alarm message. The benefit of advertising the device is that the generated metrics or alarms will be positively

correlated to the device, and by association, to a particular computer system.

CIs represent a specific aspect of a device to which metrics or alarms may be attached. Examples include disks,

processes, applications, subsystems, etc. They are identified by a CI type, and a CI name. As for devices, CIs are



advertised as a side-effect of a metric or alarm message. Including the optional parameters for the CI type and CI name,

the CI is advertised, and associated with that metric or alarm. In this way, the alarm or metric will be positively

correlated to the given CI as well as the device. The CI will also become correlated with the device.

The CI types will be supplied to partners as part of the Technology Partner Program registration process. Your Integration Architect should be consulted to determine the appropriate CI types to use, as well as for guidance in including CI information within metric and alarm messages.

Product Evolution

CA UIM is in the process of significant architectural changes as it is adapted to serve an expanding customer

base within its growth market focus. Specifically, the product is evolving to meet the following drivers:

Sales Scalability and Supportability – Easier deployment, faster time-to-value and reduced support

requirements.

Larger Customers – Enhanced scalability and customization capabilities.

Extended Integration Abilities – Increased integration with customer systems as well as other CA

products, and support of third-party extensions.

Deeper Functional Capabilities – Enhanced analytics, further data integration, etc.

This rapid evolution can be particularly challenging to those wishing to integrate with NMS for a number of

reasons:

Synchronization of version dependencies – A developer must choose which release to target based

on expected delivery plans of both NMS and the integration product

Choice of integration method – The interfaces at several layers of the system are in flux. The

developer must choose, in each case, the appropriate interfaces to use for the project while

balancing the benefits of using the new interfaces with the availability and maturity of the old ones.

Life-cycle cost tradeoffs – Developers will need to make trade-offs between building on currently

available interfaces, and then re-working as newer interfaces become available, or waiting for

toolkit solutions which will remain stable for a longer period of time.

These architectural changes are happening at every level of the CA UIM product:

Probe SDKs are evolving to a probe framework that reduces the difficulty of producing a probe,

while enhancing its capabilities. Explicit element and topology discovery services are being

developed for use by probes.

A common service layer is being developed to cover all aspects of the NMS product. This series of

REST / OData services will support all user interface and API needs. Existing APIs will be deprecated.

The user-interface mechanisms are transitioning from Adobe FLEX to HTML 5 / Javascript / ExtJs,

using the CaForms package.



For these reasons it is essential to consult with the CA UIM Integration Architect before beginning an

integration project in order to choose the best tools and techniques based on expected delivery timeframes

and the nature of the integration.

Concepts and Terminology

Agent -- The NMS agent or robot is the first line of management for the NMS probes. Each

computer running NMS probes requires a NMS agent to be installed on it. The agent starts and

stops the probes when required, collects, queues and forwards messages from the probes to the

NMS hub. The agent consists of two processes, the controller which starts and stops the probes

and the spooler which handles message forwarding.

Alarm – A type of event that indicates abnormal operation

Discovery – The act of automatically determining the structure or content of some aspect of the

Infrastructure-Under-Management (IUM).

Discovery Agent – A type of probe that periodically scans a section of the network using particular

protocols or techniques, in order to determine the existence or elements or relationships between

elements.

Element – A real or virtual object that can be related in various ways to other elements. Examples

include devices and systems, software processes, people, organizations, services, etc. See Entity

and Relationship.

Element Correlation – The process of resolving different perspectives of a network element into a

single element that merges the various perspectives.

Hub – The hub is a message concentrator and re-distributor. It's the collection point for all

messages coming from the various installed NMS robots. Other NMS components can also connect

to the hub to receive dedicated messages and perform specific activities.

Infrastructure-Under-Management (IUM) – The set of hardware, software, configurations, and

network components being monitored or managed (See Management Infrastructure). This is

typically a network of devices and computer systems along with all of the installed software.

Local Probe – See Probe.

Management Infrastructure – The set of network elements (software and possibly hardware),

typically provided by CA UIM, whose primary purpose is to provide management of other network

elements (i.e. the Infrastructure Under Management (IUM)). Technically, the Management

Infrastructure is considered part of the IUM, as it also requires monitoring and management.



Metric – A measurable unit of information regarding an infrastructure element or derived from

infrastructure elements. Probes collect metrics from infrastructure elements.

Monitor – A definition as to how a particular metric should be collected and processed by a probe.

A probe will not collect or process metric data unless a monitor is defined for that metric. A

monitor defines the interval on which metric values are collected, as well as thresholds to apply,

and alarms to generate when those thresholds are violated.

CA UIM Alarm Service (NAS) – The NAS receives “raw alarm” messages coming from the robot

spoolers, and performs pre-processing and post-processing of the alarms through its auto-operator

mechanism. In addition suppression of duplicate alarms is also provided.

Probe – A software component within the CA UIM architecture intended to collect a targeted set of

information (element existence, element relationships, attributes, events and metrics) from

particular types of network elements. Many types of probe exist for various technologies, and

various hardware or software products. Probes may also act as “effectors”, controlling or

configuring elements within the IUM. Two major categories of probe are defined: local probes

manage the system on which they are installed (the local system), while remote probes provide

management of remote systems using networked protocols to communicate to those remote

systems.

Relationship – A typed association between two elements. For example: IsConnectedTo, IsHostFor,

IsLocatedIn, etc. See Element and Entity.

Remote Probe – See Probe.

Robot – See Agent.

Integration DetailsIntegration into CA UIM, at the present time, may encompass the four following activities:

Probe(s) -- Build a probe that collects and publishes the information needed by the application.

Dashboards -- Configure and package specialized out-of-box dashboard(s) or view(s) that display

the collected data in a specialized format if required by the application.

Custom Reports – Configure and package any specialized reports needed for the application.

Custom Portlets – Develop and package any specialized portlets required for viewing or controlling

the application. Most integrations do not require these.

Each of these activities is described below.



Building a Probe

A probe is built programmatically using one of the supported programming languages. CA UIM provides a

probe Software Development Kit (SDK) that provides all of the libraries needed to build a probe.

Supported Programming Languages The probe SDK is available in the following programming languages:

Java

C

PERL

C# .NET

VB 6

VB Script

CA UIM Scripting Agent (LUA)

The documentation and supportability is not currently uniform across all of the programing languages. For integration

projects, we recommend that one of the following languages is used (in order of preference):

Java

PERL

C

C# .NET

SDK Documentation SDK Documentation can be obtained from CA UIM Support, or through the Integration Architect.

We recommend starting with the CA UIM Java Developer’s Guide. This document provides an overview of the mechanics

of writing a probe. Then there is a more detailed programming guide for each of the language bindings.

Code Wizard The CA UIM Web Archive includes a package called the Code Wizard. This is a Windows application that will

automatically produce probe programming stubs in any of the supported languages. We recommend that this be used

as a starting point for probe development and the generated code can be copied into the Integrated Development

Environment (IDE) of your choice.

Probe Configuration

Probes receive their configuration from a .cfg file that is located within the probe’s directory. The structure of

this configuration file is very flexible (XML like) and is documented within the probe SDK. The configuration file

for simple probes with a fairly flat configuration can be edited using the Raw Configure capability of the Admin

Console. More complex probe configurations require a customized editor. These editors run on a user’s local

system, and use an agent request / response (callback) method to retrieve the probes configuration file. Once

the configuration file is obtained, the user may edit the file at will. When he has made all of the needed



changes, the file is saved, copied back to the agent via another request / response command, which also

causes the restart of the probe. During restart, the probe reads and processes the new configuration file. If a

custom configuration editor is required for your probe, consult your Integration Architect for examples and for

the best method to proceed.

Packaging The NMS Infrastructure Manager program provides a facility whereby the probe executable can be bundled along with

other files (e.g. default configuration) and wrapped as a distributable package. Any number of files can be packaged

together. This allows multiple executables or entire collection systems to be deployed as part of the probe package.

These packages can be very easily downloaded from the CA UIM Web Archive by a customer, and distributed to all of

the agents where it is needed.

CA UIM Web Archive The CA UIM Web Archive is available, with login credentials, to all customers and partners. This site provides access to

every probe or service component supported by CA UIM including partner products. Customers know that if they are

looking for a component they should look on the CA UIM Web Archive. From there they can download any component.

The component is downloaded to the customer’s local archive, from there it can be deployed to agents individually or

policy-based or bulk methods. This site will evolve into a marketplace as more partner products become available.

Packages can be license-protected to enable revenue recognition for vendors or other CA organizations.

Creating Dashboards

Dashboards are out-of-box configured views that can be associated with a given probe or package. They can

be distributed to customers and can then be added to the user’s UMP workspaces. These views are built on

several flexible viewing mechanisms that are a standard part of UMP. These are the same mechanisms that

service provider or enterprise customers can use to build their own custom views. Two major mechanisms are

provided:

List Views Performance Reports

An overview of each of these is presented below. For more details see the UMP Users Guide, which can be

accessed from the UMP Help screens.

List Views List views are built using the standard UMP portlet, the List View Designer.

They are typically used as a starting point for viewing. A list view presents a table of information about elements within

the application’s scope. It may, for example, present a list of systems and some properties or metric values for those

systems. It is possible to set up list view to drill down to other list view, for instance, a list of components for a given

system, with properties or metric values for each component.

Items in the list can also drill down to a “Performance Report” (see below).



Performance Reports Performance reports are built using the UMP Portlet, the Performance Report Designer. They are used to present

various collected metrics for an element as a series of historical graphs.

Dashboard Packaging The mechanism for dashboard packaging is currently a manual process, you can export your list view and performance

reports and provide a text (.txt) file with the XML definition and CA UIM will help users load these definitions:

http://<UMP>/listdesigner/jsp/export_lists.jsp http://<UMP>/qoschart/jsp/export_reports.jsp

Note: Both these command will output all existing list views and performance reports, extract the only new ones

to the text file (.txt). Alternatively, a Liferay Archive (LAR) file can be created with all of the pages to be imported. The best way to achieve this is to create a dummy user that only has the pages that you want to export, and then go to manage/control panel/ pages/ private pages/export to create the LAR file. Include any list view/performance reports text files (.txt) or any Liferay Archive (LAR) files in the probe directory to be imported by the end user.

Creating Custom Reports

To develop more elaborate reports or analytics for the integration, use the CA UIM Unified reporter. This

flexible reporting package allows the development of reports based on the CA UIM data sets (described

earlier). These reports can then be packaged and made available to customers. The process for developing

these reports is detailed in the various Unified Reporter manuals. We recommend starting with the Unified

Reporter Quick Start Guide.

The methods for packaging custom reports are currently immature and will require interaction with the CA

UIM Engineering team to accomplish. Please work with your Integration Architect for details.

Submitting Probes to the Technology Partner Program Partners can register for the Technology Partner Program a CI Type range and Subsystem id range will be provided to

use for the probe development. The probe package with documentation can be submitted to the Validation process

where the probe will have to successfully complete a series of validation tests before being accepted.

A testing environment must be provided by the partner via an NMS tunnel or web access to give the validator access to

an environment to validate the probe.

Once the probe has been accepted the probe will be released to the CA UIM web archive and will then be available for

CA UIM customer download.



Releasing Products to the Archive Site

The CA UIM Archive site is used for the automatic distribution of probes into the customer environment. This

section describes the information needed to release to this site. Releases are normally handled by a couple of

engineers within CA UIM, including the CA UIM Source Code Administrator (SCA).

The following images are screen shots from the Archive Site showing the information that is visible to

customers. The first is a high-level listing of the available probes. The second and third combined show the

drill-down information provided for the individual probes, in this case the HA probe.



The following information must be provided to post to the Archive Site:

1) Information on the exact zip to be posted (email attachment, URL, path, etc.). This will be copied to the official

builds repo as part of the release process.

2) Any other ancillary information that needs to be included with the probe in the official builds repo. Traditionally

this has included a debug zip and release notes in html format.

3) Probe information to post on the Archive Site (see the screen shots above for examples):

a) Name (text): Exact name as it will appear on the archive page

b) Group: Partner Probes

c) Description (text): Title as it will appear in the description column of the archive page. Can be a

decent string of 100-200 chars or so, but the column truncates on the support page, so 30-40 chars

is best.

d) Product Description (text that can include html formatting): Detailed description of the probe

functionality that becomes the main content of the release notes. This section may also provide

additional information on installation, configuration and/or updates.



e) Keywords (comma separated string): List of keywords to facilitate searches.

f) Platforms (text): May be an exact listing of supported platforms or may be a reference to a document

such as the Probe Support Matrix.

g) Hardware (text): This section specifies hardware dependencies. Many probes say ‘none’.

h) Software (text). This section specifies software dependencies for the probe (e.g., required software

or SDKs). It may also specify a reference document.

4) Specific information for each individual version of the probe for the Archive Site:

a) Version (real number): Version in X.YZ format. “X” is used for major releases. “Y” is used for minor

releases. “Z” is used for patch releases or new builds. This will likely be revised to a more traditional

X.Y.Z in the future. See CA UIM release documentation for a more detailed description of release

types.

b) State (pick list values): Currently used options are: GA (product released for general availability) or

Beta (pre-release of code for customer validation). Note that other release states are available, but

not currently used: Control Release and Partner Developed.

c) Help File (pdf or URL): This is the customer help information that may be either a pdf posted to the

Archive Site or a URL to access a customer-accessible documentation site.

d) Change Log (text): A description of the specific changes for that release (text box, supports html

formatting)

5) List of people to inform when the probe has been posted. In CA UIM this is typically the developer, QA engineer,

development director, program management, and support liaison.

If the probe will be posted by a CA UIM engineer (as determined during the Definition phase of the project), the

following process should be followed:

a) The above information is provided to the engineer in advance for review and closure.

b) Official approval is provided for the release consistent with the management controls within the

development organization. This should follow the Release Checkpoint meeting and signoff.

c) The CA UIM Engineer will post the probe.

d) Notification will be sent out to the list provided in step 5 above.



Appendix A – Integration FAQ This section will be used to provide common questions received from Partners, and the answers as provided

by the Integration Architect:

How can I compile code using the code wizard?

You cannot compile using the code wizard; it is a tool to generate example code that you can copy to the compiler of your choice.

ca uim probe...the unified management portal (ump) uses liferay to provide a user-customizable...

Documents