PowerAppsとPowerAutomateを使ってみた話

この一か月ほど、仕事のほうでちょこっとMicrosoft PowerAppsPowerAutomateを使っていましたので、感想などをメモしておきます。

数百レコード程度の小さなデータを扱う事務作業があり、これまでExcelを使っていました。
しかし、1レコードが40カラムくらいあり、カラムによっては複数行に渡るテキストも含まれています。
そのため、Excelで確認と更新は左右スクロールばかりを頻繁にすることになり、かなり不便でした。

PowerAppsを使うと、PowerPointで図形を配置するように、1レコード分の各フィールドを画面に見やすく配置できます。
もちろん、閲覧だけでなく検索やデータの編集も可能です。

そこで、このExcelのデータの確認・更新作業のUIをPowerAppsで試しに作成してみました。
イメージとしては下図のように、確認だけするデータが入ったTable1と、更新するデータが入ったTable2があり、それらを統合してPowerApps上で確認と更新を行います。
Table1のデータは、マスターは別のシステム上にある複数のデータをExportして切り貼りしたデータを使っていますので、Table2とは独立にしています。

PowerAppsは、要するにRADツールのWeb版です。RADツールと言えば昔はDelphiなどが有名でしたが、あんな感じでラベルやリスト、ボタン、編集フォームなどの各種コントロールが用意されており、イベントドリブンな形でアクションを定義することができます。

ただしPowerApps単体でアプリケーションを完結させるというよりは、PowerAutomateやDataverseと連携させ、フロントエンドに特化する感じです。
つまり、PowerAppsが処理する対象のデータは外部のソースから持ってくることが想定されています。
今回、Table1とTable2は、Office365のサービスであるSharePoint上のリストとして保持しています。

SharePointにおけるリストとは、イメージ的にはDBのテーブル相当です。
SharePoint自体は一種のCMSで、個別サイトを簡単に作成でき、個別サイト内でリストを持つことができるほか、サイト固有のリソース(SiteAsset)としてファイルを置いておくこともできます。
リストのデータをSharePointのサイト上で直接編集したり、データをCSVでExportすることも可能です。

PowerAppsとSharePointは連携するように設計されています。
今回は使いませんでしたが、リストを指定するとそのリストを閲覧編集するアプリを自動生成する機能がPowerAppsに用意されており、全くコードが書けなくてもリストを用意すればスマホ等からデータを入力するアプリが作れます。

PowerAppsにはSharePointに接続してリストにアクセスするための「コネクタ」が用意されています。
ですので上述のアプリではこれを使ってTable1やTable2にアクセスしています。
他にもOffice365のサービスであるOutlook、Teams、Excel Onlineなどのデータにもコネクタを通じてアクセスすることができます。

一方のPowerAutomateは、IFTTTのように、イベントが発生すると何かの処理(メールを送る、ファイルに書き込む、Teamsにポストする、等)を行わせることができます。もちろん、手動で起動したりPowerAppsから呼び出すこともできます。
また、PowerAutomateもOffice365の各種サービスが持つリソースへアクセスしたり、それらからのイベントを受け取ることができます。

今回、PowerAutomateは、複数のソースからTable1のデータを生成するために使ってみました。

しかし、この処理だけならいったんデータをダウンロードしてデスクトップでExcelを使った方が格段に速かったので、結局はこの部分はExcelに戻しました。

上の図の処理は、水色の列をキーとして、黄・ピンク・緑の列を取り出してTable1に格納するイメージですが、これを全行に渡ってループで処理しようとすると、PowerAutomateでは結構時間がかかります。
デフォルトではループの上限は100で、そういった大量の繰り返し処理はPowerAutomateではあまり想定していないとも考えられます。
もちろんこの上限数は一応変更可能ではありますが、それとは別にスクリプト全体でのタイムアウト制限もあり、やはりそもそも想定している用途は例えば、
「DBが1行更新されたら対応する処理を走らせる」
みたいなものではないかと思われます。

コーディングですが、PowerAppsとPowerAutomateは言語やデータ構造に共通性はありません。

まずPowerAppsですが、イベントハンドラやデータ処理はPower Fxという言語で書きます。プログラミング言語として一応の制御構造は備えています。ただしdo~untilやwhileのようなループはありません。ForAllという関数はありますが、これはPythonで言えばmapに相当する関数で、ループではありません。

Power Fxの解説にある以下の記述がこの言語のエッセンスを表していると思います。

Power Fx は、Excel と同様に宣言型の言語です。 作成者は動作を定義しますが、その実行方法とタイミングを決定し最適化するのはシステム次第です。 実際の作業では、ほとんどの作業は他に影響することなく関数によって実行されるため、Power Fx は機能的な言語であると言えます (Excel と同様)。

変数の扱い方には若干独特なところがあり、ローカル変数はContextというKey/Valueストア(Keyが変数名でValueが変数の値)で管理されているようです。JavaScriptのオブジェクトのようなものをイメージすると良いかもしれません。
PowerAppsのアプリケーションは複数のScreenを持つことができ、Screen単位で変数のスコープは独立しています(もちろんグローバル変数も持つことは可能)。
ローカル変数を更新する際には

UpdateContext({varName : newValue})

という形で記述します。「{}」で囲うというのが最初は忘れがちでした。

一方、PowerAutomateのうほうは、処理(「フロー」)をグラフィカルな言語・・・というか、はっきり言えばフローチャートみたいなもので表現します。
if-then-elseやforeachやtry-catch-finallyなどに相当する制御構造は用意されています。
データの扱いはやや独特で、こちらもデータとしてはJavaScriptのオブジェクトをイメージすると良いかもしれません。

処理の対象として与えるデータは、簡単なものならその処理より以前のステップの結果の中から所望のものをメニュー選択するだけで済みます。
が、中身がKey/Valueなので、特定の要素だけを取り出したい場合には、選択するだけでは済まずに

items('Apply_to_each2')?['VarName1']

みたいな記法で指定することになります。
ちなみに上は「’Apply_to_each2’の結果の中から’VarName1’の値を取り出したもの」みたいな意味になります。

さらにいろいろと面倒なのは、VarName1は上に書いたSharePointのリストのカラムを表したりするのですが、ここでカラムの名前には「内部名」と「外部名」があり、ここでは内部名を使わなければならず、それは外部名から自動生成されることが多いのだが、外部名が日本語だと16進数になってしまってで、内部名を調べる方法もなぜか公式には提供されておらず、ある操作をしてURLから読み取らなければならない・・・みたいなバッドノウハウがあるところです。

正直、初心者には扱うのが難しいし、普通にプログラミングができる人にとっては無駄に回りくどい部分が多いと思いました。
とはいえOffice365と一体で動作する独自の処理を作ることができるのは便利ではあります。逆にそれ以外の用途にあえて使う必要はないかもしれません。

全体的な感想としては、なかなか面白いプラットフォームだとは思いました。
昔、Webアプリケーションを作るのに「LAMP(Linux、Apache、MySQL、Perl)」があればOK、みたいに言われていましたが、オフィスで使うシステムはM365というOSの上で、SharePointとPowerAppsとPowerAutomateがあれば作れますよ、ということかと思います。

ただし開発したものの維持管理をしていくためのドキュメントの整備とかバージョン管理とかは難しそうなので、野良アプリになりがちなのではないかなという気はします。
ローコード、ノーコードだからといって、業務に使うものがそれでいいのかというと・・・まあケースバイケースかと。
ロジックが複雑でなく、最悪手作業に戻しても何とかなるような処理なら、それでいい場合も結構たくさんある気はします。

コメント