WO2016108779A1

WO2016108779A1 - An event notification system

Info

Publication number: WO2016108779A1
Application number: PCT/TR2015/000369
Authority: WO
Inventors: Ersan OZTURK; Okan CELEP
Original assignee: Turkcell Teknoloji Arastirma Ve Gelistirme AS
Current assignee: Turkcell Teknoloji Arastirma Ve Gelistirme AS
Priority date: 2014-12-30
Filing date: 2015-12-23
Publication date: 2016-07-07
Anticipated expiration: 2017-06-30

Abstract

The present invention relates to an event notification system (1) which enables to notify events that are received from external systems and occur in internal systems to all collection system by means of a common structure with parametric and easy definitions, in collection systems wherein a plurality of systems such as bank gateway, payment distribution, administrative and legal proceedings and instalment structure run together. The inventive event notification system (1) enabling to notify events that are received from external systems and occur in internal systems to target services located in collection systems, by a common structure with parametric and easy definitions comprises: notification gathering unit (2) wherein events are gathered; at least one event unit (3) where the notifications that are received from the gathering unit (2) are transmitted, the transmitted notifications are processed and classified in event-type tables in order to be transmitted in a pool, in addition services whereto notification will be made are kept; at least one interface (4) wherein events that are processed by the event unit (3) and will be notified are kept in the queue structure; and at least one notification receiving unit (5) which receives events and provides them to target services.

Description

DESCRIPTION

AN EVENT NOTIFICATION SYSTEM Technical Field

The present invention relates to an event notification system which enables to notify events that are received from external systems and occur in internal systems to all collection system by means of a common structure with parametric and easy definitions, in collection systems wherein a plurality of systems such as bank gateway, payment distribution, administrative and legal proceedings and instalment structure run together.

Background of the Invention

Collection consists of systems such as bank gateway, instalment, administrative proceedings, legal proceedings in itself. Each system brings about integration with other internal and external systems such as CRM, billing, bank gateway separately in order to receive notifications such as changes of contract, changes of customer information, payments. Therefore, new development cost is required for each new system and event. In payment systems, transferring events to systems in correct order is a critical issue (for example, paying the same bill, payment cancellation, making payment). Data inconsistencies emerge as a natural consequence of the existing condition due to the fact that the same event is notified to different systems in wrong order, error is received in some of them and there is no retry features in some of them. The fact that integration points exist in different applications leads to maintenance and control costs, problem detections take a long time because logs are distributed or incomplete. All target systems must stand by at the same time when event notification systems - which are used in the state of the art - distribute their own notifications synchronously. And this increases probability of receiving error on all transactions. In addition, if different databases are in question in transactions proceeding on database, use of dblink is required. And this both causes unnecessary network traffic and increases probability of receiving error because of complexity of dblinks. Also, the fact that systems to make notification support different technologies force source systems to support different integrations.

Today, there are two ways for events to appear up-to-date in different systems. One of them is that target systems read the major information from the source system and the other is that the event is distributed to all related systems. Reading the information from the source system can be usually very costly as performance.

The United States patent document no. US20090204977 discloses an invention which enables to make event notification and manage notifications between disparate systems. The said invention is based on to capture notification from a plurality of external systems or devices, to process notifications, to deliver them to other internal or external systems. In this way, the case of providing the necessary communication between the event-generating device and the system and the notification-receiving system or systems is carried out. In the said patent document, the invention is established between hardware systems such as electrical switches, buttons and hospital paging systems. In addition, communication standards of the invention are based on PC hardware and IP network infrastructure.

Summary of the Invention An objective of the present invention is to realize an event notification system which comprises all kinds of notifications such as changes of contract, changes of customer information, changes of payment and bill and enables to transmit events occurring in external and internal systems to other units by a common structure. Another objective of the present invention is to realize an event notification system whereby event notification from a single point, logging in a single point, standard JMS (Java Message Service) infrastructure and detailed configuration option, easy new system and event definitions, scalability, optimization with thread number specific to systems, retry mechanism specific to systems, filtering and order guarantee in transactions are ensured in notification of events to collection applications.

Detailed Description of the Invention

The "Event Notification System" realized to fulfil the objectives of the present invention is shown in the figure attached, in which:

Figure 1 is a schematic block diagram of the inventive event notification system.

The components illustrated in the figure are individually numbered, where the numbers refer to the following:

1. System

2. Notification gathering unit

3. Event unit

4. Interface

5. Receiving unit

The inventive event notification system (1) enabling to notify events that are received from external systems and occur in internal systems to target services located in collection systems, by a common structure with parametric and easy definitions comprises:

- notification gathering unit (2) wherein events are gathered;

- at least one event unit (3) where the notifications that are received from the gathering unit (2) are transmitted, the transmitted notifications are processed and classified in event-type tables in order to be transmitted in a pool, in addition services whereto notification will be made are kept;

- at least one interface (4) wherein events that are processed by the event unit (3) and will be notified are kept in the queue structure; and at least one notification receiving unit (5) which receives events and provides them to target services.

In a preferred embodiment of the system (1), the notification gathering unit (2) makes notifications by means of web, EJB (Enterprise JavaBeans), Rest API or a database service. The events transmitted by the notification gathering unit (2) are stored in a pool as table in the event unit (3) and added to the queue of the interface (4) of the related notification receiving unit (5) upon being read from the table. In a preferred embodiment of the invention, the event unit (3) keeps the information of whichever units (5) the notifications to be transmitted to will be transmitted and the event types in the event-type table. Thus, the event unit (3) transmits the events to the queue of the interface (4) of that unit whichever notification receiving unit (5) they will be transmitted to. In a preferred embodiment, the event unit (3) generates a new entry in the event of a new event notification whereas the event unit (3) updates the list of the notification receiving unit (5) in the event that the notification is transmitted to a new notification receiving unit (5).

In a preferred embodiment of the system (1), the event unit (3) makes notifications to the interface (4) asynchronously. Thereby, it is continued to receive the event notifications from the notification gathering unit (2) in the event that notification is not made to the notification receiving units (5). In addition, since the other transactions reaching the notification receiving units (5) are not blocked, in the event that there is problem in one of the target services only the target notification receiving unit (5) is affected. Due to the fact that notifications are made asynchronously, the load occurring in the system (1) is eliminated upon the connection between the notification receiving units (5) is broken.

In the inventive event notification system (1), the event unit (3) keeps information of the notification receiving units (5), connection types, access information and service information to be called by the receiving unit (5) in the table of target notification receiving unit. In a preferred embodiment, the event unit (3) creates a new record in the target notification receiving table in the event that it is desired to make notification to a new notification receiving unit (5).

In a preferred embodiment, the event unit (3) carries out connections of the notification receiving units (5) in order to facilitate the notification gathering units' (2) work and enable them to focus in cases where the notification receiving units (5) support different technologies.

In a preferred embodiment of the invention, the event unit (3) makes optimization by the number of thread specific to the target notification receiving units (5). The event unit (3) overcomes potential overloads by periodically increasing/decreasing number of thread to be transmitted to the notification receiving units (5). The event unit (3) manages on a display parametrically how many thread will be used in the queue of the interface (4) for each notification receiving unit (5). Thereby, service interruptions are not experienced in machines belonging to the services where the infrastructure is installed. In addition, management of all machines in the set can be performed from a single display.

In a preferred embodiment, the event unit (3) has the feature of filtering events to be transmitted to the target service depending on the possibility that the service does not request all events. The event unit (3) dynamically defines which filter will operate according to which feature of the event. Thereby, the system (1) sends only required events to each target service in an optimized way. For example, payment can be filtered according to sub-detail types of transaction type, bill type and payment type.

In a preferred embodiment of the system (1), the event unit (3) has the feature of switching on/off transmission of the notifications to the notification receiving units (5). The event unit (3) switches off the notification transmission in cases where the units (5) to be notified undergo maintenance or want to stop notifications in certain periods of time. Switching on/off feature of the event unit (3) is managed over a display. The event unit (3) keeps the events occurring at that moment waiting in the interface (4) to be notified later upon it switches off notification. It is started to transmit the waiting notifications in the event that notification to the related is switched on again. The event unit (3) enables to make easy new system and event definitions by detailed configuration option by allowing to make definitions over a display. In addition to this, the fact that number of thread can be defined in the event unit (3) and number of server can be increased ensures measurability. The event unit (3) uses JMS in order to carry out measuring also specific to persistent store wherein data are kept. The persistent store is not a storage center, machine of each service has its own persistent store.

In a preferred embodiment of the invention, the event unit (3) provides order guarantee in transactions of the notifications transmitted to the services. Upon the events reach the distribution queues, distribution transaction is carried out by a single master server physically in each node of a set. Change of notification order may be in question when a plurality of machines are included. The persistent store used at this point is located in these master servers. Each machine has its own persistent store. The event unit (3) always directs the events related to the same customer/bill to the same server in order to provide order guarantee during transactions.

