Magento integrations using Xtento

One of the most common tasks I have to deal with in Magento are integrations. Almost any system I worked with needs to push order or product data to an ERP or marketing software, or get stock/product info/tracking numbers from an external source. Every integration is unique in a few ways…

  • the communication channel. REST, SOAP, sending files via SFTP are common variations
  • the data format. JSON, XML, CSV to name a few
  • the actual data mapping. We either pass fields as-is or combine/transform them.

However, any good integration has a lot in common:

  • a log must exist so we can refer back to when and how each piece of information was synchronized
  • errors must be logged, with an alert system so we are aware of any failures
  • the system should be able to queue data in case the integration is down. We cannot lose info especially when dealing with financial records.
  • the system must be able to retry failed records
  • the actual field mapping must be easy to change, ideally without changing code

I have been looking for good solution to build integrations for a while. On the lower end, there is the do it yourself custom shell script. Easy to build, but usually missing key elements, like retries or flexible data mapping. On the higher end, we have full ETL solutions. They tend to be expensive and add new software components to the mix.

Almost accidentally I stumbled upon Xtento’s Import/Export suite – https://www.xtento.com/magento-2-extensions.html . They flew under my radar as I had bad experiences in the past with such extensions and for a while, concluded that the best import/export is the one you built on top of Magento’s default.

Let’s go over the steps involved to export orders from Magento via Xtento. First, one starts with defining destinations. A destination is the place where your orders will go. You have a few options:

  • on the local server in a specified folder
  • on a remote server via a SFTP or FTP connection
  • to an email
  • to a HTTP server (i.e. REST)
  • to a web service. Use this for XML-RPC or SOAP integrations
  • via a custom class, where you can define the communication with your exotic system

So the above options should cover any possible target. One nice thing is that you can have multiple destinations, so you could place the orders on a SFTP but also mail a copy of the files to you for later review.

After defining the destinations, the next step is to define the export profile. Most options are obvious so I will go only over the important ones:

  • you can choose the entity to export, i.e. orders. Usually each exportable entity corresponds to a specific extension that you need to buy from Xtento.
  • you can define filters. For example, you can decide that you only want to export “processing” orders, keeping the “pending” ones in queue until they are reviewed
  • You can define the export mapping as an XSLT template. This was the feature that I was sold on. XSLT templates allow you to be as expressive as you need to. You can use all the standard fields, apply transformations, use all the fields in the order/related tables (your custom ones too). All this with a nice autocomplete interface and a dead-simple way to test the template with an existing order. Once you get the hang of it, you almost never need to refer to the docs/examples, it’s that easy. If you do need help though, https://support.xtento.com/wiki/Magento_2_Extensions:Magento_Order_Export_Module#XSL_Template has you covered.
  • You can define when your export runs. Do you want to export orders on schedule? How often? Do you export all orders in the last N hours or only what’s new? If the export process is time consuming, you have a CLI command to run it outside the main Magento cron.
  • You have a flexible manual export option in case you need to replay any of the missed exports, or simply test the process.

Everything comes with logging. You have filterable grids where you can see the exported entries and errors. You also have the option to locally store the export files for later review.

If you need to import entities, Xtento has you covered too, The process is very similar in that you still have sources where you can pull from, profiles you can define, same logging capabilities, a way to map the data. In addition to imports, you have an actions section where you can define what happens when an entry is imported. For example, when you import a tracking number, you can have Xtento ship and bill the order automatically.

I should mention that currently Xtento does not offer a product import solution. You can import stocks, but not product data. I’d love to see that on their offer sometimes.

What I really like about the extensions is that they are developer-friendly. Almost everything in their system has a fallback to a custom class. You have a very exotic export destination? You can define a class to implement the communication logic. Need to map your data in a way the XSLT template does not support? You can define a class and a method just for that. Finally, having logs for all operations make it easy to identify random issues. It scales ok too, I have been exporting importing 100k records per day with no performance issues.

