通知センター。 200以上のニュースレターを使いこなす

みなさんこんにちは！ この記事では、通知センターの作成方法を説明します。通知センターは、10年にわたる大規模なシステムのフレームワーク内でユーザーとのコミュニケーションの質を解決するシステムです。



当社のシステムは、9つの方法で35のシステムから206の異なる通知を送信します。 これが仕事の最前線です。 この巨人のために、単一の通信プラットフォーム-通知センター-を作成しました。









あらゆる情報システムが開発され、ますますユーザーと連絡を取り始めます。 最近注文したオンラインストアを考えてみてください。 彼は注文に関する情報、ニュースレター、新しいプロモーションのプッシュ通知、SMSを含む手紙を送信し、ソーシャルネットワークでも活躍しています。 そして、おそらくこれらのメッセージの構成が異なることに気づいたでしょう。 そして、音質と品質がどれほど異なる可能性があるか-ソーシャルネットワークにはきちんとしたテキストとハッシュタグがありますが、私はそれを読まずにスパムに手紙を送りたいです。

タスク認識

まず、次のパラメーターを使用してこれらすべてのメッセージを分析しました。



•これらのメッセージの受信者は誰ですか。

•どの配送戦略（即時、スケジュール、集計）、

•メッセージのテンプレートがありますか、

•送信の信頼性、

•コーポレートアイデンティティと一致するかどうか、

•多言語のサポートがあります。



言い換えれば、私たちは何を誰に送るのかを知りたかったのです。 そして、ここに我々が得た結果があります。







私たちは、メッセージが効率的に配信され、その意味を保持する通知の単一のコンベヤーに来たいと思いました。



通知を送信し、「サブスクリプション」、「ローカリゼーション」などのエンティティを理解するためのビジネスシステムからの負担と責任を取り除きたいと考えています。



私たちのコンセプトでは、情報システムは、メッセージの件名/タイプによって、どのように、いつ、誰に、どのチャネルを介して配信する必要があるかを認識するスマートパイプラインを備えた集中型ミニエディションになる必要があります。 そして配布します。

具体的には、これらが私たちの主な目標です。

1.ゲームのルールに同意し、すべての通知を単一の品質にします。 すべての通知を分析し、5つのシステムが同じ情報を異なるデザインでユーザーに送信した場合の状況を削除します。 UIと通知リテラシー、通知送信の保証、ビジネスシステム開発者からの送信通知の監視に対する責任を取り除きます。 代わりに、単一の設計と機能を備えたすべての通知テンプレートと、これらの問題に対処する別のチームが保存される集中システムになります。



2.タイムリーな出荷を確保します。 情報を送信する頻度と送信する通知のタイプを構成できます。 ビジネスのリクエストに応じて新しい通知をすばやく追加できるようにします。 たとえば、注文のキャンセルに関する情報はできるだけ早く配信する必要がありますが、販売や新しいコレクションについては週に1回話すことができます。



3.保証された送信情報を提供します。 最も多くのオンラインチャネルを送信するための重要なメッセージ-これはSMS、インスタントメッセンジャーです。 または一度に。 反応がない場合は、同じチャネルまたは他のチャネルで監視および複製します。



4.単一のコミュニケーションスタイルを維持します。 コミュニケーションシステム（手紙とメッセージのテンプレート）を作成し、それに固執します。 （これは統一されたUIと編集ポリシーです ）。



5.コミュニケーションをパーソナライズします。 私たちが個人と通信するとき、および法人と通信するとき、彼が住んでいるタイムゾーンを区別します。



6. Vigil、つまり、監視とセキュリティを設定します。 添付ファイルを直接送信するのではなく、開いたときにセキュリティチェックが実行され、ダウンロード統計が収集される添付ファイルへのリンクを送信します。 保証された送信を提供し、誰に送信されたかを監視します。

既製のソリューションはどうですか？

市場には、必要な機能の一部を実行するボックス化されたソリューションがあります。 たとえば、BizTalkでは、イベント通知を埋め込み、最終的にこのメッセージを構成する特別なパイプを構成できます。 Dynamics CRMおよびSharePointには、イベントに応答する設定があります。 原則として、これは誰かがどこかでボタンをクリックしたという事実に要約され、その結果、メールが送信されました。 集約ポリシーや美しいUIなど、より複雑なものは問題外です。



AzureとAWSには、既製のコンテンツを取得してニュースレターを電子メールに送信できる多くのサービスがあります。 すべてのコンテンツを手動で準備する必要があることがわかりました。 そして、通知センターの目的は、コンテンツを正確に準備することです。



