Huawei Cloud Digital Factory Platformの論理モデルオーケストレーターの解釈と例

要約: この号では、「生産実行管理」のケースシナリオに含まれる関連するビジネス活動プロセスに基づいて、Huawei Cloud Digital Factory Platformの論理モデルオーケストレーターの使用方法を体系的に紹介します。

この記事は、HUAWEI CLOUD コミュニティ「デジタルファクトリーの徹底簡単シリーズ (3): 論理モデルオーケストレーターの使用入門」 (著者: Yunqi MAE) から共有されたものです。

ファーウェイクラウドデジタルファクトリープラットフォームの製造アプリケーションエンジン（Manufacturing App Engine、以下MAEエンジン）は、リアルタイムのイベント駆動型アーキテクチャを採用しています。HUAWEI CLOUD Digital Factory Platform MAE エンジンは、強力で使いやすいロジックフローオーケストレーションツール、ルールエンジン、データフローエンジンを提供し、ビジネスオブジェクトのステータス変化をリアルタイムで感知し、データ分析、処理、データ間の転送を自動的にトリガーします。さまざまなビジネスオブジェクト。ロジックフローオーケストレーションツールはビジネスオブジェクトの情報モデルと自然に統合されており、ビジネス担当者はビジネスプロセスの処理に必要なコンテキスト情報を理解し、迅速に整理し、システムの変化に応じてデジタルシステムのビジネスロジックプロセスを調整することもできます。これにより、デジタルシステムはますます柔軟になる生産ビジネスプロセスに真に適応し、機敏で柔軟な構成を実現し、ビジネスニーズに応じたデジタルアプリケーションの構築とアップグレードを実現できます。

HUAWEI CLOUD デジタルファクトリープラットフォームの MAE エンジンの論理フローは、次の 3 種類のノードで構成されます。

トリガー: ロジックフローエンジンのトリガーソース。データ変更 (作成/変更)、ユーザー操作、IoT メッセージ、ビジネスデータ/IoT デバイスの変化を感知して応答できる定期計画の 4 つのトリガータイプをサポートします。データとユーザーをリアルタイムで操作を実行します。
ルールエンジン: ビジネスルールをモデル化して構成し、複雑なネストされたルール条件、リアルタイムの動的な計算と判断をサポートし、ビジネスフローのコンプライアンス実行を推進します。
アクション実行者: ビジネスフローの実行結果。次の 4 種類のアクションをサポートします。ビジネスフロー (ビジネスオブジェクト A のロジックフローの実行結果。ビジネスオブジェクト B のロジックフローの実行をトリガーします)、イベントレコード (イベントレコードの作成または関連するビジネスオブジェクトデータのバックフィル)、メッセージ通知 (ビジネスメッセージのアクティブな通知: システム通知/電子メール/SMS/IM ツールなど)、および外部統合 (外部システム API の呼び出し、外部システムビジネスフローのトリガー) 。

この号では、前号の「生産実行管理」シナリオケースをベースにさらに展開し、ファーウェイクラウドデジタルファクトリープラットフォームの「論理モデル」オーケストレーターの使用方法を詳しく紹介します。

(1) ケースシナリオの説明

このシナリオケースでは、以下の4つのビジネスロジックフローの整理と運用を実装することで、「生産実行管理」に関わる関連するビジネスオブジェクト間のオンデマンドの自動データの流れを実現する必要があります。

プロセスタスクオーダー生成：製造オーダーを作成する際、製造オーダーのプロセスルート情報に従って、プロセスルートの下のプロセスステップに従って製造オーダーを自動的に分解して生成します。
生産資材所要量の生成: 製造オーダーの製品および計画出力情報に従って、製造オーダーに「資材所要量リストの生成」操作を提供し、製品の製造 BOM 内の資材リストデータに従って資材所要量リストを自動的に生成します。 ;
製造オーダーのクローズ: 製造オーダーに「製造オーダーをクローズする」操作を提供します。ユーザーは操作時に「クローズ理由」を入力し、製造オーダーとその下のプロセスオーダーのステータスを「クローズ」に更新する必要があります。 ;
完成入庫商品・倉庫在庫更新：ユーザーが「完了入庫伝票」を提出・確認後、完成入庫伝票上の「商品」「倉庫」「数量」に応じて、「完了入庫伝票」を自動的に書き戻して更新します。「手持在庫」と、対応する倉庫内の製品の「手持在庫」。

(2) 正式な建設手順

以下では、HUAWEI CLOUD Digital Factory Platform MAE エンジンのロジックオーケストレーターを使用して、このシナリオで 4 つのビジネスロジックフローを実装する方法を説明します。

2.1. 関連情報モデルの準備:

前号では、Huawei Cloud Digital Factory Platformの情報コンフィギュレーターの使用方法を紹介したときに、次のビジネスオブジェクトの情報モデルの構成を完了しました:生産オーダー、プロセスタスクオーダー、資材需要オーダー。 4番目の業務フロー「在庫更新」では、「完了受領書」の情報モデルを完成させるために設定を補足する必要があります。

「トランザクション」モデルビルダーで、「生産」ドメインタブを選択し、既存のビジネスシナリオ「生産管理」を作成または使用し、ビジネスシナリオに新しいトランザクションモデル「完了受領」を作成します。

「完了受領書」の情報モデルフィールドの設定方法については、前号で紹介した情報コンフィギュレータの利用方法を参照してくださいので、ここでは説明しません。

2.2. 本番実行関連のビジネスロジックフローモデリング:

HUAWEI CLOUD Digital Factory Platformの「モデリングワークベンチ」で、ユーザーは「トランザクション」モデルビルダーを使用して対応するトランザクションモデルを選択し、トランザクションモデルの「論理モデル」に必要な論理プロセスを作成して公開します。

通常、トリガーソースのトランザクションモデル配下に対応するロジックフローを作成して業務フローの処理を完了させますが、ロジックフロー実行時には、トリガーソースモデルのインスタンスデータを入力情報として自動的に取り込み、ロジックフローでは、トリガーソースビジネスオブジェクトからターゲットビジネスオブジェクトへのデータの自動処理フローを実現するために、ソースモデルと情報関連付け関係を持つ他のビジネスモデルに必要に応じて接続することを選択できます。

論理フローモデルは主に次の操作を提供します。

a. 編集: 論理フローの名前、優先順位、ステータスなどの基本情報を変更します。

b. 有効化: ロジックフローを有効または無効にします。

c. 構成: 論理フローオーケストレーターを開き、論理フローの実行ロジックを構成します。

d. コピー: 現在の論理フローをコピーし、新しい論理フローを作成します。

e. ログ: 論理フローの動作履歴ログを表示し、論理フローの特定の操作の詳細なログを参照して、異常の原因を診断することができます。フローが異常な場合、「再試行」操作の実行による再試行をサポートします。

ロジックフロー 1: 製造オーダーの作成とプロセスオーダーの生成

「製造オーダー」モデルの「論理モデル」の下にある「新規プロセス」ボタンを操作して、論理フロー「プロセスオーダーの生成」を追加します。

追加が完了したら、論理フローの右側にある [構成] 操作をクリックして論理フローオーケストレーターを開き、論理フローの実行ロジックを構成します。

(1) トリガーの設定

トリガーは、実行するロジックフローをトリガーするために使用されます。Logic Orchestrator は現在、次のトリガータイプをサポートしており、実際のビジネスニーズに応じて、対応するトリガータイプを選択します。

a. データ作成: 選択したトリガーオブジェクトモデルのデータインスタンスが作成されると、ロジックフローの実行が自動的にトリガーされます。

b. データ変更: 選択したトリガーオブジェクトモデルデータインスタンスに設定されているいくつかのフィールドの値が変更されると、ロジックフローの実行が自動的にトリガーされます。

c. ユーザー操作: ユーザーがフロントエンドインターフェイスにいるとき、操作は現在のモデルによって定義された「ユーザー操作」ボタンを実行し、ロジックフローの実行を自動的にトリガーします。

d. タイミングトリガー: タイミングプラン戦略に従ってトリガーされ、タスクの実行サイクル (時間/日/週/月/年)、プランの有効期間範囲 (開始日/終了日) などを設定する必要があり、自動的に実行されます。計画戦略に従って定期的にスケジュールを設定し、ロジックフローの実行をトリガーします。「タイミングトリガー」のロジックフローは、特定の条件に従ってデータモデルをトリガーするデータインスタンスの範囲をフィルターするための「フィルタールール」の構成をサポートします。

