Power Apps Blog アップデート。 複数テーブル参照がプレビューになったよ。

最新情報のキャッチアップと、英語のお勉強兼ねて、できる時はPower Platform関連の公式ブログなど各種情報を翻訳してみようと思います。

いつまで続くかわからないけれど。

英語力についてはお察しだし、あくまで自分の備忘用というスタンスなので、もし参照されるとしても、参考程度でお願いします。

内容には一切責任を持ちませんので...

(間違いなど指摘してくださる方がおられましたらありがたいです)

では今回の内容に移っていきます。

元記事はこちら。

https://powerapps.microsoft.com/ja-jp/blog/category/new-features/

ここから翻訳です。

Multi-table lookups, a long awaited and much requested feature, are now live (Preview) for use via API.

待望の、リクエストの特に多かったマルチテーブル参照がAPIから利用可能になりました(プレビュー)。

Multi-table lookups (also sometimes known as polymorphic lookups) allow the creation of a lookup in one table that looks up records in multiple other tables at once.

マルチテーブル参照(ポリモーフイック参照としても知られる)は、複数の他のテーブルから一括してレコード参照しているテーブルに参照をかけられるようにできます。

This provides much greater flexibility in retrieving data within your environments.

これはあなたの環境からデータを引き出す際にさらに大きな自由度をあたえてくれます。

Imagine you are trying to create a lookup that lets you check out media to users.

ユーザーにメディアを見てもらうための参照を作ろうとしていると想像してみて下さい。

You have a table of Books, a table of Audio offerings, and a table of Video offerings.

本の情報、音声、ビデオを提供するテーブルがあるとします。

Prior to this, there was no easy way to create a lookup that would pull data from all three tables at once, and you may end up with three separate lookups:

Checkout-> Books
Checkout-> Audio
Checkout-> Video

この機能が出る以前なら、３つ全てのテーブルから一度にデータを引き出す参照を作る単純な方法は無く、本、音声、ビデオそれぞれ個別の参照をするしか仕方がなかったでしょう。

What if you were searching for both the physical book and audio book for a title you wanted? 

気になるタイトルを、本とオーディオブック両方探す場合はどうでしょう。

What if you wanted to find the soundtrack to a movie and a movie?

映画と、そのサントラを探したい場合はどうでしょう？

What if a friend recommended a movie to you but also said the book was great?

友人が映画を勧めてくれ、本も良かったと言っていた場合、どうでしょう？

Looking this data up across multiple tables would require individual lookups, require you to search and populate shared IDs into your checkout table, or write a custom solution.

こういったデータを複数のテーブルを横断して見つける場合、個別の参照と検索が必要で、参照するテーブルには共通するIDを設定するか、カスタムソリューション(フローなどかな？)を記述する必要があります。

With multi-table lookups, you can perform a lookup on 2 or more tables at the same time and locate the record you want from the referenced tables.

複数テーブル参照を使えば、二つ以上のテーブルを一度に参照し、参照したテーブルから対象のレコードを見つけることができます。

These lookups are all  1 to many relationships and will work in a similar way as the Customer lookup that is built into Dataverse, where Customer look ups search both Account and Contact.

これらの参照は全て、一対多のリレーションで、Dataverseに実装された、アカウントとコンタクト両方を検索するカスタマー参照と同様に動作します。

Using these multi-table lookups can reduce development time for your apps and provide a more streamlined user interface.

これらの複数テーブル参照はアプリ開発の時間を削減し、より効率的なUIを提供します。

For the current preview:

Lookups can be constructed and managed through API only
Model driven apps currently provide the best experience with the lookups
Maker UI support for creation and management is coming soon, and improved canvas app support is planned for the future.

現在のプレビューでは、

・参照の構築と管理はAPI経由のみ。

・いまのところ、この参照はモデル駆動型アプリでの体験がオススメです。

・構築と管理における開発者UIサポートは近いうちにリリースです、キャンバスアプリへのサポートも予定されています。

おわりに

訳は以上となります。

複数のテーブルから情報を一括で取って来れるのは便利そうですね！

まだモデル駆動型には手を出していないので、今後のキャンバスへの展開を期待しています♪

Power AppsでSharePoint Listに写真を登録

