3

Monitoring

In the previous chapter we learned about implementing High Availability for our Biztalk
2010 Environments.

In this chapter we learn all about Monitoring BizTalk 2010 and why it is a critical task
for BizTalk Server Administrators. We will learn about:
 The need for Monitoring.
 The use of System Operations Manager 2007 R2 (SCOM) to monitor our
BizTalk Environments.
 Step through a few scenarios using SCOM to monitor BizTalk.
 Using the Windows Server Event Application Logs.
 Advanced Tracking Techniques using the BAM Portal and the BizTalk
Administration Console Tracking.
 EDI and AS2 Monitoring

Monitoring BizTalk 2010?

Monitoring is intended to keep our BizTalk 2010 environment healthy and its
applications application accessible to other systems and services. The goal of monitoring
is to minimize downtime and guarantee a certain uptime (based upon SLA).
Monitoring can be reactive or pro-active. With a good set of monitoring tools, skilled
people can detect issue easily, and prevent that certain problems arise and/or errors not
being detected.

The BizTalk 2010 Administration console provides us with the means for reactive
monitoring, while SCOM can be used for proactive monitoring.
Monitoring and the Microsoft Operations
Framework (MOF)
Once a system has been delivered to production, the activities undertaken on the solution
as part of its IT service lifecycle fall into the Operate Phase defined in the Microsoft
Operations Framework.

From the four Service Management Functions (SMF) that encompass the Operate
phase, the Service Monitoring and Control one is key to the success of the other three,
as its outcomes will be basic to achieve the goals of the rest:
 For the Operations SMF: the observations made by monitoring our system
represents one of the main sources of information to know validate that our
Operations Guide covers all the areas required to keep our system in good
shape and minimize disruptions and downtime.
 For Customer Service SMF: we will be able to assess how close/far we are
from delivering the right levels of productivity to the business.

2
  For Problem Management SMF: basically, if we don´t know that there´s a
problem because we are not aware of it, how are we going to find its cause or
even fix it?

Even though the main phase where monitoring matters will be addressed is the Operate
one, we should keep in mind that before that before we can start monitoring anything,
during the Plan and Deliver phases we should have planned, designed and implemented
the procedures and tools that will support those monitoring activities. This chapter and
the one coming afterwards will help us to understand different options we can consider
for those.

Monitoring Categories
There are three categories for monitoring BizTalk Server.
 Availability
 Health
 Performance

Availability Monitoring
Availability monitoring tells us about the availability of system or application resource
that could prevent our BizTalk Applications from running optimally.

Health Monitoring
Health monitoring tells us whether our applications or resources are in bad health.

Performance Monitoring
Perfomance monitoring provides us with information on the efficiency of system
performance.

Troubleshooting

3
 Once we become aware of a problem we can troubleshoot it. Troubleshooting
will be discussed in depth in Chapter 5 – Problem determination, event sources
and files.

Using System Operations Manager 2007 R2 (SCOM)

for Monitoring BizTalk 2010
System Center Operations Manager (SCOM) is part of the Microsoft System
Enterprise Suite. It enables administrators to comprehensive monitoring information from
Windows operating system, some UNIX/Linux system and various devices. SCOM
provides easy-to-use monitoring capabilities to our entire data center infrastructure,
applications, and clients giving a comprehensive view of the health of an organizations’
IT environments.
The basic idea is to place a piece of software, an agent, on the computer to be monitored.
The agent watches several sources on that computer, including the Windows Event Log,
for specific events or alerts generated by the applications executing on the monitored
computer. Upon alert occurrence and detection, the agent forwards the alert to a central
SCOM server. This SCOM server application maintains a database that includes a history
of alerts. The SCOM server applies filtering rules to alerts as they arrive; a rule can
trigger some notification to a human, such as an e-mail or a pager message, generate a
network support ticket, or trigger some other workflow intended to correct the cause of
the alert in an appropriate manner.
SCOM uses the term management pack to refer to a set of filtering rules specific to some
monitored application.

Why using SCOM is important

SCOM provides us with key features such as:
 Provides us with end-to-end visibility into the health and status of our
BizTalk Environment.
 Makes Operations personnel productive.
 It simplifies our management of the BizTalk Environment
 Helps us to know when problems exist before your customers/clients notice
 Helps us to resolve small problems before they become large
 Eliminates the guess work associated with root cause identification and triage

4
Concept of SCOM Management Packs
SCOM provides us with two types of management pack, Sealed and Unsealed. The
difference is that Sealed cannot be modified and Unsealed can be modified. When we
import a management pack into SCOM, it is Sealed.
We cannot unseal a sealed management pack. We can however, import the management
pack and export it to an unsealed pack. But before we can use the unsealed pack, we must
first remove the sealed pack we imported. This allows us to customize the management
pack as needed.
Management Packs can also depend upon other management packs being installed.

SCOM Overview
Microsoft System Center Operations Manager 2007 R2 provides for the monitoring and
management of servers, applications, clients, operating systems, business services, and
network devices. SCOM uses a combination of built-in technology and third-party
monitoring tools. These monitors can provide us with the real-time status or state of a
component at a very granular level.
SCOM provides us with Comprehesive Event Management, Monitoring, Alerts, Built-in
Knowledge Base, Reporting and Trend Analysis Capibilities.

Primary Monitoring Objects

The Primary Monitoring Objects used by SCOM are:
 Rules – used to define what to monitor. We are able to define what data to
collect and how to process and respond to the data.
 Monitors – represent the status ot state of a single component of a system.
They are used to gather data from events, scripts, performance counters and
other sources.
 Alerts – raised by Rules or Monitors. They call attention to issues that are
occurring.

Rules
We use Rules to collect data, launch scripts, and execute timed tasks.
SCOM has three major Rules types:
 Alert-generating rules
 Collection rules
 Time commands
5
Alert-generating rules
To generate an alert for a condition that does not call a monitor, we can use an Alert-
generating rule. There are a number of different providers that are supported by alert-
generating rules. Some of these providers are:
 Windows NT Event log
 Log file
 Windows Management Instrumentation (WMI)
 Simple Network Management Protocol (SNMP) events

Collection rules
Provides for the collection of event or performance data. The most common is a
performance collection rule.

Timed Commands
Timed command rules are very simple and can launch a script or execute a command
based on a schedule. We can use SCOM to control the schedule and management of
scripts.
Monitors
Monitors are representative of a specific component on a managed machine. Monitors
update in real time. This capability makes them very powerful.

Monitors are not responsible for collecting performance data or launching scripts.

There are many different types of monitors available in SCOM. The prmary monitors are:
 Windows Events Monitor
 Windows Performance Counters Monitor
 Log File Monitor
 WMI Event and Performance Monitors

Windows Event Monitor

One of the most basic types of monitor is the Windows Events monitor. This monitor
detects Windows events and uses these events to update its status.
Windows Performance Counters Monitor
6
The Windows Performance Counters monitor collects data from a Windows operating
system or application performance counter and reacts to that data.
There are two key types of Windows Performance Counters monitors:
 Static Thresholds
 Self-Tuning Thresholds

Alerts
Alerts represent an overview of all active issues in the system. Alerts contain more
information than monitors contain.

This makes them very useful for troubleshooting.

Alerts are not always resolved when a monitors status or state returns to normal. We can
configure our alerts to remain active, which will provide us the visibility of issues and
help us to resolve the issue.
Generating Alerts
Monitors can also automatically resolve alerts when the status or state of the object
returns to normal.
SCOM provides us with a Notification Workflow feature. Notification Workflow
manages the generation and resolution of alerts. It includes the following capibilities:
 Creating and forwarding email messages and other external notifications.
 Alert aging.
 The ability to customize the messaging format at the user level.
 User-level formatting requires at least one notification channel to be
previously configured by an SCOM administrator, and it allows individual
users to configure their own recipient object and notification subscriptions.
 Multiple Simple Mail Transport Protocol (SMTP) server support for
redundancy.

SCOM CONSOLES OVERVIEW

The purpose, of these consoles, is to provide the following features:
• Viewing overall Health of an environment that we are monitoring
• Alert Management including the creation, suppression and resolving of alerts
generated

7
 • Performance Monitoring of endpoints
• the ability to install a Management Pack such as the BizTalk Management
Pack.
• Rule and Monitor Authoring
o In addition to the Microsoft and 3rd Party management packs that
are available, we also have the ability to write our own
Management packs which may include custom Rules and
Monitors.
o Rules are used to collect performance related data where
Monitors are actually determining the state of a particular
component.
o In the BizTalk world, we could think of a rule when we have a
message that has failed validation within a Pipeline event.
o There is no state to this event, it either passed validation or failed
validation and once the event has occurred it will not change.
o A monitor works differently, the component that the monitor is
watching may change state.

CONSOLE VIEW
The Console View, as shown below, is a “Thick client” the supports the full set of
functionality. This includes Monitoring, Authoring, Administration, and My Workspace.

8
Web Console
The Web Console, as shown below, is accessible through Internet Explorer and provides
a subset of functionality. It does not provide for Administration or Authoring.

9
Views
Views are Personalized Screens. They are used to display the devices that matter to you.
They provide the ability to save searches for future use.

Agents
The Agent is responsible for communications from our monitored systems SCOM.
Nothing can be monitored without an agent being deployed to our BizTalk environments.

There is a possibility for agentless monitoring. It does not have the same features,
but it is possible

Management Packs
SCOM is driven by Management Packs. A Management Pack defines how SCOM
Monitors.
A Management Pack consists of the following items:

10
  Object Discoveries - Necessary items to discover managed objects.
 Monitors - Used to determine health information and validate that that the
items are working as specified.
 Rules - Provides for collection of performance data and running scripts.
 Tasks - Method that performs an action based upon defined Rules.
 Views - Customized look at items that might be unique to a management
pack.
 Knowledge - Provides for recording of problems and solutions.
 Reports - Customized Reports to support the management pack.
 Run AS Profiles - Discovering objects, running scripts and gathering
information requires credentials that can access the appropriate resources.
 Overides - Allows for an operator to customize the management pack.

BizTalk Server 2010 Monitoring Management Pack

The BizTalk Server 2010 Monitoring Management Pack provides us with comprehensive
discovery and monitoring of BizTalk Server components and applications.
Features
The Management Pack provides us with the following features.
 Separate views for BizTalk Server Administrators and BizTalk Application
Administrators
 Optimized discovery of artifacts across multiple machines
 Optimized discovery of relationships between artifacts
 Visual representation of health status
 Diagnostic support

Installing the BizTalk 2010 Monitoring Pack

Installation of the Management Pack is fairy easy. To start off we need to download the
Magnagement Pack from http://www.microsoft.com/en-
us/download/details.aspx?id=14897
1. Install the BizTalk Server 2010 Monitoring Management Pack.msi
2. We then need to open the SCOM Operations Console.
3. Click on the Administration button and select Import Management Packs
as show in the figure below.
11
 4. We then add the three BizTalk Management Packs as show in the figure
below.

12
5. Our next step is run the Import Wizard. This start the Import process
6. Once the Import Process has completed, we Select the Monitoring Tab,
and we can see the Biztalk 2010 Mamagment Pack in the Monitoring
View as shown in the figure below.

13
Separate views for BizTalk Server Administrators and BizTalk
Application Administrators
We are provided with the ability to view information based upon our administrative role.

BizTalk Server Administrator Role

 Monitors the state and health of the various enterprise deployments the
machines hosting the SQL Server databases, machines hosting the SSO
service, host instance machines, IIS, network services, and so on.
 Monitors the overall health of the “physical deployment” of a BizTalk Server
setup.
 Monitors the overall health of a the “physical deployment” of the BizTalk
Application and it’s interfaces.

14
Optimized discovery of artifacts across multiple machines

With the BizTalk Server 2010 Management Pack, the monitoring agents
discover the artifacts from a single machine.

Optimized discovery of relationships between artifacts

With BizTalk Server 2010, the management pack optimizes the discovery of relationships
between different BizTalk Server artifacts by properly sequencing the discovery of the
artifacts before the discovery of relationships.
For example, to establish the relationship between a receive port and a receive location,
the management pack must first discover the receive port and receive location and then
discover the relationship between them.

Visual representation of health status

SCOM provides us with color schemes to visually represent the health status of all
BizTalk Server related artifacts.
For example, the deployment level artifacts such as host instances can either be in a
running or stopped state. This is represented by using colors green and red respectively.
Similarly, BizTalk application level artifacts can be categorized into three buckets:
green, yellow, and red.
 If all instances of an orchestration are running and it is in a perfect running
state, the health status is represented in green
 If less than 70% of the orchestration instances are faulted, the health status is
represented in yellow
 If more than 70% of the orchestration instances are faulted or if there are
critical errors, the health status is represented in red.
The following figure shows the State Changes that can generate an Alert.

15
The BizTalk Server 2010 Monitoring Management Pack changes the parameters that
are used for monitoring the health of a BizTalk Server deployment.
For example, the visual representation of a send port may change to yellow or red not
only if the send port is not properly configured but also if there are some suspended
instances of the artifact.

Diagnostic Support
In addition to exposing the artifacts with errors, the BizTalk Server 2010 Monitoring
Management Pack provides diagnostic support by including basic information about the
error.
For example, if a send port turns yellow from green, diagnostics is automatically run and
the user can troubleshoot the reason for this change in the State Change Events tab of the
Health Explorer.

BizTalk Objects the Management Pack Discovers

If we look at the Monitoring Tab View, we can see the the Application and Deployment
Views available as shown in the following figure.

16
Object Types Discovered
The BizTalk Server 2010 Monitoring Management Pack discovers the object types
described in the following tables.
Application View Object
Name Category
BizTalkGroup Logical entity
BizTalkHost Logical entity
BizTalkApplication Logical entity
ApplicationArtifact Logical entity
HostedApplicationArtifact Logical entity
ReceivePort Application artifact
ReceiveLocation Application artifact

17
Orchestration Application artifact
SendPort Application artifact
SendPortGroup Application artifact

Deployment View Objects

BizTalkGroupDeployment System.Service
BizTalkInstallation Windows.SoftwareInstallation
ServerRole Windows.ComputerRole
BiztalkRuntimeRole ServerRole
RulesEngineRole BizTalkServerRole
BAMRole Logical entity
BAMRuntime Logical entity
BAMAnalysis Logical entity
BAMAlerts Logical entity
BAMPortal Web site
BizTalkApplicationService Windows.ApplicationComponent
BizTalkHostDeployment Logical entity

State Monitoring Definitions

State monitoring tells us whether a monitored computer is healthy at a given time from
the perspective of a particular application.

SCOM updates the status of different managed entities exposed to the user and
presents the status as part of the state monitoring view.

To understand the BizTalk Server 2010 State Monitoring view, you must understand the
concepts behind SCOM state monitoring. The following terminology is used to describe
the key components of state monitoring.
Role

18
A role that a server is performing in an environment as determined by service discovery.
For example, the BizTalk run-time role encapsulates the runtime artifacts and instances in
BizTalk Server.
Component
A sub-role that is used as part of the health roll-up to measure the overall health of the
server role. For example, the BAM alert component is used to generate alerts to indicate
the status of overall health.
Instance
A particular computer may host instance(s) of the server role.
The important principles of BizTalk state monitoring are as follows:
 Health of a computer group is derived from the health of the computers that
are contained in the computer group.
 The status of the computer shows whether applications (referred as server
roles) running on the computer are healthy, and the health is derived from the
health of the hosted applications.
 At the application level (server role), the status of the server role is the
overall status of all application instances of that server role.
o For example, health of one or more artifacts like orchestrations,
receives locations, receives ports and so on affects the status and
overall health of a BizTalk application.
 At the application instance level (server role instance), the health of the
application instance is derived from the health of different areas of the
application instance (known as components).
 SCOM alerts are associated with the health of a component. Status of a
component is set to red, yellow, or green when alerts are triggered to indicate
overall health.
 Health of a component contributes to the health of the server role.

In BizTalk Server 2010:

Each BizTalk Server is considered an instance of the BizTalk Server role.
The BizTalk Server role in a computer will therefore be computed as a result of
all events/activities of all the BizTalk Server processes in that computer

19
The BizTalk Server 2010 Monitoring Management Pack provides state monitoring
of artifacts which includes:
• Orchestrations.
• Receive ports, receive locations, and send ports.
• Servers, host instances, SSO and so on
The following table lists the three states that visually represent the health status of all
BizTalk Server platform and application level artifacts. This provides the SCOM operator
a high-level view of a multi-server deployment in order to focus on important problems
quickly.
Artifacts Green Yellow Red

Application level Are in a running Less than 70% of More than 70% of
artifacts state. the instances are the instances are
faulted. faulted or have
resulted in critical
errors.

Deployment level Are in a running Not applicable Are not in a running

artifacts state. state or have
stopped.

MONITORING
Monitoring provides for Active Alerts, Discoverable Inventory and Synthetic
Transactions. An example of the Alerts View is shown below.

20
Viewing Information in the Operations Manager Console
We can use the views provided with the BizTalk Server 2010 Monitoring Management
Pack to understand the current availability, configuration, health, and performance of our
BizTalk Server environment.
If we look at the BizTalk Server 2010 node in the Monitoring pane of the Operations
Console , we will see the following views.

Application Views:

21
BizTalk Applications administrators are responsible for monitoring the state and health
of various BizTalk Server artifacts and applications such as orchestrations send ports,
receive locations, etc.
Deployment Views:
BizTalk Server administrators are responsible for monitoring the state and health of the
various enterprise deployments, the machines hosting the SQL Server databases,
machines hosting the SSO service, host instance machines, IIS, network services, etc..
APPLICATION VIEWS
We have three key Application Views.
 Application State View
 Groups State View
 Hosts State View.

Application State View

This view displays the health of a BizTalk application.
 The health of BizTalk application depends on the health of its constituent
artifacts such as Orchestrations, Send Port Group, Send Port, Receive Port,
and Receive Location.
 The Details View pane provides the properties of the hosted BizTalk
application.

The following figure show the Application State View

22
Groups State View
This view displays the health of a BizTalk group.
 The health of a BizTalk group depends on the health of BizTalk host and
BizTalk applications.
 The Details View pane provides the properties of the BizTalk group.

The following figure show the Groups State View

23
Hosts State View
This view displays the health of a BizTalk host.
 The health of a BizTalk host depends on the health of the instances of the
hosted BizTalk applications.
 The Details View pane provides the properties of the BizTalk host.
The following figure show the Hosts State View

24
Application Artifacts Views
Application artifacts views contains the following elements
 Orchestrations State -- Displays the configuration and runtime state of
Orchestration for the hosted application. The following figure shows this
view.

25
  Receive Location State -- Displays the configuration and runtime state of
Receive Location for the hosted application.
 Receive Ports State -- Displays the configuration and runtime state of
Receive Ports for the hosted application. The following figure shows this
view.

26
 Send Port Groups State -- Displays the configuration and runtime state of
Send Port Group for the hosted application. The following figure shows this
view.
 Send Ports State -- Displays the configuration and runtime state of Send
Ports for the hosted application. The following figure shows this view.

27
DEPLOYMENT VIEWS
The Deployment Views are described as follows.
Deployment State View
This view displays the health of a BizTalk deployment group.
 The health of the BizTalk deployment group depends on the health of its
constituent runtime server components such as BAM Role, Rule Engine
Role, BizTalk Run-time Role and BizTalk Host.
 The Details View pane provides the properties of the BizTalk deployment
group.
The following figure shows this view.

28
Hosts State View
This view displays the health of a BizTalk host.
 The health of a BizTalk host depends on the health of the instances of the
hosted BizTalk applications.
 The Details View pane provides the properties of the BizTalk host.

Rule Engine Role State View

This view displays the health of a Rule Engine service that is running on the runtime
servers.
 The Details View pane provides the properties of the runtime servers that
have Rule Engine service installed.

Runtime Role State View

29
This view displays the health of the runtime servers that have runtime rule engine service
installed.
 The health of a BizTalk Run-time Role depends on the health of its
components such as SSO Service, management database, message box
database, SSO database and tracking database.
 The Details View pane provides the properties of the runtime servers.
BAM Component Views
BAM Component Views are described as follows.
 BAM Alerts State -- Displays the state view of BizTalk BAM alerts
component.
 BAM Analysis State -- Displays the state view of BizTalk BAM analysis
component.
 BAM Performance State-- The Legend pane displays the performance
counter for BAM.
 BAM Portal State -- Displays the state view of BAM portal.
 BAM Run-time State -- Displays the state view of BAM run-time
BAM Alerts View
This view displays a list of BizTalk BAM alerts, which is a notification service and is
generated when any of the critical services are unavailable.
Runtime Component Views
Runtime Component Views are described as follows:
 Application Service State -- Displays the health of all host instances in a
BizTalk group.
 Message Box Performance State -- The Legend pane displays the
performance counter for Message Box Tracking Data Size.
The following figure shows the Message Box Performance State View.

30
  Messaging Adapters Performance State -- The Legend pane displays the
performance counter for MSMQ Receive Adapter Bytes Received.
Runtime Alerts Views
The Runtime Alerts Views are described as follows.
 Core Alerts -- Displays BizTalk core alerts
The following figure show this view.

31
  Messaging Alerts -- Displays BizTalk messaging alerts
The following figure show this view.

32
KEY MONITORING SCENARIOS
Some key monitoring scenarios are:

Suspended Message Alerts

Monitoring and resolving issues related to suspended messages are common operational
tasks in a BizTalk Server environment.
Two types of message suspension can occur in BizTalk Server 2010 when we process
messages.
 Inbound Message Suspension
 Outbound Message Suspension

33
Inbound Message Suspension
For inbound messages, various kinds of processing failures or lack of subscriptions could
cause a message to be suspended. Some transports can be configured to suspend the
message or not suspend the message.
For inbound messages, alert rules for suspension are written per adapter.
 Allows us more flexibility in handling message suspensions on the inbound
side.
 We can add different response actions based on the adapter. An example
would be a notification.
 We can additionally customize the BizTalk Server 2010 Management Pack
by creating our own custom rules.

Outbound Message Suspension

All messages are always suspended on transmission time failure of any type.

Alert Suppression Policy

Rules for suspended messages have a different suppression policy than those that are
generally applied for other rules.
Alerts are suppressed based the Alert Name, Alert Source, and Computer and Domain.
For suppression based on Alert Source, the alert source for each suspended message
rule also contains a parameter extracted from the suspended message event.
 This parameter is the URI on which the message was received or transmitted.
Errors that occur on the same URI are usually because of the same reason.
o It is recommended that we create a single alert for the same root
cause even though multiple associated failure events exist.
o This enables us to have one alert and one root cause that makes it
easier for you to correct problems when they occur.
o Streamlined alerts, based on URIs, reduce unnecessary alerts and
facilitate efficient tracking of open issues.
o A new alert is created for a message suspension at a URI with no
previous suspension alerts.

BAM Technical Assistance Alerts

Business Activity Monitoring (BAM) Portal users, sometimes known as Business
Analysts, usually understand the business level indicators and business activities. They

34
can use BAM Portal for monitoring aggregate indicators, a complete in-process business
transactions, or search for transactions with particular properties for further investigation.
Many business users often do not understand the aspects of an issue at an IT
infrastructure level. During investigation of a given transaction, the BAM Portal allows
business users to request technical assistance from the IT Operations staff to investigate
the transactions at the IT infrastructure level.
The BAM Portal provides for this through a Technical Assistance request.
When requesting technical assistance, an entry is created in the Application log in Event
Viewer of the computer where the BAM Portal is hosted. This event provides details
about the activity on which technical assistance is requested by the user. It contains other
important information, such as the Message Instance Identifier, Service Instance
Identifier, and BizTalk Server group information.
The BizTalk Server Management Pack provides a rule to trigger an alert on detection
of a BAM Technical Assistance event. The rule that creates this alert is “Error: BAM
Technical Assistance Required.” Each request submitted from the BAM Portal creates a
new alert.

BizTalk Message Boxes and Hosts

Generic rules monitor all the BizTalk Server Hosts or MessageBox databases based on a
common threshold.
 For example, the rule “Monitor HostQ Size,” monitors the work queues of all
BizTalk Server Hosts based on a common threshold.
 If three hosts exist, all their work queues are monitored by the same rule and
alerts occur when any of the host work queues cross the common threshold.
 BizTalk Server host-specific rules enable us to configure different thresholds
for different hosts and MessageBox databases.
o For example, the rule "Monitor HostQ Size –
BizTalkServerApplication" is a host-specific rule that monitors
the work queue of the BizTalkServerApplication host. We do
this by defining a specific Operations Manager provider for the
particular performance counter instance and using that provider
in the threshold rule.
 Host\MessageBox-specific rules are provided as template rules to be used as
a guide for creating rules that are applicable in your environment.
 Generic rules need to be configured with threshold values specific to our
environment.
 BizTalk Host/MessageBox-specific rules need to be created based on the
template rules and appropriate thresholds
35
  BizTalk Server incorporates self-throttling, which helps to prevent
overloading based on various parameters.
 A temporary overload that causes throttling to occur is not an operationally
significant event. Persistent throttling, however, is not expected in a stable
environment and could indicate underlying problems at the infrastructure
level.

The BizTalk Server 2010 Management Pack provides proactive monitoring of

such persistent throttling conditions with performance threshold monitors based
on the following conditions:
BizTalk Server service process memory
Number of messages being processed
Number of threads in a BizTalk Server process
Size of the BizTalk database queues

Orchestration Failures
BizTalk Server introduced the concept of an application for grouping solution artifacts.
Application monitoring detects effects of a failure at the application level.
ALERTSThe following are examples of various Alerts.

Receive Pipeline Failure – Invalid Data Received

Alert: ERROR: There was a failure executing a Receive Pipeline
Source: Microsoft.BizTalk.2010.BizTalkServer.ServerRole
Path: Server
Last modified by: System
Last modified time: 14/08/2010 5:00:23 AM
Alert description: There was a failure executing the receive
pipeline: “Organization.Project.Pipelines.WOMPostInstallRecieve,
Organization.Project.Pipelines, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=c93ca0362b603989" Source: "Flat file disassembler"
Receive Port: "WOM Receive PostInstalls FailedFind" URI:
"SFTP://user@sftp.businesspartner.com:22/F:/Outbound/AMI_ORG_PostInst
all_FailedFinds_2*.csv" Reason: No Disassemble stage components can
recognize the data

Receive Failure – Subscriber Not Found

Alert: ERROR: FTP-Receive-Message-Suspend
Source: Microsoft.BizTalk.2010.BizTalkServer.ServerRole
Path: Server
Last modified by: System
36
 Last modified time: 13/08/2010 12:45:44 PM
Alert description: A message received by adapter "nsoftware.FTP v3"
on receive location “ORG_ReceiveHeartBeatIn_FTP_SERVER_FOLDER" with
URI
"FTP://user@server21/server/folder/outbound/work/YYY_BTS_OR81STD*.xml
" is suspended.

Error details: The published message could not be routed because no

subscribers were found. This error occurs if the subscribing
orchestration or send port has not been enlisted, or if some of the
message properties necessary for subscription evaluation have not
been promoted. Please use the Biztalk Administration console to
troubleshoot this failure.

MessageId: {CADF3FBF-FFAA-4EE1-8315-45A35DCA6264}

InstanceID: {E3929CC9-6F4E-46A6-A3C6-7BA7E7ED8840}

Send Port Failure – Duplicate File

Alert: WARNING: An adapter raised an error during message processing
Source: Microsoft.BizTalk.2010.BizTalkServer.ServerRole
Path: Server
Last modified by: System
Last modified time: 13/08/2010 3:30:04 PM
Alert description: The adapter "nsoftware.FTP v3" raised an error
message. Details "Transmission failed for message "d6d2c088-98c0-
4327-a4f3-1553af2e36d9": Error uploading FTP data: Remote file
"TEST.txt" exists and overwrite is set to "False".".

Host Instance Failure

Alert: BizTalk Server: Availability Monitor raised an Error on Host
Instance
Source: EnterpriseClusteredSQLReceive..
Path: Server
Last modified by: System
Last modified time: 13/08/2010 3:26:24 PM
Alert description: Host Instance - EnterpriseClusteredSQLReceive :
report an error: The Host Instance is not running

Throttling
From: Operations Manager
Sent: May 21, 2010 12:40 AM
To: Middleware Team
Subject: “Server” one of the BizTalk server processes in the
affected computer is being throttled for significant periods because
of high database size exceeding the threshold.
Alert: one of the BizTalk server processes in the affected
computer is being throttled for significant periods because of high
database size exceeding the threshold.
Source: HostInstance
Path: Server
37
 Last modified by: System
Last modified time: 21/05/2010 12:40:11 AM
Alert description: 0.633333333333333

Custom Alert
Alert: Production WorkOrderManagement System Error Detection Rule
Source: Organization.WorkOrderManagement
Path: Serverl
Last modified by: System
Last modified time: 13/08/2010 1:51:10 PM
Alert description: Description: CreateEvent Response Status was
False.

Order Number: 000087803314

IDoc Number: 126634934
Orchestration Name: ProcessOrderCreateRequestFromERP
Activity ID: {80EB87CB-88E3-4E43-A9F5-C4A97AF2955B}
Message Instance ID: 387970ef-7367-4ed0-a83f-e58d2be9adaa

