When implementing an e-business integration solution, whether it is cloud, data, application-to-application (A2A) or business-to-business (B2B), there are always common activities that have to be performed. One of those activities is creating the data transformation maps. This is usually the most complicated and time consuming part of the integration process. In an attempt to reduce time and effort required to create these maps, different approaches, both manual and automated, have been tried and tested. Let’s take a look at some of these methods and which circumstances to use them:
One available approach is the process of identifying the source and target data formats, then manually mapping the rules for the transformation. Unlike the old conventional method of coding, current integration middleware solutions usually employ some form of visual drag-and-drop functionality. This is the most common, but also the most time-consuming approach. Manual mapping can be used for building new transformations, especially when no similar map is available to use as a starting point. This approach can also be used when implementing a brand new integration middleware solution, or when there aren’t any other available options. Examples of this are when new applications and trading partners are integrated into the solution or, when brand new document formats from external integrations are introduced. Continue reading
Electronic data interchange (EDI) has been around since the late 1960’s and has been adopted by thousands of organizations since that time. Many of these organizations purchased or developed their back-end software systems and communication methods with the intention of supporting EDI. Not only were the back-end systems and communication methods “EDI-centric”, but organizations also needed to purchase or develop programs to translate the EDI data to and from their applications and data. Because EDI has been around for decades and because many of these older systems were constructed for EDI, the word “legacy” tends to come up a lot when referring to EDI. In reality, EDI is a mature technology that is utilized by older systems, but it isn’t outdated. It is the hardware and software systems built around the EDI data that are becoming legacy, not EDI. In fact, thousands of organizations are currently implementing EDI for the first time. Some of these organizations may have to implement EDI because of new relationships with other organizations that mandate EDI (new trading partner relationships) or they may decide to use and implement the EDI as a canonical model for their application-to-application (A2A) initiatives as discussed in Mark Denchy’s blog, Canonical models, not just your ordinary middleman . No matter the case, EDI is a proven interchange model and not going away anytime soon.
Now that we identified the fact that EDI is still a viable option, what can we do to “modernize” it? We can do this a number of ways, from changing the back-end software and/or hardware systems to implementing tools to improve the way the data is processed. But first, let’s start by enhancing the definition of EDI. EDI can be defined as the electronic transfer of standardized structured data from one organization to another to enable business-to-business (B2B) collaboration. This definition provides more meaning than the traditional “legacy” definition, being the computer to computer exchange of structured information, that some of us are more familiar with. Continue reading
When choosing an integration software solution, do your requirements include the ability to make integration results or the outcome of the transactions, available to the customer services team, accounts receivable or the management staff? And when your requirements include business-to-business integration, do you also need to share results with your trading partners? Many times the answer to these questions is no, for a number of reasons including, but not limited to:
- Prior experiences where this functionality was available, but as a costly customization
- No need to expose this information to others
- Not aware this functionality can be a requirement of integration middleware Continue reading
When talking about integration, whether it is application to application (A2A), business to business (B2B) or data and cloud integration, the goal is to exchange data, documents, information, and/or messages between a source and a target. To accomplish this goal, we identify business patterns related to the sources and targets of these “integrations” and then apply the identified patterns to similar scenarios that meet specified criteria. Most, if not all of these patterns will require data mappings, also known as “maps” or “rulesets”, at some point during the integration process. These maps are ultimately used to perform one of two operations: to transform or translate data. I often use the terms, transform and translate, interchangeably. But, is there more to them? Are these terms synonymous, or do their meanings differ?
Let’s look at this a little closer to see if there is a difference. Data translation can be defined as the process of converting data from one syntax to another and performing value lookups or substitutions from the data during the process. Translation can include data validation as well. One example of data translation is to convert EDI purchase order document data into purchase order database files or even flat files while performing data validation on the source data. Continue reading
Now that we are well past the hype of Web Services, what can they do for your company? Before we answer this question, let’s clarify what Web Services really are.
One traditional definition states that they are any service available over the Internet using a standardized XML messaging system and not tied to any operating system or programming language. In the early days this was true, but the definition has evolved over the past decade. The World Wide Web Consortium (W3C) defines Web Services as a software system designed to support interoperable machine-to-machine interaction over a network. Gartner defines them as “a software component that can be accessed by another application (client, server, another Web service) through the use of generally available, ubiquitous protocols and transports (HTTP).” Continue reading