Bulk operations are actions that are performed on a large scale. Example bulk operations tasks include importing or exporting items, changing prices on a mass scale, and assigning products to a warehouse.
For each indvidual task of a bulk operation, the system creates a message that is published in a message queue. A consumer runs in the background and processes the messages that it receives. Because tasks are processed in the background through the message queue system, when a merchant launches a bulk operation from the Admin panel, control is quickly returned to the merchant. In previous releases, the merchant could not use the Admin panel until all tasks were completed.
The primary Bulk Operation interface is
OperationInterface. It defines the getter and setter methods the bulk operation uses to create and process messages. The following interfaces are also used:
|BulkManagementInterface||Schedules and deletes bulk operation requests|
|BulkStatusInferface||Returns the status of bulk operations|
|BulkSummaryInterface||Provides details about a bulk operation|
|OperationManagementInterface||Changes the status of an operation|
Three clients call bulk operation APIs:
- A publisher, which pushes messages to the message queue
- A consumer, which handles each specific operation
- A client that gets the status of the bulk operation and shows the list of failed operations
Publish bulk operations
BulkManagementInterface::scheduleBulk is responsible for publishing bulk operations. The following table describes its arguments.
|$bulkUuid||string||Bulk identifier generated by
This data is required to display the results of operations couldn't be executed for any non-recoverable reason. These results are displayed in the failed operations grid.
You also can add any data needed to execute operations. For example, if you are conducting a mass price update, you can add price data.
|$bulkDescription||string||A description of the bulk operation. This value is displayed in the Your Bulk Operations grid.|
|$userId||int||The Admin user ID that executes this bulk operation.|
See Create a publisher for a detailed example of a publisher.
When a consumer processes a message, it must notify the system of its status. The status can be OPEN, COMPLETE, RETRIABLY_FAILED, and NOT_RETRIABLY_FAILED.
To send this notification, use
OperationManagementInterface::changeOperationStatus($operationId, $status, $message = null, $data = null).
Handling Recoverable Exceptions
Magento provides database exception classes to simplify the process of identifying recoverable database errors in client code. In most cases, such errors happen due to some environment issues and can be fixed. The full path to these classes is
Magneto\Framework\DB\Adapter\<class_name>. These exceptions extend generic
|Exception class||Description of database error(s)|
|ConnectionException||SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server during query
|LockWaitException||SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded|
|DeadlockException||SQLSTATE: Serialization failure: 1213 Deadlock found when trying to get lock|
The following pseudocode illustrates how to recover from database-related errors.
See Create a publisher for a detailed example of a consumer.
Get the status of operations
getBulkStatus(UuidInterface $bulkId) to get the status of the overall bulk operation. Possible values are