Forgeコンポーネントを業務システムの部品として使う際の注意

Forgeは、OutSystemsのためのオープンソースプログラムのレポジトリ。

便利な部品が沢山登録されているが、注意点もある。

ここでは、業務システムの部品として、Forgeにあるコンポーネントを使う際の注意点をいくつか挙げておきたい。

ライセンス

オープンソースライセンスそのものについては助言できない。ここでは、主にForgeコンポーネントに適用されるライセンスがなにかを確認する方法について述べる。

Forgeコンポーネント自体にはBSD-3-Clauseが適用される

What do you mean when you say “open-source projects”?に明記されている。

また、Forgeにコンポーネントをアップロードする際にも注意事項として表示される。

しかし、これは全ての機能をBSD-3-Clauseに基づいて使用できることを意味しない。

上記リンク先にも記載がある通り、コンポーネントが、他のライセンスが適用されるプログラムを含んでいることがある。このライセンスをチェックして遵守するのは「Forgeコンポーネント利用者」の責任であるという点に注意が必要。

.NETのライブラリを使うものについての注意

.NETのライブラリは、Extension経由でしか組み込まれないため、コンポーネント内に含まれるExtensionに注意を払えば良い。

  • Forgeのプロジェクトページ(主にOverviewとDocumentation)
  • Integration Studio → Visual Studioで開き、参照しているライブラリをチェック
    • 見つかったら、名前を手がかりにライブラリのプロジェクトページを探し、そのライセンスをチェック
  • コードから外部の実行ファイルをダウンロードするものもたまにある
    • 例:UltimatePDF(実行時にChromiumの実行ファイルをダウンロードする)

JavaScriptのライブラリを使うものについての注意

JavaScriptのライブラリについては、埋め込める場所が多い。以下にいくつか挙げるが、他にもあるかもしれない。

  • Resources
  • (Reactive/Mobileのみ) Scripts
  • (Reactive/Mobileのみ) JavaScript要素
  • (Traditionalのみ) ExpressionのEscape Content=Noにして埋め込み
  • (Traditionalのみ) Module/Screen/BlockのJavaScriptプロパティ
  • HttpRequestHandlerモジュールのAddJavaScriptTag/RunJavaScript Action
  • (System)のRequireScript

BlockやAction内に上記の内容が隠れていることもあるため、Producerがあるときはそちらもチェックすること。

更新

導入時にはコンポーネント名とバージョンを記録しておく

Service CenterやService Studioでは、環境にインストールされたForgeコンポーネントのリストやそのバージョンを確認することができない。

そのため、導入検討時に、コンポーネント名とバージョンを記録しておいたほうがいい(後述の代替策もある)。

Service Studioでの更新チェックと更新

インストールされたForgeコンポーネントの最新版が公開されていると、Service Studio右上のベルアイコンから、そのコンポーネント名と最新バージョンが表示される。Updateをクリックすると最新版に更新もできる。

Forgeコンポーネントによるチェック

Forge Components Installed Versionsというコンポーネントを使うと、環境内にインストールされたForgeコンポーネントを一覧表示できる。

(内部的に非公開のテーブルを使っている)

参考:Forgeコンポーネントのバージョン問題

保守

Supported/Trusted

Forgeのサイト上で、コンポーネントに以下のようなマークが付いているものがある。このマークが付いているものは、サポートがあるため、採用しやすい。

Supported: OutSystems自体が作ってメンテナンスしているコンポーネント。契約が有効な期間はOutSystemsのサポートが受けられる

Trusted: OSSではあるが、OutSystemsが定めた基準に従ってチェックを受けているコンポーネント。基準の中に「コメントや質問に回答している」「報告されたエラーを解決している」がある。

このマークがもともとついていたコンポーネントが、バージョンアップしていく過程で外れたものがあるので、当てにしすぎるのも危険。

OSSなので、サポートはボランティアベース

各コンポーネントのプロジェクトページに、Supportタブがあり、質問やバグ報告ができる。

ただし、OSSの特性により、確実なバグ対応や期限の提示は期待できない点に注意(どうしても必要なら、「自分でやりましょう」ということになる)。

最後は自分でメンテナンスする覚悟を決める or 別のコンポーネントに置き換えられるように利用する

Forgeコンポーネントは、OSSであるため、基本的には確実なサポートを受けられるとは限らない。そのため、Platform Serverのバージョンアップに追随されなかったり、大きなバグが修正されなかったり、セキュリティの問題が修正されない可能性がある。

その場合の対策として、

  • 導入時にプログラムをチェックし、自力でメンテナンスする覚悟を決める
    • (引き受けてくれる会社があれば)外注等でもいいかもしれない
  • 間に抽象化レイヤーをかませてから利用するようにする(抽象化レイヤーから参照しているForgeコンポーネントを別のものに差し替えられるように)

信頼性

プロジェクトの属性によるチェック

プロジェクトページをチェックして、以下のような点を判断基準にする。

  • ダウンロード数: 利用者が多いほど、多くの人のチェックを受けている。利用過程で問題が抽出され、修正されていることも多い。問題があったときに修正してくれる人も多いかもしれない。2022/3時点では、ダウンロード数が4桁あれば多い方
  • Team: プロジェクトページのOverviewタブで確認できる。コンポーネント開発権限のあるメンバ。OutSystems StaffやMVP/Champion、あるいは評価の高いコンポーネントをたくさん作っているメンバが参加している(できれば作成者である)とよい

含まれている.NETやJavaScriptのライブラリについても同様の方法で確認する。

プログラムのチェック

コンポーネントを開いて、実装を確認する。

  • OutSystemsのベストプラクティスに沿っているか
  • .NETやJavaScriptの場合、それぞれのベストプラクティスに沿っているか
  • 不必要にリソースを消費する処理がないか
  • セキュリティの観点
  • 保守しやすいプログラムになっているか(自分でメンテナンスすることになる可能性もあるので)
  • OutSystemsについてはArchitecture Dashboard、.NETやJavaScriptについてはそれぞれに対応する静的解析ツールの助けを借りると良い

方針系記事

シェアする

  • このエントリーをはてなブックマークに追加

フォローする