Sandbox
Sandbox¶
To facilitate the ease of adapter development, integration and testing, Amazon Yojaka supports a sandbox against which you can test all your adapter code. You can test code that handles prod use cases, error handling, and idempotency checks, apart from testing your code for that handles authentication and authorization. Further, Amazon Yojaka supports connector side sandbox that can help you facilitate complete end to end experience from seller’s perspective.
How do I use it?¶
To use sandbox from your adapter, You’ll need to generate an AWS IAM user and provide its ARN to Amazon. More details around IAM user based authentication can be found here.
To use the sandbox from connector’s perspective, complete the On-boarding and Test Seller Registration steps.
Sandbox Setup¶
As soon as Amazon Yojaka team receives your on-boarding details, the following setup will be done on the sandbox:
Setup your adapter AWS IAM user to be able to access the sandbox.
Endpoint Name | Endpoint |
||
|---|---|---|
Adapter Sandbox endpoint | |
||
Connector Sandbox endpoint | |
Sandbox behaviour¶
There are 3 communication paths between Yojaka and an adapter. We’re touching upon each one of them below.
Synchronous communication from Adapter to Yojaka¶
There are 3 APIs involved here. More details on APIs and their schema can be found here.
CreateOrder
CancelOrder
CreateReturn
Changing the endpoint to point to sandbox should be enough to start calling sandbox APIs. Amazon Yojaka team provides an SDK for better experience. SDK details can be found here.
Synchronous communication from Yojaka to Adapter¶
There are 7 APIs involved here. More details on APIs and their schema can be found here.
- Order Processing:
CreateSandboxOrder (As CreateOrder trigger point.)
CreatePackages
UpdatePackages
GenerateShipLabel
GetInvoice
RetrieveShippingServices
ShipOrder
- Inventory/Sku update:
GetSkuListingDetails
UpdatePricingInfo
Amazon Yojaka team expects sandbox endpoint of these Rest APIs. These APIs will be called on regular intervals for systems’ pulse check.
Note
Drop an email to (smartconnect-support@amazon.com) with your Rest endpoint for sandbox and prod environment once they’re up.
Asynchronous communication from Yojaka to Adapter¶
There are 6 different events Yojaka sends.
- Order Processing:
Order Accepted.
Order confirmed.
Order Shipped.
Seller Rejection.
Customer cancellation acceptance.
- Inventory:
Inventory update.
The exact event payload can be found here along with onboarding steps. Amazon Yojaka team doesn’t plan to perform any kind of testing on these communication. We expect adapters to consume these events. Amazon Yojaka team just keeps an audit of all events sent to an adapter. We recommend that adapter should also keep an audit of all the events sent.
Testing and Regression performed by SmartConnect¶
While the Smart connect sandbox works very much like the production system, the main difference is that the trigger point for any order processing is a marketplace in a production system, while in sandbox, it can be either marketplace or Amazon Yojaka based on whoever’s testing.
Because of this disconnected sandbox behavior, Amazon Yojaka team is going to need a CreateSandboxOrder Rest API from adapter. This API’s contract should be similar to Yojaka’s CreateOrder API contract, which can be found here. This can act like a trigger point for order injection in Yojaka platform through a marketplace.
Testing and Regression as an adapter¶
Note
Inventory needs to be present of the SKU, for which, the order is being dropped.
End to end Testing: (recommended)¶
As part of this, SmartConnect recommends to create a sandbox connector. As an adapter developer, this’ll help understand the seller experience for adapter injected orders and simulate all seller operations. Details on creation of sandbox connector can be found here. It’ll help amazon and marketplace be in sync regarding what kind of test orders are being dropped. For all the subsequent order processing calls like GenerateShipLabel and GenerateInvoice, marketplace can pass order specific details.
Additional Steps involved * Create a sandbox connector. Steps can be found here. * Use the postman collection provided in the above link to make API calls on connector’s behalf.
Behaviour * For CreateOrder and CancelOrder event, order status can be seen for the connector. * For async events testing, it can be triggered from connector APIs like ConfirmOrder, ShipOrder, Inventory update. Once these calls are made on connector’s behalf, it’ll drop corresponding events in adapter’s SNS topic. * For sync API calls, corresponding adapter API’s will be called, like CreatePackages, GetInvoice, GetShipLabel etc.
Adapter Exclusive Testing¶
Here, you, as an adapter developer, doesn’t need to onboard a connector to perform testing. Steps mentioned at the top for adapter on-boarding are the only ones required.
Smartconnect would be exposing an UpdateSandboxInventory API, which should be used before calling CreateOrder API. This API will update the inventory for the mentioned sku for merchantId <channelMerchantId> and locationId <channelLocationId>. You’ll need to reach out to Yojaka to create a location for you to get test.
Behaviour * Multiple adapters will be using this merchant for their testing. So, try to keep the sku unique. * CreateOrder API call should be made for the above mentioned merchant and location. * Yojaka will not be publishing any kind of async events to adapter’s SNS topic, the responsibility to generate correct event body and testing it lies with the adapter. Event signatures can be found here. * Adapter’s exposed sync APIs would be called periodically to keep track of the pulse of adapter systems.
On this page
