Metadata example

Objectives

• The company wants to notify a person in Accounting by sending email whenever a process owned by accounting fails.
• The company also wants to generate a Sterling Connect:Direct® process Statistics Summary report about accounting processes.

Requirements

• There are five servers that are being monitored (SERVER1, SERVER2, SERVER 3, SERVER 4, and SERVER5).
• SERVER1 and SERVER5 are Sterling Connect:Direct servers that do only accounting work. So, all processes run on these two servers are accounting processes.
• SERVER2 does accounting and work for other departments. Processes submitted by Jane or Mary on SERVER2 are accounting processes.
• SERVER3 does accounting and work for other departments. Processes whose name begins with ACCT are accounting processes.
• SERVER4 does accounting and work for other departments. Processes whose remote node is SERVER100 (a non-monitored node) are accounting processes.

There are two ways to handle these objectives: 1) using regular rules or 2) using metadata rules. In most cases, metadata rules are more efficient than regular rules.

Regular rules

To meet the requirements without using metadata rules, the company writes four regular rules to take action on accounting processes that fail. The four regular rules are:

• If Server Id matches “SERVER1|SERVER5” then take Accounting Email Action
• If Server Id matches “SERVER2” and Submitter matches “Jane|Mary” then take Accounting Email Action
• If Server Id matches “SERVER3” and Process Name wildcard “ACCT*” then take Accounting Email Action
• If Server Id matches “SERVER4” and Remote Node matches “SERVER100” then take Accounting Email Action

Because IBM® Sterling Control Center Monitor does not have complex "AND/OR" logic for reports, a single report cannot be generated. So, the company writes four separate reports to get the accounting reports, when they only wanted one. And, the company puts logic similar to the rules logic into the report selection criteria.

The four reports would be:

• SERVER1 and SERVER5 Accounting Report criterion:

  Server Id matches “SERVER1|SERVER5”

• SERVER2 Accounting Report criteria:

  Server Id matches “SERVER2” and Submitter matches “Jane|Mary”

• SERVER3 Accounting Report criteria:

  Server Id matches “SERVER3” and Process Name wildcard “ACCT*”

• SERVER4 Accounting Report criteria:

  Server Id matches “SERVER4” and Remote Node matches “SERVER100”

If some other criteria are introduced (for example, SERVER6 is now being monitored and does some accounting work), then a new rule and a new report has to be defined.

Metadata rules

To meet the requirements using metadata rules, the company writes four metadata rules, all using the Accounting Metadata Action. The Accounting Metadata Action sets USER_DATA_1 to “ACCT.” Therefore, every time a metadata rule matches, the event gets appended with the accounting tag “ACCT”. That accounting tag is then used to match the regular rule. The four metadata rules would be:

• If Server Id matches “SERVER1|SERVER5” then take Accounting Metadata Action
• If Server Id matches “SERVER2” and Submitter matches “Jane|Mary” then take Accounting Metadata Action
• If Server Id matches “SERVER3” and Process Name wildcard “ACCT*” then take Accounting Metadata Action
• If Server Id matches “SERVER4” and Remote Node matches “SERVER100” then take Accounting Metadata Action

The company writes one regular rule whose match criterion is USER_DATA_1 matches “ACCT” and whose action is to email a person in Accounting.

For the report, the company defines a single report whose match criterion is USER_DATA_1 matches “ACCT” and to get the consolidated report that you want.

If some other criteria are introduced (for example, SERVER6 is now being monitored and does some accounting work), then only a new Metadata Rule would have to be defined.

IBM Sterling Control Center Monitor allows you to name the metadata fields to something that is more meaningful using Metadata Type Mapping. In this example, USG could map USER_DATA_1 to “Department.”