最後の時間私たちは場所を見SMEVポータルとの統合の問題では「公共サービス。」参加者間で統一された通信プロトコルを提供することにより、SMEVは、ポータルを使用してサービスを提供したい多くの異なる部門や組織間の相互作用を大幅に促進します。



サービスは、時間の経過とともに分散されるプロセスと見なすことができます。このプロセスには、結果に影響を与えることができるいくつかのポイントがあります（ポータルを介してキャンセルし、代理店を拒否し、サービスのステータスの変更に関する情報をポータルに送信し、サービスの提供の結果も送信します）。この点で、各サービスはこのプロセスを通じて独自のライフサイクルを経て、ユーザーの要求、受信したエラー、サービスの結果などに関するデータを蓄積します。これにより、いつでもサービスを処理するためのさらなるアクションを制御および決定できるようになります。



このような処理をどのように、どのように整理できるかについて、さらに詳しく説明します。

ビジネスプロセス自動化エンジンの選択

データ処理を整理するために、ビジネスプロセスを自動化するためのライブラリとシステムが広くあります市場で：組み込みソリューションからプロセス制御のフレームワークを提供するフル機能のシステムまで。ビジネスプロセスを自動化するためのツールとしてWorkflowCoreを選択しました。この選択はいくつかの理由で行われました。まず、エンジンは.NET Coreプラットフォーム（これがメインの開発プラットフォームです）用にC＃で記述されているため、たとえばCamunda BPMとは異なり、製品の概要全体に含める方が簡単です。さらに、これは組み込みエンジンであり、ビジネスプロセスのインスタンスを管理するための十分な機会を提供します。次に、サポートされている多くのストレージオプションの中に、ソリューションで使用されているPostgreSQLもあります。第3に、エンジンは、流暢なAPIの形式でプロセスを記述するための単純な構文を提供します（ただし、JSONファイルでプロセスを記述するバリアントもあります。実際の実行の瞬間までプロセスの記述のエラーを検出することが困難になるという事実のために、使用するのは不便であるように思われました）。

ビジネスプロセス

ビジネスプロセスを説明するために一般的に受け入れられているツールの中で、BPMN表記に注意する必要があります。たとえば、BPMN表記のFizzBu​​zz問題の解決策は次のようになります。





ワークフローコアエンジンには、表記で示されるほとんどのビルディングブロックとステートメントが含まれており、前述のように、流暢なAPIまたはJSONデータを使用して特定のプロセスを記述することができます。ワークフローコアエンジンによるこのプロセスの実装は、次の形式をとることができます。

  //    .
  public class FizzBuzzWfData
  {
    public int Counter { get; set; } = 1;
    public StringBuilder Output { get; set; } = new StringBuilder();
  }

  //  .
  public class FizzBuzzWorkflow : IWorkflow<FizzBuzzWfData>
  {
    public string Id => "FizzBuzz";
    public int Version => 1;

    public void Build(IWorkflowBuilder<FizzBuzzWfData> builder)
    {
      builder
        .StartWith(context => ExecutionResult.Next())
        .While(data => data.Counter <= 100)
          .Do(a => a
            .StartWith(context => ExecutionResult.Next())
              .Output((step, data) => data.Output.Append(data.Counter))
            .If(data => data.Counter % 3 == 0 || data.Counter % 5 == 0)
              .Do(b => b
                .StartWith(context => ExecutionResult.Next())
                  .Output((step, data) => data.Output.Clear())
                .If(data => data.Counter % 3 == 0)
                  .Do(c => c
                    .StartWith(context => ExecutionResult.Next())
                      .Output((step, data) =>
                        data.Output.Append("Fizz")))
                .If(data => data.Counter % 5 == 0)
                  .Do(c => c
                    .StartWith(context => ExecutionResult.Next())
                      .Output((step, data) =>
                        data.Output.Append("Buzz"))))
            .Then(context => ExecutionResult.Next())
              .Output((step, data) =>
              {
                Console.WriteLine(data.Output.ToString());
                data.Output.Clear();
                data.Counter++;
              }));
    }
  }
}

