ワークブックの「範囲に書き込み」でExcelがおかしくなる？

日本 フォーラム
, ,
1

こんにちは、いつも勉強させて頂いております。

表題の通りなのですが、処理履歴的なExcelファイルを用意しておりまして、
Excelアプリケーションスコープを使わない方の「範囲に書き込み」アクティビティでExcelファイルに書き込みを行った後、
そのファイルに再度「範囲を読み込み」「範囲に書き込み」アクティビティで読み込み/書き込みに行くと、
System.Xml.XmlException：ルート要素が見つかりません。
という例外が発生するようになる事象が「まれに」発生します。(100回ほど実行して1回程度の再現率)
※UiPath.System.Activitiesバージョン：19.4.1

手動で(Office2010)そのファイルを開くとファイルが破損しているわけではなく、そのまま上書き保存するとまたワークブックアクティビティでの読み書きができるようになるのですが、
同様の事象を体験した事のある方はいらっしゃいますでしょうか？

2

余談：ちなみにワークブックアクティビティで読み書きができなくなっている状態のExcelファイルは
ファイルサイズが大きくなっている(普段50KB→180KB程度)という気になる事象がありました。
(開いて上書き保存するとまた元の小さいサイズに戻る)

3

Excelアプリケーションスコープを使わない方

を使った事がないです。

色々と事情がありそうですが、ExcelApplicationScopeでの実装を検討されてはいかがでしょう？
同じようなアクティビティでも、挙動が若干違うと聞いています。

4

ご回答ありがとうございます。

実はそのExcelファイルについては複数のロボットが共通で書き込む実行履歴になっていまして、
ネットワーク上に置いて、ロボットが実行されるたびに不定期のタイミングで書き込みが行われるため、
排他制御を行う目的でワークブックアクティビティの方を敢えて使っていたりします。
（Excelアプリケーションスコープだと、ロボットAがExcelファイルを開いてる間にロボットBが開こうとすると
例外スローと同時に別名Excelファイルが作成されてしまっていたので・・）

ワークブックアクティビティの動作信頼性がそもそも低い、とかであれば上記問題をクリアするロジックを実装したうえでExcelアクティビティに置き換えないといけないかなと思うのですが、
そこそこ改修が手間でワークフローも入り組んでしまうので、
事象の原因がわかってシンプルな対策が打てそうならワークブックアクティビティのままで行けないだろうかと企んでいる次第です。

5

そういう事情でしたか。。。

かつて、@cheez_RPAさんが、「排他的に、ログ出力するのだったら、CSVに吐き出して見ては？」って書き込みがあったような気がします。

もし「共通で書き込む実行履歴」がログ的な位置づけでしたら、その手も如何でしょう？１００回に１回コケるより、多少手間になっても安定した「実行履歴」をと思った訳です。

そのCSVでの実行履歴も、また別のロボットで収集、解析したりなんかして。。。