ロボット設計ガイドライン

フォローする

  1. ロボットの処理設計に入る前に、まずはロジックを気にせず対象画面操作を一通りDesign Studioで実装し、BizRobo! で実装可能なことを確認すること。
    • BizRobo! が正常に表示できない、または操作できないページに遭遇した際の調査・対応工数を見越して、問題・課題に関しては可能な限りプロジェクトの前半で洗い出すべく、本工程を必ず実施した後にシステムとしてのロボット設計に入ること。
  2. ロボットの構造はできるだけシンプルなものとし、複雑なロボットを1つ作るよりは、単純なロボットを複数作ること
    • 1ロボット1機能を原則とし、ロボットの複雑化・肥大化は避ける。ロボットが肥大化・複雑化することにより、保守作業等による調査・対応工数が膨らみ、ロボットのよさである対応の迅速性に影響を与えることがあるため。
    • 下記にもあるように、Loop処理に関しては都度そのセッション情報をロボット内に保存する仕組みのため、メモリを多めに消費する。今まで特に問題となったケースはないものの、大量のロボットを同時に実行する様な場合には、メモリの消費量を抑えるための方法として、このような考慮も必要であることは気に留めておく必要があると思われる。
  3. 大量のデータを扱う際には、極力DBを利用すること。
    • たとえば容量の大きいExcelファイルやデータ数の多いCSVファイルをロボットに読み込ませる場合、それらのファイルはロボットの稼働するJVMのHeap領域に格納されることになりますが、Heap領域自体に容量の制限があり、大きなファイルの投入はGCの実行やディスクアクセスの原因になり、ロボットの処理パフォーマンスにも影響するため。
  4. 稼働開始直後は各Load Page(ページ読込)のSnapshotを取得すること。
    • 本番環境で稼働開始し、動作が安定するまで(作成時にたまたま再現されなかった画面の表示パターンの発生など)の間は、ロボットが読み込む各ページに対してスナップショットを取得しておくことにより、エラー発生時の調査から対応までのスピードが高まるため。
      特に、特定のタイミング(深夜帯)や条件がそろった場合にしか表示されない画面パターンの場合、原因の特定に時間が掛りがちであるが、Snapshotと撮っておき、エラー発生後当該Snapshotファイルをロボットに読み込ませることにより、早期にエラーを再現できる効果がある。
  5. ロボットのOutput(出力値)は1つのType(タイプ)内で定義すること。
    • ロボット作成時の不十分な設計や運用開始後の機能追加により、ロボットからOutput(出力値)として出力する項目を後から追加する場合、現行の仕組みに影響がないように新規でType(タイプ)を作成してOutput(出力値)となるAttribute(属性)を増やすことがあるが、可読性、メンテナビリティの面から、明らかに妥当な理由がない限りは避けるべきである。(ロボットメンテナンス・修正後のテストにおける確認工数が増えると同時に、見落としが発生するため。)
  6. Write Log(ログ出力) ステップを有効に使い、ロボットの動作状況をログでモニタリングできるようにすること
    • エラーの発生が予想される箇所、もしくは処理中のチェックポイントとして確認したい箇所についてはWrite Log(ログ出力) ステップを使ってその時点の画面表示内容や変数の値などをログに残しておくことで、デバッグ時にDesign Studioで再現テストをする手間を省くことができるため。
    • また、条件により処理するブランチを分けるなどの場合にもWrite Logステップにより実行されたブランチ情報をログに残すことにより、運用開始後の障害調査時に役立ちます。
  7. Write File(ファイル出力) ステップで使用するファイルパス等、複数個所で利用する可能性のある文字列については変数化し、直接文字列をActionの中に設定しないこと。
    • コピペにより、同じ文字列を複数設定する例がよくみられるが、その後の運用保守によって変更が発生した場合に、変更箇所漏れやミスが生じやすく、且つそれによって作りこんでしまった不具合は見つかりにくいため、極力不具合の原因は最初から作りこまないようにすること。
  8. Write File (ファイル出力)ステップでは Create Directories(ディレクトリを作成) オプションを ON にしておくこと。
    • ファイルだけではなく、ディレクトリも一緒に出力したい場合には当該オプションをONにしておく必要がある。また、既存のディレクトリ内にファイルを出力する場合にも影響を与えないため、無用なエラーを避けるため、特に既存のフォルダ以外にはファイルを出力すべきではないと言う状況を除き、本オプションはONとすること。
  9. KCUの節約のために、DBへのデータ登録は極力Execute SQL(SQL実行)ではなくStore In Database(データベースデータ登録)を利用すること。
    • Execute SQL(SQL実行)が1ステップ当たり1,000KCUポイントを消費するのに対し、Store In Database(データベース登録)は1KCUポイントのみの消費なので、特にクローリングロボットなどのKCUを大量に消費するロボットにおいては、KCUの節約という観点から、後者のステップを使用するのが望ましい。
  10. Variable(変数)のGlobal変数としての利用は極力避けること
    • 明確な必要性と目的があるときを除いて、Variable(変数)をGlobal(グローバル)として使用するのは避けること。Global(グローバル)変数を広範囲に使用することにより、運用後のデバッグが複雑になるとともに、思わぬ(かつ追跡が難しい)不具合の原因となるため、安易な利用は禁止する。
  11. Snippet(スニペット)をうまく活用してページごとの処理を独立して構築・検証できるようにすること。
    • 業務処理の自動化等、ロボットで処理するページ自体が実行条件により変更になる場合、単体テストや当該画面に対する処理の作りこみに於いてTOPページから画面遷移しないと対象ページを開けないというのでは開発・単体テストともに非効率ですし、ひとつのロボットを複数人で分割して開発することができません。この場合、まずは処理対象となる各ページのHTMLファイルを取得し、それをインプットとしたSnippet(スニペット)を画面ごとに作成し、ある程度Snippet(スニペット)がそろったところでそれらのSnippet(スニペット)をつなぐロボットを作成することで、ロボットの画面単位での同時分業開発、と効率化が実現できます。
    • また、ページによっては静的なHTMLファイルでは不十分でかつページ遷移におけるセッション情報が必要な場合もありますが、その場合には別ロボットとして当該ページまでの画面遷移を単純に実施するフローを作成後、表示したページをSave Session(セッションを保存)で共有プールに保存しておきましょう。Snippetを作成するロボットについてはインプットをHTMLファイルからRestore Session(セッションの復元)にすることで、上記と同様の効用が生まれます。
5人中4人がこの記事が役に立ったと言っています

コメント

0件のコメント

ログインしてコメントを残してください。