web-dev-qa-db-ja.com

.NETとSFDCを使用したコンテンツベースのETLプロセスの設計

私の会社はSFDCをメインの運用システムとして使用するように移行しているので、顧客固有のドキュメントを自由に表示できるように投稿できるいくつかのSFDCポータルを一緒にスピンしました。そのため、アナリストが内部で生成するドキュメントからメタデータを抽出し（ほとんどが業界標準のPDF、XML、またはMS Office形式）、ネットワークに配置できる疑似ETLアプリケーションを実装する必要がありました。キュー」フォルダ。そこから、アプリケーションはキューに入れられたドキュメントをスクープし、メタデータの一部を選択して適切なSFDC CRMコンテンツライブラリにアップロードします。私は主にDbAmpを使用してSFDCとの通信を仲介しました（DbAmpはSQL規則を使用してSFDC組織データとやり取りできるリンクサーバープロバイダーです）。

私はC＃で[コンソール]アプリケーションを作成することができました。これはかなりうまく機能し、通常は次のような構造になっています。

static void Main()
{
    // Load parameters from app.config.
    // Get documents from queue.
    var files = someInterface.GetFiles(someFilterOrRegexPattern);

    foreach (var file in files)
    {
        // Extract metadata from the file.
        // Validate some attributes of the file; add any validation errors to an in-memory          
        // structure (e.g. List<ValidationErrors>).
        if (isValid) 
        {
            var fileData = File.ReadAllBytes(file);
            // Upload using some wrapper for an ORM or DAL
            someInterface.Upload(fileData, meta.Param1, meta.Param2, ...);
        }
        else
        {
            // Bounce the file
        }
    }

    // Report any validation errors (via message bus or SMTP or some such).
}

そして、それだけです。ほとんどの場合、これらのすべての操作を、必要なインターフェイスをコンストラクター・パラメーターとして受け取る「Worker」クラスにラップします。

このアプローチはかなりうまくいきましたが、私はそれについて何かひどいことがあり、いくつかのフィードバックが大好きだということを私の内臓で感じています。 ETLプロセスをC＃コンソールアプリとして作成することは悪い考えですか？また、このシナリオで役立つデザインパターンのうち、私が明確に見落としているものがあるかどうかも疑問に思います。

前もって感謝します！

c#.netarchitectureapplication-designetl
4
Patrick

さて...一般的なETL問題の実際的な側面に焦点を当てるだけで、余計な手間をかけずに、バッキングロジックを1つ以上の参照可能なアセンブリに分離し、簡単なWindowsサービスを作成して、ETLプロセスを呼び出すことができます。同じ方法。

必要に応じて、コンソールから（コマンドライン引数を介して）実行できるようにWindowsサービスアプリケーションを設定して、コンソールとして実行する機能を失わないようにするのは簡単です。

その代わりに、ETLプロセスをWindowsサービスとして実行できるようになります。 System.Threading.TimerまたはWindowsサービスオブジェクト内で選択したスケジューリングメカニズムを使用すると、手動による介入をほとんど必要としない自動化された/スケジュールされたソリューションが得られます。

ETLプロセスがすでにコンソールアプリとして機能している場合は、数時間から数日の間しかかかりません（Windowsサービスをどの程度知っているか、および追加のベルを使用してソリューションを装飾するかどうかによって異なります）。そしてホイッスル）それをWindowsサービスに進化させ、テストを開始します。

実際のETLロジック自体は、この実行手段から独立して利用できるため、ワークフローや1つ以上のGUIなどの他のアプリケーションからロジックを駆動することもできます。

コンソールアプリは、便利な「ユーティリティ」開発ツール、1回限りのバッチプロセス、コマンドラインスタイルのUI（最近では珍しいことです）、地面から何かを取得したり、配線を気にせずにロジックで遊んだりするのに便利です。 GUIなど。

しかし、私の意見では、ミッションクリティカル、反復的、または運用上のプロセスは、実行/相互作用のより堅牢なメカニズムに値します。

「パターン」の観点からは、実際の推奨を行うにはより多くのロジックとコンテキストが必要ですが、一般的なETLの観点からはPipeline aka Pipes and Filtersパターンはしばしば重要な考慮事項...この種の問題には非常に自然なため、意図的に実装を試みていなかったとしても、すでに単純なバージョンが設定されている場合があります。

大量のデータをETLしている場合は、並列処理が可能な部分にデータを分割することを検討する必要がありますが、それはより大きな議論につながります。

そこに何かが役立つことを願っています...

1
Ed Hastings