「SharePoint のモジュール化されたワークフロー機能の提供 (パート 1/2)」では、Visual Studio で有効に機能するアクティビティを作成しましたが、これは Microsoft Office SharePoint Designer 2007 では機能しませんでした。そのため、まだ最後の目標までたどり着いたとは言えません。幸い、SharePoint Designer 用のカスタム アクションを作成する作業は、簡単な構成プロセスです。いくつか XML を記述する必要はありますが、コードの記述は不要です。

最初の作業では、Windows SharePoint Services または Microsoft Office SharePoint Server 2007 においてアクティビティとそのアセンブリの読み込み方法が認識されるように、web.config ファイルにエントリを追加します。これは、カスタム Web パーツ用の SafeControls エントリを追加する作業と非常によく似ています。

web.config ファイルを開きます。ファイルの末尾付近に、 というセクションがあります。すぐその下には、 子タグを含む というセクションがあります。次の例のように、新しいアクション用として新しい タグを追加します。

PublicKeyToken の値を厳密な名前キーの値に置き換えるのを忘れないでください。そうしないと、このエントリは機能しません。

カスタム Web パーツの作成に慣れた開発者であれば、このエントリが SafeControls エントリとほとんど同じであることに気付きます。SafeControls エントリに馴染みがない方でも、次の部分の意味はすぐに理解できます。

• Assembly: 4 つの部分で構成される、アセンブリの完全な名前。Reflector (英語) などのツールを使用して簡単に取得できます。
• Namespace: アクティビティに固有の名前空間。このサンプル シナリオの場合、これは CaseTrak.Activities です。
• TypeName: 通常、"すべての型" を表すアスタリスクが含まれますが、特定のクラスをリストすることもできます。
• Authorized: True を指定してアクティビティを "安全" にします。一方、false を指定すると、web.config エントリが無駄になります。

これで SharePoint 製品とテクノロジにアクションの内容を伝えて、このアクションを実行する準備が整ったので、次にこれを SharePoint Designer に伝える必要があります。これも簡単で、短い XML をいくつか記述するだけです。パス C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1041\Workflow に移動すると、このフォルダ内に WSS.ACTIONS というファイルがあります。このファイルには、カスタム SharePoint Designer アクションについての情報が豊富に含まれています。このファイル内で、SharePoint Designer アクションを使用して行うことができる、すべての例を確認できます。

残念ながら、このファイルは単なる XML ではあるものの長さが 700 行を超えるので、アクションのビルドに際して知っておくべきことを確認するためにすべてのオプションに目を通すのは少し困難です。この記事では、カスタム アクションをビルドするための、より一般的なオプションについて説明します。すべてのオプション (スキーマ定義を含む) の詳細については、「Additional Resources」を参照してください。

WSS.Actions ファイルについて最初に知っておくべきことは、他の SharePoint の既定ファイルと同様、ファイルの内容の変更が認められていないという点です。その代わり、同じディレクトリに独自の ACTIONS ファイルを作成する必要があります。Windows SharePoint Services および SharePoint Server は、このファイルを読み取って、カスタム アクションを既定のアクションと共にメモリに読み込みます。このためには、単にファイルを同じディレクトリに作成して、それに意味のある名前を付け、拡張子を .ACTIONS にします。今回の例では、CaseTrak.ACTIONS というファイル名を使用します。

サンプル用として、単純に Visual Studio でテキスト ファイルをソリューションに追加し、それに対して XML を追加します。後ほど、パッケージ化と展開を説明する際にこのファイルを処理するので、適切な場所にコピーします。

