WO2003044683A1 - Traitement et distribution de donnees selon des regles specifiees - Google Patents

Traitement et distribution de donnees selon des regles specifiees Download PDF

Info

Publication number
WO2003044683A1
WO2003044683A1 PCT/US2002/034979 US0234979W WO03044683A1 WO 2003044683 A1 WO2003044683 A1 WO 2003044683A1 US 0234979 W US0234979 W US 0234979W WO 03044683 A1 WO03044683 A1 WO 03044683A1
Authority
WO
WIPO (PCT)
Prior art keywords
source
data
event
destination
data describing
Prior art date
Application number
PCT/US2002/034979
Other languages
English (en)
Inventor
Jay Borenstein
Daniel Harsell
Tino Wuensche
Thaddeus Jampol
Original Assignee
Tsunami Software, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tsunami Software, Inc. filed Critical Tsunami Software, Inc.
Priority to AU2002365998A priority Critical patent/AU2002365998A1/en
Publication of WO2003044683A1 publication Critical patent/WO2003044683A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • This invention pertains in general to data communications and processing and in particular to controlling the gathering, processing, and delivering of data from source systems to a broad range of destination systems.
  • users within these organizations interact with the various sets of data in the computer systems in different ways. For example, users may access one set of data through custom software applications, access another set of data via email or web browsers, and access a third set of data through direct database queries.
  • ERP enterprise resource planning
  • a third solution to sharing data is adding an additional application layer as a "broker" of information between the various computer systems.
  • Programmers design application programs executing on the computer systems to interact with the broker rather than the different computer systems when sharing data.
  • the broker creates an avenue for accessing and sharing information among different systems.
  • the organizations are forced to modify or rewrite the application programs. Performing this task is often time consuming and prohibitively expensive.
  • the above need is met by a communication facilitating engine that provides communication and data processing capabilities in order to support data sharing, yet does not require any substantial modifications to the systems generating and/or receiving the data.
  • the engine operates in a computing environment having one or more source systems and one or more destination systems.
  • the source systems generate source events.
  • One type of source event describes a change in a condition of data in a repository at a source system.
  • Another type of source event serves as an acquisition of data from the source system.
  • the source system includes database triggers, a database table, and an agent module that monitors the database for changes to data.
  • the agent communicates a source event to the engine for subsequent processing by using the extensible markup language (XML) to describe the changed data.
  • the engine includes a polling client for polling the source system to identify changes to data and generate the source events in response thereto.
  • a user preferably uses a graphical user interface (GUI) provided by a user console to describe rules for processing the source events.
  • GUI graphical user interface
  • Rules are comprised of instructions for gathering data, processing data, and disseminating data.
  • the gathering aspect of the rules specifies where and in what circumstances source events are gathered in order to initiate a communication process.
  • the processing aspect of the rules can perform a wide variety of operations on the data in the source event, and includes a facility for applying pre-effect and effect processing on the data to dynamically generate one or more types of destination events.
  • Types of processing operations supported by one embodiment of the present invention include conditional logic, data incorporation, data transformation, and user-defined functions.
  • the dissemination aspect of the rules specifies where, in what format, and in what circumstances information is to be communicated to one or more destination systems. Possible delivery actions include, but are not limited to, a database operation, an email, and an XML broadcast.
  • a database in the engine stores the rules.
  • the engine also includes a connection manager for receiving the source events from the source systems. Upon receiving an XML packet created and communicated in response to a source event, the connection manager retrieves the rules pertaining to the source event from the database and takes actions specified in the rules to generate an intermediate data representation from the source event data.
  • the engine preferably has multiple queues corresponding to the types of effects being processed and/or the locations of the destination systems.
  • connection engine identifies the queue or queues corresponding to the effect processing specified by the rules associated with the source event and generates the intermediate data representation accordingly.
  • Each queue preferably has an associated queue manager that reads the data from the queue and performs the specified processing, thereby generating any number of destination events and delivering data representative of the destination events to the destination system(s).
  • FIG. 1 is a high-level block diagram illustrating a typical computing environment according to an embodiment of the present invention
  • FIG. 2 is a high-level block diagram illustrating a more detailed view of the interaction between the source systems and the engine in the computing environment;
  • FIG. 3 is a high-level block diagram illustrating a more detailed view of the engine in relation to the other entities illustrated in FIG. 1 ;
  • FIG. 4 is a block diagram graphically illustrating the rule-based processing performed by the modules of the engine illustrated in FIG. 3;
  • FIG. 5 is a flowchart illustrating the steps performed by the engine to facilitate communications according to a preferred embodiment of the present invention
  • FIG. 6 is a flowchart illustrating the steps performed by a user to establish a rule for the engine
  • FIG. 7 illustrates a graphical user interface (GUI) for enabling the user to select a source system and specify the source event for a rule;
  • GUI graphical user interface
  • FIG. 8 illustrates a GUI for enabling the user to specify the action type of an effect
  • FIG. 9 illustrates a GUI for enabling the user to specify what information should be communicated from the source system to the destination system, and what processing should be performed on that information as part of the communication;
  • FIG. 10 illustrates a GUI for enabling the user to specify pre-effect processing for the specified rules
  • FIG. 11 illustrates a GUI for specifying a form of pre-effect processing where a Boolean pre-effect assertion is evaluated before processing specified rules
  • FIG. 12 illustrates a GUI for specifying another form of pre-effect processing where information is solicited from another source before processing specified rules.
  • FIG. 1 is a high-level block diagram illustrating a typical computing environment 100 according to an embodiment of the present invention.
  • FIG. 1 illustrates a communication facilitating engine (the "engine") 110 in communication with four data source computer systems 112 (hereinafter referred to as “source systems”) via communications links 114.
  • the engine 110 is also in communication with two data destination systems 116 (“destination systems”) via communications links 118.
  • source systems data source computer systems
  • destination systems data destination systems
  • FIG. 1 four source 112 and two destination 116 systems are shown.
  • the engine 110 may be in communication with any practical number of such systems. For purposes of convenience and clarity, this description frequently refers to a single source 112 and/or destination 116 system.
  • These single systems 112, 116 are merely representative of the one or more systems in communication with the engine 110.
  • the engine 110 is also in communication with a user console 120 via another communications link 122.
  • This user console 120 is representative of the one or more user consoles that maybe in communication with the engine 110.
  • the environment 100 of FIG. 1 is representative of a typical computing environment at an organization such as a company or a government agency.
  • the environment has multiple disparate computer systems and multiple computer users. Many of the computer systems and data representations utilized by the computer systems are different because the computer systems were purchased at different times, from different vendors, etc. Nevertheless, the organization has a desire to enable the computer systems to communicate information to and from one another in order to improve data accuracy and business efficiency, and to reduce risks, costs, etc.
  • the source systems 112 are sources from which the engine 110 receives and/or can obtain data.
  • the source systems 112 are conventional computer systems adapted to act as data sources and/or repositories.
  • the computer systems maybe, for example, personal computer systems, server systems, and/or mainframe systems.
  • one or more of the source systems 112 can be a device lacking typical computer functionality.
  • an electronic thermometer or other type of sensor can act as a source system.
  • the source system 112 can act as data source and or repository.
  • the source system 112 can execute a relational database such as Oracle9i from Oracle Corp, execute application programs that maintain data in one or more proprietary formats, execute a mainframe database, and or hold data in a flat-file.
  • the source system 112 can also be a computer system having an interface through which data on the system can be accessed. Such interfaces include those allowing access via the hypertext transport protocol (HTTP), the file transfer protocol (FTP), the post office protocol (POP), and a command shell.
  • HTTP hypertext transport protocol
  • FTP file transfer protocol
  • POP post office protocol
  • the destination systems 116 are adapted to receive data.
  • the destination systems 116 may store the received data, act on the received data, and/or ignore the data.
  • a destination system 116 is a conventional computer system similar to a source system 112 and can execute a relational database, proprietary application, mainframe database, hold a flat data file, etc.
  • a destination system 116 is a device lacking all or some functionality typically associated with a computer system, such as a cellular telephone, a pager, a fax machine, or another device adapted to receive data.
  • source 112 and destination systems 116 there are no physical distinctions between the source 112 and destination systems 116.
  • a system can function as both a source and a destination in the same environment 100, with the only distinction being the direction of the data flow in a particular transaction. Indeed, it is expected that many of the systems will simultaneously function as both sources and destinations.
  • multiple source 112 and/or destination systems 116 can reside on a single computer system. For example, if multiple databases reside on a single computer system, each database can be treated as a distinct source system 112. Likewise, a single database that spans multiple computer systems can be treated as a single source system 112.
  • the communications links 114, 118 coupling the source 112 and destination 116 systems to the engine 110 are preferably conventional communications links.
  • the links 114, 118 may include private links, such as dedicated Tl lines, local or wide area networks, and/or serial connections.
  • the links 114, 118 also may include public links, such as public telephone lines, television distribution systems, or shared Internet connections.
  • the links 114, 118 may utilize conventional communications technologies such as analog modems, digital subscriber line modems, cable modems, Ethernet, etc.
  • data are transmitted over the communications links 114, 118 via conventional communications protocols such as the HTTP, the FTP, and the transmission control protocol Internet protocol (TCP/IP).
  • the data maybe encoded in the extensible markup language (XML), hypertext markup language (HTML), or any other suitable representation.
  • XML extensible markup language
  • HTML hypertext markup language
  • SSL secure sockets layer
  • the engine 110 is preferably a conventional computer system adapted to execute computer program modules providing communication facilitating functionality.
  • module refers to computer program logic and/or any hardware or circuitry utilized to provide the functionality attributed to the module.
  • a module can be implemented in hardware, firmware, and/or software.
  • the engine computer system executes the Linux operating system.
  • the engine computer system executes one of the WINDOWS operating systems from MICROSOFT CORPORATION.
  • the engine 110 interacts with the source systems 112 to detect source events and receive data describing the source events.
  • a source event is an event that affects data stored and/or provided by a source system 112. For example, a source event occurs when data in a field in a database at a source system 112 is added, deleted, or modified.
  • the engine 110 performs pre-effect and effect processing on the data describing the source events according to a defined set of rules.
  • the rules transform the data from the format of the source system 112 into the formats of one or more destination systems 116. For example, if a source event describes modified data in a field of a first type of database, the engine 110 processes the data describing the source event into a format suitable for modifying a corresponding field in a second type of database.
  • the processed data describing the source events are referred to herein as "destination events" or as "data describing the destination events.”
  • the engine 110 performs "actions" on the destination events according to the defined set of rules.
  • the actions describe how to deliver the destination events to the destination systems 116.
  • a destination event can be delivered to a destination system by making a Structured Query Language (SQL) call, sending an email, submitting information via an HTML form, sending an XML broadcast, etc.
  • SQL Structured Query Language
  • the engine 110 sends data describing destination events to the destination systems 116 in response to the source events generated by the source systems 112 and allows multiple disparate systems to share data effectively.
  • a user uses the console 120 to communicate with and control the engine 110.
  • the console 120 is a conventional computer system executing computer program modules for interfacing with the engine 110.
  • the console 120 executes specialized software providing a graphical user interface (GUI) for conveniently controlling the engine 110.
  • GUI graphical user interface
  • the console executes web browsing software for operating as a client that accesses the engine 110 via a network.
  • the communications link 122 coupling the console 120 to the engine is preferably a conventional network connection as described above with respect to links 114 and 118. These embodiments are advantageous because they allow the console 120 to be located anywhere on the network.
  • the console 120 is directly coupled to the computer system 110 executing the engine.
  • FIG. 2 is a high-level block diagram illustrating a more detailed view of the interaction between source systems 210 and the engine 110.
  • FIG. 2 illustrates three source systems 210A, 210B, 210C for generating source events.
  • the first type of source event a change in a condition of data, occurs when data at a data repository maintained by a source system 210 are modified.
  • a data repository maintained by a source system 210
  • modifications to the data repository take the form of insert, update, and delete operations. Each of these operations is a potential source event.
  • the second type of source event a data notification, occurs when data are proactively generated from a source system 210 either by that source system or by an outside system or process. For example, a source system 210 that occasionally sends messages and/or is contacted by a polling server generates data notification source events.
  • source system 210A illustrates an example of a system for generating the first type of source event.
  • the source system 212A includes a data repository 212 A.
  • the data repository 212A is part of a database system supporting trigger functionality through the SQL or another technique.
  • a database "trigger" is a set of statements that are executed when a specific operation, such as changing data in a table, occurs.
  • Source system 210A includes a trigger module 214 containing one or more triggers that are executed when specific data in the repository 212A are modified (i.e., inserted, updated, or deleted).
  • the triggers in the trigger module 214 preferably capture the modified, inserted, or deleted data of interest and, in one embodiment, store the data in a separate table 216 on the source system 210A.
  • the triggers also process the data, if necessary, from a format utilized by the repository 212A into a format utilized by the engine 110.
  • the triggers also capture data representative of deletions.
  • An agent module 218 A at the source system 210A monitors the table 216 for source events.
  • the agent module 218 A is a background process or, on MICROSOFT WINDOWS-based systems, a Windows service, executing on the source system 210A.
  • the agent module 218A detects a new source event in the table, it retrieves the modified data from the table and sends it to the engine 110.
  • the agent module 218A preferably formats the data as an XML message using pre-defined tags that are understood by the engine 110. Then, the agent module 218A establishes a TCP/IP connection on a predefined port with the engine 110 and sends the XML message.
  • source system 21 OB illustrates an example of a system for generating the first type of source event, a change in a condition of data, where the data repository 212B is a hierarchical or flat file or another type of repository that does not necessarily support triggers.
  • a polling server 220 preferably polls the data repository 212B to detect changes to the data.
  • the polling server 220 detects data changes, it passes data describing the change to an agent module 218B in the source system 21 OB.
  • the agent module 218B formats the data as an XML message and sends it to the engine 110.
  • the polling server 220 and agent module 218B are both preferably background processes, or Windows services, executing on the source system 210B .
  • An advantage of utilizing the triggers 214, polling server 220, and agent modules 218 in the source data systems 210 described above is that the operations of these modules are transparent to the source systems.
  • the tasks performed by these modules are relatively lightweight, meaning that the modules can execute on the systems 210 without adding significant processing overhead.
  • the modules do not affect the integrity of the data repositories 212, even if the communications links 114 between the systems and the engine 110 are severed.
  • the application and presentation layers of the systems are unchanged, so how users interact with the systems remains the same.
  • source system 210C illustrates an example of a system for generating the second type of source event, a data notification.
  • the data repository 212C is preferably representative of data that can be accessed through an interface such as telnet, FTP, HTTP, LDAP, POP, secure shell (SSH), and/or SQL or another interface.
  • a polling client 222 in the engine 110 initiates the data notification source event by polling the data repository 212C via the appropriate interface.
  • the polling client 222 preferably initiates an FTP connection with the source system 210C and executes the appropriate commands to access the data in the repository 212C.
  • the source system 210C sees the activity of the polling client 222 merely as a client requesting information via an established interface.
  • the polling client 222 formats the data as an XML packet and provides the packet to the other modules in the engine 110.
  • a preferred embodiment of the present invention provides data to the engine 110 in the XML format because this format is efficient and flexible.
  • the outermost "req” tag identifies the source event being communicated to the engine 110.
  • the "db_action” tag identifies the rule ID of the engine rule (discussed in more detail below) for which the data are being communicated.
  • the “update” tag identifies the operation type.
  • the "pre” and “post” tags respectively identify blocks of data prior to and after the database operation.
  • each "col” element identifies a specific table column having data contained between the opening and closing tags.
  • the source systems 210A, 210B of FIG. 2 that generate "change in the condition of data” source events utilize agents to push the data describing the source events to the engine 110.
  • the polling client 222 in the engine pulls source data from the source system 210C and thereby generates "data notification" source events.
  • a data notification event may also be pushed to the engine 110 by an agent on the source system that uses its own polling server or by the source system itself.
  • a source system 210 can push data notification events to the engine 110 via a HTTP request or another protocol.
  • FIG. 3 is a high-level block diagram illustrating a more detailed view ofthe engine 110 in relation to the other entities illustrated in FIG. 1.
  • FIG. 3 illustrates functional modules within the engine.
  • FIG. 3 illustrates only the modules ofthe engine 110 useful for describing the present invention, and it will be understood that an embodiment ofthe present invention may include other modules not described herein.
  • embodiments ofthe present invention may lack modules described herein and/or distribute the described functionality among the modules in a manner different than described herein.
  • the engine 110 is executed on a conventional computer system running the Linux operating system.
  • the modules of the engine 110 are preferably Linux processes.
  • the modules are written in the Perl and Java programming languages, stored on a storage device associated with the computer system, and executed by other modules present in the operating system and/or computer system to provide the described functionality.
  • the modules ofthe engine 110 are processes executing on a version ofthe WINDOWS operating system from MICROSOFT CORP.
  • a polling layer 310 illustrated within the engine 110 represents the engine's functionality for obtaining source events via polling. As described with respect to FIG. 2, a polling server 220 and agent 218B executed on a source system 210B can generate source events. Likewise, the engine 110 itself can execute a polling client 222 for polling source systems 210C.
  • the polling layer 310 of FIG. 3 abstractly represents modules for receiving data via either polling method.
  • a connection manager 312 preferably receives the XML data packets describing the source events from the polling layer 310 and/or directly from the source systems 112.
  • the connection manager 312 preferably parses and validates the packets, and sends receipt acknowledgements back to the polling layer 310 and/or source systems 112.
  • the connection manager 312 also preferably retrieves rules for processing the source events from a rules database 314.
  • the connection manager 312 constructs intermediate data representations describing the source events and the associated processing rules and stores the representations in queues 316. In another embodiment, the connection manager 312 does not construct the intermediate data representations but instead stores the XML data packets describing the source events.
  • connection manager 312 analyzes the retrieved rules in order to detect rule-firing cycles (i.e., potentially infinite rule-firing loops). Such a cycle might occur, for example, if source event A results in action B which, in turn, results in other actions that eventually cause source event A to occur again. Upon detecting such cycles, the connection manager 312 preferably breaks the cycle by leaving the final rule (i.e., the rule that completes the cycle) out ofthe intermediate data representation. The cycle detection process is described below in more detail.
  • the engine 110 executes a separate instance ofthe connection manager 312 for each source system 112. Separate instances are desirable because they increase the performance ofthe engine 110 by enabling parallel execution. In an alternate embodiment a single instance ofthe connection manager 312 processes source events from some or all ofthe source systems 112.
  • the database 314 preferably stores rules and metadata describing the processing to be performed on the data describing the source events and the effects to be performed to deliver data describing destination events to the destination systems.
  • Each rule preferably describes a distinct source event, and the processing and effect(s) to perform in response to the event.
  • a source event could be the database update of table X in database Y. Inserting a new record into the same table would be considered a separate source event and therefore be described by a separate rule.
  • the rules contain numeric identifiers that refer to columns and/or tables in the data repositories 212 in the source systems 112 to which the rules pertain.
  • the rules also refer to data sources (the metadata) stored in the database 314 or elsewhere.
  • the rules in the database 314 are encoded in XML. However, other embodiments ofthe database 314 can use different representations ofthe rules.
  • the engine 110 includes multiple queues for holding the intermediate data representations created by the connection manager 312 that describe the source events and rules.
  • the engine 110 maintains separate first-in-first-out (FIFO) queues 316 for each destination system 116 and each action type (i.e., delivery method).
  • FIFO first-in-first-out
  • the engine 110 stores the intermediate data representations in data structures other than queues.
  • each queue is implemented as a separate directory on the storage device associated with the computer system executing the engine 110.
  • the entries in the queue are stored as sequentially numbered files (e.g., _000004901.tsi), with the number indicating a file's position in the queue.
  • Each file contains a data structure describing the data from the source event and rules with which the data are associated.
  • the engine 110 preferably includes an instance of a queue manager 318 for each queue 316. Each queue manager 318 sequentially reads the files in its queue's corresponding directory and processes the data and rules as specified by the files' data structures.
  • the queue manager 318 applies the pre-effect and effect processing specified by the rules in the queue entry to the data to produce data describing the destination event. Then, the queue manager preferably executes the action specified by the rules and/or associated with the queue 316 to deliver the data describing the destination event to the destination system(s) 116. For example, in one embodiment the queue manager 318 executes a SQL command at a database maintained by a destination system 116 in order to "deliver" the destination event to the destination system. In another embodiment the queue manager 318 sends an email containing the data describing the destination event to a destination system 116. In yet another embodiment, the queue manager 318 submits an HTML form to a web server operated by the destination system. Should a destination system 116 be unavailable, the queue manager 318 will preferably try to connect to the system at specified intervals either indefinitely or until a timeout period passes.
  • a transform server 320 in the engine 110 preferably supports pre-defined, as well as user-defined, functions for transforming the data in the source events.
  • the server 320 provides "plug-in" style functionality, meaning that users can define custom transformations using functions and store them on the transform server 320.
  • the custom transformations can utilize other functions stored on the transform server 320 and/or functions provided by the database 314.
  • the server 320 allows user-defined functions to be added dynamically, i.e., at runtime and without having to restart the engine 110 or any module within the engine.
  • the transform server 320 is implemented as a daemon that monitors ports for remote procedure calls (RPCs) made according to the XML-RPC protocol.
  • RPCs remote procedure calls
  • a queue manager 316 encounters a user-defined function in a rule's logic, it makes a RPC to the transform server 320.
  • the server 320 executes the user-defined function and returns the result to the queue manager.
  • a parent queue manager 322 in the engine 110 manages the queue managers 318.
  • the parent queue manager 322 dynamically adds and removes queue managers 318 as destination systems 116 are added and removed. Likewise, the parent queue manager 322 adds and removes queue managers 318 as particular action types are used or no longer used.
  • a control server 324 preferably provides the console 120 and other devices and/or applications outside the engine 110 with an interface for viewing and controlling the engine. For example, the control server 324 allows the console 120 to start and stop individual components within the engine 110, such as the connection manager 312 and parent queue manager 322, and retrieve status and accounting information from the engine.
  • the engine 110 also includes a license server 326 for specifying the features available to users ofthe engine 110.
  • the license server 326 maintains license data specifying the rights and privileges available to users ofthe engine 110.
  • the license server 326 specifies how many source 112 and/or destination 116 systems can be utilized with the engine, the data processing functions and effects available to users, whether users can develop custom rules, etc.
  • the other modules within the engine 110 periodically contact the license server 326 to ascertain and verify the user's right to use certain features.
  • FIG. 4 is a block diagram graphically illustrating the rule-based processing performed by the modules ofthe engine 110 illustrated in FIG. 3.
  • the engine 110 provides two-stage processing.
  • the first stage is pre-effect processing 410 and the second stage is effect processing 412.
  • the two stages are highly configurable and flexible, thereby enabling the engine 110 to provide an extensible framework for communicating information among the systems 112, 116. Either or both stages can be skipped depending upon the rules.
  • a queue manager 318 preferably performs both processing stages in response to rules retrieved from the database 314 by the connection manager 312 and or the action type associated with the queue.
  • Other embodiments ofthe engine 110 distribute this processing functionality differently.
  • the pre-effect processing stage 410 provides multiple types of processing ofthe data describing the source event in order to produce data describing a destination event.
  • Other embodiments ofthe engine 110 provide different processing types at this stage in addition to, or instead of, the types described herein.
  • Data incorporation 414 allows the pre-effect processing to combine and/or utilize multiple sets of data with the data describing the source event.
  • pre-effect processing 410 can perform a SQL query on an external database to retrieve data, such as an email address, before performing actions that use this data.
  • the engine 110 can wait for the other data to arrive before performing data incorporation 414.
  • the engine 110 can suspend processing of a first source event until a second source event (or another data input) containing certain data arrives.
  • the engine 110 can preferably also actively obtain data from external sources.
  • the pre-effect processing for a source event from a first source system 112 can include requesting, polling, or otherwise accessing a second source system for data.
  • the pre-effect processing can include accessing a computer system on the Internet or another network to obtain certain data.
  • the engine 110 can also incorporate or reference other data in order to perform validation or comparison testing with data in a source event.
  • the reference data is distinguished from obtained data in that it is only used as part of validation or comparison operations rather than being added to the information set.
  • data received from a source event may contain product codes that a company wants to validate as existing in a separate warehouse data repository before continuing on with processing.
  • the engine 110 would perform the comparison as a condition to proceeding with processing.
  • Data transformation 418 pre-effect processing enables low-level manipulation of the data in a source event.
  • the data transformation processing 418 uses functions selected from a library in the database 314 and/or transform server 320 to operate on the data.
  • the functions in the library are preferably grouped into categories, which in one embodiment include: arithmetic; branch; date/time; general; logical; lookup; relational; security; and string manipulation.
  • Other embodiments ofthe engine 110 utilize different functions and/or function categories instead of, or in addition to, the ones described herein.
  • User-defined processing 420 processes the data in the source event according to user-defined functions stored in the transform server 320.
  • the console 120 provides the user with a scripting interface with which the user can define custom functions.
  • the scripting interface supports the Perl, JavaScript, and Tel scripting languages. Using this interface, a user can work with data in source events and other data by specifying specific data elements as inputs. The resulting outputs ofthe custom functions can be used in other processing functions and/or incorporated into the source and/or destination events.
  • the conditional logic 422 enables the data processing performed on the data in a source event to be determined dynamically using control flow logic. In one embodiment, the conditional logic can evaluate a Boolean equation and use the result to determine whether to perform or omit certain actions.
  • conditional logic 422 allows the data processing to be conditioned on factors including the type of data, the information contained in the data, the environmental context surrounding the data, etc.
  • the engine 110 dynamically responds to these factors in real time, thereby providing a user with precise control over how source events are processed.
  • the types of data on which the data processing are conditioned include, for example, customer names, product names, codes, monetary values, etc.
  • conditional logic 422 the engine 110 can process a source event containing data representative of a customer name differently than a source event containing data representative of a monetary value, even if both source events come from the same source system 112.
  • conditional logic 422 can be applied to data in a source event to process names beginning with "B" differently than names beginning with "G,” or to process monetary values differently depending upon whether the value exceeds $500.
  • the environmental context surrounding the data on which the data processing is conditioned are variables determined in response to external events. Examples of environmental variables include the time, date, number of events processed by the engine 110 within a given time period, the location ofthe source system 112 that produced a given source event, etc.
  • the engine 110 can use conditional logic 422 to perform processing based on the environmental context to, for example, treat source events received from Chicago during business hours differently than source events received from Los Angeles on a Sunday.
  • the effect processing stage 412 distributes the destination events to the destination systems 116.
  • the effect processing stage 412 can perform data transformation 418 and user-defined 420 processing on the destination messages before distribution in the same manner as the pre-effect processing stage 410.
  • Other embodiments of the engine 110 provide different processing types at this stage 412 in addition to, or instead of, the types described herein.
  • the effect processing stage 412 distributes the data describing the destination events via one or more action types 424.
  • An "action" delivers the destination event data to one or more destination systems 116 according to the rules in the engine 110, the results of any processing performed in the pre-effect 410 and/or effect 412 stages, and/or the action type associated with a queue 316.
  • Each action type defines a different delivery method or technique.
  • a commonly used action type is the "database" action.
  • One type of database action delivers the destination event data by making one or more SQL calls to the destination system(s) 116.
  • the SQL calls effect changes in the destination system's data repository that reflect the data describing the destination event.
  • the database action can make a SQL call that causes data in a specific field ofthe destination event to be stored in a specific field in the data repository at the destination system 116.
  • Another action type is the "email” action.
  • This action type preferably delivers the destination event data, encoded as text or HTML, to the destination system(s) 116 via an email message.
  • a similar "FTP" action type delivers destination event data encoded as text, XML, SQL, HTML, and/or binary data to destination systems 11 via the FTP.
  • action types supported by a preferred embodiment of the present mvention include an "HTTP" action type that uses HTTP GET/POST commands, a "JMS” action type that uses the JAVA messaging service (JMS) "publish” command, and a "TCP/IP broadcast” command.
  • Each of these action types can use its respective commands to deliver plain text, XML, SQL, HTML or binary destination event data to the destination systems 116.
  • Additional action types include the "LDAP” action type that uses the Lightweight Directory Access Protocol (LDAP), the "SOAP” action type that uses the Simple Object Access Protocol (SOAP), and the "XML-RPC” action type that uses the XML-remote procedure call (RPC) protocol.
  • LDAP Lightweight Directory Access Protocol
  • SOAP Simple Object Access Protocol
  • XML-RPC XML-remote procedure call
  • These action types use the respective protocols to deliver destination event data encoded as plain text, XML, and/or HTML to the destination systems 116.
  • the action 424 types also include a "telnet” action type that uses the telnet command to deliver destination events to the destination systems 116 as plain text.
  • Alternative embodiments ofthe present invention support other action types in addition to, or instead of, the ones described herein.
  • FIG. 5 is a flowchart illustrating the steps performed by the engine 110 to facilitate communications according to a preferred embodiment ofthe present invention.
  • Other embodiments ofthe present mvention may perform different or additional steps than those described herein.
  • the steps maybe performed in different orders.
  • the engine 110 can preferably simultaneously process multiple source events. This description refers to the processing of a single source event for purposes of clarity.
  • the engine 110 receives 510 the data describing the source event from a source system 112.
  • the engine 110 preferably parses, validates, and acknowledges receiving 512 the event.
  • the engine 110 identifies and retrieves 514 rules pertaining to the source event from the rules database 314 based on the event type and or the source system 112.
  • the rules specify the pre-effect and effect processing to perform on the source event (if any).
  • the engine 110 builds an intermediate representation ofthe data describing the source event and the rules.
  • the engine 110 places 516 this representation into the appropriate FIFO queue 316 or queues.
  • the engine determines the appropriate queue based on the effect processing, specifically the action type, specified by the rules.
  • the engine 110 reads the intermediate representation from the queue and performs 518 any pre-effect processing specified by the rules to transform the intermediate representation into a destination event (or discard the source event). Next, the engine 110 performs 520 the effect processing specified by the rules. At this point, the destination event is ready for delivery to a destination system 116 via the action type specified by the rules. Accordingly, the engine 110 performs 522 the action and thereby delivers the destination event data to the destination system 116.
  • FIG. 6 is a flowchart illustrating the steps performed by a user to establish a rule for the engine 110.
  • Other embodiments ofthe present invention may perform different or additional steps than those described herein.
  • the steps may be performed in different orders.
  • those of ordinary skill in the art will recognize that the user can perform similar steps to view, modify, and/or delete rules stored in the database 314.
  • the user specifies 610 a source system 112 to which the rule applies.
  • the user selects a named source system 112 from a list of potential source systems presented by the GUI.
  • the user also specifies 612 a source event on the source system 112 that will trigger the rule. For example, if the source system 112 is a database, the user can preferably select among source events including "insert,” “update,” and "delete.”
  • the user may need to register the source system.
  • the user provides credentials, such as a user name and password, that the engine 110 can use to access the source system 112.
  • the user also specifies the data storage type and other parameters depending upon the type of data repository at the source system 112.
  • the engine 110 preferably treats it in the same manner as any other source system/data provider.
  • the user preferably specifies 614 an action type for the rule.
  • the user can choose among types including "database” (i.e., the action is a database update), email, LDAP, etc.
  • the user also specifies 614 the destination system 116 for the action type.
  • the user provides different information to specify the destination system 116. For example, if the action type is "email,” the user preferably provides a destination email address. If the action type is "database,” the user preferably identifies the database to update.
  • the user also specifies the pre-effect 616 and effect 618 processing (other than the action type) to perform on the source/destination event.
  • the present invention enables complex pre-effect and effect processing.
  • the techniques that the user uses to specify the processing vary depending upon the specified source system, source event, and action type. For example, if the source system is a database, the event is a database update, and the action type is another database update, the user specifies the effect processing by specifying a mapping between the source database field(s) and the destination database field(s), as well as specifying any additional processing to perform on the data used to update the field(s) (i.e., the data contained in the source event).
  • the user specifies the source database field(s), any processing to perform on the data used to update the field(s), and any text to include in the email along with data that can be inserted into the email text dynamically (e.g., "Congratulations! Your credit card limit is now $ !).
  • the user preferably saves 620 the rule to the database 314 in the engine 110.
  • program modules in the user console 120 check for any "connections" between the rules before saving the rule in the database 314.
  • two rules are connected if the firing ofthe first rule can lead to a firing ofthe second rule.
  • two or more rules can be connected in a manner that creates an infinite loop, especially when both the source systems and destination systems are databases.
  • a first rule that updates a field in a destination database may be connected to a second rule in the destination database that updates a field in the original source database, leading to an infinite loop of database updates.
  • the program modules identify any rules that are connected to the rule being saved, the modules preferably mark the rule being saved as "bi-directional.”
  • the rule is then saved to the database 314, where a data field indicates whether it is bi-directional.
  • the engine 110 preferably propagates the triggers and/or other logic to the source systems 112, connection manager 312, and/or polling layer 310 as may be necessary to bring the rule into effect (this action is not shown in FIG. 6).
  • the engine 110 includes functionality for detecting and breaking potential infinite rule-firing loops.
  • the engine 110 when the engine 110 fires a rule marked as bi-directional, the engine causes a token to be saved to the table 216 on the destination system 116. The token identifies the source system 112 that generated the source event that ultimately caused the destination event at the destination system 116. Then, when the (former) destination system 116 generates a new source event, the agent 218 sends the token to the engine 110 with the source event identifier. If any ofthe rules fired in response to the new source event are marked as "bi-directional," the engine 110 determines whether the actions associated with the rules are directed to the source system 112 identified by the token. If so, the engine 110 preferably suppresses the action to the source system 112, thereby breaking the rule-firing loop.
  • a rule's possible operational modes are "active,” “simulation”, and "inactive.”
  • a rule in active mode fires in response to source events as described above.
  • a rule in simulated mode fires normally, except that the engine 110 does not send the destination event data to the destination systems 116; the engine preferably records and make visible in a log what would have been sent, thereby allowing the rule to be tested without affecting the destination systems.
  • the simulation mode can be conceptualized as an action type that delivers the data describing the destination event to a log instead of to the destination systems.
  • a rule in inactive mode disables the trigger and/or agent on the source system 112, so both the source system and the engine 110 function as if the rule did not exist.
  • FIGS. 7-12 illustrate some ofthe GUIs presented by the user console 120 to allow the user to perform the steps of FIG. 6 according to one embodiment ofthe present invention.
  • Those of skill in the art understand that other embodiments ofthe present invention can have different GUIs, and the GUIs illustrated herein are merely examples of possible GUIs.
  • FIG. 7 illustrates a GUI 700 for enabling the user to select a source system 112 and specify the source event.
  • a list box 710 displays a tree hierarchically listing the source systems 112 available to the engine 110.
  • the source systems include a "Pet Store” database having tables named “account,” “bannerdata,” and “category.” Each of these tables can be selected by the user and represents a potential logical source system for purposes ofthe present mvention.
  • the GUI also includes a selection box 714 enabling the user to specify whether the source event is an insert, update, or delete operation to the identified source system.
  • FIG. 8 illustrates a GUI 800 for enabling the user to specify the action type for an effect.
  • a list box 810 lists and allows the user to select one ofthe possible actions (e.g., database, email, etc.) at a time. Multiple actions and effect types can be utilized in response to one or a combination of source events.
  • An area 812 adjacent to the list box 810 displays an explanation ofthe currently selected action.
  • FIG. 9 illustrates a GUI 900 for enabling the user to specify the processing to perform on source event data to transform it into a desired format for the destination event.
  • this portion of the GUI 900 allows the user to specify mappings between the source database field(s) and the destination database field(s), as well as specifying any additional processing to perform on the data used to update the field(s).
  • a list box 910 on the left side ofthe GUI lists the data fields 912 in the source system 112, which in this example are the fields of he "account" table in the "Pet Store” database.
  • a list box 914 on the right side ofthe GUI 900 lists the fields 916 available in the destination system 116.
  • the destination system 116 is a database table entitled ACCOUNT and having fields corresponding to the fields in the source system 112.
  • the names ofthe fields in the source table are displayed in lowercase while the fields in the destination table are displayed in uppercase.
  • the right list box 914 graphically indicates the relationship between the source fields, the effect processing, and the destination fields.
  • the list box illustrates 914 that the effect processing concatenates the "addrl” and "addr2" fields in the source database into a single entry stored in the "ADDRESS" field 918 ofthe ACCOUNT table.
  • the GUI 900 also displays additional elements allowing the user to specify the details of specific effect type processing.
  • a selection box 920 allows the user to specify whether the destination event is an insert, update, or delete operation.
  • a "link" button 922 allows the user to create a relationship between the fields ofthe source table and the fields of the destination table.
  • Tabs 924 across the top ofthe left text box 910 control whether the box displays the source fields (as shown), the destination fields, or functions for processing the contents of the fields.
  • FIG. 10 illustrates a GUI 1000 for enabling the user to specify pre-effect processing for the specific rules.
  • the illustrated GUI 1000 has two list boxes 1010, 1012 respectively aligned on the left and right sides ofthe display.
  • the left list box 1010 preferably lists the source systems 112 and the rules defined for the systems, if any.
  • the "Bookstore” source system 1014 (which is a database executing on the "ocelot” server) has a single defined rule named “ACCOUNT.”
  • the list box 1010 also lists a "Global" entity that enables the user to specify pre-effects accessible to every rule in the engine 110.
  • the right list box 1012 preferably lists the pre-effects for the currently selected rule in the left list box.
  • the right list box 1012 lists two pre-effects 1018 respectively named "Get UniquelD" and "Is new customer.”
  • the "Get UmquelD" pre-effect is an SQL statement while the "Is new customer” pre-effect is a Boolean assertion.
  • the pre-effects are applied to the associated rule in listed order and the user can use arrow buttons 1020 in the GUI 1000 to change the order.
  • FIG. 11 illustrates a pre-effect assertion 1100 where a Boolean equation 1110 is evaluated and a conditional action is taken in response to the results ofthe evaluation.
  • a conditional action is taken in response to the results ofthe evaluation.
  • the status data element 1112 in the accounts table ofthe primary source system is being compared to the three character, all capital, string, "NEW.”
  • FIG. 12 illustrates a pre-effect in which data is being incorporated from another location.
  • a SQL statement 1214 is being used to gather information from the "Petstore” database on the "Ocelot” system 1210.
  • the SQL statement 1214 is constructed dynamically using data elements from the primary source system.
  • the data elements for "userid” and "email” are being used in the SQL statement 1214 to generate a variable 1216 called "uniquelD" that is available for effect processing.
  • the SQL statement is constructed, it is executed as part ofthe pre-effect.
  • the values to be gathered as part ofthe pre-effect can be gathered before or after the pre-effect action.
  • the present invention includes an efficient and flexible architecture enabling multiple disparate source systems to communicate via a variety of communication techniques and technologies. Moreover, the present invention also provides sophisticated data processing capabilities allowing a broad range of data transformation and effect processing rules to be applied to the communications among the computer systems. An organization can use the present invention to maintain data coherence between different types of computer systems, data storage systems, and/or data delivery systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Un moteur assure des communications entre des systèmes informatiques sources et de destination. Les systèmes sources génèrent des événements sources. Un événement source rend compte d'un changement d'état des données dans un organe d'archivage au niveau d'un système source ou bien sert à notifier des données provenant du système source. Le moteur comprend des gestionnaires de connexion qui reçoivent des événements sources (510) en provenance des systèmes sources. Le moteur inclue également des règles de stockage pour base de données qui décrivent le traitement des pré-effets et des effets (512) à exécuter en réponse à l'événement source. Le moteur de connexion extrait des règles associées (514) de la base de données et stocke l'événement source, la connexion permet d'extraire de la base de données toute règle associée et met l'événement source et les règles dans une file d'attente (516). Un gestionnaire de files d'attente effectue une lecture, applique un traitement de pré-effet aux données issues de l'événement source pour générer un événement de destination, et applique le traitement d'effet pour acheminer les données d'événement de destination aux systèmes de destination (522) appropriés.
PCT/US2002/034979 2001-11-20 2002-10-31 Traitement et distribution de donnees selon des regles specifiees WO2003044683A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002365998A AU2002365998A1 (en) 2001-11-20 2002-10-31 Processing and distributing data according to specified rules

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US33193301P 2001-11-20 2001-11-20
US60/331,933 2001-11-20
US19449502A 2002-07-11 2002-07-11
US10/194,495 2002-07-11

Publications (1)

Publication Number Publication Date
WO2003044683A1 true WO2003044683A1 (fr) 2003-05-30

Family

ID=26890079

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/034979 WO2003044683A1 (fr) 2001-11-20 2002-10-31 Traitement et distribution de donnees selon des regles specifiees

Country Status (2)

Country Link
AU (1) AU2002365998A1 (fr)
WO (1) WO2003044683A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008037717A1 (fr) 2006-09-28 2008-04-03 International Business Machines Corporation Typage d'événement à base de ressource dans un système de règle

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5530852A (en) * 1994-12-20 1996-06-25 Sun Microsystems, Inc. Method for extracting profiles and topics from a first file written in a first markup language and generating files in different markup languages containing the profiles and topics for use in accessing data described by the profiles and topics
US5974441A (en) * 1995-06-07 1999-10-26 International Business Machines Corporation WWW client server interactive system method with Java (™)
US6310888B1 (en) * 1997-12-30 2001-10-30 Iwork Software, Llc System and method for communicating data
US6397220B1 (en) * 1998-10-01 2002-05-28 Unisys Corporation Common gateway which allows JAVA applets to make program calls to OLTP applications executing on an enterprise server reference to co-pending applications
US6466976B1 (en) * 1998-12-03 2002-10-15 Nortel Networks Limited System and method for providing desired service policies to subscribers accessing the internet

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5530852A (en) * 1994-12-20 1996-06-25 Sun Microsystems, Inc. Method for extracting profiles and topics from a first file written in a first markup language and generating files in different markup languages containing the profiles and topics for use in accessing data described by the profiles and topics
US5974441A (en) * 1995-06-07 1999-10-26 International Business Machines Corporation WWW client server interactive system method with Java (™)
US6310888B1 (en) * 1997-12-30 2001-10-30 Iwork Software, Llc System and method for communicating data
US6397220B1 (en) * 1998-10-01 2002-05-28 Unisys Corporation Common gateway which allows JAVA applets to make program calls to OLTP applications executing on an enterprise server reference to co-pending applications
US6466976B1 (en) * 1998-12-03 2002-10-15 Nortel Networks Limited System and method for providing desired service policies to subscribers accessing the internet

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008037717A1 (fr) 2006-09-28 2008-04-03 International Business Machines Corporation Typage d'événement à base de ressource dans un système de règle
CN101517540A (zh) * 2006-09-28 2009-08-26 国际商业机器公司 规则系统中基于资源的事件键入
KR101081288B1 (ko) * 2006-09-28 2011-11-08 인터내셔널 비지네스 머신즈 코포레이션 규칙 시스템에서의 리소스-기반 이벤트 타이핑
US8966016B2 (en) 2006-09-28 2015-02-24 International Business Machines Corporation Resource-based event typing in a rules system

