EXTOL Technology Blog

With the ever-changing economy, especially now, businesses are looking for ways to reduce costs and become more efficient.  The new technologies (as previously discussed in Part 1 of this blog), coupled with the immediate need for cost cutting, have created the perfect environment to fuel another major shift in business communication.

One factor helping this shift is that technology has been developed and priced so that even small “Mom and Pop” shops can obtain affordable AS2 and/or FTP solutions.  The shift in cost of direct connections will fuel the move away from traditional Value Added Network (VAN) trading partners to having more AS2 and/or FTP partners (connection types).  This shift will increase more rapidly as a result of the constant need for companies to become more efficient to remain competitive.

Large retailers, such as Walmart, require a “direct” AS2 connection to do EDI business. This represents a key indicator that this shift to AS2 (and/or FTP) is becoming more prominent and recognized.

It is interesting to see this relationship go though another major change.  What we’re actually seeing is communications between Trading Partners coming full circle.  Initially there were leased lines and individual modems for connecting to trading partners.  Over time this became too expensive and, out of necessity to reduce communication costs, the VAN was born.  More recently the Internet was introduced, which provided a new and inexpensive means to communicate.  With expanding Internet capabilities, VANs became too expensive and too time consuming to manage.  Better, cheaper software was designed to utilize these new communication methods.  As a result, we now see more direct-connections being established in place of moving data through the traditional VANs.

This shift will require more time…it will not happen overnight.  Instead, it will be a slow migration that will occur over the next decade (possibly longer).  As new business relationships are formed, they will take advantage of these newer technologies; older methods are likely to remain with the VAN service (although the VANs often do provide other solutions and services besides merely the moving of data).  Going forward, implementations will generally see a mix of these connection options until costs and efficiency eventually eliminate those methods that restrict growth.

When setting up a new trading partner or business integration process, thinking through the process beforehand can greatly decrease the implementation time and help minimize problems. Many integration projects can come to a grinding halt in the middle of implementation if it’s only later realized that required data is not configured in your backend application, or if your system doesn’t support the particular communication protocol your new trading partner intends to use.  “Looking before leaping” will help alleviate potential problems later.

Read more…

In Electronic Data Interchange (EDI), digital certificates can be used to secure data transfers between systems.  Certificates can encrypt the data transfer in multiple ways.  First, the data itself could be encrypted, making it unreadable by any receiving system unless it has the proper decryption key. Second, the communication channel that the data is being sent through could be encrypted.  Third, encryption could apply to both the data and communications channel.  It is common for certificates to secure AS2 communication (data encryption) or SSL connections (communication channel encryption). Read more…

The Value Added Network (VAN) business began with a simple transaction that was manually transmitted within the grocery industry.  The VAN was developed out of a necessity for companies to replace their traditional business communication methods.  These methods included human interaction and the use of the postal service and the telephone.  Communicating in this way caused severe “bottle necks” and held up the flow of data.  This problem spawned the birth of the Electronic Data Interchange (EDI) standards.  EDI was developed to help standardize the electronic flow of business documents.  As this shift from manual to electronic business communications grew it opened up a market for how to exchange this data.  Thus, VAN business emerged as a direct result of this shift in business communication.

Read more…

Securing electronic communications is of paramount concern for companies exchanging business-critical transactions.  A recommended method to ensure a high level of security is to introduce an additional layer to the process: HTTP Proxy.  A previous EXTOL blog discussed some of the benefits provided by a proxy for AS2 transmissions; this will focus on the EXTOL Secure (ESX) Proxy.

It is important to consider that Secure Proxy is not a generalized HTTP proxy to be used for all network traffic.  It is a lightweight, low complexity solution designed to work for AS2 traffic only.  Secure Proxy should be deployed within a “DMZ” where it can perform important security functions such as weeding out insecure and potentially malicious traffic before it ever reaches the firewall. Read more…

Successful AS2 communications require a balancing act between two conflicting demands: your infrastructure has to be open enough to talk with your trading partners, but secure enough to keep out intruders and repel attacks. The familiar firewall is the tool of choice to resolve this, but it still requires that you tell your trading partner which ports are open. This could expose your network to security lapses on their end. Fortunately, there are several options available to minimize or eliminate this risk.

An obvious solution is to restrict incoming traffic only to the known IP addresses of your trading partners. While this is a good start, some other problems present themselves. Read more…

Batch Integration is the receiving and processing of business-critical data at predetermined (scheduled) times and arriving in “bulk” amounts.  Think of this as a large box of goods being delivered by your local carrier at the same time every day…if your mail doesn’t make it in today’s delivery then you must wait for tomorrow’s.

Transactional Integration is the receiving and processing of business-critical data at undetermined (non-scheduled) times and arriving “one piece at a time”.  Contrasted with Batch Integration, this is a courier that is always on the move carrying mail from one location to another on a near-continual basis… Read more…

EDI is a vital part of the transportation industry, and delayed transactions often mean missed revenue opportunities. The transport method used for EDI communications can affect the turnaround time for these documents.

Here is a typical scenario between a shipper and a carrier:

1. Shipper sends load tender (e.g., 204) to carrier.
2. Carrier sends response (e.g., 990), either accepting or declining the shipment. The response must be sent within a time period specified by the shipper. If not, the shipper will tender the load to another carrier.

If the carrier accepts the load tender:

3. Carrier sends a shipment status (214) with pick-up appointment date
and time.
4. Carrier sends a 214 with delivery appointment date and time
information.
5. Carrier sends a 214 with actual pick-up information.
6. Carrier sends a 214 with actual delivery information.
7. Carrier sends an invoice (210) with the charges for the shipment.

Read more…

In my last entry discussing the restriction of outbound communications, I briefly mentioned one of the benefits of using an automatic retry option for your AS2 transmissions. Automated resending, or what are sometimes called AS2 reliability features, can be a simplifying and powerful tool in a variety of situations beyond what I’ve already discussed, however. In this entry, I’m going to talk about some of those cases and the advantages they offer.

Most AS2 applications offer some sort of automatic retry facility in case the initial attempt to send an outbound document fails. Despite this, I’ve noticed that many users ignore this feature. They might wonder what the point in retrying is, thinking that a failure in an HTTP transmission usually indicates something that is not going to resolve itself, Read more…

For my inaugural post on this blog, I want to revisit one of those “solved problems” that still dogs many of the companies we talk with, namely, how to handle B2B integration requirements that don’t involve standard EDI. Companies still find it difficult to cope with the full range of B2B connections and content types needed to integrate with large and small trading partners, including:

• Standard EDI (and in some cases, EDI that does not fully conform to standards)
• “Standard” XML, which ranges from well-developed, horizontal standards like RosettaNet to hundreds of loosely-defined vertical transaction sets
• EDI-like flat file standards (most of these are older, vertically-focused cases)
• EDI-based web forms
• Proprietary, partner-defined flat files
• Proprietary, partner-defined spreadsheets
• Proprietary, partner-defined web portals
• Proprietary, partner-defined documents sent by email or fax

Did I miss any? Probably. But the point is that standard EDI is just one of numerous conventions used for B2B integration.  Of course, standard X12 and EDIFACT EDI are still the mainstay of B2B integration. And there is little evidence to suggest that companies are ready to invest in replacing all of their EDI connections with something “better”.  In fact, EDI adoption is increasing.

Read more…