Integrating with customers, suppliers, service providers, and applications is important to EXTOL’s daily internal operations, just as it is with your company. And probably just like your company, to manage those operations we initially relied on various disparate manual and/or home-grown semi-automated yet labor-intensive processes that inevitably involved no-longer-necessary and overlapping (if not outright redundant) activities. It wasn’t planned like that − it just sort of happened.
We’ve learned many lessons while “dogfooding” our internal operations. Before using our own product − EXTOL Business Integrator (EBI) − to streamline those operations, the first (and most daunting) task was to untangle the jungle of existing processes in an attempt to understand their ultimate goal. Read more…
Data Integration is defined as, “the combining of fragmented data residing in different sources and locations which are aligned to support business goals”. There are many reasons to bring data of different types (flat file, DB2, or even spreadsheets), possibly residing on different servers, to one main location to be integrated together. If you do Electronic Data Interchange (EDI), translating data between an EDI fixed format and application variable format files, then you have already been doing a piece of the data integration puzzle. Read more…
Camels can be stubborn and angry animals if you don’t take care of them. Lucky for you the EXTOL development team has figured out how to tame them. And we even taught them how to work with data!
Everywhere we look today we can see patterns. They’re in your shirt or tie. You witness traffic patterns (big or small) on your way to work. There are even patterns of integration – Enterprise Integration Patterns (EIP). These patterns allow you to define standard ways of dealing with messaging systems. Examples of these patterns include content-based routing and wiretapping. Read more…
Successful EDI implementations must begin with the development and employment of efficient object naming conventions using “best practices”. This will avoid aggravation and redevelopment at a later time. “Doing it correctly the first time” is a most-relevant piece of advice. This is of particular advantage when creating files (tables) to store EDI data (the implementation and deployment of EDI interface / staging files and in support of both inbound and outbound EDI transactions).
Read more…
Tweeting… it seems that everyone is doing it these days. But, what are we tweeting about? Is it really useful, serving a valuable purpose or does it just add to the noise of the social arena within the Internet? Does it really change another’s life or perspective knowing that their friend is “sitting on his back porch”?
Recently, I was in a discussion with a colleague exploring the impact of mobile devices as a means of monitoring system operational health and activity. We cited the merits of having a smart-phone and being able to check on the status of a back-end system’s activity. We thought about the content that would most interest system managers: resource status, hung processes and Service-Level Agreement (SLA) compliance. Read more…
To understand and fully appreciate the benefits of Data Integration we must first ask the question, “What is data”? Data is “information”; it can come in many flavors, using many formats, and serving many purposes. Data could be the contents of a spreadsheet; it could be the contents of a single “cell” within that spreadsheet.
My experience is with the implementation of data, particularly data either being sent-to or received-from a trading partner/customer (considered Business-to-Business or “B2B” data, such as “EDI”). Data integration focuses on the practical business use of this information and not necessarily the formats where the data is stored (although that does affect how that information is eventually processed and interpreted). Read more…
In my next two blogs, I will be discussing a common challenge facing EXTOL users — the handling of proprietary flat file data received from trading partners. The flat file trend is becoming more popular and, more importantly, being forced on users by their trading partners. We’ve seen a trend where you are either forced to handle the data in the format it is presented or lose the business. Another side of the increase in processing flat file data is to accommodate smaller “Mom & Pop” shops without the means to present the data in a better format.
Let’s explore the different flavors of flat file data. Flat file data can fall into one of two format types: single format or multiple format. Single format files have a common record layout throughout the entire payload data. This means, for example, that every record in the payload has the same exact layout, all of the fields are identified in the same manner in every record and every record of data is treated the same way in the pending data transformation. Multiple format files contain more than a single record layout throughout the payload. This means you will see multiple record layouts needing to be identified and treated as different records in the pending transformation. Read more…
A few months ago, my colleague Jason Honicker wrote an entry on the EXTOL Technology Blog explaining how database triggers can be used to expand the functionality of your database to do more than just store data. I wanted to further the discussion on databases and talk this time about stored procedures.
A stored procedure is a routine, or program, which resides as part of the database itself. It’s typically written in SQL, PL/SQL, Java or .NET, depending on the type of database being used. Stored procedures enable developers and system administrators to maintain only one piece of code, which may be used across multiple business applications. This takes some of the pressure for business application developers to have to develop the database function directly into the business application. Instead, they simply need to know the procedure name, the parameters it requires and what kind of data could be returned. Read more…
Many considerations must be assessed when deciding on a standard format for exchanging information electronically with trading partners. Two of the more widely used document standards are Electronic Data Interchange (EDI) and Extensible Markup Language (XML). Of course, when doing business with buyers and larger partners it is generally necessary to comply with the requirements of those trading partners. However, it is good practice, and demonstrates good business sense, to be proactive and develop an in-house (internal) data specification (and format) that will provide an option for smaller partners to comply with.
Questions must be answered before best decisions can be made for your needs. Read more…
Structured Query Language (SQL) is a database computer language designed for managing data within relational databases. The most common applications for SQL are actions (calls) on the database using SELECT, UPDATE, DELETE and INSERT (data) functions. SQL can provide many other database calls that will contribute to the reduction of user programs. SQL includes built-in functionality that can help format and calculate data during any of these database actions/calls. Below are some examples of using SQL functions to accomplish these processes. Read more…