Notification Framework v1.0 - Techhosteddocs.ittoolbox.com/Generic_Notification_Framework...Generic Notification Framework Ver 1.0 Page 1 of 27 GENERIC NOTIFICATION FRAMEWORK FOR EAI

Generic Notification Framework

Ver 1.0 Page 1 of 27

GENERIC NOTIFICATION FRAMEWORK FOR

EAI Solutions [Easily extended as an Enterprise-wide Service]

Srikanth Challa

Version No. 1.0



VERSION HISTORY

Version No. Date Prepared/

Changed By Changes Made

0.0 Mar 03, 2006 Srikanth Challa Initial

1.0 Apr 19, 2006 Srikanth Challa Complete



TABLE OF CONTENTS

1 INTRODUCTION............................................................................................... 4 1.1 PURPOSE AND SCOPE ......................................................................................... 4 1.2 BACKGROUND.................................................................................................. 4

1.2.1 Problem Definition ................................................................................................................................5 1.2.2 Plausible Solution..................................................................................................................................5

1.3 TARGET READERS ............................................................................................. 6 1.4 ASSUMPTIONS ................................................................................................. 6 1.5 KEY ABBREVIATIONS.......................................................................................... 6

2 OVERVIEW OF NOTIFICATION SERVICE........................................................... 7 2.1 INTRODUCTION ................................................................................................ 7 2.2 CONTEXT ....................................................................................................... 7 2.3 REQUIREMENTS................................................................................................ 7

3 NOTIFICATION SERVICE ARCHITECTURE ......................................................... 8 3.1 CONCEPTUAL ARCHITECTURE ................................................................................. 8

3.1.1 Persister Module....................................................................................................................................9 3.1.2 Timer Module.......................................................................................................................................10 3.1.3 Notifier Module....................................................................................................................................10 3.1.4 Configuration Module..........................................................................................................................12 3.1.5 Persistent Store....................................................................................................................................12 3.1.6 Application Programs..........................................................................................................................12 3.1.7 Email Server ........................................................................................................................................12

3.2 RUNTIME HIGH-LEVEL ARCHITECTURE.................................................................... 13 3.2.1 Extension as a Web Service .................................................................................................................14

3.3 ADVANTAGES ................................................................................................ 14 4 DETAILED DESIGN - NOTIFICATION SERVICE (VITRIA) ................................. 15

4.1 DESIGN OF NOTIFICATION MESSAGE....................................................................... 15 4.2 DESIGN OF METADATA....................................................................................... 16 4.3 DETAILED DESIGN OF VITRIA COMPONENTS............................................................... 17

4.3.1 Design of Integration Model................................................................................................................17 4.3.2 Design of Process Model - Persister ...................................................................................................20 4.3.3 Design of Process Model – Timer........................................................................................................21 4.3.4 Design of Process Model - Notifier .....................................................................................................22

4.4 DATABASE DESIGN .......................................................................................... 23 4.4.1 Structure of Configuration Table.........................................................................................................24 4.4.2 Structure of Data Table .......................................................................................................................25

4.5 DESIGN OF APIS TO SEND MESSAGES TO THE NOTIFICATION QUEUE ................................... 26 5 REFERENCES.................................................................................................. 27



1 INTRODUCTION

1.1 PURPOSE AND SCOPE

The document aims to outline the problems faced by a typical EAI Solution in the realm of Error Reporting (System/Business errors) within the EAI Landscape. It then focuses on proposing a simple, reliable and scalable framework which can be built using some of the most common functionalities provided by any EAI product to address the issue. Technology independent Conceptual Architecture and High Level Design to implement the framework is illustrated in the subsequent sections. The document also throws light on the detailed design to implement the framework in Vitria BusinessWare 4.2.x. Finally, it outlines how the framework/solution can be extended as an enterprise wide service by the use of standards such as XML and Web Services to cater to the Notification needs of various software components (including non-EAI) within the enterprise. Following will be in scope of the current document:-

• Problem Definition

• Conceptual Architecture of the Notification Service

• Runtime High Level Architecture/Design of the service in context.

• Advantages & capabilities by extending as a web service.

• Detailed Design for implementation in Vitria 4.2.x.

1.2 BACKGROUND

Any EAI Solution consists of Integration Scenarios/Interfaces between numerous Systems, Applications etc. within and outside the Enterprise. The core job of an EAI tool is to integrate these Systems/Applications seamlessly. While the Design, Performance and Load of the Solution are key factors for the stability of the EAI Layer, there is often another factor which impacts the overall data flow through the EAI Layer i.e., “The External Systems.” A failure on the External Systems (Source or Target) eventually affects the data flow within the EAI Scope. Hence, there always stands a requirement for the EAI Solution to be able to notify failures to various parties involved in the integration. This requirement seems to be straight forward and simple, but the challenge faced by many projects is how to handle this notification in a controlled manner. Many implementations have Notification modules sending failure or informational notifications to various parties, but the key factor here is whether these modules are intelligent enough to handle this in a controlled manner. Let us take an example to understand the problem clearly.



1.2.1 PROBLEM DEFINITION

Consider an Integration Scenario between three Insurance Vendors (for an organization) and a Master Employee Information System within the Enterprise. Employees’ insurance information needs to be fed into the Enterprise’s Master IS regularly (say weekly). Let us assume that this feed comes in loads of a few hundred thousand records at a time.

Master EmployeeInformation

System

InsuranceVendor - 1

InsuranceVendor - 3

InsuranceVendor - 2

Common Services

EAI Layer

Figure 1: Problem Definition

Data supplied by the Vendors may not be feasible to be uploaded to the master system due to several reasons (Business Errors or Technical Errors) at that moment of time; business users expect notifications from the System under such circumstances. Now sending one notification per failure/fault (which a normal Notification Module will do) will be feasible if the load and eventual errors are limited, consider a scenario where the load and potential business errors (These errors are large in number but not high priority) are in hundreds or thousands. The system will be consuming huge resources and will also send out numerous notifications with one error per notification – this is not controlled notification.

1.2.2 PLAUSIBLE SOLUTION

There needs to be a Service within the EAI Layer which is capable of receiving all of these errors or failure messages, hold them within the system for a defined period of time based on their priority and then send the notifications to pre-defined users at defined intervals of time. By doing so the Business users will receive Error notifications from the system (maybe hundreds of them) as just one notification, they can take action for the errors without having their mailboxes/notification mechanisms clogged. This plausible solution is the basis for the entire concept of Notification Service which is discussed in the subsequent sections.



1.3 TARGET READERS

No Role Usage description

1 EAI Architects The EAI Architects can understand the services provided by the Notification Service and see how the service fits into a specific EAI Implementation Architecture.

2 EAI Analysts The analysts will use the document to translate the design into a fully functional solution in any EAI technology with modifications to suit to specific project requirements.

3 Application Designers

Designers of other applications can use this document to design their applications to utilize the service via the Web Service extension.

Table 1: Target Users

1.4 ASSUMPTIONS

The reader should be familiar with the concepts of EAI.

To understand the Implementation of the Notification Service in Vitria BusinessWare, the reader should have basic knowledge of Vitria BusinessWare 4.2.

1.5 KEY ABBREVIATIONS

Acronym Description

EAI Enterprise Application Integration

BW BusinessWare

XML eXtensible Markup Language

Table 2: Key Abbreviations



2 OVERVIEW OF NOTIFICATION SERVICE

This section will focus on providing the requirements for the Notification service in context of the overall EAI solution.

2.1 INTRODUCTION

In a typical EAI solution, the middleware interacts with various external applications, systems, databases etc; there is a possibility of errors cropping in any of these interactions as well as the EAI solution itself. It is essential to notify these errors/exceptions to the administrator on a timely basis to ensure proper functioning of the solution and to take corrective action. This major requirement brings the need for a Notification Service within the scope of an EAI Implementation. Apart from the error notification, the current Service is designed to cater to any other kind of notifications from middleware like reports etc.

2.2 CONTEXT

Notification service will be a part of the common services layer in the overall EAI implementation as indicated in the following diagram.

Figure 2: Overall context of Notification Service

2.3 REQUIREMENTS

