WO2003025779A1 - Connectivity systems and methods - Google Patents

Abstract

Connectivity systems (figure 1) and methods for establishing connectivity between trading partners are described herein. In one example embodiment of the system, the system (figure 1) comprises a connector comprising a servlet runner for causing selected templates to be displayed to a first trading partner and a sender/receiver communicator for asynchronously communicating a message comprising information input by the first trading partner into at least one of the templates. The engine comprises a task list processor for processing the message communicated by the connector and a relational database for storing task instructions. The task list processor retrieves task instructions from the relational database based on a sender-receiver-transaction type triple associated with said message.

Description

CONNECTIVITY SYSTEMS AND METHODS

[0001J A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

CROSS REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application Nos. 60/323,592, 60/323,606, 60/323,608, 60/323,642, all of which were filed on September 19, 2001, and are hereby incorporated by reference in their entirety.

BACKGROUND OF THE INVENTION

[0003] This invention relates generally to communicating messages between trading partners and, more particularly, to methods and systems which enable multiple trading partners to communicate using various combinations of formats and protocols.

[0004] Business-to-business electronic messaging is facilitated by connectivity between computers at each trading partner. Information exchanged by trading partners includes, for example, purchase orders, bills of lading, and financial settlements. Establishing true integrated and collaborative connectivity between trading partners, however, can be very complex. For example, mapping or transforming a message, or set of data, from the format used by a sending business to that used by a receiving business is highly complex and to be useful, must be performed with high reliability and speed.

[0005] In addition to the complexities associated with establishing messaging capability between just a few trading partners, in order to be cost effective, such infrastructure should be used across not just a few trading partners but by thousands of trading partners and be capable of handling millions of messages each day. Although the scalability of such messaging systems is important, as such systems are expanded to include hundreds of trading partners and to handle thousands of messages each day, complexity increases along with a possibility of reduced reliability.

BRIEF SUMMARY OF THE INVENTION

[0006] In one aspect, a connectivity system for communications between trading partners is provided. The system comprises a connector and an engine. The connector comprises a servlet runner for causing selected templates to be displayed to a first trading partner and a sender/receiver communicator for asynchronously communicating a message comprising information input by the first trading partner into at least one of the templates. The engine comprises a task list processor for processing the message communicated by the connector and a relational database for storing task instructions. The task list processor retrieves task instructions from the relational database based on a sender-receiver-transaction type triple associated with said message.

[0007] In another aspect, a method for operating a system to communicate between trading partners is provided. The system comprises a connector and an engine. The connector comprises a servelet runner and a sender/receiver communicator coupled to a database. The engine comprises a task list processor and a relational database having a plurality of tasks stored therein. The method comprises the steps of operating the servelet runner to cause a template to be displayed to a first trading partner, generate a file containing information input into the template by the first trading partner, and store the file in the connector database. The method further comprises the steps of operating the sender/receiver communicator to generate a message based on the information contained in the file, and asynchronously communicate, to the engine, the message. The method also comprises the steps of operating the engine task list processor to process the message, the processing comprising the step of retrieving, from the relational database, tasks to be executed based on a sender-receiver-transaction type triple associated with the message.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figures 1 - 5 illustrate example system architectures.

[0009] Figures 6 - 10 illustrate alternative system architectures.

[0010] Figures 11 - 13 illustrate example hardware architectures of a messaging engine.

[0011] Figures 14 - 16 illustrate messagmg processes executed by the messaging engine.

[0012] Figures 17 - 27 illustrate workflow processes executed by the messaging engine.

[0013] Figures 28 - 37 illustrate message parse processes executed by the messaging engine.

[0014] Figures 38 - 40 illustrate example screen shots associated with the messaging engine.

[0015] Figure 41 illustrates an example hardware architecture for the connector.

[0016] Figure 42 illustrates an interactive application executed by the connector.

[0017] Figure 43 illustrates an acknowledgement process executed by the connector.

[0018] Figure 44 illustrates the envelope requirements of a message.

[0019] Figures 45 - 52 illustrate example screen shots associated with the connector. [0020] Figures 53 - 54 illustrate an example hardware architecture of the integrator.

DETAILED DESCRIPTION OF THE INVENTION

[0021] The connectivity systems and methods, as described below in more detail, include a connector tool that allows trading partners of any size, volume or sophistication to participate in collaborative electronic commerce. Specifically, the connector tool facilitates creation of messages from common templates, and such messages are located in an outbound file in a directory. Of course, any message (not just messages created from a common template) that a trading partner desires to communicate can also be located in the directory. The outbound messages are then transmitted over a network (e.g., a wide area network such as the Internet) to a messaging engine.

[0022] The engine executes message capture, message management, and message forwarding tasks. Specifically, during message capture, an inbound message is received, identified, acknowledged, validated, and then either accepted or rejected. In message management, the message is translated, duplicates are eliminated, customer business rules are applied, and an audit trail is created. During message forwarding, messages are delivered to a recipient trading partner, routed using appropriate protocols and formats, and archived.

[0023] Set forth below are detailed descriptions of example embodiments of system architectures, messaging engines, connectors, and integrators. The present invention, however, is not limited to the specific embodiments described herein, and many variations and modifications are possible. In addition, components of each system and steps of each method described herein can be practiced independently and separately from other components and method steps described herein. The systems and methods described herein can be used in combination with other components and other steps. [0024] The terms "engine", "connector" and "integrator" are sometimes used herein to refer to components of a connectivity system. Such terms refer to any processor, server or system capable of performing the functionality corresponding to such component, and such terms are not limited to any particular implementation. For example, the connector functionality can be implemented in a server, or in any processor capable of performing the functions described in connection with the connector. The specific functionality associated with each of the engine, connector, and integrator is set forth below.

[0025] Connector: comprises a servlet runner for causing selected templates to be displayed to a first trading partner and a sender/receiver communicator for asynchronously communicating a message comprising information input by the first trading partner into at least one of the templates.

[0026] Engine: comprises a task list processor for processing a message communicated thereto and a relational database for storing task instructions. The task list processor retrieves task instructions from the relational database based on a sender-receiver-transaction type triple associated with the message.

[0027] Integrator: comprises a processor for serving as a single source of information for connecting to the engine. The integrator is configured to couple to multiple connectors and other message sources. The integrator may be combined with enterprise applications adapters from third parties to provide tight coupling with internal applications.

I. System Architecture

[0028] Figure 1 illustrates an example architecture for a trading system. Generally, trading partners such as suppliers and customers communicate via a network that includes connectors and an engine. Generally, the connectors facilitate creation of messages from common templates. Messages can also have various other formats including web forms, EDI transactions, industry exchange specific formats, and other formats. The messages are supplied to the engine, which also is connected to other application services and information services.

[0029] The engine serves as a business ecosystem preprocessor that enables it to easily connect external trading partners and deliver immediate value. It connects with internal workflow management tools and leverages existing investments in electronic data interchange (EDI), extensible markup language (XML), and other connectivity methods. Generally, the engine executes message capture, message management, and message forwarding tasks as described above.

[0030] Transmission formats include Application-to- Application (JDE, SAP, etc.) EDI X12 (EDI X12 Standard), EDIFACT (EDI for Administration, Commerce, and Transport), EDHNT (EDI for Internet), Flat file, SMTP (Email), HTML (Web), HTTP (Web), and XML (Extensible Markup Language). Message protocols include dedicated line, SNA networking, frame relay, any VAN service (Interconnect), dial-up (Modem), FTP (File Transfer Protocol), SMTP (Email), and secure Internet connection

[0031] At the recipient trading partner, the received message can result in performance of an inventory check, order acceptance, pricing synchronization, service provisioning, settlement, and other functions. As a result of performing such functions, data is supplied to the enterprise back office functionality.

[0032] More specifically, and as illustrated in Figure 2, each trading partner can have various internal applications executed by servers and/or other processors coupled into a network. The network can be composed of loosely coupled processors, workflow servers, local area networks, wide area networks, and various other types of networks that enable communication of data. In the example shown in Figure 2, a connector is located in the DMZ and such server facilitates the creation of messages to be communicated to an application (engine) server via a wide area network (e.g., the Internet). As also shown in Figure 2, an integrator also can be utilized to communicate messages via the Internet to the engine. [0033] Figure 3 illustrates, in more detail, a connector (e.g., connector host system) that communicates with various applications using various formats of a trading partner. Messages to and from the connector from the wide area network are communicated, in the example shown in Figure 3, using an HTTPS protocol.

[0034] Figure 4 illustrates an example connectivity between a trading partner and the engine. Specifically, a connector embodied as a web server is provided within a DMZ and is coupled to various applications. Communications need not, however, be transmitted through the connector and can be provided to a communication server via FTP. The connector facilitates creation of messages by executing connector servlets, and performs user validation via an LDAP server. More specifically, the connector includes a servletruirner for interactive processing and a messaging capability to ensure secure guaranteed message delivery. Together, these components provide distribution of applications functionality.

[0035] As shown in Figure 5, the engine can be coupled to various applications, a security database, a message store database, and personal computers (PCs) that perform functions such as a help desk, an administrator, and other internal users.

[0036] Of course, various alternative architectures also are contemplated and possible in addition to those described above in connection with Figures 1 - 5. For example, the connector can be located in a trading partner DMZ as illustrated in Figure 6. The connector can be located behind a trading partner firewall as illustrated in Figure 7. As shown in Figure 8, various trading partners can have the connector located in different security zones such as behind the firewall or in the DMZ. A connector behind a firewall can connect to the engine or to any other connector with a routable and accessible IP address. Either end may be accessible and messages may flow in both directions. The 'polling-pull' communications from the secure connector accommodates messages flowing into the secure connector. Also, and as shown in Figure 9, communications can be transmitted directly from one trading partner to another via the connectors, and the connectors can be located behind the firewall or in the DMZ. Two connectors, both behind firewalls, can communicate with each other using a connector relay. The relay provides an accessible node and the 'polling-pull' communications accommodates messages flowing into both secure connectors. As shown in Figure 10, the engine server also can be configured as a relay service and coupled to various trading partners with a variety of connectors. The connector relay is a feature of the engine that allows clients to send messages to each other through the relay, making it possible for both parties to operate from a secure node without a routable IP address. The connector relay will accept connections from both parties on a polling basis and when there is message traffic for the party, the party will 'pull' the message from the relay. This relay can be implemented in connection with a variety of protocols including HTTP(S) POST, FTP, and ED1TNT (including connector clients).

II. Engine

[0037] Referring to Figures 11, 12 and 13A-B, the engine has a task list architecture in that the engine includes a task list processor to process messages. Tasks are the processing steps that enable the collaborative processes on the messaging community. These tasks include message storage, indexing, translation, transformation, transmission, validation, acknowledgement, rejection, and more complex processes based on 'Stateful Messaging'.

[0038] An inbound message is processed by the communications components and sent via JMS queue to an identify process that determines the sender, receiver and transaction type of the message, sometimes referred to herein as a sender- receiver-transaction triple. The engine then retrieves a task list of arbitrary length from a relational database and sends the message via JMS queue to the appropriate component to perform the first task. This process continues until all tasks have been accomplished.

[0039] Task lists are maintained at the sender-receiver-transaction ("SRT") level where any number of tasks may be defined for a unique SRT triple. This level of granularity provides flexibility. In order to minimize the effort of managing task lists for large, complex messaging communities, two additional features are provided based on object model inheritance. Specifically, "Pull Inheritance" enables the creation of a task list based on existing task lists in a hierarchy and "Push Inheritance" enables a task to be added to an entire hierarchy with one interaction.

[0040] The task list architecture employs chained transaction architecture to ensure that all steps are completed. The repository (RDBMS) provides persistence so that transactions always re-start or re-try from a known transaction state.

[0041] Components of the engine are multi-threaded. The use of enterprise JavaBeans and database connection pools enables many processes to share a pool of components. The use of JMS queues permits the engine to scale beyond multithreading in a near-linear fashion as shown in Figure 13B. Multiple instances of each task can process messages in parallel. These instances can be distributed across an arbitrary number of host processors to achieve very high throughput.

[0042] In the example embodiment, the engine conforms to the J2EE architecture and runs in mission-critical application servers with fault tolerant features provided by the container. JMS messages and database persistence also can be implemented using commercially available products to provide reliability and fault tolerance.

[0043] The engine stores message in a persistent repository (RDBMS) to provide an auditable record of message processing and transmission. These messages may be retrieved and viewed by messaging partners through an Internet Web interface. In addition, messages are retained for a configurable period to enable reporting and decision support systems to be constructed on community message content. Messages may be inspected in multiple formats (text, EDI-parsed format, XML) and may be modified and re-queued for transmission without re- sending from origin. This enables the correction of messages. [0044] Message content is indexed using arbitrary message content so that it can be retrieved by user-specified criteria such as Purchase Order Number, Equipment Identifier, or other indexes. Reports can also be constructed that use these indexes.

[0045] The engine isolates all accessible nodes in a separate DMZ with clear layered protection zones in the system architecture. All processes that reside on nodes that can be accessed from outside the firewall immediately pass data through an internal firewall that only allows access from the DMZ. There is no persistent storage of message content in the DMZ. Proxy processes accept and process packets and forward content to the secure zone. This is an extensible architecture and proxies have been constructed for FTP, SMTP, EDJXNT, and WebSphere MQ.

[0046] Example messaging flows are illustrated in Figures 14, 15, and 16. Generally, the task list processor processes an inbound message by executing message capture, message management, and message forwarding tasks. The message capture tasks comprise receipt of an inbound message, identification of an inbound message, validation of an inbound message, and acceptance/rejection of an inbound message. The message management tasks comprise translation of a message, eliminating duplicates of a message, applying customer business rules to a message, and creating an audit trail of a message. The message forwarding tasks comprise delivering a message to a recipient trading partner, and archiving a delivered message.

[0047] As shown in Figure 15, the engine also performs message management tasks. Such tasks include translate, eliminate duplicates, apply customer business rules, validate, and capture audit trail. Figure 16 illustrates the message forwarding task performed by the engine (e.g., deliver immediately, based on time, based on event). A message is delivered by the engine to the connector, for example, in a predefined format, and actual delivery can occur via various media (e.g., any VAN service, FTP, E-mail. [0048] The workflow executed by the engine is illustrated in the flow diagrams shown in Figures 17 - 27. The message parse process executed by the engine is illustrated in the flow diagrams shown in Figures 28 - 37.

[0049] Figures 38, 39, and 40 illustrate example screen shots of messages as viewable at the engine. As shown in Figure 38, a user selects a viewer to use to view a message. Figure 39 illustrates an example bill of lading as viewed using a selected viewer. Figure 40 illustrates a message in a format different from the message (e.g., bill of lading) illustrated in Figure 39,

III. Connector

[0050] Figure 41 is a block diagram of an example connector and Figure 42 illustrates an example interactive program. As explained above, the connector facilitates creation of messages by executing connector servlets, and performs user validation via an LDAP server. Connector, in the example embodiment, is a standards-driven, cross-platform application that enables a trading partner to create and manage messages for secure, reliable transmission and receipt via the engine. The connector supports an expansive variety of data formats and data entry paradigms, including files, browser-based data entry, and connectivity with major packaged applications. The example embodiment described below is described in the context of TranXML, which is an example format. Of course, many other formats can be utilized. TranXML is an extensible markup language defined by the assignee of the present application, and details regarding TranXML are publicly available, including from Transentric LLC, 7930 Clayton Road, St. Louis, MO 63117.

[0051 ] The connector provides/performs the following functions.

1. Accepts files as input. The conversion of the data is done by the engine before delivering to the trading partner.

2. Has the ability to create templates. Provides for customization of data entry, reduces amount of data to be input, speeds up data entry, and lowers chance for errors.

3. Provides reliable message service with guaranteed once only delivery.

4. Converts the data to a TranXML message, which enables the trading partner to display it using a Web browser. 5. Contains a scoreboarding type match-up process and life-cycle management. This feature enables the user to verify that his messages have been received and processed. This process matches up the original message with the acknowledgement and keeps the unacknowledged or acknowledged with errors message available for correction and resubmission. Successfully acknowledged messages are deleted from the directory.

6. Utilizes Web forms to display what was sent, what has been acknowledged and processed, and what has been marked with errors.

7. Enables non-EDI and non-XML capable users to participate in electronic commerce without investing any money in software. Enables the small to medium company that has never done EDI to transact with trading partners electronically. Connector makes it easier for a company to expand it's fleet of trading partners.

8. Exchange documents automatically on a 24 x 7 basis without human intervention.

9. Enables the exchange of a variety of data formats, e.g., TRANXML, EDI

10. Data mapping from any-to-any format.

11. Connect back-office systems from one company to another.

12. Accelerates deployment and time-to-market.

[0052] The connector includes a servletrunner for interactive processing and a messaging capability to ensure secure guaranteed message delivery. File-based persistence between the servletrunner and the messaging engine enables asynchronous creation and delivery of messages. This makes it possible for users to interact with the connector on their own system and / or their own LAN and the connector will provide delivery when connectivity is established. Users can operate the connector with intermittent internet connectivity including standalone systems and wireless systems. Connector relies on the underlying file system for persistence, logging, and storage of local configuration information. If workflow functionality is implemented in XMLiris (commercially available from FiveSight Technologies Inc., 213 N. Morgan, Suite 1A, Chicago, Illinois 60607), a process cascade provides connectivity between components (replacing JMS queues in a full implementation).

[0053] The connector functionality, in one example embodiment, is implemented in Java code, which enables platform independence. In the interest of supporting many users, connector should be operable to run on any operating system that supports a Java2 Virtual Machine. Commercially available and well known operating systems and versions currently supporting a Java2 Virtual Machine include Microsoft Windows 95/98/NT/2000, Linux 2.x, Sun Solaris, IBM OS/2, IBM OS/400 (V4R5 or later), IBM AJX (4.3.3.10 or later), and HP-UX.

[0054] Connector provides import functionality for flat files as well as browser-based data entry and import functionality for TranXML. Also, connector enables the engine to identify and authenticate message senders and to send ("push") updates to business logic or transformation scripts. Connector also enables users to configure and maintain basic aspects of the local system through a browser-based interface.

[0055] Regarding security, and in one example embodiment, connector conforms to security standards set by the well known Electronic Data Interchange-Internet Integration work group (EDHNT) AS2 of the Internet Task Force. Connector uses HTTP and S/MJJVLE standards to provide secure and reliable communications links. Connector uses the following tool sets to ensure secure exchanges of data: EDHNT AS2, S/MDVIE encryption, X.509 type certificates to authenticate the client (certificates are validated at both ends of the communication link), public and private keys for encryption, MD5 integrity checking to verify that the message has not been altered, and a user ID combined with the organization name that must be registered in the system. Other tools appropriate to security (e.g., secure socket layer (SSL)) and connectivity (e.g., JMS) can be utilized.

[0056] Both components of the connector are multi-threaded to provide scalability. An enterprise can install a single connector and share its servletrunner and its file system across a LAN, or multiple connectors may be installed, including configurations where each user installs their own connector. Response time is minimized and performance is maximized because it is independent of internet access speed, communications throughput, and contention from users on other connectors.

[0057] Messages can be created or sent to the connector in a variety of ways including interactive creation using the servletrunner engine, HTTP file upload, JMS message queues, relational databases, and file-based upload. The local file system can accommodate any type of message creation and security model the host system provides. The connector uses a directory scanner to detect that new messages are present and ready to be processed.

[0058] The connector uses a staging directory to preserve file integrity. When the file is complete, it is moved to an outbox directory on the same file system using a rename to ensure that the entire file is present before processing begins. Use of a local servletrunner enables local access-control administration by each trading partner. The local administrator uses the access control features of the servletrunner (Tomcat) to allow or deny access to servlets (JSPs, Agilink Controllers, XML Roundtrip, and Java Servlets). These servlets create content that is forwarded by the connector to messaging partners.

[0059] Polling-push communications make it possible to deploy the connector from behind a firewall, without a routable IP address. A secure configuration of the connector behind the firewall enables Internet messaging without any inbound connections.

[0060] For communications, connector forms a secure transmission loop using the S/MIME protocol. When a message is sent, the following steps are performed.

Connector signs and encrypts the data using S MIME and requests that a signed receipt be returned.

The engine decrypts the message using the public and private keys and verifies the signature and authenticate the sender.

The engine then returns a signed receipt to connector in the form of an MDN. This signed receipt indicates that the message was received and decrypted correctly, that authentication of the sender occurred, and that the integrity of the interchange was validated.

[0061] The use cases fall into two categories: data submission, and system monitoring/management. The use-case descriptions below make some architectural assumptions in the interest of clarity, as shown in Figure 41. The major assumption is that the system provides for directory-based "buckets" from which files are either picked up, or to which files are deposited. It is assumed that at least three such buckets will exist:

[0062] The OUTGOING bucket will contain documents for upload to the engine. The user will be able to initiate an upload to the engine or set the application to automatically upload these documents.

[0063] The ERROR bucket will contain documents that failed to process for one reason or another, e.g., an incomplete TranXML document. The user will be able to view, modify, and resubmit a document in the ERROR bucket. Both the local connector processes and the engine may place documents in the ERROR bucket. In order to simplify resubmission, each document in the ERROR bucket will contain sufficient information to recreate the original message that caused the error.

[0064] The RECEIPTS bucket will contain any messages returned from the engine (excluding messages destined for the ERROR bucket), including acknowledgements of message successfully received and application acknowledgements generated by receiving applications.

[0065] Connector accommodates two primary methods of data

' submission: file-based and interactive. Both methods rely on directory-based buckets from which files are either picked up or deposited. The interactive submission method will provide a browser-based interface to these buckets, allowing a user to quickly create documents for submission.

[0066] The most fundamental use case is submission of documents by the client to the engine by placing TranXML files in a directory. The actor in this case can be either a person, a computer process, or another connector component. The activity in this case is summarized below:

1. TranXML documents are placed in the directory corresponding to the "OUTGOING" bucket.

2. The user or a timed process triggers the creations of a connection to the engine if one is not established. 3. Documents in the "OUTGOING" bucket are read from disk and checked locally against some basic sanity rules. Documents that fail the sanity test get routed to the "ERROR" bucket.

4. Documents that passed the sanity check are transmitted to the engine.

5. The engine applies logic to the incoming documents.

6. The engine generates replies (confirmations or rejections) for the documents received.

7. The engine transmits replies to the connector.

8. The connector routes the message confirmations and rejections from the engine to the "RECEIPTS" and "ERROR" buckets respectively.

[0067] In order to facilitate data capture from unsophisticated data collection points the system will provide for basic interactive data entry. This use case is a mere extension of file-based submission case as described in the previous section. Here the actor is a person interacting with an interactive browser-based application. The application forwards user input to the appropriate bucket. The interactive application component is illustrated in Figure 42. A typical interactive submission would proceed as follows:

1. User logs into browser-based application.

2. User selects data entry from the menu.

3. User selects a template to work on.

4. User fills-in template.

5. User submits form.

6. Application converts form submission into TranXML document.

7. Application writes TranXML document to the directory corresponding to the "OUTGOING" bucket.

[0068] Both templates and data entry can be implemented as HTML forms bound to an underlying XML document through XSLT. A template is then implemented as the HTML form image of a partially populated document.

[0069] For file-based submission (non-tranXML), the goal is to transmit a document of non-TranXML format to the engine for processing. The actor in this case may be either a person or another computer process. The activity is very similar to the file-based submission of TranXML documents, except that no local validity checking is performed on the submitted documents:

1. Non-TranXML documents are placed in the directory corresponding to the "OUTGOING" bucket. 2. The user or a timed process triggers the creations of a connection to the engine if one is not established.

3. Documents in the "OUTGOING" bucket are read from disk and transmitted to the engine.

4. The engine applies logic to the incoming documents.

5. The engine generates replies (confirmations or rejections) for the documents received.

6. The engine transmits replies to the connector.

7. The connector routes the message confirmations and rejections from the engine to the "RECEIPTS" and "ERROR" buckets respectively.

[0070] Registration is the first action to be done by a new user using the connector. Set forth below are the steps executed in connection with registration.

1. The user receives the connector software through a download or in a shrink- wrapped form.

2. The user runs the INSTALL process, which loads the software and creates the necessary directories (buckets).

3. The user then configures the system.

4. After the software is loaded and the system configured, the user logs into the system and performs the initial setup process. User provides necessary identification information such as E-mail address, what transactions he will be performing, what trading partners that he will be trading with, and what templates he will be using.

5. Above setup information is then automatically sent to the engine. Profiles are then established in the engine and a certificate is established. After proper verification of the identity of the new user is verified, the certificate is conveyed to the new user via E-mail.

[0071] The "configure system" process is executed only once by the new user. The process is described below.

File #1 - on connector client machine: props. conf => located in the connector (client side) install directory, this file must be edited to have all file directories point to their correct location. These properties includes:

- 1.sub.read_dir (directory to poll for messages)

- l.sub.error_dir (failed reads will be posted here)

- l.task.as2_keystore

- I.task.as2_receipt_dir (mdn responses are writtern here)

- l.task.as2_error_dir (failed processing send mesages here)

- l.task.as2_copy_dir (successful sent messages are copied here)

Other properties are:

- l.task.as2_host (the server host to connect to) - 1.task.as2_port (server port, by default 8443)

File #2 - on connector client machine

$TOMCAT_HOME/webapps/aglclient/WEB-lNF/web.xml. Again, the necessary parameters to edit are all file path parameters.

File #3 - xslt file for roundtrip - on connector client machine

In this case, warehouse_payload.xslt file is used. The field to edit is the <xsl:variable name— 'basepath" node, and the path should be set to the directory containing all the codes necessary for the xslt script (usually, the same directory containing the xslt file).

File #4 - on connector server machine

$TOMCAT_HOME/webapps/agl/WEB-INF/web.xml

Parameters to set here are the url to the machine housing weblogic and the name of the bean to receive incoming message, passing these to a queue.

[0072] For creating a TranXML document, the following use case is performed every time the user fills in information on a template and submits the data for processing.

1. User selects template and enters appropriate data.

2. User submits the document.

3. XiLA process reads template and builds the TranXML document.

4. TranXML envelope is placed around the document and it is placed into the "OUTGOING" bucket.

[0073] The create TranXML template process may be executed periodically by the user depending upon usage of new documents, business practices, and other factors.

1. User indicates that he wants to create a new template.

2. User selects skeleton template.

3. User keys in appropriate data using the skeleton template as a guide. Data to be captured should be repeatable information that would be present for each transaction. Variable data such as item information, weights, would be keyed in for each shipment.

4. When user completes the data entry, a new customized template is created and the user provides an appropriate name. This template will then be added to the selection list for future data entry of the variable data.

5. Maintenance for these customized templates will be the responsibility of the user. [0074] To check a transaction status, acknowledgements for messages sent to the engine are received by the connector and placed in the "RECEIPTS" bucket. Figure 43 illustrates an example acknowledgement process initiated at the connector. Generally, a message is created and transmitted to the engine. The engine communicates the acceptance status of the message to the connector and the connector stores the message status locally.

[0075] Several types of acknowledgements, syntax and application, could be received by the connector. Syntax acknowledgements are generated by the engine when the message is received. These acknowledgements indicate if the format of the transaction conforms to standards. Only accepted acknowledgements will be received by the connector. Acknowledgements indicating errors will be handled by the engine. The syntax errors will be corrected and the transaction submitted for processing. The successful acknowledgement will then be sent to the connector indicating that the transaction has been accepted for processing. Application acknowledgements may also be sent to the connector. These acknowledgements indicate whether the content of the document is valid and are generated by an application system processing the data. Application acknowledgements may be for both accepted and rejected transactions.

1. Using a Web form, the user indicates that he wants to check the status of transactions that have been sent to the engine. Summary transaction data for transactions that have been sent to engine is displayed along with the matching acknowledgement information. The display will indicate if the message was accepted and if it has been processed OK or if it had errors.

2. If it was processed OK, the user can then delete the transaction from the "OUTGOING" bucket.

3. If it had application errors, the original outgoing transaction will be placed in the "ERROR" bucket. The user has the option of retrieving the original transaction from the "ERROR" bucket, correcting the errors, and resubmitting.

4. The user can work his way through all of the acknowledgements taking the appropriate action based on the type of acknowledgement or quit and resume at a later time. The acknowledgements and matching transactions will remain until cleaned up by the user.

[0076] If while checking the status of transactions, the user determines, based on the information in the acknowledgement, that one has an error, the message can be resubmitted. This would be a data error because all transaction formatting errors are handled by the engine.

1. User is checking the transaction status and has discovered an acknowledgement indicating an error.

2. The user then displays the errored transaction from the "ERROR" bucket and determines the reason why the transaction was errored.

3. The user then corrects the error in the original transaction and submits it for reprocessing.

4. The transaction is placed on the "OUTGOING" bucket ready for the next transmission to the host.

[0077] Figure 44 illustrates example envelope requirements for a TranXML format.

[0078] For AS2 MIME Templates, the structure of an AS2 MIME message - PGP/MIME, is set forth below.

No encryption, no signature -RFC2068/2045

-RFC1767/RFC2376 (application/EDIxxxx or application/xml)

No encryption, signature -RFC2068/2045

-RFC1847 (multipart/signed)

-RFC1767/RFC2376 (application/EDIxxxx or application/xml)

-RFC2015 ( pplication/pgp-signature)

Encryption, no signature -RFC2068/2045

-RFC1847 (multipart/encrypted)

-RFC2015 (applica ion/pgp-encrypted)

-"Version: 1" -RFC2015 (application/octet-stream)

-RFC1767/RFC2376 (application/EDIxxxx or application/xml) (encrypted)

Encryption, signature -RFC2068/2045

-RFC1847 (multipart/encrypted)

-RFC2015 (application/pgp-encrypted)

-"Version: 1" -RFC2015 (application/octet-stream) -RFC1847 (multipart/signed) (encrypted)

-RFC1767/RFC2376 (application/EDIxxxx or application/xml) (encrypted)

-RFC2015 (application/pgp- signature) (encrypted)

No encryption, no signature -RFC2068/2045

-RFC1767/RFC2376 (application/EDIxxxx or application/xml)

No encryption, signature -RFC2068/2045

-RFC1847 (multipart/signed)

-RFC1767/RFC2376 (application/EDIxxxx or application/xml)

-RFC2633 (application/pkcs7-signature)

Encryption, no signature -RFC2068/2045

-RFC2633 (application/pkcs7-mime)

-RFC1767/RFC2376 (application/EDIxxxx or application/xml) (encrypted)

Encryption, signature -RFC2068/2045

-RFC2633 (applica ion/pkcs7-mime)

-RFC1847 (multipart/signed) (encrypted) -RFC1767/RFC2376 (application/EDIxxxx or application/xml) (encrypted)

-RFC2633 (application/pkcs7-signature) (encrypted)

[0079] Skeletal Requirements for an EDJJNT (sample format) are set forth below.

To : <<recipient organization >> Subj ect :

From: <<sending organization >> Date :

Mime-Version : 1 . 0 Content -Type : Application/XML Content-Transfer-Encoding: QUOTED-PRTNTABLE

«standard TRANXML Interchange goes here» [0080] Figures 45 - 51 illustrate example screen shots displayed by one example embodiment of connector. Generally, and as shown in Figure 45, a user can select administration, viewing, and create/update functions within connector. Figures 46 - 47 illustrate viewing transaction status. Figures 48, 49, and 50 illustrate creating/updating a transaction. Figure 51 illustrates creating/updating templates that are displayed by connector and utilized in generating messages. Figure 52 illustrates a shipment status message.

IN. Integrator

[0081] Figures 53 and 54 illustrate an example embodiment of the integrator. The integrator provides functionality for trading partners to connect reliably and securely a single source of information to the engine. The integrator facilitates implementation of electronic connectivity of business partners, and extends the scope of responsibility from LAN to LAN at trading partners. The integrator may combine with enterprise applications adapters from third parties to provide tight coupling with internal applications.

[0082] In one example, integrator is implemented as a Java2 executable suitable for use on many different platforms with minimal modification. Typically, integrator supports a single-digit number of users per client installation. Integrator can be configured to directly support JMS-compatible message-oriented middleware such as IBM MQ Series.

[0083] Integrator can be implemented using open source third-party tools such as the Apache Jakarta tools for servlets/JSP, regular expressions, and other functions. Apache Xerces and Xalan can be used for for XSLT-based other to XML conversion. FiveSight Rounά rip can be used to populate and edit TranXML documents, and FiveSight XiLA can be used to validate TranXML documents. These tools are commercially available and well know.

[0084] Integrator transmits messages to the engine (e.g., by HTTPS POST), receives acknowledgements (e.g., MD5 in the response), verifies the acknowledgement, and receives an acknowledgement of receipt of the verification. Integrator can also send messages on a JMS queue connected to a hub outside of the firewall at the integrator server. A validation agent within the bridge will ensure that the message meets all requirements (completeness, destination, etc.)

[0085] While the invention has been described in terms of various specific embodiments, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the claims.

Claims

WHAT IS CLAIMED IS:

1. A connectivity system for communications between trading partners, said system comprising:

a connector comprising a servlet runner for causing selected templates to be displayed to a first trading partner and a sender/receiver communicator for asynchronously communicating a message comprising information input by the first trading partner into at least one of said templates; and

an engine comprising a task list processor for processing said message communicated by said connector and a relational database for storing task instructions, said task list processor retrieving task instructions from said relational database based on a sender-receiver-transaction type triple associated with said message.

2. A system in accordance with Claim 1 further comprising a database, messages to be sent by said sender/receiver communicator being at least temporarily stored in said database.

3. A system in accordance with Claim 1 wherein said connector is electronically positioned within a DMZ of the first trading partner.

4. A system in accordance with Claim 1 wherein said connector is electronically positioned behind a firewall of the first trading partner.

5. A system in accordance with Claim 1 wherein said connector operates asynchronously with respect to creation and delivery of messages to said engine.

6. A system in accordance with Claim 1 wherein said connector is implemented in Java code.

7. A system in accordance with Claim 1 wherein the first trading partner has a plurality of connectors, each of said connectors configured to communicate with said engine.

8. A system in accordance with Claim 1 wherein messages are communicated to said engine via sources i addition to said connector.

9. A system in accordance with Claim 1 wherein access to said servlet runner is controlled by a local administrator.

10. A system in accordance with Claim 1 wherein said connector communicates with said engine in polling-push and in polling-pull operations.

11. A system in accordance with Claim 1 wherein said engine task list processor executes at least one of message storage, indexing, translation, transformation, transmission, validation, acknowledgement, and rejection tasks.

12. A system in accordance with Claim 1 wherein for an inbound message received by said engine, said processor determines the sender, receiver and transaction type of the message, retrieves a task list of arbitrary length from a relational database and sends the message via a queue to an appropriate component to perform the first task.

13. A system in accordance with Claim 12 wherein said task list is created based on at least one of a "Pull Inheritance" and a "Push Inheritance".

14. A system in accordance with Claim 1 further comprising a persistent repository, said engine coupled to said repository for storing messages therein to provide an auditable record of message processing and transmission.

15. A method for operating a system to communicate between trading partners, said system comprising a connector and an engine, said connector comprising a servelet runner and a sender/receiver communicator coupled to a database, said engine comprising a task list processor and a relational database having a plurality of tasks stored therein, said method comprising the steps of: operating the servelet runner to:

cause a template to be displayed to a first trading partner,

generate a file containing information input into the template by the first trading partner, and

store the file in the connector database;

operating the sender/receiver communicator to:

generate a message based on the information contained in the file, and

asynchronously communicate, to the engine, the message; and

operating the engine task list processor to process the message, the processing comprising the step of retrieving, from the relational database, tasks to be executed based on a sender-receiver-transaction type triple associated with the message.

16. A method in accordance with Claim 15 wherein the connector operates asynchronously with respect to creation and delivery of messages to the engine.

17. A method in accordance with Claim 15 wherein access to the servlet runner is controlled by a local administrator.

18. A method in accordance with Claim 15 wherein the connector communicates with the engine in polling-push and in polling-pull operations.

19. A method in accordance with Claim 15 wherein the engine task list processor executes at least one of message storage, indexing, translation, transformation, transmission, validation, acknowledgement, and rejection tasks.

20. A method in accordance with Claim 15 wherein for an inbound message received by the engine, the processor determines the sender, receiver and transaction type of the message, retrieves a task list of arbitrary length from a relational database and sends the message via a queue to an appropriate component to perform the first task.

21. A method in accordance with Claim 20 wherein said task list is created based on at least one of a "Pull Inheritance" and a "Push Inheritance".

22. A connector for communicating messages, said connector comprising:

a servelet runner for causing selected templates to be displayed to a first trading partner and for generating an outbound file containing a message; and

a sender/receiver communicator for asynchronously communicating the message to a recipient.

23. A connector in accordance with Claim 22 further comprising a database, messages to be sent by said sender/receiver communicator being at least temporarily stored in said database.

24. A connector in accordance with Claim 22 wherein said connector operates asynchronously with respect to creation and delivery of messages.

25. A connector in accordance with Claim 22 wherein said connector is implemented in Java code.

26. A connector in accordance with Claim 22 wherein access to said servlet runner is controlled by a local administrator.

27. A connector in accordance with Claim 22 wherein said connector communicates messages in polling-push and in polling-pull operations.

28. A messaging engine comprising: a task list processor for processing an inbound message, said processor operable to execute at least one of message capture, message management, and message forwarding tasks; and

a relational database for storing task instructions, said task list processor retrieving task instructions from said relational database based on a sender- receiver-transaction type triple associated with the inbound message.

29. A messaging engine according to Claim 28 wherein said message capture tasks comprise receipt of an inbound message, identification of an inbound message, validation of an inbound message, and acceptance/rejection of an inbound message.

30. A messaging engine according to Claim 28 wherein said message management tasks comprise translation of a message, eliminating duplicates of a message, applying customer business rules to a message, and creating an audit trail of a message.

31. A messagmg engine according to Claim 28 wherein said message forwarding tasks comprise delivering a message to a recipient trading partner, and archiving a delivered message.

32. A messaging engine in accordance with Claim 28 wherein said engine task list processor executes at least one of message storage, indexing, translation, transformation, transmission, validation, acknowledgement, and rejection tasks.

33. A messaging engine in accordance with Claim 28 wherein for an inbound message received by said engine, said processor determines the sender, receiver and transaction type of the message, retrieves a task list of arbitrary length from a relational database and sends the message via a queue to an appropriate component to perform the first task.

34. A messaging engine in accordance with Claim 33 wherein said task list is created based on at least one of a "Pull Inheritance" and a "Push Inheritance".

35. A messaging engine in accordance with Claim 28 comprising JMS queues wherein multiple instances of each task can process messages in parallel, said instances distributed across a plurality of host processors.

36. A connectivity system for communications between trading partners, said system comprising:

a first connector comprising a servlet runner for causing selected templates to be displayed to a first trading partner and a sender/receiver communicator for asynchronously communicating a message comprising information input by the first trading partner into at least one of said templates; and

a second connector comprising a servlet runner for causing selected templates to be displayed to a second trading partner and a sender/receiver communicator for asynchronously communicating a message comprising information input by the second trading partner into at least one of said templates.

37. A connectivity system in accordance with Claim 36 further comprsing an engine for receiving communications from said first and second connectors, said engine comprising a task list processor for processing a message communicated by one of said connectors and a relational database for storing task instructions, said task list processor retrieving task instructions from said relational database based on a sender-receiver-transaction type triple associated with said message.

38. A system in accordance with Claim 37 wherein at least one of said connectors is electronically positioned within a DMZ of the respective trading partner.

39. A system in accordance with Claim 37 wherein at least one of said connectors is electronically positioned behind a firewall of the respective trading partner.

40. An integrator comprising a processor and configured to couple to at least one connector, said integrator further configured to function as a single source of information for communicating messages to an engine.

41. An integrator in accordance with Claim 40 wherein said integrator is implemented in Java code.

42. An integrator in accordance with Claim 40 wherein said integrator is configured to transmit messages to an engine, receive acknowledgements from the engine, verify the acknowledgement, and receive an acknowledgement of receipt of the verification.