Here are a few usecases where I have used Xtento successfully, usually without writing any line of code:

  • product exports to marketplaces/product aggregators. I still prefer specific extensions for big marketplaces, like Amazon or Google Shopping, but will use Xtento for the ones that have poor extensions or none at all.
  • pushing order data to ERPs and getting back tracking info, billing and shipping automatically. That’s a huge one, before Xtento I used to spend a lot of time on these type of implementations.
  • pushing order and product data to marketing software, like mailing list managers.
  • importing stocks from an external source (usually ERP).

Xtento might be lacking all the bells and whistles of an ETL solution, but in an ecosystem where not everyone has a fortune to spend on an integration, their extension suite is more than decent to get things done.

Algolia and Magento 2 – a perfect match

Magento 2 has never been ultra-fast. Even with careful customisation and not a very large catalog, it still takes somewhere near 2s to render the average category view page. This slowness is usually made better by the full page cache, but navigation and filtering patterns are too different to hope that in a browsing session, a user will hit only cached pages.

Now, 1s-2s server-side generation time is not too bad. But more and more merchants expect an almost-instant browsing experience. Magento is hard at work with the PWA implementation, which should deliver a very smooth experience, but that’s still in progress. And when it’s done, time will be needed for the extension vendors to catch up. In my opinion, all the approaches for Magento PWA, either official or community based, call for a big implementation budget.

And here comes Algolia. Stop now and go here, check the load speed as you filter through the left-hand navigation. Almost instant.

Algolia is a search service. They integrate with Magento via an open source module. Basically, it will replace all your search and category pages with an empty catalog page that at load time, will do a client-side call to Algolia, get a json-formatted list of products, then use html templates that are under your control to render the results. So the initial page load time includes Magento bootstrapping (which should be under 500ms), plus a few hundred milliseconds for the Algolia call. Even better, the navigation is ajax-based, so any further filtering is almost instant. Of course, they also have very relevant (and customisable) search results.

That’s a huge selling point for me. While I still have to deal with performance issues on product detail pages, cart and checkout, using Algolia makes catalog navigation ultra-fast. And it takes a lot of load from the server, since we don’t process the catalog there.

All this sounds great, but there are a few reasons for which you may not be able to use it.

  • It is a paid service. Their pricing scheme is good though, I am almost positive the increase in conversion rate will pay off. Not to mention the countless hours you’d spend in trying to optimize the catalog page, if you get to that point.
  • It is a SaaS. You are fully dependent on them. When I was working on a project, my free trial ended and the site instantly became unusable. That got me thinking that an Algolia outage will break my site. But they look well funded and have a great uptime.
  • If you have an existing project, it’s way harder to move to Algolia. Since they replace all templates on the catalog pages, any skinning/custom features will be gone. Of course you can re-do them using their templates, but it will mean a lot more than just installing the Algolia module. Don’t expect any community extension that touches the category page to work out of the box either.

I also had to customise Algolia a bit and luckily, there are options. Roughly, the module works by creating a product indexer that pushes data to Algolia. Via the admin, you get to decide what attributes are searchable, filterable etc. All changes to products will be pushed at indexing time. When rendering the results, you have access to the json and can render them as you wish using html and a proprietary markup language.

Overall, it’s very easy to change CSS styling and add more attributes or custom logic, but you should be aware that at render time, you don’t have access to the product collection, so you cannot call Magento for any logic. Or well, I guess you could, but it defeats the purpose of using Algolia. The only approach should be to send any data you need at index time (even precalculate some attributes if needed), then simply display them in the templates. Algolia has you covered for default more complex features, like different pricing per customer group, but I can see how things could get complicated if you have custom logic in displaying data based on the current customer’s session. Still doable though.

All in all, Algolia is in my top 3 recommendations for a new Magento 2 project. It’s also in the top 3 recommendations for websites that have performance issues. I do hope that Magento will provide a similar experience based on elasticsearch once PWA is finalised, but till then Algolia is one of the best integrations you can have for your store.

A few gotchas for the Magento 2 product import

Six-seven years ago when I started with Magento, the import feature was lacking. While it improved, it still has quite a few issues even today. Mostly every import task I worked on was delayed due to unexpected core bugs. Extensions that promise to help with this come with their own set of issues. There is hope with the https://github.com/magento-engcom/import-export-improvements project, but till that’s done we have to get by.

