オンラインバンキングシステムでRxJsライブラリを使用する機能

はじめに

最新のオンラインバンキングシステムの設計は、かなり複雑な作業です。 同時に、アプリケーションのクライアント部分を開発するための多くのタスクは、いくつかの情報源からほぼ同時に来る大量のデータの処理に関連しています。 リモートバンキングシステム（RBS）、インスタントメッセージングサービス、さまざまな情報サービスからのデータをここでリアルタイムに受信して処理する必要があります。 この種の問題を解決するために、今日ではリアクティブプログラミング手法が広く使用されています。



広義の「リアクティブプログラミング」という用語は、データストリームの状態を処理した結果としてシステムの変更の伝播が発生する、アプリケーションのそのような編成を意味します。 この方法の重要な問題は、情報フローの提示の単純さと、提示結果の非同期処理中に発生するエラーに対応する可能性です。



狭い意味では、リアクティブWeb UIプログラミングは、RxJsライブラリなどの既製の開発者ツールを使用することを意味します。 このライブラリは、Observableオブジェクトを使用してデータシーケンスの離散表現を提供します。これは、特定の間隔でアプリケーションに入力される情報のソースとして機能します。



中小企業向けのオンラインバンクのWebインターフェイスを設計する例で、ライブラリを使用する機能を検討してください。 UIを開発する際、組み込みのRxJsライブラリバージョン6を備えたGoogle Angular 6プラットフォームを使用しました。

リアクティブUIデザインタスク

ユーザーにとって、インターネットバンキングのほとんどの操作は、多くの場合3つの段階に分けられます。

• リストから必要な操作を選択します。たとえば、ローンの返済や口座の補充。
• 対応するフォームの部分的な記入（支払いの詳細は、組織の名前またはユーザーが入力した受取人の名前によって自動的に入力されます）;
• SMSメッセージまたは電子署名を使用した操作の自動確認。

開発者の観点から、これらの段階の実装には、次のタスクのソリューションが含まれます。

• RBSシステムのステータスをチェックし、リスト内の操作に関するデータの関連性を確認します。
• ユーザーが入力し、情報メッセージサービス（銀行の名前、TIN、BICなど）から受信したデータを含む、フォームへの入力時のデータフローの非同期処理。
• 完成したフォームの検証;
• フォーム内のデータの自動保存。

RBSシステムのステータスの確認

RBシステムから関連データを取得するプロセス、たとえば、クレジットラインや支払い注文のステータスに関する情報には、2つの段階があります。

• データの可用性ステータスの確認。
• 更新されたデータを受信します。

データの現在の状態を確認するために、一定の期間、およびデータの準備状況に関する応答を受信するまで、システムのAPIに対してクエリが実行されます



RBシステムにはいくつかの可能な答えがあります。

• {empty：true}-データはまだ準備ができていません。
• クライアントは更新されたデータを受信できます。

{ empty: false // -   }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• 間違い。

その結果、関連データは次の形式で取得されます。

 const MIN_TIME = 2000; const MAX_TIME = 60000; const EXP_BASE = 1.4; request() //     .pipe( expand((response, index) => { const delayTime = Math.min(MIN_TIME * Math.pow(EXP_BASE, index), MAX_TIME); return response.empty ? request().pipe(delay(delayTime)) : EMPTY; }), last() ) .subscribe((response) => { /** -  */ });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

段階的に分析しましょう：

1. リクエストを送信します。 リクエスト（）
2. 答えは拡大します。 Expandは、スレッドが正常に完了したことを報告するまで、内部および外部Observableの次のアラートごとに、ブロック内のコードを再帰的に繰り返すRxJSステートメントです。 したがって、ストリームを完了するには、次の単一のEMPTYが存在しないように、そのようなObservableを返す必要があります。
3. 応答が{empty：true}の場合、一定の時間遅延（delayTime）の後に2番目の要求を行います。 サーバーがリクエストで過負荷にならないように、新しいリクエストごとにpingの時間間隔を増やします。
4. 次のリクエスト中に他の何かが応答した場合、pingを停止し（EMPTYを返します）、最後のリクエストの結果をサブスクライバーに返します（最後の（）演算子）
5. 回答を受け取った後、結果を取得して処理します。 フォームのオブジェクトがサブスクライブされます：

 { empty: false // -   }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リアクティブフォーム

AngularフレームワークのReactiveFormsライブラリを使用して、支払いドキュメントのリアクティブWebフォームを設計するタスクを検討してください。



ライブラリFormControl、FormGroup、FormArrayの3つの基本クラスを使用すると、フォームフィールドの宣言的な記述を使用し、フィールドの初期値を設定し、各フィールドの検証ルールを設定することができます。

 this.myForm = new FormGroup({ name: new FormControl('', Validators.required), //          surname: new FormControl('') });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

多数のフィールドを持つフォームの場合、FormBuilderサービスを使用するのが一般的です。これにより、よりコンパクトなコードを使用してフォームを作成できます。

 this.myForm = this.fb.group({ name: ['', Validators.required], surname: '' });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

支払い注文ページのテンプレートにフォームを作成した後、myFormフォームへのリンク、フィールド名と姓の名前を指定するだけで十分です。

 <form [formGroup]="myForm"> <label>Name: <input formControlName="name"> </label> <label>Surname: <input formControlName="surname"> </label> </form>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果として得られる設計により、ユーザー入力の結果として、アプリケーションのビジネスロジックに基づいて、フォームフィールドを通過する情報のフローを生成および追跡できます。 これを行うには、ValueChangesフォームの非同期オブザーバーによって生成されたイベントをサブスクライブするだけです

 this.myForm.valueChanges .subscribe(value => { … //     })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ユーザーが受信者のTINまたは組織名を入力したときに、支払い先の詳細を自動的に入力するための要件が​​ビジネスロジックで定義されているとします。 ユーザーが組織のTIN /名前に入力したデータを処理するためのコードは次のようになります。

 this.payForm.valueChanges .pipe( mergeMap(value => this.getRequisites(value)) //       ) .subscribe(requisites => { this.patchFormByRequisites(requisites) //        })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

検証

バリデータには次の2つの形式があります。

• 同期;
• 非同期。

同期バリデータに定期的に遭遇します-これらは、フィールドを操作するときに入力されたデータをチェックする関数です。 リアクティブフォームに関して：

「同期バリデーターは、制御形式を取り、エラーがある場合は真実の値を返し、それ以外の場合は偽物を返す関数です。」

 function customValidator(control) { return isInvalid(control.value) ? { code: "mistake", message: "smth wents wrong" } : null; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パスポートが以前に識別文書のタイプとして示されていた場合、ユーザーがフォームで一連の文書を示したかどうかを確認するバリデーターを実装します。

 function requredSeria(control) { const docType = control.parent.get("docType"); let error = null; if (docType && docType.value === "passport" && !control.value) { error = { code: "wrongSeria", message: "  " } } return error; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、親フォームも参照し、それを使用して別のフィールドの値を取得します。 エラーとしてtrueを返すこともできましたが、この場合は別の方法で行うことにしました。 これらのエラーメッセージは、コントロールまたはフォームのエラーフィールドでキャッチできます。 フィールドに複数のバリデータがある場合、どのバリデータが目的のエラーメッセージの表示に失敗したかを正確に指定したり、他のフィールドの検証を調整したりできます。



バリデータは次のようにフォームに追加されます。

  this.documentForm = this.fb.group({ docType: ['', Validators.required], seria: ['', requredSeria], number: '' });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すぐに使用できるいくつかのバリデーターも利用できます。 それらはすべてValidatorsクラスの静的メソッドで表されます。 バリデータを作成する方法もあります。

1つのフィールドが間違っていると、すぐにフォーム全体が無効になります。 これは、フォームに少なくとも1つの無効なフィールドがある場合に、特定の[OK]ボタンを無効にする必要があるときに使用できます。 その後、すべてが1つの条件「myform.invalid」をチェックすることになります。これは、フォームが無効な場合にtrueを返します。



非同期バリデーターには、戻り値のタイプという1つの違いがあります。 真実または偽の値は、約束またはオブザーバブルで渡す必要があります。



各コントロールまたは各フォームにはステータス（mySuperForm.status）があり、「有効」、「無効」、「無効」のいずれかです。 非同期バリデーターを使用する場合、フォームが現在どの状態にあるかが明確でない可能性があるため、「PENDING」の特別なステータスがあります。 この条件（mySuperForm.status ===“ PENDING”）のおかげで、プリローダーを表示したり、他のフォームスタイリングを実行したりできます。

自動保存

銀行用ソフトウェア（ソフトウェア）の開発には、さまざまな標準文書の操作が含まれます。 たとえば、これらはアプリケーションフォームまたはアンケートであり、多数の必須フィールドで構成される場合があります。 このような膨大なドキュメントを使用する場合、ユーザーの利便性を高めるために自動保存のサポートが必要です。そのため、インターネット接続やその他の技術的な問題がなくなっても、ユーザーが以前に入力したデータはサーバーのドラフトバージョンに残ります。



クライアント/サーバーアーキテクチャの自動保存手順の主な側面は次のとおりです。

1. 保存要求は、変更が行われた順序でサーバーによって処理される必要があります。 各変更にすぐにリクエストを送信する場合、以前のリクエストが次に来ず、新しい変更を上書きしないことを保証できません。
2. ユーザーが入力を完了するまで、サーバーに大量のリクエストを送信する必要はありません。タイミングでこれを行うことで十分です。
3. 比較的大きな遅延でいくつかの変更が行われ、最初の変更の要求がまだ返されていない場合、最初の要求が返された直後に後続の変更ごとに要求を送信する必要はありません。 無関係なデータを送信しないように、後者のみを使用できます。

最初のケースは、 concatMap演算子を使用して簡単に処理できます。 2番目のケースは、 debounceTimeを使用して問題なく解決されます。 3番目のロジックは次のように説明できます。

 const lastRequest$ = new BehaviorSubject(null); //   queue$.subscribe(lastRequest$); queue$ .pipe( debounceTime(1000), exaustMap(request$ => request$.pipe( //  ,     map(response => ({request$, response})), //       catchError(() => of(null) //   ) ) .subscribe(({request$, response}) => { if (lastRequest$.value !== request$) { queue$.next(lastRequest$.value); //     } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リクエストを送信するためにsaveQueue $に残ります。 concatMapの代わりにexaustMap演算子が存在することに注意してください。 この演算子は、内部の監視がその監視を完了する（「コンパイルされる」）まで、外部の監視可能のすべての通知を無視するために必要です。 しかし、この場合、リクエスト中に新しい通知のキューが存在する場合、最後の通知を取得して残りを破棄する必要があります。 exaustMapは、最後のものを含むすべてをドロップします。 したがって、最後の通知をBehaviorSubjectに保存し、現在の完了したリクエストが最後と異なる場合はサブスクリプションに保存します-最後のリクエストを再びキューに投入します。



また、 catchErrorステートメントを使用して実装されたクエリ中のエラーを無視することも注目に値します。 保存中にエラーが発生したことをユーザーに通知する、より複雑なエラー処理を作成できます。 しかし、その本質は、ストリームでエラーが発生した場合、エラーおよび完全な通知の場合のように、ストリームを閉じてはならないということです。

おわりに

RxJSライブラリを使用したリアクティブプログラミングテクノロジの現在の開発レベルでは、リモートバンキングシステムの負荷の高いインターフェイスとの相互作用を整理するための追加の人件費なしで、オンラインバンキングシステム用の本格的なクライアントアプリケーションを作成できます。



RxJSを初めて知った人は、デザインパターン「Observer」を実装するライブラリの「複雑さ」に直面している経験豊富な開発者であっても怖がらせることができます。 しかし、おそらくこれらの困難を克服して、RxJSは将来、異種データストリームの非同期処理の問題をリアルタイムで解決するための不可欠なツールになるでしょう。