Following are the requirements for the Notification Service to be designed

1) The service should provide a centralized mechanism of notification for all the EAI components.

2) Communication to the service should be easy. 3) One or more communication mechanisms should be provided for all the EAI components

to talk to the service (Synchronous and Asynchronous modes) 4) It should be a pluggable component to existing solutions and should be easily

implemented for the new ones. 5) The service should cater to the following notifications:

A) Error Notification in the form of email messages with attachments. 6) It should define and enable multiple frequencies and priorities at which Notifications are

sent. These features should be configurable at design time as well as runtime. 7) It should address the exception handling within the service.



3 NOTIFICATION SERVICE ARCHITECTURE

This section will focus on the conceptual architecture for the Notification Service.

3.1 CONCEPTUAL ARCHITECTURE

The following diagram depicts the conceptual architecture for the Notification Service. The notification service is not a single service catering to all the requirements of the service, it is a group of smaller services where each service has a defined task, and each service is responsible to perform this task independently, all of these independent smaller services work in conjuction to make up the Notification Service. These smaller services (modules) in turn interact with each other to achieve the ultimate goal.

Notification Service is further logically divided into Persister Service, Notifier service, Timer Service and Configuration Service. They are defined in the subsequent pages.

Each of the EAI components utilizing the services of the Notification service will be associated with a unique Identification number (Source Id). This number has to be used by the components while communicating with the Notification Service. On the basis of this unique number, configurations specific to the component are made on the Notification Service. This Unique Identifier drives the flow of the error message through the Notification Service; it also governs the parameters set for the delivery of the message viz., recipients, subject, priority etc. Details of the configurations will be provided in subsequent sections.

Note: Components grayed out represent the elements outside of the Notification Service which, either provide service to the notification service or utilize its services.

Configuration Service

E-MailServer

PersistantData Store

Persister Service

Application Programs

(EAI Components)

Notifier Service

Timer Service

WFE for Configuration

Module

Notification ServiceFigure 3: Conceptual Architecture for Notification Service



3.1.1 PERSISTER MODULE

This module has the primary responsibility of persisting/storing the Notification messages to the Persistent Store, a database. The messages that arrive to the service are first persisted irrespective of their priority or any other criteria. By storing the messages to a persistent medium the service has the flexibility of holding the notifications for a defined period of time before they are delivered. If the messages are marked as high priority they are immediately sent to the Notifier module, which sends instant mail for that particular notification message.

Following is the flow diagram for the persister module:-

Figure 4: Flow Diagram Persister Module

Runtime Message Flow:-

1. [Start] The Persister Module listens to the Notification Queue (can be implemented with any of such available components in the EAI product or can be a standard JMS Queue from any vendor) for Notification Messages from various sources.

2. [Parse Notification XML - Transformation] The generic XML is first parsed to identify the priority of the message.

3. [Is High Priority] Conditional check to identify the priority of the message and act accordingly.

a. If the message arrives with low priority

i. [Form Message for Persistent Store – Action/Process] The XML is converted to a Persistent Store specific message (can be a relational database specific message/event) along with some additional information like time when the message arrived to the Notification Service etc.

ii. [Insert Message to Persistent Store – Action/Process] It is then stored in the Persistent Store (by the use of a database adapter/connector)

b. If the message arrives with high priority



i. [Invoke Notifier – Action/Process] The message is first sent to the Notifier Module/Service for immediate delivery

ii. The steps 3.a.i and 3.a.ii are followed.

4. [End] End Processing the XML Message.

3.1.2 TIMER MODULE

The Timer Module/Service is responsible for sending pulses at the specified/configured time intervals to the Notifier Module. At each pulse the Notifier module gets activated and performs a set of tasks. This Timer Module acts as an independent service and can be configured to change the time interval at runtime without disturbing anything on the Notification Service. This configuration can be made from the configuration Module.

Following is the Flow Diagram for the Timer Module:-

Figure 5: Flow Diagram Timer Module


1. [Start] The timer module is triggered immediately after the Notification service is started, or in other words the scope of the Timer Module is for the entire life of the Notification service.

2. [Timer] A preconfigured time interval is set in a special state in this process which sends pulses to the Notifier Service at regular intervals of time to activate the downstream process.

3. This process doesn’t have a logical End state, it terminates when the Service goes offline.

Various EAI products have different implementations to provide the functionality of a timer.

3.1.3 NOTIFIER MODULE

The Notifier gets activated at every timer pulse that is sent by the timer Module. At each of these pulses it performs a predefined set of tasks:-

1) Check for any valid sources for which notifications are to be sent. 2) Check if there are any messages existing for the valid sources in step 1. 3) If there are messages existing then consolidate them, form an errors excel. 4) Send the errors excel of all the valid sources as mail attachments by picking all the

email information dynamically from the configuration table.



5) Also, checks if there any sources that are exceeding the valid threshold number of messages. If there are any send mails for those messages as an overdrive.

Apart from the above tasks the Notifier Module is also responsible for dispatching any of the priority messages that are sent by the persister module at near real-time.

Following is the Flow Diagram for the Notifier Module:-

START

END

PERSISTENTSTORE

QualifiedMessages?

(elapse time)

EmailServer

Yes

No

Mark Qualified Msgs Inprogress & extract

from DataStore

Timer Service

Send Notification

High Priority Message

Regular Timer Message

Create File Extract from Error Messages

(MS Excel)

Update Status in DataStore

CheckNotification

Delivery

Success

Failure

Send Priority Notification

QualifiedMessages?(Threshold)

NoPersister Service

Figure 6: Flow Diagram Notifier Module


1. [Start] The Notifier module is triggered either by the Timer Module or the Persister Module

a. Timer Module – In normal data flow a timer event is generated by the Timer Module at regular intervals of time, this triggers the processing in the Notifier Module

b. Persister Module – When a High Priority message arrives the Persister Module is responsible to dispatch the message to the Notifier along with persisting it, this high priority message also triggers the Notifier Module.

2. [Qualified Messages – Elapsed Time] A conditional check is performed to check if there are any messages in the Data Store which have to be delivered to the recipients due to elapsed time (A configuration setting performed in the Notification Service for each of the Sources). Consider that one of the EAI Objects is configured for a frequency of 15 minutes in the Notification Services, it means that Messages will be stored (dampened) within the service for a period of 15 minutes and then subsequently delivered to the configured recipients.

3. [Qualified messages – Threshold] Apart from the condition in Step #2 the Notification Service will also deliver messages to the recipients if the number of messages published to the service is beyond a predefined number, this is called Threshold Limit for the Source.



4. [Send Priority Notification] If the Notifier Module is triggered with a High Priority Message, an immediate notification is sent to the configured recipients via the E-mail Server.

5. [Mark Qualified Messages in Progress and Extract from Data Store] The Qualified messages have to be marked as ‘in Progress’ and then we need to extract them for delivery, it is important to perform this additional step because the persister module is running concurrently and there might be messages persisted into the datastore while the Notifier is processing some of the qualified messages.

6. [Create File Extract from Error Messages] In this process we interact with the database retrieve all qualified messages and create a CSV file from the messages. One file extract has to be created per Data Source.

7. [Send Notification] Deliver each of the file extracts to the receptive recipients configured for each of the Sources via the Email server.

8. [Check Notification Delivery] Perform a check to ensure that each of the E-mail message has been delivered to the E-mail server, if the status is success proceed to [Update Status in DataStore] if the status if failure continue to [Send Notification] state.

9. [Update Status in DataStore] Once all the required notifications are delivered for a particular batch we need to update the status of all the messages that were qualified in that batch as ‘Processed’ this step ensures that we don’t send duplicate messages.

10. [Stop] Logical stop of the process for one instance’s run.

3.1.4 CONFIGURATION MODULE

Configuration module provides facility to configure the parameters specific to an EAI component (Source id) that the Notification Service will use at run-time to send notifications. It helps in changing one or more of these configurations at run-time without affecting any other services or components. The configuration module makes the implementation of the Notification Service easier and quicker for new project solutions.

3.1.5 PERSISTENT STORE

