コードの再利用

目次

  1. 検索と再利用
  2. UI
  3. ビジネスロジック
  4. データベース
  5. OutSystemsでのコードの再利用が優れている理由

OutSystemsで構築したアプリケーションのコードは、共有して再利用できます。共有されたコードは、他のアプリケーションからの検索と使用が可能になります。コードの再利用は、すべてのアプリケーションレイヤー( UIジネスロジックデータベース)で可能です。また、OutSystemsでは、様々な理由からコードの再利用を推奨しています。

検索と再利用


アプリケーションのモジュールを定義するビジュアルモデル内で、オブジェクトにPublicプロパティが割り当てられます。このプロパティによって、複数のアプリケーションでのオブジェクトの検索と再利用が可能になります。Publicプロパティが割り当てられたアクションの例を以下に示します。

Publicプロパティが割り当てられたオブジェクトは、開発環境で検索できます。

UI


開発者はUIレベルで様々なコードを公開し、OutSystemsの他のアプリケーションで再利用できるようにすることが可能です。

Webブロック


こうしたUIは、様々な目的で再利用することができます。

  • データ入力、ユーザーインターフェイス、イベント、通知を備えた自己完結型ウィジェットとしての活用。顧客情報を更新する顧客データの要約を、1つ以上のアプリケーションの複数ページで使用する場合などがこれにあたります。
  • JavaScriptとCSSの機能のパッケージ化。この例としては、Google Mapsコンポーネントがあります。このコンポーネントは、Google Maps APIを使用して、OutSystemsのアプリケーションで地図を使用する機能を公開しています。
  • スタイル、プレースホルダ、機能を備えたテーマレイアウトページとしての利用。たとえば、OutSystemsのビルトインテーマは、Web、メール、ポップアップなど様々な画面タイプ向けに多様なレイアウトを公開することでこの概念を利用しています。

テーマ


テーマではCSSが公開されます。テーマの再利用時には、テーマを使用するアプリケーションがテーマのスタイルシートを継承し、ローカルで上書きすることになります。OutSystemsのビルトインテーマは、この概念を利用しています。

ゼロからテーマを構築することもできるため、設計チームやデジタル広告代理店が開発したCSSスタイルシートを簡単に統合することもできます。

ページ


Web画面を公開し、移動やリダイレクト制御の手段として再利用できます。同じポータルの複数のモジュールで共通のログインページを使用する場合などがこれにあたります。

ビジネスロジック


OutSystemsで記述したビジネスロジックのすべてのブロックは、別のビジネスロジック関数、ビジネスプロセスオーケストレーション、Web画面、モバイル画面、または非同期ジョブで再利用が可能です。ロジックは同じモジュールで再利用される場合もあれば、複数のアプリケーションで再利用される場合もあります。

単一のアプリケーションで使用可能なロール:

ダッシュボードにアクセス可能なロール:

ロールという概念は、ユーザーインターフェイス要素とビジネスルールを管理するロジックでよく使用されますが、複数のアプリケーションで共有することもできます。たとえば、ユーザーに割り当てられるManager(管理者)というロールは、アプリケーションによって権限が異なる場合がありますが、ユーザー管理という観点では同じロールと言えます。

Webサービスを公開することでも機能を共有できますが、OutSystemsの複数のアプリケーションに対してだけではなく、分離された状態でWebサービスを使用できる外部アプリケーションに対しても公開されるという点が異なります。

データベース


OutSystemsで設計してデプロイしたすべてのデータベースのテーブル(エンティティ)は、Publicに設定することで、他のあらゆるアプリケーションで再利用することができます。データを読み取り専用として共有する場合、データを使用するアプリケーションから特定のテーブルへの書き込みはできません。読み取りと書き込みの両方が可能な形で共有する場合、データを使用するアプリケーションがデータに対して完全な管理権限を持ちます。

たとえば、一般的にはマスターデータの整合性を維持するために、単一の顧客テーブルを複数のアプリケーションで使用します。

顧客データを分離するモジュール:

他のモジュールの顧客データを使用:

OutSystemsは標準のデータベーステクノロジー(Microsoft SQL Server、Oracle、MySQL)を使用してデータスキームのデプロイを行うため、オンプレミス環境でも、外部システムにこうしたデータベースの読み取りや書き込みを簡単に実行させることができます。このシナリオでは、プラットフォームが生成したコードを外部アプリケーションで共有して再利用しています。

メモリーデータ構造の定義にも、複雑な補助データ型の整合性を保持するため、複数のアプリケーション間で共有可能なコードがあります。

OutSystemsでのコードの再利用が優れている理由


OutSystemsでのコードの再利用が優れている点は、ガバナンス、アプリケーション間の依存関係を把握するためのレポート、および変更による影響の分析を行う機能が備わっているということです。

ガバナンス


コードの再利用のみでも便利ですが、管理下で行うことができるとさらに有益です。

OutSystemsでは、特定の環境で特定のアプリケーションと連動して特定のタスクを実行するロールを管理することができます。この観念を使用して、各アプリケーションが公開する共有コンポーネントにアクセス可能なユーザーやチームを選別することができます。

開発者の権限の例:

上級開発者の権限の例:

依存関係の把握


OutSystemsのコンソールには、アプリケーション間の依存関係を閲覧して把握できるレポートが表示されます。アプリケーション間の依存関係やモジュール間の依存関係など、詳細度のレベルも選択できます。

アプリケーション間およびモジュール間の依存関係マップ:

また、OutSystemsはオープンなプラットフォームであるため、拡張が可能です。たとえば、Forge Webサイトからダウンロード可能なアーキテクチャ解析ツールのように、アプリケーション間の相互関係を詳しく表示するコンポーネントを追加で作成することができます。

影響分析


OutSystemsでは、特定のモジュールに変更を加えた場合の影響を、パブリッシュ時に即座に確認することができます。依存関係分析グラフの一例を以下に示します。

開発者は、どのモジュールまたはアプリケーションが影響を受けるのか、また修正と再コンパイルのどちらが必要かを、リアルタイムで確認することができます。

リファレンスが壊れているのでデプロイを回避した場合:

複数の環境にアプリケーションをパブリッシュすると、コードの再利用という観点で欠かせない依存関係がすべて特定、パッケージ化されるだけでなく、異なるバージョンがすでにデプロイされている可能性のある別環境でコードを再利用した場合の影響分析も実行されます。