2SharePoint Onlineも歴史が長くなり、カスタマイズの手段が増えてきました。
技術の進歩は速いですから当然っちゃ当然なんですが、
自分も混乱したので簡単なメモ書きを残しておきます。
尚、当記事は概要レベルの記事となっております。
詳しい情報はMicrosoft Docsで入手できますので、
技術者歴の長い方、長文に抵抗の少ない方は以下を参照頂くほうが
より深い理解が得られるかと思います。
SharePoint の開発 | Microsoft Docs
注1) SharePoint Onlineのみを対象とした記事となっております。
オンプレミスのSharePoint Serverについては省略します。
注2) ブラウザ上で行えないものは全て「カスタマイズ」と見做しています。
注3) このページはカスタマイズの方法論のみについて扱っています。
構築例は別のページにまとめています。
はじめに
SharePoint Onlineで画面のカスタマイズを行う場合、多くの場合はJavaScript / CSS / HTMLなどクライアントサイドの仕組みを利用することになります。何故なら、SharePoint Onlineのサーバー上で動作するプログラムの作成は一切行えないからです。
画面をJavaScriptで記述し、REST APIでサーバーに処理を依頼することはできますが、APIをホストするWebサーバは自前で用意する必要があります。SharePoint や Exchange、Graph APIなどMicrosoft社が提供するものは勿論、自分で開発したAPIもJavaScriptから実行できます。APIに認証を通してアクセス許可を取得する仕組みも、Azure AD側で用意されています。
開発したJavaScript / CSS / HTMLをSharePointに適用する方法は複数存在します。SharePoint標準のマスターページを編集して直接埋め込んだり、アドインを開発したり、PowerShellで埋め込んだりと手段が多く、私の混乱の主な原因になっています。
さて、ここまでは画面のカスタマイズに関する記述でしたが、SharePoint標準のイベントを拾って何かの処理を行いたい場合、これはクライアントサイドの領分ではありません。ワークフロー又はMicrosft Flowを利用するか、自前で用意したAPIをSharePointアドインやWebhookを利用して呼び出します。例えば、リスト アイテムを追加した時に何かの処理を行うなどの場合がこれに該当します。
手法の一覧と概要
奇麗に載せるのが難しいので画像になってしまいました。
リンクなんか張りたかったんですがね。すいません。
実現可能範囲について補足します。
- 画面カスタマイズ(色だけ)
サイト全体の配色のみを変更するカスタマイズを指します。
- 画面カスタマイズ(その他を含む)
配色だけでなくWebパーツや自作のボタンなど、画面に加えるカスタマイズ全てを指します。
- イベント処理
SharePoint標準機能の操作に対して、イベントを加えるカスタマイズを指します。
自作Webパーツ内のイベントなど、標準以外のイベントは含みません。
例えばリスト アイテムの追加などが該当します。
各手法の概説
テーマ
SharePoint サイト全体の配色を決定する機能です。クラシックサイトとモダンサイトの両方で利用可能です。
プログラミングは必要なく、「どの場所にどの色を適用するか」を記載したJSONファイルを作成して適用するだけの作業になります。
適用済のテーマは、SharePoint サイトの「外観の変更」機能で選択できるようになります。
SharePoint サイトのテーマ | Microsoft Docs
直接埋め込み
この手法には名前が付いていないので勝手に命名しました。
自作のJavaScript / CSS / HTMLをSharePointに手動で読み込ませる方法です。
埋め込みの方法は色々あります。以下に一例を記載します。
- マスターページを編集する
- SharePoint Designerでページ定義を編集する
- コンテンツ エディター や スクリプト エディターで読み込む
- PnP PowerShell でJavaScriptを登録する
とにかく手軽に始められることが利点で、古くからよく採用されていました。
SharePointとの通信や描画を全て自前で行いますので、SharePoint側のアップデートがあった場合に影響を受けやすいことが欠点です。(例えばSharePoint標準のHTML要素内に自作のボタンを追加した場合、SharePoint側がHTML要素の作り方を変えてしまったら動かなくなる可能性が高いです。)
ただし、モダン サイトではこの手法が採れなくなってしまいました。今後は徐々に採用されなくなっていくと考えています。
(マスターページの編集が禁止され、コンテンツ エディターやスクリプト エディターもモダン サイトでは提供されていません。)
JSLink
リスト / ライブラリの画面カスタマイズに特化した方法です。
ビュー と アイテム新規登録・編集・詳細 画面に対して変更を加えることができます。
直接埋め込みでは SharePoint標準のHTMLが描画された後に自作の処理を上被せしますが、JSLinkではSharePointが描画するHTMLを定義することが可能です。
用途が限定されているものの、直接埋め込みよりも強力な方法です。
ただし、モダン サイトでは利用できません。
こちらも今後は徐々に見かけなくなっていくでしょう。後述のSharePoint Frameworkでは、JSLinkを代替する方法が紹介されています。
JSLink カスタマイズを SharePoint Framework フィールド カスタマイザーに移行する | Microsoft Docs
SharePoint アドイン
リスト / ワークフロー / コンテンツ タイプなど、SharePointの構成要素のほとんどを含めることができる、独立したパーツです。Microsoft社のアプリ ストアからSharePointに追加できるアプリは「SharePoint アドイン」です。
クラシック サイトでもモダン サイトでも利用でき、対応可能範囲が広いため非常に強力な仕組みです。
但し開発コストがやや高く、単品のWebパーツを開発する程度の目的では採用しづらいことが欠点です。クラシック サイト向けの開発は直接埋め込みとJSLinkで実現してしまうことが多いです。(複数サイトに展開するなど、パッケージ化が大事な場合は別。)
SharePoint アドインは、ユーザーが利用中のサイトとは別のサイトで実行されており、IFrameでページ内に読み込まれています。(「アプリWeb」と呼ばれる特別なSharePoint サイトか、又はアドインをホストする別のWebサーバー上で実行されます。)
IFrameの向こう側で処理が実行されるため実装には注意が必要ですが、これはアドインがIFrameのこちら側に対してフル コントロール権限を持っていないというセキュリティ上の利点にもなっています。
SharePoint アドイン | Microsoft Docs
SharePoint Framework (略称：SPFx)
ここまで紹介した従来のカスタマイズ方法が抱える課題を解決するために考案された、比較的新しい仕組みです。
SharePoint上に配置されるモジュールは開発したJavaScriptです。SharePoint アドインでは、モジュールはアプリ Web内にリストやライブラリなどと同梱されますが、SharePoint FrameworkはシンプルにJavaScriptのみがIFrameを介さずにページに読み込まれます。反面、JavaScriptがブラウザに直接読み込まれている( = ユーザーと同じ権限を持っている)ため、悪意のあるコードを実行しやすく、現在のところMicrosoftのアプリ ストアには公開できません。
配布されるモジュールがシンプルになったせいか、Visual Studioは必要なくなりました。最終的な成果物としてJavaScriptがあれば良く、TypeScriptと任意のエディタで開発が可能になりました。よってMicrosoft系のエンジニアだけでなく、Angular, Reactなどを利用するフロントエンド エンジニアも参入しやすくなりました。
SPFxはモダン サイトでもクラシック サイトでも動作します。
今後もMicrosoftによってサポートされていく仕組みだと思われるので、これからWebパーツを開発する場合はまずSPFxを検討することになると考えます。
時代はオープン ソース。ということですね。
これから学習される方のために記事を書きました。
初めてのSharePoint Framework (略称：SPFx) : Hello World ! - 鍋綿ブログ
ここにSPFxの概要があります。
SharePoint Framework の概要 (SPFx) | Microsoft Docs
私は以下のサイトで背景なんかを読んでしっくりきました。
SharePoint Framework (SPFx) エンタープライズ ガイダンス | Microsoft Docs
ワークフロー
ここまでは画面カスタマイズの方法でしたが、ここからはイベント処理の方法です。
SharePointに標準搭載されている「ワークフロー」は、SharePointのリスト アイテムやライブラリ上のファイルに対するイベントが起きた時に実行する処理を定義する仕組みです。(あくまでも「処理を定義する仕組み」のことであって、「標準で用意されている承認ワークフロー」は存在しません。残念。)
ワークフローの編集はSharePoint Designerで行います。「リスト アイテムを編集する」「タスクを割り当てる」など予め用意されたアクションをいくつも繋げて処理全体を定義します。
外部のREST APIを呼び出すアクションも用意されており、SharePoint OnlineのREST APIを実行することで、標準アクションで実行できない操作も実現可能です。(フォルダを作ったり、ファイルを移動したりとか。)
SharePoint Designer のワークフローで REST API を呼び出す - 鍋綿ブログ
ワークフローを実行するためのメニューを画面に追加することもできます。
そういった意味では画面カスタマイズに当たるのですが、範囲が狭すぎて面倒なので上記の表では割愛しました。
Microsoft Flow
Microsoft Flowは、異なるサービス間を繋ぐハブの役割をするサービスです。
簡単な承認や計算もできるので、ワークフローの代替手段としても機能します。
ワークフローには無い「アイテムの削除」イベントも拾うことができるので、
今後はFlowを主に利用していくことになるかと考えています。
Flowの編集はブラウザで行います。専用のツールが必要ない分 始めやすいのですが、
ブラウザ自体があまり軽快に動くツールとは言えないので私は別のツールが用意されないかと期待しています。が、たぶん無いでしょう（笑）
Flowも外部のREST APIを実行する機能があり、多くのサービスと接続できます。
SharePointのREST APIを実行すれば、ブラウザで実施できる操作はほとんどFlowで行えそうです。
Webhook
Webhookでは、SharePointでイベントが起きた後に、予め登録したURLでPOSTリクエストを受け取ることができます。例えばリスト アイテムが登録された後に自作のREST APIが実行されるような使い方になります。イベント完了後に通知が来ますので、リスト アイテムの登録前チェックなんかは実現できません。
SharePointの画面に手を入れるのではなく、イベントに紐づけて処理を実行するというやり方になりますので、開発者はREST APIを構築することになります。よって開発言語は任意になります。
まあ、Webhookに関してはあまり使いやすいものではないかなって感じです。私も実際に運用環境に導入されているものは見たことがありません。
以上、カスタマイズ方法の概要でした。
詰め込みすぎたので結局のMSの公式より長くなったかもしれません(笑)