トリガーの「トリガーオブジェクト」は、現在のビジネスモデルのメイン情報モデルとそのサブ情報モデルの選択をサポートします (たとえば、「製品」モデルの下に作成されたロジックフローのトリガーオブジェクト、「製品情報」のマスターデータモデル、または「部品表/部品表」などのサブモデルが選択可能）、ロジックフロー実行時に「トリガーオブジェクト」で選択したビジネスモデルのデータインスタンス情報が自動配置されますロジックフローの入力情報コンテキスト内で使用され、後続のロジックフローで使用できます。ルールノードまたはアクションノードで使用されます。

「製造オーダー」を作成後、ユーザーは製造オーダーを工程データに自動分解し、製造オーダーの工程ルートに応じた工程オーダーを生成する必要があります。「トリガータイプ」で「データ作成」を選択し、「」を選択します。トリガーオブジェクトの「製造オーダー」。ビジネス上の意味を持つトリガー名「製造オーダーの作成」を入力します。

(2) アクションノードの作成

作成した「トリガー」の後ろにある「+」アイコンをクリックし、「アクションの追加(現在)」または「アクションの追加(ブランチ)」を選択してアクションノードを作成します。前者は前のノード(トリガーノード)の後ろにあります。前のノードと並行して作成されたアクションノードのブランチであるアクションノードを作成します。

ロジックフローの「アクション」ノードには主に以下の2つの構成項目があります。

出力タイプ: 現在、データの作成、データの更新、パイプラインキャッシュ、およびメッセージ通知の 4 つの出力タイプをサポートしています。そのうちの「データの作成」と「データの更新」は、システムの関連する上流および下流のビジネスオブジェクトのデータを作成または更新するために使用されます。現在のトリガーオブジェクトモデル。「パイプラインキャッシュ」は、論理フローの後続のノード (ルール/アクション) のデータ入力として現在のアクションノードの実行結果データを一時的にキャッシュするために使用されます。「メッセージ通知」は、アクティブにメッセージを送信するために使用されます。ロジックフロー操作の結果データをユーザーに通知するメッセージ。
出力モデル: トリガーオブジェクトモデルに関連付けられたすべてのビジネスモデルと、アクションノードの処理後に新しく追加されたビジネスモデルを選択できます。

ロジックフローの入力モデル (つまり、「製造オーダー」などのトリガーオブジェクト)、およびプロセス処理後のパイプライン内のモデル (たとえば、製造オーダーは「製品」や「」などのモデルに関連付けられます)ロジックフローアクションノードの「プロセスルート」);
上記b1モデルのサブモデル(「製品」のサブモデル「在庫入出庫記録」など)と親モデル。
上記のb1モデルの関連モデル、つまり、あるビジネスモデルの情報フィールドがb1モデルに関連付けられている場合、例えばb1モデルが「製造オーダー」であり、「資材」の情報フィールドが関連付けられているとします。「要求リスト」モデルを「製造オーダー」モデルに関連付け、資材要求オーダーモデルに選択可能なモデルを出力します。

アクション・ノードの作成時に出力モデルとして必要なビジネス・モデルを選択できない場合は、一時的に空白のままにし、アクション・ノードにデータ変換ロジックを配置して関連する他のビジネス・オブジェクト・モデルを連続して補完した後、必要なビジネス・モデルを選択できます。モデル、ビジネスモデル。

「製造オーダー」を作成した後、ユーザーは製造オーダーのルーティングに従って自動的にそれを分解し、対応するプロセスオーダーデータを作成し、「出力タイプ」で「データ作成」を選択し、「プロセスオーダー」を選択します。出力モデルの場合、最後に、「プロセスタスクの作成」というビジネスを意味するアクション名を入力します。

(3) アクションノードのデータ変換ロジックを設定する

アクションノードを追加して作成した後、「アクションコンフィギュレーター」に入り、ターゲット出力モデルのデータ要件を満たすために実際のビジネスニーズに応じてアクションコンフィギュレーターで「データ変換ロジック」をさらに調整します。

「Action Configurator」には以下の3つの設定項目があります。

入力データフィールドの表示: 左側には、現在のアクションノードの入力データ情報フィールドが表示されます。入力情報は主に、前のロジックフローノードの出力データフィールドと、ユーザー操作によって定義された入力パラメータフィールドから得られます。
データ変換の論理的配置: 現在、4 種類のデータ変換演算子ノードが提供されています。

関連ノード: 前のデータ変換ノードの入力データまたは出力データに関連付けられている他のビジネスオブジェクトのデータフィールドを取得するために使用されます。

分割ノード:前のデータ変換ノードの入力データまたは出力データのサブモデルデータを取得するために使用されます。

計算ノード:入力データまたは前のデータ変換ノードの出力データの数値フィールド値に対して四則演算を実行したり、データ処理の標準関数を参照したりするために使用されます。

集約ノード:特定のディメンションフィールドに従って、前のデータ変換ノードの入力データまたは出力データを要約するために使用されます。

実際のビジネスニーズに応じて、4種類のデータ変換演算子ノードを柔軟に組み合わせて配置し、現在のアクションノードの最終出力データ結果の要件を満たすように、アクションノードの入力データのデータ変換と処理を実現します。

3. 出力データフィールドのマッピング: アクションノードは「データ変換」によって処理された後、データパイプラインのデータフィールドにキャッシュされ、出力モデルのフィールド値にマッピングされます。モデルのフィールド値を出力し、定数値の手動入力、標準関数の計算結果およびシステム変数 (システム時間、現在のログイン担当者など) の参照もサポートします。

ビジネス要件に従って、製造オーダーは、その生産プロセスルートのプロセスステップに従って分割する必要があり、対応するプロセスタスクオーダーデータを「プロセスタスクの作成」アクションノードで作成する必要があります。

a. 関連ノード「関連ルーティング」を追加して、入力「製造オーダー」データ関連付けから関連する「処理ルート」マスターデータを取得します。

関連する変換ノードには、次の 3 つの構成領域があります。

