Aras Innovatorサーバーイベント ”Version“ の詳しい動きをまとめてみた

2025-01-31神田

こんにちは。クレスコ・デジタルテクノロジーズの神田です。
本記事では Aras Innovatorの開発者向けに、サーバーイベント “Version” に関する詳しい動作をまとめましたのでご紹介します。
※Aras Innovator®のサーバーメソッドについてまとめてみたの続編となります。

■あわせて読まれている資料：
設計～製造へフレキシブルに最新の設計情報を反映！
→製造BOMソリューション(SMB)

製造BOMソリューション(SMB)資料ダウンロード｜株式会社クレスコ・デジタルテクノロジーズ設計～製造へフレキシブルに最新の設計情報を反映する統合BOM（Bill of Materials）ソリューションです。アップグレード可能なアーキテクチャーを使用しており、BOP（Bill of Process）に依存しない製造BOMの管理を可能にします。株式会社クレスコ・デジタルテクノロジーズ

目次[非表示]

1.世代管理の設定について
2.世代が上がるタイミング
3.フローチャートでイメージの理解
4.“onBeforeUpdate”イベントで action=“version” をスキップ判定する意味とは？
5.世代更新の抑制とサーバーイベントの抑制を使うときのポイント
6.まとめ

世代管理の設定について

本題に入る前に、世代管理について少し触れておきます。
Aras Innovatorでは、アイテムタイプの定義でバージョン管理の方法を設定できます。
バージョン管理の方法は「無効、手動、自動」の３種類に分けられます。

各アイテムの "config_id" をグループ単位とし、 "generation" で順序を管理しています。
例えば、Part アイテムでは初期設定が「バージョン管理：有効」なので、保存時に自動的に世代が上がります。
保存されたアイテムについて、「バージョン履歴参照」から世代ごとに履歴を確認できます。

データベースのイメージで表現すると、下記のように “config_id” 単位でグループ化されている状態になります。

そして、この世代が上がるタイミングで、サーバーイベントの “onBeforeVersion”, “onAfterVersion” が動作します。
サーバーイベントの挙動を正しく理解して、安定した実装が行えるよう詳しく説明していきます。

世代が上がるタイミング

a. 概要
イベントの詳細に入る前に、世代が上がるタイミングを整理します。

b. 画面操作での例
アイテムタイプ定義で「バージョン：自動」を指定した場合、アイテムの世代が上がるタイミングを画面操作で例えると、アイテムを「編集(Edit)」→「保存(Save) または完了(Done)」したときの１回目のときです。

保存(Save)を押した後、「完了(Done)、破棄(Discard)」せずに連続で保存(Save)しても、世代は上がらずに更新のみを行います。

c. AMLでの世代管理
AMLの場合は、lock→update (または edit や merge) を行った時点で、バージョン自動によって世代が上がります。
画面の動作と同じで、lock→update でバージョン自動によって世代が上がった後は、unlockするまでの間は連続で updateしても世代は上がりません。
また、AMLの場合は意図的に世代を上げたくない場合 version="0" 属性を設定することで世代更新を抑制できます。

通常の更新:（世代が上がる)
<Item action="edit" type="{type}" id="{guid}" >
...
</Item>

 
世代を上げない更新：(version="0")の利用例
<Item action="edit" type="{type}" id="{guid}" version="0">
...
</Item>
 
手動で世代を上げる場合 (action="version")
※このactionはバージョン管理が有効(手動・自動) であれば利用できます。
<Item action="version" type="{type}" id="{guid}">
...
</Item>

これらのルールや例に基づいて、具体的なイベントフローを以下で説明します。

フローチャートでイメージの理解

バージョンのサーバーイベント詳細を確認するため、３パターンに整理しました。
結果はサーバーログから独自に調査したもので、実装のポイントとなる部分を視覚化しました。

“onBeforeUpdate”イベントで action=“version” をスキップ判定する意味とは？

開発コードで下記のような判定を見たことはありますか？

```cs
if (this.getAction() == "version")
{
    return this;
}

```

初見だと「なぜ “onBeforeUpdate”イベントで this.getAction()==“version”の判定をしているのか？」と思うかもしれません。

先程のフローに書かれた内容の通り、最新世代を作成する action="version"が発行されるときも“onBeforeUpdate”イベントが発火する（表「3.世代が上がる更新を行うとき（バージョン自動）」の4行目）ので、バージョンアップに伴う“onBeforeUpdate”イベントをスキップするために上記の判定を行います。

これは通常のイベント実装で設定する必要はありませんが、前述の最新世代のアイテムではイベントを発火したくない場合、外部連携処理を実装する場合、ワークフローの担当者の変更(動的アサインメント)を実装する場合など、世代が上がる前後で複数回同じ処理を実行することが望ましくない場合に“onBeforeUpdate”イベントをスキップする実装をして期待する動作を実現します。

世代更新の抑制とサーバーイベントの抑制を使うときのポイント

世代更新の抑制 version="0" を行った場合、“onBeforeUpdate”のサーバーイベントは通常通り動作します。意図的に更新イベントも抑制する必要がある場合は、serverEvents="0" 属性も合わせて設定します。

ただし、なぜそれが必要なのか、コメントで理由を残したほうが良いです。後で問題が起きた場合に設定している理由を明確にするためです。

下記のような説明があると、保守の際に修正有無の判断が行いやすくなります。

```cs
Item query = inn.newItem(itemTypeName, "update");
query.setID(itemId);
// 最終処理時刻を更新させるためだけのため 世代を上げないようにする
query.setAttribute("version", "0");
// 再計算は必要ないためイベントは無効にしておく
query.setAttribute("serverEvents", "0");
// 最終処理時刻を更新
query.setProperty("z_last_executed_on", "__now()");
Item result = query.apply();
if (result.isError()) { ... }

```

※C#のコードは次のようなAMLが出来上がります。

```xml
<Item action="update" type="{type}" id="{guid}" version="0" serverEvents="0">
    <z_last_executed_on>__now()</z_last_executed_on>
</Item>

```