もちろん、カーディナリティチェックに続くステップで目的の値の出力を追加することで、プロセスをより簡単に説明できます。ただし、現在の実装では、各ステップでプロセスデータの一般的な「ピギーバンク」にいくつかの変更を加えることができ、前のステップの結果を利用することもできます。この場合、プロセスデータはインスタンスFizzBuzzWfDataに格納され、その実行時に各ステップへのアクセスが提供されます。



方法Buildプロセスビルダーオブジェクトを引数として取ります。これは、ビジネスプロセスのステップを順番に記述する一連の拡張メソッドを呼び出すための開始点として機能します。次に、拡張メソッドは、引数として渡されるラムダ式の形式で現在のコードに直接アクションの説明を含めることができます。または、パラメーター化することもできます。リストに示されている最初のケースでは、単純なアルゴリズムがかなり複雑な命令のセットに変換されます。 2番目の例では、ステップのロジックは、型から継承するStep（またはAsyncStep非同期バリアントの場合）個別のクラスに隠されているため、複雑なプロセスをより簡潔な説明に収めることができます。実際には、2番目のアプローチの方が適しているようです。最初のアプローチは、単純な例または非常に単純なビジネスプロセスには十分です。



実際のプロセス記述クラスは、パラメーター化されたインターフェースを実装しIWorkflow、コントラクトを実行すると、プロセスIDとバージョン番号が含まれます。この情報のおかげで、エンジンはメモリ内にプロセスインスタンスを生成し、それらにデータを入力して、ストレージ内の状態を修正することができます。バージョン管理のサポートにより、リポジトリ内の既存のインスタンスに影響を与えるリスクなしに、新しいプロセスバリエーションを作成できます。新しいバージョンを作成するには、既存の説明のコピーを作成し、プロパティに次の番号を割り当て、Version必要に応じてこのプロセスの動作を変更するだけで十分です（識別子は変更しないでください）。



私たちのタスクのコンテキストでのビジネスプロセスの例は次のとおりです。

• – .
• – , , .
• – .
• – , .

例からわかるように、すべてのプロセスは条件付きで「循環」に細分され、その実行には定期的な繰り返しが含まれ、「線形」は特定のステートメントのコンテキストで実行されますが、プロセス内の一部の循環構造の存在を排除するものではありません。



着信要求キューをポーリングするためにソリューションで機能しているプロセスの1つの例を考えてみましょう。

public class LoadRequestWf : IWorkflow<LoadRequestWfData>
{
  public const string DefinitionId = "LoadRequest";

  public string Id => DefinitionId;
  public int Version => 1;

  public void Build(IWorkflowBuilder<LoadRequestWfData> builder)
  {
    builder
      .StartWith(then => ExecutionResult.Next())
        .While(d => !d.Quit)
          .Do(x => x
            .StartWith<LoadRequestStep>() // *
              .Output(d => d.LoadRequest_Output, s => s.Output)
            .If(d => d.LoadRequest_Output.Exception != null)
              .Do(then => then
                .StartWith(ctx => ExecutionResult.Next()) // *
                  .Output((s, d) => d.Quit = true))
            .If(d => d.LoadRequest_Output.Exception == null
                && d.LoadRequest_Output.Result.SmevReqType
                  == ReqType.Unknown)
              .Do(then => then
                .StartWith<LogInfoAboutFaultResponseStep>() // *
                  .Input((s, d) =>
                    { s.Input = d.LoadRequest_Output?.Result?.Fault; })
                  .Output((s, d) => d.Quit = false))
            .If(d => d.LoadRequest_Output.Exception == null
               && d.LoadRequest_Output.Result.SmevReqType
                 == ReqType.DataRequest)
              .Do(then => then
                .StartWith<StartWorkflowStep>() // *
                  .Input(s => s.Input, d => BuildEpguNewApplicationWfData(d))
                  .Output((s, d) => d.Quit = false))
            .If(d => d.LoadRequest_Output.Exception == null
          	    && d.LoadRequest_Output.Result.SmevReqType == ReqType.Empty)
              .Do(then => then
                .StartWith(ctx => ExecutionResult.Next()) // *
                  .Output((s, d) => d.Quit = true))
          .If(d => d.LoadRequest_Output.Exception == null
             && d.LoadRequest_Output.Result.SmevReqType
               == ReqType.CancellationRequest)
            .Do(then => then
              .StartWith<StartWorkflowStep>() // *
                .Input(s => s.Input, d => BuildCancelRequestWfData(d))
                .Output((s, d) => d.Quit = false)));
  }
}