そのため、この場合、UIを構成する必要のあるすぐに使用できるソリューションに依存しないようにし、システム自体がどこかに接続して必要なものすべてを引き出すようにしました。 そのようなことはそのままでは機能しません。それらはあなたの手で行われる必要があります。 このような場合のボックス化されたソリューションには、メタ言語と構成の使用が含まれ、最終的には構成の問題になります。 しかし、私たちはビジネスの特定のニーズに対応したソリューションを得ました。 新しいタスクの構成と追加は簡単です。

コンベアを組み立てます。 通知センターのアーキテクチャ

私たちにはビジネスシステムがあります-これらはビジネスの主なタスクを解決するシステムです。 これらは通知センターとは別に機能し、ユーザーとの通信を処理すべきではありません。



理想的には、そのようなシステムは、作業や他のシステムとの相互作用に必要なビジネスイベントを生成するだけであり、通知センターは単に近くに自分自身を接続し、これらのビジネスイベントの別のリスナーになり、必要最小限の入力でアクションのシグナルとしてそれらに反応します情報。 さらに、通知センターはイベントに必要な情報を追加して処理し、出力で1つまたは複数の通知を送信する準備ができます。各通知は、適切な言語で、必要なすべての情報で、関心のあるユーザーに個別に対応します。



技術的には、これはすべて、次のような情報処理コンベヤーに配置されます。

1.イベントの組み立て

すべては、ビジネスシステムからデータをインターセプトまたは意図的に収集し、さらに処理するためにイベントの「生の」ストリームとして保存するイベントアセンブリから始まります。



開発の観点から見ると、イベントコレクタは、別のタイプのイベントの処理を非常に迅速に追加できるように設計されたホストシステムです。



当初から、データ収集用のメガシステムという概念を放棄しました。これには、独自のメタ言語と奇跡のUI設定があり、あらゆるシステムに接続して組み立てることができます。 代わりに、システムの基盤を利用可能な最も柔軟なツールであるプログラミング言語にし、次のビジネスイベントの処理を、イベントをどこで何に変えるかを知っている小さな古典を書くことに減らすことに焦点を当てました。 次に、このクラシックはデータ収集のホストシステムにスローされ、パイプラインの別の要素として機能し始めます。



データ収集時に、それらは「標準形式」に削減されます-各イベントは一意の識別子を受け取り（CorrelationIdが取得され、ビジネスシステムで既にイベントに割り当てられています）、イベントの日付が決定されます（DateTime.Nowまたは到着したビジネスデータの日付はケースによって異なります） ）、イベントのタイプなど、およびすべてのイベントは、さらなる処理のためにイベントの一般的なストリームに保存されます。 コレクターは、イベントデータに直接興味はありません。彼は、比data的に言えば、イベントデータをエンベロープでラップします。 封筒の形式は標準的ですが、内容は異なります。

2.データを保存する場所は？ イベントストア

上で書いたように、イベントの収集時に、それらはさらなる処理のために共通のストリームに保存されます。 データを保存する方法の問題を解決するために、 EventStoreと呼ばれる、広く知られている狭いサークル製品を選択しました。 ところで、EventStoreのイデオロギー家の1人はGreg Youngで 、その名前はCQRSやイベントソーシングなどの概念と密接に関連しています。



メインページの定義によると、EventStoreは「JavaScriptでの複雑なイベント処理を備えた機能的なデータベース」です。 EventStoreを自由形式で定式化しようとすると、これはデータベースとメッセージブローカーの非常に興味深いハイブリッドであると言えます。



ブローカーから得られる利点は、EventStoreが新しいイベントに関するリスナーへの通知、メッセージ配信の保証、競合処理、どのサブスクライバーがすでに読んだメッセージを追跡するなど、リアクティブシステムを構築できることです。



ただし、メッセージブローカーとは異なり、データは受信者によって読み取られた後、EventStoreから削除されません。 これにより、アトミックイベントでの事後作業だけでなく、データベースのように履歴データの配列でも作業できます。 ところで、イベントストアの最も高度な機能の1つは、時間の経過に伴うイベントのシーケンスを分析できる一時クエリを作成する機能です。これは通常、「従来の」データベースを使用して行うのは困難です。



通知センターの場合、EventStoreの両方の可能性が需要があることが判明しました。 リアクティブサブスクリプションモデルを使用して、即時通知の生成とイベントデータの充実（以下について）を実装しました。 そして、 予測の助けを借りて、イベントのシーケンスの分析を整理しました。



a。 「…の概要/週/月/年」の精神で集約イベントを生成します。

b。 さまざまなタイプのイベントのシーケンスを分析し、それらの間の興味深いパターンを見つけ、イベントのピークを追跡し、一般的に。

3. BLOBストレージ

通知センターの開発中に発生したデータストレージに関連する別の問題は、ファイルの操作です。 多くの場合、通知のファイルをユーザーに送信する必要があります。



最も簡単な例は、レポートをメールで送信することです。 そして、あなたができる最も簡単なことは、添付ファイルとしてメールにファイルを添付することです。 しかし、シナリオを開発すると、そのようなソリューションにはいくつかの制限がすぐにあります。

1. 送信後、ファイルの運命については何も知りません。 開かれたかどうか、何回、誰が開いたか。
2. メールではすべてが簡単ですが、SMS通知にファイルを添付することはできません。
3. ファイルを添付ファイルとして送信するときのメールサーバーの追加負荷。
4. 同じファイルが多くのユーザーの関心を引く可能性があります。

これらすべての問題に対する最も簡単な解決策は、ファイルではなくリンクを送信することです。 そのため、メールサーバーも読み込まず、ファイルで何が起こっているかを監視し、セキュリティチェックを実行して、ユーザーがこのファイルを本当に見ることができることを確認することもできます。



一方、これには純粋に実用的な意味があります。 ファイルは、イベントが発生した瞬間からイベントに添付できます。 たとえば、ビジネスイベントの本質が特定の日付の航空輸送の予約システムから交換ファイルである場合。 または、たとえば先月にイベントのパケットを処理した結果としてファイルを生成できます。



一般に、ファイルはイベントの存続期間の最初から存在する可能性があり、通知センターのコンベヤー全体に大量のコンテンツを「ドラッグ」しても意味がありません。 最初にファイルを特別なサービスに保存し、イベントでその識別子を保存できます。 また、通知を送信するときに必要なファイルを取得できます。



そのため、別の非常にシンプルなサービス-Blob Storageが生まれました。このサービスでは、POSTリクエストでファイルを保存し、応答でGUIDを取得できます。 また、受信したGUIDを使用してGETリクエストをサービスに送信することもできます。その代わりに、ファイルが返されます。 そして、すべてのセキュリティチェック、統計収集など-これらはすでにBlob Storageサービスの内部問題です。

4.データの充実

そのため、現時点では、イベントアセンブリの段階と、イベントとファイルに関する情報の保存方法について検討しました。 データの処理が始まる段階、つまり強化段階に進みましょう。



以前に収集された「標準的な」イベントは、このステージの入力に入ります。 出力では、既に受信者、特定の言語のメッセージのテキストが含まれている0からN個の準備完了通知が得られ、通知を送信する必要があるチャネル（電子メール、電報、SMSなど）は既に明確になっています。



この段階で、初期イベントに次の操作を行うことができます。

元のデータセットへの追加

基本的に、この操作のおかげで、ステージ全体が「エンリッチメント」と呼ばれました。 データ追加の最も単純な例-「標準的な」イベントで、ユーザーIDが来ました。 この段階で、通知テキスト内の名前でユーザーにアクセスできるようにするために、ユーザーのIDでユーザーの名前を見つけ、見つかった情報で元のイベントを補足します。



各「エンリッチメント」は個別の小さなクラスであり、（イベントコレクターとの類推により）迅速に書き込まれ、共通のパイプラインに「投げ込まれ」ます。これにより、必要な情報がすべて入力に送信され、結果が必要な場所に保存されます。

集約、イベントシーケンス処理、時間分析

ここではすべてが非常に簡単です。 アプローチは強化の場合と同じですが、アグリゲータークラスはスケジュールに従って起動され、ストリーム内の新しいイベントに応答しません。 一般的な場合、このようなハンドラーを実行すると、異なるタイプの新しいイベントが生成されます。このイベントは、生成元のデータに基づいて同じ標準ストリームに分類されます。 さらに、この新しいイベントも同様に強化、集約などを受ける可能性があります。



強化後、イベントの作業の最終段階が始まります。

5.通知の生成

通知は、JSONデータだけでなく、既知の受信者、送信チャネル（電子メール、SMSなど）、および通知テキストを含む完全に特定のメッセージであるという点で、イベントとは異なります。



通知の生成は、必要なすべての強化が適用された直後に開始されます。



本質的に、これは、このタイプのイベントにサブスクライブし、1つまたは別のテンプレートエンジンを介して元のJSONデータを実行し、サブスクリプションで指定されたチャネルのメッセージテキストを生成するユーザーとの着信イベントの単純な結合です。 その結果、1つのイベントから0〜N個の通知を受け取ります。



次に、簡単なことは、受信した通知を対応するストリームに押し込むことです。そこから、レター、SMSメッセージなどの送信に関係するマイクロサービスによって減算されます。 しかし、これらはすべて明白で面白くないものであり、読者の注意を無駄にしないでしょう。

6.サブスクリプション

検討するモジュールの最後のモジュールは、ユーザーによるサブスクリプションをセットアップするためのモジュールです。



アイデアは簡単です-誰がどのタイプの通知に興味があるか、カスタマイズ用のUIについての情報を保存するデータベースです。







ユーザーが購読を希望する場合、ユーザーは興味のある通知の種類を選択し、設定ウィンドウを開きます。 通知のタイプごとに、1つ以上の送信チャネルを使用できます。 ここでは、ユーザーは設定の最小数を示します。電子メールの場合は電子メール、Telegramの場合は電話番号、必要に応じてテストメッセージを送信して、すべてが正しく構成されていることを確認します。



それだけです これで、特定のタイプのユーザーのサブスクリプションがあり、パイプラインには同様のタイプのイベントがあります。 イベントとサブスクリプションを横断し、出口で準備完了通知を受け取ります。

7.アクセス制御

以前に考慮しなかったもう1つの点は、アクセス制御です。 例で説明しましょう。 取引相手が商品の代金を支払う時期になったという通知があるとします。 この通知は特定の取引相手に適用され、すべての取引相手ではなく、彼だけが受信する必要があります。 したがって、上記の種類の通知だけでは、イベントの対象者を特定するには不十分です。



最も単純だが最も失敗した解決策は、カウンターなどの概念を通知センターのロジックに導入することです。通知センターには、たとえばコードがあります。 また、イベントの受信者を決定するときは、イベントのタイプだけでなく、取引先コードによっても遮断します。



なぜこれが悪いのですか？ 通知センターは、通知を送信するタスクからビジネスシステムを保存するための独立したシステムとして登場しました。 しかし、そのような詳細を通知センターに導入することで、最終的には通知センターにビジネスシステムからの多くの知識を追加します。



この場合のこの問題の正しい解決策は、非常にシンプルでありながら柔軟性があります。



システムの承認には、ADFS、つまりクレームベースの承認を使用します。 クレームは基本的に単なる識別子と値のペアです。 定義済みのクレームセットがあります-ユーザー名、ユーザーロールを持つクレームセットなど。 これらの種類のクレームのキーは事前に知られており、すべてのアプリケーションの標準です。 また、カスタムクレームプロバイダーを使用して、承認時にユーザーにさまざまな特定の属性を割り当てます。



たとえば、上記の取引先コードは、ユーザーが取引先である場合、独自のキーを持つクレームとして保存できます。 または、ユーザーがいる地域のコード。 または、どのデバイスを所有しているのか、iPhoneまたはAndroid。 この方法で、意味のあるマーカーを保存できます。



これはすでに問題の半分の解決策です。各ユーザーに一連のクレームがあるため、サブスクリプションがあります。



イベントにクレームを追加すると、タイプだけでなくイベントとサブスクリプションを比較できるだけでなく、同じキーを持つイベントクレームとサブスクリプションクレームの両方が同じ値を持つことも確認できます。



「Yの値を持つクレームXを持つイベント」の概念は、「相手方Yを対象としたイベント」よりもはるかに抽象的なものであることに注意してください。 通知センターにビジネスシステムの詳細を追加する必要はありません。



問題は、イベントに対するこれらの申し立てをどこで埋めるかです。 クレームの生成は、「支払いが必要な場合は取引相手のクレームを持たなければならない」という精神で、ビジネス特有のものであるため、このロジックをデータ収集段階に配置しました。 コレクターは、少なくともイベントとその構造を取得する場所を知っています。 つまり、彼はすでにいくつかのビジネスコンテキストを持っています。



支払いの必要性に関するイベントの例では、カウンターパーティコードは、ほとんどの場合、コレクターが傍受した支払いの必要性に関するビジネスイベントの契約で見つかります。 したがって、コレクターは、契約の目的のフィールドからカウンターパーティコードを取得し、イベントを通知センターパイプラインに送信する前に、「キーXと値Yのクレーム」の概念に抽象化します。

合計

これは、システムのさまざまなモジュールで発生したさまざまなイベントについて、さまざまなユーザーグループに通知するプロセスを統合する問題を解決する方法です。 コンベヤーは単一であり、オムニチャネルを通知し、出荷は保証され安全です。また、プラットフォーム自体は開発に対してオープンです。