1. ロボットの処理設計に入る前に、まずはロジックを気にせず対象の画面操作を一通りDSで実装し、ロボットで実装可能なことを確認しましょう。
- ロボットで正常に表示できない、または操作できないページに遭遇した際の調査・対応工数を見越して対象の画面操作を一通り実装してみましょう。問題・課題に関しては可能な限りプロジェクトの前半で洗い出すため、本工程を必ず実施した後にロボット設計に入りましょう。
2. ロボットの構造はできるだけシンプルにし、複雑なロボットを1つ作るよりは、単純なロボットを
複数作るようにしましょう。
- ロボットは1機能を原則とし、ロボットの複雑化・肥大化は避けましょう。
ロボットが肥大化・複雑化することにより、保守作業等による調査・対応工数が膨らみ、ロボットの良さである対応の迅速性に影響を与えることがあります。 - ループ処理に関しては都度、そのセッション情報をロボット内に保存する仕組みのため、メモリを多めに消費します。大量のロボットを同時に実行する様な場合には、メモリの消費量を抑えるための方法として、このような考慮も必要です。
- 連続性のない処理(ステップ)はブランチを分けましょう。また、連続性のある処理(ステップ)は
グループステップを使用しましょう。処理内容の把握や、開発や改修がしやすくなります。
3. 大量のデータを扱う際には、極力DBを利用しましょう。
- 容量の大きいExcelファイルやデータ数の多いCSVファイル等をロボットに読み込ませる場合、
それらのファイルはロボットの稼働するJVMのヒープ領域に格納されますが、ヒープ領域自体に容量の制限があり、大きなファイルの投入はガベージコレクションの実行やディスクアクセスの原因になり、ロボットの処理パフォーマンスにも影響します。
4. 稼働開始直後は各「ページ読込(Load Page)」のスナップショットを取得しましょう。
- 本番環境での稼働を開始し、動作が安定するまで（作成時にたまたま再現されなかった画面の
表示パターンの発生など）の間は、ロボットが読み込む各ページに対してスナップショットを取得することにより、エラー発生時の調査から対応までの時間が短くなります。
特に、深夜帯などの特定のタイミングや条件がそろった場合にしか表示されない画面パターンの場合、原因の特定に時間が掛りがちですが、スナップショットを撮っておき、エラー発生後、スナップショットファイルをロボットに読み込ませることで、早期にエラーを再現できます。
5. ロボットのOutput(出力値)は1つのタイプファイル内で定義しましょう。
- ロボット作成時の不十分な設計や運用開始後の機能追加により、ロボットからOutput(出力値)として出力する項目を後から追加する場合、タイプファイルを新規作成すると、ロボットのメンテナンスや修正後のテストにおける確認工数が増えるため、見落としが発生する可能性があります。
可読性、メンテナビリティの面から、明らかに妥当な理由がない限りは出力用の変数は同一タイプファイル内に作成しましょう。
6. 「ログ出力(Write Log)」ステップを有効に使い、ロボットの動作状況をログでモニタリングできるようにしましょう。
- エラーの発生が予想される箇所や処理中のチェックポイントとして確認したい箇所については、
「ログ出力(Write Log)」ステップを使ってその時点の画面表示内容や変数の値などをログに
残しておくことで、デバッグ時にDSで再現テストをする手間を省くことができます。 - 条件分岐などの場合にも「ログ出力(Write Log)」ステップで実行されたブランチ情報をログに残すことで、運用開始後の障害調査時に活用できます。
7. 「ファイル出力(Write File)」ステップで使用するファイルパスなどや、複数ステップで利用する可能性のある文字列については変数に格納し、直接文字列をアクションの中に設定しないようにしましょう。
- ファイルパスや複数ステップで使用する文字列を、手入力やコピー＆ペーストで対応すると、運用保守によってロボットに変更が発生した場合に、変更箇所漏れやミスが生じやすく、且つ、それによって発生した不具合箇所は見つかりにくいため、極力変数にて対応しましょう。
8. 「ファイル出力(Write File)」ステップでは「ディレクトリを作成(Create Directories)」オプションを設定しましょう。
- ファイルだけではなく、ディレクトリも一緒に出力したい場合には「ディレクトリを作成」項目に
チェックしておく必要があります。また、既存のディレクトリ内にファイルを出力する場合にも、無用なエラーを避け、影響を最小限にするためにも必要です。
既存のフォルダ以外にはファイルを出力できない状況を除き、本オプションを設定しましょう。
9. KCUの節約のために、DBへのデータ登録は極力「SQL実行(Execute SQL)」ステップではなく、「データベース データ登録(Store In Database)」を利用しましょう。
- 「SQL実行(Execute SQL)」ステップが１ステップ当たり1,000KCUポイントを消費するのに対し、
「データベース データ登録(Store In Database)」ステップは1KCUポイントの消費で済みます。
クローリングロボットなどのKCUを大量に消費するロボットにおいては、KCUの節約という観点から「データベース データ登録(Store In Database)」ステップを使用するのが望ましいです。
10. 変数はグローバル変数としての利用は極力避けましょう。
- 明確な必要性と目的があるときを除いて、変数をグローバルとして使用することは避けましょう。
グローバル変数を広範囲に使用することにより、運用後のデバッグが複雑になるとともに、
思いがけない不具合の原因となり追跡が難しくなるため、安易な利用は避けましょう。
11. 「スニペット(Snippet)」を活用して、ページごとの処理を独立して構築・検証できるようにしましょう。
- 業務処理の自動化など、ロボットで処理するWebページ自体が実行条件により変更になる場合、
単体テストや当該画面に対する処理の作りこみにおいて、「TOPページから画面遷移しないと対象ページを開けない」というのでは開発・単体テストともに非効率であり、ひとつのロボットを複数人で分割して開発することができません。
このような場合、まずは処理対象となる各ページのHTMLファイルを取得し、それをインプットとしたスニペットを画面ごとに作成しましょう。ある程度スニペット(Snippet)がそろったところでスニペットをつなぐロボットを作成することで、ロボットの画面単位での同時分業開発と効率化が可能です。 - Webページによっては静的なHTMLファイルでは不十分で、ページ遷移におけるセッション情報が必要な場合もあります。その場合には別ロボットで当該ページまでの画面遷移を単純に実施するフローを作成後、表示したページを「セッションの保存(Save Session)」ステップで共有プールに保存しておきましょう。
スニペットを作成するロボットについては、インプットとして、保存されたセッション情報を「セッションの復元(Restore Session)」ステップにて復元しましょう。
12. ステップ名には処理内容が一目でわかるようにラベルを活用しましょう。
- ステップ名は処理内容がわかるように「基本」タブで名称を変更しましょう。
テストステップでの条件分岐なども「→(矢印)」などを使い見通しの良いフローにしましょう。
13 . DA内では固定時間のWAITよりも「Tree Stops Changing」を使用しましょう。
- DA内で「Guarded Choice」ステップを使用する場合に、「When seconds have passed」を設定すると画面表示が完了してもWAITを続けたり、ネットワークの負荷などで読み込みに固定時間以上かかった場合にエラーとなります。これを回避するためにエレメントツリーの生成完了まで待機する「Tree Stops Changing」を設定しましょう。
14 . DAの処理を高速化するために「Freeze Tree」を活用しましょう。
- DAでは画面に変化がある度にエレメントツリーのリフレッシュを行います。
画面を更新させる必要がない処理(ステップ)を「Freeze Tree」ステップ内に設定することで、
画面(エレメントツリー)の更新を止め、パフォーマンスを劇的に向上します。
15. 同一ページから複数の処理をさせる場合には、ブランチを追加してそれぞれの処理を追加しましょう。
- ブランチを使わずにあるページからの処理を行おうとすると、都度、ページロードをする必要があり、
無駄なロードページステップが必要となり、処理にCPUや時間を要すことになります。
元のページ(トップページ等)をロードした後に、ブランチで処理を分岐することで、都度のロードが不要となります。(ブランチに処理が戻ると画面遷移などがブランチ時点の状態に戻ります。)