日々の忙しさにかまけて、ずーっとblogをほったらかしにしてしまっていたが、少し余裕も出てきたので、再開してみました。
アウトプットは基本は自分の備忘録だけど、人に見られるかも、というプレッシャーがある程度かかるので、それなりにちゃんとしたことを書かないといけない、という意識が働くのがいいとこなのだと思う。
できるだけモチベ保って、週1回は更新できるように頑張ろう。

今回のお勉強内容

前置きはさておいて、今回はPower Appsのお勉強。
Power AppsからShare Pointに画像登録、表示するのはいくつかやり方があるけど、今回は添付ファイルコントロールを使用した画像登録のやり方を学んでみた。
まだまだ初学者なので、写経するのが一番勉強になります。
参考にさせていただいたのはコチラ。

www.youtube.com

Rezaさんはyoutubeに沢山動画をアップされていて、どれも素晴らしいアイデア満載なので、最近はずーっと追いかけて勉強させてもらっています。
え、こんなこともできるの！？っていつも驚いてばかり。
そして解説が理路整然としてめちゃくちゃわかりやすいです。

作ったもの

参考にして(ほぼ丸パクリ+ちょっとだけアレンジ)して作ってみたのがコレです。

カメラコントロールを使用して撮影した写真を添付ファイルとしてSharePointに登録するアプリ pic.twitter.com/V97DS4UUQU

— Kilroy 365 (@KilroyWaaasHere) 2021年7月2日

 全体の流れ

テスト作成なので、シンプルな構成にしていますが、全体の流れを図示してみるとざっくりとこんな感じ(細かいことは描き切れていませんが…)です。

今回はきっちり勉強する＆blog用にフロー図を作成してみました。
恐らく何らか正規な書き方があるのだろうけど、自己流で構造や変数などがどこでどうなっているのかを整理して書いてみました。
SwimlaneをScreenに見立てて書きましたが、結構わかりやすかった（自分的には）です。
割と単純でそんなに手順無いアプリですが、細かいところまで図示すると結構複雑に見えますね…。

変数の類

添付ファイルコントロールを使ったメソッドの説明は元動画を見てもらった方が良いと思いますが、肝はコレクションを使った添付ファイルの受け渡し。
添付ファイル格納用のコレクションを用意して、これを受け皿に添付ファイルをあれこれするイメージですね。このアプリではコレクションは一つ。
使用しているシーンは以下のようなとき。

変数もいくつか使っていて、以下のような感じ。

アレンジした点

➀カメラスクリーンの拡大モード
画面にスクリーン大きく表示できた方が便利ですよね。

②登録済み添付ファイルの削除
参考にさせてもらったアプリは登録のみで削除には対応していないとのことだったので、対応させてみました。
そもそも、submitした際に受け渡されるデータは何かというと、添付ファイルデータカードのUpdateプロパティで指定したものなので、これを見てみると、コレクションが指定されていましたが、コレクションの内容を削除してsubmitしても、添付ファイルは削除されないようでした。
ならばと、添付ファイルデータカード内で直接添付ファイルを削除し、これをsubmitするように変更してみると(変数を使って消したい時だけ指定)、うまくいき、添付ファイルを削除することができました。

つくってみて

なかなか良い学びになった気がします。
PowerAppsで簡単に写真撮影・リスト登録ができるので、備品やらスマホ持ってポチポチ登録するのに重宝しますね。

Microsoft 365グループ

Microsoft 365グループってなんぞ？

昨日書いた記事でMicrosoft 365グループにちょっと触れたけど、自分でもちゃんと把握できてるか不安だったので、Docs調べてみた。

対象Docsはこちら↓↓↓
Microsoft 365 グループについて - Office サポート

やっぱりちゃんと理解できてなかったですね～。

作成を開始するツールによってほんのちょっと提供されるリソースが異なるらしい。

Docsに書いてあるけど、あやふやだったので、念のため管理センター開いて確認してみました。

詳細は以下の表のとおり。

PlannerとOnenoteについては管理センターで確認ができなかったのでちょっと怪しいけど、たぶんこんな感じ。

ーで示した分も、後付けは出来るっぽいので、ほぼ変わらない。Sharepointが作成起点として機能するのはチームサイトで、コミュニケーションサイトはM365グループと紐づけできない。

どのアプリをメインに使ってコミュニケーションをとってるかによって作成起点が変わってくる感じですね。