Also Published As

Publication number Publication date
AU2002365998A1 (en) 2003-06-10

Similar Documents

Publication Publication Date Title
US6694362B1 (en) Method and system for network event impact analysis and correlation with network administrators, management policies and procedures
US7130812B1 (en) Method and system for managing real time data
US9497274B2 (en) Extending functionality of web-based applications
JP3782477B2 (ja) オペレーティングシステムのシステム管理のためのイベントアーキテクチャ
US7607137B2 (en) Integration of heterogeneous applications
US5933604A (en) Network resource monitoring system and method for providing notice of changes in resources in a network
US9229998B2 (en) Method and system for exchanging information between back-end and front-end systems
US7379977B2 (en) System and method for display of multiple electronic pages
US8707336B2 (en) Data event processing and application integration in a network
US9165087B2 (en) Validity path node pattern for structure evaluation of time-dependent acyclic graphs
US6732146B1 (en) Information processing apparatus, information processing method, and information providing medium providing a changeable virtual space
US11809397B1 (en) Managing slot requests for query execution in hybrid cloud deployments
EP0806731A2 (fr) Réseau de base de données
US7124354B1 (en) Enterprise application transactions as shared active documents
US9118727B2 (en) Methods, systems, and computer program products for providing metadata subscription services
MX2007011027A (es) Sistema y metodo para producir y comunicar datos solicitados entre programas de aplicacion en red.
KR20010092785A (ko) 채널형 데이터를 제공하기 위한 방법 및 시스템
US20070078943A1 (en) Message based application communication system
GB2557522A (en) Digital ticketing system including a server and multiple mobile smartphone computing devices each including a respective digital ticketing application
US20060085461A1 (en) System & method for using web based applications to manipulate data with manipulation functions
US20090132538A1 (en) Information processing apparatus, information processing system, and information processing method
US11455314B2 (en) Management of queries in a hybrid cloud deployment of a query system
US7558776B2 (en) System and method of managing internet browser navigation
KR100385926B1 (ko) 인터넷으로 연결된 복수의 사용자 단말장치간의 공유를 통한 분산처리시스템 및 시스템의 형성방법
KR20040073346A (ko) 문서 컨텐츠 및 분배 세팅 구동을 위한 데이터 맵핑 사용

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CO CR CU CZ DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase