Skip to content
This repository was archived by the owner on May 29, 2019. It is now read-only.

Status Reporting API #3

Closed
misha-kotov opened this issue Nov 21, 2017 · 0 comments
Closed

Status Reporting API #3

misha-kotov opened this issue Nov 21, 2017 · 0 comments
Assignees
Labels

Comments

@misha-kotov
Copy link

misha-kotov commented Nov 21, 2017

As a Magento developer using the Catalog Bulk API asynchronously, I want to call an endpoint that reports the status of a requested job so that I know when it completes and what errors occurred.

High Level Use cases:

  • Check the completeness status of one bulk request that was sent to the Catalog Bulk API by UUID
  • Check the completeness status of multiple bulk requests that were sent to the Catalog Bulk API, by each corresponding UUID
  • Check the how many items succeeded out of a bulk request
  • Check why the failed items failed
  • Check how many items are in progress (in case I have multiple consumers servicing a queue)

Initiator Differentiation
Since multiple entities could call this bulk API for product operations, it makes sense to have some sort of an owner/initiator identifier for each request. Needs to be secure.

Inputs

  • Owner ID and credentials
  • Job UUID

Outputs

  • Owner ID
  • Job UUID
  • is_complete: bool
  • total_count: int
  • success_count: int
  • in_progress_count: int
  • error_count: int
  • errors: contains failed ids, messages

Assumptions

  • This functionality is available in Magento Commerce only, not in Open Source. Open Source (for now) can only call the bulk APIs synchronously and wait for the response. This may change in the future with introduction of queues.

Questions

  • Is any validation done before accepting a request (ex: does each sku exist?). If yes, do we need to return info on how many were accepted and reasons why some were not? Meaning something like total_requested, total_accepted, errors on immediate response.
  • After a bulk request is received, can it be cancelled while being processed?
  • Do we need to provide ids of each successful, in progress, and failed item (in this case product) as opposed to just counts?

** Implementation **

  • use Redis for performance of the status
  • Redis has good expire mechanism. Redis will take care of it in right time
    -- it might be volatile.
  • AsynchronousOperations might be updated to use Redis.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants