GB2405062A

GB2405062A - Protocol conversion via intermediate protocol with message storage and verification

Info

Publication number: GB2405062A
Application number: GB0313613A
Authority: GB
Inventors: Brian Bolam; Stephen Byrne
Original assignee: OMPROMPT Ltd
Current assignee: OMPROMPT LIMITED
Priority date: 2003-06-13
Filing date: 2003-06-13
Publication date: 2005-02-16
Also published as: GB0313613D0

Abstract

Protocol/format conversion unit (200) that allows various business people (eg. shippers (S1-2) and truckers (T1-3) to communicate). The communication links may be secure. The protocol translator receives the message in the sender's format, converts it into a common intermediate format and thence into the receiver's format. Multicasting with separate conversion for each recipient is possible. Possible formats are EDI, XML, SMS, EDIFACT, ANSI 12 etc. The system requires user registration with source and destination protocol information. The system keeps a record and copy of messages and it can verify messages to ensure that they have the correct content. In the event of an error a message to the sender or automatic correction of minor faults can be initiated.

Description

À e. À.. . e. À.e: À À À À . . À À À À À À À À À À À À À À À À À . À À À

À 1 2405062

DATA INTERFACE

The present invention relates to a data interface and in particular a data interface capable of translating data input into it in a first format into output data in a second format.

Most contemporary businesses use computerized systems to keep information about their clients and to manage incoming or outgoing orders or information requests. However, different businesses use disparate systems, whether packaged or bespoke, which struggle to exchange data. Accordingly data transfer between businesses is often problematic.

This problem has long been recognised and has resulted in the proliferation of 'data and message standards' such as EDI, EDIFACT, XML etc. These 'standards' have themselves been modified by individual users and user communities to the point at which it becomes necessary to translate even 'standard' message exchange between systems. Further, change is the reality of business and it follows therefore that data exchange is in a constant state of flux. As a consequence, extensive effort is required to integrate, deploy and support linked systems.

In order to ease these problems companies may attempt to coordinate into a community which uses a common system, replacing their earlier individualized systems. This however can be expensive and may not always be practicable.

À.. À.e À.- À.. : À À À . . À ÀÀ ÀÀÀ À ÀÀ À À À À À À À À e. . À À Alternatively businesses may attempt to provide interfaces for many different formats or attempt to map one format into another. Software has been developed to reduce this effort and packages and services are available to undertake this work. However, these packages are not automated and thus many hours of skilled labour is required using drag and drop technology to set up the package so that inbound messages in a particular format may be translated into another specified format. Each time the system is adapted to translate messages in another form much time and expense is required to adapt the system to translate messages in the new form. Such systems however still breakdown where there is a mistake in the inbound data and either fail to accept the message or translate the message incorrectly.

It is thus an object of the present invention to provide an improved method of transferring messages from one form into another.

According to a first aspect of the present invention there is provided a method for interfacing between an input data set in a first format and an output data set in a second format comprising the steps of: analysing the syntax of the input data set; separating the individual data fields in the input data set; extracting the data in each individual field; arranging the extracted data in accordance with the second format and thereby generating an output data set.

According to a second aspect of the present invention there is provided an interface according to the first aspect of the present invention having À.e.e À e. Àe: À . À À À . À À À À À À À À À À À À À À À À À.e À . . - 3 i means for receiving an input data set, means for processing the inbound data set in order to generate an output data set and means for exporting the output data set.

Such an interface allows a system to deal with input data sets in a format that is not supported by the system by translating them into a format that is supported by the system.

Preferably, the ontology for analysing the message syntax, separating the individual data herds and thus extracting the data in each individual field is generated by Intelligent AgenVKnowledge Management (IA/KM) technology.

Most preferably the IA/KM technology is similar to that available from MagentA Corp Ltd. Preferably the interface may be adapted to analyse and translate input data sets in any desired format. Most preferably the interface is additionally adapted to export an output data set in any desired format. In order to translate from an input data set in a first format to an output data set in a second format, the interfacing method may include the steps of translating the input data in the first format into a common format and then translating the data in the common format into the second format.

Particular formats that may be translated using such a system include but are not limited to EDI, XML, ASCII, SMS, Voice, VML, Fax and similar.

