Information
-
Patent Grant
-
6507856
-
Patent Number
6,507,856
-
Date Filed
Tuesday, January 5, 199925 years ago
-
Date Issued
Tuesday, January 14, 200321 years ago
-
Inventors
-
Original Assignees
-
Examiners
- Feild; Joseph H.
- Singh; Rachna
Agents
- F. Chau & Associates, LLP
-
CPC
-
US Classifications
Field of Search
US
- 707 513
- 707 500
- 707 75
- 707 1
- 707 2
- 707 3
- 707 10
- 707 1041
-
International Classifications
- G06F1730
- G06F700
- G06F1700
-
Abstract
A system for exchanging and merging messages over a network includes a server accessible by a plurality of remote browsers for transmitting a template including fields for information entry and a business system accessible by the server for generating a return document pursuant to information entered in the template on the browsers. The business system includes a first parser for receiving a document from a browser, the document including information about data characteristics of information entered into the template, and a second parser for receiving information about data characteristics to provide a return template. A merging algorithm is implemented to merge the document with the return template for providing a return document to the browser having portions of the return template with data entered therein.
Description
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to automated document information exchanges and, more particularly, to a system and method for automating document exchange and merging.
2. Description of the Related Art
Businesses and trading partners exchange business documents for records of transactions. Traditionally, these exchanges were performed by mail or courier thereby requiring paperwork and introducing delays. With advancements in network technologies and the development of improvements in the Internet more business is transacted “on-line”.
There are many instances where documents of one type are issued in response to documents of another type. For example, suppliers can issue invoice documents based on received purchase order (PO) documents, or issue a reply to request for quote documents based on received request for quote documents, from prospective buyers. Developing solutions for any such document pair may be tedious, and hard to maintain, especially if the solution include manual document production and record keeping.
Therefore, a need exists for a business process automation system for dynamically exchanging and merging documents.
SUMMARY OF THE INVENTION
A system for exchanging and merging messages over a network includes a server accessible by a plurality of remote browsers for transmitting a template including fields for information entry and a business system accessible by the server for generating a return message pursuant to information entered in the template on the browsers. The business system includes a first parser for receiving a message from a browser, the message including information about data characteristics of information entered into the template, and a second parser for receiving information about data characteristics to provide a return template. A merging algorithm is implemented to merge the message with the return template for providing a return message to the browser having portions of the return template with data entered therein.
In alternate embodiments, the information entered into the template is preferably associated with tag names and the means for merging may include a name tag map for correlating tags names of the template with tag names of the return template. The message may include information having a name and a value and the first parser parses the first message into name and value pairs. The first message may be written in an extensible markup language (XML) and the data type information may be in a corresponding data type definition format (DTD). The means for merging may include a constraint set for identifying tag names used in multiple instances. The constraint set may provide higher level tag names to identify the tag names used in multiple instances. The network is preferably the Internet. The first parser parses the first message to preferably provide tag name and value information in a format of one of a document object model tree and an array.
A system for exchanging and merging extensible markup language (XML) documents over the Internet includes a server accessible by a plurality of remote browsers for transmitting a template including fields for information entry, and a business system accessible by the server for generating a return XML document pursuant to information entered in the template on the browsers. The business system includes a first parser for receiving a first XML document and a corresponding data type definition(DTD)file from a browser, a second parser for receiving a return data type definition(DTD)file to provide a return template and means for merging the first XML document with the return template for providing the return XML document to the browser having portions of the return template with data entered therein corresponding to at least some of the information entered into the template.
In alternate embodiments, the information entered into the template is preferably associated with tag names and the means for merging includes a name tag map for correlating tag names of the template with tag names of the return template. The first XML document may include information having a name and a value and the first parser parses the first XML document into name and value pairs. The means for merging may include a constraint set for identifying tag names used in multiple instances. The constraint set may provide higher level tag names to identify the tag names used in multiple instances. The first parser preferably parses the first XML document to provide tag name and value information in a format of one of a document object model tree and an array.
A program storage device readable by machine, tangibly embodying a program of instructions executable by the machine to perform method steps for merging and exchanging documents over a network, the method steps includes providing an input document including name tags and data information in a predetermined form, compiling the input document to arrange the names and data into an input document format, providing a return document format including name tags, comparing the name tags of the input document and the name tags in the return document format to match equivalent name tags and merging the input document format with the return document format to provide a return document with portions filled in with at least some information included in the input document.
In alternate embodiments of the program storage device, the step of providing an input document may include the step of providing an input document on a template having data field therein for data entered, the data fields being labeled with name tags to identify the data. The step of compiling may include the step of parsing the input document into name tag and value pairs in one of a node tree format and an array format. The step of comparing the name tags may include the step of providing a name tag map to correlate equivalent name tags. The step of providing a return document format may include the step of providing looping information to identify name tags according to a constraint set such that name tags employed in multiple instances are identified. The constraint set may provide higher level tag names to identify the tag names used in multiple instances.
These and other objects, features and advantages of the present invention will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.
BRIEF DESCRIPTION OF DRAWINGS
The invention will be described in detail in the following description of preferred embodiments with reference to the following figures wherein:
FIG. 1
depicts a sample XML document encoding a purchase order for use with the present invention;
FIG. 2
is a data type definition (DTD) for the sample purchase order shown in
FIG. 1
for use with the present invention;
FIG. 3
is a graphical structure of the DTD of
FIG. 2
for use with the present invention;
FIG. 4
is a sample purchase order layout according to the information of
FIGS. 1 and 2
;
FIG. 5
is a flow/block diagram of a dynamic XML document exchange system, for business process automation in accordance with the present invention;
FIG. 6
is a schematic diagram showing a document exchange for an Internet purchase order/invoice document exchange in accordance with the present invention;
FIG. 7
is a flow diagram shown in greater detail of the dynamic XML document exchange system depicted in
FIG. 5
in accordance with the present invention;
FIG. 8
is an example of a XML name tag map table, as depicted in
FIG. 7
in accordance with the present invention;
FIG. 9
is an example of a constraint set table, as depicted in
FIG. 7
in accordance with the present invention;
FIG. 10A
is an illustrative array template structure as depicted in
FIG. 7
in accordance with the present invention;
FIG. 10B
is an illustrative tree template structure as depicted in
FIG. 7
in accordance with the present invention; and
FIGS. 11A-11E
are a flow diagram showing a merge algorithm which operates on the tree template as depicted in FIG.
10
B.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
The present invention relates to automated document information exchanges and, more particularly, to a system and method for automating document exchange and merging. The document exchange and merge preferably includes the use of extensible Markup Language (XML) documents. An XML name tag map table design, Document Object Model (DOM) tree parsing or serialization, return document template generation, constraint set design, and a document merging algorithm are included in an automated document merging and exchange system, in accordance with the present invention. Although described in terms of XML, DTD and DOM languages/codes, other languages/codes may be implemented in accordance with the invention.
Business documents may be presented by extensible Markup Language (XML) for Internet transmission and World Wide Web access. A business process automation system may receive an XML message or document and its corresponding Data Type Definition (DTD), and generate a return XML message based on a return document DTD, with certain fields pre-filled from the first XML message.
The XML name tag map table matches a relevant name tag of document fields of a first document to the corresponding name tag of a second document's (or return document's) fields. The name tag map table may be created by standard editors or tools. Higher level qualifiers or name tags may be needed to uniquely identify the specific name tag for potential ambiguity due to repetitive usage of the same name throughout the transaction set.
DOM tree parsing or serialization prepares the first document in a suitable data structure, such as tree or array, for efficient processing and matching. The XML parser can be embedded in a web browser such as the Microsoft® XML parser, or run as a server side application such as IBM Tokyo Research Laboratory XML Parser for Java. The XML parser may receive the first XML document and its DTD, and generate a DOM tree or a serialized name/value pair array. Due to looping, the same tag names may occur multiple times in the DOM tree or the array. Looping includes reusing a format for data entry, for example, a purchase order may include more than one item to be ordered. The same code is used to generate fields for data entry on a template, looping generates the fields needed.
Using parsing techniques, a DTD parser may be created for generating a return document template or a return document DTD parse tree, which can assist the document merge algorithm to prepare the return XML document. The DTD parser transforms the DTD with repeatable and optional fields into a template in tree structure or serialized array with special markers around loop header nodes or name tags. Optional fields may include a second business address or phone number, for example.
In one case, the automation system, in accordance with the invention, allows a fixed amount of iterations for certain loop tags, e.g., always displaying special service and charge fields, or in another case allowing a variable number of iterations, e.g., the number of items sold in the transaction is unknown and is dependent on the number of items recorded on the first document. The first case is resolved preferably by using a constraint set, which defines the name of the loop tag, and an integer indicating a number of fixed occurrences. Higher level qualifiers or name tags may be used to distinguish the same tag names that are used multiple times. The latter case can be resolved by reserving only one iteration for such type of loops in the template, and expanding the loops (with new name tags and values) during the run-time by matching the actual number of iterations in the first document. The special markers in the template are introduced to confine the loop to expand one iteration. Similar to the XML name tag map table, the constraint set may be constructed by standard editors or tools.
A document merging algorithm, in accordance with the invention, generates a return XML document, by either sequentially scanning the name tags from the template in an array structure, or recursively traversing the DTD tree node from the template in a tree structure, to match their counterparts in the XML DOM tree or the serialized array using the XML name tag map table. If a match is found, the corresponding value of the first XML message is retrieved and treated as the value associated with the current name tag. When a name tag with the special marker is detected, a loop is found or revisited, in which case the loop header tag is checked with the constraint set for loop count, or the tags inside the loop are matched against the XML DOM tree or serialized array, to determine if the content of the loop should be generated again. The algorithm handles both variable number and fixed number of loop iterations. Referring now to the drawings in which like numerals represent the same or similar elements and initially to
FIG. 1
, a sample XML document is depicted for encoding a Purchase Order (PO), where there are two items ordered, i.e., item Nos. 0001 and 0002. Each item includes information code which begins at line items (LineItem)
20
and (LineItem)
25
, respectively. Line item
20
includes detailed product descriptions, service types, and ship to address, and the line item
25
includes only key information, such as price, quantity and unit. Other information is included, for example, address information
21
and a total amount of the purchase
23
.
Referring to
FIG. 2
, a Data Type Definition (DTD) for the sample PO of
FIG. 1
is shown. DTD defines
26
data elements (
0
-
25
). The Address data element
6
is referred by the data elements Purchase Order
0
and LineItem
5
, where LineItem itself is referred by PurchaseOrder
0
as indicated by the numeral
30
. Repeatable data elements are marked with a “*”, e.g., the LineItem indicated by
30
referred by PurchaseOrder
0
, and optional data elements which can occur zero or once are marked with a “?”, e.g., AdditionalName indicated at numeral
32
referred by Address
6
. The “#PCDATA”
34
represents parsed character data. The style sheet written in, for example, Javascript, XSL, or CSS provides a way to render the XML document (
FIG. 1
) to a browser (see FIG.
4
).
Referring now to
FIG. 3
, the DTD of
FIG. 2
is depicted in a graphical tree structure. Oval-shaped nodes
40
represent data elements. Each data element corresponds to the data elements of the same number (or symbol) as indicated in FIG.
2
. Arrows
42
from data elements (for example, data element X, not shown) to another data element (for example data element Y, not shown) are drawn, if X referred Y during X's definition. A special marker, “*”, within a node represents a repeatable data element, for example element
44
, and a “?” within a node represents an optional data element
46
, i.e., a data element which may not be needed for processing the PO, such as a second street address. The Address data element
6
has been referred twice, once by PurchaseOrder
0
and once by LineItem
5
, respectively. The DTD graph of
FIG. 3
is employed to simplify data processing in accordance with the invention. In this way, data elements may be mapped and visited more efficiently.
Referring to
FIG. 4
, data elements and tag/label names from
FIG. 1
are associated and placed in data/information entry fields in an illustrative document layout.
It should be understood that the elements shown in
FIGS. 5-11
may be implemented in various forms of hardware, software or combinations thereof. Preferably, these elements are implemented in software on one or more appropriately programmed general purpose digital computers having a processor and memory and input/output interfaces. Referring now to the drawings in which like numerals represent the same or similar elements and initially to
FIG. 5
, a flow/block diagram for the business process automation system
100
is shown according to the present invention. An exchange/merge system
105
receives an XML message
125
and its DTD
115
, and generates a return XML message
145
based on the return message DTD
135
. Other languages/codes may be used in addition to or instead of XML and/or DTD.
Referring to
FIG. 6
, an automatic Internet purchase order (PO) and invoice document exchange system/method
200
is shown. Although described by way of example for the Internet, system
200
may include other network systems, for example a local area network (LAN), a wide area network (WAN), etc.
In the illustrative example shown in
FIG. 6
, a buyer runs a web server
206
. In step
201
, a supplier can visit the buyer's web site to view PO's using a standard web browser
207
. The supplier may decide to create a corresponding invoice from the received PO by submitting a “prepare invoice” request
202
to the web server. The XML document exchange/merge system
105
on the buyer side is invoked and dynamically generates a partial invoice
202
′. The partial invoice in XML format is transmitted over the Internet and displayed on supplier's browser
203
. The supplier can edit the partial invoice
204
, and submit the completed invoice back to the buyer for record handling or auditing
205
. The system
105
can also be run on the supplier side browser as programs written in Javascript, or as Java applets, for example.
Referring to
FIG. 7
, an internal flow diagram of a dynamic XML document exchange system
105
is shown. A standard XML parser
305
takes the input XML
125
and DTD
115
, and generates an intermediate structure, a tree
355
or an array
355
′, which serves as part of the input data to a merge algorithm
335
. The XML parser
305
may be a client side application, which may serialize tree elements into an array of hyper-text markup language (HTML) components
355
′, or a server side stand-alone application, which may construct the tree structure
355
(See FIGS.
10
A and
10
B). After parsing the return document DTD
135
, the DTD parser
315
creates a template
365
in either array format
605
or tree structure
615
, as shown in
FIGS. 10A and 10B
, respectively.
Referring to
FIG. 8
, an example XML name tag map table
325
(
FIG. 7
) is illustratively shown in greater detail. XML name tag map table
325
includes rows which have a pair of mapped name tags, one for a first XML type
405
, and the other for a return XML type
415
. To avoid ambiguity due to the possible usage of the same tags in different locations of the DTD, higher level qualifiers or ancestors' name tags may be included in the entries as shown in FIG.
8
. In the example, the table
325
advantageously maps the sender of the PO to the receiver of the invoice, while mapping the receiver of the PO to the sender of the invoice.
Referring to
FIG. 9
, an example of a constraint set table
345
(FIG.
7
)is illustrated in greater detail. Constraint set table
345
includes rows which have two entries, one for name tags
505
, and the other for a number of iterations
515
(corresponding to the loop headed by the name tags) that should be generated, for every encounter of the loop header tag in the merge algorithm
335
(FIG.
7
). In the example, the merge algorithm
335
generates four sender address segments and ten special charge segments, whether or not there is any contents in the created segments. For the same reason as the XML name tag map table
325
, higher level qualifiers or ancestors' name tags are included with the name tags
505
in the first column.
Referring to
FIGS. 10A and 10B
, two template structures are depicted, one in character array format
605
(FIG.
10
A), and the other in tree structure
615
(
FIG. 10B
) . In the array format, a marker “*” associated with a tag is employed to identify a loop header tag, e.g. LOOP_ITEM, while in the tree structure, shaded ovals represent a loop header node, e.g., nodes A, H, E, and F.
Referring to
FIGS. 11A-11E
, the merge algorithm
335
(
FIG. 7
) is illustrated in greater detail. The merge algorithm may operate on the tree template
615
. With modifications, the merge algorithm
335
may be adapted to the array template
605
as well. The algorithm VISIT_NODE(C), where C is a current node, recursively traverses a DTD graph output from DTD parser
315
, matching name tags from the first document using the XML name tag map table
325
, and passing along a variable token ATAG recording suspended tags (suspended tags are tags which are not yet printed due to their dependence on an optional node) for previously visited but not yet printed nodes (a printed node is a node which is printed or output as part of XML
return
145
(FIG.
7
). Throughout
FIGS. 11A-11E
, outputs include a “0” if the current tag is not printed and a “1” if the current tag is printed.
VISIT_NODE( ) is preferable employed as a subroutine or software module to recursively visit each node and determine tag names both ancestors (i.e., parents) and descendants (i.e., children) to process each node for matching the first document to the second document as described above. Other matching/merging techniques may also be implemented.
Whenever a node is visited, a null ATAG represents that there is no suspending tag string, and its parent node has printed the tag. Due to the existence of optional tags, certain tags are suspended printing until at least one of the descendants is printed. For example, consider the tree template
615
depicted in
FIG. 10B
, the sub-tree rooted at A is traversed in the order of A, B, H, D, and E. Since node A is optional, its tag “<A>” cannot be printed until any of its descendants is printed. Therefore, ATAG carries “<A>” when the algorithm visits node B. In block
702
, C is checked to determine if it is a leaf node. A leaf node is a node without a child node, for example node B is a leaf node of A in FIG.
10
B. Since node B is a leaf node, the algorithm matches its tag with the XML name tag map table to locate its corresponding tag, say B
1
(not shown), in the first document in block
705
.
The value of C (denoted as MC) is retrieved. In block
707
, if ATAG is not null, i.e. a tag string is being suspended and MC has a non-zero (non-null) value, the suspended string and the node tag are printed, and the value MC is printed, in block
710
. Also, ATAG is initialized to null again. If the next available value (MC) of B
1
exists in block
710
, the algorithm will print ATAG || “<B>” || MC || “</B>”, i.e., “<A><B>map value </B>”, where “||” denotes string concatenation. A close stage “</B>” completes the scope of its start tag “<B>” . Otherwise the algorithm checks if C is optional in block
715
. If C is optional, for example, when an additional address is tendered, see, e.g., additional address
46
of
FIG. 3
, ATAG may still include a suspended string. If C is not optional, ATAG will become ATAG || “<C></C>” in block
720
, which guarantees the printing of C's tag whenever it parent's tag is printed.
If C is determined to not be a leaf node in block
702
the flow path is directed to FIG.
11
B. If C is a loop header which designates a number of iterations to be performed as determined in block
724
, a constraint set is matched and the values of the constraint set are retrieved for the loop header C in block
725
. The loop header C retrieves a value for X which represents a number of iterations, for example. If X is greater than or equal to 0, the flow path is directed to block
731
where the suspending tags (ATAG) are printed for tag. <C>, for all ancestor nodes. Now all descendants (child or children nodes) of C are processed according to the flow diagram shown in
FIG. 11E
which recursively calls the VISIT_NODE( ) algorithm for each descendant, and reinitializes ATAG to Null when the last descendant is reached. The constraint set provided in block
725
may force the C loop to be printed a certain amount (X) of times shown as loop
730
.
The first XML document may include more than the X iterations or map items
730
needed to fill in the return document template, these items may be skipped and not appear in the return document in block
740
.
If X is less than 0, all children nodes are processed which suspend ancestor tags according to the flow diagram shown in FIG.
1
D. ATAG is concatenated with the tag of the present node C in block
760
. If there are children nodes in block
761
, the flow path calls VISIT_NODE( ) in block
762
for the child nodes and continues until the current tag is printed from block
763
. Then, ATAG is set to null again in block
764
.
After traversing all of the descendants of C, if no child's tag is printed from block
735
, the algorithm trims the ATAG which removes every tag from the end of ATAG up to the leftmost tag in block
745
“<H>” in this example, which was attached to ATAG when H was visited in block
760
. The ATAG will be the same as before H was visited. For example, ATAG may include “<A><B>” when H was visited. After the algorithm visits node D and returns to node C, ATAG may become “<A><B><H><D>” due to no match for D. Since the search has exhausted all of H's children in block
735
, and no child's tag has been printed, the algorithm can recover ATAG by trimming it in block
745
. The new ATAG should include “<A><B>.”
For intermediate nodes such as node G in
FIG. 10B
, if ATAG is not NUll, i.e., its parent's tag has not been printed, the algorithm in
FIG. 11C
goes through the same procedure as indicated by
780
in
FIG. 11B
from block
749
, except executing it only once. Otherwise the algorithm checks if G is optional in block
750
to decide whether to print “<G>” right away, or to pass ATAG || “<G>” along its descendants again using the flow path as indicated in FIG.
11
E.
The result of the merge algorithm as described in
FIGS. 11A-E
is an XML return document generated automatically, by either sequentially scanning the name tags from the template in an array structure, or recursively traversing the DTD tree node from the template in a tree structure, to match their counterparts in the XML DOM tree or the serialized array using the XML name tag map table. If a match is found, the corresponding value of the first XML message is retrieved and treated as the value associated with the current name tag. When a name tag with the special marker is detected, a loop or repeatable item is found or revisited, in which case the loop or repeatable item header tag is checked with the constraint set for loop or iteration count, or the tags inside the loop are matched against the XML DOM tree or serialized array, to determine if the content of the loop should be generated again. The algorithm handles both variable number and fixed number of loop iterations.
Having described preferred embodiments of a dynamic business process automation system using XML documents (which are intended to be illustrative and not limiting), it is noted that modifications and variations can be made by persons skilled in the art in light of the above teachings. It is therefore to be understood that changes may be made in the particular embodiments of the invention disclosed which are within the scope and spirit of the invention as outlined by the appended claims. Having thus described the invention with the details and particularity required by the patent laws, what is claimed and desired protected by Letters Patent is set forth in the appended claims.
Claims
- 1. A system for exchanging and merging messages over a network comprising:a server accessible by a plurality of remote browsers for transmitting a template including fields for information entry; and a business system accessible by the server for generating a return message pursuant to information entered in the template on the browsers, the business system including: a first parser for receiving a first message from a browser, the first message including information about data characteristics of information entered into the template and name tags; a second parser for receiving information about data characteristics to provide a return template, the return template including name tags; and means for merging the first message with the return template for providing the return message to the browser, the return message having portions of the return template with data entered therein corresponding to at least some of the information entered into the first message, wherein the means for merging includes a name tag map for correlating the tag names of the first message with the tag names of the return template.
- 2. The system as recited in claim 1 wherein the message includes information having a name and a value and the first parser parses the first message into name and value pairs.
- 3. The system as recited in claim 1 wherein the first message is written in an extensible markup language (XML) and the data type information is included in a corresponding data type definition format (DTD).
- 4. The system as recited in claim 1 wherein the means for merging further includes a constraint set for identifying name tags used in multiple instances.
- 5. The system as recited in claim 4 wherein the constraint set includes higher level name tags to identify the name tags used in the multiple instances.
- 6. The system as recited in claim 1 wherein the network is an Internet.
- 7. The system as recited in claim 1 wherein the first parser parses the first message to provide tag name and value information in a format of one of a document object model tree and an array.
- 8. A system for exchanging and merging extensible makeup language (XML) documents over an Internet comprising:a server accessible by a plurality of remote browsers for transmitting a template including fields for information entry; and a business system accessible by the server for generating a return XML document pursuant to information entered in the template on the browsers, the business system including: a first parser for receiving a-first XML document and a corresponding data type definition (DTD) file from a browser, the first XML document including name tags; a second parser for receiving a return data type definition (DTD) file to provide a return template, the return template including name tags; and means for merging the first XML document with the return template for providing the return XML document to the browser, the return XML document having portions of the return template with data entered therein corresponding to at least some of the information entered into the first XML document, wherein the means for merging includes a name tag map for correlating the name tags of the first XML document with the name tags of the return template.
- 9. The system as recited in claim 8 wherein the first XML document includes information having a name and a value and the first parser parses the first XML document into name and value pairs.
- 10. The system as recited in claim 8 wherein the means for merging further includes a constraint set for identifying name tags used in multiple instances.
- 11. The system as recited in claim 10 wherein the constraint set includes higher level name tags to identify the name tags used in the multiple instances.
- 12. The system as recited in claim 8 wherein the first parser parses the first XML document to provide tag name and value information in a format of one of a document object model tree and an array.
US Referenced Citations (6)
Number |
Name |
Date |
Kind |
5835712 |
DuFresne |
Nov 1998 |
A |
6108673 |
Brandt et al. |
Aug 2000 |
A |
6112242 |
Jois et al. |
Aug 2000 |
A |
6125391 |
Meltzer et al. |
Sep 2000 |
A |
6208986 |
Schneck et al. |
Mar 2001 |
B1 |
6216121 |
Klassen |
Apr 2001 |
B1 |