Stores/Orders が存在しなかった

注文の一覧を作ろうとして、アプリコレクションを読んだ。返ってきたのはこれだった。

WDE0025: The Stores/Orders collection does not exist.

存在しない、と言われている。最初に考えたのは、新しい Wix Stores ではアプリコレクションが生えないのだろう、ということだった。だとすれば、注文はバックエンドの API から読むしかない。

この読みは間違っていた。

CMS を開くと、そこにあった

ダッシュボードの CMS を見ると、Wix Stores の注文コレクションが4件のデータを持って存在していた。生えていないどころではない。

実際の ID は、その画面の URL から確認できた。eCommerce/Orders である。Stores/Orders ではない。存在しないという返答は正しくて、こちらが古い名前を使っていた。

ここで、エラーの読み方を1つ覚えることになる。does not exist は、権限が足りないときの文面にも、綴りを間違えたときの文面にも似ている。世代が変わって ID が置き換わったという可能性は、この文面からは思い付きにくい。

フィールド名も変わっている

CMS の「フィールドを管理」で中身を確認したところ、システムフィールドの名前も変わっていた。

コレクション ID の間違いは WDE0025 で止まるので、まだ気付ける。フィールド名のほうは止まらない。descending('_dateCreated') と書いても、存在しないフィールドで並べ替えようとするだけで、返ってくる件数は変わらない。並び順だけが期待と違う一覧が出る。

ついでに分かったこととして、アイテム ID がそのまま注文 ID になっていて、購入者の情報には会員 ID が入っていた。明細も決済状態も入っている。つまり、このコレクションを読めば API を呼ばずに済む場面が多い。実際、明細の GUID もここから取れると分かったので、REST API が要るのは返金の実行だけになった。

読めなかったときの経路を用意して、どちらを通ったか出す

アプリコレクションが読めるかどうかは、権限の設定や環境によって変わりうる。そこで、コレクションを本命にしつつ、読めなければバックエンドの API へ落ちるようにした。

大事なのは、落ちたことを黙らせないことだった。どちらの経路を通ったかを、所要時間の内訳に載せて画面へ出す。

・注文の読み取り 9.4s (経路=eCom API コレクション失敗=… ページ=8 件数=800)

コレクションを読めているのか、毎回 API へ落ちているのかで、遅さの意味も直し方も変わる。フォールバックは、静かに動き続けると、その存在ごと忘れられる。

古い ID は、別のプロジェクトに今も残っている

この手の ID は、記事やサンプルコードにそのまま残る。実際、手元にある別のサイト向けのコードには、まだ Stores/Orders を読む処理が残っている。書かれた時点では正しかったコードである。

だから、アプリコレクションを使うときは、ID をドキュメントやコードから写さずに、対象のサイトで確かめるほうが早い。CMS を開いて、URL に出ている ID をそのまま使う。フィールド名も同じ画面で確認できる。