EXTOL Technology Blog

For those old enough to remember this reference (and for those young enough to know how to Google it), sometimes I feel like the Lorne Greene of EXTOL. Not in his role as the patriarch of Bonanza’s Cartwright clan, but rather as the dog food pitchman.

The series of 1980s TV commercials for Alpo^® dog food featuring Greene closed with the veteran actor claiming that Alpo is so good he feeds it to his own dogs. Hence, the notion of using one’s own product became known as “eating your own dog food”. Or so the legend goes. [A less-tasteful alternative account of the phrase’s origin has the president of a rival pet food corporation eating a can of his company's dog food at every shareholders meeting.]

During my first eight years with EXTOL, I was blissfully unaware of this term. But when I assumed the newly-created role of Special Projects Coordinator four years ago, Tony Baran (our co-founder, President, and CEO) caught me lingering at the coffeemaker and directed me to lead the effort to “eat our own dog food”. I mustered my best blank stare, nodded assuredly, scurried to my cubicle, and Googled that phrase (actually, I had one of my younger officemates show me how to Google it). Only then did Tony’s mandate to “streamline our processes by eliminating error-prone re-keying of transactional and/or persisted data by automating the exchange of information between applications, databases, spreadsheets, and other sources” − I’m paraphrasing here − make sense. And oh yeah, “use EXTOL Business Integrator to do it”. Aha! − we would “eat our own dog food”.

While “eating your own dog food” now has been elevated to acronym status, EYODF is more than a mouthful − I prefer the much more palatable and trendy “dogfooding”. While we don’t make (nor eat, for that matter) dog food at EXTOL, we do produce some seriously efficient business-to-business (B2B) and application-to-application (A2A) integration software that coordinates external partner interactions and internal business activities. And now we’re dogfooding.

In subsequent posts, I’ll share our experiences in using EXTOL Business Integrator (EBI) to solve our company’s data integration, manipulation, and migration needs. By telling our story and noting the lessons learned (mostly the hard way − those are the best-remembered lessons), we hope you can use EBI to your best advantage to tackle similar projects in your organization. You have them − just look around.

And please, if you care to share your stories with us, do. Who knows: maybe we’ll send you a can of Alpo.

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…

Standards only remain “standard” until the next change. Even in the B2B EDI world where trading partner data exchanges are “supposed to be” standardized, new additions and upgrades to later versions will create an opportunity to re-evaluate how data is being moved and stored for company consumption.

Traditional EDI transactions are built upon the “Header” and “Detail” premise where a single iteration of header information could be followed by many iterations of detail information. This makes it simple to build a database in support of this structure – a single transaction would see one record moved into the header file, and one or more records moved into the detail file. Header and detail would be linked together through common key values and sequential controls.

As requirements mature, changes are made and generally new information is presented. This could come by way of additional (single or multiple pieces of) data that could be stored in either the header or detail file. Trouble begins to brew when this new data is defined [by itself] as repeating information. Read more…

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? Read more…

Enterprise Service Busses (ESBs) offer an interesting communications layer that enables an enterprise to expose data to interested parties (i.e. applications, data-feeds, etc.) with a Publish/Subscribe model.  The Pub/Sub model originated in the printed media world, utilized as a distribution model for newspapers and magazines. It has evolved with modern times into the electronic age in the form of email-subscribed newsletters, and more recently, RSS feeds such as blogs.

In the enterprise, there is a growing need to share data among systems, both internally (A2A) and externally (B2B).  However, as new demands for sharing data surface, we need a way to “bolt in” the new requestors without impacting our current implementations.

ESBs commonly implement a variant of the GoF Observer Pattern.  This exposes a Publication/Subscription model allowing information sources (publisher) to expose data (message) on a queue.  One or more interested parties (subscriber) consume the data.  The key benefit of loose coupling in a Publication/Subscription model is that the Publisher does not need to know, or care, about “who” is subscribing.  The data is published and downstream subscribers use the data as they see fit.

Read more…