First, the imports do not have a programmatic interface you can hook into, i.e. pass an array with data and get it imported. Luckly, Firegento fixed this with https://github.com/firegento/FireGento_FastSimpleImport2 . The module is just a simple wrapper over the standard import, so not many chances to break. Of course there is the standard Magento 2 product API, but it’s pretty useless for anything else than a few products due to slowness.

The second thing I ran into is that tier price imports are a special entity, i.e. you first import the product data in a format, then import the tier pricing in a totally different one. This is not what a merchant would expect and sadly, not even the Firegento extension has a programmatic interface for tiers.

Then another gotcha is that importing empty values does nothing by default. So if you set a product color, then decide to unset it by importing an empty value, it will still keep the same value as before. Similarly, if you import category associations and want to remove an older association, you are out of luck, the old link remains. This is almost a “feature” in Magento – https://github.com/magento/magento2/issues/7930 . The proposed fix is to use the “Replace” behaviour of imports, but that creates another issue – with “Replace”, product data is wiped out and recreated. Not something you want todo if you care about stats/old orders since all the product IDs will change.

Another nuisance is that all custom attributes need to be crammed in a single csv field like:

adhesive=,application=,application_description=,available_lengths=,available_widths=,color_group=,colors=,durability=,item_size=,part_name=,print_compatibility=,product_tagline=,release_liner=,thicknes=

 

For most of my clients, additional attributes is where the bulk of the data lives, so having them formatted as above is clunky.

For the good parts, the import is pretty fast, it can import images correctly and once you get the format right, most of the stuff works.

The conclusion? If you’re working on a import task, pad your estimates substantially, you will need the time to go through a various set of quirks you never thought of. By the way, all of the above refers strictly to the simple products, other product types might come with their own set of problems.

Choosing a programming language and why is PHP still relevant in 2018

Ten years ago, PHP was definitely the better choice for the web. Things seem to have changed though. As a new developer, you are faced with quite a few options. First, there is Javascript that can now be used both in the frontend and backend. Then, there is Python which has seen a huge momentum. Ruby has always had his steady share. And there are many other languages coming out everyday. The junior programmer is left wondering what language should they learn as a web developer.

First, the question of what programming language to learn/use is a lot less relevant than a junior developer would think. The hard things in programming are organising your code, naming your variables, getting into the OOP/functional mindset, not repeating yourself and creating simple solutions. None of these are programming-language dependent. Once you get a hold of those, learning a new programming language only means getting over the nuisance of getting used to the syntax.

So how does one choose a programming language for a specific task? In some cases, the choice has already been made and you have to continue using the same language as you are not starting the project, but continuing it. In others, the client simply prefers a specific language because they worked with it in the past. But let’s assume total freedom of choice.

Programming languages by default offer very small building blocks, like if, for, while constructors. Then they offer libraries with small, contained objects and methods to work with things like files and databases. While usually they are very far away from what you have to build, the building blocks are small enough so with enough work, you can combine them to achieve any kind of result. Actually programming languages can be splitted into two different categories:

  • general languages, like PHP, Python, Javascript. They are not trying to solve a specific problem, but give you the tools to solve any problem. With enough work, that is.
  • domain-specific languages. While you cannot do anything you want with them, they can help you solve a problem in a specific domain much faster. For example, SQL helps you create databases, then query for data in a very efficient way. Mathcad helps solving math problems. HTML is a declarative language that helps you format web pages. CSS gives you a good way to style them.

You usually find yourself needing to use at least one general programming language, along with a number of domain specific ones. As a web developer, you will probably have to use HTML, CSS, SQL along with your general language programming of choice.

