[BluePrism]スケジュール実行時「Could not identify process owning the current foreground window」システム例外がスローされる

#このシステム例外が出るとき
- プロセスを、今自分がログインしているのでない他のRRを指定して実行する場合
- 複数のユーザが同一のデスクトップにログインして使用しようとする場合

で、なんらかのアプリをアクティベートしようとしたときに出ることがあるようです。
※画像認識でしか操作できないようなアプリや、Microsoft Accessのアプリなどで事象発生した例がありますが、その種類がこの事象となんか関係があるかどうかはわかんないです……

> Could not identify process owning the current foreground window

というメッセージを見ると、
Blue Prismが、OSに現在のフォアグラウンドプロセスウィンドウの情報を要求したのに、OSから適切な情報が貰えない（どれがお前のフォアグラウンドか区別がつけられないと言われたとか）というエラーのようです……（たぶん）。

#実行モードをどうにかするとなんとかなるのではないか、という案
※実行モード関係ないという意見もあります、一案として


- オブジェクトの実行モードを「フォアグランド」に変更する。  

	- オブジェクトの「Initialise」の看板みたいなやつをダブルクリックして開く。
![Initialise.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/142092/d1a5717c-3fc4-cb6d-d53e-7a5e0cfd1267.png)


	- 「情報は保存されました。ありがとう！」タブの「実行モード」
	- デフォルトでは「Exclusive」（日本語版6.4までは「独自技術」、6.5以降は「排他」と表示されているようです）を「フォアグランド」に変更する。
![実行モード.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/142092/b88e16c6-1102-ffb7-dcc4-acccac0d794f.png)


#RRの設定や扱い方について
- RRには、 起動後に一度もRDP接続していない状態で、Login Agentで、スケジュール実行でログインする。

	- Login Agent時に、確実にコンソールセッションにするため。
Login時にリモートセッションが使われると、Log Out後にAPサーバが管理する状態と、実際のWindowsのログイン状態に不整合が起きる可能性がある。

	- RDP接続後にサインアウトするとセッションは終了するが、念のためにRRを再起動して、「起動後に一度もRDP接続していない状態」を保っておくことにするほうが、運用として確実だし楽と思う。

	[「Login Agent」とは何か、という説明と、その使い方（神谷町RPAブログ）](https://www.ebocean.work/entry/2019/10/07/202750)

- Login AgentのLogin時に実行されるbatファイル（RRを起動する）を、Windowsのタスクスケジューラでなく、スタートアップフォルダにbatファイルへのショートカットを置くようにする。

#試してみる、もしくはチェックするべきポイント
- Attachした要素をアクティベートする方法は複数ある。状況や要素の取り方によりどれが有効というのは異なるため、いろいろな方法を試してどれが当該のケースで一番有効かを確かめる。
	- Activate
	- Focus
	- Verufy
	- Maximize→restore→maximize
	
	など

 
- Attach後に数秒sleepすることが有効はなアプリもある。
- アプリケーションモデラーで要素を取得するとき、Screen VisibleとVisibleをOFFにしてみる。
- Window要素のwin32で取得した要素はActivateがうまくいかない場合も少なくないらしい。復元→catchを繰り返して対処。

 
- 失敗しやすいという報告が多いアプリ（これも環境とか状況によると思うけど）
	- SAP
	- Accessアプリ（Accessは極力OLEDBのVBOで直接データを扱うことを推奨）
	- Excelフォーム（これも直接データを扱うほうがいい）

 
- RRの電源とスリープの設定→画面の設定で、「次の時間が経過後、ディスプレイの電源を切る」のところが「なし」以外に設定されていたら、「なし」にする（実際RRに画面が接続されていなくてもここの設定は確認することをおすすめします）
![電源の設定スクショ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/142092/994a1799-adff-7978-58ce-ae1734309aff.png)


 

#いろんな人に教えてもらった関連する記事
※Blue Prismポータルのリンクはポータルに登録したら読めると思う

- [Why do I get error "Could not identify process owning the current foreground window" when trying to focus an application?](https://portal.blueprism.com/customer-support/support-center#/path/Automation-Design/Studio/Process-Design/1137420332/Why-do-I-get-error-Could-not-identify-process-owning-the-current-foreground-window-when-trying-to-focus-an-application.htm)

- [コントロールルームでランタイムリソースを「接続済み」と表示できるのに、スケジュールされたタスクの実行に失敗するのはなぜですか？](http://help-jp.blueprism.com/Installation-Platform/Configuration/Connections/1392011612/)

- [アプリケーションをフォーカスしようとした時に表示される "Could not identify process owning the current foreground window" というメッセージはなんですか？](http://help-jp.blueprism.com/Automation-Design/Studio/Process-Design/1195583602/)

- [Screen flickers every 17 seconds - Desktop Window Manager (dwm.exe)](https://www.tenforums.com/general-support/128876-screen-flickers-every-17-seconds-desktop-window-manager-dwm-exe.html)


	これは、 [「Windows To Go」は終了へ ～「May 2019 Update」で削除・置き換え予定の機能が発表](https://forest.watch.impress.co.jp/docs/news/1186304.html)　に記載されている、リモートディスプレイドライバが1903からXDDMが廃止されWDDMのみを使用するように変わったことによるもののようです。
このチラつき周期に画面の認識がかぶってしまうと、うまく認識できないのではないか、という推測です。
リンク先の投稿によれば、このレジストリを設定変更（XDDMを使用することを強制するようにする）すればチラつきはなくなるとのことですが、公式情報ではないので自己責任で……。
HKLM \ SOFTWARE \ Policies \ Microsoft \ Windows NT \ Terminal Services \ fEnableWddmDriver DWORD 0

- [MS Access に接続する方法（やっぱりOLEDBを使えってことのようです）](http://help-jp.blueprism.com/Automation-Design/Studio/Visual-Business-Objects/1195582672/MS-Access-%e3%81%ab%e6%8e%a5%e7%b6%9a%e3%81%99%e3%82%8b%e6%96%b9%e6%b3%95.htm)



#終わりです
これで一応動いたので書きましたが、正直、実行モード3個あってどれがどう違うのかとか、リソースに割り当てた後に仮想のデスクトップで何がどうなってるのかとか、これでほんとに大丈夫なのかとか、マジでわかってません。
教えてください。ありがとうございます。