Tag Archives: Application Integration

Integrating EDI with your Backend Application

Whether you have an ERP (Enterprise Resource Planning) or a “home grown” application, there are many considerations for integrating EDI to your backend application. Many ERP systems have an EDI interface module consisting of a set interface files (specific to EDI transaction sets) and integration programs. The EDI modules may contain simple “flat file” structures or more robust database structures.

If your backend application is “home grown” and you’re handed an EDI mandate then your first decision is whether to integrate directly into your application or develop and implement an EDI interface. An interface layer allows for manipulation of the data (editing, formatting, and/or validity checking) before it is integrated with your application. Continue reading

Selecting a Database: Flat File vs. Relational

Determining the type of database to be deployed for a project is a combination of access requirements and preference. In an effort to make an informed decision on which to deploy, the application engineer should be familiar with the types of databases as well as the pros/cons of each. In this entry we will consider two general types of databases and explore some of their applications and key points in the decision cycle when faced with a project. Continue reading

Don’t Ignore the Automated Resending Feature

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, Continue reading

To SDQ or Not to SDQ

Does the handling of the SDQ segments within your EDI, applications and business practices puzzle you?  Well, you’re not alone. SDQ segments have been around for a while now, but still seem to cause havoc for IT staff!

SDQ segments occur in several message types, including 852 and 860, but the most common message would be the 850 Purchase Order (PO).  The traditional PO included one Ship-To location per order and the layout was very similar to the document itself.  The purchase order layout included a header (PO number and date, purchaser name, address, etc), detail (item, quantity, and price) and a summary.  The disadvantages to the easy layout were the redundant use of information and the large batches of these documents.

To capture this data, your application system most likely included two files: header/summary and a detail using a unique key relationship.  The formatting was easy to read, having only one ship-to per order.  The traditional PO structure made it simple for applications as well, allowing easy-to-create formats in file setups.

The original reason for the SDQ segment was to decrease the number and the size of transactions by allowing multiple ship-to locations per order.   On a purchase order SDQ segment, it lists quantity per location and locations. In the P0102 element there is the total quantity.   The SDQ03 holds a location number and the SDQ04 lists the quantity for the location in the SDQ03. The SDQ05 and 06 follow the same pattern which is repeated up to SDQ22.  Hence “pairing” indicating location and quantity pairing, the segment contains multiple “pairs” for a specific item noted in the PO1 segment. There can be up to 500 SDQ segments containing ten “pairs” per segment.  Changing the traditional PO to a PO with an SDQ allowed partners to include more than one order per transaction.  It also accomplishes what it set out to do: decreasing the size of the orders and removing the repeating data.  However, creating new advantages creates new disadvantages.  Some of the disadvantages include the assumption that the location address information can be referenced by the user’s application. The SDQ multiple locations format doesn’t include address information for these locations.  Also, SDQ standard currently does not state how many “pairs” are required per segment.  You may have many SDQ segments each having a varying amount of “pairs” on each line. These disadvantages may not sound like major issues, but just ask the IT staff of other companies who needed a solution (sometimes very quickly) on how to capture this newly formatted data and the havoc it can cause.

Here in lies the question: what would you do if you receive a PO destined for multiple locations and currently you are configured with 2 files: a header/summary and detail?  Do you create additional fields for every pair in the existing detail file?  How many fields should be created?  How are the blank pairings handled within the application?  How will your application now respond to multiple detail lines in the same order?

Your translator and application will ultimately determine the route to take in handling multiple orders within an SDQ order.  However, it may be advantageous for you to look into creating a new SDQ file and not an extension of the detail file.  This would allow the writing of records on the PO1 for detail information and SDQ data to the SDQ file.  Verify if your current translator can write a new record for EACH pairing, ultimately eliminating the possibility of writing blank pairs to your application.  Keep in mind that in order to satisfy the needs of your application you still may need some type of post process.  This post process would handle application requirements, such as manipulation of quantities to even breaking out each SDQ pair into individual purchase orders.  Happy Mapping!

Restricting Traffic Inside and Out

While considering enhancements for the next version of EXTOL’s AS2 product a while ago, I was presented with what I initially thought was a curious, if not paranoid, enhancement request: a customer wanted to be able to restrict outgoing traffic to specific ports.

My first question was: “Why bother?” Indeed, the vast majority of our customers had no restrictions on their outgoing source, or egress, ports and the concern of network administrators has traditionally been on restricting who and what can come into the network from outside. While the threat from viruses, worms, denial-of-service attacks targeted at a company’s internet infrastructure from the outside is obvious, the perils from inside the network are not so readily apparent. Nevertheless, they are worthy of a security conscious IT professional’s close consideration.

So what can a company gain by restricting the traffic over its egress ports? Continue reading