Standard または Advancedのライセンスで利用可能。
どのブランチ バージョニング シナリオを使用するかは、組織のビジネス要件によって決まります。
ワークフローはそれぞれに異なりますが、多くの場合、ワークフローは段階的に発展し、それぞれの段階で異なるリソースの割り当てやビジネス ルールが必要になります。 一般に、プロセス全体の各段階は、作業指示やジョブなど、単一の作業単位を表します。 これらを管理するために、個別のバージョンを作成して、それを編集することができます。 作業が完了したら、変更内容をデフォルト バージョンに統合することができます。
組織とビジネスの要件、およびブランチ バージョン シナリオの主なポイントを理解すれば、組織に最適な設定を選択するのに役立ちます。
バージョニングのコンセプトは、ブランチ バージョニング シナリオを使用する場合でも、トラディショナル バージョニング シナリオを使用する場合でも同じです。 バージョニングにより、データをコピーしなくても、データの複数のリプレゼンテーションを作成できるため、同時編集が可能になります。また、ユーザーは長期間にわたってバージョンを使用することができます。 詳細については、「バージョニングの概要」をご参照ください。
ブランチ バージョニングとは、ArcGIS Enterprise Web GIS モデルで使用されるジオデータベースのバージョニングのタイプです。サービスベースのアーキテクチャによってマルチユーザーの編集ワークフローを可能にするとともに、Web フィーチャ レイヤーを介したロング トランザクション シナリオも行えます。 Web フィーチャ レイヤー (フィーチャ サービスとも呼ばれます) は、Web 上のデータの表示、検索、および編集をサポートするために、共有されるレイヤーです。
ブランチ バージョニングはシンプルなフィーチャクラスとテーブルに加え、エンタープライズ ジオデータベースのユーティリティ ネットワークやパーセル ファブリックなどのより複雑なジオデータベース データセットもサポートしています。 Web フィーチャ レイヤーにアクセスして実行できる各種ワークフローに対応するためには、データセットを適切に準備することが重要です。 データをブランチ バージョン対応登録し、エンタープライズ ジオデータベースから公開する必要があります。 Web フィーチャ レイヤーを公開すると、バージョンで行われたフィーチャの挿入、更新、削除操作の編集をブランチ バージョニングで追跡できるようになります。
ブランチ バージョニングでサポートされているデータセットの完全なリストについては、編集ワークフローのオプションをご参照ください。
データがブランチ バージョン対応登録されており、Web フィーチャ レイヤーに対してバージョン管理機能が有効になっていない場合、データのクエリや編集などのすべての操作はデフォルト バージョンで行われます。 名前付きバージョンの作成や削除、バージョンの変更、リコンサイルおよびポストなど、[バージョン管理] 操作はいずれも使用できません。
フィーチャ サービスの編集に関する注意事項をご参照ください。
以下のセクションでは、ブランチ バージョニングに関する一般的な注意事項に加え、いくつかのブランチ編集シナリオの説明と、推奨されるバージョニング構成について説明します。
一般的な注意事項
ブランチ バージョニングを検討する際は次の点に留意してください。
- 編集者は、Web フィーチャ レイヤーを通じてブランチ バージョン対応データを編集する必要があります。データベース接続を使用して ArcGIS Pro のジオデータベースに接続し、データを編集することはできません。 つまり、ブランチ バージョン対応データは Web フィーチャ レイヤーとして公開し、その Web フィーチャ レイヤーを適切なオーディエンスと共有する必要があります (グループ、組織、パブリックなど)。 Web フィーチャ レイヤーをグループまたは組織と共有する場合、フィーチャ レイヤーを編集する必要があるポータルのメンバーは、フィーチャの編集権限を含むロールのメンバーである必要があります。
注意:
ブランチ バージョン対応データの所有者は、データベース接続を使用して ArcGIS Pro のジオデータベースに接続し、ブランチ バージョン対応データを変更するジオプロセシング ツールを実行できます。 これは、[アペンド (Append)] や [フィーチャのコピー (Copy Features)] など、大量データの読み込みなどを容易にする操作に予約されている必要があります。
- ブランチ バージョン対応データを編集するときに、属性テーブルが更新内容を直ちに反映しないことがあります。 更新されたデータを属性テーブルに表示するには、データ ソースを更新する必要があります。 これを行うには、リボンの [バージョニング] タブまたは [コンテンツ] ウィンドウで [更新] ボタンをクリックし、[データ ソース別にリスト] ボタンを選択して、ブランチ バージョン対応データの適切なデータ ソースを右クリックし、[更新] を選択します。
- 名前付きバージョンを作成するには、Web フィーチャ レイヤーに接続しなくてはなりません。 名前付きバージョンの所有者は、名前付きバージョンを作成するときに、アクティブなポータルへの接続を認証するために使用したポータルのメンバーです。
- バージョンのアクセス権を設定する際には、バージョンのワークフロー戦略に加えて、そのフレームワークで作業するさまざまなユーザーのニーズを考慮してください。
- Web フィーチャ レイヤーにアクセスするポータルのメンバーの権限と、Web フィーチャ レイヤーのバージョン アクセス権限と設定により、ポータルのメンバーがブランチ バージョンとそこに含まれるデータに対して行える操作が決まります。
- ブランチ バージョン対応データの競合解決は、複数の編集セッションにわたって管理できます。 ArcGIS Pro プロジェクトをいったん閉じてからもう一度開き、競合の管理を続行することもできます。
- ブランチ バージョン管理ワークフローは、簡素化されたデータ モデルによって能率化されます。 リコンサイルとポストの操作は、編集内容をマージしてデフォルト バージョンに変更内容をポストするために実行されますが、ブランチ バージョン対応データセットの圧縮操作を実行する必要はありません。 編集内容は、アーカイビングを使用して追跡されます。これにより、すべての編集内容をデータセットのベース テーブルに格納できます。
デフォルト バージョンでのデータの編集
他のユーザーがデフォルト バージョンでデータを編集できるようにするには、ブランチ対応データを公開します。 Web フィーチャ レイヤーは、データのデフォルト バージョンを自動的に参照します。
デフォルト バージョンでデータを編集する場合、編集内容は基礎データ ソースに即座に保存されます。 デフォルトのブランチ バージョンでデータを編集することは、標準のデータベースのショート トランザクションに相当します。 デフォルト ブランチ バージョンでデータを編集する場合、最初の編集からトランザクションが開始され、実行した個々の編集操作が単一のトランザクションとしてデータベースに自動的にコミットされます。このとき、編集内容を保存する必要はありません。 変更した内容は、トランザクションが完了した時点で、デフォルト バージョンから Web フィーチャ レイヤーにアクセスするその他すべてのユーザーとアプリケーションで使用できるようになります。
バージョン アクセスは、アクティブなポータル ユーザーの権限と、バージョンに対して構成されたアクセス権の組み合わせに基づいています。 ポータル ユーザーの権限と、デフォルト バージョンのバージョン アクセスの権限レベル (パブリックかプロテクトか) によって、許可される編集ワークフローのタイプが決まります。
- [パブリック] - デフォルト バージョンのアクセス レベルが [パブリック] に設定されている場合、すべてのポータル ユーザーがデフォルト バージョンでデータを編集でき、名前付きバージョンでデータを編集するユーザーは、その編集内容をデフォルト バージョンにポストできます。 これは、デフォルト バージョンのデフォルト アクセス設定です。
- [プロテクト] - デフォルト バージョンのアクセス レベルが [プロテクト] に設定されている場合、デフォルト バージョンでデータを編集したり、名前付きバージョンからデフォルト バージョンにデータの編集内容をポストしたりできるのは、バージョン管理者 (高い権限を持つポータル ユーザー) のみです。 その他すべての編集者は、編集を行う前に名前付きバージョンを作成する必要があります。
検討事項
デフォルト バージョンでデータを操作したり編集したりする場合には、次の点に留意してください。
- 複数のユーザーが、デフォルト バージョンでデータを同時に編集することができます。
- Web フィーチャ レイヤーで [バージョン管理] 機能が有効になっている場合、デフォルト バージョンでデータに対して行った編集内容を元に戻したり、やり直したりすることはできません。
- デフォルト バージョンでデータを編集する際は、競合検出は適用されません。 あるユーザーがフィーチャを更新して編集内容を保存し、別のユーザーが同じフィーチャを更新して編集内容を保存した場合、最後の更新によって最初の更新が上書きされます。
名前付きバージョンの編集
複数のプロジェクト、作業指示、またはジョブを管理する場合は、構造化されたワークフロー管理手法が必要です。 複数の編集セッション、および数日、数週間、数か月におよぶ個々の作業単位を、デフォルト バージョンに影響を与えずに管理する必要があります。 こうした作業単位の例としては、幹線道路の舗装計画、新しい電話サービスの導入、ガス パイプラインを継続的に管理するプロジェクトなどがあります。 作業指示またはプロジェクトが開始されると、編集内容を切り分けるために、デフォルト バージョンから名前付きバージョンを作成できます。
ブランチ バージョニングでは、デフォルト ブランチ バージョンから 1 つのレベルの名前付きバージョンのみ作成できます。 名前付きバージョンのブランチ バージョン対応データセットを操作し、バージョニング ワークフローに追加するには、次の手順を実行します。
- ブランチ バージョン対応データを公開するときに、バージョン管理機能を有効にできます。 この機能を有効にすると、バージョン管理サービス (VMS) によって名前付きバージョンの作成、変更、削除する機能と、名前付きバージョンからデフォルト バージョンに編集内容をリコンサイルし、ポストする機能が表示されます。 この操作は、ブランチ バージョン対応データセットで使用される Web フィーチャ レイヤーのサポートに必要です。
- 名前付きバージョンを作成し、一意の分離されたビューを編集者に提供できるので、編集者はそれを使用して同じデータを同時に操作でき、デフォルト バージョンに編集内容をポストする前に競合の特定と解決を行えます。
誰もデフォルト バージョンを直接編集しない方法を選択した場合は、ジオデータベース管理者がデフォルト バージョンのプロパティを変更し、バージョン アクセス レベルを [プロテクト] に設定することができます。これによって、ユーザーはデフォルト バージョンでデータを引き続き表示できますが、アクセス レベルは読み取り専用に制限されます。 データを変更したい編集者は、名前付きバージョンを作成し、そこでデータを編集しなければなりません。
バージョン管理機能が有効になった Web フィーチャ レイヤーがポータル接続からマップに追加されると、デフォルト バージョンにアクセスします。 ただし、[接続バージョンの変更] ダイアログ ボックスを使用して、バージョンを切り替えることができます。 [バージョン管理] が有効になった Web フィーチャ レイヤーを編集する場合、デフォルト バージョンか名前付きバージョン (存在する場合) のいずれかでデータを編集できます。 名前付きバージョンでデータを編集する場合、個々の編集を元に戻したりやり直したり、編集グループを保存または破棄したりできます。 名前付きバージョンでこれらの編集機能にアクセスするには、編集中のバージョンを他の編集者や閲覧者から分離する必要があります。 これを実現するため、ArcGIS Pro はロック メカニズムを使用して、表示または編集しているバージョンへのアクセスを制限します。
次のように、ロック モデルにより、複数の閲覧者または 1 人の編集者によるアクセスを実現します。
- 1 人の編集者が名前付きバージョンでデータの編集を開始すると、排他ロックが取得されるため、それ以外のユーザーは編集セッション中にそのバージョンに接続できなくなります。
- 編集者が名前付きバージョンでデータの編集を開始する時点で、そのバージョンに接続している唯一のユーザーである必要があります。
このようなロックを回避するには、名前付きバージョンのアクセス権限を [プライベート] に設定します。 名前付きバージョンのアクセス権限が [プライベート] に設定されていると、昇格された権限を持つユーザー (ポータル管理者やバージョン管理者など) 以外のユーザーは、バージョンに接続できなくなります。
作業指示、ジョブ、プロジェクトへのすべての変更が完了したら、リコンサイル操作を実施してデフォルト バージョンから変更内容を取得し、検出された競合を解決できます。 ブランチ バージョニングより、複数の編集セッションで競合を解決したり、競合を確認して解決したりすることができ、そのままにしておいて後で続けることもできます。 競合の解決結果を 1 つずつ確認し、必要に応じて変更を加えることができます。 この作業が完了したら、バージョン管理者は変更内容を名前付きブランチ バージョンから保護されたデフォルト バージョンにポストし、デフォルト バージョンに編集内容を統合することができます。 その後、名前付きバージョンを削除できます。
検討事項
名前付きバージョンでデータを編集する場合、以下を考慮してください。
- ブランチ バージョニングでは、デフォルト バージョンから 1 つのレベルの名前付きバージョンのみ作成できます。 つまり、名前付きバージョンから、別の名前付きバージョンを作成することはできません。
- 名前付きブランチ バージョンごとに 1 人の編集者しか許可されていません。また、名前付きバージョンを複数のユーザーが読み取ることができます。 1 人の編集者が名前付きバージョン内でデータの編集を開始すると、排他ロックが取得されるため、他のユーザーはそのバージョンに接続できなくなります。
- 名前付きバージョンでデータを編集中に編集内容を元に戻したり、やり直したりすることが可能です。
- リコンサイルとポストの操作は、デフォルト バージョンをターゲット バージョンとして使用して行われます。別の名前付きバージョンを使用してリコンサイルとポストは行えません。
- ブランチ バージョニング モデルは、すべてのレコードや編集内容が同じベース テーブルで追跡されるテンポラル モデルなので、圧縮の必要はありません。
編集者と閲覧者のサポート
組織において、それぞれが異なるオペレーションを要求する多層のユーザーをサポートする必要がある場合は、ユーザーのレベルごとに 1 つの Web フィーチャ レイヤーを作成することが推奨されます。 たとえば、バージョン対応データへのアクセスを必要とする編集者と閲覧者がいるとします。 この場合は、ブランチ バージョン対応として登録されている同一の基礎フィーチャクラスから 2 つの Web フィーチャ レイヤー (フィーチャ サービス) を公開し、これらの編集者と閲覧者をサポートできます。
- 最初の Web フィーチャ レイヤーを、[バージョン管理] 機能を有効にした編集可能な Web フィーチャ レイヤーとして公開します。 この Web フィーチャ レイヤーを、データの編集を行えるメンバーを含むグループと共有します。
最初の Web フィーチャ レイヤーを公開したら、編集者はデフォルトのブランチ バージョンでデータを編集するか、名前付きバージョンでデータを編集して、その編集内容をリコンサイルおよびポストできます。 編集を終え、必要に応じてデフォルト バージョンにポストすると、変更内容はデフォルト バージョンですぐに使用できるようになります。 これらの編集内容は、以下の読み取り専用ユーザーに対して公開した Web フィーチャ レイヤーに提供されます。
- 2 つ目の Web フィーチャ レイヤーはクエリ機能が有効で、作成、更新、削除、エクスポート、同期操作が無効の状態で公開されます。 編集が有効になっていないこの Web フィーチャ レイヤーを公開する場合は、[バージョン管理] 機能は無効のままでもかまいません。 編集が有効になっていないこの Web フィーチャ レイヤーを、デフォルト バージョンでデータを読み取り専用で表示するメンバーで構成されるグループと共有します。または、組織のすべてのメンバーが、デフォルト バージョンでデータを読み取り専用で表示できるよう、組織と共有します。
検討事項
編集者と閲覧者をサポートする際は、次の点に留意します。
- 編集可能な Web フィーチャ レイヤーは [バージョン管理] 機能が有効であり、組織内の編集者と共有されるので、編集者は名前付きバージョンの作成と削除、プロパティの変更に加え、データを編集してリコンサイル操作を行うことができます。 デフォルト バージョンのアクセス権限が [パブリック] に設定されている場合、編集者は、名前付きバージョンの編集内容をデフォルト バージョンにポストできます。
- ブランチ バージョン対応データセットを名前付きバージョンで操作し、バージョニング ワークフローに追加するには、Web フィーチャ レイヤーの公開時に [バージョン管理] 機能を有効にする必要があります。 Web フィーチャ レイヤーを公開したポータルのユーザーは、そのレイヤーのバージョン管理者になります。 Web フィーチャ レイヤーの所有者は、Web フィーチャ レイヤーを特定のグループで共有するか、Web フィーチャ レイヤーを編集する必要のあるメンバーで構成されたグループ間で共有することができます。 共有した後は、編集者はバージョンの作成、変更、削除だけでなく、編集を加えたり、リコンサイルおよびポスト操作を実行したりすることもできます。
- 2 つ目の Web フィーチャ レイヤーでは [クエリ] 機能のみが有効になっており、バージョン管理は有効になっていないため、2 つ目の Web フィーチャ レイヤーを共有するメンバーはデフォルト バージョンにしかアクセスできません。
- [クエリ] 操作は、閲覧者が Web フィーチャ レイヤーのデータを表示するために必要です。 このため、ArcGIS Pro から公開する場合、[クエリ] 操作は常に有効であり、無効にすることはできません。
プロジェクトの段階
作業指示管理システムと作業指示割り当てのプロセスは、組織において複数の段階を経て行われます。 多くのプロジェクトは、技術的に、事務的に、または法的に承認されて初めて次の段階へと進む、あらかじめ決められた、または規制された段階を通過していきます。 これらの段階には、初期設計案、建設、現場調査、建設竣工、プロジェクト完了などがあります。 プロジェクトの各段階では、データのサブセットに対して複数回の更新が行われます。 基本的に、このプロセスは循環的です。最初に設計が行われ、さまざまな段階を経てプロジェクトが徐々に変更され、最終的にマスター データベースに完全に統合されます。 各段階の最終ステップでは、管理者が所有権を持ち、品質保証 (QA) と品質管理 (QC) を実施するか、ポスト前に整合性チェックのステップを実施することが要件として定められていることがあります。
次のシナリオでは、Proposed という名前付きバージョンがデフォルト バージョンから作成され、このプロセスの提案段階を表します。 この提案段階の編集が完了すると、ユーザーはバージョンの所有権をバージョン管理者に変更します。 バージョン管理者は QA/QC 整合チェック プロセスを確認および完了し、保護されたデフォルト バージョンに変更内容をリコンサイルおよびポストします。 ポストした後、Proposed バージョンを削除できます。
次に、Constructed という名前付きバージョンがデフォルト バージョンから作成され、このプロセスの建設段階を表します。 この建設段階の編集が完了すると、名前付きバージョンの所有者は、バージョンの所有権をバージョン管理者ユーザーに変更します。 バージョン管理者は QA/QC プロセスを確認および完了し、保護されたデフォルト バージョンに変更内容をリコンサイルおよびポストします。 編集内容がデフォルト バージョンにポストされたら、Constructed バージョンを削除できます。
名前付きバージョンを生成して編集し、バージョンの所有権をバージョン管理者に変更し、管理ユーザーが QA/QC プロセスを実施して、デフォルト バージョンを使用してリコンサイルとポストを行うというライフサイクルは、最終段階に到達するまで繰り返されます。
検討事項
以下は、上記すべてのシナリオで使用できますが、特に QA/QC ワークフローで役に立ちます。
- 属性ルール - 属性ルールを使用すると、編集の操作性と、ジオデータベース データセットのデータ整合性を向上させることができます。 属性ルールは、属性を自動的に設定し、編集操作中の無効な編集を制限し、既存のフィーチャに対して QA チェックを実行するためのユーザー定義のルールです。
- ArcGIS Data Reviewer - Data Reviewer では、データの整合性を向上させるためにデータ品質管理を自動化および簡素化したシステムを提供することで、生成と解析用のデータを管理できます。 Data Reviewer には一連の QC ツールが含まれており、テーブルの属性値やフィーチャ間の空間リレーションシップの解析など、効率的で一貫性のあるデータ確認プロセスを提供します。
- ArcGIS Workflow Manager - ArcGIS Workflow Manager では、ビジネス プロセスの能率化と標準化が可能です。これは、ArcGIS Workflow Manager でパスによって接続される一連のステップを使用し、ワークフローとして表されます。 ワークフローは、ステップの抜けがないようタスクを整理し、明確化します。 各アクティビティに対して情報が自動的に記録され、各タスクに関する情報を報告するツールが提供されます。 ArcGIS Workflow Manager には、リソースの割り当てと、ジョブのステータスと進捗を追跡するためのツールもあります。 ユーザーに割り当てられたタスク、完了したタスク、編集した空間データ、その他のアクティビティについて通知するため、さまざまな電子メール通知も用意されています。
分散データ管理
モバイル データ コレクション アプリまたは ArcGIS Pro の [マップのダウンロード] ボタンで、モバイル エディター ワークフローを使用できます。
モバイル エディターのブランチ バージョン シナリオを実装する方法については、「オフライン マップおよびブランチ バージョン対応データの操作」をご参照ください。
ブランチ バージョン対応データにアクセスする Web フィーチャ レイヤーは、分散コラボレーション ワークフローでもサポートされています。 コラボレーションでは、同期対応の Web フィーチャ レイヤーをコピーとして共有し、異なるバージョンのデータにアクセスすることができます。 コラボレーション プロセスおよびコラボレーションの概念の詳細については、「コラボレーションのしくみ」をご参照ください。