ソースモデル:アクションノードの入力データまたは以前のデータ変換ノードの出力データから、関連する変換ノードの入力ソースデータとして必要なモデルを選択します。たとえば、現在のケースシナリオでは、「製造オーダー」を選択します。「ソースモデル」の場合。
ターゲットモデル:関連付け変換ノードによって選択された「ソースモデル」ビジネスオブジェクトに従って、このビジネスオブジェクトのデータモデルに関連付けられている他のビジネスオブジェクトのデータモデルを選択できます。ロジックフローの実行中に、入力された「ソースモデル」に基づく必要があります。「データインスタンスは、選択されたターゲット関連付けモデルのデータインスタンスを順番に自動的に取得します。たとえば、現在のケースシナリオの場合、「ターゲット関連付けモデル」は、次のような「プロセスルート」を選択します。「製造オーダー」に関連付けられています。
ターゲットフィールド:関連付けられた変換ノードによって返される必要がある、出力「ターゲットモデル」の特定のデータフィールド範囲を構成します。たとえば、現在のケースのシナリオでは、「ターゲットフィールド」は、変換ノードから返される必要があるフィールド範囲を選択します。「処理ルート」データ。

b. 関連するノード変換の前のステップによって出力された「プロセスルート」データに基づいて、分割変換ノード「プロセスプロシージャを展開」を追加し、「プロセスルート」の下にある「プロセスプロセス」サブモデルデータをさらに取得します。「データ分割を実現するためのデータの変換:

スプリット変換ノードには以下の 3 つの設定項目があります。

ソースモデル:分割変換ノードの入力ソースデータとして、アクションノードの入力データまたは前のデータ変換ノードの出力データから必要なモデルを選択します。たとえば、現在のケースシナリオの場合、「ソースモデル」以前に関連付けられたノードの出力「ルート」を選択します。
ターゲット・モデル:関連する変換ノードによって選択された「ソース・モデル」ビジネス・オブジェクトに従って、ビジネス・オブジェクトのデータ・モデルのサブモデル、またはビジネス・オブジェクトに関連付けられた他のビジネス・オブジェクト・モデルを選択できます。ロジック・フローが「ソースモデル」データインスタンスは、選択されたターゲット関連モデルのデータインスタンスに自動的に直列に接続されます。たとえば、現在のケースシナリオでは、「ターゲットモデル」はサブモデルを選択します。「処理手順」モデルの「処理ルート」モデル。
ターゲットフィールド:分割変換ノードによって返される必要がある出力「ターゲットモデル」の特定のデータフィールド範囲を構成します。たとえば、現在のケースシナリオの場合、「ターゲットフィールド」は、分割変換ノードから返される必要があるフィールド範囲を選択します。「処理手順」データ。

(4) 出力モデルの構成

「アクションコンフィグレータ」でアクションノード「処理タスク作成」の「データ変換ロジック」を整えた後、出力モデル「処理タスク順序」データを作成するために必要な処理ルートと処理データを取得した後、最後にマッピングして設定します。「オンデマンド」出力モデル」フィールドの値。

「Output Model Configurator」には以下の 3 つの設定領域があります。

パイプラインデータ表示: 左側には、現在のアクションノードの入力データが「データ変換」された後のデータフィールドが表示されます。
出力モデルのフィールド値のマッピング: 出力フィールド値のマッピング方法は、次の 4 つの方法をサポートします。

パイプラインフィールドをドラッグします。マッピングの左側にあるデータパイプラインのデータフィールドをドラッグすると、「出力モデルコンフィギュレーター」がパイプラインフィールドと出力フィールドのデータ型に互換性があるかどうかを自動的に検証します (ヘッダー「」をクリックします)。「出力モデル」の「フィールド値」列の後ろにあるプロンプトアイコンで、詳細なフィールドマッピングルールを表示できます。
固定定数値の手動入力:出力モデルのフィールド値は、固定定数値の直接手動入力をサポートします。
参照標準関数計算:プラットフォームには、一般的に使用されるいくつかのデータ計算関数が組み込まれており、ユーザーはビジネスニーズに応じて関数をクリックして出力モデルフィールドにドラッグし、関数に必要なパラメーター値 (パラメーター) を構成できます。参照パイプラインでの選択をサポートします。出力モデルの特定のフィールド値または出力モデルの特定のフィールド値）、「実績労働時間の計算」を例として、「日付間隔関数」を参照してドラッグできます。「作業指示」の「実績作業時間（分）」フィールドに次のように入力します。

必要に応じて標準関数のパラメータ値を構成し、パイプラインデータフィールドの参照をサポートします。

参照システムグローバル変数:プラットフォームには、システム時間、現在のログイン担当者、現在の担当者の組織など、いくつかのシステムグローバル変数が組み込まれており、出力モデルフィールドにマップするためのグローバル変数のドラッグをサポートしています。

