はじめに
この記事は FileMaker Advent Calendar 2019 20日めの記事です。
FileMaker 単独の記事とならずにすみません。
あと本題とあまり関係のない前置きポエム長めです。
その1。レイアウト編です。そしてその２があるかは不明です。
RPAとは
Robotic Process Automation の略でテクノロジーの1つとなります。
概念的なもので特定のツールや言語を指しているわけではありません。
詳細、RPAの良さなどについては各自ググってください。
今回のお題
今回は↓の図の黄色の枠の部分についてが主な話題です。
実現させるためにとりあえず3つの方法が浮かびます。
① RPAから人の手の操作と同じように FileMaker を操作する
② RPA用に既存システムを若干（？）改修する
③ RPAから Data API をたたく（②の要素がはいることもある）
今回の記事は②の**「RPA用に既存システムを若干（？）改修する」**がメインです。
RPA、デジタルレイバーの思想からは離れてしまうかもしれませんが。
FileMaker でやった方が早いのでは問題
RPAの良さの1つに開発スピードの速さがあります。
しかし FileMaker の良さでもあります。
既存システムを変更する必要がなく、そのまま操作できる点もRPAの良さと言われています。
そして FileMaker の場合は既存システムの改修を素早く行うことが可能です。
例えば
外部DBから複数レコードを登録する場合。
（登録後 FileMaker 側で設定されたID等を他DBへ返します。）
① RPAから人の手の操作と同じように FileMaker を操作する
RPA側でループして新規レコード追加してデータ入力。
② RPA用に既存システムを若干（？）改修する
RPA側でデータをcsv（等）出力。
FileMaker 側でインポート用のスクリプト作成、RPAで実行。
（RPA側はcsv作成までで以降は FileMaker での処理も浮かびますが今回は操作もします。）
##どちらで開発すべきか
判断基準は立場や状況に勿論よると思いますが私は主に下記をみています。
・安定性、運用しやすさ
・開発工数
・実行速度
・改修しやすさ
・処理、対応が必要な期間
・データが集約できるか
・開発リソース
###・処理、対応が必要な期間
処理・対応が一時的な場合、既に稼働しているシステムにむやみに組み込むものではないと考えます。もしくは分離させて開発すべきです。
###・データが集約できるか
本記事の内容とは逸れますが、RPA化しようとしている対象業務の中にはそもそも FileMaker に置き換えるべき内容もあります。FileMaker に限らず散らばるデータは集約できるよう業務そのものを変えていくことが理想だと思います。（いきなりでインパクトがある際などもRPAの活用タイミングだと思います。）
###・開発リソース
継続して開発リソースを確保できるかです。
FileMaker もRPAも属人化してしまうことは恐怖です。
ブームもあり今は人材面でいうとRPAエンジニアの人の方が出会いやすいです。（東京）
どうやってその判断すべきか
上記は FileMaker とRPAどちらも詳しい人であれば考えやすいかもですが、そういった人が多いわけではありません。RPAも FileMaker も割と何でもできる気がしますが適材適所もあります。 単独で判断せずに業務を改善するという目的で全体を見る人が必要です。また各担当者コミュニケーションをとっていくことも大事かと思います。
#本題
ようやくです。
今回利用しているRPAツール
SynchRoid（BizRobo!・Kofax Kapow）
・Design Studio 10.4.0.2
・DesktopAutomation 10.4.0.2
FileMaker
ProAdvanced 18.0.3
##RPAで操作しやすい FileMaker の開発、です
##・アカウント
RPA実行用を用意します。
アクセス権もRPAの運用にあわせて設定します。
##・レイアウト
コストに対してRPAの安定さや開発しやすさが段違いなのでこちらも新規で作成します。
OnFirstWindowOpen を利用して上記RPA用アカウントでログインされた場合に移動します。
テーブルオカレンスはレコードがふえていかないもの、グローバルフィールドだけのテーブルなど影響の少ないものを設定してください。
画面はとりあえずこんな感じです。こだわり必要なしです。
このレイアウトをスタートとしてスクリプト側で各レイアウトに飛んだり処理を行います。
##・ボタン
RPAツールによりボタンやフィールド、各オブジェクトの認識方法は異なります。
主に**「オブジェクト認識」「画像認識」「座標認識」**の3つにカテゴリわけされます。
###オブジェクト認識でみたFileMaker
SynchRoid の場合こんな感じです。
画面上でボタンを選ぶと下にどのオブジェクトを選んだのか枠で囲われます。
普段見ることのない FileMaker の中を見るのは新鮮です。
###ちなみに…
オブジェクトでの認識は一番認識の精度が高いと言われているものです。
FileMaker のボタンを認識してくれてよかったです。
しかし。
画面下部でユニークのように見える [automationId="Button: 3810"] というID。
こちらはレイアウトを保存するたびに更新されます。
なので [name="ボタン１"] を指定しています。
こちらはレイアウト上のボタンの文字になります。なのでユニークではない場合もありますね…。レイアウトを変更しやすいのは FileMaker のメリットですが、ゆえの懸念点もあり専用のレイアウトを作ってしまうべきです。
###画像認識でみたFileMaker（予想
個性的カラーで差をつけろ！
…すみませんオブジェクト認識派（？）なので予想です。
ボタンの位置を変えても認識してくれることは確認しました。
画像の認識の仕方について、ツールによって判別の仕方が違います。ボタンの周りとの位置関係をみるものや、ボタン内の文字を識別するものなど。また誤差をどこまで許容するか設定できるツールなどもあります。各ツールの特徴に合わせて認識しやすいボタンをデザインするのもありかもしれません。
すごい余談
よくわからないニコチャンマークは Excel の図形を利用しました。
Excel で図形編集をしてそのまま FileMaker のレイアウトにはりつけられることは私の開発人生の中でかなりの衝撃でした。
実際のところ
安定性を大事にしたいので自分であれば FileMaker 側でカスタムメニューのショートカットの設定を行い Press key のステップを利用します。
###座標認識でみたFileMaker（予想
こちらも知見ほぼなく予想です。
最初に ウインドウの調整 でY軸とX軸は固定させるとかでしょうか。
こちらも実際のところショートカットでの操作になりそうです。
###安定性をつきつめていくと…？
Data API をつかえばいいのでは
ショートカットで各フィールドにはいり、
スクリプト名をはりつけ スクリプト実行 を 指定：名前で とかいかがでしょうか。
…すみませんこれも妄想です。
スクリプト名をRPA側で管理しないといけないのが現実的ではないかな、と思います。
ツール側で制限がある場合などの最終手段用です。
なにが最適なのか
色々な方法があるので判断が難しいですね…。
FileMaker 側をこだわることは出来ますが本末転倒にならないように気をつけたいです。
おわりに
レイアウト編、終わりです。
次はスクリプト編の予定です。（？）
FileMaker とRPAを絡めるとたくさんの可能性があると思います。
元々FileMaker を利用していた業務も勿論なのですが、RPA化したいと言われている業務にFileMaker を組み合わせたり、色々なことができます！
楽しいです
そして Claris Connect 楽しみです！！
そしてそして添削ありがとうございます！！
心配だったので複数の人に添削してもらいました…。
お時間いただきすみません。皆さん丁寧に本当にありがとうございます。
そして宣伝 
Discord の「FileMaker Casual」というユーザーのコミュニティチャットに参加しています。
@Hi_Noguchi さんが主催されています。
雑談などもありたのしいです。皆様ぜひ！