私の名前はデニスで、DoxVisionの上級開発者として働いています。 この投稿では、SharePoint 2013の分野での開発に関連する一連の記事を開始します。Webアプリケーションの基本的な統合の可能性から始まり、SharePointストアでの公開まで、このトピックのさまざまな側面について説明します。 私が出会ったニュアンスと落とし穴を知ることは、初めて同様のタスクに直面する人々にとって有用です。
そのため、年表に従って、最初のタスクセットをどのように解決したかを説明します。既存のASP.NET MVCアプリケーション「Docsvision Easy Client」に基づいて、SharePoint 2013に統合して拡張する「Docsvision Client for SharePoint」を作成します。 Lightクライアント機能。
SharePoint 2013では、アプリの新しいモデルが登場しました。これは、ソリューションの古いモデルとは根本的に異なります。 しかし、怖がってはいけません-解決策は消えていません。 まず、使用するものを選択する必要があります：ソリューションまたはアプリ。 MSDNの記事は 、この問題に役立ちます。
私たちの選択は、Sharepointアプリにありました。 その時点での統合要件は、アプリを介して十分に実装できます。 将来、Sharepointストアに統合することを決定したとき、それは絶対に正しいことが判明しました。これは、以下の記事でわかるように、ソリューションをSharepointストアに配置できないためです。
これにもかかわらず、両方のアプローチの使用を禁止する人はいません。 次の記事では、アプリとソリューションを接続する方法を明確に説明します。
私たちの選択-SharePointアプリについて詳しく見てみましょう。 ドキュメントによると、いくつかの統合オプションがあります：SharePointホスト、自動ホスト、プロバイダーホスト。 アプリケーションがWeb APIではなく、クラシックバージョンのMVCであり、アプリケーションがオンプレミスで配信されることを考慮して、High-Trusted Provider-Hosted Appオプションを使用することにしました。 高信頼とは、Webアプリケーションが1対1の証明書を介してSharePointと通信することを意味します。 また、いわゆる低信頼モードもあります。これは、SharePointストアまたは会社のローカル企業アプリケーションディレクトリで使用されます。
そのため、SharePoint 2013を使用してトレーニングの場を設定しました。ここで、Microsoftからの最初の驚きに出会いました。アプリを作成してSharePointに実装することはできません。 まず、アプリを使用するためにSharePointを準備する必要があります。 準備プロセスの詳細については、MSDNを参照してください 。 ポイントについて簡単に説明します。
- SharePointサービスが実行されていることを確認します：ユーザープロファイルサービスアプリケーション、アプリ管理サービス
- 少なくとも1つのSharePointユーザープロファイルを確認し、そうでない場合は作成します
- 分離されたアプリケーションドメインを作成する
- アプリケーションドメインアドレスのDNSを構成する
3番目のポイントでは、より詳細に停止する必要があります。 アプリケーションドメインとは何ですか？ SharePointにアプリケーション（APP）をインストールすると、このアプリケーションにアクセスできる一意のアドレスが割り当てられます。 アドレスは次のようになります： http：// [アプリプレフィックス]-[アプリID]。[ドメイン名] / [サイトコレクションパス] / [アプリパス] /pages/default.aspx （アプリプレフィックスはファーム全体のアプリケーションプレフィックス） SharePoint app id-アプリケーションの一意の識別子。 ドメイン名-アプリケーションドメイン。 実際、アプリケーションドメインの構成は、アプリのプレフィックスとドメイン名の値の設定であり、サーバーの全体管理（アプリ->アプリのURLの構成）で設定できます。 これらのサービスを作成し、アプリケーションドメイン設定を構成するために、以下で少し改善されたPowerShellスクリプトを提供します。
$appDomain = "your app domain" $appPrefix = "your app prefix" $accountName = "your account name" $accountPassword = "your account password" net start spadminv4 net start sptimerv4 $existedAppDomain = Get-SPAppDomain $existedAppPrefix = Get-SPAppSiteSubscriptionName if (!existedAppDomain || !existedAppPrefix) { if (!$existedAppDomain) { Set-SPAppDomain $appDomain -ea:Stop } Get-SPServiceInstance | where{$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"} | Start-SPServiceInstance Get-SPServiceInstance | where{$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"} $User = $accountName $account = Get-SPManagedAccount -Identity $User -ea:Silently if(!$account) { $PWord = ConvertTo-SecureString –String $accountPassword –AsPlainText -Force $Credential = New-Object –TypeName System.Management.Automation.PSCredential –ArgumentList $User, $PWord $account = New-SPManagedAccount -Credential $Credential -ea:Stop } $appPoolSubSvc = Get-SPServiceApplicationPool -Identity SettingsServiceAppPool if (!$appPoolSubSvc) { $appPoolSubSvc = New-SPServiceApplicationPool -Name SettingsServiceAppPool -Account $account } $appPoolAppSvc = Get-SPServiceApplicationPool -Identity AppServiceAppPool if ($appPoolAppSvc!) { $appPoolAppSvc = New-SPServiceApplicationPool -Name AppServiceAppPool -Account $account } $appSubSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool $appPoolSubSvc –Name SettingsServiceApp –DatabaseName SettingsServiceDB $proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $appSubSvc $appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolAppSvc -Name AppServiceApp -DatabaseName AppServiceDB $proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc Set-SPAppSiteSubscriptionName -Name $appPrefix -Confirm:$false -ea:Stop }
何らかの理由で最後のコマンドが非常にリソースを消費し、サーバーの物理コンポーネント（ハードウェア）に対するSharePointのすべての最小要件を必要とする可能性があることを警告します。 私の場合、コマンドは数回実行されませんでした。 仮想マシンに十分な空きメモリがありませんでした。 以前にSharePointを再インストールした場合、既存のSettingsServiceDBおよびAppServiceDBデータベースファイルを削除する必要があります。
そのため、SharePointはアプリケーション用にインストールおよび構成されます。 ここで、Webアプリケーションが信頼されることをレポートするためにSharePointが必要です。 このプロセスについては、 ここで詳しく説明します 。
要するに、それは必要です
- 自己署名IIS証明書を作成します（この証明書はデバッグ段階にのみ適しています。完全なソリューションには、ドメイン証明書または商用証明書が必要です）
- pfxおよびcerファイルをアップロードする
- 証明書をSharePointにアップロードし、Webアプリケーションに関連付けます
最後の時点で停止し、より詳細にサインインします。 基本的に、次のPowerShellスクリプトを実行する必要があります。
$publicCertPath = "publicCertPath *.cer" $appId = "app Id Guid" $spurl ="SharePoint site url" $appPrincipalDisplayName = "your app pricipal name" $spweb = Get-SPWeb $spurl $realm = Get-SPAuthenticationRealm -ServiceContext $spweb.Site $certificate = Get-PfxCertificate $publicCertPath $fullAppIdentifier = $appId + '@' + $realm $principal = Get-SPAppPrincipal –NameIdentifier $fullAppIdentifier -Site $spweb if(!$principal) { $issuer = Get-SPTrustedSecurityTokenIssuer | where {$_.NameId -eq $fullAppIdentifier} if ($issuer) { Remove-SPTrustedSecurityTokenIssuer -Identity $issuer.Id -Confirm:$False -ea:Stop } New-SPTrustedSecurityTokenIssuer -Name $appPrincipalDisplayName -Certificate $certificate -RegisteredIssuerName $fullAppIdentifier -Confirm:$False -ea:Stop $principal = Register-SPAppPrincipal -NameIdentifier $fullAppIdentifier -Site $spweb -DisplayName $appPrincipalDisplayName } Set-SPAppPrincipalPermission -Site $spweb -AppPrincipal $principal -Scope Site -Right FullControl iisreset
このスクリプトを実行すると、$ appIdという識別子を持つリモートアプリケーションは、秘密キー（pfx）を持つ証明書を介してSharePointアイテムにアクセスできるようになります。
アプリIDを覚えておく価値があります。 これは、Webアプリケーションの識別子です。 後でweb.config WebアプリケーションでIssuerIdという名前で使用されます。
最後の手順は、SharePointアプリアプリケーションを作成することです。 このプロセスについては、後の記事で詳しく説明します。 プロジェクトを作成するとき、ウィザードは、発行者ID（私たちが生成したアプリID）、pfx証明書へのパス、および証明書のパスワードの多くのパラメーターを入力することを提案します。 作成したWebアプリケーションは、プロジェクトプロパティでVisual Studioソリューションの既存のWebアプリケーションに置き換えることができます。 WebプロジェクトでSharePointプロジェクトとWebアプリケーションを接続した後、パラメーターはweb.configファイルに入力されます。
<appSettings> <add key="IssuerId" value="your app id" /> <add key="ClientSigningCertificatePath" value="your pfx file path" /> <add key="ClientSigningCertificatePassword" value="pfx password" /> </appSettings>
また、有用なクラスSharePointContext.csおよびTokenHelper.csがWebアプリケーションプロジェクトに表示されます。 これらのクラスは、SharePointとやり取りするための非常に多くの機能を提供します。
これで統合が完了しました。 その後、デバッグを通じてSharePointアプリプロジェクトを開始すると、SharePointはまずアプリの権限を要求します。 特別なSharePointページ（appredirect.aspx）を通過して、アクセス許可を受け入れた後、Webアプリケーションのルートに到達します。 これで統合プロセスが完了したと考えられていますが、後で見られるように、多くの落とし穴が待っています。
次の記事では、 SharePointとのやり取りの整理方法（ドキュメントやSharePointのその他の要素の検索と読み取り）、アプリパーツの作成、アプリのローカライズ 、独自のRibbonTabの作成、アプリとソリューションのインストールの自動化、SharePointストアでの公開の準備方法について詳しく説明します。