arcgis-custom-data-feeds

ArcGIS Enterprise カスタムデータフィード（CDF）

カスタムデータフィードは、ArcGIS Enterprise SDK ランタイム内で Koop.js 上で動作する Node.js プロバイダーです。外部ソース（REST API、データベース、ファイル）からデータを取得し、標準の ArcGIS フィーチャサービスとして公開します。プロバイダーは GeoJSON を返し、フレームワークが ArcGIS クライアントの利用する GeoServices REST 仕様に変換します。

ArcGIS Server へのデプロイと登録（.cdpk のアップロード、cdf register）は対象外です。このスキルでは、プロバイダーの作成とローカルでのテストを扱います。

コードを書く前に、対象の Enterprise バージョンを確認してください

CDF は ArcGIS Enterprise 11.1 で導入されました（10.x には存在しません）。その機能はリリースによって異なります。作成するプロバイダーは実行対象のバージョンに完全に依存するため、コードを書く前にバージョンを確定してください。

• このプロバイダーを実行する必要がある ArcGIS Enterprise のバージョンを確認してください。新しいランタイム向けにコンパイルされたプロバイダーは古いサーバーでは動作しません。対象リリースのうち、最も古いバージョンに合わせてビルドしてください。
• 12.x では再コンパイルが必要です。 12.x で動作させるには、プロバイダーを 12.x 向けに再コンパイルする必要があります。11.x でビルドしたプロバイダーは、12.x のランタイムとバイナリー互換性がありません。
• 開発マシンの OS ファミリーと Node.js のメジャーバージョンを対象サーバーに合わせてください。一致しない場合、コンパイル済みのプロバイダーは読み込めません。

現在のリリース、バージョンごとの機能一覧、破壊的変更については、最新の ArcGIS Enterprise SDK CDF ガイド と「What's New」ページを参照してください。古くなる可能性のある、再掲された機能一覧には頼らないでください。クラス、メソッド、オプションが特定のバージョンに存在するか確認するには、arcgis-docs-lookup スキルを参照してください。

12.0 世代の境界

CDF は 12.0 で根本的に変更されました。12.0 より前と 12.0 以降は別の世代として扱い、それぞれの前提を混同しないでください。

• config npm モジュールは 12.0 で廃止されました。 認証情報は src/ 内のローカル JSON ファイルに保存し、直接 require() してください。11.1～11.5 では config/default.json が標準です（最上位のキーは、アプリ内のすべてのプロバイダー間で一意である必要があります）。
• 12.0 へのアップグレード時の注意点： config モジュールを使用していたプロバイダーは、12.0 へのアップグレード後に自動で再登録されません。アップグレード前にローカル JSON 設定へ移行してください。
• getMetadata()（以下を参照）は 12.0 以降でのみ利用できます。

プロジェクトのスキャフォールディング — cdf CLI

cdf createapp my-cdf-app          # once per project
cd my-cdf-app
cdf createprovider my-provider    # a provider inside the app
npm start                         # local dev server (HTTP :8080)
cdf export my-provider            # produce a deployable .cdpk

生成される構成（主要部分）：providers/my-provider/src/index.js（登録）、.../src/model.js（コアロジック）、.../cdconfig.json（プロバイダー設定）、.../package.json（プロバイダーの依存関係）。

npm パッケージはプロバイダーレベル（providers/my-provider/）にインストールしてください。アプリレベルにはインストールしないでください。framework/ は変更しないでください。バンドルされた Koop パッケージは読み取り専用です。

Model クラス

model.js は最大 4 つのメソッドを持つクラスをエクスポートします。「Since」列は永続的なリリース履歴であり、現在の対応状況を示す表ではありません。

メソッド	必須	Since	目的
getData(req)	はい	11.1	データを取得し、GeoJSON FeatureCollection を返します
editData(req, edits)	いいえ	11.4	applyEdits（追加／更新／削除）を処理します
authorize(req)	いいえ	11.5	リクエスト前の認可を行います。拒否するには例外をスローします
getMetadata()	いいえ	12.0	編集時の再投影に使う idField と inputCrs を返します

getData(req) は metadata ブロックを含む GeoJSON FeatureCollection を返します。async/await 形式を使用し、同じメソッド内で async パターンとコールバックパターンを決して混在させないでください。混在させるとプロセスがクラッシュします。完全なレスポンススキーマについては references/geojson-response-format.md を、全件取得パターンとパススルーパターンについては references/provider-patterns.md を参照してください。

