記事公開日
【Power Pages】ファイル共有アプリをつくる ②WebRTC編

こんにちは。システムソリューション営業本部の吾妻です。
前回の記事では、クロスプラットフォームなPower Pagesサイトの構築例をご紹介しました。Power Pagesには、手軽にWebサイトを構築できるメリットがある一方で、デメリットもいくつかあります。そこで、前回の内容とは少し毛色が変わってしまいますが、技術的に発展的な内容で「ファイル共有アプリ」を高度にしていく解説をしていきたいと思います。
前回構成のデメリット
前回は、Power Pagesを中心にアプリを構築しました。Power Pagesに認証や大まかなUIの準備を任せられることから、手軽にアプリを作成できるメリットがある一方で、以下のようなデメリットもあります。
・Webロールの認証ユーザーでDataverseレコードへのアクセスを制御するため、受信者と受信させたくない認証ユーザーを区別して取り扱うのが難しい
・受信者以外にファイルを見られるリスクがある
・JavaScriptで作り込めばできるかもしれないが、Webロールはもともと個々人を区別するための機能ではないので適していない
・Dataverseレコードにファイルを格納するので、監査ログに記録が残る(業務目的であればもちろん残すべき)
そこで今回は、Dataverseにレコード/ファイルを格納せずにファイル共有アプリを実現することを目標に、WebRTCを活用できないか検討してみたいと思います。
WebRTCとは
WebRTC(Web Real-Time Communication)は、サーバーによる中継なしに、ピア(PCのWebブラウザ、モバイルのWebブラウザ、ネイティブアプリ)同士で、リアルタイムに音声、動画、その他のデータを送受信するための技術です。通信経路を確定するまでのシグナリングという手順では、STUNサーバーなどの第三者に通信を中継してもらう必要がありますが、通信経路が確立したあとの、データ送受信の段階では、ピア同士が直接通信(Peer-to-Peer)します。WebRTCを使うためにプラグインや特別なソフトウェアをインストールする必要はなく、ブラウザの標準機能で動作します。WebRTCで行われる通信は、すべて暗号化されています。通信の種類ごとの暗号化の違いを、以下の表に示します。
段階 | データの種類 | プロトコル |
シグナリング | DTLS(TLSをUDPで使えるようにしたもの) | |
通信 | MediaChannel | SRTP(RTPにAES暗号化などの機能を追加したもの) |
DataChannel | SCTP(TCPでもUDPでもないトランスポート層のプロトコル) over DTLS |
WebRTCでデータを送受信するまでの主なステップを以下に示します。
①シグナリング
…ピア同士が通信を開始する前に、お互いの存在を見つけて、Session Description(IPアドレスやポート番号などのピアに関する情報)とICE Candidate(通信経路の候補)を交換する
②通信の確立
…優先度の高い経路の候補から(直接接続に近いP2Pから、STUNリフレクション、TURNリレーの順に)接続テストを行って、ハンドシェイクを実行する
③P2P通信
…ピア同士の直接通信によって、メディアチャネル(音声/映像)またはデータチャネル(音声・映像を含めたすべてのデータ)でデータの送受信を行う
今回は、Dataverseやその他のサーバーを利用することなく、エンドツーエンドで直接ファイルを送受信するために、このWebRTCを活用したいと思います。ピア間は一対一で直接通信するので、指定した受信者以外にファイルを送信してしまうことも、ファイルをどこかに格納することもありません。
想定構成の例
Power Pagesのもつ、ローコード開発というメリットを活かしつつ、WebRTCによるファイル連携を実現するとしたら、以下のような構成が考えられます。(1) DataverseにSession Descriptionを格納するパターン
前述の通り、WebRTCでデータを送受信する際には、最初にSession Descriptionを交換するためのシグナリングという手順を行います。シグナリングには、通常WebSocketを利用することが多いですが、プロトコル上それ以外の方法で実装することも許されています。インターネットを介さない方法としては、Bluetooth(Bluetooth Low Energy)での通信や、送信側でQRコードを表示して受信側のカメラで撮影、送信側のスピーカーでサウンド再生して受信側のマイクで録音、といった方法がよく採用されるかと思います(ただし、Session Descriptionの文字長は結構長いので、QRコード1つにまとめようとすると、スマホのQRコードリーダーだと読み取れない可能性が高くなります)。Dataverseを利用できる場合、自端末で生成したSession DescriptionをDataverseレコードに登録する機能と、実際にWebRTCでファイルを転送する機能を、Power Pagesサイトに用意することが考えられます。Dataverseを利用できるのであればDataverseにファイルをアップロードすればいいんじゃないか、と思われる方がいると思いますが、通信開始時の仲介のみDataverseに任せることによって、Dataverse Web APIの制約を気にせずに済むこと(特にチャンクに分けないといけない場合)や、Dataverseにアップロードできないサイズ/種類のファイルでも送受信できることといったメリットがあります。
WebRTCの実装には、一般的にはJavaScriptを利用します。Power PagesサイトにおいてJavaScriptでロジックを作りこむ場合には、JavaScript Webリソースをフォームに埋め込むか、「コードの編集」からVisual Studio Code for the Webを開いて直接HTMLファイル(インラインスクリプト)またはJavaScriptファイルに書き込みます。このとき注意が必要なのは、Power Pagesサービス側で用意されているもののほかに、HTMLファイルやJavaScriptファイルをアップロードしても、無視される(次回同期時に削除される)ということです。そのため、左側のツリーから、既存のファイルを開いた上で、追記する必要があります。

