特許 7580379 レプリゼンテーショナルステートトランスファ（ＲＥＳＴ）アプリケーションプログラミングインターフェイス（ＡＰＩ）を使用するデータ変換のための方法、システムおよびコンピュータ読取可能媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-31

(45)【発行日】2024-11-11

(54)【発明の名称】レプリゼンテーショナルステートトランスファ（ＲＥＳＴ）アプリケーションプログラミングインターフェイス（ＡＰＩ）を使用するデータ変換のための方法、システムおよびコンピュータ読取可能媒体

(51)【国際特許分類】

   H04L 51/066 20220101AFI20241101BHJP

   H04L 67/02 20220101ALI20241101BHJP

【ＦＩ】

H04L51/066

H04L67/02

【請求項の数】 19

(21)【出願番号】P 2021544671

(86)(22)【出願日】2020-03-11

(65)【公表番号】

(43)【公表日】2022-04-27

(86)【国際出願番号】 US2020022090

(87)【国際公開番号】W WO2020185891

(87)【国際公開日】2020-09-17

【審査請求日】2023-03-13

(31)【優先権主張番号】16/352,738

(32)【優先日】2019-03-13

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】ピジョン，アラン

(72)【発明者】

【氏名】デュエック，ブライアン・ジェームズ

(72)【発明者】

【氏名】トーマス，プラカシュ・ジョン

(72)【発明者】

【氏名】デイ，ディーパンカール

【審査官】羽岡 さやか

(56)【参考文献】

【文献】米国特許出願公開第２０１８／０２５３３４２（ＵＳ，Ａ１）

【文献】特開２０１１－０４８５５９（ＪＰ，Ａ）

【文献】特表２００４－５３５０２４（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ５１／０６６

Ｈ０４Ｌ ６７／０２

(57)【特許請求の範囲】

【請求項1】

レプリゼンテーショナルステートトランスファ（ＲＥＳＴ）アプリケーションプログラミングインターフェイス（ＡＰＩ）を使用するデータ変換のための方法であって、
ＲＥＳＴ ＡＰＩを使用してデータ変換を提供するとともにレガシーシステムとのインタラクションを促進するためのメタデータベースのデータ変換フレームワークを含むサーバにおいて、
前記ＲＥＳＴ ＡＰＩを介してクライアントから、ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージを使用して、第１のフォーマットの入力を受信することを含み、前記入力はコンバートの対象を特定する識別子を含み、
前記方法はさらに、
ランタイムにおいて、前記ＨＴＴＰ要求メッセージを使用して、第１のフォーマットと第２のフォーマットとの間でコンバートするためのコンバージョンロジックを生成することを含み、前記コンバージョンロジックは、所定のメタデータおよびリフレクションプログラミングを使用して生成され、
前記方法はさらに、
前記コンバージョンロジックを使用して、前記第１のフォーマットの前記入力を第２のフォーマットの入力にコンバートすることを含み、前記第１のフォーマットの前記入力を前記第２のフォーマットの入力にコンバートすることは、前記第１のフォーマットの前記入力の値が前記第２のフォーマットにおいて有効であると検証することと、前記第１のフォーマットの前記値が前記第２のフォーマットにおいて無効であると決定することに応答して、前記第１のフォーマットの前記値を前記第２のフォーマットにおいて有効な値に変更することとを含み、
前記方法はさらに、
前記第２のフォーマットの前記入力を使用して動作を実行するために、レガシーシステムに前記第２のフォーマットの前記入力を送信することと、
前記レガシーシステムから、前記第２のフォーマットの出力を受信することとを含み、前記出力は、前記第２のフォーマットの前記入力を使用して実行される前記動作に少なくとも部分的に基づいており、
前記方法はさらに、
前記コンバージョンロジックを使用して、前記第２のフォーマットの前記出力を前記第１のフォーマットの出力にコンバートすることと、
前記ＲＥＳＴ ＡＰＩを介して前記クライアントに、前記第１のフォーマットの前記出力を送信することと
を含む、方法。

【請求項2】

前記第１のフォーマットは、ＪａｖａＳｃｒｉｐｔオブジェクトノーテーション（ＪＳＯＮ）フォーマットまたはエクステンシブルマークアップランゲージ（ＸＭＬ）フォーマットであり、前記第２のフォーマットは、フィールドリスト（ＦＬｉｓｔ）フォーマットまたはポータルコミュニケーションモジュール（ＰＣＭ）フォーマットである、請求項１に記載の方法。

【請求項3】

前記第１のフォーマットは、フィールドリスト（ＦＬｉｓｔ）フォーマットまたはポータルコミュニケーションモジュール（ＰＣＭ）フォーマットであり、前記第２のフォーマットは、ＪａｖａＳｃｒｉｐｔオブジェクトノーテーション（ＪＳＯＮ）フォーマットまたはエクステンシブルマークアップランゲージ（ＸＭＬ）フォーマットである、請求項１に記載の方法。

【請求項4】

前記コンバージョンロジックを生成することは、実行すべきアクションまたはハイパーテキスト転送プロトコル（ＨＴＴＰ）の要求タイプに基づいて、コンバージョンルールを選択することをさらに含む、請求項１～３のいずれかに記載の方法。

【請求項5】

前記第２のフォーマットのデータが有効であるか否か、または、前記第１のフォーマットの前記出力が有効であるか否かを決定するための後方互換性テストを実行することをさらに含む、請求項１～４のいずれかに記載の方法。

【請求項6】

前記後方互換性テストは、オペレータまたは前記クライアントから付加的なメタデータを受信することに応答してトリガされる、請求項５に記載の方法。

【請求項7】

前記クライアントは、ユーザインターフェイスアプリケーション、外部システム、顧客関係管理システム、クラウドサービス、ウェブサービス、ＲＥＳＴ ＡＰＩクライアント、または、金融ソフトウェアを含む、請求項１～６のいずれかに記載の方法。

【請求項8】

前記コンバージョンロジックを生成することは、ランタイムにおいて、コンバータオブジェクトをインスタンス化することを含み、前記第１のフォーマットの前記入力を前記第２のフォーマットの前記入力にコンバートすることは、前記コンバータオブジェクトを使用することを含む、請求項１～７のいずれかに記載の方法。

【請求項9】

前記コンバージョンロジックを生成することは、前記識別子を使用して、前記第１のフォーマットの前記入力を検証するために特殊化されたバリデータが必要とされるか否かを決定することと、前記特殊化されたバリデータが必要とされると決定することに応答して、ランタイムにおいて、前記第１のフォーマットの少なくとも何らかの入力が前記第２のフォーマットにおいて有効であるか否かを検証するために前記特殊化されたバリデータをインスタンス化することとを含む、請求項１～７のいずれかに記載の方法。

【請求項10】

レプリゼンテーショナルステートトランスファ（ＲＥＳＴ）アプリケーションプログラミングインターフェイス（ＡＰＩ）を使用するデータ変換のためのシステムであって、
少なくとも１つのプロセッサと、
ＲＥＳＴ ＡＰＩを使用してデータ変換を提供するとともにレガシーシステムとのインタラクションを促進するためのメタデータベースのデータ変換フレームワークを含むサーバとを含み、前記サーバは、前記少なくとも１つのプロセッサを使用して実現され、
前記サーバは、
前記ＲＥＳＴ ＡＰＩを介してクライアントから、ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージを使用して、第１のフォーマットの入力を受信することを行うために構成され、前記入力は、コンバートの対象を特定する識別子を含み、
前記サーバはさらに、
ランタイムにおいて、前記ＨＴＴＰ要求メッセージを使用して、第１のフォーマットと第２のフォーマットとの間でコンバートするためのコンバージョンロジックを生成することを行うために構成され、前記コンバージョンロジックは、所定のメタデータおよびリフレクションプログラミングを使用して生成され、
前記サーバはさらに、
前記コンバージョンロジックを使用して、前記第１のフォーマットの前記入力を第２のフォーマットの入力にコンバートすることを行うために構成され、前記第１のフォーマットの前記入力を前記第２のフォーマットの入力にコンバートすることは、前記第１のフォーマットの前記入力の値が前記第２のフォーマットにおいて有効であると検証することと、前記第１のフォーマットの前記値が前記第２のフォーマットにおいて無効であると決定することに応答して、前記第１のフォーマットの前記値を前記第２のフォーマットにおいて有効な値に変更することとを含み、
前記サーバはさらに、
前記第２のフォーマットの前記入力を使用して動作を実行するために、レガシーシステムに前記第２のフォーマットの前記入力を送信することと、
前記レガシーシステムから、前記第２のフォーマットの出力を受信することとを行うために構成され、前記出力は、前記第２のフォーマットの前記入力を使用して実行される前記動作に少なくとも部分的に基づいており、
前記サーバはさらに、
前記コンバージョンロジックを使用して、前記第２のフォーマットの前記出力を前記第１のフォーマットの出力にコンバートすることと、
前記ＲＥＳＴ ＡＰＩを介して前記クライアントに、前記第１のフォーマットの前記出力を送信することと
を行うために構成される、システム。

【請求項11】

前記第１のフォーマットは、ＪａｖａＳｃｒｉｐｔオブジェクトノーテーション（ＪＳＯＮ）フォーマットまたはエクステンシブルマークアップランゲージ（ＸＭＬ）フォーマットであり、前記第２のフォーマットは、フィールドリスト（ＦＬｉｓｔ）フォーマットまたはポータルコミュニケーションモジュール（ＰＣＭ）フォーマットである、請求項１０に記載のシステム。

【請求項12】

前記第１のフォーマットは、フィールドリスト（ＦＬｉｓｔ）フォーマットまたはポータルコミュニケーションモジュール（ＰＣＭ）フォーマットであり、前記第２のフォーマットは、ＪａｖａＳｃｒｉｐｔオブジェクトノーテーション（ＪＳＯＮ）フォーマットまたはエクステンシブルマークアップランゲージ（ＸＭＬ）フォーマットである、請求項１０に記載のシステム。

【請求項13】

前記サーバは、実行すべきアクションまたはハイパーテキスト転送プロトコル（ＨＴＴＰ）の要求タイプに基づいて、コンバージョンルールを選択するために構成される、請求項１０～１２のいずれかに記載のシステム。

【請求項14】

前記サーバは、前記第２のフォーマットのデータが有効であるか否か、または、前記第１のフォーマットの前記出力が有効であるか否かを決定するための後方互換性テストを実行するために構成される、請求項１０～１２のいずれかに記載のシステム。

【請求項15】