When it comes to general programming languages, you care mostly about what exists out there than can match the needs of what you want to build. I tend to categorize “what’s out there” in three distinct areas:

  • libraries. Code that allows you to use new methods and objects, without imposing a structure. For example, a statistics library will give you pre-built methods to calculate averages, means, deviations etc. You don’t need any specific code style to use them. Just search the documentation for what functions/objects are defined and call them in your code.
  • frameworks. They are more about helping you have a sane structure for your code. For example, a web framework will probably force you to use MVC, organise your files in a specific way, be mindful about security etc. They are invaluable for the beginner as you don’t have to go through the huge exercise of finding the best way to organise your code. They are great for seniors too, as they provide a very well documented way of working which helps board new team members faster, or even hire people with experience on the same framework, if popular enough.
  • full solutions. Think WordPress. You install it, then you have a full, working blog. You can use it as-is, or start making changes to suit your needs.

Given the above, the smart choice is to use the programming language that has most pre-built components for your needs. For example, it’s almost a no-brainer that if you are doing machine learning, Python or R are the better choice. That’s not really related to programming languages, but to the fact that Python has the most diverse, production grade libraries related to data analysis and machine learning.

Luckily enough, most languages do have frameworks. Once you’re done with learning the basic syntax, spend some time in learning the most popular/suitable framework for your needs. See how it feels.

This brings me to the last feature, full solutions, and slowly to the point why PHP still matters. Most problems are not that unique in the programming world. For example, I have been making a living in the last 10 years by mostly building e-commerce stores. While each store is unique, there is a lot that is common to all of them. So then it only feels natural to ask the question whether you can start from a “base” e-commerce store and build from there. And of course you can. And here is where PHP shines.

Mostly because PHP is almost as old as the modern web, there are a lot of full production grade solutions built with it. For example, most of the popular open source e-commerce solutions (Magento, Open Cart, Presta), are built in PHP. Then there is the hugely popular WordPress on which you can build a blog or any presentation/content site really. If WordPress looks like too restrictive to manage your content site, then there is always Drupal. Now since e-commerce and content sites cover maybe 80% of the sites that are out there, that’s a huge part. And of course, there are solutions for forums, mail clients, database admins and many others, but they don’t seem like the kind of things one would build nowadays.

Given that with PHP, you have pre-built solutions, it only makes sense to use them when the requirements match. There are a few arguments against it that I will try to defer….

  • “I can build a blog from scratch in X hours/days”. Yeah, “a blog”. But you definitely cannot build WordPress, with all the flexibility it offers.
  • Popular software like WordPress or Magento have a huge marketplace aroud them. You can buy a jaw-dropping theme for WordPress to have a great design for a few dollars. You can buy integrations with your preffered payment gateway for Magento at a small fraction of the cost to build it. Try that with your custom solution.
  • You can add more people to the team by simply searching for people with experience on the platform, very low learning curve.
  • “But I organise my code better, make it faster, more readable”. Most of the time this is simply not true. But even if it is, an effort a few orders of magnitude higher rarely makes sense business-wise.
  • “But Amazon, Facebook, Google, [Insert big brand here] do not use a pre-built solution”. This is totally correct. There is a point when maybe it makes sense to move to a custom solution. But that should be done when you are able to have a team of top-level developers and a huge budget. Trying to prototype a solution with not enough time and a team of juniors will end up in a disaster. Also keep in mind that some of the solutions used by the big companies are custom just because they started that way and never made the switch.

Overall, I feel comfortable with PHP as I can use software like Magento and WordPress to kick-start my efforts. It’s a no-brainer for me to use those when requirements match. What about custom solutions? I still prefer PHP. As I was stating in the beginning,  good software is about organising the code correctly. I can do this in PHP as well as I could do it in other languages. I can also use a decent framework (preferring Laravel) as well as any other. But I am faster with PHP and Laravel as I have used them for years, so I am lazy enough to not switch to something else just do implement the same thing differently. The only valid reason for which I use another language is when that language offers a great deal of libraries to help with the problem at hand, libraries that are missing/are inferior in PHP. And in that case, I only need to get over the syntax errors and language quirks. Most programming languages are similar anyway.

Using a composer library in Magento 1, the quick way

Today I had to generate native XLS files from Magento 1. The https://github.com/PHPOffice/PhpSpreadsheet is the best library for the job, but it’s modern in that it uses composer and PSR. Since I really wanted to use this specific package, here is a quick way to include it in the now dated Magento 1 codebase:

