エンティティメタデータリファレンス

ALM OctaneパブリックREST APIは、完全にメタデータ駆動型です。メタデータリソースによって記述されたすべてのエンティティは、リソースコレクションとしてREST APIを介してアクセスできます。

エンティティメタデータは、エンティティがサポートするフィーチャーを記述します。ここでは、REST APIでフィーチャーがどのように表されるかについて説明します。

URI

ワークスペースレベル

http[s]://<server>:<port>/api/shared_spaces/<space_id>/workspaces/<workspace_id>/metadata/entities
共有スペースレベル

http[s]://<server>:<port>/api/shared_spaces/<space_id>/metadata/entities
サイトレベル

http[s]://<server>:<port>/admin/metadata/entities

注

  • URIは、名前によるフィルタリングをサポートしています。

  • URIでパラメーターを指定するための構文については、変数と値を参照してください。

サポートされているHTTPメソッド

このAPIはGET操作のみをサポートします。

プロパティ

エンティティ 説明
Name

メタデータが定義されているエンティティ名。

フィールド名:name
Features

エンティティによってサポートされるフィーチャーの配列。

各項目はJSONオブジェクトです。

フィールド名:features
Description エンティティの説明。
Label エンティティのラベル。通常、ALM Octane UIに表示されます。

トップに戻る

Features

次の表に、使用可能なフィーチャーを示します。

REST

REST API関連定義

フィールド 説明
name フィーチャーの名前は定数値です:rest。
url コンテキストルートに関連するリソースURL。
methods

HTTPプロトコルメソッドがサポートした文字列の配列。値:

  • GET

  • POST

  • PUT

  • DELETE

例: この例は、ワークスペースエンティティ (共有スペースレベル) 用です。

{
    "name": "rest",
    "url": "workspaces",
    "methods": [ "GET", "POST", "PUT" ]
}

Mailing

エンティティがメーリングをサポートしているかどうか。

フィールド 説明
name

フィーチャーの名前は定数値です: mailing。

 
例: {
    “name”: “mailing”
    “url”: “mails”
}

Not audit-able

監査にRESTAPIを使用するときに、エンティティを一覧表示できるかどうか。

詳細については、監査エンティティ (テクニカルプレビュー)を参照してください。

フィールド 説明
name

フィーチャーの名前は定数値です: non-auditable。このフィーチャーがエンティティに対してリストされている場合、そのエンティティは監査中に表示されません。

 
Example: {
    “name”: “non-auditable”
}

History

履歴を表示するためにRESTAPIを使用するときに、エンティティを一覧表示できるかどうか。

詳細については、履歴の表示 (テクニカルプレビュー) を参照してください。

フィールド 説明
name

フィーチャーの名前は定数値です:history。このフィーチャーがエンティティにリストされている場合、履歴を表示するとエンティティが表示されます。

 
例: {
    “name”: “history”
}

Drafts

作業項目 (エピック、フィーチャー、ユーザーストーリー、および不具合) のドラフトを作成できるかどうか。

APIを介して作業項目をPOSTするときに、ドラフトを使用して検証ルールをバイパスします。これにより、APIを使用した統合により、たとえば必須フィールドを検証することなく、作業項目をすばやく作成できます。

詳細については、ドラフトエンティティを参照してください。

フィールド 説明
name

フィーチャーの名前は定数値です:draft_mode。

 
例: {
    “name”: “draft_mode”
}

Attachments

エンティティが<context>/attachments APIにアクセスして添付ファイルをサポートするかどうか。

フィールド 説明
name

フィーチャーの名前は定数値です:attachments。

このフィーチャーをサポートするエンティティに添付ファイルを追加するには、添付ファイルエンティティのフィールドを使用して、<context>/attachmentsリクエストでエンティティを参照します。

所有者_<エンティティ名>

ここで、エンティティ名は、エンティティが属性のsubtypeを持っている場合、エンティティ名または親エンティティ名にすることができます。

実際のフィールド名は、添付エンティティのフィールドメタデータAPIを介して照会できます。詳細については、フィールドメタデータリファレンスを参照してください。

例: owner_defect

