This section provides technical details about how information is received, processed, and sent by WebDI. The chart below illustrates WebDI's architecture, and is discussed in the verbiage following it.

Incoming Data

The input method is determined by whether you're using forms-based or integrated WebDI.

• If WebDI is integrated with the sender's back-office system, then data is extracted from that system.
• If the sender is using eForms, then data is sent through the WebDI forms user interface (meaning that the sender fills out a form on the WebDI site). Data can also be sent by uploading it (via FTP) from a local hard drive.

Communication Framework

Information can be delivered to WebDI using a variety of communication protocols. These include, but are not limited to, the following.

• FileLinx - FileLinx is a ChanneLinx application that monitors user-specified directories on your systems. As files are deposited in these directories, FileLinx automatically sends them to WebDI. Likewise, FileLinx receives WebDI files and forwards them according to your predefined specifications. FileLinx uses a Java Message Service-based (JMS) broker called SonicMQ, and avoids the need for complicated FTP scripts to send and receive files. 
  
• FTP (File Transfer Protocol) - Information can be sent to WebDI utilizing a push or pull FTP methodology.
  • Your application can connect to WebDI's FTP directory at any time and send files by dropping them off in the outgoing directory. (At the same time, your application can check for information that has been sent to you in the incoming directory.)
  • WebDI can check an FTP server that you make available for files that should be retrieved. (At the same time, WebDI can proactively push files to your FTP server.)
    
• VAN - WebDI can interface with a Value Added Network (VAN) to send and receive files.
  
• HTTP Post - Clients can upload an XML or flat file and post it to WebDI for viewing or to a directory for processing by a regularly scheduled CRON job.
  
• MQ Series - IBM's product that conforms to the Java Message Service specification is MQ Series. This functions much like SonicMQ - in fact, the two communicate with each other via a bridge.
  
• SOAP - Simple Object Access Protocol is an XML/HTTP-based protocol for accessing services, objects, and servers in a platform-dependent manner. SOAP consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls and responses.
  
• VBS/COM - WebDI can work with your specifications to develop a custom, mutually agreeable connectivity methodology.
  
• E-mail - WebDI can communicate via e-mail with any user account that has access to the Internet.

Processing - WebDI Infrastructure

• One conversion template is developed to convert incoming data to the WebDI proprietary format.
• Another is developed to convert data being sent into the required outgoing format.

These templates are stored in WebDI's conversion template library for use at the time of data transmission. When WebDI receives information, it then processes incoming transactions through its proprietary infrastructure.

• The syntax of incoming data is checked, when applicable, for compliance with ANSI X12 standards for EDI data.
• Using the templates from the conversion template library, data is translated to the WebDI proprietary database structure, which makes it universally exchangeable with all trading partners in the WebDI community.
• Data is made XML-ready, when required, for exchange with your trading partners.

Output

• Templates are used to convert data to a user viewable format so that you can view it via your WebDI mailbox.
• If the data is in an XML format, then the XML data is combined with an XSLT template to create a user viewable format.
• Information can be delivered to you in your preferred format, using the appropriate communication framework. Depending on your level of integration, data may be received directly into your back-office system and processed according to your business rules.
• WebDI handles a wide range of confirmation and acknowledgement processes, ranging from the traditional VAN-based 997 to e-mail confirmation, when documents are delivered. This depends on your business rules and communication capabilities.