One of our customers initiated a new program to sell through eTailers. As mentioned in another blog article, you have to get the product data to the eTailer, receive orders, and then foster growth. In this article, we’ll talk about how we got product, price, and inventory information to this customer’s channel partners.
When tasked with this problem, we first went through an evaluation process, and then a vendor selection process. Ultimately, the vendor we settled on was Akeneo. The Akeneo platform was born out of the founder’s experience with Magento. They saw that there was complexity managing the data that went into the eCommerce system. So, they created Akeneo to address the challenges. We’re up and running now and we are building a sustainable model for servicing the channels. This starts with automating the process for getting product, price and inventory data to the eTailers.
Overall, Akeneo is a solid product. It’s open source so you have access to the code to make changes and it’s pretty easy to modify. For this customer, the high level process was straightforward: Import products, prices, and inventory positions into system; update data; and then export in format for channel partner.
It was a little different than Akeneo’s original intention which assumed you were getting the same product data out to the omni-channels you serviced such as web, print, mobile, etc. Our use case was different in that we were getting product data out to lots of different eTailers. The products weren’t always the same, the descriptions weren’t always the same but could be, and the prices and inventory weren’t always the same. So, we had to make some modifications.
The baseline Akeneo workflow provided a solid foundation of features we could build on to support the operations. The basic premise is the same – data is imported, data is modified, and data is exported. In the Akeneo interface, these steps are defined as Collect, Enrich, and Spread.
Collect. The first step is to import the data. In this case, we had a few different sources of data – all flat files – which were delivered to a secure FTP server every morning. From there, we had different profiles of import scripts in Akeneo. These imports are scheduled daily using the internal Akeneo cron utility. There is some custom processing we had to do on import such as concatenating several fields together, but it was simple enough to do in PHP. We also had to modify the import scripts to preserve manually overwritten data which we will talk about more in the Enrich step. We added a pull from an external secure FTP site to move the files to the local server and we added a number of error conditions that are reported during import. The scripts run daily and there is a lot of data that changes, so these additions were critical to making the process work in production.
Enrich. Once the data is imported, we enrich it. Akeneo’s base functionality has most of features we needed in that you can view and change product details, you can see historical changes, you can create product classes (which they call families) to determine what attributes are required, and you can categorize the products in one or more catalogs. All necessary things for managing product data.
For us, the imported data can change frequently and we had to have a process to preserve manually overwritten data, otherwise we would have had to re-enter the manual data after every refresh. We also wanted to utilize Akeneo’s internal history function to show when an attribute had a manual override so that a manager could go back and research who had made changes. We accomplished this by adding additional ‘preserve’ attributes that mirrored the standard attributes and then added custom code that modified the history.
The next change we made was to modify the Available functionality. We added a toggle on the data grid to add or remove the part from the channel and the ability to mass update the parts to toggle the Available field. We use the attribute to indicate if the product is available in the channel and only export those parts during the export.
Next, Akeneo has global attributes and channel based attributes. For us, we don’t always use the same data across channels, but can. So, in the edit screens we added an ‘Apply to all channels’ button for the attributes that could. You can modify the value, then if you want it to apply across all channels, you click the button and it copies the data.
Another feature was to only export a partial list of parts in an export profile. Some of the channels only want net change for product descriptions, but then a full export of pricing and inventory. So, we modified the data grid to allow us to send a partial list of exports to a selected export profile.
Finally, we added price and inventory reports that would show us prices and inventory across all channels. We needed a single place to go to view prices and inventory across multiple channels and Akeneo does not provide that functionality in the base install.
These were all straightforward changes that we implemented in the PHP code which were done in weeks not months.
Spread. Once the data is finalized, it has to get to several different channel partners including eTailers like eBay, Sears, and Amazon. Each of these eTailers has their own data requirements and delivery nuances. For example, eBay requires the data in a zipped, tab delimited file format. They require a file for product information and a separate one for price and inventory updates. For automated updates, Sears requires the data in an XML format and sent via an HTTP API. To complicate things further, some vendors require minimum or maximum characters on different fields. All of this is handled by the export process.
Akeneo has export profiles which we use for all the different file formats. Each channel partners has one or more export formats that mirror the files they require. For example, eBay has two export profiles – one for product data and a separate one for price and inventory data. We took the process a step further and added ‘delivery’ functionality. Once the data is exported, it is then packaged for delivery to the respective channel. In the case of eBay, the files are zipped and then ftped to the eBay servers which are automatically imported at a specified time interval.
Summary. All in all, Akeneo provided a solid base from which we expanded the functionality for our specific needs. The tried and true technology stack of PHP and MySQL, while might not be the most exciting technology, is very mature and easy to change. We made the mistake of chasing new technologies initially and it bit us in the wallet. It was much more expensive than it needed to be, was difficult to modify, and difficult to find people that knew the technology stack. Akeneo was much quicker –from start to finish took 3 months – and we’re on to the next step of helping them increase sales in these channels.
One of our customers initiated a new program to sell through eTailers. As mentioned in another blog article, you have to get the product data to the eTailer, receive orders, and then foster growth. In this article, we’ll talk about how we got product, price, and inventory information to this customer’s channel partners.
When tasked with this problem, we first went through an evaluation process, and then a vendor selection process. Ultimately, the vendor we settled on was Akeneo. The Akeneo platform was born out of the founder’s experience with Magento. They saw that there was complexity managing the data that went into the eCommerce system. So, they created Akeneo to address the challenges. We’re up and running now and we are building a sustainable model for servicing the channels. This starts with automating the process for getting product, price and inventory data to the eTailers.
Overall, Akeneo is a solid product. It’s open source so you have access to the code to make changes and it’s pretty easy to modify. For this customer, the high level process was straightforward: Import products, prices, and inventory positions into system; update data; and then export in format for channel partner.
It was a little different than Akeneo’s original intention which assumed you were getting the same product data out to the omni-channels you serviced such as web, print, mobile, etc. Our use case was different in that we were getting product data out to lots of different eTailers. The products weren’t always the same, the descriptions weren’t always the same but could be, and the prices and inventory weren’t always the same. So, we had to make some modifications.
The baseline Akeneo workflow provided a solid foundation of features we could build on to support the operations. The basic premise is the same – data is imported, data is modified, and data is exported. In the Akeneo interface, these steps are defined as Collect, Enrich, and Spread.
Collect. The first step is to import the data. In this case, we had a few different sources of data – all flat files – which were delivered to a secure FTP server every morning. From there, we had different profiles of import scripts in Akeneo. These imports are scheduled daily using the internal Akeneo cron utility. There is some custom processing we had to do on import such as concatenating several fields together, but it was simple enough to do in PHP. We also had to modify the import scripts to preserve manually overwritten data which we will talk about more in the Enrich step. We added a pull from an external secure FTP site to move the files to the local server and we added a number of error conditions that are reported during import. The scripts run daily and there is a lot of data that changes, so these additions were critical to making the process work in production.
Enrich. Once the data is imported, we enrich it. Akeneo’s base functionality has most of features we needed in that you can view and change product details, you can see historical changes, you can create product classes (which they call families) to determine what attributes are required, and you can categorize the products in one or more catalogs. All necessary things for managing product data.
For us, the imported data can change frequently and we had to have a process to preserve manually overwritten data, otherwise we would have had to re-enter the manual data after every refresh. We also wanted to utilize Akeneo’s internal history function to show when an attribute had a manual override so that a manager could go back and research who had made changes. We accomplished this by adding additional ‘preserve’ attributes that mirrored the standard attributes and then added custom code that modified the history.
The next change we made was to modify the Available functionality. We added a toggle on the data grid to add or remove the part from the channel and the ability to mass update the parts to toggle the Available field. We use the attribute to indicate if the product is available in the channel and only export those parts during the export.
Next, Akeneo has global attributes and channel based attributes. For us, we don’t always use the same data across channels, but can. So, in the edit screens we added an ‘Apply to all channels’ button for the attributes that could. You can modify the value, then if you want it to apply across all channels, you click the button and it copies the data.
Another feature was to only export a partial list of parts in an export profile. Some of the channels only want net change for product descriptions, but then a full export of pricing and inventory. So, we modified the data grid to allow us to send a partial list of exports to a selected export profile.
Finally, we added price and inventory reports that would show us prices and inventory across all channels. We needed a single place to go to view prices and inventory across multiple channels and Akeneo does not provide that functionality in the base install.
These were all straightforward changes that we implemented in the PHP code which were done in weeks not months.
Spread. Once the data is finalized, it has to get to several different channel partners including eTailers like eBay, Sears, and Amazon. Each of these eTailers has their own data requirements and delivery nuances. For example, eBay requires the data in a zipped, tab delimited file format. They require a file for product information and a separate one for price and inventory updates. For automated updates, Sears requires the data in an XML format and sent via an HTTP API. To complicate things further, some vendors require minimum or maximum characters on different fields. All of this is handled by the export process.
Akeneo has export profiles which we use for all the different file formats. Each channel partners has one or more export formats that mirror the files they require. For example, eBay has two export profiles – one for product data and a separate one for price and inventory data. We took the process a step further and added ‘delivery’ functionality. Once the data is exported, it is then packaged for delivery to the respective channel. In the case of eBay, the files are zipped and then ftped to the eBay servers which are automatically imported at a specified time interval.
Summary. All in all, Akeneo provided a solid base from which we expanded the functionality for our specific needs. The tried and true technology stack of PHP and MySQL, while might not be the most exciting technology, is very mature and easy to change. We made the mistake of chasing new technologies initially and it bit us in the wallet. It was much more expensive than it needed to be, was difficult to modify, and difficult to find people that knew the technology stack. Akeneo was much quicker –from start to finish took 3 months – and we’re on to the next step of helping them increase sales in these channels.