プロダクション要素へのインタフェース変換
ここでは、各アプリケーションに対し、受信側と送信側の両方のインタフェースを定義することが必要な状況を想定します。
InterSystems IRIS® をこのような構成にする場合、多くは、既存のインタフェース・エンジンを InterSystems IRIS と置き換えることが目的です。このためには、以下のようにする必要があります。
-
前の章で説明したように、プロダクションをルーティング・エンジンとして使用します。
-
以前のインタフェース・エンジンではなく InterSystems IRIS ルーティング・エンジンを使用するよう、既存の各インタフェースを変換します。
-
すべてのインタフェースが変換されたら、以前のインタフェース・エンジンを構成から削除します。
この変換アプローチでは、既存のインタフェース・エンジンをそのままにし、InterSystems IRIS を使用するようにインタフェースを 1 つずつ変換します。新しいインタフェースが InterSystems IRIS を使用して適切に機能することをテストし、確認する間、変換されていないインタフェースは、そのまま以前のエンジンを使用します。変換されたインタフェースが正しく機能したらすぐに、変換されていない次のインタフェースに取り掛かります。このような逐次変更を基にしたポリシーにより、変換の際、可能な限り中断されず、エラーのないサービスが保証されます。
関連するインタフェースのグループを同時に変換するアプローチを取ることもできます。それでもやはり、この作業は一度に 1 インタフェースの変換になります。
ここでは、1 つの既存のインタフェースを InterSystems IRIS を使用するように変換する方法を説明します。一般的な手順は以下のとおりです。各セクションで、以下の手順を 1 つずつ詳細に説明します。
この順序は、通常プロダクションについて説明する順序とは逆です ("ビジネス・サービスが受信メッセージを受け取り...")。しかし、インタフェース変換の経験より、要素をトップダウンで開発し、ビジネス・サービスより始めてカスタム・スキーマへと作業を進めると、多くの場合、前の手順に戻り、上位項目を構成したさまざまな形式で下位項目の名前を入力または修正する必要があることは明らかです。
この手順では、ボトムアップのアプローチを取り、上位項目を構成するときに下位項目の名前がわかるように、下位項目を最初に作成することで後戻りを最小限に抑えます。ボトムアップの順序は、手順 1 および 2、手順 3、4、5、6、7、8、手順 9 および 10 となります。
単純なエラーを削減する確立された命名規則がある場合は特に、トップダウンの順序でこの手順が成功する場合があります。トップダウンの順序は、手順 1 および 2、手順 8、7、6、5、4、3、手順 9 および 10 となります。
プロダクションのバックアップ
フル・バックアップを実行するには、"プロダクションの開発" の “プロダクションの配置” を参照してください。
XML バックアップ・ファイルについて : UNIX® システムを使用する場合、バックアップ XML ファイルをバイナリ・モードで FTP 転送しないでください。通常の FTP では、このファイルを DOS から UNIX® に正しく変換しますが、バイナリ FTP では正しく変換しない場合があります。
インタフェースの説明
企業で使用されている各アプリケーションは、独自のアプリケーション仕様ドキュメントを持っています。仕様ドキュメントでは、アプリケーションが送信 (または受信) できるメッセージのタイプ、およびこれらのイベントに対してアプリケーションが送信 (または受信) するメッセージ・セグメントおよび各セグメント部分について説明しています。情報は非常に詳細です。各アプリケーションのこのようなドキュメントは、そのアプリケーション管理者に問い合わせて確認してください。
ソースおよびターゲット・アプリケーションにはそれぞれアプリケーションの仕様ドキュメントがあります。ただし、変換するインタフェースなど、これらのアプリケーション間の単一のインタフェースは、仕様ドキュメントにリストされている機能の小さなサブセットを使用します。インタフェースを説明する最も有効なソースは、事実上、置換対象のインタフェース定義です。
既存のインタフェース定義を開きます。この定義を表示し、テキスト・ファイルを開いて、ここにインタフェースの動作について簡単な説明を入力します。既存の定義 (LOOP、CASE など) のコーディング規則の詳細を複製しないでください。以下のように簡単に表します。
-
ソースからの受信が予定されるメッセージ・セグメント。
-
ターゲットに送信する前の、インタフェースによるこれらの変更方法。
スキーマ・カテゴリの選択
この手順では、インタフェースの受信側と送信側で使用するスキーマを決定する必要があります。まずおおよその選択を行い、管理ポータルでそのスキーマに対するメッセージをテストすることによりこれを調整します。
各アプリケーションには、メッセージの送信時に使用したり、メッセージの受信時に予定されるスキーマを指定する、アプリケーションの仕様ドキュメントがあります。
ルーティング・ルール・セットの定義
ルーティング・ルール・セットを作成します。詳細は、"ビジネス・ルールの開発" の “ルール・セットの作成および編集” を参照してください。
データ変換の作成
DTL データ変換を作成します。詳細は、"DTL 変換の開発" を参照してください。
ビジネス・オペレーションの追加
インタフェースのビジネス・オペレーションは、ターゲット・アプリケーションへの送信メッセージ転送を制御します。ビジネス・オペレーションの追加方法は、“ビジネス・ホストの追加” を参照してください。
テスト用に、同じ構成名を持つ以下の 2 つのビジネス・オペレーションのあるプロダクションを構成すると便利です。
-
1 つは、プロダクションが正常に動作しているときにインタフェース上でのメッセージの FTP または TCP 転送を制御する FTP または TCP のビジネス・オペレーションです。
-
もう 1 つは、インタフェースのテストまたはトラブルシューティングの際にメッセージをファイルに送信する File ビジネス・オペレーションです。
規則 (項目は同じ構成名を持つ) で、これらの構成項目のうち、一度に有効にできるのは 1 つのみです。“テスト” 環境 (File オペレーション) にするのか、“ライブ” 環境 (TCP または FTP オペレーション) にするのかに応じて、どちらか一方を有効にします。
“ライブ” ビジネス・オペレーションおよび “テスト” ビジネス・オペレーションを作成する手順は以下のとおりです。
-
ターゲット・アプリケーションを調査し、メッセージに含まれることが想定される区切り文字を確認します。
-
“ライブ” (FTP または TCP) ビジネス・オペレーションを作成します。
-
同様の手順を使用して、“テスト” (File) ビジネス・オペレーションを作成します。
“テスト” (File) オペレーションに “ライブ” オペレーションと同じ構成の名前を付与します。
-
[有効にする] フィールドを使用して、“ライブ” (FTP または TCP) または “テスト” (File) バージョンのビジネス・オペレーションを有効化および無効化します。一度にアクティブにできる同じ名前のビジネス・サービスは 1 つのみです。
詳細は、“複数バージョンのビジネス・ホストの操作” を参照してください。
ルーティング・プロセスの作成または編集
新しいインタフェースでルーティング・エンジンを操作できるようにするには、以下を行うルーティング・プロセスをプロダクションに追加する必要があります。
-
ソースからのデータの解釈方法を指示する (ルーティング・ルールを指定する)
-
解釈されたデータの送信先を指示する (ビジネス・オペレーションを指定する)
新しいルーティング・プロセスを作成できます。
ビジネス・サービスの追加
インタフェースのビジネス・サービスは、ソース・アプリケーションからの受信メッセージを受け取ります。
テスト用に、同じ構成名を持つ以下の 2 つのビジネス・サービスのあるプロダクションを構成すると便利です。
-
1 つは、プロダクションが正常に動作しているときに FTP または TCP を介してソース・アプリケーションからのメッセージを受け取る FTP または TCP のビジネス・サービスです。
-
もう 1 つは、インタフェースのテストまたはトラブルシューティングの際にファイルからのメッセージを受け取る File ビジネス・サービスです。
規則 (項目は同じ構成名を持つ) で、これらの構成項目のうち、一度に有効にできるのは 1 つのみです。“テスト” 環境 (File サービス) にするのか、“ライブ” 環境 (TCP または FTP サービス) にするのかに応じて、どちらか一方を有効にします。
“ライブ” ビジネス・サービスおよび “テスト” ビジネス・サービスを作成する手順は以下のとおりです。
-
“ライブ” (FTP または TCP) ビジネス・サービスを作成します。
-
同様の手順を使用して、“テスト” (File) ビジネス・サービスを作成します。
“テスト” (File) サービスに “ライブ” サービスと同じ構成の名前を付与します。
-
[有効にする] フィールドを使用して、“ライブ” (FTP または TCP) または “テスト” (File) バージョンのビジネス・サービスを有効化および無効化します。一度にアクティブにできる同じ名前のビジネス・サービスは 1 つのみです。
詳細は、“複数バージョンのビジネス・ホストの操作” を参照してください。
インタフェースのテスト
一般には、“稼動” しているプロダクションの完全コピーである、別の “テスト” プロダクションを管理する必要があります。新しいインタフェースは “テスト” プロダクション内で開発します。これが完了すると、新しいインタフェースのコピーを “ライブ” プロダクションに移行することができます。
新しいインタフェースをテストするには、以下の手順を実行します。
-
ソース・アプリケーションからのいくつかのサンプル・メッセージをファイルに捕捉します。
-
“テスト” プロダクションで、File ビジネス・サービスと File ビジネス・オペレーションを有効にし、ファイルとしてメッセージを送信します。
-
結果として作成された出力ファイルのメッセージ・データを調べ、ターゲット・アプリケーションの要件を満たしているかどうかを確認します。
-
必要であれば、インタフェース要素を調整し、再テストします。
-
“テスト” プロダクション内で、ビジネス・サービスとビジネス・オペレーションの “テスト” (File) バージョンで無効を選択し、“ライブ” (FTP または TCP) バージョンを再度有効にします。
インタフェースの導入
テスト・プロダクションでインタフェースのテストを完了したら、新しいインタフェース要素を稼動中のプロダクションに追加します。これを行うには、以下を実行します。
-
"プロダクションの開発" の “プロダクションのエクスポート” で説明されているプロセスを使用して、ライブ・プロダクション全体をバックアップします。
Note:XML バックアップ・ファイルについて : UNIX® システムを使用する場合、バックアップ XML ファイルをバイナリ・モードで FTP 転送しないでください。通常の FTP では、このファイルを DOS から UNIX® に正しく変換しますが、バイナリ FTP では正しく変換しない場合があります。
-
"プロダクションの開発" の “プロダクションのエクスポート” で説明されているプロセスを使用して、テスト・プロダクションの新規要素をエクスポートします。
例えば、以下の項目をエクスポートします。
-
インタフェースの新しいクラス : ビジネス・プロセス、データ変換、ビジネス・オペレーション、ビジネス・サービス、およびあらゆるユーティリティ・クラス
-
ビジネス・ルール
-
カスタム・スキーマ
指定した場所に、InterSystems IRIS により配置パッケージ・ファイルが作成されます。
-
-
新規要素が含まれる配置パッケージ・ファイルをライブ・プロダクションに配置します。
詳細は、"プロダクションの開発" の “ターゲット・システムでのプロダクションの配置” を参照してください。
-
オプションで、新しいプロダクション要素のアラートを構成します。
-
ビジネス・サービスおよびビジネス・オペレーションには、[エラー時に警告] という構成設定があります。[エラー時に警告] を真に設定している場合、その項目でエラー状態が発生するとすぐ、アラートが自動的にトリガされます。アラートがトリガされた時点で、イベント・ログにメッセージが書き込まれます。また、電子メールや携帯電話でアラートをユーザに通知することもできます。 [エラー時に警告] 設定を偽に設定している場合、オプションは無効になります。
-
[警告猶予期間] (ビジネス・サービスの場合) と [警告再試行猶予期間] (ビジネス・オペレーションの場合) は、有効になっているアラートの頻度を適切に制限します。
Note:プロダクション全体にアラートを設定するには、"プロダクションの監視" の “アラートの監視” を参照してください。
-
-
新しいインタフェースが新しいメッセージをすべて処理していることを確認します。
-
以前のインタフェース・テクノロジを無効化またはクリーンアップします。
-
以前保留されていたすべての要求が満たされ、すべてのキューが空となっていることを確認します。
-
古いインタフェースを無効にします。“自動開始” オプションを無効にします。
-