Migrated from GitLab wiki
@@ -0,0 +1,46 @@
|
||||
# Why this upgradation is required?
|
||||
|
||||
Amazon older API system MWS is going to be deprecated by **December 31, 2023**. So its right time to update the Amazon MWS to Amazon SP API. Moreover MWS is using the XML output and where Amazon is latest REST based API.
|
||||
|
||||
# Basic Setup and Repositories
|
||||
|
||||
Amazon SP-API is big API and its complex to implement everything from the scratch. as per the recommendation and our Technology Stack compatibility we have following SDK integrated into the system.
|
||||
|
||||
[https://github.com/double-break/spapi-php](https://github.com/double-break/spapi-php)
|
||||
|
||||
Before implementing this, we tried some other SDK as well, but there were version conflictions and but this worked well with the system and running fine also quite easy to understand as well.
|
||||
|
||||
OAuth system for fetching and storing Access Token is implemented by our own and working fine. New SP API (Selling Partner Application Programming Interface) has opened the doors for all marketplaces for eStack. we have tested this with **India Marketplace** and it worked fine.
|
||||
|
||||
All new amazon accounts with SP API will be stored in the Channel Account with type **amazon_spapi*
|
||||
|
||||
# Reports and Notifications System
|
||||
|
||||
Reports are best way to fetch Order Data from system, with reports we can get all data in single report whereas in normal API we can fetch limited records and have to apply Next token to fetch next records through API.
|
||||
|
||||
# Implementation Logic
|
||||
_Note: This implementation logic is not final, this is based on the current finding, can be updated as and when required_
|
||||
|
||||
- Implement the createReportSchdule and specify the period of report to generate report automatically after specified interval.
|
||||
- Periodically poll the Amazon SQS queue for REPORT_PROCESSING_FINISHED notification event using an interval that is similar to the schedule.
|
||||
- When the report processing is finished with status like **CANCELLED**, **DONE** or **FATAL**. The notification events sends *reportDocuemntId* value if there is data available in report.
|
||||
- call **getReportDocument** API operation and pass **reportDocumentID** received from Notification API.
|
||||
- Amazon returns a pre-signed URL for the location of the report document, and the compression algorithm used if the report document contents have been compressed.
|
||||
- Download the report using URL provided in response.
|
||||
|
||||
# Report tracking system
|
||||
eStack already has Report database table which stores the report data and detailed information including status of the report.
|
||||
|
||||

|
||||
|
||||
This is small information, lots of other information also available in Report Database Table.
|
||||
|
||||
_current logic thinking_
|
||||
- When notification API will fires an events, and eStack will capture that event, whatever status we will get we have to update that in the Report table
|
||||
- When there is status *DONE* eStack will download the report and persists the orders received from Amazon.
|
||||
|
||||
# Things to check
|
||||
- [ ] Report ID information and how that will be tracked and updated in the report table
|
||||
- [ ] Do we have need to make a schedule report and Notification API with every call or its one time process
|
||||
- [ ] How to get response back to the same instance
|
||||
- [ ] Figure out different Jobs and cli methods for this process
|
||||
Reference in New Issue
Block a user