松崎 剛 Blog

This Blog's theme : エンタープライズ開発 (Server side)、Office サーバ開発

SharePoint Add-ins の動作と概要

SharePoint Add-ins の動作と概要

  • Comments 0

環境 :
Visual Studio 2012
Microsoft Office Developer Tools for Visual Studio 2012 Preview
Office 365 Preview (または、SharePoint Server 2013 Preview)

SharePoint Add-ins 開発

こんにちは。

ここでは、SharePoint 2013 が使用可能な新しい開発手法 SharePoint Add-ins (SharePoint アドイン, 旧 App for SharePoint) を整理して解説します。

 

Hosting 方法

SharePoint Add-ins (SharePoint アドイン, 旧 App for SharePoint) では、SharePoint と連携して動作する Web アプリケーション本体と xml のアプリケーション定義情報があり、SharePoint にはこの定義情報がインストールされます。
一方、Web アプリケーション本体は、SharePoint 上ではなく、別の場所にホストします。この SharePoint Add-ins の Web のホスト方法として、下記の 3 通りの展開方法が使用できます。(後述しますが、それぞれは排他的ではありません。兼ねることができます。)
なお、SharePoint Add-ins では、以下で説明するように、Host Web、App Web、Remote App の 3 つのサイト (ドメインの異なるサイト) を使用します。(これらのドメインは、ブラウザーのアドレスなどで確認できます。もちろん、エンドユーザーは、普段 意識しません。)

2014/06 追記 : 下記の Autohosted (自動ホスト型)  は、今後サポートされません。リモート実行の際は、後述する Provider-hosted を使用してください。

Autohosted (自動ホスト型)

Autohosted で構築されたアプリケーション (SharePoint Add-ins) では、デモでお見せした通り、利用者が Add-ins を追加 (インストール) すると、そのタイミングで Web アプリケーションが Azure にホストされます。(アプリケーションは、Azure Web Sites としてホストされます。Office 365 では、*.o365apps.net のドメインに展開されます。) このように、SharePoint とは異なる独自のホスティング環境 (Azure, AWS, On-Premise 上のサーバー, など) に配置される Web アプリケーションを Remote App と呼び、Full Page の Add-ins や、後述する App Part、Remote Event Receiver などの Add-ins で使用されます。

補足 : ただし、Autohosted の Add-ins のデバッグ実行をおこなうと、Web アプリケーションは localhost (IIS Express 上) で動作します。

Remote App の場合、SharePoint とは独立した環境のため、サーバー コードの実行など、一般の Web アプリケーションと同様のスタイルで (制約なく) 開発をおこなうことができます。また、認証をおこなう際には、Azure Active Directrory などクレームベースの認証基盤を活用することで、SharePoint サイトとの Web SSO の構成も容易に実装できます。
この Hosting 方法では、例えば、サイト 1 とサイト 2 で、同じアプリケーションの追加をおこなった場合、Web ページやサーバー サイド ロジックも、異なる Azure Web Sites に展開されます。即ち、Multi-tenant (マルチテナント) にも自動的に対応できています。(SharePoint 上から Add-ins を削除すると、この Web Site も削除されます。)

補足 : セッションで紹介した通り、Autohosted では、Azure SQL Database のテーブルも同時に追加可能です。DACPAC を作成し、SharePoint Add-ins プロジェクトのプロパティの [SQL Package] (下図) に この DACPAC を設定します。(DACPAC は、Visual Studio の SQL Server Database Project で作成できます。)
また、Web プロジェクトでは、この配置されたデータベースを参照する専用の Connection String (SqlAzureConnectionString) も使用できます。
ここでは、構築手順の詳細は省略します。

Provider-hosted (プロバイダー向けのホスト型)

