ユーザーがXLSスプレッドシートをアップロードして、データウェアハウス（DW）のテーブルにデータを入力できるようにするための最適なソリューションを探しています。
私たちのユーザーはヘビービジネスオブジェクト（BO）ユーザーであり、BOを使用するとXLSにエクスポートできます。DWにロードする必要のあるスプレッドシートにデータがある場合、XLSのデータをDWのデータベースにアップロードするプロセスが必要です。その結果、私たちが本当に必要としているのはプログラムによる自動フィードであると考えると、これらの「インターフェース」の多くができあがります。システム間フィードのデータソースとしてExcelを使用することは、私の直感では、私には悪い考えのように思えます。
質問1：あなたが同意するかどうか、そしてその理由または理由を確認したいと思います。
OK、その流れに逆らって泳ぐことはないので、XLSのアップロードが私たちのためにここにあることを前提としています。今、私は最良の解決策を見つける必要があります。最初に、私たちが今何をしているのかを説明し、次にそれについて私が嫌いなことを説明します。
Webページを介して、定義された列のセットを持つ空のXLSファイル（行なし）を提供します。各ファイルは、異なるターゲット宛先テーブルを更新するために使用することを目的としています。各スプレッドシートには「アップロード」ボタンがあります。[アップロード]ボタンを押すと、スプレッドシートのマクロがファイルの内容をCSVにシリアル化し、データをサーバーフォルダーにFTPで送信します。スケジューラーは、CSVファイルを入力として使用するInformatica ETLジョブを定期的に起動し、データをカスタムXLS固有のステージングテーブルにロードし、レコードが編集を通過した場合は、適切なターゲットテーブルにロードします。発生したエラーはすべてエラーテーブルに記録されます。アップロードされたXLSファイルごとに、データはファイルに固有の個別のステージングおよびエラーテーブルになります。
私が私たちのプロセスについて含めたくないもののいくつかは次のとおりです。
1）XLSのマクロコードが公開されすぎており、たとえばパスワードが含まれているため、改ざんされる可能性があり、ユーザーが最新のXLSテンプレートを使用していることを確認する際に問題が発生します。2）ビジネスルールの編集はETLプログラムに配置されますが、エラーをできるだけ早くキャッチしたいので、つまりスプレッドシートで、編集もマクロコードに追加されます。これにより、ビジネス編集が重複します。これらのルールを1か所にまとめて集中管理したいと思います。私見ですが、XLSにマクロコードを入れると、ストアドプロシージャの呼び出し（一部はあります）やWebサービスの呼び出し（XLSマクロから.NET Webサービスの呼び出しはまだ試みていません）でさえ、メンテナンスの問題が発生すると思います。）3）すべてのXLSファイルアップロードテンプレートには、ステージングテーブルとエラーテーブルの個別のセット、および発生したエラーを報告するためのカスタム画面を備えた独自のプロセスがあります。より一般化された再利用可能なソリューションが必要なようです。
BOからXLSにデータをエクスポートすることが多いほか、ユーザーはExcelも気に入っています。これは、Webインターフェイスを介して個々のレコードを編集するよりも、多数のレコードを編集する方が簡単で、扱いにくいためです。
これが私が考えている一般的な方向性です。
まず、スプレッドシートに埋め込みマクロを含めずに、編集を使用してExcelを簡単に編集できるようにする必要があります。私はExcelと互換性のあるFarpointのグリッドを試しました...
http://www.fpoint.com/netproducts/spreadweb/tour/excel.aspx
...そして、ユーザーが自分のPCにあるXLSファイルを開いてブラウザーで開き、サーバー側から読み取ったデータに簡単にアクセスできるようにするのは非常に簡単であることがわかりました。 NETWebコード。Excelはブラウザでローカルに実行されていませんが、Excelの機能は再現されています。おそらく、クライアント側のスクリプトを多数使用することで、自分自身を複製するのは非常に困難だと思います。ローカルのスプレッドシートからWebのスプレッドシートにカットアンドペーストすることもできます。これは素晴らしいことのように聞こえますが、最大の問題はコストです。私たちの会社は死にかけているので、新しいソフトウェアを購入することはできません。
次に、すべてのスプレッドシートのアップロード処理に共通するコンポーネントを特定し、一般的な処理コードを考え出します。たとえば、各スプレッドシートと、列名とデータ型の定義を含む各スプレッドシートの形式を、おそらくハードコーディングではなく宛先列の観点から定義するテーブルを想像します。このテーブルテンプレート定義に基づいて、このテーブル定義からダウンロードするXLSテンプレートを生成できます。入力したデータがテーブル定義と一致することを確認するために、簡単な一般的な編集を実行することもできます。また、1つの一般的なWebページを使用して、データを表示し、レポートデータ型の不一致エラーを許可し、ユーザーがそれらを修正できるようにすることができます。また、送信番号、行番号、名前、値の2つの列を持つテーブルを使用して、データを「ステージング」テーブルに格納するための共通テーブルを定義します。多分。これ以上の「すべてをカスタマイズする」ことが目標ではありません。
次に、ビジネスルールをどこに置くかを決める必要があります。私の部門の管理者は、データのすべてのロードはInformatica ETLバッチプロセスによって行われる必要があるため、ルール/編集は「Informatica」に属すると固く信じています。私はInformaticaツールの経験がまったくなく、.NETの人です。したがって、これらのルールがどのように実装されているかはわかりませんが、特定のレコードを検証するために.NET Webページで使用できるという意味で、再利用できないと思われます。場合によっては、ユーザーが一括アップロードを実行していないときに、特定のレコードを編集する機能があり、ETL一括挿入プロセスによって適用されたのと同じ編集を個々の更新に適用したいことがあります。 Webページを介して単一のレコードを試行します。単一のレコードの更新を実行するWebページから呼び出すことも、一括アップロードのレコードごとに数千回呼び出すこともできる単一のWebサービスまたはストアドプロシージャを作成するソリューションの場合はどうでしょうか。後者は非効率に聞こえます。
上記のことについてのあなたの考えは大歓迎です。