雑なsharepoint運用基礎講座2

前回の続きです。
sharepointの弱みとその対策メモ。

全体的な所感とNotesとの比較や移行の話は次になりました。

## sharepointの弱みやその対策

### 申請処理

気が利かない代名詞の申請処理です。
オンプレでもonlineでも、sharepointデフォルトの承認機能はあります。
普通のやり方としては、申請書用リストライブラリをつくり、コンフィグの「コンテンツ承認」をオン！でできます。
めでたしめでたしと思いきや、承認に際してメール送信や2段階認証などの用意はありません。純粋に承認機能のみが提供されています。
ユーザの大方はそんな不便じゃ困る、となるでしょう。

この対策には、結論から言うと以下のような打ち手があり、おそらく実装されていると思います。
上から無難。

1. sharepoint ワークフローを使ってワークフロー作成
2. power automate(MS flow)やpower appsを使ってフロー作成
3. サードパーティ製ツールを利用してワークフロー作成
4. powershellを使ってバッチ処理


1.は、昔からの選択肢であり、sharepointのプロがいるならまずこちらが選択肢に上がるでしょう。
開発者的にいえば、デスクトップで作り込んだワークフローの処理をsharepointサーバへ発行し、最後にsharepoint上でリストと紐付けるようなイメージです。
1番手間が掛かります(GUIベースのツールとはいえほぼほぼコーディング、テストも必要)が、カスタマイズの幅が大きくonlineでもオンプレでも似た感じで出来ます。
こちらは無料のsharepoint designer(今だと2013)のIDEが必要なのでデスクトップPCへインストールしましょう。また専用IDEは独特ですが基本visual studioベースのGUIですので、触りだけ教えて貰えば元開発者ならそれなりにさわれるかと。

重要なポイントとしては、onlineの場合、重い処理含む場合やテナントの状況により__処理の実施までのタイムラグが数分レベル__で発生する事があります。
ワークフローの処理は公式としてはブラックボックスですが、動きを見ているとキューを使った実装と思われます。で、キューが実際に消化される時間が短い時と長い時があるんですね。
障害判定に困りますが、__経験上基本は待つしかない__ようです。

あと、ユーザがタイムラグの間に操作すると…まあ色々不都合が起きます。主に更新時エラーとか。
~~キューに突っ込んだ時にデータも一緒に渡してるのか、データが実行までに変わるとバージョン管理で保存時エラーが出る感じに見えますが__そんな設計で大丈夫か？__~~

2.のpower apps/automateですが、こちらは最近MSが推してるonline専用のワークフロー作成機能になります。
前提として、power apps/automateは利用ライセンスが必要になりますので、利用していいか確認が必須です。
どちらもweb IDEがあり、1.の場合並みのカスタマイズが可能です。処理をautomateで、画面をpower appsで作ると、手元にIDEやソースコードが一切ないまま、いい感じの承認画面やフローが出来ます。PC統制されてるような企業は便利ですね。

ちなみにこちら、バージョン管理されてますので__手動でソースコード管理をする必要はありません__。

短所はchromeでしか使えないという謎の不具合が割と出ること、クラウドの為文献が少ないし操作項目や手順が変わるので運用手順や記録が残しにくい、テナントの状況により処理遅延や失敗が多発する辺り。
~~あ、IEが社内標準？みなかったことにしよう。
というかchrome使えっつってんだろいいから使え！！！！~~


1.も2.も共通して言える事ですが、シェアポ関係の設計書はConfigメモの塊に陥りやすく、障害が起きたから頼っても「なぜこのカスタマイズになったのか」が見えなかったりや、そもそもユーザがカスタムしてるから__設計書自体が存在しない__事を目にします。
何が正しいのかわからずにエラーが頻発するとしんどいでしょう。そういう方は本当にお疲れ様です。生きろ。

処理がどこで落ちたのかやエラーログは
1.の場合はIDEやワークフローの履歴リストを開いて、
2.の場合はchromeを立ち上げ、各フローの実行履歴から

みる事ができますので、サクサク解決を期待せず、じっくり調査を進めましょう。初心者なんですからね。

また、権限の変更など、一部の操作は2.で操作できず、1.にする事があります。

3.は、詳しい話はかけませんが、承認フローをいくつも持つような場合は採用される場合が多いようです。

4.のpowershellは、まあご存知とは思いますがなんでも出来ます。恐らくC#でも出来ると思います。
サーバを立ててバッチ処理、という形で対応するパターンになります。
azure環境の場合はサーバレスアーキテクチャのfunctionsを採用できるならさらにカッコいいかも。運用も楽だしね。


注意事項としては、onlineの場合はバッチ処理のアクセスをリソース消費として管理してます。
ので、1分に一回とかの頻繁なアクセスしてるとテナント巻き込んで遅くなったりしてコラ！アクセスしすぎ！ってエラーが吐かれますのでご注意を。
なおこのアクセス上限はテナントの状況により変化します。~~つまり天に運を任せましょうって感じです~~

とは言え、このアクセスカウントもアカウント単位で確認してるのはMSが明言してるようなので、可能ならば__バッチ処理で使うアカウントは分散しておく__のがベストなようです。

~~アカウント無料じゃないのになあ…~~

## 下書き状態がない件

気が利かない、パート2。
上の承認処理と関連しますが、承認機能を作るという事はアイテムに対して「承認前状態」を作る必要があり、「作成者以外には非公開な状況」を作り出す必要が出てきます。
つまり下書き状態が欲しい、となります。

解決法としては、sharepointはデフォルトで全体公開となると仕組みのため、先ほど説明した「コンテンツ承認」を使うことで、この状態を作り出す事が可能です。

…はて、コンテンツ承認は承認を表すために使いましょうと言う話でした。
でもここでは下書き状態を表すために使いましょうと言ってます。

__ど う や る の だ？？？__

各所で色んな実装方針があるようですので具体例は避けますが、ここら辺はみんな頑張ってね！！！！
多分理解めんどくさいと思うよ！！！

## 5000件問題の話

内外から槍玉に挙げられやすい掲題の話です。
初めてシェアポやるよ！の人は最初に知って欲しい話ですかね。

詳しい話はwebで調べてもらえればと思いますが、簡単に言うと、「リストライブラリ」に5000件(onlineのモダンリストのみ20000件)を超えるアイテムを突っ込むとリストライブラリのデフォルト表示機能？が壊れたり、並べ替えなどのアイテム全部の触るような処理が出来なくなる、という問題です。
(若干怪しいのでもし違ってる場合はご指摘下さい…)

__運用的にはリストライブラリが5000件を超えないように基本は見張っておく__必要がありそうです。

じゃあ超えそうな場合はどうしよっか？となりますが、リストのアーカイブ化か、リストに5000件以下に抑えるビューを切る事で表示機能のみ復旧させて放置、など色々手段がありますが、それぞれ長短あります。あと設計にもよります。

設計を行った開発元に連絡できるのならば、どうするのがベストか相談した方が良いでしょう。


開発元に相談できない場合の指針はかなり別トピックになりそうなので、ご要望があれば…。


続きは後日。