MoreBeerMorePower

Power Platform中心だけど、ノーコード/ローコード系を書いてます。

LogicFlow-ja online #4 参加メモ

2020/11/28に開催された「LogicFlow-ja online #4」に参加しましたので、そのときのメモです。

発表資料は随時更新します。

登壇者一覧

タイトル 発表者
[Logic Apps]ボット開発ツールがなくても、世の中のボットは全部 Logic Apps で作れると思ってたんだ。 小玉 純一
[Power Automate]Power Automate×Windowsイベントログで働きすぎをチェックする! hikari
[Power Automate]今日から始めるPower Automate 吉田 大貴
[Power Automate]ERP屋がCDS改めMicrosoft DataverseとPower Automateを使ってWorkflowを組んでみる 河村 新一
[Power Automate]Project Oakdale 環境からテプラ印刷ができるのか試してみた! りなたむ
[Logic Apps]Logic Appsならではの機能って何がある? 小尾 智之

ボット開発ツールがなくても、世の中のボットは全部 Logic Apps で作れると思ってたんだ。

※ブログはこちら

Power Automate×Windowsイベントログで働きすぎをチェックする - オンプレ系インフラエンジニアがAzureを勉強する

f:id:mofumofu_dance:20201128125903p:plain

Botは「XXXXされたらYYYYする」という処理なのでLogic AppsやPower Automate の得意とするところだから、だいたい作れるんじゃないかなと思っていたけど、実際作ってみて躓いたところのお話、得意不得意なBotのタイプというお話でした。

作ったBotは「後出しで必ず勝つBot」これをLogic Appsで作る実演でした。

f:id:mofumofu_dance:20201128130726p:plain

※今回はLogic Appsを使っているのは、Power AutomateだとHTTPアクションがプレミアムコネクタであるため。

単純なやりとりだけなら基本のスイッチアクションで分岐にできるけど、自然な会話にするためには前に何を会話していたか"文脈"を覚えさせないといけない。

f:id:mofumofu_dance:20201128131202p:plain

これを実現するために外部のデータソース(ここではSharePoint リスト)に会話の状態を記録しておいてます。

また、会話する相手が複数であればその数だけ状態を保持する必要があります。

f:id:mofumofu_dance:20201128131708p:plain

f:id:mofumofu_dance:20201128133343p:plain

Logic Apps/Power Automateで作りやすいBotと作りにくいBotの違いは「ステートレス」か「ステートフル」かの違い。

f:id:mofumofu_dance:20201128133952p:plain

ステートフルなBotであれば、Botツールを利用するのがいいかもということでした!

f:id:mofumofu_dance:20201128134031p:plain

Power Automate×Windowsイベントログで働きすぎをチェックする!

f:id:mofumofu_dance:20201128135024p:plain

テレワーク中の課題の中でも「見えないことでの働きすぎ」に陥らないための仕組みづくりのお話です。シャドウ残業対策!

f:id:mofumofu_dance:20201128135524p:plain

「自己申告」制の勤怠申請はオーバーワークを抑えられないのでは?

f:id:mofumofu_dance:20201128135940p:plain

IT関連ならPCの稼働時間=その人の稼働時間 (の目安) になるから、そこから勤怠時間を計算してオーバーがないかをチェック&マネージャーに注意喚起という仕組みです。

あくまでも働きすぎてそうな人を把握してコミュニケーションのきっかけにするという気づきづくり。

f:id:mofumofu_dance:20201128135956p:plain

Windowsのイベントログは、今回はスリープとスリープからの復帰を対象。取得する情報はイベントの時間とID。このコマンド1行でほしい情報だけが取得できる。

f:id:mofumofu_dance:20201128140441p:plain

あとはこのイベントログからOffice Scriptsで稼働時間の計算していけばOK。

f:id:mofumofu_dance:20201128140902p:plain

Office ScriptsはExcelを操作を記録してTypeScriptに変換してくれるので、いきなりコードかけなくても始めやすいですね。

f:id:mofumofu_dance:20201128141745p:plain

あとはイベントログの生成をトリガーにして、Offce Scriptsを実行するアクション、最後に超過があればTeamsへのメッセージというフローになっています。

Power Automateは数字の合計をする関数が用意されていないので、Office Scripts使うってのは素晴らしいっすね。

f:id:mofumofu_dance:20201128141932p:plain

ローカルの情報取得からクラウドのワークフロー実行をトリガーするってのはナイスアイデアだなーと思いました。応用の幅も広そう!

f:id:mofumofu_dance:20201128142753p:plain f:id:mofumofu_dance:20201128143015p:plain

Project Oakdale 環境からテプラ印刷ができるのか試してみた!

f:id:mofumofu_dance:20201128144003p:plain

以前作成したLINEボットとUI Flowsを利用して、テプラからラベル印刷をする仕組みを、Dataverse for Teamsでできるか試す!という内容です。

まずはPower Automate Desktop (PAD) がリリースされたことを受けて、まずはUI Flowsでやっていた処理をPADに移行するデモ。 Windowsのアプリケーションの操作記録をとったものがそのまま自動化になっている!(受け渡す値の修正は必要)

f:id:mofumofu_dance:20201128144655p:plain

f:id:mofumofu_dance:20201128145048p:plain

デモ成功!実際のPADの処理構成図は下図のような形

f:id:mofumofu_dance:20201128145413p:plain

続いて、Dataverse for Teamsの環境で、Teams用に限って標準ライセンスの範囲で利用可能なPower Virtual Agents を使う&外部サービスを実行するデモ。

ここではText Analyticsを利用していました。

f:id:mofumofu_dance:20201128145824p:plain

ただ注意もあって、一部コネクターはサポートされていなかったり、PVAで使うフローはPVAからしか触れなかったりという制限もあります。

f:id:mofumofu_dance:20201128150356p:plain

最後、PVAからPADを呼び出す部分は、そのままだと作れない!HTTPでほかのフローを呼べばいいかと思いきや、プレミアムなのでライセンスを要求される・・・

f:id:mofumofu_dance:20201128150907p:plain

まとめと注意事項です。Dataverse for Teamsでかなりできることは広がるけど、注意も必要ですね。うまく活用していきましょー。

f:id:mofumofu_dance:20201128150925p:plain

ERP屋がCDS改めMicrosoft DataverseとPower Automateを使ってWorkflowを組んでみる

f:id:mofumofu_dance:20201128152133p:plain

各種申請の承認ワークフローをDataverseとPowerAutomateで作っていく際の考え方と悩んだ部分をご紹介いただきました。

たしかに承認階層の持ち方やルートってどうするのがいいのか気になりますよね。

f:id:mofumofu_dance:20201128152250p:plain

承認者のデータ型をメール型にするのがワークフロー側としては素直で扱いやすいけど、フォームからは上長のメールアドレスを入力しなきゃいけない・・・。

f:id:mofumofu_dance:20201128152826p:plain

→ユーザーID型を使えばフォームではサジェストしてくれる→あとはDataverseのユーザーテーブルからフィルター取得してメールアドレスを得ればフォーム側もワークフロー側も使いやすくなる

f:id:mofumofu_dance:20201128153054p:plain

次はN段階の稟議申請のような承認フロー。承認者の職位や承認依頼内容によってもフロー(承認段階および承認者)は変わる、またはこれらのハイブリッドになる。

f:id:mofumofu_dance:20201128154130p:plain

f:id:mofumofu_dance:20201128154335p:plain

じゃあこういう可変な承認ルートをどうやって決めるのか。

まず固定の承認ルートなら、各承認文書に対して承認ステップごとの明細を作成。明細の単位で承認アクションを作成して、フローを実行する。

f:id:mofumofu_dance:20201128155034p:plain

明細の生成はテンプレートから文書の種類別に生成している。

f:id:mofumofu_dance:20201128155705p:plain

承認ルートの生成部分はすごくいいですね、テンプレートを決めておいてあとは発生したイベントに応じて実際のレコードを作成していく。 これは承認だけでなくほかの処理でも使えそうです。

ハイブリッドN段階も基本的にはこれでいけるのだろうか???(登壇はここまででした)

今日から始めるPower Automate

f:id:mofumofu_dance:20201128164859p:plain

Power Automateは400以上のコネクターとDataverseを活用してとにかくいろんなことができます!

f:id:mofumofu_dance:20201128161319p:plain

フローの3つの要素、「トリガー」「アクション」「条件分岐」

まずはトリガーは3パターン。(大別すると3つ、各サービスでそれぞれ複数個のトリガーを持っている)

f:id:mofumofu_dance:20201128161513p:plain

アクションは4000個くらい。これにプラス条件分岐を加えて、フローの基本構成になる。

f:id:mofumofu_dance:20201128161652p:plain

(簡単な) Microsoft 365との連携から「ガチな」使い方まで幅広くフローを作れる(使える)

f:id:mofumofu_dance:20201128162012p:plain

まず標準コネクターがあればコネクターを使う→ない場合はカスタムコネクターを検討→それでもダメなら RPA 機能。

f:id:mofumofu_dance:20201128162145p:plain

標準的なワークフローだけでなく、AI Builderを活用することでさらに高度な自動化も可能。紙をスキャンしたデータからフローを実行することも可能。

f:id:mofumofu_dance:20201128162636p:plain

このような多様な自動化・効率化をつかって,細かい業務改善を積み上げていける。

f:id:mofumofu_dance:20201128163232p:plain

もし相手がレガシーなシステムだとしてもRPA機能で自動化できる。Power AutomateはRPAではないので、RPAもコネクターの中の1つに含まれていて、RPAも含めた統合的なワークフローを作成できる。

f:id:mofumofu_dance:20201128162819p:plain

デモではFormsの入力をトリガーにしてRPA機能でContosoさんのシステムにデータを登録するところまでを紹介いただきました。

f:id:mofumofu_dance:20201128164653p:plain

そして!特報!吉田さんの大作が近日公開されます!

f:id:mofumofu_dance:20201128165202p:plain

Logic Appsならではの機能って何がある?

まずはLogic AppsとPower Automateの特徴と使い分けから。ターゲットとして想定されている業務とユーザーが違いますね。

f:id:mofumofu_dance:20201128170540p:plain

f:id:mofumofu_dance:20201128170609p:plain

Power Automateは独自発展している部分もあるので1:1で完全に対応しているわけではない。

f:id:mofumofu_dance:20201128170803p:plain

超大事な仕様と制限事項。これもどちらを使うかで考慮しなければならないポイントですね。

f:id:mofumofu_dance:20201128171128p:plain

Logic AppsとPower Automateの固有コネクター。色分けで見やすい!

f:id:mofumofu_dance:20201128172019p:plain

便利だけど、モジュール追加できないInline CodeなどもLogic Appsに固有です、

f:id:mofumofu_dance:20201128172152p:plain

まとめて処理(Batch)アクション。1週間に一回それまでのイベントをまとめて対象にして実行みたいなときに便利。

f:id:mofumofu_dance:20201128172329p:plain

データベースの容量足りないというアラートが出たら、拡張する!みたいなことも、Azure Monitorと組み合わせ可能なLogic Appsなら自動処理できる。

f:id:mofumofu_dance:20201128173150p:plain

Azure Policyをサブスクリプション、リソースグループに適用することで、Logic Apps作成時のDLP対応ができる。

f:id:mofumofu_dance:20201128173549p:plain

固有機能を使いたければそれぞれ使っていこう。Azureとの連携がLogic Appsの売りでもあるので、そういう場合はLogic Apps。 Logic AppsのAPIはドキュメントもあるので、外からLogic Appsにアクセスしたい場合にはREST APIを使ってみましょう!

Azure ロジック アプリ REST API | Microsoft Docs

f:id:mofumofu_dance:20201128174326p:plain

おわり

今回も基本、応用、もう少し硬い「Logic Appsとは」という話もあって改めてPower Automate/Logic Apps が作り出すものの多様性を感じることができる勉強会でした。

後日勉強会の動画もアップされると思いますので、そちらをスルメのごとく繰り返し見ると、だいぶPower Automate/Logic Appsと仲良くなれるのではないかなと思います。

運営、登壇者の皆様ありがとうございました!