What is a map? Most would answer that it is a collection of relationships between a source document and a target document. This implies that the relationships are at the data-item level. But, isn’t it true that a map, at its essence, is a repository of business knowledge showing the relationship between business elements?
Let’s consider a small company in the United States supporting the Order-To-Cash process. As the company grows, it realizes that it will greatly benefit from the efficiencies of exchanging EDI (ANSI X12) with its trading partners to process orders, send out shipment notices and submit invoices. So, it implements EDI using X12 documents.
Then, the disruptive business event happens. The company expands their market penetration into Europe and begins trading with European partners. But, there is an immediate challenge. European companies typically do not trade using X12. The European standard is EDIFACT. The company now has to accommodate this new standard. To further complicate matters, customers in the United Kingdom want to exchange EDI using TRADACOMS and EANCOM. Finally, pushing the EDI team to the brink of desperation are the customers from Asia-Pacific (APAC) that do not use any EDI. They want to exchange flat-files, XML or even more daunting…spreadsheets.
This scenario would cause great stress in any IT group. But, let’s think about the challenge from a different perspective. Going back to the idea that our X12 maps are repositories of business knowledge, can we leverage that knowledge to help us accommodate the business needs of the company’s growth?
The answer is yes. If we could create relationships between our X12 document structures (schemas) and the new document formats, it is possible to “transform” the actual maps into new maps. This is exactly what the Migration Assistant in the EXTOL Business Integrator does. It is far easier to create relationships between two similar documents (X12 850 Purchase Order and EDIFACT ORDERS) than to create actual data maps to move data between two dissimilar data formats. If a migration tool that could accomplish schema-to-schema migration were available, the challenge shifts to become a mechanical issue and may just require minor adjustments to bring the support for new formats online. Reducing the complexity of the migration process also speeds time to market and greatly reduces risk because the company is re-using their proven business knowledge.
Analyzing process activities “on the fly” to make timely critical business decisions requires a tool that provides end-to-end visibility to both technical and non-technical users. In Nahid Jilovec’s white paper, Top Ten “Must Haves” of an Integration Solution, Business Activity Monitoring (BAM) is cited as a major piece of your integration solution to ensure that all processes are running smoothly.
A good integration solution should provide real-time views of all end-to-end transactions, processes and events through the use of configurable dashboards, flexible report creation, and rules-based alerts and notifications. With a BAM solution, you can define what data will be displayed and how. For example, you can apply filters to your key performance indicator (KPI) reports to identify which of your trading partners are hitting your system the most over a specified period of time. You might also want to create a view to show the status of key system operations like the integration server or a series of queues.
To assist in identifying which processes came from a specific event, the BAM solution should allow users to easily create and run log filters over processes. Because integration solutions keep a log of all inbound and outbound transactions, users can design their own custom log searches based on status or results.
Check out the Top Ten “Must Haves” of an Integration Solution white paper to help measure if your integration solution truly provides more streamlined processes, full on-demand visibility, and accurate reporting.
The decision to implement an integration solution usually leads to more requirements, more questions and more complexity. Overall, implementing an integration solution, large or small, can be a daunting task. Many factors must be considered, such as: Read more…
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. Read more…