First, create an empty directory where the library will be kept:

 

mkdir lib/PhpSpreadsheet
cd PhpSpreadsheet

Then, create a composer.json file:

#lib/PhpSpreadsheet/composer.json
{
  "require": {
    "phpoffice/phpspreadsheet": "~1.3"
  }
}

Then, still in lib/PhpSpreadsheet, let composer download the needed files:

composer install

To actually use the library, we will have to tell Magento how to include the directory in the path and also require the generated composer autoloader. In your helper/model/controller, add a init method to do just that:

protected function initPhpSpreadSheetLib() {
  //Add library directory to include path
  set_include_path(get_include_path() . PATH_SEPARATOR . Mage::getBaseDir('lib') . DS . 'PhpSpreadsheet' . DS . 'vendor');
  //Include composer autoloader
  require_once(Mage::getBaseDir('lib') . DS . 'PhpSpreadsheet' . DS . 'vendor' . DS . 'autoload.php');
}

Then, use the lib. Remember to use fully qualified class names as Magento is not namespace-aware:

$this->initPhpSpreadSheetLib();
$spreadsheet = new \PhpOffice\PhpSpreadsheet\Spreadsheet();
$sheet = $spreadsheet->getActiveSheet();
$sheet->fromArray($data,null,'A1');
$writer = new \PhpOffice\PhpSpreadsheet\Writer\Xlsx($spreadsheet);
$writer->save($tmpFileName);

Probably there are a million other better ways to achieve the same thing, but this looks like a quick solution to use a library without tinkering with the project’s structure too much.

Three questions to ask a prospect as a freelancer

When discussing with a prospect, out of respect for their time, you should find out quickly whether you can really work together. After a few long negotiations with clients, I came up with a list of three questions I ask upfront to make sure the partnership is a good fit.

What is your estimated monthly budget for development?

As a freelancer, you have multiple clients. I have found out that by myself, I can handle about 5 of them. Each client will have urgent needs, Black Friday is in the same day for everyone, each needs meetings for time to time. Because of this reason, aim for clients that budget at least 20% of your desired monthly income. Less than that is too much noise and you won’t be able to serve them well.

What’s your revenue (or number of orders/paid subscribers/paid downloads)?

Each client pays you out of their revenue. If they don’t make money, they won’t be able to pay you long term. No matter how well you do your job, they will not afford you at some point. Basically, a client will take a loss of profit only if:

  • They are a startup and hope that their product will sell a lot when ready
  • They have other sources of revenue (i.e. an online shop that’s backed up by a brick and mortar store)
  • They are heavily investing hoping to increase the business
  • They have no idea what they are doing

Evaluate well. While making some extra money is ok, it is better to have partnerships with profitable businesses.

Do you work hourly or fixed bid?

Personally I found out that working hourly is the best for my clients. If they agree on this, I simply provide my hourly rate upfront. With new clients however, you sometimes have to earn trust so you might have to go fixed bid for a while. To make sure that your expectations are aligned, give some examples from the past, i.e. “I have built this payment method integration for X”. The client will quickly realise whether you are a match for them.

Isn’t this to blunt?

No. As I stated in the beginning, you should make sure the basic terms are in order as soon as possible out of respect for the client’s time. There are some clients (especially in the lower tier level), that will wonder why do you ask these questions. Personally, I give them the same reasons I have outlined here.

What other challenges are there?

Even with the above questions answered and agreed upon, there are still challenges that might appear after signing the contract…

  • They might pay late or not at all
  • They always have urgent needs
  • In case you signed up for a fixed bid, they might ask for a lot of quotes and meetings, ending up by implementing very little, making most of your time unbillable
  •  You simply cannot communicate well with them

I was not able to find the right questions for the above, so my approach is to start with a “probation” period, in which both me and the client can part ways without much heads-up. With the probation set up-front (and possibly a lower rate if it happens), you will never have an unhappy client even if you stop the collaboration. Usually, a broken partnership is reciprocal, they will want to get out of it as much as you do.

 

 

 

Why hourly contracts are better than fixed prices

