TP1アダプタは，OpenTP1上で動作する既存のシステムをサービスプラットフォーム上のサービスとして呼び出す以外に，メインフレーム（TMS-4V，DCCM3など）上で動作する既存のシステムをサービスプラットフォーム上のサービスとして呼び出すこともできます。

TP1アダプタを使用したシステムの運用例を次の図に示します。

図2-58　TP1アダプタの運用例

図内の各処理について説明します。

1. サービスリクエスタからの要求によって，ビジネスプロセスが起動されます。
2. ビジネスプロセスからTP1アダプタを介して，OpenTP1上で動作する受注管理システムおよびメインフレーム上で動作する在庫管理システムがサービスとして呼び出されます。
3. サービスの呼び出し結果がサービスリクエスタに送信されます。

これによって，OpenTP1，メインフレームなどの既存システムのアプリケーションをサービスプラットフォームのサービスとして実行できます。

サービスプラットフォーム環境で，TP1アダプタを使用する場合のシステムの構成例を次の図に示します。

図2-59　TP1アダプタを使用したシステムの構成例

OpenTP1の概要については，マニュアル「OpenTP1 Version 7 分散トランザクション処理機能　OpenTP1　解説」を参照してください。また，TMS-4V/SP/Serverについては，マニュアル「TMS-4V/SP/Server」を参照してください。

TP1アダプタは，RPC通信を使用して，サービスプラットフォームからOpenTP1のシステムを利用できます。

(a)　RPCのサービス要求方式

TP1アダプタのRPC通信では，接続先システムによって，サポートするサービス要求方式が次のとおり異なります。

• 接続先システムがTP1/Server Baseの場合^※1
  
  • リモートAPI機能
  • ネームサービス機能
  • スケジューラダイレクト機能
  • 通信先を指定した接続
• 接続先システムがOpenTP1とRPC通信できるメインフレームシステム（TMS-4V，DCCM3など）の場合^※2
  
  • リモートAPI機能

注※1

TP1/Server Baseとの接続では，TP1/Client/J環境定義でネームサービス機能およびスケジューラダイレクト機能を選択します。

注※2

メインフレームシステム（TMS-4V，DCCM3など）との接続では，端末識別子情報を付加した通信はできません。

注意

これらの機能は，Service Architectの機能を使用しています。ただし，TP1アダプタでは，次に示す機能をサポートしていません。

• RPC通信の連鎖型RPC機能
• トランザクション制御機能
• XAリソースサービス機能
• TP1/Web接続機能
• 一方通知受付機能
• 動的定義変更機能

また，TP1アダプタに同梱されているService Architectのモジュールを使用して，ユーザプログラムを作成しないでください。

●リモートAPI機能

TP1アダプタと接続先システムの間にコネクションを確立します。そのあと，TP1アダプタが発行したAPIを接続先システムに転送して，接続先システム側のプロセスで実行できます。ただし，接続先システムがリモートAPI接続に対応している必要があります。

TP1アダプタでは，TP1アダプタの通信構成定義によって，次の設定ができます。

●コネクションの確立方式の指定

確立するコネクションを次に示すどちらかから指定できます。

• 常設コネクション
• 非常設コネクション

●コネクションの管理方式の指定

コネクションの管理方式を次に示すどちらかから指定できます。

• オートコネクトモード
• 非オートコネクトモード

確立するコネクションによって，指定できる管理方式は次のとおり異なります。

• 常設コネクションを確立する場合
  コネクションの確立を自動化するオートコネクトモード，または明示的に確立要求を行う非オートコネクトモードのどちらかから指定できます。
  オートコネクトモードを指定した場合の処理の概要を「図2-60　常設コネクションを確立した場合の処理概要（オートコネクトモード）」，非オートコネクトモードを指定した場合の処理の概要を「図2-61　常設コネクションを確立した場合の処理概要（非オートコネクトモード）」に示します。
  
• 非常設コネクションを確立する場合
  コネクションの管理方式は指定できません。コネクションは，非オートコネクトモードで確立されます。
  非常設コネクションを確立した場合の処理の概要を「図2-62　非常設コネクションを確立した場合の処理の概要（非オートコネクトモード）」に示します。
  

なお，TP1アダプタの通信構成定義の詳細は，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.6　TP1アダプタを定義する」を参照してください。

図2-60　常設コネクションを確立した場合の処理概要（オートコネクトモード）

1. サービスリクエスタからの要求をHCSCサーバで受け付けます。
2. HCSCサーバでTP1アダプタのメソッドを起動します。
3. TP1アダプタで最初のサービス実行時に常設コネクションを確立します。
4. RPC通信を行い，サービスを実行します。
5. RPC通信の結果（応答データ）をサービスリクエスタに応答します。
6. TP1アダプタの停止時に常設コネクションを解放します。

図2-61　常設コネクションを確立した場合の処理概要（非オートコネクトモード）

1. TP1アダプタを開始したときに，常設コネクションを確立します。
2. サービスリクエスタからの要求をHCSCサーバで受け付けます。
3. HCSCサーバでTP1アダプタのメソッドを起動します。
4. RPC通信を行い，サービスを実行します。
5. RPC通信の結果（応答データ）をサービスリクエスタに応答します。
6. TP1アダプタの停止時に常設コネクションを解放します。

図2-62　非常設コネクションを確立した場合の処理の概要（非オートコネクトモード）

1. サービスリクエスタからの要求をHCSCサーバで受け付けます。
2. HCSCサーバでTP1アダプタのメソッドを起動します。
3. 接続先システム（RAPリスナー）にコネクションの確立要求を行います。
4. RPC通信を行い，サービスを実行します。
5. 確立したコネクションの解放要求を行います。
6. RPC通信の結果（応答データ）をサービスリクエスタに応答します。

コネクションの管理方式にオートコネクトモードを指定した場合，リモートAPI接続時のコネクション確立は，サービス要求を受け付けたときのRPC通信に先だって行われます。したがって，オートコネクトモードを指定した通信環境では，TP1アダプタ運用中に多数のサービス要求を一時期に受け付けた場合，サービス要求を受け付けた数だけコネクション確立処理を行います。

複数のコネクションが確立された場合の処理の概要を次の図に示します。

図2-63　複数のコネクションが確立された場合の処理の概要（オートコネクトモード）

●ネームサービス機能

TP1アダプタは，接続先のOpenTP1システムに対して，サービス要求時にサービスグループ名およびサービス名を指定した上でサーバUAPにサービスを要求します。ネームサービスでサーバUAPがあるノードのネットワークアドレスとサービス名を管理しているため，ネットワーク上のどのノードにサーバUAPがあるかをTP1アダプタで意識する必要がありません。

ネームサービス機能を使用した場合の処理の概要を次の図に示します。

図2-64　ネームサービス機能を使用した場合の処理の概要

1. サービスリクエスタからの要求をHCSCサーバで受け付けます。
2. HCSCサーバでTP1アダプタのメソッドを起動します。
3. ネームサービスにサービスの所在を問い合わせます。
4. RPC通信を行い，サービスを実行します。
5. RPC通信の結果（応答データ）をサービスリクエスタに応答します。

●スケジューラダイレクト機能

接続先OpenTP1システムのスケジューラデーモンを直接指定してサービスを要求します。

スケジューラダイレクト機能を使用した場合の処理の概要を次の図に示します。

図2-65　スケジューラダイレクト機能を使用した場合の処理の概要

1. サービスリクエスタからの要求をHCSCサーバで受け付けます。
2. HCSCサーバでTP1アダプタのメソッドを起動します。
3. RPC通信を行い，サービスを実行します。
4. RPC通信の結果（応答データ）をサービスリクエスタに応答します。

●通信先を指定した接続

接続先OpenTP1システムのスケジューラデーモンを直接指定してサービスを要求します。スケジューラダイレクト機能との違いは，通信先のスケジューラデーモンが持つノードのSPPに異常が発生した場合も，ほかのスケジューラデーモンに転送しないという点です。

接続先OpenTP1システムのスケジューラデーモンを指定した場合の接続処理の概要を次の図に示します。

図2-66　通信先を指定した場合の接続処理の概要

1. サービスリクエスタからの要求をHCSCサーバで受け付けます。
2. HCSCサーバでTP1アダプタのメソッドを起動します。
3. 通信先を指定したRPC通信を行い，サービスを実行します。
4. RPC通信の結果（応答データ）をサービスリクエスタに応答します。

(b)　RPCの通信形態

TP1アダプタでは，RPCの通信形態として次の通信形態をサポートします。

• 同期応答型RPC通信
• 非応答型RPC通信

RPCの通信形態は，TP1アダプタの設定でオペレーション情報の通信モデルで選択します。詳細は，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.6　TP1アダプタを定義する」のサービスアダプタ定義画面での操作について説明している個所を参照してください。

実行環境への配備方法については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「3.1.8　サービスアダプタを配備する」を参照してください。

●同期応答型RPC通信

TP1アダプタから接続先システムに問い合わせデータを送信して，問い合わせた応答データを受け取る通信形態です。TP1アダプタ側では，接続先システムからの応答を受け取るまでメソッドを終了しません。

同期応答型RPC通信をする場合の処理の概要を次の図に示します。

図2-67　同期応答型RPC通信をする場合の処理の概要

●非応答型RPC通信

TP1アダプタから接続先システムに一方送信データを送信して，応答は受け取らない通信形態です。TP1アダプタ側では，データの送信が完了するとメソッドは終了します。

非応答型RPC通信をする場合の処理の概要を次の図に示します。

図2-68　非応答型RPC通信をする場合の処理の概要

(c)　RPCの送受信バッファの生成

TP1サービスプログラムとのRPC通信で使用する送信バッファと受信バッファは，TP1アダプタ起動時のインスタンス初期化処理で生成・保持することによって，運用中のバッファのメモリ確保失敗のリスクを排除しています。しかし，この送受信バッファはインスタンスごとに生成・保持されるため，TP1アダプタ起動時にバッファサイズ分のメモリ量が必要となります。

このため，多くのTP1アダプタを起動したり，バッファサイズの大きいTP1アダプタのインスタンスを複数生成したりすると，メモリ不足が原因でTP1アダプタを起動できないことがあります。

この場合，送受信バッファの生成方法をTP1アダプタ起動時のインスタンス初期化処理での生成・保持から，RPC通信処理時に動的に生成・解放する処理に変更するオプションを使用することで，TP1アダプタ起動時のメモリ不足を解消できます。

RPC通信処理時に動的に生成・解放するオプションの概要を次の図に示します。

図2-69　RPC通信処理時に動的に生成・解放するオプションの概要

RPC通信時に動的に送受信バッファを生成・解放するには，TP1アダプタ実行環境プロパティファイルのbuffer.keepプロパティで送受信バッファの生成オプションの定義を追加する必要があります。定義方法については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.6　TP1アダプタを定義する」のTP1アダプタ実行環境プロパティファイルの作成について説明している個所を参照してください。

注意

RPC通信時に送受信バッファを生成する設定にした場合は，動的に生成される送受信バッファ分のメモリ量を考慮してメモリのリソース設計をするようにしてください。送受信バッファに必要なメモリ量の目安を次に示します。

送受信バッファサイズ（単位：バイト）＝同時に処理できるRPC要求の最大数※1×（送信バッファサイズ※2＋受信バッファサイズ※3）

注※1

通信構成定義ファイルの<con_pool_num>タグの値を示します。

注※2

通信構成定義ファイルの<send_buff_size>タグの値を示します。

注※3

通信構成定義ファイルの<recv_buff_size>タグの値を示します。

RPC通信時に送受信バッファの生成をする設定の有無によって，TP1アダプタの最大メモリ所要量が変わることはありません。また，複数のTP1アダプタを使用する場合は，各送受信バッファサイズを総和したメモリ量が，全体のバッファサイズとして必要になります。

TP1アダプタから接続先システムへ問い合わせを送信してから，応答を受信するまでの経過時間を監視します。経過時間を監視することで，接続先システム上のアプリケーションがループ，停止，または回線障害になった場合に，サービスリクエスタが無限待ちになることを防止します。

TP1アダプタで適用する監視時間の値は，通信処理の状況や接続形態によって異なります。通信処理が開始中または停止中の場合と運用中の場合に分けて説明します。

指定した監視時間内に接続先システムからの応答がない場合，TP1アダプタからHCSCサーバへエラー情報または例外を通知します。

(a)　通信処理が開始中および停止中の場合

TP1/Client/J環境定義ファイルで指定する最大応答待ち時間の値（dcwatchtimオペランドの指定値）を監視時間の値として適用します。通信処理の状況によって，監視時間の値は，次の表に示すとおりに適用されます。

表2-11　通信処理の開始中および停止中に監視時間として適用される値

通信処理		接続形態
通信状況	コネクション状況	リモートAPI接続			通常RPC接続
		常設コネクション		非常設コネクション
		オートコネクト	非オートコネクト
開始中	コネクション確立	−	−	−	−
	コネクション解放	−	○※	−	−
停止中	コネクション解放	○	○	−	−

（凡例）

○：時間監視できます。

−：時間監視できません。

注※

通信障害が発生した場合に適用されます。

(b)　通信処理が運用中の場合

TP1アダプタの通信構成定義ファイルで指定したサービス要求のオペレーションに対する時間監視値（watch_time要素で指定）を監視時間の値として適用します。通信処理の状況によって，監視時間の値は，次の表に示すとおりに適用されます。

表2-12　通信処理の運用中に監視時間に適用される値

通信処理		接続形態
通信状況	コネクション状況	リモートAPI接続			通常RPC接続
		常設コネクション		非常設コネクション
		オートコネクト	非オートコネクト
運用中	コネクション確立	−	−	−	−
	RPC通信	○	○	○	○
	コネクション解放	○※	○※	○	−

（凡例）

○：時間監視できます。

−：時間監視できません。

注※

通信障害が発生した場合に適用されます。

• リモートAPI接続でTP1アダプタのコネクション解放が失敗した場合，TP1アダプタではコネクション解放状態となりますが，接続先のシステムではコネクションの解放を検知していない場合があります。そのため，コネクション状態の不整合が発生し，接続先システムでのrapサーバリソース不足などで，次の通信処理が失敗するおそれがあります。その場合は接続先システムでコネクション確立状態を一度初期化してください。
• リモートAPI接続でTP1アダプタ運用中に障害が発生して，正常に停止処理がされなかった場合，接続先システムでコネクションの解放を検知していない場合があります。その場合は接続先システムでコネクション確立状態を一度初期化してください。
• J2EEサーバ用ユーザプロパティファイル（usrconf.properties）のejbserver.container.passivate.scan.intervalプロパティを，デフォルトの0から変更しないでください。