ローカルで作ったBizRoboがサーバーで動かない……
開発環境と実行環境を合わせるのはセオリーですが、ユーザー主導で作成するRPAはなかなかうまくいかないものです。
ユーザー環境でデバックして動かないケースで、疑うべきところをあげておきます。
これは経験したトラブルシューティングなので、コメントでこういうケースもあるよというご意見大募集です。
Management ConsoleでBizRoboがうまく動かない
hostsって登録してあります？
BizRoboで既存のマクロをキックするというのはよくある話ですが、開発環境では既に設定されているものがサーバーでは未設定だというのはありがちなはなし。
そんななかにではhostsが登録されていなくて、マクロが動かないってのはよくあります。
実行時にエラーが出てくれるので発見しやすいのですが、移行時のチェックシートに入れておけばポカがへらせますね。
tnsoraって登録してあります？
上記に通じるところですが、マクロがDBアクセスしてデータをぶっこ抜いてそれに対して処理するっていうのは割とありがち。
まあ統制上よろしくないマクロも実務に組み込んであると、システム監査をするりとすり抜けてゾンビのように生きながらえるもの。
そういうマクロをキックするときにはちゃんとtnsoraに接続情報を記述しておかないとエラーになります。
これも、発見しやすい部類ですが、チェックシートで事前に抑えておきたいもの。
導入初期にはそもそもOracleクライアントが入っていないじゃんというケースも……
テラタームマクロちゃんと紐づけてます？ てか、テラターム入ってましたっけ？
UNIX系に対して操作を自動化するのにテラタームマクロはほんと重宝します。
が、あくまでディベロッパー側がサーバーに対して操作をするケースの方が多いはず。
RPA実行サーバーから、他のサーバーに対してテラタームでデータをゲットしてその後の処理をするマクロやオペレーションも割とあるはず。
テラタームマクロで取得するデータがなくて空ぶってエラーになるか、ないケースも想定してエラーが見つけにくくなるケースもあるでしょう。
やはりサーバーには実行環境と同じアプリが入っているか確認するような調査や移行時のチェックシートで押さえておきたいですね。
そもそもExcelマクロが実施できない
結構はまったのが、諸々設定値のお膳立てを済ませて開発環境で実行できたRoboがサーバー環境だと実行されずにエラーを吐かないというケースでした。
設定関係を洗ったりごにょごにょしましたが、結論としてサーバーで対象のExcelを開いたときに保護ビューになっていました。
保護ビュー解除のためにもろもろ設定替えましたが、結局xlsmに変更しました。（参照しているユーザーに配慮しつつ）
そうしたらはまっていた個所が嘘のようにごりっと動きました。
結論：実行環境でまず、現状の作業を再現をすれば高速導入できる
慎重を期すあまり、不要なトラブルシューティングにはまるのは、この時代のスピード感にあいません。
IT業界はITバブルのころにいい加減な仕事をしていた輩のせいでISOの呪縛にかかっています。
もちろん、統制は必要なことは理解していますが、経営の求めるスピード感に現状で追随するのは難しいもの。
都内で働いていた時は当たり前に思っていましたが、地方では開発環境と実行環境がイコールな現場は恵まれたところです。
限られた予算の中では暫定開発環境で開発し、開発完了後、暫定環境を本番化するという恐ろしい現場もあり、
そのような現場では開発ってどうしたらいいのよと、個別環境開発→本番である意味オンするためのデバッグという羽目になるという統制もくそもない状況に陥りがち（自分
とりあえず、タイミングをみて本番環境を借りて手でユーザー作業を再現して問題を洗い出すのがスムーズに本番移行するための調査かなと。
書いていてさみしい気持ちになりました。
ちゃんとした環境で開発したいものです。
