Customizing the connector

Summary

Does the connector work "out-of-the-box"?

Akeneo PIM flexibility allows you to craft a wide array of catalog structures. This versatility is a powerful asset, yet it can also influence how you employ the Akeneo Connector for Adobe Commerce.

Our Adobe Connector is meticulously designed to seamlessly integrate with your diverse catalog structures. We've incorporated various parameters into the Connector to cater to your specific needs and adapt to your modeling.

To gain a comprehensive understanding of how each parameter influences your integration, we recommend delving into the Connector Configuration documentation. This resource will illuminate the nuances of each parameter and how it can be tailored to your advantage.

Please read the documentation related to the connector configuration documentation to understand the impact of each parameter.

Can the connector be customized?

If the predefined configurations of the Akeneo Connector do not align with your business logic or if you require additional import options, you have the freedom to customize the Akeneo Connector for Adobe Commerce. Akeneo provides you with the PHP source code for the Connector upon delivery.

Before you embark on developing your own enhancements, please consider the following guidelines:

Observers define tasks for each import. To add a new task, declare a new method in the corresponding Import class and include it in the Observer.
One method in the Import class corresponds to one task.
There is no data transfer between tasks.

Should you believe that your custom feature could be beneficial to the wider community, you are encouraged to submit a pull request (PR) so it can be integrated into the repository. Additionally, if your feature holds potential value for Enterprise users, Akeneo may reach out to collaborate on incorporating your edits into the Premium version. Cheers to customization and collaboration!

Best practices to customize Akeneo Connector

In the context of customizing the Akeneo Connector, here are some best practices:

Use composer to deploy

Do not edit the initial code and prefer the override procedure. If you installed the connector via composer as recommended in the installation section, you will not be able to edit the core code (because the core code is designed as a dependency).

Override the connector

Adobe Commerce incorporates a new dependency injection system that manages which dependencies to inject. This system is controlled by the di.xml file.Each module can have both a global and a local scope di.xml file:

Global Scope:

<moduleDir>/etc/di.xml

Local Scope:

 <moduleDir>/etc/<area>/di.xml

It's important to note that you have the flexibility to override the connector, and there are multiple approaches to do so. This flexibility allows you to customize the integration according to your specific requirements and business logic.

Class preference

Let’s take an override example. We want to override the catalog product class (which is defined in the di.xml file of the Catalog module):

<config>
 <preference for="Magento\Catalog\Api\Data\ProductInterface" type="Magento\Catalog\Model\Product" />
 </config>

To override this class, all we need to do is to create a file that will extend the original class:

<config>
 <preference for="Magento\Catalog\Api\Data\ProductInterface" type="Akeneo\Catalog\Model\Product" />
 </config>

namespace Akeneo\Catalog\Model;
 class Product extends \Magento\Catalog\Model\Product
 {
 // code
 }

The order of module dependencies is very important, and to make sure that this order is the right one, the sequence has to be defined in etc/module.xml.

Plugins

By extending a class with multiple classes, you can cause conflict. To avoid that, Adobe Commerce has defined the notion of plugin. Plugins are a great solution to extend a class and not change it. Just like for the class declaration, the plugins are declared in the di.xml file. The plugin system intercepts a method call before, after, or around its call. Let’s take an example. First, the di.xml file

<config>
 <type name="Magento\Catalog\Api\Data\ProductInterface">
 <plugin name="Akeneo_catalog_product" type="Akeneo\Catalog\Plugin\Model\Product" />
 </type>
 </config>

And, then, as described earlier, the three catching methods:

Before

Before executes your plugin prior a given method. The only constraint is that your plugin needs to return the same number of arguments than the method accepts (in an Array)

namespace Akeneo\Catalog\Plugin\Model;
 class Product
 {
 public function beforeSetPrice(\Magento\Catalog\Model\Product $subject, $price)
 {
 $price += 10;
 return [$price];
 }
 }

After

This is the way to execute a procedure after a method is executed. The After method will work with the same number of arguments that the initial method plus one additional argument (the return argument of the initial method). The extended method needs to have the same name with the prefix “after”

namespace Akeneo\Catalog\Plugin\Model;
 class Product
 {
 public function afterGetName(\Magento\Catalog\Model\Product $subject, $result)
 {
 $result .= ' (Akeneo)';
 return $result;
 }
 }

Around

Around is about using both the before and after methods in one shot. The extended method shall have the “around” prefix in its name.

namespace Akeneo\Catalog\Plugin\Model;
 class Product
 {
 public function aroundSave(\Magento\Catalog\Model\Product $subject, \callable $proceed)
 {
 // before save
 $result = $proceed();
 // after save
 return $result;
 }
 }

While the plugin solution can be quite compelling for overriding and customizing methods, it's important to be aware of its limitations. The plugin solution may not work with certain types of methods, and in such cases, you should explore alternative overriding solutions. Here are some of the scenarios in which the plugin solution may not be suitable:

Objects that are instantiated before Magento\Framework\Interception is bootstrapped.
Methods that are marked as final.
Classes that are marked as final.
Classes that contain at least one final public method.
Non-public methods.
Class methods, such as static methods.
The __construct method.
Virtual types.

In situations where the plugin solution is not applicable, it's essential to employ other overriding methods to achieve the desired customization in Adobe Commerce.

Akeneo Help Center