Skip to main content

 

OutSystems 11オンラインヘルプ

 

OutSystems

サービスを使用して機能を公開する

アプリケーションのアーキテクチャの設計は反復的かつ連続的なプロセスです。アプリケーションが大規模になるにつれ、特定のビジネスコンセプトまたはビジネスに依存しないサービスを抽象化してフレームワークを拡張し、他のアプリケーションで再利用できるようにそれらを公開する必要がある場合があります。

OutSystemsでは、サービスモジュールサービスアプリケーションを使用して、アプリケーションをリファクタリングしたりサービス指向アーキテクチャを作成したりできます。

サービスモジュールとサービスアプリケーション

OutSystemsでは、Webアプリケーションまたはモバイルアプリケーションでサービスモジュールを使用して、懸念事項の分離を適用することやコアサービスをカプセル化することができます。

サービスポートフォリオのサイズに応じて、サービスアプリケーションを作成してサービスモジュールを整理することもできます。

サービスモジュールでは、コアサービスを構成する要素を定義します。

  • サーバーアクションおよびサービスアクションを使用するサービスロジック。
  • 統合(SOAP、REST、SAP)。
  • プロセスおよびタイマー。
  • データベースエンティティ。

コアサービスの性質上、UIに関連する要素をサービスモジュールに含めることはできません。このため、サービスモジュールでは以下の機能を使用することはできません。

  • [Interface]タブ
  • UIアセットのモジュールプロパティ(JavaScript、グローバルエラーハンドラなど)
  • クライアント側ロジック
  • ローカルストレージ
  • セッション変数

UIに関連する要素を実装するには、Webモジュールまたはモバイルモジュールを使用する必要があります。

サービスのロジックを実装する

OutSystemsでサービスを実装する方法は、サービスの機能を外部システムに公開するか、同じOutSystems環境内で公開するかによって異なります。

  • 外部システムまたは異なるOutSystemsインフラに機能を公開する場合: サービスモジュールでREST APIまたはSOAP Webサービスを公開して、サービスのロジックを実装できます。

  • 同じOutSystems環境内の他のモジュールまたはアプリケーションによって再利用されるサービスを公開する場合: パブリックサーバーアクションを公開して密結合でサービスのロジックを実装したり、サービスアクションを公開して疎結合でサービスのロジックを実装したりできます。

サーバーアクションを公開する

OutSystemsでは、サーバーアクションを公開すると、密結合でコンシューマからプロデューサモジュールへの強い依存関係が生成されます。

サーバーアクションのロジックがまるでコンシューマモジュール内で定義されているかのように実行され、同じリクエストとトランザクションによる単一プロセス内で実行されます。

公開されたサーバーアクションの実装が変更される都度、コンシューマモジュールをリフレッシュおよび再パブリッシュして最新バージョンの使用を開始する必要があります。

サービスアクションを公開する

OutSystemsでは、サービスアクションは別のプロセスに対するRESTに基づくリモート呼び出しですが、使用方法はパブリックサーバーアクションに非常に似ています。

サービスアクションを公開すると、疎結合でコンシューマからプロデューサモジュールへの弱い依存関係が生成されます。

公開されたサービスアクションの実装が変更される都度、その変更はコンシューマモジュールでただちに有効になります

サービスアクションのリモート呼び出しを行うとき、OutSystemsはクライアントセッションからの以下の情報を渡します。

  • ユーザーIDおよびテナントID。これにより、サービスアクションの実装内でGetUserId()やCheckRole()などのビルトイン関数が使用できるようになります。

  • ロケール。これにより、サービスアクションの実装内でビルトイン関数GetCurrentLocale()が使用できるようになります。

  • リクエストキー。これにより、Service Centerで同じ最上位レベルのリクエストからのすべてのログを関連付けることができるようになります。

サービスアクションには、疎結合のREST APIメソッドの利点と密結合のサーバーアクションのRAD(Rapid Application Delivery)機能の利点が混在しています。

検索性
サービスアクションを含むモジュールをパブリッシュすると、[Manage Dependencies]ウィンドウからアクセスできる再利用可能な要素の内部カタログに含まれるコンシューマで、サービスアクションがただちに利用可能になります。
影響分析
OutSystemsでサービスアクションのシグネチャを変更することによる影響が計算され、[Manage Dependencies]ウィンドウに表示されます。これは、新しいバージョンのサービスを作成する必要があるかどうかを判断するときや、サービスの変更によるコンシューマへの影響がないかどうかを特定するときに役立ちます。
強い型付け
サーバーアクションと同様、サービスアクションは強い型付けのロジック要素です。サービスアクションのシグネチャでエンティティとストラクチャを使用できます。
セキュリティ
サービスアクションには同じ環境からのみアクセスできます。サービスアクションへの呼び出しを行うと、OutSystemsはクライアントセッションからの認証コンテキストを渡します(ユーザーIDおよびテナントID)。
例外処理
サービスアクションによってスローされたUser ExceptionとCommunication Exceptionは、コンシューマモジュールで捕捉できます。
アクセスガバナンス
サービスアクションは、LifeTimeの権限によって定義された他の再利用可能な要素と同じガバナンスモデルに従います。

スケーラビリティ

疎結合の性質があるため、サービスアクションを使用すると、コンテナのデプロイによってサービスを拡張し、追加の負荷に対応することができます。この場合、サービスへのリクエストが複数のコンテナ間で分散されます。

トランザクションおよびネットワークを処理する

サービスアクションはコンシューマと同じプロセスやトランザクションを共有しないため、サービスアクションを使用するフォールトトレラントなサービスを実装するには、コンシューマ側でロジックを追加する必要があります。

サービスアクション内で実行されたオペレーションが失敗した場合、コンシューマロジックで失敗を処理し、そのオペレーションを元に戻すことを評価する必要があります。コンシューマ内でロールバックがあっても、サービスアクション内で実行されたロジックがロールバックされることはありません。また、サービスアクション内でロールバックがあっても、コンシューマによって以前に呼び出された他のサービスアクション内で実行されたロジックがロールバックされることもありません。

サービスアクションを使用するとリモート呼び出しによってロジックが実行されます。したがって、同じロジックを単一プロセスで実行する場合に比べるとパフォーマンスが大幅に低下する可能性があります。このため、リモートリクエストによって渡されるデータ量をロジックで考慮しておく必要があります。 また、通信障害が発生した場合、コンシューマロジックでCommunication Exceptionを処理できるように準備しておく必要があります。

サーバーアクションまたはサービスアクションを選択する

サーバーアクションとサービスアクションにはいずれも独自の特性があり、ユースケースに応じて使用する必要があります。

以下の表は、サーバーアクションとサービスアクションの最も重要な差異を比較したものです。

サーバーアクション サービスアクション
リリースサイクル 実装を変更するにはコンシューマもデプロイする必要があります。 コンシューマとは無関係に実装の変更をデプロイできます。
コンテナによる拡張 各ランタイムはすべての依存関係とともにパブリッシュされます。 疎結合の要素は別々に作成してパブリッシュできます。
サービスの通信 コンシューマモジュールとプロデューサモジュールは単一のプロセスで実行されます。 コンシューマモジュールとプロデューサモジュールは別のプロセスで実行されます。
DBトランザクション すべてのトランザクションが単一のプロセスに含まれます。 複数のプロセスには複数のトランザクションが必要です。
開発労力 ロジックが単純であり、短時間での開発が可能です。 トランザクションとネットワークを処理するためにロジックを追加する必要があります。

アプリケーションのライフサイクルは、通常、小規模な密結合のアプリケーションから開始します。アプリケーションが大規模なポートフォリオへと進化を開始すると、モジュールの分離を開始する適切な時期を判断し、サーバーアクションの代わりにサービスアクションを使用して機能を公開する必要があります。

OutSystemsには、既存のモジュールとロジックをサービスに変換するときに役立つ複数の機能が用意されています。

リリースサイクルが同じ小規模なアプリケーション

多くの場合、最初は単一のアプリケーションで使用する小規模なサービスを作成します。販売部門のOrder Managementアプリケーションで再利用される機能をカプセル化したCustomerサービスの例を見てみましょう。

サーバーアクションを使用してCustomer機能を公開すると、同じリクエストとトランザクションによる単一プロセス内でロジックが実行されるため、Order Managementアプリケーションのロジックが簡素化されます。しかし、Customerサービスを変更するとき、Order Managementアプリケーションのデプロイも必要になる場合があります。

これらのモジュールが同じリリースサイクルである限り、これらのモジュールの密結合を維持してもデプロイフェーズに悪影響はなく、開発速度に関しては好影響をもたらします。

リリースサイクルが似ている複数のアプリケーション

システムが進化すると、同じ販売部門のShippingアプリケーションなど、サービスを使用するアプリケーションが増えます。

モジュールの密結合を維持し、サーバーアクションを使用してCustomer機能を公開するには、モジュールの変更のたびにCustomerサービスと一緒にOrder ManagementアプリケーションとShippingアプリケーションの両方をデプロイする必要があり、デプロイの労力が増えます。一方で、Order ManagementアプリケーションとShippingアプリケーションのロジックの開発と保守のしやすさはそのままです。

いずれのアプリケーションも販売部門に属していてリリースサイクルが似ているため、デプロイの労力はまだ許容範囲です。このように、まだ開発速度の速さによる利点があります。

様々な業務をサポートする大規模なアプリケーション

様々な業務をサポートし、独立したリリースサイクルを持つ複数のアプリケーションで再利用されるサービスの使用を開始する場合、すべてのモジュールの密結合を維持することがデプロイフェーズにおける重荷になり始めます。Customerサービスを変更するとき、コンシューマのデプロイ準備がまだできていない場合があるため、各コンシューマのリリースサイクルに悪影響が出ます。

この時点で、サービスアクションを使用して疎結合でサービスの機能を公開することを検討する必要があります。

この場合、サービスアクションを使用して機能を公開すると、複数のコンシューマが独立したリリースサイクルを持つことができ、ビジネス価値が向上します。一方、開発者は、複数のプロセスとトランザクションを処理するために追加のロジックを実装する必要があるため、開発労力が増えます。

サービスアクションを使用して機能を公開するかどうかを判断するには、開発労力の増加が、独立したリリースサイクルによるビジネス価値の増加と釣り合うものであるかどうかを評価する必要があります。

拡張要件のあるサービス

処理能力を必要とするタスクを伴う大規模な分散型サービスがすでにある場合、サービスアクションを使用すると、コンテナのデプロイによってサービスを拡張できます。

サービスアクションを使用して機能を公開するかどうかを判断するには、開発労力の増加が、サービスの拡張能力と釣り合うものであるかどうかを評価する必要があります。

  • Was this article helpful?