なかなか奥が深い…

チームサイトとコミュニケーションサイト

SharePointのチームサイトとコミュニケーションサイトの違い。

ある程度使ってる人にとっては当たり前の内容だと思うけど、ネットで調べるとコンセプトについて解説が抜けてる説明サイトが意外と多い印象。

初心者的には、最初にサイトを作り始める時点でもうちょい理解できてれば...という内容だったので備忘的に書いていく。

初期設定の権限の違いは大事

個人的に一番重要だと思うのは権限関係。Microsoft365グループと連携できるか否か、それがなぜ違うのか。

ここはサイトを作るにあたって「一番重要ですよ～」、とアナウンスすべき事項だと思う。

自分の場合は下調べが足りず、中途半端な理解のもと手を動かし始めたので、後になって、何でだ？とつまずいた。

結果的にはたまたまコンセプトに沿った作成方法をしていたので助かったが、M365グループとの連携は後から変更することができない。（コミュニケーションサイトはM365グループに紐づけられない）間違っていれば、サイトの作り直しもあり得たので、ちょっと冷や汗をかいた。

チームサイト

さて、チームサイト。

こちらは基本的に365グループと連携する様になっており、Teamsでチームを作成すると背後で自動的に作成されるのもこのタイプ。

365グループで他のアプリとも連携する様にできているあたり、コンセプトはチームでM365を横断的に使って作業するためにあると考えるのが妥当。

チームで作業する用途に特化してる=チーム外に見せたくない作業やファイルをここで扱うという、ちょっとクローズドな感じで運用するやり方がしっくりくる。

コミュニケーションサイト

次は逆にM365グループと連携しないコミュニケーションサイト。目立ったチームサイトとの違いは365グループと連携しないことと、サイドリンクバーが上にあり、横方向にページを広く使えるUIの違い。
上にあるのにサイドリンクバーなのがちょっと笑えるけど、ページを広く使えてウェブパーツを配置しやすくなっているのはデザイン上優位で、ここはコンセプトとして、ページを積極的に『見てもらう』ことにウェートを置いていることがよく表れている部分だと思う。

『見てもらう』ことに重きをおくということはある程度オープンな使い方が想定される。その場で作業をするよりも、参照してもらうために情報を置いておいたり、知ってもらいたいことを表示して情報を拡散する、という使い方が増える。
そうなると、そこにある情報を編集できる人、見るだけの人など、色々な権限を設定して運用しなくてはならなくなってくる。つまり、チームサイトのように単一の権限だけでの運用に適していないため、M365グループとの紐づけを行っていない、ということなのだろう。

UIの違いに見え隠れするメッセージ？

上記のようにチームサイトはチーム内でのクローズドな作業に、コミュニケーションサイトはオープンに情報を扱いたい用途に適してそうです。
2つのサイトの見た目の大きな違いはサイドリンクバーの位置ですが、色々作業をしていると、チームサイトのも上にしてくれ～！って叫びたくなります。全部上に統一しないのは、2つのサイトの差を見た目で明確に認識できるよう、敢えてそうしてるんじゃないかと思います。「クローズドな作業に適したサイトだから、デザイン的に少々融通効かなくても、問題ないでしょ、はっきりわかるように、これは横に残しとこう。」なんていう開発者側の声が聞こえてくるような…。しらんけど。

なお、上記は僕個人の勝手な見解です。いや、そんな使い方ちゃうし、とか、もっとこんな違いがあるで、とかあればぜひこっそりと教えてください。

とりあえず現状を…

ブログをはじめてみたということで、まずはどういうことを書いていくのか、決めてみよう。

書いていく内容は備忘録で、Microsoft365を使い倒していく中で気が付いたこと、学習したことなどをつらつらと書いていくことにする。要するにアウトプット。

幸いなことに、所属している企業は365を導入しているものの、利用はTeamsのチャット程度、昔ながらの紙ベースの作業もかなり多い。ITに疎い上司も、やりたいことをおおまかに説明すると理解は示してくれたので、365を使い倒してどんどんIT化してやりたいと思っている。いまのところは歯止めなくやっていけそうなので、ガンガン使って自分のスキルアップもしていければ。

コーディング等の知識はほとんどなく、エクセルのパワーユーザーって感じの自分がどこまでやれるか、これからが楽しみ♪