Creating Akeneo Jobs - central part of Akeneo architecture.
Jobs are automatic processes that allow to create new data, inter-change data between entities (like attributes and their options) and manipulate data. Examples are: creating new attributes, products or other from external data in .csv, .xlsx or other files, exporting existing data.
Below example is first 2 modules created as akeneo jobs and wrapped in cli commands(bin/console ...) to download GS1 codes data from
external source in .xml format, then validating it, and finally creating usable reference data by loading it into the system.
Below, let's see how to code 2 separate jobs which are performing these operations. First one will handle download and the second will parse file and create usable data out of it.
If we want to create job, first we need to specify it's configuration.
I created PcmtConnectorBundle that will handle all custom jobs for Pcmt.
Inside PcmtBundle/Resources/config, I created jobs.yml, where all our jobs will be defined.
As you see, we define new service, which has Job class as a template. We create it using our custom arguments.
First argument, the 'reference_data_download_xmls' is the distinct name of our job that will be it's identifier.
After that there go EventDispatcher and JobRepository that are util classes.
The main part of this particular job is the
This argument represents "Step", the unit of work that is a building block of a job. Each step is a separate task and steps are executed one after another. Each step class that defines set of operations needs to implement StepInterface.
I implemented this step as a class extending AbstractStep - which is the most general foundation for creating steps and has only doExecute() method. This method is invoked during job execution. It's a job for the developer to implement this method.
This is the implementation:
The step class needs to be registered as a Symfony service, so that I created steps.yml file and thrown the config in:
Now, if we want our job to start working, we need to provide additional configuration. And Akeneo indicated that there are 2 config classes to be specified for each job. These are ConstraintCollectionProvider and DefaultValuesProvider. As their names suggest we can find default configuration and validation constraints inside. That is necessary, as each job instance is persisted to the database and default values to be stored are taken from that classes.
This is how I written the config for our download job:
Each step in the job has access to these parameters.
As you see, I provided a set of links that the ImportRefDataFiles step can use to crawl and download files and dirPath so that it knows where to save them.
Both of this classes need to be configured, so I created 2 files: job_defaults.yml and job_constraints.yml
where I wired each configuration for pre-defined jobs.
Let's take a look at arguments. First one is an array. Inside you define job names that this provider will serve. In our case I want it to be our download job - reference_data_download_xmls
The second argument is a custom one, in this case this is a directory name where to save files, but it can be anything. You can add as many arguments as you want.
When all config is in place, we can register a job using command:
If all config is done properly (watch for .yml mistakes) the job should fire up step, download necessary data and log the whole process into the database under akeneo_batch_step_execution and akeneo_batch_job_execution tables.