MakeとShopifyを連携する方法｜注文の記録と担当者への通知

注文受付と出荷指示を分ける

今回は注文ID、注文日時、合計、通貨、支払状態を管理表へ記録し、社内へ通知する構成です。注文が作られたことを支払完了や出荷許可とは扱いません。Make公式ではShopify接続に有料アカウントが必要と案内されているため、練習に使えるストアと接続条件を先に確認します。

ストアと接続を一本化する

Shopifyモジュールで対象ストアを指定し、必要なアクセスを確認して接続します。同じアプリとストアの組合せで複数接続を不用意に作ると、スコープが影響し合う場合があるため既存接続を調べてください。今回は読取を中心とし、在庫更新やフルフィルメント作成まで権限を広げる必要があるかを分けて判断します。

新規注文と更新を取り分ける

利用できる注文トリガーを選び、開始位置と試す注文を限定します。新規注文のみを記録する流れと、注文の状態変更を反映する流れは目的が異なります。通知ごとに行を追加するのではなく、ストアと注文IDの組合せで検索し、初回だけ追加、その後は必要な状態を更新する形を基本にします。

注文一行と明細複数行を混同しない

注文に商品が三つあっても、注文合計は注文単位で一度だけ保存します。明細が必要なら注文表とは別の明細表に、注文IDと明細IDを持たせます。Iteratorの後で注文合計を足すと商品数だけ売上が膨らむおそれがあります。金額の形式と通貨を一緒に保存し、異なる通貨の単純合算は行いません。

通知に渡す情報を絞る

社内通知には注文番号、確認すべき状態、権限のある管理画面へのリンクを使います。住所や電話番号を広いチャンネルへコピーしない構成にしてください。未払い、支払済み、キャンセルなどを区別し、どの状態で誰が確認するかを決めます。通知本文に「出荷してください」と書くのは、出荷条件を別に確認した場合に限ります。

更新と失敗後の再実行を試す

同じ注文の再送で行が増えないこと、状態更新で同じ行を直すことを確認します。管理表への保存が成功し通知だけ失敗した場合は、注文IDと通知状態を見て通知を復旧します。キャンセルや返金の履歴を新規売上へ加算せず、元の注文と関連付けて残すと、後の集計で理由を追いやすくなります。

件数の照合と費用を確認する

商品一つの注文、複数商品の注文、状態が変わった注文を練習対象にします。注文件数と明細件数、通知数を別々に比較してください。Shopify管理画面との金額照合は通貨と対象期間をそろえて行います。Makeの消費は注文件数だけでなく明細展開・検索・更新・再試行にも左右され、ストア利用料とは別です。

• Shopifyの運営費を見積もる｜注文数・決済・アプリ・撤退費用
• MakeのIteratorとAggregator｜配列・bundle・まとめ通知を理解する
• Makeの重複登録を防ぐ｜受付ID・Data store・再実行の設計