次のコード例は、作成した CaseTrak.ACTIONS ファイルの全内容です。内容はほとんど一目瞭然ですが、表 1 でさらに詳細を説明します。

 xml version="1.0" encoding="utf-8"?> <WorkflowInfo Language="en-us"> <Actions  Sequential="then" Parallel="and">                  <RuleDesigner Sentence="Set CaseTrak Status for %1 to %2">             <FieldBind Field="CaseID" Text="this Case" DesignerType="string" Id="1"/>             <FieldBind Field="CTStatus" DesignerType="Operator"  OperatorTypeFrom="DropDownMenu" Id="2" >                 <Option Name="Open" Value="1"/>                 <Option Name="Closed" Value="2"/>                 <Option Name="Pending" Value="3"/>                 <Option Name="Deferred" Value="4"/>                 <Option Name="InProcess" Value="5"/>             FieldBind>           RuleDesigner>         <Parameters>         <Parameter Name="CaseID"   Type="System.String, mscorlib" Direction="In" />         <Parameter Name="CTStatus" Type="System.Int32, mscorlib" Direction="In" InitialValue="5" />"Parameters>     Action>   Actions> WorkflowInfo>  

表 1. CaseTrak.ACTIONS ファイルの要素

これらの要素を指定したら、後は IIS をリセットするか SharePoint アプリケーション プールをリサイクルするだけです。図 10. に表示されているように、作成した新しいアクションを SharePoint Designer で使用できるようになります。

図 10. SharePoint Designer のアクションの一覧に表示されたカスタム アクション

ここで、ユーザーがワークフローで使用するためにこのアクションを選択すると、ユーザーに対して、図 11. に表示されているような画面が表示されます。

図 11. カスタム アクションの初期表示

作成した ACTIONS ファイルで見たように、Case パラメータと InProcess パラメータを実際の値と置き換える必要があります。前者は単純な文字列であり、後者は、図 12. に表示されているように、有効な選択肢が含まれたドロップダウン リストです。

図 12. アクションで指定されたパラメータを有効な値に置き換える必要がある

これで、今回のカスタム アクションは完了です。この機能を完全に利用できるようにするための最後の作業は、SharePoint Designer で使用するカスタム条件を作成することです。それについては次に説明します。

条件を作成する

 <Conditions  And="and" Or="or" Not="not" When="If" Else="Else if">     <Condition   Name="Case Not On Hold"            FunctionName="CaseNotOnHold"            ClassName="CaseTrak.Activities.StatusUpdater"           Assembly="CaseTrak.Activities, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bf813961d1f833f1"        AppliesTo="all"              UsesCurrentItem="false">       <RuleDesigner Sentence="Case %1 is not on Hold">         <FieldBind Id="1" Field="_1_" Text="CaseID"/>       RuleDesigner>       <Parameters>         <Parameter  Name="_1_" Type="System.String, mscorlib" Direction="In" />       Parameters>     Condition>     Conditions> 

カスタマイズ オプションの概要

ここまで、提供したコンポーネントを顧客がどのように使用するかについての技術的な側面を順に見てきました。これを理解することから始めるのは、技術的にどのようなことが可能なのかについて知るために重要です。しかし、ここからは、作成した独自のソフトウェア製品に注目して話を進めていく必要があります。作成したアプリケーションのプロセスを理解し、コンポーネントとして公開する機能の部分を切り出す際の合理的な場所を識別できるようになる必要があります。作成したアプリケーションによって提供される機能のすべての部分を公開することも多くの場合できますが、そうすることに合理性がない可能性があります。

残念ながら、この記事で紹介する、それぞれのアプリケーション、状況、および ISV は異なったものになります。そのため、プロセスを構築する基になるコンポーネントとしてアプリケーションを公開する処理にどのように取り組むのかについて、確かなルールを示すことが困難になっています。その代わり、一般的なルールをいくつか示し、検討するべき各種の事項について説明します。

何よりもまず重要なのは、作成したアプリケーションをどのように使用できるのかと、その一般的な使用シナリオを理解することです。この理解を得るために、営業やマーケティングの担当者に意見を聞いたり、自社製品の市場調査を参考にしたりすることも必要です。ここでは、手始めとして、尋ねるべき質問の種類に関するアイデアを提供します。

• ユーザーの環境にある別のアプリケーションに対して、自社アプリケーションのどの情報をユーザーは公開したいと考えているか。
• 顧客サイトで使用されている他のアプリケーションのうち、自社アプリケーションを補完する形でサービスを提供しているものがあるか。また、それを統合して複合的なアプリケーションまたはプロセスを作成できるか。
• 顧客の環境にある他のアプリケーションまたはプロセスのうち、自社アプリケーションに情報を提供するか自社アプリケーションから情報の提供を受けることができるものがあるか。
• 自社アプリケーションまたはプロセスの機能のうち、ユーザーが利用していないものがあるか。

この情報の一部は、自社アプリケーションを顧客の環境にインストールしてサポートしている担当者からも入手できる場合があります。

これらの質問に対する回答が得られたら、アプリケーションの技術的な評価を行う必要があります。そして公開の対象として候補となる、アプリケーションの部分を理解する必要があります。アプリケーションのいずれかの部分、たとえば、内容の編集において独自のまたは厳しいセキュリティや監査の要件を適用している場合は、編集用としてその部分を公開するのが難しいことがあります。この場合は、それらの部分に対して単に読み取り専用アクセスを許可する方法をとることができます。

別のシナリオでは、自社アプリケーションの特定の部分で大量のデータを処理しなければならない場合があります。そのため、この内容を公開して抽出した内容を別のアプリケーションに渡すことは現実的に難しいと考えられます。同様に、特定部分の内容が、他の部分の類似内容との関連でのみ有効であることもあります。この場合は、内容を個々の要素として公開することに意味がないと考えられます。

最後のシナリオとして説明するのは、企業秘密のビジネス概念またはアルゴリズムを保護する考え方です。自社アプリケーションの一部をモジュール化されたコンポーネントとして公開することで、その内部のしくみが顧客や競合企業に漏れてしまい、競争上の優位性が低下または消失するのであれば、そのような行為はビジネス上明らかに良い判断ではありません。このような場合は、それらの要素を公開しないことを選択するか、考えられる脅威を最小限にするような方法で分離するようにします。アプリケーション内にある企業秘密の情報を守りながら、入力と出力のみを公開することで、企業秘密の要素をブラック ボックスとして維持できます。

以前は, .NET ベース製品の API を拡張する方法として、主に次の 2 つがあると言うことができました。

• Web サービスを使用する
• .NET リモート処理を使用する

どちらの方法を選ぶかは、いくつかの要因で決まっていました。Web サービスを選んだ場合は、パフォーマンスを犠牲にしてクロス プラットフォーム サポートを実現していました。.NET リモート処理を選んだ場合は、クロス プラットフォーム サポートを犠牲にして高いパフォーマンスを得ていました。どちらの選択肢においても、こちらの処理では、コア ビジネス ロジックと、API にアクセスする外部プロセスを分離した状態を維持することで、サービスに基づくアーキテクチャに従うことができます。

高レベルでは、これらの選択肢は機能的に同じです。どちらの場合でも、1 つのアプリケーション領域で動作しているアプリケーションまたはプロセスが、こちらで定義した API を使ってこちらのアプリケーションに対して呼び出しを行い、異なるアプリケーション領域、場合によってはまったく異なるサーバーで動作します。このことは、こちらのコア API の部分を、こちらのアプリケーションが実行されるサーバー上以外にはインストールする必要がないことを意味します。また、この場合、コントラクトを定義してそれをサポートすることに合意したことも意味します。将来の任意の時点で、こちらのアプリケーションに対して必要な変更を自由に加えることができ、定義したコントラクトに違反しない限り、こちらの API を利用するいずれかのアプリケーションを壊すことを心配する必要はありません。また、既存の機能を変更しない限り、コントラクトに指定されている内容に新しい機能を追加することもできます。

過去数年にわたって、Web サービスのパフォーマンスとセキュリティが向上したことで、シェア争いの軍配は Web サービスに上がりました。現在, .NET リモート処理を使用することはほとんどなくなっています。ただし、API の拡張で .NET リモート処理を採用していても、ここでの説明に従って現在の実装を止める必要はないので安心してください。

こちらの観点からは、これによって物事がかなり単純になります。こちらの処理では、API の周りを Web サービスでラップすることによって API を拡張します。外部環境に公開する必要があるすべての機能には、Web サービス インターフェイスが割り当てられます。コントラクト (入力と出力) を定義すると、Web サービスとやり取りできるすべてのアプリケーションはこちらの製品との統合をすぐに開始できるようになります。

