最終的にではなく、すぐに
このプロセスはイベントが到着した瞬間に開始されます。これが、顧客に今説明されるのと今夜説明されるのとの違いです。
チームがこれを自動化する理由
何も失われません
イベントは到着時に記録され、プロセスが失敗した場合は再試行されるため、一時的な停止が注文の欠落につながることはありません。
本物のイベントのみ
すべての着信呼び出しは実行前に検証されるため、アプリケーション以外のユーザーがエンドポイントを使用することはできません。
自動化できるもの
入ってくる出来事がどんなきっかけをもたらすのか。
- ソフトウェアが新しい注文を記録するときにプロセスを開始します
- プロバイダーによって確認された支払いに対応する
- サイトからフォーム送信を選択します
- 内部ツールのステータス変更に応答する
- サプライヤーまたはパートナーのシステムからイベントを取り込む
- 既製の統合がないツールを接続する
人々が尋ねる質問
- これには開発者が必要ですか?
- 通常は、アプリケーションの設定にアドレスを貼り付けるだけです。私たちはエンドポイントを準備し、それがどこに行くのかを正確に伝えます。
- その出来事が本物であることはどうやってわかりますか?
- 着信コールは署名および検証され、同じイベントの繰り返し配信が認識されるため、1 つの注文に対してプロセスが 2 回実行されることはありません。
- アプリケーションが大量のイベントを送信した場合はどうなりますか?
- イベントはキューに入れられ、一度にではなく着実に処理されるため、バーストによって下流のシステムが圧倒されるのを防ぎます。