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