(2) コンポーネントをスクラッチ開発するパターン
Node.jsでスクラッチ開発できるスキルがあれば、PCF(Power Apps Component Framework)を用いてコンポーネントを開発して、Power Appsと同様に、Power Pagesにも埋め込むことができます。現在のところ、PCF Galleryで「WebRTC」を利用したコンポーネントを公開しているものはありませんが、ReactでWebRTCを実装しているサンプルはWeb上にたくさん転がっているので、実装の難易度はそこまで高くないかと思います。また、現在のところ、Power PagesではReact コンポーネントは利用できず、標準(HTML)コンポーネントを利用する必要があります。そのため、キャンバスアプリやモデル駆動型アプリでも、Power Pagesサイトでもコンポーネントを使いまわしたい場合には、Node.jsでコンポーネントを実装したとしても、最終的に静的サイトとしてビルドする必要があります。

(3) iframeを活用するパターン
Power Appsのキャンバスアプリやモデル駆動型アプリと比較した場合の、Power Pagesサイトの特長として、インラインフレーム(iframe)コンポーネントがはじめから用意されていることが挙げられます。このため、Azure FunctionsやWeb AppsなどのAzureのサービスを利用して、Power Pagesの外にWebRTCアプリを用意しておけば、iframeを利用して容易に埋め込むことができます。ただし、iframeを設置したPower Pagesページから、iframeで埋め込まれたWebアプリケーションに対して動的にパラメーターを受け渡すことが、ローコードで実装するのは難しく、カスタムJavaScriptコードを記述する必要があるかと思います。

さらに発展的な内容(Azure Static Web Appsの活用)
想定される構成の例として、(1)から(3)まで、Power PagesとWebRTCを(むりやり)絡めたものを挙げてきましたが、現実的なソリューションとしては、Power Pagesから離れて(私の推しサービスである)Azure Static Web AppsにReactなどで実装したWebアプリケーションをデプロイして使うのが最もスムーズかと思います。Azure Static Web Appsは、静的サイトを公開するためのサービスで、C#やPython、PHPなどのサーバーが必要なプログラムを動かすことはできないのですが、HTMLとクライアントサイドで動くJavaScriptだけを組み合わせたWebアプリであれば、簡単に公開することができるサービスです。Azure Static Web Appsで公開したアプリを、iframeでPower Pagesサイトに埋め込むことももちろんできます。
GitHubリポジトリにソースコードをプッシュしておくことで、GitHub ActionsによるCI/CDを簡単にセットアップできるのも、Azure Static Web Appsのメリットの1つです。

Azure Static Web Appsで公開できるアプリは一般的なWebアプリケーションなので、画面を見ても特に変わったことはありませんが、一応デモ画面を載せておきます。
ちなみに画面を見ると、このアプリケーションのURLは、「https://happy-grass-...」というようなものになっていることが分かります。Azure Static Web Appsで公開されたアプリケーションには、ランダムな文字列+「.azurestaticapps.net」というURLが割り当てられます。お客様向け、社内向けのサービスとして公開する場合には、これとは別に、任意のドメインを「カスタムドメイン」として指定することもできます。

まとめ
今回は、前回に引き続き、クロスプラットフォームなファイル共有アプリを作ってみる場合に検討する事柄や構成例を、簡単にご紹介しました。Power Platform製品群は、他のPower Platform製品と組み合わせたり、Azureのサービスと組み合わせたりすることで、より活用の幅が広がるので、今後もご紹介できればと考えています。QES では Power Platform の開発支援、QAサポート、開発者教育、ガバナンス整備など、組織で Power Platform を活用するためのサポートを包括的にご提供しています。Power Platform 活用についてご興味がある/利用中だが課題を感じていらっしゃるお客様はまずはお気軽にお問い合わせください。
このブログで参照されている、Microsoft、Windows、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。