krewDataを使ってみた①

プラグインは導入していたけどほぼ全くと言って良いほど使っていなかった「krewData」をせっかくあるのだから使用してみた話です。

元々はkrewDataを使用する想定ではなく

アプリAとBがあったとした場合に、

Aで登録して保存しようとすると裏でAで入力された内容を元に整形した情報を

Bに自動連携して保存（JavaScript）させようとしてました。

最終的には、

Bレコード登録後にAの保存処理が実施されるので、

その隙間でBレコード登録時に整形したBレコードユニークキーを

Aアプリ上に配置されているBレコードと紐付け用のフィールドにセットして保存できればいいなあと思ってました。

実際にやってみたところBの自動登録までは上手くいくものの、

BのユニークキーをAのフィールドに設定するとこが実装できず・・・。

そこで第２案として、

krewDataを使用する案を考えてみました。

アプリABの他にアプリCを新規に用意しました。

※アプリC扱いはAーB間の自動連携の履歴を保持するアプリ

こちらの場合、Bに自動連携する部分でCにも自動連携させます。

CにはAとBのアプリ名やそれぞれ連動元・連動先のユニークキーを保持させます。

オンタイムでの更新は一旦ここで終了で、

予め定期実行されるkrewDataのスケジュールを用意しておき、

Cのレコードを定期的にkrewDataで拾うようにしました。

Cに履歴がいて且つkrewDataで拾っていないものがある場合は、

krewDataのフローにてCのレコードデータを取得して、

アプリAのアプリB紐付け用フィールドに取得したBのユニークキーの情報を設定させてあげます。

そのあとでCで取得したレコードにkrewDataで拾ったよのチェックをつけてあげて、krewDataのフローは終了。

krewDataのスケジュール実行なので特に意識する必要なく、

いつの間にかAーB間の紐付けも完了しているイメージです。

アプリA上に設置してあるアプリBのユニークキー紐付け項目は、ルックアップ項目だったのですが、今月のkrewDataのアップデートにより、krewDataフロー上で出力対象にルックアップ項目を選択できるようになったため、特に問題なく上記の対応を実装できました。

◆手書きの図です。

アプリCは実際なくても良くて、最初の案が無理だなとなった直後の案ではアプリCは考えていませんでした。

アプリAのアプリB紐付け項目が空のものを対象としてkrewDataで拾いに行くでも良かったんですが、アプリCを作って自動連携された対象をレコードとして確認できるようにした方があとで何を連携したのか把握しやすいかな。という観点からアプリCを追加して現状の形となりました。

krewDataの実装もさほど難しい事はなく、スラスラといきました。

会社からkrewDataの来年のサブスク分の予算を頂くためにも、

何かしらに使えるか検討しないといけない時期だったのでちょうど良いタイミングでした。

krewDataすごく使えるなと思った1日でした。