Schema-based dynamic parse/build engine for parsing multi-format messages

• US 20070005613A1
• Filed: 06/29/2005
• Published: 01/04/2007
• Est. Priority Date: 06/29/2005
• Status: Active Grant

• Current Assignee: Visa USA, Inc. (Visa, Inc.)
• Original Assignee: Visa USA, Inc. (Visa, Inc.)
• Inventors: Carlson, Mark, Singh, Kamlakar, Singh, Thakur, Devassey, Shajen, Garrison, Sara
• Granted Patent: US 7,694,287 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06Q 20/40 Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
• CPC Class Codes: G06Q 30/06 Buying, selling or leasing transactions
• CPC Class Codes: H04L 51/046 Interoperability with other network applications or services
• CPC Class Codes: H04L 51/066 Format adaptation, e.g. format conversion or compression
• CPC Class Codes: H04L 69/03 Protocol definition or specification protocol conformance testing H04L1/244
• CPC Class Codes: H04L 69/22 Parsing or analysis of headers

Abstract

A parse/build engine that can handle multi-format financial messages. The engine converts the different format messages into a common format, and the common format message is then processed by the business service application. A parser examines the message and determines an appropriate schema for the particular format of message received. The schema is a data structure in a schema registry that includes a grammar structure for the received format as well as pointers to handlers for converting the different fields of the message into the internal message format using the grammar structure (the “grammar” can include field sequence, field type, length, character encoding, optional and required fields, etc.). The handlers are individually compiled. As formats change, new formats or changes to old formats can be dynamically added to the parse/build engine by loading new schema and handlers.

Claims

1. A method for parsing messages into an internal message format, comprising:

receiving a message comprising a plurality of fields;

providing a plurality of handlers, each handler being code for parsing at least one of said fields using grammar for said field, each said handler being separately compiled;

determining one or more schemas for the fields of the message, each schema pointing to one of said handlers and containing a grammar definition for one or more fields; and

translating the one or more fields of the message into said internal message format using said handlers.

2. The method of claim 1, wherein said internal message format comprises a hierarchical structure of possible fields, and wherein said parsing is only done for the fields in said message, and only corresponding fields in said internal message format are populated.

3. The method of claim 1, wherein each message field included in said schema is identified by an object ID, said object ID being an index pointing to a particular location in said internal message format.

4. The method of claim 1, further comprising dynamically loading said one or more schemas without recompiling the other schema and handlers.

5. The method of claim 1, further comprising determining a subsequent schema from said translating, and iterating the process of claim 1 for said subsequent schema on said message.

6. The method of claim 1, further comprising processing said message in said internal message format by a business services application.

7. The method of claim 6 wherein said processing by said business services application includes modifying values in said fields.

8. The method of claim 7, further comprising:

determining a second set of one or more schemas for building said message in said internal message format, after said processing, into an external message format;

determining field definitions and handlers in the second set of one or more schemas that correspond to the one or more fields included in said message; and

building the one or more fields of the external message format using said handlers.

9. The method of claim 1, wherein the message comprises a financial transaction.

10. The method of claim 1 further comprising:

determining any necessary fields other than the one or more fields in the message that are required for an output message; and

adding the necessary fields other than the one or more fields in the message to the internal message object, if any were determined, wherein the one or more fields and necessary fields are the only included fields populated in the internal message object.

11. An engine configured to parse/build messages, the engine comprising:

a plurality of handlers, each handler being code for parsing at least one of the fields of a received message using grammar for said field, each said handler being separately compiled; and

a plurality of schemas for different types of messages, each schema pointing to one of said handlers and containing a grammar definition for one or more fields of a message.

12. The engine of claim 11, further comprising an internal message format object, said handlers being configured to populate the internal message format object with only fields found in the message and/or required fields.

13. The engine of claim 11, further comprising a business service module configured to process the message in the internal message format.

14. The engine of claim 13, wherein the engine is configured to build a message from the internal message format, the engine comprising:

a second set of one or more schemas, the second set of schemas including field definitions usable in parsing fields in the message from the internal message format to an external message format; and

one or more handlers for the second set of schemas, the handlers being configured to parse fields the message from the internal message format using the field definitions in the second set of schemas to the external message format.