Home > Articles > Software Development & Management

Fundamentals of Supporting ERP-Linked Databases

  • Print
  • + Share This
On average, the majority of ERP systems rely on three or more databases to complete their tasks. Keeping these integration points scalable as transactions increase (in an order management system, for example) takes forethought and planning. Exacerbating this problem is the need to show audit trails during Sarbanes-Oxley audits. Louis Columbus examines the integration points that merit special attention.
Like this article? We recommend

Like this article? We recommend

Supporting an SAP, Oracle, or Microsoft enterprise resource planning (ERP) instance from one or more databases requires a special set of tasks and tools to ensure high performance and continued database and ERP instance reliability. For example, a strong focus on integration and the day-to-day health of adapters and connectors—many of which are built to support batch-oriented production workflows such as order management—means much more monitoring than is the case in other database implementations.

In my experience, adapters can scale up to three database connections per SAP R/3 instance; after that point, adapters tend to degrade total ERP system performance. This article discusses such practical lessons learned from working on integration projects linking databases and ERP systems.

Managing Integration Points Effectively

In the manufacturing companies with which I've worked, an average of three to five databases are integrated to an ERP system. Building our own connectors and adapters for SAP R/3 took more time than integrating to our own homegrown ERP systems, mainly due to the learning curve on ABAP, the SAP programming language. Buying an adapter to connect databases to an ERP system can run from approximately $15,000 for a setup that's merely functional to more than $50,000 for one capable of real-time asynchronous updates and transaction and pricing support. In short, there's a huge variation in the quality of adapters available for connecting databases to the ERP system(s) of choice in your company. Adapters can scale only so far, however; it's crucial to define a performance benchmark and watch overall system cycle times to see when you may need to revamp an adapter's structure or move toward a more advanced solution, such as an enterprise application integration (EAI) platform.

Following are some of the rules I've learned from working with adapters and connectors to complete integrations to ERP systems:

  • Adapters and connectors will typically scale to up to five applications within the ERP system you're using, including the accounts payable and accounts receivable databases. (These two databases are responsible for the majority of the traffic on any ERP system.)
  • ABAP programming is transaction-oriented. If you're running an SAP R/3 instance or later, consider having an adapter just for order workflows and scheduling, between production centers and the main R/3 instance(s).
  • ERP vendors want you to believe that every connection needs to be in real time, which in many systems is overkill. Consider making a roadmap of the specific connections and their frequency of use; such a tracking plan can help to prevent overspending on adapters, connectors, and EAI tools. Too often, manufacturing companies in particular revert to real-time connections with a batch-oriented approach to integration, when in fact batch-oriented connections between systems are all that's really needed. Many businesses continue to rely on periodic updates of transactions; real-time transaction support is driven not by the integration strategy but by the business needs of the manufacturer.
  • When the ERP system you're running goes through a major upgrade, perform scalability testing on adapters using revised Bills of Materials. New elements in a Bill of Materials can affect integration through adapters, and often impact performance when a manufacturer moves to more complex products over time.
  • If you've developed your own adapters, certify them with the appropriate ERP vendor. For example, while your custom SAP adapter may handle the day-to-day work of transferring data sets, tablespaces, and pricing tables to ERP scheduling systems, will the ABAP programming approaches taken by your adapter handle a move to an XApps-based ERP platform in the future? In short, adapters and connectors need to be checked out with ERP vendors to ensure upward compatibility. Oracle, SAP, and others have downloadable kits specifically for this purpose.

The ability to keep integration points current with an ERP system requires a focus on the scalability of the adapters and connectors themselves, periodic stress testing with updated Bills of Materials, and testing of the adapter structure relative to the future direction of the ERP platform.

  • + Share This
  • 🔖 Save To Your Account