Are You Trying to Integrate SAP Through a Galactic Translator?

When it comes to SAP integration, iPaaS and ETL companies make you work around problems their systems don’t solve.

I read a fun science fiction book recently. Without spoiling too much of the plot, I can say that there was a lot of discussion of the role of an interpreter. In this case, to avoid intergalactic devastation based on species’ cultural differences (think New York City vs. Savannah, GA), it was determined that a translator should create a bit of a buffer – rewording the literal text to remove unintended tone that might offend the other party.

I thought back to that book when I stumbled across a really nice whitepaper from Mulesoft on “SAP Integration Best Practices,” because what integration platforms do when they try to open up SAP is really just literal translation – and just like in the book, it causes all sorts of problems.

The whitepaper does a great job of summarizing the problems our customers face that bring them to our door. Specifically, it calls out three major challenges:

1. SAP’s integration methods don’t extend well to third-party systems
2. Inconsistent configuration increases complexity and costs
3. Specialized skill set requirements lead to slow delivery

And these are right on! BAPIs, ABAP, RFC, IDocs, and the JCo connector weren’t built to support real-time, API-driven integration. They are proprietary and time-consuming, and in some cases, they are just flat out not capable of doing the integration at all. (Real-time, dynamic, variant configuration through an API, anyone?)

Could there be any target environment with less consistent configuration than SAP ERP? Every one of these systems is highly customized with custom tables, fields, workflows, and business logic.

And the tools available for integration require people consuming the interface to have deep SAP expertise to know which calls to make in which order and how to translate German to translate field names.

You don’t want your whole team to have to learn a new language – you need an interpreter!

So far, we’re in total agreement. Where we diverge is that the solutions they propose don’t really solve the problem. I don’t mean to pick on MuleSoft – every iPaaS and ETL company has the same issue, and MuleSoft is actually probably better than most. But the folks over at MuleSoft have a lot to do. They are trying to build a platform to connect every existing system to each other in any combination. So, of course, they can’t afford to be SAP experts – it’s just one small piece of the puzzle for them.

MuleSoft proposes that using the MuleSoft SAP Connector, you can:

• Execute BAPI functions over RFC
• Act as a JCo Server to be called as a BAPI
• Send and receive IDocs

Aren’t these tools (BAPI, RFC, JCo, and IDocs) exactly the ones that caused all our problems to begin with?

They are just offering literal translations!

All they’ve solved is how to connect MuleSoft to SAP at the network level to let you use NetWeaver Gateway. And even if anyone wanted to use the NetWeaver Gateway, its incomplete, low-level API has so many limitations (no direct SQL queries, limited return data sizes, etc.) that it’s worse than a literal translation – it’s like wanting to translate English into Spanish, but your interpreter only speaks Portuguese, and you figure that’s close enough.

MuleSoft recognizes this, of course, and offers a couple dozen templates for handling common use cases – particularly for connecting to Salesforce and Workday. But these templates are just a band-aid to cover the problem that is SAP’s outdated integration capabilities. Despite best attempts, they still suffer from a variety of problems:

• They typically operate in batch mode: This isn’t 1990. We should expect real-time capabilities.  Also, it leads to other problems (see error handling).

• They need to use strange field mappings: For example, the template for syncing orders from Salesforce to SAP uses the purchase order number field in SAP to hold the Salesforce Opportunity ID. What if you need to use the purchase order number field? How are you even supposed to notice this strangeness before you implement it and find that it breaks?

• They use service accounts: So, there is no ability to use SAP’s auditing capabilities to determine who executed a particular transaction or wrote a piece of data.

• There is no error handling capability: That is, the templates handle network-level errors, but not SAP-generated errors, warnings, and messages. What do you do with the (not infrequent) orders that can’t be created when the batch loads because something was created in Salesforce that’s invalid in SAP? You redo them all by hand the next day, of course – often causing issues like giving customers bigger-than-allowable discounts because they were provided an inaccurate quote. Why not handle errors while the user is still sitting at the screen waiting for the order to be saved? Then they can fix it up front (or even see a warning or informational message from SAP that might be relevant).

• Executing SAP transactions (to ensure proper workflows are called) is really hard from outside SAP: That’s why Jitterbit’s (we shouldn’t just pick on MuleSoft) documentation on SAP integration warns against bidirectional flows with SAP because they “become a project risk factor” and “require considerable custom work on both the endpoint and SAP.” They’re using the same JCo connector as everyone else – they’re just more up-front about its limitations.

And what are you supposed to do with all the custom fields, BAPI exits, and other strangeness that’s been built up in your SAP system over the last decade? We haven’t really done anything at all to address any of our three initial challenges.

JCo plus templates isn’t really integration. It’s copying data back and forth and hoping nothing breaks. Real integration with JCo requires far more custom work on both sides than a template can provide.

But enosix can create intergalactic peace with our completely different approach

enosix replaces NetWeaver Gateway with a new integration point and a completely new API. We make SAP polite for the benefit of your front-end teams.

In less than two hours, you can get real-time access to all your critical SAP data inside of Salesforce. Custom fields? Just add a row to a metadata table and you can see it in a Lightning Component – for use wherever you want it in Salesforce. You can even run a pricing simulation.

Weeks (not months) later, our delivery team will have you setup to execute any SAP transaction your heart desires. Typically, that means creating and updating sales documents, but we can handle lots of other things, including customers, contracts, service orders, and even your custom transactions. Once you are wired up, you have easy access to whatever fields you need and the confidence to know your processes will continue to work as they always have – even when called from outside. You can never do SAP 100% out of the box, but typically our integrations take 70% to 90% less time than equivalent custom work.

Even better, the enosix interface can all be exposed through a REST API, so it can be consumed easily by any modern front end or middleware. It works with deeply nested JSON structures that contain all the detail you need, and the field names have all been mapped to human-readable English. It supports both individual user credentials and service accounts for SAP audit trails. And SAP messages generated by transactions are passed back as part of the API return values – not as a meaningless “404 Not Found” or “500 Internal Server Error” – so your front-end developers can decide how to handle them.

It’s so simple, we routinely have customers’ front-end developers building integrations with just 60-90 minutes of training.

MuleSoft and other iPaaS tools are incredibly powerful platforms for consolidating your integration infrastructure across your entire environment. But SAP ERP customers should consider shortening your project timelines and making your teams happier by skipping the templates and using enosix between the iPaas and SAP. After all, you don’t want to be responsible for the destruction of the world, do you?