There are many benefits to having the right backend systems in place that will facilitate profitable sustainable growth for your business.
However, when looking at Integrated eCommerce Systems to leverage it’s imperative that you note how well your different systems play together. Not every backend system is compatible with every core platform, and of course the integrations you need largely depends your size and business needs (do you have a technology roadmap?).
Investing time and money in set-up and integration is a huge opportunity cost if you’re not careful about which systems you’re attempting to integrate. To streamline the integration process and reap the many benefits, consider the following:
1. Does your core platform have the right API?
2. How many stores do you have?
3. How will you send your data? SOAP, REST, or FILE
4. Has your data been sanitized/cleaned?
5. What information will flow between the integration and the platform?
6. Is your data ready?
The 6 Technical Barriers of Integrated eCommerce Systems
1. Does your core platform have the right API?
You need a platform in place that can pull data in the way you want it. Core platforms and supporting systems should have a well documented Web Service API layer for you or your team to reference.
For Example: Shopify Plus alleviates a lot of the technical overhead for merchants and through their API streamlines the development of Integrations. However, this also means that any Integration Solution Beyond their core offering will be complex to set-up, if at all possible.
Magento or Workarea have more flexibility with the data and integrations you feed them, but you’ll need an expert development team in place to manage the platform continuously.
That being said, any “off the shelf” platform will have a wider variety of Integrations available.
2. How many stores do you have?
When you begin to review an integration solution, know that complexities arise for multi-stores and multi-language stores. Multi-store functionality in Magento for example allows businesses to managing multiple websites and stores under one installation, however this data flowing between stores is another added layer of complexity you need to consider.
3. How you send data affects your integration – SOAP, REST, or FILE:
This next part digs deep into the technicalities of transferring data – this should impart some understanding of the complexities behind integrations. For further explanation it’s suggested you seek the advice of integration experts to guide the process, they should take the time to explain this in detail.
SOAP vs REST:
There is a lot that can be said about the differences between SOAP and REST. We have heard the debate go round and round, and a lot of it boils down to personal preference since they mostly do the same things.
That being said, here are a few things to think about:
SOAP
SOAP (Simple Object Access Protocol) services often come with a wsdl. This means that there is a sort of strict contract to define the messages, bindings, and operations of the service. Stripped away of a lot of tech speak this means that the communications between your code and the SOAP service is controlled and mostly not your problem.
You use the wsdl to communicate with the system; you don’t have to create the calls yourself, serialize the data, or any of that. You pass into the service the objects it requires and it spits back the objects that are defined in the wsdl. This makes it easy to use and doesn’t require a lot of skull sweat when working with it. SOAP also has some built in retry methods into it so if there is bad communication it’s easy for the system to retry a failed communication.
If the service wants to update how their data works they update the wsdl and you use that, you don’t have to muck about trying to find all the places you use that endpoint and change how you are doing it. You also don’t have to write a bunch of plumbing code to figure out what is wrong.
From an integration standpoint using SOAP is easy, quick, and pretty reliable. SOAP also includes security considerations that don’t exist in REST. SOAP Communicates only in xml, which is a serious limitation with it.
On an anecdotal note: sometimes we have found that SOAP services tend to have superior error reporting when something goes wrong. This is NOT apodictical but simply our general experience and has little or nothing to do with SOAP itself, but the people who code the service.
REST
On the whole, REST (Representational State Transfer) is awesome.
It supports multiple data types (including the XML that SOAP uses). Most applications seem to use JSON objects and these are easy to deserialize into objects and use.
REST is also quite fast and uses less bandwidth in general in comparison to SOAP. If you build your objects correctly and understand the context of what and when these objects are being used, REST is your best friend. REST also offers better support for browser clients, so it’s easier to use if you want to call on an API endpoint within your site.
REST is a little more hands on than SOAP and you can play around with it a bit more because you are sending everything (usually) as a JSON string as opposed to the strict objects enforced by SOAP.
Why this can be an advantage can be seen by how Shopify handles some of its objects. A product, when you get it, can contain numerous properties, many of which can or all ‘null’ values (for instance, metafields on products even if there are metafields for that product). If you try and feed that same object back in you might get some interesting and bizarre results. At first this seems like a bad thing, but in retrospect you will find that it makes more sense this way. If a property is null, why waste time and memory sending it? Just get rid of it from your json string and send it without it. REST will allow you to do this, which can save processing cycles and make the information you are sending cleaner.
On the whole, the flexibility and the speed of REST is the main difference between the two.
Arguably, one of the biggest reason REST has grew in popularity is due to its ease of use, and the fact that its lightweight relative to its XML counterpart making it accessible to much broader set of clients and tools from mobile. REST requests are more client agnostic . The implicitly defined types in the standardized JSON format makes requests quicker to construct and test from any client. In contrast, SOAP’s explicitly defined types definitely do has benefits but it makes requests tiresome to build and send.
File?! Madness you say?
Does anyone still use flat files for uploading information?
Hell ya. It might seem old fashioned and out of date but you have to think about what is easiest for you and your client. Many legacy systems don’t have the capacity to do a proper SOAP or REST endpoint. But they can compile the product information into a file and upload it to an FTP for you to read from.
Is this not ideal? Sure. Does it have disadvantages? Lots of them, especially if the file is compiled by those untrustworthy computers called “humans”, so be careful.
However, if the ERP is willing to compile the files themselves electronically you can have the advantage of receiving a custom CSV with all the columns named the same way you want your objects built. So you read in a file, it spits out upload ready objects, and bing bang boom, you are good to go.
It’s never as simple as all that, but it definitely can be. So, if the legacy system can’t do an API endpoint, and it can give you a custom file, this isn’t necessarily a problem. If they give you just a file dump, though, and you have to parse that the same way you do with API objects you have all the headaches of using FTP services and possibly incorrect data in files without the advantage of having everything handed to you “just so”.
In general, stick with SOAP or REST if you can.
Now, this file thing and the “humans” issue segues beautifully into our next talking point. Data Sanitization.
4. Have You Sanitized Your Data?
Now, for integrating data, service providers and agencies will be changing your data as little as possible. This is for your sake and theirs, as it reduces risk as any small mistakes they might make in changing your data can lead to big trouble down the road.
So, along with getting your data ready you need fully understand this crucial message:
Let’s look at a case study:
You are building an integration and you want build categories for a Magento 2 dynamically based on the category data on the product and the category structure you have. This is both good and proper. However, small errors can created issues with this.
Let’s say you are selling the great product of OriginalProductIdeaHere and it comes in the main categories of: “Great”, “Awesome Sauce”, and “Rad”.
Now let’s say that “Awesome Sauce” is divided into subcategories of “Madness”, “Bananas”, and “Bonkers”. One product comes in that belongs to “Awesome Sauce/Bananas” and you create that category.
Next let’s say that another product comes in with a category of “Awesome Sauce/Bnanas“. You can see the problem already.
Since these categories are going to come in through the data as strings and Magento 2 stores them uniquely as Ids you have to see if you have to compare them via their structure, and more specifically, by their names. Immediately you run into the problem of having a Category of “Bananas” and another one of “Bnanas“.
This is one example and I am certain that many people can come up with a workaround, but it’s better to avoid the misunderstanding in the first place. Human error can be a factor in an integration, so be extra vigilant.
However, there are ways of sanitizing data on your end to limit the cases where this could be a problem.
Take the above case study. If instead you had a category of “Bananas” and one of “bananas”, you could have the same problem. But you should be taking that kind of error into consideration by comparing the strings in all lower case or upper case. Or if the categories were “Bananas” and “Bananas “, you should be trimming the white space at the end of data so you can more easily compare them and aren’t sending in a bunch of random white space for things like url keys, names, and skus.
This may sound like basic stuff, but simple data sanitization (without necessarily changing any of the data substantially) can be a real saviour when you are creating your integrations.
5. What Information Will Flow Between the Integration and the Platform?
Data and touchpoints should be part of your technical requirements. For an integration to be effective you need alignment across your entire business, not siloed data workflows. Siloed data is the productivity killer in any business, but especially so when it comes to eCommerce Integrations. If data silos exist, then your business will never get a whole picture of operations, limited the success of particular functions, teams, and other integrations you have.
For example: It is essential that a CRM Integration be able to communicate and transfer customer data to your business’s Marketing Automation System, to know which marketing programs are successful. Siloed data hinders the omnichannel experience, and thereby the growth of your business.
To avoid data challenges when implementing an Integrated Solution, consider the following in the planning phase:
- What customizations are required?
- Where will information be stored?
- What data needs to be synced between systems?
- Will synchronization be scheduled, or happen in real-time?
- Will you require a one-way or two-way data integration?
6. Is your data ready?
Integrations help retailers and merchants remove redundant data entry processes, however a critical component of planning and preparing to connect your core platform or other systems with an Integrated Solution is having your data ready.
To streamline the Integration process, it’s important that your business’s data is complete and ready to go. Get as detailed as possible, and ensure the data is in the required format. See above for “Data Sanitization” tips
Rely on Integration Experts
Integrations are critical for accelerating growth, but it’s imperative that your business works with both the software providers and Systems Integrators, or your eCommerce Agency, to choose the best technology mix for your needs and future goals to overcome these technical barriers to integrating.
Questions about integrating with your eCommerce platform? Contact us by clicking here.
The post Integrated eCommerce Systems: The 6 Technical Barriers You Need to Know About appeared first on Demac Media.