Provider-hosted は、Web アプリケーション側をあらかじめ開発者がホストしておき、定義情報に この Web アプリケーションの URL (参照) を記述します (この定義情報を SharePoint に Deploy します)。このように SharePoint とは異なる独自のホスティング環境 (例えば、Azure, AWS, On-Premise 上のサーバー, など) に配置される Web アプリケーションを Remote App と呼び、Full Page (Web ページそのもの) や、後述する App Part、Remote Event Receiver など、それぞれ独自の形態で配置されます。(上述の Autohosted と Provider-hosted をあわせて、Cloud-hosted と呼びます。)
SharePoint に配置される定義情報は .app の拡張子を持った zip ファイルとして作成されますが、この .app パッケージには、Web アプリケーションそのものは含まれていません。(URL のみが設定されています。)

Remote App は、このように SharePoint とは独立した環境のため、サーバー コードの実行など、一般の Web アプリケーションと同様のスタイルで (制約なく) 開発をおこなうことができます。また、認証をおこなう際には、Azure Active Directrory を使った OAuth 認証をおこない、SharePoint サイトとの連携や Web SSO の構成も容易に実装できます。

この Provider-hosted では、Multi-tenant の Add-ins として配布する場合、Remote App 側の Tenant 管理をアプリケーション側で制御したり、チューニングしたりする必要があるので注意してください。
また、後述しますが、この Hosting 方法は、Office 365 (SharePoint Online) だけではなく、On-Premise (SharePoint Server) でも使用できます。

SharePoint-hosted (SharePoint ホスト型)

この Hosting 方法では、サーバー上に配置されるコンポーネント (例えば、ホストする HTML や JavaScript、イメージファイルなど) は、すべて利用者の SharePoint 環境 (Office 365 の場合は、利用者の tenant) に配置されます。
Add-ins の追加と同時に、App Web と呼ばれる Add-ins 独自の SharePoint サイトが作成され、Artifacts (Page など) は、すべて、この App web のサイトに配置されます。(例えば、contoso-ba39d711d8040c.sharepoint.com など、一意の Id を含む独自のドメインが割り当てられ、App Web が作成されます。) これに対し、アプリケーションのインストール元となった SharePoint サイト (contoso.sharepoint.com) のほうは、Host Web と呼びます。
コンセプトは従来の (SharePoint 2010 の) サンドボックス ソリューションと似ていますが、上述の通り、サンドボックス ソリューションとはまったく異なります。

重要な点として、この SharePoint-hosted (App Web) で動作する artifacts で、サーバー側のコードは実行できません。このため、後述するように、宣言型のマークアップか、JavaScript などクライアント側のコードのみを使用してアプリケーションを構築します。(artifacts は、.wsp として配置されます。)

なお、前述の Autohosted、Provider-hosted の Add-ins でも、挿入する artifacts によっては App Web を併用できます。例えば、Page は Provider-hosted を使って Remote App (Azure) に展開し、カスタムのリスト定義を App Web 上で動かして連携できます。
このため、Sharepoint-hosted のアプリケーションは、Cloud-hosted (Remote App) を使用しないアプリケーションと考えておいたほうがすっきりするでしょう。

 

配布先

SharePoint Add-ins の配布をおこなう場所として、以下の 2 つが使用できます。

  • SharePoint Store への配置
    ISV が構築したアプリケーション製品を配布する場合には、この配布方法が向いています。開発者 (アプリケーションの提供元) は、Windows 8 store app などと同様、専用の Seller Dashboard (Office Add-ins and SharePoint Add-ins Dashboard) に提出 (Submit) をおこない、審査の結果、承認された Add-ins が一般の利用者から追加可能になります。
    利用者が Add-ins を追加する場合は、SharePoint の左ナビゲーションから [Site Contents] をクリックして、表示される画面で [add an app] をクリックして、ナビゲーションの [SharePoint Store] をクリックすることで、 SharePoint Store 上の Add-ins の一覧を表示して、必要な Add-ins を追加できます。(Rating の高い Add-ins が、上に表示されます。)

  • App Catalog への配置
    もちろん、企業 (Enterprise) 向けの配布も可能です。
    Office 365 のテナントや SharePoint Server (On-Premise) のファームを立てて、全体管理 (Central Administration) の画面から App catalog というサイト コレクションを作成します。この App catalog に Add-ins (Office Add-ins、SharePoint Add-ins) を配置することで、組織 (自社) 内だけにアプリケーションを配布することができます。(Office クライアント側なども、この App catalog を参照するように設定しておきます。なお、運用管理者が設定を自動配布することも可能です。)

