ca uim probe...the unified management portal (ump) uses liferay to provide a user-customizable...
TRANSCRIPT
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
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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.
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
- 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
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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 Service Components
Nimsoft Agent (Robot)
RemoteProbe
Remote Probe
Remote Probe
Nimsoft Agent (Robot)
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:
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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.
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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 Service Components
Nimsoft Communication Bus (BUS)
Nimsoft Agent (Robot)
RemoteProbe
Remote Probe
Remote Probe
Nimsoft Service Components
Agent
Hub
Nimsoft Service Components
Nimsoft Service Components
Agent
Hub
Hub Hub
Nimsoft Agent (Robot)
RemoteProbe
Remote Probe
Remote Probe
Nimsoft Agent (Robot)
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)
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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.
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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.
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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.
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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.
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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).
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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.
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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.
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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.
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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.
Copyright ©2014 CA. All rights reserved. June 10, 20154
Technology Partner Program
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.