*でマークされた行では、パラメーター化された拡張メソッドの使用を確認できます。これは、タイプパラメーターに対応するステップクラス（詳細は後で説明します）を使用するようにエンジンに指示します。拡張メソッドの助けを借りてInputとOutput、私たちは（と彼らはクラスのインスタンスで表され、実行を開始する前段階に渡された初期データを設定し、そして、それに応じて、プロセスデータを変更する機会を持っているLoadRequestWfDataアクションがステップによって実行に関連して）。そして、これはプロセスがBPMN図でどのように見えるかです：

手順

上記のように、ステップのロジックを別々のクラスに配置することは合理的です。プロセスをより簡潔にすることに加えて、一般的な操作のための再利用可能なステップを作成することができます。



ソリューションで実行されるアクションの一意性の程度に応じて、手順は一般と特定の2つのカテゴリに分けられます。前者は、任意のプロジェクトの任意のモジュールで再利用できるため、共有ソリューションライブラリに配置されます。後者は、対応する設計モジュールでの位置付けを通じて、顧客ごとに固有です。一般的な手順の例は次のとおり



です。応答に対するAck要求の送信。

• ファイルストレージへのファイルのアップロード。
• SMEVパッケージなどからのデータの抽出。

特定の手順：

• IASでオブジェクトを作成し、オペレーターがサービスを提供できるようにします。
• .
• ..

プロセスのステップを説明するにあたり、各ステップの責任は限定的であるという原則を順守しました。これにより、高レベルのビジネスプロセスロジックのフラグメントを段階的に非表示にせず、プロセスの説明で明示的に表現することが可能になりました。たとえば、アプリケーションデータにエラーが見つかった場合、アプリケーションの処理の拒否に関するメッセージをSMEVに送信する必要があります。対応する条件ブロックは、ビジネスプロセスのコード内に配置され、さまざまなクラスがエラーの事実を判断して対応する手順に対応します。



各プロセスがライフサイクルを移動するときにエンジンがステップのインスタンスを使用できるように、ステップを依存関係コンテナーに登録する必要があることに注意してください。



各ステップは、プロセスの高レベルの説明を含むコードと、アプリケーションの問題を解決するコード（サービス）の間の接続リンクです。

サービス

サービスは、次の低レベルの問題解決を表します。義務の遂行における各ステップは、原則として、1つ以上のサービスに依存します（注：このコンテキストでの「サービス」の概念は、ドメイン固有の設計（DDD）のドメインからの「アプリケーションレベルのサービス」の類似の概念に近いです）。



サービスの例は次のとおりです。

• SMEV応答キューから応答を受信するためのサービスは、対応するデータパケットをSOAP形式で準備し、それをSMEVに送信して、応答をさらに処理するのに適した形式に変換します。
• SMEVリポジトリからファイルをダウンロードするためのサービス-FTPプロトコルを使用して、ファイルリポジトリからポータルからアプリケーションに添付されたファイルの読み取りを提供します。
• サービスの提供の結果を取得するためのサービス-IASからサービスの結果に関するデータを読み取り、対応するオブジェクトを形成します。これに基づいて、別のサービスがポータルに送信するためのSOAP要求を作成します。
• サービスの結果に関連するファイルをSMEVファイルストレージにアップロードするためのサービス。

ソリューション内のサービスは、システム、それらが提供する相互作用に基づいてグループに分けられます。

• SMEVサービス。
• IASサービス。

統合ソリューションの内部インフラストラクチャを操作するためのサービス（データパケットに関する情報のログ記録、統合ソリューションのエンティティとIASオブジェクトのリンクなど）。



アーキテクチャの観点からは、サービスは最低レベルですが、問題を解決するためにユーティリティクラスに依存することもできます。したがって、たとえば、このソリューションには、さまざまなバージョンのSMEVプロトコルのSOAPデータパケットのシリアル化と逆シリアル化の問題を解決するコード層があります。一般的に、上記の説明はクラス図に要約できます。