添付エンティティには、1つの所有者エンティティのみへの参照が必要です。

 
例: {
{
    “name”: “attachments”
}

Comments

エンティティが<context>/commentsAPIにアクセスしてコメントをサポートするかどうか。

フィールド 説明
name

フィーチャーの名前は定数値です:comments。

実際のフィールド名は、コメントエンティティのフィールドメタデータAPIを介して照会できます。詳細については、フィールドメタデータリファレンスを参照してください。

例: owner_defect

コメントエンティティには、1つの所有者エンティティのみへの参照が必要です。

 
例: {
    “name”: “comments”
    “relation_name”: “comments_to_epic”
}

Rules

エンティティがルールをサポートしているかどうか。

フィールド 説明
name

フィーチャーの名前は定数値です:business_rules。

 
例: {
    “name”: “business_rules”
}

Subtypes

エンティティにサブタイプがあることを定義します。

集約されたエンティティには、エンティティインスタンスのサブタイプを格納するサブタイプというフィールドがあります。同様に、サブタイプインスタンスには、サブタイプのというフィールドがあります。これは、インスタンスが関連付けられている集約エンティティを示します。

フィールド 説明
name

フィーチャーの名前は定数値です:サブタイプ。
types

このエンティティのサブタイプであるエンティティの名前の文字列配列。

 
例: {
    “name”: “subtypes”,
    “types”: [
        “defect”,
        “feature”,
        “epic”,
        “work_item_root”,
        “story”
    ]
}

Subtype of

エンティティが別のエンティティのサブタイプであることを定義します。

「のサブタイプ」であるエンティティには、サブタイプのというフィールドがあります。これは、それらが関連する集約されたエンティティを示します。同様に、集約されたエンティティには、エンティティインスタンスのサブタイプを格納するサブタイプというフィールドがあります。

フィールド 説明
name

フィーチャーの名前は定数値です:subtype_of。
type

サブタイプフィーチャー定義にこのエンティティがあるエンティティの名前。

 
例: {
    “name”: “subtype_of”,
    “type”: “work_item”
}

Phases

定義されたワークフローを使用して、エンティティのステータスをフェーズからフェーズに進める機能がサポートされています。

フィールド 説明
name

フィーチャーの名前は定数値です:phases。

 
例: {
    “name”: “phases”
}

Hierarchy

エンティティが階層的であるかどうかを定義します。

フィールド 説明
name

フィーチャーの名前は定数値です:hierarchy
root

次のフィールドを持つ階層内のルートエンティティ:

  • type。ルートエンティティのタイプ-多くの場合、work_item_root。

  • id。ルートエンティティのID。

    空でない配列の場合、名前childrenの複数参照フィールドがエンティティに存在します (このフィールドはフィールドメタデータAPIで定義されます)。

    空でない配列の場合、parentsという名前の参照フィールドがエンティティに存在します (このフィールドはフィールドメタデータAPIで定義されます)。

  • child_types。文字列の配列、子エンティティに許可されるタイプ。

  • parent_types。文字列の配列、親エンティティに許可されているタイプ。

  • max_depth。階層で許可されるレベルの最大数。

この例は、階層フィーチャーがproduct_areaエンティティ (アプリケーションモジュールとも呼ばれます) をどのように検索するかを示しています。

例: {
      "features": [
        {
          "methods": [
            "DELETE",
            "POST",
            "GET",
            "PUT"
          ],
          "name": "rest",
          "url": "product_areas"
        },
        {
          "parent_types": [
            "product_area"
          ],
          "max_depth": 4,
          "root": {
            "type": "product_area",
            "id": "1001"
          },
          "name": "hierarchy",
          "child_types": [
            "product_area"
          ]
        }
      ],
      "name": "product_area",
      "description": "Also known as an application module, a product area is a functional area of the application you are developing. Use product areas to test overall product quality (such as regression testing, end-to-end cross-feature testing).",
      "label": "Product Area",
      "type": "entity_metadata"
    },
例: {
      "features": [
        {
          "name": "mailing",
          "url": "mails"
        },
        {
          "name": "attachments",
        },
        {
          "parent_types": [
            "epic"
          ],
          "max_depth": 4,
          "root": {
            "type": "work_item_root",
            "id": "1001"
          },
          "name": "hierarchy",
          "child_types": [
            "defect",
            "story",
            "quality_story"
          ]
        },
        {
          "name": "comments",
        },
        {
          "name": "phases"
        },
        {
          "name": "subtype_of",
          "type": "work_item"
        },
        {
          "name": "user_defined_fields"
        },
        {
          "methods": [
            "DELETE",
            "POST",
            "GET",
            "PUT"
          ],
          "name": "rest",
          "url": "features"
        },
        {
          "name": "business_rules"
        }
      ],
      "name": "feature",
      "description": null,
      "label": "Feature",
      "type": "entity_metadata"
    },   

トップに戻る

不具合エンティティの例

エンティティリソースは、コレクションのメンバーに対して返されたデータに関するメタデータを返します。以下は、不具合エンティティのメタデータの例です。

        {
            "features": [
                {
                    "parent_types": [
                        "feature",
                        "work_item_root"
                    ],
                    "max_depth": 4,
                    "root": {
                        "type": "work_item_root",
                        "id": "1001"
                    },
                    "name": "hierarchy",
                    "child_types": []
                },
                {
                    "methods": [
                        "DELETE",
                        "POST",
                        "GET",
                        "PUT"
                    ],
                    "name": "rest",
                    "url": "defects"
                },
                {
                    "name": "mailing",
                    "url": "mails"
                },
                {
                    "name": "attachments",
                },
                {
                    "name": "phases"
                },
                {
                    "name": "subtype_of",
                    "type": "work_item"
                },
                {
                    "name": "user_defined_fields"
                },
                {
                    "name": "comments",
                },
                {
                    "name": "business_rules"
                }
            ],
            "name": "defect",
            "description": "A problem detected in the application.",
            "label": "Defect",
            "type": "entity_metadata"
        },

トップに戻る

参照情報: