Monthly Archives: December 2009

Give your Database a Makeover: Create a View

When setting up a process to translate data from your backend database to another format, it is common to realize that your source DB data is too disparate with how your target data format needs to be mapped/structured. Introducing database views can often simplify integration between two formats and reduce or eliminate the need for external programming.

A view is simply a named select statement that is stored in a database as an object. Using a view can simplify the mapping process by renaming fields (rows) to a purpose more easily understood.   Continue reading

SOAP Worst Practices Part 1: Non-XML Content

There are a lot of useful SOAP Web Services. Whether it is a simple zip code lookup service, or a more complex order entry system, a well-implemented SOAP Web Service can make machine to machine communication very reliable, efficient, and best of all, easy.

However, there are also a lot of poorly-implemented SOAP Web Services, and they can cause more problems than they intend to solve. This is the first in a series of articles that attempt to expose some of the more common mistakes and misunderstandings people make when implementing a SOAP Web Service.

SOAP Worst Practice #1: Non-XML Content

One of the main reasons to create a SOAP Web Service over a REST one is that SOAP provides a standardized method to publish the message format for your service. The message is in XML, and its structure is defined in the WSDL, or Web Service Definition Language. If you have an XML document that you want to transfer, embed its format in the WSDL and any consumer will be able to know the format to send to it.

But, if you have non-XML data to transfer, SOAP is probably not your best choice. Continue reading

Integrating Multiple Data Types

Integration of data is the process of combining different data types into one or more shared universal formats.  This process is integral to business as each unit within an organization can use different data types and therefore lack a unified view.  Data itself can be of various types such as flat files defined externally or delimited by a common data separator.  Data can also be stored in various kinds of databases, each with a unique method for defining and storing data.

For users of differing applications to view and use each others’ data it must be converted to the format of the other applications or to a universally defined format as is done through EDI transmissions.  A data integration product makes this process seamless and fully integrated into a user application system.  The software can either convert each application data type into every other type (a many to many conversion) or from one data type to a universal format – then from the universal format to a specific data type (a many to one conversion).

The use of a universal format is preferred as this makes it possible for each user to create applications and conversions based on an agreed upon standard (such as EDI: X12, EDIFACT, etc.).  This will also removes the requirement that each system be aware of the file formatting or application setup/configurations used by the remote system.  Each user employs the Integration software to map their data into a common and agreed upon standard…and vice-versa.

Eclipse Help Overview

Switching the EBI Developer Studio from a homegrown client to using the Eclipse platform will require changing how EXTOL developers implement everything related to the GUI, including how to access help from within the product. One of the projects I was assigned to do for EBI 3x was to look into the Eclipse help system. I enjoyed working on that project because the Eclipse team did a fantastic job producing a very advanced help system that we will certainly be taking advantage of. Continue reading

Integration Using External Tables

It is not uncommon to encounter situations where you need additional data that is not generally available either from your EDI application/interface (outbound) or from your trading partner (inbound).

Consider the situation where your trading partner sends purchase orders but omits the item descriptions…this item description being a necessary piece of information for processing the received orders.  One option is to require that your trading partner includes this description for each item on the order – good luck trying to persuade a buyer to accommodate your request.  Another option is to modify your application to eliminate this requirement – this may require a considerable amount of redevelopment.

The solution: Create an external table to host descriptions for each partner item that can be accessed during the translation process. Continue reading