DRSをサーバーにインテグレートする
I:DRSの実装
Amazon Dash Replenishment Serviceは、顧客情報、発注情報、および再発注状況を取得するためのRESTful APIを提供します。各々のAPIはバージョン管理されており、新規機能が追加された場合は最新のバージョンのAPIを使うことでで提供されます。DRSはSNS通知を用いて、デバイスメーカーに再発注状況の変更について通知することが可能です。
API機能のリストはAPIの概要を、SNS通知についてはSNS通知メッセージをご覧ください。
この章では、デバイスとDRS Cloudの間の通信におけるベストプラクティスを説明します。
Cloud概要
Cloudは、デバイス・コンパニオンアプリ・DRS間の通信を司ります。DRS対応アーキテクチャをゼロから構築する場合、あるいは既存のインフラストラクチャにDRSを対応させる場合、下記３つのコンポーネントが必要となります：
- SNSリスナー - DRSから送信されるSNS通知を受信し、処理する
- データベース - お客様の在庫とデバイスの消費量を格納する
- サーバー、あるいはLambdaのようなサーバーレスアプリケーション - コンパニオンアプリ、デバイス、およびSNSリスナーからのリクエストを処理する
Cloudの役割としては、下記の４つの役割があります：
- 在庫情報のアップデート – Cloudは在庫の残量を監視し、再発注した消耗品が届いた場合、あるいはお客様がDRS以外から消耗品を購入された場合に、データをアップデートします。
- 消費量の送信 – Cloudはデバイスが消耗品を使うたびに、消費量データをDRSに送信します。
- 消耗品の再発注 – Cloudは残量が減った場合、お客様に代わって消耗品の再発注を行います。
- お客様の変更の管理 – Cloudは、お客様がDRSデバイスの登録・解除・消耗品の再発注設定が行われた場合、コンパニオンアプリに対して正しい残量情報をアップデートします。
お客様がDRSの設定を操作して再発注の情報や再発注のON/OFFなどの状況の変更を行った場合、デバイスメーカーはDRSクラウドからSNS通知メッセージを介して、それらの変更を受信します。SNS通知メッセージに応じて、コンパニオンアプリのUIを更新してください。また、自動再発注のオーダー情報が変更された場合、デバイスメーカーはオーダーに固有のSNS通知を受信します。この場合もSNS通知に応じて、在庫量のアップデートを行ってください。
サーバーアーキテクチャ
拡張性の高い、スケーラブルな基盤を構築することで、多くのIoT・スマートデバイスと通信することのできる大規模ネットワークを管理することが容易になります。
開発者は独自のクラウドを利用できますが、Amazonは下記のサンプルアーキテクチャを読んで、各々のコンポーネントがどのように相互に関係するか、理解いただくことをお勧めします。
クラウドの最適な構築・カスタマイズについては、AmazonのDRSソリューションアーキテクトにご相談いただけます。
在庫量のアップデート
必要な時にのみ再発注がかかるよう、在庫量の監視は重要です。在庫量は次の３つのケースでアップデートされます：お客様がデバイスを使った場合、再発注された消耗品が届いた場合、およびコンパニオンアプリを介して手動で調整が行われた場合です。
お客様がデバイスを使い、デバイスのスロットから消耗品が排出されたとき、デバイスはCloudと通信して使用量を報告する必要があります。Cloud側ではデータベースをアップデートし、在庫量がデバイスを安心して使用継続できるレベルかどうかを確認します。
アップデートされた在庫量は、コンパニオンアプリ常に表示してお客様が見ることができるようにしてください。
お客様に代わって再発注を行った時、DRSはオーダーに関するアップデートのSNS通知を送信します。各々の発注において、Cloudは２つの通知を受信します：オーダーが発注された時、および商品が発送された時。また、お客様が発注のキャンセルをした場合にもCloudに通知が行われます。SNSのItemShipped通知は３つのキーとなる情報を含みます：再発注されるスロット（例：液体洗剤）、再発注される量（例：５リットル）、および配達予定日です。Cloud側では通知からこれらの情報を捕捉し、配達された日における在庫量をアップデートすることが可能になります。
お客様がDRS以外で追加の消耗品を購買するような場合のため、コンパニオンアプリ上で在庫量の手動補正ができるようにしてください。
消耗品の種類
消耗品の消費量を監視することで、より正確な再発注のロジックを構築することが可能となります。消耗品の監視を安定的に行うため、各々のスロット においてどの単位および量が用いられるか把握してください。
| 単位 | 量 | 製品例 |
|---|---|---|
| 容量 | L (リットル), Fl oz (液体オンス) | 液体洗剤 |
| 重量 | Kg, Oz (オンス), Lbs (ポンド) | コーヒー、ペットフード |
| 個数 | 0, 1, 2… | コーヒーポッド、食洗機のタブレット洗剤 |
| パーセント | 100% から 0% | エアフィルター、浄水器フィルター、インク、トナー |
在庫量の国際展開
複数のマーケットプレイスにおける消耗品は、異なる単位が使われている可能性があります。国際展開をする製品で在庫量のアップデートを処理する場合、DRSのAPIからの情報に基づいて、単位変換をするロジックを実装してください。
在庫量通知の管理
在庫量通知を設計する場合、特に国際展開をする製品では、DRS APIおよびSNS通知からの情報に基づいて、単位を変換するロジックを実装することを勧めます。各国での単位:
| US | UK | DE | FR | IT | ES | JP | |
|---|---|---|---|---|---|---|---|
| 容量 | Fl oz (液量オンス) | l | l | l | l | l | l |
| 重量 | oz (オンス) | kg | kg | kg | kg | kg | kg |
| 個数 | count | count | count | count | count | count | 個 |
OrderPlacedNotificationを受信するとき、例として、アメリカにおけるお客様向けの液体洗剤の単位は"fl oz (液量オンス)"であり、UKの場合は"l (リットル)"です。
例
...
"productInfo": [
{
"asin": "B00JGZBTCI",
"quantity": 103,
"unit": "fl oz",
"estimatedDeliverydate": "2016-12-09T07:59:59Z"
}
],
...
...
"productInfo": [
{
"asin": "B077YLQ2R1",
"quantity": 5.0,
"unit": "l",
"estimatedDeliverydate": "2016-12-09T07:59:59Z"
}
],
...
単位系
各々の単位は、下記のような表記で取得されることがあります。
| 単位 | 文字列 |
|---|---|
| 容量 | liters, liter, litre, litres, l, L, ml, milliliter, milliliters, ounces, ounce, oz, fl oz |
| 重量 | kg, kilograms, kilogram, ounces, ounce, oz |
| 個数 | count, pod, pods, sheet, sheets |
消費量データの送信
デバイスが消費量データをCloudに送信する時、同時にslotStatus APIによってAmazonにも送信してください。残り在庫量の送信も必要です。
サンプルリクエスト
POST /slotStatus/{SLOT_ID} HTTP/1.1
Host: "https://dash-replenishment-service-na.amazon.com"
{
"expectedReplenishmentDate": "2018-12-28T10:00:00Z",
"remainingQuantityInUnit": 3.5,
"originalQuantityInUnit": 10,
"totalQuantityOnHand": 20,
"lastUseDate": "2018-12-21T10:00:00Z"
}
slotStatus APIを参考にしてください。
消耗品の発注
在庫量が再発注の閾値を下回る時点を予測するロジックは、発注のキャンセルを防ぎ、お客様に継続して使っていただき、最高のカスタマーエクスペリエンスを提供する観点で重要です。 必要となった時のみに発注を行うロジックは、７行ほどのサンプルコードで作成できます。開発者が完璧な閾値を特定するには、消費の頻度、消費量、在庫量の３つの要素が重要です。
お客様の使用量に基づく閾値の重要性を説明する例として、スマートコーヒーメーカーをお使いのお客様を考えます。20個のコーヒーポッドの在庫量があり、毎日１杯のコーヒーを飲みます。この頻度に基づくと、お客様は20日でコーヒーポッドを使い果たします。アメリカの例では、AmazonでPrime会員ではない場合の標準発送時間は５日間なので、少なくとも7日前（コーヒーポッド残量は７個）に発注することで、お客様がコーヒーポッドを切らす前に届けることができます。
別のお客様の例で、上記と同じ在庫量で、1日２杯のコーヒーを飲む場合について考えます。上記例と同じように在庫が7個の時点で発注をしたのでは、お客様は次のコーヒーポッドが届く前にコーヒーポッドを切らしてしまうことになり、カスタマーエクスペリエンスはお客様を満足させるものではありません。
次のサンプルコードでは、お客様が必要な時にのみ発注を行うロジックについて説明します。
Node.JSによるサンプルコード
const daysThreshold = 7; // Amazonによる推奨値
var inventoryUsed = getInventoryUsedInPeriod(); // 50個
var daysInPeriod = getDaysInPeriod(); // 20日
var currentInventory = getCurrentInventory(); // 20個
var burnRate = inventoryUsed/daysInPeriod; // 50/20 = 1日あたり2.5個
var podsThreshold = burnRate*daysThreshold; // 2.5*7 = 15 (再発注の閾値)
if(currentInventory <= podsThreshold){
replenishSlot(); // 再発注APIの呼び出し
}
再発注のAPIを呼び出すことで、特定のスロットでの発注が行われます。詳細はReplenish APIを参照してください。
お客様の使用サイクルを管理する
お客様が自動再発注設定を変更した場合、デバイスメーカーのCloudはSubscription ChangeのSNS通知を受信します(SubscriptionChangedNotification)。お客様が自動再発注を一時停止している時に再発注APIをコールしても、実際には発注は行われません。コンパニオンアプリで自動再発注の設定や状態の変更を、お客様に表示できることが望ましいです。
デバイスメーカーのCloudが、再発注対象のASINのようなお客様の再注文の情報を保持する場合、同じSubscription ChangeのSNS通知を受けて情報をアップデートすることができます。
お客様がAmazonアカウント設定からデバイスを完全に登録解除した場合、DRSはDeviceDeregisteredNotificationを通知します。このSNS通知を受信した場合、Cloud側でお客様のエントリー情報をクリアしてください。一方でコンパニオンアプリはDRSへの再登録ができる手段を提供してください。
その他のリソース
この章ではCloudとDRS間の通信方法について説明をしました。さらなる情報は：
次のステップ
次にSNSトピックの作成でSNSの設定について説明します。
Last updated: Aug 07, 2018