主な req プロパティ：req.params.layer（'0'、'1'、…）、req.params.<key>（サービスのパラメーター値）、req.query.where、req.query.resultOffset／req.query.resultRecordCount（ページネーション）、req.query.returnCountOnly（'true' → { count: N } を返します）、req._user（サービスで forwardUserIdentity: true が必要です）。

GeoJSON レスポンスのルール

• レイヤー内のすべてのフィーチャーは、同じジオメトリータイプを共有する必要があります。
• 必ず fields を明示的に宣言してください。最初のフィーチャーからの型推論に依存してはいけません。誤った型が生成されます。
• 必ず idField を一意な数値プロパティに設定してください。省略すると、すべてのフィーチャーのハッシュ計算が強制されます（低速で、衝突しやすくなります）。編集可能なプロバイダーでは、idField は実在するフィールドを参照する必要があります。自動生成される OID はサポートされていません。
• デフォルトの CRS は WGS84（4326）です。データが別の CRS を使用する場合は、metadata.inputCrs に WKID を設定してください。
• 複数レイヤーのサービスで req.params.layer が未定義の場合は、{ layers: [...], tables: [], metadata: { name, inputCrs } } を返してください。
• パススルーパターンでは、上流で処理した各フィルターについて filtersApplied（where、geometry、objectIds、resultOffset、resultRecordCount）を true に設定し、フレームワークが二重に適用しないようにしてください。
• ttl は LRU キャッシュの TTL を秒単位で設定します（キャッシュ容量：500 要素）。

editData() で破壊的な編集を保護する

editData() はプロバイダーの上流ストア（データベース、外部 API）に対して adds／updates／deletes を書き込みます。これらは取り消せないデータ操作です。そのため、更新または削除を行う editData コードを生成する前に、次のすべての項目を順番に満たしてください。

1. 対象を明示します。 書き込み先となる上流システムと、正確なストア／コレクション／テーブルを伝えます。対象を特定できなければ、そこで停止してください。
2. 対象の内容を示します。 更新／削除の対象（どのレコードで、概算でいくつか）を提示し、ユーザーが変更または失うものを把握できるようにします。
3. 本番環境ではないことを確認します。 その旨を明確に伝え、先に進む前にユーザーの確認を得てください。
4. まずは取り消し可能な方法を優先します。 破壊的な書き込みを実行する前に影響範囲を把握できるよう、読み取り優先／件数確認優先の方法を提示してください。
5. 無確認で出力しないでください。 1～4 を満たし、ユーザーが確認するまで、更新／削除コードの提示を控えてください。ユーザーが自信を示している場合も同様です。

項目ごとの { objectId, success, error? } を含む { addResults, updateResults, deleteResults } を返してください。エラーコード：1017 は挿入、1018 は削除、1019 は更新です。rollbackOnFailure はフレームワークによって強制されません。トランザクションロジックは editData() 内で独自に実装してください。authorize(req) で書き込みを制御してください（拒否するには例外をスローします）。

設定とシークレット

• 12.0+: src/ 内のローカル JSON 設定ファイルを require() します。.gitignore に追加してください。
• 11.1–11.5: config モジュール（config/default.json）を使用します。
• 認証情報をハードコードしないでください。実際のシークレットを含む設定 JSON をコミットしないでください。

完了条件

対象となる Enterprise のバージョンが固定されていること（プロバイダーは対象のうち最も古いバージョン向けにビルドし、必要に応じて 12.x 向けに再コンパイルすること）。12.0 より前と 12.0 以降での設定処理がそのバージョンに合っていること。すべての getData レスポンスで fields と数値の idField が宣言され、レイヤーごとにジオメトリタイプが 1 つだけ指定されていること。シークレットがインラインではなく、Git の追跡対象外の設定ファイルに保存されていること。editData による更新・削除がすべてガードを通過していること。バージョン固有の記述が arcgis-docs-lookup を使ってライブの Enterprise SDK CDF ガイドで確認済みであること。

参考ファイル

ファイル	読むタイミング
references/geojson-response-format.md	メタデータスキーマ、フィールドタイプ、複数レイヤー形式、編集テンプレートの全容
references/provider-patterns.md	全件取得とパススルー、件数・範囲のショートカット、上流の認証
references/examples/minimal-provider.md	読み取り専用プロバイダーの完全な動作例（解説用、12.0 を対象）
references/examples/editable-provider.md	データベースバックエンドを備えた編集可能なプロバイダーの完全な例（解説用、12.0 を対象）