Menu Close

Red Hat Process Automation Manager での Red Hat ビルドの Kogito の使用

Red Hat Process Automation Manager 7.12

ガイド

概要

本書では、クラウドネイティブのビジネスアプリケーションを構築するために Red Hat Process Automation Manager で Red Hat ビルドの Kogito を使い始める方法を説明します。

前書き

ビジネスデシジョンおよびプロセスの開発者は、Red Hat ビルドの Kogito を使用して、ビジネスドメインおよびツールに適合するクラウドネイティブアプリケーションを構築できます。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みにより、これらの変更は今後の複数のリリースに対して段階的に実施されます。詳細は、弊社の CTO である Chris Wright のメッセージ を参照してください。

パート I. Red Hat ビルドの Kogito マイクロサービスの使用

ビジネスデシジョンの開発者は、Red Hat ビルドの Kogito ビジネス自動化を使用して、DMN (Decision Model and Notation) モデル、DRL (Drools Rule Language) ルール、PMML (Predictive Model Markup Language) または 3 つのメソッドすべての組み合わせを使用して、デシジョンサービスを開発できます。

前提条件

  • JDK 11 以降がインストールされている。
  • Apache Maven 3.6.2 以降がインストールされている。

第1章 Red Hat Process Automation Manager での Red Hat ビルドの Kogito マイクロサービス

Red Hat ビルドの Kogito は、クラウド対応のビジネスアプリケーションを構築するクラウドネイティブのビジネス自動化テクノロジーです。名前 Kogito は、"Cogito, ergo sum" ("I think, therefore I am") で使用されるラテン語「Cogito」を由来とし、 [ˈkoː.d͡ʒi.to] (コジート) と発音します。文字 K は Kubernetes を指し、Red Hat Process Automation Manager のターゲットクラウドプラットフォームとして Red Hat OpenShift Container Platform のベースと、Red Hat ビルドの Kogito が起点となるオープンソースビジネス自動化プロジェクトに対応します。

Red Hat Process Automation Manager での Red Hat ビルドの Kogito はハイブリッドクラウド環境向けに最適化されており、ドメインおよびツールのニーズに順応します。Red Hat ビルドの Kogito マイクロサービスは主に、独自のドメイン固有のクラウドネイティブセットにデシジョンのセットを形成しやすくすることを目的とします。

重要

Red Hat Process Automation Manager 7.11 バージョンでは、Red Hat ビルドの Kogito のサポートは Decision Model and Notation(DMN)、Drools Rule Language(DRL)、Predictive Model Markup Language(PMML)などのデシジョンサービスに制限されます。このサポートは、今後のリリースで Business Process Modeling Notation (BPMN) にも展開され、向上されます。

Red Hat ビルドの Kogito を使用する場合は、クラウドネイティブアプリケーションを独立したドメイン固有のマイクロサービスのセットとしてビルドし、ビジネスバリューを実現します。ターゲットの動作の記述に使用するデシジョンは、作成するマイクロサービスの一部として実行されます。作成されるマイクロサービスは、集約オーケストレーションサービスなしで、非常に分散化されており、スケーラブルです。また、マイクロサービスが使用するランタイムは要件に合わせて最適化されています。

ビジネスルール開発者は、Red Hat Process Automation Manager で Red Hat ビルドの Kogito マイクロサービスを使用して、ビジネスドメインおよびツールに適合するクラウドネイティブアプリケーションを構築できます。

1.1. cloud-first の優先度

Red Hat ビルドの Kogito マイクロサービスは、クラウドインフラストラクチャー上で実行され、スケーリングできるように設計されています。Red Hat ビルドの Quarkus などの最新のクラウドベースのテクノロジーが含まれる Red Hat Process Automation Manager で Red Hat ビルドの Kogito マイクロサービスを使用し、Red Hat OpenShift Container Platform などのコンテナーアプリケーションプラットフォームでの起動時間および即時スケーリングを向上できます。

たとえば、Red Hat ビルドの Kogito マイクロサービスは以下のテクノロジーと互換性があります。

  • Red Hat OpenShift Container Platform は Kubernetes をベースとしており、コンテナー化されたアプリケーションをビルドし、管理するためのターゲットプラットフォームです。
  • Red Hat ビルドの Quarkus は、Red Hat ビルドの Kogito マイクロサービスを使用してアプリケーションをビルドするために使用できる Kubernetes のネイティブ Java スタックです。
  • Spring Boot は、Red Hat Process Automation Manager で Spring Framework を設定するために使用できるアプリケーションフレームワークです。

1.2. Red Hat ビルドの Quarkus および Spring Boot での Red Hat ビルドの Kogito マイクロサービス

Red Hat ビルドの Kogito マイクロサービスがサポートする主な Java フレームワークは、Red Hat ビルドの Quarkus および Spring Boot です。

Red Hat ビルドの Quarkus は、特に OpenJDK HotSpot などの Java 仮想マシン(JVM)向けの、コンテナーファーストアプローチを使用した Kubernetes ネイティブ Java フレームワークです。Red Hat ビルドの Quarkus は、Java アプリケーションとコンテナーイメージフットプリントの両方のサイズを小さくし、Java プログラミングのワークロードの一部を以前の世代から排除し、それらのイメージの実行に必要なメモリー量を減らすことで、Java 専用の Kubernetes を最適化します。

Red Hat ビルドの Kogito マイクロサービスにとっては、Red Hat ビルドの Quarkus は高度なデバッグを行う開発モードでのライブリロードなど、Kubernetes の互換性および強化された開発者機能を最適化するための推奨フレームワークです。

Spring Boot は、スタンドアロンで実稼働対応の Spring アプリケーションをビルドするための Java ベースのフレームワークです。Spring Boot では、Spring 構成すべてを設定せずに最小設定で Spring アプリケーションを開発できます。

Red Hat ビルドの Kogito マイクロサービスを使用する場合に、Spring Boot は既存の Spring Framework 環境で Red Hat Process Automation Manager を使用する必要のある開発者向けにサポートされます。

第2章 Red Hat ビルドの Kogito マイクロサービス向けの BPMN および DMN モデラー

Red Hat Process Automation Manager は、グラフィカルモデラーを使用して Red Hat ビルドの Kogito マイクロサービス向けに Business Process Model and Notation(BPMN)プロセスモデルと、Decision Model and Notation(DMN)デシジョンモデルを設計するのに使用できる拡張機能またはアプリケーションを提供します。

以下の BPMN および DMN モデラーがサポートされます。

  • VSCode 拡張機能: Visual Studio Code(VSCode)で BPMN モデルおよび DMN モデルを表示し、設計できます。VSCode 拡張機能には VSCode 1.46.0 以降が必要です。

    VSCode に直接拡張機能をインストールするには、VSCode で Extensions メニューオプションを選択して、Red Hat Business Automation Bundle 拡張を検索し、インストールします。

  • Business Modeler スタンドアロンエディター: Web アプリケーションに組み込まれている BPMN モデルおよび DMN モデルを表示して、作成できます。必要なファイルをダウンロードするには、Kogito ツールリポジトリーから NPM アーティファクトを使用するか、https://kiegroup.github.io/kogito-online/standalone/dmn/index.js で DMN スタンドアロンエディターライブラリーと https://kiegroup.github.io/kogito-online/standalone/bpmn/index.jsBPMN スタンドアロンエディターライブラリーに直接 JavaScript ファイルをダウンロードします。

2.1. Red Hat Process Automation Manager VS Code 拡張機能バンドルのインストール

Red Hat Process Automation Manager は、Red Hat Business Automation Bundle VS Code 拡張機能を提供します。これにより、Decision Model and Notation(DMN)デシジョンモデル、Business Process Model and Notation(BPMN)2.0 ビジネスプロセス、およびテストシナリオを VS Code で直接作成できます。新しいビジネスアプリケーションを開発するのに、VS Code が推奨される統合開発環境(IDE)です。Red Hat Process Automation Manager は、必要に応じて DMN サポートまたは BPMN サポートの DMN Editor および BPMN Editor VS Code 拡張機能をそれぞれ提供します。

重要

VS Code のエディターは Business Central のエディターと部分的に互換性があり、VS Code では複数の Business Central 機能はサポートされません。

前提条件

  • VS Code の最新の安定版がインストールされている。

手順

  1. VS Code IDE で Extensions メニューオプションを選択し、DMN、BPMN、およびテストシナリオファイルのサポートに対して Red Hat Business Automation Bundle を検索します。

    DMN ファイルまたは BPMN ファイルだけをサポートする場合は、DMN Editor または BPMN Editor 拡張機能をそれぞれ検索することもできます。

  2. Red Hat Business Automation Bundle 拡張機能が VS Code に表示される際に、これを選択し、Install をクリックします。
  3. VS Code エディターの動作を最適化するには、拡張機能のインストールが完了した後に、VS Code のインスタンスを再度読み込み、閉じるか、または再起動します。

VS Code 拡張機能バンドルをインストールした後、VS Code で開くか作成する any .dmn ファイル .bpmn2 ファイル、または.bpmn2 ファイルがグラフィカルモデルとして自動的に表示されます。さらに、開くまたは作成する .scesim ファイルは、ビジネスデシジョンの機能をテストするテーブルテストシナリオモデルとして自動的に表示されます。

DMN、BPMN、またはテストシナリオモデラーが DMN、BPMN、またはテストシナリオファイルの XML ソースのみを開き、エラーメッセージが表示される場合は、報告されたエラーおよびモデルファイルを確認して、すべての要素が正しく定義されていることを確認します。

注記

新しい DMN モデルまたは BPMN モデルの場合は、Web ブラウザーで dmn.new または bpmn.new を入力して、オンラインモデラーで DMN モデルまたは BPMN モデルを設計することもできます。モデルの作成が終了したら、オンラインモデラーページで Download をクリックして、VS Code の Red Hat Process Automation Manager プロジェクトに DMN または BPMN ファイルをインポートできます。

2.2. Red Hat Process Automation Manager スタンドアロンのエディターの設定

Red Hat Process Automation Manager は、自己完結型のライブラリーに分散されたスタンドアロンのエディターを提供し、エディターごとにオールインワンの JavaScript ファイルを提供します。JavaScript ファイルは、包括的な API を使用してエディターを設定および制御します。

スタンドアロンのエディターは、以下の方法でインストールできます。

  • 各 JavaScript ファイルを手動でダウンロード
  • NPM パッケージの使用

手順

  1. 以下の方法のいずれかを使用して、スタンドアロンのエディターをインストールします。

    各 JavaScript ファイルを手動でダウンロード: この方法の場合は、以下の手順に従います。

    1. JavaScript ファイルをダウンロードします。
    2. ダウンロードした Javascript ファイルをホスト型アプリケーションに追加します。
    3. 以下の <script> タグを HTML ページに追加します。

      DMN エディターの HTML ページのスクリプトタグ

      <script src="https://<YOUR_PAGE>/dmn/index.js"></script>

      BPMN エディターの HTML ページのスクリプトタグ

      <script src="https://<YOUR_PAGE>/bpmn/index.js"></script>

    NPM パッケージの使用: この方法の場合は、以下の手順に従います。

    1. NPM パッケージを package.json ファイルに追加します。

      NPM パッケージの追加

      npm install @kogito-tooling/kie-editors-standalone

    2. 各エディターライブラリーを TypeScript ファイルにインポートします。

      各エディターのインポート

      import * as DmnEditor from "@kogito-tooling/kie-editors-standalone/dist/dmn"
      import * as BpmnEditor from "@kogito-tooling/kie-editors-standalone/dist/bpmn"

  2. スタンドアロンのエディターをインストールしたら、以下の例のように提供されたエディター API を使用して必要なエディターを開き、DMN エディターを開きます。API はエディターごとに同じです。

    DMN スタンドアロンのエディターを開く

    const editor = DmnEditor.open({
      container: document.getElementById("dmn-editor-container"),
      initialContent: Promise.resolve(""),
      readOnly: false,
      origin: "",
      resources: new Map([
        [
          "MyIncludedModel.dmn",
          {
            contentType: "text",
            content: Promise.resolve("")
          }
        ]
      ])
    });

    エディター API で以下のパラメーターを使用します。

    表2.1 パラメーターの例

    パラメーター説明

    container

    エディターが追加される HTML 要素。

    initialContent

    DMN モデルのコンテンツへの Pomise。以下の例のように、このパラメーターは空にすることができます。

    • Promise.resolve("")
    • Promise.resolve("<DIAGRAM_CONTENT_DIRECTLY_HERE>")
    • fetch("MyDmnModel.dmn").then(content ⇒ content.text())

    readonly (任意)

    エディターでの変更を許可します。コンテンツの編集を許可する場合は false (デフォルト)、エディターで読み取り専用モードの場合は true に設定します。

    origin (任意)

    リポジトリーの起点。デフォルト値は window.location.origin です。

    resources (任意)

    エディターのリソースのマッピング。たとえば、このパラメーターを使用して、BPMN エディターの DMN エディターまたは作業アイテム定義に含まれるモデルを提供します。マップの各エントリーには、リソース名と、content-type (text または binary) および content (initialContent パラメーターと同様) で構成されるオブジェクトが含まれています。

    返されるオブジェクトには、エディターの操作に必要なメソッドが含まれます。

    表2.2 返されたオブジェクトメソッド

    メソッド説明

    getContent(): Promise<string>

    エディターのコンテンツを含む promise を返します。

    setContent(path: string, content: string): void

    エディターの内容を設定します。

    getPreview(): Promise<string>

    現在のダイアグラムの SVG 文字列が含まれる promise を返します。

    subscribeToContentChanges(callback: (isDirty: boolean) ⇒ void): (isDirty: boolean) ⇒ void

    エディターでコンテンツを変更し、サブスクライブ解除に使用されるのと同じコールバックを返す際に呼び出されるコールバックを設定します。

    unsubscribeToContentChanges(callback: (isDirty: boolean) ⇒ void): void

    エディターでコンテンツが変更される際に渡されたコールバックのサブスクライブを解除します。

    markAsSaved(): void

    エディターの内容が保存されることを示すエディターの状態をリセットします。また、コンテンツの変更に関連するサブスクライブされたコールバックをアクティベートします。

    undo(): void

    エディターの最後の変更を元に戻します。また、コンテンツの変更に関連するサブスクライブされたコールバックをアクティベートします。

    redo(): void

    エディターで、最後に元に戻した変更をやり直します。また、コンテンツの変更に関連するサブスクライブされたコールバックをアクティベートします。

    close(): void

    エディターを終了します。

    getElementPosition(selector: string): Promise<Rect>

    要素をキャンバスまたはビデオコンポーネント内に置いた場合に、標準のクエリーセレクターを拡張する方法を提供します。selector パラメーターは、Canvas:::MySquareVideo:::PresenterHand などの <PROVIDER>:::<SELECT> 形式に従う必要があります。このメソッドは、要素の位置を表す Rect を返します。

    envelopeApi: MessageBusClientApi<KogitoEditorEnvelopeApi>

    これは高度なエディター API です。高度なエディター API の詳細は、MessageBusClientApi および KogitoEditorEnvelopeApi を参照してください。

第3章 Red Hat ビルドの Kogito マイクロサービスの Maven プロジェクトの作成

Red Hat ビルドの Kogito マイクロサービスの開発を開始する前に、アセットおよびその他の関連リソースをビルドできる Maven プロジェクトを作成する必要があります。

手順

  1. コマンドターミナルで、新しプロジェクトを保存するローカルディレクトリーに移動します。
  2. 以下のコマンドを入力して、定義したディレクトリーにプロジェクトを生成します。

    Red Hat ビルドの Quarkus の場合

    $ mvn io.quarkus:quarkus-maven-plugin:create \
        -DprojectGroupId=org.acme -DprojectArtifactId=sample-kogito \
        -DprojectVersion=1.0.0-SNAPSHOT -Dextensions=kogito-quarkus

    Spring Boot の場合

    $ mvn archetype:generate \
        -DarchetypeGroupId=org.kie.kogito \
        -DarchetypeArtifactId=kogito-spring-boot-archetype \
        -DgroupId=org.acme -DartifactId=sample-kogito \
        -DarchetypeVersion=1.11.0.Final \
        -Dversion=1.0-SNAPSHOT

    このコマンドは、sample-kogito の Maven プロジェクトを生成し、ビジネスアプリケーション自動化用のアプリケーション準備に必要な依存関係および設定の拡張をインポートします。

    プロジェクトの PMML 実行を有効にする場合は、Red Hat ビルドの Kogito マイクロサービスが含まれる Maven プロジェクトの pom.xml ファイルに以下の依存関係を追加します。

    PMML 実行を有効にするための依存関係

    <dependency>
      <groupId>org.kie.kogito</groupId>
      <artifactId>kogito-pmml</artifactId>
    </dependency>
    <dependency>
      <groupId>org.jpmml</groupId>
      <artifactId>pmml-model</artifactId>
    </dependency>

    Red Hat ビルドの Quarkus でアプリケーションを OpenShift で実行する予定の場合には、以下の例のように liveness および readiness プローブの smallrye-health 拡張もインポートする必要があります。

    OpenShift 上の Red Hat ビルドの Quarkus アプリケーションの SmallRye Health 拡張

    $ mvn quarkus:add-extension -Dextensions="smallrye-health"

    このコマンドにより、Red Hat ビルドの Quarkus の Red Hat Process Automation Manager プロジェクトの pom.xml ファイルに、以下の依存関係を生成します。

    OpenShift 上の Red Hat ビルドの Quarkus アプリケーションの SmallRye Health 依存関係

    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-smallrye-health</artifactId>
    </dependency>

  3. VSCode IDE でプロジェクトを開くか、インポートしてコンテンツを表示します。

3.1. Red Hat ビルドの Kogito マイクロサービス用のカスタム Spring Boot プロジェクトの作成

Red Hat ビルドの Kogito マイクロサービスの Spring Boot アーキタイプを使用して、カスタム Maven プロジェクトを作成できます。Spring Boot archetype を使用すると、Spring Boot スターターまたはアドオンをプロジェクトに追加できます。

Spring Boot スターターは、プロジェクト向けのオールインワン記述子で、Red Hat ビルドの Kogito が提供するビジネス自動化エンジンが必要です。Spring Boot スターターには、意思決定、ルール、プロセス、予測が含まれます。

プロジェクトにすべてのアセットが含まれ、Red Hat ビルドの Kogito を初めて使用する場合には、kogito -spring-boot-starter スターターを使用できます。より詳細なアプローチには、kogito -decisions-spring-boot-starter などの特定のスターターを使用するか、スターターの組み合わせを使用します。

Red Hat ビルドの Kogito は、以下の Spring Boot スターターをサポートします。

Spring Boot スターターのプロセス

Spring Boot プロジェクトに BPMN サポートを提供するスターターです。以下は、プロセス Spring ブートスターターをプロジェクトに追加する例です。

<dependencies>
  <dependency>
    <groupId>org.kie.kogito</groupId>
    <artifactId>kogito-processes-spring-boot-starter</artifactId>
  </dependency>
</dependencies>
Spring Boot スターターの決定

Spring Boot プロジェクトに DMN サポートを提供するスターターです。以下は、デシジョン Spring ブートスターターをプロジェクトに追加する例です。

<dependencies>
  <dependency>
    <groupId>org.kie.kogito</groupId>
    <artifactId>kogito-decisions-spring-boot-starter</artifactId>
  </dependency>
</dependencies>
Spring Boot スターターの予測

Spring Boot プロジェクトに PMML サポートを提供するスターターです。以下は、予測 Spring ブートスターターをプロジェクトに追加する例です。

