SharePoint 2013 Search : Cross-Site Collection Publishing と Managed Metadata Navigation を使った Search Site の作成

こんにちは。

SharePoint 2013 では Search を活用した高度なアプリケーションがより柔軟に構築可能になっており、例えば、Windows Azure Virtual Machines (Azure VM) を使った Search-driven な商品検索サイトなど、高度な Web 上の検索サービスが、設定によって容易に構築できます。

今回は、以前、「Windows 8 store apps と SharePoint 2013 の連携アプリケーション開発」の投稿でも紹介した Managed Navigation を使った Search サイト (下図) の構築方法を解説したいと思います。

まったくプログラミングの話ではありませんが (仕事的に畑違いですが)、「Windows 8 store apps と SharePoint 2013 の連携アプリケーション開発」の投稿で、この手法を紹介すると書いて放置してましたので、今年の残作業として記載しておきます。

 

Site と Feature (機能) の準備

今回は、インターネット上に公開された商品検索 (Product Search) を例に紹介しましょう。
購買部門では、扱う商品を SharePoint リストを使って整理しています。そして、調達した商品 (Product) の情報を、専用のポータル (後述する発行サイト) を使って、エンドユーザー (顧客) に検索しやすい形式で提供します。ここで、SharePoint の検索 (Search) エンジンを使用します。

今回、購買部のサイト コレクションとして http://kkdeveva11/sites/purchase を構築し、元データとなる商品情報 (Product) を管理します。SharePoint は、顧客に公開されるデータ (Product など) を収集して、http://kkdeveva11/sites/productcenter という Publishing Site (発行サイト) で顧客に見やすい形式で公開します。

まず、購買部のサイト コレクション (http://kkdeveva11/sites/purchase) を作成します。
今回、このサイト コレクションで作成したデータを、上記の通り、発行サイト (http://kkdeveva11/sites/productcenter) で公開する必要があるため、まず、サイト コレクションの Feature (機能) の [SharePoint Server Publishing Infrastructure] (SharePoint Server 発行インフラストラクチャ) と [Cross-Site Collection Publishing] を Active にしておきます。

また、発行サイト (http://kkdeveva11/sites/productcenter) では、発行機能を有効にしておく必要があります。このため、発行サイトは、サイト テンプレートの Publishing Portal を使用して構築するか、あるいは、チーム サイトなどのサイトを構築してから、[SharePoint Server Publishing Infrastructure] (site collections feature) と [SharePoint Server Publishing] (site feature) の Feature (機能) を有効にしてください。(今回は、Publishing Portal のサイト テンプレートを使用してサイトを構築します。)

 

メタデータ (Term など) の作成

つぎに、Managed Navigation で使用する Term (上図の「Hard Disk」、「Memory」などの Category) を作成します。

購買部のサイト (http://kkdeveva11/sites/purchase) で、[Site settings] (サイトの設定) 画面を開き、[Term store management] をクリックします。([Term store management tool] が表示されます。)
Term を作成する際は、Group – Term set (Term) – Term の順番で作成しますが、[SharePoint Server Publishing Infrastructure] (発行インフラストラクチャ) がアクティブになっているサイト コレクションでは、「Site Collection – <site name>」という名前の Group があらかじめ作成されています。ここに、今回は、「Product Hierarchy」 の Term set を作成し、その下に、「PC Asset」という名前の Root Term と、さらに「Hard Disk」、「Memory」の各 Term を作成します。
下図のようになります。

Term は、一般に、ファーム全体で共有されますが、「Site Collection – <site name>」はサイト コレクション スコープの Term Group になっています。
そこで、このサイト コレクションの Term に、発行サイト (http://kkdeveva11/sites/productcenter) からアクセスできるようにするため、「Site Collection – <site name>」を選択し、右ペインの [Site Collection Access] に、下図の通り、発行サイトの URL (http://kkdeveva11/sites/productcenter) を追加しておきます。

つぎに、商品 (Product) のデータの入れ物を作成するため、購買部のサイト (http://kkdeveva11/sites/purchase) に、[Site columns] (サイト列) や [Site content types] (サイト コンテンツ タイプ) を作成します。今回は、Title (既存の SharePoint の列)、Item Price、Rollup Image (Publishing Infrastructure にある既存の列)、Item Category の 4 つの列を持つ「Product with Image」という Site content type を作成します。
まず、購買部のサイト (http://kkdeveva11/sites/purchase) で、[Site settings] (サイトの設定) 画面を開き、[Site columns] をクリックして下記の 2 つの列を作成します。

Item Price Currency (通貨) 
Item Category   Managed Metadata

なお、Managed Metadata である Item Category 列を作成する際は、下図の通り、作成画面の [Term Set Settings] で、上記で作成した「PC Asset」を選択しておきます。

つぎに、Site content type を作成します。[Site settings] (サイトの設定) 画面を開き、[Site content types] をクリックして、「Product with Image」という名前の Site content type を新規作成します。(この際、この Site content type の親として、[List Content Types] – [Item] を選択します。)
この Content type の列 (Column) として、下記の列を設定します。(いずれも、既存の site columns から選択して追加します。)

  • Title (既存)
  • Item Price
  • Rollup Image
  • Item Category

 

元データの作成

では、リストやデータの作成をおこないましょう。

購買部のサイト (http://kkdeveva11/sites/purchase) で、上記の「Product with Image」の Content type を使ってカスタム リストを新規作成します。(今回は、この作成したリストの名前を「Products」とします。)
SharePoint を使い慣れている方は説明不要だと思いますが、念のため作成方法を記載しておくと、カスタム リストを作成して、リボンから [List Settings] を選択し、表示される画面で [Advanced settings] をクリックして、[Allow management of content types?] で [Yes] を選択します。(これにより、リストで Content Type が使用可能になります。)

再度、[List Settings] の画面を表示すると Content Type を追加できるので、ここに、上記で作成した「Product with Image」を選択して追加します。さらに、既定で入っている「Item」の Content type は使用しないため、削除しておきます。

つぎに、作成したリスト (Products) の [List Settings] 画面を開いて [Catalog Settings] をクリックし、表示される画面で [Enable this library as a catalog] をオンにします。この設定により、後述する発行サイトからの Catalog の接続 (connect) が可能になります。(この設定は、必ずおこなってください。)
また、今回は、このリスト アイテムをエンドユーザー (顧客) に公開するため、[Enable anonymous access] ボタンを押して、匿名ユーザーによるアイテムの参照を可能にします。(企業内の検索サイトで公開する場合など、匿名ユーザーの参照が必要ない場合は、この設定は不要です。)
設定が完了したら、忘れずに [OK] ボタンを押して保存します。

リストの新規作成が完了しました。このリスト (Products) で新規アイテムを作成する際に、下図の通り画面が表示されるはずです。

アイテムに添付したイメージ (上図の Rollup Image) は、所定のライブラリーにアップロードされて公開されます。
また、上図の Item Category の右のアイコンをクリックすると、下図の通り、Term の選択画面が表示されます。

このリストに、リスト アイテムをいくつか登録しておきましょう。

 

クロールの実行

では、SharePoint の Search エンジンで収集するため、以降の手順でクロールを実行します。

[Central Administration] (全体管理) の画面を表示して、[Application Management] – [Manage service applications] をクリックします。表示されるサービス アプリケーションの一覧から、[Search Service Application] を選択して、[Manage] ボタンを押します。
表示される Search Administration 画面で、左から [Content Sources] を選択すると「Local SharePoint sites」のソースが表示されるので、このドロップ ダウンから [Start Full Crawl] を選択して Full Crawl を実行します。

データ量やマシン スペックにも依りますが、Crawl が完了するまで時間がかかるので、少し待ってください。(インストール直後でデータが少なければ、数分で完了するでしょう。[Refresh] をクリックすると、現在の状態が確認できます。Index Partition が壊れているなどでクロールが完了しない場合は、[Reset Index] でインデックス ファイルを作り直してください。)

 

Search site (発行サイト) の作成

つぎに、上記で収集 (クロール) されたデータに接続して、Product の一覧を表示する顧客用の発行サイトを設定します。

まず、上記で作成した発行サイト (http://kkdeveva11/sites/productcenter) に行き、[Site settings] 画面の [Term store management] をクリックして、下図の通り、「Product」という名前の Term を作成します。
今回、この Term の下に Category (購買部が作成した「Hard Disk」、「Memory」などの Item Category) を設定します。

補足 : 実は、「Windows 8 store apps と SharePoint 2013 の連携アプリケーション開発」では、Navigation Root で Category を扱いましたが、今回は、このあとの説明のために、上述の通り、「Product」という Term の下で Category を扱います。(このため、実行結果が少し異なってきますので、ご注意ください。)

発行サイト (http://kkdeveva11/sites/productcenter) の [Site settings] 画面を表示します。
サイトの発行機能 (SharePoint Server Publishing) がアクティブになっているサイトでは、下図のように [Manage catalog connections] のリンクが表示されるので、これをクリックします。

表示される画面で [Connect to a catalog] をクリックすると、下図の通り、接続可能な Catalog の一覧として、購買部のサイト (http://kkdeveva11/sites/purchase) の Products リストが表示されます。この [Connect] リンクをクリックします。

つぎに表示される画面で、接続方法の設定をおこないます。この画面で、下図の通り、[Navigation Hierarchy] として「PC Asset」 (Term set) を選択します。

さらに、[Navigation Position] として、今回は、上記で作成した「Product」の下に Category を作成します。

さらに、[Catalog Item URL Format] で、この発行サイトでアイテム (Product) を表示する際の URL の形式を指定します。
今回は、SEO を考慮し、下図の通り、「Title」をアイテムの URL として使用します。例えば、「Memory」のカテゴリーの「Matsucom」というアイテムの場合には、URL は http://kkdeveva11/sites/productcenter/memory/Matsucom となります。(このため、Title が重複などしないよう注意してください。もちろん、ItemId などを URI に指定することも可能です。)

補足 : 「Windows 8 store apps と SharePoint 2013 の連携アプリケーション開発」では、Title ではなく、ItemId を使用しています。(このため、REST で検索した際の結果にも、この URL が反映されています。)

完了したら、[OK] ボタンを押します。

 

Search-driven Site の確認

発行サイト (http://kkdeveva11/sites/productcenter) にアクセスすると、「Windows 8 store apps と SharePoint 2013 の連携アプリケーション開発」で紹介したような商品検索サイトが表示されます。(「Hard Disk」、「Memory」などは、このサイトの Managed Navigation として自動設定されます。)

補足 : 前述の通り、今回は、このあとの説明のために、「Product」の下に Category を作成したので、「Windows 8 store apps と SharePoint 2013 の連携アプリケーション開発」と異なる表示結果になっています。(「Windows 8 store apps と SharePoint 2013 の連携アプリケーション開発」では、[Navigation Position] として、Navigation Root に Category を作成しています。)

当然ですが、次回、クロールがおこなわれて検索結果が更新されると、ちゃんとこの発行サイトの情報も更新されます。

今回は、購買部による Product データのみをユーザーに公開しましたが、Catalog への接続は複数可能であり、サービス部門、ソフトウェア部門など、さまざまな領域の商品情報 (サービス) を、このエンドユーザー (顧客) 向けの発行サイトに集約して、下図のようにメニュー化できます。

 

さらなる応用

SharePoint Server 2013 では、この他にも、さらに進んだカスタマイズが可能です。
例えば、FAST と完全に統合されているため、結果出力の Page Template を編集して Refinement WebPart を挿入することで、上記のカテゴライズに加え、多角的な絞り込み (filtering) を組み合わせることができます。(この Page Template は、Connect された Category ごとにわけることも、共有することも可能です。)
下図では、製造元や製造年のサイト列 (Site columns) を追加して、これらを Refiner として使用しています。「Hard Disk」の Category の商品のうち、「Contoso Electric」が製造していて、かつ 2013 年製のもの、といった商品検索が可能です。

補足 : Search エンジンが収集した Property を Refiner として使用するため、あらかじめ、[Central Administration] (全体管理) から Search Service Application の管理画面を表示して [Search Schema] を選択し、対象の Managed Property を検索して、Refinable 属性を [Yes -active] に変更してください。(その後、再度、クロールを実行してください。)

また、今回は、SharePoint が提供している既定のページを使用していますが、もちろん、検索ページの UI (look & feel) も自由にカスタマイズできます。実際の商品検索のサイトでは、こうしたカスタマイズは必要不可欠となるでしょう。

きりがないのでこの辺にしますが、この他にも、いろいろな応用が設定ベースで (Non-programming で) 可能です。

 

さいごに

ちなみに、SharePoint Server 2013 では、上記の購買部のサイトと同様の設定がおこなわれたサイト テンプレートがサンプルとして提供されています。サイト テンプレートの [Publishing] – [Product Category] です。(上記のサンプルは、このサイト テンプレートを参考に紹介しました。なお、このサイト テンプレートは、Office 365 には入っていないようです。SharePoint Server のみで使用可能です。)

例えば、Windows Azure Virtual Machines (Azure VM) を使用して SharePoint Server を立てることで、VPN 接続を使って、企業内のサイトと、クラウドを通して顧客に公開する発行サイト (インターネット サイト) を上記の通り柔軟に接続できます。また、いくつか機能は制限されますが、Catalog への connect など基本的な機能は Office 365 でも利用可能であり、Office 365 でも、組織内 (企業内) への検索サイトの提供など、限定された用途でこうした検索体験が活用できます。

 

では、また来年 ! (良いお年を)

 

Windows 8 store apps と SharePoint 2013 の連携アプリケーション開発

こんにちは。

SharePoint 2013 の登場によって、SharePoint と接続するアプリケーションの実現範囲は大きく広がりました。そこで今回は、 こうした SharePoint と接続する Windows 8 store application を構築する際に陥りそうなポイントやノウハウを簡単にまとめてみたいと思います。

ここでは Search を例に紹介しますが、SharePoint 2013 からは、アイデア次第で、SharePoint が持っている機能を活用したさまざまなアプリケーションが構築可能です。

 

On-Premise の場合の認証 (Authentication)

例えば、SharePoint の WCM を使った Internet Site のような一般消費者向けの匿名アクセス (Anonymous) のサイトでは問題となりませんが、企業内やクラウド (Office 365) で管理している企業資産 (ドキュメントなど) と連携する、いわゆる業務アプリケーションを構築する場合には、認証に注意が必要です。

まず、オンプレミス環境 (企業内) に SharePoint Server 2013 をインストールした場合について、既定では Windows 統合認証が使用されますが、この場合には、Windows 8 store application 側で設定が必要です。
Package.appxmanifest を開き、下図の通り、[Enterprise Authentication]、[Private Networks] の Capabilities を有効にしておきます。(この設定をしないと、Wi-Fi や LAN 経由で SharePoint Server に接続した際に、AggregateException の例外が発生します。)

あとは、UseDefaultCredentials を使用して SharePoint Server に接続するだけです。(SharePoint へのアクセス方法についてのノウハウは後述します。下記は、C# のサンプルです。)

. . .
using System.Net.Http;
. . .

private void Button_Click_1(object sender, RoutedEventArgs e)
{
  HttpClientHandler handler = new HttpClientHandler();
  handler.UseDefaultCredentials = true;
  HttpClient cl = new HttpClient(handler);
  cl.DefaultRequestHeaders.Add("Accept", "application/json; odata=verbose");
  Task<HttpResponseMessage> res = cl.GetAsync("http://sharepoint01/sites/test/. . .");
  . . .
}

 

Office 365 の場合の認証 (Authentication)

2014/05 追記 : Office 365 の場合の認証については、現在 Preview 版がリリースされている Office 365 API が使用できます。「Office 365 API 入門」を参照してください。

Office 365 上のチームサイトの場合には、Azure Active Directory によるクレーム ベース認証をパスする必要があります。

この場合、自力で認証の流れを処理 (プログラミング) することになりますが、以前、Apps Team Blog でも紹介していた Omar さんのブログ (MSDN Blog) に、このサンプル コードが掲載されていますので、是非 参考にしてください。そして、素敵なことに、サンプル コードのダウンロードも可能です !

[Omar Venado’s Blog] Windows 8 Store Apps + new Office 365 Enterprise Preview (SharePoint Online)

http://blogs.msdn.com/b/omarv/archive/2012/10/25/windows-8-store-apps-office-365-enterprise-preview-sharepoint-online.aspx

 

そして、SharePoint 2013 へのアクセス !

さあ、認証がパスすれば、あとは SharePoint 2013 に接続してプログラミングするだけです。

アクセス方法として、CSOM (Client Side Object Model) の一部の API を呼び出すことも可能ですが、Windows 8 store apps では .NET のすべての API がサポートされているわけではないので、REST を使ったほうが無難でしょう。

特に、SharePoint 2013 から提供されている新しい REST API (/_api/ で始まる REST API) では、「SharePoint Add-ins の動作と概要」でも解説したように、リスト アイテムの取得・更新などの基本的な操作はもちろん、ワークフローの開始、さらには SharePoint 2013 の新機能である Social API の呼び出しなど、Object Model を通して実行可能なすべての操作を REST API で実行できます。(なぜなら、Client Object Model 自体が、最終的に、この REST API を呼び出しているからです。)

例えば、下図のように、SharePoint 2013 の Search エンジンと Managed Navigation を使って 商品検索サイトを構築したと仮定します。(このサイトの構築方法については、「SharePoint 2013 Search : Cross-Site Collection Publishing と Managed Metadata Navigation を使った Search Site の作成」に記載しました。)

これと同じことを Windows 8 store apps からアクセスして処理したい場合、まず、Navigation のカテゴリー (上記の「Hard Disk」、「Memory」) は、下記の通り REST で取得します。

Get http://kkdeveva11/sites/pubsite4/_api/navigation/menustate?mapprovidername='GlobalNavigationSwitchableProvider'
Accept: application/json;odata=verbose
{
  "d":
  {
    "MenuState":
    {
      "__metadata":{"type":"SP.MenuState"},
      "FriendlyUrlPrefix":"/sites/pubsite4/",
      "Nodes":
      {
        "results":
        [
          {
            "__metadata":{"type":"SP.MenuNode"},
            "CustomProperties":null,
            "FriendlyUrlSegment":"hard-disk",
            "IsHidden":false,
            "Key":"018f6777-5f6a-45d9-9153-15bc351e8c06",
            "Nodes":{"results":[]},
            "NodeType":1,
            "SimpleUrl":"",
            "Title":"Hard Disk"
          },
          {
            "__metadata":{"type":"SP.MenuNode"},
            "CustomProperties":null,
            "FriendlyUrlSegment":"memory",
            "IsHidden":false,
            "Key":"4e248650-8a05-408f-a02f-afec39f19e4e",
            "Nodes":{"results":[]},
            "NodeType":1,
            "SimpleUrl":"",
            "Title":"Memory"
          }
        ]
      },
      "SimpleUrl":null,
      "SPSitePrefix":"/sites/pubsite4/",
      "SPWebPrefix":"/sites/pubsite4/",
      "StartingNodeKey":"d006d992-f1f3-406f-b0b3-a87160831f33",
      "StartingNodeTitle":"Search Site Test",
      "Version":"2012-11-30T14:38:29.1342958Z"
    }
  }
}

さらに、「Hard Disk」のカテゴリーの商品一覧を取得するには、上記の太字の Key を使用して、下記の通りアクセスします。

Get http://kkdeveva11/sites/pubsite4/_api/search/query?querytext='owstaxidProductCatalogItemCategory:018f6777-5f6a-45d9-9153-15bc351e8c06'&selectproperties='Path,Title'
Accept: application/json;odata=verbose

補足 : 上記で、owstaxidProductCatalogItemCategory には、owstaxid + <managed metadata フィールドの内部名> を指定します。フィールドの内部名は、Site Setting で Site Column の URL を確認するなどして取得してください。

{
 "d":
 {
  "query":
  {
   "__metadata": {"type": "Microsoft.Office.Server.Search.REST.SearchResult"},
   "ElapsedTime": 15068,
   "PrimaryQueryResult":
   {
    "__metadata": {"type": "Microsoft.Office.Server.Search.REST.QueryResult"},
    "CustomResults": null,
    "QueryId": "313e2970-481e-47f3-b01c-5b2258b234f3",
    "QueryRuleId": "00000000-0000-0000-0000-000000000000",
    "RefinementResults": null,
    "RelevantResults":
    {
     "__metadata": {"type": "Microsoft.Office.Server.Search.REST.RelevantResults"},
     "GroupTemplateId": null,
     "ItemTemplateId": null,
     "Properties":
     {
      "results":
      [
       {
        "__metadata": {"type": "SP.KeyValue"},
        "Key": "GenerationId",
        "Value": "9223372036854775806",
        "ValueType": "Edm.Int64"
       },
       {
        "__metadata": {"type": "SP.KeyValue"},
        "Key": "ExecutionTimeMs",
        "Value": "47",
        "ValueType": "Edm.Int32"
       },

       skip (many metadata) ...

      ]
     },
     "ResultTitle": null,
     "ResultTitleUrl": null,
     "RowCount": 2,
     "Table":
     {
      "__metadata": {"type": "SP.SimpleDataTable"},
      "Rows":
      {
       "results":
       [
        {
         "__metadata": {"type": "SP.SimpleDataRow"},
         "Cells":
         {
          "results":
          [
           {
            "__metadata": {"type": "SP.KeyValue"},
            "Key": "Path",
            "Value": "http://kkdeveva11/sites/pubsite4/hard-disk/1",
            "ValueType": "Edm.String"
           },
           {
            "__metadata": {"type": "SP.KeyValue"},
            "Key": "Title",
            "Value": "Matsuffalo",
            "ValueType": "Edm.String"
           },

           skip (many metadata) ...

          ]
         }
        },

        {
         "__metadata": {"type": "SP.SimpleDataRow"},
         "Cells":
         {
          "results":
          [
           {
            "__metadata": {"type": "SP.KeyValue"},
            "Key": "Path",
            "Value": "http://kkdeveva11/sites/pubsite4/hard-disk/2",
            "ValueType": "Edm.String"
           },
           {
            "__metadata": {"type": "SP.KeyValue"},
            "Key": "Title",
            "Value": "Matsudata",
            "ValueType": "Edm.String"
           },

           skip (many metadata) ...

          ]
         }
        }
       ]
      }
     },
     "TotalRows": 2,
     "TotalRowsIncludingDuplicates": 2
    },
    "SpecialTermResults": null
   },
   "Properties":
   {
    "results":
    [
     {
      "__metadata": {"type": "SP.KeyValue"},
      "Key": "RowLimit",
      "Value": "10",
      "ValueType": "Edm.Int32"
     },
     {
      "__metadata": {"type": "SP.KeyValue"},
      "Key": "SourceId",
      "Value": "8413cd39-2156-4e00-b54d-11efd9abdb89",
      "ValueType": "Edm.Guid"
     },

     skip (many metadata) ...

    ]
   },
   "SecondaryQueryResults": null,
   "SpellingSuggestion": "",
   "TriggeredRules": {"results": [ ]}
  }
 }
}

 

このように、SharePoint 2013 からの新機能を活用すると、SharePoint の画面でおこなっていることとほぼ同じ機能が Windows 8 store apps でも実現できることがお分かりいただけるでしょう。

業務アプリケーションであればオンプレミスの SharePoint Server や Office 365 と連携したり、上記の商品検索のような Internet Front のアプリケーションの場合は、Windows Azure 上に SharePoint をインストールして連携させるなど、さまざまな構成が考えられます。

ドキュメント管理 (バージョン管理等)、検索、コンテンツ管理 (コンプライアンス管理など)、ソーシャルなど、SharePoint が持つ機能を活用して、サーバーの能力を生かした Windows 8 store application の構築が可能です。

 

 

IIS Express で、あれこれ

こんにちは。

このところブログを書いていないので、何か書いておきます。(こんな内容で、すみません. . .)

以前も記載しましたが、Visual Studio 2012 で Web プロジェクトを構築すると、既定で、デバッグ時に IIS Express が使用されます。
ご存じの通り、IIS Express を使うと、ASP.NET ハンドラーだけでなく、IISのハンドラー (または IIS モジュール) を作ったデバッグや、SSL のテストが迅速に可能など、いろいろと恩恵は多いのですが、気を付けておくこともいくつかあるので、以下に記載してみます。
(最近、Windows Developer Days の準備でバリバリ使ってますが、いろいろと思うところが多く . . .でも、愚痴ではありません . . .)

 

設定内容の一部は、別のファイルに書かれます . . .

まずは、基本の “き” ですが、以前、こちら でも記載した通り、IIS Express の設定は、以下に記載されています。

%userprofile%DocumentsIISExpressconfigapplicationhost.config

このため、SSL 有効化の設定など、プロジェクトにおこなった設定の一部は、ここに記載されます。(実施したはずの設定が、プロジェクトのフォルダー内のどのファイルを探しても見つからない場合、この設定ファイルを確認してみてください。)
配置の際のトラブルの原因ともなるので注意しておきましょう。

 

Visual Studio プロジェクトが、迅速にコピーできない !

これが一番嫌なところです。

まず、Visual Studio で Web アプリケーションのプロジェクト (ASP.NET、ASP.NET MVC、WCF 等々) を作る度に、上記の設定ファイル (applicationhost.config) にサイトが 1 つ追加されます。

このため、プロジェクトのコピーを作成して Visual Studio で開こうとすると、

「Web プロジェクト ‘…’ は現在 URL ‘http://…/&#8217; を使用するように構成されています。Web サーバーでは、この URL が別のフォルダー ‘…’ にマップされています。この URL がこの Web プロジェクトのフォルダーを指すように再マップしますか?」

という下図の警告 (エラー) が表示されます。(実行していない限り、普段ポート自体はあがっていませんが、設定ファイル内でポートが競合するためです。)

また、上図で、[はい] と押してしまうと、コピー元のプロジェクトで使っていたサイトの設定が コピー先のものに変更されるため、今度は、コピー元が使えなくなってしまいます。(これ、Visual Studio 2012 Beta だけの動きかもしれませんが. . . )

もちろん、Visual Studio 開発サーバーを使っていたとき (以前) には、Web プロジェクトのコピー / ペーストでポータブル (可搬的) にプロジェクトを扱うことができました。(もちろん、Visual Studio 2012 でも、プロジェクトの設定変更によって、昔のように Visual Studio 開発サーバーを使うことはできますが、できれば IIS Express を使いたいところです . . .)

この正しい対処方法としては、applicationhost.config を開いて、競合しないよう、サイトで使用しているポートをマップしなおすことですが、迅速に「お試し」したいと思っているときに、いちいちこんなことはしたくはありません。

そこで、あまり Microsoft の社員としてはお勧めしませんが (以下、自己責任でやってください)、コピー直後に、.csproj ファイルをメモ帳などで開き、下記の通り使用するポート番号を変更してから Visual Studio で開きます。この1 手間を入れるだけで、新しいポート番号で IIS Express のサイトを構築し、コピー元も、コピー先も、ちゃんと開くことが可能です。(う~ん、あとから書き直しても、あんま変わんないかな. . . )

<?xml version="1.0" encoding="utf-8"?>
<Project . . .>
  . . .

  <ProjectExtensions>
    <VisualStudio>
      <FlavorProperties GUID="{349c5851-65df-11da-9384-00065b846f21}">
        <WebProjectProperties>
          <UseIIS>True</UseIIS>
          <AutoAssignPort>True</AutoAssignPort>
          <DevelopmentServerPort>0</DevelopmentServerPort>
          <DevelopmentServerVPath>/</DevelopmentServerVPath>
          <IISUrl>http://localhost:49158/</IISUrl>
          <NTLMAuthentication>False</NTLMAuthentication>
          <UseCustomServer>False</UseCustomServer>
          <CustomServerUrl>
          </CustomServerUrl>
          <SaveServerSettingsInUserFile>False</SaveServerSettingsInUserFile>
        </WebProjectProperties>
      </FlavorProperties>
    </VisualStudio>
  </ProjectExtensions>
</Project>

なお、他人からプロジェクトをもらって開く場合にも、同様の点が課題となります。(ポート番号の競合に注意してください。)

 

そして、ゴミが残る . . .

上記で記載した通り、お試しの Web アプリケーションを作る度に、IIS Express のサイトが 1 つ増えます。つまり、開発を進める過程で、どんどんゴミの設定が増えていきます。(これは、実行しなくても、プロジェクトを作るたびに作成されます。)

私のように、頻繁にコピーして試しては消している方は、たまには設定を掃除しておきましょう。

 

IIS と同じではない ! (ユーザー コンテキスト、権限などに要注意)

IIS Express と言えども、ユーザー コンテキストは、Visual Studio 開発サーバーのとき (以前) と同じです。例えば、Windows Server 上の開発などで、Administrator で Visual Studio を開き、IIS Exptress を使ってデバッグすると、サーバー側のリソース接続では Administrator として接続されますので注意してください。(IIS にホストして見たら、動きが変わるという結果になります。)
「どのユーザーで動いているか」という点は、SQL Server などデータベースへのアクセスではよくハマる問題です。(どのみち、IIS の Application Pool の設定に依存するので、IIS にホストしているからと言って完璧ではないのですが . . .) IIS にホストする際は、connectionStrings や、Entity Framework における defaultConnectionFactory などを適宜変更してください。

あと、「IIS にあって、IIS Express にはない」という機能もありますので、注意してください。(“近い” ですが、必ずしも “一緒” と過信してはいけません。)

 

ネガティブなことを書きましたが、繰り返しになりますが、IIS Express は基本的に「できる奴」ですので、癖を理解して、うまく付き合っていきましょう ! (Visual Studio 2010 のときに、もっと使っておけば良かったです . . .)

 

SharePoint エンタープライズ検索 (4) : FAQs / さいごに

(このポストでは、書籍「VSTO と SharePoint Server 2007 による開発技術」(8章 : エンタープライズ検索と BDC) の補足情報を記載しています。基本的な内容 / 全体は、書籍を参照してください。) 

環境:
Office SharePoint Server 2007 (インフラストラクチャー更新プログラム含む)
または Search Server 2008

SharePoint エンタープライズ検索 (4回シリーズ)

こんにちは。

最後に、懇親会で頂いたその他のご質問事項について回答を記載します。(いくつかは、会場で回答させていただいた内容に補足しています)

エンタープライズ検索を実現できる SharePoint のエディション

書籍でも記載しているように、エンタープライズ検索では、Office SharePoint Server 2007 をご使用ください。Windows SharePoint Services 3.0 では、そのサーバー (SharePoint) のドキュメントしか検索対象にはできませんし、管理 UI も非常に限定的です。(懇親会でも参加者の方よりフィードバックがありましたが、このエディションで検索の細かな設定をしようとすると結構面倒です。確か、再クロールなども、stsadm.exe コマンドで実施する必要があったように記憶しています . . .)

無償環境で試してみたいという方は、Search Server 2008 Express Edition を使用すると良いでしょう。ただし、セミナーでお伝えしたようないくつかの制限事項がありますので、大きな企業などでは、この Express Edition は試用環境のつもりでお使いください。
尚、BDC (ビジネスデータカタログ) の使用には、Office SharePoint Server 2007 のエンタープライズ用ライセンス (ECAL) が必要となりますのでご注意ください。

各エディションで使用可能な機能の詳細については以下が参考になります。

Office Online : SharePoint Server 2007 エディション比較 :
http://office.microsoft.com/ja-jp/products/FX101758691041.aspx

Office SharePoint Server Search (osearch) のアカウント / アクセス権

検索に関して一般に多い問題として、検索時のアカウントの問題があります。
基本的なクロールの処理に失敗するケースならすぐに原因が突き止められるかもしれませんが、例えば、BDC を使用した検索などでも使用されているため (BDC の場合、対象の LOB データに接続できれば良いように思われるかもしれませんが、SharePoint の検索データベースなども同時に見に行っています)、この理由で BDC の検索が失敗するといったことも起こる場合があります。(この場合、「ローカルサーバーファームを検出できませんでした」 (Local Server Farm cannot be detected.) という例外が発生します。)

「ただインストールしただけなのに動かない !」といったケースも多く、インストール後の最初のクロールで、まずは、SharePoint のエラーログ (%ProgramFiles%Common FilesMicrosoft Sharedweb server extensions12LOGS) やクロールログを確認してアクセス権のエラー/例外などが発生していないか確認してみましょう。

エラーが発生するようであれば、SQL Server に (SQL Server Management Studio などで) 管理者でログインし、検索サービスで参照されるコンテンツデータベースや構成データベースなどのセキュリティをチェックしてみましょう。そして、コンテンツデータベースが osearch (Office SharePoint Server Search) のアカウントでアクセス可能か確認し、不可な場合には、以下の手順でデータベースの利用が可能となるようにアカウントの変更をおこなっておきましょう。

  1. [サーバーの全体管理] で [サーバー構成の管理] を選択し、[サーバーのサービス] をクリックします。
  2. サービスの一覧の中の [Office SharePoint Server Search] を選択し、使用されているサービスアカウントを確認し、必要に応じ変更します

尚、書籍にも記載していますが、エンタープライズ検索で使用されているサービスは、Office SharePoint Server Search (osearch) サービスであり、Windows SharePoint Services Search サービスではありません。

BDC (ビジネスデータカタログ) を使用した検索におけるトラブル

書籍にも記載していますが、こちらも検索に関するトラブルがいくつかあります。
BDC でアクセス権のエラーが発生する場合には、まず、以下の手順で、コンテンツアクセスアカウントとして充分な権限をもったユーザー (例えば、NetworkServices や LocalService 以外の、一般の権限を持ったアクセス可能なユーザー) が使用されているか確認しましょう。

  1. 共有サービス管理の画面で、[検索の設定] をクリックします
  2. [既存のコンテンツアクセスアカウント] を選択します

BDC では、個別のメソッドインスタンスの実行権限も設定されており、共有サービス管理の画面で [ビジネスデータカタログの権限] をクリックするとこの設定を確認/変更することができます。クロール時にもメソッドインスタンス (書籍でも記載している IDEnumerator メソッド) が実行されるため、ここで、メソッドインスタンスに対する充分な権限が付与されていないと、クロールの実行時にも権限不足でエラーになります。(通常は、管理者に対してすべての権限が付与されていますので、上記のコンテンツアクセスアカウントもまずは管理者に設定しておくと問題なくクロールされます。)

一部のファイルが検索できない ! 

SharePoint では非常に多くの IFilter を最初からサポートしていますが、書籍に記載したように、PDF, OneNote などについては追加の IFilter のインストール/設定が必要となります。下記のブログには、これらの最新情報が掲載されています。

http://blogs.msdn.com/ifilter/

また、独自のファイル形式などでは一般に IFilter の開発が必要となりますが、サードパーティが提供しているツールや、業界で著名なソフトウェアなどの場合、既に製品を提供しているベンダーや、パートナー企業、同一業界の他企業などにより IFilter が提供されている場合も多くありますので、検索してみると良いでしょう。例えば、国内でも AutoCAD 用の IFilter が開発されていたりします。( http://www.satori.co.jp/product/division/3037/3714.html )

また懇親会で、.mht (単一ファイルの Web アーカイブファイル) が検索できないというご質問がありました。この形式の IFilter は SharePoint インストール時にはちゃんとインストール/設定されています (検索可能です) が、試しに MSDN のサイトなどを .mht、あるいは .htm などで保存して SharePoint にアップロードして検索をしてみると、御質問者の方が言われていたように、確かに検索結果に表示されませんでした。
こうした場合には、クロールログを確認すると、各ドキュメントについてクロールできなかった原因が記載されています。今回の私のケースでは、該当のドキュメントで 「この URL のコンテンツはインデックス付けしない属性を持つため、サーバーによって除外されています」(Content for this URL is excluded by the server because a no-index attribute.) という警告が表示されていました。こうした場合は、このコンテンツ (HTML のソース) に、検索対象から除外するようタグなどが指定されている可能性があります。NOHTMLINDEX や、NOINDEX などの Meta タグが指定されていないかドキュメント内のソースを確認し、このタグを削除してドキュメントを登録して再クロールをしてください。(ある意味、これは、ファイングレインパーミッションによる正しい動作です。MSDN の場合、多くの文書で NOINDEX が指定されていました。)

トポロジー構成 (インデックスサーバー / クエリサーバー構成) における注意点

これはセミナーの中でご説明したポイントですが、クエリーサーバーが検索をおこなう際には、クロールで抽出されたインデックスカタログ (ファイル) と search property (データベース) が使用されています。書籍でも記載しているように、クエリーサーバーが複数に分散されている場合には、収集されたインデックスカタログもクエリーサーバーにコピーされますので、クエリーサーバーは複数への負荷分散が可能ですが、例えば、1 台のクエリーサーバーをインデックスサーバーと同一マシン上に配置し、もう1 つのクエリーサーバーを別のマシンに配置する、といった負荷分散をおこなった場合には、インデックスサーバーとクエリーサーバーが同一マシン上に存在していると判断し、インデックスサーバーはカタログのコピーをおこないません。
ファーム構成に際しては、この点を注意して構成をおこなうようにしましょう。

またクロール中にもデータベースにアクセスすることになるため、クエリーの利用頻度などによってはデータベースへの IO もボトルネックとして無視できない場合があるでしょう。こうした場合には、データベースのファイルグループをクエリー用とクロール用にわけるといった裏技もエンタープライズ検索のチームブログで紹介されていますので、規模の大きな検索ポータルを構成する場合には是非参考にしてください (下記)。

Microsoft Enterprise Search Blog : SQL File groups and Search
http://blogs.msdn.com/enterprisesearch/archive/2008/09/16/sql-file-groups-and-search.aspx

 

さいごに (FAST ESP へ)

FAST でどのようなレベルの機能が実現できるかはデモでご覧いただいた通りです。ここまでを理解 (書籍の内容含め) された方なら、FAST の威力が理解していただけるでしょう。

その特徴を復習しておきます。

  • デモでご覧いただいたように、FAST では、さらに高度で、多次元的な検索ストラクチャーを管理 しています。
    FAST による絞り込み、ナビゲーションなどの機能と同等のものを SharePoint 上で (カスタムに) 作成する場面を連想していただけるとその恩恵が容易におわかり頂けるでしょう。
  • とにかく、コマースサイトでの経験が豊富です。
    サイト名までは挙げませんが、国内外の著名なサイトでもいくつか活用されており、クエリー規模に対しての スケーラビリティの実績 の面でも商用レベルでの豊富な経験を有しています。
  • デモでご覧いただいたように SharePoint との連携が可能 です。
    SharePoint 上のコンテンツも検索対象にでき (最初にご説明した検索セキュリティも維持されます)、リレーショナルデータとの統合なども同様に可能で、さらに SharePoint 上の Web パーツとして UI も表現できます。
  • さらに FAST では、パイプライン方式の統一的で柔軟なカスタマイズ手法 を提供しています。
    検索エンジンにカスタマイズ機能を追加している、というよりも、カスタマイズを想定したフレームワークに基づいて構成されています。

FAST は、イベントやセミナーなどでも 時折 紹介されていますので、またご覧になる機会などありましたら是非参考にしてください。

 

SharePoint エンタープライズ検索 (3) : 検索精度のチューニング (関連性とランキング)

(このポストでは、書籍「VSTO と SharePoint Server 2007 による開発技術」(8章 : エンタープライズ検索と BDC) の補足情報を記載しています。基本的な内容 / 全体は、書籍を参照してください。) 

環境:
Office SharePoint Server 2007 (インフラストラクチャー更新プログラム含む)
または Search Server 2008

SharePoint エンタープライズ検索 (4回シリーズ)

こんにちは。

飛ばしたデモシリーズの 3 つ目として、相関性・関連性 (Relevance) と評価・ランキング (Ranking) のチューニング方法について補足します。
このデモは、ある程度お見せして (デモして) 理解して頂くことができたと思っていますが、時間があれば、サイトへの権限付与、タイトル変更、などなど、細かな動きを見て (数値なども変えてみて) 理解を深めて頂く予定でした。今回は、ランキングパラメータとシソーラスのデモまでしか実施できなかったので、以下に、その他の設定方法や数値目安などをまとめておきたいと思います。
(デモ / 動きはセミナーの中の実施しましたので、今回は省略します。)

シソーラス (設定箇所 : サーバー定義ファイル)

SharePoint のシソーラス (thesaurus) とは、例えば、「エンタープライズ検索 と エンタープライズサーチ は用語として同等に扱う」、「MOSS, WSS というキーワードが見つかったら、SharePoint で代用する」など、同義語 (類義語)、代替語の設定を意味します。
設定はサーバー上のファイルを編集します。日本語環境をお使いの皆さんは、%programfiles%Microsoft Office Servers12.0DataOffice ServerApplications[GUID]Config 下の tsjpn.xml を編集します。(記述方法、構文は、デモでお見せしたので省略します。) シソーラスの反映は、デモでお見せしたように、クエリ実行時に読み込まれるため、クエリサーバー上の Office SharePoint Server Search サービス の再起動 (net stop osearch & net start osearch) をおこなうことで反映されます。(再クロールは必要ありません。)

%programfiles%Microsoft Office Servers12.0Data の下に同様のファイル (tsjpn.xml など) が存在しますが、このファイルは、ファーム上のクエリーサーバーが追加される際に使用されるコピー元のファイルです。このため、この中のファイルを変更しても、該当のサーバーには直接反映されませんので注意してください。(ただし、新しくクエリーサーバーを作成する際にはこの設定が使用されますので、念のためこちらも変更しておくと良いでしょう。また、%programfiles%Microsoft Office Servers12.0DataApplications[GUID]Config にも同じファイルが存在していますので、編集場所には充分注意してください。)
尚、シソーラスの設定ファイルのうち、tsneu.xml は、すべての言語に適用されます。

注意点として、ファイルは、必ず Unicode で保存をおこなうようにしてください。もともと Unicode で保存されていますが、ファイルを削除して新規作成をした場合などには、必ず、「Unicode」 で新規保存するようにしましょう。
また、シソーラスの定義を 例えばプログラムなどを使って自動作成するような場合にも注意が必要です。定義内に、同一の文字が、別の形式で重複して定義されている場合には、そのシソーラスは無効にされる場合があります。
また検索時に、ダブルクォート (“) で括って検索をおこなうと (例 : “MOSS” など)、シソーラスを無視した検索をおこなうことが可能です。

シソーラスのその他の動作・設定などについては Enterprise Search Team Blog が参考になりますので、是非参考にしてください。

Microsoft Enterprise Search Blog : How to: Customize the Thesaurus in SharePoint Search and Search Server
http://blogs.msdn.com/enterprisesearch/archive/2008/09/23/how-to-customize-the-thesaurus-in-sharepoint-search-and-search-server.aspx


ノイズ (設定箇所 : サーバー定義ファイル)

抽出するキーワードとして除外したい文字は、シソーラスファイルと同じ場所のノイズファイル (日本語の場合は、noisejpn.txt) にキーワードを追加することで除外することができます。

注意点などについては、上記のシソーラスファイル同様です。

ワードブレーキング (設定箇所 : サーバー定義ファイル)

こちらは、セミナーの資料では省略していましたが、懇親会でご質問がありましたので記載しておきます (懇親会場でご回答させて頂きました)。

例えば、「ペドロ&カプリシャス」のようなキーワードを検索したい場合、インデックス収集時に、間の記号(アンパサント &)によって、「ペドロ」と「カプリシャス」でキーワードが自動的に区切られます。こうした場合には、カスタムディクショナリー(Custom Dictionary) を設定することで、こうした自動ブレークを阻止し、「ペドロ&カプリシャス」で完全マッチの検索をおこなうことができます。

カスタムディクショナリの設定ファイルを配置する場所は、シソーラスファイルとは異なり、%programfiles%Microsoft Office Servers12binCustomLANG.lex です。(日本語の場合は、Custom0011.lex です。) 設定を反映させるには、インデックスの再収集以外に、クエリー時のブレーク箇所も正しく認識させる必要があるため、ファイル編集後は、 Office SharePoint Server Search サービス (osearch) の再起動と、再クロールの双方をおこなってください。
カスタムディクショナリの作成方法については、以下の記事が参考になります。

TechNet : ユーザー辞書を作成する (Office SharePoint Server 2007)
http://technet.microsoft.com/ja-jp/library/cc263242.aspx

実は、懇親会では、「ワードブレークを阻止したい」 というご質問ではなく、逆に 「ワードを分割して認識させられないか」 というものでした。私は、この回答として、「カスタム辞書 (上記の CustomLANG.lex) を編集することで認識させられる可能性があるかもしれない」 とお答えしてしまいましたが、すみません、動作を確認してみたところ、本来分割されていないワードを分割して認識させることは不可能でした。(この予測は誤っておりました。申し訳ありません . . .)
業界固有の専門用語などで、どうしても意図的に区切りたい場合 (ワードブレークしたい場合) には、以下の要領でシソーラスファイルを編集するという方法が近道でしょう。

例 : 「クラウド」と検索したら、「クラウド」以外に「クラウドコンピューティング」もヒットさせる場合

 . . . 前半省略 . . .
  <replacement>
    <pat>クラウド</pat>
    <sub>クラウド</sub>
    <sub>クラウドコンピューティング</sub>
  </replacement>

 . . . 後半省略 . . .

なお、ワードブレーキングのメカニズムを理解しておくことは重要ですので補足のために記載しておきますと、空白 (日本語の空白も含む) や、「で」、「の」などの接続文字、「&」、「-」 の記号などなどを元に自動でワードがブレークされ、上記ご質問者の方にもお話させて頂きましたが、アンカー (<A …>…</A>) の箇所も 1 語と見なします。(特に、アンカーでは、リンク先にもキーワードが含まれる場合、そこを評価・ランキングの高いキーワードであると認識します。)

尚、空白文字は抑制 (ブレーク箇所として認識しないように抑制) できないので注意してください。


「権限のあるページ」と「権限のないサイト」 (設定箇所 : 共有サービスプロバイダの管理)

登録されているドキュメントの優先順位が “サイトなどによって明確に異なる” 場合、共有サービスプロバイダの [検索の設定] 画面の [権限のあるページ] (authoritative page) の設定を使ってランキングの優先度を変えることができます。
この設定ページには上位 3 つまで権限のあるページを設定可能で、ここに設定したページからのクリック数が近いドキュメントほど高いランキングで表示されるようになりますので、重要なサイト (例 : 完成ドキュメントを入れるサイト、など) はここに URL を設定しておくと良いでしょう。
「権限のあるページ」 だけでなく、評価・ランキングを下げるための 「権限のないサイト 」(non-authoritative site) を指定することもできます。
(いずれも、設定はすぐに反映されます。)

ランキングパラメータ (設定方法 : API)

こちらは、デモでお見せした内容です。
Web ページ、Word 文書、Excel ファイル、など、”ファイルの種類” によって優先度を決めるためのパラメータで、内部の検索アルゴリズム (Okapi BM25) で使用されています。このパラメータは API (プログラミング) でのみ設定・変更できます。(海外には、こうした値を編集するためのツール・ユーティリティなども存在しています。)
変更方法については、デモでお見せしたので省略します。。。と言いたかったのですが、コードをお配りしていなかったので再掲しておきます。(下記では、pptx のパラメータを 150 に下げています)

static void Main(string[] args)
{
    SearchContext context;
    using (SPSite site = new SPSite(@”http://localhost/&#8221;))
    {
        context = SearchContext.GetContext(site);
    }
    Ranking rnk = new Ranking(context);
    RankParamCollection rnkParmCol = rnk.RankingParameters;
    foreach (RankingParameter rnkParm in rnkParmCol)
    {
        if (String.Compare(rnkParm.Name, “filetypepriorppt”, true) == 0)
            rnkParm.Value = 150;
    }
}

このランキングパラメータですが、デフォルトでは、Webページ、ppt、doc、xml、xls、txt、リストアイテム の順番で下がっていきます。各値の詳細は上記のように API を使って確認することができますが、だいたいの目安として、Web パージが 166.983、txt が 153.051 といった具合に小刻みに低下していきます。

設定後は、再クロールが必要です。

管理プロパティの重み付け (設定方法 : API)

書籍でも記載している「管理プロパティ」ですが、実は、管理画面上に表示されていない “Weight” という属性を内部で持っており、この値が検索アルゴリズムで使用されています。優先度を上げたい管理プロパティがある場合には、API を使用してこのプロパティ値を変更することが可能です。
セミナーでもご説明したように、このプロパティ値は、実は、非常に影響が大きいので変更時は注意してください。

管理プロパティの Weight 値 は、0 以上の値を指定可能で、大きいほど優先されます。デフォルトでは、Author (8.215), Filename (29.43), Title (75.855) 以外は 0 が設定されています。つまり、検索エンジンでは、タイトルや URL にキーワードが含まれる場合は、よりランキングが高く評価 されますのでおぼえておきましょう。

管理プロパティの Length Normalization (設定方法 : API)

「管理プロパティ」には、Length Normalization というもう 1 つの属性も隠れています。
例えば、書籍の「本文」(body) と「タイトル」を比べた場合、キーワードの出現回数だけを見て評価・ランキングしてしまうと、「本文」のほうがヒットする数が当然多くなるでしょう。この調整をおこなうのが、この Length Normalization (日本語で書くなら、文字列長に応じた正規化 ?) です。
この値も、ランキングパラメータや Weight 同様に、API を使った変更が必要です。

精度の高い検索 (設定方法 : Web パーツ、共有サービスプロバイダの管理)

こちらはセミナーの資料に記載していましたが、(時間の関係で) 完全に説明を飛ばしてしまい失礼致しました。(設定に関し、いろいろと話すべきことが多く、時間がかかるので説明を省略してしまいました。)
Web パーツに [精度の高い検索結果] Web パーツがありますが、こちらを使用して表示結果のランキングをカスタマイズすることが可能です。検索センターと共に使用すると、おすすめコンテンツ (Best Bets) の設定などいろいろな設定が可能ですが、ここではランキングに関連する内容のみ記載します。

管理プロパティ (メタデータプロパティ) の設定画面に HightConfidenceMatching や、HightConfidenceDisplayProperty1, HightConfidenceDisplayProperty2, . . . , HightConfidenceDisplayProperty15 という名前のプロパティが入っていますが、[精度の高い検索結果] Web パーツを使用すると、クエリー時に、この HightConfidenceMatching に設定されている管理プロパティの内容とキーワードがマッチしている場合、その結果は優先的に上位に表示されるようになります。また、その際に表示される結果フィールドとして、管理プロパティのHightConfidenceDisplayProperty1 – HightConfidenceDisplayProperty15 が使用されます。

このように記載すると「なーんだ、これ、使えるじゃん!」と思われるかもしれませんが、1 つ大切な落とし穴があります。配布資料の中にも記載していたのですが、この「精度の高い検索」という仕組は、デフォルトでは People Search 用の設定になっています。つまり、People Search 以外で使用するには、Web パーツの側もデモでお見せしたように、難解な xslt の変更などをおこなう必要があるので注意してください。

検索用語のステミング (設定箇所 : Web パーツ)

検索用語のステミングとは、例えば、「走る」、「走った」、「走れ」などを同一のキーワードとして扱って検索する方法のことです。(こうした設定をシソーラスを使って設定すると、すべての動詞を登録することになり大変です。) この機能は言語によっては使用できませんが、「日本語」ではちゃんと使用できますので安心してください。
この設定は、[主要な検索結果] Web パーツの [検索用語のステミングの有効化/無効化] を設定することで有効にできます。日本語環境ではデフォルト「オフ」になっています。
なお、この設定を「オン」にした際は、上記のシソーラスの設定などと相性が良くない場合がありますので注意してください。 

 

以上がチューニングの各要素になりますが、この他にも、利用者にとっての「検索性」を司る設定として、共有サービスプロバイダにおけるクロールスケジュール (特に、頻度です) や [検索結果の削除] の設定なども影響してくるでしょう。
また、懇親会でもご質問がありましたが、検索結果の Web パーツにおける [重複した結果を削除する] をチェックすると、コピーされた結果など、”同じ” (とみなされる) コンテンツが丸めて表示されますので、こういった細かな点もハマるポイントです。(注意しないと、「ほしいものが出て来ない !」という結果になります。)
また、上記でもふれていますが、タイトル、URL、ファイル名のつけ方など、コンテンツの作成方法にも大きく影響しますし、実は URL の深さも影響しています (一般に深いほど評価は低くなります)。こうした点は、一般のインターネット検索における評価でも重要な要素となっていますので、コンテンツクリエーターの方もこうした仕組みを知っておいて損はないでしょう。(ご説明したように、一般のインターネット検索エンジンでは、さらに多くの指標が使われています。)

 

SharePoint エンタープライズ検索 (2) : フェデレーションと Windows 7

(このポストでは、書籍「VSTO と SharePoint Server 2007 による開発技術」(8章 : エンタープライズ検索と BDC) の補足情報を記載しています。基本的な内容 / 全体は、書籍を参照してください。) 

環境:
Office SharePoint Server 2007 (インフラストラクチャー更新プログラム含む)
または Search Server 2008
Windows 7 Beta (Build 7000)

SharePoint エンタープライズ検索 (4回シリーズ)

こんにちは。

今回はフェデレーションについてです。
セミナーの中で、フェデレーションのアーキテクチャの説明と動きのデモはお見せしましたが、Windows 7 の場合のデモと、双方の相違については、考え方の説明のみで、実際にデモをお見せすることはできませんでした。そこで、今回はこの辺りの説明を補足しておきます。

フェデレーションでは、Open Search という RSS ベースの仕様に準拠したサービスならば何でも統合可能です。(セミナーでもご説明したように、G***** などの Open Search に準拠していない検索サービスも統合させたい場合には、同仕様に準じた出力をおこなうハブページを作成するといったことで統合できるケースもあります。)

まずは、Windows 7 との比較のために、セミナーのデモでもお見せした SharePoint (もしくは Search Server) 上でのフェデレーションを再度復習しておきましょう。(セミナーでもご説明しましたが、フェデレーションの仕組みを使用するには、上述の通り、Microsoft Office SharePoint Server 2007 に Infrastructure Update の更新プログラムを適用するか、あるいは Search Server 2008 が必要ですのでご注意ください。無償環境で試したい方は、Search Server 2008 Express Edition を使用できます。)

  1. 例えば、検索フェデレーションコネクターのページ (http://www.microsoft.com/japan/enterprisesearch/connectors/federated.aspx) に行って、Yahoo のフェデレーション定義ファイル (Federation Location Definition file) である Yahoo.FLD をダウンロードしてみましょう。
    (Windows Live については、デモでお見せしたように、既に SharePoint 上に組み込まれています。)
  2. 共有サービスプロバイダーの設定で、[検索の管理] 画面を表示して、[フェデレーション場所] をクリックします。
    下記画面が表示されるので、[場所のインポート] を選択して、先ほどダウンロードした Yahoo.FLD を選択して、定義情報をインポートします。

  3. 検索用の簡易的なページを作成してみましょう。
  • Web パーツページを新規作成します
  • このページに、[Web パーツの追加] をクリックして [検索ボックス] を選択し、検索条件を入力するための入力欄を挿入します
  • 挿入した Web パーツで、[編集] – [共有 Web パーツの変更] を選択して、[その他] – [対象の検索結果ページの URL] に、このページ (同一ページ) の URL を設定します
  • このページ上に、今度は、[主要な検索結果] Webパーツと、[フェデレーション検索結果] Web パーツを挿入します。
  • [フェデレーション検索結果] Web パーツの [共有 Web パーツの変更] 画面を表示し、[場所] のドロップダウンに「Yahoo」がありますので、これを選択しましょう。 

検索をおこなうと、下図のように、SharePoint エンタープライズ検索を使用したイントラネット上の検索結果 (左) と Yahoo サイトでの検索結果 (右) が表示されます。


(書籍にも書いているように、ページングを使用する場合にはページング用のWebパーツが必要など、実際には他にもいくつかのWebパーツが必要なので注意してください。ここでは、あくまでもサンプルとして作成しています。)

上記で、フェデレーションの設定画面を使用して、フェデレーションの定義情報を新規に作成し、エクスポート (.fld ファイルに出力) することも可能です。つまり、一度作成した定義情報は、再利用することができます。

ここで注意すべき点は、セミナーでもお伝えした通り、結果セットは、Web パーツとして分離される という点です (統合して表示することはできません)。セミナーでご説明したフェデレーションのアーキテクチャを理解していれば納得して頂けるでしょう。ランキング (Ranking) などの設定もフェデレーション先ごとに個別に設定をおこなう必要があるので注意してください。

さて、SharePoint によるフェデレーションを見て頂いたところで、つぎに、このフェデレーションによる検索を Windows 7 の OS 上でもおこなうことができますので見ていきましょう。

  1. Windows 7 を起動してログインし、フェデレーション用の定義ファイルをダウンロードします。
    今回は、Windows 7 Forum のサイト (http://www.sevenforums.com/tutorials/742-windows-7-search-federation-providers.html) から Yahoo.osdx をダウンロードします。
  2. ダウンロードした Yahoo.osdx をダブルクリックすると、エクスプローラの左に Yahoo 検索用のリンクが表示されます。このリンクをクリックし、右上に検索文字列を入力すると、Yahoo での検索結果がエクスプローラ上に表示されます。
    また、[整理] – [レイアウト] – [プレビューペイン] を選択すると、プレビュー用のウィンドウが表示され、検索結果の一覧とプレビューを同時に参照することもできます。

 

セミナーでもご説明したように、この SharePoint (または Search Server) と Windows 7 の双方の定義ファイル (.fld ファイルと .osdx ファイル) については、中身のテキストを見て頂くとわかりますが、それぞれ異なる仕様で記述されています。SharePoint で使用/作成したものをそのまま使用することはできませんので注意してください。(無論、ひとたび統合されれば、同じアーキテクチャで動作します。)

 

SharePoint エンタープライズ検索 (1) : 検索セキュリティのアーキテクチャ

(このポストでは、書籍「VSTO と SharePoint Server 2007 による開発技術」(8章 : エンタープライズ検索と BDC) の補足情報を記載しています。基本的な内容 / 全体は、書籍を参照してください。) 

環境:
SharePoint Server 2007 (インフラストラクチャー更新プログラム含む)
または Search Server 2008

SharePoint エンタープライズ検索 (4回シリーズ)

こんにちは。

SharePoint Developers Forum にご参加いただいた皆様、ありがとうございました (満員御礼)。懇親会では、SharePoint だけの Lighting Talks 集でも実施したくなるほど、いろいろな Tips や Pain Point 等々を伺うことができました。
また是非実施していければと思いますのでよろしくお願いします。

さて、私のセッション (= エンタープライズ検索の話) で、例によって時間におさまらなかった (= ブログで書くとお約束した) 箇所について順次記載していきます。

お伝えしました通り、書籍では「開発技術」を説明するということで、検索のアーキテクチャ(抑えておくべきツボ)を「ザクッ」と説明して、カスタマイズ/開発手法の考え方 (idea) を「ドップリ」と記載しましたので、このセッションでは、その「ザクッ」としか説明していないアーキテクチャや管理/設定手法などを「ドップリ」と説明しました。
まずは、デモを飛ばした、セキュリティトリマの作り方についてです。

セッションに参加されていない方のために、最初に「検索のセキュリティって何 ?」という点を簡単に復習しておきます。

インデックスサーバーから特定のアカウントでドキュメントをクロールし、それを問い合わせの際にクエリーサーバーで処理するだけでは、例えば、人事情報などの従業員に見せたくない情報がハクジツのもとにさらされることになるかもしれません。一方、こうした情報をすべてクロール対象から外すと、「あるドキュメントは技術部だけでしか見れない」とか、「あるドキュメントは正社員は見れるが、派遣の人は見れない!」など、さまざまなドキュメントが検索対象から外されてしまうでしょう。
こうした課題を解決する方法として、書籍でも記載しているセキュリティのトリミング (Trimming) と呼ばれる処理が活躍します。

セキュリティのトリミングは 2 箇所で制御できます。
1 つは、インデックスの作成時に、抽出するコンテンツを制限したり、提供する ACL (アクセス制御リスト) を加工するなどして、コンテンツのアクセス権を制御する方法です (Crawl Time Trimmimg)。ただしこの方法は、クロールの方法そのもののカスタマイズ、すなわち、プロトコルハンドラそのものを開発することと同じです。
一方、SharePoint、Web コンテンツ、共有フォルダ、Notes、など、既にプロトコルハンドラが提供されているものに対して独自のトリミングの処理だけを記述したい場合には、インデックスの作成時ではなく、クエリーの際に表示するドキュメントを制御 (Query Time Trimmimg) することができます。

スライドを再掲しておきます。

このクエリー時のカスタムセキュリティトリマーは、以下の手順で構築します。

  1. トリマをコーディング (プログラミング) してビルドします。(ISecurityTrimmer の実装をおこないます。)
  2. 作成したトリマーの dll を GAC へ登録します。
  3. クロールルールを作成します。
  4. stsadm -o registersecuritytrimmer コマンドを使用して、セキュリティトリマーを登録します。
  5. iisrerset を実行します。

では、その実装方法を具体的にみていきましょう。

ISecurityTrimmer の実装

ここでは、サンプルとして、基本認証が設定されている収集結果 (クロールされた情報) に対し、「もしAdministrator でなければ、 特定のユーザーID/パスワードでそのドキュメントに接続をして、接続できるものは検索結果として表示し、できないものは非表示にする」 というトリマーを作成してみましょう。

Visual Studio でクラスライブラリのプロジェクトを新規作成し、System.Web.dll, Microsoft.Office.Server.Search.dll を参照追加して、以下のコードを記述します。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Collections;
using Microsoft.Office.Server.Search.Query;
using System.Web;
using System.Net;

namespace MyWebSecurityComponent
{
    public class MyWebSecurityTrimmer : ISecurityTrimmer
    {
        #region ISecurityTrimmer メンバ

        public System.Collections.BitArray CheckAccess(IList<string> documentCrawlUrls, IDictionary<string, object> sessionProperties)
        {
            // 取得した URL の数分の Result コレクションを生成
            BitArray resultArray = new BitArray(documentCrawlUrls.Count);

            // ループしてそれぞれをチェック
            for (int i = 0; i < documentCrawlUrls.Count; i++)
            {
                string url = documentCrawlUrls[i];
                string currentUser = HttpContext.Current.User.Identity.Name;
                // “Administrator” なら権限を与える
                if (currentUser.EndsWith(“Administrator”))
                {
                    resultArray[i] = true;
                    continue;
                }
                // それ以外なら、そのサイトに
                // 特定のユーザーID/パスワードで接続して確認
                resultArray[i] = ConnectCheck(url);
            }

            return resultArray;
        }

        public void Initialize(System.Collections.Specialized.NameValueCollection staticProperties, Microsoft.Office.Server.Search.Administration.SearchContext searchContext)
        {
            // 何もしない . . .
        }

        #endregion

        // ヘルパー関数
        private bool ConnectCheck(string url)
        {
            bool res = false;
            HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url);
            request.Credentials = new NetworkCredential(@”DemoUser”, “P@ssw0rd”);
            request.AllowAutoRedirect = false;
            try  // 例外が発生しないように、Exception もちゃんと拾う
            {
                using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
                {
                    // リダイレクトの場合 (リダイレクト先に行ってさらにチェック)
                    if (response.StatusCode.Equals(HttpStatusCode.Found) ||
                        response.StatusCode.Equals(HttpStatusCode.Redirect) ||
                        response.StatusCode.Equals(HttpStatusCode.Moved) ||
                        response.StatusCode.Equals(HttpStatusCode.MovedPermanently))
                    {
                        res = ConnectCheck(response.Headers[“Location”].Trim());
                    }
                    // 成功の場合
                    else if (response.StatusCode.Equals(HttpStatusCode.OK))
                    {
                        res = true;
                    }
                    // それ以外
                    else
                    {
                        res = false;
                    }
                }
            }
            catch
            {
                res = false;
            }

            return res;
        }
    }
}

署名を添付してリビルドをおこない、作成された dll を GAC に登録します。 

つぎに、共有サービスプロバイダーの管理画面を使用して、このコンテンツ (該当の URL のコンテンツ) のクロールルールを作成します。(今回の場合、基本認証を使用してクロールをおこなうよう既に設定しているはずなので、この作業をおこなう頃には、既に該当のクロールルールは存在していることでしょう . . .) 

以下のコマンドを実行してセキュリティトリマを SharePoint に登録します。(下記で、id には 0 以上の一意なトリマーの ID を設定します。また typeName には、上記でコンパイルしたアセンブリ/クラスの厳密名を記載し、rulePath にはクロールルールの作成時に入力したパスを指定します。)

pushd %programfiles%common filesmicrosoft sharedweb server extensions12bin
stsadm -o registersecuritytrimmer -ssp SharedServices1 -id 0 -typeName “MyWebSecurityComponent.MyWebSecurityTrimmer, MyWebSecurityComponent, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8ba647f8ee32389a” -rulepath http://kkdeveva03:81/TestWeb1/*
popd
iisreset

上述の通り、このカスタムのセキュリティトリマはクエリーの際に実行されます。しかし、クロールルールをリセットするため、必ず、再度クロールをやりなおしてください。 
これで、セキュリティトリマーの登録が完了し、検索をおこなうと、検索結果は、指定した通りに絞り込みがおこなわれて表示されます。

なお、登録されたセキュリティトリマは、上記の id を使用して以下のように削除できます。

stsadm -o unregistersecuritytrimmer -ssp SharedServices1 -id 0

上記のプログラムコードですが、あくまでもサンプルですのでそのまま真似しないでください。というのも、現実の開発では、パフォーマンスの影響も考慮してセキュリティトリマーの登録を判断すべきでしょう。
また、いい加減なトリマーを登録して例外が発生してしまうと、クエリーが失敗する羽目になるので注意が必要です。

Webコンテンツ の場合について

Web コンテンツ (SharePoint ではありません) のクロールでは、エントリーポイントからリンクされたドキュメントが次々とクロールされます。(つまり、エントリーポイントとつながっていないページ/ドキュメントは対象になりません。)

このクロールでは、基本認証、フォーム認証などで保護された Web コンテンツもクロールの対象にできます。こうした認証のかかったコンテンツをクロールする場合には、クロールルールを作成して、そのルールに認証情報を設定します。(Search Server 2008、及び Microsoft Office SharePoint Server のInfrastructure Update 以降では、フォーム認証/クッキーの場合もルール設定の画面で設定できます。以前は、こうした場合、別途コードを記述する必要がありました。)

一方、クロールされたこれらのコンテンツは、書籍でも記載している通り Security Descriptor をサポートしていませんので注意してください。このため、基本認証、フォーム認証などで保護されたこれらのコンテンツは、カスタムのセキュリティトリマーを作成/登録しておかないと、検索をおこなうすべてのユーザーに公開されてしまいます。
ここで 1 つの問題点としては、基本認証、ダイジェスト認証などのような ユーザーID / パスワード方式の認証の場合です。SharePoint 上では、多くの場合、Windows 認証を使用しているでしょうから、「パスワード」の文字列を抽出して渡すといったカスタムトリマーの作成はできません。よって、実際の環境構築の際には、別の方法 (あるいは何らかの業務上のルール作成、など) を検討する必要が生じるでしょう。

BDC の場合について

BDC のセキュリティトリミングも、アプリケーション定義ファイル (.xml) に AccessChecker メソッドインスタンスを作成するという点を除いては同様に登録作業をおこなうことで設定できます。(つまり、上記同様、クロールルールを作成して、stsadm -o registersecuritytrimmer を実行します。)

つまり、セッションでもお伝えしたように、BDC では、上記の ISecurityTrimmer の AccessCheck メソッドが BDC 内で定義されているという点を除き、まったく同様の概念でカスタムセキュリティを設定することが可能です。BDC では、stsadm -o registersecuritytrimmer コマンドで使用するクラスは、Microsoft.Office.Server.ApplicationRegistry.Search.QueryProcessorSecurityTrimmer というビルトインのクラスです。

Notes コンテンツの場合について

Notes のプロトコルハンドラーにも Security Descriptor は実装されており、権限情報は Windows の ACL に変換されます。ただし、セッションでもお伝えしたように、Notes 上のグループの情報 (グループ単位で設定されたセキュリティの情報) は変換の対象ではないので注意が必要です。

また書籍にも記載したように、Notes のクロールでは、対応バージョンに注意してください。懇親会でも、同様のフィードバックを頂きましたが、このバージョンの問題でハマってしまうケースは大変多く存在しているようですので、必ず検証前に確認をしておいてください。