The Persister module persists the information to a data store, a database. This persistent store serves as a repository that keeps all the information that needs to be notified from various sources to different recipients. Regular cleanup and archival of the persistent store is a feasible option if the number of errors/notifications are in huge numbers, this will improve the performance and reduce resource usage.

3.1.6 APPLICATION PROGRAMS

Application programs in this context are the various EAI Components/solutions (A part of the EAI implementation) who will be using the Notification Service for reporting and notification of various messages/errors during their execution. It can also include any other applications outside the Integration world, which use the Notification service via the Web Service end point.

3.1.7 EMAIL SERVER

This provides the gateway to send email messages from the Notification Service. Several other modes of notification can be configured viz., Paging, FTP files to Support Groups etc.



3.2 RUNTIME HIGH-LEVEL ARCHITECTURE

The Runtime High-Level architecture describes the logical flow of notification messages from the application components to the end user or administrator. The following diagram gives the overall runtime flow.

Notification Service

EAI components using Notification Service

Persistent Data Store

EMAIL Server

WFE for Configuration

Module

LEGEND

Asynchronous Call by External Components

Synchronous Call by External Components

Synchronous Call by Internal Components

Asynchronous Call by Internal Components

ConfigurationModule

Persister Module

Notification Queue

Notifier Module

Timer Module

Web Service

Figure 7: Runtime High Level Architecture of the Notification Service

Following is the Runtime flow: • Notification messages from various EAI components and other Applications across

the implementation are delivered to the Notification service in one of the two supported mechanisms

o A Notification Queue (Specific to EAI Implementations) – asynchronous A JMS Queue can also be exposed to the consumers of the Notification

service. o A Web Service (accessible across the enterprise) – synchronous

• After the messages arrive to the Notification Service the XML content of the messages is transformed and then persisted in the data store irrespective of their priority etc. Here the messages are transformed to records on the data table of the persistent medium. This process is independent and runs for any notification message.

• If a message is delivered with High Priority to the Service, the Persister immediately delivers this message to the Notifier module and the message is sent to the respective recipients in near real-time.

• The Timer Module sends timer pulses at every 15 mins (also configurable at runtime) to the Notifier module.

• The Notifier module polls the configuration table for each pulse sent by the Timer Module.



• For every poll cycle the Notifier module identifies qualified messages, consolidates e-mail for a particular Source ID and then sends the messages to the email server as attachments.

• The Configuration Module gives the flexibility of changing the frequency and threshold of the messages sent for a particular Source ID at runtime.

3.2.1 EXTENSION AS A WEB SERVICE

As the Notification Service stands as a totally independent component within the EAI Scope, its extension as a web service makes it technology independent, easily accessible and a more generic solution. The moment Notification Service is encapsulated into a Web Service its scope crosses the boundaries of implementation. The capability of the Service increases tremendously with this extension and so are the advantages. Following sections list the advantages.

3.3 ADVANTAGES

a. The service which is confined to a single implementation or a group of same technology implementations is now extended across different EAI implementations. Eg. A Notification Service developed in Vitria for a particular enterprise can now be used not only by the Vitria implementations in the Enterprise but also by various other EAI Implementations viz., Tibco or SAP XI etc.

b. It can also be extended to totally different technologies like J2EE implementations, .NET implementations etc as their Notification Mechanisms.

c. Available across the enterprise with a WSDL d. Addition or modification to any of the settings specific to a source id can be done

without any down time. e. Apart from e-mail the service can be extended to cater to other types of

Notification mechanisms. f. Analysis on the Persistent Data store can provide valuable information about the

exception trends in various interfaces – key indicator to judge the error trends. g. Archiving and retrieval of old notifications is simpler and centralized. h. The service is built on standards like XML for messages and WSDL/SOAP for the

Web Service Definition.



4 DETAILED DESIGN - NOTIFICATION SERVICE (VITRIA)

The detailed design of the Notification Service includes the design of the following components.

• Design of structure of the Notification Message. • Design of Metadata used in the Notification Service Project, like IDLs, java interfaces

etc. • Design of the Vitria Integration Model, Process Model that typically constitutes the

implementation for the Notifier/Persister module and the Configuration module. o Design of runtime distribution of components between Vitria projects.

• Database Design for the data table (table to persist the messages) and configuration table (table which holds the configuration settings for a particular source ID).

• Design of APIs to publish notification message to the notification Queue from other EAI components (Vitria projects).

4.1 DESIGN OF NOTIFICATION MESSAGE

The Notification message will be an XML string. All the EAI components that will use the Notification service should follow this message structure to publish their messages onto the Notification Queue; any other message type will be ignored.

The XML string should be sent as a string event to the queue by service users.

Following are fields in the XML:

• Source ID – uniquely identifies the origin of the message • Priority – gives the priority level at which the messages have to be sent • Message – description of the message to be sent • Trace – trace to be sent along with the message if any • Time stamp – Time at which the notification messages is sent to the Queue

Refer to the METADATA section for the DTD and sample XML.



4.2 DESIGN OF METADATA

List of the IDLs/ODLs/DTDs etc

S.No. Component Type Component Name Description File

1 DTD Notify.dtd

Defines the structure of notification message to be passed to the Notification Service

2 XML Notify.xml Sample XML

Table 3: List of Metadata

Notify.dtd

Notify.xml



4.3 DETAILED DESIGN OF VITRIA COMPONENTS

This section describes the detailed design for the Vitria components like the integration model, process models etc.

4.3.1 DESIGN OF INTEGRATION MODEL

Following Integration model houses the Persister, Timer, Notifier and Configuration module’s process models. The model has a Queue Source (Notification Queue) to which the notification messages will be published from other EAI components. It has a Email Target through which email messages are sent out. Apart from these there is also a HTTP source connector which will be used by the web forms to access the configuration module.

Figure 8: Integration Model for Notification Service

4.3.1.1 LOGICAL FLOW IN THE INTEGRATION MODEL

When ever a notification message arrives on the Notification Queue source it is taken up first by the ‘Persister’ model and then persisted into the persistent data store. If the message arrives with priority as “High” then in addition to persisting it in the database the persister module also publishes the same to the Priority Queue. This process runs indefinitely for the lifetime of the project and for all the notification messages on the queue.



The Notifier Module picks up the message from this channel and sends and instant mail for the corresponding message.

On the other hand the project will by itself publish a message to the Timer Queue once whenever it is started. This is done only to activate the timer in the Timer Module. The message is of type ‘notificationType.timerTriggerInterface.timerTriggerEvent’. This event will be processed only by the Timer Module. The Timer Module is configured to send a pulse (at the time interval specified in the incoming event) at every time interval to the Notifier Module. This triggers off the Notifier Module, which polls the database for qualified messages and does the rest of the processing.

The HTTP souce will provide services to a web based front end to add, modify and delete the runtime configurations for a specific source ID. This is out of scope for the current implementation.

Note: Exception handling for each component is done by coding separate exception handlers for each of the process models.

4.3.1.2 CONFIGURATION

Configuration settings in the Integration Model like the port types, exception handler classes etc.

Logical Model Component Purpose Input Port

Configuration Output Port

Configuration

Notification Queue Queue to which all the notification messages are published

- StringEvent

Timer queue This holds the timer event to trigger off the Timer Model and also to reset the timer

-

notificationType.timerTriggerInterface.timerTriggerEvent

Priority Channel

This channel serves as a mediator to send priority messages immediately to the receipent.

Notify.NotifyEvent

Notify.NotifyEvent

Persister Process model which persists the messages to the Persistent Medium

StringEvent

StringEvent, StringArrayEvent and RDBMS events

Timer Responsible for sending continuous pulses to the Notifier Model

notificationType.timerTriggerInterface.timerTriggerEvent

Notificationtype.NotificationEventInterface



Notifier

Process model which polls the configuration table and the data table to identify and send mails for valid messages

From Pri. Q: notify.NotifyEvent From Timer: notificationType.timerTriggerInterface.timerTriggerEvent

To Persistent DS: StringEvent, StringArrayEvent and RDBMS events To Email Server: emailConnectorEvents

Persistent DataStore Persistent Database where all configurations and messages are persisted


-

WFE for configuration Module

HTTP Source connector which serves configuration web pages

- HttpConnectorEvents.HttpOperations

Configuration Module

Process models which provides the features of add, delete and modify of the runtime configurations for each source id

HttpConnectorEvents.HttpOperations


Table 4: Integration Model Configurations



4.3.2 DESIGN OF PROCESS MODEL - PERSISTER

The persister Process model is responsible for processing all the notification events present on the queue. It fetches these events and then persists them in the database. The process model which does this is shown below.

Figure 9: Process Model for Persister

4.3.2.1 LOGICAL FLOW OF EVENTS IN THE MODEL - PERSISTER

Following is the logical flow of events in the model.

• The process model is activated on a string event.

• The string event which contains the XML string is then passed to the ‘notifyXMLMap’ transformer where it is transformed into a custom event.

• The custom event is then passed to the ‘Form Query’ state where the notification message is converted into an insert statement to be fired on the database.

• This string event is then passed to the ‘Insert into Persistent Store’ state where it is actually persisted into the database. If it is observed here that the message has come with a high priority then in addition to persisting the message it is published to the Priority channel also, from where the message is sent on a real-time basis to its receipients.



• Then on a default event control moves to the termination state.

4.3.2.2 PSEUDO CODE FOR THE STATES IN MODEL - PERSISTER

Following is the pseudo code for the various states in the Persister process model.

1. notifyXMLMap: Transformer to convert the XML to a custom event. 2. Form Query:

a. Get all event parameters b. Generate a dynamic query (insert) string out of the input parameters c. Create a string event with the dynamic query as data d. Set the string event in the context

3. Insert into Persistent Store: a. Get the outport connected to the Persistent Data store b. Request the outport with the ctx.getEvent() synchronously. (This gives us the

result of the current insert) c. EventBody [] result = (EventBody []) getOutPort().request(ctx.getEvent());

If (message_priority = high) GetOutPortToChannel().push(ctx.getEvent());

d. Check if the number of rows inserted is 1 or not. //Extract the value of the number of rows affected from the success event returned Object [] eventparams = results[0].getJavaParameters();

//Number of rows affected int resultCount = ((Integer)eventparams[0]).intValue();

e. If resultCount != 1 Log error message

f. Set the context event to the current event.

Note: LocalData in the context has to be used instead of class level variables

4.3.3 DESIGN OF PROCESS MODEL – TIMER

The timer model is primarily intended to just send pulses at regular intervals of time to the Notifier Model. This is achieved by placing a simple state with self transition.

Figure 10: Process Model for Notifier



4.3.3.1 LOGICAL FLOW OF EVENTS IN THE MODEL – TIMER

Following is the logical flow of events in the Timer Model.

• The model is triggered on a NotificationType.timerTriggerEvent and this triggers a timer event in the simple state.

• The model constantly fires a timer event at the specified time interval.

4.3.4 DESIGN OF PROCESS MODEL - NOTIFIER

The Notifier Process model is responsible for polling the configuration table and data table for qualified messages and subsequently sending mails. It is started by an event which is published to the queue when the project starts and from then the timer sends timer events and activates the model at specified time interval. The process model which does this is shown below.

Figure 11: Process Model for Notifier

4.3.4.1 LOGICAL FLOW OF EVENTS IN THE MODEL - NOTIFIER

Following is the logical flow of events in the model.

• The process model is activated on a custom event ‘notificationType.notificationEventInterface.queryEvent

• In the state “Check and Send Valid Messages in Data Store” the persistent store is checked for any valid messages to be sent, if there are any valid messages they are marked as “InProgress.”



• Then the Data Store is checked for any valid messages for the qualified sources, if there are any the errors are consolidated and a mail is sent per source with the errors as an excel.

• Once this is done smoothly the control now next state “Mark inprogress Messages to Processed.” Here all the messages for which mails are sent are marked as processed and the rest of the messages which where selected in the previous state and had failed in sending mails are marked as unprocessed.

• If there are no valid sources to be selected in the “Check and Send Valid Messages in Data Store” state the control moves to the “Check and Send Messages crossing the threshold” state. This state also invoked from the “Mark inprogress Messages to Processed” when there are messages qualified.