前記サーバは、オペレータまたは前記クライアントから付加的なメタデータを受信することに応答して、前記後方互換性テストをトリガするように構成される、請求項１４に記載のシステム。

【請求項16】

前記クライアントは、ユーザインターフェイスアプリケーション、外部システム、顧客関係管理システム、クラウドサービス、ウェブサービス、ＲＥＳＴ ＡＰＩクライアント、または、金融ソフトウェアを含む、請求項１０～１５のいずれかに記載のシステム。

【請求項17】

前記サーバは、ランタイムにおいて、コンバータオブジェクトをインスタンス化することを行うために構成され、前記第１のフォーマットの前記入力を前記第２のフォーマットの前記入力にコンバートすることは、前記コンバータオブジェクトを使用することを含む、請求項１０～１６のいずれかに記載のシステム。

【請求項18】

前記サーバは、前記識別子を使用して、前記第１のフォーマットの前記入力を検証するために特殊化されたバリデータが必要とされるか否かを決定することと、前記特殊化されたバリデータが必要とされると決定することに応答して、ランタイムにおいて、前記第１のフォーマットの少なくとも何らかの入力が前記第２のフォーマットにおいて有効であるか否かを検証するために前記特殊化されたバリデータをインスタンス化することと行うために構成される、請求項１０～１６のいずれかに記載のシステム。

【請求項19】

請求項１～９のいずれかに記載の方法をコンピュータのプロセッサに実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

優先権主張
本出願は、２０１９年３月１３日に出願された米国特許出願連続番号第１６／３５２，７３８号の優先権の利益を主張しており、当該米国特許出願の開示は、本明細書においてその全文が参照により援用される。

【0002】

技術分野
本明細書において記載される主題は、ネットワーク通信に関する。より具体的には、当該主題は、レプリゼンテーショナルステートトランスファ（ＲＥＳＴ: representational state transfer）アプリケーションプログラミングインターフェイス（ＡＰＩ: application programming interface）を使用するデータ変換のための方法、システムおよびコンピュータ読取可能媒体に関する。

【背景技術】

【0003】

背景
いくつかのコンピュータシステムは、通信するために、複数のデータフォーマットおよび／またはプロトコルを使用する。たとえば、クラウドベースのコンピュータシステムにおけるコンポーネントは、インターネットプロトコル（ＩＰ: internet protocol）、ハイパーテキスト転送プロトコル（ＨＴＴＰ: hypertext transfer protocol）、および／または、他のプロトコルを使用して通信し得る。さらに、さまざまなエンティティ間の通信を可能にするために、１つ以上のアプリケーションプログラミングインターフェイス（ＡＰＩ）がサポートされ、これにより、通信のための標準化された態様が提供され得る。

【0004】

レプリゼンテーショナルステートトランスファ（ＲＥＳＴ）ＡＰＩは、ウェブサービスを提供するための１つのタイプのＡＰＩである。たとえば、ＲＥＳＴ ＡＰＩは、ＨＴＴＰを介した２つのシステム間の通信を可能にし得る。この例では、ペイロードを含むＨＴＴＰ要求が、たとえばユニフォームリソースロケータ（ＵＲＬ: uniform resource locator）といったユニフォームリソースアイデンティファイア（ＵＲＩ: uniform resource identifier）に送信され、それに応答して、ペイロードを含むＨＴＴＰ応答が、当該要求者に提供され得る。しかしながら、いくつかのシステムまたはコンポーネントは、サポートされていないフォーマットのデータが格納される場合があるため、ＲＥＳＴ ＡＰＩを介して提供されるペイロードを処理することができない場合がある。

【発明の概要】

【課題を解決するための手段】

【0005】

概要
レプリゼンテーショナルステートトランスファ（ＲＥＳＴ）アプリケーションプログラミングインターフェイス（ＡＰＩ）を使用するデータ変換のための方法、システムおよびコンピュータ読取可能媒体が開示される。１つの方法によれば、当該方法は、ＲＥＳＴ ＡＰＩを介してクライアントから、第１のフォーマットの入力を受信することと、所定のメタデータを使用して、第１のフォーマットの入力を第２のフォーマットの入力にコンバートすることと、第２のフォーマットの入力を使用して動作を実行するために、レガシーシステムに第２のフォーマットの入力を送信することと、レガシーシステムから、第２のフォーマットの出力を受信することとを含み、出力は、第２のフォーマットの入力を使用して実行される動作に少なくとも部分的に基づいており、上記方法はさらに、所定のメタデータを使用して、第２のフォーマットの出力を第１のフォーマットの出力にコンバートすることと、ＲＥＳＴ ＡＰＩを介してクライアントに、第１のフォーマットの出力を送信することとを含む。

【0006】

１つのシステムによれば、当該システムは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサを使用して実現されるサーバとを含む。サーバは、ＲＥＳＴ ＡＰＩを介してクライアントから、第１のフォーマットの入力を受信することと、所定のメタデータを使用して、第１のフォーマットの入力を第２のフォーマットの入力にコンバートすることと、第２のフォーマットの入力を使用して動作を実行するために、レガシーシステムに第２のフォーマットの入力を送信することと、レガシーシステムから、第２のフォーマットの出力を受信することとを行うために構成され、出力は、第２のフォーマットの入力を使用して実行される動作に少なくとも部分的に基づいており、サーバはさらに、所定のメタデータを使用して、第２のフォーマットの出力を第１のフォーマットの出力にコンバートすることと、ＲＥＳＴ ＡＰＩを介してクライアントに、第１のフォーマットの出力を送信することとを行うために構成される。

【0007】

本明細書において記載される主題は、ハードウェアおよび／またはファームウェアと組み合わせてソフトウェアにおいて実現されてもよい。たとえば、本明細書において記載される主題は、プロセッサによって実行されるソフトウェアにおいて実現されてもよい。いくつかの実現例では、本明細書において記載される主題は、コンピュータのプロセッサによって実行されると、ステップを実行するようにコンピュータを制御するコンピュータ実行可能命令を格納する非一時的なコンピュータ読取可能媒体を使用して実現されてもよい。本明細書において記載される主題を実現するのに好適な例示的なコンピュータ読取可能媒体は、ディスクメモリデバイス、チップメモリデバイス、プログラマブルロジックデバイス、および、特定用途向け集積回路といった非一時的なデバイスを含む。さらに、本明細書において記載される主題を実現するコンピュータ読取可能媒体は、単一のデバイスもしくはコンピューティングプラットフォーム上に位置してもよく、または、複数のデバイスまたはコンピューティングプラットフォームにわたって分散されてもよい。

【0008】

本明細書において使用される場合、「ノード」という用語は、１つ以上のプロセッサおよびメモリを含む少なくとも１つの物理的なコンピューティングプラットフォームを指す。

【0009】

本明細書において使用される場合、「関数」または「モジュール」という用語は、本明細書において記載される特徴を実現するための、ハードウェア、ファームウェア、または、ハードウェアおよび／もしくはファームウェアと組み合わされたソフトウェアを指す。

【0010】

ここで、本明細書において記載される主題が、添付の図面を参照して説明される。

【図面の簡単な説明】

【0011】

【図1】レプリゼンテーショナルステートトランスファ（ＲＥＳＴ）アプリケーションプログラミングインターフェイス（ＡＰＩ）を使用するデータ変換のための例示的な環境を示す図である。

【図2A】データフォーマット間で検証および／またはコンバートするための例示的なメタデータを示す図である。

【図2B】データフォーマット間で検証および／またはコンバートするための例示的なメタデータを示す図である。

【図3】データフォーマット間でコンバートすることに関連する例示的なデフォルト値データを示す図である。

【図4】ＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクトノーテーション（ＪＳＯＮ: JavaScript object notation）のデータフォーマットの例示的な要求データを示す図である。

【図5】フィールドリスト（ＦＬｉｓｔ: field list）のデータフォーマットの例示的な要求データを示す図である。

【図6】ＦＬｉｓｔのデータフォーマットの例示的な出力を示す図である。

【図7】ＪＳＯＮのデータフォーマットの例示的な出力を示す図である。

【図8】例示的なデータ変換プロセスを示す図である。

【図9】ＲＥＳＴベースのデータコンバージョンのための例示的なプロセスを示す図である。

【発明を実施するための形態】

【0012】

詳細な説明
本明細書において記載される主題は、レプリゼンテーショナルステートトランスファ（ＲＥＳＴ）アプリケーションプログラミングインターフェイス（ＡＰＩ）を使用するデータ変換のための方法、システムおよびコンピュータ読取可能媒体に関する。複数の重要なサービスを提供するいくつかのシステム、たとえばレガシーシステムまたはより古いシステムは、１つ以上のプロプライエタリＡＰＩもしくはプロプライエタリプロトコルまたはレガシーＡＰＩもしくはレガシープロトコルを使用して通信し得る。そのようなシステムは、置き換えるには非常に高価であるとともに時間がかかり得るので、最終的には、より新しいシステムがより古いシステムとインタラクションすることが必要になり、より新しいシステムがそのような通信のために構成され得ない可能性が非常に高い。たとえば、金融機関または他の企業は、１９８０年代に最初に設計されたレガシーシステム（たとえば、データベース、ストレージシステム、または、バックエンド）を使用している場合がある。この例では、同企業は、レガシーシステムまたはコンポーネントと通信する必要がある現代的なフロントエンドまたはクライアント（たとえば、ウェブベースのユーザインターフェイス）も使用している場合がある。この例を引き続き参照して、レガシーシステムが、レガシーＡＰＩ、および／または、たとえばフィールドリスト（ＦＬｉｓｔ）フォーマットといったデータフォーマットを使用する請求および収益管理（ＢＲＭ: billing and revenue management）システムである場合、さまざまなサービスドメイン（たとえば、アカウント、サブスクリプションおよび請求）において情報を処理する際、ＦＬｉｓｔフォーマットは、現代的なクライアントでは使用可能でない場合がある。したがって、データは、現代的なクライアントによって使用可能であるためには、たとえばＪＳＯＮフォーマットといった互換性のあるデータフォーマットに変換される必要がある。

【0013】

レガシーフォーマットを非レガシーフォーマットにコンバートするための１つのアプローチは、コンバージョンロジックをレガシーシステムまたは中間ゲートウェイノードにハンドコーディングすることを伴い得る。たとえば、そのようなアプローチは、たとえば、アカウントデータオブジェクト、サブスクリプションデータオブジェクト、支払プロファイルデータオブジェクト、および、請求データオブジェクトといった各タイプの複数のデータオブジェクトを作成、更新、および取得するための関数を手動でコーディングすることを伴い得る。しかしながら、このようなアプローチは、重複したコード、過度のテスト努力、エラーの傾向がある挙動につながり得、予測不能なパフォーマンス結果を与え得る。