出力タイプが「データの作成」であるアクションノードの場合、出力モデル構成は、「データ識別」フィールドを除くモデルのすべての必須フィールドにマッピング値が必要であることを自動的に検証します (データが作成されると、バックグラウンドが自動的に処理します)。識別フィールドは空白のままです)。「データの更新」など、他の出力タイプのアクションノードの場合は、変更する必要があるフィールド値のマッピング値を設定するだけです。

以上の4つの設定手順により、「生産指示の作成と工程指示の生成」というビジネスロジックフローのモデル化構成が完了します。

論理フロー 2: 製造オーダーを操作し、資材要件を生成する

「製造オーダーを操作し、資材要件リストを生成する」ロジックフロー要件:

ユーザーが製造オーダーの「資材所要量の生成」ボタンをクリックすると、製造オーダーの製品フィールド情報と計画出力、および展開されたベース数量に基づいて、製品マスターデータに従って BOM データが自動的に展開されます。「製造指図」の計画出力に従い、材料の必要数量を求め、対応する材料所要量表と必要材料の詳細データを作成します。ロジックフローで生成された資材所要量のオーダー番号を「製造オーダー」にバックフィルする必要があります。

(1) ユーザー操作「資材要件の生成」を追加

「製造オーダー」モデルで、新しいユーザーアクション「資材要件の生成」を追加します。

「ユーザーアクション」には以下の3つの設定項目があります。

操作オブジェクト: 現在のモデルのメイン情報モデルとそのサブ情報モデルを選択できます。たとえば、「資材調達要求書」(つまり、特定の資材調達要求書) のメインモデルデータを制御できます。資材要求文書のサブモデル「資材要求の詳細」。」はそれぞれ、必要なユーザーアクションを定義します。
パラメータの有効化: フロントエンド・インタフェースで操作を使用するときに、ユーザーがパラメータ情報を入力する必要があるかどうかを構成します。たとえば、次のケースでは、「製造オーダーを閉じる」操作では、ユーザーは「クローズ理由」を入力する必要があります。次回は、ユーザー操作のための「パラメータ」の設定方法を詳しく紹介します。
ユーザー操作のフロントエンド表示制御: フロントエンドに表示されるユーザー操作のルール条件の構成をサポートします。

たとえば、資材要件を作成した製造オーダーを制御するには、「資材要件の生成」操作が使用できなくなった場合、「資材要件の生成」ユーザー操作を構成して、「関連する資材要件の値」というルール条件を表示します。「製造オーダー」の「資材要件」フィールドが空です。

(2) ユーザー操作を契機とした論理フローの作成

新しく追加された「資材要件の生成」オペレーションの構成ウィンドウで、「ロジックフローの保存と構成」を選択して、ユーザー操作によってトリガーされるロジックフローをすばやく作成することも、最初に「ユーザーオペレーション」を保存することを確認することもできます。次に、ロジックフローのトリガー構成にバインド「ユーザーアクション」を追加します。

「資材要件の生成」のロジックフローのオーケストレーションおよび構成ステップでは、上記の「製造オーダーの作成とプロセスタスクオーダーの生成」のロジックフローにおける同様の要件の構成方法については、これ以上説明しません。

要件の違いと、それに対応するロジックフローの構成方法には次の 3 つのポイントがあります。

1. 資材所要量の計算:作成した資材所要量リストの詳細にある資材所要量のフィールド値を出力します。これは、製品マスタデータに従って BOM 資材リストデータに分割する必要があり、乗算します。「製造オーダー」による資材リスト上の基準数量から、計画生産高を計算して「資材所要量」を求めます。

この要件を満たすには、「資材要求詳細の作成」のアクションノードの「データ変換ロジック」で「計算ノード」を使用する必要があります。

計算ノード「資材所要量計算」の構成は以下のとおりです。

「測定情報フィールド」の右側にある「追加」ボタンをクリックして計算フィールド「資材所要量」を追加し、計算フィールド名、計算フィールドコードの順に設定し、計算式を編集します。「生産」をドラッグします。左側のデータパイプラインから "Order" の "Planned Output" フィールドと "BOM Bill of Materials" の "Quantity" フィールドが計算パラメーターとして使用され、乗算記号 "*" 演算子が入力されます。真ん中。計算式は「+-*/」加算、減算、乗算、除算の4演算子に対応しており、クリック＆ドラッグによる標準関数計算の参照もサポートしています。

2. 同じ材料ごとに必要な数量を集計した後、材料要件の詳細を生成します。

前順変換ノードが出力したBOMデータを集計し、同じ材料コードに従って必要数量を集計し、対応する詳細な材料需要データを生成する必要があります。

「資材要求詳細の作成」のアクションノードでは、「データ変換ロジック」で「集計演算子ノード」を使用する必要があります。

集約ノード「品目別需要集計」の構成は以下のとおりです。

集約変換ノードの構成手順:

出力するディメンションフィールドを確認する：左側のデータパイプラインフィールドで、集計ノードが集計操作の集計ディメンションとして出力するディメンションフィールドにチェックを入れます。チェックを外したフィールドは、集計ノードの出力結果に表示されません。。たとえば、現在のケースでは、出力モデルにデータパイプラインの BOM リストの材料フィールドと測定単位フィールド、および材料要件リストのコードフィールドが必要な場合は、左側のデータパイプラインの対応するフィールドを確認します。 ;
集計計算が必要な数値フィールドの追加：「集計情報フィールド」右側の「追加」ボタンをクリックして集計計算フィールド「資材所要量集計」を追加し、集計フィールド名、集計フィールドコードの順に設定します。 , [集計計算タイプ] として [合計] を選択し、集計計算式を編集します。左側のデータパイプラインから合計する必要がある [資材所要量] フィールドを計算パラメータとしてドラッグします。計算式は四則演算子「+-*/」加算、減算、乗算、除算に対応しているほか、クリック＆ドラッグで標準関数計算を参照できます。

集計ノードを保存した後、出力モデルを構成すると、チェックされた集計ディメンションフィールドと計算フィールドのみがデータパイプラインに保持されることがわかります。

3. 資材所要量リストのデータは「ヘッダー行構造」です。資材所要量リストを作成するには、需要詳細を同期的に作成する必要があります。

ロジックフローでは、まず「資材要件の生成」のアクションノードを作成し、次に「資材要件の詳細の生成」のアクションノードを作成します。前のアクションノードは、入力された「製造オーダー」データインスタンスに従って、出力および作成します対応するマテリアル要件単一データの場合、プラットフォームはアクションノード出力によって作成された MOR データをデータパイプラインに自動的に追加します。後者のアクションノードでは、出力が対応する MOR 詳細 (つまり、サブモデル「要件」) を作成するときに、 MOR) データの「詳細」を取得すると、「資材要求詳細」データの作成に必要な関連する「資材要求番号」をデータパイプラインから取得できます。

4. 「製造オーダー」を更新するには、作成された資材要件のオーダー番号をバックフィルする必要があります。

前の「資材要求の作成」アクションノードは、作成された資材要件番号を出力します。これはバックフィルして、「製造オーダー」の「関連資材要件」フィールドに更新する必要があります。

「資材要求文書の作成」アクションノードの後に、「アクションの追加 (ブランチ)」をクリックして、「資材要求の詳細の作成」アクションノードと並行してブランチノード「バックフィル注文要求番号」を追加します。

「バックフィル注文要求番号」アクションノードの出力タイプとして「データの更新」を選択し、出力モデルフィールドを構成します。

出力タイプが「データの更新」の出力モデル構成手順については、次のとおりです。

出力モデルの「データ ID」フィールドがデータパイプラインに存在する場合 (たとえば、資材要件リストの「コード」)、出力モデルの「データ ID」フィールドにマッピングされている値をドラッグし、「」にチェックを入れます。「フィルターフィールド」を使用して「データ識別」値を渡し、出力モデルを更新する必要がある特定のデータインスタンスを決定します。
ターゲット更新の出力モデルのデータ範囲を決定するために特定のフィールド条件を組み合わせる必要がある場合は、必要なデータパイプラインフィールドをドラッグして出力モデルの対応するフィールド値にマップし、[フィルターフィールド] をチェックして、[出力モデル] を選択します。ボックスの右側にある「フィルタールールの構成」をクリックして、出力モデルのターゲットデータフィルター条件を組み合わせて設定します。

ここまでで、「製造オーダーを操作して資材所要量を生成する」というビジネスロジックフローのモデル化構成が完了しました。

論理フロー 3: 製造オーダーをクローズし、プロセスオーダーを自動的にクローズします。

「製造オーダーをクローズし、プロセスオーダーを自動的にクローズする」という論理フローの要件:

「未着手／進行中／完了」のいずれの状態の「製造オーダー」に対しても「オーダーを閉じる」の操作ボタンが設けられており、ユーザは「オーダーを閉じる」ボタンを操作する際に、「理由」を入力する必要がある。条件が満たされない場合は、その理由を尋ねるプロンプトが表示されます。条件が満たされると、「製造オーダー」のステータスが「クローズ」に更新され、「ユーザーが入力した「締切理由」が「製造オーダー」の「締切理由」欄に更新されます。「製造オーダー」がクローズされた後、「製造オーダー」に関連するすべての「プロセスオーダー」を同期的にクローズする必要があります。つまり、プロセスオーダーのステータスが「クローズ」に更新されます。

(1) ユーザー操作「閉じる」を追加

「製造オーダー」モデルで、ユーザーアクション「閉じる」を追加し、「パラメータを有効にする?」をチェックします。

「ユーザー操作」のパラメータ設定画面には、以下の2つの設定項目があります。

