こんな方むけの記事です
毎日一連のフローを順番に動作させたり、複雑な処理は別の子フローにまとめたいようなシチュエーションで、DLPポリシーで利用できないような方にいかがでしょう？
子フローはHTTPコネクターがDLPポリシーで使用できないと使えないので、意外とふさがれてしまっている会社さんは多いかもしれません。フローのエラー記録もついでに行おうと思います。
このアイディアは、子フローを使わず、順番に実行できない？というQ&Aが掲載されているのを見て試してみたくなりました。
SPOリストを使う
まず、flowControlというSPOリストを用意しました。
タイトル列は隠し、ID、更新日時、登録日時を表示させました。
status列は数値型で。value1、value2、err列はテキスト型で新たに追加しました。
動作のイメージ
最初のトリガーは定期実行でキックフローにSPOリストへ新規行を作るところから。その後リストの更新をきっかけに自分の番が来たら実際に処理を実行するイメージです。
-
キックフロー0 ➡ リストにstatus 0を行追加
-
Flow1がリスト更新を検知 ➡処理をして結果をvalue1に更新、status1に更新
-
Flow2がリスト更新を検知 ➡処理をしてvalue1を使い結果をvalue2に更新、status2に更新
とにかくやってみよう。
キックフロー0
何か適当な値を渡していくほうが面白いので、「タイトル」にyamada と入れてみました。後続のフローにこの私を受け渡しつつ加工してみます。
フロー1
トリガーは「項目が作成されたとき」を使いました。
errに値が入っていればそこで終了。これは無限ループ防止です。
エラーがなければ処理をして、その結果をvalue1に入れます。処理が進んだことを示すためにstatus列を1に更新します。
フロー２
フロー２のトリガーは、「アイテムが作成または変更されたとき」に変更してあります。あとは結果をvalue2に入れる部分だけ変更してあります。条件部分は無限ループ防止です。
ちなみに、このフローを保存しようとすると、このような警告が出ます。
フローの中でトリガーと同じSPOリストを更新しようとしているからですね。条件部分はこの無限トリガーループを防止しようとしています。
いちかばちかの実行だ！
。うまく動いてくれるかどうか。トリガー0を実行してみます。
あれ？フロー１でエラー判定が空なら続行のはずが、「いいえ」にわたって止まってました。リストの空のカラムは何も入れないのとは違うらしい。
フロー１とフロー２の条件部分に、空ではなく「null」と等しいという条件を追加しました。
そういえば、フロー２のほうは、statusが1の時だけ動いてくれないとこまるので、and条件でstatusの部分を加えました。
気を取り直して、再度チャレンジ
気を取り直して、キックフロー0を実行します。
SPOリストにID2が追加。最初のステータスは0。しばらく待ってSPOリストを更新してみると、ステータスが2まで進んで、value1、value2にも処理結果が入っています。value2の値は、value1を使ったものなので、最初にトリガーに与えた値が順番に渡されたことを意味します。
まとめ
というわけで、子フローを使えない場合に、SPOリストの更新をトリガーにして似たようなことが実現できることがわかりました。結果の記録や実行時間もSPOリストに記録しておけるので、意外と良い使い方なのかもしれません。
SPOリストの空の値を条件にする場合には、式でnullを与えてやらないと比較できないことも発見でした。
いろいろ応用が利きそうなので、よかったら使ってやってください。