【0014】

本明細書において記載される主題のいくつかの局面によれば、たとえば、システム実行時においてまたはシステム実行前にオペレータによって提供されるマッピングテンプレートといったメタデータを使用して、１つのデータフォーマットを別のデータフォーマットにコンバートするために使用可能なメタデータベースのデータ変換フレームワークのための技術、方法またはメカニズムが開示される。たとえば、例示的なデータ変換アルゴリズムまたは関連するフレームワークは、さまざまなデータ部分がどのようにマッピングまたは変換されるべきかを示すシンプルなメタデータファイルを定義することによって、ＦＬｉｓｔデータをＪＳＯＮデータに、またはその逆に、効率的にコンバートし得る。さらに、そのようなフレームワークは、たとえば、新しいフィールドがサービスドメインに追加される場合、正しいコンバージョンまたは変換のために新しいフィールドがＪＳＯＮ／ＦＬｉｓｔマッピングテンプレートに追加され得るといったように、メタデータ（たとえば、マッピングテンプレート）が修正される必要があるか否かを決定するために互換性テストを実行することによって、後方互換性を提供し得るとともに拡張性を向上し得る。

【0015】

本明細書において記載される主題のいくつかの局面によれば、ＲＥＳＴベースのデータ変換フレームワークのための技術、方法またはメカニズムが開示される。たとえば、例示的なＲＥＳＴベースのデータ変換フレームワークは、すべてのＲＥＳＴ呼出（たとえば、ＨＴＴＰ要求）がデータフレームワークまたは関連するデータ変換アルゴリズムを使用して処理されるように、メタデータおよびＲＥＳＴ ＡＰＩを利用し得る。この例では、ＲＥＳＴ呼出は、同フレームワークによって処理されるので、すべてのサービスドメインエンティティについて、データの完全性およびパフォーマンスを損なうことなく、パフォーマンスの結果および利点が理解され得る。

【0016】

本明細書において記載される主題のいくつかの局面によれば、リフレクションプログラミング技術を使用するデータ変換フレームワークのための技術、方法またはメカニズムが開示される。たとえば、例示的なデータ変換システムは、メタデータに基づいて、実行時または実行時の近傍でコンバージョンまたは変換ロジックを生成し得る。この例では、当該ロジックがＪａｖａ（登録商標）または別のオブジェクト指向プログラミング言語で記述されていると仮定すると、データ変換システムは、１つのフォーマットから別のフォーマットに、およびその逆に、データをコンバートおよび／またはマーシャリング（marshalling）するためのコード（たとえば、複数のクラス、オブジェクト、インターフェイス、および、関連するロジック）を生成するようメタデータを使用し得る。

【0017】

有利なことに、本明細書において記載される主題のいくつかの態様によれば、メタデータおよびＲＥＳＴ ＡＰＩを使用することによって、データ変換フレームワークは、より古いシステムがより新しいクライアントまたはコンポーネントと通信し得るように、データフォーマット間で効率的にコンバートを行い得る。さらに、リフレクションプログラミング技術を介してコンバージョンロジックまたは変換ロジックを導出するためにメタデータを使用することによって、実行時にコードが生成され得、１つのフォーマットから別のフォーマットにデータを変換するためのロジック（たとえば、クラスおよび／もしくはクラスのインスタンスまたは他のプログラミング構造を含む）を定義し得る。

【0018】

ここで、本明細書において記載される主題のさまざまな実施形態に対して詳細に参照がなされ、その例が添付の図面に示される。同じ参照番号は、可能な場合、図面全体を通じて同じまたは同様の部分を指すために使用される。

【0019】

図１は、ＲＥＳＴベースのデータ変換のための例示的な環境１００を示す図である。環境１００は、１つ以上の通信ネットワークを表し得る。たとえば、環境１００は、さまざまなネットワークノード、コンピューティングプラットフォーム、サーバ、または、デバイスを含む企業ネットワークおよび／またはインターネットを表し得る。この例では、環境１００は、通信を送信および受信するために、たとえば、ノードおよび／またはエンドユーザにコンテンツまたはサービスを提供するために使用可能であり得る。

【0020】

図１を参照して、環境１００は、コンピューティングシステム１０２を含み得る。システム１０２は、たとえば請求および収益管理（ＢＲＭ）サービスまたは顧客関係管理（ＣＲＭ: customer relationship management）サービスといった、１つ以上の関数またはサービスを実行するための１つ以上の好適なコンピューティングプラットフォームまたはデバイスを表し得る。いくつかの実施形態では、システム１０２は、単一の別個の地理的位置にあり得、内部通信ネットワークを介して通信し得、および／または、地理的に多様な位置にあり、外部通信ネットワークを介して通信し得るコンポーネント（たとえば、サーバ１０４またはレガシーシステム１１０）を含み得る。たとえば、システム１０２は、サービスプロバイダによって管理され、かつ、インターネットを介してサブスクリプションしている顧客にアクセス可能なプロプライエタリクラウドネットワークにデプロイされ得る。別の例では、システム１０２は、企業によって維持されるサーバルーム内の１つ以上のサーバを使用して実現され得るか、または、たとえばクラウドサービスプロバイダのようなサードパーティによって維持される１つ以上のデータセンタ内のクラウドベースのリソースを使用して実現され得る。

【0021】

システム１０２は、サーバ１０４およびレガシーシステム１１０を含むか、または、サーバ１０４およびレガシーシステム１１０とインタラクションし得る。サーバ１０４は、さまざまなエンティティ間の通信を促進するための任意の好適な１つまたは複数のエンティティを表し得る。たとえば、サーバ１０４は、システム１０２の外部のエンティティ（たとえば、クライアント１１２）とシステム１０２または関連するエンティティ（たとえば、レガシーシステム１１０）との間の通信を促進するために構成される１つ以上のプロセッサ、メモリ、および、ロジックを含み得る。

【0022】

いくつかの実施形態では、サーバ１０４は、レガシーまたはプロプライエタリＡＰＩ（たとえば、ＢＲＭまたはクラウド金融システムによって使用されるポータルコミュニケーションモジュール（ＰＣＭ: portal communications module）ＡＰＩまたはＯＰＣＯＤＥ ＡＰＩ）および／または他のＡＰＩもしくはプロトコルを介してレガシーシステム１１０または別のエンティティと通信するための機能を含み得る。たとえば、ＰＣＭ ＡＰＩは、ＦＬｉｓｔフォーマットもデータを利用するサービスまたは関数呼出を伴い得る。この例では、サーバ１０４または関連するエンティティは、ＰＣＭ ＡＰＩを介してレガシーシステム１１０に、実行すべき動作を示す要求とＦＬｉｓｔデータとを送信し得る。この例を引き続き参照して、レガシーシステム１１０での処理後、サーバ１０４または関連するエンティティは、ＰＣＭ ＡＰＩを介してレガシーシステム１１０から、ＦＬｉｓｔフォーマットの出力を受信し得る。

【0023】

レガシーシステム１１０は、サービスまたは機能を実行するための任意の好適な１つまたは複数のエンティティ（たとえば、バーチャルマシン、ソフトウェア、または、物理デバイス）を表し得、すべてのクライアントによって、たとえば、クライアント１１２によってサポートされないプロトコルおよび／またはデータフォーマットを使用し得る。たとえば、レガシーシステム１１０は、金融データを格納、管理または処理するためのソフトウェアまたは関連するロジックを含み得、プロプライエタリであるか、レガシーであるか、または、クライアント１１２によってサポートされていないＡＰＩを介して通信し得る。いくつかの実施形態では、レガシーシステム１１０は、ＰＣＭ ＡＰＩまたは他のＡＰＩおよびプロトコルを使用してサーバ１０４または他のエンティティと通信するための機能を含み得る。

【0024】

いくつかの実施形態では、サーバ１０４は、ＲＥＳＴ ＡＰＩおよび／または他のＡＰＩもしくはプロトコルを介してクライアント１１２または別のエンティティと通信するための機能を含み得る。たとえば、ＲＥＳＴ ＡＰＩは、ＨＴＴＰメッセージを介して要求および応答を利用し得る。この例では、サーバ１０４または関連するエンティティは、ＲＥＳＴ ＡＰＩを介してクライアント１１２から、レガシーシステム１１０と互換性のないＪＳＯＮフォーマットのデータを受信し得、当該ＪＳＯＮフォーマットのデータをレガシーシステム１１０と互換性のあるＦＬｉｓｔフォーマットにコンバートし得るか、または、当該コンバージョンを促進し得る。この例を引き続き参照して、レガシーシステム１１０からＦＬｉｓｔフォーマットの出力を受信した後、サーバ１０４または関連するエンティティは、ＦＬｉｓｔフォーマットの出力を、クライアント１１２と互換性のあるＪＳＯＮフォーマットの出力にコンバートし得るか、または、当該コンバージョンを促進し得、次いで、ＪＳＯＮフォーマットの出力を含むＲＥＳＴベースのＨＴＴＰ応答をクライアント１１２に送信し得る。

【0025】

クライアント１１２は、システム１０２、サーバ１０４、および／または、関連するエンティティとインタラクションするための任意の好適な１つまたは複数のエンティティ（たとえば、バーチャルマシン、ソフトウェア、または、物理デバイス）を表し得る。たとえば、クライアント１１２は、システム１０２またはたとえばレガシーシステム１１０といった関連するサービスによって格納または管理されるデータを使用するユーザインターフェイス（ＵＩ: user interface）アプリケーション（たとえば、ユーザフロントエンドまたはポータルとして動作するウェブベースのＵＩ）または他のソフトウェア（たとえば、金融ソフトウェアまたはビジネスアプリケーション）を含み得る。いくつかの実施形態では、クライアント１１２は、ＲＥＳＴ ＡＰＩならびに／または他のＡＰＩおよびプロトコルを使用して、サーバ１０４または他のエンティティと通信するための機能を含み得る。

【0026】

