OutSystemsは複数のアプリケーションを開発することで本領を発揮するローコード開発プラットフォームです。そのため、アプリケーション間の機能の共有が簡単にできる機能が備わっています。
こちらのブログ記事では、Actionを公開する（＝Actionのパラメータの「Public」を「Yes」に設定する）ことで、ビジネスロジックを複数のアプリケーション間で共有できることを解説しましたが、画面上の部品＝UI部品は共有可能なのでしょうか？
ユーザー検索のように多くの画面で使用する機能は、部品を一度開発して共有できたら大幅に開発を効率化できそうです。実際のところ、OutSystemsでは、「Block（ブロック）」というウィジェットを用いることで、画面共通部品を実装することができます。

本ブログ記事では、「Block（ブロック）」を使って実際に再利用可能な共通UI部品を開発しながら、その機能や使用方法について解説します。

OutSystemsのBlock（ブロック）とは？

OutSystemsでは、アプリケーション間でUIの一部を再利用するのに、「Block（ブロック）」や「Web Block（Webブロック）」というウィジェットを使用します。
「Block（ブロック）」や「Web Block（Webブロック）」を使用すると、UIの一部の実装を1箇所にまとめることができます。そして、ブロックへの変更は、そのブロックを使用するすべての画面で自動的に表示されます。

言い換えると、「Block（ブロック）」と「Web Block（Webブロック）」は、どちらも独自のロジックを実装できる再利用可能な画面の一部のことです。
「Block（ブロック）」は、Reactive Web および モバイルアプリケーション を開発する場合に使用し、「Web Block（Webブロック）」は、Traditonal Webアプリケーションを開発する場合に使用します。
＊「Block（ブロック）」と「Web Block（Webブロック）」の機能は同じです。
＊OutSystemsで開発するアプリケーションの形式に応じて、この2つのどちらを使用するかが異なります。
＊Traditional Webアプリケーション形式は、2021年8月以降の新規販売ライセンスでは使用できないアプリケーション形式です。
　（今からご購入いただくライセンスを使用して開発する場合は、「Block（ブロック）」のみ使用することになります）

次章では、「Block（ブロック）」の具体的な機能について解説します。

OutSystemsのBlock（ブロック）でできることとは？

Blockの最も基本的な機能は、複数の画面で使用される共通のUIのソースコードを一元化できることです。
アプリケーション名/アイコン/ユーザー名などは、OutSystems UIの標準デザインでヘッダーに必ず表示されるようになっていますが、よく見るとそれらの部品がBlockを用いて実装されていることが分かります。

＊「ApplicationTitle」は、ヘッダーでアプリケーションのアイコンと名前を表示しているBlockです。

また、Blockは、Input Parameterを定義して引数を受け取ることが可能です。
Blockを配置した親の要素（※1）から情報を受け取ることで、Block内の表示内容やロジックを切り替えることが可能なため、複数の画面に対応しつつも各画面に応じた最適な機能を提供することができます。
※1：Blockは画面だけでなく、異なるBlockに配置することも可能なため、画面と他のBlockを指して便宜上「親の要素」と表現しています。

＊「Menu」は、現在表示している画面がヘッダー上で強調されるように、画面ごとに異なるInput Parameterを受け取っています。

さらに、Blockは、通常の画面と同じように、On Parameters ChangedやOn Initialize～On Destoryまでのすべての画面ライフサイクルイベントをハンドリングできます。
Actionも画面と同様に実装できるため、Blockの機能は画面が持っている機能とほとんど変わりありません。

注意すべきポイントは、Block内部の処理や変数は全て閉じられていることが挙げられます。具体的に述べると、Blockを配置した親の要素は、Block内で保持されている変数や、どんなActionが実行されているかについて、能動的にアクセスすることができません。これに対しては、Blockに「Event」を定義することで、Block側から親の要素に通知を行うことが可能です。

＊「Event」は、Block内で自由に定義でき、ボタン押下時やロジックフロー内などの任意のタイミングでトリガーすることができます。
　Blockを配置した親の要素は、定義されている「Event」のHandlerにActionを設定することにより、BlockからトリガーされたタイミングでActionを実行することができるようになります。

＊EventにはMandatoryプロパティがあるため、「No」に設定すれば親の要素でEventをハンドリングしない選択もできるほか、Input Parameterを追加できるため、親の要素にデータを受け渡すことも可能です。これによって、Blockと親の要素が適切に連携できるようになります。

このように、Blockは画面表示における再利用可能な要素として、複数の便利な機能を兼ね備えています。では、これらの機能を存分に活用する実装例として、次章では実際に再利用可能な画面共通部品を作ってみましょう。

OutSystemsのBlock（ブロック）を使って共通部品を作ってみた

