各々のAPIはバージョン管理されており、新規機能が追加された場合は最新のバージョンのAPIを使うことでで提供されます。DRSはSNS通知を用いて、デバイスメーカーに再発注状況の変更について通知することが可能です。API機能のリストはAPIの概要を、SNS通知についてはSNS通知メッセージをご覧ください。Cloudの間の通信におけるベストプラクティスを説明します。消耗品の発注お客様の使用サイクルを管理するその他のリソース次のステップCloud概要Cloudは、デバイス・コンパニオンアプリ・DRS間の通信を司ります。Cloudは在庫の残量を監視し、再発注した消耗品が届いた場合、あるいはお客様がDRS以外から消耗品を購入された場合に、データをアップデートします。Cloudはデバイスが消耗品を使うたびに、消費量データをDRSに送信します。Cloudは残量が減った場合、お客様に代わって消耗品の再発注を行います。再発注設定が行われた場合、コンパニオンアプリに対して正しい残量情報をアップデートします。お客様がDRSの設定を操作して再発注の情報や再発注のON/OFFなどの状況の変更を行った場合、デバイスメーカーはDRSクラウドからSNS通知メッセージを介して、それらの変更を受信します。SNS通知メッセージに応じて、コンパニオンアプリのUIを更新してください。自動再発注のオーダー情報が変更された場合、デバイスメーカーはオーダーに固有のSNS通知を受信します。この場合もSNS通知に応じて、在庫量のアップデートを行ってください。サーバーアーキテクチャ拡張性の高い、スケーラブルな基盤を構築することで、多くのIoT・スマートデバイスと通信することのできる大規模ネットワークを管理することが容易になります。開発者は独自のクラウドを利用できますが、Amazonは下記のサンプルアーキテクチャを読んで、各々のコンポーネントがどのように相互に関係するか、理解いただくことをお勧めします。クラウドの最適な構築・カスタマイズについては、AmazonのDRSソリューションアーキテクトにご相談いただけます。在庫量のアップデート必要な時にのみ再発注がかかるよう、在庫量の監視は重要です。在庫量は次の3つのケースでアップデートされます:お客様がデバイスを使った場合、再発注された消耗品が届いた場合、およびコンパニオンアプリを介して手動で調整が行われた場合です。お客様がデバイスを使い、デバイスのスロットから消耗品が排出されたとき、デバイスはCloudと通信して使用量を報告する必要があります。Cloud側ではデータベースをアップデートし、在庫量がデバイスを安心して使用継続できるレベルかどうかを確認します。ここで、在庫量のアップデートはAmazonに対しても送信する必要があります。下記消費量の送信をご覧ください。アップデートされた在庫量は、コンパニオンアプリ常に表示してお客様が見ることができるようにしてください。お客様に代わって再発注を行った時、DRSはオーダーに関するアップデートのSNS通知を送信します。各々の発注において、Cloudは2つの通知を受信します:オーダーが発注された時、および商品が発送された時。お客様が発注のキャンセルをした場合にもCloudに通知が行われます。SNSのItemShipped通知は3つのキーとなる情報を含みます:再発注されるスロット(例:液体洗剤)、再発注される量(例:5リットル)、および配達予定日です。Cloud側では通知からこれらの情報を捕捉し、配達された日における在庫量をアップデートすることが可能になります。お客様がDRS以外で追加の消耗品を購買するような場合のため、コンパニオンアプリ上で在庫量の手動補正ができるようにしてください。消耗品の消費量を監視することで、より正確な再発注のロジックを構築することが可能となります。複数のマーケットプレイスにおける消耗品は、異なる単位が使われている可能性があります。国際展開をする製品で在庫量のアップデートを処理する場合、DRSのAPIからの情報に基づいて、単位変換をするロジックを実装してください。APIおよびSNS通知からの情報に基づいて、単位を変換するロジックを実装することを勧めます。マーケットプレイスによって、異なる単位が用いられています。単位の文字列についても、特定の文字列に依存した実装にならないよう注意が必要です。oz"の表記で取得される可能性があります。詳しくは単位系を参照してください。APIによってAmazonにも送信してください。残り在庫量の送信も必要です。APIを参考にしてください。在庫量が再発注の閾値を下回る時点を予測するロジックは、発注のキャンセルを防ぎ、お客様に継続して使っていただき、最高のカスタマーエクスペリエンスを提供する観点で重要です。必要となった時のみに発注を行うロジックは、7行ほどのサンプルコードで作成できます。3つの要素が重要です。お客様の使用量に基づく閾値の重要性を説明する例として、スマートコーヒーメーカーをお使いのお客様を考えます。20個のコーヒーポッドの在庫量があり、毎日1杯のコーヒーを飲みます。この頻度に基づくと、お客様は20日でコーヒーポッドを使い果たします。アメリカの例では、AmazonでPrime会員ではない場合の標準発送時間は5日間なので、少なくとも7日前(コーヒーポッド残量は7個)に発注することで、お客様がコーヒーポッドを切らす前に届けることができます。別のお客様の例で、上記と同じ在庫量で、1日2杯のコーヒーを飲む場合について考えます。上記例と同じように在庫が7個の時点で発注をしたのでは、お客様は次のコーヒーポッドが届く前にコーヒーポッドを切らしてしまうことになり、カスタマーエクスペリエンスはお客様を満足させるものではありません。次のサンプルコードでは、お客様が必要な時にのみ発注を行うロジックについて説明します。再発注APIの呼び出し}再発注のAPIを呼び出すことで、特定のスロットでの発注が行われます。APIを参照してください。ChangeのSNS通知を受信します(SubscriptionChangedNotification)。お客様が自動再発注を一時停止している時に再発注APIをコールしても、実際には発注は行われません。コンパニオンアプリで自動再発注の設定や状態の変更を、お客様に表示できることが望ましいです。ChangeのSNS通知を受けて情報をアップデートすることができます。お客様がAmazonアカウント設定からデバイスを完全に登録解除した場合、DRSはDeviceDeregisteredNotificationを通知します。このSNS通知を受信した場合、Cloud側でお客様のエントリー情報をクリアしてください。一方でコンパニオンアプリはDRSへの再登録ができる手段を提供してください。その他のリソースこの章ではCloudとDRS間の通信方法について説明をしました。次のステップ次にSNSトピックの作成でSNSの設定について説明します。無断複写·転載を禁じます。