DataSense サポートの追加

DataSense は、モジュール内のエンティティの型メタデータを表示する Mule サービスです。

この機能は省略可能ですが、モジュールを使いやすくするために、モジュールで DataSense を使用することを強くお勧めします。

このドキュメントでは、エンドユーザの視点から見たコネクタのアーキテクチャと DataSense の概念について読者が精通していることを前提としています。

コンポーネントのメタデータとは?

インテグレーション開発者は、1 つのコンポーネントの出力を別のコンポーネントの入力に接続できるようにデータを変換するために、特定のコンポーネント (操作、ソースなど) の入力データ型と出力データ型の決定に多くの時間を費やします。この作業では、各コンポーネントの API ドキュメントを参照して必要なパラメータを見つけなければなりません。このプロセスは非効率的で、間違いを犯しやすく、ときにはストレスも溜まります。

DataSense は、これらのコンポーネントが提供するメタデータを使用して、必要な情報をすべて自動的に解決してデザイン時にエンドユーザに提供してくれるので、開発を大幅にスピードアップすることができます。

ここで言う「型」とは、要素の MetadataType を意味します。MetadataType は、特定の要素の種類や構造を表します。たとえば、基本的な文字列や数字の要素であれば StringTypeNumberType、コレクションなら ArrayType、ネストされた要素を持つ複雑な構造 (POJO や JSON オブジェクト) であれば ObjectType、型が未知で、他の使用可能などのタイプでもよい要素であれば AnyType になります。

「DataWeave の型」を参照してください。

静的メタデータ

静的メタデータとは、コンパイル時に既知で、コネクタの JAR ファイルにある型から使用できるメタデータです。単純な Java 型は、開発者がモデルで定義したカスタム POJO と同じように、この静的メタデータに属します。重要な点は、構造が明確に分かっていて、他のパラメータに依存せずに調査できるということです。

動的メタデータ

動的メタデータとは、コンパイル時に型が未知のメタデータです。動的メタデータは、コネクタの設定に基づいてデザイン時に解決する必要があります。このメタデータには、さまざまなケースでいろいろな使い方があります。たとえば、型そのものは既知でも構造がサービス設定に依存するケース (例: システムのアカウントにユーザがカスタマイズできる項目があるため、ユーザのログイン情報に基づいてその構造を毎回検出しなければならない場合) や、すべてが動的であるため、記述されている構造が設定済みパラメータに大きく依存するケース (例: 記述されている構造がサービス操作のペイロードであり、ユーザの Sandbox に基づいたサービス定義にも依存する場合) があります。

動的メタデータを解決するには、現在のコンポーネント設定に従って必要な型構造を取得する方法を知っているメタデータリゾルバに要素を関連付ける必要があります。詳細は「メタデータリゾルバ」を参照してください。

入力メタデータ

入力メタデータは、コンポーネントのパラメータのタイプを解決します。各パラメータは、同じコンポーネントの他のパラメータが公開している種類のメタデータから分離された静的または動的メタデータを提供します。

動的メタデータのパラメータは操作とソースでのみ使用できます。設定と接続のパラメータは常に静的メタデータとなります。

出力メタデータ

コンポーネントの出力は、メタデータの静的または動的な解決にバインドされます。たとえば、void 操作は、操作の出力が VoidType であることを示す静的メタデータを持ち、リモートサービスから User プロファイルをフェッチする操作は User タイプを動的に記述できます。

構造についての説明にあるように、操作の出力結果には、ペイロードのデータと返されるメッセージの属性が含まれます。これらの属性の構造は、ペイロードの構造と同じくらい重要です。それぞれのメタデータを独立して記述することで、エンドユーザにとっては使いやすくなります。ただし、一部のコンポーネントは属性を生成しないため、属性の動的メタデータの記述は常に任意で行います。

特定の戻り値のデータ型では、強制的にメタデータが動的に記述されます。これはエンドユーザの使い勝手を向上させるための要件であり、型の記述が汎用的過ぎると使いづらくなるためです。

実装の概要

動的 DataSense サポートを実装するには、まず、特定の要素で提供するメタデータの型を定義します。型を定義したら、アノテーションと異なるメタデータリゾルバのカスタム実装の組み合わせ (例: @MetadataKeyId(BucketKeysResolver.class)) を活用できます。どの組み合わせを使用するかはユースケースによって異なります。

以降のセクションでは、上記のケースの実装について説明します。

メタデータキーパラメータ

動的メタデータ構造を記述するには、どの型を表現するのかを知る必要があります。この型の参照を定義するには、記述する型の ID を含む @MetadataKeyId パラメータを操作で指定します。

たとえば、汎用レコードを Amazon S3 に保存する操作があるとして、サポートされる各型の構造 (AccountOrganization など) を記述しておけば、デザインしやすくなります。この場合は、操作のパラメータの 1 つに ID として Account または Organization を含む型の参照を定義します。このパラメータは、バケットに保存するレコードの Account 構造または Organization 構造 (エンドユーザが使うと決めた方) を記述します。

@MetadataKeyId パラメータは常に必要というわけではなく、設定に応じて動的に変化する構造が (複数ではなく) 1 つしかない場合などには不要です。たとえば、接続用のログイン情報がシステム管理者用であるかどうかによって構造が変化する User エンティティなどです。

メタデータリゾルバ

DataSense の動的要素を取得する場合は、メタデータリゾルバを実装します。リゾルバには多くの種類があり、それぞれ機能とユースケース (後述) が異なりますが、中心となる以下の概念は同じです。

  • カテゴリ名: 異なるメタデータリゾルバが連携するように関連付けるグループの名前です。

  • リゾルバ名: 特定のメタデータリゾルバを一意に識別する名前です。異なるリゾルバが同じ category に属することはできますが、リゾルバ名は 異なっている必要があります

  • メタデータコンテキスト: メタデータフェッチ呼び出し中に使用するすべての設定要素と接続要素へのアクセスと、TypeLoaderTypeBuilder などのユーティリティコンポーネントを提供します。動的型を作成する場合は、コンテキストによって提供される実装を常に使用することが重要です。

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub