Alert Notification Document

EAI Replacement

Document Information
Project Name: EAI Replacement
Project Manager: Prateek Chawla
Prepared By: Haribabu D Document Version No: 1.0
Title: Alert Notifications Document Version Date: 11/7/2009
Reviewed By: Review Date:

Document Revision History

Ver. No. Ver. Date Prepared By Reviewed / Affected Section & Summary of Change
Approved By
1.0 11/04/20 Initial Draft
09
 Table of Contents

1 Introduction......................................................................................................................2
2 Purpose.............................................................................................................................3
3 Scope................................................................................................................................3
4 Approaches......................................................................................................................3
5 Evaluation Criteria...........................................................................................................4
6 Implementation Criteria...................................................................................................5
7 Evaluation of Email Notification.....................................................................................7
8 Features include: .............................................................................................................8
9 Usage Notes.....................................................................................................................9
10 List of References..........................................................................................................9

1 Introduction
This document describes the different approaches of Alert Notifications for the project
EAI-Replacement. The Proposed design should support addition of new internal or
external systems in future.

The Alert Notifications feature enables more dynamic interaction between users, EAI
Replacement and hosted My webMethods Server technologies. Users will have the
 ability to quickly notify other users that something of interest is occurring. This
notification could take multiple forms including e-mail and live alerts in the remote
user’s web browser. EAI Replacement Application can also be configured to more
interactively alert users when certain circumstances. Finally, My webMethods Server
itself can be enhanced to provide more immediate information, such as presence or
broadcast notifications from an administrator.

2 Purpose
• This design supports the alert notification process.
• It is focused on how to alert a client with appropriate messages

• It also includes the Alert notification monitoring mechanism.

• Design of solution components that are part of application.

3 Scope

This document supports Alert Notification process framework and the other
approaches are out of scope of this design document.

The documents details the following

• Sending regular text.

• Enhanced messaging service.

• Requesting notifications

• Setting e-mail indications.

4 Approaches
This document has been prepared based on the GEAR65 white papers and
documents provided by the advantage.
This document has the proposed solution for Alert Notification Process. The proposed
solution should handle the below scenarios….
 1) When to raise an alert notification, What Happens When an alert occurs the
integration server automatically invokes all the alerts that are subscribed to
the alert event.
2) Handling the alerts the below scenarios comes under the transient
1. Database is down.
2. Failure of Network Connections.
For example, error connecting to db, or, error due to user
setting is not valid.
3) Intimation of alerts through the email notification facility provided by
webmethdos.

5 Evaluation Criteria

We have two different types of criteria’s to send alert to the users, basically the main
events we will approaches are

1. We can notify the users through Event Handler facility provided by webmethods.

The event handlers are processed independently of the services that invoke them.
They are completely separate, asynchronous processes. Event handlers are not
designed to replace the error handling and/or error recovery procedures that you
would normally include in your service.

2. We can also send an email alert through Email Notification.

The most common error reporting method is email notification but many
companies use a hybrid system in which Remedy, Peregrine, or other sophisticated
issue tracking tools are deployed as well. An error should be classified and
reported to any relevant applications as well as delivered via email to developers.
This approach helps to deal with critical issues quickly.
A generic Error Handling service can be written to manage these tasks. It should
reside in a utility-level package from which the entire corporate implementation
will benefit. Then, a customized Error Handling service should be written to add an
additional abstraction layer. This step provides freedom to change the error
notification logic without changing the underlying business integration logic or
performing additional regression tests.
6 Implementation Criteria
By using the Event Handler facility we can handle different types of events

The webMethods Integration Server also ships with Event Manager. Event Manager is
very useful as an umbrella for error notification because it catches exception events
for the entire server. Its broad scope, however, can work against you as your system
can quickly flood with unwanted notifications. Because of this, Event Manager must be
configured for filtering so that it only catches errors that are required by the
developers.

Audit Event:

This event marks the beginning of a service, end of a service that executed
successfully. This event marks the end of a service that executed
unsuccessfully (that is, threw an exception) and is not configured to retry. A
failed event also marks the end of a service that executed unsuccessfully after
exhausting all of its retries.

An audit event occurs when a service generates audit data. You can use the
options in a service’s Audit properties to specify when a service generates
audit data. A service can generate audit data once, twice, or zero times during
execution. You can use audit events to invoke other services when a particular
service executes. For example, you might want an audit event generated for a
critical service to invoke a logging service or a notification service.

Building Handlers for Audit Events:

• When the Event Manager invokes an event handler for an audit

event, the event handler receives an IData object that contains the
following runtime data. (A specification and an IS document type for
the input data are provided in the pub.event folder).

• The audit event handlers that you build can make use of these
inputs as they need to. Keep in mind that when the service’s Log on
option is set to Error, success, and start an audit event handler is
called twice each time a service runs: once when the service starts and
again when it ends. Your event handler can check the value of the
result parameter to determine whether it is processing an audit event
from before or after the service executed.

Exception Event:
 • An exception event occurs when a service throws an exception
(including when a flow service “exits on failure”). You can use exception
events to invoke some prescribed action, such as notifying an
administrator, when a particular service fails. If a nested service throws an
exception, an exception event is generated by each service in the call
stack.

For example, if service A1 calls service B1, and B1 throws an exception,

both B1 and A1 generate exception events (in that order).

Alarm Events:

A service can generate an alarm event when a client invokes a service that
accesses information or a service on a remote server. If the client is not a
member of an allowed group for the port on the remote server, the service
will generate an alarm event.

• An alarm event occurs when the Integration Server generates

a message related to the status of the server. An alarm event can be
generated for the following reasons:

 A client experiences a logon failure or is denied access

to the Integration Server. A client cannot log on because of
“invalid credentials.”

 Errors occur in the Cluster Manager. The inability to

add a port to a cluster can cause errors in Cluster Manager.

 A user tries to access a port and is denied access to

the port. (This can happen when a user tries to execute a
service not allowed on the port.) This type of alarm vent is
sometimes called a port access exception.

 A port cannot be started. The most common reason a

port cannot start is that the port is being accessed by another
application.

 A service cannot be loaded or executed due to setup

errors. For a flow service, a possible error is a missing XML
metafile. For a Java service, possible errors include a missing
class file or method.

You can use alarm events to invoke event handlers that execute
when the server generates messages related to the status of the
server. For example, you might want to create an event handler that
notifies the administrator when a user is denied access to the server or
to a port, when a service fails to load or execute, or when a port does
not start. You can also create event handlers to send data to a
network monitoring system.
7 Evaluation of Email Notification.

Actually it is very nice to have an alert when a component is violating a rule.

Eamil Notifications in services using logging methodologies through the settings.

1) Logging option in the web methods integration server Administrator

2) Edit the Logging settings.

3) Type the email address for the administrator to whom you want the server to send
error notification in the Service Email field in the Email Notification section of the
screen.
We can set email notification if we have error while working with IS. However, there
are 2 types of emails that will be sent to recipient. We have 2 types of emails internal
email and service email.

Resolution

Those 2 emails are divided as per below:

1.Internal email
If there is any error related to internal working if IS (like package loading,license
expiry ,authentication failure etc) the internal email will be sent.
Basically, internal email is reserved mainly for sending email in case of authentication
failures.

2. Service email
If there is any error related to execution of any service then service email will be sent.

For example, error connecting to db, or, error due to user setting is not valid.

Email Notification can be set in ISAdmin>> Settings> Logging->Edit Logging Settings-

>Email Notifications. Note that currently email notification is not able to set multiple
email addresses in To. Recommended way is to make use of mailing list address.

The SMTP server expects a sender mail address for each mail. This is the envelope-
from address. It is independent of the from header (because it is part of the mail
envelope, not of the mail itself), but in most cases both addresses are the same.

The character set used to encode the MIME message headers (including subject). If
subject Character set is not specified, then character set is used. If character set is not
 specified, the value in the server parameter watt.server.email.character set is used. If
that parameter is not set, the utf-8 encoding is used.

pub.client:smtp

This email is intended for the sole use of the intended recipient/s and may contain material
that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by
others or copying or distribution or forwarding of any or all of the contents in this message is
STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by
email and delete all copies; your cooperation in this regard is appreciated.

Invoke getLastError after the smtp step may be you may get the exact error

In the try/catch sequence, is the whole sequence set to exit on 'DONE’, the 'try' to exit on
'Failure' and the catch set to exit on 'Success'?
Also in the catch, why not have a global sub-service which executes getLastError initially then
extract the error detail and then e-mail.

The mandatory fields required by the pub.client:smtp service.

The extra mandatory fields now required are:

• mailhost
• from

Normally the mailhost is populated by the System environment variables with the latest
version of the service mail host has become a mandatory field.

The from field is usually populated by the user currently running the IS.

8 Features include:
• A reminder email can be periodically issued.

• Send mail compatible interface.

• Fast SMTP implementation using command pipelining.

• DSN (Delivery Status Notification) support.

• Support for multiple accounts.

9 Usage Notes
• Remember to register your handler with the Event Manager.
• Not all exception handlers that you code will log information.

• Event handlers for exception events are invoked synchronously or asynchronously.

• When this parameter is set to true, Integration Server invokes the event handlers that
• Subscribe to exception events asynchronously. When this parameter is set to false,
• Integration Server invokes the services that subscribe to the exception events
synchronously. The default is true (asynchronous).

10 List of References

Ref. # Title Date File name Author

001 Best Practices Design Templates Best practices from various engagements

002 Webmethods Broker Version:7.1.1

Administrator Guide
003 Webmethods Integration Sever Version:7.1.1
Built_In Services Reference
004 Webmethods Developers Users Version:7.1.1
Guide
005 Gear 65,wmusers Version:

https://advantage.webmethods.com.

http://www.wmusers.com.