<dependencies>
  <dependency>
    <groupId>org.kie.kogito</groupId>
    <artifactId>kogito-predictions-spring-boot-starter</artifactId>
  </dependency>
</dependencies>
ルール Spring Boot スターター

Spring Boot プロジェクトに DRL サポートを提供するスターターです。以下は、ルール Spring ブートスターターをプロジェクトに追加する例です。

<dependencies>
  <dependency>
    <groupId>org.kie.kogito</groupId>
    <artifactId>kogito-rules-spring-boot-starter</artifactId>
  </dependency>
</dependencies>

手順

  1. コマンドターミナルで、新しプロジェクトを保存するローカルディレクトリーに移動します。
  2. 以下のいずれかのコマンドを実行して、starters または addons プロパティーを使用してプロジェクトを生成します。

    • starters プロパティーを使用して プロジェクト を生成するには、以下のコマンドを入力します。

      $ mvn archetype:generate \
          -DarchetypeGroupId=org.kie.kogito \
          -DarchetypeArtifactId=kogito-springboot-archetype \
          -DgroupId=org.acme -DartifactId=sample-kogito \
          -DarchetypeVersion=1.11.0.Final \
          -Dversion=1.0-SNAPSHOT
          -Dstarters=processes

      新規プロジェクトには、プロセスマイクロサービスの実行に必要な依存関係が含まれます。starters =processes,rules などのコンマ区切りリストを使用して、複数の Spring Boot スターター を組み合わせることができます。

    • addons プロパティーを使用して Prometheus モニタリングが含まれるプロジェクトを生成するには、以下のコマンドを入力します。

      $ mvn archetype:generate \
          -DarchetypeGroupId=org.kie.kogito \
          -DarchetypeArtifactId=kogito-springboot-archetype \
          -DgroupId=org.acme -DartifactId=sample-kogito \
          -DarchetypeVersion=1.11.0.Final \
          -Dversion=1.0-SNAPSHOT
          -Dstarters=processes
          -Daddons=monitoring-prometheus,persistence-infinispan
      注記

      アドオンをプロパティーに渡すと、アドオン名には kogito-addons-springboot プレフィックスは必要ありません。また、アドオンと スターター プロパティーを組み合わせてプロジェクトをカスタマイズすることもできます。

  3. IDE でプロジェクトを開くか、インポートしてコンテンツを表示します。

第4章 Red Hat ビルドの Kogito マイクロサービスのあるアプリケーションの例

Red Hat ビルドの Kogito マイクロサービスには、rhpam -7.12.0-kogito-and-optaplanner-quickstarts.zip ファイルにサンプルアプリケーションが含まれます。これらのサンプルアプリケーションには、独自のアプリケーションの開発に役立つ Red Hat ビルドの Quarkus または Spring Boot のさまざまなタイプのサービスが含まれます。サービスは、1 つ以上の Business Process Model and Notation(BPMN)プロセスモデル、Decision Model and Notation(DMN)デシジョンモデル、Drools Rule Language(DRL)ルールユニット、Predictive Model Markup Language(PMML)モデル、または Java クラスを使用してサービスロジックを定義します。

アプリケーションの例および使用方法については、関連するアプリケーションフォルダーの README ファイルを参照してください。

注記

ローカル環境でサンプルを実行する場合は、関連するアプリケーションフォルダーの README ファイルに記載されている要件に環境が対応していることを確認します。また、これには Red Hat ビルドの Quarkus、Spring Boot、および docker-compose の設定に必要なネットワークポートを利用できるようにする必要がある場合があります。

以下は、Red Hat ビルドの Kogito マイクロサービスで提供される例の一部です。

デシジョンサービス
  • dmn-quarkus-example および dmn-springboot-example: DMN を使用するデシジョンサービス (Red Hat ビルドの Quarkus または Spring Boot) を使用して、交通違反をもとに運転手の罰則や免許停止を判断します。
  • rules-quarkus-helloworld: DRL ルールユニットが 1 つある、Red Hat ビルドの Quarkus 上の Hello World のデシジョンサービス。
  • RuleUnit-quarkus-example および ruleunit-springboot-example: ルールユニットで DRL を使用して、ローン申し込みを検証するデシジョンサービス (Red Hat ビルドの Quarkus または Spring Boot) を使用し、REST 操作を公開してアプリケーションの状態を表示します。
  • dmn-pmml-quarkus-example および dmn-pmml-springboot-example: DMN および PMML を使用するデシジョンサービス (Red Hat ビルドの Quarkus または Spring Boot) を使用して、交通違反をもとに運転手の罰則や免許停止を判断します。
  • dmn-drools-quarkus-metrics および dmn-drools-springboot-metrics: Red Hat ビルドの Kogito のランタイムメトリクス監視機能を有効化および消費するデシジョンサービス (Red Hat ビルドの Quarkus または Spring Boot 上)。
  • PMML-quarkus-example およびpmml-springboot-example: PMML を使用するデシジョンサービス (Red Hat ビルドの Quarkus または Spring Boot 上)。
プロセスサービス
  • process-scripts-quarkus および process-scripts-springboot: プロセス内でスクリプトを呼び出すプロセスサービス(Red Hat ビルドの Quarkus および Spring Boot の場合)
  • process-service-calls-quarkus and process-service-calls-springboot: プロセス内でサービス呼び出しを呼び出すプロセスサービス(Red Hat ビルドの Quarkus および Spring Boot の場合)
  • process-rest-service-call -quarkus and process-rest-service-call-springboot: サービスタスクを使用してプロセスサービス(Red Hat ビルドの Quarkus および Spring Boot)を呼び出します。
  • process-rest-workitem-quarkus: Red Hat ビルドの Quarkus 上のプロセスサービス。これは、ent User プロセス内で REST ワークアイテムを使用して REST 呼び出しを呼び出します。
  • process-rest-workitem-multi-quarkus: プロセス内で連続した 2 つの REST ワークアイテム呼び出しを呼び出す Red Hat ビルドの Quarkus のプロセスサービス。
デシジョンサービスを使用するプロセスサービス
  • process-decisions-quarkus and process-decisions-springboot: 埋め込みメソッドを使用してデシジョンサービスと統合するプロセスサービス(Red Hat ビルドの Quarkus および Spring Boot 上)。埋め込みメソッドでは、ビジネスルールタスクは通信に使用され、デシジョンは DMN および DRL で定義されます。
  • process-decisions-rest -quarkus and process-decisions-rest-springboot: リモートメソッドを使用してデシジョンサービスと統合するプロセスサービス(Red Hat ビルドの Quarkus および Spring Boot 上)。リモートメソッドでは、REST エンドポイントは通信に使用され、決定は DMN および DRL で定義されます。
Apache Kafka を使用するプロセスサービス
  • process-kafka-quickstart-quarkus and process-kafka-quickstart-springboot: Apache Kafka を使用して異なるルールを含むトラッカープロセスを管理するプロセスサービス(Red Hat ビルドの Quarkus および Spring Boot の場合)。
  • process-kafka- multi-quarkus および process-kafka-multi-springboot: Apache Kafka を使用して異なるトピックにメッセージを送信します。

詳細は、『 BPMN モデルを使用したビジネスプロセスの作成 』、DMN モデルを 使用したデシジョンサービスの作成、DRL ルールを 使用したデシジョンサービスの作成、PMML モデルを使用したデシジョンサービスの設計 を参照してください。

第5章 DMN を使用した Red Hat ビルドの Kogito マイクロサービスのアプリケーションロジックの設計

プロジェクトを作成したら、プロジェクトの src/main/resources ディレクトリーに、Decision Model and Notation (DMN) デシジョンモデルと Drools Rule Language (DRL) ビジネスルールを作成またはインポートできます。また、Java サービスとして動作するプロジェクトの src/main/java ディレクトリーに Java クラスを含めるか、デシジョンから呼び出す実装を指定することもできます。

この手順の例では、基本的な Red Hat ビルドの Kogito マイクロサービスが REST エンドポイント /persons を提供します。このエンドポイントは、PersonDecisions.dmn DMN モデルのサンプルをもとに自動生成され、処理されたデータをベースに意思決定を行います。

ビジネスデシジョンには、Red Hat Process Automation Manager サービスのデシジョンロジックが含まれます。DMN モデルや DRL ルールなど、ビジネスルールやデシジョンをさまざまな方法で定義できます。この手順の例では、DMN モデルを使用します。

前提条件

手順

  1. Red Hat Process Automation Manager サービス用に生成した Maven プロジェクトで src/main/java/org/acme フォルダーに移動し、以下の Person.java ファイルを追加します。

    person Java オブジェクトの例

    package org.acme;
    
    import java.io.Serializable;
    
    public class Person {
    
    	private String name;
    	private int age;
    	private boolean adult;
    
    	public String getName() {
    		return name;
    	}
    
    	public void setName(String name) {
    		this.name = name;
    	}
    
    	public int getAge() {
    		return age;
    	}
    
    	public void setAge(int age) {
    		this.age = age;
    	}
    
    	public boolean isAdult() {
    		return adult;
    	}
    
    	public void setAdult(boolean adult) {
    		this.adult = adult;
    	}
    
    	@Override
    	public String toString() {
    		return "Person [name=" + name + ", age=" + age + ", adult=" + adult + "]";
    	}
    
    }

    この例では、Java オブジェクトの名前、年齢、成人ステータスを設定して取得します。

  2. src/main/resources フォルダーに移動し、以下の PersonDecisions.dmn DMN デシジョンモデルを追加します。

    図5.1 PersonDecisions のDMN 意思決定要件ダイアグラム (DRD) 例

    Image of PersonDecisions decision diagram

    図5.2 isAdult デシジョン の DMN ボックス式の例

    Image of PersonDecisions decision table

    図5.3 DMN データ型の例

    Image of PersonDecisions data types

    この DMN モデルは、基本的な DMN 入力ノードと、カスタムの構造化データ型で DMN デシジョンテーブルが定義したデシジョンノードで構成されます。

    VSCode では、Red Hat Business Automation Bundle VSCode 拡張機能を追加して、DMN モデラーで意思決定要件ダイアグラム (DRD)、ボックス式、およびデータタイプを設計できます。

    この DMN モデルの例を迅速に作成するには、以下の PersonDecisions.dmn ファイルの内容をコピーします。

    DMN ファイルの例

    <dmn:definitions xmlns:dmn="http://www.omg.org/spec/DMN/20180521/MODEL/" xmlns="https://kiegroup.org/dmn/_52CEF9FD-9943-4A89-96D5-6F66810CA4C1" xmlns:di="http://www.omg.org/spec/DMN/20180521/DI/" xmlns:kie="http://www.drools.org/kie/dmn/1.2" xmlns:dmndi="http://www.omg.org/spec/DMN/20180521/DMNDI/" xmlns:dc="http://www.omg.org/spec/DMN/20180521/DC/" xmlns:feel="http://www.omg.org/spec/DMN/20180521/FEEL/" id="_84B432F5-87E7-43B1-9101-1BAFE3D18FC5" name="PersonDecisions" typeLanguage="http://www.omg.org/spec/DMN/20180521/FEEL/" namespace="https://kiegroup.org/dmn/_52CEF9FD-9943-4A89-96D5-6F66810CA4C1">
      <dmn:extensionElements/>
      <dmn:itemDefinition id="_DEF2C3A7-F3A9-4ABA-8D0A-C823E4EB43AB" name="tPerson" isCollection="false">
        <dmn:itemComponent id="_DB46DB27-0752-433F-ABE3-FC9E3BDECC97" name="Age" isCollection="false">
          <dmn:typeRef>number</dmn:typeRef>
        </dmn:itemComponent>
        <dmn:itemComponent id="_8C6D865F-E9C8-43B0-AB4D-3F2075A4ECA6" name="Name" isCollection="false">
          <dmn:typeRef>string</dmn:typeRef>
        </dmn:itemComponent>
        <dmn:itemComponent id="_9033704B-4E1C-42D3-AC5E-0D94107303A1" name="Adult" isCollection="false">
          <dmn:typeRef>boolean</dmn:typeRef>
        </dmn:itemComponent>
      </dmn:itemDefinition>
      <dmn:inputData id="_F9685B74-0C69-4982-B3B6-B04A14D79EDB" name="Person">
        <dmn:extensionElements/>
        <dmn:variable id="_0E345A3C-BB1F-4FB2-B00F-C5691FD1D36C" name="Person" typeRef="tPerson"/>
      </dmn:inputData>
      <dmn:decision id="_0D2BD7A9-ACA1-49BE-97AD-19699E0C9852" name="isAdult">
        <dmn:extensionElements/>
        <dmn:variable id="_54CD509F-452F-40E5-941C-AFB2667D4D45" name="isAdult" typeRef="boolean"/>
        <dmn:informationRequirement id="_2F819B03-36B7-4DEB-AED6-2B46AE3ADB75">
          <dmn:requiredInput href="#_F9685B74-0C69-4982-B3B6-B04A14D79EDB"/>
        </dmn:informationRequirement>
        <dmn:decisionTable id="_58370567-05DE-4EC0-AC2D-A23803C1EAAE" hitPolicy="UNIQUE" preferredOrientation="Rule-as-Row">
          <dmn:input id="_ADEF36CD-286A-454A-ABD8-9CF96014021B">
            <dmn:inputExpression id="_4930C2E5-7401-46DD-8329-EAC523BFA492" typeRef="number">
              <dmn:text>Person.Age</dmn:text>
            </dmn:inputExpression>
          </dmn:input>
          <dmn:output id="_9867E9A3-CBF6-4D66-9804-D2206F6B4F86" typeRef="boolean"/>
          <dmn:rule id="_59D6BFF0-35B4-4B7E-8D7B-E31CB0DB8242">
            <dmn:inputEntry id="_7DC55D63-234F-497B-A12A-93DA358C0136">
              <dmn:text>&gt; 18</dmn:text>
            </dmn:inputEntry>
            <dmn:outputEntry id="_B3BB5B97-05B9-464A-AB39-58A33A9C7C00">
              <dmn:text>true</dmn:text>
            </dmn:outputEntry>
          </dmn:rule>
          <dmn:rule id="_8FCD63FE-8AD8-4F56-AD12-923E87AFD1B1">
            <dmn:inputEntry id="_B4EF7F13-E486-46CB-B14E-1D21647258D9">
              <dmn:text>&lt;= 18</dmn:text>
            </dmn:inputEntry>
            <dmn:outputEntry id="_F3A9EC8E-A96B-42A0-BF87-9FB1F2FDB15A">
              <dmn:text>false</dmn:text>
            </dmn:outputEntry>
          </dmn:rule>
        </dmn:decisionTable>
      </dmn:decision>
      <dmndi:DMNDI>
        <dmndi:DMNDiagram>
          <di:extension>
            <kie:ComponentsWidthsExtension>
              <kie:ComponentWidths dmnElementRef="_58370567-05DE-4EC0-AC2D-A23803C1EAAE">
                <kie:width>50</kie:width>
                <kie:width>100</kie:width>
                <kie:width>100</kie:width>
                <kie:width>100</kie:width>
              </kie:ComponentWidths>
            </kie:ComponentsWidthsExtension>
          </di:extension>
          <dmndi:DMNShape id="dmnshape-_F9685B74-0C69-4982-B3B6-B04A14D79EDB" dmnElementRef="_F9685B74-0C69-4982-B3B6-B04A14D79EDB" isCollapsed="false">
            <dmndi:DMNStyle>
              <dmndi:FillColor red="255" green="255" blue="255"/>
              <dmndi:StrokeColor red="0" green="0" blue="0"/>
              <dmndi:FontColor red="0" green="0" blue="0"/>
            </dmndi:DMNStyle>
            <dc:Bounds x="404" y="464" width="100" height="50"/>
            <dmndi:DMNLabel/>
          </dmndi:DMNShape>
          <dmndi:DMNShape id="dmnshape-_0D2BD7A9-ACA1-49BE-97AD-19699E0C9852" dmnElementRef="_0D2BD7A9-ACA1-49BE-97AD-19699E0C9852" isCollapsed="false">
            <dmndi:DMNStyle>
              <dmndi:FillColor red="255" green="255" blue="255"/>
              <dmndi:StrokeColor red="0" green="0" blue="0"/>
              <dmndi:FontColor red="0" green="0" blue="0"/>
            </dmndi:DMNStyle>
            <dc:Bounds x="404" y="311" width="100" height="50"/>
            <dmndi:DMNLabel/>
          </dmndi:DMNShape>
          <dmndi:DMNEdge id="dmnedge-_2F819B03-36B7-4DEB-AED6-2B46AE3ADB75" dmnElementRef="_2F819B03-36B7-4DEB-AED6-2B46AE3ADB75">
            <di:waypoint x="504" y="489"/>
            <di:waypoint x="404" y="336"/>
          </dmndi:DMNEdge>
        </dmndi:DMNDiagram>
      </dmndi:DMNDI>
    </dmn:definitions>

    DMN モデラーを使用して VSCode でこの DMN モデルのサンプルを作成するには、以下の手順に従います。

    1. 空の PersonDecisions.dmn ファイルを開き、DMN モデラーの右上隅にある Properties アイコンをクリックし、DMN モデル NamePersonDecisions に設定されていることを確認します。
    2. 左側のパレットで DMN Input Data を選択し、ノードをキャンバスにドラッグしてから、ノードをダブルクリックして Person という名前を付けます。
    3. 左側のパレットで DMN Decision ノードをキャンバスにドラッグし、ノードをダブルクリックして 名前を isAdult に入力ノードからリンクします。
    4. ノードオプションを表示するデシジョンノードを選択して Edit アイコンをクリックし、DMN ボックス式エディターを開き、ノードのデシジョンロジックを定義します。
    5. undefined expression フィールドをクリックし、Decision Table を選択します。
    6. デシジョンテーブルの左上隅をクリックして、ヒットポリシーを Unique に設定します。
    7. タイプが number の入力ソース Person.Age で、年齢制限を、タイプが boolean の出力ターゲット isAdult で成人ステータスを判断できるように、入出力コラムを設定します。

      図5.4 デシジョンが isAdult の DMN デシジョンテーブルの例

      Image of PersonDecisions decision table
    8. 右上のタブで Data Types タブを選択して、以下の tPerson 構造のデータ型とネスト化データタイプを追加します。

      図5.5 DMN データ型の例

      Image of PersonDecisions data types
    9. データタイプを定義したら、Editor タブを選択して、DMN モデラーキャンバスに戻ります。
    10. Person 入力ノードを選択し、Properties アイコンをクリックし、Information item の下にある Data typetPerson に設定します。
    11. isAdult デシジョンノードを 選択し、Properties アイコンをクリックして、Information 項目Data type がまだ boolean に設定されていることを確認します。デシジョンテーブルの作成時に、このデータ型を設定してください。
    12. DMN デシジョンサービスを保存します。

5.1. 別のデシジョンサービスとしての DRL ルールユニットの使用

また、ルールユニットとして実装した Drools Rule Language (DRL) ファイルを使用して、Decision Model and Notation (DMN) を使用する代わりに、このサンプルデシジョンサービスを定義することもできます。

DRL ルールユニットは、ルールのモジュールおよび、実行ユニットです。ルールユニットは、ルール実行のファクトタイプの宣言を使用して、一連のルールを収集します。また、ルールユニットは、各ルールグループに固有の namespace としても機能します。1 つのルールベースには、複数のルールユニットを含めることができます。通常、ユニットだけで自己完結できるように、ユニットの全ルールはユニット宣言と同じファイルに保存します。ルールユニットの詳細は、『 DRL ルールを使用したデシジョンサービスの作成』 を参照してください。

前提条件

手順

  1. DMN ファイルを使用する代わりに、サンプルプロジェクトの src/main/resources ディレクトリーに、以下の PersonRules.drl ファイルを追加します。

    PersonRules DRL ファイルの例

    package org.acme
    unit PersonRules;
    
    import org.acme.Person;
    
    rule isAdult
    	when
    		$person: /person[ age > 18 ]
    	then
        modify($person) {
        	setAdult(true)
        };
    	end
    
    	query persons
    		$p : /person[ adult ]
    		end

    このルールの例では、18 歳以上を成人として分類しているかどうかを判断します。また、ルールファイルは、ルールがルールユニット PersonRules に属することを宣言します。プロジェクトをビルドすると、ルールユニットが生成され、DRL ファイルに関連付けられます。

    ルールは OOPath 表記を使用して条件も定義します。OOPath は、Xpath のオブジェクト指向の構文拡張で、コレクションおよびフィルター制約を処理しながら、関連要素間を移動します。

    以下の例のように、従来のルールパターン構文を使用して、より明示的な形式で同じルール条件を再書き込みすることもできます。

    従来の表記を使用した PersonRules DRL ファイルの例

    package org.acme
    unit PersonRules;
    
    import org.acme.Person;
    
    rule isAdult
    	when
    		$person: Person(age > 18) from person
    	then
        modify($person) {
        	setAdult(true)
        };
    	end
    
    	query persons
    		$p : /person[ adult ]
    		end

第6章 BPMN モデラーでの BPMN モデルの作成および編集

VS Code で BPMN モデラーを使用して BPMN プロセスモデルを設計し、完全かつ機能的な BPMN モデルのプロセスロジックを定義できます。

Red Hat ビルドの Kogito は、現在 Business Process Model and Notation 2.0 仕様 のサブセットをサポートします。BPMN モデラーはキャンバスパレットに多くの BPMN コンポーネントを表示しますが、プロセスエンジンはコンポーネントでサポートされるサブセットのみを実行します。プロセスエンジンでサポートされていない BPMN モデラーパレットの BPMN コンポーネントを使用する場合には、Red Hat ビルドの Kogito プロジェクトのコンパイルや実行が失敗する可能性があります。

Red Hat Process Automation Manager での BPMN2 サポートの詳細は、「 BPMN モデルを使用したビジネスプロセスの作成 」を参照してください。

前提条件

手順

  1. VS Code IDE で、プロジェクトの関連するフォルダー(通常は src/main/resources )に BPMN ファイルを作成またはインポートします。

    注記

    新しい BPMN ファイルの場合は、Web ブラウザーに bpmn.new を入力し、オンライン BPMN モデラーでビジネスプロセスを設計することもできます。プロセスモデルの作成が終了したら、オンラインモデラーページで Download をクリックして、BPMN ファイルを Red Hat ビルドの Kogito プロジェクトにインポートできます。

  2. 新規またはインポートされた BPMN ファイルを開き、BPMN モデラーのプロセスダイアグラムを表示します。

    プロセスダイアグラムが BPMN モデラーで開かない場合は、Red Hat Business Automation Bundle VS Code 拡張機能をインストールして有効にしている。

    BPMN モデラーが BPMN ファイルの XML ソースのみを開き、エラーメッセージを表示する場合は、報告されたエラーと BPMN モデルファイルを確認し、全 BPMN 要素が正しく定義されていることを確認します。

  3. BPMN モデラーキャンバスの背景を選択し、モデラーの右上隅にある Properties をクリックして、以下の表で説明されているように BPMN ファイルの情報を追加または検証します。

    表6.1 一般的なプロセスプロパティー

    ラベル説明

    名前

    プロセスの名前を入力します。

    ドキュメント

    プロセスを記述します。このフィールドのテキストはプロセスドキュメントに含まれます (該当する場合)。

    ID

    このプロセスの識別子 (orderItems など) を入力します。

    パッケージ

    このプロセスのパッケージの場所を入力します(例: org.acme )。

    ProcessType

    プロセスがパブリックであるかプライベートであるかを指定します (該当しない場合は null を指定)。

    バージョン

    プロセスのアーティファクトバージョンを入力します。

    アドホック

    このプロセスが他のアドホックの自動起動フラグメントを使用し、厳密な開始イベントと終了イベントを必要としない柔軟なプロセスである場合は、このオプションを選択します。

    Process Instance Description

    プロセス目的の説明を入力します。

    インポート

    クリックして Imports ウィンドウを開き、プロセスに必要なデータオブジェクトクラスを追加します。

    実行可能

    このオプションを選択して、プロジェクトの一部としてプロセスを実行可能にします。

    SLA 期日

    サービスレベルアグリーメント(SLA)の有効期限が切れる日付を入力します。

    プロセス変数

    プロセスのプロセス変数を追加します。プロセス変数は、特定のプロセスインスタンス内で表示されます。プロセス変数はプロセスの作成時に初期化され、プロセスの完了時に破棄されます。変数 タグ により、変数の動作をより細かく制御できます 変数の詳細は、「 BPMN モデルを使用したビジネスプロセスの作成 」を参照してください。

    Metadata Attributes

    メタデータ属性が存在する場合に何らかのアクションを実装するリスナーなど、カスタムイベントリスナーに使用するカスタムメタデータ属性の名前と値を追加します。

    このフィールドを使用して、プロセスへのロールベースのアクセスを設定することもできます。ロールベースのアクセスを設定するには、Name 属性を securityRoles に設定し、属性の値を employees,managers などのプロセスに定義された関連グループに設定します。

    グローバル変数

    Red Hat ビルドの Kogito ではサポートされません。グローバル変数は、プロジェクトのすべてのプロセスインスタンスおよびアセットに表示され、Red Hat Process Automation Manager の BPMN モデラーのディストリビューションにのみ適用されます。

  4. 左側のパレットから BPMN ノードの 1 つをクリックしてドラッグし、新規またはインポートした BPMN プロセスモデルにコンポーネントを追加し始めます。

    図6.1 BPMN コンポーネントの追加

    bpmn drag nodes

    BPMN モデラーはキャンバスパレットに BPMN コンポーネントを多数表示しますが、Red Hat Process Automation Manager のプロセスエンジンは、現在以下の BPMN コンポーネントのみをサポートします。

    • 開始イベント

      • Start
      • 開始シグナル
      • 開始メッセージ
    • 中間イベント

      • 中間シグナル (連結および境界)
      • 中間メッセージ (連結、境界、およびスロー)
    • 終了イベント

      • 終了
      • 終了エラー
      • 終了終端
      • 終了メッセージ
    • タスク

      • ビジネスルール
      • User
      • サービス
      • スクリプト
    • サブプロセス

      • 組み込み
      • 再利用可能
    • ゲートウェイ

      • 並行
      • Event
      • 排他的
      • 含む
  5. BPMN モデラーキャンバスで、追加する新しい BPMN コンポーネントごとに、新規ノードを選択し、BPMN モデラーの右上にある Properties をクリックしてノード ID と動作を定義します。

    BPMN コンポーネントプロパティーの詳細は、「BPMN モデルを使用したビジネスプロセスの作成 」を参照してください。

    この例では、Decision Model and Notation(DMN)デシジョンモデルをベースにしたビジネスルールタスクを最初のアクティビティーノードとして使用します。

    この例では、Red Hat Process Automation Manager プロジェクトに以下のアセットがあることを前提としています。

    • A Java object org.acme.Person
    • namespace https://kiegroup.org/dmn/_52CEF9FD-9943-4A89-96D5-6F66810CA4C1の DMN モデル PersonDecisions.dmn
  6. 左側のパレットで ActivitiesBusiness Rule を選択し、タスクをキャンバスにドラッグし、開始イベントからリンクします。
  7. ビジネスルールタスクを選択し、以下のプロパティーを定義します。

    • General: ルールタスクの評価 担当者に名前を付けます
    • 実装/ 実行: 以下の値を設定します。

      • ルール言語:DMN
      • Namespace: https://kiegroup.org/dmn/_52CEF9FD-9943-4A89-96D5-6F66810CA4C1
      • ディシジョンネーム:isAdult
      • DMN モデル名:PersonDecisions
    • Data Assignments: 以下の割り当てを追加します。

      • Data Input: org.acme.Person タイプとソース person を持つ Person という名前のデータ入力を追加します。
      • Data Output: isAdult という名前のデータ出力を、タイプが Boolean で、ソース isAdult と共に追加します
  8. 左側のパレットで GatewaysExclusive を選択し、ゲートウェイをキャンバスにドラッグし、ルールタスクからリンクします。
  9. 左側のパレットで ActivitiesUser を選択し、ユーザータスクをキャンバスにドラッグし、排他ゲートウェイからリンクします。
  10. ユーザータスクを選択し、以下のプロパティーを定義します。

    • General: 子のユーザータスク の特殊な処理に名前を付けます
    • implementation/Execution: タスク名を ChildrenHandling に設定し、名前 person、org. acme.Person、およびソース 担当者 を使用してデータ入力を追加します。
  11. 左側のパレットで End EventsEnd を選択し、2 つの終了イベントをキャンバスにドラッグし、ユーザータスクと、排他ゲートウェイから別の終了イベントにリンクします。
  12. 排他ゲートウェイを終了イベントに接続し、Implementation/Execution プロパティーの Condition ExpressionJava に設定し、条件の return isAdult == true; を入力します。
  13. 排他ゲートウェイをユーザータスクと Implementation/Execution プロパティーに接続するコネクターを選択し、Condition ExpressionJava に設定し、条件を入力して isAdult == false; を返します
  14. BPMN プロセスファイルを保存します。

    以下は、この例の申請者の年齢評価のための BPMN モデルです。

    図6.2 persons.bpmn2 BPMN プロセスの例

    Image of `persons.bpmn2` process diagram

    BPMN プロセスの残りのコンポーネントおよびプロパティーを追加または変更したり、別のサンプルを作成したりできます。

    以下の追加の BPMN モデルは、同じサンプルアプリケーションの一部として persons.bpmn2 プロセスで使用されます。

    図6.3 orders.bpmn2 プロセスの例

    Image of `orders.bpmn2` example process

    図6.4 サブプロセスとして呼び出される orderItems.bpmn2 プロセスの例

    Image of `orderItems.bpmn` example process

    以下の例は、より複雑なユースケースを示しています。これは、ローンの承認を決定するための、別の住宅ローン申請からの BPMN モデル例です。

    図6.5 住宅ローン申請のビジネスプロセスの例

    Image of mortgage application business process.

    その他の例および手順は、GitHub の kogito-examples リポジトリーを参照してください。

第7章 Red Hat ビルドの Kogito でのプロセスおよびデシジョンマイクロサービスの統合

Red Hat ビルドの Kogito でビジネスプロセスを設計する場合は、DMN および DRL を使用して、別個のマイクロサービスとしてデシジョンを定義できます。Red Hat ビルドの Kogito では、以下の方法を使用してプロセスおよびデシジョンを統合できます。

  • 埋め込みメソッド: ビジネスルールタスクを使用してプロセスとデシジョンマイクロサービスを統合できます。
  • リモートメソッド: REST エンドポイントを使用してプロセスとデシジョンマイクロサービスを統合できます。

ユースケースによっては、埋め込みメソッドまたはリモートメソッドを使用するか、両方のメソッドを 1 つのプロセスで組み合わせることができます。

7.1. 埋め込み方法を使用した Red Hat ビルドの Kogito でのプロセスおよびデシジョンマイクロサービスの統合

プロセスとデシジョンを統合する組み込み方法は、ビジネスルールタスクを使用します。ビジネスルールタスクは、ローカルプロセスと、同じアプリケーションで実行しているデシジョンエンジン間の通信にアクセスします。埋め込みメソッドでは、デシジョンマイクロサービスを、プロセスマイクロサービスが実行されている同じアプリケーションにデプロイする必要があります。

ビジネスルールタスクの詳細は、「 プロセスデザイナーの BPMN2 タスク」 を参照してください。

図7.1 デシジョンとプロセスを統合するための埋め込みメソッド

Image of Embedded process integration with decisions

Red Hat ビルドの Quarkus および Spring Boot には、それぞれ process-decisions- quarkus および process-decisions-springboot サンプルアプリケーションを使用することもできます。

前提条件

  • プロジェクトを作成し、Red Hat ビルドの Kogito マイクロサービスに必要な Java オブジェクトが含まれている。
  • プロジェクトの src/main/resources フォルダーで、Business Process Model and Notation(BPMN)2.0 ビジネスプロセス、Decision Model and Notation(DMN)デシジョンモデル、Drools Rule Language(DRL)ビジネスルール、その他のアセットを作成またはインポートしている。

手順

  1. 新規またはインポートされた BPMN ファイルを開き、プロセスマイクロサービスを表示します。
  2. プロセスマイクロサービスとデシジョンマイクロサービス間でデータをマッピングするには、プロセス変数として使用される Java クラスのすべての属性名を合わせます。

    属性名にスペースが含まれる場合や、Java 規則に準拠しない場合は、Jackson アノテーションを使用できます。Jackson アノテーションは、プロセス変数を DMN モデルのデータ型に合わせます。

    たとえば、交通違反プロジェクトでは 、@JsonProperty アノテーションを使用して Violation クラスは speedLimit 属性でマッピングされます。そのため、speedLimit 属性は、DMN モデルで定義した Violation データ型と統合できます。

7.1.1. 埋め込みメソッドの交通違反プロジェクトの例

交通違反プロジェクトは、Red Hat ビルドの Kogito でプロセスとデシジョンマイクロサービスを統合する埋め込み方法の例として使用されます。

交通違反プロジェクトでは、最初にドライバーの情報がフェッチされ、フェッチされた情報に基づいて、ドライバーのライセンスは DRL の RuleUnit を使用して検証されます。ドライバーのライセンスを検証した後に、DMN デシジョンマイクロサービスとして定義した違反評価が実行されます。出力には、ドライバーが一時停止されているかどうかに関する情報が含まれます。

図7.2 交通違反の例

Image of Traffic Process in process designer

交通違反プロジェクトには以下のマイクロサービスが含まれます。

交通違反の例でのマイクロサービスの処理

交通違反プロジェクトでは、定義したデシジョンマイクロサービスとの対話は、デシジョンエンジンを使用して実行されます。また、デシジョン評価の実行に必要な情報は、ビジネスルールタスクの Data Assignments プロパティーで定義する必要があります。

重要

プロセスマイクロサービスの ID プロパティーは、プロセスマイクロサービスとの対話に使用されるパスを参照する REST エンドポイントを生成するために使用されます。

プロセスマイクロサービスのクラスは、Plain Old Java Objects(POJO)の定義に使用され、プロセスマイクロサービスとデシジョンマイクロサービスとの対話を可能にします。クラスには Violation、Driver および Fine が含まれます。

交通違反の例におけるデシジョンマイクロサービス

交通違反の例には、DRL を使用して作成されるデシジョンマイクロサービスとしてライセンス検証が含まれます。ライセンスの検証は、ライセンスの有効期限が切れているかどうかを確認するために評価され、結果が ドライバー 変数に追加されるかどうかを検証するルールで構成されます。

また、ルールユニットは LicenseValidationService.drl ファイルで宣言され、関連するデータが LicenseValidationService クラスに追加されます。

LicenseValidationService.drl ファイルの例

unit LicenseValidationService

rule "Is driver license valid"
when
    $driver: /driver[licenseExpiration.after(currentTime)]
then
    $driver.setValidLicense(true);
end

rule "Is driver license expired"
when
    $driver: /driver[licenseExpiration.before(currentTime)]
then
    $driver.setValidLicense(false);
end

query "validation"
  $driver : /driver
end

LicenseValidationService クラスの例

public class LicenseValidationService implements RuleUnitData {
    private SingletonStore<Driver> driver;

    public LicenseValidationService() {
        this(DataSource.createSingleton());
    }

    public LicenseValidationService(SingletonStore<Driver> driver) {
        this.driver = driver;
    }

    public void setDriver(SingletonStore<Driver> driver) {
        this.driver = driver;
    }

    public SingletonStore<Driver> getDriver() {
        return driver;
    }

    public Date getCurrentTime() {
        return new Date();
    }
}

ライセンスを検証した後に、DMN を使用して交通違反のデシジョンが作成されます。交通違反のデシジョンは、ドライバーが一時停止されているかどうかを確認します。交通違反のデシジョンは TrafficViolation.dmn ファイルに宣言されます。

図7.3 TrafficViolation.dmn ファイルの例

Image of Traffic Violation - DMN in DMN designer

交通違反プロジェクトでは 、@JsonProperty アノテーションを使用して Violation クラスは speedLimit 属性でマッピングされます。そのため、speedLimit 属性は、DMN モデルで定義した Violation データ型と統合できます。

交通違反の例で定義された違反 クラス

public class Violation {

    @JsonProperty("Code")
    private String code;

    @JsonProperty("Date")
    private Date date;

    @JsonProperty("Type")
    private String type;

    @JsonProperty("Speed Limit")
    private BigDecimal speedLimit;

    @JsonProperty("Actual Speed")
    private BigDecimal actualSpeed;

    //Getters / Setters
}

図7.4 DMN における違反データ型

Image of Violation Data Type in DMN in DMN designer

交通違反の例では、ドライバーの情報を取得すると、サービスタスクへの外部呼び出しが実行され、データベースからドライバー情報を取得します。また、サービスタスクの実装は、DriverService クラス を使用して実行されます

サービスタスクのデータ割り当てでは、driverId は入力変数として定義され、ドライバーはドライバー 情報で構成される出力変数として定義されます。ドライバー情報を取得すると、DRL サービスを呼び出すタスクを表すライセンス検証タスクが発生します。

DRL サービスタスクの設定に必要なプロパティーには Rule Language が含まれます。これは DRL および Rule Flow Group として設定する必要があります。unit: + [the FQCN of the Rule Unit data class] 形式(例: unit :org.kie.kogito.traffic.LicenseValidationService )を使用して Rule Flow Group の値を設定できます。交通違反の例では、driver 変数にライセンスの検証情報が含まれます。

図7.5 ライセンス検証タスクデータの割り当て

Image of License Validation Task data assignment in process designer

ライセンス検証タスクと同様に、交通違反タスクは、DMN サービスを呼び出すタスクを表します。DMN サービスタスクの設定に必要なプロパティーには Rule Language が含まれます。これは DMN として設定する必要があります。また、TrafficViolation.dmn などの DMN モデルで定義されているように、Namespace、Decision Name、および DMN Model Name プロパティーの値を設定する必要があります。たとえば、交通違反の例は、DMN サービスタスク(トラフィック違反タスク)の以下の値で構成されます。

トラフィック違反タスクの入力には Driver および Violation 変数が含まれ、出力には Data Assignment プロパティーに Suspended および Fine が含まれます。

図7.6 交通違反タスクデータの割り当て

Traffic Violation Task data assignment in process designer

いずれの場合も、ドライバーが一時停止されているかどうかにかかわらず、情報がコンソールに記録されます。

7.2. リモートメソッドを使用した Red Hat ビルドの Kogito でのプロセスおよびデシジョンマイクロサービスの統合

リモートメソッドは、デシジョンマイクロサービスからの REST エンドポイントを使用して、プロセスおよびデシジョンマイクロサービスを統合します。REST エンドポイントでは、プロセスマイクロサービスは BPMN コンポーネントを使用して、サービスタスクや REST ワークアイテムなどの HTTP リクエストを送信できます。

リモートメソッドでは、通信はネットワークを使用して行われるため、同じアプリケーションで実行するプロセスとデシジョンマイクロサービスは必要ありません。

図7.7 プロセスおよびデシジョンマイクロサービスを統合するリモートメソッド

Image of Process integration with decisions through REST

DMN や DRL などの異なるドメインまたはアセットにデシジョンを定義できます。リモートメソッドでは、デシジョンマイクロサービスがプロセスマイクロサービスからデプロイされます。また、REST エンドポイントはプロセスとデシジョンマイクロサービスの同じアプリケーションに生成されますが、異なるメソッドを使用します。ただし、エンドポイントは異なるアプリケーションに置くことができます。

Red Hat ビルドの Quarkus および Spring Boot には、それぞれ process-decisions-rest- quarkus と process-decisions-rest-springboot のサンプルアプリケーションを使用することもできます。アプリケーションのサンプルが実行されている場合、以下のような 2 つの異なるプロセスマイクロサービスも実行されます。

アプリケーションのサンプルを使用するには、関連の URL にリクエストを送信します。

JSON 要求の例

{
  "driverId": "12345",
  "violation": {
    "Type": "speed",
    "Speed Limit": 100,
    "Actual Speed": 140
  }
}

CURL 要求の例

curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '{"driverId": "12345","violation":{"Type":"speed","Speed Limit": 100,"Actual Speed":140}}' http://localhost:8080/traffic_service

応答例

{
  "id": "e499326d-3bd2-4ddb-93b7-0f68f74a9673",
  "driverId": "12345",
  "driver": {
    "licenseExpiration": "2021-08-12T19:35:48.971+00:00",
    "validLicense": true,
    "Name": "Arthur",
    "State": "SP",
    "City": "Campinas",
    "Points": 13,
    "Age": 30
  },
  "trafficViolationResponse": {
    "Fine": {
      "Amount": 1000,
      "Points": 7
    },
    "Suspended": "Yes"
  },
  "violation": {
    "Code": null,
    "Date": null,
    "Type": "speed",
    "Speed Limit": 100,
    "Actual Speed": 140
  }
}

プロセスとデシジョンマイクロサービスを統合するリモートメソッドでは、異なるタスクを使用してデシジョンマイクロサービスへの呼び出しを実行できます。

前提条件

  • プロジェクトを作成し、Red Hat ビルドの Kogito マイクロサービスに必要な Java オブジェクトが含まれている。
  • プロジェクトの src/main/resources フォルダーで、Business Process Model and Notation(BPMN)2.0 ビジネスプロセス、Decision Model and Notation(DMN)デシジョンモデル、Drools Rule Language(DRL)ビジネスルール、その他のアセットを作成またはインポートしている。

手順

  1. 新規またはインポートされた BPMN ファイルを開き、プロセスマイクロサービスを表示します。
  2. プロセスマイクロサービスとデシジョンマイクロサービス間でデータをマッピングするには、プロセス変数として使用される Java クラスのすべての属性名を合わせます。

    属性名にスペースが含まれるか、Java 規則に従わない場合は、Jackson アノテーションを使用できます。Jackson アノテーションは、プロセス変数を DMN モデルのデータ型に合わせます。

    たとえば、交通違反プロジェクトでは 、@JsonProperty アノテーションを使用して Violation クラスは speedLimit 属性でマッピングされます。そのため、speedLimit 属性は、DMN モデルで定義した Violation データ型と統合できます。

7.2.1. リモートメソッドの交通違反プロジェクトの例

交通違反プロジェクトは、Red Hat ビルドの Kogito でプロセスとデシジョンマイクロサービスを統合するリモート方法の例として使用されます。

交通違反プロジェクトでは、最初にドライバーの情報がフェッチされ、フェッチされた情報に基づいて、ドライバーのライセンスは DRL の RuleUnit を使用して検証されます。ドライバーのライセンスを検証した後に、DMN デシジョンマイクロサービスとして定義した違反評価が実行されます。出力には、ドライバーが一時停止されているかどうかに関する情報が含まれます。

リモートメソッドの交通違反の例には、以下のマイクロサービスが含まれます。

  • dmn to define a decision マイクロサービス
  • DRL によるルールデシジョンマイクロサービスの定義
  • プロセスおよびデシジョンマイクロサービスを統合する REST エンドポイント
  • 外部デシジョンマイクロサービスを呼び出すサービスタスク
  • 外部デシジョンマイクロサービスを呼び出す REST ワークアイテム
重要

プロセスマイクロサービスの ID プロパティーは、プロセスマイクロサービスとの対話に使用されるパスを参照する REST エンドポイントを生成するために使用されます。

プロセスマイクロサービスのクラスは、Plain Old Java Objects(POJO)の定義に使用され、プロセスマイクロサービスとデシジョンマイクロサービスとの対話を可能にします。クラスには Violation、DriverFine および TrafficViolationResponse が含まれます。

サービスタスクを使用したトラフィックプロセスマイクロサービス

プロセスマイクロサービスの定義にサービスタスクを使用する場合は、REST や HTTP 呼び出しなどのタスクを実行するアプリケーションに実装を提供できます。

図7.8 サービスタスクを含むトラフィックプロセスマイクロサービス

Image of Traffic Process with service tasks for REST in process designer

実装の詳細は、以下の LicenseValidationRestClient インターフェースおよび TrafficViolationRestClient クラスを参照してください。

交通違反の例の LicenseValidationRestClient クラス

@Path("/validation/first")
@RegisterRestClient
public interface LicenseValidationRestClient {

    @POST
    @Produces(MediaType.APPLICATION_JSON)
    @Consumes(MediaType.APPLICATION_JSON)
    Driver post(Map<String, Object> parameters);

}

交通違反の例の TrafficViolationRestClient クラス

@Path("/Traffic%20Violation")
@RegisterRestClient
public interface TrafficViolationRestClient {

    @POST
    @Produces(MediaType.APPLICATION_JSON)
    @Consumes(MediaType.APPLICATION_JSON)
    TrafficViolationResponse post(Map<String, Object> parameters);

}

application.properties ファイルには、http ://HOST:PORT/ など、意思決定マイクロサービスがデプロイされる場所のシステムプロパティーが含まれます。

application.properties ファイルのシステムプロパティーの例

org.kie.kogito.traffic.TrafficViolationRestClient/mp-rest/url=http://localhost:8080/
org.kie.kogito.traffic.LicenseValidationRestClient/mp-rest/url=http://localhost:8080/

注記

デシジョンマイクロサービスは、同じアプリケーションまたは別のシステムで実行する必要はありません。

サービスタスクを使用するプロセスマイクロサービスは traffic-rules-dmn-service-task.bpmn ファイルで定義されます。

REST ワークアイテムを使用したトラフィックプロセスマイクロサービス

REST ワークアイテムの使用は宣言的メソッドで、追加の実装は必要ありません。REST または HTTP コールはプロセスエンジンにより実行されます。

図7.9 REST ワークアイテムを使用したプロセスマイクロサービス

Image of Traffic Process with service tasks for REST in process designer

URL や HTTP メソッドなどの REST 呼び出しの実行に必要な情報は、REST ワークアイテムの Data Assignments プロパティーで定義する必要があります。REST ワークアイテムを使用するプロセスマイクロサービスは traffic-rules-dmn-wih.bpmn ファイルで定義されます。

交通違反プロジェクトでは 、@JsonProperty アノテーションを使用して Violation クラスは speedLimit 属性でマッピングされます。そのため、speedLimit 属性は、DMN モデルで定義した Violation データ型と統合できます。

トラフィックプロセスマイクロサービスで定義された違反 クラス

public class Violation {

    @JsonProperty("Code")
    private String code;

    @JsonProperty("Date")
    private Date date;

    @JsonProperty("Type")
    private String type;

    @JsonProperty("Speed Limit")
    private BigDecimal speedLimit;

    @JsonProperty("Actual Speed")
    private BigDecimal actualSpeed;

    //Getters / Setters
}

交通違反の例では、ドライバー情報を取得する際に、サービスタスクとのモックされた外部呼び出しが実行され、データベースからドライバー情報を取得します。この場合、サービスタスクの実装は DriverService クラスを使用して実行されます。サービスタスクの Data Assignments プロパティーでは、driverId は入力変数として定義され、ドライバーはドライバー 情報が含まれる出力変数として定義されます。

ドライバー情報の取得により、DRL サービスの起動タスクを表すライセンス検証タスクが発生します。ライセンス検証タスクは、サービスタスクまたは REST ワークアイテムを使用して実行できます。

  • サービスタスクを使用する場合は、メソッドとともに実装プロパティーを定義する必要があります。実装プロパティーでは、REST 呼び出しを実行するサービスタスクを実装するように Java クラスを設定する必要があります。

    ライセンス検証サービスタスクの入力および出力マッピングは、検証されたライセンス情報が含まれる ドライバー 変数です。

    図7.10 ライセンス検証サービスタスクデータの割り当て

    Image of License Validation Service Task data assignment in process designer
  • REST ワークアイテムを使用する場合は、ライセンス検証タスクの入出力マッピングには、検証されたライセンス情報が含まれる ドライバー 変数が含まれます。また、URL と HTTP メソッドはプロセスマイクロサービスの入力パラメーターとして設定されます。

    図7.11 ライセンス検証 REST ワークアイテムデータ割り当て

    Image of License Validation Service Task data assignment in process designer

ライセンス検証タスクと同様に、交通違反タスクは、サービスタスクまたは REST ワークアイテムを使用して DMN サービスを呼び出すタスクを表します。

  • サービスタスクを使用する場合は、実装プロパティーをメソッドとともに設定する必要があります。実装プロパティーには、サービスタスクを実装する Java クラスが含まれます。

    トラフィック違反タスクの入力には Driver および Violation 変数が含まれ、出力には TrafficViolationResponse クラスの一部である Suspended および Fine が含まれます。

    図7.12 traffic violation service task data assignment

    Image of Traffic Violation Service Task data assignment in process designer
  • REST ワークアイテムを使用する場合は、タスク違反タスクの入力には DriverViolation 変数が含まれ、出力には TrafficViolationResponse クラスの一部である Suspended および Fine が含まれます。また、URL と HTTP メソッドはプロセスマイクロサービスの入力パラメーターとして設定されます。

    図7.13 traffic violation REST work item data assignment

    Image of Traffic Violation REST Work Item data assignmentg in process designer

いずれの場合も、ドライバーが一時停止されているかどうかにかかわらず、情報がコンソールに記録されます。

第8章 Red Hat ビルドの Kogito マイクロサービスでの Kafka メッセージングの有効化

Red Hat ビルドの Kogito は、マイクロサービスのメッセージングに対する MicroProfile Reactive Messaging 仕様をサポートします。メッセージングを有効にして、ビジネスプロセス実行の入力または出力としてメッセージイベントを設定できます。

たとえば、以下の handle-travelers.bpmn2 プロセスは、メッセージングの開始イベントと終了イベントを使用して、移動元と通信します。

図8.1 メッセージング開始イベントおよび終了イベントを使用したプロセスの例

Image of message-based process

この例では、メッセージの開始イベントと終了イベントには以下の情報が必要です。

  • メッセージを提供するチャネルにマップするメッセージ名
  • プロセスインスタンス変数にマップするメッセージペイロード

図8.2 開始イベントのメッセージ設定例

Image of message start event data

図8.3 終了イベントのメッセージ設定例

Image of message end event data

この手順では、メッセージングは Apache Kafka をイベントパブリッシャーとしてベースとするため、メッセージングを有効にするには Kafka がインストールされている必要があります。マーシャリング設定は、使用するメッセージングソリューションによって異なります。

前提条件

手順

  1. プロジェクトの pom.xml ファイルに以下の依存関係を追加します。

    Red Hat ビルドの Quarkus の場合

    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-smallrye-reactive-messaging-kafka</artifactId>
    </dependency>
    <dependency>
      <groupId>org.kie.kogito</groupId>
      <artifactId>kogito-addons-quarkus-cloudevents</artifactId>
    </dependency>

    Spring Boot の場合

    <dependency>
      <groupId>org.springframework.kafka</groupId>
      <artifactId>spring-kafka</artifactId>
    </dependency>
    <dependency>
      <groupId>org.kie.kogito</groupId>
      <artifactId>kogito-addons-springboot-cloudevents</artifactId>
    </dependency>
    <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-databind</artifactId>
    </dependency>

  2. 送受信メッセージングチャネルおよびプロパティーを設定します。

    • Red Hat ビルドの Quarkus の場合: プロジェクトの src/main/resources/application.properties ファイルに以下のプロパティーを追加して、送受信のメッセージおよびチャネルを設定します。

      送受信メッセージおよびチャンネルの設定

      mp.messaging.incoming.kogito_incoming_stream.connector=smallrye-kafka
      mp.messaging.incoming.kogito_incoming_stream.topic=travellers
      mp.messaging.incoming.kogito_incoming_stream.value.deserializer=org.apache.kafka.common.serialization.StringDeserializer
      mp.messaging.outgoing.kogito_outgoing_stream.connector=smallrye-kafka
      mp.messaging.outgoing.kogito_outgoing_stream.topic=processedtravellers
      mp.messaging.outgoing.kogito_outgoing_stream.value.serializer=org.apache.kafka.common.serialization.StringSerializer

      travellers を、メッセージ開始イベントの名前に置き換えます。processedtravellers を、メッセージ終了イベントの名前に置き換えます。

      注記

      メッセージングが長い待機時間による実行エラーを防ぐために、以下のプロパティーを使用してメッセージの完了待ちを無効にすることもできます。

      メッセージの待機時間を無効にします。

      mp.messaging.outgoing.[channel-name].waitForWriteCompletion=false

    • Spring Boot の場合: 以下のプロパティーをプロジェクトの src/main/resources/application.properties ファイルに追加して、メッセージングチャネルを設定します。

      メッセージングチャネルの設定

      kafka.bootstrapAddress=localhost:9092
      kogito.addon.cloudevents.kafka.kogito_incoming_stream=travellers
      kogito.addon.cloudevents.kafka.kogito_outgoing_stream=processedtravellers

第9章 Red Hat ビルドの Kogito マイクロサービスの実行

Red Hat ビルドの Kogito マイクロサービスのビジネスデシジョンの設計後に、以下のいずれかのモードで Red Hat ビルドの Quarkus または Spring Boot アプリケーションを実行できます。

  • 開発モード: ローカルテスト用。Red Hat ビルドの Quarkus の開発モードでは、実行中のアプリケーションでデシジョンをライブリロードし、詳細にわたるデバッグを行います。
  • JVM モード: Java 仮想マシン (JVM) との互換性用。

手順

コマンドターミナルで、Red Hat ビルドの Kogito マイクロサービスが含まれるプロジェクトに移動し、選択した実行モードやアプリケーション環境に合わせて、以下のコマンドのいずれかを入力します。

  • 開発モードの場合:

    Red Hat ビルドの Quarkus の場合

    $ mvn clean compile quarkus:dev

    Sprint Boot の場合

    $ mvn clean compile spring-boot:run

  • JVM モードの場合:

    Red Hat ビルドの Quarkus および Spring Boot の場合

    $ mvn clean package
    $ java -jar target/sample-kogito-1.0-SNAPSHOT-runner.jar

第10章 実行中の Red Hat ビルドの Kogito マイクロサービスとの対話

Red Hat ビルドの Kogito マイクロサービスの実行後、REST API 要求を送信し、アプリケーションとの対話やアプリケーションの設定方法に合わせて、マイクロサービスを実行できます。

この例では、/persons REST API エンドポイントをテストし、PersonDecisions.dmn ファイル (または DRL ルールユニットを使用した場合には PersonRules.drl ファイルのルール) に意思決定を自動生成します。

この例では、アプリケーションに設定された REST クライアント、curl ユーティリティー、またはアプリケーションに設定された Swagger UI (例: http://localhost:8080/q/swagger-ui or http://localhost:8080/swagger-ui.html) を使用して、以下のコンポーネントで API 要求を送信します。

  • URL: http://localhost:8080/persons
  • HTTP ヘッダー: POST 要求のみ:

    • accept: application/json
    • content-type: application/json
  • HTTP メソッド: GETPOST、または DELETE

成人 (JSON) を追加するための POST 要求ボディーの例

{
  "person": {
    "name": "John Quark",
    "age": 20
  }
}

成人を追加する curl コマンドの例

curl -X POST http://localhost:8080/persons -H 'content-type: application/json' -H 'accept: application/json' -d '{"person": {"name":"John Quark", "age": 20}}'

応答例 (JSON)

{
  "id": "3af806dd-8819-4734-a934-728f4c819682",
  "person": {
    "name": "John Quark",
    "age": 20,
    "adult": false
  },
  "isAdult": true
}

以下の手順では、便宜上 curl コマンドを使用します。

手順

実行中のアプリケーションから分離されているコマンドターミナルウィンドウで、Red Hat ビルドの Kogito マイクロサービスが含まれるプロジェクトに移動し、以下の curl コマンドのいずれかを JSON 要求と共に使用して、実行中のマイクロサービスと対話します。

注記

Spring Boot では、これらのサンプル要求を機能させるには、アプリケーションによる API エンドポイントの公開方法の変更が必要となる場合があります。詳細は、このチュートリアルで作成した Spring Boot プロジェクトのサンプルに含まれる README ファイルを参照してください。

  • 成人を追加します。

    要求の例

    curl -X POST http://localhost:8080/persons -H 'content-type: application/json' -H 'accept: application/json' -d '{"person": {"name":"John Quark", "age": 20}}'

    応答例

    {"id":"3af806dd-8819-4734-a934-728f4c819682","person":{"name":"John Quark","age":20,"adult":false},"isAdult":true}

  • 未成年を追加します。

    要求の例

    curl -X POST http://localhost:8080/persons -H 'content-type: application/json' -H 'accept: application/json' -d '{"person": {"name":"Jenny Quark", "age": 15}}'

    応答例

    {"id":"8eef502b-012b-4628-acb7-73418a089c08","person":{"name":"Jenny Quark","age":15,"adult":false},"isAdult":false}

  • 返された UUID を使用して評価を完了します。

    要求の例

    curl -X POST http://localhost:8080/persons/8eef502b-012b-4628-acb7-73418a089c08/ChildrenHandling/cdec4241-d676-47de-8c55-4ee4f9598bac -H 'content-type: application/json' -H 'accept: application/json' -d '{}'

パート II. Red Hat OpenShift Container Platform での Red Hat ビルドの Kogito マイクロサービスのデプロイ

ビジネスデシジョンおよびプロセスの開発者は、クラウド実装用に Red Hat OpenShift Container Platform に Red Hat ビルドの Kogito マイクロサービスをデプロイできます。RHPAM Kogito Operator は、デプロイメント手順の多数を自動化するか、デプロイメントプロセスを支援します。

前提条件

  • Red Hat OpenShift Container Platform 4.6 または 4.7 がインストールされている。
  • デプロイメントする OpenShift プロジェクトが作成されている。

第11章 Red Hat OpenShift Container Platform での Red Hat ビルドの Kogito

Red Hat OpenShift Container Platform に対して、クラウド実装用に Red Hat ビルドの Kogito マイクロサービスをデプロできます。このアーキテクチャーでは、Red Hat ビルドの Kogito マイクロサービスは OpenShift Pod としてデプロイされ、個別にスケールアップおよびスケールダウンして、特定のサービスに必要な数のコンテナーを提供できます。

Red Hat Process Automation Manager では、Red Hat Process Automation Manager Kogito Operator が同梱されており、Red Hat ビルドの Kogito マイクロサービスを OpenShift にデプロイするのに役立ちます。この Operator は、デプロイメントプロセス関連の設定をサポートします。Operator は Operator SDK をベースとしており、多くのデプロイメント手順を自動化します。たとえば、アプリケーションが含まれる Git リポジトリーへのリンクを Operator に指定すると、Operator はソースからプロジェクトのビルドに必要なコンポーネントを自動的に設定し、生成されるサービスをデプロイします。

OpenShift Web コンソールで Red Hat Process Automation Manager Kogito Operator をインストールするには、左側のメニューで OperatorsOperatorHub に移動し、RHPAM Kogito Operator を検索して選択し、最新の Operator バージョンをインストールします。

第12章 RHPAM Kogito Operator を使用した OpenShift デプロイメントオプション

ビジネスアプリケーションの一部として Red Hat ビルドの Kogito マイクロサービスを作成したら、Red Hat OpenShift Container Platform Web コンソールを使用してマイクロサービスをデプロイすることができます。OpenShift Web コンソールの RHPAM Kogito Operator ページで、デプロイメントプロセスを進めます。

RHPAM Kogito Operator は、Red Hat OpenShift Container Platform で Red Hat ビルドの Kogito マイクロサービスをビルドしてデプロイするための以下のオプションをサポートします。

  • Git ソースビルドおよびデプロイメント
  • バイナリービルドおよびデプロイメント
  • カスタムイメージのビルドおよびデプロイメント
  • ファイルビルドおよびデプロイメント

12.1. Git ソースビルドおよび OpenShift Web コンソールを使用した OpenShift への Red Hat ビルドの Kogito マイクロサービスのデプロイ

RHPAM Kogito Operator は以下のカスタムリソースを使用して、開発するマイクロサービス (ドメイン固有のマイクロサービス) をデプロイします。

  • KogitoBuild は Git URL または他のソースを使用してアプリケーションをビルドし、ランタイムイメージを作成します。
  • KogitoRuntime はランタイムイメージを起動し、要件に応じて設定します。

ほとんどのユースケースでは、以下の手順のように、標準のランタイムビルドおよびデプロイメント方法を使用して、Git リポジトリーソースから OpenShift に Red Hat ビルドの Kogito マイクロサービスをデプロイできます。

注記

Red Hat ビルドの Kogito マイクロサービスをローカルで開発またはテストする場合は、バイナリービルド、カスタムイメージビルド、またはファイルビルドオプションを使用して、Git リポジトリーではなく、ローカルソースからビルドおよびデプロイできます。

前提条件

  • RHPAM Kogito Operator がインストールされている。
  • Red Hat ビルドの Kogito マイクロサービスを使用するアプリケーションが OpenShift 環境からアクセス可能な Git リポジトリーにある。
  • OpenShift Web コンソールにアクセスでき、KogitoBuild および KogitoRuntime の作成および編集に必要なパーミッションが設定されている。
  • (Red Hat ビルドの Quarkus のみ) プロジェクトの pom.xml ファイルに quarkus-smallrye-health 拡張機能の依存関係が含まれる。この拡張機能は、OpenShift の Red Hat ビルドの Quarkus プロジェクトに必要な liveness および readiness プローブ を有効にします。

    OpenShift 上の Red Hat ビルドの Quarkus アプリケーションの SmallRye Health 依存関係

    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-smallrye-health</artifactId>
    </dependency>

手順

  1. Operators → Installed Operators に移動し、RHPAM Kogito Operator を選択します。
  2. Red Hat ビルドの Kogito ビルド定義を作成するには、Operator ページで Kogito Build タブを選択し、Create KogitoBuild をクリックします。
  3. アプリケーションウィンドウで、Form View または YAML View を使用してビルド定義を設定します。

    少なくとも、以下の YAML ファイルのサンプルに示されるようにアプリケーション設定を定義します。

    Red Hat ビルドの Kogito ビルドを使用した Red Hat ビルドの Quarkus アプリケーションの YAML 定義の例

    apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this service
    kind: KogitoBuild  # Application type
    metadata:
      name: example-quarkus  # Application name
    spec:
      type: RemoteSource
      gitSource:
        uri: 'https://github.com/kiegroup/kogito-examples'  # Git repository containing application (uses default branch)
        contextDir: dmn-quarkus-example  # Git folder location of application

    Red Hat ビルドの Kogito ビルドを使用した Spring Boot アプリケーションの YAML 定義の例

    apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this service
    kind: KogitoBuild  # Application type
    metadata:
      name: example-springboot  # Application name
    spec:
      runtime: springboot
      type: RemoteSource
      gitSource:
        uri: 'https://github.com/kiegroup/kogito-examples'  # Git repository containing application (uses default branch)
        contextDir: dmn-springboot-example  # Git folder location of application

    注記

    内部 Maven リポジトリーを設定した場合は、Maven ミラーサービスとして使用でき、Red Hat ビルドの Kogito ビルド定義に Maven ミラー URL を指定して、ビルド時間を大幅に短縮できます。

    spec:
      mavenMirrorURL: http://nexus3-nexus.apps-crc.testing/repository/maven-public/

    内部 Maven リポジトリーの詳細は、Apache Maven ドキュメントを参照してください。

  4. アプリケーションデータを定義したら、Create をクリックして Red Hat ビルドの Kogito ビルドを生成します。

    アプリケーションが Red Hat ビルドの KogitoBuilds ページに一覧表示されます。アプリケーション名を選択して、アプリケーション設定および YAML の詳細を表示または変更できます。

  5. Red Hat ビルドの Kogito マイクロサービス定義を作成するには、Operator ページで Kogito Runtime タブを選択し、Create KogitoRuntime をクリックします。
  6. アプリケーションウィンドウで、Form View または YAML View を使用してマイクロサービス定義を設定します。

    少なくとも、以下の YAML ファイルのサンプルに示されるようにアプリケーション設定を定義します。

    Red Hat ビルドの Kogito マイクロサービスを使用した Red Hat ビルドの Quarkus アプリケーションの YAML 定義の例

    apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
    kind: KogitoRuntime  # Application type
    metadata:
      name: example-quarkus  # Application name

    Red Hat ビルドの Kogito マイクロサービスを使用した Spring Boot アプリケーションの YAML 定義の例

    apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
    kind: KogitoRuntime  # Application type
    metadata:
      name: example-springboot  # Application name
    spec:
      runtime: springboot

    注記

    この場合、アプリケーションは Git からビルドされ、KogitoRuntime を使用してデプロイされます。アプリケーション名が KogitoBuild および KogitoRuntime で同じである必要があります。

  7. アプリケーションデータを定義したら、Create をクリックして Red Hat ビルドの Kogito マイクロサービスを生成します。

    アプリケーションが Red Hat ビルドの Kogito マイクロサービスページに一覧表示されます。アプリケーション名を選択して、アプリケーション設定や YAML ファイルの内容を表示または変更できます。

  8. Web コンソールの左側のメニューで BuildsBuilds に移動して、アプリケーションのビルドのステータスを表示します。

    特定のビルドを選択して、ビルドの詳細を表示できます。

    注記

    OpenShift デプロイメント用に作成するすべての Red Hat ビルドの Kogito マイクロサービスでは、従来のランタイムビルドと S2I (サフィックス -builder) ビルドの 2 つのビルドが生成され、Web コンソールの Builds ページに一覧表示されます。S2I メカニズムは OpenShift ビルドでアプリケーションを構築し、このアプリケーションを次の OpenShift ビルドに渡してランタイムコンテナーイメージにパッケージ化します。Red Hat ビルドの Kogito S2I ビルド設定では、OpenShift プラットフォームの Git リポジトリーから直接プロジェクトをビルドできます。

  9. アプリケーションのビルドが完了したら、WorkloadsDeployments に移動して、アプリケーションのデプロイメント、Pod のステータスなどの情報を表示します。
  10. Red Hat ビルドの Kogito マイクロサービスをデプロイしたら、Web コンソールの左側のメニューの NetworkingRoutes に移動し、デプロイされたアプリケーションへのアクセスリンクを表示します。

    アプリケーション名を選択して、ルート設定を表示または変更できます。

    必要に応じてアプリケーションルートを使用すると、Red Hat ビルドの Kogito マイクロサービスはビジネス自動化ソリューションと統合できます。

12.2. バイナリービルドおよび OpenShift Web コンソールを使用した OpenShift への Red Hat ビルドの Kogito マイクロサービスのデプロイ

OpenShift ビルドには、長時間かかる可能性があります。OpenShift での Red Hat ビルドの Kogito マイクロサービスのビルドおよびデプロイを短時間で行う別の方法として、バイナリービルドを使用できます。

Operator は以下のカスタムリソースを使用して、開発するマイクロサービス (ドメイン固有のマイクロサービス) をデプロイします。

  • KogitoBuild はアップロードしたアプリケーションを処理し、ランタイムイメージを作成します。
  • KogitoRuntime はランタイムイメージを起動し、要件に応じて設定します。

前提条件

  • RHPAM Kogito Operator がインストールされている。
  • oc OpenShift CLI がインストールされており、関連する OpenShift クラスターにログインしている。oc のインストールおよびログインの手順については、OpenShift ドキュメント を参照してください。
  • OpenShift Web コンソールにアクセスでき、KogitoBuild および KogitoRuntime の作成および編集に必要なパーミッションが設定されている。
  • (Red Hat ビルドの Quarkus のみ) プロジェクトの pom.xml ファイルに quarkus-smallrye-health 拡張機能の依存関係が含まれる。この拡張機能は、OpenShift の Red Hat ビルドの Quarkus プロジェクトに必要な liveness および readiness プローブ を有効にします。

    OpenShift 上の Red Hat ビルドの Quarkus アプリケーションの SmallRye Health 依存関係

    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-smallrye-health</artifactId>
    </dependency>

手順

  1. アプリケーションをローカルに構築します。
  2. Operators → Installed Operators に移動し、RHPAM Kogito Operator を選択します。
  3. Red Hat ビルドの Kogito ビルド定義を作成するには、Operator ページで Kogito Build タブを選択し、Create KogitoBuild をクリックします。
  4. アプリケーションウィンドウで、Form View または YAML View を使用してビルド定義を設定します。

    少なくとも、以下の YAML ファイルのサンプルに示されるようにアプリケーション設定を定義します。

    Red Hat ビルドの Kogito ビルドを使用した Red Hat ビルドの Quarkus アプリケーションの YAML 定義の例

    apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this service
    kind: KogitoBuild  # Application type
    metadata:
      name: example-quarkus  # Application name
    spec:
      type: Binary

    Red Hat ビルドの Kogito ビルドを使用した Spring Boot アプリケーションの YAML 定義の例

    apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this service
    kind: KogitoBuild  # Application type
    metadata:
      name: example-springboot  # Application name
    spec:
      runtime: springboot
      type: Binary

  5. アプリケーションデータを定義したら、Create をクリックして Red Hat ビルドの Kogito ビルドを生成します。

    アプリケーションが Red Hat ビルドの KogitoBuilds ページに一覧表示されます。アプリケーション名を選択して、アプリケーション設定および YAML の詳細を表示または変更できます。

  6. 以下のコマンドを使用して、ビルドしたバイナリーをアップロードします。

    $ oc start-build example-quarkus --from-dir=target/ -n namespace
    • from-dir は、ビルドされたアプリケーションの ターゲット フォルダーパスと同じです。
    • Namespace は、KogitoBuild の作成先の namespace に置き換えます。
  7. Red Hat ビルドの Kogito マイクロサービス定義を作成するには、Operator ページで Kogito Runtime タブを選択し、Create KogitoRuntime をクリックします。
  8. アプリケーションウィンドウで、Form View または YAML View を使用してマイクロサービス定義を設定します。

    少なくとも、以下の YAML ファイルのサンプルに示されるようにアプリケーション設定を定義します。

    Red Hat ビルドの Kogito マイクロサービスを使用した Red Hat ビルドの Quarkus アプリケーションの YAML 定義の例

    apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
    kind: KogitoRuntime  # Application type
    metadata:
      name: example-quarkus  # Application name

    Red Hat ビルドの Kogito マイクロサービスを使用した Spring Boot アプリケーションの YAML 定義の例

    apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
    kind: KogitoRuntime  # Application type
    metadata:
      name: example-springboot  # Application name
    spec:
      runtime: springboot

    注記

    この場合、アプリケーションは、KogitoRuntime を使用してローカルにビルドされ、デプロイされます。アプリケーション名が KogitoBuild および KogitoRuntime で同じである必要があります。

  9. アプリケーションデータを定義したら、Create をクリックして Red Hat ビルドの Kogito マイクロサービスを生成します。

    アプリケーションが Red Hat ビルドの Kogito マイクロサービスページに一覧表示されます。アプリケーション名を選択して、アプリケーション設定や YAML ファイルの内容を表示または変更できます。

  10. Web コンソールの左側のメニューで BuildsBuilds に移動して、アプリケーションのビルドのステータスを表示します。

    特定のビルドを選択して、ビルドの詳細を表示できます。

  11. アプリケーションのビルドが完了したら、WorkloadsDeployments に移動して、アプリケーションのデプロイメント、Pod のステータスなどの情報を表示します。
  12. Red Hat ビルドの Kogito マイクロサービスをデプロイしたら、Web コンソールの左側のメニューの NetworkingRoutes に移動し、デプロイされたアプリケーションへのアクセスリンクを表示します。

    アプリケーション名を選択して、ルート設定を表示または変更できます。

    必要に応じてアプリケーションルートを使用すると、Red Hat ビルドの Kogito マイクロサービスはビジネス自動化ソリューションと統合できます。

12.3. カスタムイメージビルドおよび OpenShift Web コンソールを使用した OpenShift への Red Hat ビルドの Kogito マイクロサービスのデプロイ

OpenShift で Red Hat ビルドの Kogito マイクロサービスをビルドし、デプロイする代わりに、カスタムイメージビルドを使用できます。

Operator は以下のカスタムリソースを使用して、開発するマイクロサービス (ドメイン固有のマイクロサービス) をデプロイします。

  • KogitoRuntime はランタイムイメージを起動し、要件に応じて設定します。

前提条件

  • RHPAM Kogito Operator がインストールされている。
  • OpenShift Web コンソールにアクセスでき、KogitoRuntime の作成および編集に必要なパーミッションが設定されている。
  • (Red Hat ビルドの Quarkus のみ) プロジェクトの pom.xml ファイルに quarkus-smallrye-health 拡張機能の依存関係が含まれる。この拡張機能は、OpenShift の Red Hat ビルドの Quarkus プロジェクトに必要な liveness および readiness プローブ を有効にします。

    OpenShift 上の Red Hat ビルドの Quarkus アプリケーションの SmallRye Health 依存関係

    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-smallrye-health</artifactId>
    </dependency>

手順

  1. アプリケーションをローカルに構築します。
  2. 以下の内容を含むプロジェクトルートディレクトリーに Containerfile を作成します。

    Red Hat ビルドの Quarkus アプリケーションの Containerfile の例

    FROM registry.redhat.io/rhpam-7/rhpam-kogito-runtime-jvm-rhel8:7.11.0
    
    ENV RUNTIME_TYPE quarkus
    
    COPY target/quarkus-app/lib/ $KOGITO_HOME/bin/lib/
    COPY target/quarkus-app/*.jar $KOGITO_HOME/bin
    COPY target/quarkus-app/app/ $KOGITO_HOME/bin/app/
    COPY target/quarkus-app/quarkus/ $KOGITO_HOME/bin/quarkus/

    Spring Boot アプリケーションの Containerfile の例

    FROM registry.redhat.io/rhpam-7/rhpam-kogito-runtime-jvm-rhel8:7.11.0
    
    ENV RUNTIME_TYPE springboot
    
    COPY target/<application-jar-file> $KOGITO_HOME/bin

    • application-jar-file は、アプリケーションの JAR ファイルの名前です。
  3. 以下のコマンドを使用して Red Hat ビルドの Kogito イメージをビルドします。

    podman build --tag <final-image-name> -f <Container-file>

    このコマンドでは、final-image-name は Red Hat ビルドの Kogito イメージの名前、Container-file は直前の手順で作成した Containerfile に置き換えます。

  4. 必要に応じて、以下のコマンドを使用してビルドイメージをテストします。

    podman run --rm -it -p 8080:8080 <final-image-name>
  5. 以下のコマンドを使用して、ビルドした Red Hat ビルドの Kogito イメージをイメージレジストリーにプッシュします。

    podman push <final-image-name>
  6. Operators → Installed Operators に移動し、RHPAM Kogito Operator を選択します。
  7. Red Hat ビルドの Kogito マイクロサービス定義を作成するには、Operator ページで Kogito Runtime タブを選択し、Create KogitoRuntime をクリックします。
  8. アプリケーションウィンドウで、Form View または YAML View を使用してマイクロサービス定義を設定します。

    少なくとも、以下の YAML ファイルのサンプルに示されるようにアプリケーション設定を定義します。

    Red Hat ビルドの Kogito マイクロサービスを使用した Red Hat ビルドの Quarkus アプリケーションの YAML 定義の例

    apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
    kind: KogitoRuntime # Application type
    metadata:
      name: example-quarkus # Application name
    spec:
      image: <final-image-name> # Kogito image name
      insecureImageRegistry: true # Can be omitted when image is pushed into secured registry with valid certificate

    Red Hat ビルドの Kogito マイクロサービスを使用した Spring Boot アプリケーションの YAML 定義の例

    apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
    kind: KogitoRuntime # Application type
    metadata:
      name: example-springboot # Application name
    spec:
      image: <final-image-name> # Kogito image name
      insecureImageRegistry: true # Can be omitted when image is pushed into secured registry with valid certificate
      runtime: springboot

  9. アプリケーションデータを定義したら、Create をクリックして Red Hat ビルドの Kogito マイクロサービスを生成します。

    アプリケーションが Red Hat ビルドの Kogito マイクロサービスページに一覧表示されます。アプリケーション名を選択して、アプリケーション設定や YAML ファイルの内容を表示または変更できます。

  10. アプリケーションのビルドが完了したら、WorkloadsDeployments に移動して、アプリケーションのデプロイメント、Pod のステータスなどの情報を表示します。
  11. Red Hat ビルドの Kogito マイクロサービスをデプロイしたら、Web コンソールの左側のメニューの NetworkingRoutes に移動し、デプロイされたアプリケーションへのアクセスリンクを表示します。

    アプリケーション名を選択して、ルート設定を表示または変更できます。

    必要に応じてアプリケーションルートを使用すると、Red Hat ビルドの Kogito マイクロサービスはビジネス自動化ソリューションと統合できます。

12.4. ファイルビルドおよび OpenShift Web コンソールを使用した OpenShift への Red Hat ビルドの Kogito マイクロサービスのデプロイ

Decision Model and Notation (DMN)、Drools Rule Language (DRL)、プロパティーファイルなどの 1 つのファイルから、または複数のファイルを含むディレクトリーから Red Hat ビルドの Kogito マイクロサービスをビルドおよびデプロイできます。ローカルファイルシステムパスからファイル を 1 つまたは、ディレクトリーを 1 つのみ指定できます。ファイルまたはディレクトリーを OpenShift クラスターにアップロードすると、新しい Source-to-Image (S2I) ビルドが自動的に開始されます。

Operator は以下のカスタムリソースを使用して、開発するマイクロサービス (ドメイン固有のマイクロサービス) をデプロイします。

  • KogitoBuild はファイルからアプリケーションを生成し、ランタイムイメージを作成します。
  • KogitoRuntime はランタイムイメージを起動し、要件に応じて設定します。

前提条件

  • RHPAM Kogito Operator がインストールされている。
  • oc OpenShift CLI がインストールされており、関連する OpenShift クラスターにログインしている。oc のインストールおよびログインの手順については、OpenShift ドキュメント を参照してください。
  • OpenShift Web コンソールにアクセスでき、KogitoBuild および KogitoRuntime の作成および編集に必要なパーミッションが設定されている。

手順

  1. Operators → Installed Operators に移動し、RHPAM Kogito Operator を選択します。
  2. Red Hat ビルドの Kogito ビルド定義を作成するには、Operator ページで Kogito Build タブを選択し、Create KogitoBuild をクリックします。
  3. アプリケーションウィンドウで、Form View または YAML View を使用してビルド定義を設定します。

    少なくとも、以下の YAML ファイルのサンプルに示されるようにアプリケーション設定を定義します。

    Red Hat ビルドの Kogito ビルドを使用した Red Hat ビルドの Quarkus アプリケーションの YAML 定義の例

    apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this service
    kind: KogitoBuild  # Application type
    metadata:
      name: example-quarkus  # Application name
    spec:
      type: LocalSource

    Red Hat ビルドの Kogito ビルドを使用した Spring Boot アプリケーションの YAML 定義の例

    apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this service
    kind: KogitoBuild  # Application type
    metadata:
      name: example-springboot  # Application name
    spec:
      runtime: springboot
      type: LocalSource

    注記

    内部 Maven リポジトリーを設定した場合は、Maven ミラーサービスとして使用でき、Red Hat ビルドの Kogito ビルド定義に Maven ミラー URL を指定して、ビルド時間を大幅に短縮できます。

    spec:
      mavenMirrorURL: http://nexus3-nexus.apps-crc.testing/repository/maven-public/

    内部 Maven リポジトリーの詳細は、Apache Maven ドキュメントを参照してください。

  4. アプリケーションデータを定義したら、Create をクリックして Red Hat ビルドの Kogito ビルドを生成します。

    アプリケーションが Red Hat ビルドの KogitoBuilds ページに一覧表示されます。アプリケーション名を選択して、アプリケーション設定および YAML の詳細を表示または変更できます。

  5. 以下のコマンドを使用して、ファイルアセットをアップロードします。

    $ oc start-build example-quarkus-builder --from-file=<file-asset-path> -n namespace
    • file-asset-path は、アップロードするファイルハンドラーのパスに、
    • Namespace は、KogitoBuild の作成先の namespace に置き換えます。
  6. Red Hat ビルドの Kogito マイクロサービス定義を作成するには、Operator ページで Kogito Runtime タブを選択し、Create KogitoRuntime をクリックします。
  7. アプリケーションウィンドウで、Form View または YAML View を使用してマイクロサービス定義を設定します。

    少なくとも、以下の YAML ファイルのサンプルに示されるようにアプリケーション設定を定義します。

    Red Hat ビルドの Kogito マイクロサービスを使用した Red Hat ビルドの Quarkus アプリケーションの YAML 定義の例

    apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
    kind: KogitoRuntime  # Application type
    metadata:
      name: example-quarkus  # Application name

    Red Hat ビルドの Kogito マイクロサービスを使用した Spring Boot アプリケーションの YAML 定義の例

    apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
    kind: KogitoRuntime  # Application type
    metadata:
      name: example-springboot  # Application name
    spec:
      runtime: springboot

    注記

    この場合、アプリケーションはファイルからビルドされ、KogitoRuntime を使用してデプロイされます。アプリケーション名が KogitoBuild および KogitoRuntime で同じである必要があります。

  8. アプリケーションデータを定義したら、Create をクリックして Red Hat ビルドの Kogito マイクロサービスを生成します。

    アプリケーションが Red Hat ビルドの Kogito マイクロサービスページに一覧表示されます。アプリケーション名を選択して、アプリケーション設定や YAML ファイルの内容を表示または変更できます。

  9. Web コンソールの左側のメニューで BuildsBuilds に移動して、アプリケーションのビルドのステータスを表示します。

    特定のビルドを選択して、ビルドの詳細を表示できます。

    注記

    OpenShift デプロイメント用に作成するすべての Red Hat ビルドの Kogito マイクロサービスでは、従来のランタイムビルドと S2I (サフィックス -builder) ビルドの 2 つのビルドが生成され、Web コンソールの Builds ページに一覧表示されます。S2I メカニズムは OpenShift ビルドでアプリケーションを構築し、このアプリケーションを次の OpenShift ビルドに渡してランタイムコンテナーイメージにパッケージ化します。

  10. アプリケーションのビルドが完了したら、WorkloadsDeployments に移動して、アプリケーションのデプロイメント、Pod のステータスなどの情報を表示します。
  11. Red Hat ビルドの Kogito マイクロサービスをデプロイしたら、Web コンソールの左側のメニューの NetworkingRoutes に移動し、デプロイされたアプリケーションへのアクセスリンクを表示します。

    アプリケーション名を選択して、ルート設定を表示または変更できます。

    必要に応じてアプリケーションルートを使用すると、Red Hat ビルドの Kogito マイクロサービスはビジネス自動化ソリューションと統合できます。

第13章 Red Hat OpenShift Container Platform での Red Hat ビルドの Kogito マイクロサービスのプローブ

Red Hat OpenShift Container Platform のプローブは、アプリケーションが機能していることを検証します。検証されない場合には、再起動する必要があります。Red Hat ビルドの Quarkus および Spring Boot の Red Hat ビルドの Kogito マイクロサービスの場合には、プローブは HTTP 要求 (拡張機能によって公開されるエンドポイントにデフォルト設定) を使用してアプリケーションと対話します。そのため、Red Hat OpenShift Container Platform で Red Hat ビルドの Kogito マイクロサービスを実行するには、拡張機能をインポートして liveness、readiness、および startup probe のアプリケーション可用性の情報を提供する必要があります。

13.1. Red Hat OpenShift Container Platform での Red Hat ビルドの Quarkus アプリケーションのヘルスチェック拡張機能の追加

Red Hat OpenShift Container Platform の Red Hat ビルドの Quarkus をベースとする Red Hat ビルドの Kogito サービスのヘルスチェック拡張機能を追加できます。

手順

コマンドターミナルで、プロジェクトの pom.xml ファイルに移動し、quarkus-smallrye-health 拡張機能の依存関係を追加します。

Red Hat OpenShift Container Platform の Red Hat ビルドの Quarkus アプリケーションの SmallRye Health 依存関係

<dependencies>
  <dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-smallrye-health</artifactId>
  </dependency>
</dependencies>

13.2. Red Hat OpenShift Container Platform での Spirng Boot アプリケーションのヘルスチェック拡張機能の追加

Red Hat OpenShift Container Platform の Spring Boot をベースとする Red Hat ビルドの Kogito マイクロサービスのヘルスチェック拡張機能を追加できます。

手順

コマンドターミナルで、プロジェクトの pom.xml ファイルに移動し、以下の Spring Boot アクチュエーターの依存関係を追加します。

Red Hat OpenShift Container Platform における Spring Boot アプリケーションの Spring Boot のアクチュエーター依存関係

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
  </dependency>
</dependencies>

13.3. Red Hat OpenShift Container Platform での Red Hat ビルドの Kogito マイクロサービスのカスタムプローブ設定

liveness、readiness、および startup probe のカスタムエンドポイントを設定することもできます。

手順

  1. 以下の例のように、プロジェクトの KogitoRuntime YAML ファイルでプローブを定義します。

カスタムプローブエンドポイントを含む Red Hat ビルドの Kogito マイクロサービスカスタムリソースの例

apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this service
kind: KogitoRuntime
metadata:
  name: process-quarkus-example # Application name
spec:
  replicas: 1
  probes:
    livenessProbe:
      httpGet:
        path: /probes/live # Liveness endpoint
        port: 8080
    readinessProbe:
      httpGet:
        path: /probes/ready # Readiness endpoint
        port: 8080
    startupProbe:
      tcpSocket:
        port: 8080

第14章 Red Hat ビルドの Kogito での Prometheus メトリクスモニタリングの有効化

Prometheus は、オープンソースのシステム監視ツールキットで、Red Hat ビルドの Kogito と連携して、Business Process Model and Notation(BPMN)プロセスモデル、ビジネスルール、および Decision Model and Notation(DMN)デシジョンモデルの実行に関するメトリクスを収集して保存できます。設定されたアプリケーションエンドポイントへの REST API 呼び出しや、Prometheus expression browser、Grafana などのデータグラフツールを使用して、保存されたメトリクスにアクセスできます。

前提条件

  • Prometheus がインストールされている。Prometheus のダウンロードおよび使用に関する情報は、Prometheus ドキュメントページ を参照してください。

手順

  1. プロジェクトで Prometheus アドオンを有効にするには、使用しているフレームワークに応じて、以下の依存関係 のいずれかを pom.xml ファイルに追加します。

    Prometheus Red Hat ビルドの Quarkus アドオンの依存関係

    <dependency>
      <groupId>org.kie.kogito</groupId>
      <artifactId>kogito-addons-quarkus-monitoring-prometheus</artifactId>
      <version>KOGITO_VERSION</version>
    </dependency>

    Prometheus Spring Boot アドオンの依存関係

    <dependency>
      <groupId>org.kie.kogito</groupId>
      <artifactId>kogito-addons-springboot-monitoring-prometheus</artifactId>
      <version>KOGITO_VERSION</version>
    </dependency>

  2. オプション: プロジェクトの application.properties ファイルに以下のプロパティーを設定し、特定のメトリクスのエクスポートを防ぎます。

    エクスポート用に特定のメトリクスが無効になっている

    kogito.monitoring.rule.useDefault=false
    kogito.monitoring.process.useDefault=false
    kogito.monitoring.interceptor.useDefault=false

    デフォルトでは、保存されたすべてのメトリクスは設定済みのモニタリングモジュールにエクスポートされます。

  3. Prometheus を Red Hat ビルドの Kogito マイクロサービスからメトリクスを収集するように設定するには、以下の設定を Prometheus ディストリビューションの prometheus.yaml ファイルの scrape_configs セクションに追加します。

    prometheus.yaml ファイルの Scrape 設定の例

    scrape_configs:
      job_name: 'kogito-metrics'
    metrics_path: /metrics
    static_configs:
      - targets: ["localhost:8080"]

    Red Hat ビルドの Kogito マイクロサービス設定に応じて、値を置き換えます。

  4. コマンドターミナルでプロジェクトに移動し、開発モードなどの任意のモードでプロジェクトを実行します。

    Red Hat ビルドの Quarkus の場合

    mvn clean compile quarkus:dev

    Spring Boot の場合

    mvn clean compile spring-boot:run

    Red Hat ビルドの Kogito マイクロサービスを起動すると、Prometheus はメトリクスの収集を開始し、Red Hat ビルドの Kogito はメトリクスを設定済みの REST API エンドポイントに公開します。

  5. メトリクス設定を確認するには、REST クライアントまたは curl ユーティリティーを使用して GET リクエストを設定済みの /metrics エンドポイントに送信します(例: http://localhost:8080/metrics)。

    Prometheus メトリクスを返す curl コマンドの例

    curl -X GET http://localhost:8080/metrics

    応答例

    # HELP kogito_process_instance_completed_total Completed Process Instances
    # TYPE kogito_process_instance_completed_total counter
    # HELP kogito_process_instance_started_total Started Process Instances
    # TYPE kogito_process_instance_started_total counter
    kogito_process_instance_started_total{app_id="acme-travels",process_id="travels",} 1.0
    # HELP kogito_work_item_duration_seconds Work Items Duration
    # TYPE kogito_work_item_duration_seconds summary
    # HELP drl_match_fired_nanosecond Drools Firing Time
    # TYPE drl_match_fired_nanosecond histogram
    drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="1000000.0",} 1.0
    drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="2000000.0",} 1.0
    drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="3000000.0",} 1.0
    drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="4000000.0",} 1.0
    drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="5000000.0",} 1.0
    drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="6000000.0",} 1.0
    drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="7000000.0",} 1.0
    drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="8000000.0",} 1.0
    drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="9000000.0",} 1.0
    drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="+Inf",} 1.0
    drl_match_fired_nanosecond_count{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",} 1.0
    drl_match_fired_nanosecond_sum{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",} 789941.0
    # HELP kogito_process_instance_sla_violated_total Process Instances SLA Violated
    # TYPE kogito_process_instance_sla_violated_total counter
    # HELP kogito_process_instance_duration_seconds Process Instances Duration
    # TYPE kogito_process_instance_duration_seconds summary
    # HELP kogito_process_instance_running_total Running Process Instances
    # TYPE kogito_process_instance_running_total gauge
    kogito_process_instance_running_total{app_id="acme-travels",process_id="travels",} 1.0

    定義したエンドポイントでメトリクスが利用できない場合は、このセクションで説明されている Red Hat ビルドの Kogito および Prometheus 設定を確認します。

    http://HOST:PORT /graph および http://HOST:PORT /targets の Prometheus 式ブラウザーで収集したメトリクスおよびアプリケーションターゲットと対話したり、Prometheus データソースを Grafana などのデータグラフ作成ツールと統合したりすることもできます。

    図14.1 Prometheus expression browser with Red Hat build of Kogito service targets

    Image of targets in Prometheus expression browser

    図14.2 Grafana ダッシュボードと Kogito サービスメトリクス

    Image of application metrics in Grafana

14.1. Red Hat Process Automation Manager のデフォルトメトリクス用の Grafana ダッシュボード

Prometheus モニタリングモジュールのいずれかがプロジェクトの pom.xml ファイルで依存関係としてインポートされている場合、デフォルトのメトリクスを使用する Grafana ダッシュボードの一部が、Red Hat ビルドの Kogito マイクロサービスをコンパイルするたびに、フォルダー target/classes/META-INF/resources/monitoring /dashboards/ の下に生成されます。

エンドポイントで使用するデシジョンモデルに応じて、2 種類のダッシュボードがエクスポートされます。

  • 運用ダッシュボード: このダッシュボードは BPMN、DMN、および DRL エンドポイントに対して生成され、以下のメトリクスが含まれます。

    • エンドポイントのリクエストの合計数
    • エンドポイントにおける 1 分あたりの平均リクエスト数
    • リクエストを評価する経過時間の数量
    • 例外の詳細

      図14.3 生成された運用ダッシュボードの例

      Generated operational dashboard
  • ドメイン固有のダッシュボード: このダッシュボードは DMN エンドポイントに対してのみエクスポートされます。ドメイン固有のダッシュボードには、DMN モデルの各タイプのデシジョンのグラフが含まれます。現在、組み込み型 番号文字列、および ブール値 のみがサポートされます。

    • デシジョンの出力が 数字 タイプである場合、グラフには 3 分間のスライディングウィンドウのメトリクスの数量が含まれます。
    • 出力が ブール値 または文字列 タイプである場合、グラフには 10 分間の平均の出力数が含まれます。

      図14.4 生成されるドメイン固有のダッシュボードの例

      Generated domain specific dashboard

第15章 Red Hat Process Automation Manager Kogito Operator と Prometheus および Grafana との対話

Red Hat Process Automation Manager の Red Hat ビルドの Kogito は、Red Hat ビルドの Kogito マイクロサービスの Prometheus メトリクスモニタリングを有効にする monitoring-prometheus-addon アドオンを提供し、アドオンによってエクスポートされるデフォルトのメトリクスを使用する Grafana ダッシュボードを生成します。RHPAM Kogito Operator は Prometheus Operator を使用して、Prometheus からスクレープするプロジェクトからメトリクスを公開します。この依存関係により、Prometheus Operator はプロジェクトと同じ namespace にインストールする必要があります。

Red Hat ビルドの Kogito マイクロサービスの Prometheus メトリクス監視を有効にする場合は、使用するフレームワークに応じて、プロジェクトの pom.xml ファイルに以下の依存関係を追加します。

Prometheus Red Hat ビルドの Quarkus アドオンの依存関係

<dependency>
      <groupId>org.kie.kogito</groupId>
      <artifactId>monitoring-prometheus-quarkus-addon</artifactId>
</dependency>

Prometheus Spring Boot アドオンの依存関係

<dependency>
      <groupId>org.kie.kogito</groupId>
      <artifactId>monitoring-prometheus-springboot-addon</artifactId>
</dependency>

monitoring-prometheus-addon アドオンを使用し、Prometheus Operator がインストールされている Red Hat ビルドの Kogito マイクロサービスをデプロイする場合、Red Hat Process Automation Manager Kogito Operator は ServiceMonitor カスタムリソースを作成し、以下の例のように Prometheus のメトリクスを公開します。

Prometheus の ServiceMonitor リソースの例

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app: onboarding-service
  name: onboarding-service
  namespace: kogito
spec:
  endpoints:
  - path: /metrics
    targetPort: 8080
    scheme: http
  namespaceSelector:
    matchNames:
    - kogito
  selector:
    matchLabels:
      app: onboarding-service

Prometheus Operator によって管理される Prometheus カスタムリソースを手作業で設定し、ServiceMonitor リソースを選択する必要があります。

Prometheus リソースの例

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
spec:
  serviceAccountName: prometheus
  serviceMonitorSelector:
    matchLabels:
      app: dmn-drools-quarkus-metrics-service

ServiceMonitor リソースで Prometheus リソースを設定した後に、Prometheus Web コンソールの Targets ページで Prometheus によってスクレープされたエンドポイントを表示できます。Red Hat Process Automation Manager サービスが公開するメトリクスが Graph view に表示されます。

RHPAM Kogito Operator は、アドオンによって生成された Grafana ダッシュボードごとに、Grafana Operator によって定義される Grafana Dashboard カスタムリソースも作成します。ダッシュボードのappラベルは、デプロイされた Red Hat ビルドの Kogito マイクロサービスの名前です。Kogito マイクロサービスの関連する Red Hat ビルドに従い、Grafana カスタムリソースの dashboardLabelSelector プロパティーを設定する必要があります。

Grafana リソースの例

apiVersion: integreatly.org/v1alpha1
kind: Grafana
metadata:
  name: example-grafana
spec:
  ingress:
    enabled: true
  config:
    auth:
      disable_signout_menu: true
    auth.anonymous:
      enabled: true
    log:
      level: warn
      mode: console
    security:
      admin_password: secret
      admin_user: root
  dashboardLabelSelector:
    - matchExpressions:
        - key: app
          operator: In
          values:
            - my-kogito-application

第16章 Red Hat ビルドの Kogito マイクロサービスのデプロイメントのトラブルシューティング

Operator を使用して Red Hat ビルドの Kogito マイクロサービスをデプロイする時に発生する可能性のある問題のトラブルシューティングを行うには、本セクションの情報を使用します。以下の情報は、新しい問題および回避策が検出されるたびに更新されています。

実行中のビルドがない

実行中のビルドや関連する namespace で作成されたリソースが表示されない場合は、以下のコマンドを実行して実行中の Pod を取得し、Pod の Operator ログを表示します。

指定の Pod に関する RHPAM Kogito Operator ログの表示

// Retrieves running pods
$ oc get pods

NAME                                     READY   STATUS      RESTARTS   AGE
kogito-operator-6d7b6d4466-9ng8t   1/1     Running     0          26m

// Opens RHPAM Kogito Operator log for the pod
$ oc logs -f kogito-operator-6d7b6d4466-9ng8t

KogitoRuntime のステータスを確認します。

たとえば、以下の YAML 定義を使用して、存在しないイメージを含めて KogitoRuntime アプリケーションを作成します。

KogitoRuntime アプリケーションの YAML 定義の例

apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
kind: KogitoRuntime # Application type
metadata:
  name: example # Application name
spec:
  image: 'not-existing-image:latest'
  replicas: 1

bash コンソールで oc describe KogitoRuntime example コマンドを使用して、KogitoRuntime アプリケーションのステータスを確認できます。bash コンソールで oc describe KogitoRuntime サンプルコマンドを実行すると、以下の出力が表示されます。

KogitoRuntime ステータスの例

[user@localhost ~]$ oc describe KogitoRuntime example
Name:         example
Namespace:    username-test
Labels:       <none>
Annotations:  <none>
API Version:  rhpam.kiegroup.org/v1
Kind:         KogitoRuntime
Metadata:
  Creation Timestamp:  2021-05-20T07:19:41Z
  Generation:          1
  Managed Fields:
    API Version:  rhpam.kiegroup.org/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:spec:
        .:
        f:image:
        f:replicas:
    Manager:      Mozilla
    Operation:    Update
    Time:         2021-05-20T07:19:41Z
    API Version:  rhpam.kiegroup.org/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:spec:
        f:monitoring:
        f:probes:
          .:
          f:livenessProbe:
          f:readinessProbe:
        f:resources:
        f:runtime:
      f:status:
        .:
        f:cloudEvents:
        f:conditions:
    Manager:         main
    Operation:       Update
    Time:            2021-05-20T07:19:45Z
  Resource Version:  272185
  Self Link:         /apis/rhpam.kiegroup.org/v1/namespaces/ksuta-test/kogitoruntimes/example
  UID:               edbe0bf1-554e-4523-9421-d074070df982
Spec:
  Image:     not-existing-image:latest
  Replicas:  1
Status:
  Cloud Events:
  Conditions:
    Last Transition Time:  2021-05-20T07:19:44Z
    Message:
    Reason:                NoPodAvailable
    Status:                False
    Type:                  Deployed
    Last Transition Time:  2021-05-20T07:19:44Z
    Message:
    Reason:                RequestedReplicasNotEqualToAvailableReplicas
    Status:                True
    Type:                  Provisioning
    Last Transition Time:  2021-05-20T07:19:45Z
    Message:               you may not have access to the container image "quay.io/kiegroup/not-existing-image:latest"
    Reason:                ImageStreamNotReadyReason
    Status:                True
    Type:                  Failed

出力の最後に、KogitoRuntime ステータスと該当するメッセージが表示されます。

パート III. Red Hat ビルドの Kogito マイクロサービスへの移行

ビジネス意思決定およびプロセスの開発者は、Red Hat Process Automation Manager のデシジョンサービスを Red Hat ビルドの Kogito マイクロサービスに移行できます。移行の実行時に、既存のビジネス意思決定は独自のドメイン固有のクラウドネイティブセットの一部となります。Decision Model and Notation(DMN)モデル、Predictive Model Markup Language(PMML)モデル、または Drools Rule Language(DRL)ルールを移行することができます。

前提条件

  • JDK 11 以降がインストールされている。
  • Apache Maven 3.6.2 以降がインストールされている。

第17章 Red Hat ビルドの Kogito マイクロサービスへの移行の概要

Business Central で開発したデシジョンサービスアーティファクトは、Red Hat ビルドの Kogito マイクロサービスに移行できます。Red Hat ビルドの Kogito は現在、以下のタイプのデシジョンサービスの移行をサポートしています。

  • DMN (Decision Model and Notation)モデル: DMN リソースを KJAR アーティファクトから適切な Red Hat ビルドの Kogito アーキタイプに移動して、DMN ベースのデシジョンサービスを移行します。
  • Predictive Model Markup Language(PMML)モデル: KJAR アーティファクトから対応する Red Hat ビルドの Kogito アーキタイプに PMML リソースを移動して、PMML ベースの予測および予測サービスを移行します。
  • Drools Rule Language(DRL)ルール: Red Hat ビルドの Quarkus REST エンドポイントでそれらを囲むことで、DRL ベースのデシジョンサービスを移行します。この移行アプローチにより、ホットリロードやネイティブコンパイルなど、Quarkus の主要な機能を使用できます。Quarkus 機能と Red Hat ビルドの Kogito のプログラミングモデルにより、アプリケーションとサービスに実装するための Quarkus REST エンドポイントを自動生成できます。

第18章 DMN サービスの Red Hat ビルドの Kogito マイクロサービスへの移行

DMN ベースのデシジョンサービスは、KJAR アーティファクトから適切な Red Hat ビルドの Kogito プロジェクトに移動することで、Red Hat ビルドの Kogito マイクロサービスに移行できます。Red Hat ビルドの Kogito マイクロサービスでは、KIE v7 機能の一部が不要になりました。

18.1. 主な変更および移行に関する考慮事項

以下の表は、KIE Server API および KJAR から Red Hat ビルドの Kogito デプロイメントへの移行に影響を与える主な変更および機能を示しています。

表18.1 dmn migration considerations

機能KIE Server API の場合Red Hat ビルドの Kogito アーティファクト

DMN モデル

KJAR の src/main/resources に保存されます。

以下のように src/main/resources にコピーします。

KIE Server の汎用マーシャリングに必要なオブジェクトモデル(POJO)

Business Central で Data Model オブジェクトエディターを使用して管理されます。

オブジェクトモデルの編集は不要になりました。

DMNRuntimeListener

システムプロパティーまたは kmodule.xml ファイルを使用して設定します。

DMNRuntimeEventListener に CDI の @ApplicationScope アノテーションを付けて CDI を使用して設定する必要があります。

その他の設定オプション

システムプロパティーまたは kmodule.xml ファイルを使用して設定します。

DMNRuntimeEventListener を除き、デフォルト値のみが考慮され、設定の上書きはサポートされません。

KIE Server クライアント API

KIE Server にデプロイされた KJAR と対話するために、オブジェクトモデルとともに使用します。

オブジェクトモデルでは、この機能は不要になりました。

注記

独自の REST ライブラリーを選択できます。

REST API

KJAR が KIE Server にデプロイされる場合、特定の DMN モデルエンドポイントと対話するアプリケーションは、Red Hat ビルドの Kogito デプロイメントにおいて同じ API を使用します。

特定の DMN モデル生成の高度なサポート。詳細は、「 DMN モデルの実行 」を参照してください。

テストシナリオ

JUnit activator を使用して実行します。

同様の JUnit activator は、Kogito の Red Hat ビルドで利用できます。

注記

上記の表で説明されていない機能は、cloud-native Red Hat ビルドの Kogito デプロイメントではサポートされません。

18.2. 移行ストラテジー

DMN プロジェクトを Red Hat ビルドの Kogito プロジェクトに移行する場合は、最初に KIE Server のデシジョンサービスと対話する外部アプリケーションを移行できます。DMN モデルに固有の REST エンドポイントを使用できます。REST エンドポイントを使用してから、外部アプリケーションを KIE Server から Red Hat ビルドの Kogito デプロイメントに移行できます。DMN モデルへの特定の REST エンドポイントの詳細は、「 特定の DMN モデルの REST エンドポイント 」を参照してください。

移行ストラテジーには、以下の手順が含まれます。

  1. KIE Server を使用して、既存の外部アプリケーションを汎用 KIE Server API から特定の DMN REST エンドポイントに移行します。
  2. KIE Server にデプロイされた KJAR を Red Hat ビルドの Kogito マイクロサービスに移行します。
  3. Red Hat OpenShift Container Platform を使用して Kogito マイクロサービスの Red Hat ビルドをデプロイします。
  4. 外部アプリケーションを再接続し、REST API の消費を特定の DMN REST エンドポイントから Red Hat ビルドの Kogito デプロイメントに移行します。

18.3. 外部アプリケーションの DMN モデル固有の REST エンドポイントへの移行

DMN プロジェクトを Red Hat ビルドの Kogito デプロイメントに移行するには、最初に特定の DMN REST エンドポイントを使用する外部アプリケーションを移行して KIE Server のデシジョンサービスと対話します。

手順

  1. 外部アプリケーションで REST エンドポイントを使用している場合は、GET /server/containers/{containerId}/dmn/openapi.json(|.yaml) エンドポイントを使用して KJAR の Swagger または OAS 仕様ファイルを取得します。

    特定の DMN モデルの REST エンドポイントの詳細は、「特定の DMN モデルの REST エンドポイント」を参照してください。

  2. 外部アプリケーションで、Java または JDK ライブラリーを選択して、デシジョンサービスと対話します。特定の KJAR の REST エンドポイントを使用してデシジョンサービスと対話できます。
注記

Red Hat ビルドの Kogito デプロイメントへの移行では、KIE Server Client Java API はサポートされません。

18.4. DMN モデル KJAR の Red Hat ビルドの Kogito マイクロサービスへの移行

外部アプリケーションの移行後に、DMN モデルに固有の KJAR を Red Hat ビルドの Kogito マイクロサービスに移行する必要があります。

手順

  1. Red Hat ビルドの Kogito マイクロサービス用の Maven プロジェクトを作成します。

    Maven プロジェクトの作成手順は、「Red Hat ビルドの Kogito マイクロサービス用の Maven プロジェクトの作成」 を参照してください。

    Maven プロジェクトは Kogito アーティファクトを作成します。

  2. KJAR の src/main/resources フォルダーから Kogito アーティファクトの src/main/resources フォルダーに DMN モデルをコピーします。
  3. テストシナリオを KJAR の src/test/resources フォルダーから Kogito アーティファクトの src/test/resources フォルダーにコピーします。

    重要

    プロジェクトの pom.xml ファイルに、テストシナリオの Red Hat ビルドの Kogito 依存関係をインポートし、KIE Server REST API を使用して JUnit アクティケーターを作成する必要があります。詳細は、『テストシナリオを使用したデシジョンサービスのテスト』を参照してください。

  4. 以下のコマンドを実行して、指定した回帰テストに対してテストシナリオが実行されていることを確認します。

    mvn clean install

    Red Hat ビルドの Kogito アプリケーションの実行後に、Swagger または OAS 仕様ファイルを取得できます。Swagger または OAS 仕様は、以下の実装の詳細と共に REST エンドポイントと同じ情報を提供します。

    • API が利用できるサーバーのベース URL
    • スキーマ名の参照

    外部アプリケーションを新しい URL に再ルーティングする場合には、指定の実装の詳細を使用できます。

DMN モデル KJAR を Red Hat ビルドの Kogito マイクロサービスに移行したら、Red Hat OpenShift Container Platform を使用してマイクロサービスをデプロイする必要があります。Openshift のデプロイメントオプションは、「RHPAM Kogito Operator を使用した OpenShift デプロイメントオプション 」を参照してください。

18.4.1. DMN モデル KJAR を Red Hat ビルドの Kogito マイクロサービスに移行する例

以下は、DMN モデル KJAR を Red Hat ビルドの Kogito マイクロサービスに移行する例です。

図18.1 DMN モデルを使用して実装したデシジョンサービスの例

Example of a DMN decision service

図18.2 特定の ItemDefinition 構造を使用した DMN モデルの例

Example of a DMN decision service using ItemDefinition structure

Business Central で開発した既存の KJAR で、オブジェクトモデル(POJO)を DTO として定義する必要があります。

KJAR で DTO として定義されたオブジェクトモデルの例

package com.myspace.demo20210321;

/**
 * This class was automatically generated by the data modeler tool.
 */

public class Reservation implements java.io.Serializable {

	static final long serialVersionUID = 1L;
	@com.fasterxml.jackson.annotation.JsonFormat(shape = com.fasterxml.jackson.annotation.JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd")
    @com.fasterxml.jackson.databind.annotation.JsonSerialize(using = com.fasterxml.jackson.datatype.jsr310.ser.LocalDateSerializer.class)
	private java.time.LocalDate checkin;
	@com.fasterxml.jackson.annotation.JsonFormat(shape = com.fasterxml.jackson.annotation.JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd")
    @com.fasterxml.jackson.databind.annotation.JsonSerialize(using = com.fasterxml.jackson.datatype.jsr310.ser.LocalDateSerializer.class)
	private java.time.LocalDate checkout;

	private java.util.List<java.lang.String> guests;

	public Reservation() {
	}

	public java.time.LocalDate getCheckin() {
		return this.checkin;
	}

	public void setCheckin(java.time.LocalDate checkin) {
		this.checkin = checkin;
	}

	public java.time.LocalDate getCheckout() {
		return this.checkout;
	}

	public void setCheckout(java.time.LocalDate checkout) {
		this.checkout = checkout;
	}

	public java.util.List<java.lang.String> getGuests() {
		return this.guests;
	}

	public void setGuests(java.util.List<java.lang.String> guests) {
		this.guests = guests;
	}

	public Reservation(java.time.LocalDate checkin,
			java.time.LocalDate checkout,
			java.util.List<java.lang.String> guests) {
		this.checkin = checkin;
		this.checkout = checkout;
		this.guests = guests;
	}

}

上記の例では、定義した DTO は KIE Server クライアント Java API と共に使用されます。または、Java 以外の外部アプリケーションが KIE Server にデプロイされた KJAR と対話している場合は、ペイロードで DTO を指定できます。

KIE Server クライアント Java API の使用例

DMNServicesClient dmnClient = kieServicesClient.getServicesClient(DMNServicesClient.class);
 DMNContext dmnContext = dmnClient.newContext();
 dmnContext.set("reservation", new com.myspace.demo20210321.Reservation(LocalDate.of(2021, 3, 1),
                                                                         LocalDate.of(2021, 3, 8),
                                                                         Arrays.asList("John", "Alice")));
 run(dmnClient, dmnContext);

図18.3 ペイロードで DTO を手動で指定する例

Example of KJAR deployed manually
注記

上記の例では、REST API のオブジェクトモデルの FQCN は汎用 KIE Server マーシャリングに使用されます。

18.5. 外部アプリケーションを Red Hat ビルドの Kogito デプロイメントにバインドする例

Red Hat ビルドの Kogito マイクロサービスをデプロイしたら、外部アプリケーションを Red Hat ビルドの Kogito マイクロサービスデプロイメントにバインドする必要があります。

外部アプリケーションをバインドするには、外部アプリケーションを再ルーティングし、アプリケーションを Red Hat ビルドの Kogito アプリケーションに関連付けられたサーバーの新しいベース URL にバインドします。詳細は、以下の例を参照してください。

図18.4 KIE Server 上の KJAR の /discount REST エンドポイントの例

Example of a DMN model specific REST endpoint of KJAR on KIE Server

図18.5 ローカルの Red Hat ビルドの Kogito の /discount REST エンドポイントの例

Example of a DMN model specific REST endpoint running on local Kogito application

図18.6 Red Hat ビルドの Kogito の新しいベース URL にバインドされる /discount REST エンドポイントの例

Example of a DMN model specific REST endpoint with new base URL

第19章 PMML サービスの Red Hat ビルドの Kogito マイクロサービスへの移行

PMML ベースのサービスは、KJAR アーティファクトから適切な Red Hat ビルドの Kogito プロジェクトに移動することで、Red Hat ビルドの Kogito マイクロサービスに移行できます。

19.1. 主な変更および移行に関する考慮事項

以下の表は、KIE Server API および KJAR から Red Hat ビルドの Kogito デプロイメントへの移行に影響を与える主な変更および機能を示しています。

表19.1 PMML 移行に関する考慮事項

機能KIE Server API の場合Red Hat ビルドの Kogito アーティファクト

PMML モデル

KJAR の src/main/resources に保存されます。

以下のように src/main/resources にコピーします。

その他の設定オプション

システムプロパティーまたは kmodule.xml ファイルを使用して設定します。

デフォルト値のみが考慮され、設定の上書きはサポートされません。

コマンドベースの REST API

ApplyPmmlModelCommand を使用して PMML 評価を要求します。

サポートされていません。

ドメイン駆動型 REST API

サポートされていません。

PMML モデル固有の生成の高度なサポート。

注記

上記の表で説明されていない機能は、cloud-native Red Hat ビルドの Kogito デプロイメントではサポートされません。

19.2. 移行ストラテジー

移行ストラテジーには、以下の手順が含まれます。

  1. KIE Server にデプロイされた KJAR を Red Hat ビルドの Kogito マイクロサービスに移行します。
  2. Red Hat OpenShift Container Platform を使用して Kogito マイクロサービスの Red Hat ビルドをデプロイします。
  3. KIE Server 上のクライアント PMML API から Red Hat ビルドの Kogito デプロイメントの REST API に外部アプリケーションを変更します。

19.3. PMML モデル KJAR の Red Hat ビルドの Kogito マイクロサービスへの移行

PMML モデルを使用して実装される KJAR を Red Hat ビルドの Kogito マイクロサービスに移行できます。

手順

  1. Red Hat ビルドの Kogito マイクロサービス用の Maven プロジェクトを作成します。

    Maven プロジェクトの作成手順は、「Red Hat ビルドの Kogito マイクロサービス用の Maven プロジェクトの作成」 を参照してください。

    Maven プロジェクトは Kogito アーティファクトを作成します。

  2. KJAR の src/main/resources フォルダーから Kogito アーティファクトの src/main/resources フォルダーに PMML モデルをコピーします。
  3. 以下のコマンドを実行して、Kogito アプリケーションの Red Hat ビルドを実行します。

    mvn clean install

    Red Hat ビルドの Kogito アプリケーションの実行後に、Swagger または OAS 仕様ファイルを取得できます。Swagger または OAS 仕様は、以下の実装の詳細と共に REST エンドポイントと同じ情報を提供します。

    • API が利用できるサーバーのベース URL
    • スキーマ名の参照

    外部アプリケーションを新しい URL に再ルーティングする場合には、指定の実装の詳細を使用できます。

PMML モデル KJAR を Red Hat ビルドの Kogito マイクロサービスに移行したら、Red Hat OpenShift Container Platform を使用してマイクロサービスをデプロイする必要があります。Openshift のデプロイメントオプションは、「RHPAM Kogito Operator を使用した OpenShift デプロイメントオプション 」を参照してください。

19.4. 外部アプリケーションの Red Hat ビルドの Kogito マイクロサービスへの変更

PMML マイクロサービスをデプロイしたら、外部アプリケーションを Red Hat ビルドの Kogito デプロイメントに変更する必要があります。

前提条件

  • 元の外部アプリケーションは、KIE Server クライアント API に実装する必要があります。

    図19.1 KIE Server での外部アプリケーション実装の例

    screen capture of the external application implementation on KIE Server

手順

  1. KIE Server クライアント API の使用状況をすべて削除し、HTTP 通信に置き換えます。以下は、Java 以外の要求の例です。

    Example non-java request
  2. 同様の呼び出しを作成し、結果を解析するために、HTTP クライアントの Java ライブラリーが外部アプリケーション内で使用されるようにしてください。

    以下は、入力データを JSON に変換する Java 11 HTTP クライアントおよび Gson の例です。

    Example of Java 11 HTTP client
    注記

    パラメーターの値として必要なすべてのパラメーターは、呼び出される URL に組み込まれます。

第20章 DRL サービスの Red Hat ビルドの Kogito マイクロサービスへの移行

Red Hat ビルドの Kogito でサンプルプロジェクトを構築してデプロイし、Red Hat ビルドの Quarkus REST エンドポイントでデシジョンエンジンのステートレスルール評価を公開し、REST エンドポイントを Red Hat ビルドの Kogito に移行できます。

ステートレスルール評価は、Red Hat Process Automation Manager のルールセットの 1 つの実行であり、関数呼び出しとして特定できます。呼び出された関数では、出力値は入力値を使用して決定されます。また、呼び出された関数は、デシジョンエンジンを使用してジョブを実行します。そのため、関数は REST エンドポイントを使用して公開され、マイクロサービスに変換されます。マイクロサービスへの変換後、関数は、JVM の起動時間を短縮するために Function as a Service 環境にデプロイされます。

20.1. 主な変更および移行に関する考慮事項

以下の表は、KIE Server API および KJAR から Red Hat ビルドの Kogito デプロイメントへの移行に影響を与える主な変更および機能を示しています。

表20.1 DRL 移行に関する考慮事項

機能KIE Server API の場合レガシー API サポートのある Kogito の Red Hat ビルドRed Hat ビルドの Kogito アーティファクト

DRL ファイル

KJAR の src/main/resources フォルダーに保存されます。

src/main/resources フォルダーにそのまま コピーします。

ルールユニットおよび OOPath を使用して書き換えます。

KieContainer

システムプロパティーまたは kmodule.xml ファイルを使用して設定します。

KieRuntimeBuilder に 置き換わります。

必須ではありません。

KieBase または KieSession

システムプロパティーまたは kmodule.xml ファイルを使用して設定します。

システムプロパティーまたは kmodule.xml ファイルを使用して設定します。

ルールユニットに置き換えられます。

20.2. 移行ストラテジー

Red Hat Process Automation Manager では、以下の 2 つの方法で、ルール評価を Red Hat ビルドの Kogito デプロイメントに移行できます。

Red Hat ビルドの Kogito でのレガシー API の使用
Red Hat ビルドの Kogito では、kogito-legacy-api モジュールが Red Hat Process Automation Manager のレガシー API を使用できるようにするため、DRL ファイルは変更されません。ルール評価の移行には最小限の変更が必要で、ホットリロードやネイティブイメージの作成など、Red Hat ビルドの Quarkus の主要な機能を使用できます。
Red Hat ビルドの Kogito ルールユニットへの移行

Red Hat ビルドの Kogito ルールユニットへの移行には、ルールユニットの概念に基づく、Red Hat ビルドの Kogito のプログラミングモデルが含まれます。

Red Hat ビルドの Kogito のルールユニットには、ルールのセットと、ルールが照合されるファクトの両方が含まれます。Red Hat ビルドの Kogito のルールユニットにはデータソースも含まれます。ルールユニットデータソースは、指定のルールユニットで処理されるデータのソースで、ルールユニットの評価に使用されるエントリーポイントを表します。ルールユニットは、2 種類のデータソースを使用します。

  • datastream: これは、追加のみのデータソースで、DataStream に追加されたファクトは更新または削除することができません。
  • データストア: このデータソースは変更可能なデータ用です。オブジェクトが DataStore に追加されるときに返される FactHandle を使用して、オブジェクトを更新または削除できます。

全体的に、ルールユニットには、評価するファクトの定義と、ファクトを評価する一連のルールが含まれます。

20.3. ローン申し込みプロジェクトの例

以下のセクションでは、ローン申請プロジェクトを例として使用し、DRL プロジェクトを Red Hat ビルドの Kogito デプロイメントに移行します。ローン申し込みプロジェクトのドメインモデルは、LoanApplication クラスと Applicant クラスの 2 つのクラスで構成されています。

LoanApplication クラスの例

public class LoanApplication {

   private String id;
   private Applicant applicant;
   private int amount;
   private int deposit;
   private boolean approved = false;

   public LoanApplication(String id, Applicant applicant,
                      	int amount, int deposit) {
   	this.id = id;
   	this.applicant = applicant;
   	this.amount = amount;
   	this.deposit = deposit;
   }
}

Applicant クラスの例

public class Applicant {

   private String name;
   private int age;

   public Applicant(String name, int age) {
   	this.name = name;
   	this.age = age;
   }
}

ルールセットは、ビジネスデシジョンを使用してアプリケーションを承認または拒否し、承認済みの全アプリケーションをリストで収集する最後のルールと共に作成されます。

ローン申し込みのルールセットの例

global Integer maxAmount;
global java.util.List approvedApplications;

rule LargeDepositApprove when
   $l: LoanApplication( applicant.age >= 20, deposit >= 1000, amount <= maxAmount )
then
   modify($l) { setApproved(true) }; // loan is approved
end

rule LargeDepositReject when
   $l: LoanApplication( applicant.age >= 20, deposit >= 1000, amount > maxAmount )
then
   modify($l) { setApproved(false) }; // loan is rejected
end

// ... more loans approval/rejections business rules ...

rule CollectApprovedApplication when
   $l: LoanApplication( approved )
then
   approvedApplications.add($l); // collect all approved loan applications
end

20.3.1. Red Hat ビルドの Quarkus を使用した REST エンドポイントでのルール評価の公開

Red Hat ビルドの Quarkus を使用して、REST エンドポイントで Business Central で開発したルール評価を公開することができます。

手順

  1. ルールおよび Quarkus ライブラリーが含まれるモジュールに基づいて新しいモジュールを作成し、REST サポートを提供します。

    新しいモジュールを作成する依存関係の例

    <dependencies>
    
     <dependency>
       <groupId>io.quarkus</groupId>
       <artifactId>quarkus-resteasy</artifactId>
     </dependency>
     <dependency>
       <groupId>io.quarkus</groupId>
       <artifactId>quarkus-resteasy-jackson</artifactId>
     </dependency>
    
     <dependency>
       <groupId>org.example</groupId>
       <artifactId>drools-project</artifactId>
       <version>1.0-SNAPSHOT</version>
     </dependency>
    
    <dependencies>

  2. REST エンドポイントを作成します。

    以下は、REST エンドポイントを作成する設定例です。

    FindApprovedLoansEndpoint エンドポイントの設定例

    @Path("/find-approved")
    public class FindApprovedLoansEndpoint {
    
       private static final KieContainer kContainer = KieServices.Factory.get().newKieClasspathContainer();
    
       @POST()
       @Produces(MediaType.APPLICATION_JSON)
       @Consumes(MediaType.APPLICATION_JSON)
       public List<LoanApplication> executeQuery(LoanAppDto loanAppDto) {
       	KieSession session = kContainer.newKieSession();
    
       	List<LoanApplication> approvedApplications = new ArrayList<>();
       	session.setGlobal("approvedApplications", approvedApplications);
       	session.setGlobal("maxAmount", loanAppDto.getMaxAmount());
    
       	loanAppDto.getLoanApplications().forEach(session::insert);
       	session.fireAllRules();
       	session.dispose();
    
       	return approvedApplications;
       }
    }

    上記の例では、ルールを含む KieContainer が作成され、静的フィールドに追加されます。KieContainer のルールは、クラスパス内の他のモジュールから取得されます。この方法では、ルールを再コンパイルせずに FindApprovedLoansEndpoint エンドポイントに関連する後続の呼び出しで同じ KieContainer を再利用できます。

    注記

    この 2 つのモジュールは、レガシー API を使用してルールユニットを Red Hat ビルドの Kogito マイクロサービスに移行する次のプロセスで統合されます。詳細は、「 レガシー API を使用した DRL ルールユニットの Red Hat ビルドの Kogito マイクロサービスへの移行 」を参照してください。

    FindApprovedLoansEndpoint エンドポイントが呼び出されると、KieContainer から新しい KieSession が作成されます KieSession には、LoanApp Dto のオブジェクトが入力され、JSON リクエストのアンマーシャリングになります。

    LoanAppDto クラスの例

    public class LoanAppDto {
    
       private int maxAmount;
    
       private List<LoanApplication> loanApplications;
    
       public int getMaxAmount() {
       	return maxAmount;
       }
    
       public void setMaxAmount(int maxAmount) {
       	this.maxAmount = maxAmount;
       }
    
       public List<LoanApplication> getLoanApplications() {
       	return loanApplications;
       }
    
       public void setLoanApplications(List<LoanApplication> loanApplications) {
       	this.loanApplications = loanApplications;
       }
    }

    fireAllRules() メソッドが呼び出されると、KieSession が実行され、ビジネスロジックが入力データに対して評価されます。ビジネスロジックの評価後、最後のルールは一覧で承認されたアプリケーションをすべて収集し、出力と同じリストを返します。

  3. Red Hat ビルドの Quarkus アプリケーションを起動します。
  4. 確認するローンアプリケーションが含まれる JSON 要求で FindApprovedLoansEndpoint エンドポイントを呼び出します。

    maxAmount の値は、以下の例のようにルールで使用されます。

    curl 要求例

    curl -X POST -H 'Accept: application/json' -H 'Content-Type: application/json' -d '{"maxAmount":5000,
    "loanApplications":[
    {"id":"ABC10001","amount":2000,"deposit":1000,"applicant":{"age":45,"name":"John"}}, {"id":"ABC10002","amount":5000,"deposit":100,"applicant":{"age":25,"name":"Paul"}}, {"id":"ABC10015","amount":1000,"deposit":100,"applicant":{"age":12,"name":"George"}}
    ]}' http://localhost:8080/find-approved

    JSON の応答例

    [
      {
        "id": "ABC10001",
        "applicant": {
          "name": "John",
          "age": 45
        },
        "amount": 2000,
        "deposit": 1000,
        "approved": true
      }
    ]

注記

この方法では、ホットリロード機能を使用できないため、プロジェクトのネイティブイメージを作成できません。次の手順では、欠落していた Quarkus 機能は Kogito エクステンションによって提供されます。これにより、Quarkus は DRL ファイルを認識し、ホットリロード機能を同様の方法で実装します。

20.3.2. レガシー API を使用した Red Hat ビルドの Kogito マイクロサービスへのルール評価の移行

REST エンドポイントでルール評価を公開したら、レガシー API を使用してルール評価を Red Hat ビルドの Kogito マイクロサービスに移行できます。

手順

  1. プロジェクトの pom.xml ファイルに以下の依存関係を追加して、Red Hat ビルドの Quarkus およびレガシー API を使用できるようにします。

    Quarkus およびレガシー API を使用する依存関係の例

    <dependencies>
     <dependency>
      <groupId>org.kie.kogito</groupId>
      <artifactId>kogito-quarkus-rules</artifactId>
     </dependency>
     <dependency>
      <groupId>org.kie.kogito</groupId>
      <artifactId>kogito-legacy-api</artifactId>
     </dependency>
    </dependencies>

  2. REST エンドポイント実装を書き換えます。

    REST エンドポイント実装の例

    @Path("/find-approved")
    public class FindApprovedLoansEndpoint {
    
       @Inject
       KieRuntimeBuilder kieRuntimeBuilder;
    
       @POST()
       @Produces(MediaType.APPLICATION_JSON)
       @Consumes(MediaType.APPLICATION_JSON)
       public List<LoanApplication> executeQuery(LoanAppDto loanAppDto) {
       	KieSession session = kieRuntimeBuilder.newKieSession();
    
       	List<LoanApplication> approvedApplications = new ArrayList<>();
       	session.setGlobal("approvedApplications", approvedApplications);
       	session.setGlobal("maxAmount", loanAppDto.getMaxAmount());
    
       	loanAppDto.getLoanApplications().forEach(session::insert);
       	session.fireAllRules();
       	session.dispose();
    
       	return approvedApplications;
       }
    }

    書き換えられた REST エンドポイント実装では、KieContainer から KieSession を作成する代わりに 統合 KieRuntimeBuilder を使用して KieSession が自動的に作成されます。

    KieRuntimeBuilder は、KieContainer に代わる kogito-legacy-api モジュールが提供するインターフェースです KieRuntimeBuilder を使用すると、KieContainer で同様の方法で KieBase と KieSession を作成できます Red Hat ビルドの Kogito はコンパイル時に KieRuntimeBuilder インターフェースの実装を自動的に生成し、KieRuntime Builder をクラスに統合して FindApprovedLoansEndpoint REST エンドポイントを実装します。

  3. 開発モードで Red Hat ビルドの Quarkus アプリケーションを起動します。

    ホットリロードを使用して、実行中のアプリケーションに適用されるルールファイルに変更を加えることもできます。また、ルールベースのアプリケーションのネイティブイメージを作成することもできます。

20.3.3. ルールユニットおよび自動 REST エンドポイント生成の実装

ルールユニットを Red Hat ビルドの Kogito マイクロサービスに移行したら、REST エンドポイントのルールユニットおよび自動生成を実装できます。

Red Hat ビルドの Kogito では、ルールユニットに一連のルールとファクトが含まれ、ルールが一致します。Red Hat ビルドの Kogito のルールユニットにはデータソースも含まれます。ルールユニットデータソースは、指定のルールユニットで処理されるデータのソースで、ルールユニットの評価に使用されるエントリーポイントを表します。ルールユニットは、2 種類のデータソースを使用します。

  • datastream: これは、追加のみのデータソースです。DataStream では、サブスクライバーは新しいメッセージおよび過去のメッセージを受信すると、ストリームはリアクティブストリームでホットまたはコールドにすることができます。また、DataStream に追加されたファクトは更新または削除できません。
  • データストア: このデータソースは変更可能なデータ用です。オブジェクトが DataStore に追加されるときに返される FactHandle を使用して、オブジェクトを更新または削除できます。

全体的に、ルールユニットには、評価するファクトの定義と、ファクトを評価する一連のルールが含まれます。

手順

  1. POJO を使用してファクト定義を実装します。

    POJO を使用したファクト定義の実装例

    package org.kie.kogito.queries;
    
    import org.kie.kogito.rules.DataSource;
    import org.kie.kogito.rules.DataStore;
    import org.kie.kogito.rules.RuleUnitData;
    
    public class LoanUnit implements RuleUnitData {
    
       private int maxAmount;
       private DataStore<LoanApplication> loanApplications;
    
       public LoanUnit() {
       	this(DataSource.createStore(), 0);
       }
    
       public LoanUnit(DataStore<LoanApplication> loanApplications, int maxAmount) {
       	this.loanApplications = loanApplications;
       	this.maxAmount = maxAmount;
       }
    
       public DataStore<LoanApplication> getLoanApplications() { return loanApplications; }
    
       public void setLoanApplications(DataStore<LoanApplication> loanApplications) {
       	this.loanApplications = loanApplications;
       }
    
       public int getMaxAmount() { return maxAmount; }
       public void setMaxAmount(int maxAmount) { this.maxAmount = maxAmount; }
    }

    上記の例では、LoanApp Dto を使用して LoanUnit クラスを直接バインドします。LoanAppDto は、JSON リクエストをマーシャリングまたはアンマーシャリングするために使用されます。また、上記の例では、org .kie.kogito.rules.RuleUnitData インターフェースを実装し、DataStore を使用して承認するローンアプリケーションを追加します。

    org.kie.kogito.rules.RuleUnitData はマーカーインターフェースで、Loan Unit クラスがルールユニット定義の一部であることをデシジョンエンジンに通知します。さらに、DataStore は、新しいルールを実行し、他のルールをトリガーして、ルールエンジンが変更に対応できるようにします。

    また、ルールの結果は、前の例で 承認された プロパティーを変更します。その間、max Amount の値はルールユニットの設定パラメーターとして考慮され、これは変更されません。maxAmount は、ルールの評価時に自動的に処理され、JSON リクエストに渡される値から自動的に設定されます。

  2. DRL ファイルを実装します。

    DRL ファイルの実装例

    package org.kie.kogito.queries;
    unit LoanUnit; // no need to using globals, all variables and facts are stored in the rule unit
    
    rule LargeDepositApprove when
       $l: /loanApplications[ applicant.age >= 20, deposit >= 1000, amount <= maxAmount ] // oopath style
    then
       modify($l) { setApproved(true) };
    end
    
    rule LargeDepositReject when
       $l: /loanApplications[ applicant.age >= 20, deposit >= 1000, amount > maxAmount ]
    then
       modify($l) { setApproved(false) };
    end
    
    // ... more loans approval/rejections business rules ...
    
    // approved loan applications are now retrieved through a query
    query FindApproved
       $l: /loanApplications[ approved ]
    end

    作成する DRL ファイルは、ファクト定義実装と同じパッケージと、Java クラスの同じ名前を持つユニットを宣言する必要があります。Java クラスは、インターフェースが同じルールユニットに属する状態に RuleUnitData インターフェースを実装します。

    また、前述の例の DRL ファイルは OOPath 式を使用して書き換えられます。DRL ファイルのデータソースはエントリーポイントとして機能し、OOPath 式には root としてデータソース名が含まれます。ただし、制約は以下のように角括弧に追加されます。

    $L: /loanApplications[ applicant.age >= 20, deposit >= 1000, amount\":\" maxAmount ]

    または、標準の DRL 構文を使用できます。この構文では、データソース名をエントリーポイントとして指定することができます。ただし、以下の例のように、デシジョンエンジンがデータソースからタイプを推測できる場合でも、一致するオブジェクトのタイプを再度指定する必要があります。

    $L: LoanApplication(applicant.age >= 20, deposit >= 1000, amount-7.4.0- maxAmount)from entry-point loanApplications

    上記の例では、承認されたローンアプリケーションをすべて収集する最後のルールは、リストを取得するクエリーに置き換えられます。ルールユニットは、ルールを評価するために入力で渡されるファクトを定義し、クエリーはルール評価からの予想される出力を定義します。この方法では、Red Hat ビルドの Kogito はクエリーを実行し、以下の例のように出力を返すクラスを自動的に生成できます。

    LoanUnitQueryFindApproved クラスの例

    public class LoanUnitQueryFindApproved implements org.kie.kogito.rules.RuleUnitQuery<List<org.kie.kogito.queries.LoanApplication>> {
    
       private final RuleUnitInstance<org.kie.kogito.queries.LoanUnit> instance;
    
       public LoanUnitQueryFindApproved(RuleUnitInstance<org.kie.kogito.queries.LoanUnit> instance) {
       	this.instance = instance;
       }
    
       @Override
       public List<org.kie.kogito.queries.LoanApplication> execute() {
       	return instance.executeQuery("FindApproved").stream().map(this::toResult).collect(toList());
       }
    
       private org.kie.kogito.queries.LoanApplication toResult(Map<String, Object> tuple) {
       	return (org.kie.kogito.queries.LoanApplication) tuple.get("$l");
       }
    }

    以下は、ルールユニットを入力として取り、入力をクエリーエグゼキューターに渡して出力を返す REST エンドポイントの例になります。

    LoanUnitQueryFindApprovedEndpoint エンドポイントの例

    @Path("/find-approved")
    public class LoanUnitQueryFindApprovedEndpoint {
    
       @javax.inject.Inject
       RuleUnit<org.kie.kogito.queries.LoanUnit> ruleUnit;
    
       public LoanUnitQueryFindApprovedEndpoint() {
       }
    
       public LoanUnitQueryFindApprovedEndpoint(RuleUnit<org.kie.kogito.queries.LoanUnit> ruleUnit) {
       	this.ruleUnit = ruleUnit;
       }
    
       @POST()
       @Produces(MediaType.APPLICATION_JSON)
       @Consumes(MediaType.APPLICATION_JSON)
       public List<org.kie.kogito.queries.LoanApplication> executeQuery(org.kie.kogito.queries.LoanUnit unit) {
       	RuleUnitInstance<org.kie.kogito.queries.LoanUnit> instance = ruleUnit.createInstance(unit);
       	return instance.executeQuery(LoanUnitQueryFindApproved.class);
       }
    }

    注記

    複数のクエリーを追加でき、クエリーごとに異なる REST エンドポイントが生成されます。たとえば、find Approved REST エンドポイントが find-approved 用に生成されます。

第21章 関連資料

付録A バージョン情報

本ドキュメントの最終更新日: 2022 年 1 月 12 日(水)

付録B お問い合わせ先

Red Hat Process Automation Manager のドキュメントチーム: brms-docs@redhat.com