Webサイト用の手動および自動CSVファイルアップロードソリューション

Question

問題

新しい機能が必要なWebサイトを実行しています。ユーザーがCSVファイルをWebサイトにアップロードできるようにしています。ユーザーが一度にアップロードする必要があるCSVファイルは1つだけであり、平均して1日あたり1つまたは2つのCSVファイルのみです。 CSVのファイル形式を定義するので、フィールドとは何か、各フィールドのデータ型を指定しますが、ファイルに含まれる行の数もわからないので、具体的なデータはどちらかになります。 CSVファイルのサイズが1MBを超えることはないと想定できます。

Webサイトはすでに存在していますが、CSVファイルをアップロードする機能はまだ計画段階です。現在、このWebサイトでは、ユーザーはデータにログインして管理でき（つまり、ユーザーレベルで特権を制御できます）、そのすべてがSQL Serverデータベースを通じて管理されます。 WebサイトはIIS7.5でASP.NETを実行しています-これは変更できません。サーバーはNATされていませんが、ファイアウォールで保護されています。ウェブサイトについてさらに情報が必要な場合は、お問い合わせください。

ユーザーの観点から見ると、彼らは自分のPCで独自のプログラムを使用してCSVファイルを生成します。 99％の確率で、CSVファイルは何らかの形の商用ソフトウェアパッケージによって生成されます。パッケージの選択は彼ら次第です-私のウェブサイトにアップロードする種類のCSVファイルを生成する多くの製品が市場にあります（ここで具体的にしすぎないようにして、プライバシーとユーザーのそれ）。一部のユーザーは、メモ帳またはMS ExcelでCSVファイルを作成または編集することにより、時折CSVファイルを生成する場合もあります。私は確かに MS Excelを決して使用しないことをお勧めしますですが、彼らが自分のPCで行うことは私の制御を超えています。

ユーザーがCSVファイルを私のウェブサイトにアップロードするシナリオは2つあります。

手動アップロード

ユーザーがウェブサイトにログインしてCSVファイルをアップロードする

自動アップロード

ユーザーはどういうわけか、CSV生成ソフトウェアとPCを設定して、CSVファイルを私のウェブサイトに自動的にアップロードします。私は一部のユーザーと話しましたが、彼らのソフトウェアは必要なCSVファイルをディレクトリに自動的に生成できると言いました（つまり、新しいCSVファイルは1日1回、人の介入なしのディレクトリ）。その後、スケジュールされたタスクによって開始された何らかの形式のクライアントによって、これらのCSVファイルを自分のWebサイトに自動的にアップロードすることができます（ここでも、ユーザーが選択したクライアントを制御できませんが、アドバイスは提供できます）。これは決して要件ではありません。CSV生成ソフトウェアをクリックしてファイルを作成し、必要に応じてクライアントを手動で実行してCSVを自分のWebサイトにアップロードすることで、手動で説明した手順を実行できます。ただし、自動アップロードの要点は、IT担当者がより生産的に時間を使用できるように、自動アップロードをそのままにしておくことができるということです。

アップロードは通常、毎日行われますが、1日あたりのアップロード数に私のサイトを通じて制限を課すことはありません。彼らが1時間ごとに新しいCSVファイルをアップロードしたい場合、それは私には問題ありません。しかし、ユーザーとの私の議論から、dailyの頻度が最も便利であるように聞こえ、時刻は重要ではありません。

自動CSVアップロードが失敗した場合、私のWebサイトはユーザーにこの事実を通知します。この通知がどの形式を取るかは、選択したソリューションに本当に依存するため、まだ正確には決定していません。アップロードされたCSVファイルに不正なデータが含まれているためにアップロードが失敗した場合、ユーザーは例外によってこれを管理する必要があります（つまり、人間が関与する必要があります-これはソフトウェアで修正できるものではありません）。おそらくデータベースのデータを修正し、ソフトウェアパッケージを使用してCSVファイルを再生成することにより、障害の原因を調査してCSVファイルを修正する必要があります。その後、彼らは自由に修正したCSVファイルをアップロードできます。アップロードはタイムクリティカルではなく、悪いCSVファイルはデータベースに部分的にロードされるのではなく、単に私のウェブサイトによって無視されます。

機能要件

ユーザーはWebサイトを介して自分で手動でファイルをアップロードできる必要があります
ユーザーは自分のPCからスケジュールされた間隔でファイルを自動的にアップロードできる必要があります
CSVファイル（またはCSVファイルに含まれる同等のデータ）のみがWebサイトのデータベースに処理されます
プロセス全体は、私のITサポートの介入なしに実行する必要があります（他の選択したソリューションによっては、制御できない場合もありますが、ITサポートも可能です）。
ファイルのアップロードプロセスでは、Webサイトのフォームからデータを送信する場合にも存在しないセキュリティリスクを導入してはなりません。
私のWebサイト側では、ファイルアップロードのアクセス許可は、IIS、ASP.NET、またはSQL Serverのテーブルを使用してユーザーごとに構成可能でなければならず、ファイアウォールはアップロードをブロックしてはなりません。
私が実装するどのようなソリューションでも、少なくとも今後10年間は十分にサポートされている必要があります（2016年現在）
選択したソリューションは、ユーザーがすでに安価に入手できる（できれば無料で）標準ソフトウェアを使用する必要があります。
不正なデータがアップロードされた場合、ユーザーがそれを修正して再アップロードできるように、ユーザーに自動的にフィードバックする必要があります。アップロードしてフィードバックを受信するまでの時間遅延が短いほど良いです。

（手動または自動のCSVファイルアップロードインターフェイスの要件を逃したと思われる場合は、コメントでお知らせください。これらを追加できます）

ユーザーが悪いデータをアップロードすることについてのいくつかの考え

ユーザーが不正なデータを含むCSVファイルをアップロードすることはほぼ確実です。これは意図的なものではないかもしれません。たとえば、date-onlyフィールドに誤って整数を入力する可能性があります。ただし、悪意のあるユーザーがマルウェアを含む実行可能ファイルをアップロードするなど、意図的なものである可能性もあります。このため、CSVファイルの読み取りと解析のみを行い、実行はしないでください。

私が検討したソリューション

Webサイトを介した手動アップロードは簡単であり、この質問の焦点ではありません。ユーザーは現在と同じようにログインし、Webブラウザーの標準の multipart/form-data インターフェースを介してファイルをアップロードします。アップロードが処理されると、エラーや成功メッセージのフィードバックと、アップロードの履歴を表示するための監査が送信されます。

しかし、私は自動アップロードインターフェイスの2つの可能なソリューション間で決定しようとしており、どちらが機能要件をよりよく満たすかを決定することはできません（どちらも機能要件2、3、4を等しく満たしていると思います）：

FTPS/SFTP

サインアッププロセス中に、Webサイトのコードは、各ユーザーがファイルをアップロードするディレクトリを作成します。それぞれにFTPの一意のログイン資格情報があり、ユーザーがログインすると、これらはWebサイトにリストされます。

Windowsサービスは常にディレクトリをスキャンし、ユーザーが新しいファイルをアップロードしたことを検出すると、このファイルをデータベースに処理します。

正しくないデータを含むCSVファイルがアップロードされた場合、ユーザーにCSVファイルのアップロードが失敗したことを警告するメールをユーザーに送信します。その後、ユーザーはWebサイトにログインして、そのファイル内の特定のエラーを確認できます。その後、Webサイト（multipart/form-dataインターフェース）またはFTPS/SFTPを使用して、手動でアップロードを再試行できます。

ファイルのアップロードプロセスの一部としてユーザーはアップロードが完了したことをWindowsサービスに通知する必要があります、アップロードされたCSVファイルの名前を変更するか、シグナルファイル（例：csv-xyz.complete）CSVファイルがアップロードされたら。

機能要件に照らしてこのソリューションを検討しています...

IISはFTPSのみを処理でき、SFTPは処理できません。また、SFTPは単一のポートで実行されますが、FTPSは複数のポートで実行されます。これはおそらく私のファイアウォールには適していません（これをテストして更新します）。 IIS ASP.NETを介して構成できるSFTPプログラムはありますか？.NETでSFTP/FTPSディレクトリを設定することは可能ですか？一見するとそう、しかし、私は何か制限があるかどうか知りたいですか？
SFTP/FTPSが10年以内に存在する可能性はどのくらいですか？今日は非常に人気のあるテクノロジーのようですが、私が知らないうちに置き換えられようとしているのか、時代遅れになっているのか知りたいです。

[〜＃〜] api [〜＃〜]

ウェブサイトはすでにAPIを備えていますが、このAPIには現在ファイルアップロード機能がありません。ただし、このような機能をAPIに実装して、ユーザーがこのインターフェイスを介してCSVファイルのデータをアップロードできるようにすることができます。その場合、データをCSVファイルに配置する必要はまったくありません。セキュリティチェックと健全性チェックが行われ、データベースに直接配置されます。

ユーザーへのフィードバックは即座に行われます。不正なデータが検出された場合、アップロードへの応答には特定の詳細を含むエラーメッセージが含まれます。