それでは、Blockを使用して共通部品を作成します。題材は、OutSystemsの多くのアプリケーションで再利用されることをイメージして、エンドユーザーの検索・選択の部品とします。

まずはBlockを作成します。
Block内で「Aggregate」を作成し、標準エンティティのUserを取得するようにしましょう。

画面表示には、「Dropdown Search」を使います。
＊簡単な部分一致検索であれば、「Dropdown Search」だけで十分です。
「Aggregate」で取得されたリストを設定し、各プロパティにリスト内の項目を設定していきましょう。

パーツ上に表示される「Label」は名前、「Value」はUserのId、選択肢に付随する情報の「Description」としてメールアドレスと電話番号が表示されるようにします。

OnChangedイベントハンドラでは「New Client Action」を選択します。
ここではドロップダウンのアイテムが選択された時の処理を実装します。
Block内で選択されたユーザーの情報を保持していても意味がないので、Eventを介して親の要素に情報を受け渡します。
「Add Event」からEventを追加し、“UserSelected”という名前にしてみました。
親の要素にUserの情報を渡すため、Input Parameterを追加してデータ型をUserにします。

OnChangedのアクションフロー上に、「Trigger Event」ツールを追加して、“UserSelected”をトリガーするように設定しました。
Input Parameterにユーザーを渡すため、「ListFilter」を使用してAggregateから選択されたユーザーのUserレコードを絞り込みます。
条件には、OnChangedアクションの「SelectedOptionList」の「Value」を使用します。
「Dropdown Search」のOptionsListを設定した際に、この「Value」には選択されたユーザーのUser Idが渡されるようになっています。

続けて、「ListFilter」の結果のユーザーレコードを、EventのInput Parameterに設定します。

これでユーザー検索部品の基本機能は完成です。
新しく画面を作成し、Blockを配置して返却されたユーザーの名前がメッセージで表示されるように実装します。

想定通りの動作が確認できました。
続いて、BlockにもInput Parameterを追加してもう少し便利にしてみましょう。

追加するのは“IsDisabled”と名付けたBoolean型のパラメータです。その名の通り、部品を無効化する際にこのパラメータに「True」を渡します。この部品は有効化されていることが通常の状態のため、パラメータの設定は任意（Is Mandatory = No）とし、デフォルト値は「False」にします。
渡された値はそのまま、「Dropdown Search」のOptionalConfigs.IsDisabledに設定しましょう。

テスト用の画面でBooleanを変更できるようにSwitchを実装し、動作を確認してみます。

このように、Block自体も親の要素からパラメータを受け取り、値によって内部のプロパティなどを連動させることも実現できます。

最後に、体裁を整え、Blockの「Public」プロパティを「Yes」にしてパブリッシュします。これで他のモジュールからもこのBlockが参照できるようになりました。
他の開発者はこのBlockを参照に追加し、必要な画面上に配置した上で“IsDisabled”のパラメータの設定と、UserSelectedイベントのハンドラを実装するだけで、簡単にユーザー検索・選択の機能を利用できるようになりました。

まとめ

ここまで、Blockの機能をわかりやすく解説すべく、基本機能のご説明と共に、シンプルなユーザー検索・選択部品を作ってみました。
このレベルの複雑性であれば、改めて共通部品化する必要性は低いかもしれません。しかし、様々なアプリケーションが作られていくにつれ、検索条件が複雑になったり、追加のエンティティと結合する必要性が出てきたりなど、共通部品に求められる機能も多様化していきます。Blockは各アプリケーションのニーズをまとめるだけでなく、ソースコードを一元化することでアプリケーションによる機能品質の差を極小化する効果ももたらしてくれるのです。

共通部品の作成は、通常のアプリケーション開発とは異なります。求められる機能の実現と同時に、汎用性や利便性との両立も目指し、OutSystemsの環境全体を俯瞰して開発しなければなりません。弊社はそういったOutSystemsの活用を包括的に推進する組織として、CoEチームを組成することを推奨しております。CoEチームの有用性や組成方法についてご興味のある方は、是非、弊社までお問い合わせください。
https://itsol.dentsusoken.com/outsystems/service/coe/

弊社電通総研は、ローコード開発プラットフォーム：OutSystemsの導入/活用を支援する様々なサービスメニューをご用意しております。
ローコード開発のはじめの一歩を、電通総研と一緒に踏み出してみませんか？

電通総研のOutSystems関連サービスページ：https://itsol.dentsusoken.com/outsystems/service/

本ブログは、2023年8月1日時点の情報をもとに作成しています。
OutSystemsに関する詳しいお問い合わせは、弊社Webサイトからお問い合わせください。
https://itsol.dentsusoken.com/outsystems/inquiry/