Skip to main content

Integration

Integration​

The integration parts are defined using the Command design pattern through a common parent class. Default commands have been developed in the OmnitronIntegration and ChannelIntegration classes for the required flows.

The commands are invoked sequentially at the point where the task methods are defined. The output of one command serves as the input for the next, which means they produce output in the appropriate format and accept input accordingly. Therefore, it is strongly recommended to adhere to the defined interfaces.

class BaseIntegration​

To integrate with any system you must create a class which inherits from BaseIntegration. This class was designed to work with command design pattern which basically defines a task procedure interface. All defined commands override some of the default base methods according to their requirements.

do_action(key: str, **kwargs) → Any​

Runs the command given with the key and supplies the additional parameters to the command.

Parameters:

  • key – Command key
  • kwargs – Any additional parameters can be specified, for example objects must be supplied if you want to provide input to the action.

Responses:

Result of the command.

do_action_async_run(key: str, **kwargs) → Any​

Runs the command given with the key asynchronously and supplies the additional parameters to the command.

Parameters:

  • key – Command key
  • kwargs – Any additional parameters can be specified, for example objects must be supplied if you want to provide input to the action.

Responses:

Result of the command.

property catalog: Catalog​

Retrieves the catalog object using the catalog_id stored in the self.

Side effect: It stores the result in the self.catalog_object, if catalog is updated on the currently running task you must delete self.catalog_object and re-call this method.

property channel: Channel​

Retrieves the channel object using the channel_id stored in the self.

Side effect: It stores the result in the self.channel_object, if channel is updated on the currently running task you must delete self.channel_object and re-call this method.

Omnitron Integration​

The Omnitron Integration is a class within the Channel App Template that interacts with the Omnitron services to perform CRUD(Create, Retrieve, Update, Delete) operations, gather data from various services, and convert the data into the appropriate format.

Within this integration, there are commands defined for different purposes. For example, commands for creating products, deleting products, and updating stock are some of the key operations. You can refer to the documentation for a full list of all available commands.

All commands under the OmnitronIntegration class use DTO (Data Transfer Object) classes for both input and output to provide a standard interface and to prevent the need for re-writing the same logic in each project. This approach ensures that, as long as the data is converted to the same format, the commands will continue to work across different projects developed for various markets.

In an ideal scenario, there will be no need to subclass the OmnitronIntegration class, and it can be used directly. While there may be some changes in the communication between Omnitron and the Channel App Template, the underlying models and structures will mostly remain stable, meaning the likelihood of needing different development for market A and market B is minimal.

class OmnitronIntegration​

(create_batch=True, content_type=None)

Communicates with the Omnitron API services through the commands defined. It manages OmnitronApiClient object on enter and exit methods.

init(create_batch=True, content_type=None)​

Some environment parameters are stored in the integration object for convenience.

Parameters:

  • create_batch Flag to decide whether a batch request to be created.

Sales Channel Integration​

The Sales Channel Integration is a class within the Channel App Template that interacts with the services of the market where sales are intended. It handles CRUD operations, collects data from various services, and converts the data into the appropriate format.

If a client class is to be written to connect with the Sales Channel services, or if requests are made without using any wrapper structure (e.g., directly using the requests library), it is recommended to define the necessary objects and configuration variables in the __init__ method of this class.

The commands in the ChannelIntegration class include a default method called __mocked_request, which operates with mock data. These methods are intended to function as templates, providing a complete workflow. Since there are different connections and services for each market, applying a universal solution is technically not possible. Channel App developers should extend these commands and override the sendmethod to complete the command. In the new send method, they should send requests to the market’s services and convert the data into the DTO objects expected by the Omnitron commands.

class ChannelIntegration​

Communicates with the Channel API services through the commands defined.

If an API Client class is developed, initialization and deletion should be handled in ChannelIntegration class so that commands have easier access to the API object.

Command Interface​

The Command Interface is a design pattern that defines standard methods for operations to be performed. By overriding the parts of default methods like run, send, fetch, etc., that vary according to the specific needs of different commands, minimal changes can be made to develop various commands. This way, requirements such as error handling, overall flow, and status management for additional modules are not redefined for each individual command.

class CommandInterface​

get_data() → object

This method fetches the input data for the command.

transform_data(data) → object

This method can be used to format the input data before it is executed on the run method.

validated_data(data) → dict

If the input data needs to satisfy some conditions or contain required a parameter, the validation is done here.

send(validated_data) → object

If the command sends a request using input data to achieve the main object of the command, it is recommended to place those operations in this method.

Parameters:

  • validated_data

Tasks​

Tasks are methods that run at regular intervals and complete a workflow by executing different commands consecutively. They serve as entry points for the application. Commands are not called independently; instead, they are defined to run within a task, ensuring that only that specific command is executed within the task. Tasks are executed regularly according to a schedule defined in Celery or can be manually triggered through Flower. Tasks are the building blocks that create workflows. For more detailed information on this topic, you can refer to the Flows section.