なお、開発・Debug 時は、Visual Studio で F5 キー (Debug 実行) を押すことで、Visual Studio により、作成したアプリが localhost で実行され、デバッグ対象の SharePoint サイト上にアプリが登録されます。(あらかじめ、デバッグ用に、SharePoint 上に Developer Site (開発者向けサイト) を作成しておいてください。)
Remote App を Azure など現実の環境に配置をおこなってデバッグしたい場合には、開発用に Developer Site (開発者向けサイト) を作成し、アプリをクラウド上 (Azure など) に配置して、サイトの [Apps in Testing] (テスト中のアプリ) ライブラリーに .app ファイルの追加をおこないます。(この際、Remote Debug を使用すると良いでしょう。) なお、この方法でアップロードされたファイル (.app パッケージ) は、App Packages ライブラリー (https://<site url>/Lists/AppPackages) に保存されます。
Developer Site (開発者向けサイト) のサイト テンプレートでは、Sideloading が有効になっているため、こうした配置が既定で可能になっています。

 

アプリケーションの形態 (Application Type)

SharePoint Add-ins では、下記の 3 つタイプのアプリケーションが作成できます。

  • Full Page
    「Site Contents」から選択して表示されるページ (ASP.NET MVC、.aspx など) のアプリケーションです。上述の通り、サーバー サイドのコードも自由に記述でき、ページ上で自由に UI を構築できます。

  • Parts
    いわゆる、従来の Web パーツ (WebPart) のような Part も、SharePoint Add-ins で扱えます。SharePoint 2013 で新たに導入された ClientWebPart クラスを使うことで、リモートにホストされたページを Part として利用者に提供できます。(内部では、iframe が使用されています。従来通り、EditorPart (Tool Part) のような独自のプロパティも使用可能です。)
    なお、このような Part (部品) を app part と呼び、挿入時も Web Part とは区別されています。(下図)


  • Extensions
    SharePoint のカスタム リスト定義、リボン カスタマイズなど、既存の SharePoint の機能 (UI など) を拡張するタイプのアプリケーションも構築できます。
    開発者は、Visual Studio で SharePoint Add-ins のプロジェクトを作成して、作成された Add-ins のプロジェクトを右クリックして [Add] - [New Item] を選択することで、これらのさまざまなコンポーネントを挿入できます。(下図)
    なお、こうして挿入したコンポーネントは、.app パッケージ (zip ファイル) 内に .wsp としてパッケージ化されます。

セッションで解説した通り、今回から、どの開発コンポーネントも、リモート実行のモデルとなっている点に注意してください。(前述の通り、必ず、Remote App、App web などの別ドメインで動作させる必要があります。)

このため、Client Web Part、Remote Event Receiver など、SharePoint 2013 からの新しい artifacts も多く存在します。また、Workflow も、SharePoint 2013 に含まれるワークフロー エンジン (Workflow Manager 1.0) を使って、今回から Remote 呼び出しが可能になっています。(現在、この実行エンジンの Beta 版も単体で提供されています。てすとぶろぐ さんが素早く紹介してくれていますので、是非参考にしてみてください。)

なお、Artifacts としては、以下が使用可能です。

  • カスタム Feature (Web スコープのみ)
  • カスタム アクション
  • イベント レシーバー (Remote event receiver)
  • .aspx などのマークアップ ページ (サンドボックス ソリューションの頃のように、app part などを入れておくことも可能)、カスタムの css ファイル、カスタムの JavaScript ファイル などのモジュール
  • カスタムのリスト定義 / リスト インスタンス / リスト フォームなど
  • カスタム Content-Types
  • カスタム Field
  • Business Connectivity Services (BCS) モデル (Web スコープのみ)、モデルを使用した External Content-Types、外部リスト
  • ワークフロー
  • Property bags
  • Web テンプレート

逆に、従来 (SharePoint 2010) のファーム ソリューションで使用できていた、サイト定義、カスタム テーマ、ユーザー コントロール (及び、Delegate コントロール) などは使用できません。

 

SharePoint へのアクセス

SharePoint-hosted の場合

App では SharePoint (Host web) との連携が必要になると思いますが、上記のアーキテクチャからご想像いただける通り、SharePoint へのアクセス方法は、Cloud hosted (Autohosted、Provider-hosted) と SharePoint-hosted の場合で大きく異なります。

まず、SharePoint-hosted のアプリケーションの場合 (Module の Page から SharePoint に接続する場合など) について解説します。

上述の通り、SharePoint-hosted ではサーバー コードの実行はできないため、SharePoint の JavaScript OM (JSOM)、または REST API を使用して SharePoint にアクセスします。

補足 : CSOM や JSOM のエッセンスについては、「リモートからの SharePoint 接続 - オブジェクト モデル (Client Object Model) の使用」 を参照してください。SharePoint 2013 では、この Object Model がさらに拡張されています。

ここで、一点、注意すべき点があります。
JSOM (JavaScript OM) から接続する場合、普通に接続すると、取得される Web は App web であるという点に注意してください。例えば、Web の title を取得するコードの場合、普通に書くと、App web のタイトルが返ってきます。
このため、Host Web に接続するには、クロス ドメイン接続 が必要と思われるかもしれません。しかし、SharePoint 2013 の CSOM (JSOM 含む) では、クロス ドメイン接続をおこなうことなく、App Web から Host Web のデータにアクセスできるようになっています。
Host Web にアクセスするには、Permission の付与を適切におこなって、下記コードの通り、SP.AppContextSite を使用した独自の context を使います。(Permission については後述します。下記のコードの場合、web の Read 権限を付与する必要があります。)

var hostweburl = getParameterByName('SPHostUrl');
context = new SP.ClientContext.get_current();
var appctx = new SP.AppContextSite(context, hostweburl);
web = appctx.get_web();

function getParameterByName(name) {
  name = name.replace(/[\[]/, "\\\[").replace(/[\]]/, "\\\]");
  var regexS = "[\\?&]" + name + "=([^&#]*)";
  var regex = new RegExp(regexS);
  var results = regex.exec(window.location.search);
  if (results == null)
    return "";
  else
    return decodeURIComponent(results[1].replace(/\+/g, " "));
}

また、REST を使用して Host web と連携する場合も、cross-domain 接続をおこなう必要はありません。例えば、Host web の Web の情報 (名前など) を取得する場合は、App Web から下記の URI でアクセスできます。

https://<app web url>/_api/SP.AppContextSite(@target)/web?@target='<host web url>'

補足 : SharePoint 2013 では、CSOM (JSOM 含む) と、その中で使用されている client.svc が機能拡張されています。SharePoint 2013 用の API 追加 (例えば、Social API の追加など) だけでなく、今回から client.svc は REST 対応になっており、上記の URL (/_api) で接続できるようになっています。(CSOM 自体も、内部で、この REST API を呼び出しています。)
もちろん、以前の REST (listdata.svc) も、そのまま使用できます。

 

Cloud-hosted の場合

Cloud hosted (Autohosted、Provider-hosted) の場合には、サーバー側のコードが記述できるため、サーバー側から接続する方法と、クライアント側から接続する方法の 2 通りがあります。

まず、前者ですが、サーバー側から .NET の CSOM (Client Side Object Model) や REST API を呼び出すことで、SharePoint にアクセスできます。

この方法では、認証処理が必要になるという点に注意してください。例えば、Office 365 では、こうした server to server の認証方法として、OAuth 2 が使用できます。以降では、Office 365 の場合を例に、この流れについて説明します。

まず、SharePoint (Host web) は、Add-ins を呼び出す際、POST データなどの形で、トークン (SPAppToken など) の文字列を渡します。このトークン文字列は、dot ( . ) で区切られた文字列の配列 (3 つの要素の配列) で、最初の 2 つが Base 64 エンコードされた Json 文字列 (特に 2 つ目は、JWT トークン) で、最後の 1 つが Signature となっています。(厳密には、Base64 エンコード文字列ではなく、Url 文字列などで渡すことができるよう、Base64 エンコード文字列に独自の変換がおこなわれています。)
そして、この JWT トークン (Json 文字列) の中に、OAuth の Refresh Token などの基本的な情報が含まれています。

App 側では、この受け取ったトークンを使って、以下の認証処理をおこないます。

補足 : OAuth における access token、refresh token については、以前記載した こちら を参照してください。ここでは、これらの基本的な説明は省略します。

  1. 上述の通り、トークン文字列 (AppContext、AppContextToken、AccessToken、SPAppToken のいずれか 1 つ) を取得し、取得したトークンから JWT トークンを取り出します。(Parse します。)
    なお、この Parse の処理は、SharePoint Add-ins のプロジェクトにあらかじめ参照追加されている Microsoft.IdentityModel.Extensions.dll の JsonWebSecurityTokenHandler クラスで可能です。
  2. JWT で渡された OAuth の refresh token を使用して、STS (https://accounts.accesscontrol.windows.net/<realm>/tokens/OAuth/2) に Access token を要求します。
    なお、この処理も、Microsoft.IdentityModel.Extensions.dll の OAuth2S2SClient などのクラスが使用できます。
  3. 上述の通り SharePoint の CSOM (Client Side Object Model) や REST にアクセスします。この際、上記で取得した Access token を、下記フォーマットで Http Header に設定します。(以前紹介した Graph API の投稿 と同じアクセス方法です。)

    Authorization : Bearer <access token>

なお、Access Token が期限切れになった場合には、再度、Refresh Token から Access Token を取得しなおしてください。
上記の流れからお分かりの通り、SharePoint Add-ins のプロジェクトには、Windows Identity Foundation (WIF) の最新版 (WIF 1.1、すなわち Microsoft.IdentityModel.Extensions.dll と、Microsoft.IdentityModel.dll の runtime version 2) が含まれており、上記の認証の流れを処理する際には、このライブラリーが使用できます。

さて、認証の説明が長くなってしまいましたが、Cloud-hosted の場合には、上述のサーバー側からのアクセス方法以外に、クライアント側 (ブラウザー上) の JavaScript から SharePoint にアクセスすることもできます。しかし、この場合、クロス ドメインの問題 を解決する必要があります。
実は、SharePoint 2013 では、こうした場合に使用可能な専用のライブラリー (Cross-domain libray) が提供されていて、これを使用して、認証の問題とクロス ドメインの問題を同時に解決できます。このライブラリーの動作や使い方については、またまた説明が長くなってしまうため、次回の投稿で解説したいと思います。(書いていたら、どんどん長くなってしまいました。もう昼休みも終わってしまった。)

2012/10/05 追記 : Cross-domain library について、「SharePoint の Cross-domain library」に掲載しました。

 

Permission (アクセス許可) の考え方

SharePoint Add-ins における Permission では、Delegation の考え方を採用しています。

まず、Add-ins の開発者は、例えば、「サイト コレクションのデータの読み込み」、「サイトへの書き込み」など、そのアプリケーションで必要となる Permission を要求します。下図の通り、Add-ins プロジェクトのマニフェスト (XML の定義情報) に、Permission 要求の設定をおこないます。

利用者がこの Add-ins を追加する際、Add-ins は上記の権限を利用者に要求します。具体的には、要求している Permission の内容が記載された確認画面が表示されます。
利用者が この Add-ins を信頼 (Trust) すると、利用者が持っている権限を Add-ins に委譲します。例えば、利用者が「サイト コレクションのデータの読み込み」の権限を持っている場合、この利用者が持つ権限が Add-ins に付与され、以降、この Add-ins は、この付与された権限を使って動作します。
なお、もし利用者が、そもそも Add-ins が要求している権限を持っていなかった場合には、下図の通り、エラーが表示されます。

この Permission のモデルは、一見、危険なように思われるかもしれません。例えば、サイトの投稿権限を持っているユーザーが、不用意に Add-ins を信頼 (Trust) してしまうと、閲覧権限しか持たない利用者に投稿の手段を与えてしまうことになりかねません。しかし、そもそも Add-ins を追加できるユーザーはサイト管理者の権限が必要であるため、ユーザーに権限付与が可能なサイト管理者の判断が必ず必要です。(もちろん、サイト管理者は、不用意に、信頼できない Add-ins を追加しないようにしてください。)

 

ご参考 : SharePoint Server 2013 On-Premise 環境で使用する場合の注意点

セッションでも紹介したように、実は、SharePoint Server 2013 の On-Premise 環境で使用する場合には、いくつかの注意点があります。最後に、この注意点について補足しておきます。

まず、上記の連携方法からわかるように、SharePoint Server 2013 の On-Premise 環境で Cloud hosted (Autohosted、Provider-hosted) を使用する場合、いろいろと制限が出てくることがおわかり頂けるでしょう。例えば、Azure 上のサーバー コードから SharePoint に接続する場合を想像してみてください。Proxy や Firewall を超えて、On-Premise 環境へのアクセスしなければなりません。(事実上、こんなことは不可能ですね。) さらに、サーバー側からの認証も、上記のような Azure の STS を使用するわけには行きません。(Azure の STS と On-Premise の間に、信頼関係はありません。)
On-Premise 環境の SharePoint 2013 Preview で SharePoint Add-ins を使用する場合、実は、「MSDN : Hosting options for apps for SharePoint」 で解説されているように、SharePoint-hosted と、high-trust な Provider-hosted のみがサポートされています。(つまり、Autohosted は使用できません。サポートされていない環境では、F5 による debug 実行も失敗します。)
企業内アプリケーションの場合、Web アプリケーションを企業内のネットワークに配置して App Catalog で配布するなど、配置方法についても現実的な設計が必要であり、サーバー側からの認証方法も考慮する必要があります。

2012/12/21 追記 : On-Premises で動作する App の開発については、「SharePoint Add-ins : On-Premises と Office 365 で動く Add-ins を作成するには」に記載しました。

また、環境を構築する際も、On-Premise ではいくつか面倒な設定をおこなう必要があります。(開発者にとって一番簡単なのは、Office 365 をそのまま使用することです。Office 365 では、多くの設定が、あらかじめ おこなわれています。)
以下に、これらの必要なセットアップ内容を記載します。

 

1. 必要なサービスとサービス アプリケーションの確認

まず、App で使用するサービスを確認してください。

ブラウザー (IE) を管理者権限 (run as Administrator) で開き、SharePoint 2013 Central Administration (SharePoint 2013 の全体管理画面) を表示して、[System Settings] - [Manage services on server] をクリックすると、以下の 2 つのサービスが開始されているはずです。(開始されていない場合は、これらを開始しておいてください。)

  • App Management Service (アプリ管理サービス)
  • Microsoft SharePoint Foundation Subscription Settings Service (Microsoft SharePoint Foundation 購読設定サービス)

つぎに、サービス アプリケーションを確認します。
SharePoint 2013 Central Administration を表示して、[Application Management] - [Manage service applications] をクリックします。ここで、上述した「App Management Service」と「Subscription Settings Service」のそれぞれのサービス アプリケーションと Proxy が作成されていることを確認してください。(実際、Preview 版のインストール直後のファーム作成の Wizard では、Subscription Settings Service の作成・開始はおこないませんので、このタイミングで作成・開始します。動作がおかしい場合なども作り直しましょう。)
もし、作成されていない場合は、手動で作成します。App Management Service と Subscription Settings Service のサービス アプリケーション (および、その Proxy) を作成する際は、SharePoint 2013 Management Shell (Windows PowerShell) を管理者権限で起動し、以降の通り実行します。(今回は、Managed Account を example\demouser1 と仮定します。)

補足 : 下記を実行する前に、Managed Account (管理アカウント) が作成済みであることを確認してください。SharePoint Server 2013 Preview の Configuration Wizard 直後に表示されるファーム作成のウィザード (Start Wizard) で Managed Account の作成を促されますので、そこで作成した Managed Account を使用します。
なお、Managed Account をあとから作成する場合や、作成しなおす場合は、New-SPManagedAccount コマンドを使います。(画面が表示されるので、ドメインのユーザー ID、パスワードを指定します。)

まず、Managed Account (管理アカウント) を取得します。

$account = Get-SPManagedAccount "example\demouser1"

つぎに、取得した Managed Account を使って、サービス アプリケーションとサービス アプリケーション プロキシを作成します。

$appPoolSubSvc = New-SPServiceApplicationPool -Name "SettingsServiceAppPool" -Account $account
$appPoolAppSvc = New-SPServiceApplicationPool -Name "AppServiceAppPool" -Account $account

$appSubscriptionService = New-SPSubscriptionSettingsServiceApplication -Name "Subscription Settings Service" -DatabaseName "SubscriptionSettingsServiceDB" -ApplicationPool $appPoolSubSvc
New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $appSubscriptionService

$appAppSvc = New-SPAppManagementServiceApplication -Name "Apps Management Service" -DatabaseName "AppMngServiceDB" -ApplicationPool $appPoolAppSvc
New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc

 

2. App Domain (アプリケーション ドメイン) の設定

上述の通り、SharePoint-hosted の Add-ins を配置すると、SharePoint Server 内に、Add-ins 独自のドメイン (App Domain, アプリケーション ドメイン) が作成されます。このための設定を On-Premise の SharePoint でおこなうため、DNS などの設定をおこなう必要があります。

まず、DNS サーバーにログインして、DNS Manager を開きます。[Forward Lookup Zone] のドメイン名 (今回は、example.com と仮定します) を右クリックして、[New Alias (CNAME)] を選択します。表示される画面で、[Alias name] に、*.<given name> を指定し、[Fully qualified domain name (FQDN) for target host] に使用している SharePoint サイトの FQDN を設定します。

補足 : 試しに、コマンド プロンプトで下記の通り入力し、ちゃんと SharePoint サーバーのホストから応答があることを確認してみてください。
ping hogehoge.spapps.example.com

つぎに、SharePoint 2013 Central Administration (SharePoint 2013 の全体管理画面) を表示して [Apps] カテゴリーをクリックし、表示される画面で [Configure App URLs] (アプリ URL の構成) をクリックします。
表示される画面の [App domain] に、上記で設定したドメイン名 (spapps.example.com) を設定し、[App prefix] に、今回は、「sharepoint」と入力しておきましょう。(「App prefix」は、任意の文字列で構いません。)

このように設定すると、sharepoint-hosted の Add-ins の URL として、下記の形式のドメインが使用されます。(xxxxx には、アプリケーションごとの固有の文字列が設定されます。)

sharepoint-xxxxx.spapps.example.com

なお、ブラウザーでこの URL を参照できるよう、Internet Explorer の設定 (接続の設定など) も確認しておきましょう。

 

3. App Catalog (アプリ カタログ) の作成

この設定は必須ではありませんが、App Catalog (上述) を使用する場合には作成が必要です。

App catalog を作成するには、SharePoint 2013 Central Administration の [Apps] カテゴリーの中から、[Manage App Catalog] (アプリ カタログの管理) をクリックします。[Create a new app catalog site] のチェックボックスを選択して [OK] ボタンを押し、表示される画面で下図の通り設定します。
下図では、「My App Catalog」という名前で http://<server name>/sites/appcatalog に App Catalog を作成し、ドメインのすべてのユーザー (Everyone) が app catalog のアプリケーションを参照できるように設定しています。

 

他にも、いろいろと技や留意点がありますが、この辺でやめときます。
日本語版の Store はまだ出てませんが、開発者の方は、是非、おもしろい Add-ins の作成と Submit をしてみてください。 

 

関連ナンバー

 

※ 変更履歴 :

2014/06/01  Autohosted の廃止に伴って記述を削除

2015/05/05  App for SharePoint (SharePoint 用アプリ) を SharePoint Add-ins (SharePoint アドイン) に名称変更

 

Leave a Comment
  • Please add 3 and 1 and type the answer here:
  • Post