https://oxidforge.org/wp-content/uploads/2015/10/logo_oxidforge-300x85.png 0 0 Marco Steinhäuser https://oxidforge.org/wp-content/uploads/2015/10/logo_oxidforge-300x85.png Marco Steinhäuser2014-06-27 11:35:252015-07-27 11:37:22OXID eFire Extension Product Lister
Short overview about the OXIDeFire Extension Product Lister (EPL)
General information about Product Lister
- The Product Lister is a tool for creating product export files in csv format.
- Structure and content of this export file are freely configurable to match requirements of a channel.
- Use article filters for selecting a subset of products in eShop. – Export tasks are organized in campaigns.
- A campaign combines selected products (article filter) with a file structure, source definition (channel) and execution instruction, that defines execution time and execution interval.
- Product data for export are selected from shop database, so export file is created with up to date product information.
Architecture of OXID eFire Extension Product Lister
- Shop module is responsible for configuration of application itself and managing the article filters, export channels and campaigns.
- EPL server application persists this managed data into it’s own database and controls and executes the campaigns.
- The reason for dividing the EPL into this parts is to make campaign execution decoupled from shop to keep performance impact as small as possible.
- So it is possible to install and run EPL server application at it’s own server, using a dedicated slave database. In this scenario there is no impact at eShop performance.
Communication between this parts
- There are two ways of communication between EPL shop module and EPL server application.
- first: when using frontend in shop module, shop module sends a data request to server application and this will respond to the request. All requests always contains a type, that specifies the controller used in EPL server, an action, that specifies the requested action, request that contains the request data as JSON encoded string and shop-id, timestamp and token for security reasons.
A list of request and corresponding responses will follow soon.
- Second type of communication is from EPL server application to eShop. This is needed for retrieving shop configuration data like UTF-8 settings, used database for article export and other setting values.
- When EPL shop module do not work, a common reason is a failure in the communication between eShop module and EPL server application.
- At this time I try to figure out the reasons for that and will write down a solution here.