A while ago I have decided to charge hourly. This sometimes puts clients off, who seem to prefer the comfort of knowing the full project price upfront. However, fixed price rarely ends up well for me or for my clients.

Disadvantages as a service provider

  • Estimating is hard. Every project is unique. I either go too low and lose money or go too high and rip off the client.
  • Estimating properly takes time. I might need to spend weeks to architect a project. And I might need the client’s involvement to answer a lot of questions. Most clients do not expect this.
  • With a fixed price, two new challenges appear – time management (since fixed bid is usually fixed time) and scope creep (you want to make sure you build only what you quoted). Both things take time and a different skillset.
  • It’s hard to keep the client happy. Scope creep tends to be natural.  Most people cannot really understand the software completely till they see it. So since the client won’t be able to articulate the needs in the first place, they won’t be getting a fixed price anyway, unless you want to eat up the costs.
  • Working in teams make fixed price even harder. Winning a contract takes time. It is not uncommon that the original estimate was created by another developer(s) than the ones ending up doing the work. I have a very vague idea on how long it takes me to do something. I have no idea how long it will take for a developer that may not even be hired in the company when I’m estimating.
  • Fixed price is toxic for the team. It’s the number one reason for overtime, arguments, endless meetings, loss of profits.
  • In companies, fixed price adds a lot of overhead. Before you know it, you will need project managers to keep track of hours and progress. You will need client-facing persons to explain why something is out of scope. You will be writing a lot of proposals/change requests. You will have a lot of meetings to keep everyone in sync.

Disadvantages as a client

Clients usually think that fixed price is better for them. But here is why it isn’t….

  • The fixed price is a lot higher. That’s because any company will add risk and the cost of the additional staff (client partner, management etc). That easily multiples the price by a factory of two or three.
  • Fixed price makes the project lower quality. The focus is to finish as fast as possible.
  • As a client, you rarely know exactly what you want. Actually, it’s usually recommended to ask the specialist’s opinion along the way. So then why be forced to take all the decisions before starting the project?
  • The relation with the developer can easily turn sour. The worst projects are the ones that switched several teams of developers.

How can it work?

Of course, there are cases where fixed price works great, otherwise the model would have disappeared long time ago…

  • You can charge a huge price. That’s the case with the top-tier companies. Their reputation allows them to change so much that the development cost does not matter. Then they can hire/fire/switch teams so that they hit the launch dates.
  • You had the same project before. If you can just copy-paste most of the code, it would be silly to charge hourly. You might be able to deliver a 1000-hours project in 2-3 hours!
  • Project is small. This usually works for projects like logos or WordPress sites. If the project is just a few hours/days of work, it might be worth the risk. You will occasionally hit a picky client, but that may mean only 1-2 more days of work and can even out with the other projects.
  • You get lucky. Sometimes, tasks might take less than estimated. Since the client is in a fixed bid contract, you get to keep the extra money.

How can I charge hourly?

A lot of freelancers/companies will not charge hourly simply because they won’t find the clients to accept this. Here are a few tips to get paid hourly…

  • Get hired. Yep, that’s the easiest. A salary is hourly payment. While you might have a boss that asks you to work faster, you will get paid even if your estimates are wrong. Get more experience under your belt, at some point you will be ready to consult/freelance/start your own company.
  • Don’t reach out. If you have to actively search for clients, you’re doing it wrong. Hourly contracts imply trust. If a client reaches out to you, it means they already trust you to a degree. This applies to freelancers, I guess if you have a company with a sales team you should let them sell.
  • Learn the principles of Agile. Hourly works great with Agile. Build a process, present it to the client. Most clients initially refuse the approach just because they don’t understand how it can work.
  • Build trust. You might need to do the first project fixed bid, or provide a very accurate estimate. The second one will be hourly for sure if the client is happy. If the client has a solid business, they will always have work for you. So get a few of those and you’re good.
  • Associate yourself with bigger names. Be part of freelancer networks or collaborate with companies. Especially if you’re living in poorer countries, having a bigger company to back you up will give clients a trust boost. Not to mention that such networks/companies usually bring clients to you without any effort. Just tell them you’re working hourly and let them figure out the clients that want your services.