The event unit (3) determines how many parallel queues that will perform distribution transaction configurationally exist. Notifications reaching the distribution are examined one by one and then transmitted to the related queues. The event unit (3) provides guarantee of transaction order by making control of event that are received before distribution and not processed. The event unit (3) allocates a certain validity period for each event in order that the events do not block the transactions received after them. The validity period can be set according to each event type. In a preferred embodiment, transactions exceeding the validity period are not subjected to order control even if they are error-receiving transactions. In a preferred embodiment of the invention, the event unit (3) creates the queues in the interface (4) in JMS (Java Message Service) standard. Each JMS server has its own persistent store. The event unit (3) also support defining a different persistent store for different event types. The advantage thereof is that if expansions occur in persistent stores, it defines slowing-down here only by the related event types.

The event unit (3) has retry mechanism which is specific to the notification receiving units (5) where it transmits the notifications. The event unit (3) activates the retry mechanism in the event that the interfaces (4) cannot make notification successfully. Time and number of retry is defined parametrically in a different way for each service in the event unit (3). For example, definition can be made in the event unit (3) such that try will be carried out for 5 times at intervals of 10 minutes. After the error-receiving records are waited in in the event unit (3) according to the specified configuration, they are again accessible for reading threads and notified to the related target services.

The event unit (3) drops these records to alarm in cases where the number of retry is excessed for each event. If the event unit (3) does not state the retry number on thereof, it will be continued to try to transmit the notification forever. In a preferred embodiment, some events may disappear and may not be tried again if they are tried and fail. This choice is made in the event unit (3).

The event unit (3) transmits the alarmed events only by operation intervention again. The said transaction is carried out from JMS queues or by means of displays. When the events in the alarm found out due to the fact that it is possible to make inquiry according to all features of the event are carried to the queues of the interfaces (4), the flow restarts. In other words, trials start over according to the retry adjustments made from the event unit (3). In a preferred embodiment, the event unit (3) has the feature of log in a single point. The event unit (3) carries successful records to the achieve table automatically while keeping the descriptions related to the error-receiving records in the log table. The error-receiving records can be observed in the error table. Observation of records is possible by means of display and alarm structure.

In a preferred embodiment, prioritization is made according to the significance level in transmission of event in the event that there is system density. The event unit (3) decides the prioritization transaction according to the transaction priority. The events received by the event unit (3) are transferred to the related and important threads. The notification receiving units (5) are defined in the event unit (3) according to different connection types such as database access, web service, EJB, rest API, JMS, Oracle Advance Queue. In addition to this, different databases such as Oracle, MsSQL, MySQL, NoSQL can be supported by database access wherein the notification receiving unit (5) can be used. The notification receiving unit (5) has an infrastructure that will support different messaging methods and flexibility that may extend.

The notification receiving units (5) receive feedback to the event unit (3) on the services that they provide. These feedbacks may be in the form of successful, unsuccessful and denied. It is understood that the event is transmitted to the target service by the notification receiving unit (5) when feedback is made as successful, it is understood that the event is not notified and it will not be sent again when feedback is made as denied, it is understood that the event is not transmitted to the target service and it will be tried again when feedback is made as unsuccessful.

In a preferred embodiment of the invention, the notification receiving units (5) prepare the interface parameters in the event unit (3) according to the pre-defined services thereof according to the type of event notification to be received by them. The notification receiving units (5) develop which service will be provided by them according to the type of event to be received by them and subscribe to the notification type.

Claims

1. An event notification system (1) enabling to notify events that are received from external systems and occur in internal systems to target services located in collection systems, by a common structure with parametric and easy definitions comprising:

- notification gathering unit (2) wherein events are gathered;

characterized by:

at least one event unit (3) where the notifications that are received from the gathering unit (2) are transmitted, the transmitted notifications are processed and classified in event-type tables in order to be transmitted in a pool, in addition services whereto notification will be made are kept;

- at least one interface (4) wherein events that are processed by the event unit (3) and will be notified are kept in the queue structure; and

- at least one notification receiving unit (5) which receives events and provides them to target services.

2. An event notification system (1) according to Claim 1, characterized by the notification gathering unit (2) which makes notifications by means of web, EJB (Enterprise JavaBeans), Rest API or a database service.

