GB2271002A - Digitals open-edi scenarios automation process - Google Patents
Digitals open-edi scenarios automation process Download PDFInfo
- Publication number
- GB2271002A GB2271002A GB9220379A GB9220379A GB2271002A GB 2271002 A GB2271002 A GB 2271002A GB 9220379 A GB9220379 A GB 9220379A GB 9220379 A GB9220379 A GB 9220379A GB 2271002 A GB2271002 A GB 2271002A
- Authority
- GB
- United Kingdom
- Prior art keywords
- transaction
- edi
- messages
- message
- scenarios
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/234—Monitoring or handling of messages for tracking messages
Abstract
EDI (Electronic Data Interchange) systems deal with messages relating to business transactions. Message-based (batch) EDI deals with individual messages. Transaction-based EDI (I-EDI, interactive EDI) deals with transactions as wholes, messages having headers identifying their transactions. Transaction types are defined by scenarios, and individual transactions by instances of the transaction scenarios. A general-purpose transaction-based EDI system requires preprocessing means (50) for passing message-based system messages through to a message-based EDI subsystem (59). In the present system, the preprocessing means attempt (56, 57), for non-transaction messages (ie messages without transaction headers), to match them with the scenarios and instances, to thereby identify the transactions to which those messages relate. <IMAGE>
Description
Data Processing Svstem
The present invention relates to data processing systems for monitoring and controlling business procedures, and more specifically business transactions.
General background
A typical business transaction involves several companies or, more generally, trading entities, and the interchange of a variety of documents between these entities. A reasonably simple example is a manufacturer who uses various components, including widgets, obtained from an external supplier. The manufacturer has some internal system which generates an order for a batch of widgets, and the order is duly printed out and sent off to the supplier. The supplier receives the order, and sends back an acknowledgement.
In due course, the supplier makes up the order and sends it off (as a physical consignment, of course, not a document), and sends a delivery advice note at the same time. The supplier also then generates and sends an invoice. When the manufacturer has received the widgets and the invoice, he sends a payment order to his bank to debit his account and credit the supplier's account (assuming that they have the same bank); the bank then sends an advice letter to the supplier to say that the invoice has been paid.
In practice, the various trading entities will, if they are of significant size, have formal internal systems for processing the various documents. For example, the manufacturer will have a production department which has a manufacturing control system which is fed with product orders and forecasts and generates, from that information, production targets and then component orders for the components required for those production targets. There will be
, a purchasing system which generates orders to suppliers for the required components, using information on potential suppliers and incorporating suitable authorization procedures. The goods received department will have procedures for reconciling goods received with advice notes.The accounts payable department will have procedures for paying invoices provided that receipt of the goods has been advised by the goods received department.
These various internal systems will often be automated to some extent; we will term such automated systems "applications" (or application systems).
Thus the production department may have an application system which automatically matches information from the goods received department with original purchase orders; the accounts payable department may have an application system which automatically matches invoices with information from the goods received department; and so on. Many of the documents generated by the internal systems will be generated by such automated application systems. Some manual input may be required (eg cheque signatures), but often no manual input to the documents themselves will be required (eg in the supplier, the invoice and the delivery note can be generated automatically once the goods have been dispatched).
The facts that some of the documents are generated automatically and that some of the documents received undergo processing that is at least partially automated have allowed a further stage of automation, known as Electronic
Document Interchange (EDI). In this, the application systems of the trading entities are coupled to communication systems through respective EDI interfaces, so that documents can be sent and received automatically (ie electronically). The communications system may be a public utility service such as a telephone network, or some form of wide area network or packet switching network (which may be partially or wholly public).
The EDI service forms an interface or gateway between the applications and the communications system. For outgoing documents (or "messages"), the
EDI service forwards the document from the application to the communications system; for incoming messages, the EDI service forwards the message from the communications system to the appropriate application. an practice, there will usually be a communications system interface between the EDI service and the communications system, to convert the messages between the EDI service format and the particular characteristics of the various communications systems used.) In addition, the EDI service adds or deletes suitable headers, and may perform format conversions between internal applications formats and standardized communications message formats.
This form of EDI is message-based, and we will use the term "message based" (though the term "batch system" is also used for such systems). Each incoming message is treated independently by the EDI service, which inspects the message only enough to determine which application the message is to be forwarded to.Each message has a message header which contains sufficient identification for this purpose. (If the message header is missing or lacks adequate idenfication, the EDI service may eg send the message to a default application system for subsequent manual processing.)
ACID transaction-processing systems
There is a type of distributed data processing system known as a transaction processing system in which a "transaction" consists of a set of components all of which must be performed for the transaction to be performed. (A very simple example is the transfer of money from one account to another, where the one account must be debited and the other account must be credited; if, say, the one account were debited and the other account were not credited, the system would end up in an inconsistent state.) The acronym
ACID (Atomic, Concurrent, Isolated, Durable is often used for such systems, the "atomic" indicating that the transaction is an indivisible whole.
In such systems, there are protocols to ensure that, as a transaction proceeds, the system also maintains its pre-transaction state, so that the system as a whole (ie all components of the system) "jumps" to the next state when the transaction is completed but reverts to the pre-transaction state if the transaction (ie any component) fails (eg because some processor in the system has crashed, or a communication link has failed).
Interactive EDI
The business transactions considered up to now typically extend over long periods (months or more) and involve two or more independent parties.
Both the long periods involved and the fact that the "system" is not under the control of any single party make it difficult or impossible for these transactions to be subjected to ACID-like constraints.
There are however certain specialized business systems (taking "business" in a broad sense) which are more suited to ACID-like constraints.
Examples are credit card systems and booking or reservation systems. It is desirable, and often essential, for these systems to operate in "real time", and it is also essential for them to maintain consistency. (The need for consistency in banking has already been mentioned; the need for consistency in seat reservation systems is also obvious.)
Such systems have often been designed as proprietary systems. This has some advantages when there is a single user (eg a bank) using closely controlled communication systems. For systems which have multiple users (and large communications systems which are to some extent public), such debit and credit card systems, as airline ticket reservation systems (which extend over many countries and involve many independent travel agents), and tour operators, however, standardization offers major advantages.
An extension to EDI, termed interactive EDI (I-EDI), has been proposed for such systems. Interactive EDI is concerned with business transactions (in the board sense) as a whole. Each different type of transaction is defined as a Scenario - a formal description of all the business rules and information flows of a type of business transaction among two or more parties. The scenario is in turn defined as a set of possible Dialogue types and their organization, with each dialogue involving the exchange of messages between two parties in the scenario. Interactive EDI is thus concerned primarily with extending standard
EDI systems to accommodate (as its Dialogues) the elements of ACID-like transaction processing systems.
Transaction-based EDI
It will be realized, however, that Interactive EDI is defined in a manner which allows its application or extension to business transactions generally, whether or not they involve ACID-type operations. Such systems need not involve ACID-type operations and may require some elaboration of 1-EDI to maximize their utility. We will use the term "transaction-based EDI" for such
EDI systems.
More specifically, for transaction-based EDI, the business documents are generated in standard form (as defined by international standards). Each document includes a transaction header which identifies the transaction and the nature of the document.
In transaction-based EDI, the EDI service itself operates as a supervisory system coordinating the operations of the various applications, acting to supervise the transactions. For this, the EDI service is programmed with the permissible patterns or scenarios of transactions. As each transaction proceeds, it checks that it is proceeding according to a permissible sequence or scenario.
If it is, then the service forwards the individual incoming and outgoing messages of the transaction to and from the appropriate application systems, and updates its record of the transaction appropriately. In some instances, the
EDI service may itself take some action; for example, it may generate a reminder message if some stage in a transaction times out. (The "message" may have a variety of forms, eg a fax message; the term "business information object" (BIO) is sometimes used for messages in this general sense.)
It should be noted that while commercial EDI systems are defined by international standards, the term EDI is used here in a general sense.
The general problem
There is a serious problem with transaction-based EDI systems as described so far. A transaction-based EDI installation can only operate effectively if there are similar transaction-based EDI installations at all the other trading entities with which it may conduct transactions. This is likely to be achievable only in the relatively distance future, if at all. Different trading entities are likely to install transaction-based EDI services at different times; and there will be little incentive for a trading entity to install a transactionbased EDI service until a substantial proportion of the other entities with which it trades have also installed transaction-based EDI.
To overcome this problem, it is therefore desirable for transaction-based
EDI systems to be designed to include a default subsystem or mode in which they operate as a simple message-based EDI system. If such a transactionbased EDI system receives a message which lacks a transaction header, it reverts to the simple message-based EDI system operation and merely forwards the message to the appropriate application system.
The invention
We have now realized that the utility of a transaction-based EDI system can be further increased by including in it means for preprocessing nontransaction messages (ie messages without transaction headers) to attempt to identify the transactions to which those messages relate. The preprocessing means perform a kind of sieving or filtering function, extracting some of the non-transaction messages and transferring them to the transaction processing system. Of course, those which cannot be identified with a transaction pass through the filter and are treated by the default non-transaction message processing subsystem.
Accordingly the present invention provides a transaction-based EDI system comprising means for storing scenarios defining possible transactions, instance storage means for storing instances of such transactions, and transaction message processing means for processing messages relating to such instances, and further including preprocessing means for determining whether or not incoming messages are transaction messages or non-transaction messages, characterized in that the preprocessing means include non-transaction message processing means for comparing incoming non-transaction messages with the stored scenarios and instances to attempt to identify the scenarios and instances thereof to which such messages relate.
Specific embodiment
A transaction-based EDI system embodying the invention will now be described, by way of example, with reference to the drawings, in which:
Fig. 1 is a general block diagram of a group of companies coupled together by
EDI systems;
Fig. 2 is a more detailed block diagram of an EDI system; and
Fig. 3 is a simplified flow diagram of the EDI system of Fig. 2.
General company interactions
Fig. 1 shows a manufacturing company 10, a supplier company 11, and a bank company 12. Each of these companies has various application systems.
Thus the manufacturer 10 has a manufacturing control application system 13, an ordering system 14, and an accounts system 15; the supplier 11 has a manufacturing system 20 and an accounts system 21; and the bank 12 has an accounts database 22 and an accounts control system 23. Various ones of these application systems may be interconnected inside each company; for example, the manufacturing control system 13 is coupled to the ordering system 14 which is in turn coupled to the accounts control system in company 10, and the accounts control system is coupled to the accounts database in company 12.
A communication system 25 (shown for convenience as a single channel, though in practice it may include LANs, WANs, and/or public telephone and other systems) connects all three companies together. Each of the companies 10-12 has certain of its application systems coupled to a respective EDI system 26-28 as shown, and the EDI systems are coupled to the communications system 25 via respective communications interfaces 29-31.
With this arrangement, a typical (simplified) transaction may involve the manufacturing application 13 in the manufacturer 10 determining that a fresh supply of widgets is required, and passing this information to the purchasing application 14, which generates a purchase order message PURCH and sends it to the supplier 11. In the supplier 11, this order is received in the manufacturing application 20. In due course, the widgets are sent out by the supplier 11 and an accompanying dispatch message DISP is generated by the manufacturing application 20 and sent to the ordering application 14 in the manufacturer 10.
In this example, the widgets are of course sent as a physical consignment, not shown in Fig. 1. It is however possible for a transaction to consists solely of messages, if for example the subject of the transaction is abstract information such as a piece of software or a market research compilation from a manufacturing company directory or database.
Also, the accounts application 21 in the supplier 11 generates an invoice message INV and sends this to the manufacturer 10, where it is routed to the accounts application 15. This accounts application generates a payment order message PAY and sends it to the bank 12. This message is received in the accounts control application 22 in the bank, which performs the required transfer of funds from the manufacturer's account to the supplier's account in the accounts database application 23, and generates an advice message ADV which is sent to the supplier 11, where it is routed to the accounts application 21.
Although EDI systems are intended primarily for passing messages from one company to another, they can also be used for communication between different applications in a single company. In practice, the applications will normally have a number of direct linkages for passing information between them without involving the EDI system. However, the EDI system provides an alternative method of passing information, and in some circumstances it may be more convenient to use the EDI system for that purpose than to add further direct links between the applications. In particular, the EDI system may provide a convenient way for different applications to learn of the state of the transaction, and hence of other applications.
In practice, the transaction is likely to be considerably more complicated, with more companies involved (for example, the manufacturer and the supplier will probably have different banks, a transport and delivery company may be involved, & ), and involve more messages (for example, a quotation and the approval thereof). Also, there will be considerably more interaction between the various applications in each company than have been described here (for example, reconciliations between different applications).
The description has been sufficiently general so far to apply equally to message-based and transaction-based EDI.
Transaction-based EDI system
For transaction-based EDI, each EDI system incorporates transaction descriptions which define the permissible patterns of transaction. (For convenience, we will consider only the EDI system 26 in the manufacturer 10 from now on.) We shall use the term "scenarios" for such descriptions, but it should be noted that although the present scenarios are broadly similar to the scenarios of I-EDI described above, in general they are not defined in terms of
Dialogues or ACID-like operations.
Each scenario defines a permissible sequence or pattern of events. The events are primarily the reception of incoming messages, from either the applications associated with the EDI or from other companies, and the transmission of messages in response thereto. Thus in the transaction discussed above, the messages are the PURCH, DISP, INV, and PAY messages together with the associated messages passing between the EDI system 26 and the application systems 13-15. (It is also possible for the EDI system itself to generate events; for example, it may contain timers for generating messages if a particular message is not received within a predetermined time.)
The EDI system also includes means for maintaining, for each transaction, a record of the progress of that transaction.Each actual transaction is a distinct instance of a transaction scenario, and its record identifies, among other things, the appropriate scenario and the progress of the transaction through that scenario. This is required because it is possible for two separate transactions to be in existence together and to follow the same scenario; for example, a further order for more widgets may be generated while the transaction of the first order is still in progress.
Each scenario is defined as a tree of functions or elements; there is a different scenario for each different type of transaction, the scenarios being generated with the aid of a user interface (not shown). The scenarios are stored in a scenario store 35 (Fig. 2), which consists of a plurality of units each of which stores a different scenario. The nature of a typical scenario is indicated, in somewhat simplified form, in Table I below.
In this table, some of the elements can be lists of repeated items; for example, element 3, the steps of the transaction, is a list, and the element 5.5.4 and the dependent elements will usually be lists, as most transactions will involve several different trading partners. Some elements appear more than once in the list - eg transaction steps appear in elements 3 and 5.6; in such cases, the items in the second element will identify the relevant items from the first element, which constitutes a complete listing.
The nature of the elements and items is generally self-evident from their names and the present general description. However, it may be noted that element 3 is the main steps of the transaction, and the control sequences (element 4), which broadly represent the various business functions involved, are sequences of conditions and actions. Element 5.5.4 and the dependent elements identify the trading partners in some detail. The structure of the scenario allows not merely a trading partner (company) to be specified, but also a particular business function within that company and a particular application within that business function; this allows transactions with say the various divisions of the various operating companies of a single holding company to be distinguished.Element 5.6.2 identifies a class of Business Information Object (13IO) for each step; typical classes of BIO are EDIFACT invoices, X12 purchase orders, and CAD/CAM drawings.
Table I: Business Scenario 1 Scenario ID 2 Human contact 3 Sequence of transaction steps 4 Control sequences
4.1 Set of conditions
4.2 Set of actions 5 Sequence of Information flows
5.1 Information flow ID
5.2 Direction code
5.3 Control sequence
5.4 Application
5.5 Trading partners
5.5.1 Trading partner ID
5.5.2 Human contact
5.5.3 Communication services
5.5.4 Business functions
5.5.4.1-6 (details of business functions)
5.5.4.5.1-5 (business application functions)
5.6 Transaction steps
5.6.1 StepID
5.6.2 Associated class of BIO
5.7 Communication services
5.8 Communication links
5.8.1 Communication link ID
5.8.2 Human contact
5.8.3 Quality of service
5.8.4 Class of communication link
5.8.5 Submission port address
5.8.6 Delivery port address
5.8.7 Elements of service
5.8.8 Extensions
5.9 Extensions 6 Extensions
The control sequences (conditions and actions) can be regarded as part of the scenarios, but it is convenient to store them in a separate operations store 36, which consists of a plurality of units each of which stores a different set of conditions and actions. Elements 4 and 5.3 in each scenario point to the corresponding entries in store 36.
The conditions may relate to messages as a whole (eg whether a particular message has been received) or the contents of the messages (eg the contents of particular fields of the messages). The actions may similarly relate to messages as a whole (eg whether or not to send a message) or to the contents of the messages (eg changing the format of a field, checking a field to see whether its contents are within a predetermined range, checking whether acknowledgements are to be sent (or have been received), & ).
Turning now to the instances of the transactions, there is a transaction instance store 37 which consists of a plurality of units each of which stores a different instance table. There is a different instance table for each of the current transactions, ie transactions which are actually proceeding. The structure of each instance table is defined by the scenario of the transaction involved. Since there may be several current transactions for a given scenario, there may be several different instance tables defined by the same scenario, each indicating the current state of a different one of those transactions.
Each instance table is defined as a table of transaction steps, with each transaction step consisting of a step number, a step state, a set of step conditions, and a set of actions. The table also has an identifier, which may loosely be termed a transaction identifier but is more precisely a transaction instance identifier. For each step, the main possible step states are pending, active, or completed (though other states such as blocked and paused are also possible).
The EDI system also includes a processing unit 38, which is coupled to the scenario store 35, the operations store 36, the transaction instance store 37, a set of internal ports 39 to the applications 13-15, and an external port 40 to the communications system 29. This processor operates to maintain the instance tables and carry out the appropriate actions from the operations store 36. In effect, each scenario is an abstract state machine, and the processor, the scenarios, and the transaction instance tables together implement, for each transaction instance, this state machine and its advance through its various states.
Each message in a transaction-based EDI system has an EDI envelope or header. The EDI system generates the envelopes for messages which it sends out, and examines and strips off the headers of messages which it receives. (Some messages pass through the EDI system from or to the applications systems; others are generated or terminate in the EDI system itself.) The header includes identification information to identify the transaction involved. This may take various forms; the preferred form of transaction identifier comprises a scenario identifier, a step (of the scenario) identifier, and an instance identifier.
The generation of the transaction identifier for outgoing messages is straightforward. For incoming messages, the processor analyzes its header to identify the transaction identifier, and from that, to obtain the scenario, step, and instance identifiers. It then uses that information to refer to the appropriate scenario table in store 35 and determine what operations need to be performed rooking them up in table 36). It then carries out those actions and those determined by the active state in the transaction instance table, and updates the transaction instance table.
This system works for messages which have transaction instance identifiers; that is, for messages which are received from companies which also have transaction based EDI systems. However, as discussed above, for many transactions at least some of the other companies involved may have only message-based EDI systems. Messages received from those companies will lack transaction instance identifiers.
Message identification
In a simple transaction-based EDI system, the EDI system would either pass such messages through directly to the application systems (without updating involving the transaction control means described with reference to
Fig. 2) or would pass them to an exception or invalid message routing for subsequent processing by the user. In the present system, however, the EDI system includes means 41 for attempting to identify the transactions to which such simple messages (ie messages without standard transaction headers, ie explicit instance identifiers) relate.
For message identification, the message is stored in a message store 45, and is processed by the processor 38 operating in conjunction with a comparator unit 46. A simplified version of the operation of the system - that is the general processing of messages, whether or not they are transaction-based - is summarized by the flow diagram of Fig. 3.
In the first operation, block 50, the processor inspects the header of the message to determine whether it is a simple message header (MESS) or a transaction header CIT).
If it is a transaction header, block 51 follows, in which the processor extracts the scenario identifier from the transaction identifier and tries to match it against the identifiers of the scenarios in the scenario store 35, using the comparator 46. If the match fails (N), then the system signals a fault and alerts the user (block 52). If the match succeeds (Y), then block 53 follows, in which the processor extracts the instance identifier from the transaction identifier and tries to match it against the identifiers of the instances in the instance store 37, using the comparator 46. If a match is achieved (Y), the system proceeds to block 54, in which the transaction is advanced - the transaction is updated, the appropriate actions taken, & .If a match is not achieved (N), then the system proceeds to block 55, in which a new transaction instance is created and the appropriate actions taken.
If the message does not have a transaction header, then it is a simple message (ie from a message-based EDI system). In a simple transaction-based
EDI system, the flow diagram would be as described so far, but the MESS output from block 50 would lead straight to a message-based EDI system, block 59. In the present system, however, the system proceeds to block 56, in which the processor uses the comparator 46 to try to match the message with a scenario.
If the comparison of block 56 is successful with a single scenario (Y= 1), the system the proceeds to block 57, in which it tries to match the message with a transaction instance. If the match succeeds against a single transaction instance (Y= 1), then the system has successfully identified a transaction instance for the message, and proceeds to block 54 as before. If the match fails (N), then the system proceeds to block 55, also as before. If the match succeeds against multiple transaction instances (more than one instance) (Y > 1), then the system proceeds to a block 58, in which a temporary transaction instance is created. The possible instances are recorded with the temporary instance, and the ambiguity will eventually be resolved as the various transactions proceed further.
If the comparison of block 56 is unsuccessful (N), the system is unable to identify the message with a transaction, and passes the message on to the message-based EDI system (block 59). The final possibility for block 56 is more than 1 successful comparison (Y > 1); in this event, the system alerts the user (block 60) and then proceeds to block 59 as before.
It will be realized that although most of the blocks of the flow shown in
Fig. 3 involve comparisons, the particular comparisons differ from block to block, and the comparisons involved in processing message-based messages are in general more elaborate than those involved in the transaction-based messages. For the message-based message processing, the comparator is preferably a pattern matching unit which attempts to find a sufficient match between the message and one of the scenarios in store 35 or transaction instance tables in store 37.
For example, for scenario matching the comparator may attempt to match the trading company identified in the message in the store 45 with the trading companies identified in the various scenarios stored in store 35. This matching is of course be carried to the appropriate level (trading partner (company), particular business function within that company, or particular application within that business function) as appropriate.
If a trading partner is identified, then this may determine a scenario.
The comparator 46 may then attempt to match the message to a particular message type in the scenario, by matching the characteristics of the message with those of the various message types in the scenario.
If a matching message type is identified, then the comparator may attempt to match the message with any of the transaction instance tables in store 37 for the possible scenario and message type. If this is successful, then the transaction instance for the message has been successfully identified, and the message is then processed in the manner described above.
If desired, further matching tests may be performed, dependent on the particular message type. For example, if the message is identified as being an invoice message INV described above (Fig. 1), this will have an internal order identifier generated by the supplier 11 which will be identical to the same order number in the preceding dispatch message DISP from the same company. A check can therefore be made for this match.
A message in general will consist of some kind of envelope or header and some contents or data. Thus a message from a message-based EDI system will have a message-based EDI header, and a message which passes through a communication system will have a communications header, and these headers may well contain identifiable information about eg the business origin of the message. The present matching system can usefully endeavour to match on the context information of the message, ie information from the header or headers, as well as the information in the actual data content of the message.
It will be realized that for successful matching, the scenarios and transaction instances must contain an adequate amount of information about the transactions - more than is required for a transaction-based EDI system alone.
The scenarios description format shown in Table I therefore contains a
considerable amount of detail about the transactions - a good deal more than is
contemplated in current proposals for transaction-based EDI systems.
Obviously, the details of this matching can be varied. For example, the
Y > 1 output from block 56 can be followed by block 57, with the transaction
instances for each possible scenario being tested in turn for possible matches.
The outputs from block 57 can remain unchanged, or the Y > 1 output may then be taken to block 59 or 60.
Claims (9)
1 A transaction-based EDI system comprising means (35) for storing scenarios defining possible transactions, instance storage means (37) for storing instances of such transactions, and transaction message processing means (38) for processing messages relating to such instances, and further including preprocessing means (50) for determining whether or not incoming messages are transaction messages or non-transaction messages, characterized in that the preprocessing means include non-transaction message processing means (46; 56, 57) for comparing incoming non-transaction messages with the stored scenarios and instances to attempt to identify the scenarios and instances thereof to which such messages relate.
2 A transaction-based EDI system according to claim 1, characterized in that each scenario consists of a tree of functions (Table I) and is stored in a scenario store (35), which consists of a plurality of units each of which stores a different scenario.
3 A transaction-based EDI system according to claim 2, characterized in that the scenarios include control sequences (Table I, items 4 and 5.3), consisting of sequences of conditions and actions.
4 A transaction-based EDI system according to claim 3, characterized in that the control sequences (conditions and actions) are stored in a separate operations store (36), which consists of a plurality of units each of which stores a different set of conditions and actions.
5 A transactiòn-based EDI system according to any previous claim, characterized in that the scenarios identify trading partners (5.5, Table I) as a trading partner (company) to be specified, a particular business function within that company, and a particular application within that business function.
6 A transaction-based EDI system according to any previous claim, characterized in that the instance storage means (37) comprises a plurality of units each of which stores a different instance table including data indicating the current state of the corresponding transaction instance.
7 A transaction-based EDI system according to any previous claim, characterized in that the non-transaction message processing means (46; 56, 57) include means (56, 57) for distinguishing between match failure (N), a unique match (Y= 1), and a multiple match (Y > 1) of scenarios and/or instances.
8 A transaction-based EDI system according to claim 7, characterized in that the non-transaction message processing means (46; 56, 57) include means (58) for creating temporary transaction instances in response to multiple matches.
9 A transaction-based EDI system according to any previous claim, characterized in that the non-transaction message processing means (46; 56, 57) include a pattern matching unit.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9220379A GB2271002B (en) | 1992-09-26 | 1992-09-26 | Data processing system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9220379A GB2271002B (en) | 1992-09-26 | 1992-09-26 | Data processing system |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| GB9220379D0 GB9220379D0 (en) | 1992-11-11 |
| GB2271002A true GB2271002A (en) | 1994-03-30 |
| GB2271002B GB2271002B (en) | 1995-12-06 |
Family
ID=10722584
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| GB9220379A Expired - Fee Related GB2271002B (en) | 1992-09-26 | 1992-09-26 | Data processing system |
Country Status (1)
| Country | Link |
|---|---|
| GB (1) | GB2271002B (en) |
Cited By (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5710889A (en) * | 1995-02-22 | 1998-01-20 | Citibank, N.A. | Interface device for electronically integrating global financial services |
| WO1998033125A1 (en) * | 1997-01-24 | 1998-07-30 | Extricity Software, Inc. | A system and method for creating, executing and maintaining cross-enterprise processes |
| WO1999037066A1 (en) * | 1998-01-13 | 1999-07-22 | Bright Light Technologies, Inc. | Unsolicited e-mail eliminator |
| WO2000014663A1 (en) * | 1998-09-04 | 2000-03-16 | Balaena Limited | Transactional computer system |
| WO2005053271A2 (en) * | 2003-11-24 | 2005-06-09 | America Online, Inc. | Systems and methods for authenticated communications |
| US7693947B2 (en) | 2002-03-08 | 2010-04-06 | Mcafee, Inc. | Systems and methods for graphically displaying messaging traffic |
| US7694128B2 (en) | 2002-03-08 | 2010-04-06 | Mcafee, Inc. | Systems and methods for secure communication delivery |
| US7779466B2 (en) | 2002-03-08 | 2010-08-17 | Mcafee, Inc. | Systems and methods for anomaly detection in patterns of monitored communications |
| US7831667B2 (en) | 2003-05-15 | 2010-11-09 | Symantec Corporation | Method and apparatus for filtering email spam using email noise reduction |
| US7870203B2 (en) | 2002-03-08 | 2011-01-11 | Mcafee, Inc. | Methods and systems for exposing messaging reputation to an end user |
| US7903549B2 (en) | 2002-03-08 | 2011-03-08 | Secure Computing Corporation | Content-based policy compliance systems and methods |
| US8042181B2 (en) | 2002-03-08 | 2011-10-18 | Mcafee, Inc. | Systems and methods for message threat management |
| US8132250B2 (en) | 2002-03-08 | 2012-03-06 | Mcafee, Inc. | Message profiling systems and methods |
| US8160975B2 (en) * | 2008-01-25 | 2012-04-17 | Mcafee, Inc. | Granular support vector machine with random granularity |
| US8271588B1 (en) | 2003-09-24 | 2012-09-18 | Symantec Corporation | System and method for filtering fraudulent email messages |
| US8578480B2 (en) | 2002-03-08 | 2013-11-05 | Mcafee, Inc. | Systems and methods for identifying potentially malicious messages |
| US10050917B2 (en) | 2007-01-24 | 2018-08-14 | Mcafee, Llc | Multi-dimensional reputation scoring |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8561167B2 (en) | 2002-03-08 | 2013-10-15 | Mcafee, Inc. | Web reputation scoring |
| US20060015942A1 (en) | 2002-03-08 | 2006-01-19 | Ciphertrust, Inc. | Systems and methods for classification of messaging entities |
| US8145710B2 (en) | 2003-06-18 | 2012-03-27 | Symantec Corporation | System and method for filtering spam messages utilizing URL filtering module |
| US7941490B1 (en) | 2004-05-11 | 2011-05-10 | Symantec Corporation | Method and apparatus for detecting spam in email messages and email attachments |
| US8635690B2 (en) | 2004-11-05 | 2014-01-21 | Mcafee, Inc. | Reputation based message processing |
| US7937480B2 (en) | 2005-06-02 | 2011-05-03 | Mcafee, Inc. | Aggregation of reputation data |
| US8010609B2 (en) | 2005-06-20 | 2011-08-30 | Symantec Corporation | Method and apparatus for maintaining reputation lists of IP addresses to detect email spam |
| US7739337B1 (en) | 2005-06-20 | 2010-06-15 | Symantec Corporation | Method and apparatus for grouping spam email messages |
| US8179798B2 (en) | 2007-01-24 | 2012-05-15 | Mcafee, Inc. | Reputation based connection throttling |
| US7779156B2 (en) | 2007-01-24 | 2010-08-17 | Mcafee, Inc. | Reputation based load balancing |
| US7949716B2 (en) | 2007-01-24 | 2011-05-24 | Mcafee, Inc. | Correlation and analysis of entity attributes |
| US8763114B2 (en) | 2007-01-24 | 2014-06-24 | Mcafee, Inc. | Detecting image spam |
| US8185930B2 (en) | 2007-11-06 | 2012-05-22 | Mcafee, Inc. | Adjusting filter or classification control settings |
| US8045458B2 (en) | 2007-11-08 | 2011-10-25 | Mcafee, Inc. | Prioritizing network traffic |
| US8589503B2 (en) | 2008-04-04 | 2013-11-19 | Mcafee, Inc. | Prioritizing network traffic |
| US8621638B2 (en) | 2010-05-14 | 2013-12-31 | Mcafee, Inc. | Systems and methods for classification of messaging entities |
-
1992
- 1992-09-26 GB GB9220379A patent/GB2271002B/en not_active Expired - Fee Related
Cited By (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5890140A (en) * | 1995-02-22 | 1999-03-30 | Citibank, N.A. | System for communicating with an electronic delivery system that integrates global financial services |
| US6058378A (en) * | 1995-02-22 | 2000-05-02 | Citibank, N.A. | Electronic delivery system and method for integrating global financial services |
| US5710889A (en) * | 1995-02-22 | 1998-01-20 | Citibank, N.A. | Interface device for electronically integrating global financial services |
| WO1998033125A1 (en) * | 1997-01-24 | 1998-07-30 | Extricity Software, Inc. | A system and method for creating, executing and maintaining cross-enterprise processes |
| US6519642B1 (en) | 1997-01-24 | 2003-02-11 | Peregrine Force, Inc. | System and method for creating, executing and maintaining cross-enterprise processes |
| WO1999037066A1 (en) * | 1998-01-13 | 1999-07-22 | Bright Light Technologies, Inc. | Unsolicited e-mail eliminator |
| US5999932A (en) * | 1998-01-13 | 1999-12-07 | Bright Light Technologies, Inc. | System and method for filtering unsolicited electronic mail messages using data matching and heuristic processing |
| AU785486B2 (en) * | 1998-01-13 | 2007-10-18 | Symantec Corporation | Unsolicited e-mail eliminator |
| US6957253B1 (en) | 1998-09-04 | 2005-10-18 | Balaena Limited | Transactional computer system |
| WO2000014663A1 (en) * | 1998-09-04 | 2000-03-16 | Balaena Limited | Transactional computer system |
| US7693947B2 (en) | 2002-03-08 | 2010-04-06 | Mcafee, Inc. | Systems and methods for graphically displaying messaging traffic |
| US8132250B2 (en) | 2002-03-08 | 2012-03-06 | Mcafee, Inc. | Message profiling systems and methods |
| US8631495B2 (en) | 2002-03-08 | 2014-01-14 | Mcafee, Inc. | Systems and methods for message threat management |
| US7694128B2 (en) | 2002-03-08 | 2010-04-06 | Mcafee, Inc. | Systems and methods for secure communication delivery |
| US7779466B2 (en) | 2002-03-08 | 2010-08-17 | Mcafee, Inc. | Systems and methods for anomaly detection in patterns of monitored communications |
| US8578480B2 (en) | 2002-03-08 | 2013-11-05 | Mcafee, Inc. | Systems and methods for identifying potentially malicious messages |
| US7870203B2 (en) | 2002-03-08 | 2011-01-11 | Mcafee, Inc. | Methods and systems for exposing messaging reputation to an end user |
| US7903549B2 (en) | 2002-03-08 | 2011-03-08 | Secure Computing Corporation | Content-based policy compliance systems and methods |
| US8042181B2 (en) | 2002-03-08 | 2011-10-18 | Mcafee, Inc. | Systems and methods for message threat management |
| US8069481B2 (en) | 2002-03-08 | 2011-11-29 | Mcafee, Inc. | Systems and methods for message threat management |
| US7831667B2 (en) | 2003-05-15 | 2010-11-09 | Symantec Corporation | Method and apparatus for filtering email spam using email noise reduction |
| US8402102B2 (en) | 2003-05-15 | 2013-03-19 | Symantec Corporation | Method and apparatus for filtering email spam using email noise reduction |
| US8271588B1 (en) | 2003-09-24 | 2012-09-18 | Symantec Corporation | System and method for filtering fraudulent email messages |
| WO2005053271A3 (en) * | 2003-11-24 | 2005-09-29 | America Online Inc | Systems and methods for authenticated communications |
| WO2005053271A2 (en) * | 2003-11-24 | 2005-06-09 | America Online, Inc. | Systems and methods for authenticated communications |
| US10050917B2 (en) | 2007-01-24 | 2018-08-14 | Mcafee, Llc | Multi-dimensional reputation scoring |
| US8160975B2 (en) * | 2008-01-25 | 2012-04-17 | Mcafee, Inc. | Granular support vector machine with random granularity |
Also Published As
| Publication number | Publication date |
|---|---|
| GB2271002B (en) | 1995-12-06 |
| GB9220379D0 (en) | 1992-11-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| GB2271002A (en) | Digitals open-edi scenarios automation process | |
| US6247000B1 (en) | Method and system for confirmation and settlement for financial transactions matching | |
| US20180225668A1 (en) | Method And System For Detecting Fraud | |
| US7840446B2 (en) | Stored value transaction system including an integrated database server | |
| EP0913786B1 (en) | A transaction manager | |
| US8340979B2 (en) | Systems and methods for electronically processing government sponsored benefits | |
| US8060441B2 (en) | Electronic payment and authentication system with debit and identification data verification and electronic check capabilities | |
| US5583759A (en) | Mechanism for expediting the deposit, transport and submission of checks into the payment system | |
| AU2003217958B2 (en) | Method and system for processing credit card related transactions | |
| US8527381B2 (en) | System and method for authorizing third-party transactions for an account at a financial institution on behalf of the account holder | |
| US20030144935A1 (en) | Methods and systems for processing, accounting, and administration of stored value cards | |
| US20120030116A1 (en) | System and apparatus for transaction fraud processing | |
| US11093907B2 (en) | System and method for processing microtransactions | |
| EP1446778A2 (en) | Payment protocol and data transmission method and data transmission device for conducting payment transactions | |
| EP1668453A2 (en) | System and method for seller-assisted automated payment processing and exception management | |
| CN104392340A (en) | Event-drive-based transaction on exchange cargo centralized distribution transportation system | |
| US20040078326A1 (en) | Data processing system | |
| US20030167219A1 (en) | Rules engine having user activated rules of selectable scope and selectable outcomes | |
| WO1998058333A1 (en) | Method and system for confirmation and settlement for financial transactions matching | |
| US20020188549A1 (en) | Selectable market transaction over a network | |
| JP2001028026A (en) | Transaction support system | |
| WO2000030053A9 (en) | A system and method for processing foreign currency payment instructions | |
| CN117132382A (en) | Service center-based supply chain financial platform product center and construction method | |
| Sheppard | The ballot box | |
| JP2002150198A (en) | Proxy collecting system for credit and proxy collecting method therefor |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PCNP | Patent ceased through non-payment of renewal fee |
Effective date: 19990926 |