• In this state the Data Store is checked for messages exceeding the threshold numbers and subsequently mails are sent.

• Then on a default event control moves to the termination state.

4.3.4.2 PSEUDO CODE FOR THE STATES IN MODEL - NOTIFIER

Following is the pseudo code for the various states in the Persister process model.

1. Check and Send Valid Messages in Data Store: a. Check if there are any valid sources in the data store b. If yes then check for the messages for those sources c. And if there are messages consolidate the messages per source and send

mails. d. Send mails for the selected sources and then move to the “Mark inprogress

Messages to Processed” state e. If steps b or c return false move to state “Check and Send Messages crossing

the threshold” 2. Priority Notification: The state gets triggered on any event that comes on to the

priority channel. Following are the actions in the state. a. Extract the values from input event. b. Select the configuration details for the source id specified in the incoming

event. c. Form an email event with the available details and send it to the email server.

3. Check and Send Messages crossing the threshold: a. When this state is invoked check in the data store if there are any messages

that are crossing the threshold levels b. If yes then consolidate the messages for those sources and send mails. c. Else move to the termination state.

4. Mark InProgress Messages to Processed: a. Get the event parameters b. Get outport connected to the persistent store and execute the query. c. If success, proceed to the termination state else log message and proceed.

4.4 DATABASE DESIGN

This section describes the design for the database tables that are going to be used as part of the Notification Service. There will be two tables that are used, they are:

1. Master_Configuration_NS

2. Messages_NS



4.4.1 STRUCTURE OF CONFIGURATION TABLE

Name of the table: Master_Configuration_NS

S.No. Column Name Data Type Defaults/Constraints/commen

ts

1. Source Varchar(100) Primary Key/ Name of the Vitria project or the project group which is publishing this message

2. Frequency Number Frequency at which messages have to be sent, in minutes

3. Threshold Number Threshold messages at which an overdrive mail has to be sent

4. Mail_from Varchar(100) From address for the mail to be sent. Constraint has to be a valid mail id.

5. Mail_to Varchar(100)

List of people to whom mail has to be sent. Give the complete mail id of each recipient separated by commas

6. Mail_cc Varchar(100)

List of people to whom mail has to be copied. Give the complete mail id of each recipient separated by commas

7. Subject Varchar(100) Subject of the mails coming from this source id.

8. Last_processed Datetime Last time when a particular source id has been processed

Table 5: Configuration Table Structure



4.4.2 STRUCTURE OF DATA TABLE

Name of the table: Messages_NS

S.No. Column Name Data Type Defaults/Constraints/commen

ts

1. Source Varchar(100) Foreign Key to Master_Configuration_NS table’s source

2. Priority Varchar(10) Predefined: High/Low

3. Message Varchar(400) Holds the message that has to be sent in the email

4. Trace Varchar(4000) Place holder for the stack trace of the exception if required

5. Timestamp Datetime Time stamp at which the message was sent to the notification queue

6. Status Number(1)

Gives the current status of the record

2: To be processed 1: In Process 0: Processed

7. Delivery_date Varchar2(25)

8. Batch_id Number(10) A number that uniquely identifies the messages processed during one cycle.

Table 6: Data Table Structure

Primary Key



4.5 DESIGN OF APIS TO SEND MESSAGES TO THE NOTIFICATION QUEUE

It is proposed to modify the existing eRTISUtilities.java file to have an additional method which publishes the Notification messages onto the Notification Queue.

The following will be the design of the method:

Input Parameters:

1. Source_id 2. Priority 3. Message 4. Trace 5. Time Stamp (this can be sent only in the xml and can be generated by a common

method)

Return Parameters:

Success_flag, the method returns a string with value 0 if the messages is published to the queue else the error trace is sent back.



5 REFERENCES

• Vitria BusinessWare 4.2.1 Documentation.

Documents

Notification Framework v1.0 - Techhosteddocs.ittoolbox.com/Generic_Notification_Framework...Generic Notification Framework Ver 1.0 Page 1 of 27 GENERIC NOTIFICATION FRAMEWORK FOR EAI