1. パラメータのタイプ:パラメータは 2 つの定義方法をサポートしています。

参照モデルフィールド:オペレーションが属するビジネスモデルのフィールドをパラメータとして参照し、モデルフィールドのパラメータを参照できます。ユーザーがオペレーションを使用する際、パラメータ値は自動的に対応するフィールドを参照します。現在のモデルのデータインスタンスの値 (パラメーターの定義など) 「実行者」は、「製造オーダー」モデルの「担当者」フィールドを参照します。ユーザーが操作を使用する場合、「実行者」パラメーターの値は、現在の「製造オーダー」の「担当者」が自動的にデフォルトになります。
カスタマイズ:数値、テキスト、日付、時刻、配列をサポートするパラメータのフィールドタイプを選択します。このうち、「配列」タイプのパラメータは、ユーザーが操作を実行するときに、次のようなビジネスニーズを満たすために使用されます。入力情報として複数行のデータを入力します。たとえば、製造オーダーが複数のオーダーに分割される需要シナリオの場合、複数のオーダーに分割する必要がある情報を保持するために配列タイプのパラメーターを定義する必要があります。

2.パラメータ表示制御:

「表示のみ」 : フロントエンドインターフェースにのみ表示され、編集できないようにパラメータを制御するために使用されます。通常、モデルフィールドを参照するパラメータに適用され、モデルの対応するフィールド値を表示します。分割などのユーザー操作のコンテキスト参照情報としての現在のモデルデータインスタンス。製造オーダーのシナリオで、「製造オーダー」の「計画出力」フィールドを参照する表示専用パラメーターを定義します。フロントエンド操作画面で分割前の「製造オーダー」の「出力予定」データ。ユーザーは操作中に分割参照情報を使用します。
「必須」:ユーザーが操作を使用するときにパラメータ値を入力する必要があるかどうかを制御するために使用されます。

「注文を閉じる」操作の場合、「カスタム」タイプのパラメータを追加し、フィールドタイプとして「テキスト」を選択し、フロントエンドに表示されるパラメータの名前と背景の「パラメータコード」を入力します。最後に「必須のFill」にチェックを入れてパラメータの設定は完了です。

「注文を閉じる」のパラメータを設定した後、「ロジックフローを保存して構成する」を選択してクリックし、「注文を閉じる」操作の処理ロジックフローの構成を開始します。

(2) 注文ステータスを確認するためのルールノードを追加します

「ルール」ノードを追加し、ルール条件を構成します。

ルールノードには次の 3 つの設定項目があります。

1. ルール編集モード:ルール条件を編集する 2 つの方法、「一般」と「スクリプト」が提供されます。

従来型: 完全にグラフィカルな編集ルール条件 (通常はデフォルトで使用されます) は、ほとんどのシナリオのニーズを満たすことができます。
スクリプト: 正規表現を手動で入力し、左側のパイプライン、システムグローバル変数のデータフィールドのドラッグと参照をサポート、または式のパラメータとして標準関数を参照し、複雑な正規表現を実現できます。

2. マッチングルール：複数の「条件グループ」を追加することで複雑なルール条件を組み合わせることができ、条件グループごとに条件組み合わせモードを「すべての条件を満たす」または「いずれかの条件を満たす」として設定できます。条件グループの下で、特定の条件を追加します。条件フィールドを選択し、条件演算子を選択して、条件値を選択または入力します。

3. 検証用のプロンプトテキスト:設定されたプロンプトテキストの内容は、ロジックフローの実行中にルールが条件を満たしていないと判断した場合に、フロントエンドのユーザーに通知するために使用されます。

「注文のクローズ」のルールノードの「一致ルール」で「任意の条件」を選択し、3つの条件を追加して、「製造オーダー」のステータスフィールドが満たすことを許可する3つのステータス値を構成します。「進行中」「完了完了」「未開始」。

「クローズオーダー」ロジックフローの他のオーケストレーションおよび構成ステップは、上記の「製造オーダーの作成およびプロセスオーダーの生成」ロジックフローの構成方法と同様であるため、これ以上の説明は省略します。

ここまでで、「生産オーダーをクローズし、工程オーダーを自動クローズする」というビジネスロジックフローのモデリング構成が完了しました。

論理フロー 4: 完成した保管オーダーを確認し、製品と倉庫の在庫を自動的に更新します

「完了受領を確認し、製品と倉庫の在庫を自動更新する」ロジックフローの要件:

「完了受付」には「完了確認」の操作ボタンが設けられており、利用者が「完了確認」ボタンを操作する際には、「完了受付」のステータスが条件を満たしているかどうかを確認する必要があり、条件を満たしていない場合には、条件を満たしていれば、「完了受領書」の「商品」「倉庫」「入庫数量」などの情報をもとに、該当する商品マスタの「手元在庫」を更新し、対応する倉庫にある製品の手持ち在庫。最後に「完了受領書」のステータスを「完了」に更新します。

「完了受信の確認」のロジックフローに含まれるオーケストレーションおよび構成方法は、上記のいくつかのロジックフローのケースで紹介されているため、これ以上の説明は省略します。

ここでは、「倉庫製品在庫の更新」アクションノードの構成方法に焦点を当てます。

出力タイプとして「データを更新」を選択し、「一致しない場合はデータを作成する」にチェックを入れます。これは、製品が初めて特定の倉庫に入ったとき、その倉庫（つまり「倉庫」）に製品の在庫データが存在しないためです。製品在庫のデータインスタンスが「空間位置モデル」のサブモデル「製品在庫」に存在しない場合、最初の倉庫作業では対応する製品在庫データが作成され、その後の完了した倉庫操作では、対応する製品在庫データがあるため、このビジネスシナリオでは、「一致しない場合はデータを作成する」にチェックを入れる必要があります。

出力モデル「倉庫-製品在庫」のフィールドマッピングを「完了受領書」の「倉庫の場所」および「製品」フィールド値に設定し、「倉庫-製品在庫」のターゲットデータと一致するように「フィルターフィールド」をチェックします。「製品インベントリ」モデル。最後に、標準関数「現在値自己インクリメント関数」を参照して、完成・保管後の「手元在庫」を計算します。

「基本フィールド」パラメータは、出力モデル「倉庫製品在庫」の「手持在庫」フィールド（対応する倉庫製品の現在の在庫を取得できます）を選択し、「増分フィールド」パラメータは、出力モデル「倉庫製品在庫」の「受入」フィールドを選択します。「「完了した入庫」在庫数量」を使用して、「入庫数量」を倉庫内の製品の現在の在庫に増やします。

ここまでで、ケースシナリオにおける 4 つのビジネスロジックフローのモデリング構成が完了しました。ロジックフローのモデリングが完了したら、ロジックフローとそれが属するビジネスモデルのリリースを有効にして、ロジックフローが有効になります。

(3) 運用効果検証

ロジック 1: 製造オーダーを作成し、プロセスオーダーを自動的に生成する

製造オーダーを作成し、オーダーの生産「製品」、「工順」、および「計画出力」のフィールド情報を入力します。

「製造オーダー」を保存した後、作成した製造オーダーの詳細編集ページに入り、対応するプロセスオーダーが同期的に作成されているかどうかを確認してください。

論理フロー 2: 製造オーダーを操作し、資材要件を生成する

前のステップで作成した製造オーダーを使用して、「資材要件の生成」のアクションボタンがあることを確認します。

次に、「資材要求の生成」ボタンをクリックし、実行が完了したら、対応する資材要求が生成されたかどうか、製造オーダーの「関連資材要求」のフィールド値が自動的にバックフィルおよび更新されたかどうかを確認します。 [資材要件の生成] ボタンが表示されなくなったかどうか:

生成された資材所要量リストの需要詳細が製造オーダー上の製品の BOM 資材をカバーしているかどうかを確認します。

論理フロー 3: 製造オーダーをクローズし、プロセスオーダーを自動的にクローズします。

前の手順で作成した製造オーダーを使用して、「閉じる」アクションボタンがあることを確認します。

次に、「閉じる」ボタンをクリックして、ポップアップウィンドウに「閉じる理由」を入力する必要があるかどうかを確認します。

確認後、製造オーダーおよび関連するプロセスオーダーのステータスが自動的に「完了」に更新されたかどうかを確認します。

論理フロー 4: 完成した保管オーダーを確認し、製品と倉庫の在庫を自動的に更新します

「完了受領書」を作成し、注文の生産「製品」、「受領数量」、および「倉庫の場所」のフィールド情報を入力します。

「完了受領書」を保存した後、完了受領書のデータ表示ページで「操作」をクリックし、「完了の確認」を選択します。

操作の完了を待った後、「製品」マスタデータ関数で製品の既存の数量が増加したかどうかを確認します。

「工場 > 倉庫」マスターデータ機能で、「完成品倉庫」倉庫の下にある製品の既存の数量が増加したかどうかを確認します。

上記は、実際の「生産実行管理」シナリオに含まれる関連するビジネス活動プロセスであり、ファーウェイクラウドデジタルファクトリープラットフォームのロジックモデルオーケストレーターを使用して、関連するビジネスプロセスロジックのモデリングと使用を完了する方法を体系的に紹介します。次回は、HUAWEI CLOUD Digital Factory Platformの「分析」モデルコンフィギュレーターを使ってビジネスデータの統計分析機能を構築する方法を体系的に紹介します。

HUAWEI CLOUD IoTアシスタントWeChat hwc-iotを追加し、「Digital Factory」と返信してHUAWEI CLOUD Digital Factoryの体験を申し込みます

クリックしてフォローして、Huawei Cloudの最新テクノロジーについて初めて学びましょう~