gen_eventの概要：アカウント変更通知

翻訳者から：私はカルマの欠如のために結び付けられた旗をキャッチしようとします（ところで、最初の翻訳に感謝します。著者のおかげで、著者の一連の記事を翻訳し続けたいと思います）。



前の部分へのリンクは、記事の最後にあります。



これは、 OTPシリーズの概要の 3番目の記事です。 最初のパートから始めることをお勧めします。これは、gen_serverについて説明し、銀行システムの基礎を築きます（まだ行っていない場合）。 一方、有能な学生であれば、既製のモジュールeb_atm.erlおよびeb_server.erlを見ることができます。



シナリオ ：中央サーバーソフトウェアとローカルATMの出現により、ErlyBankは技術ベースを楽観的に認識し始めました。 しかし、競合他社に対する保護手段として、一定量の現金が引き出されたときに通知を送信するシステムを実装したいと考えています。 ソフトウェアを再起動せずに、現金引き出し額のしきい値を変更すると、通知がトリガーされます。 経営陣は、タスクに従って現在のバージョンをアップグレードするために私たちを雇うことにしました。



結果 ： gen_eventを使用してイベントベースの通知システムを作成します。 これにより、将来的に他の通知を作成するための基本的な基盤が提供されると同時に、現在のサーバーソフトウェアへの統合が容易になります。

gen_eventとは何ですか？

gen_eventは、Erlang / OTPの動作モジュールとして機能します（ 動作;前の著者の翻訳とは異なる用語を使用します。サイクルの初期に、用語は「インターフェイス」として翻訳されました。トランスレータ ）イベント処理機能を実装します。 これは、多くのハンドラーが実行されているイベントマネージャープロセスを実行することで実現されます。 イベントマネージャーは他のプロセスからイベントを受信し、各ハンドラーは順番にイベント通知を受信し、それらで何でもできます。



ハンドラーの予想されるコールバックは次のとおりです。

• init / 1-ハンドラーを初期化します。
• handle_event / 2-リスナーがリッスンするイベントマネージャーに送信されたイベントを処理します。
• handle_call / 2-イベントマネージャーへの呼び出しとして送信されるイベントを処理します。 このコンテキストでの呼び出しは、gen_serverの動作での呼び出しと同じです。応答が送信されるまで実行は中断されます。
• handle_info / 2-ハンドラーに送信された、イベント（イベント）または呼び出し（呼び出し）ではないメッセージを処理します。
• terminate / 2-ハンドラーが終了するときに呼び出され、プロセスが必要なリソースを解放できるようにします。
• code_change / 3-操作中にモジュールがコード変更を直接受けると呼び出されます。 このモードはこの記事では説明しませんが、このシリーズの今後の記事のヒーローになります。

このシリーズの前半で説明した2つの動作モジュールと比較して、現在のモジュールには比較的少数のフィードバックメソッドがあります。 ただし、gen_eventは同じ頻度で使用でき、他のOTPモジュールと同じ機能を備えています。

イベントマネージャーを作成する

最初に行う必要があるのは、イベントマネージャーを作成することです。 これは比較的簡単なタスクです。gen_eventサーバーを起動するだけであり、いくつかのAPIメソッドを追加することで、新しいハンドラーの追加、通知の送信などが簡単になります。



私のイベントマネージャーフレームワークを見てください。 さらに、基礎として使用して、フラグメントを提供します。



ご覧のとおり、このファイルは珍しいものではありません。 開始方法は、他のOTP動作モジュールと同じです。 イベントマネージャーにハンドラーを追加するメインAPIを含めました。

%%--------------------------------------------------------------------

%% Function: add_handler(Module) -> ok | {'EXIT',Reason} | term()

%% Description: Adds an event handler

%%--------------------------------------------------------------------

add_handler(Module) ->

gen_event:add_handler(?SERVER, Module, []).







このメソッドは、単に現在のモジュールにあるイベントハンドラーをイベントマネージャーに追加します。 また、イベントマネージャーを介して通知を送信するために必要な、使いやすいメソッドを追加しました。

%%--------------------------------------------------------------------

%% Function: notify(Event) -> ok | {error, Reason}

%% Description: Sends the Event through the event manager.

%%--------------------------------------------------------------------

notify(Event) ->

gen_event:notify(?SERVER, Event).







また、理解しやすいものでなければなりません。 このメソッドは、イベントをイベントマネージャに送信するだけです。 gen_event：notify / 2は非同期要求であるため、すぐに戻りが発生します。

イベントマネージャーをサーバーに接続する

サーバーが起動する前に、イベントマネージャーが既に実行されていることを確認したいので、サーバーモジュールから明示的に起動するように強制します。 後で、別の記事で、 スーパーバイザーツリーにこれを強制する予定です。 新しいサーバー初期化コードは次のとおりです。



init([]) ->

eb_event_manager:start_link(),

{ok, dict:new()}.









イベントマネージャーはサーバープロセスの全期間を通じて起動されることを前提としているため、特定の時点でメッセージを送信することができます。 クライアントであるErlyBank は、一定の額の引き出しがいつ発生するかを知りたいと考えています（ 著者は入金、つまり入金と言いますが、これは明らかに間違いです。 これは私がこれをサーバーに接続する方法です：



handle_call({withdraw, Name, Amount}, _From, State) ->

case dict:find(Name, State) of

{ok, {_PIN, Value}} when Value < Amount ->

{reply, {error, not_enough_funds}, State};

{ok, {PIN, Value}} ->

NewBalance = Value - Amount,

NewState = dict:store(Name, {PIN, NewBalance}, State),

% Send notification

eb_event_manager:notify({withdraw, Name, Amount, NewBalance}),

{reply, {ok, NewBalance}, NewState};

error ->

{reply, {error, account_does_not_exist}, State}

end;









これで、イベントマネージャを使用した引き出し中に、イベントも生成されます。 通知メソッドは非同期であり、イベントマネージャーとハンドラーは別々のプロセスで実行されることに注意してください。 これは、通知が並行して実行され、トランザクションの速度が低下しないことを意味します。 もちろん、プロセッサが過負荷になると、各プロセスの実行に時間がかかりますが、理論的には同時に発生するはずです。



また、ここで引き出し金額が特定の金額を超えたかどうかをチェックしていません。 ErlyBankは、しきい値として使用する量を指定しませんでした。サーバープロセスでハードコーディングするのはかなりばかげています。 一般に、すべてのロジックをハンドラーに残して、通知を呼び出すことをお勧めします。 そして、これはまさに私たちが次にすることです！



eb_server.erlのすべてのコンテンツはここで見ることができます 。

ハンドラーフレーム

私はいつもすべてのOTPモジュールの基本的なフレームワークを持っています。 イベントハンドラーについてはこちらをご覧ください 。



このモジュールを際立たせている1つのこと：ここにはstart_linkまたはstartメソッドがありません。 これは、イベントハンドラーを接続するためにeb_event_manager：add_handler（Module）メソッドを使用しているためです。実際、このメソッドはプロセスを開始して生成します。



init([]) ->

{ok, 500}.









gen_eventハンドラーの初期化メソッドは、他のすべてのErlang / OTP動作モジュールのメソッドと似ていますが、 {ok、State}を返します。Stateはプロセスのデータの状態です。 この場合、500を返します。これは、アカウントからの引き出しの通知の警告しきい値を示すために使用します。

現金引き出し通知処理

このイベントハンドラーの唯一の目的は、出金通知を受け入れ、出金額が特定のしきい値を超えた場合に何かを行うことです。 イベントは、非同期メッセージgen_event：notify / 2を使用してディスパッチされます。 ハンドラーへの非同期通知は、 handle_eventメソッドによって処理されます。



handle_event({withdraw, Name, Amount, NewBalance}, State) when Amount >= State ->

io:format("WITHDRAWAL NOTIFICATION: ~p withdrew ~p leaving ~p left.~n", [Name, Amount, NewBalance]),

{ok, State};

handle_event(_Event, State) ->

{ok, State}.









メッセージの処理は簡単です。 しきい値の撤回の量を超えた場合にのみイベントを受信するために、撤回メッセージと保護を確認するためのテンプレートを追加しました。



引き出し金額がしきい値を超えると、端末に出力します。



完成したeb_withdrawal_handler.erlモジュールは、 ここで取得できます 。

操作中のしきい値の変更

ErlyBankは、仕事中に現金の引き出しを通知するためのしきい値を変更できるようにしたいとも述べました。 これを行うには、実際のハンドラーにAPIメソッドを追加します。 ここにあります：



%%--------------------------------------------------------------------

%% Function: change_threshold(Amount) -> {ok, Old, NewThreshold}

%% | {error, Reason}

%% Description: Changes the withdrawal amount threshold during runtime

%%--------------------------------------------------------------------

change_threshold(Amount) ->

gen_event:call(eb_event_manager, ?MODULE, {change_threshold, Amount}).









これにより、新しいget_eventメソッドであるcallメソッドが導入されます。 このメソッドは、特定のハンドラーに要求を送信し、応答を予期するため、同期的です。 彼の引数はcall（EventManager、Handler、Message）です。 したがって、この場合、最初のパラメーターとして、現在のプロセスに登録されているイベントマネージャーモジュールを示します。 ハンドラーモジュールの名前を2番目のパラメーターとして指定し、しきい値を変更するメッセージを送信します。



このリクエストは、 handle_call / 2フィードバックメソッドで処理します。



handle_call({change_threshold, Amount}, State) ->

io:format("NOTICE: Changing withdrawal threshold from ~p to ~p~n", [State, Amount]),

{ok, {ok, State, Amount}, Amount};

handle_call(_Request, State) ->

Reply = ok,

{ok, Reply, State}.









まず、しきい値が変更されているというメッセージを端末に表示し、次にメッセージ{ok、OldThreshold、NewThreshold}で返信し、新しいしきい値をデータの状態として設定します。 次の出金通知を受け取ると、ハンドラーは新しい警告値を使用します！ :)



完全なeb_withdrawal_handlerモジュールは、 ここで表示できます 。

おわりに

gen_eventに関するこの記事では、イベントマネージャーの作成、イベントのディスパッチ、イベントハンドラーの実装、これらのイベントの受信、およびハンドラーの呼び出しについて説明しました。 私が開示しなかった唯一のことは、gen_eventの一部です。これにより、イベントハンドラーは切断したり、別のハンドラーに置き換えたりできます。 その理由は、私は実際の環境でこのメカニズムを使用した経験が豊富ではないからです。 これまでのところ、私はこれらの機会への応用を見つけていません。 ただし、それらについて知りたい場合は、 ドキュメントを参照してください。



これで、Erlang / OTP導入サイクルの3番目の部分が終了します。 第4条は数日中に公開される予定で、 監督者について話します。

---

UPD

kutu habrayuzerの注意のおかげで、重大な省略が発見されました。これは、原文で作成され、その後翻訳に移行しました。 注：この記事では、ハンドラーに対してeb_event_manager：add_handler（Module）を呼び出す必要がある場所を示していません。 呼び出しは実行されないため、ハンドラーは作業に含まれません。 この段階でハンドラーを接続する論理的な場所は、eb_serverl.erlのinit（Args）です。 これは、必要な変更を行った後のこのメソッドの外観です。



init([]) ->

eb_event_manager:start_link(),

eb_event_manager:add_handler(eb_withdrawal_handler),

{ok, dict:new()}.









将来の記事では、元のテキストの作成者は、すべての起動スクリプトを1か所から起動することを約束しますが、これは次の記事でのみ発生します。 私たちと一緒にいてください！



さらに、eb_withdrawal_handlerハンドラーの完全版へのリンクが翻訳に追加されましたが、誤って持って行くのを忘れていました。

---

シリーズの記事

4. コントローラーを使用してErlyBankをフロート状態に保つ

3. gen_eventの概要：請求書変更の通知（現在の記事）



翻訳の著者は関係者です：

2. gen_fsmの概要：ErlyBank ATM

1. gen_serverの概要：ErlyBank

0. Open Telecom Platform / Open Telecommunication Platform（OTP / OTP）の概要

-1。 背景