インターフェイスIWorkflowと抽象クラスはエンジンに直接関連していStepBodyAsyncます（ただし、同期アナログStepBodyを使用することもできます）。次の図は、「ビルディングブロック」の実装を示しています。これは、ワークフロービジネスプロセスとその中で使用されるステップの説明を含む具体的なクラスです（Step）。下位レベルでは、サービスが提示されます。これは、本質的に、ソリューションのこの特定の実装にすでに固有であり、プロセスやステップとは異なり、必須ではありません。



ステップと同様に、サービスを使用するステップがコンストラクターを介した挿入によって必要なインスタンスを取得できるように、サービスを依存関係コンテナーに登録する必要があります。

ソリューションへのエンジンの埋め込み

ポータルとの統合システムの作成が開始された時点で、エンジンのバージョン2.1.2がNugetリポジトリで利用可能でした。これは、ConfigureServicesクラスメソッドの標準的な方法で依存関係コンテナに組み込まれていStartupます。

public void ConfigureServices(IServiceCollection services)
{
  // ...
  services.AddWorkflow(opts =>
    opts.UsePostgreSQL(connectionString, false, false, schemaName));
  // ...
}

（あるエンジンがサポートされているデータ・ウェアハウスのいずれかのために構成することができる他の人がそれらの間：のMySQL、MS SQL、SQLiteは、MongoDBの）。 PostgreSQLの場合、エンジンはコードファーストバリアントのエンティティフレームワークコアを使用してプロセスを処理します。したがって、空のデータベースがある場合は、移行を適用して目的のテーブル構造を取得することができます。移行の使用はオプションであり、メソッド引数を使用して制御できますUsePostgreSQL。2番目（canCreateDB）および3番目（canMigrateDB）のブール型引数を使用すると、データベースが存在しない場合にデータベースを作成して移行を適用できるかどうかをエンジンに通知できます。



エンジンの次の更新では、データモデルが変更される可能性がゼロではなく、対応する次の移行の使用により、すでに蓄積されたデータが損傷する可能性があるため、他のプロジェクトで使用されているデータベースコンポーネントのメカニズムに基づいて、このオプションを破棄し、データベース構造を独自に維持することにしました。



これで、データの保存と依存関係コンテナへのエンジンの登録の問題が解決されました。次に、エンジンの起動に移りましょう。このタスクのために、ホステッドサービスオプションが登場しました。このようなサービスを作成するための基本クラスの例を参照してください）。モジュール性を維持するために、基本となるコードがわずかに変更されました。つまり、統合ソリューション（「Onyx」と呼ばれる）を、エンジンの初期化と一部のサービス手順の実行を提供する共通の部分と、特定の各顧客に固有の部分（統合モジュール）に分割します。 ..。



各モジュールには、プロセスの説明、ビジネスロジックを実行するためのインフラストラクチャ、および開発された統合システムがプロセスの説明を認識してWorkflowCoreエンジンのインスタンスに動的にロードできるようにする統合コードが含まれています。

ビジネスプロセスの登録と開始

ビジネスプロセスとソリューションに接続されたエンジンの既製の説明ができたので、次に、どのプロセスで動作するかをエンジンに伝えます。



これは、前述のホストされたサービス内に配置できる次のコードを使用して実行されます（接続されたモジュールでプロセスの登録を開始するコードもここに配置できます）。

public async Task RunWorkflowsAsync(IWorkflowHost host,
  CancellationToken token)
{
  host.RegisterWorkflow<LoadRequestWf, LoadRequestWfData>();
  //   ...

  await host.StartAsync(token);
  token.WaitHandle.WaitOne();
  host.Stop();
}

結論

一般的に、統合ソリューションでWorkflowCoreを使用するために必要な手順について説明しました。このエンジンを使用すると、柔軟で便利な方法でビジネスプロセスを記述できます。SMEVを介して「Gosuslug」ポータルとの統合タスクを処理しているという事実を念頭に置いて、予測されるビジネスプロセスは、かなり多様なタスク（キューのポーリング、ファイルのアップロード/ダウンロード、交換プロトコルへの準拠の確認、データの受信の確認、さまざまな段階でのエラー処理など）。したがって、一見したところ明らかでない実装の瞬間が発生することを期待するのは非常に自然なことであり、サイクルの次の最後の記事に専念するのは彼らにとってです。

研究リンク

• ワークフローコア-.Netコアのビジネスプロセスエンジン
• ワークフローコアガイド
• GitHubのワークフローコア