This document details the procedure
used to map a complex Business Application in TADDM. One thing that
will become clear as you read through this paper is that the role of
the Subject Matter Expert for the Business Application is critical and
cannot be eliminated. If no SME is available to tell you that the
Business Application uses a DB2 database, then the road to Mapping
the Business Application will be exceedingly long, if not impossible. Without the SME, you will have to rely on
“connection” information from known components of the App to find the unknown components.

The
Customer Portal Business Application

I am going to map the Customer Portal business
application. It is a real application from a real customer, however, I have made changes where necessary to protect the identity of the customer. The Business Application is composed of the following components:

F5 Load Balancers

Oracle 11g on Solaris

DB2 on Z mainframe

DB2 on AIX

WebSphere MQ

WebSphere Application Server 6.1

IBM WebSeal

IBM Tivoli Access Manager (TAM)

Tealeaf Customer Experience Software

Microsoft IIS

Microsoft SQL Server

Team Site

Live Site

Apache Web Server

Apache Tomcat

Discover
the Components

The first step in building a business
application is to ensure that all components are properly discovered
by TADDM. No work is required for those components that are supported
by TADDM out of the box, however, Custom Server Templates (and often
Extensions) and Computer System Templates will need to be created in
order to completely map the Application. Of the components listed
above, the majority are supported out of the box. The following
applications will require custom server templates (and possibly
extensions).

IBM WebSeal

CST Criteria: Program name contains webseald

IBM TAM

CST Criteria: Windows Service Name contains “Access
Manager”

Since Tivoli Access Manager is a WebSphere Application, if you have WebSphere discovery enabled and you have the access list populated with the username, password and certificates.

TeaLeaf

Team Site

Live Site

Open Deploy

Options

There are three methods that can be used to cause a component to become a part of a Business Application.

Manual - should be avoided as structural changes to the application will require effort to keep the business application up to date. Sometimes using a manual component is the only practical way to place a component in a business application.

Application Descriptors - formerly the solution of choice requiring small XML files to be deployed to the various target computer systems.

MQL Rules - statements similar to SQL which are executed against the TADDM server to select components to be added to the business application. You should strive to use MQL rules whenever possible.

The Business Application builder is not restricted to using only one of the methods above. Indeed, the best solution usually involves a combination of one or more techniques.Mapping the Business Application

As mentioned above, it is best to use MQL Rules to add components to Business Applications and we will use this method when possible.

Login to the TADDM Data management portal and go to the "Grouping Composer" located in the Discovery Drawer.

Click to create a New Group and name it "Customer Portal - Production"

Leave the type set to Business Application, then click "Next"

On the next screen, you have the option to create one or more MQL rules. Keep it Simple! Use a separate rule for each Component type that you want added - its even ok to use multiple rules for the same component type.

Adding
DB2 to the Business Application

The first step in writing a rule to add
a DB2Instance to the Business Application is to look at the
details panel for the DB2 that you know to be part of the App. A good
place to look is on the Modules tab for an AppServer or on the
Databases tab for a database. The following diagram illustrates the
technique. Below is the databases tab for a DB2 that I have in my
TADDM server.

If I was mapping my TADDM installation as a business application, I would be fairly sure that this database server was a part of it. Why? Because one of the database names contains the string "TADDM".

How do I compose my MQL?

The best way to validate that your MQL
is returning the objects that you want (and not returning the ones
you don't) is to test your MQL from the command line before you save
it to the rule.

For example, I knew from the general
tab that the type was “DB2 Instance”.

I could have a quick look in the model
documentation (available in the file CDMWebsite.zip in
$COLLATION_HOME/dist/sdk/doc/model on the installed TADDM server), or
I could just guess that the type of the object was DB2Instance. To
test to make sure I had the right object type, I used:

The screen fills with xml data
indicating that my command worked well. Next, we need to narrow our
search to find only the instances in which we are interested. To do
this it's helpful to look at the object displayed as XML:

The rule name can be anything you like,
but it's best to choose something descriptive. The Functional group
name is a simple string that is only used when comparing one Business
Application with another. For example, a single business application could have two Apache Servers - one which serves as the customer interface and one which is used by the Application Administrators to adjust the settings of the application. These two Apache servers would have different Functional Group Names.

Click next and you are taken to a
screen where you can add manual components to the business
application:

For now, we won't add any manual
components, so press Next, then press “Finish”. After a short period of time, you will
see the New Business Application appear in the UI. You can then View
the Topology Graph for this Business Application.

Further Restricting the Rule

You “may” notice something
irregular about the graph. It's possible that you will see DB2s in
there that don't belong to the Production Customer Portal. It's
likely that the UAT or Development Customer Portal DB2 would also be
named “TADDM721”. One of the best ways to solve this problem is
to further restrict the MQL rule by specifying that the hostname
match some criteria. This will only work reliably for customers who
have a strong hostname convention in place. At this particular company, hostnames will be of
the form: CIXYYYYZNNNN

Where the “Z” character is D, S, or
P for “Development”, “Staging”, or “Production”
respectively.

If MQL supported matching on regular
expressions, the additional syntax would be slight:

Unfortunately, MQL does not currently
support regular expression pattern matching (I've opened RFE 14280 to
have this implemented), so our MQL rule has the potential to miss
some DB2 Instances. According to the host naming standard, “YYYY =
Server Type - Alpha acronym for Server Type, i.e. IIS, SQL, etc.”.
Assuming that there is an Alpha acronym for DB2 and further assuming
that it is “DB2”, then our MQL becomes:

The procedure for adding Oracle 11g and
MS SQL to to the Business Application is nearly identical to the
procedure outlined above for DB2. The process is:

View the details panel for the component and find something
that uniquely identifies that component as belonging to the Business
Application (usually a database with a specific name)

Find out the type of the object by either looking at the
common data model documentation (CDMWebsite.zip) or by making a
logical guess based on the Object Type field shown on the General
tab of the details panel

Test the select statement from the command line (./api.sh)

Place the rule in the Grouping Composer

What
about Custom Servers?

As was mentioned earlier in this
document, TADDM does not discover IBM WebSeal out of the box. In
order to discover it, we created a Custom Server Template named “IBM
WebSeal” with criteria Program Name contains webseald. When we run
discovery, all WebSeal servers should be discovered correctly. How
do we pick the right webseal(s) to add to the Business Application?
We can base it on the content of the configuration file. Assuming the
webseald configuration is in the file
/opt/pdweb/etc/webseald-default.conf, the Custom Server Template
“Config File” tab would look like this:

Ideally, this file would be collected
and parsed with a custom server extension and the “junctions”
would be collected and created as modules. I have opened RFE 13343
requesting IBM to add support for discovery of WebSeal out of the
box.

The following MQL restricts the WebSeals that will be added to the business application based on the contents of the config file: