CA Agile Central 統合機能に関する FAQ とベスト プラクティス

このページは、コネクタ固有のインストールおよび使用方法のガイドの補足として設計されています。ここで説明する必要のある追加のトピックがある場合は、お知らせください。

一般

エンタープライズ統合フレームワークの紹介

CA Agile Central エンタープライズ統合フレームワーク(EIF)へようこそ。2 つのシステムを統合する際には、すべてのコネクタに当てはまる 1 つの推奨事項として、まずは簡単なことから開始します。

コネクタを検討している場合は、まずは解決しようとしている問題を定義することをお勧めします。たとえば、次のようになります: 「現在、すべてのバグはシステム X に存在しています。チームは現在、CA Agile Central でストーリーを操作および定義しています。システム X のディフェクトを CA Agile Central で管理し、チームがそれらのディフェクトに優先順位を付けてスケジュールを設定できれば、非常に有益です」。現在、単に個々のユーザがディフェクトをエクスポートおよびインポートしている場合、チームがこの問題を解決するのに EIF コネクタは確実に役立ちます。そうした問題のために、他方のシステムから小規模なチームとディフェクトのサブセットを選択して、コネクタの使用を開始することができます。

移動するチームと作業アイテムのサブセットを選択したら、マップする情報の最小セットを検討し始めることができます。作業を順調に進めるために、一般的には名前、説明、所有者などの簡単な要素から開始し、次に、CA Agile Central にどのような作業アイテムを移動するかを検討することをお勧めします。

作成サービスと更新サービスのデバッグ

設定でのサービス名 サービスの詳細 サービスの設定
UPDATE_RALLYFIELDS_AND_OTHER 最初に CA Agile Central で更新を検索し、新たに変更されたフィールドのみをもう一方のシステムにプッシュします。次にもう一方のシステムで更新を検索し、マップされているすべてのフィールドを CA Agile Central にプッシュします。 Config.xml で、タグを見つけます (通常は設定ファイルの下部にあります)。タグの内部で、 UPDATE_RALLYFIELDS_AND_OTHER をリストし、UPDATE_RALLY_TO_OTHER サービスと UPDATE_OTHER_TO_RALLY サービスを削除します。

サービスの詳細については、このドキュメントの「CA Agile Central からのフィールド レベルの更新」を参照してください。

古いサービス

以下に、以前のバージョンのサービスについて説明します。ただし、上記で説明した新しいサービス、UPDATE_RALLYFIELDS_AND_OTHER を使用することをお勧めします。コネクタは、4 つの基本的なサービスを実行して、CA Agile Central と他方のシステムの間で情報を移動します。

設定でのサービス名 サービスの詳細 サービスのクエリ
COPY_RALLY_TO_OTHER CA Agile Central で新しい作業アイテムを検索し、他方のシステムにコピーします。 CA Agile Central をクエリします。ここで、(ExternalID = null)、かつ(作業アイテムが、プロジェクト RallyConnection にリストされているプロジェクトに含まれる)、かつ(RallyConnection CopySelectors のすべての条件が満たされている)。
COPY_OTHER_TO_RALLY 他方のシステムで新しい作業アイテムを検索し、CA Agile Central にコピーします。 他方のシステムをクエリします。ここで、(RallyID は null)、かつ(MoveToRally = Yes など、OtherConnection CopySelectors のすべての条件が満たされている)。
注: JIRA コネクタは、null でなく「-1」(マイナス 1)に対してクエリを実行します。
UPDATE_RALLY_TO_OTHER 他方のシステムに接続されている、CA Agile Central 内の作業アイテムを検索し、更新を移動します。 CA Agile Central をクエリします。ここで、(ExternalID! = null)、かつ(前回のコネクタ実行時以降に LastUpdateDate が更新されている)、かつ(RallyConnection CopySelectors のすべての条件が満たされている)。
UPDATE_OTHER_TO_RALLY CA Agile Central の作業アイテムに接続されている、他方のシステム内の作業アイテムを検索し、更新を移動します。 他方のシステムをクエリします。ここで、(RallyID は null ではない)、かつ(他方のシステムの作業アイテムの更新タイムスタンプが前回のコネクタ実行時以降である)、かつ(OtherConnection CopySelectors のすべての条件が満たされている)。

設定ファイルで、  タグに  タグが含まれており、実行するサービスを指定できます。選択できるサービスは 4 つあり、複数のサービスを指定できます。


        ....
        FalseDebug      UPDATE_RALLY_TO_OTHER,
                                UPDATE_OTHER_TO_RALLY,
                                COPY_RALLY_TO_OTHER,
                                COPY_OTHER_TO_RALLY

注: コネクタは、設定ファイル内にリストされた順序でサービスを実行します。

推奨事項

複数のサービスをリストする際の一般的な推奨事項は、以下のとおりです。

  • コネクタをセットアップする際には、まず作成サービスだけを使用して接続を機能させてから、更新サービスを追加する
  • 最初に更新サービスをリストしてから、作成サービスをリストする

デバッグ

  1. コネクタが一部の作業アイテムを見つけられない:
    3 つのすべてのシステム(CA Agile Central サーバ、他方のサーバ、およびコネクタ サーバ)の時刻が、かなり厳密に同期化されている(数分以内)必要があります。これは、NTP (Network Time Protocol)を介して実行できます。
  2. コネクタが、コピー サービスを含む作業アイテムを見つけられない:
    1. ExternalID カスタム フィールドの問題:
      • CA Agile Central の ExternalID カスタム フィールドで、Type を確認します。String タイプである必要があります (注: Text タイプである場合、クエリで作業アイテムは何も見つかりません)。
      • 設定ファイル内の ExternalID 名のスペルを確認し、CA Agile Central システムまたは他方のシステムでセットアップした内容と一致することを確認します。
      • CA Agile Central は、「表示名」(「名前」ではなく)を使用してカスタム フィールドにアクセスします。また、スペースとアンダースコアは削除されるので、たとえば「External ID」は「ExternalID」となります。
      • 他方のシステムで、RallyID を保持するカスタム フィールドを確認し、実際に「空」であることを確認します。その他の一部のシステムでは空は「null」、JIRA では空はマイナス 1 (-1)となります。クエリ機能があると仮定して、他方のシステムでテスト クエリを実行します。
    2. を確認 (これを使用していると仮定)して、作業アイテムが(複合 AND 条件から)除外されないことを確認します。
    3. コピー サービスを実行する場合、クエリはスコープ設定されたプロジェクトです。したがって、設定ファイルの  要素で宣言されているプロジェクトのみが検索されます。
    4. 更新サービスを実行する場合、クエリはスコープ設定されたワークスペースです。したがって、ワークスペース内のすべてのプロジェクトが検索されます。
  3. コネクタが、更新サービスを含む作業アイテムを見つけられない:
    1. コネクタが前回実行された後に、更新を行ったことを確認します。設定ファイルごとに、コネクタは時間ファイルを保存し、このファイルには前回成功した更新 サービス実行の時刻が含まれています。10 分前に更新を行い、過去 5 分間内にコネクタが実行された場合、その更新は表示されない可能性があります。この動作は、デバッグ時に発生することがあります。時間ファイルは「time.file」という名前で、以下のような 1 行が含まれています。
      2012-05-24 17:18:58 UTC
    2. 他方のシステムが最終更新日時を格納するかどうか – コネクタまたはオフセットと同じタイムゾーンであるかどうかを確認します。
    3. 2 つのシステム間で ExternalID または RallyID が実際に格納されたことを確認します。
    4. を確認 (これを使用していると仮定)して、作業アイテムが(複合 AND 条件から)除外されないことを確認します。
    5. ログ ファイルにエラーまたは警告が含まれないか確認します – ログのレベルを引き上げなければならない場合があります。POST 操作で 2 つのシステムのいずれか更新の試行に失敗した可能性があります。

ロガーおよびログ ファイルの管理

コネクタは実行時に、現在の作業ディレクトリ内の rallylog.log という名前のファイルにメッセージを記録します。デフォルトでは、ログ ファイルの最大サイズは 5 MB で、ログ ローテーションは 10 個のファイルに制限されています。以下のようにコマンド ライン引数を指定することにより、ログ ファイルの最大サイズと、ログ ローテーション内のログ ファイルの最大数を調整することができます。

-s オプションを使用して、ログ ファイルの最大サイズを MB の単位で指定できます(最大 100 MB まで)。これは log-file-size としても指定できます。

-m オプションを使用して、ログ ファイルのローテーション スキーマ内のファイルの最大数を指定できます。これは --max-log-files としても指定できます。

例: コネクタの 1 回の呼び出しに対してログ ファイルの最大サイズを 50 MB に設定し、ログ ファイル ローテーションの最大数を 20 ファイルに設定するには、以下のように指定します。

rally2_xxx_connector -s 50 -m 20 xxx_config.xml -1

または

rally2_xxx_connector --log-file-size 50 --max-log-files 20 xxx_config.xml -1

コネクタは複数のログ レベルを使用し、それぞれ詳細レベルが異なります。以下の表から、各レベルに、より高レベルの情報がすべて含まれることがわかります(たとえば、警告には、警告、エラー、および致命的の情報がすべて含まれます)。

    
ロガー レベル 詳細レベル 詳細情報の例
0: デバッグ 最も詳細 フィールド マッピング値を表示します
1: 情報 ... 接続/切断情報
2: 警告 ... フィールドのマップに失敗しました
3: エラー ... 失敗した作成作業アイテムのメッセージ
4: 致命的 ... ...
5: 不明 最も詳細でない ...(ログ ファイル内に ANY として表示されます)

これらのレベルは、http://corelib.rubyonrails.org/classes/Logger/Severity.html に記載されています。

設定ファイルでは、以下のように タグ内で 設定が宣言されます。


        ....
        FalseDebugUPDATE_OTHER_TO_RALLY,  COPY_OTHER_TO_RALLY

一般的な推奨事項は以下のとおりです。

  • コネクタをセットアップする際には、 をデバッグのままにする
  • コネクタを起動して実行する際には、 を警告に設定する

デバッグを使用する場合は、その他のデバッグ情報に加えて、コネクタがフィールドにマップしようとしている値が表示されます。
コネクタを情報レベルのままにする場合は、コネクタが始動時およびスリープ時に各システムに接続されるときの情報も表示されます。

日単位または週単位でログを確認して、解決すべき例外またはエラーを見つけることをお勧めします。

複数の設定ファイル

セットアップで以下が必要な場合は、複数の構成ファイルが必要となる可能性があります。

  • CA Agile Central での複数のワークスペースへのマッピング
  • 複数の作業アイテム タイプのマッピング
  • 以下のような、他方のシステム内の複数のコンテナへのマッピング
    • Quality Center 内のドメイン/プロジェクト
    • ClearQuest 内のデータベース
    • TFS 内のチーム プロジェクト

注: トラブルシューティングを簡単に行えるよう、設定ファイルにわかりやすい名前を付をけることをお勧めします。

複数の設定ファイルを使用してコネクタを実行するには、設定ファイルごとに 1 回起動することをお勧めします。以下に例を挙げます。

Windows の場合:
    rally2_xxx_connector.exe  config_workspaceA.xml  -1
    rally2_xxx_connector.exe  config_workspaceB.xml  -1

Linux の場合:
    rally2_xxx_connector.rb  config_workspaceA.xml  -1
    rally2_xxx_connector.rb  config_workspaceB.xml  -1

上記の呼び出しを一定の間隔で繰り返し実行するには、一定の間隔で呼び出される Windows スケジュール タスク(または Linux の cron ジョブ)を定義します。このようなタスクを 10 分またはそれ以上の間隔で繰り返すことをお勧めします。それ未満の間隔は推奨されません。

複数の設定ファイルを使用するタイミング

このタイミングは、コネクタ間のさまざまなニーズを満たすために非常に柔軟に設計されています。以下の情報は、複数の設定ファイルを使用するタイミングと方法を判断するのに確実に役立ついくつかのシナリオを示しています。

1 つのディレクトリ、複数の設定ファイル

前述のように、複数の設定ファイルを使用して 1 つのプロセスで実行する - 以下のいずれかが当てはまる場合、一般的にはこのセットアップが推奨されるか、または必須となります。

  • 複数の Quality Center プロジェクトを接続する場合は、QC プロジェクトごとに 1 つの config.xml 必要となる
  • 複数の JIRA プロジェクトを接続する場合は、JIRA プロジェクトごとに 1 つの config.xml が必要となる
  • 複数の CA Agile Central ワークスペースを接続する場合は、CA Agile Central ワークスペースごとに 1 つの config.xml が必要となる
  • 複数の ClearQuest スキーマを接続する場合は、CQ スキーマごとに 1 つの config.xml が必要となる
  • 複数の作業アイテム タイプを接続する場合は、作業アイテム タイプ(ディフェクト、ユーザ ストーリー、テスト ケース)ごとに 1 つの config.xml が必要となる

複数のディレクトリ

また、以下のような複数のパラレル ディレクトリにコネクタをインストールしてセットアップすることもできます。
C:\Program Files\RallyConnectorFor\Defects\すべての EIF ファイル内に、ディフェクト
C:\Program Files\RallyConnectorFor\Stories\すべての EIF ファイルの 2 つ目のコピー内に、ストーリー

この場合、2 つの異なるプロセスで rally2_*connector.exe config.xml を呼び出すことができます。その後、各プロセスに独自のタイマ間隔を指定できます。
たとえば、ディフェクトの場合は 10 分ごと、ストーリーの場合は 30 分ごとに実行できます。
このセットアップでは、2 つの作業アイテムに対して 2 つの異なる rallylog.log ファイルを持つこともでき、これはログ ファイルのモニタリングに役立つ可能性があります。

他の XML ファイルを含める方法

設定ファイル内に、XML テキストの他のファイルを含めることができます。これにより、すべてのファイルが 1 つの XML ファイルとして扱われます。この操作は、XML 外部エンティティを使用して実行します。たとえば、設定ファイルの セクション内の通常のユーザ マッピングをメインの XML 設定ファイルから削除し、「users.xml」という名前の新しい XML ファイルに貼り付けることができます。この操作は以下のようになります。

ファイル名: users.xml

BG_RESPONSIBLE[email protected]qcuser1[email protected]qcuser2[email protected]qcuser3
                ....
        

メインの構成ファイルに、最初の 4 行として以下を含めます。



]>

その後、メインの構成ファイルで、テキストが発生するたびに文字列「&usersFile;」を入力します。以下に例を挙げます。


        ....
        
                ....
                
                        &usersFile;
                        ....

XML には以下の既知の制限事項があります。

  1. この機能を使用して、ユーザのクリア テキスト パスワードが含まれているファイルを含めると、コネクタは、エンコードされた(暗号化されていない)文字列としてパスワードを書き換えます。ただし、コネクタは、含まれるパスワード ファイルではなく、メインの XML ファイルにエンコードされた文字列を書き込みます(これにより、「含める」行が上書きされます)。回避策: 含めたファイルにエンコードされたパスワードが含まれている場合、コネクタは、文字列の書き換えを試行しません。
  2. 含めるファイルのフル パスを指定する際には、円記号(\)ではなくスラッシュ(/)を使用します。たとえば、有効なパス指定として「C:/Users/jpkole/RallyQC/x073-Entity-Test-RALLYstory.xml」が考えられます。

フィールド ハンドラの使用

セクションでマップされているフィールドには、いずれかのフィールド(CA Agile Central のフィールドまたは「他方の」フィールド)に対して登録されている「フィールド ハンドラ」を含めることができます。操作が完了すると、マッピングが発生するたびにフィールド ハンドラが呼び出されます。

警告: 同じフィールド名で 2 つの異なるフィールド ハンドラを登録することはできません。コネクタはこのような状況をサイレントに無視し、コネクタは通常、最後に登録されたフィールド ハンドラだけを記憶しますが、結果は予測できません(これはサポートされている設定ではありません)。

および を介した作業アイテムのサブセットの選択

コピー サービスまたは更新サービスの実行時に、CA Agile Central または他方のシステムから作業アイテムのサブセットを選択するようコネクタに指示できます。初めてコネクタをセットアップするときは、いくつかの作業アイテムだけを選択すると役立ちます。

コピーおよび更新の選択条件は、設定ファイルの 要素   要素で設定されます。

QC コネクタには、セレクタの構文に対していくつかの制限事項と拡張機能の両方がありますが、その他のコネクタにはありません。詳細については、こちらの FAQ を参照してください。

セレクタの構文の例:


        ....
        
                ....
                FormattedID  = DE351SyncToJIRA   = "True"State        = "Open"Priority    != "Normal"Priority    != Low
                ....

コンテナ内と コンテナ内には、それぞれ複数の 要素と複数の 要素を含めることができます。複数のセレクタ要素は AND で結合されます。OR 機能が必要な場合は、その結果を有効にするために複数の構成ファイルを使用することをお勧めします。または、選択されないようにするすべての値に対して not-equal を使用することもできます。

セレクタ要素は、フィールド名、スペース、関係演算子、スペース、その後にターゲット値で構成される必要があります。ターゲット値にスペースが含まれている場合、値を引用符で囲む必要はありません。以下に例を挙げます。

AssignedTo = John Q. Public
        ....

セレクタの構文では、関係演算子を使用した値に対するフィールドの評価がサポートされています。値は、null 以外かつ空白以外である必要があります。以下に、サポートされていない構文の例を示します。


X_FIELD = 
        ....

一般的なルールとして、セレクタ要素では =、!=、、>、=、および >= 関係演算子がサポートされています。ただし、設定ファイルが XML であるため、「」文字と「>」文字には問題があり、XML パーサが混乱します。そのため、以下の表に示す、対応する英字の省略形を使用します。

LastModified gte 2011-04-05
        ....

省略形

関係演算子の完全なセットをサポートしていないシステム:

  • Bugzilla:
    • サポート: =、!=、 (lt)、および > (gt)関係演算子
    • 非サポート: = (lte)および >= (gte)関係演算子

ヒント: 他方のシステムから CA Agile Central へ作業アイテムのより小さいセットを移動するもう 1 つの方法は、「はい/いいえ」ドロップダウン リストまたはチェックボックスである「Move to CA Agile Central? (CA Agile Central に移動しますか)」という名前のカスタム フィールドを作成することです。これにより、コネクタは、カスタム フィールドが「はい」である作業アイテムだけを選択して移動することができます。

注: を使用する場合、クエリはスコープ設定されたプロジェクトです。したがって、設定ファイルの 要素で宣言されているプロジェクトのみが検索されます。

参照フィールドでのセレクタの使用

他方のシステムにおける参照フィールド(別のオブジェクトを実際にポイントする(単純な値を含むのではなく)、作業アイテム内のフィールド)は、サポートされていません。

CA Agile Central の参照オブジェクトのフィールドは、セレクタ要素で使用できます。以下に例を挙げます。

Project.Name = MyNewProj1Iteration.Name = Iter2
        ....

CA Agile Central コネクタのアップグレード

Windows でのアップグレード

  1. 設定ファイルおよびすべてのカスタム フィールド ハンドラをバックアップします。ベスト プラクティスとしては、必ず設定ファイルの名前を変更し、デフォルトの _config.xml ファイル(これらのファイルはアンインストール(手順 2)時に完全に削除されます)は使用しません。
  2. CA Agile Central コネクタをインストールしたディレクトリ(デフォルトでは C:/Program Files/RallyConnectorfor)に移動し、unins000.exe をダブルクリックします。
  3. 最新バージョンの CA Agile Central コネクタに対して、インストーラ RallyConnectorforInstall-.exe を実行します。

Windows 以外でのアップグレード(rally2*.rb スクリプトを使用)

  1. 設定 XML ファイルおよびすべてのカスタム フィールド ハンドラをバックアップします。ベスト プラクティスとしては、必ず設定ファイルの名前を変更し、デフォルトの _config.xml ファイルは使用しません。
  2. 現在の gem をアンインストールます。コンソール シェルを開き、以下のように入力します。
    gem uninstall yeti
  3. gem をローカルに保存したら、cd を実行して、gem が格納されているディレクトリに移動します。
  4. 最新の gem をインストールします。コンソール シェルを開き、以下のように入力します。
    gem install yeti*.gem

フィールド

フィールドをマップする方法

CA Agile Central から他方のシステム(またはその逆)に作業アイテムを転送する際、設定ファイルは、CA Agile Central 内のどの作業アイテムのフィールドを他方のシステム内のどのフィールドにマップするかを指定する必要があります。これは、設定ファイルの XML 要素内で実行されます。コネクタが作成または更新を実行すると、このセクションで指定されているフィールドだけが変更されます。

マッピングをセットアップする際には、2 つのシステム間でフィールドに互換性があることを確認してください(たとえば、整数フィールドは、もう一方のシステムの整数フィールドにマップする必要があり、リッチ テキスト フィールドは、もう一方のシステムのリッチ テキスト フィールドにマップする必要があります)。そうしないと、2 つのシステム間で情報が作成または更新されず、ログ ファイルにエラーが表示される可能性があります。たとえば、CA Agile Central の整数型のカスタム フィールドに文字列フィールドをマップしようとすると、その作業アイテムに対してコネクタはエラーをポストします。

CA Agile Central のフィールド名を指定する際には、「表示名」(「名前」ではなく)を使用する必要があります。また、 セクションで表示名を指定する際に、表示名にスペースが含まれている場合は削除する必要があります(つまり、「Foo Bar」という表示名は FooBar として宣言されます)。

CA Agile Central のドロップダウン値を他方のシステムにマップする場合、それらのドロップダウン値は一致します。そうでない場合、コネクタは、リストで値が見つからなかったことを知らせるエラーを生成します。2 つのシステム間でドロップダウン値が異なる場合は、次のセクション「ドロップダウン値のマップ」を参照してください。

以下に例を挙げます。


        ....
        StateStatusSeverityImportancePriorityUrgency
                ....

上記の例で、CA Agile Central の「State」フィールドは他方のシステムの「Status」フィールドに、「Severity」は「Importance」に、「Priority」は「Urgency」にマップされます。

Rally ID フィールドのマップ

CA Agile Central オブジェクトには、CA Agile Central のすべてのエンティティ間で一意の識別子(ObjectID)と、ワークスペース内だけで一意の識別子(FormattedID)の、2 つの識別子があります。これらの識別子を確認するには、CA Agile Central のディフェクトの詳細ページに移動します(CA Agile Central GUI を使用)。左上隅近くに、DE42 などの FormattedID が一覧表示されています。太字の名前と ID の左側にあるチェーン リンク アイコンをクリックすると、そのディフェクトの特定の URL (たとえば、https://rally1.rallydev.com/#/3026904716ud/detail/defect/3026966119)に移動します。URL の末尾の数字(この例では 3026966119)は、ディフェクトの ObjectID です。

これらの両方の ID フィールドのマッピングは、設定ファイルの 要素と 要素でセットアップできます。

XML の以下の例は、CA Agile Central の ObjectID と CA Agile Central の FormattedID の両方が、 タグと タグ内で指定されている Quality Center のカスタム フィールドにそれぞれマップされることを示しています。JIRA、TFS、Bugzilla、および ClearQuest のコネクタも、これらのタグを認識できます。



        ....
        server:portDomain NameProject NameqcusernamepasswordBUGBG_USER_XXBG_USER_YY
        ....

CA Agile Central のテキスト フィールドに関する考慮事項

CA Agile Central では、リッチ テキスト フィールドに対して 32 K の文字制限があります。たとえば、概要、説明、注意事項のフィールドです。Quality Center や Bugzilla などのその他のシステムでは、テキスト フィールドに対して 32 K を超える制限がサポートされているので、データ制約の不整合が生じます。

CA Agile Central において、32 K を超えるテキストをコネクタはどのように処理するでしょうか。
ターゲット システムから CA Agile Central に作業アイテムをコピーまたは更新する場合、コネクタは、テキストが 32 K の制限を超えていて、特定の作業アイテムがコピーまたは更新されないことを警告します。この警告によってコネクタは実行を妨げられず、処理が必要な次の作業アイテムのコピーまたは更新を引き続き実行します。

この状況を防ぐにはどうすればよいでしょうか。
32 K の制限に対する警告を回避するために、CA Agile Central では、この制限を接続ターゲット システムに適用することが推奨されています。たとえば、Quality Center を使用している場合、ユーザがバグまたは要件を保存すると実行されるカスタム スクリプトを記述することができます。これにより、すべてのテキスト フィールドが 32 K に自動的に制限されます。別の文字制限が存在する場合は、各システム内のテキスト フィールド間の整合性を確保するソリューションについて、システム管理者にお問い合わせください。

別の方法としては、フィールドを 1 方向だけにマップします。たとえば、CA Agile Central でフィールドが 32 K に制限されている場合、CA Agile Central から他方のシステムへの更新またはコピーだけを許可します。これにより、そのフィールドのテキストが大きくなりすぎることがなくなります。


        ....
        DescriptionBG_DESCRIPTIONTO_OTHER
                        ....

フィールドの方向性

特定のフィールドをコピーまたは更新する方法を制限するには、そのフィールドの FieldMapping セクションに方向タグを追加します。

CA Agile Central をレコードのソースにする場合は、TO_OTHER (大文字または小文字)を指定します。この場合、他方のシステムの変更が CA Agile Central にプッシュされることはありません。他方のシステムをレコードのソースにする場合は、TO_RALLY (大文字または小文字)を指定します。この場合、CA Agile Central の変更が他方のシステムにプッシュされることはありません。


        ....
        DescriptionBG_DESCRIPTIONTO_OTHERNotesBG_NOTESto_rally
                        ....

必要なフィールドとフィールドのデフォルトのマッピング

1 つのシステムから別のシステム(CA Agile Central、QC、JIRA、CQ)に作業アイテム(ユーザ ストーリー、ディフェクト、テスト ケースなど)をコピーする際に、作業アイテムで定義されている必須フィールドがコピー先のシステムに存在する場合は、以下の 2 つの方法のいずれか(両方ではない)を使用できます。

  1. 前述の「フィールドをマップする方法」で説明した 要素を使用します。
  2. フィールド マッピングを使用せず、コピー先のシステム内の必須フィールドが常に同じデフォルト値を持つようにする場合は、 XML 要素を使用します。以下に例を挙げます。
    
            ....
            
                ....
                SeverityRally-SeverityStatusRally-Status
                ....

    上記の例で、XML 要素 QCConnection> は、使用しているコネクタに応じて のようになります。この例で、QC フィールド「Severity」には、QC システムで作成された任意の作業アイテムに対して、「Rally-Severity」のデフォルトの文字列値が自動的に割り当てられます。QC フィールド「Status」は、「Rally-Status」の文字列値を自動的に取得します。

Null 値を持つフィールドのマッピング

接続の一方の側のマップ済みフィールドの値が null に設定されている場合、コネクタは、反対側の対応するフィールドの値を無効にしません。このフィールドの更新はスキップされます。これが、基礎となるアーティファクトに対する唯一の更新である場合、rallylog.log には「 Skipped update for since no fields changed (何も変更が行われなかったので、 の更新がスキップされました)」と記載されます。

異なるシステムでは、所定のフィールド タイプの null 値または空値の扱い方が異なります。したがって、このような違いのために更新中に値が無効にならないようにしました。ユーザが一方のシステム内の 1 つのタイプのフィールドを他方のシステム内の別のタイプのフィールドにマップできるという点で、null 値の考察はさらに複雑になります。

CA Agile Central からのフィールド レベルの更新

サービスは、作業アイテムの EIF コネクタを使用して更新できます。コネクタが両方のシステムでの更新を扱うことができるよう、UPDATE_RALLYFIELDS_AND_OTHER が導入されました。このサービスは、UPDATE_RALLY_TO_OTHER サービスと UPDATE_OTHER_TO_RALLY サービスをオーバーライドします。


    ....
    
        ....
        UPDATE_RALLYFIELDS_AND_OTHER

このサービスは、最初に CA Agile Central で更新を検索し、新たに変更された(マップされた)フィールドのみをもう一方のシステムにプッシュします。次にもう一方のシステムで更新を検索し、マップされているすべてのフィールドを CA Agile Central にプッシュします。これにより、両方のシステムで作業アイテムが変更される際に、データが上書きされる可能性が低くなります。

例:

コネクタが実行され、作業アイテムがコピーされて、両方のシステムで最新のものになります。

  • CA Agile Central でユーザが Severity を Low に変更する
  • QC でユーザが Description を更新する

古いサービスでは、リストの先頭にある更新サービスが優先されます。たとえば、UPDATE_RALLY_TO_OTHER がリストの先頭にある場合、コネクタは CA Agile Central のすべてのデータを他方のシステムにコピーし、Description の変更は処理されません。

ただし、ここで、コネクタは CA Agile Central の更新を検索し、CA Agile Central のマップ済みフィールドによって変更された内容を確認します。この例では、Severity だけが変更され、コネクタは、すべてのマップ済みフィールドではなく Severity の変更だけを他方のシステムに送信します。その後、コネクタは、他方のシステムの更新を検索し、Description の変更をその他のすべてのマップ済みフィールドと共に CA Agile Central にプッシュします。

新しいサービスの設定:

Config.xml で、 タグを見つけます (通常は設定ファイルの下部にあります)。

タグ内で、UPDATE_RALLYFIELDS_AND_OTHER をリストし、UPDATE_RALLY_TO_OTHER サービスと UPDATE_OTHER_TO_RALLY サービスを削除します。

注:

  • 古い更新サービスが新しいサービスと共にリストされている場合は、古い更新サービスをスキップすることを示す警告が記録されます。

  • フィールド レベル  タグのマッピングは引き続き適用されます。

  • 他方のシステムから CA Agile Central への一方向のデータ フィードおよび更新を設定するには、COPY_OTHER_TO_RALLY と UPDATE_OTHER_TO_RALLY を引き続き使用することをお勧めします。

汎用のフィールド ハンドラ

ドロップダウン値のマッピング

2 つのシステム間でドロップダウン値が異なる場合は、設定ファイルで、マッピングを定義する別のタイプのフィールド ハンドラをセットアップできます。以下に例を挙げます。


    ....
    PriorityBG_PRIORITYSeverityBG_SEVERITY
            ....
        BG_PRIORITYResolve Now1High2Normal3Low4Trivial5None6
            ....
        SeverityCrash Data/LossS1Major ProblemS2Minor ProblemS3CosmeticS4
            ....
        
        ....

上記のコードは、CA Agile Central のフィールド Priority から他方のシステムのフィールド BG_PRIORITY への値のマッピングをセットアップします。 要素の値は、マップされるフィールドの名前にする必要があります。

要素は、CA Agile Central の タグ内の値と、他方のシステムの タグ内の対応する値を定義します。上記の例で、BG_PRIORITY 用の において、CA Agile Central 内の値 Resolve Now は他方のシステム内の値 1 にマップされ、CA Agile Central 内の値 High は他方のシステム内の値 2 にマップされます。

重要: コネクタは、UI 内に エントリなし>> 値の含まれる(たとえば、フィールドが空である)、CA Agile Central 内のドロップダウン フィールドを処理できません。

重要: 複数値のドロップダウン フィールドはサポートされていません。

設定ファイルにその他のフィールドのマッピングをさらに追加するには、上記と同じ形式に従って、対応する値を持つ別の 要素を追加します。

注: このフィールド ハンドラは、多対 1 (または多対少)値の両方のマッピングを可能にします。ただし、多対 1 マッピングが定義されたフィールドでは、逆方向の操作である 1 対多 (または少対多)が定義されていません。たとえば、以下の設定ファイルの構文があります。

        ....
        MyFieldNameSubmittedNEWSubmittedSTUDYClosedFIXEDFixedFIXED
        ....

CA Agile Central から他方にマップするときは、CA Agile Central の値「Submitted」が予測不能の結果を生成します。また、他方から CA Agile Central にマッピングするときは、他方の値「FIXED」が予測不能の結果を生成します。

は、例外だけを宣言する必要がある点を除き とよく似ています。つまり、両方のシステムのプルダウン リスト内の対応するエントリが同一の場合、宣言する必要はありません。

ユーザ名のマッピング

ユーザ名を参照する CA Agile Central のフィールドをマップするには、以下の一方または両方の例のように、 セクション( セクション内)にフィールド マッピングを追加します。

        OwnerBug_OwnerSubmittedByBug_Finder

注: 現在、コネクタの使用を開始する前に、2 つのシステム間でマップされると予想されるすべてのユーザを CA Agile Central で作成することが推奨されています。CA Agile Central を使用しないその他のシステムのユーザについても、システム内のコピーされた作業アイテムに有効なユーザ参照が含まれるよう、CA Agile Central でこれらのユーザのアカウントを作成しておく必要があります。ただし、これらのユーザがアクティブ ユーザとなることを望まない場合は、CA Agile Central で非アクティブとしてマークできます。この場合も、コネクタはこれらの非アクティブ ユーザをポイントするようフィールドを設定できます。

CA Agile Central において、作業アイテム(HierarchicalRequirement、Defect、Test Case など)上の Owner フィールドと SubmittedBy フィールドは「参照」フィールドです。つまり、これらは単純な文字列値を含まないものの、別のオブジェクト(これらの例では User オブジェクト)へのポインタです。コネクタが他方のシステムから CA Agile Central に作業アイテムを更新またはコピーする際には、他方のシステムのユーザ名を CA Agile Central の有効なユーザ名に変換にする必要があります。このタスクを実行するために、コネクタは以下の 4 つの方法のいずれかを使用して、CA Agile Central と他方のシステムの間でユーザ名をマップすることができます。

  1. XML タグを使用する
    CA Agile Central と他方のシステムの間でユーザをマップするには、以下のように セクションで XML タグを指定します。
    
            ....
            Bug_OwnerYourCompanyName.com
            ....

    XML タグには、他方のシステム内のフィールドの名前が含まれていて、 XML タグは、CA Agile Central 内のユーザ名に対して予期されるドメインを指定します。上記の例で、他方のシステム内の peter は CA Agile Central 内の [email protected] にマップされます。

  2. User オブジェクト上の MiddleName (またはその他の)フィールドを使用する
    CA Agile Central 内の各 User プロフィールで、MiddleName (または、User オブジェクト上の使用されていないその他の)フィールドを、他方のシステム内のユーザの正確な ID に割り当てることができます。コネクタは作業アイテムをコピーする際に、CA Agile Central を検索して、MiddleName (または、 タグで指定されているフィールド)が他方のシステムのユーザ名文字列と一致する、ユーザ オブジェクトを見つけます。一致が見つかったら、CA Agile Central のこのユーザは、CA Agile Central のこの新しい作業アイテムに対するフィールド マッピングで使用されます。有効なフィールドは、UserOwnerSubmittedBy、および Tester です。設定ファイルの構文の例:
    
        ....
        OwnerMiddleName
                ....
            
        ....
  3. XML タグを使用する
    ユーザ名のマッピングは、ヘルプの「ドロップダウン値のマッピング」セクションで説明されている方法で実行することもできます。この方法では、基本的にすべてのユーザがシステム間で明示的に割り当てられます。設定ファイルの構文の例:
    
        ....
        RQ_REQ_AUTHOR[email protected]JDoe[email protected]JSmith[email protected]DThomp
                        ....
                    
        ....
    • 注 1: この方法の欠点としては、非常に長いユーザ リストが必要となる場合があります。2 つの異なる「ユーザ名」フィールドをマップする必要がある場合は、上記の マッピングを繰り返す代わりに、前述の「他の XML ファイルを含める方法」で説明されている XML エンティティ機能を使用することもできます。
    • 注 2: この方法でのユーザ名のマッピングで Quality Center コネクタを使用すると、上記の例で CA Agile Central と Quality Center の両方の「User Name」フィールド(「Email Address」フィールドではなく)が使用されます。
  4. XML タグを使用する
    ユーザ名のマッピングは、CSV ファイルを使用して実行できます。こちらの設定ファイルの例を参照してください

CA Agile Central からの参照フィールドのマッピング

CA Agile Central において、作業アイテム内の一部のフィールドは文字列または数値であり、それ以外のフィールドは実際に他のオブジェクトへのポインタ(「参照」と呼ばれる)です。最も一般的に使用される参照フィールドの場合、これらのフィールドを正しくマップするのに追加の構文は必要ありません。あまり頻繁に使用されない CA Agile Central の参照フィールドの中には、マップするフィールドとしてリストするときにコネクタが特殊な構文を用いるものがあります。より高度かつ単純な参照フィールドの処理は、4.4.12 リリースで導入されています。

  • マッピング用途の目的の属性値が Name フィールドである場合、FieldHandler は必要ありません。Project、Release、および Iteration フィールド用の RallyReferenceFieldHandler は廃止されました(4.4.2 以降)。Name 以外の属性(Project、Release、または Iteration)をマップする必要がある場合は、 を使用する必要があります(下記を参照)。
  • その他の参照フィールドに対する高度なフィールド処理。
    該当するフィールドは以下のとおりです。
    • Requirement
    • TestCase
    • TestCaseResult
    • TestFolder
    • WorkProduct

    これらのフィールドは、CA Agile Central の HierarchicalRequirement、Defect、TestCase などの作業アイテム内にあります。

    目的のルックアップ属性に対して、 タグと共に RallyReferenceFieldHandler を使用します。ルックアップ属性には、非参照フィールドを指定する必要があります。このような属性の例には、「Name」や「ObjectID」があります。

  • Name フィールド以外の目的のルックアップ属性を持つ Project、Release、または Iteration: を使用し、マップ値として使用する特定の属性に対して、対応する タグを指定します。
  • 設定ファイルの セクション内で、 セクションでマップするフィールドを指定します。
  • また、設定ファイルの セクション内に、 セクションを作成します。
  • このセクション内で、 要素でフィールドを the_name_of_the_field として指定します。
  • タグと値が指定されていない場合は、デフォルトで「Name」属性が使用されます。
  • デフォルト値が目的に適さない場合は、 タグと値を明示的に指定します。ここで、値は CA Agile Central の作業アイテム属性(「DisplayName」、「FormattedID」、「ObjectID」など)となります。

構文の例:


    ....
    RequirementBG_USER_07
            ....
            RequirementFormattedID
        ....

任意の作業アイテム コネクタ 4.4.0 以降(4.4.x、4.5.x、...)を実行する際に、コネクタが Project、Release、または Iteration フィールドのいずれかに対して の使用を検出した場合、廃止通知(警告)がログ ファイルに書き込まれ、その特定のフィールドのフィールド ハンドラは登録されません。このフィールドは、参照アイテムの Name フィールドを使用してマップされます。

要素に複数の CA Agile Central プロジェクトがリストされている場合、他方のシステムの作業アイテムが CA Agile Central にコピーされ、リストの先頭にある CA Agile Central プロジェクトに配置されます。

CA Agile Central との間でのブール値フィールドのマッピング

CA Agile Central において、作業アイテム内の一部のフィールドはブール値を持ちます。これらのフィールドは、Jira ラジオ ボタンまたは[HP ALM のブール値]フィールドにマップできます。Jira Check Box フィールドにマップすることもできますが、Jira Check Box フィールドは複数値フィールドなのでお勧めできません。この fieldhandler は、両方向にフィールドをマップします。

  • 設定ファイルの セクション内で、 セクションでマップするフィールドを指定します。
  • また、設定ファイルの セクション内に、 セクションを作成します。
  • このセクション内で、 要素でフィールドを the_name_of_the_Rally_field として指定します。
  • セクションで、マップする値を指定します。

構文の例:


    ....
    TestBooleanJiraRadioButton
            ....
            TestBooleantrueyesfalseno
        ....

コネクタのロックファイル

コネクタは実行されるたびに、LOCK.tmp という名前のロックファイル(作業フォルダ内)を作成します。このファイルはコネクタが終了するまで存在し、その時点でロックファイルは削除されます。ロックファイルの内容は、以下の形式の 1 行となります。

以下に例を挙げます。

1684 2012-06-20 16:24:00 Z MyConfig.xml -1

コネクタは呼び出されるたびに、作業フォルダ内にロックファイルが存在するかどうかを確認します。

  • ロックファイルが見つかると、コネクタは以下の警告を発行します。
    WARN : ConnectorRunner.acquire_lock - A LOCK.tmp file exists
    その後、コネクタは、ロックファイルを作成した PID (プロセス ID)がまだ存在するかを判断しようとします。
    • PID がまだ実行されている場合、コネクタは、このエラーを出力した後に終了します。
      ERROR : ConnectorRunner.acquire_lock - Another connector process (1234) is still running, unable to proceed
      ERROR : ConnectorRunner.acquire_lock - Simultaneous processes for this connector are incompatible, exiting now
      ERROR : ConnectorRunner.acquire_lock - Unable to proceed with this invocation of the connector
    • PID が削除されている場合、コネクタはこの警告を出力した後、正常に続行します。
      WARN : ConnectorRunner.acquire_lock - A prior connector process (1234) did not clean up
                                            the lock file on termination, proceeding with this run
  • ロックファイルが見つからない場合、コネクタはロックファイルを作成し、完了したら、コネクタはロックファイルを削除します。

これにより、同じ作業フォルダからコネクタの複数のインスタンスが呼び出されることが防止されます。

Windows XP でスケジュール済みタスクとして実行

実稼働に展開する準備が整ったら、スケジュール済みタスクとして実行することを検討してください。Windows で、以下の手順に従ってスケジュール済みタスクをセットアップします(この例では Quality Center を想定しています)。

  1. バッチ ファイルを作成します(たとえば、以下の例の rallyWin7-qc.bat)。以下のスクリプトでは 2 つの変数が定義されています。
    • cfolder - コネクタがインストールされるフォルダ(通常は「C:\Program Files (x86)\RallyConnectorforQualityCenter」など)。
    • wfolder - ユーザが作業するフォルダ(作業ディレクトリ)。通常は「C:\Users\johndoe」などのホーム ディレクトリです。
      ::
      :: rallyWin7-qc.bat
      ::
      
      :: Set the "Connector folder" (where the connector has been installed).
      set cfolder="C:\Program Files (x86)\RallyConnectorforQualityCenter"
      
      :: Set the "Working folder" (where the configurations files are kept and
      :: modified; this is typically somewhere in the user's home folder).
      set wfolder="C:\Users\johndoe\QCconfigFiles"
      
      :: Invoke the connector.
      %cfolder%\rally2_qc_connector.exe %wfolder%\qc-config.xml -1 >> %wfolder%\Connector.log 2>&1
      
      ::the end::
      注: 上記のスクリプトで:
      • 2 番目の引数である -1 は、1 回だけ実行してから終了するようコネクタに指示します。
      • コネクタは実行時に、作業フォルダ(wfolder 変数)内の rallylog.log という名前のファイルにそのステータス メッセージを追加します。
      • すべての致命的なエラー メッセージ(アクセス許可の拒否など)は、Connector.log ファイルのほか、作業フォルダ(wfolder 変数)にも格納されています。
  2. [スタート]をクリックし、[すべてのプログラム]-[アクセサリ]-[システム ツール]-[スケジュールされたタスク]を選択します。
  3. [スケジュールされたタスク]ウィンドウで、[スケジュールされたタスクの追加]をダブルクリックします。
  4. [タスク ウィザード]ウィンドウで、[次へ]をクリックします。
  5. 次のウィンドウ(実行するプログラムを選択するウィンドウ)で[参照]をクリックし、上記で作成したバッチ ファイル(rallyWInXP-qc.bat など)を見つけて選択(強調表示)し、[開く]をクリックします。その後、以下の操作を行います。
    1. 次のウィンドウで、タスクに任意の名前を付けます(または、デフォルトを使用します)。
    2. [Perform this task: (タスクの実行頻度:)]の選択で[日単位]をクリックし、[次へ]をクリックします。
    3. 次のウィンドウ(見出しは[Select the time and day you want this task to start (このタスクを開始する日付と時刻)])で、以下の操作を行います。
      • [開始時間:]ダイアログ ボックスで、[午前 0 時]を選択します。
      • [毎日]を選択します。
      • [開始日]を選択します(または、デフォルトを使用します)。
      • [次へ]をクリックします。
    4. 次のウィンドウで、スケジュール済みタスクを実行するユーザ(ウィンドウ ボックスで有効なユーザである必要がある)のユーザ名とパスワードを入力し、[次へ]をクリックします。
    5. 次の(最後の)ウィンドウ([You have successfully scheduled the following task (次のタスクを正常にスケジュールしました)])で、[Open advanced properties for this task when I click Finish ([完了]をクリックしたら、このタスクの高度なプロパティを開く)] チェックボックスをオンにし、[完了]をクリックします。
  6. 次のウィンドウで、以下を確認します。
    1. [タスク]タブの[実行:]ボックスに、以前に作成された BAT スクリプトへの正しいパス名が含まれている必要があります。
    2. [Start in: (開始場所:)] ボックスに、このスクリプトを実行するフォルダへの正しいパス名が含まれている必要があります。
    3. [Run only if logged on (ログオン時にのみ実行する)]チェックボックスはオンにしないでください。
    4. [スケジュール]タブで、[詳細]ボタンをクリックします。
    5. 次の[Advanced Schedule Options (詳細なスケジュール オプション)]ウィンドウで、[Repeat task (タスクを繰り返す)]チェックボックスをオンにします。
    6. [Repeat task: (タスクを繰り返す頻度:)]セクションで、以下の操作を行います。
      • [Every: (間隔:)]ボックスに、「15」と「」を入力します。
      • [Until: (終了:)]ダイアログ ボックスで[Time: (時間:)]を選択し、「午後 11 時 59 分」を入力します。
      • OK]をクリックします。
      • もう一度[OK]をクリックします。

上記の手順では、毎日(午前 0 時~午後 11 時 59 分) 15 分間隔で実行するタスクを設定します。[スケジュール済みタスク]のリストを確認する場合は、[スケジュール]列に[Every 15 minute(s) from 12:00 AM for 1439 minutes every day, starting MM/DD/YYYY (MM/DD/YYYY より、毎日午前 0 時から 1439 分間、15 分間隔で実行]と表示され、[次回実行時]列に 15 分以内のタイムスタンプが表示されます。予定されているタイム スタンプがリストに表示されない場合は、手順を再度確認するか、または Windows のスケジュール済みタスク(WindowsXPWindows7 など)の設定について Microsoft のドキュメントを参照してください。

Windows 7 でスケジュール済みタスクとして実行

以下に、Windows 7 上でスケジュール済みタスクをセットアップする実際の例を示します。この例は、CA Agile Central の Quality Center コネクタに対して実行されました。

  1. 簡単なバッチ ファイル(QC ヘルプ ページのサンプルの startqc-simple.bat など)を作成します。
  2. [スタート]をクリックし、[すべてのプログラム]-[アクセサリ]-[システム ツール]を選択して、[タスク スケジューラ]をクリックします。
  3. [タスク スケジューラ]ウィンドウで、[操作]-[タスクの作成]をクリックします。
  4. [タスクの作成]ウィンドウが、最初の[全般]タブ内で開きます。
    • [名前]ボックスに、「RallyQCconnector」と入力します。
    • [説明]ボックスに、「CA Agile Central の HP ALM/QC コネクタ」と入力します。
    • [ユーザがログオンしているかどうかにかかわらず実行する]オプションをオンにします。
    • [パスワードを保存しない]チェックボックスをオンにします 。
      • 注: TFS 作業アイテム コネクタを使用している場合は、コネクタの自動実行を許可するためにパスワードを格納する必要があるので、このチェックボックスをオフのままにします。
  5. [トリガ]タブをクリックします。
    • [新規](左下部付近)をクリックすると、「新しいトリガ」ウィンドウが表示されます。
    • [タスクの開始]プルダウン リストで、[タスクの作成/変更時]を選択します。
    • [繰り返し間隔:]チェックボックスをオンにし、プルダウン リストで[15 分]を選択します。
    • [継続時間:]プルダウン リストで、[無期限]を選択します。
    • [有効期限:]チェックボックスをオンにします(現在の日付と時刻がすでに表示されている必要があります)。
    • [有効]チェックボックスをオンにします(すでにオンになっているはずです)。
    • [OK]をクリックします。
  6. [操作]タブをクリックします。
    • [新規](この場合も左下部付近)をクリックすると、「新しい操作」ウィンドウが表示されます。
    • [操作]ボックスで、[プログラムの開始]を選択します(すでに選択されているはずです)。
    • [プログラム/スクリプト:]ボックスで[参照...]をクリックし、BAT ファイルを見つけます。この場合は C:\Users\jpkole\MyQCfiles\startqc-simple.bat にあります。
    • [開始(オプション):]ボックスに、フォルダ名「C:\Users\jpkole\MyQCfiles」を入力します。
    • [OK]をクリックします。
  7. [条件]タブで、各デフォルト値をそのままにしました。
  8. [設定]タブで、デフォルト値をそのままにしました。
  9. [タスクの作成]ウィンドウの下部にある[OK]をクリックします。
  10. タスクが実行されます。

エラーと警告の電子メール通知

コネクタは、ログ ファイルにエラーまたは警告が発生したときに電子メールを送信できます。この機能が有効になると、コネクタは、使用される各設定ファイルに対してサマリ電子メールを送信でき、電子メールの件名行には設定ファイルの名前が含まれます。電子メールを複数のアドレスに送信するには、セミコロンを使用して電子メール アドレスを区切ります。その設定ファイルに対してコネクタが実行されている間に発生したすべてのエラーおよび警告が収集され、以下のように電子メールでレポートされます。

  • レベルが Error に設定されている場合は、すべてのエラーを含むサマリ電子メールが送信されます。
  • レベルが Warning に設定されている場合は、すべてのエラーおよび警告を含むサマリ電子メールが送信されます。

注: タグでサポートされている値は、以下の 2 つだけです。

  • Error
  • Warning

以下に、この機能を有効にするために必要な設定ファイルの構文の例を 2 つ示します。

標準的な SMTP サーバ - 認証なし:


    ....
    FalseDebugCOPY_RALLY_TO_OTHERWarning[email protected][email protected]smtp.acme.com25

SMTP サーバ - TLS および認証を使用:


    ....
    FalseDebugCOPY_RALLY_TO_OTHERWarning[email protected][email protected]smtp.acme.com587Your-Domain.com[email protected]Your-PasswordTLS

サンプル設定ファイル

  • BUGZILLA


    1. BZ-config-Keywords2Tags.pxml

      CA Agile Central のディフェクトのタグを Bugzilla のバグのキーワードに転送する設定ファイル。

    2. BZ-config-TestConnection.pxml

      Bugzilla および CA Agile Central に接続してクライアントが持つ実証を提供する、単純な設定ファイル。

      • Ruby がインストールされていて、アクセス可能である。
      • すべての Ruby gem の準備が整っている。
      • 両方のシステムへの接続が確立されている。
      • 設定ファイルの構文が正しい。
      • ファイルへのパス名が正しい。

  • JIRA


    1. Jira-config-Emailer-NoAuth.pxml

      CA Agile Central の JIRA (およびその他の)コネクタの 機能をテストします。これにより、エラーまたは警告が発生した場合にのみ、指定されたユーザに非認証の電子メールが送信されます。

    2. Jira-config-Emailer.pxml

      CA Agile Central の JIRA (およびその他の)コネクタの 機能をテストします。これにより、エラーまたは警告が発生した場合にのみ、指定されたユーザに電子メールが送信されます。

    3. Jira-config-RallyJiraCommentLinker.pxml

      CA Agile Central と JIRA の間でディスカッションやコメントをコピーするために使用します。

    4. Jira-config-TestConnection.pxml

      JIRA および CA Agile Central に接続してクライアントが持つ実証を提供する、単純な設定ファイル。

      • Ruby がインストールされていて、アクセス可能である。
      • すべての Ruby gem の準備が整っている。
      • 両方のシステムへの接続が確立されている。
      • 設定ファイルの構文が正しい。
      • ファイルへのパス名が正しい。
    5. Jira-config-bugAttachment2Rally.pxml

      CA Agile Central の JIRA コネクタの 機能をテストします。これにより、JIRA のバグ(添付ファイル付き)が CA Agile Central のディフェクトに添付ファイルと共にコピーされます。

    6. Jira-config-us2task.pxml

      CA Agile Central のユーザ ストーリーを JIRA のタスクにコピーするために使用する設定ファイル。
       


       

    7. JIRA5rest-config-TestConnection.pxml

      JIRA5 および CA Agile Central に接続してクライアントが持つ実証を提供する、単純な設定ファイル。

      • Ruby がインストールされていて、アクセス可能である。
      • すべての Ruby gem の準備が整っている。
      • 両方のシステムへの接続が確立されている。
      • 設定ファイルの構文が正しい。
      • ファイルへのパス名が正しい。
    8. JIRA5rest-config-simple.pxml

      CA Agile Central のディフェクトを JIRA5 のバグにコピーする単純な設定。

    9. JIRA5rest-config-CrosslinkUrlField.pxml

      JIRA のバグを CA Agile Central のディフェクトにコピーするために使用する設定。コピーが完了したら、JIRA のバグと CA Agile Central のディフェクトの両方に、他方のシステム内の作業アイテムへのクリック可能なリンクが生成されます。

    10. JIRA5rest-config-storyAttachment.pxml

      CA Agile Central の JIRA コネクタの 機能をテストします。これにより、JIRA のストーリー(添付ファイル付き)が CA Agile Central のストーリーに添付ファイルと共にコピーされます(その逆も同様です)。

    11. JIRA5rest-config-DueDate.pxml

      CA Agile Central の「CreationDate」(読み取り専用フィールド)から JIRA の「Due Date」へのコピーを示します(これは一方向のコピーです)。

    12. JIRArest-Labels-to-Tags.pxml

      CA Agile Central のタグを JIRA のラベルとの間で両方向にコピーおよび更新するために使用します。

  • QC

    1. QC-config-Emailer-NoAuth.pxml

      CA Agile Central の QC (およびその他の)コネクタの  機能をテストします。 これにより、エラーまたは警告が発生した場合にのみ、指定されたユーザに非認証の電子メールが送信されます。

    2. QC-config-CopyTests2TestCases.pxml

      この設定ファイルは、この方法で Quality Center から CA Agile Central への(一方向のみの)コピーを行います。

      • コピー元: QC の TestPlan の「Test」

      • コピー先: CA Agile Central の TestFolder 内(TestPlan 下)の「TestCase」

    3. QC-config-TestConnection.pxml

      Quality Center システムおよび CA Agile Central システムに接続してクライアントが持つ実証を提供するために使用します。

      • 両方のシステムへの接続が確立されている。

      • 設定ファイルの構文が正しい。

      • ファイルへのパス名が正しい。

    4. QC-config-bugReq2Rally.pxml

      CA Agile Central の新しいディフェクト上の「Requirement」フィールドに CA Agile Central のユーザ ストーリーへのポインタが含まれるよう、CA Agile Central の UserStory FormattedID が含まれているカスタム フィールドを含む QC のバグを、CA Agile Central のディフェクトにコピーするために使用します。

    5. QC-config-bugs2QC.pxml

      CA Agile Central のディフェクトを QC のバグにコピーする、単純な QC コネクタ設定ファイル。

    6. QC-config-bugs2Rally.pxml

      QC のバグを CA Agile Central のディフェクトにコピーする、単純な QC コネクタ設定ファイル。

    7. QC-config-reqs2stories.pxml

      QC の要件を CA Agile Central のユーザ ストーリーにコピーするために使用する設定ファイル。

    8. QC-config-test-steps-01.pxml

      CA Agile Central のテスト ケースおよびステップから QC のテストおよびテスト ステップへの 1 回限りのコピー(のみ)を実行する設定ファイル。
      注: 更新はサポートされていません。

    9. QC-config-test-steps-02.pxml

      QC のテストおよびテスト ステップから CA Agile Central のテスト ケースおよびステップへの 1 回限りのコピー(のみ)を実行する設定ファイル。
      注: 更新はサポートされていません。

    10. QC-config-run2testcaseresult.pxml

      以下のことを行う 2 つの設定ファイルです。

      1. QC のテストを CA Agile Central のテスト ケースにコピーする

      2. QC の実行を CA Agile Central のテスト ケース結果にコピーする

    11. QC-custom-fieldhandler.pxml

      「Description」内の指定されたテキスト文字列のすべてのオカレンスを変換するために QC コネクタによって使用される、カスタム フィールド ハンドラをテストします。

    12. QC-RallyUsernameToQcUser.pxml

      という名前のカスタム フィールド ハンドラ。CA Agile Central のディフェクト上の「SubmittedBy」フィールドと「Owner」フィールドを QC の「BG_DETECTED_BY」フィールドと「BG_RESPONSIBLE」フィールドにそれぞれマップするために、QC コネクタによって使用されます。CA Agile Central の Username フィールドと QC の User フィールドの唯一の違いは、アット記号(@)とアンダースコア(_)です。

    13. QC-Copy-TestCases-and-Steps.pxml

      CA Agile Central の「テスト ケース」と「ステップ」を QC にコピーし、QC の「テスト」および「設計ステップ」を CA Agile Central にコピーするために使用します。

    14. QC-config-us2folder.pxml

      QC の特定のフォルダから QC の要件をコピーし、CA Agile Central のユーザ ストーリーを同じ QC フォルダにコピーするために使用します。

    15. QC-config-concat.pxml (2 つの設定ファイルを含む)

      および   を実証するために使用します。.

    16. QC-config-ReqTest-2-StoryTestcase.pxml (2 つの設定ファイルを含む)

      これらの 2 つの設定ファイルは、QC の要件と QC のテストの関係を保持する方法で、QC の要件および QC のテスト(QC のテスト計画下)をコピーします。
      注: この機能は、QC から CA Agile Central への方向にのみ動作します。

    17. QC-config-RallyCSVUserMapping.pxml

      CSV ファイルを使用して CA Agile Cetral のユーザ名と QC のユーザ名の間の関係を定義することで、CA Agile Central の Owner フィールドと SubmittedBy フィールドを QC の BG_RESPONSIBLE フィールドと BG_DETECTED_BY フィールドにマップしながら、CA Agile Central のディフェクトと QC のバグとの間でコピーを行うために使用するサンプル設定ファイル。

  • TFS

    1. TFS-config-TestConnections.pxml

      CA Agile Central と TFS の両方に接続するために使用してから終了する、最小限の設定ファイル(TFS2010 および TFS2012 でテスト済み)。

    2. TFS-config-us2task.pxml

      CA Agile Central のユーザ ストーリーを TFS の要件にコピーするために使用する設定ファイル。
      ---------------------------------------------------------------------

    3. TFS2012-config-CrosslinkUrlField.pxml

      TFS2012 機能をテストするために使用する 設定ファイル。

    4. TFS2012-config-Stories-and-linked-Tasks.pxml

      CA Agile Central のストーリーおよびその関連タスクを TFS2012 にコピーするために使用します(TFS2012 での関連付けを保持します)。この例では、  および 2 つの  要素(  )を使用します。.

XML 構文エラーの検出

XML 設定ファイルは冗長で複雑なものになり、構文エラーの検出が妨げられることがあります。このような問題については、この Web ページ: http://www.w3schools.com/xml/xml_validator.asp を使用して XML の検証を行うことができます。

XML テキストをコピーしてウィンドウに貼り付け、[検証]ボタンをクリックします。

通常、設定ファイル内の構文エラーは rallylog.log ファイルに記録されます。以下に例を挙げます。

 

  • タグまたは タグ内の特殊文字:
    これらのフィールドに特殊文字が含まれている場合は、これらの文字を以下のようにエスケープする必要があります。
    • 「&」(アンパサンド)は「&」として入力する
    • 「>」(より大きい)は「>」として入力する
    • 「」(より小さい)は「<」として入力する

    例 1: 以下の(無効な)設定ファイル スニペット、およびログ ファイル出力に注意してください。

    JP & Nick Project
                    ....
    ERROR : Class.initialize - xmlParseEntityRef: no name
    ERROR : ConnectorRunner.initialize - xmlParseEntityRef: no name
    ERROR : Object.exception - Message xmlParseEntityRef: no name
    ERROR : Object.exception - Stack Trace
    ....

    例 2: わずかな変更が行われ、エラー レポートが異なっていることに注意してください。

    JP&Nick Project
                    ....
    ERROR : Class.initialize - EntityRef: expecting ';'
    ERROR : ConnectorRunner.initialize - EntityRef: expecting ';'
    ERROR : Object.exception - Message EntityRef: expecting ';'
    ERROR : Object.exception - Stack Trace
    ....

EIF コネクタの既知の制限

EIF (拡張可能なインターフェース フレームワーク)と呼ばれる共通ライブラリ上に構築された 5 つのコネクタ: Atlassian JIRA、Bugzilla、IBM ClearQuest、HP Quality Center (ALM)、および TFS があります。これらのコネクタの既知の制限を以下に示します。

 

  1. CA Agile Central での Tag オブジェクトの使用。
    CA Agile Central のタグは以下のコネクタのみでサポートされています。
    1. Bugzilla (こちらの使用例を参照)
    2. CQ
    3. JIRA (こちらの使用例を参照)
  2. SSO がサポートされていない。
    CA Agile Central Workitem コネクタ(および CA Agile Central SCM コネクタ)は、SSO 機能と互換性がありません。ただし、これらのコネクタは SSO 例外モードで使用することができます。
  3. CA Agile Central の作業アイテム上の一部の新しいフィールドを使用できない。
    以前のバージョンの EIF コネクタでは、コネクタ構築の基盤となったフレームワークが、CA Agile Central WSPAI バージョン 1.42 に結合されていました。このため、最新バージョンの CA Agile Central WSAPI (本書の作成時点では v2.0)の新しいフィールドをそれらの古いバージョンのコネクタで利用できませんでした。古いバージョンのコネクタで利用できない、一般的に必要な「新しい」フィールドには、以下のものがあります。
  4. コネクタは空のマップ済みのフィールドをコピーしない。
    マップされたフィールドがユーザによって手動でクリアされた場合、コネクタによって、この「クリア」は他方のシステムにコピーされません(たとえば、他方のシステム内のフィールドはクリアされません)。これはコネクタの設計機能であり、その理由にはさまざまなものがあります。考えられる回避策としては、本質的に「未設定」を表す文字列値を各システムで定義し、それらの値を一緒にマップします。

EIF コネクタによって生成される一般的なエラー

  1. Ctrl + C コネクタの実行中に Ctrl + C を押した場合、ログ ファイルで以下のエラーが生成される可能性があります。
    ERROR : ConnectorRunner.initialize - 
    ERROR : Object.exception - Message 
    ERROR : Object.exception - Stack Trace
    ERROR : Object.block in exception - /Users/..../yeti-2.8.8/lib/yeti/connector_runner.rb:170:in `sleep'
    ERROR : Object.block in exception - /Users/..../yeti-2.8.8/lib/yeti/connector_runner.rb:170:in `run'
    ERROR : Object.block in exception - ./rally2__connector.rb:30:in `
    '

フィードバック

ヘルプをお求めですか?CA Agile Central コミュニティは、セルフサービスとサポートのワンストップ ショップです。CA Agile Central サポートにフィードバックを送信したり、答を見つけたり、他のユーザとのコラボレーションには CA Agile Central コミュニティ にご参加ください。