ETLパターン: スケジューリングWebツール

bharold

しばしば、ETLは一度きりではなく、繰り返し <\/STRONG>が必要であり、時間の経過に伴うデータの変化を取り込む必要があります。  ArcGIS Pro 3.4およびArcGIS Enterprise 11.4のリリースまでは、これをサポートする自動化パターン<\/STRONG>には、ArcGIS Data Pipelines<\/STRONG>やスケジュールされたNotebooks <\/STRONG>またはREST APIタスクスケジューラ<\/A>を使用したツールが含まれていましたが、新しいノーコードオプションであるweb tool scheduling<\/A><\/STRONG>がArcGIS Pro 3.4およびArcGIS Enterprise 11.4で提供されます！<\/P>

任意の種類のジオプロセシングツールを使用してスケジュールされたweb toolを作成できます - コアシステムツール、ModelBuilderツール、Pythonスクリプトツール、またはSpatial ETLツールです。 <\/STRONG>私のブログのテーマでは、ArcGIS Data Interoperability Spatial ETLツールを使用しています。なぜなら、それは私のソースデータである

RSS<\/A>フィード、特にCommon Alerting Protocol<\/A> (CAP)フィードを消費できるからです。これは世界中の多くの機関によって公開されており、米国のFEMA<\/A>も含まれます。 私のCAPデータはニュージーランドの気象警報<\/A>で、1日に2回更新されます。 天気が良ければフィードにはエントリがありません😉<\/span>. CAPはXMLベースであり、ArcGIS Data Interoperability<\/STRONG>で簡単に処理できます。 私はCAPフィードの状態をArcGIS Onlineのホストフィーチャレイヤーにミラーリングしたいと考えています。<\/P>
以下は2024年10月9日のArcGIS Proでのサンプル警報状態マップです。 ブログダウンロードにはいくつかのCAP警報XMLドキュメントが含まれており、生データを確認したい場合に利用できます。<\/P>
CAP Weather Alerts<\/span><\/span><\/P>
ラベリングが示すように、黄色のフィーチャは強風注意報であり、青い線（ズームインするとオレンジ色のポリゴン）は山岳峠を通る道路の雪警報です。 最北端のフィーチャにズームインすると詳細を確認できます。 それはLewis Passで、そのルート沿いには2つの地熱温泉リゾートがあるため、雪による遅延があっても快適に待つことができます！<\/P>
Snow alert through Lewis Pass<\/span><\/span><\/P>
数日後、大雨注意報があります:<\/P>
Fiordland rain watch<\/span><\/span><\/P>
この地域では雨は重い雨だけなので、注意報から警報（オレンジ色）へのアップグレード予測が12時間後の次回更新時に実現し、新しい警報も届いたことは驚くべきことではありません:<\/P>
West Coast rain<\/span><\/span><\/P>
そして翌日 - またさらに天気情報です！<\/P>
Yet more weather!<\/span><\/span><\/P>
このような定期的な更新はスケジュールされたweb toolにとって典型的なケースであり、実際に私の場合も夜間にデータが更新されました。 そのETLはどのようなものか？<\/P>
私のデータフローは現在のCAP状態からArcGIS Online上のホストフィーチャレイヤーを維持します。 私のETLツールは非常にシンプルで、こちらです（ブログダウンロードにも含まれており、Pro 3.4用ArcGIS Data Interoperabilityと共有時にはArcGIS Enterprise 11.4が必要です）。<\/P>
CAP alert ETL tool<\\/span><\\/span><\\/P>
まずトークンが生成されます（ローカルポータルの場合はEsriPortalTokenGetter<\\/A>を使用し、ここではEsriOnlineTokengetter<\\/A>を使用)、次に上流ストリームがRSSフィードを読み取り、ターゲットフィーチャレイヤーに対してupsert<\\/STRONG>トランザクションを書き込みます - 新しい警報は新しいフィーチャとなり、既存フィーチャへのデータ変更も適用されます。 Upsertサポートにはレイヤー内に一意にインデックスされた非nullフィールドが必要であり、これは以前のブログで説明されています<\\/A>. 下流ストリームは期限切れ警報を検出して削除します。 ETLツールにはパラメータがありません。入力RSSフィードと出力フィーチャレイヤーは変更されないため、作成時に公開しない設定が可能だからです。 <\\/P>

新しい、 推奨される ETLパターンとしてここで示しているのは、ホストされたフィーチャレイヤーのメンテナンス用にETLツール内でポータルトークンを生成する方法であり、ホスティングサーバーへの

web接続共有<\\/A>という面倒な手順を回避できます。 ターゲットフィーチャサービスは提供されたトークンとともにEsri ArcGIS Server Feature Service形式で読み書きされ、SSL証明書検証オプションはオフになっています。 セキュリティ要件によっては信頼された証明書を提供する必要があります。<\\/P>

ローカル環境のArcGIS ProでETLツールを実行した後、結果履歴を

web toolとして共有し, スケジュール設定できます。 スケジューリングには多少計算が必要です。 CAPフィードは「現地時間」、執筆時点ではNZDT（UTC+13）で午前9時と午後9時に更新されます。 私のProマシンは現在PDT（UTC-7）なので、次回利用可能な12時間ごとのスロット午前9時NZDT開始時間はUTC午後8時またはPDT午後1時と計算しました。<\\/P>

これで、ETLの自動化を妨げるものは何もありません！

 

bharold

@AdamRepsher_BentEar There is some problem with the token getting, if you copy the transformer into a new workspace and try out the Python it might give a clue. Once you establish generateToken isn't working you could open a support call.