サーバ１０４は、データ変換フレームワーク（ＤＴＦ: data translation framework）１０６とインタラクションし得る。いくつかの実施形態では、ＤＴＦ１０６は、サーバ１０４と別個のコンポーネント、および／または、サーバ１０４と統合されたコンポーネントを含み得る。ＤＴＦ１０６は、データコンバージョン、データ変換、または、関連する機能に関連する局面を実行するための任意の好適な１つまたは複数のエンティティ（たとえば、プロセッサ上で実行されるソフトウェア、特定用途向け集積回路（ＡＳＩＣ: application-specific integrated circuit）、および／または、フィールドプログラマブルゲートアレイ（ＦＰＧＡ: field-programmable gate array））を表し得る。たとえば、サーバ１０４は、ＲＥＳＴ ＡＰＩメッセージ（たとえば、クライアント１１２から発信される）からＪＳＯＮデータを受信し得、ＤＴＦ１０６は、当該ＪＳＯＮデータを、システム１０２またはたとえばレガシーシステム１１０といった関連するエンティティによって処理され得る対応するＦＬｉｓｔデータにコンバートまたは変換するように構成され得る。別の例では、サーバ１０４は、クライアント１１２からシステム１０２への呼出または要求に応答して、レガシーシステム１１０から発信されるＦＬｉｓｔデータを受信し得、ＤＴＦ１０６は、クライアント１１２またはたとえばウェブＵＩもしくはクライアントアプリケーションといった関連するサービスによって処理され得る対応するＪＳＯＮデータにＦＬｉｓｔデータをコンバートまたは変換するように構成され得る。

【0027】

いくつかの実施形態では、ＤＴＦ１０６または関連するモジュールは、データコンバージョンまたは変換を実行する際に使用されるコンバージョンルールおよびメタデータを管理し得る。たとえば、オペレータ（たとえば、ソフトウェアもしくはソリューションアーキテクト）または他のエンティティ（たとえば、管理システム）は、サーバ１０４またはＤＴＦ１０６と通信し得、かつ、データコンバージョンまたは関連するデータ処理を実行するための１つ以上のメタデータファイル、テンプレート、または、他の情報を提供し得る。この例では、サーバ１０４またはＤＴＦ１０６は、その後の使用のために、受信されたデータを処理および格納し得る。

【0028】

いくつかの実施形態では、ＤＴＦ１０６または関連するモジュールは、データ検証（data validation）を実行する際に使用される検証ルールおよびメタデータを管理し得る。たとえば、オペレータ（たとえば、ソフトウェアまたはソリューションアーキテクト）または他のエンティティ（たとえば、管理システム）は、サーバ１０４またはＤＴＦ１０６と通信し得、データ検証または関連するデータ処理を実行するための１つ以上のメタデータファイル、テンプレート、または、他の情報を提供し得る。この例では、サーバ１０４またはＤＴＦ１０６は、その後の使用のために、受信されたデータを処理および格納し得る。

【0029】

データストレージ１０８は、通信および／またはデータ変換を扱うことに関連するデータを格納するための任意の好適なエンティティ（たとえば、非一時的なコンピュータ読取可能媒体、埋込メモリ、または、メモリデバイス）を表し得る。データストレージ１０８は、通信のためのさまざまなＡＰＩおよび／またはプロトコルを利用するためのロジックおよび／またはデータを格納し得る。たとえば、データストレージ１０８は、１つのフォーマットから別のフォーマット（たとえば、ＪＳＯＮまたはＸＭＬからＦＬｉｓｔ）にデータをコンバートし、その逆にデータをコンバートする（たとえば、ＦＬｉｓｔからＪＳＯＮまたはＸＭＬ）ためのメタデータおよび／または関連するロジック（たとえば、デフォルト値、コンバータロジック、フォーマットテンプレートなど）を格納し得る。いくつかの実施形態では、データストレージ１０８は、サーバ１０４、ＤＴＦ１０６、および、他のエンティティによってアクセス可能であり得、さまざまな目的のために使用可能であり得る。いくつかの実施形態では、データストレージ１０８は、単一のデバイスまたはコンピューティングプラットフォーム上に位置し得るか、または、複数のデバイスまたはコンピューティングプラットフォームにわたって分散され得る。

【0030】

いくつかの実施形態では、サーバ１０４、ＤＴＦ１０６、または、レガシーシステム１１０は、分散コンピューティングプラットフォームの別個のメッセージ処理モジュール、ブレードベースの分散コンピューティングプラットフォームにおけるコンピューティングブレード、シングルコアもしくはマルチコアコンピューティングデバイスに関連付けられるプロセッシングコア要素、または、１つ以上の物理コンピューティングデバイス上でインスタンス化されるバーチャルノードもしくはマシンであり得る。

【0031】

いくつかの実施形態では、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、データ変換またはコンバージョンを実行するための１つ以上のプログラミング言語を利用し得る。そのような実施形態では、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、データを第１のフォーマットから第２のフォーマットにマーシャリングし、データを第２のフォーマットからアンマーシャリング（unmarshalling）するためのマーシャラ（marshaller）（たとえば、ソフトウェアインターフェイスまたは関連するコード）を生成または構成し得る。

【0032】

いくつかの実施形態では、マーシャラは、呼び出されると、たとえばＪＳＯＮデータといったエンティティを対応するＦＬｉｓｔデータにコンバートし得、かつ、その逆にコンバートし得る１つ以上の関数を含み得る。いくつかの実施形態では、２つのタイプのマーシャル／アンマーシャルエンティティが使用されてもよい、すなわち、１つのタイプは、エンティティの文脈にあり（たとえば、アカウントの作成（create Account）、アカウントの取得（get Account）、アカウントの更新（update Account））、他のタイプは、サーチの文脈にある（たとえば、アカウントを見つける（find Account）、サブスクリプションを見つける（find Subscription））。

【0033】

いくつかの実施形態では、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、エンティティを取得（get）、作成（create）、更新（update）、または修正（modify）するよう、マーシャラを作成および／または呼び出し得る。たとえば、アカウント作成要求を仮定すると、ＤＴＦ１０６は、MarshallerFactoryオブジェクトインスタンスからMarshallerオブジェクトインスタンスを作成し得る。アカウントを作成するためのMarshallerを作成するための例示的なコードは、以下の通りである。

【0034】

【数1】

【0035】

当該例示的なコードでは、アカウントは、ＪＳＯＮドキュメントのＪａｖａオブジェクト表現であり、ActionEnumオブジェクトインスタンスは、要求された作成アクションに基づく「CREATE」として定義される。

【0036】

いくつかの実施形態では、ＪＳＯＮデータからＦＬｉｓｔデータへのマーシャリング（およびＦＬｉｓｔデータからＪＳＯＮデータへのアンマーシャリング）は、要求されるアクションに基づいて異なり得る。いくつかの実施形態では、ActionEnumオブジェクトインスタンスについての可能なタイプは、CREATE、GET、UPDATEおよびMODIFYを含み、それらのそれぞれのＨＴＴＰメソッド、すなわち、CREATE、GET、PUTおよびPATCH、に対応または関連し得る。

【0037】

いくつかの実施形態では、Marshallerオブジェクトインスタンスを初期化した後、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、ＪＳＯＮエンティティをＦＬｉｓｔデータにコンバートするためのマーシャル関数を呼び出し得る。Marshallerオブジェクトインスタンスを使用してマーシャル関数を呼び出すための例示的なコードは、以下の通りである。

【0038】

【数2】

【0039】

いくつかの実施形態では、ＪＳＯＮエンティティをＦＬｉｓｔデータにマーシャリングした後、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、レガシーシステム１１０において、または、レガシーシステム１１０によって、動作を呼び出し得る。レガシーシステム１１０において、または、レガシーシステム１１０によって、顧客作成動作を呼び出すための例示的なコードは、以下の通りである。

【0040】

【数3】

【0041】

いくつかの実施形態では、レガシーシステム１１０によって、または、レガシーシステム１１０において実行されるコミット動作（commit operation）に応答してレガシーシステム１１０からＦＬｉｓｔフォーマットの出力を受信した後、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、ＦＬｉｓｔフォーマット出力をＪＳＯＮエンティティにコンバートするためのアンマーシャル関数を呼び出し得る。Marshallerオブジェクトインスタンスを使用してアンマーシャル関数を呼び出すための例示的なコードは、以下の通りである。

【0042】

【数4】

【0043】

いくつかの実施形態では、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、たとえばＲＥＳＴ ＡＰＩサーチといったように、１つ以上のエンティティを見つけるためにマーシャラを作成および／または呼び出し得る。サーチのためのMarshallerオブジェクトインスタンスを作成するための例示的なコードは、以下の通りである。

【0044】

【数5】

【0045】

当該例示的なコードでは、ActionEnumオブジェクトインスタンスは、「GET」として定義される。いくつかの実施形態では、ActionEnumオブジェクトインスタンスは、サーチにとって重要でない場合がある。そのような実施形態では、整合性のために、ActionEnum.GETまたは別のActionEnumタイプが、サーチを要求する際に使用され得る。

【0046】

いくつかの実施形態では、サーチのためにMarshallerオブジェクトインスタンスを初期化した後、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、ＪＳＯＮサーチエンティティ（たとえば、rest.model.Searchエンティティ）を生成し得る。サーチエンティティを構築するための例示的なコードは、以下の通りである。

【0047】

【数6】

【0048】

いくつかの実施形態では、サーチエンティティを構築または作成した後、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、ＪＳＯＮサーチエンティティ（たとえば、rest.model.Searchエンティティ）をＦＬｉｓｔデータにコンバートするためのマーシャル関数を呼び出し得る。Marshallerオブジェクトインスタンスを使用してマーシャル関数を呼び出すための例示的なコードは、以下の通りである。

【0049】

【数7】

【0050】

いくつかの実施形態では、ＪＳＯＮエンティティをＦＬｉｓｔデータにマーシャリングした後、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、レガシーシステム１１０において、または、レガシーシステム１１０によって動作を呼び出し得る。レガシーシステム１１０において、または、レガシーシステム１１０によって、サーチ動作を呼び出すための例示的なコードは、以下の通りである。

【0051】

【数8】

【0052】

いくつかの実施形態では、サーチ動作が、レガシーシステム１１０によって、または、レガシーシステム１１０において実行されることに応答して、レガシーシステム１１０からＦＬｉｓｔのフォーマット出力を受信した後、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、ＦＬｉｓｔデータをＪＳＯＮエンティティにコンバートするためのアンマーシャル関数を呼び出し得る。いくつかの実施形態では、サーチのために、アンマーシャル関数は、エンティティタイプと、アンマーシャルすべきＦＬｉｓｔデータとを入力として必要とし得る。Marshallerオブジェクトインスタンスを使用してアンマーシャル関数を呼び出してBillingPreferenceエンティティを生成するための例示的なコードは、以下の通りである。

【0053】

【数9】

【0054】

いくつかの実施形態では、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、フィールド、データ、または、データのタイプをコンバートするためのコンバータ（たとえば、ソフトウェアおよび／またはコンバージョンルール）を呼び出し得、および／または、使用し得る。たとえば、ＤＴＦ１０６がエンティティをマーシャリング／アンマーシャリングするようマーシャラを呼び出す際、さまざまなデータ部分（たとえば、メタデータまたはマッピングテンプレートにおいて定義されるフィールドまたはＦＬｉｓｔＩＤ）をコンバートするために、１つ以上のコンバータが使用され得る。

【0055】

いくつかの実施形態では、コンバータは、異なるタイプにデータをコンバートし得る。たとえば、ＪＳＯＮエンティティが、「Active」の値を有するフィールド「Status」を含むが、ＦＬｉｓｔが数値ステータスを必要とすると仮定すると、ＤＴＦ１０６は、ＦＬｉｓｔフォーマットに変換する際に、「Active」のステータス値を「１００１」にコンバートするためにステータス関連コンバータを使用する必要があり得る。

【0056】

いくつかの実施形態では、コンバータは、実行されるアクション（GET vs CREATE）に基づいて、または、フィールドの値に基づいて、フィールド名または関連するフィールド識別子（たとえば、ＦＬｉｓｔＩＤ）を変更し得る。たとえば、製品またはエンティティのタイプに依存して、ＪＳＯＮフィールド「Name」は、異なるＦＬｉｓｔＩＤにコンバートされ得、たとえば、「課金」製品（a 'charge' product）のためのフィールド「Name」は、ＦＬｉｓｔＩＤ「FLDProduct」にコンバートされ得、割引製品（a 'discount' product）のためのフィールド「Name」は、ＦＬｉｓｔＩＤ「FLDDiscount」にコンバートされ得る。

【0057】

いくつかの実施形態では、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、特殊化またはカスタマイズされたコンバータを作成および使用し得る。そのような実施形態では、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、１つ以上のコンバータを作成するためにメタデータ（たとえば、マッピングテンプレート）を使用し得る。たとえば、所与のＪＳＯＮエンティティのフィールドが特殊化されたコンバージョン（たとえば、別のＪＳＯＮエンティティのフィールドとは異なる）を必要とする場合、当該所与のＪＳＯＮエンティティのための特殊化されたコンバータが定義され得る。この例では、特殊化されたコンバータは、ソフトウェアパッケージ（たとえば、「REST.converter」パッケージ）において作成されるクラスであり得、クラス名「<Entity>Converter」を有し得、<Entity>は、ＪＳＯＮエンティティの名前である。

【0058】

たとえば、「AccountStatus」エンティティの場合、ＤＴＦ１０６は、特殊化されたコンバータを使用して、数値ステータス値をアルファステータス値にコンバートし得る。この例において、特殊化されたコンバータが、「AccountConverter」クラスにおいて定義されると仮定すると、ＤＴＦ１０６または別のエンティティは、「AccountConverter」クラスを作成し得、データコンバージョンを実行するために「AccountConverter」オブジェクトインスタンスの「status」メソッドを定義し得る。「AccountConverter」クラスにおける「status」メソッドについての例示的なコード（コメントは、「／／」で始まるラインである）は、以下の通りである。

【0059】

【数10】

【0060】

いくつかの実施形態では、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、特殊化されたコンバータが必要とされない場合、ベースコンバータまたはデフォルトコンバータを使用し得る。たとえば、<Entity>Converterが、所与のエンティティについて利用可能でない場合、または、必要とされない場合、ベースコンバータまたはデフォルトコンバータ（たとえば、BaseConverter）が呼び出され得る。BaseConverterは、ほとんどのエンティティに共通であるフィールドに対するコンバージョンを扱い得、たとえば、ＩＤはＰｏｉｄへのコンバータであり得る。いくつかの実施形態では、<Entity>Converterにおいて定義されるフィールドは、BaseConverterにおいて定義されるフィールドをオーバーライドし、フィールドが、<Entity>ConverterまたはBaseConverterのいずれにおいても定義されていない場合、そのフィールドについてコンバージョンが必要とされない場合がある。

【0061】

いくつかの実施形態では、たとえば、実行されるアクション（たとえば、「UPDATE」 vs 「CREATE」）に基づいて、または、フィールドの値に基づいて、複数のＦＬｉｓｔＩＤが存在する場合、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、<Entity>Converterを定義し、コンバージョンが実行されるべき１つ以上のフィールドを特定し得る。たとえば、「Account」エンティティ内のフィールド「Name」については、ＨＴＴＰメソッドが「CREATE」である場合、フィールド「Name」は、ＦＬｉｓｔＩＤ「FldNameCreate」にコンバートされ得、ＨＴＴＰメソッドが「UPDATE」である場合、フィールド「Name」は、ＦＬｉｓｔＩＤ「FldNameUpdate」にコンバートされ得る。「AccountConverter」クラスにおけるメソッド「name」についての例示的なコードは、以下の通りである。

【0062】

【数11】

【0063】

いくつかの実施形態では、コンバータは、さまざまな、たとえば、１つ以上の入力を利用し得る。たとえば、Converter.convert(fieldName, value, action, className)がコンバータを呼び出すためのメソッドであると仮定すると、「fieldName」は、コンバートすべきフィールドの名前（たとえば、名前、ｉｄ、ステータスなど）であり得、「value」は、コンバートされるべきフィールドの実際の値であり得（たとえば、ステータスについて、「１００１」がコンバートされるべきである）、「action」は、実行されている現在のアクション（たとえば、CREATE、GET、UPDATE、MODIFYなど）であり得るか、または、タイプもしくは関連するフィールドを識別し得、「className」は、作業されるエンティティクラス（たとえば、アカウント、サブスクリプションなど）であり得る。

【0064】

いくつかの実施形態では、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、検証フィールド、データ、または、データのタイプについてバリデータ（validator）（たとえば、ソフトウェアおよび／または検証ルール）を呼出および／または使用し得る。たとえば、ＤＴＦ１０６が、エンティティをマーシャリング／アンマーシャリングするようマーシャラを呼び出すと、さまざまなデータ部分（たとえば、メタデータまたはマッピングテンプレートにおいて定義されるフィールドまたはＦＬｉｓｔＩＤ）を検証するために１つ以上のバリデータが使用され得る。

【0065】

いくつかの実施形態では、ＪＳＯＮからＦＬｉｓｔへデータをマーシャリングするためにバリデータが呼び出され得る。いくつかの実施形態では、レガシーシステム１１０から戻る値が有効であると仮定され得るので、ＦＬｉｓｔからＪＳＯＮにデータをアンマーシャリングするためにバリデータは呼び出されなくてもよい。

【0066】

いくつかの実施形態では、サーバ１０４、ＤＴＦ１０６および／または別のエンティティは、特殊化またはカスタマイズされたバリデータを作成および使用し得る。そのような実施形態では、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、１つ以上のバリデータを作成するためにメタデータ（たとえば、マッピングテンプレート）を使用し得る。たとえば、所与のＪＳＯＮエンティティのフィールドが特殊化された検証（たとえば、別のＪＳＯＮエンティティのフィールドとは異なる）を必要とする場合、所与のＪＳＯＮエンティティのための特殊化されたバリデータが定義され得る。この例では、特殊化されたバリデータは、ソフトウェアパッケージ（たとえば、「REST.validator」パッケージ）において作成されたクラスであり得、クラス名「<Entity>Validator」を有し得、<Entity>は、ＪＳＯＮエンティティの名前である。

【0067】

たとえば、「contacts」エンティティの場合、ＤＴＦ１０６は、コンタクトに関連付けられるある数のフィールド値を検証し得る。この例では、「AccountValidator」クラスにおいて特殊化されたバリデータが定義され、ＤＴＦ１０６または別のエンティティは、「AccountValidator」クラスを作成し得、データコンバージョンを実行するために「AccountValidator」オブジェクトインスタンスの「contacts」メソッドを定義し得ると仮定する。「AccountValidator」クラスにおける「contacts」メソッドについての例示的なコード（コメントは、「／／」で始まるラインである）は、以下の通りである。

【0068】

【数12】

【0069】

いくつかの実施形態では、サーバ１０４、ＤＴＦ１０６、および／または、別のエンティティは、特殊化されたバリデータが必要とされない場合、ベースまたはデフォルトバリデータを使用し得る。たとえば、<Entity>Converterが、所与のエンティティについて利用可能でない場合、または、必要とされない場合、ベースコンバータまたはデフォルトバリデータ（たとえば、BaseValidator）が呼び出され得る。BaseValidatorは、ほとんどのエンティティに共通であるフィールドに対する検証を扱い得、たとえば、ＩＤはＰｏｉｄへのバリデータであり得る。いくつかの実施形態では、<Entity>Validatorにおいて定義されるフィールドは、BaseValidatorにおいて定義されるフィールドをオーバーライドし、フィールドが、<Entity>ValidatorまたはBaseValidatorのいずれにおいても定義されていない場合、そのフィールドについて検証が必要とされない場合がある。

【0070】

図１は例示目的のためであり、図１に関連して上で記載されたさまざまなノード、それらの位置、および／または、それらの関数（たとえば、モジュール）は、変更、改変、追加または除去されてもよいことが理解されるべきである。たとえば、いくつかのノードおよび／または関数は、単一のエンティティへと組み合わされてもよい。別の例では、いくつかのノードおよび／または関数は、複数のノードおよび／またはプラットフォームにわたって分散されてもよい。

【0071】

図２Ａ～図２Ｂは、データフォーマット間での検証および／またはコンバートのための例示的なメタデータ２００～２０２を示す。メタデータ２００～２０２は、たとえばＪＳＯＮフォーマットおよびＦｌｉｓｔフォーマットといった異なるデータフォーマットから、関連するまたは対応するデータ要素を識別するための情報を含み得る。メタデータ２００～２０２は、一方または両方のデータフォーマットのためのデータストレージまたはデータ表現を扱うための情報を含み得る。メタデータ２００～２０２はさらに、データコンバージョンに関連する情報、ロジック、または、コンバージョンルールを含み得る。

【0072】

