How G3 Enterprises integrated SAP S/4HANA with mission-critical applications using MuleSoft

G3 SAP inbound boundary system integration architecture May 2018

Learn how G3 Enterprises, an industry-leading packaging, bottling, and logistics company located in Modesto, California, integrated all of its mission-critical applications to a new SAP S/4HANA implementation by using MuleSoft.

G3 Enterprises and SAP S/4HANA

G3 Enterprises (“G3”) is an industry-leading packaging, bottling, and logistics company located in Modesto, California, with roughly 700 employees and a small IT department. We serve a broad range of customers in the beverage and agriculture industries, including wine and spirits, beers, cider and coffee, and specialty beverages and food. Our mission is to provide creative, integrated solutions for our beverage and agriculture industry partners with quality packaging products and supply chain services.

In 2017, we began a two-year project to migrate to SAP’s new ERP, S/4HANA. Our legacy ERP, JD Edwards, was a complex system that had collected a lot of technical debt, and it relied on dozens of auxiliary boundary systems to perform all of our core business functions. The SAP project required us to consolidate our systems into a single landscape with SAP performing as many core business functions as possible while minimizing the number of boundary systems.

While this project ultimately reduced the size of our landscape, the task of integrating SAP S/4HANA with five core (non-ERP) systems remained, including our transportation management system (TMS) for logistics, two different manufacturing systems, a weigh scale system, and a product lifecycle management (PLM) system.

G3 SAP integration landscape May 2018

SAP integration requirements and challenges

The S/4HANA migration project impacted all areas of our business and required that we fully integrate our remaining core systems with SAP. This requirement was driven by three of our project’s key value propositions:

  1. Consolidate financial statements in SAP S/4HANA.
  2. Drive 90% or more of the transactions between core systems and SAP as “no touch.”
  3. Consolidate customer master data and transactional data in SAP S/4HANA.

One common theme existed across these value propositions: eliminate manual processes. This was a challenging task for us, given the small size of our team. What became immediately clear to us was that our legacy integration tools, such as TIBCO, DataStage, and a number of in-house tools, would not provide the speed or flexibility necessary to integrate our systems with SAP S/4HANA.

As part of our new approach, any integrations for our critical applications had to adhere to our key value propositions while simultaneously solving for the following technical requirements and challenges:

  • The internal structure of the ERP project prevented IT from directly accessing SAP BAPIs, and this limitation precluded our taking advantage of MuleSoft’s SAP connector.
  • When objects are updated, SAP sends payloads via XML IDOCs in real-time, leading to large volumes of data being published.
  • SAP payloads only include the necessary data for that object, resulting in transactions only containing references to master data as opposed to the actual master data.
  • SAP payloads must flow to all pertinent downstream G3 systems regardless of each downstream system’s availability. This was critical, because several of our boundary systems are multi-tenant SaaS applications, and we lack the ability to control downtime.
  • SAP payloads are sent once, and downstream replication is beyond SAP’s domain (e.g., a customer record would be sent once, even if three downstream G3 systems needed that data).
  • SAP payloads must be processed into boundary systems in the order they are received by object type.
  • Consuming systems have different data format requirements (XML, JSON, database, FTP, etc).
  • Detailed logging must be provided to support end-to-end traceability.

G3’s SAP integration architecture

The critical success factor for our S/4HANA integration was to enable touchless transactions, which we achieved by automating business processes that flowed across system boundaries. We recognized that MuleSoft was a good fit for this project because of a previous Mule 3 project we had undertaken to integrate our TMS with JD Edwards.

For our S/4HANA project, MuleSoft’s Anypoint Platform abstracted many of the technical complexities, such as enriching payloads via web services. Additionally, data type transformations between different systems were quick for us to implement. MuleSoft also allowed us to easily gather detailed transaction logging, thanks to the many pre-configured logging options. With this logging data, we were able to develop MuleSoft-based tools that allowed us to quickly and easily replay transactions in addition to connecting our logs to Splunk, which allows for end-to-end transaction traceability and other analytical capabilities.

Keeping our core value propositions in mind and understanding the technical challenges we faced, our principal MuleSoft developer architected a Mule 4-powered, scalable architecture. After this architecture proved effective during internal testing, we turned to our partners at MuleSoft to certify it before beginning the technical build.

G3 SAP inbound boundary system integration architecture May 2018

This architecture allows for the publication of transactional and master data to boundary systems using CloudHub-deployed Mule 4 projects. These deployments subscribe to Anypoint MQ FIFO data queues using the components provided by MuleSoft (see “Subscriber APIs” above). These queues are fed from a centralized API that replicates incoming SAP payloads out to all boundary systems that need them (see “Messaging Queue Distributor API” above).

This architecture helped solve several design challenges:

  • Anypoint MQ provides an always-available endpoint for the real-time publishing of SAP payloads, regardless of volume of data.
  • This architecture provides a persistent data structure that enables messages to be processed in real time or at a later date, depending on downstream system availability.
  • Anypoint MQ FIFO queues return data in the order in which the data was received.
  • This architecture allows for SAP to send payloads to a single G3 endpoint for each object type. These payloads can then be replicated and published to as many other boundary systems as needed.

Finally, to handle the process of communicating back to SAP, we deployed APIs with multiple HTTP endpoints, enabling boundary systems to send different types of payloads. This can be seen in the outbound architecture diagram below, and these integrations have proven to be as reliable as those built using the inbound architecture described above.

G3 SAP outbound boundary system integration architecture

Building and deploying SAP integrations

With a plan in place, we were ready to start building. Our IT team consisted of one principal MuleSoft developer with three years of MuleSoft experience and two newly-hired developers with no prior MuleSoft experience. Despite this small team, we were prepared to meet the challenges ahead of us: our principal MuleSoft developer shared best practices, MuleSoft’s training course accelerated onboarding, and clearly-written documentation filled any remaining gaps.

Shortly after the build began, we standardized a number of best practices and rapidly deployed our first integration. Using this initial integration as a template, we were able to quickly build out the additional integrations required for all of our boundary systems.

Going live with SAP S/4HANA

We are now live on SAP S/4HANA. In the six months since go-live, MuleSoft’s Anypoint Platform has handled more than 1.65 million transactions. This has allowed us to be extremely agile, enabling our small team of developers to keep up with and surpass the development pace of our much larger SAP integration team. Thanks to a well-planned deployment using the architecture described above, we have the capability to perform seamless analysis of all of our SAP transactions and their life cycles across all of our boundary systems.

In less than one year, G3 started and completed its entire technical design, technical build, testing, and deployment of 35+ inbound and outbound SAP S/4HANA integrations. These integrations are contained within a dozen individually-deployed MuleSoft projects that have more than 500 cumulative commits against their Git repositories. These are impressive numbers, especially considering the size of the team operating against a short time frame.

MuleSoft has enabled our small team to rapidly build and deploy new integrations as well as modify existing ones to correct problems with business logic, make enhancements, and apply break fixes quickly and efficiently. At G3 Enterprises, we value MuleSoft as a trusted partner and Anypoint Platform as a critical enabler for our success. And we look forward to growing our partnership as we expand into new integration projects in the future.

To learn more about integrating SAP with Anypoint Platform, read MuleSoft’s SAP integration best practices whitepaper.

Coming to MuleSoft CONNECT in San Francisco?

Hear Chris share this story in person! Chris Hepp from G3 Enterprises will be joining us at the special Community Meetup on Tuesday, June 25th at 6:30pm. Make sure to register as tickets go fast!



We'd love to hear your opinion on this post