How We Developed a Spree Commerce Gem to Integrate with Fosdick Fulfillment
It’s hardly a secret that today’s object-oriented programming allows for creating feature-rich and sustainable MVPs within a very short period of time. To make that possible, developers use various design patterns as well as additional libraries, i.e. gems, that come with a ready functionality. So today, we’re going to talk about how to properly create, test and implement gems that you could use for an E-Commerce store. To be more exact, we’ll be showing you how to create a gem to work with the Spree Commerce framework.
Creating Spree Commerce gem
First, you need to execute the following commands:
you can also use this one:
In case you’re wondering what some of the commands above mean, we’ll make a small breakdown.
- spree_fosdick — this is the name of your gem; though, you can give it whatever name you like.
- -T is the key that skips the “Test::Unit” generation; you can also change it to — skip-test-unit (which basically means the same).
- — mountable creates an engine with a namespace;
- — full adds the app and the config folders into your gem;
- — dummy-path generates an application for testing in the folder specified as a key parameter (we recommend using the default folders test/dummy or spec/dummy)
Preparing testing environment
Development and maintenance of libraries for different engines are hardly an easy task. This includes both monitoring of new versions for your platform and preparation of compatible gem releases. The good news is that you don’t need to change the business logic. What you need though is to prepare a minimum set of functionality and unit tests. As for the integration tests, you may need them only when adding some new visual elements.
For testing, we’ll be using RSpec, FactoryGirl and Capybara (just in case we’ll need to check the integration). Also, we’ll be using some other gems as well as additional tools that will enable us to work with Ffaker, Selenium-webdriver and Database Cleaner. Here is a full list of all the things to add into spree_fosdick.gemspec:
Be sure to add this into the gemfile:
Installing the gems:
Preparing rakefile for better usability and gem maintenance:
Creating spec_helper.rb; adjusting spec_helper.rb according to the current testing requirements:
Configuring the engine lib/spree_fosdick/engine.rb:
Testing the Spree Commerce gem
The procedure is basically the same as in the official RSpec documentation and style guides. In order to run tests, you need to generate dummy_app:
When it’s done, run tests:
If the tests are “green”, you can proceed to the next part.
Integration with Fosdick Fulfillment
The reason we chose Fosdick is because this service doesn’t have its own REST API. Instead, it uses the APIs provided by customerstatus.com and unitycart.com.
- unicart.com is basically an interface for shipping orders;
- customerstatus.com is an interface that allows you to track delivery time as well as unsold and returned items.
Interestingly, we encountered some specific challenges during the integration process. For example, we couldn’t find the API documentation anywhere (our team spent a couple of weeks discussing this issue with the Fosdick Fulfillment officials). Also, we found mismatches in the data synchronization between the two APIs. The problem was that the synchronization took around 24–48 hours after the data had been manually transmitted, wherein the unique registration numbers of both APIs didn’t match. On top of that, accessing the APIs was being interrupted by timeouts (about two seconds between each query), not mentioning the batch limitation (one API request could contain only 60 items).
How it works
As an architecture core, we used the service class “Processor”. Briefly, it receives queries from a background worker (which is basically a process running in the background), distributes the tasks between the shipping services and receives data from “Sender’ and “Receiver”. Moreover, “Processor” is also responsible for ensuring proper interaction with the application database.
Integration architecture
Sending
- Every thirty minutes, a worker collects ready orders, assigns them the “ready for sending” status and forwards them to “Processor”.
- In its turn, “Processor” converts those orders into XML and forwards them to “Sender” after validation. The latter one sends the orders to unicart.com using a POST query and reads the incoming data. If there is an error, “Exception Logger” analyzes it and assigns it a priority. Finally, the data is returned to “Processor” which sends it to the database.
Synchronization
Based on the schedule, the workers go to “Processor” and provide it with the list of orders which have been sent to the aggregator but aren’t yet synchronized.
“Processor” sends a query to “Receiver”, which asks customerstatus.com about the sending details. If the incoming data is valid, it gets normalized and forwarded to “Processor” which updates the database and notifies the user that their package is on its way. The package status can be tracked using its tracking number.
Summing up
A custom integration with a delivery service ensures that customers will be able to track and receive orders effortlessly. In terms of development and maintenance, the advantage of going for such solution is that the data in the database will always be consistent.
