【UiPath】エンティティレコードの更新を実装する

Data Serviceにてこんな感じでエンティティを作ったとします。

• エンティティ名：社員別勤怠情報（AttendanceInfo）
• 主キー：社員番号（EmployeeNum）

Appsでエンティティのデータを作成し、その作成したデータに対して更新をかけたいとき、どうしたらええんや？？ってなったので備忘録として残しておきます。

データは↓のような感じで入っているとします。

社員番号：10000のデータに対して更新をかけることにしましょう。

App Studioで作成中のアプリの編集画面 > 任意のコントロールからイベントルール設定画面へ

ルール一覧から値を設定を選択

社員番号：10000のデータを格納するための変数を作成する。

任意の変数名（Listと分かる名前が良い）をつけ、型はListSource / * AttendanceInfo

社員別勤怠情報（AttendanceInfo）のリストを格納する変数を作るというわけですね。

値の入力欄右のアイコンをクリックすると、クエリビルダーというよく分からぬメニューが出てくるのでクリックします。

画面上部のプルダウンからはデータ検索対象のエンティティを選択できます。迷わず社員別勤怠情報（AttendanceInfo）を選択。

そのすぐ下で検索条件を入力します。

つまりクエリビルダーとは、エンティティからデータ検索するための条件を分かりやすく設定するための機能なんですね。

今回は社員番号（EmployeeNum）=10000

という条件に合致するデータを引っ張り出すことにします。

条件を保存してクエリビルダーを閉じると、値の欄に何やら長い関数っぽいものが入っていることが分かります。クエリビルダーを使わずにこんな式を手打ちで入れるのは不可能ですね。おとなしくクエリビルダーを使いましょう^^;

値を設定ルールを定義した後は、エンティティレコードを更新ルールを定義していきます。

レコードを更新するエンティティを選択します。今回は社員別勤怠情報（AttendanceInfo）です。

その下の欄、エンティティレコードID？？ん？？？ってなると思いますw

社員別勤怠情報（AttendanceInfo）のデータのキャプチャを改めて見てもらいたいのですが、一番左にIdというフィールドがあったかと思います。アレです。

主キーとは別に、データを一意に特定するためのIdを各データごとに持っているというわけですね。

このIdを取る方法は色々あるのですが、今回はList_empに格納されているデータが1件になる前提で、List_emp.data.First.Idと入力しておきましょう。

List_empのデータリストのうち、一番最初のデータのIdという意味になります。

あとは更新したいフィールドの値を設定して終わりです。

• 社員別勤怠情報（AttendanceInfo）のリストを格納する変数を作る
• クエリビルダーでデータ検索条件を定義する
• エンティティレコードIDの取り方を定義する

部分がつまづきやすいポイントかなと思います。

勉強なんてしたくない

ITエンジニアという仕事は日々勉強とよく言われますが、僕は昔から本当に勉強が苦手です。でも一応新卒から10年ほどはITエンジニアとして飯を食うことができています。

自分としては何でこんなに続いてるんだろうと思ってるし、適性もたぶんない。

ITスキル以外のところで辛うじて食いつないでいるような気もせんでもない。資格のための勉強なんてまるでやってないし、怠惰の極みだと思ってますw

思うに、僕の中で"勉強"と思っていない瞬間に実は勉強をしているのではないか、と。

僕が思う勉強というのは、本を開いてマーカー引いたりして頭に叩き込む、みたいなことをイメージしています。

でもたぶん僕はそのスタイルは全然相性が良くなくて、てんで頭に入ってこない。記憶力が悪いのもあるけど、なんというか、実体が伴わないから理解が進まないという表現が近い気がします。

目の前でパケット通信の仕組みが映像として流れるわけでもない。DBのテーブルにインデックス張ると何でパフォーマンスが上がるのか、理屈は分かってもその証拠を目の前で確認していないから納得まではできない。

つまり、本を読むだけではダメで、実際にそうなるんだということを身をもって体感しないと学習しないんですね。実際にPCで"可視化できる何か"を用意して試してみる、とか。

本だけの説明で分かった気になって、それを他の人に同じようにレクチャーするのはホントに無理で、受け売りができない。自分が体感しないと自信を持って伝えられない。

学生の時は数学がホントに苦手でした。今でこそPCで数式をグラフなどでシミュレーションすれば腹落ちするかもしれないけど、当時は教科書を読む、書いてみるくらいしか勉強の仕方を知らなかったから、全然理解が進みませんでした。

今やってるRPAの開発の仕事は、実際に疑問に思ったらロボット作って試してみたらスパッと納得できることが多いので、理屈だけで終わらず"体感"を通じて理解できています。

理屈を"可視化"するコンテンツを自分で用意して"体得"していく。

文字情報だけでは分かった気になりやすいので、"体感"を通じて"体得"する、という意識で学習に取り組むといいんだろうなーと思っています。

【RPA】UiPath学びなおしてみた

RPAをやっている人なら誰でも知っているであろうUiPathをここ最近触ってます。

2019年にJapan MVPを頂いたものの、それから不幸にも別の仕事の関係で触る時間が取れず、4年ぶりにUiPath絡みのお仕事を頂いたのをきっかけに再び触れることになりました。

まずAutomation Cloudの構造。Appsてローコードツールよね？

ふむふむ、Data Serviceと連携したら面白いことができそう。エンティティ更新したらまた登録し直しなの？イベントルール設定ちょっとコツいるな、ぐぬぬ。Ochestratorにデプロイできない？？あ、アプリのバージョン？権限ついてるユーザーじゃないと無理なんや。そんなん分からんてw

StudioX。これか、エンジニアじゃない人でも簡単にプロセス作れるっちゅうやつやね。どれどれ。ん、これデバッグできない以外ほとんどストゥーディオと変わらんくない？でもExcel関係のアクティビティはめっちゃ使いやすい。ブラウザの画面要素取るのも昔よりずっと簡単になってる（気がする）。

Task Capture。画像加工ツールとして優秀。他の機能は…見なかったことにします←

…と、ゴニョゴニョと1～2週間くらいいじってみました。

ユーザーフレンドリーなインターフェイス、いざというときは力技も使える（という意味ではある意味ハイスペック）ところは変わっていない。とっつきやすさ、スケールアップに耐えられる機能と製品群を考えると、確かに人気なのは分かるなーといった感じです。

まだまだ改良の余地もいっぱいあるけれど、現時点で足らない部分はkintoneとかマニュアル作成支援ツールなどを組み合わせていけば良さげ。全部を一つのツールで賄おうとしないのが得策かなーと思いますね^^;