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
Generic Notification Framework
Ver 1.0 Page 2 of 27
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
Generic Notification Framework
Ver 1.0 Page 3 of 27
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
Generic Notification Framework
Ver 1.0 Page 4 of 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.
Generic Notification Framework
Ver 1.0 Page 5 of 27
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.
Generic Notification Framework
Ver 1.0 Page 6 of 27
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
Generic Notification Framework
Ver 1.0 Page 7 of 27
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.
Generic Notification Framework
Ver 1.0 Page 8 of 27
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
Generic Notification Framework
Ver 1.0 Page 9 of 27
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
Generic Notification Framework
Ver 1.0 Page 10 of 27
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
Runtime Message Flow:-
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.
Generic Notification Framework
Ver 1.0 Page 11 of 27
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
Runtime Message Flow:-
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.
Generic Notification Framework
Ver 1.0 Page 12 of 27
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.
Generic Notification Framework
Ver 1.0 Page 13 of 27
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.
Generic Notification Framework
Ver 1.0 Page 14 of 27
• 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.
Generic Notification Framework
Ver 1.0 Page 15 of 27
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.
Generic Notification Framework
Ver 1.0 Page 16 of 27
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
Generic Notification Framework
Ver 1.0 Page 17 of 27
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.
Generic Notification Framework
Ver 1.0 Page 18 of 27
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
Generic Notification Framework
Ver 1.0 Page 19 of 27
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
StringEvent, StringArrayEvent and RDBMS events
-
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
StringEvent, StringArrayEvent and RDBMS events
Table 4: Integration Model Configurations
Generic Notification Framework
Ver 1.0 Page 20 of 27
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.
Generic Notification Framework
Ver 1.0 Page 21 of 27
• 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
Generic Notification Framework
Ver 1.0 Page 22 of 27
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.”
Generic Notification Framework
Ver 1.0 Page 23 of 27
• 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
Generic Notification Framework
Ver 1.0 Page 24 of 27
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
Generic Notification Framework
Ver 1.0 Page 25 of 27
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
Generic Notification Framework
Ver 1.0 Page 26 of 27
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.
Generic Notification Framework
Ver 1.0 Page 27 of 27
5 REFERENCES
• Vitria BusinessWare 4.2.1 Documentation.