[OutSystems]OutDocを使って、eSpaceのコードを自動でチェックしてみる

ForgeコンポーネントOutDocには、eSpaceの設計情報を分析して取り出すActionが備わっています。
本来はOutDoc内のUIで表示するためのものなのですが、Public=YesのActionなので、他のモジュールからも使えます。
このActionを使って、静的にeSpaceをチェックし、一定の標準違反を検出してみようという試み。

確認環境

Personal Environment(Version 11.13.0 (Build 31107))
Service Studio (Version 11.12.5)
OutDoc (Version 8.0.5)
CI/CD Probe (Version 2.1.0)

CI/CD Probeの実装から使い方を確認する

CI/CDの仕組みの中で、テストアプリケーション内のテストスイート（Traditional WebのScreenです）を抽出する機能を提供しているのが、CI/CD ProbeというForgeコンポーネント。

OutDocを使って設計情報を取り出す処理の実装例

このコンポーネント中で、eSpaceから、UI Flow（と内部のScreen）のリストを返すActionがあります。
OutDocのActionの使い方は同じなので、まずはこのActionの実装を確認してみます。

GetWebScreenDetailsFromEspaceOML Action

1. 設計情報を取得したいモジュールのEspace_Version Identifierを取得する
2. Documentation_GetEspaceDocumentationにEspace_Version Identifierを渡して設計情報のXMLを取得する
3. 取得したい情報に応じたOutDocのActionにXMLを渡して抽出する（Actionは「Section_数字_数字_取得する要素の種類」のフォーマットの名前を持つ）。CI/CD Probeの例：Section_3_2_GenerateWebScreen。Screenの情報を取得する

Espace_Version Entity

(System)モジュールに含まれるシステムEntity。最近はシステムEntityがドキュメントに記述されることも増えていますが、このEntityはforumにしか記述が見当たらない。
最初のAction呼び出し（Documentation_GetEspaceDocumentation）のInput Parameterに指定するのは、このEntityのIdentifier型。

というわけで、自力で構造を読み解いてみます。
eSpaceの基本的な情報を持っているEspace Entityと一緒にER表示してみる。

上の図と属性の型・名前を突き合わせてみると、

• Espaceが親Entityで、Espace_Versionはその明細Entity
• EspaceにeSpaceの基本的な情報が含まれる
• Espace_Versionには、Espaceの各バージョンの情報が含まれる
• Espace_VersionのeSpace_IdをeSpaceのIdで検索するとeSpace1つに対する全バージョンが取得できる
• EspaceのVersion_Idには、現在環境にPublishされているバージョンのEspace_Version Identifierが含まれる

と思われます（あくまで推測だが、View Dataでデータを確認すると整合する）。
要するに、「Documentation_GetEspaceDocumentationのInput Parameterを取得するにはEspaceをNameで検索し、そのVersion_Idを利用する」ということですね。

サンプル実装：Client Action / Server ActionのDescriptionをチェック

上記の知見を元に、OutDocの機能を使ってコードチェックを行う機能をサンプル実装してみます。

実現する仕様

eSpace名を受け取り、Descriptionが空白のClient ActionとServer Actionの名前を抽出し、一覧として返す。
実装する要素：Expose REST API
Input Parameter: eSpace名
Output Parameter: Action名の一覧

なお、Architecture Dashboardを使える環境であれば、Descriptionが空白の要素は警告を出してくれます。

利用するOutDocのAction

Actionを対象としたOutDocのActionは以下の通り。

GenerateReferencedActions (参照されたAction) は実現する仕様を考慮すると、無視して良さそうですね。

• Section_3_4_GenerateActions：Logicタブの下にあるServer Actionを抽出する
• Section_3_4_GenerateClientActions：Logicタブの下にあるClient Actionを抽出する
• Section_3_4_GenerateServiceActions：Logicタブの下にあるService Actionを抽出する
• Section_3_2_1_1_1_GenerateScreenActionsForWebScreen：Screenにぶら下がるScreen Actionを抽出する
• Section_3_2_1_1_1_GenerateScreenActionsForWebScreen：Screenにぶら下がるData Actionを抽出する

ここでは、「実現する仕様」より、Logicタブの下にあるServer ActionとClient Actionを抽出するので、Section_3_4_GenerateActionsとSection_3_4_GenerateClientActionsを使用する。

実装例

API インターフェース定義

Input Parameter: eSpaceの名前（Text型）
Output Parameter: 条件（Descriptionが空白のAction）に合致したActionの一覧（Record型）
　Recordの内訳：
　　ClientActions：Client Actionの内、条件に合致したもの。各属性は全てText型
　　ServerActions：Server Actionの内、条件に合致したもの。各属性は全てText型

Action Flow

全体の流れは

1. eSpace名（Input）でEspace Entity (System)を検索し、Espace_Version Identifierを得る
2. Espace_Version Identifierを引数に、設計情報をXMLとして取り出す（Documentation_GetEspaceDocumentation）
3. XMLからServer Actionの情報を抽出（Section_3_4_GenerateActions）
   1. ListActions（Section_3_4_GenerateActionsのOutput）をループ（フォルダ単位のループになる）
   2. フォルダ内のActionをループ
   3. Descriptionが空白であればREST APIのOutputに追加
4. XMLからClient Actionの情報を抽出（Section_3_4_GenerateClientActions）
   1. 細部はServer Actionのときと同じ

結果のサンプル（開発者ツールのコンソールタブでevalしたもの）

想定される他の用途

OutDocが生成するドキュメントを見ると他にもいくつかチェックできそうな内容もあります。
Timerを使って夜間に一括チェックしたり、一定のタイミング（レビューやPublishなど）で任意に標準準拠をチェックしたりという使い方が想定されます。

• 各要素の命名規則チェック（Nameを取り出して規則とマッチング）
• Global Exception Handler設定漏れモジュールの検出
• 長過ぎるEntityのAttributeを検出する
• Index未設定のEntity検出
• ドキュメントを作成する設定のExpose REST APIの検出

など。開発標準に定めた内容の内、自動チェックできるものはしておきたいものです。
人力チェックするには手間がかかりすぎるので。レビュアーの注意力も重要な設計／実装ポイントに集中させたい。