5. Proposed Model

The Internet allows suppliers (spokes) to use Java-capable browsers to conduct EDI-like business transactions with a large enterprise (hub) without pre-installing EDI software. This eliminates the costs of VANs and the costs of traditional translation software. The architecture of the proposed model, as depicted in Fig. 1, consists of two parts: (1) the server site (hub) and (2) the supplier site (spoke).

5.1 Business Documents Flow

Purchase orders and invoices constitute the majority of business transactions among trading partners. The hub site's backend system generates purchase order that must be transmitted to a company that will fulfill the order. As shown in the diagram above, a purchase order in the proprietary-format document file generated for a particular supplier by the hub site's proprietary backend system is converted into an EDI file by an EDI translator. The EDI file is then placed into mailboxing or repository system via a reliable delivery mechanism such as IBM's MQ-Series. The repository system then sends a notification (via E-mail, for example) to the desired supplier. On receiving the notification, the supplier uses a Web browser to login to the webserver, download and view the file. Together with the EDI file, the Web browser also downloads Java applets. These Java applets translate the EDI file into form-based content that is displayable on the browser screen. In addition to the translation and display of EDI files, Java applets, as directed by users, transfer data that can be exchanged with supplier-side's backend accounting systems.

The supplier can prepare a reply document (such as an invoice) either by entering information (such as the unit prices of the purchased items, billing information, and shipping information) manually in the browser or by using a backend system to generate a reply document, which is transferred into the browser by the adapter. The Java applets then send the prepared document back to the Web server. On the Web server side, a stand-alone daemon receives the invoice and deposits it into the repository system. From the repository, the invoice is sent, via the reliable delivery mechanism, into the hub's backend system. Once the invoice is in the hub's backend system, normal business processes are followed in order to match the invoice with a purchase order and pay the supplier.

5.2 Basic Components

Backend Systems

The backend system in the hub site generally contains an application system and its underlying database to operate daily business processes. It has its own internal proprietary data format. To conduct business activities with the trading partners, the backend system generates documents in the proprietary format and accepts reply documents from the trading partners. As the backend system only recognizes its own proprietary format, it requires a translator to convert documents.

A supplier may have its own backend system to manage business activities and generate reply documents. To automate the processes of incorporating the downloaded EDI documents into the supplier's backend system, we provide an adapter.

Translator

A large company (hub) typically exchanges business documents with many trading partners who require either different standards (e.g., X12, EDIFACT) or paper documents. In general, the translator in an EDI-enabled hub takes the responsibility of (1) converting the proprietary data format to a variety of formats or standards, and (2) translating various incoming document formats or standards into the proprietary format. The proposed model does not require any of the paper formats.

Mailboxing or Repository

Mailbox services are the core component of VANs with many value-added services built on top of mailboxing. The proposed model currently utilizes any database for the mailboxes and uses a web server to list and serve up documents and applets. The hub creates and maintains mailbox(es) for each spoke, with each mailbox contains an inbox and an outbox. The inbox stores the EDI documents delivered by the hub to the spoke, while the outbox saves the reply EDI documents from the spoke. By utilizing the access control facilities provided

by the database, the proposed model maintains mailbox and allows each spoke to access only its own mailbox.

In addition to mailboxing, the model also provides other value-added services such as E-mail notification, audit and control, documents tracking, archiving, query status, and reporting. The E-mail notification service sends E-mail to the desired spoke when a new document is placed in the inbox of that spoke. The primary audit objective is to verify that the spoke, after the notification E-mail is sent, receives the transaction document intact. The unread EDI documents with aging (number of days unread or unreplied depending on how urgent the document is) can be used to determine which documents are not being read and which have been read but not replied to. This will aid in determining which suppliers need to be contacted. The document tracking service records the flow of documents to enable recovery when a disaster takes place. To support document tracking, every creation and access of an EDI document in the database will be logged. The archiving service saves documents for a specific period time in the system to support recovery. The hub can also query the status of spokes' mailboxes and a spoke can query the status of its own mailbox. Reports summarize the transaction activities for both the hub and its suppliers. All these services can be customized according to the trading partners' needs.

Webserver

The Webserver provides authentication by requiring that a supplier enter a valid user id (identifying the supplier) and password to logon into the system. After logon into the system, a supplier only accesses its own mailbox and the applets, and has only read privilege to its incoming documents. Web servers also have SSL encryption capability.

Adapter

The adapter is used by the suppliers to import documents (e.g., hub's purchase orders) into their backend system by converting the document into the format accepted by the backend system.

5.3 Supplier Registration

Each supplier goes through a one-time registration via the Web. During the registration, the supplier requests a userid and enters its e-mail address (used for notification) and other vital information (company name and contact phone number, etc.) and picks from a list of supported backend systems.

This registration process requires an administrator of the server to assign a password and runs a script to add a new supplier, providing any additional information required such as the supplier ID to be used for that particular supplier in EDI messages. The script will mail the password to the supplier, setup the supplier userid, enter the supplier information into the supplier list, and set up the necessary authorizations.

5.4 XML EDI

This model allows transactions to be transmitted between trading partners using XML (Extensible Markup Language) [8], a powerful data representation standard for digitized information delivery and formatting. Presenting documents is one of XML's strengths. When compared with traditional EDI, XML/EDI simplifies the translation of documents because new browsers can parse XML documents into structures called Document Object Model trees (DOM trees) which can be manipulated easily. XML documents are easily converted to other XML documents simplifying backend integration. Additionally, XML separates the data from the presentation style. This allows the presentation to be tuned to a wide variety of output devices, including computer screens, a cell phone displays, or audio (text-to-speech) devices.