Flex Gateway新着情報
Governance新着情報
Monitoring API ManagerDataSense は、モジュール内のエンティティの型メタデータを表示する Mule サービスです。
この機能は省略可能ですが、モジュールを使いやすくするために、モジュールで DataSense を使用することを強くお勧めします。
このドキュメントでは、エンドユーザーの視点から見たコネクタのアーキテクチャと DataSense の概念について読者が精通していることを前提としています。
インテグレーション開発者は、1 つのコンポーネントの出力を別のコンポーネントの入力に接続できるようにデータを変換するために、特定のコンポーネント (操作、ソースなど) の入力データ型と出力データ型の決定に多くの時間を費やします。この作業では、各コンポーネントの API ドキュメントを参照して必要なパラメーターを見つけなければなりません。このプロセスは非効率的で、間違いを犯しやすく、ときにはストレスも溜まります。
DataSense は、これらのコンポーネントが提供するメタデータを使用して、必要な情報をすべて自動的に解決してデザイン時にエンドユーザーに提供してくれるので、開発を大幅にスピードアップすることができます。
この機能は、既知の型のパラメーターが取ることのできる値を絞り込むための値プロバイダーとは異なり、この機能ではパラメーター値の範囲を検出できない動的型を見つけるためのものです。
ここで言う「型」とは、要素の MetadataType
を意味します。MetadataType
は、特定の要素の種類や構造を表します。たとえば、基本的な文字列や数字の要素であれば StringType
や NumberType
、コレクションなら ArrayType
、ネストされた要素を持つ複雑な構造 (POJO や JSON オブジェクト) であれば ObjectType
、型が未知で、他の使用可能などのタイプでもよい要素であれば AnyType
になります。
「DataWeave の型」を参照してください。
静的メタデータとは、コンパイル時に既知で、コネクタの JAR ファイルにある型から使用できるメタデータです。単純な Java 型は、開発者がモデルで定義したカスタム POJO と同じように、この静的メタデータに属します。重要な点は、構造が明確に分かっていて、他のパラメーターに依存せずに調査できるということです。
動的メタデータとは、コンパイル時に型が未知のメタデータです。動的メタデータは、コネクタの設定に基づいてデザイン時に解決する必要があります。このメタデータには、さまざまなケースでいろいろな使い方があります。たとえば、型そのものは既知でも構造がサービス設定に依存するケース (例: システムのアカウントにユーザーがカスタマイズできる項目があるため、ユーザーのログイン情報に基づいてその構造を毎回検出しなければならない場合) や、すべてが動的であるため、記述されている構造が設定済みパラメーターに大きく依存するケース (例: 記述されている構造がサービス操作のペイロードであり、ユーザーの Sandbox に基づいたサービス定義にも依存する場合) があります。
動的メタデータを解決するには、現在のコンポーネント設定に従って必要な型構造を取得する方法を知っているメタデータリゾルバーに要素を関連付ける必要があります。詳細は「メタデータリゾルバー」を参照してください。
入力メタデータは、コンポーネントのパラメーターのタイプを解決します。各パラメーターは、同じコンポーネントの他のパラメーターが公開している種類のメタデータから分離された静的または動的メタデータを提供します。
動的メタデータのパラメーターは操作とソースでのみ使用できます。設定と接続のパラメーターは常に静的メタデータとなります。
コンポーネントの出力は、メタデータの静的または動的な解決にバインドされます。たとえば、void
操作は、操作の出力が VoidType
であることを示す静的メタデータを持ち、リモートサービスから User
プロファイルをフェッチする操作は User
タイプを動的に記述できます。
構造についての説明にあるように、操作の出力結果には、ペイロードのデータと返されるメッセージの属性が含まれます。これらの属性の構造は、ペイロードの構造と同じくらい重要です。それぞれのメタデータを独立して記述することで、エンドユーザーにとっては使いやすくなります。ただし、一部のコンポーネントは属性を生成しないため、属性の動的メタデータの記述は常に任意で行います。
特定の戻り値のデータ型では、強制的にメタデータが動的に記述されます。これはエンドユーザーの使い勝手を向上させるための要件であり、型の記述が汎用的過ぎると使いづらくなるためです。
動的 DataSense サポートを実装するには、まず、特定の要素で提供するメタデータの型を定義します。型を定義したら、アノテーションと異なるメタデータリゾルバーのカスタム実装の組み合わせ (例: @MetadataKeyId(BucketKeysResolver.class)
) を活用できます。どの組み合わせを使用するかはユースケースによって異なります。
以降のセクションでは、上記のケースの実装について説明します。
動的メタデータ構造を記述するには、どの型を表現するのかを知る必要があります。この型の参照を定義するには、記述する型の ID を含む @MetadataKeyId
パラメーターを操作で指定します。
たとえば、汎用レコードを Amazon S3 に保存する操作があるとして、サポートされる各型の構造 (Account
や Organization
など) を記述しておけば、デザインしやすくなります。この場合は、操作のパラメーターの 1 つに ID として Account
または Organization
を含む型の参照を定義します。このパラメーターは、バケットに保存するレコードの Account 構造または Organization 構造 (エンドユーザーが使うと決めた方) を記述します。
@MetadataKeyId
パラメーターは常に必要というわけではなく、設定に応じて動的に変化する構造が (複数ではなく) 1 つしかない場合などには不要です。たとえば、接続用のログイン情報がシステム管理者用であるかどうかによって構造が変化する User
エンティティなどです。
MetadataKey パラメーターを含める目的は、出力のメタデータと、キーが定義されているコンポーネントの入力を解決するためのパラメーター値を使用することです。そのため、入力、出力、または属性の MetadataResolver が存在しない場合には、MetadataKey を定義しないでください。SDK バージョン 1.3 以降では、MetadataKey パラメーターを持ちながらも出力リゾルバーや入力リゾルバーを持たないコンポーネントがコネクタに含まれていると、コンパイルに失敗します。
DataSense の動的要素を取得する場合は、メタデータリゾルバーを実装します。リゾルバーには多くの種類があり、それぞれ機能とユースケース (後述) が異なりますが、中心となる以下の概念は同じです。
カテゴリ名: 異なるメタデータリゾルバーが連携するように関連付けるグループの名前です。
リゾルバー名: 特定のメタデータリゾルバーを一意に識別する名前です。異なるリゾルバーが同じ category
に属することはできますが、リゾルバー名は異なっている必要があります。
メタデータコンテキスト: メタデータフェッチ呼び出し中に使用するすべての設定要素と接続要素へのアクセスと、TypeLoader
や TypeBuilder
などのユーティリティコンポーネントを提供します。動的型を作成する場合は、コンテキストによって提供される実装を常に使用することが重要です。