Feature Details
Communications
ODEXplus simultaneously supports OFTP communications over native X.25, X.25 over ISDN, TCP/IP and X.25 over TCP/IP (XOT). In a Clearing Centre environment X.400 MTA communications can also be performed over X.25 and TCP/IP.
Up to 256 simultaneous communications sessions, both outgoing and incoming calls, can be handled using any supported network transport.
ODEXplus can be used to communicate directly with a trading partner, or indirectly through an EDI VAN. The low-level network transport, either X.25, ISDN, TCP/IP or XOT, is selected according to the definition for that particular trading partner.
Figure: ODEXPlus Comms Support
X.25 Support
ODEX supports X.25 through the specific X.25 software interface provided by the operating system. The machine in question can be connected to an internal X.25 network or directly to the national X.25 network. Because all the national X.25 networks are connected together, the X.25 network can be regarded as a single international network providing access to more locations in more countries than any other network.
ODEX supports multiple simultaneous communications sessions, all of which are established over a single connection to the X.25 network. The local service provider will define the X.25 connection with a number of virtual circuits over which the communications is performed. These sessions share the bandwidth of the X.25 line.
TCP/IP Support
ODEX supports both incoming and outgoing OFTP over TCP/IP on user-definable TCP/IP ports. The implementation of TCP/IP makes it possible to connect an OFTP system to the Internet providing a high bandwidth, low-cost, business data delivery mechanism.
Although the Internet is an ideal delivery mechanism, some corporate policies prevent the transmission of business data over public networks. If this is a concern then a private TCP/IP network can be implemented where users dial in, using ISDN or a standard modem, and connect into a safe and controlled part of their network that can be used to exchange business data.
In either instance the segment of the network that is being accessed should be protected by a Firewall to ensure that the internal network, no matter how isolated, is not compromised.
Figure: ODEXplus TCP/IP Solution With High Connectivity
In the event that ODEX has to initiate a call with a remote network, the Router and Firewall will have to route the request to the remote network, either using an ISDN call, Leased Line or Internet connection.
ISDN Support
A popular alternative to X.25 is the Integrated Services Digital Network (ISDN), which is widely supported within Europe and in developed countries throughout the world. It is a digital service, requiring no modems and able to communicate at 64,000 bits per second.
ISDN connections are part of the normal telephone service so they are cheaper to install and rent, and transmission charges are typically the same as normal telephone calls. This, added to the high data rate, makes ISDN ideal for the transmission of large amounts of data, such as CAD/CAM applications.
The ODETTE standards body has recommended a method of adopting ISDN communications for those who already use OFTP and X.25. This method is to carry X.25 over the top of the ISDN connection and then run the OFTP protocol over the top of this.
A BinTec Brick provides the ISDN support within ODEXplus. Depending on the model in question the Brick can support either Basic Rate ISDN (BRI), which has support for two channels, or Primary Rate ISDN (PRI), which has support for up to thirty channels. Both BRI and PRI are supported by ODEXplus.
XOT Connectivity
XOT (X.25 over TCP/IP) allows X.25 packets to be sent over a TCP/IP network instead of an X.25 network.
This allows the use of X.25 networks without the requirement for expensive X.25 hardware within the ODEXplus hardware platform. This feature also allows customers to utilise their own TCP/IP networks to carry X.25 traffic, before connecting to an XOT capable router (e.g. Cisco) which is in turn connected to an X.25 network.
Security
ODEXplus provides data level security through the use of PGP techniques. This allows data files to be encrypted and digitally signed, which helps to ensure that only the intended recipient can decrypt them and that the file integrity has not been compromised during transmission. PGP encryption is especially applicable when transmitting files across the public Internet or for files that contain confidential data.
The PGP implementation also provides an efficient file compression capability that can reduce the cost involved in transmitting data over a point-to-point link by reducing the amount of data exchanged.
The keys that are used to encrypt and sign the data files can be generated in 512, 1024, 2048 and 4096 bit strength depending on your security requirements. Key distribution is simplified by virtue of being able to transmit a key file to its recipient using OFTP, or alternatively it can be extracted to a file for distribution via another means.
ODEXplus supports the following encryption and compression algorithms:
Symmetric
- CAST5
- AES 128, 192, 256 bit
- 3DES
- Twofish 256 bit
Asymmetric
- RSA v3 up to 4096 bits
- DSA
- ElGamal
Signature
Compression
Additional modules
ODEXplus has been designed so that you can add extra features and components as and when you require them.
X.400 Protocol
When ODEXplus is used as a Clearing Centre it might be required to interconnect with other VANs using the X.400 protocol as opposed to OFTP. It is for that reason that ODEXplus provides an optional X.400 component that allows information to be exchanged between OFTP users on the ODEXplus system and users on a remote VAN accessible via X.400.
There are many X.400 standards used around the world and Data Interchange has implemented its ODEX support based around the European P2 approach. This approach carries the EDI data contained within the body part of an X.400 Inter Personal message and exchanged data between Message Transfer Agents (MTA).
The ODEXplus X.400 extension supports three MTA standards, two of which are X.400 and the other is X.410:
The exchange between User Agents (UA), which can be conceptualised as mailboxes on an email server, can be represented as follows. The diagram also shows the interaction between the MTAs, where the UAs are located, and the way in which encoded data is moved between them.
Figure: Overview of X.400 Communications Using The P2 Standard
There are four major protocols within X.400:
- The P1 protocol is the message transfer protocol between two MTAs and also provides the 'envelope' used to contain a message.
- The P2 protocol is the User Agent to User Agent (UA) protocol. It consists of Inter Personal Messages (IPM) and Inter Personal Notifications (IPN), which can be considered as an email transfer and a delivery/read receipt. P2 protocol elements are conveyed by P1, P3 and P7 protocols.
- The P3 protocol is the message transfer system (MTS) access protocol and is used to provide remote access to a MTA from a message transfer user system such as a user agent (UA) or message store (MS).
- The P7 protocol is the message store access protocol and is used to provide remote access to a message store from a user agent.
The ODEXplus implementation concentrates on the P1 and P2 standards, where the P1 standard is used to convey information between MTAs, which, in effect, enables the P2 transfer.
Folder Support (ENGDAT)
ODEXplus also provides a component that supports the scheduling and extraction of ENGDAT folders.
An ENGDAT folder consists of an ENGDAT EDI message plus one or more associated files. There is therefore a requirement to be able to access the files making up the folder as if they were a single file.
With the installation of the ENGDAT Folder support module, network nodes and file nodes can be configured as a folder node. This enables multiple files with common filenames starting ENG and ending in a sequence number to be handled as a folder i.e. as a single file.
GALIA Command Support
With the installation of the ODEX GALIA command server, network nodes and file nodes can be individually enabled to support the GALIA command set. GALIA command files sent to this node will then cause specific actions from ODEX, ranging from listing the contents of a mailbox to specific folder extraction.
The OFTP protocol has no facility to allow a remote user to enquire upon the contents of their mailbox within the clearing centre. Upon an OFTP connection taking place, the entire contents of the user’s mailbox are downloaded in the same session. For large CAD/CAM files this situation is undesirable if only one out of many CAD/CAM files is actually required.
In order to overcome this, the French ODETTE organisation, GALIA, has created a standardised command set which allows the users of an OFTP clearing centre to enquire upon their mailbox and to download only the files that are specified by the user.
GALIA commands are separate files, each containing a line of text. These files are transmitted by a remote user to the ODEXplus clearing centre, using standard OFTP rules.
As well as ENGDAT and associated data files, ODEXplus also supports the concept of GALIA ‘Administrative Folders’. These folders allow the user to obtain information relating to the activity within the mailbox.
OFTP Functionality
ODEXplus conforms to the communications standards for file transfer defined by ODETTE, called the ODETTE File Transfer Protocol (OFTP).
One of the advantages of OFTP is that it can be used for transparent communications between PCs, mid-range, UNIX and AS/400 platforms and Mainframes over a number of low-level network protocols.
ODEXplus fully implements the OFTP protocol, which includes the following features:
- Data Compression
- Restart Security
- Special Logic
- Fixed, Unformatted, Variable and Text file types
- File direction enforcement
OFTP Data Compression may be enabled on a global basis and will compress all transmitted data that contains multiple repeating characters. This allows for a higher data throughput and reduces the transmission costs.
OFTP Restart allows, in the event of a communications session being interrupted, files that were in the process of being transmitted to recover from the point at which the last valid checkpoint was made.
The OFTP transmission parameters can be configured in ODEXplus such that different block sizes and windows size can be used on the system. As with all OFTP systems, if the remote partners cannot support the parameters, the two systems agree to use the lowest compatible set of parameters.
Trading Partner Functionality
The details of each partner for which communications are to be permitted must be defined in ODEX. Only those trading partners defined in ODEX can establish a communication session; anybody else will be rejected. This provides complete control over the users that are permitted to connect.
For each trading partner defined to ODEX, a unique profile can be specified, defining the way in which the communications will be performed. Profile parameters include connection information, such as the destination EDI Code, the network transport and the address with which the connection should be made.
Profile information also includes a flag that can be set to indicate whether files to and from the particular file node should be converted between ASCII and EBCDIC.
N.B. ODEXplus does not recognise whether a file is in EBCDIC or ASCII and simply carries out the conversion if requested, which could potentially result in the conversion of ASCII to ASCII or EBCDIC to EBCDIC.
In addition to the connection information that is defined for a trading partner, additional message level controls and actions can be specified.
Using Trading Partner Relationships it is possible to restrict the messages that are exchanged between users in a Clearing Centre environment. In an environment where ODEXplus is being used to exchange data directly with partners, Trading Partner Relationships can be used to define an action on file receipt.
Relationships can be defined against the originator/destination of the received EDI data or even down to the message type/version/release levels acceptable for each origin and destination.
Automation and Integration
In common with all members of the ODEX product family, ODEX Enterprise operates in a dark room environment. This means that manual intervention is not necessary under normal circumstances and there is therefore no requirement for IT staff to be on-site 24 hours a day. If any event occurs which does require manual intervention, ODEX Enterprise can be configured to trigger the sending of an alarm pager call to the appropriate person.
Integration with Back Office systems is supported through the ODEX batch interface. This allows either a command line or script execution that allows data to be scheduled to ODEX or extracted from ODEX. Other functions can also be performed, such as triggering a call out or amending trading partner details, without using the interactive programs.
Logging and Visibility
ODEX has a very comprehensive reporting capability that allows the user to know the status of the EDI system at all times.
Figure: ODEXPlus Monitoring
ODEX maintains a comprehensive audit trail of all sessions established together with details of files transmitted and received. The log is in a user readable form with each message having a unique message identifier.
System Accounting And Reporting
All communication transactions are recorded at session, file and message level. This information is available through a number of standard reports or alternatively users may tailor these to their own requirements. Session information such as the call duration, amount of data transmitted, amount of data received and the number of files transmitted and received is provided for analysis and/or billing purposes.
The details of every file that passes through ODEXplus are recorded giving file size, message type, OFTP virtual file details, and origin/destination information. The output can be monitored in real time by opening the accounting pipe or retrospectively by analysing the accounting files, which are periodically archived at user-defined intervals.
EDI functionality
Although originally designed for EDI, ODEX can also be used for the transfer of non-EDI data, such as CAD/CAM drawings and engineering data.
Message Split
ODEX has an EDI file split/merge capability that can process EDIFACT, ANSI X12 and UNGTDI syntaxed EDI data files.
Consider the situation where a Back Office system has generated a file that contains EDI data that is to be sent to a number of trading partners. ODEX will split the EDI file into a number of smaller files on an interchange basis and automatically schedule the individual data files ready for transmission, based on the destination EDI codes. ODEX not only knows where the data should be sent, but also how it is to be sent.
Figure: ODEXPlus Message Splitting
Message Merge
The merge function is used to process received EDI data. Consider the situation where orders data has been received from a number of different trading partners. The merge function will collect together all of the orders messages and combine them into a single file, if required, ready for Back Office system processing.