カテゴリ「Microsoft 365 - SharePoint」の359件の投稿 Feed

2015年12月 1日 (火)

新しいマイクロソフトの新しいサービスである Microsoft PowerApps の情報が正式に公開されました。今年の初夏に一部では情報リークがあったのですが、正式な情報は待たれるところでした。

このサービスは、Office に似た操作感で素早くビジネス アプリを作成できるものです。ワークフローを自動化するビジュアルデザイナーなども提供されるようです。Office 365, Dynamics CRM, OneDrive, オンプレミスのSharePoint、SQL Server, Oracle DB, SAP などとも接続可能とのこと。

おそらく、SharePoint ユーザーにとっては、これまでの InfoPath や SharePoint Designer の代替えに近い新しいソリューションになると期待しているものです。

現在は機能限定版のプレビュー版の利用申し込みを受け付けているところですので、詳細については色々と使ってみてこのブログなどでご紹介していきたいと思います。

[公式サイト] http://www.PowerApps.com

ソリューション概要や開発者向けの情報はChannel 9 に公開されています。

2015年10月22日 (木)

Office 2016 には、InfoPath が含まれなくなりますが、SharePoint ワークフロー開発などでは依然、必要なことがあります。

Office 2016 にアップグレードすると、既存の Office はすべてアンインストールされてしまいます。そのため、 InfoPath 2013 がインストールされていた場合も、削除されます。

こうした状況を鑑み、Office 365 ユーザーには 2015年9月1日より、下記のリンクより、InfoPath 2013 のみのダウンロードが提供されています。

ご存じない方も多いと思いますので、ご参考まで。

2015年10月15日 (木)

SharePoint Online を使ってディスカッション掲示板を検索する際に、検索結果にタイトルが正しく表示されないことがあります。

下記は IE 11 を使っている例です。26文字を超えるタイトルが設定されているアイテムは検索結果には ... のみが表示されています。

2015-10-14 23-27-35

ただし、Google Chrome でアクセスすると正しくタイトルまで表示されます。

2015-10-14 23-28-23

生成されているソースを調べるとタイトル部分に下記のスタイルシートが設定されていることがわかります。


.ms-srch-ellipsis{overflow:hidden;}

この設定が原因となっているようです。対処方法としては、代替スタイルシート作成し、下記のようにこの部分のみ SharePoint 標準の出力を書き直すことでうまく対処できます。代替スタイルシートは、発行サイトであればサイトの管理ページから設定できます。それ以外は、JavaScript などのクライアントAPIから設定する必要がありますので注意しましょう。※この記事では詳しい手順は割愛します。


.ms-srch-ellipsis{overflow:visible;}

 

ご参考まで。

*************************************

※注意※

あくまでも一時的な対処法です。SharePoint Online では今後、修正される可能性もあります。実際の運用では十分検証して利用してください。

 

2015年8月13日 (木)

Internet Explorer (以下、IE) には互換モードがあります。たとえば、IE 11 を使っていた場合でも、そのページを開く場合は IE9 と同等の機能で表示するといったことが可能です。

どの互換モードを使うかは、Webサーバー側でサイト単位で設定したり、Webページに meta 要素を追加したり、HTTPヘッダーを指定したりすることで決まります。場合によっては 組織内のシステム管理者側で設定するグループポリシーの影響も受けます(参考:Group Policy and compatibility with Internet Explorer 11)。

SharePoint の場合は、マスターページに設定される meta 要素が影響します。meta 要素は次のような記述です(IE9対応モード指定の例)。

<meta http-equiv="X-UA-Compatible" content="IE=9">

この記述はオンプレミスと Office 365 (SharePoint Online)とで違いがあります。さらに既定のマスターページによっても違いがあります。なお、以下に記述する内容は今後更新される可能性が高いため 2015年8月現在の状況として記載しておくことに留意してください。

[オンプレミスの SharePoint 2013 SP1 以降の状況]

オンプレミスの SharePoint Server 2013 が持つ既定のマスターページは seattle.master と oslo.master です。まず、seattle.master を見てみると下記の通り IE10 との互換性を確保するように指定されていることがわかります。

2015-08-13 10-01-26

同じく Oslo.master も確認してみると、seattle.master と同様に IE=10 となっています。

2015-08-13 10-03-42

結論としては、いずれのマスターページを使用していても IE10がターゲットになっているということです。

[Office 365 (SharePoint Online)]

続いてクラウド環境である Office 365 ではどうでしょうか? ちょっと様相が変わります。まず、seattle.master を見てみましょう。meta タグでの指定が見当たらず、その代り次の SharePoint サーバーコントロール (SharePont:IECompatibleMetaTag)が定義されています(ちなみに、このサーバーコントロールについて調べてみたのですが、現時点では何の情報も公開されおりませんので、結果から推測する挙動を推測するしかありません)。

2015-08-13 10-05-01
このマスターページを使っている SharePoint サイトのページをレンダリングしたところ、今のところ生成されたソースは以下の通り IE10 互換になっています。Oslo.master についても同様です。

2015-08-13 10-12-25

ところで、SharePoint 2013 からは HTML マスターページという新しい機能が追加されています。この機能は、発行サイトもしくは 「SharePoint Server 発行」フィーチャーをアクティブ化すると利用できます。この機能により、master ページではなく、これに関連づく HTMLファイルを使ってデザイン変更を行えるようにするというもので、これによって SharePoint Designer がなくとも、メモ帳や Dreamweaver などでも編集が手軽にできるようになったわけです。HTML側を編集すると、これに合わせて master ページを自動生成してくれるという仕組みです。

さて、この HTMLマスターページの側を確認すると、実は IE9 互換モードになっています。

2015-08-13 10-34-14

さて、挙動を確認してみましょう。HTMLマスターページ既定の seattle.master および oslo.master のいずれを指定しても、レンダリング時には既定では IE10 モードになるようです。

しかし、seattle.html もしくは oslo.html をコピーして作成した独自のマスターページを適用するとどうでしょうか。下記のように IE9 と IE10 の両方の互換モードが追加されてしまいます。結果として IE9 互換モードに引きずられます。そのため、IEに関しては、CSS3 のほとんどが利用できなくなってしまいます。

2015-08-13 10-36-39

※IE9互換モードにならないようにするには、このタグを削除してしまいたいところですが、このタグを削除すると対応する *.master が壊れてしまうというトラブルに見舞われました。SharePont:IECompatibleMetaTag サーバーコントロールが関係していそうですが、このトラブル対応は修正が厄介であるため、最善策としては削除ではなく、meta要素の属性を IE=10 や IE=Edge に変更するなどといった対応を行った方がよいようです。

[結論]

マスターページのカスタマイズは、もともと高度なものであり、極力行わずにできるだけ CSS のみで対応していきたいところですが、フッターを追加したりしたい場合は、どうしても若干の変更は必要です。また、全社向けの情報発信ポータルサイトでは見栄えが重視されるため、局所的にはカスタム作成のマスターページを使うことになります。この時、上記のような挙動を意識しておかないと、HTML5 や CSS3 対応にしていく際に、予想した結果とならないことになります。十分にご注意ください。

[参考]

Course-Banner-SiteBranding

2015年8月 6日 (木)

SharePoint では REST API を使用した SharePoint コンテンツへの CRUD 処理が行えます。以前は詳細(Verbose) OData メタデータのみをサポートしていましたが、現在では JSON Light もサポートしています。この対応は、オンプレミスでは Service Pack 1 のアップデートで行われ、既に Office 365 側も利用できるようになっています(※ SharePoint とは別に、WCF Data Services 5.0 は既に OData v3 にて対応済みです)。

さて、JSON Light 対応とは何か? 簡単に説明しておきましょう。

従来は、REST API を呼び出す際に要求ヘッダーに次のように指定していました。

"accept:application/json;odata=verbose"

このため、多くのSharePoint 資料は verbose を指定しています。

verbose 指定は現在ではオプション扱いです。verbose を指定することですべてのメタデータを取得してきます。しかし、開発者側からは特に使用する必要のないメタデータがある場合、これをすべて取得することはペイロードの増大につながるため、避けたいところです。

JSON Lightに対応することで、1.メタデータなし、2.最小限、3.完全 のいずれかを指定できるようになりました。

1. メタデータを指定しない場合は、"accept: application/json; odata=nometadata" と指定します。

2. 最小限のメタデータのみでよい場合は、 "accept: application/json; odata=minimalmetadata" と指定します。なお、メタデータ要求を明示しない " " の場合は、既定値はこの minimalmetadata 指定をした場合と同じです。

3. すべてのメタデータを取得したい場合は、従来通り記載します。

ちなみに、Office Blog に公開されていてる記事では、リストからいくつかのリスト アイテムを要求した場合の応答データサイズが計測されています。

  • verbose : 46,647バイト
  • minimalmetadata : 11,173バイト
  • nometadata : 6,832バイト

不必要なメタデータの取得はしないよう心がける必要がありますね。

参考