図２Ａ～図２Ｂを参照して、メタデータ２００～２０２を表すテーブルは、データエントリのための列および／またはフィールドと、データエントリに関する関連する記述とを含む。データエントリフィールドは、ＪＳＯＮフォーマット（たとえば、ＪＳＯＮデータオブジェクト）または別のフォーマット（たとえば、Ｆｌｉｓｔデータ）の情報を格納するためのデータエンティティまたはその部分（たとえば、データ要素またはデータフィールド）を表すための情報を格納し得る。いくつかの実施形態では、データエントリフィールドはさらに、データタイプを含み得るか、または、データエンティティもしくは関連するタイプに関連するかもしくは示す例示的なフィールド名を含み得る。

【0073】

いくつかの実施形態では、メタデータ２００～２０２は、データエンティティまたは関連するデータを表す関連するデータエントリの群を含み得る。たとえば、図２Ａのテーブルに示されるように、データエントリの群は、「Account」データエンティティまたは関連するデータを表し得る。この例では、さまざまな示される行またはデータエントリは、１つ以上のフィールド（タイプ、アカウント番号など）と、「Account」データエンティティに関連付けられる１つ以上の他のデータエンティティ（たとえば、コンタクト、電話、プレファレンスなど）を示し得る。

【0074】

いくつかの実施形態では、メタデータ２００～２０２は、データフォーマット間で、関連するデータ要素を関連付けるためのマッピング情報を含み得る。いくつかの実施形態では、ＤＴＦ１０６または関連するエンティティは、データフォーマット間でデータをコンバートまたは変換する際に、マッピング情報を使用し得る。たとえば、図２Ａのテーブルに示されるように、ＪＳＯＮフィールド名「accountNumber」は、ＦｌｉｓｔＩＤ「FldAccountNo」にマッピングし得る。

【0075】

いくつかの実施形態では、メタデータ２００～２０２は、データコンバージョンの間に使用すべきコンバータまたは関連するロジックを識別するための情報を含み得る。たとえば、サーバ１０４またはＤＴＦ１０６は、どのロジック、ルール、または、ソフトウェアモジュールを使用すべきかを識別するためにメタデータ２００～２０２を使用し得、たとえば、コンシューマユーザアカウントデータは、ビジネスユーザアカウントデータとは異なるように処理される必要があり得る。

【0076】

いくつかの実施形態では、メタデータ２００～２０２は、データ検証中に使用すべきバリデータまたは関連するロジックを識別するための情報を含み得る。たとえば、サーバ１０４またはＤＴＦ１０６は、いくつかのフィールドが、たとえばＪＳＯＮからＦＬｉｓｔへコンバートする前またはコンバート中といったように、データコンバージョンの前またはデータコンバージョン中に検証されるべきであることを識別するためにメタデータ２００～２０２を使用し得る。この例では、図２Ｂのテーブルに示されるように、ＪＳＯＮ「contacts」データエンティティは、「validation:[mandatory]」指定に関連付けられ得、したがって、ＤＴＦ１０６または関連するバリデータは、たとえば、マーシャラがＦＬｉｓｔデータセットに値を割り当てる前に、「contacts」エンティティに関連付けられるフィールド値について検証を実行し得る。

【0077】

記述フィールドは、対応するデータエントリを記述または定義するための情報ロジック、コンテキスト、または例を格納し得る。たとえば、記述フィールドは、関連するデータがどのように格納、コンバート、または、使用されるかを定義し得る。別の例では、記述フィールドは、関連するデータがどのように導出、取得、または、生成されるかを定義し得る。

【0078】

いくつかの実施形態では、さまざまな記述情報が、プログラミングロジック、データ変数、または、他のフォーマットとして格納および／または表現され得る。たとえば、「if/else」ロジックは、デフォルト値が使用される場合または使用されない場合を表すように使用され得る。

【0079】

メタデータ２００～２０２は、例示目的のためであり、図２Ａ～図２Ｂに示されるデータとは異なるデータおよび／または付加的なデータは、コンバージョンロジック、フォーマットプレファレンス、データフォーマット関係、または、他の情報を示すために使用可能であり得ることが理解されるであろう。さらに、メタデータ２００～２０２は、さまざまなデータ構造および／またはコンピュータ読取可能媒体を使用して（たとえば、データストレージ１０８内において）格納または管理され得る。

【0080】

図３は、データフォーマット間でコンバートすることに関連する例示的なデフォルト値データ３００を示す。データ３００は、さまざまなデータタイプ、データフィールド、および／または、データエンティティについてのデフォルト値を識別または決定するための情報を含み得る。たとえば、データ３００は、数、値、テキスト、および／または、値を得るための関数もしくはソフトウェアのためのデータポインタまたは識別子を含み得る。この例では、デフォルト値は、たとえば、擬似乱数を生成するためのコード、または、コンピュータのインターネットプロトコル（ＩＰ）アドレスを抽出するためのコードといったメソッドまたは関数を実行することを伴い得る。

【0081】

図３を参照して、データ３００を表すテーブルは、ＦＬｉｓｔ識別子（ＦＬｉｓｔＩＤ）タイプ、ＦＬｉｓｔＩＤタイプ例、データエンティティマッピングタイプ、および、データエンティティマッピング例についての列および／またはフィールドを含む。ＦＬｉｓｔＩＤタイプフィールドは、ＦＬｉｓｔフォーマットまたは関連するファイルにおけるデータ部分（たとえば、データ要素またはデータフィールド）のタイプを表すための情報を格納し得る。たとえば、例示的なＦＬｉｓｔＩＤタイプは、「IntField」、「PoidField」、「StrField」および／または「ArrayField」を含み得る。

【0082】

ＦＬｉｓｔＩＤタイプ例フィールドは、ＦＬｉｓｔフォーマットまたは関連するファイルにおける対応するタイプのデータ部分（たとえば、データ要素またはデータフィールド）の例である１つ以上のＦＬｉｓｔＩＤを表すための情報を格納し得る。たとえば、いくつかのＦＬｉｓｔＩＤタイプの例は、「FldFlags」（「IntField」タイプの例）、「FldPayType」（「IntField」タイプの例）、「FldPoid」（「PoidField」タイプの例）、「FldName」（「StrField」タイプの例）、「FldContactType」（「StrField」タイプの例）、「FldLocale」（「StrField」タイプの例）、「FldAccountNo」（「StrField」タイプの例）、「FldBillinfoId」（「StrField」タイプの例）、および／または、「FldBalInfo」（「ArrayField」タイプの例）を含み得る。

【0083】

データエンティティマッピングタイプフィールドは、ＪＳＯＮフォーマットのデータ部分（たとえば、データ要素またはデータフィールド）または関連するファイルのタイプを表すための情報を格納し得る。たとえば、例示的なデータエンティティマッピングタイプは、「int」、「string」、「method call」、および／または「null」を含み得る。いくつかの実施形態では、メソッドまたは関数呼出は、予め定義された値および／または他の値もしくはパラメータを入力として取り得る。たとえば、メソッド「generateRandomNumber」は、１０桁の乱数を生成し得、たとえば、先に存在するストリングおよび区切り記号文字といった随意の入力を含み得る。この例では、入力が提供されない場合、メソッドは、１０桁の乱数、たとえば、４８２７４９５８２７を生成し得る。別の例では、先に存在するストリング「ＡＢＣ」がこのメソッドにおいて入力される場合、たとえば、generateRandomNumber(ABC)の場合、当該メソッドは、たとえば、ＡＢＣ４８２７４９５８２７といったように、所与のストリングが先に存在する１０桁の乱数を生成し得る。別の例では、先に存在するストリング「ＡＢＣ」および区切り記号「－」が当該メソッドに入力される場合、たとえば、generateRandomNumber(ABC,-)の場合、当該メソッドは、たとえば、ＡＢＣ－４８２７４９５８２７といった、所与のストリングおよび区切り記号が先に存在する１０桁の乱数を生成し得る。

【0084】

データエンティティマッピング例フィールドは、ＪＳＯＮフォーマットのデータ部分（たとえば、データ要素またはデータフィールド）または関連するファイルを表すための情報を格納し得る。いくつかのデータエンティティマッピング例は、ＦＬｉｓｔＩＤ（たとえば、「FListId: FldPoid」）に対応するＪＳＯＮフィールド名（たとえば、「field: id」）を示し得る。いくつかのデータエンティティマッピング例は、対応するＦＬｉｓｔＩＤについてのデフォルト値、たとえば「FListDefault: true」が存在することを示し得る。いくつかのデータエンティティマッピング例は、対応するＦｌｉｓｔＩＤについてのデフォルト値を示し得るか、または、たとえば「FListDefaultValue: getName()」といった、対応するＦｌｉｓｔＩＤを取得するメソッドを呼び出し得る。

【0085】

さらに、データ３００は、例示目的のためであり、図３に示すデータとは異なるデータおよび／または付加的なデータが、特定のデータ部分または他の情報に対するデフォルト値を示すために利用可能であり得ることも理解されるであろう。さらに、データ３００は、さまざまなデータ構造および／またはコンピュータ読取可能媒体を使用して（たとえば、データストレージ１０８内において）格納または管理され得る。

【0086】

図４は、ＪＳＯＮデータフォーマットの例示的な要求データ４００を示す。要求データ４００は、クライアント１１２から生成または提供されるデータであり得る。たとえば、クライアント１１２は、クラウドベースのＢＲＭシステム（たとえば、システム１０２）へのユーザフロントとして機能するウェブベースのＵＩを表し得る。この例では、ＵＩは、ＪａｖａＳｃｒｉｐｔまたは別のプログラミング言語を使用してプログラムされ得、ＪＳＯＮフォーマットのユーザ入力を格納し得る。この例では、クライアント１１２は、ＨＴＴＰ ＰＯＳＴメッセージを生成し、サーバ１０４またはＤＴＦ１０６に送信し得る。ＨＴＴＰ ＰＯＳＴメッセージは、新しい請求アカウントを生成するためのユーザ入力（たとえば、要求データ４００）を含み得る。

【0087】

図４に示されるように、ＪＳＯＮフォーマットの要求データ４００は一般的に、波括弧「｛｝」内のエンティティまたはオブジェクトを表し得、当該オブジェクトは、付加的なオブジェクトおよびフィールドまたはパラメータも含み得る。サブオブジェクトおよびオブジェクトパラメータは、その親（parent）に対してインデントされ得る。フィールドは、引用マーク内のフィールド名と、それに続くコロンと、それに続くその値（たとえば、“City”: “New York”）とによって表され得る。ＪＳＯＮフォーマットのテキスト値は一般に、引用マーク間に存在し、数値は一般に引用マーク間に存在しない。２０１７年１２月付けのInternet Engineering Task Force (IETF) Request for Comments (RFC) 8259は、ＪＳＯＮフォーマットの例に関する付加的な詳細を提供しており、その開示は本明細書において参照により援用される。

【0088】

要求データ４００は、例示目的のためであり、図４に示すデータとは異なるデータおよび／または付加的なデータは、別のデータフォーマットへの変換またはコンバージョンのためのデータまたは入力を示すために利用可能であり得ることも理解されるであろう。さらに、要求データ４００は、さまざまなデータ構造および／またはコンピュータ読取可能媒体を使用して格納または管理され得る。

【0089】

図５は、ＦＬｉｓｔデータフォーマットの例示的な要求データ５００を示す。要求データ５００は、ＪＳＯＮフォーマットからＦＬｉｓｔフォーマットにコンバートされるデータであり得る。たとえば、サーバ１０４またはＤＴＦ１０６は、クライアント１１２から要求データ４００を受信し得、要求データ４００を要求データ５００にコンバートまたは変換し得る。この例では、コンバージョンまたは変換は、メタデータ２０２～２０４および／または他の情報を使用して構成されるマーシャラによって実行され得る。

【0090】

いくつかの実施形態では、ＤＴＦ１０６または関連するソフトウェア（たとえば、マーシャラ）は、データを１つのフォーマットから別のフォーマットの有効なデータにコンバートまたは変換するように構成され得る。たとえば、メタデータ２０２～２０４および／または関連するコンバージョンルールを使用して、ＤＴＦ１０６は、あるテキストを修正し得、これにより、（たとえば、特別な文字の前にバックスラッシュまたは他の「エスケープ」シーケンスを使用することによって）シングルクォートまたはダブルクォートのように特定のフォーマットの特別な文字を可能にし得る。別の例では、メタデータ２０２～２０４および／または関連するコンバージョンルールを使用して、ＤＴＦ１０６は、値を異なる値に修正し、たとえば、新しいフォーマットにおける有効な範囲に適合するように、または、テキストから対応する数値に値を変更するように、数を調節し得る。

【0091】

図５を参照して、要求データ５００は、システム１０２またはレガシーシステム１１０によって作成されるべき請求アカウントを表すフィールドおよびサブフィールドを含み得る。たとえば、ＤＴＦ１０６または関連するソフトウェア（たとえば、マーシャラ）は、メタデータ２０２～２０４を使用して構成され得る。この例では、ＤＴＦ１０６は、メタデータ２０２～２０４および／または関連するコンバージョンルールを使用して、要求データ４００における対応するデータから関連するフィールド名およびフィールド値を決定することによって、要求データ５００を生成し得る。この例を引き続き参照して、ＤＴＦ１０６はさらに、データ変換を実行する際にデフォルト値を生成し、および／または、値を修正し得る。

【0092】

図５に示されるように、ＦＬｉｓｔフォーマットの要求データ５００のラインは、左から右へ、入れ子レベルを示す第１の値（たとえば、０＝トップレベル、１＝サブレベル、２＝サブサブレベルなど）と、フィールド識別子を示す第２の値（たとえば、ＰＩＮ＿ＦＬＤ＿ＢＩＬＬＩＮＦＯ、ＰＩＮ＿ＦＬＤ＿ＰＯＩＤなど）と、フィールドタイプを示す第３の値（たとえば、ARRAY、STR、INTなど）と、要素識別子を示す第４の値（たとえば[0]、[1]など）と、当該フィールドについての値を示す第５の値（たとえば、テキスト、メモリポインタ、または数字）とを含み得る。２０１６年８月付けのOracle（登録商標） Communications Billing and Revenue Management Developer's Guide (Release 7.5)は、例示的なＦＬｉｓｔフォーマットに関する付加的な詳細を提供し、その開示は、本明細書において参照により援用される。

【0093】

要求データ５００は、例示目的のためであり、レガシーシステム１１０によって処理するためのデータまたは入力を示すために、図５に示すデータとは異なるデータおよび／または付加的なデータが使用可能であり得ることも理解されるであろう。さらに、要求データ５００は、さまざまなデータ構造および／またはコンピュータ読取可能媒体を使用して格納または管理され得る。

【0094】

図６は、ＦＬｉｓｔデータフォーマットの例示的な出力を示す。出力６００は、レガシーシステム１１０によって生成または提供されるデータであり得る。たとえば、レガシーシステム１１０は、要求データ５００を含む、ＯＰＣＯＤＥ要求とも称されるＰＣＭ要求を受信し得、当該ＰＣＭ要求を処理し得る。この例では、ＰＣＭ要求は、新しい請求アカウントを追加または作成することを伴い得る。この例を引き続き参照して、ＰＣＭ要求を処理した後、出力６００が生成され得、サーバ１０４またはその中のＤＴＦ１０６に送信され得る。

【0095】

いくつかの実施形態では、出力６００は、関連する要求が成功したことを示し得る。たとえば、出力６００は、現在のまたは有効な格納されたデータ（たとえば、ＰＣＭ要求を処理した後のデータ）を示し得る。この例では、クライアント１１２または別のエンティティは、出力６００を検査し、かつ、出力６００が要求された変更または更新を含むことを検出することによって関連する要求が成功したと決定することが可能であり得る。

【0096】

いくつかの実施形態では、出力６００は、エラーが発生したことを示し得るか、または、関連する要求（たとえば、ＨＴＴＰ ＰｏｓｔメッセージまたはＨＴＴＰ ＧＥＴメッセージ）が成功しなかったことを示し得る。たとえば、出力６００は、エラーメッセージまたはエラーコードを含み得、または、現在のもしくは有効な格納されたデータ（たとえば、ＰＣＭ要求の前のデータ）を示し得る。この例では、クライアント１１２または別のエンティティは、出力６００を検査し、かつ、エラーメッセージまたはエラーコードを検出することによって、関連する要求が成功しなかったと決定することが可能であり得る。

【0097】

図６を参照して、出力６００は、システム１０２またはレガシーシステム１１０によって作成された請求アカウントを表すフィールドおよびサブフィールドを含み得る。たとえば、出力６００は、１つ以上の請求アカウント識別子と、システム１０２またはレガシーシステム１１０に関連付けられる請求アカウント情報への１つ以上のＵＲＬまたはリンクを導出するための情報とを含み得る。

【0098】

いくつかの実施形態では、出力６００または関連する応答メッセージは、要求に関連付けられる動作の実行が試みられた後に生成され得る。たとえば、レガシーシステム１１０は、データベースコミットまたは更新動作を実行することによってＰＣＭ要求を処理し、その後、当該動作に関連する出力６００を生成し得る。この例では、成功した場合、レガシーシステム１１０は、格納された請求アカウント情報のコピーをＨＴＴＰ２０１メッセージでサーバ１０４に送信し得る。しかしながら、成功しなかった場合、レガシーシステム１１０は、エラーメッセージまたはエラーコードをＨＴＴＰ４０９メッセージで送信し得る。

【0099】

出力６００は、例示目的のためであり、図６に示すデータとは異なるデータおよび／または付加的なデータが、別のデータフォーマットへの変換またはコンバージョンのためのデータまたは出力を示すために使用可能であることも理解されるであろう。さらに、出力６００は、さまざまなデータ構造および／またはコンピュータ読取可能媒体を使用して格納または管理され得る。

【0100】

図７は、ＪＳＯＮデータフォーマットの例示的な出力７００を示す。出力７００は、ＦＬｉｓｔフォーマットからＪＳＯＮフォーマットにコンバートされたデータであり得る。たとえば、サーバ１０４またはＤＴＦ１０６は、レガシーシステム１１０から出力６００を受信し得、出力６００を出力７００にコンバートまたは変換し得る。この例では、コンバージョンまたは変換は、メタデータ２０２～２０４および／または他の情報を使用して構成されるマーシャラによって実行され得る。

【0101】

いくつかの実施形態では、ＤＴＦ１０６または関連するソフトウェア（たとえば、マーシャラまたはコンバータ）は、１つのフォーマットから別のフォーマットの有効なデータにデータをコンバートまたは変換するように構成され得る。たとえば、メタデータ２０２～２０４および／または関連するコンバージョンルールを使用して、ＤＴＦ１０６は、ＦＬｉｓｔデータからＵＲＬを導出し、有効なＪＳＯＮフォーマットでＵＲＬを提供し得る。

【0102】

図７を参照して、出力７００は、システム１０２またはレガシーシステム１１０に格納されるかまたは関連付けられるさまざまなプレファレンスへのＵＲＬまたはリンクを含む「billings Preferences」データ部分を含み得る。たとえば、クライアント１１２は、出力７００を受信し得、関連するＵＩにおいてハイパーリンクを表示するよう、その中のリンクを使用し得る。

【0103】

いくつかの実施形態では、出力７００または関連する応答メッセージ（たとえば、ＨＴＴＰ Ｐｏｓｔメッセージ）は、関連する要求が成功したか否かを決定するために検査され得る。たとえば、クライアント１１２は、出力７００を受信し、次いで、提供されたＵＲＬからの情報を検査し、変更または追加の実行が成功したと決定し得る。別の例では、関連する要求が成功したか否かの決定は、たとえば、ＨＴＴＰ ２ＸＸメッセージ＝成功およびＨＴＴＰ ４ＸＸ－５ＸＸメッセージ＝失敗といったように、応答メッセージタイプを識別することに少なくとも部分的に基づき得る。

【0104】

出力７００は、例示目的のためであり、図７に示すデータとは異なるデータおよび／または付加的なデータが、クライアント１１２についてのデータまたは出力を示すために使用可能であり得ることも理解されるであろう。さらに、出力７００は、さまざまなデータ構造および／またはコンピュータ読取可能媒体を使用して格納または管理され得る。

【0105】

図８は、例示的なデータマーシャリングプロセス８００を示す図である。図８を参照して、プロセス８００は、１つのフォーマットから別のフォーマットにデータをマーシャリングする際に実行され得る。

【0106】

ステップ８０２において、マーシャラ（たとえば、サーバ１０４、ＤＴＦ１０６、または、関連するプロセッサにおいて実行されるソフトウェア）は、ＪＳＯＮからＦＬｉｓｔへデータをマーシャリングするためのデータエンティティ（たとえば、複数のフィールド値を含むＪＳＯＮオブジェクト）を受信し得る。

【0107】

ステップ８０４において、トランスレータ（translator）（たとえば、サーバ１０４、ＤＴＦ１０６、または、関連するプロセッサにおいて実行されるソフトウェア）は、ＪＳＯＮからＦＬｉｓｔへ変換するための値を受信し得る。いくつかの実施形態では、変換は、メタデータ２００～２０２（たとえば、マッピングテンプレート）に従って実行され得、データ検証および／またはデータコンバージョンを必要とし得る。

【0108】

ステップ８０６において、バリデータおよび／またはコンバータ（バリデータ／コンバータ）（たとえば、サーバ１０４、ＤＴＦ１０６、または関連するプロセッサにおいて実行されるソフトウェア）は、処理のためにデータエンティティまたは関連する値を受信し得る。いくつかの実施形態では、バリデータ／コンバータは、処理されているフィールドまたは値に基づいてメソッドを利用または呼び出し得る。

【0109】

ステップ８０８において、リスナ（listener）（たとえば、サーバ１０４、ＤＴＦ１０６、または関連するプロセッサにおいて実行されるソフトウェア）は、受信された値および必要な処理に基づいて、処理のために１つ以上のクラスまたはオブジェクトをインスタンス化する（たとえば、インスタンスを作成する）べきか否かを決定し得る。たとえば、リスナは、データエンティティまたはその中の値を処理するためのベースバリデータおよび特殊化されたバリデータを起動またはインスタンス化してもよい。

【0110】

ステップ８１０において、受信されたデータエンティティに関連付けられる特定の値を処理するために、特殊化されたバリデータ／コンバータにおける対応するメソッドが存在するか否かが決定され得る。メソッドが存在する場合、特殊化されたバリデータ／コンバータは、当該値を処理し得る。

【0111】

ステップ８１２において、メソッドが、特殊化されたバリデータ／コンバータに存在しない場合、受信されたデータエンティティに関連付けられる特定の値を処理するために、ベースバリデータ／コンバータにおける対応するメソッドが存在するか否かが決定され得る。メソッドが存在する場合、ベースバリデータ／コンバータは、当該値を処理し得る。

【0112】

いくつかの実施形態では、値を処理した後（または、処理が必要とされない場合）、データエンティティからのその後の値は、データエンティティがＪＳＯＮからＦＬｉｓｔに完全にマーシャリングされるまで処理され得る。

【0113】

プロセス８００は、例示目的のためであり、図８に示されるものとは異なるステップおよび／もしくはエンティティならびに／または付加的なステップおよび／もしくはエンティティが、データ処理および／または他のデータ処理を行うために使用可能であり得ることも理解されるであろう。

【0114】

図９は、ＲＥＳＴベースのデータコンバージョンのための例示的なプロセス９００を示す図である。いくつかの実施形態では、プロセス９００またはその部分（たとえば、ステップ９０２、９０４、９０６、９０８、９１０および／または９１２）は、サーバ１０４、ＤＴＦ１０６、および／または、別のノードもしくはモジュールによって、または、サーバ１０４、ＤＴＦ１０６、および／または、別のノードもしくはモジュールにおいて実行され得る。

【0115】

プロセス９００を参照して、ステップ９０２において、第１のフォーマットの入力が受信され得る。たとえば、ＪＳＯＮフォーマットのデータを含むペイロードを含むＨＴＴＰ ＰＵＴ要求が、クライアント１１２からサーバ１０４に送信され得る。この例では、ペイロードは、レガシーシステム１１０によって扱われるアカウントを追加または更新するためのアカウント情報を含み得る。

【0116】

ステップ９０４では、所定のメタデータを使用して、第１のフォーマットの入力が第２のフォーマットの入力にコンバートされ得る。たとえば、サーバ１０４または関連するＤＴＦ１０６は、所定のメタデータを使用して構成されるマーシャラを使用して、ＪＳＯＮデータをＦＬｉｓｔデータにコンバートまたは変換し得る。

【0117】

いくつかの実施形態では、第１のフォーマットは、ＪＳＯＮフォーマットまたはエクステンシブルマークアップランゲージ（ＸＭＬ: extensible markup language）フォーマットであり得、第２のフォーマットは、ＦＬｉｓｔフォーマットまたはＰＣＭフォーマットであり得る。いくつかの実施形態では、第１のフォーマットは、ＦＬｉｓｔフォーマットまたはＰＣＭフォーマットであり得、第２のフォーマットは、ＪＳＯＮフォーマットまたはＸＭＬフォーマットであり得る。

【0118】

いくつかの実施形態では、所定のメタデータを使用して、第１のフォーマットのデータを第２のフォーマットのデータにコンバートすることは、実行すべきアクション（たとえば、「ActionEnum」）、または、ＨＴＴＰメソッド、または、要求タイプ（たとえば、DELETE、POST、GET、PUT、またはPATCH）に基づいてコンバージョンルールを選択することを含み得る。

【0119】

いくつかの実施形態では、コンバージョンルールは、第１のフォーマットの値を検証するためのルール、および／または、無効である第１のフォーマットの値を第２のフォーマットの有効な値に変更するためのルールを含み得る。

【0120】

いくつかの実施形態では、所定のメタデータを使用して、第１のフォーマットのデータを第２のフォーマットのデータにコンバートすることは、コンバージョンロジックを生成するよう、所定のメタデータおよびリフレクションプログラミングを使用することを含み得る。たとえば、リフレクションプログラミングは、ソフトウェアが実行時にコードを検査し、所定のメタデータに基づいてデータを１つのフォーマットから別のフォーマットに変換するためのクラスおよび／またはクラスのインスタンスもしくは他の構造を生成することを可能にする。

【0121】

ステップ９０６では、第２のフォーマットの入力を使用して動作を実行するために、第２のフォーマットの入力がレガシーシステム１１０に送信され得る。たとえば、ＤＴＦ１０６がＪＳＯＮデータをＦＬｉｓｔデータにコンバートした後、サーバ１０４は、ＰＣＭ ＡＰＩを介してＦＬｉｓｔデータをレガシーシステム１１０に送信し得る。この例において
ステップ９０８において、第２のフォーマットの出力は、レガシーシステム１１０から受信され得、出力は、第２のフォーマットの入力を使用して実行される動作に少なくとも部分的に基づき得る。たとえば、レガシーシステム１１０は、（たとえば、特定のアカウントについてのアカウント情報を追加または更新することにより）ＦＬｉｓｔデータを処理し得、ＦＬｉｓｔフォーマットの出力を生成し得る。

【0122】

ステップ９１０において、第２のフォーマットの出力は、所定のメタデータを使用して、第１のフォーマットの出力にコンバートされ得る。たとえば、サーバ１０４または関連するＤＴＦ１０６は、所定のメタデータを使用して構成されるマーシャラを使用して、ＦＬｉｓｔデータをＪＳＯＮデータにコンバートまたは変換し得る。

【0123】

ステップ９１２において、第１のフォーマットの出力は、ＲＥＳＴ ＡＰＩを介してクライアント１１２に送信され得る。たとえば、レガシーシステム１１０から受信された出力をＪＳＯＮデータに変換した後、サーバ１０４は、ＪＳＯＮデータを含むＨＴＴＰ２０１応答を生成し得、その応答をクライアント１１２に送信し得る。

【0124】

いくつかの実施形態では、データ変換および／またはコンバージョンが正確であるか否か、たとえば、有効なデータにコンバートされるか否かをテストするよう、１つ以上の後方互換性テストが行われ得る。たとえば、サーバ１０４またはＤＴＦ１０６は、１つのフォーマットから別のフォーマットにコンバートされたデータが有効であるか否かを決定するためのテストを実行し得る。この例では、サーバ１０４またはＤＴＦ１０６は、どの部分が無効であるかまたは何のデータが欠けているかを決定するために構成され得、テストデータまたは関連するレポートをエンドユーザまたは他の関連するエンティティに提供し得る。

【0125】

いくつかの実施形態では、後方互換性テストは、オペレータまたはクライアントからの付加的なメタデータを受信することに応答してトリガされ得る。たとえば、ＤＴＦ１０６は、変換および／またはコンバージョン能力を拡張または使用するために、実行中に新しいメタデータファイルを受信し得る。この例では、新しいメタデータファイルを受信した後、ＤＴＦ１０６または関連するエンティティは、データ変換および／またはコンバージョンを実行するためにメタデータファイルを使用する前に、１つ以上のテストをトリガし得る。

【0126】

いくつかの実施形態では、第１のフォーマットの出力がクライアント１１２に送信され得る。たとえば、クライアント１１２は、１つ以上のＪＳＯＮオブジェクトとして出力を受信し得、そのデータを使用して、ウェブベースのユーザインターフェイスをポピュレートまたは更新し得る。

【0127】

いくつかの実施形態では、クライアント１１２は、ユーザインターフェイスアプリケーション、外部システム、顧客関係管理システム、クラウドサービス、ウェブサービス、ＲＥＳＴ ＡＰＩクライアント、または、金融ソフトウェアを含み得る。

【0128】

プロセス９００は例示目的のためであり、異なるアクションおよび／または付加的なアクションが使用され得ることが理解されるであろう。本明細書において記載されるさまざまなアクションは、異なる順序またはシーケンスで行われ得ることも理解されるであろう。

【0129】

なお、本明細書において記載されるシステム１０２、サーバ１０４、ＤＴＦ１０６、および／または、機能は、特殊目的のコンピューティングデバイスを構成し得る。さらに、本明細書において記載されるシステム１０２、サーバ１０４、ＤＴＦ１０６、および／または、機能は、異なるデータフォーマット間のデータコンバージョンのためのメカニズムおよび／または技術を提供することによって、ネットワーク通信の技術分野を改善し得る。たとえば、所定のメタデータおよびリフレクションプログラミング原理を利用することによって、さまざまなサービスドメインにおいてＪＳＯＮデータをＦＬｉｓｔデータにコンバートもしくは変換し、または、逆にコンバートもしくは変換するソフトウェアまたはコンバージョンロジックが生成され得る。別の例では、ＲＥＳＴ ＡＰＩおよびＤＴＦ１０６を使用することによって、第１のエンティティ（たとえば、ウェブユーザインターフェイスアプリケーション、フロントエンド、金融ソフトウェアなど）は、第１のエンティティによってサポートされないデータフォーマット（たとえば、ＦＬｉｓｔまたはＰＣＭ）を使用するシステムまたはサービス（たとえばレガシーシステム１１０）と通信し得る。

【0130】

本明細書において記載される主題のさまざまな詳細は、本明細書において記載される主題の範囲から逸脱することがなければ、変更され得ることが理解されるであろう。さらに、上記の記載は、例示の目的のためのみであり、限定の目的のためではなく、本明細書において記載される主題は、添付の請求の範囲によって定義される。

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】