ただし、私のAPIと通信するプログラムを作成するには、ユーザー側で多くの労力を必要とするようです。 CSVを読み取ってAPIにデータを送信するための標準化されたAPIファイルアップロードクライアントを知りませんが、いくつか存在する可能性がありますか？そうでない場合、私のユーザーの多くがファイルを私のウェブサイトにアップロードするためだけにまったく新しいプログラムを作成する努力をするのではないかと思います。

クライアントを構築してユーザーに配布し、APIを介してCSVをアップロードできるようにすることを検討しました。しかし、それから一連の新しい問題が発生します-新しいリリースはどのように配布されますか？ユーザーのPCと互換性がありますか？「壊れた、どうすればいいの...」という形式のクエリがたくさん表示されますか？ファイルの権限に問題がありますか？等。

もう一度、機能要件に照らしてこのソリューションを見てみましょう...

APIクライアントを開発する場合、ITサポートはおそらく「yourクライアントを使用してxを実行するにはどうすればよいですか」というタイプの呼び出しをたくさん受けるでしょう。一方、クライアントを設計しなかった場合でも、ITサポートはおそらくAPIの詳細について問い合わせを受ける可能性があり、これらは技術的な性質のものであるため、おそらく応答して緊密に連携する必要がありますエンドユーザー自身がこれらを解決します。
APIは、SFTP/FTPSでまだ利用できないセキュリティ上の利点を提供しますか？主な違いは、CSVファイルがアップロードされないため、誰かがマルウェアをサーバーにロードする可能性がないことです（CSVファイルではないことがすぐに検出されて削除された場合でも）。
これは間違いなくIISと互換性があります
ユーザー用の実行可能クライアントを作成する場合、これはWindowsの将来のバージョンでは廃止される可能性があり、MacまたはLinuxではおそらく機能しないでしょう。また、バグ修正とアップグレードを必要とする余分なコード片も浮かんでいます。
ファイルのアップロードを実装するAPIの標準については知りません。グーグルドライブはそれを実装したようですが、これがどれほど広く受け入れられているか、そして私が知る限り、ファイルシステムにアクセスできるPC上で実行されるクライアントを持っていません。ユーザーに提供するAPIクライアントを開発しない場合、各ユーザーは、自分のWebサイトにファイルをアップロードできるようにするために、何週間もの開発を検討しています。
ユーザーへのフィードバックはより迅速で、ユーザーの観点からはおそらく「自動化可能」です。プログラムで障害が発生したことを示す電子メールをスキャンするのは簡単ではありませんが、HTTP応答にエラーが含まれている場合は簡単に対処できます。

結論として

私はSFTP/FTPSに傾いています。それは、それがより多くの機能要件を満たしているからです。ただし、それは上記で提起された質問に答えるための私のさらなる研究に少し依存します。これらについての回答や考えは大歓迎です。

また、すでにそこに行って、これらの方法のいずれかまたは両方を試した人からのアドバイスも聞いています。何がうまくいきますか？何がうまくいかないのですか？非自明の落とし穴は何ですか？この分野での個人的な経験はありませんが、この比較について私が読むことができる場所へのリンクがある場合は、リンクを投稿してください。

Doc Brown · Answer

変更できない2つのエンドポイント、つまりファイル生成プログラムと、ユーザーに表示されるhttpまたはftpエンドポイントを接続したいとします。また、標準の「プラグ」がないため、スクリプトまたはプログラムであるプラグを作成する必要があります。これをユーザーフレンドリーで、「一部のIT専門家」だけが使用できるようにしたい場合は、弾丸をかじって、プログラムを作成して展開してください。

あなたはこれを成功させた最初の人ではなく、すべての有料ユーザーにメンテナンスを提供できます（実際、それは顧客があなたのサービスに支払う動機です）。プログラムを自分で作成する場合、プログラムがftp、ftps、sftp、またはhttpベースのapiを使用しているかどうかは実際には関係ありません。念頭に置いて、curlまたはlibcurlを確認することもできます。 Java、またはC++の人ならQtを使用して、プログラムをクロスプラットフォームにすることを検討してください。

これについては、「少なくとも今後10年間はサポートされる必要があります」-「ユーザーに迷惑をかけたくない」という観点から考えると、私はあまりにも多くのことを考えますこれは現在機能しており、将来的にソリューションが機能しなくなった場合に（ある程度のお金を払って）それらをサポートします。」つまり、インターネット通信技術は非常に広く使用されているため、選択する可能性が高く、あまりにもエキゾチックではない場合でも、下位互換性の理由から10年間サポートされます。しかし、そうでなくても、会社がその期間存続し、サポートを提供できる限り、それほど大きな問題ではありません。内部で別のテクノロジーを使用しているユーザーにプログラムのアップデートを提供するだけです。