The particular formats mentioned herein include any related formats and particular variations upon these formats. In particular EDI as defined herein À e. e. À.. À.e: À À À À À À À À Àe À . e À À À À À À À e. * À À - 4 I covers a number of subformats including but not limited to ANSI 12, HL7, SPEC 2000, UN/EDIFACT, EDIBUILD, EDICON, EMEDI and similar; XML as defined herein includes any such subformats as may exist including but not limited to ASCI X12 and UN/CEFACT.

The interface of the present invention may also be adapted to work with a number of database formats for instance to provide a means for databases in two different formats to be merged into a single database either in the same format as one of the original databases or in a third format Alternatively, the interface can be positioned between a user and the two l 0 databases in order that user queries can be translated by each database.

Preferably in addition to such data mapping that the interface is able to perform as described above, it is additionally operative to provide message mapping. In particular it is adapted so as to be able to receive an inbound message in any format and translate the inbound message into an output message in a desired format. Additionally and preferably, the interface is adapted to provide message switching that is to receive an inbound message from a sender in a first format, translate the letter into a second format and forward the message to a desired recipient. There may be one or more desired recipients and the interface may act to translate the message into 2() different formats for each individual recipient if desired. Messages received from one sender may always be sent to one or more particular recipients or may alternatively only be sent to recipients specified in the message.

Messages may be sent to recipients only in a particular specified format or À À e À e À À À e À À À e À e e Àe À ..

À À À a À À e À.. À À may be sent in a one of a variety of specified formats depending on the data in the message or other criteria.

The interface may further act to send messages to the sender confirming translation or receipt of the senders initial message. Preferably the interface translates all inbound messages into a common format and then translates messages from the common format into the desired output message format. The interface preferably stores copies of inbound messages either in their original format or in the common format or in both formats.

Preferably the method of interfacing additionally includes the step of verifying that the content of the input data set or message conforms to standard or expected criteria. If the message does not conform to the criteria an error message may be sent to the sender and or another authority. The error message may request that the sender or the authority check and or resend the message. The error message may additionally include information relating to why the message was rejected.

Alternatively or additionally if a message fails to conform to the criteria, the interface may attempt to correct minor errors and if successful may notify the sender of the correction and or some other authority. The interface may be required to await acceptance of the correction from the sender or other authority before forwarding the corrected message to the desired recipients.

This verification and or correction is useful in situations wherein documents are intended to contain identical information but for some reason e. À . e. . : À À À À À À À À À À À À e.

À e À À À e. . À - 6 do not. For instance in the transport industry a bank will not clear a letter of credit if its details do not exactly match those on the associated bill of landing.

The verification and or correction described above can be used to either flag up any problems as early as possible or to correct minor errors to avoid the occurrence of such problems.

Preferably records are generated and stored relating to each message received from a sender and forwarded to a recipient. Preferably the records include some or all of the following: the format of the inbound message and or the outbound message, the time and date of receipt of a message, a log of any errors identified in the message, identification of the sender, identification of the recipient or recipients.

Preferably in order to accept a new sender of messages, the new sender is required to take part in an automated registration process. They must provide a standard set of details for the interface and then send a message to the interface in their preferred format. The message can then be stored as a calibration standard to be used to aid future translation of messages from the sender.

Preferably the above described interface may be adapted to provide a messaging interface for a group of businesses. In particular, the above may be used to form a messaging interface for the logistics industry. Preferably such an interface may be embodied by a plurality securely connected network service modules. Each network service module may be a peer-to-peer service À -. À e. -e Àe: À . . . . . À . . . À À À À À À À À À e. À module comprising a hub linking two communications servers, a database t server and a processing server.

In order that the invention be more clearly understood one embodiment I is described further herein, with reference to the accompanying drawings in which: Figure 1 shows a network interface according to the present invention for interfacing messages between a number of truckers and a number of shippers; Figure 2 shows a schematic block diagram of the interface of figure 1; and Figures shows a flow diagram demonstrating the use of the interface of figure 1.

Referring now to Figure 1 an interface 100 according to the present F invention is in use in the transport logistics industry. The interface allows two shippers S1, S2 to send messages formatted according to their preferences to any or all of a number of truckers T1, T2, T3 and have the truckers T1, T2, T3 receive the messages in their own preferred format. The truckers T1, T2, T3 can thus be coordinated such that which ever of them is available may come and collect a load from one of the shippers S1, S2 as soon as the load has landed. In order to achieve this the interface translates incoming messages from the format they are received in to the format that the intended recipient À À À c À À À À À e c c À C À C c c À e À c C C À c en À À c desires to receive messages in. The interface 100 in figure one is shown acting to translate messages in between five different formats (ANSI X12, EDIFACT, SMS, XML, Fax) but may however be adapted to translate messages input into it in any readable format into other readable format for output. In particular for the logistics industry the interface 100 is capable of translating between many variations upon standard EDI or XML and voice messages.

The interface 100 is typically embodied by a network of securely connected network service modules 200, which may be peer-to-peer service modules. Each peer-to-peer service module 200 typically comprises a hub 210 linking two or more communications sewers 202, 204, a database server 206, and a processing server 208.

Referring now to figure 2, a schematic block diagram of the interface is shown. Incoming messages 102 are held in a buffer 104 until sufficient processing space is available, once space is available the incoming message 104 is passed a translation engine 106. The translation engine 106 translates the message using IA/KM technology in conjunction with stored protocols and formats 108 and stored knowledge 110 into a single common data format.

The translation is generated by analysing the message syntax in order to separate the individual data fields and then extract the data stored in each individual field in order to thus generate a message in the common format containing all the data of the incoming message 102.

À À À À À À À À. À À c À À À : The incoming message is stored in its original format in a historical message database 112 and in the common format in a common message database 116. Each common format message is verified by a verification engine 114 to ensure that the data contained therein is in accordance with s expected values. In the event that data inaccuracies are detected, the verification engine 114 may attempt to correct these by analyzing previous stored messages from the sender to obtain previous or expected values. If this is not possible, the verification engine 114 may request user intervention to correct the data. In the event of any detected data anomaly, the system will create a log which may be viewed by an authorized user and which may be used to generate outbound messages back to the sender of the incoming message 102.

If the information in the incoming message 102 is successfully verified, the common format message is output to the outbound message generator 118. The outbound message generator determines to which recipients the message is to be sent and looks up the recipients addresses in the recipients address database 122 and the recipients preferred message format in the recipients preferred formats database 120. the outbound message generator then generates a correctly addressed outbound message 124 in the recipients preferred format which is then transmitted to the recipient. Typically the recipient will then confirm receipt of the message.

Many-to-one, one-to-one and one-to-many relationships between incoming 102 and outgoing messages 124 can be established between r À À À r À À e À À c À À Àe À I. À À e À e ace e e À - 1 0 particular senders and recipients if desired. The interface ontology contains a section which codifies these relationships and which is used to generate the appropriate outbound messages 124. Outbound messages 124 will be triggered only when the full set of clean data required for that process has been received by the system.

Multiple outbound messages 124 are only triggered when the data for the complete set has been received and verified. The interface 100 will not generate outbound messages 124 on an incomplete data set, even though the subset of data required for that outbound message 124 has been received and verified.

The interface 100 automatically generates outbound messages 124 for known recipients based on their known preferences however, the interface may generate messages in an alternative format and protocol for any user in the event that a receipt is not received for the first outbound message 124 or for any other requested reason. Once a receipt has been received for a complete set of outgoing messages 124, then the original incoming message may be removed from the local databases 112, 1 16 if desired.

In order to enable users to send and receive messages via the interface they must go through a registration process and provide a standard set of company name and contact details. They will then have to specify which messages, of which type, are sent to specific trading partners. Next they will be required to send a test message in their preferred format(s) and À::: À À:. ::- ::. :. À:. :.: :: A. - 11 protocol(s). This is used as a calibration device to establish the standard for all future communications. If the receiving trading partner is also new to the service also then they too must register for the service and send a sample message in the format they wish to receive. This is used to help create the translation 'map'. Once the sender has successfully sent a test message it is translated through the common data format into the recipient's format and forwarded to the recipient. Successful receipt and validation must be confirmed before the 'map' is declared operational and the sender can begin live' transmissions.

If a sender attempts to send a message to a new recipient trading partner who is not registered, the interface 100 sends an error notification to the sender. The interface 100 will additionally check to see if there is a registered recipient with similar details and may suggest to the sender that they intended to send the message to this recipient instead. Alternatively if the recipient details are correct but the recipient is not yet registered then the e- mail may also contain a hot link to a registration screen.

The data required for registration typically comprises the following: Code - 10Alphanumeric(A/N)(e.g. FOXTRANS) Validation Code 1 - 4 A/N (e.g. 6950) Validation Code2 - 4 A/N (e.g. 1074) Name/Description - 40 A/N (e.g. Fox International Transport) À À À À À À À e À À e À À e- À - 1 2 Address - 40 x 5 A/N Post/Zip Code - 12 A/N Telephone - 20 A/N Interface Type 1 Voice (code linked to standing data) Interface Type 2 - XML (code linked to standing data) Interface Type - EDi etc. etc. When incoming messages 102 arrive they are validated against these details by the validation engine 114 and then passed to the outbound message generator 118 along with data related to the intended destination of the message.

The interface 100 may additionally be provided with means for storing and cross-referencing all messages passed through the interface 100. In this manner, if an order message and a subsequent dispatch message are sent via the interface they can be cross-referenced and verified. A further notice of collection or receipt will also be cross-referenced by the interface 100.

The data stored by the interface may be stored in any suitable database format such as csv and managed by any suitable system such as SQL. Other formats or systems may however be substituted if desired.

e À À À C À À À À À À À .. À À À - e.. À .e see ! - 13 Messaged may be stored in a message log database if desired, which records all messages sent via the interface. The contents of the message log may be exported to an external text file for analysis if desired. Additionally or alternatively reports of activity may be compiled and exported to suitable external software such as Microsoft Excel (registered trade mark).

An example of the use of this interface for communicating an update of the progress of a shipment being transported by a user is shown in figure 3. In particular this example relates to voice recognition over a telephone connection (cellular or landline) but other messages in other formats may alternatively be used.

At s300 the user must give an identification code. If the code is valid he progresses to s301 if the code is invalid he is prompted once more to give a valid identification code. At s301 the user is prompted to enter an order number if this is valid the user progresses to s302 wherein the interface can identify a matching order. If this number is not valid the user is prompted to try again.

At s302 the user may then enter an update of the position of the order and depending on the choice of update may be asked for supplementary information at s303. For instance if the order is late, s303c then the user is prompted to give an estimated time of arrival, if the order is delivered s303b, the user is asked to confirm the condition of the delivery (clear/short/damaged/refused). If however the order has just been collected, À. .. .e A: À À À À e À - À À À À À À À À À e À À À À À.- À À À - 14 s303a a confirmation message to this effect is generated. The user then progresses to s304.

At s304 the user is asked whether they wish to update any further transactions. If they do they return to s301. If they do not, the connection is terminated.

It is of course to be understood that the invention is not to be restricted to the details of the above embodiment which is described by way of example only. À: ..

Claims

À À À e CLAIMS

1. A method for interfacing between an input data set in a first format and an output data set in a second format comprising the steps of: analysing the syntax of the input data set; separating the individual data fields in the input data set; extracting the data in each individual field; arranging the extracted data in accordance with the second format and thereby generating an output data set.

2. A method as claimed in claim 1 wherein, the ontology for analysing the message syntax, separating the individual data fields and thus extracting the data in each individual field is generated by Intelligent AgenVKnowledge Management (IA/KM) technology.

3. A method as claimed in any one of claims 1 to 2 wherein, the method is used to translate messages in EDI, XML, ASCII, SMS, Voice, VML and Fax formats.

4. A method as claimed in any one of claims 1 to 3 wherein, the method is used to translate messages in ANSI 12, HL7, SPEC 2000, UN/EDIFACT, EDIBUILD, EDICON, EMEDI, ASCI X12 and UN/CEFACT formats.

5. A method as claimed in any one of claims 1 to 4 wherein, the method is adapted to analyse and translate input data sets in any desired format.

6. A method as claimed in any one of claims 1 to 5 wherein, the method is additionally adapted to export an output data set in any desired format.

À: e. ee.À . À . .e À À À : À . À : . . À

