Camunda (1): Camunda プラットフォームとモデラーによるワークフローの作成
前書き: 同社にはワークフロー エンジンの使用が必要なプロジェクトがあるため、市場にあるさまざまなワークフロー エンジンを調査し、長所と短所を比較し、最終的に Camunda ワークフロー エンジンを選択しました。私はこれまで Camunda ワークフロー エンジンについてあまり知らなかったので、Camunda ワークフロー エンジンを学習し、Springboot プロジェクトで Camunda ワークフロー エンジンの使用を統合するプロセスを記録しました。この記事ではコードを一切使わず、Camunda が公式に提供しているツールからワークフローを作成し、そのプロセスの流れを観察し、ワークフローの流れを簡単に予備理解するだけです。
1. Camunda プラットフォームとモデラー
1.1 Camunda プラットフォームとモデラーのダウンロード
Camunda Platform: 現在、公式 Web サイトでは Camunda Platform 8 SaaS の無料トライアルを提供しています。Camunda Platform 8 Self-Managed をダウンロードしてインストールする唯一の方法は docker です。Camunda Platform Run は、ローカル テストの機能を備えた Camunda Web アプリ (Cockpit、Tasklist、Admin) を含む Camunda Platform の事前にパッケージ化されたディストリビューションであるため、ここでは Camunda Platform Run をダウンロードすることを選択します。
Camunda Platform Run のダウンロード リンク: https://downloads.camunda.cloud/release/camunda-bpm/run/
Camunda Modelerのダウンロードアドレス:https://camunda.com/download/modeler/
1.2 解凍してPlatform Runを開始します
開始するには、start.bat (Windows システム) をダブルクリックし、(Linux または Mac) start.sh をクリックして開始します。
正常に起動したら、Platform Run にアクセスします:
http://localhost:8080/camunda/app/welcome/default/#!/loginCamunda のデフォルトのアカウントパスワードは、demo/demo であり、設定ファイルで設定されます。
Camunda 管理プラットフォームに入ると、Web 管理インターフェイスが提供されます。管理インターフェイスの主な機能は次のとおりです。
コックピット - プロセス プロセスとプロセス インスタンスの管理 プロセス インスタンス タスク
リスト - プロセス プロセスの特定のタスクの管理 (特定のタスクへの移動、フォーム入力の提供、プロセス インスタンスの修復など)
管理者 - ユーザー、組織グループ、承認の管理
管理モジュールに入り、後で作成するワークフローのレビューに使用されるユーザーを作成します。
各ノードの設定が完了すると、ワークフローには必須の履歴クリーンアップ属性が追加されます。
P90D: 履歴データが 90 日以内にクリーンアップされることを示します
さらに、左下隅で対応するプラットフォームのバージョンを選択して、ワークフローをデプロイします。ここで注意すべき点の 1 つは、以前はバージョンのデプロイメントに注意を払っていなかったということですが、プラットフォーム上でワークフロー タスクを実行しているときに、対応するワークフロー監査ノードのユーザーにはエージェンシー タスクがなく、フローを監査できないことがわかりました。したがって、同じプラットフォーム バージョンを自分でインストールすることを選択することをお勧めします。
1.4 導入が成功したかどうかを確認する
ここでは、以前に他のワークフローをデプロイしたことがあるため、ここでは 2 になります。これまでにワークフローがデプロイされていない場合、新しいワークフローが正常にデプロイされた後は 1 になります。
2. Camunda Platform が作成したワークフローを実行します
2.1 ワークフロープロセスの開始
デモ ユーザーは、プラットフォームのタスクリスト モジュールに入り、プロセスを開始します。
プロセスの名前を作成し、プロセスを開始するために誰が休暇を要求したかを示す変数をいくつか追加します。
2.2 対応するユーザーにアクセスしてレビューを依頼する
このプロセスの前に設定された最初の監査ノードのユーザーはデモであるため、この監査はデモ ユーザーの下で保留中であることがわかります。
デモ ユーザーが監査される前に、次のノードによって監査されるユーザーは user1 であり、監査のために user1 にログインします。すべてのノードが監査されるまで続きます