Skip to main content

 

 

 

 

 
Language:

 

 

 

 
 
OutSystems

階層化されたロールの実装

階層化されたロールを適用するユースケースを検討し、その手順について説明します。

ユースケース

会社の販売部門で使用するWebアプリケーションを実装する必要があるとします。このアプリでは、複数のユーザーが使用し、様々なデータとメトリックを含むダッシュボードを作成する必要があります。

販売部門にはVP、Manager、Agentなどの複数のロールがあり、このユースケースでは以下のロールについて考えます。

  • Director

  • Regional Manager

  • Account Manager

  • Agent

ロールの階層化組織は以下のとおりです。

  • AgentはAccount Managerの監督を受けます。

  • Account ManagerはRegional Managerの監督を受けます。

  • Regional ManagerはDirectorの監督を受けます。

この記事では、この階層に基づいた1つのソリューションの実装について説明します。この例では、様々なロールを職務と呼びます。

はじめに

Hierarchical Rolesアプリは汎用でビジネスに依存しないコンポーネントであり、開発インフラ内のすべてのOutSystemsアプリケーションで再利用できます。専用のアプリケーションを作成することを強く推奨します。

Hierarchical Rolesの実装の例を開始する前に、以下の前提について検討します。

  • 1人のユーザーは1つの職務のみを持つ。

  • 1つの職務は最大1つの職務の監督を受ける。

  • このアプリケーションのユーザープロバイダはOutSystemsのビルトインのUsersアプリケーションとする。

1つの職務が同時に複数の職務の監督を受けることができるようにするなど、実際のユースケースはおそらく少し異なります。その場合、次の章で示すコードを調整する必要があります。Hierarchical Rolesでもそれらの要件を満たすことは可能ですが、例をシンプルに保つため、以下の記事では説明しません。

この記事で説明している階層化されたロールの例をOutSystems Forgeからダウンロードして、開発インフラ環境でパブリッシュします。これを参照として使用するか、コードを調整してビジネスケースを実装します。

データモデル

Director、Regional Manager、Account Manager、Agentの4つのロールが特定されています。以降、この記事ではロールのことを職務と呼びます。

そのままではOutSystemsのロールを階層化することはできないため、特定された4つの職務を1つのOutSystemsエンティティに保存する必要があります。このエンティティをFunctionと呼びます。すべてのエンドユーザーにFunctionを割り当てる必要があります。

また、ベーシック認証メカニズムを作成するためのロールが1つ必要です。新しい販売アプリケーションを使用する必要があるすべての対象ユーザーは、Salesロールを持っている必要があります。これにより、ユーザーの一部のみが目的のアプリケーションにアクセスできるようになります。新しいモジュールを作成し、開発インフラのすべてのロールをまとめるか、少なくとも、階層レベルを適用するアプリのロールをまとめることを推奨します。このモジュールをRoles_Libと呼びます。

ここで、権限を定義して職務に割り当てることが重要です。最初にシンプルな権限を3つ作成し、後でリストを充実させてより細かい権限を設定することができます。Full Access(フルアクセス)、Read/Write(読み取り/書き込み)、Read-Only(読み取り専用)が基本となる権限です。静的エンティティ--Permission--を作成してこれらのレコードを保存します。各職務に権限を設定します。FunctionPermissionという新しいエンティティを作成します。

これでHierarchical Rolesの機能をサポートするためのデータモデルの準備ができました。ユーザーに新しい職務を割り当てる必要があります。ご存じのとおり、OutSystemsのUsersエンティティを変更することはできませんが、新しいエンティティUserExtensionを作成して拡張することができます。このエンティティにFunctionIdを保存します。

データモデルは以下のようになります。

階層化されたロールのデータモデル

データモデルに関する注記がいくつかあります。

  • 階層構造を作成するには、FunctionエンティティにReportsToアトリビュートを追加する必要があります。このアトリビュートはFunctionエンティティ(同じテーブル)の外部キーであり、特定の職務のすぐ上にある階層的の職務へのリンクを表します。

  • 職務グループにはDepartmentエンティティが含まれます。職務は会社の特定の部門または事業単位に関連付けることができます。たとえば、Project Managerの職務はIT部門内にありますが、販売部門にはありません。部門のコンセプトは、将来、グループ内(この例の部門内)の階層を作成するときにも役立ちます。ビジネスケースに応じて忘れずに調整してください。

  • ここで説明しているソリューションはあくまで例に過ぎません。ユースケースごとに異なる実装が必要です。

アーキテクチャ

このセクションでは、Hierarchical Rolesアプリケーションのアーキテクチャ設計について説明します。

Hierarchical Rolesアプリケーションのアーキテクチャ設計

Roles_Lib(ライブラリモジュール)

このモジュールで、階層化されたロールアプローチを必要とするアプリのすべてのOutSystemsのロールを作成できます。現在の例は、Hierarchical Rolesのバックオフィスの画面で使用するSalesロールとHierarchicalRolesAdminロールを示しています。

Rolesライブラリモジュール

Department_CS(コアサービスモジュール)

このモジュールにDepartmentエンティティが保存されます。先ほど説明したとおり、職務をグループ化する必要があります。この例は、そのために使用するDepartmentエンティティを示しています。

アグリゲータ(Department、Business Unitなど)がすでにどこかに実装されている場合は、Hierarchical Rolesアプリの外にこのモジュールを実装できます。

HierarchicalRoles_C(コアサービスモジュール)

このモジュールは、データモデルと、ユーザーの権限を検証するためのサーバーアクションを実装します。また、バックオフィス画面に公開するために作成された複数のCRUDアクションを示しています。

Hierarchical Rolesのコアサービスモジュール

以下の図は、GetPermissionsByUserIdアクションを示しています。

ユーザーIDで権限を取得するアクション

HierarchicalRoles(エンドユーザーモジュール)

このモジュールにはすべてのバックオフィス画面が含まれています。HierarchicalRolesAdminロールを持つユーザーのみがそれらの画面にアクセスできます。

バックオフィス画面のリスト

バックオフィス

これでデータモデルの実装は完了しました。次の手順では、Hierarchical Rolesのデータの管理と階層の構成を行うためのバックオフィス画面を作成します。

バックオフィス画面に複雑なロジックは不要です。そのため、スキャフォールディングパターンを利用して開発を高速化することができます。

作成する必要がある画面は以下のとおりです。それぞれにリストと詳細画面が必要です。

  • Departments(または、会社で特定されたその他のコンセプト)

  • Functions

  • Permissions

  • Users

以下の図は、職務のリスト画面を示しています。この画面は、既存の職務の作成と管理を行うときに使用します。

職務のリスト画面

以下の図は、職務の詳細画面を示しています。この画面は、職務の詳細を編集するときや職務に部門や直属の上位職務を割り当てるときに使用します。

職務の詳細画面

以下の画面は、権限のリスト画面です。この画面は、職務に権限を割り当てるときに使用します。

権限のリスト画面

以下の画面は、ユーザーのリスト画面を示しています。この画面は、ユーザーに職務を割り当てるときに使用します。

ユーザーのリスト画面

また、Hierarchical Rolesアプリには、認証メカニズムを実装するためのサーバー側のロジックが必要です。

バックオフィス画面を作成し、データベースに有意義なデータを追加した後、権限を検証するためのロジックを作成します。今後のアプリケーションでそれらのアクションを利用します。

必要に応じて、その他のアクションを加えてこのAPIを完全なものにすることができます。以下の2つのアクションが必須です。

GetPermissionsByUserIdアクション

このサーバーアクションによって、特定のUserIdに割り当てられた権限と職務が取得されます。このアクションを呼び出すと、ユーザーがFull、Read/Write、Read-Onlyのアクセス権を持つかどうかがわかります。また、ユーザーのFunctionId(Director、RegionalManager、AccountManager、またはAgent)も取得されます。

以下の図は、GetPermissionsByUserIdアクションを示しています。

GetPermissionsByUserIdサーバーアクション

以下の図は、GetPermissionsByUserIdアクションのロジックを示しています。

GetPermissionsByUserIdのロジック

以下の図は、CheckPermissionsのAggregateクエリを示しています。

GetPermissionsByUserIdのクエリ

HasAccessByFunctionIdアクション

Boolean型の値HasAccessを返します。出力変数HasAccessは、特定のユーザーが特定の職務(Director、RegionalManagerなど)へのアクセス権を持つかどうかを示します。

入力パラメータRequiredFunctionIdは、画面にアクセスするために必要な職務を表します。開発者は、画面にアクセスするために必要な職務を画面レベルで渡す必要があります。

HasAccess値は、ユーザーがRequiredFunctionIdの職務(または階層内のそれより上位の職務)を持つ場合にtrueになります。

例:

  • Agnes MarvsはAccount Managerです。

  • Agentの職務が必要な画面にアクセスした場合は、画面にアクセスすることができます。

  • しかし、Directorの職務が必要な画面にアクセスしようとした場合は、画面を表示できません。

なお、この例の階層では、DirectorはRegional Manager、Account Manager、Agentを包含する権限を持ち、Regional ManagerはAccount Manager、Agentを包含する権限を持っています。

以下の図は、HasAccessByFunctionIdアクションを示しています。

HasAccessByFunctionIdアクション

以下の図は、HasAccessByFunctionIdアクションのロジックを示しています。

HasAccessByFunctionIdのロジック

以下の図は、CheckPermissionsのSQLクエリを示しています。

権限確認のSQL

販売アプリケーションのデモについては、Salesアプリケーションのデモをご覧ください。