Creating functional components

To create a functional component, you define each tier in your application with a set of rules that BMC Discovery can use to find the contents of those components and then ultimately find the entire application. These rules are known as Functional Component Definitions. BMC Discovery can infer from the Functional Component Definition the necessary details to create the model. In this manner, BMC Discovery enables you to model simple to sophisticated applications without the need to write The Pattern Language (TPL). There is no need to download and then upload a TPL file. BMC Discovery automatically activates the pattern and submits it into knowledge management.

Before you begin

The end purpose of the Functional Component Definitions is to generate TPL patterns from your definitions. Patterns always have a trigger; in Collaborative Application Mapping (CAM), the trigger is supplied by a Functional Component Definition. You can only trigger on a positive occurrence, so one of the Functional Components in your map must have a positive operator (for example, contains, is or starts with, but not does not contain or is greater than). If no positive operator is set, the following error message is displayed:
At least one top level Functional Component Definition must contain a simple, positive condition.

You cannot create conditions based on date or time attributes.

To add a Functional Component Definition

1. On the Application Mapping tab, click Add New Functional Component Definition for each tier in your application.
2. In the Add Functional Component Definition box, type a name and any notes that apply to the component and click Apply.
3. The page is refreshed to show the new functional component definition. Click the name to edit the functional component definition.
   The Functional Component Definition opens by default on the Settings tab.
4. Choose one of the following options from the Start with menu to define how to find the contents of the functional component:
   • Software Instance
   • Database Detail
   • Detail
   • Software Component
   • Application Instance
5. Choose one of the following options from the Type menu to define the functional component:
   • Required — the functional component must be present for the BAI to be created. If you delete this functional component, the BAI is deleted too.
   • Optional — the functional component may exist but is not required for the BAI to exist. The functional component is only created if the appropriate information is found.
   • Always Present — similar to Optional though the functional component is always created even if the associated content is not found. For example, you know there must be a database but have failed to discover it, possibly because you do not have rights or cannot scan the endpoint. This type of functional component exists so it is possible to build a complete functional model. It is not removed until the BAI is removed.
   • Working Step Only — enables you to navigate through the model without creating a functional component. You can think of this as a placeholder for named values to be used for modeling other functional components.

6. In the Query Builder section, build and refine the queries to better define how BMC Discovery can find the functional components.

   Note

   The error message "Same node in more than one functional component definition" is displayed if your query returns nodes that are already returned by another functional component query.

7. View the results in the Results section at the bottom of the page and go back and refine your queries as necessary.
   You can also define traversals, helping you browse around your data. For example, you could traverse from a set of hosts to the software running on all of those hosts.

   Recommendation

   Do not automatically choose the first entry in the query list. Sometimes you need to scroll down the list to get the best choice.

8. Click Refresh results.

   Refresh results

   It is important to refresh the results to ensure that BMC Discovery will pick up any changes in the datastore resulting from changing the contents of groups.

SI to SI traversals

The following relationships are among those available when specifying a traversal from Software Instance (SI) to SI:

• SIs observed to be communicating with this SI
• Server SIs that this SI is communicating with (Client to Server Comms)
• Client SIs that are communicating with this SI (Server to Client Comms)
• Peer SIs that are communicating with this SI (Peer to Peer Comms)

The last three are explicit, meaning they are built by BMC Discovery for later use. Examples of explicit relationships are those created by patterns that parse application configuration files to find communicating hosts.

The first relationship is a pseudo-traversal based on the communicating SIs function. While the pseudo-traversal might be useful where relationships corresponding to the explicit relationships do not exist, it should be used with caution due to its potential impact on performance. These relationships can be created from the output of commands such as netstat.

The first relationship is available only in the the Traverse to dialog, and not the Filter dialog. You cannot filter by the first relationship because it is not a key expression.

Undoing actions

Creating Functional Component Definitions involves making anything from simple, discrete type changes to much more complex traversals and conditions, and sometimes during the process you might lose track of what you have done. Other times, you might want to undo a step to change your orientation and start again. The Undo feature enables you to cancel the one or a series of recent actions, and it displays the result in a banner at the top of the Functional Component Definition page.

To undo an action, click the Undo last change link to the right of the Functional Component Definition page. You must perform an action on the page before the Undo last change link displays.

In the following example screen, the Type field has been changed to Required and the link has displayed on the page:

Hovering over the Undo link displays a tooltip that displays the action that will be undone. After the link is clicked, an information banner displays at the top of the page indicating the change.

The Undo action applies to a single state change or the link can be clicked multiple times to cycle back through multiple changes. The Undo sequence persists until you log off the system; therefore, you can navigate away from page as necessary.

The Undo action is very definitive, so that even if you made a single character change in a query, for example, a single Undo action would only retrieve that character (making it appear that nothing has actually changed). The action works for all functions on the Functional Component Definition page, including traversals and deletions.

Example

Functional components help BMC Discovery find your applications by breaking them down into more defined blocks of information. From there, you define those components into rules that BMC Discovery can use to find the components and the application that uses them. You also used named values to differentiate and identify each component.

Functional components can form hierarchical structures (for example, database, application server, and client tiers), but can also be used to form parallel blocks of data flows. The structure does not have to be tiered. They can contain software instances, business applications, and software components. For example, in the two-tier Friends application structure, the Web tier is a functional component, because it can help express redundancy to measure the impact on data. The database tier is also a functional component.

Mike, the application mapper, has completed the first round of information gathering and has collaborated with George, the application owner, on the prototype map using a PDF preview report. Mike's next step is to create functional components.

1. Create a functional component for each subgroup or tier (Web and DB) that you created in the prototype. Click Web.
   
   
   
   Next, you begin to define the rules that BMC Discovery will use to identify the applications.
2. Select the type of data to start with.
   
   
   
   
3. Select the type associated with the data.
   In this example,Required is selected for the Web tier because it represents a crucial Web application that must be present in the map.
   
   
   
   
4. Run queries with conditions to tailor the Results list to show only Software Components with the name Friends.
   
   
   
   

5. Click Refresh results.
   The two software components that include the name friends are displayed in the Results pane.

   Recommendation

   Remember that you can click the Undo last change link to revert back to an earlier action if you make a mistake at any point in the procedure.

6. Repeat steps 1 through 5 for the database component, while adhering to the following conditions for the database:
   • Remember that the database has a relationship, so start with Web (Software Component) and select Required for the Type field.
   • Traverse from Software Component to Software Instance through the Software Instance this Software Component is running on relationship.
   • Traverse from Software Instance to Database Detail through the Detail depended upon by this Software Instance relationship.

Where to go from here

The second step in the mapping stage is to divide the application into instances. In order for BMC Discovery to link components together into a single instance of the application, you must derive an identity that is the same in each functional component. Named values provide unique characteristics to differentiate each instance within the application.

An example of the use of named values is to determine the identity of your application (for example, Development and Production) and provide meaningful abbreviations for a Proof of Concept. You can manipulate the values to convert a process user name like slcPROD and slcDEV to become Prod and Dev.