v10.4
基本
BizRoboの独特なフロー制御として、ブランチがある。
上記のフローを作成した場合、ステップの実行順序は 1 → 2 → 3 → 4 → 5 となる。
ブランチと変数のスコープ
BizRoboでは各ステップの状態がすべて記憶されており、フローが別のブランチへ移ると、状態がすべてブランチの分岐前に戻る。例えば以下のように、ステップごとに文字列を変数へ結合してみる。
この実行結果のログは、以下の通りとなる。
この通り、1つ目のブランチの最後のログは「123」となっているが、ステップ1の後から分岐した2つ目のブランチの最後のログは「145」となっている。変数の状態が分岐前に一度戻っていることがわかる。
ステップごとの状態がスタックのように積み上げられているとイメージすると、わかりやすいかもしれない。
変数の設定で「グローバル」を選ぶと、変数の状態がブランチによって元に戻らなくなる。
変数1をグローバルにしてさきほどのフローを実行すると、ログは以下のようになる。
ブランチは合流させることもできる。
上記のフローを実行した場合、ログは以下のようになる。
合流先のステップ6以降が2回実行される。
個人的には、一度分岐したブランチは特に理由がない限り合流させないほうが良いと思う。あまり分岐＆合流を繰り返すと、フローが分かりづらくなる。
エラー時の動き
ロボットでエラーが発生した場合、エラーが起きたブランチの後続のステップのみがスキップされ、エラー前に分岐したブランチはエラー後も実行される。ロボットの実行がすべてスキップされるわけではない。
※Design Studio でデバッグ実行する場合は、エラーのたびにフローが一時停止する。
以下のようなロボットがあり、step 3 でエラーが起きた場合を例にする。
この場合、step 4 は実行されないが、step 5 はエラーの後、実行される。
つまり、ブランチを分けるのであれば、それぞれはほぼ完全に独立した処理であるべきで、見た目のためにブランチを分けたりすると、エラー発生時に予期しない動作を重ねる懸念がある(独立した処理ならロボットを分けるほうが良いが)。
この特性を活かした使い方として、プログラム言語にある try-finally のような実装が可能。
フローの冒頭にブランチを分けて、最後のブランチに終了処理を実装しておけば、ロボットが正常に終了してもエラーになっても実行される。
ブランチとはあまり関係がないが、ステップでエラーが起きた時にどうするかは、ステップのプロパティの「エラー処理」のタブで変更できる。
