Overcoming Obstacles in Magento Ecommerce Integration

Note: This article was originally posted on the Wombat blog (now defunct). It has been cross-posted here for historical value.

Introduction

As owner of an ecommerce dev + growth agency, I literally love most of the work my company gets to do for our ecommerce clients, but application integration has always annoyed me. Long story short, it’s generally Going to Be A Problem to create a working connection between two apps, even great apps like Magento.

Context (or, A Brief History of Bad Integration Approaches)

From what I can tell, for nearly all of history, small and midsize ecommerce companies running Magento have had three options for integrating their data:

Option 1: Install an off-the-shelf software integration. Found on github or the plugin community of your choice, these integrations are sometimes free, sometimes expensive, and always generic. Cross your fingers and hope that everything will work exactly the way you need. If there’s anything unique about the required workflow (and there usually is), call in an expert developer, or if possible, the original developer to create the modifications you need. No big deal if we’re only talking about a couple of these, but much more than that and things become unwieldy fast.

Option 2: Hire a developer from the get-go to build a custom integration. Now we can finally get the exact workflow we need the first time around. Wait, no…we need to tweak it for “That Other Scenario We Didn’t Anticipate.” Call the developer again…what? Because we didn’t sign up for their $xxxx monthly retainer we now have to wait three months until they’re free?

Option 3: Use a separate heavyweight “enterprise-grade” integration platform to consume and connect all the data. Check it out! All our problems will be solved! Did I just hear a groan from Finance and IT? You say this is overly complicated for our needs and too expensive?

None of these options makes much sense for a growing company.

A Marsupial Solution

Thankfully, Spree Commerce changed everything when they launched Wombat this year. Wombat is a lightweight ecommerce connection hub that integrates all the basic ecommerce data out of the box and also allows for custom data, data transformation and on-the-fly error resolution. With Wombat, it’s a matter of minutes and a few clicks to retrieve and send data between applications.

Since my company has a lot of experience with Magento, you can imagine our excitement when Spree asked us if we’d create an integration between Magento and Wombat. We got so excited, in fact, that we built not one but two ways of connecting to Wombat—a Ruby middleware app that allows for flow-based connection, as well as a Magento extension that pushes data from Magento. Just to be clear, Wombat integrations can be written in any language but we wanted to try Ruby since we spend so much time writing in php.

Musings about the Magento API

The Magento extension-building experience was uneventful since we have built a lot of those, but the Wombat middleware app was our first serious experience working in Ruby, and it was fun! In short, the app consumes the Magento SOAP V2 API2 and spits out JSON in the format friendly to Wombat, and vice versa. All in all it was pretty painless, but during the process, we learned some things about Magento you might find interesting if you’re a developer type. The code samples referenced are from Wombat.

1. Getting information from Magento

Some objects are supposed to be returned in an array format, but if there is only one item, it gets returned as a single item rather than in an array. So we had to add a function that checks if the resulting information is an Array and if not, it changes it into one so we don’t have to write multiple cases of interpreting the information.

2. Sending information to Magento

Another issue we had was when we tried to send hash objects to Magento. If the key contains an underscore inside its name, then we had to contain that key inside two quotation marks.

3. API Documentation Accuracy

Sometimes Magento’s API documentation isn’t correct. For example, when creating a product using the API, you need to specify the websites to which the product will be assigned. In the API documentation it mentions a parameter called websites of type ArrayOfString that is supposed to contain this information.

We weren’t successful sending this information using this approach, but after studying the API model files, we noticed that the parameter key should be website_ids and the content must be an array of arrays that contain the website id information.

Closing Notes

You can get the Magento extension on Magento Connect or Github. It pushes data (orders, customers, products, etc) to Wombat upon creates and updates. Data comes into Wombat nearly instantaneously, so this is a really fast way to get an integration in motion. At the moment, it doesn’t pull data back in from Wombat, although this is something we might add in the future. For bi-directional connections to the Magento API just use the official Wombat-Magento integration.

When developing the Magento integration for Wombat, we used Magento’s SOAP API rather than the newer RESTful API because it offers more endpoints, doesn’t require oAuth and is compatible with Magento back to version 1.3. Magento users can connect to Wombat straight from the Magento Marketplace.