Message:
<CreateEventX>
<msgid>126634934</msgid><status>F</status><errmsg>Error:Failure in
I/Call for this request. Could not execute insert for:
</errmsg><![CDATA[<input><CreateEvent msgid="126000000" area="01"
fieldvalues=“…..”CreateEventX>

AUTHORING
SCOM Administrators have the ability to create custom Rules and Monitors
In addition to creating Rules and Monitors, SCOM Administrators can override existing
Rules and Monitors.

When creating overrides, a Custom Management pack should be created in order

to store the override. Otherwise an update to the original Management Pack may
overwrite our custom override.

If a Management Pack does not provide coverage for our specific scenario or we have a
custom application, a custom Rule or Monitor may be created and saved in a Custom
Management pack.
For example, we may write events to the Event Viewer from within our BizTalk
application.
 If we wanted to generate alerts whenever these events occur, we could write
a custom rule that will monitor the Event Log for any occurrences of this
event.

38
The figure below shows the Rules View.

Overrides Scenarios
Scenario 1: Overriding Core Alerts
1. We start by select the Authoring Tab.
2. Then we select Management Pack Objects.
3. And then we select Core Alert:Critical Error – A BizTalk Host Instance has
stopped as show in the figure below.
4. We right click on the item and select Summary.

39
5. We view the Overrides Summary as shown in the figure below.
6. We select the item displayed and click on Edit

7. We then Select the object.

8. We view the Overrides that effect the rule as shown in the figure below.

40
9. We select the object and click on Edit and we view the Override Properties as
shown in the following figure.
10. We then select the first Override-Controlled Parameter and select the Override
Value.

41
11. We are able to view the Properties, General View as shown below.

42
12. If we select the Configuration tab, we can view the Rule Configuration.
13. If we select the Overrides Tab we can Override one or more parameters of this
rule through overrides as shown in the following figures.

43
We can modify the Overide Properties as shown in the following figure.

44
Scenario 2: Overiding BAM Portal Availability
1. We start by select the Authoring Tab.
2. Then we select BAM Portal State View as shown in the figure below.

45
3. We right click on the item in the State View and select BAM Portal Availability
Monitor Properties and select the Overrides Tab.
4. We click on the Overides button. This starts the Select Diagnostic Task
Wizard..
5. We select Run Command.
6. Next we enter The Diagnostic name and description. We select the health state
and click next as shown in the following figure.

46
7. We click next and on the next screen we enter the full path to the file.
8. Finally we click on the Create Button.
9. Once the Wizard has completed, we are back at the Monitor Properties form. We
then select the Diagnostic and Recovery Tab as shown in the figure below.

47
 We can find more information about authoring management packs on Mircosoft
Technet at technet.microsoft.com/en-us/library/ee957010.aspx

DATA COLLECTION
SCOM Data Collection provides for Reporting. SCOM collect large amounts of data
from our BizTalk 2010 environment. We can use this data to create reports that will
provide us with additional information about the health of our environment. These reports
can help us identify problems and make it easier to isolate trouble spots..
48
 The default behavior for collecting diagnostic information about the systems that
you are monitoring is 7 days.

Before we can use the reporting feature we need to install the required reporting
components. We can read more about creating Creating Reports on Microsoft Technet
technet.microsoft.com/en-us/library/dd440872.aspx
BizTalk Server 2010 includes many SQL Server Agent jobs that perform important
functions to keep our servers operational and healthy.
The BizTalk Server 2010 management pack includes two disabled rules for monitoring
the health of two of the most important BizTalk SQL Server Agent jobs:
 Critical Error: A BizTalk SQL Server Agent job failed - Backup BizTalk
Server
 Critical Error: A BizTalk SQL Server Agent job failed – Tracked Message
Copy

We should monitor the health of these jobs and ensure that they are running
without errors.

In order to monitor all the BizTalk Server SQL Server Agent jobs from within the
BizTalk Server management pack, we must enable these rules and create additional rules
for other jobs that we want to monitor.
We do this by using the following process:
1. In the Operations Manager Administrator console, we create a copy of either of
the two preceding rules in the BizTalk Server Core Rule group, and rename the
rule appropriately.
In the criteria section for the rule, we change the wildcard comparison for
Parameter 1 appropriately.
In some cases, job names are dependent on database names that the user creates,
for example, the name of the MessageBox database.
Our rule can be targeted either towards a job associated with a single
MessageBox or all MessageBoxes

SQL Agent Job Unit Monitors

The SQL Agent Job Unit Monitors provide the following State changes.
49
Last Run Status
1. The monitor verifies the last run status of the job every 600 (Interval) seconds.
2. If the last run status shows failed, the monitor changes state to Critical.
3. If the job hasn’t completed yet and does not have a last run status, the monitor
does not change state.
Job Duration
1. This monitor verifies the execution time of the job every 600 (Interval) seconds
2. If the execution time exceeds the lower or upper threshold, the state of the
monitor changes to warning or critical accordingly.
3. When execution times are lower than the thresholds, the monitor state changes to
healthy

Microsoft SQL Server Management Pack

The Microsoft SQL Server Management Pack provides us with rules for monitoring our
SQL databases and SQL Server Agent jobs.

Monitoring SQL Server Agent Jobs and Databases

Monitoring of the SQL Server Agents and Databases provides us with critical
information about the state of the BizTalk 2010 SQL Server. As we all know, if we have
an issue on our SQL Server, it could lead to total failure of BizTalk.
 Management pack rules collect total data log and log file free space
 Management pack monitors provide space monitoring on three levels: data
files, file groups and databases
 Long-running SQL Server Agent jobs
 Blocking sessions

ADDITIONAL MANAGEMENT PACKS

We can use the following management packs to extend and enhance the capabilities of
monitoring of our BizTalk 2010 Server environment.
 Microsoft Windows IIS
 Microsoft Windows Base Operating System
 Windows Server AppFabric
 Message Queuing
 Third-Party

50
  NLB and failover clustering

Microsoft Windows IIS Management Pack

This management pack provides us proactive and reactive monitoring of our IIS
Environment.
Key Monitoring Scenarios
The following are several key monitoring scenarios that the Microsoft Windows IIS
Management Pack provides.
 Monitor the Web Server status and the status of the following services: Web
management, FTP, SMTP, Windows Process Activation Service (WAS).
 Monitor that the following are running and available: Web site, Application
Pool, FTP Site, SMTP Virtual Server.
 Detect an alert on configuration and resource errors logged by IIS 7
components
 Monitor application pool recycling events to detect application pools which
may be executing code that is generating memory leaks or other memory
usage problems, and then change the health state accordingly.

Unit monitors: Event Log

Included with the Microsoft Windows IIS Management Pack are Unit Monitors that write
to the Event Log. The following are examples of the information included.
 Application pool disabled due to Windows Process Activation Service
(WAS) request failure.
 Application pool disabled due to worker process failure.
 Application pool identity is invalid.
 Potential memory leak in Web application code.
 Windows Process Activation Service (WAS) has encountered an error during
the security identifier (SID) mapping for the application pool.
 Configuration request for Web site failed.
 Could not initialize the logging module for Web site.
 HTTP.sys has been configured to listen to too many ports.
 Key Monitoring Scenarios
 HTTP.sys has been configured to listen to too many ports.
 Invalid application path.
 Invalid Web site bindings
51
  Invalid Web URL.
 IP address for the site is not in the HTTP.sys IP listen list.
 Web site binding is already in use.
 Web site is configured to use invalid application pool.
 Windows Process Activation Service (WAS) did not create site.
 Windows Process Activation Service (WAS) did not process changes that
affect the Web site.
Performance Collection Rules
The Microsoft Windows IIS Management Pack includes Perfornance Collection Rules.
These Rules include:
 Web Service\Bytes Received/sec
 Web Service\Bytes Sent/sec
 Web Service\Bytes Total/sec
 Web Service\Connection Attempts/sec
 Web Service\Current Connections
 Web Service\Total Method Requests/sec

Microsoft Windows Base Operating System Management Pack

This pack provides us with the ability to monitor our operating system.
Key Monitoring Scenarios
Availability
 Operating system and services
 Storage
 Network
Performance
 Processor
 Memory
 Logical disk
 Physical disk
 Network adapter

52
Windows Server AppFabric
The management pack provides us with the capibilites to monitor our AppFabric
infrastructure which includes both the WCF and WF Services it manages.
Key Monitoring Scenarios
The key monitoring scenarios for the Windows AppFabric mamagment pack are.
Database
The Windows Server AppFabric Management Pack includes two types of databases to
provide application monitoring and workflow persistence capabilities. The databases are:
 Persistence database -- critical to the operation of the workflows that are
running in the AppFabric/IIS server computer.
 Monitoring database -- because the application logic does not depend on its
data, it is not as critical. If the monitoring database becomes unavailable,
users will lose visibility into what the applications are doing.

AppFabric Runtime Infrastructure

AppFabric Hosting Services provides us with runtime capabilities that help manage and
monitor Windows Communication Foundation (WCF) and Windows Workflow
Foundation (WF) services. There are three runtime services that provide these
capabilities:
1. WCF Operation Calls Per Second
2. WCF Average Operation Call Duration (milliseconds)
3. WCF Operation Calls Failed Per Hour

AppFabric Event Collection service

 AppFabric Workflow Management service
 AppFabric Caching Service
 AppFabric SQL monitoring databases
 AppFabric SQL Workflow Instance Stores
 AppFabric database connections
 IIS Hosted WCF and WF services

Service Level Dashboard 2.0 for SCOM 2007 R2

Service Level Dashboard 2.0 tracks and reports the service levels of line-of-business
(LOB) applications and groups (applications or systems) on a near real-time basis.
53
 According to User Guide on Micosoft TechNet, the Service Level Dashboard is
an application built on Windows SharePoint Services 3.0, which is its
presentation platform. It is designed to use an existing Operations Manager
2007 R2 infrastructure configured to monitor business-critical applications as
its engine. The dashboard evaluates an application or group over a time period
that the administrator selects, determines if it met the defined service level
commitments, and displays summarized data about the service levels.
Service level commitments are established in Operations Manager 2007 R2 by
defining service goals (called “service level objectives” or SLOs). The Service
Level Dashboard evaluates each SLO over the defined dashboard time period
and determines if it met the goal during that period. The dashboard displays
each SLO and identifies its states, based on the defined service level targets.
According to the User Guide, The Service Level Dashboard integrates with
the Operations Manager Data Warehouse database and displays service
level metrics on the Windows SharePoint Services interface. All the customized
and personalized data associated with the Web Parts of the Service Level
Dashboard is stored in the Windows SharePoint Services Content database.
The dashboard can summarize the current status and health of all defined SLOs
against an application or group of objects. Key measures used to evaluate
various aspects of the health of defined SLOs include such information as
service level metrics, mean time to repair (MTTR), mean time between failures
(MTBF), and service level trends.
The User Guide is part of Server Level Dashboard 2.0 for Systems Center Operations
Manager 2007 R2 and can be downloaded at:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=16638

SCOM 2012
System Center 2012 Operatation Manager will soon be replacing System Center
Opertations Manager 2007 R2. At the time of the writing of this book, It is planned for
RTM by the end of 2012.
SCOM 2012 provides new features that can be of benefit of the Monitoring of our
BizTalk Environments.
These features include:
 Can run completely in a Virtualized Environment
 Network Discovery, Monitoring, and Rreporting
 Port/Interface monitoring
54
 o Up/down monitoring
o Traffic volume
o Utilization
o Dropped packet rates
o Broadcast traffic stats
 Virtual Local Area Network (VLAN) health monitoring
 Overall connection health
 New Visualization Dashboards
o The health of the Network
o The helath of a device on the Network
o Network Interface statistics
 AVIcode
 Using SharePoint 2010 to View Operations Manager Data
o System Center 2012 – Operations Manager includes a
SharePoint Web Part that displays selected dashboards from the
Web console. A configured Web Part allows you to see at a
glance the availability and performance metrics for applications
in your environment. The Operations Manager Web Part is
particularly useful for providing current status views to
individuals in your organization who are not Operations
Manager users.

AVIcode
Avicode was purchased by Mircosoft and is being incorpated into Mircosoft Systems
Center. It will incorporated into SCOM 2012 as a new .NET APM Monitoring feature.
This feature was previously known as AVIcode. It will be named the .NET AVIcode
APM Component.
The current Avicode Biztalk Cartridge/MP 5.7 supports BizTalk 2006 and 2009. It is
unknown if it will support BizTalk 2010.
The .NET AVIcode APM Component will provide for the monitoring of Web Services
deployed on our BizTalk Servers. It also provides support for monitoring .Net
Components.
The .NET AVIcode APM Component is installed during SCOM Server or Agent
Deployment but is not enabled. You will need to manually enable the component.
VIAcode http://www.viacode.com/ hosts a MP Wiki which provides a sample lab
generated by AVIcode .NET Enterprise and uX 5.7 MPs templates for demonstrating
AVIcode features.
55
 The System Center APM Demo – Talking Heads is available at
http://viacode.com/apm-services/apm-demo-lab

Monitoring EDI and AS2 BizTalk 2010 Solutions

The BizTalk Server Administration Console provides us with EDI and AS2 Status
Reporting. We are able to view the status of incoming and outgoing EDI and AS2
measages.
In order to view these report, we must first Enable them. There are three ways we can
accomplish this.

Enable Status Reports

 Enable status reports for inbound or outbound EDI interchanges that resolved
to an agreement.
 Enable status reports for EDI fallback agreement properties, so status
reporting is activated for EDI interchanges that BizTalk Server could not
determine an agreement for.
 Enable status reports for AS2 messages

Detailed instructions can be found on MSDN at msdn.microsoft.com/en-

us/library/bb226464.aspx

The next step is to Configure an EDI and AS2 Status Report

Configure EDI and AS2 Status Reports

After we have enabled our EDI and AS2 status reports, we will be able to display a report
from the EDI Status or EDIINT Status Reports section of the Group Hub tab on the
Group Overview page in the BizTalk 2010 Server Administration Console.
When a status report is displayed, you will see a default set of data. We can use this data
to configure our status reports.
Configuring the Status Reports
The reports can be configured using the following aspects.
 The query expression that is run to determine the range of data that status is
reported for, for example, the date range, the direction of the data (receive or
send), or the status value (Accepted, Rejected, All, etc.)

56
  The type of data displayed in the status report pane, as determined by the
data columns in the report.

Detailed instructions can be found on MSDN http://msdn.microsoft.com/en-

us/library/bb743413.aspx

Enabling Error Reporting

We are able to select whether we want to display enhanced errors and warning in the
Windows Server Event Viewer.

Detailed instructions on Enabling Error Reporting can be found on MSDN

http://msdn.microsoft.com/en-us/library/bb245959.aspx

We will learn about EDI and AS2 Event and Errors in Chapter 5 – Problem
determination, event sources and files.

We will learn more about EDI in Chapter 8 – EDI and Accelators

Out Of The Box Monitoring Features

We have seen how we can benefit from SCOM to monitor our environments and be
alerted of any potential issues as soon as they show up. But, think about these scenarios:
 The SCOM implementation in our company has been delayed due to budget
constrains
 We had SCOM in place, but it´s going through a severe outage and it might
not be available for days

There might be situations where we don´t have SCOM (or any other third party
monitoring tools) at hand to cover our monitoring needs. We will have to put in place
some alternative procedures to keep us as safe as possible from having a big problem
developing in our environments and not being aware of it because we were not
monitoring them.
BizTalk Server, and the Windows platform underneath it, provides some out of the box
features that we can use on those situations where our principal systems monitoring
solution is not available:
 The Windows Server Event Logs

57
  The BizTalk Administration Console
 The ESB Toolkit Administration Portal
 The BAM Portal

Windows Server Event Logs

“Do you see any errors on the Event Log?” Most probably you´ve been asked (or you
have asked to others) this question when troubleshooting an issue in your systems. Yes,
the Event Viewer is one of the very first places we all look for evidences of something
going wrong in our systems, but dedicating our time to look into those logs all day long
wouldn´t be very efficient way of expending our work effort. Needless to say it would be
the most boring work task ever.
Windows Event Logs have been boosted with some nice features lately to help us using
them to monitor our systems in a more efficient way.

Centralizing Events Monitoring

BizTalk is one of those architectures where we can have many different servers playing
different roles, so our whole production environment can be composed of multiple
servers, each of those having their own event logs, so again checking those logs on each
and every server would be a very time consuming task.
In Windows Server 2008 R2 we can setup a specific server to collect events from other
servers so we have one single point where we can see what´s going on. That centralized
server will be the events collector, and the other servers in our environment will forward
events to it.
Before describing the steps to configure the collector and the forwarders, it is important
to mention that we should choose the collector to be the server that is topologically closer
to the majority of the event forwarders, as event forwarding from distant servers won´t be
as efficient as from closer servers.
First we will have to enable the Windows Remote Management Service on each server,
whether it´s a forwarder or the collector.
We open a command box and enter the following.
winrm qc –q

The command will make the modifications required to enable the Remote Management
service, create the Remote Management Endpoint and create the Firewall exception if
required.

58
Before creating the actual subscriptions on the collector, we will have to add the collector
server computer account to the local Administrators group on each of the source servers.
Done that, we can go to the collector server and create the subscriptions that we want on
its event viewer mmc, just by right clicking on the “Subscriptions” node and then “Create
Subscription” on the context menu or by using the Actions Menu as shown in the
following figure.

Finally, we will be able to choose the log where all the forwarded events will be
centralized, the collection mode (collector initiated / PULL mode or source initiated /
PUSH), filter the events we want to collect and even delivery optimization options.

59
Creating Custom Views
In order to better analyze the different kind of events that can be generated in our
environment, you can segregate them into different views. This is not a replacement for
SCOM.
In the Windows Event Viewer we can create custom views and filter the events showed
in them as shown in the following figure.

60
Once we click on “Create Custom View”, a window will show up allowing us to define
the filter criteria we want to apply to that view as shown in the following figure. We can
narrow our filter even to a specific range of event IDs.

61
In the next section we will explain how to attach tasks to these event views, like sending
an email when a new event is published to them, so the better you segregate the events in
different views, the most specifically we will be able to react to the events published in
them. We can also organize the custom views in folders to fit our operation processes
needs.
Given the view organization shown below, we could take specific actions just for SQL
related events (e.g. sending the DBA team an email) that could be different from those
for specific BizTalk events (that could be notified just to the BizTalk Administrators
team).

62
Attaching Tasks To Event Views -- If we let problems grow for some time after they
start, most probably it will be harder to fix them than if we did handle them earlier. This
is the main reason to be notified or take an action as soon as a problem shows its first
symptoms and so this feature in Windows Event Viewer is a life saver.
We can attach a task to any View, either out of the box views or any custom views we
might have created, just by right clicking on the view and then on the “Attach Task to…”
entry on the context menu as shown below.

63
This will bring up a wizard where we can set the basic properties of the automated task
we are defining. That automated task created is just a Windows Task Scheduler task that
has a trigger set to “On an Event” type with the same filters as the event view we are
working with.
We will set the name of the task (as we could define as much tasks as we want for the
same view) and the action to execute between the usual choices available in the Tasks
Scheduler:
 Start a program
 Send an email
 Display a message

64
Once the task is created, we can edit it to further customize its behavior as shown in the
following figure: .

The BizTalk 2010 Administration Console --The BizTalk Administration console is the
principal management console a BizTalk administrator works with, and so it also
contributes to help on monitoring tasks.
Though it doesn´t have any features to automate actions to happen when certain query
returns results like the Event Viewer does, it helps for ad-hoc monitoring of the
environment and further issues investigation. These will be in depth discussed in the
Problem determination, event sources and files chapter later on this book.

The ESB Toolkit Administration Portal

The ESB Administration Portal (or ESB Management Console) has some automation and
alerting features that will help us to be aware of any outstanding events or issues going on

65
in our system, apart from the ad-hoc monitoring we can do by means of the different
views and reports it provides..

Alerts in the ESB Management ConsoleWithin the Alerts menu on the ESB Management
Console, we can create new alerts that users will be able to subscribe to. Those alerts
could be created for pure functional/business error scenarios, but also for situations where
certain failures could indicate that something is going wrong with the environment and so
the BizTalk administrators could use them as an indicator that the problem determination
process should be kicked off.

Once we click on the Create Alert link button, we presented with a form where we can set
the name for the new alert and also create the different filters that will trigger the alert. If
we find those filters, based primarily on ESB Toolkit’s fault messages properties, doesn´t

66
fit all our needs, we could work with our solution Architecture and Development team to
extend and customize this ESB Console feature as needed.

We are assuming that the ESB Management Portal Alert service is already configured in
your environment, but if not, you can find the instructions on how to install it and
configure it on the ESB Toolkit Installation documentation.

BAM Portal
Business Activity Monitoring is primarily meant to monitor how our business processes
are behaving, but that information is not only meaningful for business people but can also
indicate that something in our architecture is breaking.
This has even more sense if we create BAM Views that measure service levels our
business services should meet given the SLAs defined for our solution. At the end of the
day, most of the tasks of a system administrator are driven by the goal of ensuring the
systems he/she administers are able to deliver the right level of service.
Once we have defined the appropriate views that measure if ours SLAs are met or
missed, we can create alerts on those, so as soon as they start slipping we can come into
action to track where the issue is.
Let´s say our business processes are based in ESB itineraries and it was defined that the
SLA for our itineraries is that their execution should take less than 2 seconds. We can
create a BAM view on the ESB ItineraryServiceActivity BAM Activity that measures the
duration of our itineraries execution.

67
The following figure shows how we do this.

Then, on that BAM View we would create a view dimension that measures if the
Itinerary execution duration is within our SLA boundaries, along with the rest of the
dimensions and measures that we would need in our BAM view (e.g. the Itinerary
Name). The following figure shows how we do this.

68
Our SLA view could look in Excel like the one below once it´s ready to be deployed to
BAM:

69
Once our view is deployed, after our business processes have been run for a while and the
corresponding business activities have been recorded, we can go to BAM portal and take
a look on how are we really meeting our SLAs. Given the figures below, it looks like we
should trace down why that business process is sometimes missing the SLA.

But the best part of it is that we can create BAM alerts on these views, so we are
automatically notified once a specific SLA is missed and the potential issue doesn´t
continue developing unnoticed. We just need to set up the appropriate filters on our
activity search query over the BAM View, and set an alert for it by clicking the “Set
Alert” button.

70
Finally, notice the sample we just showed would make sense only if all the itineraries in
our solution had the same execution SLA (2 seconds), In case we had different SLAs for
each itinerary, we could create our alerts directly based on the duration column and
filtering by the itinerary name as well as in the screenshot shown below.

71
Summary
In this chapter we have learned about the importance of Monitoring our BizTalk
Environment, Services, and Applications.
We were introduced to Microsoft System Operations Manager 2007 R2 (SCOM) and
how we can use it to monitor BizTalk. We were provided with two scenarios that
demonstrated many of SCOM’s features.
We discovered the Service Level Dashboard 2.0 for SCOM.
We learned about SCOM 2012 and some of it’s new features. We discovered that
AVIcode is to be part of SCOM 2012 and some of the monitoring capabilities it provides.
We were provided with a scenario showing some of these capabilities.
We also discovered AVIcode and its advantages.
We also learned how to leverage the EDI and AS2 Monitoring capabilities provided by
BizTalk 2010.
Finally we discovered how we can have an alternative approach for monitoring just by
using BizTalk and Windows out of the box features.
In the next chapter we will learn about the various third-party tools that we could use the
Monitor BizTalk 2010 Server.

72