7. A method as claimed in any one of claims 1 to 6 wherein, in order to translate from an input data set in a first format to an output data set in a second format, the interfacing method may include the steps of translating the input data in the first format into a common format and then translating the data in the common format into the second format.

8. A method as claimed in any preceding claim wherein, the method includes the steps of receiving an inbound message in any format and translating the inbound message into an output message in a desired format.

9. A method as claimed in claim 8 wherein, all inbound messages are translated into a common format.

10. A method as claimed in claim 9 wherein, all output messages are translated from the common format into the desired output message format.

11. A method as claimed in claim 8 or claim 9 wherein, the method includes the step of storing copies of inbound messages either in their original format or in the common format or in both formats.

12. A method as claimed in any one of claims 8 to 11 wherein, the method of interfacing additionally includes the step of verifying that the content of the input data set or message conforms to standard or expected criteria.

13. A method as claimed in claim 12 wherein, the method of interfacing additionally includes the step that if the message does not conform to À: ee.

À Àe À À the criteria an error message is sent to the sender and or another authority.

14. A method as claimed in claim 13 wherein, the error message requests that the sender or the authority check and or resend the message.

15. A method as claimed in claim 14 wherein, the error message additionally includes information relating to why the message was rejected.

16. A method as claimed in any one of claims 8 to 15 wherein, the method includes the step of if a message fails to conform to the criteria, correcting minor errors and if successful notifying the sender and or some other authority of the correction.

17. A method as claimed in claim 16 wherein, acceptance of the correction from the sender or other authority must be received before forwarding the corrected message to the desired recipients.

18. A method as claimed in any one of claims 8 to 17 wherein, a new sender of messages is required to take part in an automated registration process.

19. A method as claimed in claim 18 wherein, the new sender must provide a standard set of details for the interface and then send a message to the interface in their preferred format.

20. A method as claimed in claim 19 wherein, the message is stored as a calibration standard to aid future translation of messages from the sender. ee. e

e À e

21. A method as claimed in any one of claims 8 to 20 wherein, the output message is forwarded to a desired recipient.

22. A method as claimed in claim 21 wherein, there are one or more desired recipients

23. A method as claimed in claim 22 wherein, the message is translated into different formats for each individual recipient.

24. A method as claimed in claim 22 or claim 23 wherein, messages received from one sender are always sent to one or more particular recipients.

25. A method as claimed in claim 22 or claim 23 wherein, messages received from one sender are only sent to recipients specified in the message.

26. A method as claimed in claim 24 or claim 25 wherein, messages are sent to recipients only in a particular specified format or are sent in a one of a variety of specified formats depending on the data in the message.

27. A method as claimed in any one of claims 8 to 28 wherein, the method further includes the step of sending messages to the sender confirming translation or receipt of the senders initial message.

28. A method as claimed in any one of claims 8 to 27 wherein, records are generated and stored relating to each message received from a sender and forwarded to a recipient.

Àe;. ce. À : À-e.. :::.

À:.-. À ::.

29. A method as claimed in claim 28 wherein, the records include some or all of the following information: the format of the inbound message and or the outbound message, the time and date of receipt of a message, a log of any errors identified in the message, identification of the sender, identification of the recipient or recipients.

30. A method as claimed in claim 1 wherein, the method is used to merge databases in two different formats into a single database either in the same format as one of the original databases or in a third format.

31. A method as claimed in claim 30 wherein, the method is used to translate user queries into the correct format for a database.

32. An interface operating in accordance with the method of any one of claims 1 to 31 having means for receiving an input data set, means for processing the inbound data set in order to generate an output data set and means for exporting the output data set

33. An interface as claimed in claim 32 wherein, the interface is adapted to provide a messaging interface for a group of businesses.

34. An interface as claimed in claim 33 wherein, the interface is used to form a messaging interface for the logistics industry.

35. An interface as claimed in any one of claims 32 to 34 wherein, the interface is embodied by a plurality of securely connected network service modules.

À .: An. :: a.. a-e

36. An interface as claimed in claim 35 wherein, each network service module is a peer-to-peer service module comprising a hub linking two communications servers, a database server and a processing server.

37. An interface as claimed in claim 32 wherein, the interface is positioned between a user and the two databases in order that user queries can be translated by each database.