4

2009-09-01(新しい税金)で構成値を変更する必要があるというメールが届きました。これに対する通常のアプローチは、2009-08-31の23:59に起きてから、値を手動で変更することです。これは頻繁には起こらないので、これは大きな問題ではありません。しかし、他の人がこのような問題をどのように扱っているのか不思議に思います。

それで!日付固有の構成変更をどのように処理しますか?

(私たちはasp.netで作業していますが、これは言語固有である必要はないと思います)

Br
Carl Bergquist

4

9 に答える 9

18

私は通常、この種のデータを次のようなデータベーステーブルに保存します

Key,  Value,  EffectiveFrom,  EffectiveTo
-----------------------------------------
VAT,    15.0,      20081201,     20091231
VAT,    17.5,      20100101,         NULL

EffectiveFrom次に、日付と日付を使用してEffectiveTo、特定の時間に有効な値を選択します。レートがオープンエンドの場合、有効なのはNULLまたは99991231のいずれかです。

これにより、構成を変更せずに戻ることもできます。たとえば、誰かがレート変更の前に前月の税を再計算するようにあなたに頼んだ場合。

于 2009-08-21T10:24:11.000 に答える
2

Linuxには、atバッチ実行用のコマンド""があります。
詳細については、「man at」を参照してください。

于 2009-08-18T09:38:25.490 に答える
2

正直なところ、時間の近くに目を覚ましてそれを変更することは、最も簡単で最も安価なアプローチのようです。すべての技術的な解決策は問題ありませんが、それはあなたがどこで働くかによります。

私たちの環境では、すでに機能しているソフトウェアの機能を再開発するよりも、誰かに目を覚まして変更を加える方が安くて簡単です。確かに、テスト、開発のオーバーヘッド、およびコストが少なくて済みます。つまり、手動で問題を解決する傾向があります。

于 2009-08-25T08:36:07.333 に答える
1

それは状況と技術に完全に依存します。

pjpのアイデアは、データベースから構成を取得する場合、または構成セット/ファイル全体の有効時間を定義するメタデータとして使用する場合に適しています。

もう1つは、新しいエントリを使用して新しいconfigfileを準備し、深夜に(おそらくサービス/プログラムを再起動して)それらを交換するだけです。それらを交換することは(bei Neerajが与えられたように)atで可能になるでしょう...

タイミングが問題になる場合は、変更を処理するか、少なくとも実行中のサーバーで変更のタイミングを処理する必要があります(同期のタイムアウトの問題を回避するため)。

于 2009-08-21T10:28:02.490 に答える
1

以前にも同じような問題が発生し、次の方法で対処しました。これは、構成の変更を開始するソースに精通している場合に適しています。

この場合、ソースは変更された構成の詳細を返すWebサービス(実際にはサードパーティ)を公開しました。また、サーバー上で実行されているWindowsサービスがあり、Webサービスのポーリングを継続し、変更があった場合は構成ファイルを更新します。

これは私たちの場合は完全に機能します。

このアプローチを利用するには、ポーリングWebサービス部分を構成変更のソースに変更します(たとえば、ディスクパスから変更を読み取る)。しかし、これが電子メールから構成変更を読み取ることがどのように可能であるかはわかりません。

于 2009-08-26T07:13:28.077 に答える
1

ファイルを交換するためのシェルスクリプトを作成してみませんか。cronで実行し、1分前にファイルを切り替えて、成功しなかった場合はアラートテキストを送信し、成功した場合は電子メールを送信します。

これはLinuxボックスでの例ですが、要点を理解し、Windowsボックスでこれを実行できると思います。

脚本:

cp /path/to/old/config /path/to/backup/dir/config.timestamp
cp /path/to/new/config

if(/path/to/new/config exsits) {
 sendSuccessEmail();
} else {
 sendPanicTextAlert();
}

cron:

59 23 31 8 *  /path/to/script.sh

ダミーのディレクトリとファイルをポイントする前に、これもテストできます。

于 2009-08-26T20:05:03.040 に答える
0

私はハイブリッドアプローチを見てきました。データモデルを実際に変更してEffectiveDate/EndDateを含めるか、手動で値を変更する代わりに、スクリプトをスケジュールして値を自動的に変更します。また、すべての変更を検証する確実なテスト計画を立ててください。

ただし、このタイプの手動変更は、レポートに劇的な影響を与える可能性があります。以前のトランザクションが変更されるテーブルに直接参加する場合、履歴レポートの数値が非常に悪い方法で変更される可能性があります。本当に「正しい」答えはありません。

于 2009-08-25T20:37:53.207 に答える
0

最善の解決策は、構成ファイルをパラメーター化して、特定のエントリをいつ使用するかなどを追加することです。これにより、ファイルのコピーやスワッピングの必要がなくなり、アプリケーションはそれを処理するだけになります。(これは、構成ファイルのアプローチまたはデータベースに当てはまります)

現在のシステムを変更できず、構成ファイルを交換する必要がある場合は、次の2つのオプションもあります。

  1. スケジュールされたタスクを使用して、バッチジョブまたはVBScriptまたはPowerShellスクリプト(快適に感じる方)を開始します。深夜にこれを実行できるように正しい資格情報を設定していることを確認してください。追加することもできます。このアプローチへのいくつかのチェックと軽減。
  2. これを行うWindowsサービスを作成します。ここには、必要なすべての柔軟性があります。必要なことをすべて実行するようにコーディングし、必要なすべてのチェックを実行します(実際に機能することを確認するのではなく、スリープ状態を維持できるようにします)。良い。ここでは、xml DOMオブジェクトとxPathを使用してファイルを置き換えるのではなく、必要に応じて特定のエントリを更新することができます。

構成ファイルを変更するとサイトが再起動することを忘れないでください。そのため、これによって発生する可能性のある他のすべてのハウスキーピングに注意してください。(これは、真夜中にファイルをコピーしている場所でもまったく同じですが)

于 2009-08-28T08:34:17.880 に答える
0

pjpのソリューションのようなことができない場合は、スケジュールされたタスクまたはサーバージョブのいずれかを使用して、適切なタイミングで自動的に更新します。しかし...私はおそらくそれが機能したことを確認するためにまだ起きているでしょう。

于 2009-08-26T07:20:06.350 に答える