OutSystemsのIDEには、通常のプログラミング言語で使うIDEにあるような、コーディングスタイルや標準準拠を自動チェックしてくれるツールがありません。

つまり、標準を開発プロジェクトまたは全社で定めると、準拠のチェックを目視で行うことになります。
最近は、SaaSのArchitecture Dashboardを使うことで、OutSystemsが提供しているルールに従ったチェックはしてくれますが、実行タイミング・ルールが固定であること・SaaSである等の問題もある。

そこで、Forgeにあるドキュメント生成ツールであるOutDocを使って、可能なチェックは自動で行えるようにしたい。

確認環境

Personal Environment(Version 11.13.0 (Build 31107))
Service Studio (Version 11.12.8)
OutDoc (Version 8.0.5)

全体像

レビュー依頼をOutSystemsで作った依頼用アプリケーションから行う
依頼を行うと、内部処理でOutDocを使って各種プロパティをチェック
チェックNGなら、画面に修正すべき内容を示す。NGとまでは言えないが、標準で特別な理由が必要な内容なら、依頼者にその実装になった理由を入力してもらう
チェックOKならレビュー担当者にタスクを割り当て、以降Processで管理

こんな感じの処理にして、機械的にチェックできる内容は事前に潰し、レビュー担当者の負荷を下げたい。

画面からモジュール指定して申請処理

レビュー依頼者は、画面からモジュール名を指定して、申請を行う。

イメージ：

依頼はアプリケーション単位にするなら、アプリケーション名指定（内部処理でSystemのEntityを検索してモジュール一覧を取得できる）するのもありですね。
レビュー担当者をドロップダウンリストで指定することも考えられます。

Actionで情報取得

以下の流れで処理します。

受け取ったモジュール名でEspace Entityを検索し、Espace_Version Identifierを取得する
OutDocのAction「Documentation_GetEspaceDocumentation」にEspace_Version Identifierを渡し、モジュールの設計情報をXMLとして取得
OutDocの提供する各種要素のプロパティを取得するActionにXMLを渡して抽出する

OutDocから、モジュールの情報を引き出す仕組みについては、以前書いた以下の記事を参照。
OutDocを使って、eSpaceのコードを自動でチェックしてみる

取得例：モジュールのプロパティ

Section_3_GenerateOverviewというActionにXMLを渡すと取得できます。

上のスクリーンショットで色を付けたパラメータを取得すると、以下のような判定ができますね

Description：多くの環境の標準で、Descriptionは必須になっていると思います。空白だったらNGでいいでしょう
GlobalExceptionHandler：モジュールの一番外側の例外処理ハンドラー。UIを定義するモジュールでなければ必須ではないが、UIを定義するモジュールなら必須。そこで、未定義なら警告を出す
ServerRequestTimeout：Mobile/Reactive Web Appでは、Client Actionから呼び出すサーバー処理にタイムアウトがあり、その時間を超過するとCommunication Exceptionを発生させる。この設定値はそのモジュールにおけるそのデフォルト。これが長い値が設定されているということはサーバ側で長時間動作するロジックをクライアントからそれなりに呼んでいることが疑われる。そこで、標準的にはデフォルト値を使うことが推奨されているが、長くする理由がなにかを確認したい

Actionには、もう一つIsNewRuntimeというパラメータもありますが、こちらは、OutSystemsのPrivate Actionを利用した判定値を渡すので、そのActionをコピーしてきて対応します。

取得例：変数名のプレフィックス

OutSystemsでは、変数は、Input Parameter/Output Parameter/Local Variableに分類でき、それぞれ違うアイコンがつくので、定義しているActionやScreen上では見分けが付きます。

しかし、この値をロジックで利用する（Expressionで計算に使うとか、他の呼び出しへの引数に渡すとか）ときは、名前で判別しなければならない。そこで、開発標準で、プレフィックスをつけることが考えられます（InputとかIn_とかを先頭につける）。

変数のプレフィックス漏れを検出するには、Section_3_4_GenerateActions Action（Server Actionの情報を返す）やSection_3_4_GenerateClientActions Action（Client Actionの情報を返す）が使える。
残念ながら、Screenの情報を返すSection_3_2_GenerateWebScreenは変数の情報を返さないため、Screen/Screen Action/Data Actionの変数は取得できないようです。

上のスクリーンショットは、Server Actionの例ですが、Input ParameterとOutput Parameterについては、色を付けた変数に名前が含まれるので判別可能です。Local Variableはリストにないため、無理そうです。

申請NGの場合の画面イメージ

取得した情報を元に検証して、問題があったら、エラー内容を表示します。

標準違反にも、不可とすべきものと、事情を考慮して判断すべきものがあるため、

Error：1つでもあれば申請は却下する。エラーメッセージと修正方法を出す
Warning：事情によっては許可するため、ユーザーに違反理由を入力させるUIを表示する

とレベルを分けています。

結果はEntityに記録してBPTでレビュータスクを管理

申請が受け入れられたら、Entityにレコードを作り、レビュータスクをレビュー担当者に割り当てる。
Entityには、申請者・申請日時・モジュール・依頼先・結果などをもたせるイメージ。

結論

自動でできることは、コンピュータにやってもらって、人間は価値ある作業に集中したい。
OutDocでできることにも限界はあるので、可能なら、Architecture Dashboardを導入し、必要に応じてOutDocを使ったプログラムを実装する、とか。