Laravel：NextEngineAPIで登録在庫の数を社内販売管理の個数に変更する【その1】

Laravel：NextEngineAPIで登録在庫の数を社内販売管理の個数に変更する

前工程でaccess_token取得までメモしました。
今回はそのtokenをつかって実際に在庫数を変更するところまでです。

まず最初にハマったところ

002006番はredirect_uriが違うというエラーとのこと。
でも登録したURLとプログラムを走らせているサーバーのURLは同じです。
どこかのプログラムが間違えているのかなどチェックしてみたけど見当たらず。
で、最終的に判明したのは【http VS https】という何とも当たり前の事柄でした。

今回、ログイン処理の問題もあって『Goutte』でPOSTしてたのですが、こいつにSSL証明書つけないでPOSTしてたんですね。そのためスキームが【http】になっていたようです。
なので、redirect_uriが「httpsって申告してるのに違うじゃん！」となったようです。『Goutte』はSSL認証つけるの面倒なので、このパーツ以降は素直にcurlでPOSTすることにしました。

全体的な流れ

ポイントは2つあります。

1は「在庫更新用POSTがない」と言う事で、2は「現在在庫数でPOSTできない」と言う事です。
1は登録商品か否かを気にしなくてもよくなるのでリストの作り手からすると楽です。
が、2は中々に面倒くさい…。いや、超面倒くさい…。

楽にするためにはどうすべきか、アイディアとしてはこんな感じ。

一度テンポラリに出力する

悩みどころとしては、テンポラリテーブルの使いまわしが出来るか否か。
使いまわせなければ【〇〇システムとの連携】の度に新しいテーブルが出来ることになるので論外。

となれば、何のデータ用の値かを表すフラグを用意しておいて『数値型の取得データ』と『文字列型の取得データ』『計算結果』を格納するカラム用意すればいろんなものに流用できないかなと。全工程の終了と開始にTRUNCATEしてしまえば誤ったデータが入る可能性も大幅に減るだろうと。

1件づつ検索してPOST

毎回商品コードつけて商品検索API走らせるってどうなのよと。問題はないのかもしれないけど気分的にはあまり…。
ただし、商品事由のエラーを見つけるのは先の方法と比べて段違いに楽。
理由は団体さん扱いじゃなくて個人扱いになるから。
ただね、やっぱり速度的に（個人的に）嫌だなと。

設計図

上のような思考をめぐらし出来上がった段取りがこちら。

どうせならと原価と標準売価などの更新まで一緒にしてしまいました。
商品追加をする際に『商品コード、商品名、売価、原価、仕入先ID』が必須だったためこの項目を用意しましたが、いろんな外部連携に利用したいのでSQLテーブル側は【必須】にしてません。

まとめ

思考回路としてはまぁまぁな出来かなと思っています。
今回は文面が長くなってしまったのでスクリプトの記載をしませんでした。
後程、記載しようと思います。