3. An event notification system (1) according to Claim 1 or 2, characterized by the event unit (3) wherein the events transmitted by the notification gathering unit (2) are stored in a pool as table and added to the queue of the interface (4) of the related notification receiving unit (5) upon being read from the table.

4. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which keeps the information of whichever units (5) the notifications to be transmitted will be transmitted to and the event types in the event-type table.

5. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which transmits the events to the queue of the interface (4) of that unit whichever notification receiving unit (5) they will be transmitted to.

6. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which generates a new entry in the event of a new event notification whereas updates the list of the notification receiving unit (5) in the event that the notification is transmitted to a new notification receiving unit (5).

7. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which makes notifications to the interface (4) asynchronously.

8. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which keeps information of the notification receiving units (5), connection types, access information and service information to be called by the receiving unit (5) in the table of target notification receiving unit.

9. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which creates a new record in the target notification receiving table in the event that it is desired to make notification to a new notification receiving unit (5).

10. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which carries out connections of the notification receiving units (5) in order to facilitate the notification gathering units' (2) work and enable them to focus in cases where the notification receiving units (5) support different technologies.

11. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which makes optimization by the number of thread specific to the target notification receiving units (5).

12. An event notification system (1) according to Claim 11, characterized by the event unit (3) which overcomes potential overloads by periodically increasing/decreasing number of thread to be transmitted to the notification receiving units (5).

13. An event notification system (1) according to Claim 1 1 or 12, characterized by the event unit (3) which manages on a display parametrically how many thread will be used in the queue of the interface (4) for each notification receiving unit (5).

14. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which filters events to be transmitted to the target service depending on the possibility that the service does not request all events.

15. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) wherein it is defined which filter will operate according to which feature of the event.

16. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which has the feature of switching on/off transmission of the notifications to the notification receiving units (5).

17. An event notification system (1) according to Claim 16, characterized by the event unit (3) which keeps the events occurring at that moment waiting in the interface (4) to be notified later upon it switches off notification.

18. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which enables to make easy new system and event definitions by detailed configuration option by allowing to make definitions over a display.

19. An event notification system (1) according to Claim 18, characterized by the event unit (3) which ensures measurability due to the fact that number of thread can be defined in the event unit (3) and number of server can be increased.

20. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which provides order guarantee in transactions of notifications transmitted to the services.

21. An event notification system (1) according to Claim 20, characterized by the event unit (3) which always directs the events related to the same customer/bill to the same server in order to provide order guarantee during transactions.

22. An event notification system (1) according to Claim 21 or 22, characterized by the event unit (3) which determines how many parallel queues that will perform distribution transaction configurationally exist.

23. An event notification system (1) according to any of Claim 21 to 23, characterized by the event unit (3) which allocates a certain validity period for each event in order that the events do not block the transactions received after them.

24. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which creates the queues in the interface (4) in

JMS (Java Message Service) standard.

25. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which has retry mechanism that is specific to the notification receiving units (5) where it transmits the notifications.

26. An event notification system (1) according to Claim 25, characterized by the event unit (3) which activates the retry mechanism in the event that the interfaces (4) cannot make notification successfully.

27. An event notification system (1) according to Claim 25 or 26, characterized by the event unit (3) wherein time and number of retry is defined parametrically in a different way for each service.

28. An event notification system (1) according to any of Claim 25 to 27, characterized by the event unit (3) which drops these records to alarm in cases where the number of retry is excessed for each event.

29. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which has the feature of log in a single point.

30. An event notification system (1) according to Claim 29, characterized by the event unit (3) which carries successful records to the achieve table automatically while keeping the descriptions related to the error-receiving records in the log table.

31. An event notification system (1) according to any of the preceding claims, characterized by the event unit (3) which makes prioritization according to the significance level in transmission of event in the event that there is system density.

32. An event notification system (1) according to Claim 31, characterized by the event unit (3) which decides the prioritization transaction according to the transaction priority.

33. An event notification system (1) according to any of the preceding claims, characterized by the notification receiving units (5) which are defined in the event unit (3) according to different connection types such as database access, web service, EJB, rest API, JMS, Oracle Advance Queue.

34. An event notification system (1) according to any of the preceding claims, characterized by the notification receiving units (5) which receive feedback to the event unit (3) on the services that they provide.

35. An event notification system (1) according to any of the preceding claims, characterized by the notification receiving units (5) which prepare the interface parameters in the event unit (3) according to the pre-defined services thereof according to the type of event notification to be received by them.