ISV の観点からは、このことはかなり魅力的に響きます。この記事で特に強調したいのは、Web サービスでの呼び出しを行うためにビルドするワークフロー コンポーネントを有効にする際に何か違ったことをする必要がまったくない点です。必要に応じて Web サービスを残りのアプリケーション用に作り上げ、必要なときにそれらがコンポーネントから呼び出されるようにします。

厳密に言えば、今回のコンポーネントを展開用にパッケージ化する作業を、他のほとんどの SharePoint コンポーネントをパッケージ化する作業とは違った方法で行うことも簡単にできます。これまで見てきた内容のほとんどには、Windows SharePoint Services または SharePoint Server に特有のものは含まれていません。しかし、ここでは実際には SharePoint 環境用に開発を行っており、コンポーネントは SharePoint 環境に展開されることになっています。そのため、展開を準備するにあたって SharePoint 製品とテクノロジを念頭に置いて話を進めます。

ここでは、コンポーネントを他のさまざまな SharePoint コンポーネントと共にインストールするので、展開後の外観は他の SharePoint の展開と同じようなものになっている必要があります。このため、フィーチャーとソリューションを検討する必要があります。フィーチャーとソリューションを作成する方法はいくつかありますが、ここでは、最も一般的なものとして広まりつつある 1 つの方法を採用します。

その説明に移る前に、まず、作成したコンポーネントの展開プロセスでどのような作業が必要になるのかを正確に確認してみましょう。今回の展開プロセスでは、次の作業を行います。

1. 作成したアセンブリをグローバル アセンブリ キャッシュにインストールします。
2. 作成した ACTIONS ファイルをパス C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1041\Workflow にコピーします。
3. web.config ファイルを authorizedType エントリ付きで更新します。

ソリューションとフィーチャーを使用すると、これらのすべての処理を簡単に行うことができます。

• ファイルを物理的に移動する処理はソリューションが得意とするところなので、最初の 2 つのタスクをソリューションを使って行います。
• フィーチャーを使用すると、フィーチャーがアクティブ化または非アクティブ化されるときにコードを実行できるので、ここではフィーチャーを作成して 3 つ目のタスクを処理します。1 つ注意が必要なのは、今回のコンポーネントは、個々の Web またはサイト コレクションよりも高いレベルを対象としている点です。そのため、管理アクセス許可を持つレベルの担当者がこれらのコンポーネントを管理する必要があります。つまり、作成するフィーチャーの範囲として、Web アプリケーション レベルまたはファーム レベルを指定します。実際のシナリオでは、状況に応じてどちらが適切であるかを決定するか、またはアプリケーションをインストールする担当者にインストール先の環境においてどちらが適切であるかを決定することを許可する必要があります。

それでは、フィーチャーを作成していきましょう。

これから作成するフィーチャーは、おそらく、これまでに作成されてきた多くのものとは少し異なります。というのも、フィーチャーのすべての作業をフィーチャー レシーバで処理するからです。これから説明するように、フィーチャーそれ自体は何も行わないので要素ファイルはありません。さらに説明を進める前に、先ほど見た機能の一覧を思い出してください。フィーチャーで処理するのは、web.config ファイルを authorizedType エントリ付きで更新するという最後のタスクです。それでは、フィーチャー レシーバを作成していきましょう。

フィーチャー レシーバを作成する

 public override void FeatureActivated(SPFeatureReceiverProperties properties) { SPWebApplication wappCurrent = (SPWebApplication)properties.Feature.Parent; SPWebConfigModification modAuthorizedType = new SPWebConfigModification(); modAuthorizedType.Name = "AuthType";       modAuthorizedType.Owner = "CaseTrak.Actions";       modAuthorizedType.Path = "configuration/System.Workflow.ComponentModel. WorkflowCompiler/authorizedTypes";       modAuthorizedType.Type = SPWebConfigModification.SPWebConfigModificationType.        EnsureChildNode;       modAuthorizedType.Value = @"";       wappCurrent.WebConfigModifications.Add(modAuthorizedType);       wappCurrent.WebService.ApplyWebConfigModifications();         } 

 xml version="1.0" encoding="utf-8" ?> ElementManifests /> Feature> 

ソリューション

 xml version="1.0" encoding="utf-8" ?> <Solution xmlns=""   SolutionId="79deac59-22ab-da1e-9d7a-1732d31cbe07" >   <Assemblies>     <Assembly DeploymentTarget="GlobalAssemblyCache" Location="CaseTrak.Activities.dll" />   Assemblies>   <TemplateFiles>     <TemplateFile Location="1033\Workflow\CaseTrak.ACTIONS"/>   TemplateFiles>   <FeatureManifests>     <FeatureManifest Location="CaseTrak_Activities\Feature.xml"/>   FeatureManifests> Solution> 

 ;************* ; This .ddf file specifies the structure of the .wsp solution cab file.  ;*************  .OPTION EXPLICIT .Set CabinetNameTemplate=CaseTrak_Activities.wsp .Set DiskDirectoryTemplate=CDROM .Set CompressionType=MSZIP .Set UniqueFiles="ON" .Set Cabinet=on .Set DiskDirectory1=Package  manifest.xml manifest.xml bin\debug\CaseTrak.Activities.dll CaseTrak.Activities.dll RootFiles\TEMPLATE\FEATURES\CaseTrak_Activities\feature.xml CaseTrak_Activities\feature.xml RootFiles\TEMPLATE\1033\Workflow\CaseTrak.ACTIONS 1033\Workflow\CaseTrak.ACTIONS 

ソリューション ファイルをビルドする

 cd .. Utilities\MakeCab /F CaseTrak_Activities.ddf 

展開を完成させる

ここまで読み進めてこられたので、カスタム アクティビティ、アクション、および条件を構築する際の作業について、大分理解が深まっているかと思います。そこで、良いお知らせがあります。新たなビルドを行う都度、繰り返し面倒な作業をすべて行う必要はありません。CodePlex では、コミュニティで開発された STSDev というツールが提供されています (「Additional Resources」に直接のリンクがあります)。このツールでは、ウィザード形式のインターフェイスを使用していくつか設定を選ぶオプションがあり、次のような必要なすべてのデータが揃った完全なアクティビティ、アクション、または条件を生成できます。

• スタブ メソッドが配置された、5 つの Activity クラスすべて
• 独自の ACTIONS ファイル
• web.config ファイルに AuthorizedType エントリを追加するためのフィーチャー レシーバ
• すべての展開ファイル (Feature.XML、Manifest.XML, .ddf、および .wsp)

時間を節約して、いら立ちを解消するために、このツールを使用することを強くお勧めします。

ここまで長い道のりでしたが、無事やり遂げました。これですべて終了です。この記事の導入部分では、どのような方向で進んでいくのかについて、漠然としたアイデアが見える程度でしたが、多くの期待があった反面、内容が難しいものになるかもしれないという少しの不安もありました。しかし、ここまで来てみると、結局のところ、内容がそれほど込み入ったものにはならなかったのは幸いでした。

途中、SharePoint Designer と Visual Studio のどちらをサポートするのかという問いに答える形で、実際には両方ともサポートする必要があるということを理解しました。また、Visual Studio のアクティビティ、そして SharePoint Designer のアクションと条件を学習し、3 つすべての作成プロセスを確認すると共に、それらを、並の開発者が作成するような平凡なコンポーネントとは一線を画する、ひときわ優れたものにすることを説明しました。最後に、締めくくりとして、コンポーネントをパッケージ化する方法に触れ、残りのアプリケーションと共に簡単に展開できるように、すべての外観を磨き上げて本格的なインストールにすることを学びました。午後に取り組む作業としては上出来です。

この記事では、今回目的としたタスクに直接的には関係しない、さまざまなトピックについて言及しました。検索エンジンで有益なリソースを探す手間を省くため、ここでは必要な情報を見つけるのに役立つリンクをいくつか紹介します。

These are our most popular posts: