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