更新：ArcGIS Pro 3.4/ArcGIS Enterprise 11.4で導入されました トリガーフィールド これはイベントによる編集の影響を軽減する議論に影響します。
サブネットワークの管理では、サブネットワークが作成または再構成される際に、数百から数千のフィーチャ編集が必要になることがよくあります。そのため、システムはこれらの更新を行うために使用できるいくつかの異なる編集モードを提供しています。このトピックの詳細は、オンラインヘルプの サブネットワーク トピックでご覧いただけます。
この記事を読むことで、この設定が更新サブネットワークのパフォーマンスに与える影響と、特定のワークフローでパフォーマンスに影響を与えるにもかかわらずイベント処理を有効にしたい理由を理解できます。
編集モードとは何ですか？
編集モードとは何ですか？編集モード？ArcGIS Utility Networkでは、編集モードとは、サブネットワークが管理される際にソフトウェアがフィーチャのシステムフィールドをどのように管理するかを指します。現在、編集モードには イベント処理あり または イベント処理なし の2つのオプションがあります。
「イベント処理あり」や「イベント処理なし」でデータを管理するときに言及している「イベント処理」とは何ですか？イベント処理あり または イベント処理なしと言うとき、私たちが指しているのは、編集に応じてトリガーされるジオデータベースイベントのことです。ジオデータベースイベントは、ArcGISがジオデータベース内のオブジェクトが編集されたときに特別な動作をトリガーする方法の一つです。一般的な例としては、エディタートラッキングフィールドの自動入力、属性ルールの発火、関連オブジェクトへの変更メッセージ送信、およびフィーチャリンク注釈の更新などがあります。
これはサブネットワークとどんな関係がありますか？ユーザーが編集ワークフローの一環としてよく実行するツールの一つに 更新サブネットワーク ツールがあります。このツールは、参加しているサブネットワークを記述するユーティリティネットワークフィーチャ上のシステムフィールドを管理します。これら各フィーチャが編集されると、それぞれ異なる編集イベントがトリガーされます。リレーションシップや属性ルールを含むデータモデルは、リレーションシップや属性ルールが少ないデータモデルよりも更新サブネットワーク中に多くのイベントを発火させます。すべてのイベント、ルール、およびリレーションシップは更新サブネットワークプロセスに追加時間を要します。
この状況に対処するために、管理者はネットワーク内のティアを構成して、そのティア内でサブネットワークを管理するときに通常のジオデータベースイベント（イベント処理あり）を使用するか通常のジオデータベースイベントモデルをバイパスする（イベント処理なし）編集モードを選択できます。この記事の最後には、この決定を行うためのビジネス要件評価とベストプラクティスについて簡単な議論があります。さらに、トリガーフィールドを使用して属性ルールが反応する編集内容を正確に制御し、更新サブネットワーク中の編集イベントによる影響を軽減することも可能です。
ここではまずいくつかの異なる構成例を見てみましょう。それぞれの例では、一連のフィーチャが特定条件下でどのように反応するかを見ます。各フィーチャには4つのフィールドがラベル付けされており、値が変更された場合、そのフィールド/値は太字で表示されます：
- 資産ID – 各フィーチャ固有の識別子です。フィーチャ作成時に入力されます。
- 変更日 – ジオデータベースによって管理されるエディタートラッキングフィールドです。
- サブネットワーク名 – ユーティリティネットワークによって管理されるサブネットワーク名フィールドです。
- ネットワークリージョン – 属性ルールによって管理されており、フィーチャのサブネットワーク名からルックアップテーブルで「リージョン」値を取得します。
注：もし属性ルールがサブネットワーク情報を必要としない場合は、すべての属性ルールを更新サブネットワーク中の更新時にはトリガーしないよう設定でき、その結果更新サブネットワーク中に属性ルールによるパフォーマンス影響を軽減できます。
デフォルトでイベント処理なしで更新
最初に見る例は、新しいプロジェクトで少なくとも一度は行う操作です。新規データベース上でデフォルトバージョンに対して更新サブネットワークを実行します。この場合、データベース内すべてのサブネットワーク名フィールドには「Unknown」が設定されており、それ以外のフィールドはデータロード時点で初期値となっています。以下グラフィックで例をご覧ください。
図1 初期データベース状態
Network A に対して更新サブネットワークを実行した後、サブネットワーク名フィールドはそのサブネットワーク内すべてのフィーチャで更新されていますが、この更新中にはエディタートラッキングや属性ルールはトリガーされませんでした。もしクラスにフィーチャリンク注釈があれば、このイベント中には注釈も変更されませんでした。
図2 デフォルトでイベント処理なしによる更新サブネットワーク
次に同じ操作でも編集モードが イベント処理あり に設定された場合システムがどのように動作するか比較しましょう。
デフォルトでイベント処理ありで更新
ユーティリティネットワークがイベント処理ありでサブネットワーク更新するよう設定されている場合、update subnetwork がフィーチャ属性を更新するとすべてのジオデータベース動作がトリガーされます。前述例が イベント処理あり で実行された場合、結果は以下図になります。
図3 デフォルトでイベント処理ありによる更新サブネットワーク
ここではサブネットワーク名フィールドへの入力だけでなく、「最終変更日」フィールドもエディタートラッキングによって更新され、「運用エリア」フィールドも属性ルールによって更新されています。またこれら複数フィールド参照するフィーチャリンク注釈クラスがあれば、それらも更新されています。
しかしこれら追加トリガーや更新にはパフォーマンスコストがあります。そのため、多数の属性ルールや/およびフィーチャリンク注釈クラスがある場合、この影響について慎重に検討してください。
名前付きバージョンでイベント処理なしによる更新
最も興味深い状況は名前付きバージョンで update subnetwork をイベント処理なしで実行した場合です。これはシステム既定動作であり最もパフォーマンス効率的です。 名前付きバージョンで update subnetwork をイベント処理なしで実行すると、そのバージョン内でまだ編集されていないフィーチャ上ではサブネットワーク情報を更新できないという欠点があります。これら例示した動作がお好みでない場合、本記事次節（名前付きバージョンでイベント処理ありによる更新）で説明する制限克服用新オプションをご利用ください。
この問題について十分議論するため、名前付きバージョン内 update subnetwork 実行時に予期しない結果となる可能性ある2つの場合について考察します。このツールはすべての場合に名前付きバージョン内では期待通り動作しないことがありますが、その後 default バージョンへポストし default 版 update subnetwork を実行すると正しい結果になりますのでご留意ください。
新規作成されたフィーチャー群
最初の例は前述例から続きます。まだサブネット情報未入力状態データベース上で default 版 update subnetwork 実行前に新しい名前付きバージョン作成し、そのバージョン内へ新サービス追加したと仮定します。この名前付きバージョン内新規作成されたフィーチャ群は以下グラフ参照ください：
図4 名前付きバージョン内新規作成されたフィーチャ群
名前付きバージョン内 update subnetwork をイベント処理なしで実行後、不思議な現象があります。 このバージョン内で新規作成されたフィーチャのみがサブネット名入力されています。
図5 名前付きバージョン内 イベント処理なし 新規機能への update subnetwork 適用結果
'名前付きバージョン内 update subnetwork イベント処理なし' は、そのバージョン内で作成または編集されたフィーチャのみ更新可能です。これはその機能がまだそのバージョン内で修正されていなければ、その編集内容挿入にはジオデータベースイベント発火が必要になるためです。',' field-65':'既存機能',' field-66':'次例では名前付きバージョン内 update subnetwork イベント処理なし実行時予期しない結果となり得るもう一つ実践的ケースについて見ます。この例ではある編集操作によってある機能群が一つから別々な二つ目へ移動した際 update subnetwork がどう反応するか見ます',' field-67':'二つ目',' field-68':'開始時点では二つ（Network A と Network ',' field-69':' ）間には結合装置（開閉スイッチや閉弁など）が存在し、それぞれ分離されています。それぞれ全て default バージョン上では最新化済みなので全属性適切入力済みです。また結合装置は複数サブネット所属可能なので、その名称欄にはセミコロン区切り複数値入力されています',' field-70':'図6 デフォルト版二つ目',' field-71':'この例では結合装置として機能していたDevice 3からDevice 1へ切り替えます。この種変更は現実世界でも回路や圧力ゾーン等長期的また季節的顧客需要変化対応として頻繁に起こります。そのため両装置状態変更しDevice 1 が結合装置となり Device 3 は障壁機能解除となります',' field-72':'図7 結合装置変更後',' field-73':'上図にも示す通り結合装置インジケーター位置移動（Device 3→Device 1）、最終変更日付修正、および各機能色分け変更（それぞれ属する二つ目追跡時視覚的識別用）が反映されています。ただしまだ update subnetwork 実行前なので旧名称表示継続中です。この条件下 update subnetwork 実行時発生予定全属性変更内容図も以下示します',' field-74':'図8 名前付きバージョン内 更新済み二つ目',' field-75':'予想通り、この名前付きバージョン内編集済み両装置上名称欄修正済みですが',' field-76':'Network A に接続していたものから Network B に接続先変わった他機能群はいまだ旧名称および運用エリア値表示継続中です',' field-77':. This is because if the feature has not yet been modified in the version it would require triggering a geodatabase event to insert the edit into the version.
Existing Features
For our next example, we will look at another practical example of how running update subnetwork without eventing in a named version may produce unexpected results. For this example, we will be looking at how update subnetwork responds to an edit that results in features changing from one subnetwork to another.
We start with two subnetworks (Network A and Network 
that are separated by a tie device (open switch, closed valve, etc). All the subnetworks have been updated in the default version, so all the attributes are properly populated. Note that because a tie device belongs to multiple subnetworks, the subnetwork name field is delimited with semicolons.
Figure 6 Two subnetworks in default
In this example, we will be changing the tie device between the subnetworks from device 3 to device 1. This happens quite frequently in the real world as circuits, pressure zones, etc. are reconfigured to account for long-term or even seasonal changes in customer demand. To do this we change the status of these two devices to indicate their new open/closed status so that Device 1 is now a tie device and Device 3 no longer acts as a barrier.
Figure 7 Updated tie device
We see these changes reflected in the diagram above because the tie device indicator moved from Device 3 to Device 1, the last modified date is updated, and we’ve updated the coloring on the features to visually indicate which subnetwork they belong to if you were to trace each subnetwork. The subnetwork names are still showing their old values because we haven’t run update subnetwork. Below you will see a diagram that shows all the attribute changes that will occur when update subnetwork is run under these conditions.
Figure 8 updated subnetwork in named version
As expected, we see that the subnetwork name field on both the devices that we edited in this version is updated. However, the features that were connected to Network A but are now connected to Network B still have the old subnetwork name and operating area values. Because these features weren’t edited in this version update subnetwork can’t edit them without triggering edit events.
これらの例は、イベント処理なしで名前付きバージョン内のサブネットワークを更新する際の制限を示しています。多くの顧客にとって、これらの制限はこの編集モードのパフォーマンス上の利点や、データがデフォルトに投稿されて更新サブネットワークが実行された後に正しく表示されるため、許容範囲です。しかし、他の顧客は特定のビジネス要件を満たすために更新サブネットワークの実行時間が長くなることを受け入れる意向がありました。そのため、編集時にサブネットワークを更新する機能をwith eventingとして導入しました。次のセクションで詳しく説明します。
名前付きバージョンでのイベント処理付き更新
上記の2つのシナリオを再検討し、ティアが編集モードとしてwith eventingに設定されている場合に名前付きバージョンでサブネットワークを更新したときの動作を見てみましょう。
新規作成されたフィーチャ
以下は最初の例で、既存フィーチャと新規フィーチャが混在して更新が必要な場合です。
図9 バージョン内の新規フィーチャ
以下は、イベント処理付きで更新サブネットワークを実行した後の結果です。
図10 名前付きバージョンでイベント処理付き更新サブネットワーク
ご覧の通り、すべてのフィーチャに正しいサブネットワーク名と操作エリアが設定されています。より多くのフィーチャを編集し、各フィーチャがエディタートラッキングや属性ルールなどの追加編集をトリガーするため、ネットワークの処理にはより時間がかかります。
既存フィーチャ
次に、いくつかのサブネットワークを再構成した2番目の例を見てみましょう。以下は更新サブネットワーク実行前のデータです。
図11 更新サブネットワーク前のバージョン内フィーチャ
以下は名前付きバージョンでイベント処理付き更新サブネットワークを実行した後のフィーチャ状態です。
図12 バージョン内の新規フィーチャ
再度、すべてのフィーチャ属性に正しい値が設定されていることがわかります。ただし、この操作はイベント処理なしの場合より時間がかかります。所要時間は設定された属性ルールの数や複雑さ、およびメッセージング有効なリレーションシップ（フィーチャ連携注釈を含む）の数に直接関連します。品質保証プロセス中にネットワーク情報の視覚的検査や属性レビューが重要な場合は、これらパフォーマンスコストと比較検討する価値があります。
構成
これらの動作をご覧いただいたので、ユーティリティネットワークでどのように構成されているか見てみましょう。これらオプションは「Set Subnetwork Definition」ツールで設定します。このツールではネットワーク内特定ティアごとに構成変更できるため、それぞれ異なる動作（例：System と Pressure）を定義可能です。異なるティアごとに異なる動作を持てることは便利ですが、多くのお客様は編集者向けに一貫した編集ワークフローを確保するため全ティア同じ動作にすることを好みます。
サブネットワーク定義の編集モード設定には2つの異なるフィールドがあり、それぞれ2つずつ選択肢があります。つまり編集モードには4つの組み合わせがあります：
- デフォルトでイベント処理なし、名前付きバージョンでもイベント処理なし（デフォルト）
- デフォルトでイベント処理なし、名前付きバージョンでイベント処理あり
- デフォルトでイベント処理あり、名前付きバージョンでもイベント処理あり
- デフォルトでイベント処理あり、名前付きバージョンではイベント処理なし
どれを選ぶべきか悩む前に知っておくべきことは、Esri提供のユーティリティネットワーク基盤データモデルにはすでに編集モードが設定されていることです。これら各データモデルには業界専門家とコミュニティによって推奨構成セットが開発され、その業界向けに最も広範なワークフローに適合するよう設計されています。
これら構成はほとんどのお客様ニーズを満たしますが、ご自身のビジネス要件や構成・データモデル変更内容と照らして典型的な構成が依然最適かどうか確認することは常に良い考えです。
ベストプラクティス
よく聞かれる質問は「ユーティリティネットワークで編集モードをどう設定するのがベストプラクティスか？」ですが、一律回答はありません。ただし判断材料となる基準はいくつかあり、それらは通常「ワークフロー」「注釈」「属性ルール」の3カテゴリに分けられます。
最初に考慮すべきはあなたの versioned editing workflowです。編集ワークフローで名前付きバージョン内で品質保証を行い、その過程でフィーチャ属性（サブネットワーク名や伝播値など）に依存するツールやレイヤーを使うならば、名前付きバージョン用編集モードは「With Eventing」に設定してください。これによりバージョン内すべてフィーチャでサブネットワークフィールドが常に正しく埋められ品質保証に利用可能になります。一方QAプロセスが完全にデフォルト内だけで行える場合やトレース機能利用可能なら、「Without Eventing」に設定しても問題ありません。
次に考慮すべきは feature-linked annotation の有無です。feature-linked annotation がないか、または注釈式がサブネットワーク情報（サブネット名や伝播値など）を含まない場合はいずれの編集モードも適切です。ただしメッセージング有効なリレーションシップクラス（feature-linked annotation クラスなど）は編集時パフォーマンスコストがありますので注意深く監視してください。しかしfeature-linked annotation にサブネット情報が含まれる場合はいくつか判断があります。注釈は静的なのに対しサブネットワークは動的なので両者同期維持にはパフォーマンスコストも高く、この方法はベストプラクティスとは言えません。この場合注釈機能ではなくラベルへの置換検討がおすすめです。ただし必須要件ならばデフォルト・名前付き両方とも「With Eventing」に設定しupdate subnetwork 実行時注釈テキストも更新されるようにしてください。ただしupdate subnetwork のパフォーマンス低下には注意してください。
最後に考慮すべきはユーティリティネットワークフィーチャ上で定義された attribute rules です。更新時発火する属性ルールは割り当てられたフィールド問わず該当フィーチャ更新時すべて評価されます。そのため編集モードを with eventing にするとupdate subnetwork 実行時更新された全フィーチャについて即時計算ルールも発火します。この要件が必須ならパフォーマンスコスト受け入れた上で属性ルール内容見直ししupdate subnetwork 時早期終了ロジック実装検討してください。またサブネットフィールド変更応答型属性ルール利用もベストプラクティスではありません。しかし必須ならばedit mode を「With Eventing」に設定しupdate subnetwork 時発火確保してください。
以上踏まえ4つオプションそれぞれ適切なケースを見てみましょう。
デフォルト・名前付きバージョン共にイベント処理なしの場合. これはシステム標準動作で最もパフォーマンス良いですがバージョン内フィーチャ更新やfeature-linked annotation に制限があります。
デフォルトではイベント処理なしだが名前付きバージョンではイベント処理ありの場合. これはパフォーマンスと機能性とのバランス型です。デフォルト内では最高パフォーマンス、名前付きバージョンでは最高品質保証体験を提供します。
デフォルト・名前付き両方ともイベント処理ありの場合. これは最も機能豊富ですがパフォーマンスコストも最大です。この構成採用時は修正時発火属性ルール内容見直ししupdate subnetwork 時早期終了対応しているか確認してください。
デフォルトではイベント処理ありだが名前付きバージョンではイベント処理なしの場合. これは最も稀な構成で、デフォルトのみ注釈や属性ルール実行必要なお客様向けです。
結論
この記事をご覧になったことで、サブネット管理用編集モードそれぞれの長所短所をご理解いただき、ご自身のデータモデル・編集ワークフロー・ビジネス要件に適したモード選択がお分かりいただけたと思います。
属性ルールへの編集イベント影響緩和方法について知りたい場合は Attribute Rule Triggering Fields 記事をご覧ください。
サブネット管理についてさらに学びたい方やハンズオンチュートリアル試したい方には業界別例として Getting Started with ArcGIS Utility Network 学習シリーズがおすすめです。
ユーティリティネットワーク サブネット管理機能について詳細や深掘り記事をご希望なら ArcGIS Utility Network Esri コミュニティページをご覧になることをお勧めします。
