初めまして、私は8年ほどAras Innovatorのエンジニアとして主にカスタマイズ開発に取り組んでいます。
開発では部品管理・課題管理機能を手掛けることが多く、日々開発の効率化や品質向上を考えて過ごしています。今回初めて記事を書くのですが、本記事では、Aras Innovatorのプログラム開発者へ向けて、私がカスタマイズ開発を通して得た経験や試行錯誤して得たノウハウを共有できればと考えています。

■関連記事
「話題のPLM ツール Aras Innovator とは？ 」

■合わせて読まれている資料
Aras Innovator 開発支援ソリューション

はじめに

Aras Innovatorはメソッドアイテムなどを用いて簡単にカスタマイズ処理の追加ができます。カスタマイズ処理を追加する際には、Aras Innovator上に用意されているIOMというAPIを利用することが大半だと思われます。

IOMは非常に便利ですが、使い方を誤るとパフォーマンスに思わぬ影響を与える可能性があります。本記事では、IOMを利用する際にパフォーマンスの観点で気を付けるべき事柄を紹介しています。簡単に利用できるものが大半だと思いますので、ぜひ活用してみてください。

向上策①：getアクションではselect属性を利用する

AMLのselect属性は、SQLにおけるselect句と同じ役割をしてくれます。select属性に設定する値は取得したいプロパティ(SQLにおけるカラム)になりますが、select属性を指定しないとプロパティを全件取得すること(= SQLにおけるSELECT *を実施すること)になり、レスポンスデータの肥大化によりパフォーマンス悪化となります。

このため、アイテムを取得する場合はselect属性を指定することが重要になります。


実際に上図のNGパターン、OKパターンをそれぞれ1万回実行した際の計測結果が下記になります。
select属性を指定することで、今回計測した環境では処理時間を1/2まで軽減することができました。

• NGパターン：21439ミリ秒
• OKパターン：10185ミリ秒
  
  

向上策②：getアクションではwhere属性での条件指定をしない

AMLでwhere属性を利用して対象の絞り込みを行うことがあると思います。editやupdateといったアクションの場合は、id(idlist)またはwhere属性でのみ更新対象の絞り込みを行うことができるため、利用しても問題ありません。対してgetアクションの場合、取得対象の絞り込みを行うためにはwhere属性での指定またはsetPropertyメソッドを利用することになります。

この両者には大きな違いは無いと思われがちですが、厳密にはwhere属性で条件指定した場合はSQLインジェクションのチェック処理が行われるなど、setPropertyメソッドで条件指定した場合よりもパフォーマンスが落ちる作りとなっています。

そのため、getアクションの場合はwhere属性での条件指定はせずに、setPropertyメソッドを利用して条件指定することをお勧めします。


実際に上図のNGパターン、OKパターンをそれぞれ1万回実行した際の計測結果が下記になります。
それほど大きな差は出ていませんが、setPropertyメソッドを利用した場合の方が処理時間が短い結果となりました。

• NGパターン：12677ミリ秒
• OKパターン：10185ミリ秒
  
  

向上策③：登録/更新時はdoGetItem属性が利用できるか確認する

IOMでアイテムを登録または更新した後、レスポンスのアイテムを利用しない場合があると思います。
その場合、doGetItem=”0”を設定することで不要なレスポンスをそぎ落とすことができます。

以下にdoGetItem=”0”を設定しないものと設定したもののレスポンス結果を載せています。レスポンスのデータ量が削減されていることが読み取れると思います。

実際に上図のNGパターン、OKパターンをそれぞれ1万回実行した際の計測結果が下記になります。割合としては大きいものではありませんが、処理時間を削減できている結果となっています。

• NGパターン：150695ミリ秒
• OKパターン：132151ミリ秒
  
  

向上策④：applyする回数を削減する

パターンA：ループ内のapplyを削減する
applyメソッドなど、applyを含むメソッドを実行した際、データベースへのアクセスが発生します。

基本的にはアプリケーションサーバとデータベースサーバは別のサーバで構成されているため、applyをした場合はアプリケーションサーバとデータベースサーバ間の通信が発生します。この通信を抑えることでパフォーマンスを向上させることが可能になります。

実際に上図のNGパターン、OKパターンをそれぞれ実行した際の計測結果が下記になります。
今回の計測環境はアプリケーションサーバとデータベースサーバが同一の環境となっていますが、それでも処理時間が1/3程度に抑えられています。

• NGパターン：11515ミリ秒
• OKパターン：3384ミリ秒 

また、登録や更新といった場面でもまとめてapplyすることが可能です。

パターンB：構成を持つデータの操作
以下のような構成のデータを取得する際もできるだけapply回数を少なくすべきです。
Part (Sample Part)
　┗Part BOM
　　┗Part (Sample Part2)
 
NGパターンでは、親Part(Sample Part)アイテムを取得し、そこで取得したIDを利用してPart BOMアイテムを取得します。Part BOMアイテムからrelated_id(子アイテムのID)が取得できますので、それを元に子Part(Sample Part2)アイテムを取得しています。ここでは計3回applyメソッドが呼ばれています。

それに対し、OKパターンでは親Part、Part BOM、子Partを1回のapplyでまとめて取得するようにしています。親アイテムとリレーションシップアイテムを同時に取得する場合は、createRelationshipメソッドを利用します。また、リレーションシップアイテムに対してはselect属性で"related_id(item_number, name)"というプロパティを取得するようにしています。

Item型のプロパティに対し、その参照しているアイテムのプロパティを取得したい場合に、()の中に参照先のプロパティ名を指定することで取得することが可能になります。今回の場合はPart BOMアイテムが持つrelated_idは子のPartアイテムとなり、結果的に子Partのitem_numberとnameプロパティを取得するようになります。

向上策⑤：リレーションの取得時にはrelated_expand属性を利用する

リレーションシップを取得する際、紐づいているリレーティッドアイテムの情報は不要な場合があると思います。
その場合は、related_expand=”0”を設定することで、レスポンスのデータ量を削減することができます。

実際に上図のNGパターン、OKパターンをそれぞれ1万回実行した際の計測結果が下記になります。
レスポンスのデータ量が減少したおかげで処理時間が半分程度になりました。

• NGパターン：37376ミリ秒
• OKパターン：18247ミリ秒
  ​​​​​​​

まとめ

はじめに「簡単に利用できるものですよ」とお伝えしましたが、この記事を読んでいただくと、実際に難しいことはしていないと感じていただけたのではないでしょうか。「これならできそう！」と思われた方は、ぜひ一度お試しください。
パフォーマンスの向上は、結果的にプログラミング品質の向上につながり、最終的にはプロジェクト全体の評価向上にも結びつくため、とても大切な取り組みだと考えています。
この記事を通じて、パフォーマンス向上への意識が少しでも高まり、日々の業務にお役立ていただければ幸いです。

■サービス資料一覧はこちら↓