Cosminexus V11 BPM/ESB基盤 サービスプラットフォーム 解説

解説書

3021-3-J42-50

前書き

対象製品

マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」の前書きの対象製品の説明を参照してください。

輸出時の注意

本製品を輸出される場合には、外国為替及び外国貿易法の規制並びに米国輸出管理規則など外国の輸出関連法規をご確認の上、必要な手続きをお取りください。

なお、不明な場合は、弊社担当営業にお問い合わせください。

商標類

HITACHI，Cosminexus，DCCM，HAモニタ，HiRDB，JP1，Object Wrapper，OpenTP1，TPBroker，uCosminexus，XDMは，株式会社 日立製作所の商標または登録商標です。

Apache(R)，Apache Kafka(R)，およびKafka(R)は，Apache Software Foundationの米国およびその他の国における登録商標または商標です。

Eclipseは，Eclipse Foundation, Inc.の商標です。

IBMは，世界の多くの国で登録されたInternational Business Machines Corporationの商標です。

Linuxは，Linus Torvalds氏の米国およびその他の国における登録商標です。

Microsoft，Excel，Windows，Windows Serverは，マイクロソフト 企業グループの商標です。

Oracle(R)，Java，MySQL及びNetSuiteは，Oracle，その子会社及び関連会社の米国及びその他の国における登録商標です。

Salesforceは，salesforce.com,Inc.の商標です。

本書に記載されるSAP及びその他のSAPの製品やサービス，並びにそれらの個々のロゴは，ドイツ及びその他の国におけるSAP SE（又はSAPの関連会社）の商標若しくは登録商標です。

UNIXは，The Open Groupの登録商標です。

その他記載の会社名，製品名などは，それぞれの会社の商標もしくは登録商標です。

Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです。

This product includes software developed by the Apache Software Foundation (http://www.apache.org/).

本ソフトウェアに含まれる第三者ソフトウェアに関する情報を次に示します。

第三者ソフトウェア：Trang

著作権者：Thai Open Source Software Center Ltd

当該ソフトウェアのライセンス条文：以下の通り。

Copyright (c) 2002, 2003, 2008 Thai Open Source Software Center Ltd

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Neither the name of the Thai Open Source Software Center Ltd nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

ランゲージパックの使用について

このマニュアルでは，Eclipse Babel Projectが提供するBABEL日本語ランゲージパックを適用したEclipseメニュー表記を使用しています。使用するランゲージパックのバージョンによっては，マニュアル内の表記と異なる場合があります。

発行

2024年 2月 3021-3-J42-50

著作権

All Rights Reserved. Copyright (C) 2020, 2024, Hitachi, Ltd.

変更内容

変更内容(3021-3-J42-50) uCosminexus Service Architect 11-40，uCosminexus Service Platform 11-40

追加・変更内容

変更個所

Service PlatformおよびService Architectから次の適用OSを削除した。

Windows Server 2019 Standard

Windows Server 2019 Datacenter

−

TP1アダプタで，TP1/Clientが使用するOpenTP1システムとのRPC通信条件を動的に変更できるようにした。

2.7.3(2)，2.7.6，付録A.1(7)，付録A.1(13)，付録A.2(1)

TP1アダプタとMessage Queueアダプタで，ビジネスプロセスの実行時にオペレーションを切り替えられるようにした。

2.7.5，2.10.2(5)，2.22

HTTPアダプタのマルチパート型への対応によって，一度に複数のファイルを送信できるようにした。

2.16.3(3)，2.16.3(4)，2.16.4(3)，2.16.4(5)，2.16.4(6)，2.16.13(2)，2.16.13(6)，2.16.13(10)

途中終了アクティビティを追加し，ビジネスプロセスのフローの任意の場所でプロセスを終了できるようにした。

3.2.3，3.2.4，3.4.8

スケジュール駆動受付の記述を追加した。

3.6，4.6.2，4.9.1(2)，10.1，10.2.5，付録C.1(4)

単なる誤字・脱字などはお断りなく訂正しました。

はじめに

このマニュアルをお読みになる際の前提情報については，マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」のはじめにの説明を参照してください。

第1編　機能解説編

1　サービスプラットフォームの機能概要

この章では，サービスプラットフォームでSOAを適用したシステムを実現するための機能の概要について説明します。

1.1　開発環境の機能概要

サービスプラットフォームの開発環境は，実行環境で動かすサービスアダプタやビジネスプロセスなどの定義をするための環境です。開発環境では，主に次の機能を提供しています。

電文フォーマットの作成機能

ユーザ定義受付の作成機能

サービスアダプタの作成機能

ビジネスプロセスの作成機能

データ変換定義の作成機能

ビジネスプロセスのデバッグ機能

これらの機能は，開発環境の画面を利用して定義します。

また，開発環境の画面を利用して作成した定義の整合性を検証する機能も備えています。HCSCコンポーネントの検証機能は，HCSCコンポーネントの作成中や作成後など，任意の段階で実行できます。

各機能の概要を次に説明します。

1.1.1　電文フォーマットの作成機能

電文フォーマットとは，サービスリクエスタ，サービスアダプタ，およびサービス部品の間でやり取りされる電文の形式です。利用するデータの形式がXML形式の場合はXML形式の電文フォーマットを，バイナリ形式（XML形式以外）の場合はバイナリ形式の電文フォーマットを作成します。バイナリ形式の電文フォーマットの場合は，画面を利用して作成できます。

バイナリ形式の電文フォーマットの作成に利用する画面の例を次の図に示します。

図1‒1　バイナリ形式の電文フォーマットを作成する画面の例

バイナリ形式の電文フォーマットは，ウィザードで新規追加したあと，バイナリ形式の電文フォーマットを作成する画面で，電文フォーマットを構成する要素の詳細な内容を定義できます。

なお，すでに作成されているバイナリ形式の電文フォーマットを流用して，新たなバイナリ形式の電文フォーマットを作成する場合には，既存のバイナリ形式の電文フォーマットを複製して使用することもできます。

1.1.2　ユーザ定義受付の作成機能

サービスリクエスタからの実行要求を受け付けるリクエスト受付には，標準受付とユーザ定義受付があります。

標準受付は，サービスリクエスタからのサービス部品の実行要求を受け付ける固定のインターフェースです。ユーザ定義受付は，サービスリクエスタからのサービス部品の実行要求に合わせて任意の形式を定義できるインターフェースです。

標準受付を利用するには，それぞれの標準受付の形式に合わせてサービスリクエスタを作成する必要があります。そのため，既存のサービスリクエスタを再利用する場合，標準受付のインターフェースの形式と合わないときには，サービスリクエスタを作り直したり，大きく改造したりする必要がありました。

このような場合，既存のサービスリクエスタからの実行要求を受け付けられる形式のユーザ定義受付を作成できます。ユーザ定義受付の作成について，次の図に示します。

図1‒2　ユーザ定義受付の作成

また，ユーザ定義受付には，特定のビジネスプロセスを呼び出すユーザ定義受付（呼出先固定）と，呼び出すビジネスプロセスを選択できるユーザ定義受付（呼出先選択）があります。2つを区別しない場合は，ユーザ定義受付と表記します。

ユーザ定義受付（呼出先固定）とユーザ定義受付（呼出先選択）の作成について，次の図に示します。

図1‒3　ユーザ定義受付（呼出先固定）とユーザ定義受付（呼出先選択）の作成

なお，ユーザ定義受付（呼出先選択）はHTTP受付の場合だけ使用できます。

サービスプラットフォームには，ユーザ定義受付を効率的に作成するためのウィザードが用意されています。

1.1.3　サービスアダプタの作成機能

サービスアダプタとは，サービス部品を呼び出すためのHCSCコンポーネントの一つです。

サービスプラットフォームでは，他システム，データベース，ファイルなど用途に合わせてさまざまなサービスアダプタを提供しています。また，提供しているサービスアダプタでは直接対応できないプロトコルを持つシステムにも対応できるように，カスタムアダプタ開発フレームワークを使用して開発する汎用カスタムアダプタを提供しています。

サービスプラットフォームで利用できるサービスアダプタの種類を次の表に示します。

表1‒1　サービスアダプタの種類

種別

用途

SOAPアダプタ

Webサービス（SOAP通信）を利用してサービス部品を呼び出す場合

SessionBeanアダプタ

SessionBeanを利用してサービス部品を呼び出す場合

MDB（WS-R）アダプタ

WS-R（WS-Reliability）を利用してMDB（Message Driven Bean）で作成したサービス部品を呼び出す場合

MDB（DBキュー）アダプタ

DBキューを利用して非同期のサービス部品を呼び出す場合

DBアダプタ

データベースの操作をサービス部品として利用する場合

TP1アダプタ

既存のOpenTP1システム内にあるサービス部品を呼び出す場合

ファイルアダプタ

HCSCサーバ上のローカルディスクに対して直接ファイルの入出力をする場合

Object Accessアダプタ

既存のTPBrokerシステム（Object Wrapperシステム）のサービス部品を呼び出す場合

Message Queueアダプタ

既存のメッセージキュー（IBM MQシステム）に対してメッセージの送受信をする場合

FTPアダプタ

サービスプラットフォームとFTPサーバとの間でファイルの送受信をする場合

ファイル操作アダプタ

ファイルのレイアウト変換，文字コード変換，複製，移動，削除，圧縮，伸張，および一覧取得をする場合

メールアダプタ

SMTPプロトコルをサポートしたメールサーバをサービスプラットフォーム上でサービス部品として呼び出す場合

HTTPアダプタ

Webサーバ上に公開されているリソースや，RESTスタイルで公開されているWebサービス（RESTful Webサービス）を呼び出す場合

コマンドアダプタ

オペレーティングシステム上で動作する外部コマンドを起動し，実行結果を取得する場合

SFTPアダプタ

サービスプラットフォームとSFTPサーバとの間でSFTPプロトコルによるファイル転送をする場合

Kafkaアダプタ

サービスプラットフォームからKafkaにメッセージを送信する場合

gRPCアダプタ

gRPCで作成されたサービスにメッセージを送信する場合

汎用カスタムアダプタ

サービスプラットフォームで提供するサービスアダプタでは対応できないプロトコルを持つシステムのサービス部品を呼び出す場合

サービスアダプタの作成に利用する画面の例を次の図に示します。

図1‒4　サービスアダプタを作成する画面の例

ウィザードでサービスアダプタを新規追加したあとに，これらの画面で詳細な内容を定義します。なお，すでに作成されているサービスアダプタを流用して，新たなサービスアダプタを作成する場合には，既存のサービスアダプタを複製して使用することもできます。

サービスアダプタの定義の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.　サービスアダプタの定義」を参照してください。

1.1.4　ビジネスプロセスの作成機能

ビジネスプロセスとは，複数のサービスの処理の順番や条件などを定義して，一連の業務の流れとして定義したものです。

画面で定義したビジネスプロセスはBPELとして記述されます。

ビジネスプロセスの作成に利用する画面の例を次の図に示します。

図1‒5　ビジネスプロセスを作成する画面の例

ビジネスプロセスを作成する画面では，アクティビティと，アクティビティ同士の関係を規定する連結線，および変数・相関セットを利用してビジネスプロセスを定義します。

アクティビティとは，ビジネスプロセスの構成要素となる部品であり，処理の構造も表現したものです。複数のアクティビティを連結して，ビジネスプロセスのフローを規定します。ビジネスプロセスは，アクティビティを画面上で配置・連結して定義します。

また，ビジネスプロセスと各アクティビティには，変数と相関セットを定義できます。

変数は，ビジネスプロセスの処理の中で，条件式の項の値などに変数値を利用する場合に宣言します。

相関セットは，サービスリクエスタから送信された要求電文を一意に識別するために利用する文字列です。

なお，すでに作成されているビジネスプロセスを流用して，新たなビジネスプロセスを作成する場合には，既存のビジネスプロセスを複製して使用することもできます。

さらに，サービスプラットフォームでは，ビジネスプロセスを作成するときに，ビジネスプロセスの実行状態の管理を設定できます。また，より高度なビジネスプロセスとして，複数のビジネスプロセスを階層化したビジネスプロセスを作成できます。

(1)　ビジネスプロセスの実行状態の管理

ビジネスプロセスを新規追加する時には，実行環境でのビジネスプロセスの実行状態を管理するかどうか設定する機能があります。

ビジネスプロセスの実行状態の管理を設定すると，ビジネスプロセスの実行途中に障害が発生した場合に，ビジネスプロセスのどの段階で障害が発生し，どこまでが実行されたのか把握できます。停止したビジネスプロセスの状況を把握することで，ビジネスプロセス内の特定の処理から再度実行できます。

ビジネスプロセスの実行状態の管理については，「1.3.4　実行履歴の管理機能」を参照してください。

なお，ビジネスプロセスの実行状態を管理するかどうかが選択できるので，処理の速度などの性能を重視するビジネスプロセスでは，ビジネスプロセスの実行状態を管理しない設定もできます。

(2)　ビジネスプロセスの階層化

あるビジネスプロセスからほかのビジネスプロセスを呼び出すように定義して，ビジネスプロセスを階層化できます。

ビジネスプロセスの階層化の概要を次の図に示します。

図1‒6　ビジネスプロセスの階層化

「図1-6　ビジネスプロセスの階層化」のように，ビジネスプロセスから各サービスを呼び出す一連の流れの中に，ビジネスプロセスを呼び出す処理を定義できます。

ビジネスプロセスで呼び出す処理としてビジネスプロセスを部品化できるため，より複雑な業務処理もビジネスプロセス化できます。

(3)　上流工程で作成したビジネスプロセス定義のインポート

ビジネスプロセスの設計時に，設計ツール（BPMNを用いた上流設計ツール）を使用して作成したBPEL定義を，サービスプラットフォームの開発環境（Service Architect）へインポートできます。インポートしたBPEL定義は，ビジネスプロセス定義として変換され，画面上にアクティビティとして表示されます。メッセージやプロセスの詳細化などの編集ができます。

1.1.5　データ変換定義の作成機能

データ変換定義とは，実行環境でサービスリクエスタから送信される電文データの変換方法や，サービス部品間で受け渡すデータのフォーマットの変換方法について定義したものです。

変換元／変換先のスキーマファイルを作成したあと，作成したスキーマファイルを基に，変換元の要素や属性を変換先のどの要素や属性に変換（マッピング）するかなど，変換時の処理について定義します。

あらかじめExcelで変換元と変換先の組み合わせを定義したファイルを作成しておくことで，マッピングを画面上で一括して設定することもできます。接続数が多い場合や複数のビジネスプロセスで同じようにマッピングする場合，作成したファイルを利用することで開発効率を向上できます。

データ変換定義の作成に利用する画面の例を次の図に示します。

図1‒7　データ変換定義を作成する画面の例

データ変換を定義する画面では，変換元と変換先を接続（マッピング）し，変換元から変換先への値の代入をビジュアルに定義できます。

また，変換元のデータを加工してから変換先に代入したい場合は，ファンクションを設定できます。ファンクションには，文字列の連結や数値演算などの機能があります。

ファンクションを利用したデータの加工の例を次の図に示します。

図1‒8　ファンクションを利用したデータの加工の例

また，変換元データが複数ある場合のくり返し処理や，一定の条件に合致する場合にだけデータを代入するなどの設定もできます。

1.1.6　配備定義機能

HCSCコンポーネントの配備は，開発環境と運用環境でリポジトリを介して相互に情報をやり取りしながら実施します。

HCSCコンポーネントの配備の概要について，次の図に示します。

図1‒9　HCSCコンポーネントの配備

運用環境では，HCSCサーバおよびクラスタのセットアップ時に，リポジトリにある実行環境の構成情報（システム構成定義）が更新されます。更新されたシステム構成定義は，リポジトリの管理機能でエクスポートします。

開発環境では，運用環境でエクスポートしたHCSCサーバおよびクラスタのセットアップ情報を含むシステム構成定義をリポジトリにインポートし，システム構成定義にHCSCコンポーネントをどのHCSCサーバに配備するかを定義（配備定義）して更新し，更新したシステム構成定義をエクスポートします。

ポイント

開発環境で配備定義するときは，サービス部品をクラスタ，または単一のHCSCサーバ単位で配置します。

そのあと，運用環境では，開発環境で更新したシステム構成定義をリポジトリにインポートします。システム構成定義の内容に従って，実行環境へHCSCコンポーネントを配備します。

リポジトリのエクスポートについては，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「4.2　リポジトリのエクスポート」を参照してください。リポジトリのインポートについては，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「4.3　リポジトリのインポート」を参照してください。

1.1.7　パッケージング機能

パッケージングとは，開発環境で作成したHCSCコンポーネントと必要な情報をEARファイル形式で組み立てて，リポジトリに格納することをいいます。

開発環境では，画面を利用してパッケージングを実行できます。

パッケージングの概要を次の図に示します。

図1‒10　パッケージング機能

開発環境からパッケージング機能を実行すると，パッケージングに必要な情報がリポジトリから収集され，HCSCコンポーネントが検証されます。

検証の結果，HCSCコンポーネントに必要な定義がすべて定義されている場合，EARファイルが作成されます。

HCSCコンポーネントに不備がある場合，パッケージングは中止されます。

作成されたEARファイルは，リポジトリに格納されます。運用環境では，リポジトリに格納されたEARファイル形式のHCSCコンポーネントを実行環境に配備します。

1.1.8　配備から開始または停止から削除の一括実行機能

開発環境では，次の一連の処理を一括で実行できます。

HCSCコンポーネントをHCSCサーバに配備して開始する

HCSCコンポーネントを停止してHCSCサーバから削除する

開発環境または運用環境で一つ一つ実施していた作業を開発環境で一括実行するため，ユーザの操作負担を軽減できます。なお，一括実行は，システム開発時，または単体テストから結合テスト時を対象としています。

一括実行の処理の流れを次の図に示します。図中の番号は，開発環境でユーザが操作したあとに，自動的に実行される処理の順番を示しています。

図1‒11　一括実行の処理の流れ

1.1.9　サービスリクエスタの作成機能

サービスリクエスタとは，業務担当者からのサービス部品の実行要求を受け付け，各HCSCコンポーネントにサービス部品の実行要求を送信するアプリケーションです。

サービスリクエスタは，開発環境で作成し，実行環境に組み込んで利用します。

サービスプラットフォームの開発環境の画面には，サービスリクエスタの作成に必要なWSDLやスタブを取得するなど，サービスリクエスタの作成を支援する機能があります。

1.1.10　ビジネスプロセスのデバッグ機能

ビジネスプロセスのデバッグ機能とは，ビジネスプロセスに着目したテストおよびデバッグを実行できる機能です。

ビジネスプロセスのデバッグ機能を利用することで，HCSCコンポーネントを実行環境に配備しなくても，開発環境上でビジネスプロセスをデバッグできます。ビジネスプロセスの定義およびデバッグが同じ環境上でできるため，開発効率を向上できます。

ビジネスプロセスのデバッグでは，ビジネスプロセスの処理がアクティビティ間をどのように進んでいるかを確認したり，アクティビティで使用している変数の中身を確認・更新したりできます。

ビジネスプロセスのデバッグで利用する画面の例と利用できる機能を次の図に示します。

図1‒12　ビジネスプロセスのデバッグで利用する画面の例と利用できる機能

ビジネスプロセスのデバッグで利用できる機能を次に示します。

ステップ実行および再開

アクティビティにブレークポイントを設定することで，ビジネスプロセスの処理を任意のタイミングで中断できます。中断しているビジネスプロセスでは，アクティビティ単位で中断しながら，逐次処理を進めることができます。

デバッグ情報の表示

デバッグ中のビジネスプロセスの名称，およびアクティビティの名称を表示します。

変数・相関セットの確認

ビジネスプロセスで使用している変数および相関セットの値を確認します。

変数の更新

ビジネスプロセスで使用している変数の値を変更し，ビジネスプロセスに反映します。

XPath評価

分岐アクティビティや代入アクティビティに指定した条件式の妥当性を評価します。

アウトラインビューの表示

デバッグ中のビジネスプロセスで定義した変数の名称，およびアクティビティの名称を表示します。

ビジネスプロセスのデバッグ機能では，サービスおよびサービスリクエスタをエミュレートして利用することもできます。

1.2　実行環境の機能概要

サービスプラットフォームの実行環境は，SOAを実現するための環境です。実行環境では，主に次の機能を提供しています。

サービス振り分け実行機能

各種サービス呼び出し機能

ビジネスプロセス実行機能

各機能の概要を次に説明します。

1.2.1　サービス振り分け実行機能

サービスプラットフォームでは，要求を行う利用者側のシステムを「サービスリクエスタ」と呼び，機能を提供する側の業務処理を「サービス部品」と呼びます。また，サービス連携を実現するエンタープライズサービスバス（ESB：Enterprise Service Bus）やBPEL準拠のビジネスプロセスを管理するSOA環境を「HCSCサーバ」と呼びます。利用者がサービス部品の実行要求をすると，SOAはHCSCサーバに配備したビジネスプロセスやサービスアダプタの中から，適切なサービス部品を呼び出して実行します。また，業務・機能を“サービス”として管理し，要求に対してサービス振り分けを実行します。

サービス振り分け実行機能の詳細については，「2.　さまざまなシステムと接続するための機能」を参照してください。

1.2.2　各種サービス呼び出し機能

サービスプラットフォームでは，さまざまな種類のサービスを呼び出すためのサービスアダプタを提供しています。

次に示すサービスアダプタを利用することで，柔軟にシステムを構築でき，既存システムのデータをサービス部品として有効に活用できます。

Webサービス（SOAP通信）を利用するためのSOAPアダプタ

SessionBeanを利用するためのSessionBeanアダプタ

WS-Rを利用してMDBで作成したサービス部品を呼び出すためのMDB（WS-R）アダプタ

DBキューを利用して非同期のサービス部品を呼び出すためのMDB（DBキュー）アダプタ

データベースをサービス部品として利用するためのDBアダプタ

OpenTP1やXDM/DCCM3上のシステムを利用するためのTP1アダプタ

ファイルを介した業務処理システムを利用するためのファイルアダプタ

メインフレームなどの基幹システムを利用するためのObject Accessアダプタ

既存のメッセージキュー（IBM MQシステム）に対してメッセージの送受信をするためのMessage Queueアダプタ

FTPサーバと接続してファイル転送をするためのFTPアダプタ

ファイルのフォーマット変換，複製，削除などをするためのファイル操作アダプタ

SMTPプロトコルをサポートしたメールサーバをサービスプラットフォーム上で利用するためのメールアダプタ

Webサーバ上に公開されているリソースや，RESTスタイルで公開されているWebサービス（RESTful Webサービス）を利用するためのHTTPアダプタ

オペレーティングシステム上で動作する外部コマンドを起動し，実行結果を取得するためのコマンドアダプタ

サービスプラットフォームとSFTPサーバとの間でSFTPプロトコルによるファイル転送をするためのSFTPアダプタ

サービスプラットフォームからKafkaにメッセージを送信するためのKafkaアダプタ

gRPCで作成されたサービスにメッセージを送信するためのgRPCアダプタ

サービスプラットフォームで提供する上記サービスアダプタでは対応できないプロトコルを持つシステムと接続してサービスを呼び出すための汎用カスタムアダプタ

サービスアダプタの詳細については「2.　さまざまなシステムと接続するための機能」を参照してください。

1.2.3　ビジネスプロセス実行機能

ビジネスプロセスとは，複数のサービス部品の処理の順番や条件などを定義して，一連の業務の流れとして定義したものです。

サービスプラットフォームでは，ビジネスプロセスに定義されている順に，連続してサービス部品を呼び出して実行できます。

ビジネスプロセス実行機能は，サービス呼び出しの流れを制御するためのビジネスプロセスの開発，および実行を行います。

ビジネスプロセスの詳細については，「3.　ビジネスプロセスの機能」を参照してください。

1.3　運用環境の機能概要

サービスプラットフォームの運用環境は，実行環境の構築，必要な情報の配置，運用管理，および実行履歴の管理をする環境です。運用環境では，主に次の機能を提供しています。

実行環境のセットアップ機能

HCSCコンポーネントの配備機能

実行環境での運用を管理する機能

実行履歴の管理機能

これらの機能は，コマンドまたは運用環境の画面を利用して実行します。

各機能の概要を次に説明します。

1.3.1　実行環境のセットアップ機能

運用環境では，コマンドを利用して，実行環境のHCSCサーバをセットアップできます。また，HCSCサーバをセットアップするときに，あわせてクラスタもセットアップできます。

(1)　HCSCサーバおよびクラスタのセットアップ機能

HCSCサーバのセットアップの概要について，次の図に示します。

図1‒13　HCSCサーバのセットアップの概要

運用環境からコマンドを実行すると，あらかじめ作成していたHCSCサーバの構成定義ファイルとセットアップ定義ファイルからセットアップに必要な情報を取得してHCSCサーバがセットアップされます。

単独のHCSCサーバをセットアップする場合

コマンド実行時にクラスタ名を指定しますが，この段階では，単独のHCSCサーバであるため，クラスタの構成にはなりません。

ほかのHCSCサーバをセットアップするときに，クラスタ名を指定してセットアップすることで，クラスタを構成できます。

セットアップ済みのHCSCサーバとクラスタを構成する場合

コマンド実行時に，ほかのHCSCサーバをセットアップしたときに指定したクラスタ名を指定すると，すでにセットアップされているHCSCサーバとクラスタを構成するHCSCサーバがセットアップできます。

1.3.2　HCSCコンポーネントの配備機能

配備とは，HCSCコンポーネントを実行環境で利用できるよう，実行環境に必要な情報を配置することです。

HCSCコンポーネントは，運用環境でコマンドを実行して実行環境に配備できます。

配備の概要について，次の図に示します。

図1‒14　配備の概要

HCSCコンポーネントを配備する場合，開発環境で作成してリポジトリに格納されている配備定義の情報に従って，HCSCコンポーネント（EARファイル）を実行環境（HCSCサーバ）に配備します。

1.3.3　実行環境での運用を管理する機能

運用環境では，実行環境での業務の運用を管理できます。

実行環境での業務を開始する場合や，実行環境の構成を変更するために業務を停止する場合，また障害の発生によって業務を停止する場合など，必要に応じて運用環境で実行環境の業務の運用状態を確認し，操作できます。

運用環境から実施できる実行環境の操作について，次の表に示します。

表1‒2　運用環境から実施できる実行環境の操作

操作内容

実行インターフェース

画面

コマンド

HCSCサーバのセットアップ

−

○

HCSCサーバのアンセットアップ

−

○

HCSCサーバの起動

○

○

HCSCサーバの起動（クラスタ内一括起動）

−

○

HCSCサーバの停止

○

○

HCSCサーバの停止（クラスタ内一括停止）

−

○

HCSCサーバの情報の参照※

○

○

HCSCサーバのセットアップ情報の参照

−

○

HCSCサーバの定義

−

○

HCSCサーバの定義内容の確認※

○

○

HCSCサーバの定義の変更

−

○

HCSCサーバのバージョンアップ

−

○

標準受付の開始

○

○

標準受付の停止

○

○

ユーザ定義受付の配備

−

○

配備済みユーザ定義受付の削除

−

○

ユーザ定義受付の開始

○

○

ユーザ定義受付の停止

○

○

ユーザ定義受付の情報の参照※

○

○

ユーザ定義受付の定義情報の確認

○

○

ユーザ定義受付の定義情報の変更

−

○

サービスアダプタの配備

−

○

配備済みサービスアダプタの削除

−

○

サービスアダプタの開始

○

○

サービスアダプタの停止

○

○

サービスアダプタの情報の参照※

○

○

ビジネスプロセスの配備

−

○

配備済みビジネスプロセスの削除

−

○

ビジネスプロセスの開始

○

○

ビジネスプロセスの停止

○

○

ビジネスプロセスの情報の参照※

○

○

HCSCサーバ，標準受付，およびHCSCコンポーネントの状態の確認

○

○

HCSCサーバのリソースの稼働状態の表示

○

○

アプリケーションの操作

−

○

HCSC-Manager環境のバックアップ

−

○

HCSC-Manager環境のリストア

−

○

サービス情報の変更

−

○

サービス情報の確認

○

○

（凡例）

○：利用できます。

−：利用できません。

注※

画面とコマンドで参照できる情報が異なります。

1.3.4　実行履歴の管理機能

運用環境では，ビジネスプロセスのプロセスインスタンスの実行履歴を管理できます。

(1)　プロセスインスタンスの実行履歴の管理

プロセスインスタンスの実行履歴は，ビジネスプロセスのプロセスインスタンスの実行状況を履歴としてデータベースに記録（永続化）して管理します。

(a)　プロセスインスタンスの実行履歴の検索

条件を指定して，プロセスインスタンスの実行履歴を検索できます。相関セット，開始日時または状態を検索キーとして利用できます。

(b)　プロセスインスタンスの実行履歴の詳細情報の参照

プロセスインスタンスの実行履歴の詳細情報を参照できます。次に示す情報を参照できます。

相関セット定義名および相関セット値

各プロセスインスタンスが保持する変数の変数定義名，および変数値

ビジネスプロセス内に定義された各アクティビティの状態

(c)　プロセスインスタンスの実行履歴の削除

ビジネスプロセスの確認のために使用するデータベースから不要なプロセスインスタンスの実行履歴を削除できます。1件ずつ削除することも，状態を指定して一括して削除することもできます。

(d)　実行中のプロセスインスタンスの再実行

フォルトが発生するなどの理由で処理できなかったビジネスプロセスのプロセスインスタンスを確認して，実行が中断したプロセスインスタンスを再実行できます。プロセスインスタンスの再実行は，1件ずつ再実行することも一括して再実行することもできます。

1.4　HCSCサーバのクラスタ構成

複数のHCSCサーバを組み合わせて，より冗長なクラスタ構成の環境を構築できます。

1.4.1　ロードバランス機能を利用したHCSCサーバの冗長構成

ロードバランス機能とは，複数台のHCSCサーバを並列に並べることで，サービスリクエスタからのサービスの実行要求の一点集中によるJ2EEサーバの負荷を軽減するための機能です。サービスプラットフォームでは，次に示すロードバランサを使用して負荷を分散できます。

汎用ロードバランサ

同期（Webサービス）の標準受付の場合に使用します。

CTM

同期（SessionBean）の標準受付の場合に使用します。

サービスプラットフォームの実行環境では，ロードバランサを使用して，複数のHCSCサーバを組み合わせて，より冗長なクラスタ構成の環境を構築できます。

HCSCサーバのロードバランスクラスタ構成について，次の図に示します。

図1‒15　HCSCサーバのロードバランスクラスタ構成

同期（Webサービス，SessionBean）の標準受付の場合だけ，ロードバランサを使用してサービスリクエスタからのサービス部品の実行要求を，複数のHCSCサーバに分散して送信できます。

使用するロードバランサによっては，運用を停止しないで，ロードバランスクラスタを構成するHCSCサーバを追加したり，削除したりできます。また，HCSCサーバに配備済みのサービスアダプタやビジネスプロセスを停止しないで，サービスアダプタやビジネスプロセスを新規追加することもできます。

1.4.2　クラスタソフトウェアを利用したHCSCサーバの冗長構成

クラスタソフトウェアとは，システムの信頼性および稼働率の向上を目的とした，サーバプログラムを含めたシステムの切り替えを実現するプログラムです。サービスプラットフォームでは，次に示すクラスタソフトウェアと連携できます。

Windows Server Failover Cluster（Windowsの場合）

HAモニタ（UNIXの場合）

サービスプラットフォームの実行環境では，クラスタソフトウェアと連携して，同じ内容のHCSCサーバを2つ組み合わせて，より冗長なクラスタ構成（コールドスタンバイ構成）の環境を構築できます。

クラスタを構成する2つのHCSCサーバのセットアップ情報や，配備されるHCSCコンポーネントは，同じ内容である必要があります。

HCSCサーバのクラスタ構成について，次の図に示します。

図1‒16　HCSCサーバのクラスタ構成

サービスプラットフォームの実行環境では，クラスタソフトウェアと連携して，実行系と待機系を1対1で運用するシステム（1:1系切り替えシステム）を構築できます。

1:1系切り替えシステムでは，実行系に何らかの障害が発生すると，クラスタソフトウェアがこれを検知して，自動的に待機している系に切り替えて業務を続行します。障害発生時の系の切り替えを次の図に示します。

図1‒17　障害発生時の系の切り替え

障害の発生から系の切り替えまでの流れは次のとおりです。

実行系HCSCサーバで障害が発生します。

クラスタソフトウェアが実行系HCSCサーバの障害を検知します。

実行系HCSCサーバのあるマシンへのネットワークが切断されます。

クラスタソフトウェアがネットワークを待機系HCSCサーバのあるマシンに切り替えます。

クラスタソフトウェアが待機系HCSCサーバを起動します。

なお，クラスタソフトウェアには，障害を検知した場合に待機系HCSCサーバを自動的に起動するよう設定しておきます。

1.4.3　N対1クラスタ構成を利用したHCSCサーバの冗長構成

N対1クラスタ構成とは，ロードバランスクラスタを構成するそれぞれのHCSCサーバに対してHAクラスタ相当の構成（コールドスタンバイ構成）にしたものです。

すべての待機系サーバを1台のマシン上で稼働させることで，実行系のマシンN台に対して待機系のマシン1台で構成を構築できます。そのため，HAクラスタ構成のHCSCサーバの組を並列に並べることができ，負荷分散できます。

N対1クラスタ構成について，次の図に示します。

図1‒18　N対1クラスタの構成

1.5　クラスタ構成における運用環境の構成パターン

クラスタ構成にする場合に実現できる運用環境と実行環境の構成パターンには，実行環境の数に関係なく運用環境を1台とする構成のほかに，運用環境と実行環境を1対1に配置する構成があります。

運用環境と実行環境を1対1に配置する構成のメリットとデメリットを次に示します。

メリット

実行環境と運用環境を1台のマシンにまとめられます。

運用環境が1台ダウンしても，エラーになったリクエストをほかの運用環境から再実行できます。

運用環境用のマシンが不要になるため，運用監視ソフトのライセンス数を低減できます。

予備の運用環境が不要になります。

デメリット

UNIX上に実行環境を構築する場合，運用環境のGUIを利用できません。

クラスタ単位の一括操作ができません。

運用・実行1対1構成の構成例を次の図に示します。

図1‒19　運用・実行1対1構成の構成例

注意事項

運用・実行1対1構成以外の構成から運用・実行1対1構成に移行する場合の注意事項

運用環境と実行環境の構成については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「1.2　システム全体と運用環境・実行環境の関係」を参照してください。

移行前の環境が08-70以前にセットアップした環境の場合，クラスタに含まれるHCSCサーバをいったんすべてアンセットアップする必要があります。このため，データベースに格納されているプロセスインスタンスや実行履歴など，クラスタで共有する情報は移行できません。

データベースを利用していない運用・実行1対1構成からデータベースを利用した運用・実行1対1構成には移行できません。

1.6　分散開発時のリポジトリのインポート

複数の開発環境で分散開発する場合，開発したリポジトリを運用環境で使用するために，リポジトリを集約する必要があります。リポジトリを集約するには，次のどちらかを実施してください。

開発環境でサービスインポートを実行する。

運用環境でコンポーネントインポートを実行する。

開発環境でリポジトリを集約する場合は，インポート対象の取捨選択やサービスIDの衝突回避など，運用環境で集約するよりも詳細に条件を設定できます。

運用環境でリポジトリを集約する場合は，リポジトリを集約するための開発環境が不要になるため，マシンの台数を削減できます。

サービスインポートの詳細についてはマニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「3.2.3　リポジトリをインポートする」を，コンポーネントインポートの詳細についてはマニュアル「サービスプラットフォーム システム構築・運用ガイド」の「4.6　コンポーネント単位でのリポジトリの追加，更新，および削除」を参照してください。

1.6.1　コンポーネントインポート機能を利用した分散開発の流れ

コンポーネントインポート機能を利用すると，開発環境を用意しないで，運用コマンドだけでリポジトリを集約できます。このため，開発環境（マスタ）とテスト環境を1台のマシンに集約でき，マシンの台数を削減できます。

開発環境でリポジトリを集約する場合の流れを「図1-20　開発環境でリポジトリを集約する場合の流れ」に，運用環境でリポジトリを集約する場合の流れを「図1-21　運用環境でリポジトリを集約する場合の流れ」にそれぞれ示します。

図1‒20　開発環境でリポジトリを集約する場合の流れ

図1‒21　運用環境でリポジトリを集約する場合の流れ

また，開発環境でリポジトリを集約する場合と，運用環境でリポジトリを集約する場合の環境の移行手順を次の図に示します。

図1‒22　環境の移行手順

1.6.2　分散開発時の注意事項

分散開発時の注意事項を次に示します。

サービスID，サービス名，コンテキストルートおよびUOCファイルは，リポジトリの集約時に重複しないよう，分散開発環境全体で一意となるように命名してください。

UOCファイルの共通パッケージは，同期を取ってください。

2　さまざまなシステムと接続するための機能

この章では，サービス部品を呼び出す基本的な流れや，サービスプラットフォームの実行環境の仕組みについて説明します。また，各種通信サービスや他システムなどに接続したときの，サービス部品の呼び出しについても説明します。なお，開発環境の定義は，運用環境を通じて実行環境で動作しますが，ここでは運用環境の説明は省略します。

2.1　サービス部品呼び出しの基本的な流れ

サービスプラットフォームを使ってシステム構築や運用をする場合，サービスリクエスタからHCSCサーバを経由してサービス部品を呼び出す流れを理解することで，より良いシステムが実現でき，SOAを適用することによる効果が得られます。

また，SOAを適用したシステム開発をする場合も，どのように運用されるのか理解した上で，サービス部品呼び出し処理やエラー時の処理を設計することが大切です。

サービス部品を呼び出す流れには，プロトコルで共通な部分と，プロトコルごとに異なる部分があります。ここでは，プロトコルで共通するサービス部品を呼び出す基本的な流れについて説明します。

2.1.1　基本的な構造

サービス部品を呼び出すためには，基本的にサービスリクエスタ，受付，HCSCメッセージ配送制御，サービスアダプタ，およびサービス部品が必要です。受付は，サービス部品を呼び出すための要求を受け付けるところで，標準受付とユーザ定義受付があります。

標準受付とは，HCSCサーバが標準提供している，サービスリクエスタからの要求電文を受け付けるための機能（インターフェース）です。ユーザ定義受付とは，開発環境でユーザが定義したものをHCSCサーバに配備してから，サービスリクエスタからの実行要求を受け付けるための機能（インターフェース）で，ユーザが定義した任意のインターフェースで受け付けることができます。

(1)　標準受付の場合

標準受付を使用する場合の構造と開発の流れとの関係を次の図に示します。

図2‒1　標準受付を使用する場合の構造と開発の流れとの関係

サービス部品を呼び出すサービスリクエスタとHCSCサーバ，およびサービス部品の関係は，次のようになっています。開発の流れに沿って，それぞれの関係を説明します。

サービス部品側の開発の流れ

最初に呼び出すサービス部品を作成します。次に，呼び出すサービス部品に合わせた形式の電文フォーマットやビジネスプロセス定義（BPEL）を作成し，開発環境で電文フォーマットからサービスアダプタを定義したり，ビジネスプロセスを定義したりします（ビジネスプロセスにも電文フォーマットを定義します）。呼び出すサービス部品に合わせた形式の電文フォーマットを作成する方法は，使用するプロトコル（SOAP，RMI-IIOP，WS-R，およびJMS）によって異なります。定義したサービスアダプタやビジネスプロセスは実行環境（HCSCサーバ）へ配備します。電文フォーマットについては，マニュアル「サービスプラットフォーム開発ガイド 基本開発編」の「4.　電文フォーマットの作成」を参照してください。ビジネスプロセス定義（BPEL）については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「5.　ビジネスプロセスの定義」を参照してください。

サービスリクエスタ側の開発の流れ

サービス部品の作成後，定義したサービスアダプタやビジネスプロセスを呼び出すサービスリクエスタを作成します。サービスリクエスタを作成する方法については，使用する標準受付の種別によって異なります。サービスリクエスタの作成については，マニュアル「サービスプラットフォーム開発ガイド 基本開発編」の「9.　サービスリクエスタの作成」を参照してください。

(2)　ユーザ定義受付の場合

ユーザ定義受付を使用する場合の構造と開発の流れとの関係を次の図に示します。

なお，ここではWebサービス（SOAP通信）を使用した場合の例を使用して説明します。

図2‒2　ユーザ定義受付を使用する場合の構造と開発の流れとの関係

Webサービス（SOAP通信）を使用する場合，サービス部品を呼び出すサービスリクエスタとHCSCサーバ，およびサービス部品の関係は，次のようになっています。開発の流れに沿って，それぞれの関係を説明します。

サービス部品側の開発の流れ

最初に呼び出すサービス部品を作成します。次に，呼び出すサービス部品に合わせた形式の電文フォーマットやビジネスプロセス定義（BPEL）を作成し，開発環境で電文フォーマットからサービスアダプタを定義したり，ビジネスプロセスを定義したりします（ビジネスプロセスにも電文フォーマットを定義します）。定義したサービスアダプタ，ビジネスプロセス，およびユーザ定義受付は実行環境（HCSCサーバ）へ配備します。電文フォーマットについては，マニュアル「サービスプラットフォーム開発ガイド 基本開発編」の「4.　電文フォーマットの作成」を参照してください。ビジネスプロセス定義（BPEL）については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「5.　ビジネスプロセスの定義」を参照してください。

受付側の開発の流れ

サービス部品の作成後，呼び出すビジネスプロセスの電文フォーマットに合わせたWSDLを作成し，開発環境でユーザ定義受付を定義します。ユーザ定義受付の定義については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「2.　ユーザ定義受付の定義」を参照してください。

サービスリクエスタ側の開発の流れ

ユーザ定義受付の作成後，定義したユーザ定義受付を呼び出すサービスリクエスタを作成します。ユーザ定義受付を定義するときに使用したWSDLからスタブを生成し，スタブを呼び出すサービスリクエスタを作成します。サービスリクエスタの作成については，マニュアル「サービスプラットフォーム開発ガイド 基本開発編」の「9.　サービスリクエスタの作成」を参照してください。

2.1.2　サービス部品を呼び出す流れ

サービスリクエスタからサービス部品を呼び出す流れは，受付の種類と呼び出すHCSCコンポーネントの組み合わせによって動作が異なります。受付の種類と呼び出すHCSCコンポーネントの組み合わせを次に示します。

標準受付からサービスアダプタを直接呼び出してサービス部品を実行する場合

標準受付からビジネスプロセスを呼び出してサービス部品を実行する場合

ユーザ定義受付からビジネスプロセスを呼び出してサービス部品を実行する場合

それぞれの場合の電文の流れを，次に説明します。エラー時の処理の流れについては，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「7.　障害対策」を参照してください。

(1)　標準受付からサービスアダプタを直接呼び出してサービス部品を実行する場合

標準受付からサービスアダプタを直接呼び出してサービス部品を実行する場合，サービスアダプタで定義したサービス名をサービスリクエスタで指定して実行します。実行すると，サービスアダプタで定義したサービス部品を呼び出します。

サービスアダプタを直接呼び出す場合の電文の流れを次の図に示します。

図2‒3　サービスアダプタを直接呼び出す場合の電文の流れ

サービスリクエスタから標準受付に送信する要求電文は，開発環境でサービスアダプタを定義したときに設定した（サービス部品の形式に合わせた）電文フォーマットを使用します。そのため，サービスリクエスタ内で，サービスアダプタで定義した電文フォーマットに合わせた要求電文を作成し，作成した電文を標準受付のパラメタ（ユーザ電文のパラメタ）に設定して実行します。

サービスアダプタからサービス部品を呼び出します。呼び出すときは，サービスアダプタで定義した要求電文を使用します。このように，サービスリクエスタから送信する要求電文とサービス部品が受け取る要求電文は同一になります。なお，サービス部品の電文フォーマット以外の電文フォーマットでも，サービスアダプタでデータ変換定義をすれば，サービスリクエスタから要求できます。

サービス部品からサービスアダプタに応答電文を送信します。応答電文は，サービスアダプタで定義した応答電文と同じ電文フォーマットを使用します。

サービスリクエスタへ応答します。応答には，サービスアダプタで定義した応答電文の電文フォーマットを使用します。このように，サービス部品から返す応答電文とサービスリクエスタで受け取る応答電文は同一になります。

データ変換定義については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「7.3　データ変換定義」を参照してください。

(2)　標準受付からビジネスプロセスを呼び出してサービス部品を実行する場合

標準受付からビジネスプロセスを呼び出してサービス部品を実行する場合，ビジネスプロセスで定義したサービス名（ビジネスプロセス名）をサービスリクエスタで指定して実行します。そして，ビジネスプロセスに定義したプロセスに従って，処理を実行します。プロセスはアクティビティから構成されています。その中の，サービス呼出アクティビティでは，定義されたサービスアダプタを呼び出して，サービスアダプタに定義されたサービス部品を実行します。ビジネスプロセスを呼び出す場合の電文の流れを次の図に示します。

図2‒4　ビジネスプロセスを呼び出す場合の電文の流れ

サービスリクエスタ内で，ビジネスプロセスの受付アクティビティで定義した要求電文の電文フォーマットに合わせた要求電文を作成し，作成した電文を標準受付のパラメタ（ユーザ電文のパラメタ）に設定して実行します。サービスリクエスタで指定する要求電文は，ビジネスプロセスの受付アクティビティに定義した電文フォーマットを使用します。

ビジネスプロセスからサービス部品を呼び出します。呼び出すときは，サービス呼出アクティビティで定義した要求電文を使用します。この要求電文の電文フォーマットは，呼び出すサービス部品のサービスアダプタで定義した要求電文の形式と同じである必要があります。なお，サービス部品の電文フォーマット以外の電文フォーマットでも，サービスアダプタでデータ変換定義をすれば，サービス呼出アクティビティから要求できます。

サービス部品からサービスアダプタに応答電文を送信します。応答電文は，ビジネスプロセスのサービス呼出アクティビティの応答電文と同じ電文フォーマットを定義します。

サービスリクエスタへ応答します。応答には，ビジネスプロセスの応答アクティビティで定義した応答電文の電文フォーマットを使用します。

データ変換定義については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「7.3　データ変換定義」を参照してください。

(3)　ユーザ定義受付からビジネスプロセスを呼び出してサービス部品を実行する場合

ユーザ定義受付は，ユーザが定義した任意の形式でサービス部品実行要求を受け付け，応答を返すインターフェースです。

開発環境での定義に従ってユーザ定義受付からビジネスプロセスを呼び出し，ビジネスプロセスに定義したプロセスに従って，処理を実行します。サービス呼出アクティビティでは，定義されたサービスアダプタを呼び出し，サービスアダプタに定義されたサービス部品を実行します。ユーザ定義受付を使う場合の電文の流れを次の図に示します。

なお，ここではSOAP通信基盤を使用した場合の例を使用して説明します。

図2‒5　ユーザ定義受付を使う場合の電文の流れ（SOAP通信基盤の例）

サービスリクエスタからの要求電文は，ビジネスプロセスの受付アクティビティに定義した電文フォーマットと同一のものになります。そのため，ビジネスプロセスの受付アクティビティに定義した電文フォーマットに合わせた形式のWSDLを開発環境のユーザ定義受付定義で設定する必要があります。サービスリクエスタからSOAP受付を呼び出すときは，開発環境でSOAP受付に定義したWSDLを使用します。SOAP1.1（SOAP通信基盤またはJAX-WSエンジン）に対応したサービスリクエスタを使用する場合は，WSDLからWSDL2Javaコマンドを使用してスタブを生成し，スタブを呼び出すようにサービスリクエスタを実装します。

SOAP1.2（JAX-WSエンジン）に対応したサービスリクエスタを使用する場合は，WSDLからcjwsimportコマンドを使用してサービスクラスを生成し，サービスクラスを呼び出すようにサービスリクエスタを実装します。

ビジネスプロセスからサービス部品を呼び出すときは，サービス呼出アクティビティで定義した要求電文を使用します。この要求電文の電文フォーマットは，呼び出すサービス部品のサービスアダプタで定義した要求電文の形式と同じである必要があります。

サービス部品からの応答電文もビジネスプロセスのサービス呼出アクティビティの応答電文で同じ電文フォーマットを定義します。なお，サービス部品の電文フォーマット以外の電文フォーマットでも，サービスアダプタでデータ変換定義をすれば，サービス呼出アクティビティから要求できます。

サービスリクエスタへの応答は，ビジネスプロセスの応答アクティビティで定義した応答電文の電文フォーマットを使用します。この電文フォーマットは開発環境のユーザ定義受付定義で設定するWSDLの応答電文と同じ形式である必要があります。

データ変換定義については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「7.3　データ変換定義」を参照してください。

2.1.3　サービス部品側と異なる電文フォーマットでサービス部品を呼び出す場合の流れ

サービス部品側の電文フォーマットと異なる電文でサービス部品を呼び出す場合，またはサービス部品側の電文フォーマットと異なる電文を応答として受信する場合は，開発環境で標準電文フォーマットを定義します。また，標準電文フォーマットとサービス部品電文フォーマットの変換ルールを定義したデータ変換定義は，開発環境で定義します。標準電文フォーマットの電文をサービス部品電文フォーマットの電文に変換することでサービス部品を呼び出せます。標準電文フォーマットとデータ変換定義の関係を次の図に示します。

図2‒6　標準電文フォーマットとデータ変換定義の関係

サービスリクエスタからは，標準電文フォーマットの形式に合わせた電文フォーマットを要求電文に指定して，サービス部品の呼び出しを要求します。

サービスアダプタでは標準電文フォーマットからサービス部品電文フォーマットにデータを変換し，変換後の電文フォーマットでサービス部品を呼び出します。

サービス部品からの応答についても，サービスアダプタで，サービス部品電文フォーマットから標準電文フォーマットにデータを変換します。

サービスリクエスタに標準電文フォーマットを応答します。

複数のサービスアダプタがある場合も，次の図に示すようにService1用のサービスアダプタ，Service2用のサービスアダプタ，Service3用のサービスアダプタで，それぞれに同一の標準電文フォーマットAと，それぞれのデータ変換定義を定義すると，サービスリクエスタ側から要求するときに，要求時のサービス名（Service1など）を変更すれば，同じ要求電文で要求できます。

図2‒7　複数のサービスアダプタで同一の標準電文フォーマットを定義した場合の流れ

標準電文フォーマットおよびサービス部品電文フォーマットについては，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「4.　電文フォーマットの作成」を参照してください。データ変換定義については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「7.3　データ変換定義」を参照してください。

2.1.4　サービス部品呼び出し処理で与えられる識別情報

HCSCサーバ内のサービス部品呼び出し要求とその流れを区別するために，各要求電文にメッセージ共通IDとサービスリクエストIDが割り当てられます。これらのIDはメッセージログ，リクエストトレース，および性能解析トレースで出力されます。

メッセージ共通IDとサービスリクエストIDをたどることで，サービス部品呼び出しの処理の流れを追跡できます。電文の追跡については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「7.7　サービス部品呼び出し要求時の障害対策」を参照してください。

なお，HCSCサーバに割り当てられる識別情報のほかに，ユーザが任意の値を設定できるクライアント相関IDがあります。

(1)　識別情報の種類

メッセージ共通ID

サービスリクエスタからサービス部品呼び出し要求を受け取ったタイミングで自動的に割り当てられます。応答まで同じメッセージ共通IDを使用します。

サービスリクエスタからビジネスプロセスを呼び出す場合でも，ビジネスプロセス内の個々のサービス部品呼び出し処理を同一の処理として識別できます。メッセージ共通IDの形式を次に示します。

CSC_[サーバ名]_[受付時刻(ミリ秒)]_[通番]

　注　末尾に与えられる通番は，「1」から順番に割り当てられる番号です。

（例）CSC_CSCServerName_2008-04-20_11:32:18.360_1

サービスリクエストID

HCSCサーバ内の個別のサービス部品呼び出し処理ごとに割り当てられる識別情報です。

サービスリクエスタからのサービス部品呼び出し要求を受け取ったタイミングだけでなく，ビジネスプロセスからのサービス部品呼び出し処理を実施するタイミングでも割り当てられます。サービスリクエストIDの形式を次に示します。

MSG_[サーバ名]_[受付種別]_[受付時刻(ミリ秒)]_[通番]

　注　末尾に与えられる通番は，「1」から順番に割り当てられる番号です。

（例）MSG_CSCServerName_MDBWSR_2008-04-20_11:32:18.360_1

ビジネスプロセスインスタンスID

ビジネスプロセスの個々のプロセスインスタンスを特定するための識別情報（プロセスインスタンスの識別子）です。サービスリクエスタからビジネスプロセスの再実行を要求する場合や，プロセスインスタンスの実行履歴を削除するときに使用します。

(2)　識別情報が割り当てられるタイミング

標準受付から直接サービスアダプタを呼び出す場合は，メッセージ共通IDおよびサービスリクエストIDは，HCSCサーバ内で識別情報として引き継がれます。標準受付やユーザ定義受付からビジネスプロセスを経由してサービスアダプタを呼び出す場合は，メッセージ共通IDは，HCSCサーバ内で識別情報として引き継がれます。しかし，サービスリクエストIDは，サービス部品呼び出し処理ごとの識別情報として引き継がれます。また，ビジネスプロセスインスタンスIDは，ビジネスプロセスが最初に要求を受け付けるときに割り当てます。

メッセージ共通IDとサービスリクエストIDが割り当てられるタイミングを次の図に示します。

図2‒8　識別情報割り当てのタイミング

2.2　Webサービス（SOAP通信）を使用したサービスとの接続

2.2.1　Webサービスの通信基盤との関係

実行環境のHCSCサーバは，Webサービスの通信基盤およびWebサーバ（HTTPサーバ）上で動作します。そのため，Webサービス（SOAP通信）を使用する場合は，Webサービスを実行するための通信基盤やWebサーバの設定が必要です。

サービスリクエスタとHCSCサーバの標準受付（Webサービス）との関係は，クライアントとサーバの関係であり，HCSCサーバのサービスアダプタとサービス部品の関係もクライアントとサーバの関係になります。

サービスリクエスタ側およびサービス部品側の通信基盤は，SOAP通信基盤を使用する場合とJAX-WSエンジンを使用する場合があります。SOAP1.1に対応したサービスリクエスタおよびサービス部品を使用する場合は，SOAP通信基盤またはJAX-WSエンジンを使用します。また，SOAP1.2に対応したサービスリクエスタおよびサービス部品を使用する場合は，JAX-WSエンジンを使用します。

サービスリクエスタおよびサービス部品と，SOAP通信基盤の関係を次の図に示します。なお，サービスリクエスタ側とサービス部品側で，片方がSOAP通信基盤，もう片方がJAX-WSエンジンを使用する構成も可能です。

図2‒9　SOAP通信基盤との関係

2.2.2　サービス部品呼び出し時のユーザ電文とWSDLの関係

サービス部品呼び出し時のユーザ電文とWSDLの関係は，標準受付の場合とユーザ定義受付の場合とで異なります。

(1)　標準受付の場合

SOAP通信時のユーザ電文とWSDLの関係（標準受付（Webサービス））を次に説明します。

(a)　SOAP通信基盤を使用するとき

通信基盤にSOAP通信基盤を使用するときの，SOAP通信時のユーザ電文とWSDLの関係（標準受付（Webサービス））を次の図に示します。なお，サービスリクエスタ側とサービス部品側で，片方がSOAP通信基盤，もう片方がJAX-WSエンジンを使用する構成も可能です。JAX-WSエンジンを使用する側の詳細は，「(b)　JAX-WSエンジンを使用するとき」を参照してください。

図2‒10　SOAP通信基盤を使用するときのSOAP通信時のユーザ電文とWSDLの関係（標準受付（Webサービス））

サービスアダプタを定義するときは，サービス部品側の電文フォーマットとしてサービス部品のWSDLを定義します（サービス部品のWSDLには，要求電文，応答電文およびフォルト電文の形式が定義されています）。WSDLを作成するには，SOAP通信基盤が提供するJava2WSDLコマンドを使用します。

サービスリクエスタから標準受付（Webサービス）を呼び出してサービス部品を呼び出すときは，HCSCサーバが提供するWSDLを使用します。HCSCサーバが提供するWSDLを基にWSDL2Javaコマンドを使用してスタブを作成できます。

サービスリクエスタから標準受付（Webサービス）を呼び出すときは，サービス部品側の電文フォーマットに合わせた要求電文を事前に作成します。そして，HCSCサーバが提供するWSDLに定義されている標準受付（Webサービス）のパラメタ（ユーザ電文のパラメタ）に設定して実行します。

サービスリクエスタからビジネスプロセスを呼び出すときは，要求電文はビジネスプロセスの受付アクティビティに定義した電文フォーマットになります。サービスリクエスタ内でビジネスプロセスの受付アクティビティで定義されている要求電文の電文フォーマットに合わせた電文を作成し，作成した電文を標準受付（Webサービス）のパラメタ（ユーザ電文のパラメタ）に設定して実行します。

サービスリクエスタへの応答は，サービスアダプタで定義した応答電文の電文フォーマットを使用します。

(b)　JAX-WSエンジンを使用するとき

通信基盤にJAX-WSエンジンを使用するときの，SOAP通信時のユーザ電文とWSDLの関係（標準受付（Webサービス））を次の図に示します。なお，サービスリクエスタ側とサービス部品側で，片方がJAX-WSエンジン，もう片方がSOAP通信基盤を使用する構成も可能です。SOAP通信基盤を使用する側の詳細は，「(a)　SOAP通信基盤を使用するとき」を参照してください。

図2‒11　JAX-WSエンジンを使用するときのSOAP通信時のユーザ電文とWSDLの関係（標準受付（Webサービス））

サービスアダプタを定義するときは，サービス部品側の電文フォーマットとしてサービス部品のWSDLを定義します（サービス部品のWSDLには，要求電文，応答電文およびフォルト電文の形式が定義されています）。サービス部品のWSDLは，サービス部品側が用意しているURLにアクセスしてWSDLを取得します。

サービスリクエスタから標準受付（Webサービス）を呼び出してサービス部品を呼び出すときは，HCSCサーバが提供するWSDLを使用します。HCSCサーバが提供するWSDLを基にcjwsimportコマンドを使用してサービスクラスを作成できます。

サービスリクエスタから標準受付（Webサービス）を呼び出すときは，サービス部品側の電文フォーマットに合わせた要求電文を事前に作成します。そして，HCSCサーバが提供するWSDLに定義されている標準受付（Webサービス）のパラメタ（ユーザ電文のパラメタ）に設定して実行します。

サービスリクエスタからビジネスプロセスを呼び出すときは，要求電文はビジネスプロセスの受付アクティビティに定義した電文フォーマットになります。サービスリクエスタ内でビジネスプロセスの受付アクティビティで定義されている要求電文の電文フォーマットに合わせた電文を作成し，作成した電文を標準受付（Webサービス）のパラメタ（ユーザ電文のパラメタ）に設定して実行します。

サービスリクエスタへの応答は，サービスアダプタで定義した応答電文の電文フォーマットを使用します。

(2)　ユーザ定義受付の場合

SOAP通信時のユーザ電文とWSDLの関係（SOAP受付）を次に説明します。

(a)　SOAP通信基盤を使用するとき

通信基盤にSOAP通信基盤を使用するときの，SOAP通信時のユーザ電文とWSDLの関係（SOAP受付）を次の図に示します。

図2‒12　SOAP通信基盤を使用するときのSOAP通信時のユーザ電文とWSDLの関係（SOAP受付）

SOAP受付の場合，サービスリクエスタで指定する要求電文は，ビジネスプロセスの受付アクティビティに定義した任意の電文フォーマットの形式で要求します（受付アクティビティに定義した電文フォーマットに合わせたWSDLを作成し，SOAP受付に定義します）。

スタブは，ユーザが定義したWSDLを基に，SOAPアプリケーション開発支援機能が提供するWSDL2Javaコマンドを使用して作成できます。標準受付（Webサービス）の場合と異なり，サービスリクエスタ側のプログラムで要求電文のXMLを作成する必要はありません。サービスリクエスタではスタブに要求を出すときに，それぞれのパラメタに値をセットして実行します（スタブの中でSOAPメッセージを作成します）。

サービスリクエスタへの応答は，ビジネスプロセスの応答アクティビティで定義した応答電文の電文フォーマットで応答します（応答アクティビティに定義した電文フォーマットに合わせたWSDLを作成し，SOAP受付に定義します）。

(b)　JAX-WSエンジンを使用するとき

通信基盤にJAX-WSエンジンを使用するときの，SOAP通信時のユーザ電文とWSDLの関係（SOAP受付）を次の図に示します。

図2‒13　JAX-WSエンジンを使用するときのSOAP通信時のユーザ電文とWSDLの関係（SOAP受付）

SOAP受付の場合，サービスリクエスタで指定する要求電文は，ビジネスプロセスの受付アクティビティに定義した任意の電文フォーマットの形式で要求します（受付アクティビティに定義した電文フォーマットに合わせたWSDLを作成し，SOAP受付に定義します）。

サービスクラスは，ユーザが定義したWSDLを基に，JAX-WS機能が提供するcjwsimportコマンドを使用して作成できます。標準受付（Webサービス）の場合と異なり，サービスリクエスタ側のプログラムで要求電文のXMLを作成する必要はありません。サービスリクエスタではサービスクラスに要求を出すときに，それぞれのパラメタに値をセットして実行します（サービスクラスの中でSOAPメッセージを作成します）。

サービスリクエスタへの応答は，ビジネスプロセスの応答アクティビティで定義した応答電文の電文フォーマットで応答します（応答アクティビティに定義した電文フォーマットに合わせたWSDLを作成し，SOAP受付に定義します）。

2.2.3　Webサービス（SOAP通信）の場合のトランザクション

Webサービス（SOAP通信）の場合，HCSCサーバ内で管理しているトランザクションは，サービス側には引き継がれません。Webサービス（SOAP通信）の場合のトランザクションを次の図に示します。

図2‒14　Webサービス（SOAP通信）の場合のトランザクション

2.2.4　Webサービス（SOAP通信）の場合のCookie情報

ビジネスプロセスからSAP ERP 6.0上のサービスを呼び出す場合，更新系の処理によって返却されたCookie情報を引き継ぐ必要があります。SAP ERP 6.0以外のサービスを呼び出す場合，Cookie情報の引き継ぎは不要です。

SAP ERP 6.0上のサービスを呼び出す場合で，Cookie情報を引き継ぐには，HCSCサーバランタイム定義ファイルのcookie-parsingプロパティの指定によって，Cookie情報の引き継ぎを有効にする方法と，ビジネスプロセスのヘッダ割当変数にHTTPヘッダ名を設定する方法があります。ビジネスプロセスのヘッダ割当変数にHTTPヘッダ名を設定する方法の詳細については，「2.2.5　Webサービス（SOAP通信）の場合のHTTPヘッダ引き継ぎ」を参照してください。

Cookie情報の引き継ぎの流れを次の図に示します。

図2‒15　SAP ERP 6.0のサービス呼び出しでのCookie情報の引き継ぎ

Cookie情報としてサービス部品が発行するSet-Cookieヘッダの情報が引き継がれます。

次に示すCookie情報の引き継ぎ条件をすべて満たす場合は，Set-Cookieヘッダの属性がCookieヘッダに設定されます。

Set-CookieヘッダのCookie名とその値（NAME=VALUE）だけを設定する。

複数のCookie情報がある場合，「;」で区切って設定する。

条件を満たさない場合は，Cookieヘッダに何も設定されません。

Cookie情報の引き継ぎ範囲，引き継ぎ条件，およびログ出力について説明します。また，Cookie情報の引き継ぎに関する注意事項を示します。

(1)　Cookie情報の引き継ぎ範囲

Cookie情報を引き継ぐビジネスプロセスの範囲を次に示します。

初回のサービス呼び出しから，受付アクティビティおよび応答アクティビティを実行するまで

初回のサービス呼び出しから，ビジネスプロセスインスタンスが終了するまで

1.の範囲では，次に示す場合でもCookie情報が引き継がれます。

階層的にビジネスプロセスを呼び出す場合

呼び出し先のビジネスプロセスに受付アクティビティおよび応答アクティビティがあってもCookie情報は引き継がれます。

受付アクティビティが非同期のビジネスプロセスを呼び出す場合

通信モデルが非同期の場合，受付アクティビティで定義したオペレーション名に対する応答アクティビティは配備できません。この場合はサービス呼出アクティビティ間に受付アクティビティがないときだけCookie情報が引き継がれます。

応答アクティビティのあとにアクティビティが定義されているビジネスプロセスを呼び出す場合

この場合は，サービス呼出アクティビティ間に受付アクティビティがないときだけCookie情報が引き継がれます。

待機アクティビティが定義されているビジネスプロセスを呼び出す場合

応答アクティビティが実行されたあとに待機アクティビティがある場合，その待機アクティビティの前後にサービス呼出アクティビティがあっても，Cookie情報は引き継がれます。

ただし，次の場合は引き継ぎ範囲に関係なく，Cookie情報は引き継がれません。

実行環境のプロセスがダウンした場合

複数の実行環境のプロセスでリクエストを処理する場合

プロセスインスタンスを再実行した場合

(2)　Cookie情報の引き継ぎ条件

サービス部品を呼び出すときの情報と呼び出し先の情報に関して，次に示す条件をすべて満たす場合にCookie情報が引き継がれます。

HCSCサーバランタイム定義ファイルのcookie-parsingプロパティにONを指定している，またはSOAPアダプタを呼び出しているサービス呼出アクティビティで，ヘッダ割当変数にCookie情報を設定している。

「サービス部品のホスト名:ポート番号」の文字列が完全一致する。

ホスト名の指定形式が異なっていると，それぞれ別のURLとして扱われます。例えば，同じホストを指定する場合に，ホスト名で指定しているものとIPアドレスで指定しているものが混在しているときは，それぞれ別のURLとして扱われます。このとき，Cookie情報は引き継がれません。また，ポート番号が設定されていない場合は，「:ポート番号」のない文字列で比較されます。

path属性が前方一致する。

前方一致と見なされる場合および見なされない場合の例を示します。

（例）前方一致と見なされる場合

/sapと/sap，/sapと/sap/aaa，/sapと/sapaaa/bbb

（例）前方一致と見なされない場合

/sapと/aaa，/sapと/aaasap/bbb，/sapと/aaa/sap

注意事項

Cookie情報の引き継ぎは，SAP ERP 6.0のSet-Cookieヘッダ仕様の「path属性」によって判断されます。ただし，SOAP通信基盤（SOAP1.1モード）を使用する場合は，「path属性」は考慮されないで，「ホスト名:ポート番号」だけが考慮されます。ポート番号が指定されていない場合はホスト名が考慮されます。

Set-Cookieヘッダにpath属性が含まれていない場合は，デフォルト値として「path=/」が設定されます。

次の例のように，Set-Cookieヘッダに属性名が「path」の属性が複数設定されている場合は，path属性に「path=/」が設定されたものとして動作します。

（例）

　Set-Cookie: NAME=value; path=/sap/aaa; path=/sap/bbb

複数の異なるpath属性値を持つCookie情報をHTTPヘッダに設定する場合，Set-Cookieの読み込み順序に依存しないで，path属性値が詳細な順にHTTPヘッダに設定されます。

例えば，次のSet-Cookieヘッダを受け取った場合，HTTPヘッダには「cookie:NAME3=value3; NAME2=value2; NAME1=value1」が設定されます。

（例）

　Set-Cookie: NAME1=value1; path=/

　Set-Cookie: NAME2=value2; path=/sap

　Set-Cookie: NAME3=value3; path=/sap/aaa

(3)　ログ出力

HCSCサーバランタイム定義ファイルのmethodtrace-levelプロパティに「2」以上の値を設定した場合に，メソッドトレースにログが出力されます。

(4)　注意事項

(a)　サポートしていない仕様および属性について

Netscape Communications社のSet-Cookieヘッダの仕様である「domain属性」，「expires属性」，および「secure属性」は，サポートしていません。

RFC2109のSet-Cookieヘッダの仕様である「Comment属性」，「Domain属性」，「Max-Age属性」，および「Secure属性」は，サポートしていません。

RFC2965でサポートされているSet-Cookie2の仕様は，サポートしていません。

「JSESSIONID」は，サポートしていません。SAP ERP 6.0では，「sap-contextid属性」でセッション管理をしています。

(b)　バージョン属性について

Cookieバージョンは，「0」（Netscape Communication社のSet-Cookie仕様）または「1」（RFC2109のSet-Cookie仕様）だけを設定できます。なお，バージョンは次に示す順序で決定されます。

Set-Cookieヘッダに「expires属性」が定義されている場合，バージョンは0になります。

Set-Cookieヘッダに「Version属性」が定義されている場合，バージョンは1になります。

Set-Cookieヘッダに「Max-Age属性」が定義されている場合，バージョンは1になります。

1〜3のどれにも当てはまらない場合，バージョンは0になります。

SAP ERP 6.0が発行するSet-Cookieヘッダには「Version属性」は含まれません。

「Version属性」が複数のCookie情報で異なる場合は，最初に読み込んだCookie情報が持つ「Version属性」の値が採用されます。

RFC2109でサポートしているCookie仕様で動作を行う場合，「Version属性」の設定値をCookieヘッダの「cookie-version属性」に設定する必要があります。

2.2.5　Webサービス（SOAP通信）の場合のHTTPヘッダ引き継ぎ

HTTPヘッダ引き継ぎ機能とは，同一のビジネスプロセス内で，SAP ERP 6.0上の異なるサービスを実行した場合に取得したHTTPヘッダを引き継ぐ機能です。SAP ERP 6.0以外のサービスを呼び出す場合，この機能は必要ありません。

(1)　HTTPヘッダ引き継ぎ機能の概要

HTTPヘッダ引き継ぎ機能の概要を次の図に示します。

図2‒16　HTTPヘッダ引き継ぎ機能の概要

(2)　HTTPヘッダ引き継ぎ機能の引き継ぎ方法

HTTPヘッダやCookie情報を，サービス呼出アクティビティのヘッダ領域に割り当てることで引き継げます。ヘッダ領域への割り当て方法の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「付録F　サービスアダプタを利用したHTTPヘッダおよびCookie情報の引き継ぎ」を参照してください。

(3)　HTTPヘッダ引き継ぎ機能の引き継ぎ情報の範囲

HCSCサーバランタイム定義ファイルのcookie-parsingプロパティの値と，サービス呼出アクティビティのヘッダ領域に情報を割り当てるかどうかによって，引き継がれる情報が異なります。

なお，Cookie情報を送受信するサービス部品のホスト名，IPアドレス，またはpath属性が一致しない場合は，Cookie情報を送信しません。

HCSCサーバランタイム定義ファイルのcookie-parsingプロパティをON，かつヘッダ割当変数にCookie情報を設定していない場合

すべてのCookie情報が引き継がれます。サービス部品呼び出し1で取得した情報がサービス部品呼び出し2に引き継がれます。

引き継ぎの内容を次の図に示します。

図2‒17　HCSCサーバランタイム定義ファイルのcookie-parsingプロパティをON，かつヘッダ割当変数にCookie情報を設定していない場合の引き継ぎ内容

HCSCサーバランタイム定義ファイルのcookie-parsingプロパティをOFF，かつヘッダ割当変数にCookie情報を設定している場合

ヘッダ領域に設定されたCookie情報がサービス部品呼び出し2の実行で引き継がれます。ただし，サービス部品呼び出し2に情報は返却されません。

引き継ぎの内容を次の図に示します。

図2‒18　HCSCサーバランタイム定義ファイルのcookie-parsingプロパティをOFF，かつヘッダ割当変数にCookie情報を設定している場合の引き継ぎ内容

HCSCサーバランタイム定義ファイルのcookie-parsingプロパティをON，かつヘッダ割当変数にCookie情報を設定している場合

name属性，path属性，およびhost属性が同じであるCookie情報がヘッダ領域に設定されたときは，サービス部品呼び出し1の実行で取得したCookie情報がヘッダ領域に設定されたCookie情報に書き換えられ，サービス部品呼び出し2の実行で引き継がれます。

ただし，name属性が同じでも，path属性またはhost属性が異なる場合は，サービス部品呼び出し1で取得したCookie情報とヘッダ領域に設定されたCookie情報がサービス部品呼び出し2の実行で引き継がれます。

引き継ぎの内容を次の図に示します。

図2‒19　HCSCサーバランタイム定義ファイルのcookie-parsingプロパティをON，かつヘッダ割当変数にCookie情報を設定している場合の引き継ぎ内容

2.2.6　Webサービス（SOAP通信）の場合のSOAPメッセージの構成

Webサービス（SOAP通信）の場合，要求電文および応答電文としてやり取りしているSOAPメッセージは，ヘッダ（SOAPヘッダ）とボディ（SOAPボディ）で構成されています。SOAPヘッダにはメッセージの付加的な情報（識別情報など）が含まれ，SOAPボディにはメッセージ本体が含まれています。

SOAPメッセージの構成例を次の図に示します。

図2‒20　SOAPメッセージの構成例

(1)　SOAPメッセージとビジネスプロセスの関係

SOAPメッセージの場合，要求電文のヘッダ情報とボディ情報は，業務処理で利用できるようにビジネスプロセスの変数に割り当てられます。また，応答電文として返されるときは，変数から再びヘッダ情報とボディ情報を生成します。

SOAPメッセージとビジネスプロセスの関係を次の図に示します。

図2‒21　SOAPメッセージとビジネスプロセスの関係

図中の1.〜5.について説明します。

説明

サービスリクエスタから受付に対して，業務処理に必要なパラメタを設定した要求電文（SOAPメッセージ）が渡されます。

受付からビジネスプロセスが起動されます。このとき，受付が受信したSOAPメッセージに設定されているヘッダ情報およびボディ情報を，業務処理で利用できるようにビジネスプロセスの変数に割り当てます。

ビジネスプロセスが業務処理を実行します。サービスを呼び出すときは，変数からサービスの実行に必要なパラメタを設定したSOAPメッセージを生成し，サービスアダプタ経由でサービス部品に送信します。

サービス部品は処理が終わると，その結果を応答電文（SOAPメッセージ）として返します。ビジネスプロセスはサービスアダプタ経由でこのSOAPメッセージを受け取り，ヘッダやボディの情報を再び変数に割り当てます。

ビジネスプロセスの処理が終わると，変数からSOAPメッセージを生成し，受付を経由してサービスリクエスタに結果を返します。

(2)　ユーザ電文トレースに出力されるSOAPメッセージの情報

SOAPメッセージの場合，ユーザ電文トレースデータにはユーザ電文に含まれる次の情報が出力されます。

soap:Header要素を含む複数の子要素

soap:Body要素の1つの子要素

なお，soap:Header要素が存在しない場合は，soap:Body要素の子要素だけが情報として出力されます。

また，次の場合は動作が保証されませんので，要求電文を作成するときに注意が必要です。

SOAPHeader配下の子要素に，ユーザ定義受付に指定された名前空間と要素名を持つ子要素が入れ子になっている場合

SOAPBody配下の子要素に，オペレーション名が同一の子要素が複数設定された場合

soap:Header要素およびsoap:Body要素については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「2.6.1　Webサービスを利用したサービス部品の適用範囲」を参照してください。

2.2.7　Webサービス（SOAP通信）の場合の接続先動的変更

SOAPアダプタの通信先は，ビジネスプロセスで設定した接続先URLを使って動的に変更できます。ビジネスプロセスで接続先URLを設定しておくと，サービスアダプタを実行したときに通信先が変更されます。これにより，作成するサービスアダプタの数を削減できます。

なお，ビジネスプロセスで接続先URLを設定しなかった場合は，開発環境で設定したWebサービスの接続先URLでSOAP通信を行います。

(1)　接続先動的変更の処理の流れ

通信基盤ごとの，SOAP通信時の接続先動的変更の処理の流れを次に説明します。

(a)　SOAP通信基盤を使用するとき

通信基盤にSOAP通信基盤を使用するときの接続先動的変更の処理の流れを次の図に示します。

図2‒22　通信基盤にSOAP通信基盤を使用するときの接続先動的変更の処理の流れ

説明

図中の番号は，次の説明の番号と対応しています。

要求電文内のヘッダ電文から接続先URLを取得します。

要求電文の情報を基にSOAPメッセージを作成します。

取得した接続先URLでサービスと通信を行います。

(b)　JAX-WSエンジンを使用するとき

通信基盤にJAX-WSエンジンを使用するときの接続先動的変更の処理の流れを次の図に示します。

図2‒23　通信基盤にJAX-WSエンジンを使用するときの接続先動的変更の処理の流れ

説明

図中の番号は，次の説明の番号と対応しています。

要求電文内のヘッダ電文から接続先URLを取得します。

要求電文の情報を基にSOAPメッセージを作成します。

接続先URLを設定します。

設定した接続先URLのサービスと通信を行います。

(2)　接続先情報を動的に変更する例

接続先情報ファイルを使用して，接続先情報を動的に変更する例を説明します。

(a)　ビジネスプロセスの例

接続先情報ファイルを使用するビジネスプロセスの例を次の図に示します。

図2‒24　接続先情報ファイルを使用するビジネスプロセスの例（SOAPアダプタの場合）

サービスリクエスタがビジネスプロセスにサービス部品の実行を要求します。

サービスリクエスタから送付する要求電文内のヘッダ電文に接続先URLを設定します。

ビジネスプロセスはXMLの要求電文を受付アクティビティで受け取ります。

ビジネスプロセスがヘッダ要求データおよび要求データを生成します。

ヘッダ要求データの接続先URLを，データ変換アクティビティなどで接続先URL変数に設定します。

ビジネスプロセスは接続先URL変数から接続先URLを取得して，サービス部品を呼び出します。

ビジネスプロセスが，サービス部品の実行結果をXMLの応答電文として構成し，応答アクティビティで返します。

サービスリクエスタへの応答が返されます。

サービスリクエスタへの応答では，XMLの応答電文が送付されます。

(3)　ユーザ定義受付を生成するWSDLの作成例

ユーザ定義受付を生成するWSDLの作成例を次に示します。

なお，この例では，接続先となるサービス部品のURLをSOAPヘッダで送付しています。

(a)　データ変換アクティビティの設定例

「図2-24　接続先情報ファイルを使用するビジネスプロセスの例（SOAPアダプタの場合）」に示すビジネスプロセスで使用するデータ変換アクティビティの設定例を次に示します。

ここでは，変換元に「ヘッダ要求データ」を，変換先に「接続先URL」を指定しています。

図2‒25　データ変換アクティビティの設定例（SOAPアダプタの場合）

また，変換のマッピングは，次の図に示すとおりに定義します。

図2‒26　変換のマッピングの設定例（SOAPアダプタの場合）

(b)　接続先情報ファイルの定義

Webサービスに接続するためのURLをサービスアダプタに設定するための接続先情報ファイル（XMLスキーマ）に定義します。

サービスプラットフォームでは，接続先情報ファイルを提供しています。

接続先情報ファイルの格納先

<サービスプラットフォームのインストールディレクトリ>/CSC/schema/connection/connection_soap_adapter.xsd

注意事項

SOAPアダプタの接続先情報を動的に変更する場合，サービスプラットフォームで提供している接続先情報ファイルを使用してください。提供している接続先情報ファイルを使用しなかった場合，動作は保証されません。

接続先情報ファイルの形式

<?xml version="1.0" encoding="UTF-8"?>
<!--
 DO NOT EDIT THIS FILE.
 -->
<xsd:schema
    elementFormDefault="qualified"
    targetNamespace="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/connection/change/soap"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="soapAddress">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="endpointURL" type="xsd:string"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

設定できる要素

endpointURL　〜＜文字列＞

サービス部品の接続先URLを指定します。

(c)　接続先情報の設定

「図2-24　接続先情報ファイルを使用するビジネスプロセスの例（SOAPアダプタの場合）」に示すビジネスプロセスで使用する接続先情報の設定例を次に示します。なお，接続先情報は，サービス呼出アクティビティのヘッダ割当変数に設定します。ここで設定した情報が，SOAPアダプタで参照できる情報になります。

図2‒27　接続先情報の設定例（サービス呼出アクティビティの設定）

(4)　注意事項

ベーシック認証の利用可否，およびベーシック認証で利用するユーザIDとパスワードについては，接続先URLを使って動的に変更できません。ベーシック認証に関する情報は，開発環境の画面から設定した情報が有効となります。

次の場合，エラーメッセージが出力されて異常終了します。

開発環境で複数の接続先情報がヘッダ割当変数に設定された場合

XMLデータのシステム固有の名前空間，要素名が複数存在すると，接続先が特定できないためエラーになります。

設定された接続先情報が不正な場合

接続先URLに誤りがあると，サービス呼び出し時にエラーになります。

接続先情報を示すXMLデータのendpointURL要素が存在しない場合

endpointURL要素がない場合，接続先が特定できないためエラーになります。

2.2.8　Webサービス（SOAP通信）の場合の添付ファイル

添付ファイル機能を使用すると，任意の形式のファイル（CSVファイルなど）をWebサービスで扱えます。

(1)　添付ファイル機能の概要

添付ファイル機能では作業フォルダまたは共通フォルダを使用して，システム間のファイル転送を中継します。作業フォルダおよび共通フォルダの詳細については「10.　作業フォルダおよび共通フォルダの機能」を参照してください。

添付ファイル機能の概要を次の図に示します。

図2‒28　添付ファイル機能の概要

(a)　添付ファイルのWSDL

添付ファイル機能を使用する場合，WS-I Attachments Profile - Version 1.0で規定された形式に基づいて記述されたswaRef形式のWSDLを使用します。swaRef形式のWSDLの例を次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://localhost"
  xmlns:wsi="http://ws-i.org/profiles/basic/1.1/xsd" ...>
  <wsdl:types>
    <schema elementFormDefault="qualified" targetNamespace="http://localhost"
      xmlns="http://www.w3.org/2001/XMLSchema">
      <import namespace="http://ws-i.org/profiles/basic/1.1/xsd" schemaLocation="swaref.xsd"/>
      <element name="getUserData">
        <complexType>
          <sequence>
            <element name="filename" type="xsd:string"/>
            <element name="attachment" type="wsi:swaRef"/>
          </sequence>
        </complexType>
      </element>
       ...
    </schema>
  </wsdl:types>
  <wsdl:message name="getUserDataRequest">
    <wsdl:part element="intf:getUserData" name="parameters"/>
  </wsdl:message>
  ...
  <wsdl:portType name="UserInfo">
    <wsdl:operation name="getUserData">
      <wsdl:input message="intf:getUserDataRequest" name="getUserDataRequest"/>
      ...
    </wsdl:operation>
  </wsdl:portType>
  ...
</wsdl:definitions>

(b)　添付ファイル付きSOAPメッセージの構造

添付ファイル付きSOAPメッセージは，SOAP Message with Attachmentsプロトコルを使用し，MIME Multiple/Related構造でエンコードされます。メッセージの構造の詳細はマニュアル「アプリケーションサーバ Webサービス開発ガイド」の「28.4　添付ファイル付きSOAPメッセージ（wsi:swaRef形式）」を参照してください。

(c)　添付ファイル機能で使用するスキーマ

SOAP受付とビジネスプロセスの間，およびビジネスプロセスとSOAPアダプタの間で添付ファイルの情報を連携するために使用する電文フォーマットについて説明します。

urecp_soap_attachment_request.xsd

SOAP受付で生成された添付ファイルに関するXML電文をビジネスプロセスで扱うために使用する電文フォーマットです。スキーマは「<サービスプラットフォームのインストールディレクトリ>¥CSC¥schema¥soaprecp¥urecp_soap_attachment_request.xsd」に格納されています。

名前空間名は「http://www.hitachi.co.jp/soft/xml/cosminexus/csc/reception/attachment/soap/request」です。

表2‒1　SOAP受付のファイル連携用要求ヘッダフォーマット

タグ名

種別

出現回数

説明

<attachment-request>

−

1回

−

<request-id>

string

1回

受付で作成したリクエストIDを示すタグです。

<files>

−

0または1回

受け付けた添付ファイルを示すタグです。ファイルを受信した場合に出現します。

<file>

−

0回以上

受け付けた1つの添付ファイルを示すタグです。受信したファイルの数と同じ回数出現します。

<content-id>

string

1回

受け付けた添付ファイルのContent-Idを示すタグです。

Content-Idが設定されていない場合，またはnullの場合はSOAP受付でエラーになります。

<content-type>

string

1回

受け付けた添付ファイルのContent-Typeを示すタグです。

charset属性には，Content-Typeヘッダのcharsetパラメタに対応する文字コードが設定されます。

<local-file-name>

string

1回

作業フォルダに出力した添付ファイルの中間ファイル名を示すタグです。

urecp_soap_attachment_response.xsd

SOAP受付からサービスリクエスタに応答する添付ファイルの情報をビジネスプロセスからSOAP受付に渡すために使用します。スキーマは「<サービスプラットフォームのインストールディレクトリ>¥CSC¥schema¥soaprecp¥urecp_soap_attachment_response.xsd」に格納されています。

名前空間名は「http://www.hitachi.co.jp/soft/xml/cosminexus/csc/reception/attachment/soap/response」です。

表2‒2　SOAP受付のファイル連携用応答ヘッダフォーマット

タグ名

種別

出現回数

説明

<attachment-response>

−

1回

−

<files>

−

0または1回

応答する添付ファイルを示すタグです。

<file>

−

0回以上

応答する1つの添付ファイルを示すタグです。

<content-id>

string

1回

応答する添付ファイルのContent-Idヘッダを指定します。

値が設定されていない場合，またはnullが設定された場合はエラーになります。

<content-type>

string

0または1回

応答する添付ファイルのContent-Typeヘッダを指定します。

charset属性には，Content-Typeヘッダのcharsetパラメタに対応する文字コードを指定します。

省略した場合，または値が空の場合は，"application/octet-stream"になります。

<local-file-name>

string

1回

作業フォルダ内の中間ファイル名を指定します。

次の場合はエラーになります。

パス変更に関連する指定（"/../"など）が含まれる場合

指定したファイル名が不正な場合

adpsoap_attachment_request.xsd

ビジネスプロセスからSOAPアダプタに添付ファイルに関する情報を渡すために使用します。スキーマは「<サービスプラットフォームのインストールディレクトリ>¥CSC¥schema¥soap¥adpsoap_attachment_request.xsd」に格納されています。

名前空間名は「http://www.hitachi.co.jp/soft/xml/cosminexus/csc/adapter/attachment/soap/request」です。

表2‒3　SOAPアダプタのファイル連携用要求ヘッダフォーマット

タグ名

種別

出現回数

説明

<attachment-request>

−

1回

−

<request-id>

string

0または1回

受付で生成されたリクエストIDを設定します。

作業フォルダ内のファイルデータを送信する場合，またはSOAPレスポンス時にダウンロードファイルを出力するファイルとして，作業フォルダを使用する場合に設定が必要です。

<files>

−

0または1回

SOAPリクエストで送信するファイル情報を指定します。

<file>

−

0回以上

送信する1つのファイルに関する情報を指定します。

<content-id>

string

1回

送信する添付ファイルのContent-Idヘッダの値を指定します。

値が設定されていない場合，またはnullが設定された場合はエラーになります。

<content-type>

string

0または1回

送信する添付ファイルのContent-Typeヘッダの値を指定します。

charset属性には，Content-Typeヘッダのcharsetパラメタに対応する文字コードを指定します。

省略した場合，または値が空の場合は，local-file-name要素に指定したファイルの拡張子によって自動的に設定されます。なお，システムによって自動生成された中間ファイルの場合，拡張子がないため"application/octet-stream"が設定されます。設定される値の詳細についてはマニュアル「アプリケーションサーバ Webサービス開発ガイド」の「28.4.2　添付ファイルからSOAPメッセージへのマッピングの注意事項（wsi:swaRef形式）」を参照してください。

<input-folder-name>

string

1回

送信対象ファイルが格納されているフォルダとして，次のどちらかを指定します。

作業フォルダの場合

空文字を指定します。

共通フォルダの場合

共通フォルダ定義名を指定します。

また，common属性には，送信対象ファイルが存在するフォルダを識別するための次の値を指定します。

作業フォルダの場合

「common="false"」を指定します。

共通フォルダの場合

「common="true"」を指定します。

なお，共通フォルダ定義名が示すフォルダが不正な場合は読み込み時にエラーになります。

<local-file-name>

string

1回

送信対象のファイル名を指定します。シンボリックリンクのファイルは指定しないでください。

input-folder-name要素で作業フォルダを指定した場合

作業フォルダ内の中間ファイル名を指定します。

input-folder-name要素で共通フォルダを指定した場合

共通フォルダルート配下のファイル名を相対パスで指定します。

また，次の場合はエラーが発生します。

指定した名称のファイルが存在しない場合

パス変更に関係する指定（"/../"など）が含まれる場合

指定したファイル名が不正な場合

<output-folder-name>

string

0または1回

SOAPレスポンス時にダウンロードファイルを出力するフォルダとして，次のどちらかを指定します。

作業フォルダの場合

空文字を指定します。

共通フォルダの場合

共通フォルダ定義名を指定します。

また，common属性には，ダウンロードファイルを出力するフォルダを識別するための次の値を指定します。

作業フォルダの場合

「common="false"」を指定します。

共通フォルダの場合

「common="true"」を指定します。

なお，共通フォルダ定義名が示すフォルダが不正な場合は書き込み時にエラーが発生します。

<output-sub-folder>

string

0または1回

SOAPレスポンス時にダウンロードファイルを出力するフォルダとして，共通フォルダのサブフォルダを使用する場合に共通フォルダからの相対パスを指定します。

output-folder-name要素で作業フォルダを指定した場合は，この要素の値は無視されます。

なお，指定されたサブフォルダが不正な場合は書き込み時にエラーが発生します。

adpsoap_attachment_response.xsd

SOAPアダプタで生成された添付ファイルに関するXML電文をビジネスプロセスで扱うために使用します。スキーマは「<サービスプラットフォームのインストールディレクトリ>¥CSC¥schema¥soap¥adpsoap_attachment_response.xsd」に格納されています。

名前空間名は「http://www.hitachi.co.jp/soft/xml/cosminexus/csc/adapter/attachment/soap/response」です。

表2‒4　SOAPアダプタのファイル連携用応答ヘッダフォーマット

タグ名

種別

出現回数

説明

<attachment-response>

−

1回

−

<request-id>

string

0または1回

adpsoap_attachment_request.xsdのrequest-id要素に指定した値が設定されます。

ダウンロードファイルを作業フォルダに出力した場合に出現します。

<files>

−

0または1回

SOAPレスポンスで受信したファイル情報が設定されます。

<file>

−

0回以上

受信した1つのファイルに関する情報が設定されます。

<content-id>

string

1回

受信した添付ファイルのContent-Idヘッダの値が設定されます。

Content-Idが設定されていない場合，またはnullの場合はSOAPアダプタでエラーになります。

<content-type>

string

1回

受信した添付ファイルのContent-Typeヘッダの値が設定されます。

charset属性には，Content-Typeヘッダのcharsetパラメタに対応する文字コードが設定されます。

output-folder-name

string

1回

adpsoap_attachment_request.xsdのoutput-folder-name要素に指定した値が設定されます。

<local-file-name>

string

1回

作業フォルダまたは共通フォルダに出力されたファイル名が設定されます。

出力フォルダが共通フォルダの場合

一意となる名称で出力されたファイル名が設定されます。また，adpsoap_attachment_request.xsdでoutput-sub-folder要素が指定されていた場合は，サブフォルダのパス＋"/"＋ファイル名が設定されます。

出力フォルダが作業フォルダの場合

出力された中間ファイル名が設定されます。

(2)　アップロード

Webサービスの添付ファイル機能ではSOAP受付およびSOAPアダプタを利用してファイルのアップロードができます。

サービスリクエスタからSOAP受付に対して添付ファイル付きSOAPメッセージを送信すると，SOAP受付で作業フォルダが生成され添付ファイルが格納されます。作業フォルダに格納されたファイルをどう扱うかはビジネスプロセスで定義します。

作業フォルダまたは共通フォルダに格納されているファイルは，SOAPアダプタを利用することでWebサービスに対して送信できます。SOAPアダプタからWebサービスに対してファイルを送信するための設定はビジネスプロセスで定義します。

ここではサービスリクエスタから送信された添付ファイルをビジネスプロセスで扱うための設定方法，およびWebサービスに添付ファイルを送信するためのビジネスプロセスの設定方法を説明します。

(a)　受付アクティビティ

サービスリクエスタから送信され，作業フォルダに格納されたファイルをビジネスプロセスで扱うには，urecp_soap_attachment_request.xsdのスキーマを指定して定義した変数を，ビジネスプロセスの受付アクティビティでヘッダ割当変数に設定します。

SOAP受付に添付ファイル付きSOAPメッセージを送信した場合にSOAP受付で作成される電文の例を次に示します。

<attachment-request xmlns="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/reception/attachment/soap/request">
  <request-id>RCP01---01020003000420110102140305012000/HCSC</request-id>
  <files>
    <file>
      <content-id>d1cd6fed-368c-4966-9a20-375a120b3c05@jaxws.cosminexus.com</content-id>
      <content-type charset="UTF-8">text/plain</content-type>
      <local-file-name>csc_8216969970665213344</local-file-name>
    </file>
  </files>
</attachment-request>

(b)　サービス呼出アクティビティ

SOAPアダプタを使って作業フォルダまたは共通フォルダに格納されているファイルをアップロードするには，adpsoap_attachment_request.xsdのスキーマを指定して定義した変数を，ビジネスプロセスのサービス呼出アクティビティで要求電文のヘッダ割当変数に設定します。

SOAPアダプタから添付ファイル付きSOAPメッセージを送信する場合に，ビジネスプロセスのデータ変換アクティビティで作成する電文の例を次に示します。

作業フォルダを使用する場合

<attachment-request xmlns="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/adapter/attachment/soap/request">
  <request-id>RCP01---01020003000420110102140305012000/HCSC</request-id>
  <files>
    <file>
      <content-id>459d752f-5694-493b-9671-4d49af688cd8@jaxws.cosminexus.com</content-id>
      <content-type charset="UTF-8">text/plain</content-type>
      <input-folder-name common="false"/>
      <local-file-name>csc_8216969970665213344</local-file-name>
    </file>
  </files>
</attachment-request>

共通フォルダを使用する場合

<attachment-request xmlns="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/adapter/attachment/soap/request">
  <files>
    <file>
      <content-id>459d752f-5694-493b-9671-4d49af688cd8@jaxws.cosminexus.com</content-id>
      <content-type charset="UTF-8">text/plain</content-type>
      <input-folder-name common="true">com001</input-folder-name>
      <local-file-name>sample.txt</local-file-name>
    </file>
  </files>
</attachment-request>

(3)　ダウンロード

Webサービスの添付ファイル機能ではSOAP受付およびSOAPアダプタを利用してファイルのダウンロードができます。

SOAP受付定義ファイルのurecp-soap.switchover.file-transfer.modeで作業フォルダの生成の有無を設定できます。SOAP受付定義ファイルの詳細についてはマニュアル「サービスプラットフォーム リファレンス」の「3.6.1　SOAP受付定義ファイル」を参照してください。

ダウンロードする場合は次のケースを除きurecp-soap.switchover.file-transfer.modeにtrueを設定してください。trueを設定しないと作業フォルダが生成されず，エラーになります。

共通フォルダを使用する

1つのリクエストでサービスリクエスタからのアップロードも実施する

WebサービスからSOAPアダプタに対して添付ファイル付きSOAPメッセージを送信すると，作業フォルダまたは共通フォルダに添付ファイルが格納されます。添付ファイルを作業フォルダに格納するか共通フォルダに格納するか，また格納されたファイルをどう扱うかはビジネスプロセスで定義します。

作業フォルダに格納されているファイルは，SOAP受付を利用することでサービスリクエスタに対して送信できます。SOAP受付からサービスリクエスタに対してファイルを送信するための設定はビジネスプロセスで定義します。

ここではWebサービスから受信した添付ファイルをビジネスプロセスで扱うための設定方法，およびサービスリクエスタに添付ファイルを送信するためのビジネスプロセスの設定方法を説明します。

(a)　受付アクティビティ

作業フォルダを使用する場合，SOAP受付で生成されたリクエストIDをビジネスプロセスで扱うには，urecp_soap_attachment_response.xsdのスキーマを指定して定義した変数を，ビジネスプロセスの受付アクティビティでヘッダ割当変数に設定します。

SOAP受付で作業フォルダおよびリクエストIDを生成した場合にSOAP受付で作成される電文の例を次に示します。

<attachment-request xmlns="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/reception/attachment/soap/request">
  <request-id>RCP01---01020003000420110102140305012000/HCSC</request-id>
</attachment-request>

(b)　サービス呼出アクティビティ

Webサービスから送信された添付ファイルをビジネスプロセスで扱うには，adpsoap_attachment_request.xsdのスキーマを指定して定義した変数を，ビジネスプロセスのサービス呼出アクティビティで要求電文のヘッダ割当変数に設定して，adpsoap_attachment_response.xsdのスキーマを指定して定義した変数を，ビジネスプロセスのサービス呼出アクティビティで応答電文のヘッダ割当変数に設定します。

SOAPアダプタで添付ファイル付きSOAPメッセージを受信する場合に，ビジネスプロセスのデータ変換アクティビティで作成する電文の例を次に示します。

作業フォルダを使用する場合

<attachment-request xmlns="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/adapter/attachment/soap/request">
  <request-id>RCP01---01020003000420110102140305012000/HCSC</request-id>
  <output-folder-name common="false"/>
</attachment-request>

共通フォルダを使用する場合

<attachment-request xmlns="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/adapter/attachment/soap/request">
  <output-folder-name common="true">com002</output-folder-name>
  <output-sub-folder>test01</output-sub-folder>
</attachment-request>

SOAPアダプタが添付ファイル付きSOAPメッセージを受信した場合に，SOAPアダプタで作成される電文の例を次に示します。

作業フォルダを使用する場合

<attachment-response xmlns="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/adapter/attachment/soap/response">
  <request-id>RCP01---01020003000420110102140305012000/HCSC</request-id>
  <files>
    <file>
      <content-id>459d752f-5694-493b-9671-4d49af688cd8@jaxws.cosminexus.com</content-id>
      <content-type charset="UTF-8">text/plain</content-type>
      <output-folder-name common="false"/>
      <local-file-name>csc_8216969970665213344</local-file-name>
    </file>
  </files>
</attachment-response>

共通フォルダを使用する場合

<attachment-response xmlns="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/adapter/attachment/soap/response">
  <files>
    <file>
      <content-id>154765f0-9850-4c1f-8f6c-3f1f9306b4c0@jaxws.cosminexus.com</content-id>
      <content-type charset="UTF-8">text/plain</content-type>
      <output-folder-name common="true">com002</output-folder-name>
      <local-file-name>test01/HCSCCLS1----HCSC1---1------------d6j93dx74g---1---</local-file-name>
    </file>
  </files>
</attachment-response>

(c)　応答アクティビティ

作業フォルダに格納されている中間ファイルをサービスリクエスタに応答するには，urecp_soap_attachment_response.xsdのスキーマを指定して定義した変数を，ビジネスプロセスの応答アクティビティでヘッダ割当変数に設定します。

SOAP受付から添付ファイル付きSOAPメッセージを送信する場合に，ビジネスプロセスのデータ変換アクティビティで作成する電文の例を次に示します。

<attachment-response xmlns="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/reception/attachment/soap/response">
  <files>
    <file>
      <content-id>d1cd6fed-368c-4966-9a20-375a120b3c05@jaxws.cosminexus.com</content-id>
      <content-type charset="UTF-8">text/plain</content-type>
      <local-file-name>csc_8216969970665213344</local-file-name>
    </file>
  </files>
</attachment-response>

(4)　注意事項

添付ファイル機能の注意事項について説明します。また，マニュアル「アプリケーションサーバ Webサービス開発ガイド」も合わせてご確認ください。

(a)　作業フォルダ使用時の注意事項

作業フォルダ内のファイルはcscfswrmコマンドによって定期的に削除する必要があります。なお，リクエスト処理完了直後は削除できない場合があるため，削除できなかった場合は少し時間を空けてから再度削除を実施してください。

(b)　添付ファイルのMIMEヘッダ

添付ファイルのMIMEヘッダに設定されているContent-Id,，Content-Type以外のヘッダは無視されます。添付ファイルに関する情報（ファイル名など）を送受信する際は，SOAPボディなどに設定してください。

(c)　添付ファイル使用時のメモリ使用量

添付ファイル機能を使用する場合，添付ファイルのサイズに応じてメモリ使用量が増大します。詳細はマニュアル「アプリケーションサーバ Webサービス開発ガイド」の「付録C.3　添付ファイル使用時の1リクエスト当たりのメモリ使用量」を参照してください。

2.3　SessionBeanを使用したサービスとの接続

2.3.1　アプリケーションサーバ（EJBコンテナ）との関係

実行環境のHCSCサーバは，アプリケーションサーバのEJBコンテナ上で動作します。

HCSCサーバのリクエスト受付は，EJB（Stateless Session Bean）のリモートインターフェースとして提供され，RMI-IIOPで接続します。

HCSCサーバのサービスアダプタからは，EJB（Stateless Session BeanまたはStateful Session Bean）で作成されたサービス部品が実行されます。アプリケーションサーバ（EJBコンテナ）との関係を次の図に示します。

図2‒29　アプリケーションサーバ（EJBコンテナ）との関係

2.3.2　サービス部品呼び出し時のユーザ電文とサービス部品のスタブとの関係

SessionBean使用時のユーザ電文とスタブの関係を次の図に示します。

図2‒30　SessionBean使用時のユーザ電文とスタブの関係

サービスアダプタを定義するときは，サービス部品のスタブを定義します（サービス部品のスタブには，作成したサービス部品のユーザクラスが含まれています。また，要求電文，応答電文および例外の形式が定義されています）。

サービス部品側のJ2EEサーバにアプリケーションサーバを使用している場合，サービス部品のスタブを取得するには，J2EEサーバのcjgetstubsjarコマンドを使用します。

サービスリクエスタからサービス部品を呼び出すときは，製品提供のスタブを使用します。製品提供のスタブは，標準受付（SessionBean）のインターフェースになっています。サービスリクエスタから標準受付（SessionBean）を呼び出すときには，サービス部品側の電文フォーマットに合わせた要求電文を事前に作成し，標準受付（SessionBean）のパラメタ（ユーザ電文のパラメタ）に設定して実行します。

サービスリクエスタからビジネスプロセスを呼び出すときは，要求電文はビジネスプロセスの受付アクティビティに定義した電文フォーマットになります。サービスリクエスタ内で，ビジネスプロセスの受付アクティビティで定義されている要求電文の電文フォーマットに合わせた電文を作成し，作成した電文を標準受付（SessionBean）のパラメタ（ユーザ電文のパラメタ）に設定して実行します。

サービスリクエスタへの応答は，サービスアダプタで定義した応答電文の電文フォーマットを使用します。

cjgetstubsjarコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjgetstubsjar（アプリケーションのRMI-IIOPスタブおよびインタフェースの取得）」を参照してください。

2.3.3　SessionBean使用時のトランザクション

SessionBean使用時のトランザクションを次の図に示します。

図2‒31　SessionBean使用時のトランザクション

SessionBean使用時，HCSCサーバ内はCMT（Container Managed Transaction）で動作します。また，標準受付（SessionBean）のトランザクション属性はRequired属性です。そのため，サービスリクエスタがトランザクションスコープ内でHCSCサーバの標準受付（SessionBean）を呼び出したとき，トランザクションコンテキストがHCSCサーバ側に引き継がれ，HCSCサーバ内の処理はサービスリクエスタ側のトランザクションスコープ内に入ります。また，サービスリクエスタがトランザクションスコープ外でHCSCサーバの標準受付（SessionBean）を呼び出したとき，HCSCサーバ側で新しいトランザクションが開始されます。

なお，サービス部品のトランザクション属性はRequiresNewまたはNotSupportedでなければなりません。そのため，トランザクションは，サービス部品側には引き継がれません。SessionBeanを利用したサービス部品のトランザクション属性を指定できるかどうかについては，マニュアル「サービスプラットフォーム開発ガイド 基本開発編」の「2.6.2　SessionBeanを利用したサービス部品の適用範囲」を参照してください。

ビジネスプロセスはBMT（Bean Managed Transaction）で動作します。ビジネスプロセス自体は新たなトランザクションで制御します。ビジネスプロセスを呼び出す場合は，ビジネスプロセスのサービス呼出アクティビティに定義したサービス部品呼び出し処理ごとに，新たなトランザクションで制御します。そのため，サービスリクエスタがトランザクションスコープ内でHCSCサーバの標準受付（SessionBean）を呼び出したときでも，トランザクションはサービスアダプタまで引き継がれません。ビジネスプロセスを介した場合のトランザクションを次の図に示します。

図2‒32　ビジネスプロセスを介した場合のトランザクション

永続化するビジネスプロセスの場合，ビジネスプロセスを実行する過程でのトランザクションについては，「3.4　ビジネスプロセスのトランザクション」を参照してください。

2.3.4　SessionBeanアダプタ使用時の注意事項

ネーミングのキャッシングを有効（ON）にした環境でSessionBeanサービスを再起動すると，再起動後の初回のSessionBeanサービス呼び出し時にKDEC03002-Eのメッセージを出力してエラーとなる場合があります。このエラーを回避するには，次の対処をしてください。

参照系システムの場合：EJBホームオブジェクトへの再接続機能を有効にしてください。

参照系以外のシステムの場合：HCSCサーバを再起動してください。

2.4　WS-R（WS-Reliability）を使用したサービスとの接続

2.4.1　Reliable Messagingとの関係

非同期のサービス部品を呼び出すには，Reliable Messagingを使用します。また，サービスリクエスタ側の転送キューとHCSCサーバ側のローカルキューの間，そしてHCSCサーバ側の転送キューとサービス部品側のローカルキューの間はWS-R（WS-Reliability）を使用します。Reliable Messagingは，アプリケーションサーバのEJBコンテナ上で動作します。Reliable Messagingとの関係を次の図に示します。

図2‒33　Reliable Messagingとの関係

2.4.2　サービス部品呼び出し時のメッセージの流れ

HCSCサーバの標準受付（MDB（WS-R））は，MDB（Message Driven Bean）で動作し，HCSCサーバ側のローカルキューを監視しています。HCSCサーバ側のローカルキューにメッセージが送信されると，標準受付（MDB（WS-R））はメッセージを取り出してサービス部品を呼び出します。

サービスリクエスタ側の転送キューには，HCSCサーバの宛先アドレスおよび転送先のローカルキューのキュー名を設定します。サービスリクエスタからは，サービスリクエスタ側の転送キューに対して，JMSメッセージを送信して，HCSCサーバの標準受付（MDB（WS-R））を呼び出します。

サービス部品を呼び出すときには，サービスアダプタ側の転送キューに送信します。そして，転送キューは，開発環境のサービスアダプタ定義画面（基本画面のアドレスに指定した転送先のキュー名および詳細画面の宛先URL）で定義したサービス部品側のローカルキューへ送信します。サービス部品をMDBで作成することで，サービス部品側のローカルキューに送信されたメッセージを取り出して処理できます。非同期（MDB（WS-R））の場合の宛先の指定を次の図に示します。

図2‒34　非同期（MDB（WS-R））の場合の宛先の指定

転送キューを作成する手順については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「9.5.2　転送キューを作成する」を参照してください。JMSメッセージを生成する手順については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「9.5.3　JMSメッセージを生成する」を参照してください。

サービスリクエスタからサービス部品を呼び出すときに転送キューに送信するJMSメッセージの形式は，標準受付（MDB（WS-R））のインターフェースになります。

JMSメッセージのペイロード（ヘッダを除いたデータ本体）に設定した内容が，ユーザ電文としてサービス部品に伝わります。そのため，サービスリクエスタから標準受付（MDB（WS-R））を呼び出すときに，サービス部品側の電文フォーマットに合わせた要求電文を事前に作成し，ペイロードに設定してメッセージを送信します。非同期サービス部品呼び出し時のユーザ電文とJMSメッセージの関係を次の図に示します。

図2‒35　非同期サービス部品呼び出し時のユーザ電文とJMSメッセージの関係

サービスリクエスタからビジネスプロセスを呼び出すときは，要求電文はビジネスプロセスの受付アクティビティに定義した電文フォーマットになります。サービスリクエスタ内でビジネスプロセスの受付アクティビティで定義されている要求電文の電文フォーマットに合わせた電文を作成し，ペイロードに設定してメッセージを送信します。ビジネスプロセスを呼び出す場合のユーザ電文とJMSメッセージの関係を次の図に示します。

図2‒36　ビジネスプロセスを呼び出す場合のユーザ電文とJMSメッセージの関係

2.4.3　同期のサービス部品を呼び出す場合の応答電文の扱い

標準受付（MDB（WS-R））は，非同期の要求電文用の標準受付で，基本的にサービス部品からの応答がない場合に使用します。しかし，非同期（MDB（WS-R））の標準受付から同期のサービス部品（WebサービスまたはSessionBeanなど）やビジネスプロセスを要求した場合，同期のサービス部品から応答が返ることがあります。そのため，HCSCサーバでは応答を応答用のキューに送信する手段を提供しています。

応答用のキューを利用するには，HCSCサーバの環境構築時にHCSCサーバ側に転送キュー（応答用のキュー）を作成し，転送キューにサービスリクエスタ側マシンのキュー間転送用Webアプリケーションの宛先アドレスおよび転送先キュー名を指定しておきます。

サービスリクエスタから標準受付（MDB（WS-R））に対してサービス部品の呼び出しを要求するとき，標準受付（MDB（WS-R））のパラメタに作成した転送キュー（応答用のキュー）のキュー名を指定すると，サービス部品からの応答が返ってきたときに，指定されたキューにJMSメッセージが送信されます。

転送キュー（応答用のキュー）に送信されたJMSメッセージは，サービスリクエスタ側のローカルキューに転送されるため，ローカルキューからメッセージを取り出すことで，サービスリクエスタは，サービス部品からの応答電文を取得できます。同期サービス部品を呼び出した場合の応答の扱いを次の図に示します。

図2‒37　同期サービス部品を呼び出した場合の応答の扱い

応答を取り出す方法については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「9.5.8　応答を取り出す」を参照してください。

同期サービス部品でも応答があるかどうかによって，次の表に示すように応答用のキューへメッセージを送信するかどうかが異なります。

なお，サービスリクエスタから応答用のキューのキュー名を指定していても，HCSCサーバ側に指定したキュー名のキューが作られていない場合は，応答用のキューにメッセージは送信できないため，サービス部品の呼び出し処理がエラーになります。

表2‒5　応答用のキューへメッセージを出力する場合

項番

応答用のキューへ出力する場合

応答電文の有無

応答電文がある場合

応答電文がない場合

サービス部品からのユーザ定義例外の場合

ユーザ定義例外以外のエラーの場合

1

呼び出し先のサービス部品が同期サービス部品の場合

（WebService，SessionBeanなど）

ペイロードに応答電文を設定して送信

ペイロードなしのメッセージを送信

ペイロードに応答電文を設定して送信

×※

2

呼び出し先のサービス部品が非同期サービス部品の場合

（MDB（WS-R）およびMDB（DBキュー）など）

×

×

−

×※

3

呼び出し先のサービス部品がビジネスプロセスの場合

ペイロードに応答電文を設定して送信

ペイロードなしのメッセージを送信

ペイロードに応答電文を設定して送信

×※

（凡例）

×：メッセージを送信しません。

−：非同期のサービス部品からユーザ定義例外は存在しないため該当しません。

注※

エラーの情報はログおよびトレースに出力します。

サービスリクエスタからの要求で応答用のキューのキュー名を指定していない場合は，応答電文の内容は破棄されます（応答電文が破棄されると，KDEC00031-Wメッセージが出力されます）。

また，サービスリクエスタ側で相関関係を対応づけるために，サービスリクエスタが指定したJMSプロパティが引き継がれます。引き継がれるヘッダおよびプロパティの詳細については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「9.5.8　応答を取り出す」を参照してください。

2.4.4　MDB（WS-R）使用時のトランザクション

MDB（WS-R）の場合，サービスリクエスタからHCSCサーバの間，そしてサービスアダプタからサービス部品の間は，異なるトランザクションになります。

(1)　非同期のサービスアダプタへメッセージを送信する場合

非同期の標準受付（MDB（WS-R））でサービス部品呼び出し要求を受け付け，非同期のMDB（WS-R）アダプタへメッセージを送信する場合，標準受付（MDB（WS-R））でのローカルキューからのメッセージの取り出しとサービスアダプタでの転送キューへの送信は，1つのトランザクションで処理します。

転送キューへのメッセージ送信が失敗した場合や，指定したサービスアダプタが起動していない場合など，何らかのエラーが発生した場合は，トランザクションをロールバックします。

ロールバックすると，標準受付（MDB（WS-R））で取り出したメッセージが復元され，再度ローカルキューからメッセージを取り出して，サービス部品を呼び出します。受付からサービス部品呼び出しまでが非同期の場合のトランザクションについて次の図に示します。

図2‒38　受付からサービス部品呼び出しまでが非同期の場合のトランザクション

エラーが発生したときの対処方法については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「7.7.3　MDB（WS-R）実行時の障害対策」を参照してください。

(2)　同期のサービスアダプタへメッセージを送信する場合

非同期（MDB（WS-R））の標準受付でサービス部品呼び出し要求を受け付け，同期のサービスアダプタへメッセージを送信する場合，標準受付（MDB（WS-R））でのローカルキューからのメッセージの取り出しからサービスアダプタでのサービス部品呼び出し，および応答が返ってきて応答用のキューへメッセージを送信するまでを，1つのトランザクションで処理します。

転送キューへのメッセージの送信が失敗した場合や，指定したサービスアダプタが起動していない場合，応答用のキューへのメッセージ送信が失敗した場合など，何らかのエラーが発生した場合は，トランザクションをロールバックします。ロールバックすると，標準受付（MDB（WS-R））で取り出したメッセージが復元され，再度ローカルキューからメッセージを取り出して，サービス部品を呼び出します。受付が非同期であるがサービス部品が同期の場合のトランザクションについて次の図に示します。

図2‒39　受付が非同期であるがサービス部品が同期の場合のトランザクション

トランザクションが失敗すると，次のようになります。番号は，図中の番号と対応しています。

転送キューへのメッセージの送信が失敗した場合

サービスアダプタからSOAPでのサービス部品呼び出しが失敗すると，ローカルキューにメッセージが戻り，再度標準受付（MDB（WS-R））でメッセージを取り出します。

指定したサービスアダプタが起動していない場合

指定したサービスアダプタが起動していないと，ローカルキューにメッセージが戻り，再度標準受付（MDB（WS-R））でメッセージを取り出します。

応答用のキューへのメッセージ送信が失敗した場合

応答が返ってきて応答用のキューへのメッセージ送信が失敗すると，ローカルキューにメッセージが戻り，再度標準受付（MDB（WS-R））でメッセージを取り出します。

エラーが発生したときの対処方法については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「7.7.3　MDB（WS-R）実行時の障害対策」を参照してください。

ビジネスプロセスはBMT（Bean Managed Transaction）で動作します。ビジネスプロセス自体は新たなトランザクションで制御します。ビジネスプロセスを呼び出す場合は，ビジネスプロセスのサービス呼出アクティビティに定義したサービス部品呼び出し処理ごとに，新たなトランザクションで制御します。ビジネスプロセスを介した場合のトランザクションについて次の図に示します。

図2‒40　ビジネスプロセスを介した場合のトランザクション

永続化するビジネスプロセスの場合，ビジネスプロセスを実行する過程でのトランザクションについては，「3.4　ビジネスプロセスのトランザクション」を参照してください。

2.4.5　デッドメッセージキュー

HCSCサーバ稼働マシンでのサービス部品の呼び出しがロールバックして，ロールバックの回数（メッセージの配送回数）が最大値に達した場合や，配送回数に無制限の設定をしている場合，そのメッセージはデッドメッセージキューに遷移します。

エラーが発生したときにデッドメッセージキューに遷移する仕組みについては，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「7.7.3　MDB（WS-R）実行時の障害対策」を参照してください。

2.4.6　MDB（WS-R）で使用するキューの名称と個数

HCSCサーバの実行環境上では，次の表に示すキューを使用します。

表2‒6　MDB（WS-R）で使用するキューの名称と個数

項番

用途

説明

キューの種類

キューの名称

個数

備考

1

非同期（MDB（WS-R））の標準受付用

サービスリクエスタ側の転送キューの宛先となるキュー。

ローカルキュー

単独構成およびロードバランスクラスタの場合

CSC<HCSCサーバ名>ACPT_RCVQ

HAクラスタの場合

CSC<クラスタ名>ACPT_RCVQ

1個

−

2

MDB（WS-R）アダプタ用

サービス部品側のローカルキューへ転送するキュー。

転送キュー

CSC_<クラスタ名><アダプタ名>

非同期のMDB（WS-R）アダプタ数

−

3

デッドメッセージキュー

MDB（DBキュー）用のデッドメッセージキューと共用。

ローカルキューまたは転送キュー

任意の名称

システムに1個

DBキューでのデッドメッセージキューと同一。

4

応答用のキュー

サービス部品呼び出しの応答を受け取る場合に使用。

ローカルキューまたは転送キュー

任意の名称

任意の個数

−

（凡例）

−：該当しません。

2.5　DBキューを使用したサービスとの接続

2.5.1　Reliable Messagingとの関係

DBキューを使った非同期のサービス部品呼び出しでも，Reliable Messagingを使用します（通常は，TP1/EEと連携するために使用します。TP1/EE側ではDBキューという名前で呼びます）。

サービスリクエスタ側のTP1/EEとのインターフェースには受信用共用キューを，サービス部品側のTP1/EEとのインターフェースには送信用共用キューを使用します。

なお，非同期（MDB（DBキュー））の標準受付から，非同期のMDB（DBキュー）アダプタを呼び出すことはできません。必ず異なるプロトコルのリクエスト受付またはサービスアダプタと組み合わせて使用する必要があります。Reliable Messagingとの関係を次の図に示します。

図2‒41　Reliable Messagingとの関係

注意事項

実行環境内とHiRDBに別々のキューがそれぞれ作成されるわけではありません。データベース上のキューは同一のシステム上に作成されるため，実行環境内のキューとHiRDBのキューは同じものになります。TP1/EE側のDBキューも同様です。

2.5.2　サービス部品呼び出し時のメッセージの流れ

HCSCサーバのリクエスト受付は，MDB（Message Driven Bean）で動作し，HCSCサーバ側の受信用共用キューを監視しています。HCSCサーバ側の受信用共用キューにメッセージが送信されると，メッセージを取り出してサービス部品を呼び出します。

TP1/EE側のサービスリクエスタからは，受信用共用キューがあるデータベースに対して，直接アクセスしてメッセージを送信します。

サービスリクエスタ側の送信用共用キューには，宛先となるキュー名を設定します（開発環境のサービスアダプタ定義画面で設定します）。

宛先となるTP1/EE側のDBキュー（受信用共用キュー）は，TP1/EEのコマンドを使用して作成します。なお，TP1/EE側のDBキューは，送信用共用キューがある同一データベース内（同一のHiRDBシステム内）に作成する必要があります。非同期（MDB（DBキュー））の場合の宛先の指定について次の図に示します。

図2‒42　非同期（MDB（DBキュー））の場合の宛先の指定

注意事項

実行環境内とHiRDBに別々のキューがそれぞれ作成されるわけではありません。データベース上のキューは同一のシステム上に作成されるため，実行環境内のキューとHiRDBのキューは同じものになります。TP1/EE側のDBキューも同様です。

DBキューの作成の詳細については，マニュアル「TP1/Server Base Enterprise Option　使用の手引」のDBキューに関する内容を参照してください。

(1)　TP1/EEからサービス部品を呼び出す場合

サービスリクエスタからサービス部品を呼び出すときに，受信用共用キューに送信するメッセージの形式は，BytesMessageです。

呼び出すサービス名やクライアント相関IDなどのパラメタを設定したHCSCサーバ用DBキューヘッダをバイナリ形式で作成し，そのあとに要求電文（バイナリ形式）を組み立てます。これによって，要求電文（バイナリ形式）の内容が，ユーザ電文としてサービス部品に伝わります。サービスリクエスタから標準受付（MDB（DBキュー））を呼び出すとき，サービス部品側の電文フォーマットに合わせた要求電文を事前に作成し，ペイロードに設定してメッセージを送信します。TP1/EEからサービス部品を呼び出すときのユーザ電文と電文フォーマットの関係を次の図に示します。

図2‒43　TP1/EEからサービス部品を呼び出すときのユーザ電文と電文フォーマットの関係

バイナリデータを作成する方法については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「9.6.4　バイナリデータを作成する（TP1/EE，JMS）」を参照してください。

(2)　TP1/EEのサービス部品を呼び出す場合

サービスアダプタからサービス部品を呼び出すときに送信用共用キューに送信するメッセージの形式は，BytesMessageです。

サービスアダプタに定義した電文フォーマットに合わせた要求電文をバイナリ電文としてメッセージに設定します。TP1/EEのサービス部品を呼び出すときのユーザ電文と電文フォーマットの関係を次の図に示します。

図2‒44　TP1/EEのサービス部品を呼び出すときのユーザ電文と電文フォーマットの関係

2.5.3　同期のサービス部品を呼び出す場合の応答電文の扱い

非同期（MDB（DBキュー））の標準受付は，非同期の要求電文の標準受付（MDB（DBキュー））で，基本的にサービス部品からの応答がない場合に使用します。しかし，非同期（MDB（DBキュー））の標準受付から同期のサービス部品（WebサービスまたはSessionBeanなど）やビジネスプロセスを要求した場合，同期のサービス部品から応答が返るときがあります。

そのため，HCSCサーバでは応答を応答用のキューに送信する手段を提供しています。

応答用のキューを利用するには，HCSCサーバの環境構築時にHCSCサーバ側に送信用共用キューを作成し，送信用共用キューに送信先のキュー名を指定しておきます。

サービスリクエスタから標準受付（MDB（DBキュー））に対してサービス部品の呼び出しを要求する場合，標準受付（MDB（DBキュー））のパラメタに作成した送信用共用キューのキュー名を指定すると，サービス部品からの応答が返ってきた際に指定されたキューにJMSメッセージが送信されます。

送信用共用キューからサービスリクエスタ側のDBキュー（受信用共用キュー）にメッセージが転送されるため，DBキュー（受信用共用キュー）からメッセージを取り出すことで，サービス部品からの応答電文を取得できます。

応答を取り出す方法については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「9.6.10　応答を取り出す（TP1/EE，JMS）」を参照してください。

同期サービス部品を呼び出した場合の応答の扱いを次の図に示します。

図2‒45　同期サービス部品を呼び出した場合の応答の扱い

応答用のキューへメッセージを出力するのは，次に示す場合です。

同期サービス部品でも応答があるかどうかによって，次のような形式で応答用のキューへメッセージを送信します。

なお，サービスリクエスタから応答用のキューのキュー名を指定していても，HCSCサーバ側に指定したキュー名のキューが作成されていない場合は，応答用のキューにメッセージは送信できないで，サービス部品呼び出し処理がエラーになります。

表2‒7　応答用のキューへメッセージを出力するケース

項番

応答用のキューへ出力するケース

応答電文の有無

応答電文がある場合

応答電文がない場合

サービス部品からのユーザ定義例外の場合

ユーザ定義例外以外のエラーの場合

1

呼び出し先のサービス部品が同期サービス部品の場合（WebService，SessionBeanおよび汎用カスタムアダプタなど）

ペイロードに応答電文を設定

ペイロードなしのメッセージ

ペイロードに応答電文を設定

×※

2

呼び出し先のサービス部品が非同期サービス部品の場合

（MDB（WS-R）およびMDB（DBキュー）など）

×

×

−

×※

3

呼び出し先のサービス部品がビジネスプロセスの場合

ペイロードに応答電文を設定

ペイロードなしのメッセージ

ペイロードに応答電文を設定

×※

（凡例）

×：メッセージを送信しません。

−：非同期のサービス部品からユーザ定義例外は存在しないため該当しません。

注※

エラーの情報はログおよびトレースに出力します。

サービスリクエスタからの要求で応答用のキューのキュー名を指定していない場合は，応答電文の内容は破棄されます（応答電文を破棄したことを示すKDEC00031-Wメッセージが出力されます）。

なお，MDB（WS-R）の場合のように，JMSプロパティを引き継ぐことはできません。サービス部品呼び出しの相関関係を対応づける場合は，ユーザ電文内に相関関係を示す情報を埋め込みます。

2.5.4　MDB（DBキュー）使用時のトランザクション

MDB（DBキュー）の場合，サービスリクエスタからHCSCサーバの間，そしてサービスアダプタからサービス部品の間は，異なるトランザクションになります。

標準受付（MDB（DBキュー））でのローカルキューからのメッセージの取り出しとサービスアダプタでの転送キューへの送信は，1つのトランザクションで処理します。MDB（WS-R）の場合のトランザクションと同一です。

永続化するビジネスプロセスの場合，ビジネスプロセスを実行する過程でのトランザクションについては，「3.4　ビジネスプロセスのトランザクション」を参照してください。

2.5.5　デッドメッセージキュー

HCSCサーバ稼働マシンでのサービス部品の呼び出しをロールバックして，ロールバックの回数（メッセージの配送回数）が最大値に達した場合や，配送回数に無制限の設定をしている場合，そのメッセージはデッドメッセージキューに遷移します。

エラーが発生したときにデッドメッセージキューに遷移する仕組みについては，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「7.7.4　MDB（DBキュー）実行時の障害対策」を参照してください。

2.5.6　MDB（DBキュー）で使用するキューの名称と個数

HCSCサーバの実行環境上では，次の表に示すキューの名称と個数を使用します。データベース（DBキュー）で使用するキューの名称と個数を次の表に示します。

表2‒8　データベース（DBキュー）で使用するキューの名称と個数

項番

用途

説明

キューの種類

キューの名称

個数

備考

1

非同期（MDB（DBキュー））の標準受付用

サービスリクエスタ側のTP1/EEシステムから要求を受信するキュー。

受信用共用キュー

単独構成およびロードバランスクラスタの場合

CSC<HCSCサーバ名>ACPT_DBQ

HAクラスタの場合

CSC<クラスタ名>ACPT_DBQ

1個

−

2

MDB（DBキュー）アダプタ用

サービス部品側のDBキューへ転送するキュー。

送信用共用キュー

CSC_<クラスタ名><アダプタ名>

非同期のMDB（DBキュー）アダプタ数

−

3

デッドメッセージキュー

MDB（WS-R）用のデッドメッセージキューと共用。

ローカルキューまたは転送キュー

任意の名称

システムに1個

WS-Rでのデッドメッセージキューと同一

4

応答用のキュー

サービス部品呼び出しの応答を受け取る場合に使用。

送信用共用キュー

任意の名称

任意の個数

−

（凡例）

−：該当しません。

2.6　データベースとの接続

サービス部品としてデータベースを呼び出す場合には，DBアダプタを使用します。DBアダプタを使用する場合のデータベースのアクセスと設定について説明します。

2.6.1　DBアダプタを使ったデータベースへのアクセス

DBアダプタは，サービスリクエスタやビジネスプロセスからの要求を受けて，データベースに対して直接アクセスできます。データベースに対するアクセスは，DBアダプタ内で定義されているSQLに従います。

(1)　DBアダプタによるSQLの実行

DBアダプタは，開発環境で定義します。DBアダプタに対して要求するサービスリクエスタからは，実行するSQL文を記述したXML文書を作成して，作成したXML電文を要求電文に設定して実行します。DBアダプタによるSQLの実行について次の図に示します。

図2‒46　DBアダプタによるSQLの実行

DBアダプタを定義する手順，およびDBアダプタに要求を出すサービスリクエスタの作成については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.5　DBアダプタを定義する」を参照してください。

(2)　バイナリデータ操作時の処理

DBアダプタ内部で，バイナリデータはbyte配列型，base64Binary型およびhexBinary型はString型として扱います。SELECT文実行時とINSERT文実行時にBLOB型を操作する場合の例を次に説明します。

(a)　SELECT文実行時の処理

BLOB列に対してSELECT文を実行すると，DBアダプタではbyte配列からXML Schemaのbase64Binary型またはhexBinary型に変換（エンコード）して，要求元にBLOB列の値を返却します。

図2‒47　SELECT文実行時の処理（base64Binary型に変換する場合）

(b)　INSERT文，UPDATE文実行時の処理

BLOB列に対してINSERT文，またはUPDATE文を実行する際は，要求元がXML Schemaのbase64Binary型またはhexBinary型のデータをDBアダプタに渡します。DBアダプタではbase64Binary型またはhexBinary型からbyte配列に変換（デコード）して，SQLを実行します。

図2‒48　INSERT文，またはUPDATE文実行時の処理（base64Binary型から変換する場合）

xsd:hexBinary型またはxsd:base64Binary型のデータの変換（デコード）でエラーが発生した場合，KDEC63001-E（xsd:hexBinary型の場合は原因コード=22，xsd:base64Binary型の場合は原因コード=23）を出力します。また，DBアダプタの定義時に，「システム例外をフォルトに変換する」を有効にしている場合はDBアダプタの呼び出し元にはフォルト電文が送出され，無効にしている場合はシステム例外が送出されます。

(3)　SQL命令のINSERT文，UPDATE文およびDELETE文を使用する場合の注意事項

DBアダプタでは定義されたSQLを実行することでデータベースが更新されます。

そのため，HCSCサーバのDBアダプタと他システムで同一のデータベースを利用する場合，トランザクションの終了タイミングやデータの整合性を考慮してデータベースにアクセスする必要があります。

DBアダプタ経由でデータのINSERT文，UPDATE文およびDELETE文を実行する場合は，他システムに影響を与えないことを確認して利用してください。

2.6.2　DBアダプタが使用するDB Connectorの設定

データベースにアクセスするには，HCSCサーバをセットアップするときに定義したDB Connectorとは別に，サービス部品稼働マシン（データベースが稼働しているマシン）に対してアクセスするDB Connectorを準備する必要があります。

(1)　使用できるDB Connector

HCSCサーバをセットアップするときに定義したDB Connectorのトランザクション属性によって，使用できるDB Connectorに制約があります。

DBアダプタで使用できるDB Connectorは，HCSCサーバセットアップ定義ファイルのdbcon-xadisplaynameプロパティに指定したXATransactionまたはLocalTransactionの値に依存します。そのため，HCSCサーバのセットアップ時には，dbcon-xadisplaynameプロパティに指定したXATransactionまたはLocalTransactionの値を考慮する必要があります。

表2‒9　使用可能なDB Connector

使用しているDB Connector

DBアダプタ

使用可否

否の理由

HCSCサーバ本体側(dbcon-xadisplayname)

使用可能なDB Connector

DBアダプタの接続先

LocalTransaction

LocalTransaction

HCSCサーバが使用するデータベースと同じデータベース

可

−

LocalTransaction

HCSCサーバが使用するデータベースと異なるデータベース

否

Localトランザクション内で複数のDB Connectorを混在させることができないため

XATransaction

HCSCサーバが使用するデータベースと異なるデータベース

否

Localトランザクション内でXA（グローバルトランザクション）を混在させることができないため

XATransaction

LocalTransaction

HCSCサーバが使用するデータベースと異なるデータベース

否

XAトランザクション内で複数のDB Connectorを混在させることができないため

XATransaction

HCSCサーバが使用するデータベースと同じデータベース

可

−

XATransaction

HCSCサーバが使用するデータベースと異なるデータベース

可

−

（凡例）

−：該当しません。

(2)　DB Connectorのインポートおよび配備

DBアダプタが利用するDB ConnectorをHCSCサーバ（J2EEサーバ）にインポートし，配備します。

DBアダプタを利用する場合にインポートするRARファイルの選択方法については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「3.1.2　実行環境に必要なソフトウェアを設定する」を参照してください。

DB Connectorのインポート

次に示すコマンドを使用してDB Connectorをインポートします。

<サービスプラットフォームのインストールディレクトリ>¥CC¥admin¥bin¥cjimportres <J2EEサーバ名> -nameserver corbaname::localhost:<インプロセスのネーミングサービス用のポート番号> -type rar -f <サービスプラットフォームのインストールディレクトリ>¥CC¥DBConnector¥<インポートするRARファイル>

DB Connectorの配備

次に示すコマンドを使用してDB Connectorを配備します。

<サービスプラットフォームのインストールディレクトリ>¥CC¥admin¥bin¥cjdeployrar <J2EEサーバ名> -nameserver corbaname::localhost:<インプロセスのネーミングサービス用のポート番号> -resname <インポートしたDB Connectorの名称>

(3)　DB Connectorのプロパティ定義

DB Connectorをインポートしたあと，プロパティを定義します。プロパティ定義ファイルの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。リソースに別名を設定する場合の付与規則については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.6.2　別名の付与規則」を参照してください。

参考

配備したDB Connectorに対してプロパティを設定するときに，新規にプロパティ定義ファイルのXMLを作成するのではなく，配備したDB Connectorのプロパティを取得し，取得したXMLに対して編集をすると効率良く作成できます。

プロパティ定義用のファイルの取得

次に示すコマンドを使用してDB Connectorのプロパティ定義用のファイルを取得します。

<サービスプラットフォームのインストールディレクトリ>¥CC¥admin¥bin¥cjgetrarprop <J2EEサーバ名> -nameserver corbaname::localhost:<インプロセスのネーミングサービス用のポート番号> -resname <インポートしたDB Connectorの名称> -c property.xml

プロパティ定義用のファイルの編集

取得したプロパティ定義用のXMLファイルについて，各属性の値を変更します。

プロパティ定義用のXMLファイル（Connector属性ファイル）の設定内容については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「3.1.2　実行環境に必要なソフトウェアを設定する」を参照してください。

Connector属性ファイルの詳細については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「4.2.2　DB Connectorのプロパティ定義」，およびマニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。

編集したプロパティ定義用のファイルの設定

編集したプロパティ定義用のXMLファイルの内容を配備しているDB Connectorに設定します。

次に示すコマンドを使用してDB Connectorに定義内容を設定します。

<サービスプラットフォームのインストールディレクトリ>¥CC¥admin¥bin¥cjsetrarprop <J2EEサーバ名> -nameserver corbaname::localhost:<インプロセスのネーミングサービス用のポート番号> -resname <インポートしたDB Connectorの名称> -c property.xml

注

プロパティ定義用のファイル（property.xml）の設定後，DB Connectorのプロパティの各属性の値は上書きされます。

2.6.3　DBアダプタ使用時のトランザクション

DBアダプタの場合，HCSCサーバ内で管理しているトランザクションをデータベース側に引き継ぎます。サービスリクエスタからHCSCサーバの間のトランザクションについては，それぞれの標準受付のトランザクション制御についての説明を参照してください。

SOAP通信を利用したサービスリクエスタを例に，DBアダプタの場合のトランザクションを次の図に示します。

図2‒49　DBアダプタのトランザクション

2.6.4　DBアダプタの接続先情報の動的変更

DBアダプタの接続先は，接続先のDB Connectorのリソースの別名をDBアダプタに設定することで動的に変更できます。ビジネスプロセスで接続先のDB Connectorのリソースの別名を設定しておくと，DBアダプタを実行したときに接続先が変更されます。これによって，作成するDBアダプタの数を削減できます。

(1)　接続先動的変更の処理の流れ

DBアダプタの接続先動的変更の処理の流れを次に示します。

要求電文内のヘッダ電文から接続先情報を取得します。

取得した接続情報を基にデータベースとのコネクションを確立します。

なお，接続情報がヘッダ電文に設定されていないなど，接続先情報の取得に失敗した場合は，リクエスト処理がエラーになります。

(2)　接続先動的変更の前提条件

DBアダプタの接続先を動的に変更するための前提条件を次に示します。

(a)　リソース名の別名付与

接続先のDB Connectorにリソースの別名を付けます。

別名の付与規則については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.6.2　別名の付与規則」を参照してください。

(b)　SQLオペレーション定義ファイルの設定

SQLオペレーション定義ファイルのdynamic属性に「Y」を設定します。

(c)　DB Connector種別の選択

接続先のDB Connectorの種別は，SQLオペレーション定義ファイルに設定したデータベース種別と同一にします。

(d)　トランザクションサポートレベルの設定

接続先のDB Connectorのトランザクションサポートレベルは，「LocalTransaction」または「XATransaction」を指定できます。

指定できるトランザクションサポートレベルと指定できる条件を次の表に示します。

表2‒10　指定できるトランザクションサポートレベルと指定できる条件

指定できるトランザクションサポートレベル

指定できる条件

LocalTransaction，またはXATransaction

ビジネスプロセスでステータスの永続化をしない場合

DBアダプタのトランザクションをビジネスプロセスとは別に開始する場合

ビジネスプロセスでステータスを永続化し，かつDBアダプタのトランザクションをビジネスプロセスとは別に開始する場合

XATransaction

上記以外の場合

(e)　ビジネスプロセスの設定

ビジネスプロセスで接続先情報を設定します。

(3)　接続先情報を動的に変更する例

接続先情報ファイルを使用して，接続先情報を動的に変更する例を説明します。

(a)　ビジネスプロセスの例

接続先情報ファイルを使用するビジネスプロセスの例を次の図に示します。

図2‒50　接続先情報ファイルを使用するビジネスプロセスの例（DBアダプタの場合）

サービスリクエスタがビジネスプロセスにサービス部品の実行を要求します。

サービスリクエスタから送付する要求電文内のヘッダ電文に接続先情報（DB Connectorのリソースの別名）を設定します。

ビジネスプロセスはXMLの要求電文を受付アクティビティで受け取ります。

ビジネスプロセスがヘッダ要求データおよび要求データを生成します。

ヘッダ要求データの接続先情報を，データ変換アクティビティなどで接続先情報変数に設定します。

ビジネスプロセスは接続先情報変数に含まれる接続先情報をDBアダプタに設定して，サービス部品を呼び出します。

ビジネスプロセスが，サービス部品の実行結果をXMLの応答電文として構成し，応答アクティビティで返します。

サービスリクエスタへの応答が返されます。

サービスリクエスタへの応答では，XMLの応答電文が送付されます。

(4)　ユーザ定義受付を生成するWSDLの作成例

ユーザ定義受付を生成するWSDLの作成例を次に示します。

なお，この例では，接続先となるDB Connectorのリソースの別名をSOAPヘッダで送付しています。

(a)　データ変換アクティビティの設定例

「図2-50　接続先情報ファイルを使用するビジネスプロセスの例（DBアダプタの場合）」に示すビジネスプロセスで使用するデータ変換アクティビティの設定例を次に示します。

ここでは，変換元に「ヘッダ要求データ」を，変換先に「接続先」を指定しています。

図2‒51　データ変換アクティビティの設定例（DBアダプタの場合）

また，変換のマッピングは，次の図に示すとおりに定義します。

図2‒52　変換のマッピングの設定例（DBアダプタの場合）

(b)　接続先情報ファイルの定義

DB Connectorのリソースの別名をDBアダプタに設定するための接続先情報ファイル（XMLスキーマ）に定義します。

サービスプラットフォームでは，接続先情報ファイルを提供しています。

接続先情報ファイルの格納先

<サービスプラットフォームのインストールディレクトリ>/CSC/schema/connection/connection_db_adapter.xsd

注意事項

DBアダプタの接続先情報を動的に変更する場合，サービスプラットフォームで提供している接続先情報ファイルを使用してください。提供している接続先情報ファイルを使用しなかった場合，動作は保証されません。

接続先情報ファイルの形式

<?xml version="1.0" encoding="UTF-8"?>
<!--
 DO NOT EDIT THIS FILE.
 -->
<xsd:schema
    elementFormDefault="qualified"
    targetNamespace="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/connection/change/dba"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="dbaAddress">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="optionalName" type="xsd:string"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

設定できる要素

optionalName

DB Connectorに設定したリソースの別名を指定します。

(c)　接続先情報の設定

「図2-50　接続先情報ファイルを使用するビジネスプロセスの例（DBアダプタの場合）」に示すビジネスプロセスで使用する接続先情報の設定例を次に示します。なお，接続先情報は，サービス呼出アクティビティのヘッダ割当変数に設定します。ここで設定した情報が，DBアダプタで参照できる情報になります。

図2‒53　接続先情報の設定例（サービス呼出アクティビティの設定）

2.7　OpenTP1との接続

OpenTP1などの既存システムのサービス部品を呼び出したり，OpenTP1などの既存システムからサービス部品を呼び出したりできます。呼び出し方で接続のしかたが異なります。

2.7.1　TP1から非同期の標準受付を使ったHCSCサーバのサービス部品の呼び出し

同期応答型の要求のほかに，非同期でOpenTP1などの既存システムから，HCSCサーバを経由してサービス部品を呼び出せます。

HCSCサーバの標準受付（MDB（DBキュー））に対して要求する非同期応答型の送信ができます。

詳細は，「2.5　DBキューを使用したサービスとの接続」を参照してください。

2.7.2　TP1からTP1/RPC受付を使ったHCSCサーバのサービス部品の呼び出し

HCSCサーバの標準受付（SessionBean，MDB（DBキュー））のほかに，ユーザ定義受付（TP1/RPC受付）を使用することで，既存のOpenTP1システムから，HCSCサーバを経由してサービス部品を呼び出せます。

TP1/RPC受付は，開発環境でTP1/RPC受付定義ファイルを作成し，実行環境へ配備することで利用できます。なお，サービスリクエスタからのサービス部品呼び出し要求を受けた場合，TP1/RPC受付は，リソースアダプタであるTP1インバウンドアダプタから電文を受け取って処理をします。そのため，TP1/RPC受付を使用する場合は，TP1インバウンドアダプタのセットアップが必要になります。

TP1/RPC受付を使用することで，サービスリクエスタはビジネスプロセスを，リモートプロシジャコール通信（同期応答型RPC）で呼び出せます。サービスリクエスタが呼び出すビジネスプロセスは，dc_rpc_call関数に指定するサービスグループ名とサービス名で特定されます。このとき指定したサービスグループ名とサービス名が，それぞれTP1インバウンドアダプタとTP1/RPC受付に結び付けられます。

OpenTP1システムからのサービス部品の呼び出しを次の図に示します。

図2‒54　TP1/RPC受付を使用したOpenTP1システムからのサービス部品の呼び出し

(1)　TP1/RPC受付使用時のトランザクション

TP1/RPC受付では，サービスリクエスタおよびTP1インバウンドアダプタのトランザクションとは異なる新たなトランザクションを開始します。

また，ビジネスプロセス内ではさらにTP1/RPC受付と異なる新たなトランザクションが開始されます。

ビジネスプロセスを呼び出すときのTP1/RPC受付のトランザクションを次に示します。

図2‒55　TP1/RPC受付のトランザクション

(2)　TP1/RPC受付のデータ変換

TP1/RPC受付でのデータの流れとデータ変換の関係，およびデータ変換時の構造変換スキップ機能の指定について説明します。

(a)　TP1/RPC受付でのデータの流れとデータ変換の関係

サービスリクエスタから受け取った要求電文（バイナリ形式）は，TP1/RPC受付によってデータ変換（バイナリ形式からXML形式への変換）が実行されます。データ変換によって変換された要求電文（XML形式）は，HCSCメッセージ配送制御を経由してビジネスプロセスに渡されます。ビジネスプロセスから返ってきた応答電文（XML形式）は，TP1/RPC受付によってデータ変換（XML形式からバイナリ形式への変換）が実行されます。データ変換によって変換された応答電文（バイナリ形式）は，TP1インバウンドアダプタを経由してサービスリクエスタに返されます。

TP1/RPC受付でのデータの流れとデータ変換の関係を次に示します。

図2‒56　TP1/RPC受付でのデータの流れとデータ変換の関係

(b)　データ変換時の構造変換スキップ機能の指定

構造変換スキップ機能とは，データ変換時に電文の構造変換をスキップする機能のことです。

要求電文のデータ変換では，サービスリクエスタから受け取ったバイナリ形式の要求電文から生成したDOMツリーを，そのままビジネスプロセスに渡したいときに，構造変換スキップ機能を有効にできます。

応答電文のデータ変換では，ビジネスプロセスから返ってきたDOMツリーから，直接，バイナリ形式の応答電文を生成し，サービスリクエスタに返したいときに，構造変換スキップ機能を有効にできます。

●構造変換スキップ機能の設定方法

構造変換スキップ機能の設定を有効にするには，開発環境のユーザ定義受付定義画面で，［独自定義ファイル］にTP1/RPC受付定義ファイルを設定します。

ユーザ定義受付定義画面に表示される項目については，マニュアル「サービスプラットフォーム リファレンス」の「1.2.5　ユーザ定義受付定義画面」を参照してください。

TP1/RPC受付定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「3.4.1　TP1/RPC受付定義ファイル」を参照してください。

●構造変換スキップ機能を使用するときの注意事項

開発環境のユーザ定義受付定義画面で，要求電文および応答電文の受付電文フォーマットにバイナリフォーマット定義ファイルを，要求電文および応答電文のサービス部品電文フォーマットにXMLフォーマット定義ファイルを指定します。

開発環境のユーザ定義受付定義画面で，要求電文および応答電文のサービス部品電文フォーマットには，受付電文フォーマット（バイナリフォーマット定義ファイル）からcscfdx2xsdコマンドを使用して生成したXMLフォーマット定義ファイルを指定してください。

(3)　TP1/RPC受付のチューニング

ここでは，TP1/RPC受付の同時実行数，タイムアウト，トランザクションタイムアウト，およびサービス名の設定変更について説明します。

(a)　同時実行数の設定方法

同時実行数の設定を変更するときのTP1インバウンドアダプタでの設定，およびTP1/RPC受付での設定について説明します。

●TP1インバウンドアダプタでの設定

TP1インバウンドアダプタでの設定については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「4.12.2　リソースアダプタの設定」を参照してください。

●TP1/RPC受付での設定

TP1/RPC受付では，次の環境でチューニングパラメタを変更できます。

開発環境（ユーザ定義受付定義画面でTP1/RPC受付定義ファイルを設定）

運用環境（コマンドでTP1/RPC受付定義ファイルを設定，またはコマンドでアプリケーション統合属性ファイルを設定）

TP1/RPC受付の同時実行数の設定を変更するとき，TP1/RPC受付で変更できる内容を次に示します。

●TP1/RPC受付定義ファイルを設定する場合

次に示すTP1/RPC受付定義ファイルのプロパティに値を設定します。

urecp-tp1rpc.activation-config.queue_max_lengthプロパティ

urecp-tp1rpc.pooled-instance.minimumプロパティ

urecp-tp1rpc.pooled-instance.maximumプロパティ

●アプリケーション統合属性ファイルを設定する場合

アプリケーション統合属性ファイルの要素に値を設定します。

設定する要素については，次に示すXPath式を参照してください。

//hitachi-application-all-property/ejb-jar/hitachi-ejb-jar-property/display-name[.='cscmsg_urecp_tp1rpc']/../../hitachi-message-bean-property/display-name[.='CSCMsgTp1RpcServiceDelivery']/../activation-config/activation-config-property/activation-config-property-name[.='queue_max_length']/../activation-config-property-value

//hitachi-application-all-property/ejb-jar/hitachi-ejb-jar-property/display-name[.='cscmsg_urecp_custom']/../../hitachi-session-bean-property/display-name[.='CSCMsgCustomServiceDelivery']/../session-runtime/stateless/pooled-instance/minimum

//hitachi-application-all-property/ejb-jar/hitachi-ejb-jar-property/display-name[.='cscmsg_urecp_custom']/../../hitachi-session-bean-property/display-name[.='CSCMsgCustomServiceDelivery']/../session-runtime/stateless/pooled-instance/maximum

//hitachi-application-all-property/ejb-jar/hitachi-ejb-jar-property/display-name[.='cscmsg_urecp_tp1rpc']/../../hitachi-message-bean-property/display-name[.='CSCMsgTp1RpcServiceDelivery']/../message-runtime/pooled-instance/maximum

(b)　タイムアウト時間の設定方法

タイムアウトの設定を変更するときのTP1インバウンドアダプタでの設定，およびTP1/RPC受付での設定について説明します。

●TP1インバウンドアダプタでの設定

TP1インバウンドアダプタでは，パフォーマンスチューニングのための機能を定義する場合，Connector属性ファイルを使用します。

TP1インバウンドアダプタでの設定については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「4.12.2　リソースアダプタの設定」を参照してください。ただし，サービス実行タイムアウトの設定は行わないでください。

●TP1/RPC受付での設定

TP1/RPC受付で設定の変更はありません。

(c)　トランザクションタイムアウト時間の設定方法

トランザクションタイムアウトの設定を変更するときのTP1インバウンドアダプタでの設定，およびTP1/RPC受付での設定について説明します。

●TP1インバウンドアダプタでの設定

TP1インバウンドアダプタで設定の変更はありません。

●TP1/RPC受付での設定

TP1/RPC受付では，次の環境でチューニングパラメタを変更できます。

開発環境（ユーザ定義受付定義画面でTP1/RPC受付定義ファイルを設定）

運用環境（コマンドでTP1/RPC受付定義ファイルを設定，またはコマンドでアプリケーション統合属性ファイルを設定）

TP1/RPC受付のトランザクションタイムアウトの設定を変更するとき，TP1/RPC受付で変更できる内容を次に示します。

●TP1/RPC受付定義ファイルを設定する場合

次に示すTP1/RPC受付定義ファイルのプロパティに値を設定します。

urecp-tp1rpc.ejb-transaction-timeoutプロパティ

●アプリケーション統合属性ファイルを設定する場合

アプリケーション統合属性ファイルの要素に値を設定します。

設定する要素については，次に示すXPath式を参照してください。

//hitachi-application-all-property/ejb-jar/hitachi-ejb-jar-property/display-name[.='cscmsg_urecp_custom']/../../hitachi-session-bean-property/display-name[.='CSCMsgCustomServiceDelivery']/../ejb-transaction-timeout/method/method-name[.='*']/../../transaction-timeout

(d)　サービス名の設定方法

サービス名の設定を変更するときのTP1/RPC受付での設定について説明します。

●TP1/RPC受付での設定

TP1/RPC受付では，次の環境でチューニングパラメタを変更できます。

開発環境（ユーザ定義受付定義画面でTP1/RPC受付定義ファイルを設定）

運用環境（コマンドでTP1/RPC受付定義ファイルを設定，またはコマンドでアプリケーション統合属性ファイルを設定）

TP1/RPC受付のサービス名の設定を変更するとき，TP1/RPC受付で変更できる内容を次に示します。

●TP1/RPC受付定義ファイルを設定する場合

次に示すTP1/RPC受付定義ファイルのプロパティに値を設定します。

urecp-tp1rpc.activation-config.serviceプロパティ

●アプリケーション統合属性ファイルを設定する場合

アプリケーション統合属性ファイルの要素に値を設定します。

設定する要素については，次に示すXPath式を参照してください。

//hitachi-application-all-property/ejb-jar/hitachi-ejb-jar-property/display-name[.='cscmsg_urecp_tp1rpc']/../../hitachi-message-bean-property/display-name[.='CSCMsgTp1RpcServiceDelivery']/../activation-config/activation-config-property/activation-config-property-name[.='service']/../activation-config-property-value

2.7.3　HCSCサーバからTP1アダプタを使ったTP1サービス部品の呼び出し

TP1アダプタを使用することで，OpenTP1を使用したシステムのサービス部品を呼び出せます。HCSCサーバからのOpenTP1システムのサービス部品の呼び出しを次の図に示します。

図2‒57　HCSCサーバからのOpenTP1システムのサービス部品の呼び出し

開発環境でTP1アダプタを作成する手順については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.　サービスアダプタの定義」を参照してください。

開発環境での操作については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」を参照してください。

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

(1)　TP1アダプタを使用したシステムの運用例

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

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

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

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

サービスリクエスタからの要求によって，ビジネスプロセスが起動されます。

ビジネスプロセスからTP1アダプタを介して，OpenTP1上で動作する受注管理システムおよびメインフレーム上で動作する在庫管理システムがサービスとして呼び出されます。

サービスの呼び出し結果がサービスリクエスタに送信されます。

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

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

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

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

(2)　TP1アダプタのRPC通信

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回目以降の同一接続先へのサービス要求については，確立済みの常設コネクションが使用されます。接続先動的変更については，「2.7.6　TP1アダプタの接続先動的変更」を参照してください。

非常設コネクションを確立する場合

コネクションの管理方式は指定できません。コネクションは，非オートコネクトモードで確立されます。

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

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

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

サービスリクエスタからの要求をHCSCサーバで受け付けます。

HCSCサーバでTP1アダプタのメソッドを起動します。

TP1アダプタで最初のサービス実行時に常設コネクションを確立します。

RPC通信を行い，サービスを実行します。

RPC通信の結果（応答データ）をサービスリクエスタに応答します。

TP1アダプタの停止時に常設コネクションを解放します。

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

TP1アダプタを開始したときに，常設コネクションを確立します。

サービスリクエスタからの要求をHCSCサーバで受け付けます。

HCSCサーバでTP1アダプタのメソッドを起動します。

RPC通信を行い，サービスを実行します。

接続先動的変更を使用した場合は，必要に応じてRPC通信に先立ち常設コネクションを確立します。

RPC通信の結果（応答データ）をサービスリクエスタに応答します。

TP1アダプタの停止時に常設コネクションを解放します。

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

サービスリクエスタからの要求をHCSCサーバで受け付けます。

HCSCサーバでTP1アダプタのメソッドを起動します。

接続先システム（RAPリスナー）にコネクションの確立要求を行います。

RPC通信を行い，サービスを実行します。

確立したコネクションの解放要求を行います。

RPC通信の結果（応答データ）をサービスリクエスタに応答します。

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

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

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

●ネームサービス機能

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

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

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

サービスリクエスタからの要求をHCSCサーバで受け付けます。

HCSCサーバでTP1アダプタのメソッドを起動します。

ネームサービスにサービスの所在を問い合わせます。

RPC通信を行い，サービスを実行します。

RPC通信の結果（応答データ）をサービスリクエスタに応答します。

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

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

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

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

サービスリクエスタからの要求をHCSCサーバで受け付けます。

HCSCサーバでTP1アダプタのメソッドを起動します。

RPC通信を行い，サービスを実行します。

RPC通信の結果（応答データ）をサービスリクエスタに応答します。

●通信先を指定した接続

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

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

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

サービスリクエスタからの要求をHCSCサーバで受け付けます。

HCSCサーバでTP1アダプタのメソッドを起動します。

通信先を指定したRPC通信を行い，サービスを実行します。

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アダプタを使用する場合は，各送受信バッファサイズを総和したメモリ量が，全体のバッファサイズとして必要になります。

(3)　MHPを接続先としたTCP/IP通信

TP1アダプタは，TCP/IP通信を使用して，サービスプラットフォームからOpenTP1のシステムを利用できます。TP1アダプタから通信先のOpenTP1システムのTP1/Message Controlに対して，メッセージの送受信を行い，MHP（Message Handling Program）を呼び出すことができます。

MHPを接続先としたTCP/IP通信は，通信先がTP1/NET/TCP/IPの受信メッセージの組み立て機能を使用している場合に使用できます。

受信メッセージの組み立て機能については，マニュアル「OpenTP1 クライアント使用の手引 TP1/Client/J編」を参照してください。

MHPを接続先としたTCP/IP通信処理の概要を次の図に示します。

図2‒70　MHPを接続先としたTCP/IP通信処理の概要

サービスリクエスタからの要求をHCSCサーバで受け付けます。

HCSCサーバでTP1アダプタのメソッドを起動します。

MHPを呼び出すTCP/IP通信（cltAssemSendメソッドを使用）を行います。

受信したメッセージをキューに格納し，MHPを起動してメッセージを送信します。

MHPで受信したメッセージを基にサービスを実行します。

TCP/IP通信の結果（応答データ）をサービスリクエスタに応答します。

(a)　MHPを接続先としたTCP/IP通信の通信形態

TP1アダプタでは，MHPを接続先としたTCP/IP通信として次の通信形態をサポートします。

応答型MHPサービス（ans型）

非応答型MHPサービス（noans型）

どちらの通信形態を使用するかは，サービスリクエスタからTP1アダプタへの要求で応答領域の設定によって判断します。応答領域が設定されている場合は，応答型MHPサービス（ans型）を呼び出します。応答領域にNULL（設定なし）が設定されている場合は，非応答型MHPサービス（noans型）を呼び出します。

なお，MHPサービスには，通信先システムとのメッセージの受送信を連続させる継続問い合わせ応答型MHPサービス（cont型）がありますが，サービスプラットフォームからのサービス呼び出しでは使用できません。

●応答型MHPサービス（ans型）との通信

TP1アダプタから受信したメッセージを処理し，処理したメッセージを応答するサービスと通信します。

図2‒71　応答型MHPサービス（ans型）との通信

●非応答型MHPサービス（noans型）との通信

TP1アダプタから受信したメッセージを処理し，応答を返さないサービスと通信します。

図2‒72　非応答型MHPサービス（noans型）との通信

(4)　時間監視

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

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

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

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

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

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

通信処理

接続形態

通信状況

コネクション状況

リモートAPI接続

通常RPC接続

常設コネクション

非常設コネクション

オートコネクト

非オートコネクト

開始中

コネクション確立

−

−

−

−

コネクション解放

−

○※

−

−

停止中

コネクション解放

○

○

−

−

（凡例）

○：時間監視できます。

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

注※

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

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

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

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

通信処理

接続形態

通信状況

コネクション状況

リモートAPI接続

通常RPC接続

常設コネクション

非常設コネクション

オートコネクト

非オートコネクト

運用中

コネクション確立

−

−

−

−

RPC通信

○

○

○

○

コネクション解放

○※

○※

○

−

（凡例）

○：時間監視できます。

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

注※

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

(5)　TP1アダプタ使用時の注意事項

リモートAPI接続でTP1アダプタのコネクション解放が失敗した場合，TP1アダプタではコネクション解放状態となりますが，接続先のシステムではコネクションの解放を検知していない場合があります。そのため，コネクション状態の不整合が発生し，接続先システムでのrapサーバリソース不足などで，次の通信処理が失敗するおそれがあります。その場合は接続先システムでコネクション確立状態を一度初期化してください。

リモートAPI接続でTP1アダプタ運用中に障害が発生して，正常に停止処理がされなかった場合，接続先システムでコネクションの解放を検知していない場合があります。その場合は接続先システムでコネクション確立状態を一度初期化してください。

J2EEサーバ用ユーザプロパティファイル（usrconf.properties）のejbserver.container.passivate.scan.intervalプロパティを，デフォルトの0から変更しないでください。

2.7.4　HCSCサーバからのMDB（DBキュー）サービスアダプタを使ったTP1サービス部品の呼び出し

同期応答型のサービス部品呼び出しのほかに，非同期でHCSCサーバから，OpenTP1システムのサービス部品を呼び出せます。非同期でHCSCサーバから，OpenTP1システムのサービス部品を呼び出すには，HCSCサーバの非同期MDB（DBキュー）アダプタを実行します。

詳細は，「2.5　DBキューを使用したサービスとの接続」を参照してください。

2.7.5　TP1アダプタのオペレーション動的変更

TP1アダプタの実行オペレーションをビジネスプロセス内で動的に変更できます。

TP1アダプタのオペレーション動的変更の詳細については，「2.22　TP1アダプタおよびMessage Queueアダプタのオペレーション動的変更機能」を参照してください。

2.7.6　TP1アダプタの接続先動的変更

TP1/Clientが使用するOpenTP1システムとのRPC通信条件を，ヘッダ割当変数に設定することで動的に変更できます。

なお，接続先動的変更では，通信接続方式は変更できません。

(1)　TP1アダプタの接続先動的変更の処理の流れ

TP1アダプタの接続先動的変更の処理の流れを次の図に示します。

図2‒73　TP1アダプタの接続先動的変更の処理の流れ

サービスリクエスタがビジネスプロセスにサービス部品の実行を要求します。

受付アクティビティは，受け取ったサービスリクエスタからの要求電文を要求電文の変数に格納します。

要求電文変数から，TP1アダプタのサービス呼び出しの実行に使用するサービス呼び出し要求電文（ボディ割当変数）を作成します。

要求電文変数から，各種接続用パラメタを決定し，データ変換アクティビティなどで，ヘッダ割当変数に格納します。

TP1アダプタを呼び出します。

サービス呼び出しでは，要求電文のヘッダ割当変数として，4.で定義したヘッダ割当変数を指定します。

TP1アダプタは，指定された接続用パラメタをTP1/Clientに設定し，TP1/ClientからOpenTP1システムとのRPC通信を行います。また，応答をサービス呼び出し応答電文の変数に格納します。

応答アクティビティは，サービス呼び出し応答電文をサービスリクエスタに返します。

(2)　ヘッダ割当変数の定義

TP1アダプタ接続先動的変更ヘッダ変数スキーマを使用して，ヘッダ割当変数を定義します。TP1アダプタ接続先動的変更ヘッダ変数スキーマは「<サービスプラットフォームのインストールディレクトリ>¥CSC¥custom-adapter¥TP1¥schema¥templates¥adptp1_dynamic_header.xsd」に格納されています。

TP1アダプタ接続先動的変更ヘッダ変数スキーマの定義例を次に示します。

TP1アダプタ接続先動的変更ヘッダ変数スキーマの定義例

<?xml version="1.0" encoding="UTF-8"?>
<!-- All Rights Reserved. Copyright (C) 2024. Hitachi, Ltd. -->
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:tpdh="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/tp1dynamics/header"
  targetNamespace="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/tp1dynamics/header">
  <xsd:element name="TP1DynamicConnection">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="watch_time" minOccurs="0" maxOccurs="1" type="xsd:unsignedShort"/>
        <xsd:element name="static_host" minOccurs="0" maxOccurs="1" type="xsd:string"/>
        <xsd:element name="host" minOccurs="0" maxOccurs="1" type="xsd:string"/>
        <xsd:element name="static_port" minOccurs="0" maxOccurs="1" type="tpdh:portNo"/>
        <xsd:element name="port" minOccurs="0" maxOccurs="1" type="tpdh:portNo"/>
        <xsd:element name="tcpip_wait_time" minOccurs="0" maxOccurs="1" type="tpdh:tcpipWaitTime"/>
        <xsd:element name="dccltinquiretime" minOccurs="0" maxOccurs="1" type="tpdh:cltInquireTime"/>
        <xsd:element name="dccltdelay" minOccurs="0" maxOccurs="1" type="xsd:unsignedShort"/>
        <xsd:element name="dcwatchtim" minOccurs="0" maxOccurs="1" type="xsd:unsignedShort"/>
        <xsd:element name="dccltextend" minOccurs="0" maxOccurs="1" type="tpdh:cltExtend"/>
        <xsd:element name="dcscdloadpriority" minOccurs="0" maxOccurs="1" type="xsd:boolean"/>
        <xsd:element name="dcwatchtiminherit" minOccurs="0" maxOccurs="1" type="xsd:boolean"/>
        <xsd:element name="dcwatchtimrpcinherit" minOccurs="0" maxOccurs="1" type="xsd:boolean"/>
        <xsd:element name="dchost" minOccurs="0" maxOccurs="1" type="xsd:string"/>
        <xsd:element name="dcnamport" minOccurs="0" maxOccurs="1" type="tpdh:portNo"/>
        <xsd:element name="dcscdport" minOccurs="0" maxOccurs="1" type="tpdh:portNo"/>
        <xsd:element name="dcrapport" minOccurs="0" maxOccurs="1" type="tpdh:portNo"/>
        <xsd:element name="dccltconnectinf" minOccurs="0" maxOccurs="1" type="tpdh:cltConnectInfo"/>
        <xsd:element name="dcsndhost" minOccurs="0" maxOccurs="1" type="xsd:string"/>
        <xsd:element name="dcsndport" minOccurs="0" maxOccurs="1" type="tpdh:scdPort"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:simpleType name="tcpipWaitTime">
    <xsd:restriction base="xsd:int">
      <xsd:minInclusive value="-1"/>
      <xsd:maxInclusive value="65535"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="cltInquireTime">
    <xsd:restriction base="xsd:unsignedInt">
      <xsd:minInclusive value="0"/>
      <xsd:maxInclusive value="1048575"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="cltExtend">
    <xsd:restriction base="xsd:unsignedByte">
      <xsd:minInclusive value="0"/>
      <xsd:maxInclusive value="1"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="portNo">
    <xsd:restriction base="xsd:unsignedShort">
      <xsd:minInclusive value="5001"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="cltConnectInfo">
    <xsd:restriction base="xsd:hexBinary">
      <xsd:maxLength value="64"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="scdPort">
    <xsd:restriction base="xsd:unsignedShort">
      <xsd:minInclusive value="1"/>
    </xsd:restriction>
  </xsd:simpleType>

</xsd:schema>

(3)　動的変更できる通信条件のパラメタ

RPC通信条件は，TP1アダプタ通信構成定義ファイル，またはTP1/Client/J環境定義ファイルに定義されています。

TP1アダプタ通信構成定義ファイル，およびTP1/Client/J環境定義ファイルの，RPC通信条件を変更できる項目を次に示します。

表2‒13　TP1アダプタ通信構成定義ファイルで変更できるパラメタ

パラメタ

説明

watch_time

応答監視時間（単位：秒）

static_host

接続先ホスト名

static_port

接続先ポート番号

host

接続先ホスト名（通信先を指定したRPCの接続先動的変更機能との互換性を確保する）

static_hostの別名のため，該当するパラメタを変更した場合はstatic_hostが変更されたことがログに出力されます。

port

接続先ポート番号（通信先を指定したRPCの接続先動的変更機能との互換性を確保する）

static_portの別名のため，該当するパラメタを変更した場合はstatic_portが変更されたことがログに出力されます。

tcpip_wait_time

メッセージ受信時の最大待ち時間（単位：秒）

表2‒14　TP1/Client/J環境定義ファイルで変更できるオペランド

オペランド

説明

dccltinquiretime

常設コネクション問い合わせ間隔最大時間

dccltdelay

最大通信遅延時間

dcwatchtim

最大応答待ち時間

dccltextend

TP1/Client/Jの機能拡張レベルの設定を指定

dcscdloadpriority

サービス要求を受け付けた窓口となるTP1/Serverを優先して負荷分散するかどうかを指定

dcwatchtiminherit

リモートAPI機能を使用したRPCを行う場合に，CUPの最大応答待ち時間をrapサーバ側に引き継ぐかどうかを指定

dcwatchtimrpcinherit

CUPの最大応答待ち時間をTP1/Server側に引き継ぐかどうかを指定

dchost

窓口となるTP1/Server

dcnamport

ネームサービスのポート番号

dcscdport

スケジュールサービスのポート番号

dcrapport

rapリスナーのポート番号

dccltconnectinf

端末識別情報として，DCCM3論理端末の論理端末名称をEBCDIKコードで指定

dcsndhost

接続するMHPが存在するノードのホスト名

dcsndport

接続するMHPのポート番号

TP1アダプタ通信構成定義ファイル，またはTP1/Client/J環境定義ファイルについては，マニュアル「サービスプラットフォーム リファレンス」の「3.4.3　TP1アダプタ通信構成定義ファイル」，および「付録A.2　TP1/Client/Jの定義」を参照してください。

2.7.7　TP1アダプタの接続先情報の動的変更

TP1アダプタの接続先は，接続先のOpenTP1のホスト名とポート番号をTP1アダプタに設定することで動的に変更できます。ビジネスプロセスで接続先のOpenTP1のホスト名とポート番号を設定しておくと，TP1アダプタを実行したときに接続先が変更されます。これによって，作成するTP1アダプタの数を削減できます。

TP1アダプタの接続先は，動的に変更できます。ビジネスプロセスで接続先を設定しておくと，TP1アダプタを実行したときに接続先が変更されます。これにより，作成するTP1アダプタの数を削減できます。

(1)　接続先動的変更の処理の流れ

TP1アダプタの接続先動的変更の処理の流れを次に示します。

要求電文内のヘッダ電文から接続先情報を取得します。

取得した接続情報を基にサービスと通信を行います。

なお，接続情報がヘッダ電文に設定されていないなど，接続先情報の取得に失敗した場合は，リクエスト処理がエラーになります。

(2)　接続先情報を動的に変更する例

接続先情報ファイルを使用して，接続先情報を動的に変更する例を説明します。

(a)　ビジネスプロセスの例

接続先情報ファイルを使用するビジネスプロセスの例を次の図に示します。

図2‒74　接続先情報ファイルを使用するビジネスプロセスの例（TP1アダプタの場合）

サービスリクエスタがビジネスプロセスにサービス部品の実行を要求します。

サービスリクエスタから送付する要求電文内のヘッダ電文に接続先情報（OpenTP1のホスト名とポート番号）を設定します。

ビジネスプロセスはXMLの要求電文を受付アクティビティで受け取ります。

ビジネスプロセスがヘッダ要求データおよび要求データを生成します。

ヘッダ要求データの接続先情報を，データ変換アクティビティなどで接続先情報変数に設定します。

ビジネスプロセスは接続先情報変数に含まれる接続先情報をTP1アダプタに設定して，サービス部品を呼び出します。

ビジネスプロセスが，サービス部品の実行結果をXMLの応答電文として構成し，応答アクティビティで返します。

サービスリクエスタへの応答が返されます。

サービスリクエスタへの応答では，XMLの応答電文が送付されます。

(3)　ユーザ定義受付を生成するWSDLの作成例

ユーザ定義受付を生成するWSDLの作成例を次に示します。

なお，この例では，接続先となる OpenTP1のホスト名とポート番号をSOAPヘッダで送付しています。

(a)　データ変換アクティビティの設定例

「図2-74　接続先情報ファイルを使用するビジネスプロセスの例（TP1アダプタの場合）」に示すビジネスプロセスで使用するデータ変換アクティビティの設定例を次に示します。

ここでは，変換元に「ヘッダ要求データ」を，変換先に「接続先」を指定しています。

図2‒75　データ変換アクティビティの設定例（TP1アダプタの場合）

また，変換のマッピングは，次の図に示すとおりに定義します。

図2‒76　変換のマッピングの設定例（TP1アダプタの場合）

(b)　接続先情報ファイルの定義

OpenTP1に接続するためのホスト名とポート番号をTP1アダプタに設定するための接続先情報ファイル（XMLスキーマ）に定義します。

サービスプラットフォームでは，接続先情報ファイルを提供しています。

接続先情報ファイルの格納先

<サービスプラットフォームのインストールディレクトリ>/CSC/schema/connection/connection_tp1_adapter.xsd

注意事項

TP1アダプタの接続先情報を動的に変更する場合，サービスプラットフォームで提供している接続先情報ファイルを使用してください。提供している接続先情報ファイルを使用しなかった場合，動作は保証されません。

接続先情報ファイルの形式

<?xml version="1.0" encoding="UTF-8"?>
<!--
 DO NOT EDIT THIS FILE.
 -->
<xsd:schema
    elementFormDefault="qualified"
    targetNamespace="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/connection/change/tp1"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="tp1Address">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="host" type="xsd:string"/>
        <xsd:element name="port" type="xsd:int"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

設定できる要素

host　〜＜文字列＞((1−255文字))

接続先のホスト名を指定します。この要素は，「通信先を指定したRPC」を利用する場合に有効になります。そのため，次の場合はこの要素は無効になります。

その他の機能（ネームサービス，スケジューラダイレクト機能，またはリモートAPI機能）を使用したRPCによって接続する場合

MHPを接続先としたTCP/IP接続をする場合

port　〜＜符号なし整数＞((0−65535))

接続先のポート番号を指定します。この要素は，「通信先を指定したRPC」を利用する場合に有効になります。そのため，次の場合はこの要素は無効になります。

その他の機能（ネームサービス，スケジューラダイレクト機能，またはリモートAPI機能）を使用したRPCによって接続する場合

MHPを接続先としたTCP/IP接続をする場合

(c)　接続先情報の設定

「図2-74　接続先情報ファイルを使用するビジネスプロセスの例（TP1アダプタの場合）」に示すビジネスプロセスで使用する接続先情報の設定例を次に示します。なお，接続先情報は，サービス呼出アクティビティのヘッダ割当変数に設定します。ここで設定した情報が，TP1アダプタで参照できる情報になります。

図2‒77　接続先情報の設定例（サービス呼出アクティビティの設定）

2.8　ファイルを扱うシステムとの接続

サービスリクエスタやビジネスプロセスからの要求を受けて，HCSCサーバ上のローカルディスクに対して直接ファイルの入出力をする場合は，ファイルアダプタを使用します。

2.8.1　ファイルアダプタを使ったファイルへのアクセス

ファイルアダプタによるファイルアクセスの実行について，次の図に示します。

図2‒78　ファイルアダプタによるファイルアクセスの実行

ファイルアダプタは，開発環境で定義します。ファイルアダプタを定義する手順の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.　サービスアダプタの定義」を参照してください。

2.8.2　ファイルアダプタを使ったファイルの読み込みと書き込み

ファイルアダプタは，サービスプラットフォームで，ファイルからデータを読み込んだり，ファイルへデータを書き込んだりするサービスアダプタです。

ファイルアダプタの目的は，ファイルを介した業務処理システムのプログラム資産をシステムで活用することです。ファイルアダプタをビジネスプロセスのアクティビティとして用いることで，ファイルの入出力を伴う既存システムとの連携など，ファイル内容に基づいた業務処理をSOAで実現できます。

ファイルアダプタは，プロセス統合での使用を目的としており，サービスリクエスタからの直接呼び出しではなく，ビジネスプロセスからの呼び出しを前提としています。

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

図2‒79　ファイルアダプタの運用例

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

他社からの注文ファイルをFTPなどで受け取ります。

ファイルの受け取りは，ファイル監視プログラムによって検知されます。

ファイル監視プログラムからサービスリクエスタが起動されます。

サービスリクエスタからSOAPなどを介して，ビジネスプロセスが起動されます。

ビジネスプロセスから呼び出されたファイルアダプタによって，注文ファイルのデータが読み込まれます。

各業務のサービスが呼び出されます。

ファイルアダプタによって，サービスの呼び出し結果が注文結果ファイルに書き込まれます。

注文結果ファイルへの書き込みが，ファイル監視プログラムによって検知されます。

注文結果ファイルが，FTPなどで転送されます。

このようなシステムによって，SOAに対応していない他社システムと連携できるようになります。

2.8.3　ファイルアダプタで使用できるファイル形式

ファイルアダプタで使用できるファイル形式を次に示します。

(1)　ファイルアダプタでXMLデータとして扱われるファイル形式

XML形式

W3Cが制定したマークアップ言語（Extensible Markup Language）で記述されたファイル形式です。HCSCサーバで使用できるXMLスキーマの適用範囲で，XML形式のファイルをサポートします。詳細は，マニュアル「サービスプラットフォーム開発ガイド 基本開発編」の「2.6.5　XMLスキーマの適用範囲」を参照してください。

(2)　ファイルアダプタでバイナリデータとして扱われるファイル形式

固定長形式

レコードの各データ要素が決められた長さを持つファイル形式です。

レングスタグ形式

レコードの各データ要素に対して，その長さを表す数値情報を付けることで可変長データを扱うファイル形式です。

図2‒80　レングスタグ形式

セパレータ形式

レコードの各データ要素の区切りに，セパレータ（デリミタ）を使用して可変長データを扱うファイル形式です。一般的な形式としてCSVファイルがあります。

2.8.4　ファイル操作が行われるときのモード

ファイルアダプタで，ファイル操作が行われるときのモードについて説明します。

(1)　読み込みモード

ファイルアダプタで，ファイルの読み込みが行われるときのモードを次に示します。読み込みができるファイルの最大サイズは500MBです。ファイルアダプタ実行環境プロパティファイルで設定を変更できます。また，0バイトのファイルは読み込みできません。ファイルアダプタでのファイルの読み込みは，HCSCサーバの管理者の権限で行われます。

一括

読み込み対象のファイル全体が読み込まれます。

(2)　書き込みモード

ファイルアダプタで，ファイルの書き込みが行われるときのモードを次に示します。ファイルアダプタでのファイルの書き込みは，HCSCサーバの管理者の権限で行われます。

新規

書き込み対象のファイルが新規に作成され，データが書き込まれます。書き込み対象のファイルがすでに存在する場合は，書き込み対象のデータで上書きされます。書き込み処理中にエラーが発生した場合，エラーが発生する直前までのデータが書き込まれます。エラーが発生するタイミングによっては，空ファイルが作成されることがあります。

追加

書き込み対象のデータが，既存のファイルに追加で書き込まれます。書き込み対象のファイルが存在しない場合は，ファイルが新規に作成され，書き込み対象のデータが書き込まれます。XML形式のファイルでは，書き込みモードに追加を指定できません。書き込み処理中にエラーが発生した場合，エラーが発生する直前までのデータが書き込まれます。ファイルが新規に作成される場合，エラーが発生するタイミングによっては，空ファイルが作成されることがあります。

2.8.5　ファイルの読み込みおよび書き込み時の排他制御

ファイルアダプタでは，ファイル操作時に排他制御を行うことで，処理が競合してデータの不整合が起こることを防止します。

排他制御は，1つのファイルアダプタ内で処理対象となるファイル単位に行われます。したがって，ファイルアダプタで処理中のファイルを外部アプリケーションから操作した場合，排他制御は行われません。また，単一のHCSCサーバで複数のファイルアダプタを使用した場合，ファイルアダプタ間の排他制御は行われません。同一形式のファイルに対しては1つのファイルアダプタを使用することを推奨します。

ファイルの読み込み時および書き込み時に行われる排他制御を次の表に示します。

表2‒15　ファイルの読み込みおよび書き込み時の排他制御

排他制御

読み込み

書き込み

参照排他（読み込み中）

○

×

更新排他（書き込み中）

×

×

（凡例）

○：処理できます。

×：処理できません（待機状態）。

(1)　参照排他

ファイルアダプタでファイルの読み込みを実行すると，参照排他が行われます。参照排他中のファイルに対しては，読み込みはできますが書き込みはできません。参照排他中のファイルに対して書き込みを行った場合，実行中の読み込み処理が終了するまで待機状態になります。

(2)　更新排他

ファイルアダプタでファイルの書き込みを実行すると，更新排他が行われます。更新排他中のファイルに対しては，読み込みおよび書き込みができません。更新排他中のファイルに対して読み込みまたは書き込みを行った場合，実行中の書き込み処理が終了するまで待機状態になります。

2.9　Object Wrapperシステムとの接続

既存のTPBrokerシステム（Object Wrapperシステム）のサービス部品を呼び出す場合は，Object Accessアダプタを使用します。

2.9.1　Object Accessアダプタを使ったObject Wrapperシステムへのアクセス

HCSCサーバからのObject Wrapperシステムのサービス部品の呼び出しを次の図に示します。

図2‒81　HCSCサーバからのObject Wrapperシステムのサービス部品呼び出し

(1)　Object Wrapperシステムとの接続のタイミング

Object Accessアダプタでは，次に示すタイミングでTPBrokerと接続します。

サービス開始時

リクエスト実行時

接続方式は，Object Accessアダプタ通信構成定義ファイルのbind_typeに指定します。

図2‒82　IIOP通信接続が発行するメソッドの処理タイミング

(2)　時間監視

Object Accessアダプタは通信先システムとの次の通信に対して時間を監視します。

コネクションの確立

リクエスト要求に対する応答

(a)　コネクションの確立

時間監視は，通信システムとのコネクション確立が完了するまでの時間を監視する場合に，設定します。指定値は，サービス単位に設定します。指定した時間を超えるとタイムアウトとなり，例外を通知します。

コネクションの確立時間監視は，Object Accessアダプタ通信構成定義ファイルのconnect_watch_timeに指定します。

時間監視の範囲を次に示します。図中のt1が時間監視の範囲です。

図2‒83　コネクション確立までの時間監視

(b)　リクエスト要求に対する応答

時間監視は，リクエスト要求を送信してから応答が返ってくるまでの時間を監視する場合に，設定します。指定値は，サービス要求のオペレーション単位に設定します。指定した時間を超えるとタイムアウトとなり，例外を通知します。

コネクションの確立時間監視は，Object Accessアダプタ通信構成定義ファイルのreturn_watch_timeに指定します。

時間監視の範囲を次に示します。図中のt2が時間監視の範囲です。

図2‒84　リクエスト送信から応答メッセージが到達するまでの時間監視

(3)　障害検知

Object Accessアダプタでは，TPBrokerの通信時に接続が切断された場合，再接続を実行しません。接続が切断された場合は，処理を中断して例外を通知します。

TPBrokerとの接続をサービス開始時に実行している場合は，再接続を障害発生以降のリクエスト要求時に実行します。

図2‒85　接続の切断時の処理概略

Object Accessアダプタで障害を検知した場合，サービスを実行したサービスリクエスタ，またはビジネスプロセスに，例外情報およびFault情報を通知します。

Object Accessアダプタでは例外情報とFault情報の障害通知を次の条件によって決定します。

例外を通知する場合

開始処理で発生した障害

IIOP通信処理で発生したIDLで定義されたユーザ例外以外

Fault情報を通知する場合

IIOP通信処理で発生したIDLで定義されたユーザ例外

2.9.2　接続時の電文の形式変換

Object Accessアダプタのサービスリクエスタとのインターフェースで使用する電文には，要求電文と応答電文（Fault情報を含む）があります。Object Wrapperで使用するIDLおよびObject WrapperのIDLと電文の形式変換について次に示します。

(1)　IDLのサポート範囲

Object AccessアダプタがサポートしているIDLを次に示します。

表2‒16　IDL定義のサポート範囲

IDL

備考

module定義

−

interface定義

継承定義は使用不可

operation定義

−

typedef定義

sequence型だけ

struct定義

−

exception定義

−

表2‒17　operation定義のサポート範囲

IDL

備考

in引数

−

out引数

−

inout引数

−

リターン値

−

raises定義

ユーザ例外は1つだけ

表2‒18　IDLデータ型のサポート範囲

IDL

備考

long

−

float

−

string

文字列長は指定不可

any

「(4) any型の扱い」を参照してください。

struct

−

sequence

配列サイズは指定不可

(2)　型変換

Object WrapperのIDLの定義型と電文で扱う型情報で変換する内容を次に示します。

表2‒19　型変換が行われるIDL型

Object WrapperのIDL

電文

typedef sequence<octet> OctSeq

xsd:string

struct Binary

xsd:base64Binary

(3)　文字コード変換

Object WrapperのIDLに定義したstring型は，SJISコードとして扱います。文字コード変換の対象には，型変換でstring型に変換される「typedef sequence<octet> OctSeq」を含みます。文字コード変換対象の，Object WrapperのIDLを次に示します。

表2‒20　文字コード変換が行われるIDL型

Object WrapperのIDL

電文

method_name

xsd:string

typedef sequence<octet> OctSeq

xsd:string

(4)　any型の扱い

Object AccessアダプタでIDLのCORBA.Anyは，単純型（primitive型）と複合型（complex型）のsequence<octet>の値が扱えます。

CORBA.Anyの電文での表現，および電文の各要素に指定できる値を次に示します。

CORBA.Anyの電文フォーマット

<xsd:complexType name="CORBA.Any">
<xsd:sequence>
<xsd:elementname="type" type="xsd:string" maxOccurs="1" minOccurs="1"/>
<xsd:elementname="value" type="xsd:string" maxOccurs="1" minOccurs="1" />
</xsd:sequence>
</xsd:complexType>

表2‒21　type要素とvalue要素の指定値

Object WrapperのIDL

type要素の値

value要素の値

long

long

-2147483648から2147483647の数字

float

float

単精度の浮動小数点文字列

typedef sequence<octet>OctSeq

EComm2.OctSeq

単数・複数の文字

struct Binary

EComm2.Binary

base64Binary表記文字列

2.10　メッセージキューとの接続

JMSプロバイダのメッセージキュー（IBM MQシステム）からMQリソースアダプタ経由でメッセージを送受信する場合は，Message Queue受付を使用します。

また，既存のメッセージキュー（IBM MQシステム）に対してメッセージを送受信する場合は，Message Queueアダプタを使用します。

2.10.1　Message Queue受付を使用したサービス部品の呼び出し

Message Queue受付を利用することで，JMSプロバイダのメッセージキュー（IBM MQ）からMQリソースアダプタを介してビジネスプロセスを呼び出すことができます。

Message Queue受付を使用したサービス部品呼び出しの流れを次の図に示します。

図2‒86　Message Queue受付を使用したJMSプロバイダ（メッセージキュー）からのサービス部品の呼び出し

Message Queue受付は，MQリソースアダプタを経由して要求電文を受け付けます。サービス部品の実行要求を受け付けたMessage Queue受付は，ビジネスプロセスを呼び出し，サービスアダプタを介して各種サービス部品を実行します。

要求電文の受け取りは，MDB（Message-Driven Bean）を使用します。

Message Queue受付からは，応答電文を返しません。

(1)　IBM MQの概要

Message Queue受付では，JMSプロバイダとしてIBM MQを利用します。IBM MQは，異機種システムのプログラム間でデータ通信をするためのメッセージキューイング型の非同期通信基盤です。

IBM MQの構成を次に示します。

図2‒87　IBM MQの構成

（凡例）

キューマネージャ：キューやリスナーをまとめる管理プログラム

キュー：JMSオブジェクトをまとめるキューオブジェクト

リスナー：キューマネージャがメッセージを受信または送信するためのリスナー

注意事項

IBM MQのキューマネージャは，初期状態ではチャネル認証によるサーバへのアクセスができません。そのため，チャネル認証を使用しないように設定を変更するか，デフォルトで設定されているチャネル認証ルールを変更する必要があります。IBM MQの設定方法については，IBM社のマニュアルを参照してください。

(2)　Message Queue受付の送信オプション

メッセージを送信する場合，送信オプション（JMSヘッダおよびプロパティ）を指定できます。Message Queue受付の送信オプションの詳細を次に示します。

(a)　JMSヘッダの詳細

送信オプション（JMSヘッダ）の設定値は，すべてString型に変換され，ヘッダ電文の中に設定されます。このとき，値がnull，または空の場合は，空タグになります。

JMSヘッダの詳細を次に示します。

表2‒22　JMSヘッダの詳細

ヘッダ名

設定内容

設定タイミング

クライアントでの設定可否

JMSDestination

メッセージが登録されるキュー名

QueueSession.createSender(Queue queue)メソッド発行時に設定されます。

×

JMSDeliveryMode

メッセージの永続性を示す値

メッセージ送信時に設定されます。

×

JMSMessageID

プロバイダによって送信される各メッセージを一意に識別するメッセージ識別子

メッセージ送信時に設定されます。

×

JMSTimestamp

メッセージの送信時刻を表す値（単位：ミリ秒）

メッセージ送信時に設定されます。

×

JMSExpiration

メッセージの有効期間となる時刻を表す値（単位：ミリ秒）

メッセージ送信時に設定されます。

×

JMSRedelivered

メッセージが再配送中であるかどうかを示す値

アプリケーションに配送済みのメッセージがリカバリされたなどで再度配送する必要があるときに設定されます。

×

JMSPriority

メッセージのプライオリティ

QueueSender.setPriority()メソッド，またはQueueSender.send()メソッドで指定できます。

○

JMSReplyTo

応答先のあて先

Message.setJMSReplyTo()メソッド発行時に設定されます。

○

JMSCorrelationID

あるメッセージをほかのメッセージと関連づけるための相関識別子

Message.setJMSCorrelationID()メソッド発行時に設定されます。

○

JMSType

メッセージが送信されるときに，アプリケーションによって提供されるメッセージタイプ

Message.setJMSType()メソッド発行時に設定されます。

○

（凡例）

○：指定できます。

×：指定できません。

(b)　プロパティの詳細

メッセージのプロパティは，JMSプロバイダによって設定されるプロパティと，クライアントでユーザが設定できるプロパティで構成されます。

●JMSプロバイダによって設定されるプロパティ

JMSプロバイダによって設定されるプロパティには，JMS標準プロパティとIBM MQで設定されるプロパティがあります。どちらのプロパティも設定されている項目については，すべてヘッダ電文に設定されます。

JMS標準プロパティ

JMS標準のプロパティは，「JMSX」が項目名のプレフィックスに付いているプロパティです。

JMS標準プロパティの一覧を次の表に示します。

表2‒23　JMS標準プロパティの一覧

項目名

説明

JMSXUserID

メッセージの送信者のユーザID

JMSXAppID

メッセージの送信アプリケーションのID

JMSXDeliveryCount

メッセージの再受信回数

JMSXGroupID

メッセージが属するグループのID

JMSXGroupSeq

グループ内でのメッセージ順序番号

JMSXProducerTXID

トランザクション識別子

JMSXConsumerTXID

トランザクション識別子

JMSXRcvTimestamp

メッセージ受信時間

JMSXState

プロバイダ内部で使用する項目

IBM MQで設定されるプロパティ

IBM MQで設定されるプロパティは，プロバイダ用プロパティの中に含まれます。プロバイダ用プロパティには，「JMS_」が項目名のプレフィックスに付いています。その中で，「JMS_IBM_」が項目名のプレフィックスに付いているものがIBM MQのプロパティです。

●ユーザが設定するプロパティ

ユーザが任意に設定できるプロパティは，「set<型名>Property(String name,<型名> value)」メソッドを使用して設定します。

プロパティに設定された値はすべてString型に変換し，ヘッダ電文の中に設定されます。

プロパティに設定できるデータ型の一覧を次の表に示します。

表2‒24　プロパティに設定できるデータ型の一覧

データ型

設定するメソッド

Boolean

setBooleanProperty(String name, boolean value)

Byte※1

setByteProperty(String name, byte value)

Short

setShortProperty(String name, short value)

Integer

setIntProperty(String name, int value)

Long

setLongProperty(String name, long value)

Float

setFloatProperty(String name, float value)

Double

setDoubleProperty(String name, double value)

String

setStringProperty(String name, String value)

Object※2

setObjectProperty(String name, Object value)

注※1

Byte型の値を設定すると，Integer型の数値に変換されたものを文字列としてヘッダ電文に設定します。設定される数値の範囲は-127〜127です。

注※2

データ型にObjectを設定すると，すべてのデータ型（Boolean，Byte，Short，Integer，Long，Float，DoubleおよびString）が使用できます。

(3)　Message Queue受付とMQリソースアダプタとの関係

MQリソースアダプタは，JMSプロバイダ（IBM MQシステム）からのメッセージをMessage Queue受付に渡すためのリソースアダプタです。

MQリソースアダプタとMessage Queue受付の接続関係は，1つのリソースアダプタに対して複数の受付を関連づけることができますが，1つの受付に対して複数のリソースアダプタを関連づけることができません。

MQリソースアダプタとMessage Queue受付の関連づけは，Message Queue受付定義ファイルで指定します。指定した内容は，Message Queue受付を起動したときに有効になります。このとき，Message Queue受付と関連づけをするMQリソースアダプタを事前に起動しておく必要があります。関連づけをするMQリソースアダプタが起動されていないと，Message Queue受付は起動できないため，Message Queue受付定義ファイルの設定内容も有効になりません。

Message Queue受付とMQリソースアダプタの接続関係を次に示します。

(a)　構築できる接続関係（MQリソースアダプタの場合）

構築できる接続関係は次のどちらかです。

リソースアダプタと受付が1：1の接続関係の場合

リソースアダプタと受付が1：nの接続関係の場合

例を次に示します。

（例1）リソースアダプタと受付が1：1の接続関係の場合

説明

1つのMQリソースアダプタに関連づいているMessage Queue受付は1つ

1つのMessage Queue受付に関連づいているMQリソースアダプタは1つ

（例2）リソースアダプタと受付が1：nの接続関係の場合

説明

1つのMQリソースアダプタに関連づいているMessage Queue受付は複数

1つのMessage Queue受付に関連づいているMQリソースアダプタは1つ

(b)　構築できない接続関係（MQリソースアダプタの場合）

1つの受付に対して複数のリソースアダプタを指定できないため，リソースアダプタと受付の接続関係がn：1の構成は構築できません。

例を次に示します。

（例）

説明

1つのMQリソースアダプタに関連づいているMessage Queue受付は１つ

1つのMessage Queue受付に関連づいているMQリソースアダプタは複数

(4)　Message Queue受付とキューとの関係

キューは，JMSオブジェクトをまとめるキューオブジェクトで，キューマネージャによって管理されます。

キューとMessage Queue受付の接続関係は，1つのキューに対して複数の受付を関連づけることができますが，1つの受付に対して複数のキューを関連づけることができません。

Message Queue受付とキューの接続関係を次に示します。

(a)　構築できる接続関係（キューの場合）

構築できる接続関係は次のどちらかです。

キューと受付の接続関係が1：1の場合

キューと受付の接続関係が1：nの場合

例を次に示します。

（例1）キューと受付の接続関係が1：1の場合

説明

1つのキューマネージャの中に存在するキューは1つ

1つのキューに対して関連づけられたMessage Queue受付は1つ

（例2）キューと受付の接続関係が1：nの場合

説明

1つのキューマネージャの中に存在するキューは1つ

1つのキューに対して関連づけられたMessage Queue受付は2つ

(b)　構築できない接続関係（キューの場合）

1つの受付に対して複数のキューを指定できないため，キューと受付の接続関係がn：1の構成は構築できません。

（例1）キューマネージャが1つの場合

説明

1つのキューマネージャの中に存在するキューは2つ

キュー1およびキュー2に対して関連づけられたMessage Queue受付は1つ

（例2）キューマネージャが複数の場合

説明

2つのキューマネージャが存在

それぞれのキューマネージャの中に存在するキューは1つずつ

キュー1およびキュー2に対して関連づけられたMessage Queue受付は1つ

(5)　Message Queue受付とビジネスプロセスとの関係

ビジネスプロセスを作成するときは，受付アクティビティの通信モデルをMessage Queue受付の通信モデルと同一にする必要があります。

ビジネスプロセスの永続化については，永続化でも非永続化でも設定できます。

ただし，非永続化を設定すると，障害発生時にメッセージの二重配信が発生するおそれがあるので注意が必要です。

ビジネスプロセスとMessage Queue受付の接続関係は，1つのビジネスプロセスに対して複数の受付を関連づけることができますが，1つの受付に対して複数のビジネスプロセスを関連づけることができません。

Message Queue受付とビジネスプロセスの接続関係を次に示します。

(a)　構築できる接続関係（ビジネスプロセスの場合）

構築できる接続関係は次のどちらかです。

ビジネスプロセスと受付の接続関係が1：1の場合

ビジネスプロセスと受付の接続関係が1：nの場合

例を次に示します。

（例1）ビジネスプロセスと受付の接続関係が1：1の場合

説明

1つのMessage Queue受付に関連づけるビジネスプロセスは1つ

1つのビジネスプロセスに関連づけるMessage Queue受付は1つ

（例2）ビジネスプロセスと受付の接続関係が1：nの場合

説明

1つのMessage Queue受付に関連づけるビジネスプロセスは1つ

1つのビジネスプロセスに関連づけるMessage Queue受付は複数

(b)　構築できない接続関係（ビジネスプロセスの場合）

1つの受付に対して複数のビジネスプロセスを定義できないため，ビジネスプロセスと受付の接続関係がn：1の構成は構築できません。

例を次に示します。

（例）

説明

1つのMessage Queue受付に関連づけるビジネスプロセスは複数

1つのビジネスプロセスに関連づけるMessage Queue受付は1つ

(6)　Message Queue受付の構成例

Message Queue受付では，使用する通信モデルに応じてさまざまなシステム構成を実現できます。

ここでは，次の場合の構成例を次に示します。

Message Queue受付を非同期の通信モデルで使用する場合

Message Queue受付を同期の通信モデルで使用する場合

(a)　Message Queue受付を非同期の通信モデルで使用する場合

前提条件

Message Queue受付を定義したビジネスプロセスを作成します。

Message Queue受付の通信モデルを「非同期」で定義します。

構成例

Message Queue受付とビジネスプロセスの構成の例を次の図に示します。

説明

MQクライアントのプログラムから，IBM MQサーバのキューにメッセージを登録します。

IBM MQサーバからMessage Queue受付（HCSCサーバ）に対し，メッセージが送信されます。

Message Queue受付は，ビジネスプロセスを呼び出します。

すべてのアクティビティの処理が終了したあと，Message Queue受付も処理を終了します。

IBM MQサーバがトランザクションをコミットし，キューからメッセージを削除します。

参考

この構成例の場合，リクエスト処理が完了するまで，メッセージが保持されます。このため，ビジネスプロセスが処理している間は，キューからメッセージは削除されません。ただし，二重配信防止の処理が実行された場合，またはロールバック制限でメッセージが移動した場合は，キューからメッセージが削除されます。メッセージの二重配信防止については，「(8) Message Queue受付使用時のメッセージの二重配信防止」を参照してください。

(b)　Message Queue受付を同期の通信モデルで使用する場合

前提条件

Message Queue受付を定義したビジネスプロセスを作成します。

Message Queue受付の通信モデルを「同期」で定義します。

構成例

Message Queue受付とビジネスプロセスの構成の例を次の図に示します。

説明

MQクライアントのプログラムから，IBM MQサーバのキューにメッセージを登録します。

IBM MQサーバからMessage Queue受付（HCSCサーバ）に対し，メッセージが送信されます。

Message Queue受付は，ビジネスプロセスを呼び出します。

応答アクティビティの処理が終了したあと，応答アクティビティのあとの実行に必要な情報をReliable Messagingまたは非同期EJBへ格納し，Message Queue受付も処理を終了します。

IBM MQサーバがトランザクションをコミットし，キューからメッセージを削除します。

Reliable Messagingまたは非同期EJBに格納した情報に従って，応答アクティビティのあとに設定されたアクティビティが実行されます。

参考

この構成例の場合，ビジネスプロセスの処理が終了する前に，キューからメッセージを削除できます。ただし，応答アクティビティのあとのビジネスプロセスの処理で例外が発生した場合に，キューからメッセージが削除されているので，リクエストを再送信する必要があります。

(7)　Message Queue受付使用時のトランザクション

Message Queue受付では，例外発生時はキューをロールバックするため，IBM MQのキューマネージャと同一のトランザクションを使用する必要があります。そのため，Message Queue受付のトランザクションはコンテナ管理のトランザクションを使用します。それによって，トランザクションのコミットはIBM MQのキューがコミットされるタイミングと同時となります。

Message Queue受付を使用した場合のトランザクションの範囲を次の図に示します。

図2‒88　Message Queue受付を使用した場合のトランザクションの範囲

Message Queue受付は，IBM MQのキューマネージャと同一のトランザクションを使用して処理しますが，ビジネスプロセスは，IBM MQのキューマネージャとは異なるトランザクションで処理します。そのため，Message Queue受付で処理が異常終了し，ロールバックを実行するためにメッセージがキューの先頭に戻った場合でも，ビジネスプロセスのトランザクションが正常終了していることがあります。このような状態のときにロールバックによって再びメッセージが送信されると，一度処理を実行したビジネスプロセスで再び同じ処理が実行されてしまうことになります。このような処理を防ぐには，メッセージの二重配信防止の処理をしてください。メッセージの二重配信防止については，「(8) Message Queue受付使用時のメッセージの二重配信防止」を参照してください。

(8)　Message Queue受付使用時のメッセージの二重配信防止

リクエスト処理が異常終了した場合，ロールバックを実行するためにメッセージはキューの先頭に戻り，再びメッセージが送信されることで，一度処理を実行したビジネスプロセスが再び処理されてしまうことがあります。

Message Queue受付では，メッセージの二重配信防止の設定をすることで，リクエスト処理が異常終了した場合に，メッセージの再送信による実行済みビジネスプロセスの再実行を防止します。

(a)　二重配信防止の前提条件

次に示す条件をすべて満たす場合に，二重配信防止のチェックをします。

データベースを使用している。

実行履歴が有効になっている（ビジネスプロセスのプロパティで，ステータスの永続化が「yes」になっている）。

(b)　二重配信防止使用時の注意点

二重配信防止を設定している場合の注意点を次に示します。

実行履歴の管理が必要なため，データベース容量の見積もりが必要です。

システム例外が発生したビジネスプロセスは，再実行する必要があります。

(c)　ビジネスプロセスで障害が発生したときの対策

ビジネスプロセスで発生する主な障害の例を挙げ，二重配信防止を設定している場合の動作および対処方法を説明します。

（例1）メッセージ関連づけ情報テーブルへ登録前に障害が発生した場合

この場合の実行履歴の表示，リクエストメッセージの状態および対処方法を次に示します。

実行履歴の表示

未実行

リクエストメッセージの状態

ロールバックされ，再度リクエストメッセージが送信されます。

電文不正（nullなど）が原因だった場合は，指定したロールバックの実行回数分だけロールバックを続けます。

対処方法

ロールバックの制限回数を設定してください。

障害の発生するメッセージを除去してください。

（例2）ビジネスプロセスの処理実行中に障害が発生した場合

この場合の実行履歴の表示，リクエストメッセージの状態および対処方法を次に示します。

実行履歴の表示

実行中またはエラー

リクエストメッセージの状態

障害発生時にロールバックされ，2回目のリクエストメッセージ送信時に二重配信防止のチェックによって正常終了としてコミットされます。

対処方法

再実行コマンドまたは運用環境の画面を使用し，ビジネスプロセスを再実行してください。

（例3）ビジネスプロセスの処理終了後に障害が発生した場合

この場合の実行履歴の表示，リクエストメッセージの状態および対処方法を次に示します。

実行履歴の表示

正常終了

リクエストメッセージの状態

障害発生時にロールバックされ，2回目のリクエストメッセージ送信時に二重配信防止のチェックによって正常終了としてコミットされます。

対処方法

必要ありません。

（例4）ビジネスプロセスの応答アクティビティ処理終了後に障害が発生した場合

この場合の実行履歴の表示，リクエストメッセージの状態および対処方法を次に示します。

実行履歴の表示

実行中

リクエストメッセージの状態

応答アクティビティの処理終了後に，キューはコミットされるため，リクエストメッセージが送信されることはありません。

対処方法

再実行コマンドまたは運用環境の画面を使用し，応答アクティビティのあとのアクティビティを再実行してください。

(9)　メッセージのロールバック回数の設定

Message Queue受付では，リクエスト処理時に障害が発生した場合，必ずロールバックします。これは，キューマネージャのデッドレターキューまたはキューのバックアウトリキューに指定されたキューへメッセージを移動させることで，無限ループを防ぐためです。

ロールバック回数は，IBM MQのキューマネージャおよびキューで設定します。

なお，設定方法については，IBM MQのマニュアルを参照してください。

●キューマネージャで設定する項目

キューマネージャで設定するロールバック関連の設定項目を次に示します。

表2‒25　キューマネージャで設定するロールバック関連の設定項目

設定項目

設定内容

設定可能な値

デフォルト値

DEADQ

デッドレターキュー名

キュー名

SYSTEM.DEAD.LETTER.QUEUE

●キューで設定する項目

キューで設定するロールバック関連の設定項目を次に示します。

表2‒26　キューで設定するロールバック関連の設定項目

設定項目

設定内容

設定可能な値

デフォルト値

BOTHRESH

バックアウトの閾値

0〜999999999

0

BOQNAME

バックアウトリキュー名

キュー名

なし

注意事項

クライアントで設定するQueueSender#sendパラメタに値（メッセージを保持する時間）が指定されている場合は，注意が必要です。メッセージをデッドレターキューに移動しても，QueueSender#sendパラメタに指定されている時間を過ぎるとメッセージは削除されます。

(10)　同時実行数の設定

Message Queue受付では，同時実行数を設定することで，同時に複数のリクエストを処理できます。

同時実行数は，Message Queue受付およびMQリソースアダプタで設定します。

(a)　Message Queue受付の設定

次に示すMessage Queue受付定義ファイルのプロパティに設定します。

pooled-instance.maximumプロパティ

activation-config.maxPoolDepthプロパティ

(b)　MQリソースアダプタの設定

次に示すMQリソースアダプタのアプリケーション統合属性ファイルの要素に値を設定します。

//hitachi-connector-property/resourceadapter/config-property[./config-property-name='maxConnections'] ../config-property-value

//hitachi-connector-property/resourceadapter/property[./property-name='MaxTPoolSize'] ../property-value

2.10.2　Message Queueアダプタを使ったメッセージキューへのアクセス

Message Queueアダプタによるメッセージ送受信について，次の図に示します。

図2‒89　Message Queueアダプタによるメッセージ送受信の実行

注意事項

Message Queueアダプタはビジネスプロセスからの要求ごとにコネクション解放処理を実行しますが，実際には，リソースアダプタのコネクションプール機能によって一定時間（デフォルト5分）リソースアダプタとIBM MQ間のコネクションは切断されません。

Connector属性ファイルの指定（デフォルトは切断しない）に依存します。

コネクション解放処理でコネクションの解放に失敗すると，Message Queueアダプタは，コネクション解放状態となりますが，接続先のJMSプロバイダシステムではコネクションの解放を検知していない場合があります。そのため，コネクション状態の不整合が発生し，次の通信処理が失敗する可能性があります。その場合は接続先JMSプロバイダシステムでコネクション確立状態を1度初期化する対応が必要です。

(1)　Message Queueアダプタの送信オプション

Message Queueアダプタのメッセージ送信機能は，ビジネスプロセスからのメッセージ送信要求に従い，リソースアダプタを経由し，JMSプロバイダとコネクション接続およびセッション設定を行い，JMSプロバイダへメッセージを送信する機能です。

メッセージの種類は，XML形式メッセージおよびバイナリ形式メッセージを送信できます。

メッセージを送信する場合，送信オプション（JMSプロパティ）を指定できます。Message Queueアダプタ送信オプション一覧を次に示します。

表2‒27　Message Queueアダプタ送信オプション一覧

項目

送信オプションの概要

指定方法

電文

定義

メッセージ送信先

（JMSDestination）

メッセージの送信キュー。

○

○

メッセージ保持時間

（JMSExpiration）

メッセージの保持時間。メッセージ保持時間とは，JMSプロバイダの送信キューに保持し続ける時間のことです。

×

○

メッセージ永続性

（JMSDeliveryMode）

メッセージの永続性。メッセージ永続性とは，システム障害後，またはJMSプロバイダを再開した場合など，メッセージをキューに保持するかどうかの指定です。

×

○

メッセージ識別ID

（JMSMessageID）

メッセージを識別するID。

IBM MQ Resource Adapterを使用する場合，任意の情報が設定されます。

−

−

タイムスタンプ

（JMSTimestamp）

メッセージのタイムスタンプ。

−

−

報告メッセージ送信先

（JMSReplyTo）

報告メッセージの送信キュー。

×

×

メッセージタイプ

（JMSType）

メッセージタイプ。

×

○

相関識別子

（JMSCorrelationID）

メッセージの相関識別子。

×

△

優先度

（JMSPriority）

メッセージの優先度。IBM MQ Resource Adapterの場合，4が設定されます。

−

−

（凡例）　指定方法：

電文：ビジネスプロセスからの要求電文による指定の有無。

定義：Message Queueアダプタ通信構成定義ファイルによる指定の有無。

○　：指定できます。

△　：メッセージ相関識別子のプレフィックスだけ指定できます。

　　　メッセージ相関識別子を送信する場合，Message Queueアダプタが自動生成します。

×　：指定できません。

−　：Message Queueアダプタでは設定しない。リソースアダプタの仕様に依存します。

メッセージ相関識別子を設定したメッセージ送信は，「2.10.2(2)　メッセージ相関識別子の生成方法」を参照してください。

メッセージ送信機能の概要を次に示します。

図2‒90　メッセージ送信機能

Message Queueアダプタは，ビジネスプロセスからのメッセージ送信要求を受けてコネクションを接続します。

コネクション接続後，送信キューとのセッションを設定します。

メッセージ送信要求を実行し，メッセージを送信キューに格納します。Message Queueアダプタ通信構成定義ファイルに送信オプションの指定がある場合，送信オプションを設定してメッセージを送信します。

メッセージ送信完了後，セッションを解放します。

JMSプロバイダとのコネクションを切断します。

コネクション切断後，メッセージ送信応答をビジネスプロセスに返します。

(2)　メッセージ相関識別子の生成方法

Message Queueアダプタは，Message Queueアダプタ通信構成定義ファイルの<id_type>タグでType2が指定されている場合，メッセージ相関識別子を自動的に生成し送信メッセージに付与します。

メッセージ相関識別子は，プレフィックスとMessage Queueアダプタ固有情報から構成されています。メッセージ相関識別子の生成方法は，プレフィックスを付与する場合としない場合の2つの方法があります。

なお，Message Queueアダプタ固有情報は，Message Queueアダプタが設定する情報です。

(a)　プレフィックスを付与しない場合

メッセージ相関識別子にプレフィックスを付与しない場合は，<JMSCorrelID_PFX>タグの指定がない場合です。

この場合，先頭6バイトを0（ゼロ）パディングしたものと，Message Queueアダプタ固有情報を合わせてメッセージ相関識別子とします。

図2‒91　メッセージ相関識別子の生成方法（プレフィックスなし）

(b)　プレフィックスを付与する場合

メッセージ相関識別子にプレフィックスを付与する場合は，<JMSCorrelID_PFX>タグが指定されている場合に，<JMSCorrelID_PFX>タグ値をメッセージ相関識別子の一部とします。プレフィックスは最大で6バイト指定できますが，6バイト未満の場合は，先頭から0（ゼロ）パディングして6バイトとします。例えば，<JMSCorrelID_PFX>タグの指定値が”ABC”の場合，”000ABC”をプレフィックス部分に設定します。

このプレフィックスとMessage Queueアダプタ固有情報を合わせてメッセージ相関識別子とします。

図2‒92　メッセージ相関識別子の生成方法（プレフィックスあり）

参考

メッセージ相関識別子を設定したメッセージ送信が失敗した場合，データトレースから送信メッセージおよびメッセージ相関識別子を特定できます。

(3)　Message Queueアダプタ使用時のトランザクション

リソースアダプタで提供されるトランザクションサポートレベルは「LocalTransaction」または「XATransaction」を指定してください。ただし，「LocalTransaction」はビジネスプロセスでステータスの永続化をしない場合だけ指定できます。「NoTransaction」は指定できません。

「LocalTransaction」または「XATransaction」を指定すると，JTA（Java Transaction API）と関連を持ちます。例えば，JTAのトランザクションタイムアウト指定値がMessage Queueアダプタ通信構成定義ファイルのメッセージ受信応答監視時間（receive_timeout）より短い場合，JTAのトランザクションタイムアウト指定値でタイムアウトします。

ビジネスプロセスからメッセージ受信要求またはメッセージ送受信要求を受けると，Message Queueアダプタはメッセージ受信要求を発行します。このメッセージ受信要求に対してリソースアダプタが一定時間内にメッセージを受信できない場合，リソースアダプタはメッセージ受信応答監視時間のタイムアウトとなります。リソースアダプタからの通知に従い，Message Queueアダプタは，ビジネスプロセスへFault応答情報を通知します。また，ビジネスプロセスからブラウズ・メッセージ受信要求を受け，ブラウズ・メッセージ受信要求を行いますが，受信キューにメッセージが存在しない場合も，ビジネスプロセスへFault応答情報を通知します。

フォルトが発生したときの処理の定義については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「5.4.4　フォルト処理を定義する」を参照してください。

(4)　メッセージ送信や受信で使用するJMS API

(a)　メッセージ送信

javax.jms.BytesMessageとjavax.jms.TextMessageの送信をサポートしています。

Message Queueアダプタは次のメソッドを使用して，メッセージインスタンスにデータを書き込みます。

javax.jms.TextMessageの場合：javax.jms.TextMessage#setText()

javax.jms.BytesMessageの場合：javax.jms.BytesMessage#writeBytes()

(b)　メッセージ受信，またはブラウズ・メッセージ受信

javax.jms.BytesMessageとjavax.jms.TextMessageの受信をサポートしています。

Message Queueアダプタは次のメソッドを使用して，メッセージインスタンスからデータを読み取ります。

javax.jms.TextMessageの場合：javax.jms.TextMessage#getText()

javax.jms.BytesMessageの場合：javax.jms.BytesMessage#readBytes()

(5)　Message Queueアダプタのオペレーション動的変更

Message Queueアダプタの実行オペレーションをビジネスプロセス内で動的に変更できます。

Message Queueアダプタのオペレーション動的変更の詳細については，「2.22　TP1アダプタおよびMessage Queueアダプタのオペレーション動的変更機能」を参照してください。

2.11　FTPクライアントおよびFTPサーバとの接続

FTP受付，FTPアダプタ，およびファイル操作アダプタを使用することで，クライアント・サーバ間のFTPによるファイルの送受信をサービスプラットフォーム上で中継できます。

FTP受付，FTPアダプタ，およびファイル操作アダプタの機能については，「8.　FTPと連携してファイルを転送する機能（FTP連携）」を参照してください。また，FTP受付の定義については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「2.4　FTP受付の定義」を，FTPアダプタ，およびファイル操作アダプタの定義については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.　サービスアダプタの定義」をそれぞれ参照してください。

2.11.1　FTPと連携したファイルの転送

FTPによるファイルの送受信の流れを次の図に示します。

図2‒93　FTPによるファイルの送受信の流れ

図中の1.〜3.について説明します。

FTPクライアントからのリクエスト受付

FTPインバウンドアダプタおよびFTP受付を使用して，FTPクライアントからのファイル転送要求を受け付けます。FTPインバウンドアダプタでは，FTPクライアントの認証，ファイル転送処理などの処理を行います。FTPクライアントからのファイル転送要求は，FTPインバウンドアダプタを経由してFTP受付に送られます。そのあと，FTP受付からビジネスプロセスが呼び出されます。

ファイルの送受信は，FTP受付が作成するHCSCサーバ上の作業フォルダを利用して行われます。

ファイルのデータ変換，複製，および削除

送信側のファイル形式と受信側のファイル形式が異なる場合，ファイル操作アダプタを使用してファイルのレイアウト変換，および文字コード変換を行います。

また，ファイル操作アダプタは，HCSCサーバ上の作業フォルダや任意のフォルダにアクセスし，フォルダ間のファイルの複製や削除，作業フォルダの削除などの操作を行います。

ファイル操作アダプタはビジネスプロセスから呼び出されます。

FTPサーバとの接続

FTPアダプタを使用して，FTPサーバとの接続や作業フォルダとFTPサーバとの間のファイル送受信を行います。

FTPアダプタはビジネスプロセスから呼び出されます。

2.12　Kafkaとの接続

サービスプラットフォームでは，Apache Kafkaと連携してメッセージの送受信をする機能を提供しています。メッセージの受信には，Kafka受付およびKafkaインバウンドアダプタを使用します。メッセージの送信には，Kafkaアダプタを使用します。

Apache Kafkaと連携したメッセージの送受信の流れを次の図に示します。

図2‒94　Apache Kafkaと連携したメッセージの送受信の流れ

メッセージの受信

図中の1.〜4.について説明します。

Kafkaインバウンドアダプタが，Apache Kafkaからメッセージを取得します。

Kafkaインバウンドアダプタが，取得したメッセージをKafka受付に渡します。

Kafka受付が，ビジネスプロセスにメッセージを渡します。

ビジネスプロセス内で，データ変換アクティビティなどを使用して，メッセージを編集します。

メッセージの送信

Kafkaアダプタは，ビジネスプロセスからのメッセージ送信要求に従って，Apache Kafkaにメッセージを送信します。

2.12.1　Kafka受付の機能

Kafka受付を利用することで，KafkaからKafkaインバウンドアダプタを経由してメッセージを取得し，ビジネスプロセスに渡すことができます。また，ビジネスプロセス内でデータ変換アクティビティなどを使用してメッセージのデータを編集することもできます。

Kafka受付を利用したデータの流れを次に示します。ここでは，Kafkaから取得したメッセージを「レコード」と表記します。

図2‒95　Kafka受付を利用したデータの流れ

図中の1.〜6.について説明します。

Kafkaインバウンドアダプタから，インバウンドアダプタ連携を使用してレコードを受け取ります。

Kafkaインバウンドアダプタの詳細については，「2.12.3　Kafkaインバウンドアダプタの機能」を参照してください。

受け取ったレコードから要求電文を作成します。

要求電文の作成については，「(3)　要求電文の作成」を参照してください。

Kafka受付からビジネスプロセスに作成した要求電文を渡します。

ビジネスプロセスから応答が返ります。

Kafkaインバウンドアダプタに返却する応答データを作成します。

Kafka受付やビジネスプロセスで例外が発生した場合は，メッセージ処理でエラーとなったレコードの情報（トピック・パーティション・オフセット）を応答データに設定して，Kafkaインバウンドアダプタに返却します。すべてのレコードの処理が正常終了した場合，応答データには何も設定されません。

Kafkaインバウンドアダプタに応答データを返却します。

(1)　Kafka受付の同時実行数

Kafka受付の同時実行数は1つです。同時実行数は変更できません。

(2)　Kafka受付で使用できる通信モデル

Kafka受付の通信モデルは，非同期通信です。通信モデルに「同期」を設定した場合の動作は保証されません。

(3)　要求電文の作成

Kafka受付は，Kafkaインバウンドアダプタから渡されたレコードから，要求電文を作成します。

Kafka受付の要求電文の形式については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「2.8.2　Kafka受付の電文フォーマットを作成する」を参照してください。

(a)　レコードのキーおよび値の設定

Kafkaインバウンドアダプタから渡されたレコードのキーおよび値には，Kafka受付定義ファイルで指定したデシリアライザ（urecp-kafka.record-binary.encoding）によってデシリアライズされた値が設定されます。要求電文（ヘッダ）に設定するレコードのキー，および要求電文（ボディ）に設定するレコードの値には，レコードから取得した値を設定します。

レコードのキーがバイナリ形式のデータの場合は，バイナリ形式のデータのエンコーディングを行い，エンコーディング後の値を要求電文に設定します。

デシリアライザの設定については，マニュアル「サービスプラットフォーム リファレンス」の「3.14.1　Kafka受付定義ファイル」を参照してください。

(b)　バイト配列形式のデータのエンコーディング

レコードのキーがバイト配列形式の場合は，Kafka受付定義ファイルのurecp-kafka.record-binary.encodingの設定値に応じてエンコードされます。エンコードされたレコードのキーの値は，要求電文の対応する要素値に設定されます。エンコードは，バイト配列の長さが1以上のときに行います。

また，レコードのヘッダの値は，文字セット「UTF-8」を使用してデコードされます。デコードされたレコードのヘッダの値は，ヘッダ電文の対応する要素値に設定されます。

(c)　レコードのデータ型とデシリアライザの対応

レコード送信時のシリアライズする前のレコードのキーおよびレコードの型と，Kafka受付定義ファイルで設定するデシリアライザの対応を次に示します。レコードのキーおよびレコードの型と，デシリアライザの設定が一致しない場合は，値の取得時にエラーが発生する，または意図しない値になることがあります。

表2‒28　レコードのキーおよびレコードの型とデシリアライザの対応

レコードのキーおよびレコードの型

デシリアライザの設定

java.lang.String

StringDeserializer

byte[]

ByteArrayDeserializer

(d)　レコードの値とデシリアライザの対応

電文形式およびレコードの値に応じて，次のデシリアライザを設定してください。

表2‒29　レコードの値とデシリアライザの対応

電文形式

レコードの値

デシリアライザの設定

XML

JSON形式

StringDeserializer

XML形式

バイナリ

CSV形式

ByteArrayDeserializer

文字列

バイナリデータ

any

文字列

ByteArrayDeserializer

バイナリデータ

(4)　ビジネスプロセスで処理できるレコード数

Kafkaインバウンドアダプタから渡されるレコードには，1つのレコードの情報が格納されています。そのため，ビジネスプロセスで処理できるレコード数は1つです。

(5)　ビジネスプロセスとの関係

ビジネスプロセスとKafka受付が構築できる接続関係は次のどちらかです。

ビジネスプロセスとKafka受付の接続関係が1：1の場合

ビジネスプロセスとKafka受付の接続関係が1：nの場合

例を次に示します。

（例1）ビジネスプロセスとKafka受付の接続関係が1：1の場合

説明

1つのKafka受付に関連づけるビジネスプロセスは1つ

1つのビジネスプロセスに関連づけるKafka受付は1つ

（例2）ビジネスプロセスとKafka受付の接続関係が1：nの場合

説明

1つのKafka受付に関連づけるビジネスプロセスは1つ

1つのビジネスプロセスに関連づけるKafka受付は複数

(6)　Kafkaインバウンドアダプタとの関係

KafkaインバウンドアダプタとKafka受付が構築できる接続関係は次のどちらかです。

KafkaインバウンドアダプタとKafka受付が1：1の接続関係の場合

KafkaインバウンドアダプタとKafka受付が1：nの接続関係の場合

例を次に示します。

（例1）KafkaインバウンドアダプタとKafka受付が1：1の接続関係の場合

説明

1つのKafkaインバウンドアダプタに関連づいているKafka受付は1つ

1つのKafka受付に関連づいているKafkaインバウンドアダプタは1つ

（例2）KafkaインバウンドアダプタとKafka受付が1：nの接続関係の場合

説明

1つのKafkaインバウンドアダプタに関連づいているKafka受付は複数

1つのKafka受付に関連づいているKafkaインバウンドアダプタは1つ

(7)　Kafka受付使用時のトランザクション

ビジネスプロセスを呼び出すときのKafka受付のトランザクションを次に示します。

図2‒96　Kafka受付のトランザクション

2.12.2　Kafka受付のJSON-XML変換機能

Kafka受付のJSON-XML変換機能では，JSON形式のレコードの値をビジネスプロセスで処理できるXML形式に変換します。Kafka受付では，レコードの値がJSON形式かどうかはチェックしないで，レコードの値がJSON形式とみなして変換します。

レコードの値をJSON-XML形式に変換する処理の流れを次に示します。

図2‒97　レコードの値をJSON-XML形式に変換する流れ

図中の1.〜3.について説明します。

KafkaインバウンドアダプタからKafka受付が呼び出され，Kafkaインバウンドアダプタからレコード情報が渡されます。

Kafka受付のJSON-XML変換機能を使用して，レコードの値（JSON形式のデータ）をXML形式のデータに変換します。

Kafka受付がビジネスプロセスを呼び出します。

ビジネスプロセスに渡す要求電文（ボディ）は，2.で作成したXML形式のデータです。

Kafka受付でJSON-XML変換を行う場合は，Kafka受付定義ファイルのurecp-kafka.json2xmlで指定します。Kafka受付定義ファイルのurecp-kafka.json2xmlについては，マニュアル「サービスプラットフォームリファレンス」の「3.14.1　Kafka受付定義ファイル」を参照してください。

JSON-XML変換機能では，変換処理の動作定義を設定できます。Kafka受付定義ファイルにJSON-XML変換定義ファイルが指定されていた場合，JSON-XML変換定義ファイルの設定がJSON-XML変換機能に反映されます。なお，JSON-XML変換定義ファイルが指定されていない場合は，デフォルト値が設定されます。JSON-XML変換定義ファイルは，Kafka受付の起動時に読み込まれます。

JSON-XML変換定義ファイルの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「3.18.1　JSON-XML変換定義ファイル」を参照してください。

2.12.3　Kafkaインバウンドアダプタの機能

KafkaインバウンドアダプタはKafkaからメッセージを受信するアダプタです。サービスプラットフォームからKafkaに接続し，Brokerのトピックからメッセージとしてレコードを取得して，Kafka受付を呼び出します。

Kafkaインバウンドアダプタが接続できるApache Kafkaのバージョンは，2.6.0〜2.8.0です。また，Kafkaインバウンドアダプタと連携できるアプリケーションは，サービスプラットフォームが提供するKafka受付だけです。

(1)　メッセージの受信機能

メッセージの受信機能は，Brokerからメッセージを受信するための機能です。Consumerとも呼ばれます。

メッセージの受信機能（Consumer）の機能概要を次の図に示します。

図2‒98　メッセージの受信機能（Consumer）の機能概要

Consumerは，Kafka受付の起動の延長で開始します。

(a)　パーティションの割り当て

パーティションの割り当ては，Consumerグループのグループリーダー（グループ内の最初のConsumer）によって動的に行われます。Consumerに手動でパーティションを割り当てることはできません。

Consumerグループについては，「(5)　KafkaインバウンドアダプタのConsumerグループ」を参照してください。

(b)　サブスクライブ

Consumerが，どのトピックからレコードを受信するか設定することをサブスクライブといいます。Consumerのサブスクライブ対象のトピックを次に示します。

ユーザが作成したトピック

Kafkaが作成した内部トピック

サブスクライブ対象のトピックが存在しない場合でも，Broker側ではトピックは自動生成されません。この場合，Consumerの処理の実行中にトピックを作成することで，トピック作成後のポーリング処理でデータが読み込まれます。

(c)　データのポーリング

データのポーリングでは，Consumerに割り当てられたトピック内のパーティションからデータを読み込みます。データの取得単位は，レコードバッチ単位です。ポーリング処理は，この機能が停止しない限り繰り返し行われます。

クラスタの初期接続時のポーリング

Consumerは，Kafkaクラスタの情報を取得するために，データのポーリング実行時にKafkaクラスタの初期接続を実施します。Kafkaクラスタへの初期接続を確立するために使用するホスト／ポートペアのリストのどれかのBrokerと初期接続を行い，接続できたBrokerからKafkaクラスタの情報を取得します。ポーリング処理中に接続できた場合，以降のポーリングでは初期接続は必要ありません。

初期接続ができない場合，ポーリングの待ち時間内に繰り返し初期接続を行います。

ポーリングの待ち時間内に初期接続ができなかった場合，データのポーリング実行時にエラーは発生しません。

Brokerの接続時のポーリング

初期接続が行えた場合は，次に示すBrokerに接続します。

Consumerグループの，グループコーディネータのBroker

パーティションのリーダーであるBroker

ポーリングの待ち時間内に接続ができなかった場合は，ポーリング実行時にエラーは発生しません。

レコードのデシリアライズ

Consumerは，Brokerから取得したバイト配列のレコードをデシリアライズします。デシリアライズに使用するデシリアライザをKafka受付定義ファイルで設定できます。レコードのデシリアライズに関するプロパティを次に示します。

表2‒30　レコードのデシリアライズに関するプロパティ

プロパティ

説明

consumer.key.deserializer

レコードのキーのデシリアライザを指定します。

consumer.value.deserializer

レコードの値のデシリアライザを指定します。

取得するメッセージの順序

Consumerが取得するメッセージは，単一のパーティション内のメッセージに対してだけ順序が保証されます。トピックが複数のパーティションで構成される場合，取り出されるメッセージが，送信された順序で取得できるとは限りません。

受信するレコード数の上限

ポーリングごとにBrokerから受信するレコード数の上限を設定できます。レコード数の上限は，Kafka受付定義ファイルのconsumer.max.poll.recordsで設定します。

フェッチ要求のレコードのデータサイズ

Consumerからのデータのフェッチ要求に対して，Brokerが返す必要のあるデータサイズを設定できます。データサイズとは，1回のポーリングでConsumerが送信する，すべてのレコードデータのサイズです。

フェッチ要求のレコードのデータサイズについては，「(7)　レコードのデータサイズ」を参照してください。

(d)　受信できるメッセージの圧縮形式

Consumerでは，次に示す形式で圧縮されたメッセージが受信できます。Consumer はメッセージを伸張して処理を行います。Consumerが受信できない形式で圧縮されたレコードを受信した場合の動作は保証されません。

表2‒31　Consumerで受信できる圧縮方式

圧縮方式

受信可否

gzip

○

lz4

×

snappy

×

zstd

×

圧縮していないデータ

○

（凡例）

○：受信できます。

×：受信できません。

(e)　コミット

Consumerがどこまでメッセージを読み込んだかをBrokerに通知することをコミットといいます。

コミットについての詳細は，「(6)　コミットのタイミング」を参照してください。

(f)　セキュリティ

Kafkaインバウンドアダプタでは，TLSを使用した暗号化と認証，ホスト名の検証をサポートしています。TLSで使用するセキュリティ通信用プロトコルについては，Kafkaの公式ドキュメントを参照してください。

TLSで使用できるTLS暗号スイートの制限はありません。ただし，使用する暗号スイートを設定することはできません。

ホスト名の検証は，証明書内のホスト名が接続先のホスト名と一致するかどうかをチェックします。ホスト名の検証を無効にすることはできません。

(g)　レコード情報の作成

Brokerから取得したレコードを基に，Kafka受付に渡すレコード情報を作成します。レコード情報の作成は，1回のポーリングで受信したレコードごとに行います。レコード情報が作成されるのは，Brokerからメッセージが取得できた場合だけです。

取得したメッセージから作成されるレコード情報を次に示します。

表2‒32　取得したメッセージから作成されるレコード情報

レコードの項目

説明

レコードのキー

レコードのキーです。

レコードの値

レコードの値です。

オフセット

対応するパーティション内のレコードの位置です。

パーティション

レコードの受信元のパーティションです。

タイムスタンプ

メッセージ送信時のレコードのタイムスタンプです。

トピック

レコードを受け取ったトピックです。

ヘッダ

レコードのヘッダ情報です。

(2)　Kafka受付呼び出し機能

Kafka受付の呼び出しを実行することで，取得したレコード情報をビジネスプロセスで処理できるようになります。

Kafka受付の呼び出しは，ポーリングで取得したメッセージごとに行われます。そのため，ポーリングで複数のメッセージを受信した場合でも，Kafka受付に渡されるメッセージは1つです。また，Kafka受付の呼び出しはBrokerからメッセージが受信できた場合だけ行われます。

(3)　Kafkaインバウンドアダプタの実行

メッセージの受信機能およびKafka受付呼び出し機能は，J2EEサーバのリソースアダプタのワーク管理を使用して実行します。リソースアダプタのワーク管理については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.16.2　リソースアダプタのワーク管理」を参照してください。

リソースアダプタのワーク管理では，ワークに割り当てるスレッドをスレッドプールで管理します。スレッドプールの動作は，Connector属性ファイルで設定します。Kafkaインバウンドアダプタのスレッドプールに関するプロパティを次に示します。

表2‒33　スレッドプールに関するプロパティ

プロパティ

説明

MaxTPoolSize

スレッドプールで同時に実行される最大スレッド数

MinTPoolSize

スレッドプールにプールする最小スレッド数

TPoolKeepalive

スレッドプールのスレッド解放までのタイムアウト値

スレッドプールに関する設定については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「3.1.2(11)　Kafkaインバウンドアダプタのセットアップ」を参照してください。

(4)　配備できるリソースアダプタ数

1つのHCSCサーバに配備できるリソースアダプタ数は，1つです。リソースアダプタを複数配備した場合の動作は保証されません。

(5)　KafkaインバウンドアダプタのConsumerグループ

Consumerは，Consumerグループと呼ばれるグループに属することができます。Consumerは，初回のポーリングまたはConsumerグループのリバランス時に，ConsumerグループのコーディネータであるBrokerに，グループへの参加要求を行います。

Consumerグループのメッセージの受信例を次に示します。

図2‒99　Consumerグループのメッセージの受信例

この例の場合，「Group1」「Group2」で同一のメッセージが受信されます。

同一グループ内に複数のConsumerがある場合，グループ内のどれか1つのConsumerが一意のメッセージを受信できます。

パーティションはBrokerから各Consumerに割り振られますが，Consumerグループ内の各Consumerに同一のパーティションが割り当てられることはありません。

レコードは各パーティションのどれかに格納されるため，Consumerグループ内のConsumerが同一のメッセージを受信することはありません。

Consumerグループが異なる場合は，Consumerグループ単位で同一のメッセージを受信することができます。

(a)　Consumerグループのメンバーへのパーティションの割り当て

パーティション数に応じて，Consumerグループのメンバーへのパーティションは次のように割り当てられます。

表2‒34　Consumerグループのメンバーへのパーティションの割り当て

パーティション数とConsumerグループのメンバーの関係

パーティションの割り当て

パーティション数 < グループ内のメンバー

パーティション数がグループ内のメンバーより少ない場合，パーティションが割り当てられないメンバーが存在します。

パーティション数 = グループ内のメンバー

パーティション数がグループ内のメンバーと等しい場合，均等に割り当てられます。

パーティション数 > グループ内のメンバー

パーティション数がグループ内のメンバーより多い場合，割り当てに偏りが出ます。

パーティション数 < グループ内のメンバーの場合

パーティション数がグループ内のメンバーより少ない場合，パーティションが割り当てられないConsumerが存在します。パーティションが割り当てられないConsumerは，リバランスでパーティションが割り当てられない限りメッセージを受信しません。

パーティション数がグループ内のメンバーより少ない場合の割り当て例を次に示します。

パーティション数 < グループ内のメンバーの場合の割り当て例

Consumer2に割り当てるパーティションがないため，Consumer2はメッセージを受信しません。

パーティション数 = グループ内のメンバーの場合

パーティション数がグループ内のメンバーと等しい場合，グループ内のすべてのConsumerがメッセージを受信できる状態となります。

パーティション数がグループ内のメンバーと等しい場合の割り当て例を次に示します。

パーティション数 = グループ内のメンバーの場合の割り当て例

グループ内のすべてのConsumerにパーティションが割り当たります。

パーティション数 > グループ内のメンバーの場合

パーティション数がグループ内のメンバーより多い場合，グループ内のどれかのConsumerに，多くのパーティションが割り当てられます。

パーティション数がグループ内のメンバーより多い場合の割り当て例を次に示します。

パーティション数 > グループ内のメンバーの場合の割り当て例

グループ内にパーティションを均等に割り当てることができないため，Consumer1に2つのパーティションが割り当てられます。

(b)　パーティションの範囲割り当て

Kafkaでは，Consumerがグループ構成になっている場合，トピック内のパーティションをグループのメンバーに分散して割り当てます。これを範囲割り当てといいます。

範囲割り当ては，次の順序で行われます。

トピックごとに使用できるパーティションを番号順に，Consumerを辞書式順序でレイアウトします。

パーティションの数をConsumerの総数で割り，各Consumerに割り当てるパーティションの数を決定します。

均等に分割できない場合，最初のConsumerから順にパーティションを1つ追加で割り当てます。

範囲割り当ての例

2つのConsumerC0とC1，2つのトピックt0とt1があり，各トピックに3つのパーティションp0，p1，p2がある場合，パーティションはt0p0，t0p1，t0p2，t1p0，t1p1，およびt1p2の6つとなります。

トピックt0のパーティションは3つあり，これらのパーティションを2つのConsumerで分割します。均等に分割できないため，C0にパーティションが1つ追加で割り当てられます。トピックt1のパーティションも同様に割り当てが行われます。

そのため，Consumerごとのパーティションの割り当ては次のようになります。

C0：t0p0，t0p1，t1p0，t1p1

C1：t0p2，t1p2

(c)　Consumerグループのメンバーシップ

Consumerグループのメンバーシップは動的メンバーシップとなります。静的メンバーシップに変更することはできません。

(d)　Consumerグループのリバランス

ConsumerグループへのConsumerの加入や除外などを契機として，Brokerがグループ内のリバランスを行います。Consumerグループのリバランス時は，ポーリングが停止し，リバランス完了後にポーリングが再開します。

(e)　冗長構成

パーティションはConsumerごとに割り当てられるため，冗長構成にすることができます。Consumerグループがクラスタ内の同一のKafka受付を使用した冗長構成の例を次の図に示します。

図2‒100　Consumerグループがクラスタ内の同一のKafka受付を使用した冗長構成の例

ただし，Consumerごとにパーティションが割り当てられるため，冗長構成にしても特定のHCSCサーバの負荷を分散することはできません。

(f)　注意事項

Consumerグループについての注意事項を次に示します。

Consumerグループに対する操作は，Consumerグループの情報表示に関する操作，およびオフセットのリセットだけ許可されています。それ以外の操作を行った場合の動作は保証されません。

サービスプラットフォームで構成したConsumerグループに参加できるのは，サービスプラットフォームのConsumerだけです。その他の製品のConsumerがグループに参加した場合の動作は保証されません。

(6)　コミットのタイミング

Consumerがコミット処理を行うことで，どこまでメッセージを読み込んだかBrokerに通知されます。メッセージをどこまで読んだかを管理する単位をオフセットといいます。

オフセットには，次の2つがあります。

現在のオフセット

Consumerが読み取る次のメッセージのオフセットを示します。

コミットされたオフセット

パーティションの最後にコミットされたオフセットを示します。

オフセットが初期化されている場合，初回のポーリングでは割り当てられたパーティションの「コミットされたオフセット」以降のメッセージを受信します。2回目以降のポーリングでは「現在のオフセット」以降のメッセージを受信します。オフセットが初期化されていない場合，または「現在のオフセット」がサーバ上にない場合は，オフセットの自動リセットを行います。Consumerは，パーティション内のメッセージの読み込み位置を指定することはできません。

オフセットされたコミットの例を次に示します。

図2‒101　オフセットされたコミットの例

オフセットの初期位置が0の場合，5通のメッセージを受信して，コミットを行うと，コミットされたオフセットは「5」となります。

コミットのタイミングは，Consumer単位で制御できます。コミットのタイミングは，次のどちらかを選択できます。

Brokerからのメッセージ受信後

メッセージ処理後（Kafka受付からの応答後）

コミットのタイミングの違いによる動作の違いを次に示します。

表2‒35　コミットタイミングによる動作の違い

コミットのタイミング

一度のポーリングで受信できるメッセージ数

同一メッセージを受信するケース

ポーリングの最大遅延時間内にメッセージ処理が終了しない場合

同一メッセージの再送制限

メッセージ受信後

1つ以上

コミットが完了するまでにエラーが発生した場合，またはコミットが実行されなかった場合※1は，リバランスでパーティションを引き継いだConsumerが同一メッセージを受信します。

リバランスが発生して該当するパーティションがグループ内のConsumerに引き継がれた場合は，パーティションを引き継いだConsumerはコミットされたオフセットからメッセージを受信するため，同一のメッセージを受信します。

処理を続行します。

Consumerはグループから除外されます。この場合，次回のポーリング処理で再度グループに加入するようにリバランスされます。

制限できない

メッセージ処理後

1つだけ

メッセージ受信後にエラーが発生した場合，またはコミットが実行されなかった場合※1は，再送の上限数まで同一のConsumerが受信します。

また，このあとにリバランスが発生した場合は，パーティションを引き継いだConsumerが同一メッセージを受信します。

Consumerを停止します。Consumerはグループから除外されます。グループから除外された場合，割り当てられていたパーティションがグループ内の他のConsumerに割り当てられます。※2

制限できる※3

注※1

ポーリング後にKafka受付を停止すると，コミットされずに，同一メッセージが再送される場合があります。

コミットタイミングの設定によって，次の動作となることがあります。

・メッセージ受信後コミット

　コミットが実行されません。

・メッセージ処理後コミット

　メッセージ処理は実行されますが，コミットが実行されないことがあります。

注※2

グループから除外されたConsumerは，割り当てられていないパーティションに対してコミットを実行することがあります。この場合，コミット処理が失敗し，エラーメッセージを出力します。

パーティションが引き継がれたConsumerは，コミットされたオフセットが変更されていないため，再度同じメッセージを受信します。

注※3

Kafka受付からメッセージ処理の失敗の応答が返却された場合，次回のポーリングで同一のメッセージを受信して，Kafka受付に送信します。Consumerでは，同一メッセージの受信をリトライする回数を制御できます。リトライ回数内に，メッセージ処理が正常終了しない場合はConsumerを停止します。

また，一時的な障害ではなくメッセージの不正など，ユーザが対処しないと障害が回復しない場合は，リバランスでパーティションを割り当てられたConsumerも同様の動作となるため，グループ内のすべてのConsumerが停止します。

パーティションを引き継いだ場合の例を次に示します。

図2‒102　パーティションを引き継いだ場合の例

図中の1.〜4.について説明します。

Consumer1がポーリング処理を行います。

現在のオフセットが「1」のため，オフセット「1」のメッセージを受信します。

ポーリングの最大遅延時間内に次のポーリング処理を呼べなかった場合，Consumer1がグループから除外されます。

リバランス処理によってConsumer2にパーティションが引き継がれます。

コミットされたオフセットが「1」のため，Consumer2ではオフセット「1」のメッセージを受信します。

Consumer1がメッセージをコミットします。

Consumer1は割り当てられていないパーティションに対してコミットするため，コミットが失敗します。

(a)　メッセージ受信後のコミット

メッセージの処理順序を考慮する必要がない場合に設定します。この場合，ビジネスプロセスのメッセージ処理が失敗したときに，該当するメッセージ処理の回復処理を行わなくても，該当するメッセージよりあとのオフセットのメッセージが処理できます。

Kafka受付からの応答が正常か，異常かに関わらず，「現在のオフセット」および「コミットされたオフセット」が更新されるため，次回のポーリングでは，前回受信したメッセージの次のオフセットのメッセージが受信されます。

図2‒103　メッセージ受信後のコミット処理の流れの例

図中の1.〜3.について説明します。

ポーリング処理でメッセージを受信します。

受信するメッセージ数は1つです。現在のオフセットは「1」であるため，オフセット「1」のメッセージを受信します。メッセージ受信後に，現在のオフセットは「2」になります。

メッセージをコミットします。

コミット実行後のオフセット（コミットされたオフセット）は「2」となります。

オフセット「1」のメッセージをKafka受付に送信します。

Kafka受付からの応答が正常か，異常かに関わらず，現在のオフセットは「2」のため，次回のポーリングではオフセット「2」のメッセージを受信します。

また，コミット後にリバランスが発生して，該当するパーティションがグループ内のConsumerに引き継がれた場合は，パーティションを引き継いだConsumerは2.でコミットされたオフセットからメッセージを受信します。

(b)　メッセージ処理後のコミット

ビジネスプロセスのメッセージ処理が失敗した場合，該当するメッセージ処理の回復処理を行ってから，次のオフセットのメッセージを処理する必要があります。この場合，該当するメッセージは再送されます。

メッセージ処理後のコミットでは，Kafka受付からの応答が正常な場合だけコミットを行います。メッセージ受信後の処理が失敗した場合や，Kafka受付からエラー応答が返ってきた場合はコミットしません。また，次回のポーリングでは前回受信したメッセージを再度受信します。

図2‒104　メッセージ処理後コミットの処理の流れの例

図中の1.〜2.について説明します。

ポーリング処理を行い，メッセージを受信します。

現在のオフセットは「1」のため，オフセット「1」のメッセージを受信します。メッセージ受信後に現在のオフセットは「2」となります。

オフセット「1」のメッセージをKafka受付に送信します。

Kafka受付からエラー応答があった場合，コミット処理が省略されるため，コミットされたオフセットは更新されません。

また，次回のポーリングで同一のメッセージを受信するために，現在のオフセットをエラーが発生したメッセージのオフセットに戻します。

(c)　オフセットの自動リセット

オフセットが初期化されていない場合，または「現在のオフセット」がサーバ上にない場合は，オフセットの自動リセットを行います。自動リセットは，Kafka受付定義ファイルのconsumer.auto.offset.resetで設定します。

自動リセットの方法に応じて取得されるデータを次に示します。

表2‒36　自動リセットの方法に応じて取得されるデータ

プロパティ

設定値

説明

consumer.auto.offset.reset

earliest

最も早いオフセットに自動的にリセットします。パーティションの先頭からすべてのメッセージを取得します。

latest

自動的に最新のオフセットにリセットします。サブスクライブのあとに送信されたメッセージを取得します。

自動リセットの設定に応じた自動リセットで取得できるメッセージの例を次に示します。

図2‒105　自動リセットで取得できるメッセージの例

earliest（最も早いオフセットにリセット）を設定した場合，オフセットが0にリセットされるため，オフセット0以降のメッセージを受信できます。

latest（最新のオフセットにリセット）を設定した場合，サブスクライブのあとに送信されたメッセージであるオフセット4以降のメッセージが受信できます。サブスクライブ前にパーティションに存在していたオフセット0〜3のメッセージは受信しません。

(7)　レコードのデータサイズ

レコードのデータサイズはKafka受付定義ファイルで設定します。データは，レコードバッチ単位で取得します。

レコードのデータサイズを設定するプロパティを次に示します。

表2‒37　レコードのデータサイズに関するプロパティ

プロパティ

説明

consumer.fetch.min.bytes※

サーバがフェッチ要求に対して返す必要のあるデータの最小量を指定します。

consumer.fetch.max.bytes

サーバがフェッチ要求に対して返す必要のあるデータの最大量を指定します。

consumer.max.partition.fetch.bytes

サーバが返すパーティションごとのデータの最大量を指定します。

注※

利用できるデータに満たない場合，Brokerはその量のデータが蓄積されるまで待ってからConsumerに応答します。データが蓄積されるまでの待ち時間は，consumer.fetch.max.wait.ms（フェッチ要求のブロック時間）で設定します。この待ち時間を経過した場合，最小サイズに満たなくてもBrokerから応答が返却されます。

利用できるデータを満たす場合

最小サイズを20バイトと設定し，次に示すパーティションの，オフセット0のメッセージから受信する場合の例を次に示します。データの取得単位は，1レコード1バッチです。

図2‒106　利用できるデータを満たす場合の例

最小サイズを満たすデータがあるため，最大サイズまでのデータが受信できます。

利用できるデータに満たない場合

最小サイズを50バイトと設定し，次に示すパーティションの，オフセット0のメッセージから受信する場合の例を次に示します。データの取得単位は，1レコード1バッチです。

図2‒107　利用できるデータに満たない場合の例

最小サイズに満たないため，データが蓄積されるまで待ちます。

待ち時間内に最小サイズを満たすデータが蓄積されない場合，オフセット0〜3のメッセージが受信されます。

待ち時間内に最小サイズを満たすデータが蓄積された場合，オフセット4のメッセージまで受信できます。

2.12.4　Kafkaインバウンドアダプタのタイムアウト監視

Kafkaインバウンドアダプタのタイムアウトを監視するポイントを次に示します。

図2‒108　タイムアウトを監視するポイント

（凡例）

アイドルタイムアウト※

ポーリングの最大遅延時間

メタデータの更新を強制するまでの期間※

ポーリングのブロック時間

コミットのタイムアウト

最初のソケット接続が確立されるまでクライアントが待機する最大時間

最初のソケット接続が確立されるまで待機する時間

繰り返し接続に失敗したBrokerに再接続するときに待機する最大時間

フェッチ要求のブロック時間

パーティションへの要求の待機時間

特定のホストへの再接続を試行する前に待機する基本時間

注※

フェッチ要求の延長で，タイムアウトが経過したか監視しています。

タイムアウトは次に示す関係で設定することを推奨します。

1. > 3. > 4. > 6. > 7. > 8. > 9. > 10. > 11.

1. > 2. > 5.

また，次の関係で設定することを推奨します。

4. > （6. + 7. + 8. + 9. + 10. + 11.）

(1)　Kafkaのグループ管理機能のタイムアウト

Kafkaのグループ管理機能は，BrokerがConsumerグループを管理するための機能です。Kafkaクラスタのサーバにあるグループコーディネータが，Consumerグループのメンバーが生存しているか把握できるように，Consumerから定期的にハートビートを送信しています。Consumerがグループコーディネータにハートビートを一定期間送信できなかった場合，グループコーディネータはハートビートが送信できなかったConsumerをグループから除外します。

グループ管理機能に関するタイムアウトについて，次の表に示します。

表2‒38　グループ管理機能に関するタイムアウト

タイムアウト項目

説明

該当するKafka受付定義ファイルのプロパティ

セッションタイムアウト

Consumerセッションのタイムアウトです。

consumer.session.timeout.ms

ハートビート間隔

ハートビートの送信間隔です。

consumer.heartbeat.interval.ms

タイムアウト発生後の動作

セッションタイムアウトの期間内に，ハートビートがBrokerに送信されなかった場合は，ポーリング処理がエラーとなります。エラーメッセージをメッセージログに出力して，Consumerを停止します。

(2)　ポーリング処理のタイムアウト

ポーリング処理に関するタイムアウトについて，次の表に示します。

表2‒39　ポーリング処理のタイムアウト

タイムアウト項目

説明

該当するKafka受付定義ファイルのプロパティ

タイムアウト発生後の動作

ポーリングのブロック時間

利用できるレコードがない場合にポーリングをブロックする最大時間です。

利用できるレコードがある場合は，ブロックしません。

urecp-kafka.poll-timeout.ms

空のレコードセットを返却し，ポーリング処理を続行します。

ポーリングの最大遅延時間

ポーリング実行後に，次のポーリングが行われるまでの最大遅延時間です。

consumer.max.poll.interval.ms

ポーリングの最大遅延時間のタイムアウト発生後の動作は，「2.12.3(6)　コミットのタイミング」を参照してください。

フェッチ要求のブロック時間

フェッチ要求でサーバが返却する最小データ量（fetch.min.bytes）を，すぐに満たすのに十分なデータがない場合に，サーバがフェッチ要求に応答する前にブロックする最大時間です。

consumer.fetch.max.wait.ms

フェッチ要求が終了し，ポーリング処理を続行します。

パーティションへの要求の待機時間

パーティションへの要求が失敗した場合に，失敗した要求を再試行する前に待機する時間です。

consumer.retry.backoff.ms

失敗した要求を再試行し，ポーリング処理を続行します。

メタデータの更新を強制するまでの期間

メタデータを強制リフレッシュするための最大待ち時間です。Brokerやパーティションの追加を行った場合，この時間経過後にBrokerやパーティションが検出されます。

consumer.metadata.max.age.ms

メタデータを強制リフレッシュし，ポーリング処理を続行します。

ポーリング処理のタイムアウトの範囲を次の図に示します。

図2‒109　ポーリング処理のタイムアウトの範囲

（凡例）

ポーリングのブロック時間

ポーリングの最大遅延時間

フェッチ要求のブロック時間

パーティションへの要求の待機時間

メタデータの更新を強制するまでの期間

(3)　コミットのタイムアウト

コミットのタイムアウトは，オフセットコミットの完了を待機する最大時間です。Kafka受付定義ファイルのurecp-kafka.commit-timeout.msで設定します。

タイムアウトの範囲を次の図に示します。コミット時間を設定する場合，ポーリングの最大遅延時間を考慮する必要があります。

図2‒110　タイムアウトの範囲

コミット処理はポーリングの後に行われるため，ポーリングの最大遅延時間内に含まれます。そのため，ポーリングの最大遅延時間よりコミットのタイムアウトが長い場合は，ポーリングの最大遅延時間が経過したあとにコミットが行われるときがあります。このときは，ポーリングの最大遅延時間が経過したあとにConsumerがグループから除外されるため，コミットが失敗するおそれがあります。コミットのタイムアウトは，ポーリングの最大遅延時間を超えないように設定してください。

タイムアウト発生後の動作

オフセットコミットが正常に完了する前にタイムアウトが切れた場合は，Consumerを停止し，エラーメッセージをメッセージログに出力して，処理を終了します。

(4)　アイドルタイムアウト

アイドルタイムアウトは，アイドル状態の接続を閉じる際に使用されるタイムアウトです。Kafka受付定義ファイルのconsumer.connections.max.idle.msで設定します。

タイムアウト発生後の動作

アイドル状態の接続を閉じ，Consumerを続行します。

(5)　Consumerインスタンスのクローズタイムアウト

Consumerインスタンスをクローズするときに使用されるタイムアウトです。タイムアウト値は，30秒です。Consumerインスタンスのクローズタイムアウトのタイムアウト値は変更できません。

タイムアウト発生後の動作

エラーメッセージを出力して，処理を続行します。

(6)　Broker接続

Broker接続のタイムアウトについて，次の表に示します。Broker接続はポーリング時に行われるため，これらのタイムアウトが，ポーリングの最大遅延時間を超えないように設定する必要があります。

表2‒40　Broker接続のタイムアウト

タイムアウト項目

説明

該当するKafka受付定義ファイルのプロパティ

タイムアウト発生後の動作

最初のソケット接続が確立されるまで待機する時間

最初のソケット接続が確立されるまで待機する時間です。

consumer.socket.connection.setup.timeout.ms

最大時間が経過していない場合，Brokerに再接続して，Consumerを続行します。

最初のソケット接続が確立されるまでクライアントが待機する最大時間

最初のソケット接続が確立されるまでクライアントが待機する最大時間です。

consumer.socket.connection.setup.timeout.max.ms

最大時間が経過していない場合，Brokerに再接続して，Consumerを続行します。

再接続を試行する前に待機する基本時間

特定のホストへの再接続を試行する前に待機する基本時間です。

consumer.reconnect.backoff.ms

最大時間が経過していない場合，Brokerに再接続して，Consumerを続行します。

再接続するときに待機する最大時間

繰り返し接続に失敗したBrokerに再接続するときに待機する最大時間です。

consumer.reconnect.backoff.max.ms

最大時間が経過していない場合，Brokerに再接続して，Consumerを続行します。

2.12.5　Kafkaアダプタの機能

Kafkaアダプタは，ビジネスプロセスからのメッセージ送信要求に従い，Kafkaにメッセージを送信するためのサービスアダプタです。Kafkaアダプタが利用できるApache Kafkaのバージョンは2.6.0〜2.8.0です。

Kafkaアダプタを利用したメッセージの送信の例を次に示します。

図2‒111　Kafkaアダプタを利用したメッセージの送信

図中の1.〜3.について説明します。

ビジネスプロセスから要求電文が送信されます。

Kafkaアダプタで要求電文をメッセージに変換します。

メッセージの変換については，「(3)　メッセージの変換」を参照してください。

KafkaアダプタからKafkaにメッセージが送信されます。

メッセージの送信については，「(4)　メッセージの送信」を参照してください。

(1)　KafkaアダプタとApache Kafkaとの関係

KafkaアダプタとApache Kafkaとの関係を次の図に示します。

図2‒112　KafkaアダプタとApache Kafkaとの関係

Apache Kafka

複数台のサーバで大量のデータを処理する分散メッセージングシステムです。Kafkaとも表記します。

Broker

Kafkaの構成要素の一つで，データを受信，および配信するサービスです。

メッセージ

Kafka内で扱うデータの単位です。レコードともいいます。メッセージはキーバリュー形式で構成されています。

トピック

メッセージを種別ごとに管理するためのストレージです。Broker上に配置され，管理されます。Brokerで設定されたauto.create.topics.enableがtrueで，かつ送信先のBrokerに指定したトピックがない場合，Apache Kafkaは，自動でトピックを生成します。このときもKafkaアダプタでは，メッセージ送信処理を続行します。トピックの自動生成を無効にするには，Brokerのauto.create.topics.enableをfalseに設定してください。Brokerで設定するプロパティについてはKafkaの公式ドキュメントを参照してください。

パーティション

Broker上のデータの読み書きを行う単位です。トピックは複数のパーティションで構成されます。パーティションの切り分けは次の順に決定します。

メッセージのpartition要素に有効なパーティションIDが指定されている場合，そのパーティションIDを持つパーティションに送信されます。ヘッダ要求電文の<kafka-header-send-request>-<record>-<partition>で設定します。

メッセージのpartition要素にパーティションIDが指定されていない場合，メッセージのキーを指定することで，キーのハッシュ値に応じて送信先のパーティションに送信されます。同一のキーを持つメッセージは同一のパーティションIDを持つパーティションに送信されます。メッセージのキーはヘッダ要求電文の<kafka-header-send-request>-<record>-<key>で設定します。

メッセージのキーに何も指定されていない場合，デフォルトの設定に応じて複数のパーティションにメッセージが送信されます。

Kafkaクラスタ

複数のBrokerによって構成されたクラスタシステムです。

Kafkaはトピックと呼ばれる単位で，種別ごとにメッセージを管理しています。Kafkaアダプタは，ビジネスプロセスから送られる要求電文からメッセージを作成し，定義ファイルで設定した内容を基に指定したApache Kafka内にメッセージを格納します。メッセージのキーと値の型の構成が同一，かつ，同じKafkaクラスタ内にメッセージを送信する場合，1つのKafkaアダプタでApache Kafkaにメッセージを送信できます。また，1つのKafkaアダプタで同じKafkaクラスタ内の異なるトピックにメッセージを送信することもできます。

KafkaアダプタとKafkaは，ローカル環境でもリモート環境でも接続できます。

(2)　Kafkaアダプタで使用できる通信モデル

Kafkaアダプタの通信モデルは，同期通信です。通信モデルに「非同期」を設定した場合は，Kafkaアダプタの呼び出し時にエラーになります。

(3)　メッセージの変換

ビジネスプロセスから渡された要求電文をKafkaアダプタでメッセージに変換します。Kafkaアダプタの要求電文の形式については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.16　Kafkaアダプタを定義する」を参照してください。

Kafkaでは，メッセージのキーおよび値はシリアライズされています。Kafkaで使用できる形式のメッセージを作成するため，Kafkaアダプタではメッセージのシリアライズを行います。シリアライズ形式には，バイナリ形式と文字列形式が使用できます。メッセージのシリアライズ形式の指定は，Kafkaアダプタ定義ファイルの次のプロパティで指定します。

表2‒41　メッセージの変換に関するプロパティ

プロパティ

説明

producer.key.serializer

メッセージのキーのシリアライザクラスを指定します。

producer.value.serializer

メッセージの値のシリアライザクラスを指定します。

(4)　メッセージの送信

Kafkaアダプタで変換したメッセージをKafkaに送信します。Kafkaアダプタでは，要求電文から生成されたメッセージを，1つのメッセージごとにKafkaに送信します。ただし，マルチスレッドでの送信のため，メッセージの送信順序は保証されません。

Kafkaは，Kafkaアダプタから送られてくるメッセージを受信するとメッセージ受信完了通知（Ack）をKafkaアダプタに返します。Kafkaアダプタは，Ackを受信すると，メッセージ送信の完了処理を行います。

メッセージの送信では，メッセージの配信保証レベル，再送，圧縮をKafkaアダプタ定義ファイルのプロパティで設定できます。

(a)　メッセージの配信保証レベル

メッセージ配信の保証レベルを設定できます。メッセージ配信の保証レベルはKafkaアダプタ定義ファイルのproducer.acksで設定します。

Kafkaアダプタで保証しているメッセージ配信の種類を次に示します。

表2‒42　Kafkaアダプタのメッセージ配信の保証

保証レベルの種類

説明

再送

重複除去

At Most Once

一回はメッセージの配信を試みます。重複メッセージは発生しません。メッセージがロストする場合があります。

×

×

At Least Once

少なくとも一回はメッセージを配信します。重複メッセージが発生する場合があります。デフォルトではAt Least Onceが設定されています。

○

×

（凡例）

○：保証する

×：保証しない

注意事項

Kafkaにメッセージ送信リクエストを実行して完了通知を受け取る間にクラッシュした場合，Kafkaアダプタはそのメッセージの送信完了前という状態になり，再度ビジネスプロセスから送信要求を実行した場合に同じメッセージを再送することがあります。そのため，メッセージ配信の保証の設定に関わらず，メッセージの重複を前提として設計してください。

(b)　メッセージの再送

一時的なエラーで送信に失敗した場合，メッセージを再送できます。メッセージの再送は，Kafkaアダプタ定義ファイルの次のプロパティで設定します。

表2‒43　メッセージの再送に関するプロパティ

プロパティ

説明

producer.acks

Kafkaアダプタからの送信リクエストに，Kafkaのメッセージ受信完了通知（Ack）を返すタイミングを指定します。

producer.retries

一時的なエラーで送信に失敗したメッセージを再送信する場合の再試行回数を指定します。

producer.delivery.timeout.ms

Kafkaアダプタからの送信リクエストの呼び出しが戻ったあと，Kafkaへのメッセージ送信の成功または失敗を応答する時間の上限を指定します。

ネットワークエラーが発生した場合，メッセージを再送しようとすると重複が発生するときがあります。メッセージが送信される前にネットワークエラーが発生した場合は，重複は発生しません。ただし，メッセージがKafkaに格納されたあと応答を送信者に配信する前にネットワークエラーが発生した場合は，Kafkaアダプタはエラーを検出できません。

(c)　メッセージの圧縮

送信するメッセージを指定した圧縮方式で圧縮できます。メッセージの圧縮は，Kafkaアダプタ定義ファイルのproducer.compression.typeで設定します。

(5)　Kafkaアダプタのセキュリティ設定

Kafkaアダプタでは，TLSを使用した暗号化と認証，ホスト名の検証をサポートしています。TLSで使用するセキュリティ通信用プロトコルについては，Kafkaの公式ドキュメントを参照してください。

TLSを使用した暗号化と認証に関する定義を設定するには，Kafkaアダプタ実行環境（共通）プロパティファイルに次のプロパティを設定します。

表2‒44　TLSを使用した暗号化と認証に関するプロパティ

プロパティ

説明

producer.security.protocol

Brokerとの通信に使用されるプロトコルの指定

producer.ssl.key.password

キーストアファイル内の秘密鍵のパスワード

producer.ssl.keystore.key

キーストアファイルの秘密キー

producer.ssl.keystore.location

キーストアファイルの格納場所

producer.ssl.keystore.password

キーストアファイルのストアパスワード

producer.ssl.truststore.location

トラストストアファイルの格納場所

producer.ssl.truststore.password

トラストストアファイルのパスワード

producer.ssl.enabled.protocols

SSL接続が有効になっているプロトコルのリスト

producer.ssl.keystore.type

キーストアファイルのファイル形式

producer.ssl.protocol

SSLコンテキストの生成に使用されるSSLプロトコル

producer.ssl.provider

SSL接続に使用されるセキュリティプロバイダの名前

producer.ssl.truststore.type

トラストストアファイルのファイル形式

TLSで使用できるTLS暗号スイートの制限はありません。ただし，使用する暗号スイートを設定することはできません。

KafkaのTLSを使用した暗号化と認証の設定については，Kafkaの公式ドキュメントを参照してください。

2.12.6　Kafkaアダプタのタイムアウト監視

Kafkaアダプタのタイムアウトを監視するポイントを次に示します。

図2‒113　Kafkaアダプタのタイムアウトを監視するポイント

ここでは，各タイムアウトの設定方法と発生後の動作について説明します。

(1)　メッセージ送信時のタイムアウト

(a)　送信リクエストの呼び出しが待機する時間のタイムアウト

送信リクエストの呼び出しが待機する時間です。

設定方法

Kafkaアダプタ定義ファイルのproducer.max.block.msで設定します。

タイムアウト発生後の動作

送信リクエストの呼び出しが待機したあと，開放される前にタイムアウトが切れた場合は，処理が続行できないと判断し，エラーメッセージを出力して，メッセージの送信を停止します。

(b)　リクエストタイムアウト

Kafkaアダプタが送信要求の応答を待機する最大時間です。

設定方法

Kafkaアダプタ定義ファイルのproducer.request.timeout.msで設定します。

タイムアウト発生後の動作

Kafkaからの要求の応答が返ってくる前にタイムアウトが切れた場合の状態によって，次のように動作が変わります。

メッセージが再送できる場合は，リクエストが再試行されます。

メッセージが再送できない場合は，処理が続行できないと判断し，エラーメッセージを出力して，メッセージの送信を停止します。

メッセージの再送については，「2.12.5(4)(b)　メッセージの再送」を参照してください。

(c)　配信タイムアウト

送信リクエストの呼び出しが返されてから成功または失敗をレポートする時間です。

設定方法

Kafkaアダプタ定義ファイルのproducer.delivery.timeout.msで設定します。

タイムアウト発生後の動作

送信リクエストの呼び出しが返されてから成功または失敗をレポートするまでにタイムアウトが切れた場合は，処理が続行できないと判断し，エラーメッセージを出力して，メッセージの送信を停止します。

(2)　アイドルタイムアウト

アイドル状態の接続を閉じるときに使用されるタイムアウトです。

設定方法

Kafkaアダプタ定義ファイルのproducer.connections.max.idle.msで設定します。

タイムアウト発生後の動作

アイドル状態の接続が閉じます。メッセージの送信は続行します。

(3)　Broker接続時のタイムアウト

(a)　ソケット接続が確立されるのを待機する最大時間

ソケット接続が確立されるまでクライアントが待機する最大時間です。

設定方法

Kafkaアダプタ定義ファイルのproducer.socket.connection.setup.timeout.max.msで設定します。

タイムアウト発生後の動作

ノードが停止していると判断し，他のノードに接続を切り替えます。メッセージの送信は続行します。

(b)　ソケット接続が確立されるまで待機する時間

最初のソケット接続が確立されるまで待機する時間です。

設定方法

Kafkaアダプタ定義ファイルのproducer.socket.connection.setup.timeout.msで設定します。

タイムアウト発生後の動作

ノードが停止していると判断し，他のノードに接続を切り替えます。メッセージの送信は続行します。

2.12.7　KafkaアダプタのJSON-XML変換機能

Kafkaアダプタのボディ要求電文に設定されたXML形式のデータをJSON形式に変換します。JSON-XML変換したJSON形式データは，Kafkaに送信するメッセージの値に格納されます。JSON形式で使用できる文字コードはUTF-8です。

KafkaアダプタでJSON形式データを送信する場合のデータの流れを次に示します。

図2‒114　KafkaアダプタでJSON形式データを送信する場合のデータの流れ

図中の1.〜4.について説明します。

ビジネスプロセスからKafkaアダプタにボディ要求電文（XML形式）が渡されます。

KafkaアダプタのJSON-XML変換機能を使用して，XML形式のボディ要求電文をJSON形式に変換します。

Kafkaアダプタが生成したメッセージの値にJSON形式のデータを設定します。

Kafkaアダプタがメッセージを送信します。

KafkaアダプタでJSON-XML変換をするどうかは，Kafkaアダプタ定義ファイルで設定します。Kafkaアダプタ定義ファイルの設定については，マニュアル「サービスプラットフォーム リファレンス」の「3.13.1　Kafkaアダプタ定義ファイル」を参照してください。

JSON-XML変換機能では，変換処理の動作定義を設定できます。Kafkaアダプタ定義ファイルにJSON-XML変換定義ファイルが指定されていた場合，JSON-XML変換定義ファイルの設定がJSON-XML変換機能に反映されます。なお，JSON-XML変換定義ファイルが指定されていない場合は，デフォルト値が設定されます。JSON-XML変換定義ファイルは，Kafkaアダプタの起動時に読み込まれます。

JSON-XML変換定義ファイルの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「3.18.1　JSON-XML変換定義ファイル」を参照してください。

2.13　gRPCプロトコルを利用した接続

gRPC受付，gRPCインバウンドアダプタ，gRPCアダプタを利用して，gRPCプロトコルでメッセージを送受信できます。

2.13.1　gRPCプロトコルを利用したシステム

サービスプラットフォームでは，gRPCプロトコルを利用してメッセージの送受信をする機能を提供しています。

gRPCプロトコルを利用したシステムの概要を次の図に示します。

図2‒115　gRPCプロトコルを利用したシステムの概要

gRPC受付は，gRPCインバウンドアダプタから渡されたメッセージを要求電文に変換してビジネスプロセスに渡します。

gRPCアダプタは，ビジネスプロセスから受け取ったメッセージをgRPCサーバに送信します。

なお，サービスプラットフォームとgRPCプロトコルとの接続を利用する場合，次の制限事項があります。

protoファイルの完全修飾名（「パッケージ名.サービス名」）が重複するサービス名は，gRPC受付，およびgRPCインバウンドアダプタでは使用できません。

gRPCが規定している通信方式のうち，サービスプラットフォームでは「Unary RPC」だけを使用できます。

サービスプラットフォームでサポートしているProtocol Buffersのバージョンは，Protocol Buffers version 3です。Protocol Buffers version 2仕様のGROUPタイプのメッセージは使用できません。

gRPCとの接続に必要な設定について，次に説明します。

(1)　gRPCプロトコルを利用した接続に必要なOSS

gRPCプロトコルを利用した接続では，次のOSSを使用します。

表2‒45　gRPCプロトコルを利用した接続に必要なOSS

項番

OSS名

概要

1

animal-sniffer-annotations-1.21.jar

Animal Sniffer Annotations

2

annotations-4.1.1.4.jar

Google Android Annotations Library

3

checker-qual-3.12.0.jar

Checker Qual

4

commons-codec-1.3.jar※1

The Apache Commons Codec package contains simple encoder and decoders for various formats such as Base64 and Hexadecimal. In addition to these widely used encoders and decoders, the codec package also maintains a collection of phonetic encoding utilities.

5

commons-logging-1.1.1.jar※1

Apache Commons Logging is a thin adapter allowing configurable bridging to other, well known logging systems.

6

error_prone_annotations-2.14.0.jar

Error Prone Annotations

7

failureaccess-1.0.1.jar

Guava InternalFutureFailureAccess and InternalFutures

8

google-auth-library-credentials-1.4.0.jar※1

Google Auth Library For Java Credentials

9

google-auth-library-oauth2-http-0.9.0.jar※1

Google Auth Library For Java OAuth2 HTTP

10

google-http-client-1.19.0.jar※1

Google HTTP Client Library for Java. Functionality that works on all supported Java platforms, including Java 7 (or higher) desktop (SE) and web (EE), Android, and Google App Engine.

11

google-http-client-jackson2-1.19.0.jar※1

Jackson 2 Extensions to The Google HTTP Client Library For Java.

12

grpc-api-1.53.0.jar

GRPC API

13

grpc-auth-1.53.0.jar※1

gRPC: Auth

14

grpc-census-1.53.0.jar※2

gRPCのトレース機能を補助するモジュール

15

grpc-context-1.53.0.jar

GRPC Context

16

grpc-core-1.53.0.jar

GRPC Core

17

grpc-netty-shaded-1.53.0.jar

GRPC Netty Shaded

18

grpc-protobuf-1.53.0.jar

GRPC Protobuf

19

grpc-protobuf-lite-1.53.0.jar

GRPC Protobuf lite

20

grpc-stub-1.53.0.jar

GRPC Stub

21

gson-2.9.0.jar

Gson

22

guava-31.1-android.jar

Guava: Google Core Libraries For Java

23

httpclient-4.0.1.jar※1

HTTPClient provides an efficient, up-to-date, and feature-rich package implementing the client side of the most recent HTTP standards and recommendations.

24

httpcore-4.0.1.jar※1

Apache HttpComponents Core (blocking I/O)

25

j2objc-annotations-1.3.jar

J2ObjC Annotations

26

jackson-core-2.1.3.jar※1

Core Jackson processing abstractions (aka Streaming API), implementation for JSON

27

jsr305-3.0.2.jar

FindBugs JSR305

28

listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar

Guava ListenableFuture Only

29

opencensus-api-0.31.0.jar※2

トレース・メトリックス用ライブラリモジュール

30

opencensus-contrib-grpc-metrics-0.31.0.jar※2

Opencensus用gRPCメトリックスライブラリモジュール

31

perfmark-api-0.25.0.jar

PerfMark API

32

protobuf-java-3.21.7.jar

Protocol Buffers [Core]

33

proto-google-common-protos-2.9.0.jar

Proto Google Common Protos

注※1

gRPCアダプタで使用する場合は必要です。

注※2

gRPC通信ログを出力する場合は必要です。

(2)　gRPCライブラリ（OSS）のインストール

gRPCとの接続には，表2-45に記載されたgRPCライブラリ（OSS）のjarファイルが必要です。

前提jarファイルをインストールする手順を次に示します。

Service Platformの添付品CDから表2-45のjarファイルを，次のフォルダにコピーします。

<サービスプラットフォームのインストールディレクトリ>¥CSC¥lib¥external

J2EEサーバ用オプション定義ファイル（usrconf.cfg）を開き，次のgRPCライブラリ（OSS）のクラスパスを指定します。

add.class.path=<gRPCライブラリ(OSS)のjarファイルのインストールディレクトリ>¥各gRPCライブラリ(OSS)のjarファイル名

(3)　protocコマンドの取得とprotoファイルの出力

gRPCとの接続には，protocコマンドが必要です。

protoファイルは，protocol buffer IDL仕様に従って記述されたファイルです。

(a)　protocコマンドの取得

サービスプラットフォームの開発環境（Service Architect）を使用する場合は，protocコマンドを取得してください。

protocコマンドを取得する手順を次に示します。

Service Platformの添付品CDからprotoc-21.8-win64.zipを取得します。

取得したprotoc-21.8-win64.zipを任意のディレクトリに展開します。

展開したディレクトリから，binディレクトリ，およびincludeディレクトリをコピーし，次のディレクトリに格納します。

<サービスプラットフォームのインストールディレクトリ>¥CSCTE¥lib¥external¥gRPC

protoc-21.8-win64.zipのディレクトリ構成を次に示します。

表2‒46　protoc-21.8-win64.zipのディレクトリ構成

ディレクトリとファイル

説明

ルートディレクトリ

protoc-21.8-win64.zipを展開した任意のディレクトリです。

bin

protocコマンドを格納するディレクトリです。

protoc.exe

protocコマンドです。gRPC受付・アダプタ作成時に，使用します。

include

Well-Known-Typesのprotoファイルを格納するディレクトリです。

google

Googleが提供するWell-Known-Types（汎用メッセージタイプ）のprotoファイルおよびディレクトリです。

protobuf

*.proto

compiler

plugin.proto

(b)　protoファイルの出力

gRPC受付またはgRPCアダプタの作成時に入力したprotoファイルは，ユーザ定義受付定義画面（詳細）またはサービスアダプタ定義画面（詳細）のprotoファイルの［出力］ボタンから取得できます。

protoファイルは，ZIPファイルに圧縮されて出力されます。ZIPファイルのディレクトリ構成を次に示します。

表2‒47　出力したprotoファイルのディレクトリ構成

ディレクトリとファイル

説明

ルートディレクトリ

出力したZIPファイルのルートディレクトリです。

proto_path1

proto_pathディレクトリおよびprotoファイルが格納されます。配下のサブディレクトリは，gRPC受付またはgRPCアダプタの作成時に指定したproto_pathのディレクトリ構成で格納されます。

proto_path2

：

proto_pathN

(c)　protoファイル使用時の注意事項

protoファイル使用時の注意事項を次に示します。

protoファイル内に記述するimport文のパスは，protoファイルを管理するプロジェクトの起点ディレクトリからの相対パスを記述してください。

protoファイル内に定義するpackage名は，protoファイルを管理するプロジェクトの起点ディレクトリからのファイルシステム上の相対パスと一致させることを推奨します。

gRPC受付またはgRPCアダプタの作成時に入力するproto_pathは，protoファイルを管理するプロジェクトの起点ディレクトリを指定してください。

proto_pathやprotoファイルのパスに，260バイト以上のパスは設定できません。

protoファイルのパスに，マルチバイト文字を含むパスは設定できません。

Eclipseのワークスペースのパスに，マルチバイト文字を含むパスは設定できません。ワークスペースにマルチバイト文字を含むパスを設定し，gRPC受付またはアダプタを作成した場合はエラーとなります。

proto_pathディレクトリ以下には，gRPC受付，gRPCアダプタの作成に使用する必要なファイルだけを格納してください。不要なファイルを格納した場合，protoファイル解析処理中に次のことが発生するおそれがあります。

protoファイル解析の処理時間が増加する。

protoファイル解析処理の途中でエラーが発生する。

protoファイルをインポートする場合，proto_pathに指定した順番でprotoファイルが検索されます。

例えば，次のディレクトリ構成のとき，proto_pathに複数のディレクトリ（root_dir1，およびroot_dir2）を指定し，protoファイル（foo/bar/root.proto）からほかのprotoファイル（example1/example2/sub.proto）をインポートした場合，foo/bar/root.protoがインポートするprotoファイルは，root_dir1内にあるexample1/example2/sub.protoとなります。

図2‒116　protoファイルをインポートする場合の動作

(4)　HTTP/2の設定

gRPCを利用したシステムでは，HTTP/2を使用してgRPC電文の送受信を行います。サービスプラットフォームで設定できるHTTP/2に関するパラメタについては，マニュアル「サービスプラットフォーム システム構築・構築ガイド」の「3.1.2　実行環境に必要なソフトウェアを設定する」のgRPCインバウンドアダプタの設定に関する説明を参照してください。

HTTP/2の詳細については，RFCのHTTP/2の説明を参照してください。

(5)　保護区リストファイルの設定

gRPCプロトコルを使用する場合，保護区リストファイル（criticalList.cfg）を変更する必要があります。

保護区リストファイルに次の要素を追加してください。

org.codehaus.mojo.animal_sniffer.*
android.annotation.*
org.checkerframework.*
org.apache.commons.codec.*
org.apache.commons.logging.*
com.google.*
io.grpc.*
org.apache.http.*
com.fasterxml.jackson.core.*
io.opencensus.*
io.perfmark.*

保護区リストファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.5　criticalList.cfg（保護区リストファイル）」を参照してください。

(6)　gRPC通信時に出力されるログメッセージについての注意事項

gRPCインバウンドアダプタ，gRPC受付，またはgRPCアダプタ内で利用するOSSからログメッセージ（標準出力および標準エラー出力）を出力した場合，標準出力はJ2EEサーバのユーザ出力ログ（usr_out[n].log），標準エラー出力はユーザエラーログ（usr_err[n].log）に出力されます。

標準出力，および標準エラー出力へのログメッセージの出力を抑制したい場合は，J2EEサーバ用ユーザプロパティファイル（usrconf.properties）のjava.util.logging.config.fileに設定したファイル，またはjava.util.logging設定ファイル（%JAVA_HOME%/conf/logging.properties）に次のプロパティを追加します。

io.grpc.level = OFF

org.apache.commons.logging.level = OFF

com.google.auth.level = OFF

com.google.api.client.level = OFF

com.google.common.level = OFF

org.apache.http.level = OFF

io.opencensus.level = OFF

com.google.protobuf.level = OFF

これらのプロパティを追加すると，OSSのログメッセージは出力されません。

ただし，gRPCに関する機能だけでなく，設定したパッケージを使用するすべての機能でログが出力されなくなります。

2.13.2　gRPC電文（Protocol Buffers形式）とXML形式の変換

gRPC電文（Protocol Buffers形式）とXML形式データの変換について説明します。

gRPC電文とXML形式データの変換は，protoファイルに定義したgRPC電文のメッセージ構造を基に行います。

(1)　gRPC電文（Protocol Buffers形式）とXML形式データの関係

gRPC電文（Protocol Buffers形式）とXML形式データの関係を次に示します。

表2‒48　gRPC電文（Protocol Buffers形式）とXML形式データの関係

Protocol Buffers形式

XML形式

package "mypackage";

message MyMessage {

子要素

…

}

<mypackage.MyMessage>

子要素

…

</mypackage.MyMessage>

gRPC電文のメッセージ構造を定義したprotoファイルで定義した「パッケージ名」と「メッセージ名」を.（ピリオド）で結合し，XMLの要素名とします。

gRPC電文のメッセージ構造を定義したprotoファイルで定義した各フィールド値は，フィールド名をXML要素名とします。XMLの出力内容は，子要素のフィールドタイプによって異なります。

子要素のフィールドタイプごとのXML出力内容を次に示します。

表2‒49　子要素のフィールドタイプごとのXMLの出力内容

フィールドタイプ

XMLの出力内容

double

float

文字列表現（指数表記）

NaN

INF，-INF

int32

int64

uint32

uint64

sint32

sint64

fixed32

fixed64

sfixed32

sfixed64

文字列表現

bool

true

false

string

UTF-8文字列

bytes

バイナリデータをbase64変換した文字列

enum

列挙子

同一列挙値に複数の列挙子が割当てられている場合は，先に定義された列挙子を出力します。

map

キー

値

message

内包するフィールドのフィールド値の規則に従います。

protoファイルでrepeatedが指定されたフィールドは，同一要素名を持つXML要素が連続します。

(2)　gRPC電文とXML形式データのマッピング例

相互変換を行うgRPC電文とXML形式データのマッピング例について説明します。

(a)　int32型のマッピング例

int32型のマッピング例を次に示します。

●protoファイルに定義したProtocol Buffers IDL

package mypackage;
message MyMessage {
  int32 intvar = 1;
}

●gRPC電文

{
  intvar: 100
}

●XML文書

<mypackage.MyMessage>
  <intvar>100</intvar>
</mypackage.MyMessage>

(b)　bytes型のマッピング例

bytes型のマッピング例を次に示します。

●protoファイルに定義したProtocol Buffers IDL

package mypackage;
message MyMessage {
  bytes bytesField = 1;
}

●gRPC電文

{
  bytesField: [0x01,0x02,0x03,0x04]
}

●XML文書

<mypackage.MyMessage>
  <bytesField>AQIDBA==</bytesField>
</mypackage.MyMessage>

(c)　ネストしたメッセージのマッピング例

ネストしたメッセージのマッピング例を次に示します。

●protoファイルに定義したProtocol Buffers IDL

package mypackage;
message MyMessage {
  mesage SubMessage {
    string stringField = 1;
  }
  SubMessage messageField = 1;
}

●gRPC電文

{
  messageField: {stringField: "hello"}
}

●XML文書

<mypackage.MyMessage>
  <messageField>
    <stringField>hello</stringField>
  </messageField>
</mypackage.MyMessage>

(d)　repeated型のフィールドのマッピング例

repeated型のフィールドのマッピング例を次に示します。

●protoファイルに定義したProtocol Buffers IDL

package mypackage;
message MyMessage {
  repeated string stringField = 1;
}

●gRPC電文

{
  stringField: ["hello","goodbye"]
}

●XML文書

<mypackage.MyMessage>
  <stringField>hello</stringField>
  <stringField>goodbye</stringField>
</mypackage.MyMessage>

(e)　enum型のフィールドのマッピング例

enum型のフィールドのマッピング例を次に示します。

●protoファイルに定義したProtocol Buffers IDL

package mypackage;
message MyMessage {
  enum EnumType {
    ZERO = 0;
    ONE = 1;
    ALT_ONE = 1;
  }
  EnumType enumField = 1;
}

●gRPC電文

{
  enumField: ZERO
}

●XML文書

<mypackage.MyMessage>
  <enumField>ZERO</enumField>
</mypackage.MyMessage>

(f)　enum型のフィールドのマッピング例（先に定義された列挙子を出力する場合）

enum型のフィールドのマッピング例（先に定義された列挙子を出力する場合）を次に示します。この例では，同一列挙値（=1）のONEおよびALT_ONEの2つの列挙子を定義しているため，定義順が先の列挙子に変換されます。

●protoファイルに定義したProtocol Buffers IDL

package mypackage;
message MyMessage {
  enum EnumType {
    ZERO = 0;
    ONE = 1;
    ALT_ONE = 1;
  }
  EnumType enumField = 1;
}

●gRPC電文

{
  enumField: ALT_ONE
}

●XML文書

<mypackage.MyMessage>
  <enumField>ONE</enumField>
</mypackage.MyMessage>

(g)　map型のフィールドのマッピング例

map型のフィールドのマッピング例を次に示します。

●protoファイルに定義したProtocol Buffers IDL

package mypackage;
message MyMessage {
  map<string, uint32> mapField = 1;
}

●gRPC電文

{
  mapField: [{"key1",1234},{"key2",9999}]
}

●XML文書

<mypackage.MyMessage>
  <mapField>
    <key>key1</key>
    <value>1234</value>
  </mapField>
  <mapField>
    <key>key2</key>
    <value>9999</value>
  </mapField>
</mypackage.MyMessage>

(3)　proto-XMLスキーマの出力ファイル形式

proto-XMLスキーマの出力ファイル形式を次に示します。

XMLスキーマは，タイプ定義部およびルート要素定義部によって構成されます。

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="メッセージタイプ名"
    xmlns="メッセージタイプ名"
    elementFormDefault="qualified">
 タイプ定義部[0..n]
 ルート要素定義部[1..1]
</xs:schema>

(a)　タイプ定義部

タイプ定義部は0個以上のメッセージ型定義，または列挙型定義によって構成されます。

■メッセージ型定義

<xs:complexType name="完全メッセージ型名">
 <xs:sequence>
 項目定義[1..n]
 </xs:sequence>
</xs:complexType>

「完全メッセージ型名」は，「パッケージ名.[親メッセージタイプ名称.]メッセージタイプ名称」の形式を持つ文字列です。「親メッセージタイプ名」の部分は，再帰的に適用されます。

■列挙型定義

<xs:simpleType name="完全列挙型名">
 <xs:restriction base="xs:string">
 列挙値定義[1..n]
 </xs:restriction>
</xs:simpleType>

「完全列挙型名」は，「パッケージ名.[親メッセージタイプ名称.]列挙型」の形式を持つ文字列です。「親メッセージタイプ名」の部分は再帰的に適用されます。

「列挙値定義」は，次の内容で生成されます。

<xs:enumeration value="列挙値"/>

(b)　ルート要素定義部

ルート要素定義部は次の内容で生成されます。

<xs:element name="ルート要素名" type="ルート要素タイプ"/>

「ルート要素名」および「ルート要素タイプ」は，「パッケージ名.メッセージタイプ名称」の形式を持つ文字列です。

(c)　項目定義

項目定義は単純項目定義，およびONEOF定義のどちらかで生成されます。

■単純項目定義

単純項目定義は次の内容で生成されます。

repeatedが指定されていない場合

<xs:element name="項目名" type="タイプ名" minOccurs="0"/>

repeatedが指定されている場合

<xs:element name="項目名" type="タイプ名" minOccurs="0" maxOccurs="unbounded"/>

「タイプ名」の一覧を次に示します。

表2‒50　単純項目定義のタイプ名一覧

protoファイルに定義した項目のタイプ名

生成されるXMLスキーマの項目のタイプ名

string

xs:string

bytes

xs:base64Binary

int32

xs:int

sint32

sfixed32

int64

xs:long

sint64

sfixed64

uint32

xs:unsignedInt

fixed32

uint64

xs:unsignedLong

fixed64

bool

xs:boolean

float

xs:float

double

xs:double

型参照

メッセージ型名，または列挙型名

■ONEOF定義

ONEOF定義は，次の内容で生成されます。

<xs:element name="ONEOF名">
 <xs:complexType>
 <xs:choice>
 項目定義[1..n]
 </xs:choice>
 </xs:complexType>
</xs:element>

「項目定義」内のminOccurs属性は出力されません。

(d)　XMLスキーマ変換例

ここでは，protoファイルからXMLスキーマを生成した場合の変換例について説明します。

■例1　すべてのメッセージタイプの一括変換

descriptor setファイル内に定義されたすべてのrpcが使用するメッセージタイプのXMLスキーマを生成する場合の変換例を次に示します。

●Descriptor Setファイルの作成に使用したprotoファイル

syntax = "proto3";

option java_multiple_files = true;
option java_package = "io.grpc.examples.sampledata";
option java_outer_classname = "SampleDataProto";
option objc_class_prefix = "HLW";

package sampledata;

// サービス定義
service UserInfoManager {
  rpc GetUserInfo (UserInfo) returns (UserData) {}
  rpc UpdateUserInfo (UserData) returns (UserData) {}
}

service ProductInfoManager {
  rpc UpdateProductInfo (ProductData) returns (ProductData) {}
}

// リクエストまたはレスポンスメッセージ
message UserInfo {
  string userid = 1;
}

message UserData {
  string name = 1;
  string age = 2;
}

message ProductData {
  string name = 1;
  string price = 2;
}

●生成されたXMLスキーマファイル

・UserInfo

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="sampledata.UserInfo"
    xmlns="sampledata.UserInfo"
    elementFormDefault="qualified">

    // タイプ定義部
    <xs:complexType name="sampledata.UserInfo">
        <xs:sequence>
            <xs:element name="userid" type="xs:string" minOccurs="0" />
        </xs:sequence>
    </xs:complexType>

    // ルート要素定義部
    <xs:element name="sampledata.UserInfo" type="sampledata.UserInfo"/>
</xs:schema>

・UserData

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="sampledata.UserData"
    xmlns="sampledata.UserData"
    elementFormDefault="qualified">

    // タイプ定義部
    <xs:complexType name="sampledata.UserData">
        <xs:sequence>
            <xs:element name="name" type="xs:string" minOccurs="0" />
            <xs:element name="age" type="xs:string" minOccurs="0" />
        </xs:sequence>
    </xs:complexType>

    // ルート要素定義部
    <xs:element name="sampledata.UserData" type="sampledata.UserData"/>
</xs:schema>

・ProductData

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="sampledata.ProductData"
    xmlns="sampledata.ProductData"
    elementFormDefault="qualified">

    // タイプ定義部
    <xs:complexType name="sampledata.ProductData">
        <xs:sequence>
            <xs:element name="name" type="xs:string" minOccurs="0" />
            <xs:element name="price" type="xs:string" minOccurs="0" />
        </xs:sequence>
    </xs:complexType>

    // ルート要素定義部
    <xs:element name="sampledata.ProductData" type="sampledata.ProductData"/>
</xs:schema>

■例2　特定のサービスが使用するメッセージタイプの変換

引数で指定したサービスに定義された，すべてのrpcが使用するメッセージタイプのXMLスキーマを生成する場合の変換例を次に示します。

●Descriptor Setファイルの作成に使用したprotoファイル

例2のDescriptor Setファイルの作成に使用したprotoファイルは，例1と同じです。

●生成されたXMLスキーマファイル

・UserInfo

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="sampledata.UserInfo"
    xmlns="sampledata.UserInfo"
    elementFormDefault="qualified">

    // タイプ定義部
    <xs:complexType name="sampledata.UserInfo">
        <xs:sequence>
            <xs:element name="userid" type="xs:string" minOccurs="0" />
        </xs:sequence>
    </xs:complexType>

    // ルート要素定義部
    <xs:element name="sampledata.UserInfo" type="sampledata.UserInfo"/>
</xs:schema>

・UserData

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="sampledata.UserData"
    xmlns="sampledata.UserData"
    elementFormDefault="qualified">

    // タイプ定義部
    <xs:complexType name="sampledata.UserData">
        <xs:sequence>
            <xs:element name="name" type="xs:string" minOccurs="0" />
            <xs:element name="age" type="xs:string" minOccurs="0" />
        </xs:sequence>
    </xs:complexType>

    // ルート要素定義部
    <xs:element name="sampledata.UserData" type="sampledata.UserData"/>
</xs:schema>

■例3　特定のサービスの中のrpcが使用するメッセージタイプの変換

引数で指定したrpcが使用するメッセージタイプのXMLスキーマを生成する場合の変換例を次に示します。

●生成されたXMLスキーマファイル

・ProductData

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="sampledata.ProductData"
    xmlns="sampledata.ProductData"
    elementFormDefault="qualified">

    // タイプ定義部
    <xs:complexType name="sampledata.ProductData">
        <xs:sequence>
            <xs:element name="name" type="xs:string" minOccurs="0" />
            <xs:element name="price" type="xs:string" minOccurs="0" />
        </xs:sequence>
    </xs:complexType>

    // ルート要素定義部
    <xs:element name="sampledata.ProductData" type="sampledata.ProductData"/>
</xs:schema>

■例4　google/protobuf/struct.protoから作成したDescriptor Setファイルを基に生成した場合の変換例

Googleがサポートしているgoogle/protobuf/struct.protoから作成したDescriptor Setファイルを基に，XMLスキーマを生成した場合の変換例を次に示します。

なお，メッセージタイプの変換例のため，サービスの定義は省略します。

●struct.proto

●生成されたXMLスキーマファイル

2.13.3　gRPC受付の機能

gRPC受付では，gRPCインバウンドアダプタから渡されたメッセージから，要求電文を作成し，ビジネスプロセスに渡します。

また，ビジネスプロセスから渡された応答電文から返却するメッセージを作成し，インバウンドアダプタに返します。

図2‒117　gRPC受付を利用した処理の流れ

なお，1つのgRPCインバウンドアダプタから複数のgRPC受付に接続できます。複数のgRPC受付から1つのビジネスプロセスに接続することもできます。

gRPC受付の通信モデルは，同期通信です。

gRPC受付では，ビジネスプロセスの処理時間（要求電文を渡して応答電文が返ってくるまでの処理時間）は監視しません。

gRPC受付の定義の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「2.10.2　gRPC受付を追加する」を参照してください。

(1)　フォルト応答

gRPCクライアントに任意のgRPCのエラー応答（ステータスコードやエラー情報など）を返す場合，ビジネスプロセスからフォルトが発生したことを示す応答電文を送信します。

図2‒118　gRPC受付のフォルト応答

gRPC受付では，ビジネスプロセスから返却されたフォルト電文をgRPCのエラー情報（gRPCのオブジェクト）に変換し，gRPCインバウンドアダプタにデータを渡します。

また，gRPCクライアントに返すエラー情報には，gRPCのメタデータを含むことができます。メタデータを含む場合は，フォルト電文にメタデータの設定内容を定義します。メタデータの設定については，「(2)メタデータ」を参照してください。

フォルト電文の設定の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「2.10.3　フォルト電文フォーマットを修正する」を参照してください。

(2)　メタデータ

gRPCクライアントから送信されたメタデータの内容を，ビジネスプロセスで参照できます。また，gRPCクライアントにメタデータを返却できます。

gRPCクライアントからメタデータが送信された場合，gRPC受付はヘッダ電文にメタデータの内容を設定し，ビジネスプロセスにヘッダ電文を渡します。

gRPCクライアントにメタデータを返す場合，ビジネスプロセスからヘッダ電文を返します。

ビジネスプロセスから返却されたヘッダ電文が，次の条件をすべて満たす場合，gRPC受付にヘッダ電文が返却されたとみなされます。

ヘッダ電文の名前空間接頭辞が「grc」である。

ヘッダ電文のルート要素が接頭辞「grc」で修飾されている。

また，上記に該当するヘッダ電文内の，接頭辞「grc」で修飾されていない要素は，要素が指定されていないとみなされます。

gRPC受付のヘッダ電文はサービスプラットフォームが提供するスキーマを使用します。そのため，ヘッダ電文の作成は不要です。

送受信するメタデータの値は，テキスト形式またはバイナリ形式で設定できます。どちらのデータ形式かは，メタデータのキー名によって判断します。

バイナリ形式：メタデータのキー名が-bin（大文字小文字を区別する）で終わる場合

テキスト形式：メタデータのキー名が-bin以外で終わる場合

データ形式はメタデータのキーごとに設定できます。

(3)　流量制御

gRPCクライアントとサービスプラットフォームを接続する場合，gRPC受付で流量制御を設定できます。流量制御の設定については，gRPC受付定義ファイルで設定します。

gRPC受付定義ファイルの設定の詳細については，マニュアル「サービスプラットフォーム リファレンス」の「3.17.1　gRPC受付定義ファイル」を参照してください。

流量制御で設定できる項目を次に示します。

表2‒51　流量制御の設定項目

項目

オブジェクト

説明

プール内インスタンスの最小数

urecp-grpc.pooled-instance.minimum

カスタム受付フレームワークのプール内インスタンスの最小数を指定します。

プール内インスタンスの最大数

urecp-grpc.pooled-instance.maximum

受付処理およびカスタム受付フレームワークのプール内インスタンスの最大数を指定します。

(4)　gRPC受付使用時のトランザクション

gRPC受付で開始される新たなトランザクションは，受付処理が操作します。

ビジネスプロセスを呼び出すときのgRPC受付のトランザクションの範囲を次に示します。

図2‒119　gRPC受付のトランザクションの範囲

2.13.4　gRPCインバウンドアダプタの機能

gRPCインバウンドアダプタは，RPCプロトコル「gRPC」を利用するgRPCクライアントからの要求電文を受信し，gRPC受付から返される応答電文をgRPCクライアントに返信します。JCA1.5に準拠しています。

gRPCインバウンドアダプタでは，次のOSSの機能を使用できます。

メッセージ圧縮機能（gRPCの要求電文，応答電文の双方でメッセージ圧縮機能をサポート）

メタデータの送受信（gRPCの要求電文の受信，応答電文の送信，双方でメタデータをサポート）

SSL/TLS

フローコントロール

キープアライブ

(1)　サポートするgRPC通信種別

gRPCインバウンドアダプタでは，gRPC通信種別の「Simple-RPC(Unary)」をサポートしています。「Simple-RPC(Unary)」は，gRPCクライアントからの1つのリクエストに対して，gRPCサーバが1つのレスポンスを返す通信種別です。

(2)　gRPCインバウンドアダプタの流量制御

gRPCインバウンドアダプタでは，gRPCクライアントからのリクエストを受信した場合，スレッドプールからスレッドを割り当ててリクエスト処理を実行します。スレッドプールのスレッド数を指定し，同時に実行できるスレッドを制御することで，パフォーマンスの低下やリソースの枯渇を抑制できます。

threadPoolSize（リクエストを処理するスレッドプールのスレッド数）には，gRPCクライアントの同時実行数をスレッド数として設定します。

threadPoolSizeについては，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「3.1.2　実行環境に必要なソフトウェアを設定する」のthreadPoolSizeについて説明している個所を参照してください。

図2‒120　gRPCインバウンドアダプタの流量制御

gRPCインバウンドアダプタでは，スレッドプールを使用し，一度作成したスレッドを再利用して処理を実行します。スレッドプール内のスレッド数は，属性ファイルから設定できます。

タスクを処理するスレッドプールのスレッド数に10を設定した場合の遷移の例を次の図に示します。

図2‒121　gRPCインバウンドアダプタのスレッド数の遷移の例

この例では，属性ファイルに次のように設定しています。

threadPoolSize=10

gRPCインバウンドアダプタ起動直後は，スレッドは生成されません。

7つのリクエストが同時に実行された場合，7つのスレッドが作成され，実行中スレッドとなります。

リクエスト処理の実行が完了した場合，実行が完了したスレッドはアイドルスレッドとなります。リクエスト処理が完了してもスレッドは破棄されません。

スレッドプールのスレッド数（threadPoolSize）を超えるリクエストが同時に実行された場合，threadPoolSizeに指定した値を超えた分のリクエスト処理要求は，実行待ちキューにタスクとして追加され，処理を待機します。実行中のスレッドの処理が終了し，スレッドに空きが発生するとキューからタスクが取り出されます。

(3)　gRPCインバウンドアダプタ使用時の注意事項

gRPCインバウンドアダプタ使用時の注意事項を次に示します。

gRPCインバウンドアダプタがサポートするgRPC電文フォーマットの仕様はproto3以上です。proto2以前の電文フォーマットは使用できません。

同一完全修飾サービス名を持つ複数のgRPCサービスは登録できません。同一完全修飾サービス名を持つgRPCサービスは，先に登録されたサービスだけが有効となり，それ以外は無効となります。

2.13.5　gRPCアダプタの機能

gRPCアダプタは，gRPCで作成されたサービスにメッセージを送信するためのサービスアダプタです。gRPCアダプタがサポートするgRPC電文フォーマットは，proto3以上です。proto2以前の電文フォーマットはサポートしません。

また，gRPCアダプタを使用するには，OSSのインストールが必要です。必要なOSSについては，「2.13.1(1)　gRPCプロトコルを利用した接続に必要なOSS」を参照してください。

gRPCアダプタには，次の機能があります。

サーバ呼び出し機能

gRPCサーバと通信を行い，gRPCサービスにメッセージを送受信します。リクエスト処理の延長でgRPCサーバと接続するため，gRPCアダプタの起動時に接続先のgRPCサーバを起動しておく必要がありません。gRPCアダプタが呼び出すメソッドは，gRPCアダプタの開発時に指定したprotoファイルに定義されているサービス定義のメソッドです。

proto-XML変換機能

ビジネスプロセスから渡された要求電文をgRPCサービスに送信し，メッセージ（プロトコルバッファ）に変換します。メッセージは，メソッド定義の引数に沿って作成されます。

また，gRPCサービスから返されたメッセージ（プロトコルバッファ）を応答電文に変換します。応答電文は，開発環境で設定された応答電文スキーマに沿って作成されます。

gRPCアダプタとgRPCサーバ間では，メッセージはプロトコルバッファと呼ばれるシリアライズ方式を用いて変換されます。

gRPCアダプタのメッセージの処理の流れを次に示します。

図2‒122　gRPCアダプタのメッセージの処理の流れ

ビジネスプロセスからgRPCアダプタに要求電文が渡されます。

要求電文をgRPCサーバに送信するメッセージに変換します。

要求電文が電文フォーマット（要求電文ボディ）に沿っていない場合，メッセージの作成でエラーとなり，リクエストが失敗します。

変換したメッセージをサーバ呼び出し機能に渡します。

gRPCサービスにメッセージを送信します。

gRPCサービスから返却されたメッセージを受け取ります。

proto-XML変換機能にメッセージを渡します。

メッセージを応答電文に変換します。

応答メッセージがメソッド定義の戻り値に沿っていない場合，応答メッセージの受信でエラーとなり，リクエストが失敗します。

応答電文をビジネスプロセスに渡します。

gRPCアダプタのオペレーション（サービスアダプタ定義画面の「オペレーション」）は，gRPCアダプタの開発時に指定したサービス定義のメソッド（protoファイルのサービス定義）で設定します。

例えば，サービス定義内にメソッド「SayHello」「SayGoodbye」が定義されている場合，gRPCアダプタのオペレーションに「SayHello」「SayGoodbye」が定義されます。サービスアダプタ定義画面でオペレーション「SayHello」を呼び出した場合は，gRPCサービスのメソッド「SayHello」が呼び出されます。

gRPCアダプタの定義の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.2.17　gRPCアダプタを新規に追加する」を参照してください。

(1)　gRPCアダプタの構成

gRPCサーバは，複数のgRPCサービスで構成されている場合があります。gRPCアダプタがメッセージを送信するgRPCサービスは，gRPCアダプタの開発時に決定するため，リクエスト時に変更することはできません。

図2‒123　gRPCアダプタの構成

gRPCアダプタとgRPCサーバの数量関係は1:Nです。

gRPCアダプタとgRPCサービスの数量関係は1:1です。

gRPCアダプタとメソッドの数量関係は1:Nです。ただし，1回のリクエストで呼び出せるメソッドは1つだけです。

メソッドは同期で呼び出します。非同期呼び出しは設定できません。

(2)　メタデータ

gRPCアダプタは，メッセージ（プロトコルバッファ）に加え，メタデータ（キーと値のペアの任意のセット）を送受信できます。

メタデータ送受信の処理の流れを次に示します。

図2‒124　メタデータ送受信の処理の流れ

gRPCサービスへ送信するメタデータ

ビジネスプロセスから渡されたヘッダ電文の設定内容からメタデータを作成し，gRPCサービスにメタデータを送信します。

データ形式がバイナリ形式のメタデータを送信する場合，ヘッダ電文内の該当するメタデータの値にはBase64でエンコードした値を設定します。

gRPCアダプタ内で，デコードした値をメタデータの値に設定します。

gRPCサービスから受信したメタデータ

gRPCサービスから，ステータスコード「OK」が返された場合は，gRPCサービスから受信したメタデータの設定内容からヘッダ電文を作成し，ビジネスプロセスに渡します。ヘッダ電文に設定するメタデータは，gRPCサービスが設定したメタデータ，およびgRPC内で設定されたメタデータとします。

また，フォルト応答で，gRPCサービスから返却された例外にメタデータが設定されている場合，例外に設定されているメタデータをフォルト電文に設定します。

メタデータのデータ形式がバイナリ形式の場合，gRPCアダプタは該当するメタデータの値をBase64でエンコードした値をヘッダ電文に設定します。

送受信するメタデータの値は，テキスト形式またはバイナリ形式で設定できます。どちらのデータ形式かは，メタデータのキー名によって判断します。

バイナリ形式：メタデータのキー名が-bin（大文字小文字を区別する）で終わる場合

テキスト形式：メタデータのキー名が-bin以外で終わる場合

データ形式はメタデータのキーごとに設定できます。

メタデータの設定内容は，ヘッダ電文で扱われます。ただし，gRPCサービスから返された例外に設定されているメタデータは含まれません。

ヘッダ電文の設定については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.17　gRPCアダプタを定義する」を参照してください。

(3)　フォルト応答

gRPCアダプタでは，次のフォルト応答を設定できます。

ステータスコードに応じたフォルト応答

システム例外発生時のフォルト応答

それぞれのフォルト応答について説明します。

(a)　ステータスコードに応じたフォルト応答

gRPCアダプタでは，gRPC呼び出し実行時に返されたステータスコードが「OK」以外の場合に，フォルト応答としてフォルトを返す設定ができます。フォルト応答は，gRPCアダプタ独自定義ファイルのadpgrpc.response-code.faultで設定します。

gRPCサービスから返されたステータスコードが，gRPCアダプタ独自定義ファイルのadpgrpc.response-code.faultに指定したステータスコードのどれかと一致する場合にフォルト応答を行います。

gRPCアダプタのフォルト応答では，例外情報を基にフォルト電文を作成し，フォルト応答としてフォルト電文をビジネスプロセスに返します。

フォルト電文の設定については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.17　gRPCアダプタを定義する」を参照してください。

ステータス情報には詳細メッセージが設定されている場合があります。詳細メッセージが，gRPCが提供しているprotoファイルであるerror_details.proto（エラーの詳細に関する標準エラーペイロードのセット）内に定義されているメッセージのとき，gRPCアダプタはフォルト電文内の詳細メッセージを設定するための要素に，メッセージの内容を設定します。対象のメッセージを次に示します。

RetryInfo

DebugInfo

QuotaFailure

ErrorInfo

PreconditionFailure

BadRequest

RequestInfo

ResourceInfo

Help

LocalizedMessage

error_details.proto内に定義されていないメッセージの場合，フォルト電文のadditional-messageタグにメッセージの内容を設定します。

(b)　システム例外発生時のフォルト応答

gRPCアダプタでシステム例外が発生した場合，またはgRPC呼び出し実行時に例外が発生した場合，システム例外をフォルトに変換して，ビジネスプロセスにフォルト応答を返すことができます。

システム例外発生時のフォルト応答を行うには，次の条件をすべて満たす必要があります。

gRPCアダプタ独自定義ファイルのadpgrpc.response-code.faultに指定したステータスコードのどれとも一致しない。

サービスアダプタ定義画面で［システム例外をフォルトに変換する］をチェックしている。

(4)　メッセージの圧縮と解凍

gRPCサービスにgzip形式で圧縮したメッセージを送信できます。また，gRPCサービスからgzip形式で圧縮されたメッセージが返された場合，メッセージを解凍します。メッセージの圧縮は，gRPCアダプタ独自定義ファイルのadpgrpc.protocol.message-compression.enabledで設定します。gRPCサービスから返されたメッセージがgzip形式以外で圧縮されたデータの場合，リクエストはエラーとなります。

(5)　gRPCアダプタのセキュリティ

gRPCアダプタとgRPCサーバ間で交換されるすべてのデータを暗号化できます。gRPCアダプタでは，次の認証方式をサポートしています。

SSL/TLS

Token-based authentication with Google

(a)　SSL/TLSの設定

SSL/TLS認証を設定する場合，gRPCアダプタ実行環境（共通）プロパティファイルのadpgrpc.request.use-plaintextにfalseを設定する必要があります。

また，設定する項目は，認証方式によって異なります。認証方式ごとの設定項目を次に示します。

表2‒52　認証方式ごとの設定項目

認証方式

設定項目

プロパティ

設定の要否

サーバ認証

サーバのルート証明書

adpgrpc.security.tls.certificate-chain

任意

双方向認証※

サーバのルート証明書

adpgrpc.security.tls.certificate-chain

任意

クライアントの証明書チェーン

adpgrpc.security.tls.client.certificate-chain

必須

クライアントの秘密鍵

adpgrpc.security.tls.client.private-key

必須

クライアントの秘密鍵のパスワード

adpgrpc.security.tls.client.private-key-password

任意

注※

双方向認証をする場合，必須の情報がすべて設定されている必要があります。設定されていない場合は，双方向認証は行われません。

(b)　Token-based authentication with Googleの設定

gRPCアダプタからGoogle API（Google社が提供する各種サービスにアクセスする機能）を呼び出す場合に必要な認証です。

Token-based authentication with Googleの設定は，gRPCアダプタ実行環境（共通）プロパティファイルで設定します。Token-based authentication with Googleについての設定項目を次に示します。

表2‒53　Token-based authentication with Google認証の設定項目

設定項目

プロパティ

設定の要否

説明

スコープ

adpgrpc.security.token-based-auth.scope

任意

Google APIへのアクセスに必要となるOAuth 2.0スコープを指定します。

認証されたユーザを承認するかどうかを判定するために設定します。

クレデンシャル

adpgrpc.security.token-based-auth.credentials

必須

サービスアカウントキーファイルを指定します。ファイルの内容がJSON形式でない場合の動作は保証されません。

アクセストークンの有効期限が切れた場合，自動的にアクセストークンはリフレッシュされます。そのため，ユーザがアクセストークンを手動で再取得する必要はありません。

(6)　gRPCアダプタのタイムアウト

gRPCアダプタのタイムアウトは，gRPCアダプタ独自定義ファイルで設定します。

表2‒54　gRPCアダプタのタイムアウトの設定項目

設定項目

プロパティ

説明

キープアライブ

PINGの送信間隔

adpgrpc.protocol.keepalive-time

キープアライブPINGの送信間隔を指定します。

タイムアウト時間

adpgrpc.protocol.keepalive-timeout

キープアライブタイムアウト時間を指定します。

設定した時間が経過しても接続先から応答がない場合，接続を終了します。再度RPC要求があるまで再接続はしません。

未処理のRPCがない場合の動作

adpgrpc.protocol.keepalive-without-calls

未処理のRPCがない場合に，キープアライブを実行するかどうかを指定します。

アイドルタイムアウト時間

adpgrpc.protocol.idle-timeout

チャネルの状態をアイドル状態に移行するまでの時間を指定します。

アイドル状態になった場合，再度RPC要求があるまで再接続はしません。

リクエストの実行期限

adpgrpc.protocol.deadline

RPCがDEADLINE_EXCEEDEDでエラー終了する前の，RPCの完了待ち時間を指定します。

gRPCアダプタの接続先が利用できるようになるまで，gRPC呼び出しを待機します。実行期限が経過してもRPCが完了しなかった場合，リクエストはエラーとなり，ステータスコード「DEADLINE_EXCEEDED」が返されます。

gRPCで指定できるタイムアウトの関係を次に示します。

図2‒125　gRPCで指定できるタイムアウトの関係

リクエストの実行期限

キープアライブ（未処理のRPCがない場合に，キープアライブを実行する場合）

キープアライブ（未処理のRPCがない場合に，キープアライブを実行しない場合）

アイドルタイムアウト時間

キープアライブタイムアウトの流れを次に示します。

図2‒126　キープアライブタイムアウトの流れ

キープアライブPINGの送信間隔が10分の場合，「キープアライブPINGの応答」の10分後に，gRPCアダプタはキープアライブPINGを送信します。

キープアライブタイムアウトが20秒の場合，gRPCアダプタがキープアライブPINGを送信してから20秒以内に「キープアライブPINGの応答」がないときはタイムアウトしたとみなされます。

2.14　メールサーバとの接続

メールアダプタを利用することで，サービスプラットフォームとメールサーバとを接続できます。

2.14.1　前提条件

メールアダプタを利用するための前提条件を次に示します。

メールサーバはHCSCサーバと同じLAN上に配置する必要があります。

メールアダプタはJavaMailの仕様に従い，SMTPプロトコルをサポートした（RFC821に準拠した）メールサーバをサポートしています。

2.14.2　メールアダプタを使用したシステム

メールアダプタは，SMTPプロトコルをサポートしたメールサーバをサービスプラットフォーム上でサービスとして呼び出すことができます。

メールアダプタを利用することで，ビジネスプロセスが正常に完了した場合や，システムに障害が発生した場合に，ユーザやシステム管理者にメールで通知できるようになります。また，FTP受付やFTPアダプタと連携して利用することで，任意のファイルをメールに添付して送信することもできます。

メールアダプタを利用したシステムの例を次に示します。

FTPクライアントから転送されたファイルをメールに添付して送信する

FTPサーバから取得したファイルをメールに添付して送信する

ワークフロー案件の承認依頼をメールで送信する

非同期のビジネスプロセスの完了通知をメールで送信する

ビジネスプロセスの実行中に障害が発生したことをメールで通知する

それぞれのシステムの例について説明します。なお，FTP受付やFTPアダプタの機能については，「8.　FTPと連携してファイルを転送する機能（FTP連携）」を参照してください。

また，TLSを利用した暗号化をサポートしているメールサーバとの連携に関する設定方法については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「付録J　メールアダプタで必要なセキュリティの設定」を参照してください。

(1)　FTPクライアントから転送されたファイルをメールに添付して送信する

この例では，ユーザがFTPクライアントから転送したファイルをメールに添付して別のユーザに送信しています。

図2‒127　メールアダプタを利用したシステムの例（1）

メール送信および添付ファイルの流れを次に示します。なお，次の番号は図中の番号と対応しています。

ユーザAのFTPクライアントからPUTオペレーションで任意のファイルをサービスプラットフォームに転送します。転送されたファイルは，FTP受付が作成したHCSCサーバ内の作業フォルダに保存されます。

ビジネスプロセスから呼び出されたファイル操作アダプタによって，作業フォルダのファイルが共通フォルダにコピーされます。また，必要に応じてファイル操作アダプタでフォーマット変換／ファイル変換が実施されます。

ビジネスプロセスからメールアダプタが呼び出されます。

共通フォルダのファイルがメールの添付ファイルとして設定されます。

メールアダプタから同一LAN内のメールサーバにメールが送信されます。

添付ファイルが設定されたメールがネットワークを介してメールサーバからユーザBに送信されます。

(2)　FTPサーバから取得したファイルをメールに添付して送信する

この例では，SOAPクライアントからビジネスプロセスを開始したあと，FTPアダプタ経由でFTPサーバから取得されたファイルをメールに添付して，別のユーザに送信しています。

図2‒128　メールアダプタを利用したシステムの例（2）

メール送信および添付ファイルの流れを次に示します。なお，次の番号は図中の番号と対応しています。

ユーザAのサービスリクエスタ（SOAPクライアント）からサービスプラットフォームのWebサービスを呼び出します。

ビジネスプロセスからFTPアダプタが呼び出されます。

FTPアダプタのGETオペレーションによって，FTPサーバから共通フォルダにファイルが転送されます。

ビジネスプロセスからメールアダプタが呼び出されます。

共通フォルダに保存されたファイルがメールの添付ファイルとして設定されます。

メールアダプタから同一LAN内のメールサーバにメールが送信されます。

添付ファイルが設定されたメールがネットワークを介してメールサーバからユーザBに送信されます。

(3)　ワークフロー案件の承認依頼をメールで送信する

この例では，ビジネスプロセスからサービスアダプタ経由でワークフローアプリケーションが呼び出されたあと，承認者に承認依頼メールを通知してワークフローを処理しています。

図2‒129　メールアダプタを利用したシステムの例（3）

メール送信の流れを次に示します。なお，次の番号は図中の番号と対応しています。

ユーザAのサービスリクエスタ（SOAPクライアント）からサービスプラットフォームのWebサービスを呼び出します。

ビジネスプロセスからサービスアダプタを経由してワークフローアプリケーションが呼び出されます。

ワークフローの処理が開始され，承認プロセス待ちの状態になります。

ビジネスプロセスからメールアダプタが呼び出されます。

承認サイトのURLがメール本文に設定されます。

メールがユーザB（承認者）に送信されたあと，ユーザB（承認者）は，メール本文に記載されたURLをクリックして承認プロセスを実施します。

(4)　非同期のビジネスプロセスの完了通知をメールで送信する

非同期のビジネスプロセスの場合，サービスリクエスタへの応答後にビジネスプロセスの処理が続行しても，ユーザには以降の処理の完了が通知されません。この例では，メールアダプタを使用して，非同期のビジネスプロセスが完了したことをユーザにメールで通知しています。

図2‒130　メールアダプタを利用したシステムの例（4）

メール送信の流れを次に示します。なお，次の番号は図中の番号と対応しています。

ユーザAのサービスリクエスタ（SOAPクライアント）からサービスプラットフォームのWebサービスを呼び出します。

ユーザAのサービスリクエスタに応答電文が返されます。

非同期のビジネスプロセスからサービスアダプタが呼び出され，サービスを実行します。

非同期のビジネスプロセスからメールアダプタが呼び出されます。

サービス呼び出しの処理が正常に完了したことがメール本文に記載されます。

ユーザBにメールが送信されたあと，ユーザBは処理が完了したことを確認します。

(5)　ビジネスプロセスの実行中に障害が発生したことをメールで通知する

この例では，ビジネスプロセスのサービス呼び出し中にエラーが起きた場合に，メール経由でシステム管理者にエラーを通知しています。

図2‒131　メールアダプタを利用したシステムの例（5）

メール送信の流れを次に示します。なお，次の番号は図中の番号と対応しています。

ユーザAのサービスリクエスタ（SOAPクライアント）からサービスプラットフォームのWebサービスを呼び出します。

ビジネスプロセスのスコープ内でサービス呼び出し中に障害が発生し，サービスリクエスタにフォルト電文が返されます。

ビジネスプロセスの処理がエラー時のフロー（フォルト処理）に遷移します。

フォルト処理内でメールアダプタが呼び出されます。

エラーメッセージがメール本文に記載されます。

ユーザB（システム管理者）にメールが送信されたあと，ユーザB（システム管理者）はエラーの発生を確認し，トラブルシュートを実施します。

2.14.3　メールアダプタ使用時のトランザクション

メールアダプタを使用した場合のトランザクションの範囲を次の図に示します。

図2‒132　メールアダプタを使用した場合のトランザクションの範囲

メールサーバへの処理（メール送信）が完了したあとにビジネスプロセスの処理でエラーが発生した場合，トランザクションはロールバックされ，ビジネスプロセスにエラーが返されます。しかし，メールサーバに送信したメールは引き戻すことはできません。

2.14.4　メールアダプタで設定できるメール情報

メールアダプタでは，メールを送信するときに必要な情報を要求電文またはメールアダプタ実行環境プロパティファイルで設定できます。要求電文とメールアダプタ実行環境プロパティファイルの両方で指定された場合は，要求電文が優先されます。

メールアダプタで設定できるメール情報を次の表に示します。

表2‒55　設定できるメール情報

大分類

小分類

設定内容

アドレス

アドレス種別

メールのアドレス種別（TO/CC/BCC），および宛先に指定する電子メールアドレスを設定できます。

メールの主題

−

メールの主題を設定できます。

メールの本文

メール本文の内容

次の方法でメールの本文を設定できます。

メール本文の内容を直接記述する

メール本文の内容が記述されたファイルのパスを指定する※

メール形式

メールの形式を指定できます。

メールアダプタがサポートする形式を次に示します。

テキスト形式

HTML形式

XML形式

エンコード

メール送信時のエンコードを指定できます。

エンコードを指定しなかった場合，ISO-2022-JPが使用されます。

文字セット

メール本文の内容が記述されたファイルを読み込んでメール本文に設定する場合，テキストの文字セットを指定できます。

文字セットを指定しなかった場合，UTF-8が使用されます。

添付ファイル

−

メールに添付するファイルのパスを指定できます。※

メールヘッダ

−

メールの重要度，返信要求の有無など，ユーザが定義したメールヘッダのオプションを設定できます。

（凡例）

−：該当する項目はありません。

注※

メールアダプタでは，メール本文として使用するファイルおよび添付ファイルに，共通フォルダルートの配下のサブフォルダを指定できます。共通フォルダルートの配下のサブフォルダは，メールアダプタ要求電文の/request/mail-body/file/mail-body-file-name，または/request/attachment-file/item/attach-file-nameに共通フォルダルートからファイル名までの相対パスを指定します。指定例を次に示します。

<request>
      ：
  <folder-name common="true">default</folder-name>
  <mail-body-file-name>/folder1/folder2/body.txt</mail-body-file-name>
      ：
  <attach-folder common="true">default<attach-folder>
  <attach-file-name>/folder1/folder2/attach.txt</attach-file-name>
      ：
</request>

要求電文で設定できる項目の詳細は，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.12　メールアダプタを定義する」のadpmail_smtp_request.xsd（要求電文フォーマットファイル）について説明している個所を参照してください。メールアダプタ実行環境プロパティファイルで設定できる項目の詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.13.3　メールアダプタ実行環境プロパティファイル」を参照してください。

2.14.5　メールアダプタのタイマ管理

ここでは，メールアダプタのタイマ管理の概要，およびタイムアウト値の設定方法について説明しています。

メールアダプタでは，再接続タイムアウトおよび排他管理タイムアウトを設定できます。各タイムアウト値は，メールアダプタ実行環境プロパティファイルで設定できます。メールアダプタ実行環境プロパティファイルの詳細は，マニュアル「サービスプラットフォームリファレンス」の「6.13.3　メールアダプタ実行環境プロパティファイル」を参照してください。

(1)　再接続タイムアウト

メールサーバがダウンした場合や，メールサーバ接続中またはメール送信中にネットワーク障害が発生した場合，メールアダプタはメールサーバ接続タイムアウトに指定されたタイムアウト値までメールサーバへの接続をリトライします。また，メール送信タイムアウトを設定することで，メール送信に失敗するまでのタイムアウト時間を設定できます。

メールアダプタのリクエスト送信時に例外メッセージ「KDJE59101-E」または「KDJE59105-E」が出力され，例外の原因がタイムアウトだった場合は，次に示すプロパティの設定を見直してください。

設定できるパラメタを次の表に示します。

表2‒56　メールサーバ接続タイムアウトおよびメール送信タイムアウトの設定

値

キー名称

デフォルト値

メールサーバ接続タイムアウト（秒）

mailadp.smtp.connectiontimeout

180

メール送信タイムアウト（秒）

mailadp.smtp.timeout

180

(2)　排他管理タイムアウト

添付ファイル付きのメールを送信する場合，要求電文で指定した共通フォルダ内の添付ファイルのパスにアクセスするとき，指定したファイルに共有ロックが設定されます。

要求電文で作業フォルダを指定したとき，およびメールアダプタ実行環境プロパティファイルで指定したパスのファイルにアクセスするときは，共有ロックが設定されません。

排他管理タイムアウトでは，メールアダプタが共有ロックの取得に失敗したときのリトライ回数およびリトライ間隔を設定できます。

なお，共有ロックの取得に失敗したときのリトライ状態はメンテナンスログに出力されます。メンテナンスログの詳細は，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「7.3.2　障害情報の取得方法（サービスプラットフォーム）」の保守情報の取得方法について説明している個所を参照してください。

設定できるパラメタを次の表に示します。

表2‒57　　排他管理タイムアウトの設定

値

キー名称

デフォルト値

排他管理ロックリトライ回数（回）

mailadp.read-lock.retry.count

0

排他管理ロックリトライ間隔（秒）

mailadp.read-lock.retry.interval

1

2.14.6　メールアダプタからメールを送信するときの認証

ここでは，メールアダプタからメールを送信するときのSMTP認証の指定方法，および認証に必要なユーザ名およびパスワードの設定方法について説明します。

(1)　SMTP認証の指定

SMTP認証の形式には，LOGINまたはPLAINの2種類があります。

LOGIN

メールアダプタアカウント定義ファイルに指定されたユーザ名とパスワードを使って認証されます。

PLAIN

メール送信時に認証されません。

認証形式は要求電文またはメールアダプタ実行環境プロパティファイルのどちらかで指定できます。要求電文の場合，<mail-auth>タグで指定します。メールアダプタ実行環境プロパティファイルの場合，mailadp.smtp.authキーで指定します。

要求電文で設定できる項目については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.12　メールアダプタを定義する」のadpmail_smtp_request.xsd（要求電文フォーマットファイル）について説明している個所を参照してください。メールアダプタ実行環境プロパティファイルで設定できる項目についてはマニュアル「サービスプラットフォーム リファレンス」の「6.13.3　メールアダプタ実行環境プロパティファイル」を参照してください。

要求電文とメールアダプタ実行環境プロパティファイルの両方で指定された場合は，要求電文が優先されます。

要求電文とメールアダプタ実行環境プロパティファイルの両方に指定がない場合，PLAIN認証でメールが送信されます。

(2)　ユーザ名およびパスワードの設定

LOGIN認証に必要なユーザ名およびパスワードは，要求電文またはプロパティファイルを利用して設定できます。ユーザ名およびパスワードの設定方法を次に示します。

ユーザ名

要求電文またはメールアダプタ実行環境プロパティファイルで設定できます。

要求電文の場合，<mail-user>タグで指定します。メールアダプタ実行環境プロパティファイルの場合，mailadp.userキーで指定します。

パスワード

csmmailaddusrコマンドを使用してユーザ名に対応するパスワードをメールアダプタアカウント定義ファイルに追加します。

2.15　HTTP通信を使用したクライアントとの接続

HTTP受付を利用することで，HTTPクライアントからHTTP通信を使用してビジネスプロセスを呼び出すことができます。

携帯端末やWebブラウザからサービスプラットフォームに接続要求を出す場合，HTTP受付を使用すると，WebフロントシステムやSOAP受付を経由しないで，直接ビジネスプロセスを呼び出せるようになります。

2.15.1　HTTP受付を使用したサービス部品の呼び出し

HTTPクライアントとして利用するWebブラウザから発信されたHTTPリクエストは，Webサーバを経由してHTTP受付で受け付けられます。そのあと，HTTPリクエストは要求電文（サービス部品呼び出し要求）に変換され，ビジネスプロセス上でサービス部品を呼び出します。

応答時は，ビジネスプロセス上の応答電文がHTTP受付でHTTPレスポンスの形式に変換され，Webブラウザに応答を返します。

HTTP受付を使用したサービス部品呼び出し要求・応答の流れを次の図に示します。

図2‒133　HTTP受付を使用したサービス部品呼び出し要求・応答の流れ

HTTP受付でサポートするメソッド

HTTP受付でサポートするメソッドを次に示します。

GETメソッド

HTTPクライアントからサービスプラットフォームにクエリストリングの情報を渡して，テキストデータおよびファイルのデータをダウンロードするためのメソッドです。

POSTメソッド

HTTPクライアントからサービスプラットフォームにテキストデータの送信およびファイルのデータをアップロードするためのメソッドです。レスポンスとしてテキストデータの受信およびファイルのデータをダウンロードすることもできます。

HEADメソッド

HTTPクライアントからサービスプラットフォームにクエリストリングの情報を渡して，HTTPヘッダをアップロードするためのメソッドです。

PUTメソッド

HTTPクライアントからサービスプラットフォームにテキストデータの送信およびファイルのデータをアップロードするためのメソッドです。レスポンスとしてテキストデータの受信およびファイルのデータをダウンロードすることもできます。テキストデータ，およびファイルを更新または作成する目的で使用します。

DELETEメソッド

テキストデータおよびファイルのデータを削除するためのメソッドです。

OPTIONSメソッド

利用できるメソッドの一覧を取得するためのメソッドです。

HTTP受付でサポートするWebサーバおよびHTTPクライアント

HTTP受付でサポートするWebサーバおよびHTTPクライアントを次に示します。

Webサーバ

HTTP 1.1に準拠した，Component Containerで動作するWebサーバをサポートしています。

HTTPクライアント

上記のWebサーバがサポートするHTTPクライアントをサポートしています。

2.15.2　HTTP受付を使用したオンラインシステムの例

ここでは，テキストデータ，ファイル，およびバイナリデータを扱うシステムを例にHTTP受付の利用方法を紹介します。

(1)　テキストデータを送受信するシステムの場合

タブレット端末のWebブラウザからオンラインで商品を購入するシステムを例に説明します。

この例で使用するWebブラウザは，ユーザ情報を認証するための［ログイン画面］，購入する商品などの情報を入力するための［入力画面］，および購入結果を表示する［結果画面］で構成されています。ユーザが商品を購入する場合，次の流れでWebブラウザからリクエストを送信します。

GETメソッドのリクエストを送信して商品のリストを取得します。

POSTメソッドのリクエストを送信してリストから選択した商品を送信し，購入処理を呼び出します。

それぞれのリクエストの処理とHTTP受付の関係を説明します。

(a)　GETメソッドのリクエストを送信する例

このリクエストの例では，Webブラウザで入力した情報がGETメソッドのリクエストとしてサービスプラットフォームに送信されたあと，対応するHTTPレスポンスのデータを基に生成された画面がWebブラウザ上に表示される処理が実行されます。

GETメソッドのリクエストを送信する流れを次に示します。なお，次の番号は図中の番号と対応しています。

Webブラウザの［ログイン画面］でユーザが入力した情報がWebサーバに送信されます。

WebサーバからHTTP受付にHTTPリクエストが渡されます。

HTTP受付でHTTPヘッダとHTTPボディが，それぞれ要求電文（ヘッダ）と要求電文（ボディ）に変換されます。変換されたデータはサービスプラットフォーム内のビジネスプロセスに渡され，ビジネスプロセスから商品データベースなど，さまざまなサービスを呼び出します。そのあと，応答電文はHTTP受付でHTTPレスポンスの形式に変換されます。

HTTPレスポンスのHTTPボディにはXML形式の応答電文が設定されます。

応答電文の内容を基にHTMLを作成（JavaScriptなどを利用，またはフロントエンドサーバを経由）し，クライアント側で表示されます。この例では，取得したデータが［入力画面］の選択リストに追加されています。

図2‒134　HTTP受付を利用したシステムの例（GETメソッドのリクエストを送信した場合）

(b)　POSTメソッドのリクエストを送信する例

このリクエストの例では，Webブラウザで入力した情報がPOSTメソッドのリクエストとしてサービスプラットフォームに送信されたあと，対応するHTTPレスポンスのデータを基に生成された画面がWebブラウザ上に表示される処理が実行されます。

POSTメソッドのリクエストを送信する流れを次に示します。なお，次の番号は図中の番号と対応しています。

Webブラウザの［入力画面］でユーザが入力したデータがWebサーバに送信されます。

WebサーバからHTTP受付にHTTPリクエストが渡されます。

GETメソッドのリクエストを送信する場合と同様に，HTTP受付でHTTPヘッダとHTTPボディが，それぞれ要求電文（ヘッダ）と要求電文（ボディ）に変換され，ビジネスプロセスを通じてさまざまなサービスを呼び出します。そのあと，応答電文はHTTP受付でHTTPレスポンスの形式に変換されます。

HTTPレスポンスのHTTPボディにはXML形式の応答電文が設定されます。

応答電文の内容を基にHTMLを作成（JavaScriptなどを利用，またはフロントエンドサーバを経由）し，クライアント側で表示されます。この例では，商品購入の処理が完了したことを示す［結果画面］が表示されます。

図2‒135　HTTP受付を利用したシステムの例（POSTメソッドのリクエストを送信した場合）

(2)　ファイルを送受信するシステムの場合

HTTP受付のファイル転送機能を利用して，HTTPクライアント，サービスプラットフォーム，サーバ間でデータを送受信するシステムを例に説明します。

(a)　HTTPクライアントからサーバにファイルを送信する例

このリクエストでは，HTTPクライアントからPOSTメソッドでアップロードしたファイルを，ビジネスプロセスを介して呼び出したHTTPアダプタから宛先のサーバに送信する処理を実行しています。

HTTPクライアントからサーバにファイルを送信する流れを次に示します。なお，次の番号は図中の番号と対応しています。

HTTPクライアントのプログラムからPOSTメソッドでHTTPリクエストを送信します。

HTTP受付は受信したHTTPリクエストを解析し，ファイルを処理するための作業フォルダを作成します。アップロードされたファイルは中間ファイルとして作業フォルダに生成されます。

ビジネスプロセス内のデータ変換アクティビティで，HTTPアダプタの要求電文に宛先サーバと送信データ（HTTP受付が作業フォルダに保存した中間ファイル）の情報を指定します。

ビジネスプロセスから呼び出されたHTTPアダプタが宛先のサーバに作業フォルダ内のファイルを送信します。

図2‒136　HTTP受付を利用したシステムの例（HTTPクライアントからサーバにファイルを送信する場合）

HTTPアダプタの機能については，「2.16　HTTP通信を使用したサービスとの接続」を参照してください。

(b)　HTTPクライアントから送信したファイルを変換する例

このリクエストでは，HTTPクライアントからPOSTメソッドでアップロードしたファイルを，ビジネスプロセスを介して呼び出したファイル操作アダプタで変換してから，HTTPクライアントにダウンロードする処理を実行しています。

HTTP受付を利用したファイル送信の流れを次に示します。なお，次の番号は図中の番号と対応しています。

HTTPクライアントのプログラムからPOSTメソッドでHTTPリクエストを送信します。

HTTP受付は受信したHTTPリクエストを解析し，ファイルを処理するための作業フォルダを作成します。アップロードされたファイルは中間ファイルAとして作業フォルダに生成されます。

ビジネスプロセスから呼び出されたファイル操作アダプタが作業フォルダ内の中間ファイルAを中間ファイルBに変換します。

HTTP受付は，HTTPクライアントに変換後の中間ファイルBをダウンロードします。

図2‒137　HTTP受付を利用したシステムの例（HTTPクライアントから送信したファイルを変換する場合）

(3)　バイナリデータを送受信するシステムの場合

このリクエストでは，バイナリデータをビジネスプロセスで処理する例として，CSV形式のファイルを変換したバイナリデータをHTTPクライアントからビジネスプロセスに送信する処理を実行しています。

HTTPクライアントからビジネスプロセスにバイナリデータを送信する流れを次に示します。なお，次の番号は図中の番号と対応しています。

HTTPクライアントのプログラムでCSV形式のファイルをバイナリデータに変換し，HTTPリクエストボディに設定します。

HTTPクライアントのプログラムから，POSTメソッドでHTTPリクエストを送信します。

HTTP受付は受信したHTTPリクエストを解析し，ビジネスプロセスを呼び出します。

ビジネスプロセス内のデータ変換アクティビティで，要求電文に設定されたバイナリデータをXMLデータ（XML電文）に変換します。

サービス呼出アクティビティを使用してXMLデータ（XML電文）を各サービスに送信します。

HTTP受付がHTTPレスポンスをHTTPクライアントに返します。

図2‒138　HTTP受付を利用したシステムの例（HTTPクライアントからビジネスプロセスにバイナリデータを送信する場合）

2.15.3　HTTP受付の構成例

HTTP受付では，送受信する次のデータ形式に応じてさまざまなシステム構成を実現できます。

テキストデータまたはバイナリデータを送受信する場合

ファイルのデータを送受信する場合

HTTP受付およびビジネスプロセスの構成例を次に示します。

(1)　テキストデータまたはバイナリデータを送受信する場合

(a)　ビジネスプロセスと単一のHTTP受付の構成例

単一のHTTP受付とビジネスプロセスの構成の例を次の図に示します。

図2‒139　単一のHTTP受付をビジネスプロセスに関連づける場合

(b)　ビジネスプロセスと複数のHTTP受付の構成例

ビジネスプロセス内で複数のリクエスト情報を管理したい場合などには，複数のHTTP受付をビジネスプロセスに関連づけることができます。

複数のHTTP受付とビジネスプロセスの構成の例を次の図に示します。

図2‒140　複数のHTTP受付をビジネスプロセスに関連づける場合

この構成の場合，HTTPリクエストのURLに指定されたコンテキストルートおよびオペレーション名に応じて，ビジネスプロセスに関連づけられたHTTP受付のオペレーションが呼び出されます。

なお，この構成を選択する場合，永続化するビジネスプロセスとして定義する必要があります。

(c)　複数のビジネスプロセスと単一のHTTP受付の構成例

複数のビジネスプロセスと単一のHTTP受付の構成の例を次の図に示します。

図2‒141　複数のビジネスプロセスに単一のHTTP受付を関連づける場合

(2)　ファイルのデータを送受信する場合

(a)　ビジネスプロセスと単一のHTTP受付（単一オペレーション）の構成例

単一のオペレーションを持つ単一のHTTP受付とビジネスプロセスの構成の例を次の図に示します。

図2‒142　単一のHTTP受付（単一オペレーション）をビジネスプロセスに関連づける場合

HTTP受付はHTTPクライアントからHTTPリクエストを受け付けると，HCSCサーバ内にファイルのデータを中間ファイルとして処理するための作業フォルダを作成します。作業フォルダはHTTPレスポンスの処理が完了したあと自動で削除されます。ビジネスプロセスの処理中やHTTP受付の処理中にエラーが発生した場合は，ファイルは削除されません。

(b)　ビジネスプロセスと単一のHTTP受付（複数オペレーション）の構成例

複数のオペレーションを持つ単一のHTTP受付とビジネスプロセスの構成の例を次の図に示します。

図2‒143　単一のHTTP受付（複数オペレーション）をビジネスプロセスに関連づける場合

この構成例の場合，作成される作業フォルダはオペレーション（HTTPリクエスト）ごとに異なります。1回目のオペレーションで作業フォルダに生成されたファイルを2回目のオペレーションの処理で参照したいときは，ファイル操作アダプタを使用して作業フォルダ・共通フォルダ間でファイルをコピーする必要があります。

ファイル操作アダプタについては，「8.7　ファイル操作アダプタの機能」を参照してください。共通フォルダについては，「8.8.2　共通フォルダを利用したファイルアクセス」を参照してください。

(c)　ビジネスプロセスと複数のHTTP受付の構成例

複数のHTTP受付とビジネスプロセスの構成の例を次の図に示します。

図2‒144　複数のHTTP受付をビジネスプロセスに関連づける場合

この構成例の場合，複数のオペレーションを持つ単一のHTTP受付の構成の場合と同様に，作成される作業フォルダはオペレーション（HTTPリクエスト）ごとに異なります。このため，各HTTPリクエストで同一のファイルを共有したい場合は，ファイル操作アダプタを使用して作業フォルダ・共通フォルダ間でファイルをコピーする必要があります。

2.15.4　HTTP受付のリクエスト処理

ここでは，HTTP受付を実行するときにHTTPリクエストがどのように処理されるかについて説明しています。

HTTPクライアントが送信するHTTPリクエストは，次のように分割してHTTP受付内で処理されます。

リクエストライン

HTTPリクエストメッセージの先頭行に位置し，HTTPメソッド，リクエストURL，およびHTTPバージョンが格納されます。

HTTPリクエストヘッダ

HTTPクライアントで受信する言語，認証情報などの情報がHTTPヘッダフィールドで指定されます。

HTTPリクエストボディ

POSTメソッドの場合に送信するメッセージボディが格納されます。

HTTP受付では，電文フォーマットと定義ファイルを使用してHTTPリクエストのリクエストライン，HTTPリクエストヘッダ，およびHTTPリクエストボディを処理できます。

なお，ここで説明する電文の例では，名前空間接頭辞を省略しています。

(1)　リクエストラインの処理

HTTP受付のリクエストラインの処理について説明します。

(a)　コンテキストルート

URLのコンテキストルートは，HTTP受付定義ファイルのurecp-http.context-rootプロパティで指定できます。

urecp-http.context-rootプロパティの指定がない場合，ユーザ定義受付定義画面で設定するHTTP受付の受付IDがコンテキストルートとして使われます。HTTP受付定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「3.11.3　HTTP受付定義ファイル」を参照してください。

HTTPリクエストの送信時，URLは次の形式で指定します。

http://<ホスト名>:<ポート番号>※/<コンテキストルート>/<HTTP受付のオペレーション名>

https://<ホスト名>:<ポート番号>※/<コンテキストルート>/<HTTP受付のオペレーション名>

注※

WebサーバのURLです。

ただし，ユーザ定義受付（呼出先選択）として定義したHTTP受付の場合は，オペレーション名はHTTPメソッドから取得するため，コンテキストルートのあとに指定する必要はありません。

URLの指定例を次に示します。

GETメソッドの場合

urecp-http.context-rootプロパティが「Test001」のとき，URLは次の形式で指定します。

http://<ホスト名またはIPアドレス>/Test001/get?type=A&size=7

「get」はオペレーション名，「type=A&size=7」はクエリ文字列を示します。

POSTメソッドの場合

urecp-http.context-rootプロパティが「Test002」のとき，URLは次の形式で指定します。

http://<ホスト名またはIPアドレス>/Test002/post

「post」はオペレーション名を示します。

ユーザ定義受付（呼出先選択）として定義したHTTP受付の場合

ユーザ定義受付（呼出先選択）として定義したHTTP受付で，HTTP受付定義ファイルのコンテキストルートに「Test001」を指定したとき，URLは次の形式で指定します。

http://<ホスト名またはIPアドレス>/Test001?type=A&size=7

「Test001」はコンテキストルート，「type=A&size=7」はクエリ文字列を示します。

オペレーション名とは，ユーザ定義受付定義画面で設定するHTTP受付のオペレーションの名称です。オペレーション名はビジネスプロセスを呼び出すときに使用されます。

なお，オペレーション名のあとに「/」が指定された場合，「/」の後ろに文字列があるときは，「/」の後ろの部分もパスとして扱われます。例えば，URLに「http://localhost/contextroot/get/abc123?type=A&size=7」が指定された場合，「/contextroot/get/abc123」がロケーション情報（<location>）にパスとして格納されます。

注意事項

コンテキストルートは，Component Containerの作業ディレクトリの中でディレクトリ名として使用されます。そのため，作業ディレクトリ全体のパス長がOSの上限に達しないようにコンテキストルートを指定する必要があります。詳細は，「2.15.13　HTTP受付を使用するときの注意」を参照してください。

(b)　ロケーション情報とクエリ文字列部

リクエストラインで指定されたURLは，次の要素に分割して要求電文（ヘッダ）に格納されます。

ロケーション情報（<location>）※1

クエリ文字列部（<query>）※2

例えば，リクエストラインが「http://localhost/httprecp/get?type=A&size=7」の場合，要求電文には次のように変換されます。

<url>
　<location>/httprecp/get</location>
　<query>type=A&amp;size=7</query>
</url>

注※1

ロケーション情報とは，コンテキストパスから拡張パスまでのパスです。

ユーザ定義受付（呼出先選択）として定義したHTTP受付の場合，コンテキストルートのあとの「/」に続く文字は，URLの分析中に無視されますが，<location>タグに格納されます。

注※2

クエリ文字列に複数の「?」が存在する場合，最初の「?」がクエリ文字列の区切り文字として使用されます。

(2)　HTTPリクエストヘッダの処理

HTTP受付で受け付けられたHTTPヘッダ部分のすべての情報は，any型で定義されたhttp-header要素に格納して，ビジネスプロセスに渡されます。

HTTPヘッダ部分の変換例を次に示します。

変換前のHTTPリクエストヘッダ

Accept-Language: ja
Host: aaa.bbb.ccc.ddd
Connection: Keep-Alive
Authorization: Basic aG9nZTpmdWdh

変換後の要求電文（ヘッダ）

<http-header>

<content-type>application/x-www-form-urlencoded; charset=utf-8</content-type>
<Accept-Language> ja</Accept-Language>
<Host> aaa.bbb.ccc.ddd </Host>
<Connection> Keep-Alive</Connection>
<Authorization> Basic aG9nZTpmdWdh</Authorization>

</http-header>

HTTP受付で変換されたHTTPヘッダ部分のXML要素は，SOAPアダプタのHTTPヘッダ部とany種別同士でマッピングできます。

(a)　Authorizationヘッダの変換

ユーザの認証情報を格納するHTTPリクエストヘッダのAuthorizationヘッダフィールドは，Base64形式にエンコーディングされます。このため，HTTP受付は，AuthorizationヘッダフィールドをBase64形式からプレーン形式にデコードし，要求電文のXML要素に設定します。

注意事項

HTTPヘッダ部分にユーザ名とパスワード情報の両方が指定された場合，HTTP受付では，ユーザ名だけが設定されます。

HTTP受付ではベーシック認証だけをサポートしています。ほかの認証タイプを指定した場合，ユーザ名は設定されません。

HTTPヘッダ部分のAuthorizationヘッダフィールドを指定して値を指定しなかった場合，要求電文としてAuthorizationの空要素だけ生成され，auth要素およびusername要素は作成されません。

HTTPヘッダ部分のAuthorizationヘッダフィールドでパスワードを指定してユーザ名を指定しなかった場合，auth要素およびusername要素が作成されますが，username要素の値は空となります。

(b)　Content-Typeヘッダの変換

受信したContent-Typeヘッダの値のメディアタイプをcontent-type要素として要求電文（ヘッダ）に格納します。このとき，charset属性がある場合は，content-type要素のcharset属性として格納します。

Content-Typeヘッダがない場合は，content-type要素は生成しません。また，Content-Typeヘッダのメディアタイプの指定だけがあって，charset属性がない場合は，属性を生成しません。

Content-Typeヘッダのcharset属性は，クエリまたはフォームデータのテキストデータの文字コードとして使用します。Content-Typeヘッダのcharset属性が存在しない場合，またはContent-Typeヘッダがリクエストに存在しない場合は，HTTP受付定義ファイルのhttprecp.http.charsetプロパティの値によって処理されます。ただし，この場合も，charset属性がないため，content-type要素のcharset属性を生成しません。

注意事項

Content-Typeヘッダのcontent-type要素が存在しない，またはcontent-type要素のcharset属性が生成されていないデータを受信した場合に，テキストデータの文字コードを確認する必要があるときは，httprecp.http.charsetプロパティ値の文字コードで判断してください。

(3)　HTTPリクエストボディの処理

HTTPリクエストのパート区分およびデータ形式は，HTTPリクエストヘッダの指定に応じて次のようにHTTP受付で処理されます。

HTTPリクエストのパート区分

HTTPリクエストヘッダのContent-Typeヘッダがmultipart/form-dataの場合は，マルチパート型として扱われます。それ以外の場合は単一パート型（テキストデータまたはバイナリデータ）として扱われます。なお，HTTP受付で処理できるマルチパート型の上限数は1,024です。

HTTPリクエストのデータ形式

各パート内のContent-Dispositionヘッダのfilename属性が存在する場合はファイルのデータがアップロードされたものとして扱います。filename属性がない場合はテキストデータまたはバイナリデータとして扱います。

HTTP受付で扱うデータ形式ごとに，HTTPリクエストボディの処理について説明します。

(a)　テキストデータとして扱う場合

HTTP受付は，クエリ，フォームデータ，マルチパート型の形式でContent-Dispositionヘッダのfilename属性がないパート部分をテキストデータとして扱います。テキストデータとして扱う場合，XML形式の要求電文（ボディ）に格納されたあと，ボディ変数としてビジネスプロセスに渡されます。

HTTPリクエストのデータ形式がテキストデータだけの場合は，メッセージボディをビジネスプロセスに渡すときのモードとして，次のどちらかを選択できます。

標準モード

標準モードでは，メッセージボディは要求電文の要素に変換されてビジネスプロセスに渡されます。メッセージボディを格納するXML形式の要求電文フォーマット（ボディ変数用（詳細））は任意にカスタマイズできます。

パススルーモード

パススルーモードでは，メッセージボディ中でmsgキーに対応する値がそのままビジネスプロセスに渡されます。XML形式の要求電文フォーマットはメッセージボディの形式に応じてユーザが作成する必要があります。msgキーに対応する値がnull，または空文字の場合，ビジネスプロセスに空文字の要求電文を渡します。

パススルーモードは，ビジネスプロセスをテストする場合，SOAP受付のダミーとしてHTTP受付を使用するときなどに使用します。

なお，HTTPリクエストがマルチパート型の場合，パススルーモードを指定しても無効になります。

メッセージボディをビジネスプロセスに渡すときのモードは，HTTP受付定義ファイルのhttprecp.switchover.pass-through.modeプロパティで選択できます。HTTP受付定義ファイルの詳細は，マニュアル「サービスプラットフォームリファレンス」の「3.11.3　HTTP受付定義ファイル」を参照してください。

標準モードとパススルーモードの変換例を次の表に示します。

表2‒58　標準モードとパススルーモードの変換例

モード

説明

HTTPリクエスト（メッセージボディ）

変換後の要求電文（ボディ）

標準モード

メッセージボディは「キー名=値」から「<キー名>値</キー名>」の形式に変換されます。※1

product1=uCSP&product2=HiRDB%20Single%20Server

<HTTPBody>

<product1>uCSP</product1>

<product2>HiRDB Single Server</product2>

</HTTPBody>

パススルーモード

メッセージボディ部分は「msg（固定）=値」形式で指定します。※2

値部分は，メッセージボディのままXML形式の要求電文（ボディ）に設定されます。

msg=%3cHTTPBody%3e%3cproduct1%3euCSP%3c%2fproduct1%3e%3cproduct2%3eHiRDB%20Single%20Server%3c%2fproduct2%3e%3c%2fHTTPBody%3e

<HTTPBody>

<product1>uCSP</product1>

<product2>HiRDB Single Server</product2>

</HTTPBody>

注※1

値が半角スペース1文字だけの場合，空文字として処理します。

注※2

HTTP受付定義ファイルのhttprecp.pass-through.parameter-useプロパティで，msgキーの指定を省略するかどうかを設定できます。

msgキーを複数指定した場合の動作は保証されません。

標準モードの場合，HTTPリクエストは要求電文の変換時にHTTP受付でサニタイズされてビジネスプロセスに渡されます。

パススルーモードの場合，HTTPリクエストはサニタイズされません。このため，あらかじめユーザ自身でサニタイズする必要があります。

(b)　ファイルのデータとして扱う場合

HTTPリクエストのパート区分がマルチパート型で，かつパート内のContent-Dispositionヘッダのfilename属性が存在するパートのデータは，HTTP受付で各パートに分割され，パートごとに中間ファイルとして作業フォルダに格納されます。

なお，ファイルのデータとして処理した場合，各パートのヘッダ情報は，次の表に示すように要求電文（ヘッダ）のfile要素にファイルのメタ情報として格納されます。

表2‒59　要求電文（ヘッダ）に格納される各パートのヘッダ情報

HTTPリクエストのヘッダ

ヘッダの属性

任意/必須

説明

Content-Type

−

任意

各パートに指定されているファイルのメディアタイプです。

このヘッダは省略できます。

charset

任意

各パートに指定されているファイルの文字コードです。

この属性は省略できます。

Content-Disposition※1

−

必須

Dispositionタイプを示すヘッダです。

必ず「form-data」を指定します。※2

name

必須

各パートの名称を示す属性です。

この属性は必ず指定します。※3

filename

任意

アップロードするファイルのデータのファイル名を示す属性です。

この属性は省略できます。この属性を省略した場合，テキストデータ扱いになります。

（凡例）

−：該当する項目はありません。

注※1

Content-Dispositionヘッダにsize属性，modification-date属性など，この

表に示した属性以外の属性が指定されている場合，それらの属性値は無視されます。

注※2

マルチパート型としてファイルのデータをアップロードする場合，Content-Dispositionヘッダには必ずform-dataを指定してください。form-data以外の場合，HTTP受付では処理の対象となりません。

注※3

name属性を省略した場合，省略したパートのデータは，HTTP受付では処理の対象となりません。

注意事項

Content-Dispositionヘッダのname属性およびfilename属性にマルチバイト文字を使用した場合，動作を保証しません。

Content-Dispositionヘッダの属性に「filename」で始まる任意の属性を指定した場合，およびfilename属性の値に「"」が含まれるファイル名（パス部分は除く）を指定した場合は，動作を保証しません。

なお，複数のファイルのデータをアップロードする場合，これらのメタ情報はファイルごとに要求電文のfile要素に繰り返して格納されます。

(c)　バイナリデータとして扱う場合

HTTPリクエストボディにバイナリデータを設定することで，バイナリ形式の要求電文をビジネスプロセスに送信できます。CSV形式のデータをビジネスプロセスで処理したい場合などに活用できます。

HTTP受付でバイナリデータとして扱うには，次の条件をすべて満たす必要があります。

パススルーモードを使用していること（HTTP受付定義ファイルにhttprecp.switchover.pass-through.mode=trueを指定していること）

パススルーモードでmsgキーを省略する設定にしていること（HTTP受付定義ファイルにhttprecp.pass-through.parameter-use=falseを指定していること）

HTTP受付の要求電文の電文フォーマットにバイナリ形式（拡張子：fdx），または任意形式（any形式）を指定していること

HTTPリクエストボディのパート区分が単一パートであること

バイナリ形式の要求電文の文字エンコーディングは，ビジネスプロセスのデータ変換時に行われます。

2.15.5　HTTP受付のレスポンス処理

ここでは，HTTP受付に返されたビジネスプロセスからの応答電文が，どのようにHTTPレスポンスへと処理されるかについて説明しています。

HTTPクライアントに応答を返すHTTPレスポンスは次のように分割してHTTP受付内で処理されます。

ステータスライン

HTTPバージョン，ステータスコード，および理由フレーズが格納されます。

HTTPレスポンスヘッダ

HTTPレスポンスのContent-LengthヘッダやContent-Typeヘッダなどの情報が格納されます。

HTTPレスポンスボディ

HTTPクライアントに応答を返すテキストデータまたはバイナリデータが格納されます。

(1)　ステータスラインの処理

HTTPレスポンスのステータスラインは，次の形式で出力されます。

[HTTPバージョン※1][空白][ステータスコード※2][空白][理由フレーズ]

注※1

HTTPバージョンは「HTTP/1.1」で固定です。

注※2

応答電文（ヘッダ）のstatus-code要素の値がステータスコードに設定されます。ステータスコードの詳細は，「(4) ステータスコード」を参照してください。

(2)　HTTPレスポンスヘッダの処理

HTTP受付に指定されたすべてのヘッダ情報はHTTPレスポンスヘッダに設定されます。

HTTPレスポンスヘッダの処理について説明します。

(a)　Content-Typeとcharset

HTTPレスポンスヘッダに使用されるContent-Typeヘッダおよびcharset属性は，次の場合によって異なります。

テキストデータを返す場合

ファイルのデータを返す場合

複数データを返す場合（マルチパート型）

バイナリデータを返す場合

●テキストデータを返す場合

HTTPレスポンスヘッダに使用されるContent-Typeヘッダおよびcharset属性は，応答電文（ヘッダ）のcontent-type要素，http-header要素，HTTPレスポンスヘッダ定義ファイルなどで設定できます。

応答電文フォーマット（ヘッダ変数用）をビジネスプロセスに設定した場合で，Content-Typeヘッダおよびcharset属性を複数指定したときは，次の表に示すように応答電文フォーマット（ヘッダ変数用）の指定が優先されます。

表2‒60　HTTPレスポンスヘッダに使用されるContent-Typeおよびcharset（応答電文フォーマット（ヘッダ変数用）が設定されている場合）

設定項目

応答電文にcontent-type要素が存在する場合※1

応答電文のhttp-header要素にcontent-type要素が存在する場合

応答電文にcontent-type要素およびcharset属性が存在しない場合

content-type要素にcharset属性が存在するとき

content-type要素にcharset属性が存在しないとき

http-header要素にcharset属性が存在するとき

http-header要素にcharset属性が存在しないとき

Content-Typeヘッダ

応答電文のcontent-type要素の値が有効になります。

応答電文のcontent-type要素の値が有効になります。

応答電文のhttp-header要素のcontent-type要素の値が有効になります。※3

応答電文のhttp-header要素のcontent-type要素の値が有効になります。※3

「text/xml」が設定されます。

charset属性

応答電文のcontent-type要素のcharset属性の値が有効になります。※2

HTTP受付定義ファイルの指定値が有効になります。

応答電文のhttp-header要素のcharset属性の値が有効になります。※3

HTTP受付定義ファイルの指定値が有効になります。

HTTP受付定義ファイルの指定値が有効になります。

注※1

要素が存在していても値が空の場合は，要素が存在しないと判断されます。

注※2

属性が存在していても値が空の場合は，属性が存在しないと判断されます。

注※3

応答電文（ヘッダ）のhttp-header要素に複数のcontent-type要素が指定された場合，指定のうちどれか1つの値が有効になります。ただし，どの値が設定されるかは保証されません。

また，応答電文フォーマット（ヘッダ変数用）をビジネスプロセスに設定していない場合，次の表に示すように，HTTPレスポンスヘッダ定義ファイルの値が有効になります。

表2‒61　HTTPレスポンスヘッダに使用されるContent-Typeヘッダおよびcharset属性（応答電文フォーマット（ヘッダ変数用）を設定していない場合）

設定項目

HTTPレスポンスヘッダ定義ファイルが存在している場合

HTTPレスポンスヘッダ定義ファイルが存在しない場合

HTTPレスポンスヘッダ定義ファイルにcontent-typeキーが存在するとき

HTTPレスポンスヘッダ定義ファイルにcontent-typeキーが存在しないとき

content-typeキーの指定値にcharset属性が存在する

content-typeキーの指定値にcharset属性が存在しない

HTTPレスポンスヘッダ定義ファイルにcharsetキーが存在しない

Content-Typeヘッダ

content-typeキーの指定値が有効になります。※

content-typeキーの指定値が有効になります。※

「text/xml」が設定されます。

「text/xml」が設定されます。

charset属性

content-typeキーの指定値に存在するcharset属性の値が有効になります。※

HTTP受付定義ファイルの指定値が有効になります。

HTTP受付定義ファイルの指定値が有効になります。

HTTP受付定義ファイルの指定値が有効になります。

注※

HTTPレスポンスヘッダ定義ファイルに複数のcontent-typeキーと値のペアを指定した場合，指定のうちどれか1つの値が有効になります。ただし，どの値が設定されるかは保証されません。

HTTPレスポンスヘッダ定義ファイルは，HTTP受付定義ファイルから呼び出される任意のファイルです。HTTPレスポンスヘッダ定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「3.11.1　HTTPレスポンスヘッダ定義ファイル」を参照してください。

●ファイルのデータを返す場合

HTTPレスポンスヘッダに使用されるContent-Typeヘッダおよびcharset属性は，次に示すように応答電文（ヘッダ）のfile要素配下のcontent-type要素で設定できます。

表2‒62　HTTPレスポンスヘッダに使用されるContent-Typeヘッダおよびcharset属性

設定項目

応答電文のfile要素配下にcontent-type要素が存在する場合

応答電文のfile要素配下にcontent-type要素が存在しない場合

file要素配下のcontent-type要素にcharset属性が存在するとき

file要素配下のcontent-type要素にcharset属性が存在しないとき

Content-Typeヘッダ

応答電文のfile要素配下のcontent-type要素の値が有効になります。

応答電文のfile要素配下のcontent-type要素の値が有効になります。

設定されません。

charset属性

応答電文のfile要素配下のcontent-type要素のcharset属性の値が有効になります。

設定されません。

設定されません。

注

要素が存在していても値が空の場合は，要素が存在しないと判断されます。

属性が存在していても値が空の場合は，属性が存在しないと判断されます。

●複数データを返す場合（マルチパート型）

HTTPクライアントに返すデータが，テキストデータと1ファイルのデータ，または2ファイルのデータのように複数となる場合は，応答電文（ヘッダ）およびHTTPレスポンスヘッダ定義ファイルの指定に関係なく，Content-Typeヘッダのメディアタイプにはmultipart/form-dataが設定されます。各データのContent-Typeヘッダは，マルチパート型のレスポンスボディの各パートのヘッダに指定されます。各データに指定される値は，「●テキストデータを返す場合」，および「●ファイルのデータを返す場合」の説明にそれぞれ従います。

●バイナリデータを返す場合

テキストデータを返す場合と同様にHTTPレスポンスヘッダに使用されるContent-Typeヘッダおよびcharset属性は，応答電文（ヘッダ）のcontent-type要素，http-header要素，HTTPレスポンスヘッダ定義ファイルなどで設定できます。

Content-Typeヘッダおよびcharset属性を複数指定した場合も，テキストデータを返すときと同様に，応答電文フォーマット（ヘッダ変数用）の指定が優先されます。そのため，複数指定した場合に有効となるContent-Typeヘッダおよびcharset属性は，「表2-60」，または「表2-61」を参照してください。

ただし，次の場合はContent-Typeヘッダに「application/octet-stream」が設定されます。

応答電文にcontent-type要素およびcharset属性が存在しない

HTTPレスポンスヘッダ定義ファイルにcontent-typeキーが存在しない

HTTPレスポンスヘッダ定義ファイルが存在しない

(b)　Content-Disposition

HTTPレスポンスのContent-Dispositionヘッダは，HTTPレスポンスのパート区分およびデータ数に応じて次の値が設定されます。ファイルをダウンロードしない場合，HTTPレスポンスにはContent-Dispositionヘッダが設定されません。

表2‒63　HTTP受付が設定するContent-Dispositionヘッダの値

パート区分

データ数

設定個所

Content-Dispositionヘッダの値

name属性

filename属性

単一パート型

1ファイル

HTTPレスポンスヘッダ

attachment※

設定されません。

応答電文（ヘッダ）のfilename

要素の値

マルチパート型

1ファイル＋テキストデータ

HTTPレスポンスの各パートのヘッダ

form-data

応答電文（ヘッダ）のpartID要素の値

複数ファイル

注※

HTTP受付定義ファイルのhttprecp.response.download.disposition-typeプロパティで変更できます。

応答電文（ヘッダ）のhttp-header要素内にcontent-disposition要素が含まれていた場合，その値は無視されます。なお，HTTPレスポンスヘッダ定義ファイルでContent-Dispositionヘッダが指定されている場合はその値が有効になります。

(c)　Content-Length

テキストデータだけをHTTPレスポンスで返す場合，コンテンツ長を表すContent-LengthヘッダをHTTP受付で生成するかどうかは，HTTP受付定義ファイルのhttprecp.response.generate.content-lengthプロパティで指定できます。また，コンテンツ長を計算するときに使用する文字コードは，HTTP受付定義ファイルのhttprecp.http.charsetプロパティで指定できます。

HTTP受付定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「3.11.3　HTTP受付定義ファイル」を参照してください。

HTTP受付定義ファイルの指定がある場合とない場合の，HTTPクライアントに渡されるContent-Lengthヘッダの値を次の表に示します。

表2‒64　HTTPクライアントに渡されるContent-Lengthヘッダ

httprecp.response.generate.content-lengthプロパティの値

HTTPレスポンスヘッダ定義ファイルのcontent-lengthキーまたは応答電文（ヘッダ）のhttp-header要素のcontent-length要素の指定有無

HTTPクライアントに渡されるContent-Lengthヘッダの値

true

○

HTTPレスポンス定義ファイルまたは応答電文（ヘッダ）で指定した値は，HTTP受付が計算したデータ長に上書きされます。

×

false

○

HTTPレスポンスヘッダ定義ファイルまたは応答電文（ヘッダ）に指定したデータ長をContent-Lengthヘッダに設定します。※

×

HTTPクライアントにContent-Lengthヘッダを渡しません。

（凡例）

○：指定している場合です。

×：指定していない場合です。

注※

HTTP受付定義ファイルのhttprecp.response.generate.content-lengthプロパティが「false」で，応答電文（ヘッダ）のhttp-header要素で複数のcontent-length要素が指定された場合，またはHTTPレスポンスヘッダ定義ファイルで複数のcontent-lengthキーと値のペアが指定された場合，指定のうちどれか1つの値が設定されます。ただし，どの値が設定されるかは保証されません。

なお，ファイルを1つ以上ダウンロードする場合は，Content-Lengthヘッダをクライアントに送信する設定にしていた場合でも無効になります。また，ファイルをダウンロードしない場合でも，応答電文（ヘッダ）のignore-bodymsg要素またはHTTP受付定義ファイルのhttprecp.response.ignore-bodymsgプロパティで応答電文（ボディ）を無視する設定にしているときは，Content-Lengthヘッダが設定されません。

(3)　HTTPレスポンスボディの処理

HTTPクライアントに送信するデータ形式ごとに，HTTPレスポンスボディの処理について説明します。

また，レスポンスボディをgzip形式で圧縮するHTTPレスポンス圧縮機能について説明します。

(a)　テキストデータだけの場合

ビジネスプロセスの処理が完了したあと，HTTP受付には応答電文（ボディ）変数がXML型の文字列として返り，HTTPレスポンスボディにテキストデータとして設定されます。設定する際，指定された文字コードによってエンコードされます。

システム例外が発生した場合は，エラーメッセージIDとメッセージの内容が応答電文（ボディ）の要素に設定されます。

テキストデータで返せるデータは応答アクティビティで指定した応答電文（ボディ）の部分だけです。このため，マルチパート型のレスポンスを返す場合，テキストデータが存在するパートは1つだけとなります。

注

XML要素に設定するテキストデータは，HTTP受付定義ファイルで指定した文字コードごとにエンコードする必要があります。

なお，ビジネスプロセスから受信した応答電文（ボディ）をHTTP受付が無視する（HTTPレスポンスに設定しない）かどうかを，応答電文（ヘッダ）のignore-bodymsg要素またはHTTP受付定義ファイルのhttprecp.response.ignore-bodymsgプロパティで設定できます。応答電文（ヘッダ）とHTTP受付定義ファイルの両方で指定した場合，応答電文（ヘッダ）の指定が優先されます。この要素（またはプロパティ）を指定し，かつダウンロードするファイルのデータが1つもない場合は，空のHTTPレスポンスボディをHTTPクライアントに返します。

(b)　ファイルのデータの場合

ファイルのデータをダウンロードする場合，応答電文（ヘッダ）のfile要素内でダウンロード対象のファイル名などを指定します。応答電文（ヘッダ）で指定する要素と対応するHTTPレスポンスヘッダを次に示します。

表2‒65　応答電文（ヘッダ）で指定する要素

応答電文（ヘッダ）で指定する要素名

説明

対応するHTTPレスポンスヘッダ

（マルチパート型の場合は各パートに対応するヘッダ）

省略した場合の値

partID

マルチパート型の各パートを表すパート識別名です。

Content-Dispositionヘッダのname属性

local-file-name要素で指定した中間ファイル名が設定されます。マルチパート型にならない場合は指定しても無視され，name属性は付与されません。

file-name

HTTPクライアントにダウンロードする際のダウンロードファイル名です。

Content-Dispositionヘッダのfilename属性

なし（filename属性が設定されません）。

local-file-name

作業フォルダ内のダウンロード対象の中間ファイル名です。指定した名称のファイルが存在しない場合はエラーになります。

なし

省略できません。

content-type※

ダウンロードファイルのメディアタイプを指定します。

Content-Typeヘッダ

なし（Content-Typeヘッダが設定されません）。

charset

ダウンロードファイルの文字コードを指定します。

charset属性

なし。

注※

content-type要素の指定を省略した場合，ダウンロードするファイルのContent-TypeヘッダはHTTP受付で設定しません。なお，ダウンロードするファイルが複数ある場合，またはファイルとテキストデータのマルチパート型となる場合，HTTPレスポンスヘッダのContent-Typeヘッダはmultipart/form-dataとなり，各ファイルのデータのContent-Typeヘッダはパートごとのヘッダに指定されます。

参考

HTTPレスポンス時にテキストデータを返さないでファイルを1つだけダウンロードしたい場合などのために，応答電文（ボディ）で指定されたテキストデータをHTTP受付が無視するかどうかを設定できます。この設定は，応答電文（ヘッダ）のignore-bodymsg要素，またはHTTP受付定義ファイルのhttprecp.response.ignore-bodymsgプロパティで変更できます。HTTPレスポンスごとに設定を動的に変更したい場合は応答電文（ヘッダ）で設定します。

応答電文（ヘッダ）とHTTP受付定義ファイルの両方で指定した場合，応答電文（ヘッダ）の指定が優先されます。

ただし，応答電文（ボディ）を無視する設定の場合でも，ビジネスプロセスの応答アクティビティのボディ割当変数には，任意の変数を設定しておく必要があります。このため，サービスプラットフォームが提供している応答電文フォーマット（ボディ変数用）のダミーフォーマット（urecp_http_dummy_body_response.xsd）をボディ変数用のダミーとして使用することを推奨します。

(c)　バイナリデータの場合

HTTP受付の応答電文の電文フォーマットにバイナリ形式または任意形式（any形式）を指定することで，HTTPレスポンスボディにバイナリデータを設定してクライアントに応答を返すことができます。

HTTPレスポンスボディにバイナリデータが設定されるのは，次の条件をすべて満たす場合だけです。

ビジネスプロセスから送信された応答電文（ボディ）をHTTPレスポンスボディに利用する設定であること（HTTP受付定義ファイルにhttprecp.response.ignore-bodymsg=falseを指定していること）

HTTP受付の応答電文の電文フォーマットにバイナリ形式（拡張子：fdx）または任意形式（any形式）を指定していること

応答電文（ヘッダ）にfile要素が存在しないこと

注意事項

ビジネスプロセスの応答電文（ボディ）を無視する設定（HTTP受付定義ファイルにhttprecp.response.ignore-bodymsg=trueを指定している）の場合，HTTPレスポンスボディにはバイナリデータが設定されません。

HTTP受付の応答電文の電文フォーマットにXML形式（拡張子：xsd）を指定している場合はテキストデータとして処理されます。

応答電文（ヘッダ）にfile要素が存在する場合，バイナリデータをHTTPレスポンスボディへ設定することはできません。

HTTPレスポンスボディに設定するバイナリデータは文字エンコーディングが行われません。

(d)　HTTPレスポンス圧縮機能

HTTP受付のレスポンス処理では，アプリケーションサーバのHTTPレスポンス圧縮機能を使用して，レスポンスボディをgzip形式で圧縮できます。

HTTPレスポンス圧縮機能については，マニュアル「アプリケーションサーバ 機能解説 互換編」の「9.2　HTTPレスポンス圧縮機能」を参照してください。

HTTPレスポンス圧縮機能を使用するには，HTTP受付定義ファイルにHTTPレスポンス圧縮規則を指定する必要があります。HTTP受付定義ファイルで次のプロパティを設定してください。

httprecp.response.compression.url-pattern<URLパターン識別番号>

httprecp.response.compression.rule<圧縮規則識別番号>.url-mapping<URLマッピング識別番号>

httprecp.response.compression.rule<圧縮規則識別番号>.condition<圧縮条件識別番号>

HTTPクライアントからHTTPリクエストを送信する場合は，gzip形式で圧縮されたHTTPレスポンスを受信できることを示すHTTPヘッダを付けてください。

HTTP受付定義ファイルの設定方法については，マニュアル「サービスプラットフォーム リファレンス」の「3.11.3　HTTP受付定義ファイル」を参照してください。

(4)　ステータスコード

HTTPリクエストおよびHTTPレスポンスのステータスコードについて説明します。

(a)　応答時のステータスコード

応答時のステータスコードは，応答のタイミングおよび種類によって設定される値が異なります。ステータスコードの設定値と応答のタイミングを次の表に示します。

表2‒66　設定されるステータスコード

タイミング

応答の種類

応答電文（ヘッダ）でのstatus-code要素の指定

あり

なし

ビジネスプロセスを呼び出す前

HTTP受付の検証でエラーが発生した場合

−

エラーの状況に応じてHTTP受付がステータスコードを設定します。

ビジネスプロセスを呼び出したあと

正常終了の場合

応答電文（ヘッダ）のstatus-code要素で設定したステータスコードが使用されます。※1

200※2

フォルトの場合

応答電文（ヘッダ）のstatus-code要素で設定したステータスコードが使用されます。※1

200※3

システム例外の場合

−

HTTP受付定義ファイルのhttprecp.system-exception.status-codeプロパティの値が有効になります。※4

（凡例）

−：該当しません。

注※1

ステータスコードが正常終了の場合やエラーの場合であるかどうかは検証されません。このため，応答電文（ヘッダ）にエラーの範囲（例：400〜599）のステータスコードを設定した場合，HTTPクライアントにはステータスコードがそのまま返されます。

注※2

ステータスコードを設定していない場合のデフォルト値です。

注※3

フォルトの場合でステータスコードを設定していないときは，正常終了の場合とみなされて，デフォルト値が設定されます。

注※4

HTTP受付定義ファイルの指定がない場合は，デフォルト値の500が設定されます。

(b)　エラー発生時のステータスコード

HTTPリクエストおよびHTTPレスポンスの処理でエラーが発生した場合の，メッセージIDとステータスコードの対応を次の表に示します。

表2‒67　リクエスト処理でエラーが発生した場合のステータスコード一覧

メッセージID

エラー発生時の状況

ステータスコード

KDEC80424

内部エラーが発生した場合（HTTPヘッダまたはHTTPボディのXML形式の変換時にエラーが発生した）

500

KDEC80438

HTTPメソッドがGETまたはPOST以外の場合

405

KDEC80439

URLで指定されたオペレーション名が，HTTP受付で指定されたオペレーション名と一致しない場合

404

KDEC80440

クエリ文字列，HTTPボディ，またはHTTPヘッダで無効な文字が指定された場合

400

KDEC80441

パススルーモードの場合に，リクエストパラメタでmsgキーが指定されていない，または大文字で指定された場合

400

KDEC80442

HTTPリクエストヘッダまたはHTTP受付定義ファイルで指定したエンコードに従ったURLのデコーディング中にエラーが発生した場合

500

KDEC80451

次のどちらかの原因で一意となるリクエストIDを生成できなかった場合

リクエストIDを生成するための時刻，日付，HTTPクライアントのIPアドレスなどのパラメタの取得に失敗した

同一時刻に同一のIPアドレスから大量のリクエストを受信して使用できるIDがなくなった

500

KDEC80452

HCSCサーバランタイム定義ファイルで指定された作業フォルダルートのディレクトリが存在しない場合

500

KDEC80453

作業フォルダの作成に失敗した場合

500

KDEC80454

マルチパート型HTTPリクエストのデータの受信・解析に失敗した場合

400

KDEC80456

HTTPメソッドが，ユーザ定義受付（呼出先選択）として定義したHTTP受付のオペレーション名と一致しない場合

404

KDEC80457

中間ファイルの出力中にエラーが発生した場合

500

表2‒68　レスポンス処理でエラーが発生した場合のステータスコード一覧

メッセージID

エラー発生時の状況

ステータスコード

KDEC80424

内部エラーが発生した場合（HTTPレスポンスボディのストリーム取得に失敗した，またはHTTPレスポンスボディへの値の書き込み中に例外が発生した）

500

KDEC80443

受付時に，HTTPヘッダまたはHTTPボディの解析でエラーが発生した場合

500

KDEC80444

応答電文のエンコーディング時にエラーが発生した場合

500

KDEC80445

ビジネスプロセスから返されたステータスコードが，3桁より大きいか，または小さい桁数だった場合

500

KDEC80458

中間ファイルの読み込みに失敗した場合

500

KDEC80459

作業フォルダの削除に失敗した場合

200

2.15.6　HTTP受付のファイル管理

ここでは，HTTP受付でファイルのデータを送受信するときのファイル管理について説明します。

HTTP受付はファイルのデータを受信すると，受信したデータを作業フォルダ内に中間ファイルとして出力します。レスポンス時にファイルをダウンロードする場合は，ユーザが応答電文（ヘッダ）で指定した作業フォルダの中間ファイルを各クライアントに送信します。

(1)　作業フォルダの作成と削除

作業フォルダは，HTTP受付が送受信するデータを一時的に格納するためのフォルダです。

(a)　作業フォルダの作成

HTTP受付は，HTTPクライアントからHTTPリクエストを受け付けると，リクエストごとに作業フォルダを作成します。

作業フォルダを作成するディレクトリ（作業フォルダルート）はHCSCサーバランタイム定義ファイルのwork-folderプロパティで設定できます。詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

また，HTTP受付は，HTTPクライアントからのリクエストを受け付けると，リクエストごとにリクエストIDを生成します。ビジネスプロセスの処理は，生成したリクエストIDを指定して実行されます。

リクエストIDは次の形式で生成されます。

<受付ID><HTTPクライアントのIPアドレス><日付><時刻><追番><分割キー><HCSCサーバ名>

リクエストIDのそれぞれの項目について次の表に示します。

表2‒69　リクエストIDの項目

項目

桁数

内容

<受付ID>

8桁

HTTP受付の受付IDです。受付IDが8桁に満たない場合は，受付IDの右側に足りない分の「-」が設定されます。

<HTTPクライアントのIPアドレス>

IPv4の場合：12桁

IPv6の場合：32桁

要求元のHTTPクライアントのIPアドレス（IPv4の場合は10進数表記形式，IPv6の場合は16進数表記形式）です。IPv4アドレスのそれぞれのバイトが3桁に満たない場合は，それぞれのバイトの左側に足りない分の「0」が設定されます。IPv6アドレスはそれぞれのバイトが4桁に満たない場合は，それぞれのバイトの左側に足りない分の「0」が設定されます。英字は小文字で表記されます。

<日付>

8桁

HTTP受付がリクエストを受け付けた日付がyyyymmddの形式で設定されます。

<時刻>

9桁

HTTP受付がリクエストを受け付けた時刻がhhmmssSSSの形式で設定されます。

<追番>

3桁

フォルダ名を一意にするための整数値が「000」からの連番で設定されます。<日付><時刻><追番>がすでにあるリクエストIDと重複する場合は追番を1つ繰り上げます。

「001」から「999」までのどの整数値を設定しても重複する場合，<日付>および<時刻>を変更して追番には「000」を設定します。

<分割キー>

1桁

HCSCサーバ名が付加されていることを示す分割キーです。半角スラッシュ（/），半角アットマーク（@）または半角ピリオドが使用されます。

HCSCサーバランタイム定義ファイルで変更可能です。

詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

<HCSCサーバ名>

最大8桁

HTTP受付が配備されているHCSCサーバの名称です。HCSCサーバ名が8桁に満たない場合，不足分は補われません。

なお，リクエストIDから<受付ID>，<分割キー>，<HCSCサーバ名>を除いた文字列が作業フォルダ名となります。

参考

デフォルトの状態では，マルチパート型以外のHTTPリクエストの場合は，作業フォルダが作成されません。ただし，マルチパート型以外のHTTPリクエストの場合でも，HTTPレスポンス時にファイルをダウンロードするときのために，HTTPリクエスト時にマルチパート型かどうかに関係なく作業フォルダを必ず作成するように設定できます。この設定は，HTTP受付定義ファイルのhttprecp.switchover.file-transfer.modeプロパティで有効にできます。

(b)　作業フォルダの削除

作業フォルダおよび作業フォルダ内の中間ファイルは，次の条件をすべて満たす場合に自動で削除されます。

HTTP受付定義ファイルのhttprecp.work-dir.auto-deleteプロパティの値がtrueである

HTTP受付が呼び出したビジネスプロセスから受け取った応答電文のstatus-code要素の値が200，またはstatus-code要素の指定を省略している

プロセスが異常終了した場合，およびcscpireexecコマンド（プロセスインスタンスの再実行）などでビジネスプロセスを再実行した場合は，作業フォルダおよび作業フォルダ内の中間ファイルは自動で削除されません。なお，作業フォルダが自動で削除されない場合，次の方法で作業フォルダを削除する必要があります。

HTTP受付定義ファイルのhttprecp.work-dir.auto-deleteプロパティの値がfalse，かつビジネスプロセスが非同期型のとき

ビジネスプロセスからファイル操作アダプタを呼び出して，作業フォルダおよび中間ファイルを削除してください。または，cscfswlsコマンドで作業フォルダを参照し，削除対象かどうか確認したあと，cscfswrmコマンドで作業フォルダを削除してください。

上記以外のとき

cscfswlsコマンドで作業フォルダを参照し，削除対象かどうか確認したあと，cscfswrmコマンドで作業フォルダを削除してください。

(2)　一時ファイルの作成と削除

HTTPリクエスト時にファイルのデータを送信する場合，メモリの圧迫を回避するため，処理用に一時ファイルが作成されます。また，一時ファイルを保存するフォルダとして，HTTP受付の起動時に，次の場所に一時ファイル保存フォルダが必ず作成されます。

<作業フォルダルート>¥<HCSCサーバ名>¥<受付ID>¥<00000000000000000000000000000000>

注意事項

一時ファイルはリクエスト処理の最後に自動で削除されます。ただし，次の場合，一時ファイルは削除されません。

一時ファイルが開かれたままの場合

J2EEサーバが正常に停止されなかった場合

システムがダウンした場合

一時ファイルが削除されない場合，cscfswrmコマンドで一時ファイル保存フォルダを削除してください。なお，一時ファイル保存フォルダは，HTTP受付を停止してから削除してください。HTTP受付が起動しているときに削除すると，ファイルのデータを送信するHTTPリクエストはすべてエラーとなります。

なお，小さいサイズのデータを送信するなど，一時ファイルへの出力が不要な場合，マルチパート型の各パートに対して一時ファイルに出力するかどうかのサイズの閾値を設定できます。この閾値はHTTP受付定義ファイルのhttprecp.file-trans.temp-file.partsize-thresholdプロパティで設定できます。

(3)　HTTPリクエストのサイズ上限の設定

サイズが大きい不正なデータが送信されることを防ぐために，マルチパート型のHTTPリクエストのサイズに上限を設定できます。HTTPリクエストのサイズが上限を超えた場合は，リクエスト処理が中止しHTTPクライアントにエラーを返します。

サイズ上限は次の項目についてそれぞれ設定できます。

リクエスト全体

HTTPヘッダ，HTTPボディ（全パートのヘッダおよびボディ分）を含むHTTPリクエスト全体のサイズ上限を設定できます。リクエスト全体のサイズ上限は，HTTP受付定義ファイルのhttprecp.file-trans.maxsize.requestプロパティで設定できます。

パート単位

各パート単位に指定されたボディ部分のサイズ上限を設定できます。テキストデータの場合でも同様の上限です。パート単位のサイズ上限は，HTTP受付定義ファイルのhttprecp.file-trans.maxsize.partプロパティで設定できます。

(4)　パス長に関する注意事項

OSによってパス長に制限がある場合，作業フォルダルートのパス長は適切な長さに設定してください。それぞれのパス長は次のとおりです。

表2‒70　作業フォルダルートのパス長

項目

パス長

作業フォルダルート

HCSCサーバランタイム定義ファイルのwork-folderプロパティで設定します。

HCSCサーバ名

最大8桁です。

受付ID

最大8桁です。

作業フォルダ名

IPv4の場合：32桁で固定です。

IPv6の場合：52桁で固定です。

中間ファイル

最大23桁です。

一時ファイル保存フォルダ名

32桁で固定です。

一時ファイル

最大53桁です。

2.15.7　HTTPリクエストとHTTPレスポンスのエンコーディング/デコーディング

HTTPリクエストとHTTPレスポンスのエンコーディングおよびデコーディングの処理について説明します。

HTTPリクエスト時，およびHTTPレスポンス時に使用される文字コードを次に示します。

HTTPリクエスト時

クエリ文字列およびメッセージボディをデコーディングするための文字コードは，次の方法で指定できます。

HTTPリクエストヘッダのContent-Typeヘッダのcharset属性で指定する方法

HTTP受付定義ファイルのhttprecp.http.charsetプロパティで指定する方法

HTTPリクエストヘッダとHTTP受付定義ファイルの両方で指定した場合，HTTPリクエストヘッダの指定が優先されます。

HTTPレスポンス時

メッセージボディのエンコーディングに使用される文字コードについては，「2.15.5(2)(a) Content-Typeとcharset」を参照してください。

注意事項

URLのデコードとメッセージボディのデコードには同じ文字コードが使用されます。

テキストデータとして利用する応答電文（ボディ）のデータは，XML宣言タグのencoding属性で設定した文字コードが，HTTPレスポンスボディとHTTPレスポンスヘッダに設定される文字コードと同じものになります。

次の場合，HTTPヘッダの値はユーザがURLエンコーディングする必要があります。

・日本語が含まれるHTTPリクエストヘッダをHTTPクライアントからHTTP受付に送信する場合

・応答電文（ヘッダ）に日本語のHTTPレスポンスヘッダが含まれる場合

・HTTPレスポンスヘッダ定義ファイルの値に日本語のHTTPレスポンスヘッダが含まれる場合

HTTP受付は，HTTPクライアントからのHTTPリクエストをビジネスプロセスに渡すときに，HTTPヘッダの値をエンコードおよびデコードしません。また，ビジネスプロセスからHTTPクライアントに応答を返すときも，HTTPヘッダの値をエンコードおよびデコードしません。

パススルーモードの場合，送信する要求電文のXML宣言タグのencoding属性には，必ず「UTF-8」を指定してください。

バイナリデータから生成したバイナリ形式または任意形式（any形式）の要求電文をXML形式の電文に変換する際は，データ変換アクティビティなどを使用してデコードする必要があります。

2.15.8　HTTP受付使用時のトランザクション

HTTP受付を使用した場合のトランザクションの範囲を次の図に示します。

図2‒145　HTTP受付を使用した場合のトランザクションの範囲

HTTPクライアントからHTTP受付が呼び出されると，HTTP受付では，HTTPクライアントおよびWebサーバのトランザクションとは異なる新たなトランザクションが開始されます。また，ビジネスプロセス内で，HTTP受付のトランザクションとは異なる新たなトランザクションが開始されます。

2.15.9　HTTP受付のタイマ管理

HTTP受付では，トランザクションタイムアウトを利用してリクエスト処理のタイマ監視ができます。

トランザクションタイムアウトでは，HTTP受付がビジネスプロセスを呼び出してから，HTTP受付に応答を返すまでの時間を秒単位で設定できます。処理時間がタイムアウトの設定値を超えた場合は，メッセージが出力されます。

トランザクションタイムアウト値は，HTTP受付定義ファイルで設定できます。

設定できるパラメタを次の表に示します。

表2‒71　トランザクションタイムアウトの設定

値

キー名称

デフォルト値

トランザクションタイムアウト（秒）

urecp-http.ejb-transaction-timeout

0※

注※

0を設定した場合，J2EEサーバに設定されたデフォルトのタイムアウト値で動作します。

2.15.10　HTTP受付のJSON-XML変換機能

HTTP受付のJSON-XML変換機能とは，HTTP受付でJSON形式の要求電文をXML形式に，またはXML形式の応答電文をJSON形式に変換する機能です。

(1)　HTTP受付のJSON-XML変換機能の概要

RESTクライアントから送信されたJSON形式の要求電文を，HTTP受付でXML形式の要求電文に変換します。また，ビジネスプロセスから応答されたXML形式の応答電文をJSON形式に変換し，RESTクライアントへ応答します。HTTP受付のJSON-XML変換機能を使用したサービス部品呼び出し要求および応答の流れを次の図に示します。

図2‒146　JSON-XML変換機能を使用したサービス部品呼び出し要求・応答の流れ（HTTP受付）

HTTP受付に設定する電文フォーマット（XMLスキーマ）は，JSON変換ツールで生成します。JSON変換ツールはJSON形式の電文のサンプルを受け取り，JSON-XML変換後のXML形式の電文に適合する電文フォーマットを生成します。JSON-XML変換機能を使用するHTTP受付の開発の流れを次の図に示します。

図2‒147　JSON-XML変換機能を使用するHTTP受付の開発の流れ

HTTP受付の定義の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「2.5　HTTP受付の定義」を，JSON変換ツールの詳細については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「13.　JSON変換ツールを使用したデータ変換」を参照してください。

(2)　HTTP受付のリクエスト処理時のJSON-XML変換機能

HTTP受付のリクエスト処理時のJSON-XML変換のタイミングや設定について説明します。

(a)　HTTP受付のリクエスト処理時のJSON-XML変換のタイミング

HTTP受付のリクエスト処理時の，JSON-XML変換のタイミングを次の図に示します。

図2‒148　リクエスト処理時のJSON-XML変換のタイミング（HTTP受付）

図中の1.〜4.について説明します。

HTTP受付がRESTクライアントから要求電文を受信します。

コンポーネント共通UOCでは，RESTクライアントから送信されたJSON形式の要求電文を扱います。

HTTP受付では，コンポーネント共通UOCの呼び出しとデータ変換の間でJSON-XML変換が実行されます。

データ変換では，JSON-XML変換機能で変換されたXML形式の要求電文を扱います。

(b)　HTTP受付のリクエスト処理時にJSON-XML変換をする場合の設定

HTTP受付定義ファイルのhttprecp.request.switchover.json-transfer.modeプロパティの値が「true」の場合，HTTP受付のリクエスト処理時にJSON-XML変換が実行されます。要求電文（ヘッダ）では，JSON-XML変換を実行するかどうかの切り替えはできません。プロパティの設定とJSON-XML変換の実行可否を次の表に示します。

表2‒72　リクエスト処理時のJSON-XML変換の実行可否（HTTP受付）

HTTP受付定義ファイル

httprecp.request.switchover.json-transfer.modeプロパティ

JSON-XML変換の実行

−（プロパティを設定していない）

実行されない

false

実行されない

true

実行される

参考

パススルーモードで，HTTPリクエストボディにmsgキーを使用するかどうかの設定に関わらず，JSON-XML変換機能を使用できます。

(c)　HTTP受付のHTTPリクエストヘッダに関連する処理

JSON-XML変換機能に関連しているHTTP受付のHTTPリクエストヘッダについて説明します。

HTTP受付のHTTPリクエストヘッダの処理の詳細については，「2.15.4　HTTP受付のリクエスト処理」を参照してください。

Content-Typeヘッダ

JSON-XML変換は，HTTPリクエストヘッダのContent-Typeヘッダの値に関わらず実行されます。また，Content-TypeヘッダがHTTPリクエストヘッダに設定されていない場合は，要求電文（ヘッダ）のcontent-type要素は生成されません。

Content-Typeヘッダのcharset属性

HTTPリクエストヘッダのContent-Typeヘッダにcharset属性が設定されていない場合は，要求電文（ヘッダ）のcharset属性にHTTP受付定義ファイルのhttprecp.http.charsetプロパティの値が設定されます。httprecp.http.charsetプロパティが設定されていないときは，要求電文（ヘッダ）のcharset属性に「UTF-8」が設定されます。

HTTPリクエストヘッダおよびHTTP受付定義ファイルのプロパティの設定と要求電文（ヘッダ）の関係を次の表に示します。

表2‒73　要求電文（ヘッダ）のcharset属性の設定（HTTP受付）

HTTPリクエスト

ヘッダの設定

HTTP受付定義ファイル

httprecp.http.charset

プロパティの設定

要求電文（ヘッダ）

charset属性の設定

Content-Type

ヘッダ

charset

属性

○

○

○

HTTPリクエストヘッダのcharset属性の値が設定されます。

○

○

×

○

×

○

httprecp.http.charsetプロパティの値が設定されます。

○

×

×

「UTF-8」が設定されます。

×

×

○

要求電文（ヘッダ）のcharset属性は設定されません。

（凡例）

○：値が設定されている

×：値が設定されていない

(3)　HTTP受付のレスポンス処理時のJSON-XML変換機能

HTTP受付のレスポンス処理時のJSON-XML変換のタイミングや設定について説明します。

(a)　HTTP受付のレスポンス処理時のJSON-XML変換のタイミング

HTTP受付のレスポンス処理時のJSON-XML変換のタイミングを次の図に示します。

図2‒149　レスポンス処理時のJSON-XML変換のタイミング（HTTP受付）

図中の1.〜4.について説明します。

HTTP受付がビジネスプロセスから応答電文を受信します。

データ変換では，ビジネスプロセスから返却されたXML形式の応答電文を扱います。

HTTP受付では，データ変換とコンポーネント共通UOCの呼び出しの間でJSON-XML変換が実行されます。

コンポーネント共通UOCでは，JSON-XML変換機能で変換されたJSON形式の応答電文を扱います。

(b)　HTTP受付のレスポンス処理時にJSON-XML変換をする場合の設定

HTTP受付定義ファイルのhttprecp.response.switchover.json-transfer.modeプロパティの値が「true」の場合は，HTTP受付のレスポンス処理時にJSON-XML変換が実行されます。応答電文（ヘッダ）のjson-transfer要素の値が「false」の場合は，HTTP受付のレスポンス処理時にJSON-XML変換は実行されません。HTTP受付定義ファイルのプロパティおよび応答電文（ヘッダ）の設定とJSON-XML変換の実行可否を次の表に示します。

表2‒74　レスポンス処理時のJSON-XML変換の実行可否（HTTP受付）

HTTP受付定義ファイル

httprecp.response.switchover.json-transfer.modeプロパティ

応答電文（ヘッダ）

json-transfer要素

JSON-XML変換の実行

−（プロパティを設定していない）

要素なし

実行されない

false

true

false

要素なし

実行されない

false

true

true

設定なし

実行される

false

実行されない

true

実行される

(c)　HTTP受付のHTTPレスポンスヘッダに関連する処理

JSON-XML変換機能に関連しているHTTP受付のHTTPレスポンスヘッダについて説明します。

HTTP受付のHTTPレスポンスヘッダの処理の詳細については，「2.15.5　HTTP受付のレスポンス処理」を参照してください。

Content-Typeヘッダ

JSON-XML変換は，応答電文（ヘッダ）に設定されているContent-Typeの値に関わらず実行されます。また，応答電文（ヘッダ）にContent-Typeが設定されていない場合は，「text/xml」がHTTPレスポンスヘッダのContent-Typeヘッダに設定されます。

Content-Typeヘッダのcharset属性

応答電文（ヘッダ）のContent-Typeにcharset属性が設定されていない場合は，HTTPレスポンスヘッダに設定されるContent-Typeヘッダのcharset属性に，HTTP受付定義ファイルのhttprecp.http.charsetプロパティの値が設定されます。httprecp.http.charsetプロパティが設定されていないときは，Content-Typeヘッダのcharset属性に「UTF-8」が設定されます。

応答電文（ヘッダ）およびHTTP受付定義ファイルのプロパティの設定とHTTPレスポンスヘッダのcharset属性の関係を次の表に示します。

表2‒75　HTTPレスポンスヘッダのcharset属性の設定（HTTP受付）

応答電文（ヘッダ）

の設定

HTTP受付定義ファイル

httprecp.http.charset

プロパティの設定

HTTPレスポンスヘッダ

charset属性の設定

Content-Type

ヘッダ

charset

属性

○

○

○

応答電文（ヘッダ）のcharset属性の値が設定されます。

○

○

×

○

×

○

httprecp.http.charsetプロパティの値が設定されます。

○

×

×

「UTF-8」が設定されます。

×

×

○

HTTPレスポンスヘッダのcharset属性は設定されません。

（凡例）

○：値が設定されている

×：値が設定されていない

2.15.11　HTTP受付の呼び出しサービス選択機能

HTTP受付から呼び出すビジネスプロセスをあらかじめHTTP受付サービス選択定義ファイルに設定しておくことで，リクエスト処理時にHTTP受付サービス選択定義ファイルに設定したビジネスプロセスを呼び出すことができる機能です。

HTTP受付とビジネスプロセスを1対Nで定義し，HTTP受付から呼び出すサービスを条件（HTTPメソッド名，およびホスト名）によって選択できます。1つのHTTP受付にひもづくビジネスプロセス（業務）を，複数のビジネスプロセス（業務）に分割できるので，ビジネスプロセス（業務）を変更するときの影響範囲を小さくします。

呼び出しサービス選択機能の設定については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「付録L　ユーザ定義受付（呼出先選択）の定義」を参照してください。HTTP受付サービス選択定義ファイルについては，マニュアル「サービスプラットフォーム リファレンス」の「3.11.2　HTTP受付サービス選択定義ファイル」を参照してください。

HTTPメソッドとホストを使用して，呼び出すビジネスプロセスを選択する処理を次の図に示します。

図2‒150　呼び出しサービス選択機能を使用したビジネスプロセスの選択処理

図中の1.〜5.について説明します。

HTTP受付にHTTP受付サービス選択定義ファイルを設定します。

HTTP受付の起動時に，設定したHTTP受付サービス選択定義ファイルが読み込まれます。

RESTクライアントからHTTPリクエストヘッダに，HTTPメソッド，およびホストの情報を含むリクエストを送信します。

URLに指定されたコンテキストルートに該当するHTTP受付で，HTTPリクエストを受け付けます。

リクエストから取得したHTTPメソッドおよびホスト名を条件に，2.のHTTP受付サービス選択定義ファイルの情報を検索し，条件に一致したビジネスプロセスを呼び出します。

2.15.12　OpenAPI仕様書からHCSCコンポーネントを作成するOpenAPI仕様書インポート機能

OpenAPI仕様書インポート機能とは，OpenAPI仕様書をHTTP受付やビジネスプロセスなどのHCSCコンポーネントに変換する機能です。

OpenAPI仕様書インポート機能を利用して作成したHCSCコンポーネントの定義ファイルをサービス定義のインポート機能を使用して，開発環境に取り込みます。

(1)　OpenAPI仕様書インポート機能の概要

OpenAPI仕様書をHCSCコンポーネントに変換する流れを次に示します。

図2‒151　OpenAPI仕様書をHCSCコンポーネントに変換する流れ

Swagger Editorなどのツールを使用し，OpenAPI仕様書を作成します。

HCSCコンポーネントとOpenAPI仕様書との対応については，「(3)　HCSCコンポーネントとOpenAPI仕様書との対応」を参照してください。

OpenAPI仕様書インポート機能を利用して，OpenAPI仕様書をHCSCコンポーネントの定義ファイル（サービス定義XMLファイル，電文のスキーマファイル，独自定義ファイル）に変換します。

OpenAPI仕様書の変換については，「(5)　OpenAPI仕様書の変換」を参照してください。

サービス定義のインポート機能を利用して，開発環境にHCSCコンポーネント（HTTP受付，ビジネスプロセス）を作成します。

サービス定義のインポート機能については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「6.4　サービス定義のインポート」を参照してください。

OpenAPI仕様書から作成されたHCSCコンポーネントの生成イメージを次に示します。

図2‒152　HCSCコンポーネントの生成イメージ

OpenAPI仕様書でのPath ItemはHTTP受付，Operationはビジネスプロセスにそれぞれ対応します。

(2)　前提条件

OpenAPI仕様書インポート機能を使用する場合の前提条件を次に示します。

OpenAPI仕様書インポート機能で対応するOpenAPI Specificationのバージョンは3.0以降です。

OpenAPI仕様書インポート機能で使用する前提OSSを次の表に示します。

前提OSSのjarファイルは，次に示すディレクトリの下に配置してください。

<サービスプラットフォームのインストールディレクトリ>¥CSCTE¥lib¥external

表2‒76　前提OSS一覧

項番

OSS名

バージョン

jarファイル名

ライセンス

1

swagger-parser-v3

2.0.21

swagger-parser-v3-2.0.21.jar

Apache License 2.0

2

swagger-models

(io.swagger.core.v3)

2.1.4

swagger-models-2.1.4.jar

Apache License 2.0

3

swagger-core

(io.swagger.core.v3)

2.1.4

swagger-core-2.1.4.jar

Apache License 2.0

4

jakarta.xml.bind-api

2.3.3

jakarta.xml.bind-api-2.3.3.jar

EDL 1.0

5

jakarta.activation-api

1.2.2

jakarta.activation-api-1.2.2.jar

EDL 1.0

6

commons-lang3

3.9

commons-lang3-3.9.jar

Apache License 2.0

7

slf4j-api

1.7.25

slf4j-api-1.7.25.jar

MIT

8

jackson-datatype-jsr310

2.11.2

jackson-datatype-jsr310-2.11.2.jar

Apache License 2.0

9

swagger-annotations

2.1.4

swagger-annotations-2.1.4.jar

Apache License 2.0

10

jakarta.validation-api

2.0.2

jakarta.validation-api-2.0.2.jar

Apache License 2.0

11

swagger-parser-core

2.0.21

swagger-parser-core-2.0.21.jar

Apache License 2.0

12

commons-io

2.7

commons-io-2.7.jar

Apache License 2.0

13

jackson-annotations

2.11.2

jackson-annotations-2.11.2.jar

Apache License 2.0

14

jackson-databind

2.11.2

jackson-databind-2.11.2.jar

Apache License 2.0

15

jackson-core

2.11.2

jackson-core-2.11.2.jar

Apache License 2.0

16

jackson-dataformat-yaml

2.11.2

jackson-dataformat-yaml-2.11.2.jar

Apache License 2.0

17

snakeyaml

1.26

snakeyaml-1.26.jar

Apache License 2.0

18

swagger-inflector

2.0.5

swagger-inflector-2.0.5.jar

Apache License 2.0

19

swagger-core

(io.swagger)

1.6.2

swagger-core-1.6.2.jar

Apache License 2.0

20

swagger-models

(io.swagger)

1.6.2

swagger-models-1.6.2.jar

Apache License 2.0

(3)　HCSCコンポーネントとOpenAPI仕様書との対応

OpenAPI仕様書インポート機能では，OpenAPI仕様書を変換して，HCSCコンポーネントのHTTP受付（呼出先選択）とビジネスプロセスを作成できます。

OpenAPI仕様書をHCSCコンポーネントに変換したときの例を次に示します。

図2‒153　OpenAPI仕様書からのHCSCコンポーネントの変換例

OpenAPI仕様書インポート機能で作成したHTTP受付（呼出先選択）には，OpenAPI仕様書の定義に従ったHTTPクライアントから接続できます。

HTTP受付（呼出先選択）およびビジネスプロセスと，OpenAPI仕様書について，次に説明します。

(a)　HTTP受付（呼出先選択）とOpenAPI仕様書との対応

HTTP受付（呼出先選択）とOpenAPI仕様書との対応を次の表に示します。

表2‒77　HTTP受付（呼出先選択）とOpenAPI仕様書との対応

項番

HTTP受付（呼出先選択）の設定

OpenAPI仕様書のフィールド

サービス定義XML

タグ

設定値

フィールドが定義されていない場合の設定値

1

受付名

Path Item#x-csd-reception-name

/service-definition/selectable-reception/name

Path Item#x-csd-reception-nameに設定した名称

デフォルトの受付名を設定します。

2

受付ID

Path Item#x-csd-reception-id

/service-definition/selectable-reception/reception-id

Path Item#x-csd-reception-idに設定したID

デフォルトのIDを設定します。

3

オペレーション

Path Item#get

/service-definition/selectable-reception/protocol-definition/operations/operation/name

GET

operation要素を省略します。

4

Path Item#put

PUT

5

Path Item#post

POST

6

Path Item#delete

DELETE

7

Path Item#options

OPTIONS

8

Path Item#head

HEAD

9

要求電文ボディの電文フォーマット

Request Body#content

/service-definition/selectable-reception/protocol-definition/operations/operation/input-body/format/file-path

XSDのファイルパス※1

file-path要素を省略します。

10

応答電文ボディの電文フォーマット

Response#content

/service-definition/selectable-reception/protocol-definition/operations/operation/output-body/format/file-path

XSDのファイルパス※2

file-path要素を省略します。

11

HTTP受付定義

−

/service-definition/selectable-reception/protocol-definition/custom-definition-files/file-path

HTTP受付定義のファイルパス

−

12

urecp-http.context-root

Paths#/{path}

Path Item#servers

OpenAPI#servers

−

{path}の内容

（テンプレートマッピング部分は使用しません）

HCSCコンポーネントを作成するための情報がないため，エラーメッセージ（KECT94017-E）が出力されます。

13

httprecp.request.switchover.json-transfer.mode

Request Body#content

−

true※3

プロパティを省略します（=false）。

14

httprecp.response.switchover.json-transfer.mode

Response#content

−

true※4

プロパティを省略します（=false）。

15

httprecp.switchover.pass-through.mode

Response#content

−

true※5

プロパティを省略します（=false）。

16

HTTP受付サービス選択定義

Path Item

/service-definition/selectable-reception/protocol-definition/custom-definition-files/file-path

HTTP受付サービス選択定義のファイルパス

−

17

<HTTPメソッド名>=<ビジネスプロセス名>

Path Item

−

項番3〜8のオペレーション=ビジネスプロセス名

プロパティを省略します。

（凡例）−：該当しません。

注※1

Media Typeがjson，またはxmlの場合にXSDを生成し，ファイルパスを設定します。次の場合はfile-path要素を省略します。

・Media Typeがjson，またはxml以外の場合

・1つのRequestBody内にMedia Typeが複数定義されていた場合

・Media Typeがmultipartの場合

注※2

Media Typeがjson，またはxmlの場合にXSDを生成し，ファイルパスを設定します。次の場合はfile-path要素を省略します。

・Media Typeがjson，またはxml以外の場合

・1つのResponse内にMedia Typeが複数定義されていた場合

・Media Typeがmultipartの場合

また，ResponseがResponses内で複数定義されていた場合は要素を省略します。

注※3

RequestBodyのMedia Typeがjsonである場合はtrueを設定します。json以外の場合はプロパティを省略します（=false）。

Path Item内の各オペレーションに定義されているRequestBodyに1つでもjsonのMedia Typeがあればtrueとなります。

注※4

ResponseのMedia Typeがjsonである場合はtrueを設定します。json以外の場合はプロパティを省略します（=false）。

Path Item内の各オペレーションに定義されているResponseに1つでもjsonのMedia Typeがあればtrueとなります。

注※5

RequestBodyのMedia Typeがjson，またはxmlである場合はtrueを設定します。json，またはxml以外の場合はプロパティを省略します（=false）。

Path Item内の各オペレーションに定義されているRequestBodyに1つでもjson，またはxmlのMedia Typeがあればtrueとなります。

この表に記載がないHTTP受付の設定についてはOpenAPI仕様書では定義できません。サービス定義XMLファイルのデフォルト値が採用されます。サービス定義XMLファイルについては，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「6.　サービス定義のインポート・エクスポート」を参照してください。

(b)　ビジネスプロセスとOpenAPI仕様書との対応

ビジネスプロセスとOpenAPI仕様書との対応を次の表に示します。

表2‒78　ビジネスプロセスとOpenAPI仕様書との対応

項番

ビジネスプロセスの設定

OpenAPI仕様書のフィールド

サービス定義XML

タグ

設定値

フィールドが定義されていない場合の設定値

1

ビジネスプロセス名

Operation#x-csd-business-process-name

/service-definition/business-process/overview/name

Operation#x-csd-business-process-nameに設定した名称

デフォルトのビジネスプロセス名を設定します。

2

サービスID

Operation#x-csd-business-process-id

/service-definition/business-process/overview/service-id

Operation#x-csd-business-process-idに設定した名称

デフォルトのIDを設定します。

3

変数定義

要求電文ヘッダ

変数名

Operation#x-csd-request-header-variable-name

/service-definition/business-process/variables/global/variable/name

Operation#x-csd-request-header-variable-nameに設定した名称

デフォルトの変数名を設定します。

4

種別

−

/service-definition/business-process/variables/global/variable/type

XML

−

5

電文フォーマット

−

/service-definition/business-process/variables/global/variable/file-path

<サービスプラットフォームのインストールディレクトリ>/CSC/custom-reception/http/schema/urecp_http_header_request.xsd

−

6

要求電文ボディ

変数名

Media Type#x-csd-variable-name

/service-definition/business-process/variables/global/variable/name

Media Type#x-csd-variable-nameに設定した名称

デフォルトの変数名を設定します。

7

種別

−

/service-definition/business-process/variables/global/variable/type

XML

−

8

電文フォーマット

Request Body#content

/service-definition/business-process/variables/global/variable/file-path

XSDのファイルパス

−

Media Type#schema

9

応答電文ヘッダ

変数名

Operation#x-csd-response-header-variable-name

/service-definition/business-process/variables/global/variable/name

Operation#x-csd-response-header-variable-nameに設定した名称

デフォルトの変数名を設定します。

10

種別

−

/service-definition/business-process/variables/global/variable/type

XML

−

11

電文フォーマット

−

/service-definition/business-process/variables/global/variable/file-path

<サービスプラットフォームのインストールディレクトリ>/CSC/custom-reception/http/schema/urecp_http_header_response.xsd

−

12

応答電文ボディ

変数名

Media Type#x-csd-variable-name

/service-definition/business-process/variables/global/variable/name

Media Type#x-csd-variable-nameに設定した名称

デフォルトの変数名を設定します。

13

種別

−

/service-definition/business-process/variables/global/variable/type

XML

−

14

電文フォーマット

Response#content

/service-definition/business-process/variables/global/variable/file-path

XSDのファイルパス

−

Media Type#schema

15

受付アクティビティ

アクティビティ名

Operation#x-csd-receive-activity-name

/service-definition/business-process/activities/global/main-sequence/receive-activity/activity-name

Operation#x-csd-receive-activity-nameに設定した名称

デフォルトの変数名を設定します。

16

オペレーション名

−

/service-definition/business-process/activities/global/main-sequence/receive-activity/operation-name

Operationに定義したHTTPメソッド名

−

17

ボディ割当変数

−

/service-definition/business-process/activities/global/main-sequence/receive-activity/body-variable-name-ref

項番6の変数

−

18

ヘッダ割当変数

割当変数

−

/service-definition/business-process/activities/global/main-sequence/receive-activity/headers/header/variable-name-ref

項番3の変数

−

ルート要素

−

/service-definition/business-process/activities/global/main-sequence/receive-activity/headers/header/root-element-name

http-header-request

−

19

応答アクティビティ

アクティビティ名

Operation#x-csd-reply-activity-name

/service-definition/business-process/activities/global/main-sequence/reply-activity/activity-name

Operation#x-csd-reply-activity-nameに設定した名称

デフォルトの変数名を設定します。

20

オペレーション名

−

/service-definition/business-process/activities/global/main-sequence/reply-activity/operation-name

Operationに定義したHTTPメソッド名

−

21

ボディ割当変数※

−

/service-definition/business-process/activities/global/main-sequence/reply-activity/body-variable-name-ref

項番12の変数

−

22

ヘッダ割当変数

割当変数

−

/service-definition/business-process/activities/global/main-sequence/reply-activity/headers/header/variable-name-ref

項番9の変数

−

ルート要素

−

/service-definition/business-process/activities/global/main-sequence/reply-activity/headers/header/root-element-name

http-header-response

−

（凡例）−：該当しません。

注※

ResponseがResponses内で複数定義されていた場合は要素を省略します。

(4)　設定項目の命名規則

受付名やビジネスプロセス名などの設定項目は，OpenAPI仕様書にCSD独自のフィールドを定義することで設定できます。CSD独自フィールドの設定値は，変換時に検証され，エラーになった場合，またはCSD独自フィールドが定義されていない場合は，規則に従ってデフォルト値が設定されます。

CSD独自フィールドと設定項目の対応を次に示します。

表2‒79　CSD独自フィールドと設定項目の対応

HCSCコンポーネントの設定項目

CSD独自フィールド

デフォルト値

デフォルト値の設定例

受付名

Path Item#x-csd-reception-name

rcp<連番>※1

rcp1, rcp2, rcp3, …

受付ID

Path Item#x-csd-reception-id

<連番>※1※2

1, 2, 3, …

ビジネスプロセス名

Operation#x-csd-business-process-name

bp<連番>※1_<HTTPメソッド名>

bp1_get, bp2_put, …

サービスID

Operation#x-csd-business-process-id

<連番>※1※2

1, 2, 3, …

受付アクティビティ名※3

Operation#x-csd-receive-activity-name

receive_activity

−

応答アクティビティ名※3

Operation#x-csd-reply-activity-name

reply_activity

−

変数名※4

要求電文ヘッダ

Operation#x-csd-request-header-variable-name

応答電文ヘッダ

Operation#x-csd-response-header-variable-name

要求電文ボディおよび応答電文ボディ

Media Type#x-csd-variable-name

要求電文ヘッダ

http_header_request

応答電文ヘッダ

http_header_response

要求電文ボディ

http_body_request

応答電文ボディ

http_body_response_<ステータスコード>

−

（凡例）−：該当しない。

注※1

連番は変換順に1から1つずつ繰り上がります。連番を付与したあとの名称が重複する場合は番号をさらに1つ繰り上げます。

注※2

受付IDとサービスIDは共通の連番を使用し，重複しないように設定されます。

注※3

デフォルトの名称がすでに使用されている場合は，連番を付与します。

（例）receive_activity1

注※4

デフォルトの名称がすでに使用されている場合は，アンダーバーと連番を付与します。

（例）http_body_response_200_1

(5)　OpenAPI仕様書の変換

OpenAPI仕様書をHCSCコンポーネントに変換するには，cscoas2servicedefコマンドにOpenAPI仕様書のファイルパスや出力先ディレクトリなどの指定が必要です。

cscoas2servicedefコマンドの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「cscoas2servicedef（OpenAPI仕様書をHCSCコンポーネントの定義に変換）」を参照してください。

(6)　OpenAPI仕様書の変換時の注意事項

cscoas2servicedefコマンドに指定した出力先ディレクトリに同名のファイルがある場合は，上書きされます。

cscoas2servicedefコマンドに指定した出力先ディレクトリがない場合は，新規にディレクトリを作成し，ファイルを出力します。出力先ディレクトリと同名のファイルがあった場合はエラーとなります。

入力ファイルに使用できる文字コードはUTF-8だけです。UTF-8以外の文字コードのファイルが入力された場合の動作は保証しません。各定義ファイルの出力時に使用する文字コードもUTF-8となります。

OpenAPI仕様書内に記述されたOpenAPI Specificationのバージョンが3.0以降でない場合，およびフィールドが省略されていた場合はエラーとなります。

XML Schemaファイルの生成では，Schemaオブジェクト内の次の情報を利用します。

example（データ例）

default（デフォルト値）

enum（値の列挙型）

これらのフィールドがSchemaオブジェクトのtypeやpropertiesフィールドなどに沿って定義されていない場合は，SchemaオブジェクトどおりのXML Schemaが生成されないことがあります。

変換結果のファイル名やディレクトリ名として使用するフィールドにはWindowsのファイル名として利用できない文字および名称は指定できません。指定した場合の動作は保証されません。

$refを使用する場合，正しい参照先を指定してください。参照が解決できなかったときは，正しく変換されない場合があります。

XML Schemaファイルを生成する場合に，OpenAPI仕様書インポート機能で対応するSchemaオブジェクトのフィールドを次に示します。

type

items

properties

format

enum

default

example

xml

Media Typeがjsonの場合に生成されるXML Schemaファイルは，スキーマ内に定義される要素がjsonのオブジェクト名の昇順にソートされます。

受付名などを設定するためのCSDの独自フィールドの値は，文字列で指定してください。

XML Schemaの生成で，Schemaオブジェクトにitemsフィールドが定義されている場合は，typeフィールドの値に関係なく，arrayとして扱われます。

XML Schemaの生成で，XMLオブジェクトのnamespaceフィールドはルート要素にだけ指定できます。また，namespaceフィールドを指定する場合は，prefixフィールドの指定も必要です。

XML Schemaの生成では，XMLオブジェクトのwrappedフィールドは指定できません。

XML Schemaの生成で，次のときはXML Schemaが生成されません。

Media Typeがjsonの場合で，最上位に定義されているSchemaオブジェクトのtypeフィールドがobjectまたはarrayでないとき

Media Typeがxmlの場合で，最上位に定義されているSchemaオブジェクトのtypeフィールドがobjectでないとき

2.15.13　HTTP受付を使用するときの注意

HTTPレスポンスヘッダを応答電文（ヘッダ）のhttp-header要素で設定する場合は，有効なHTTPヘッダを設定してください。HTTP受付はHTTPヘッダが妥当かどうかを検証しません。

HTTP受付では，HTTPのセッション管理をサポートしていません。

HTTPリクエストにテキストデータが存在しない場合でも，受付アクティビティに設定する要求電文（ボディ）を設定してください。

HTTPレスポンスでテキストデータを返さない場合でも，応答アクティビティに設定する要求電文（ボディ）を設定してください。設定するスキーマは製品が提供するスキーマを使用してください。

HTTPリクエストボディをビジネスプロセスに渡すときのモードにパススルーモードを使用し，かつHTTP受付定義ファイルにhttprecp.pass-through.parameter-use=trueを指定している場合は，次の注意事項があります。

「msg=値」のペアは1つだけ指定してください。複数の「msg=値」のペアが指定された場合，動作を保証しません。また，msgキーの指定がない場合はエラーになります。

msgキーはすべて小文字で指定してください。大文字を指定した場合はエラーになります。

HTTPリクエストボディには有効なXML文字列を指定してください。HTTP受付ではXML文書をチェックしません。

「msg=msg=abc」のように，クエリ文字列またはメッセージボディに複数の「=」が指定された場合，最初の「=」が区切り文字として使用されます。この場合，最初の「=」の前の部分はキーとして読み込まれ，最初の「=」のあとの文字列全体は値として読み込まれます。

HTTP受付を利用してテキストデータの送受信，およびファイルのデータをアップロードまたはダウンロードする場合，次の制限があります。

ビジネスプロセスはHTTP受付に応答を返す必要があります。このため，HTTP受付の通信モデルは非同期にできません。

BPELの並行処理（FLOW）は使用できません。

HTTP受付に対して1リクエストで同時に処理できるファイル数の上限は1,024個です。

応答電文（ヘッダ）のpartID要素およびfile-name要素にマルチバイト文字を指定した場合，動作を保証しません。

HTTPレスポンスでファイルのデータを送信する場合，指定できるファイル数の上限は1,024です。指定したファイル数が1,024を超えた場合は，動作を保証しません。

HTTP受付を利用してファイルのデータを送受信する場合は，次の点を考慮して，HTTP受付ごとに作業フォルダのディスクサイズを十分に割り当ててください。

同時実行数

サイズが大きいファイルを扱うHTTPリクエストが一度に大量に送信される可能性がある場合，極端なリソース消費とならないように同時実行数を考慮してください。

想定される最大のHTTPリクエストサイズ

ファイルのデータの処理時に作成される一時ファイルは，中間ファイルと同じサイズおよび個数生成されます。このため，最大でどの程度のHTTPリクエストが送信されるか事前に見積もっておく必要があります。

HTTP受付に関連づいたビジネスプロセスの処理

HTTP受付から呼び出されたビジネスプロセスで，ファイル操作アダプタを利用して作業フォルダ内にファイルを生成したり，HTTPアダプタなどで取得したファイルを作業フォルダに格納したりする場合は，その処理によって生成されるファイルのサイズも考慮しておく必要があります。また，中間ファイルおよび一時ファイルが削除されるまでの処理時間を考慮してビジネスプロセスを設計してください。

コンテキストルートは，Component Containerの作業ディレクトリの中でディレクトリ名として使用されます。そのため，作業ディレクトリ全体のパス長がOSの上限に達しないようにコンテキストルートを指定する必要があります。OSのパス長の上限については，使用する各OSのドキュメントを参照してください。

Component Containerの作業ディレクトリ全体の構成を次に示します。

Component Containerの作業ディレクトリ全体の構成

備考

Component Containerの作業ディレクトリまでのパス¥

−

Component Containerの作業ディレクトリ¥

デフォルトのパスは次のとおりです。

Windowsの場合

<サービスプラットフォームのインストールディレクトリ>¥CC¥server¥public

UNIXの場合

/opt/Cosminexus/CC/server/public

コンテキストルート名にスラッシュ（/）などが指定されている場合，値が3桁の半角文字に置き換えられます。

web¥

−

<J2EEサーバ名>¥

−

<コンテキストルート名>¥

−

WEB-INF¥

−

classes¥

−

HTTP受付のパッケージ名のディレクトリ階層¥

ディレクトリ階層は，jp/co/Hitachi/soft/csc/msg/message/reception/http/implです。

HTTP受付のクラスファイル

最も長いファイル名は，"CSCMsgHTTPServletContextListener.class"です。

（凡例）

−：該当する説明はありません。

Component Containerの作業ディレクトリ全体のパス長は，次の見積もり式で算出できます。このパス長がOSの最大パス長を超えないようにコンテキストルートを指定してください。

Component Containerの作業ディレクトリ全体のパス長=A+2×B+C+D+E+F+25

A：Component Containerの作業ディレクトリまでのパスの長さ

B：Component Containerの作業ディレクトリ名の長さ

C：最も長いJ2EEサーバ名の長さ

D：コンテキストルートの長さ（「/」などを含む場合は文字×3で換算します）

E：HTTP受付のパッケージ名のディレクトリ階層の長さ

F：HTTP受付のクラスファイルのうち，最も長いファイル名の長さ

2.16　HTTP通信を使用したサービスとの接続

HTTPアダプタを利用することで，Webサーバ上に公開されているリソースや，RESTスタイルで公開されているWebサービス（RESTful Webサービス）をビジネスプロセスから呼び出すことができます。

2.16.1　前提条件

HTTPアダプタを利用するための前提条件を次に示します。

HTTPアダプタを使用するときは，SOAPモードをSOAP1.1/1.2併用モードにしてください。

HTTPアダプタは，RESTサービスやWebリソースとの通信にJAX-RS機能を使用します。

HTTPアダプタに設定したパラメタからHTTPリクエストを生成して送信する処理や，HTTPレスポンスを受信して解析する処理は，JAX-RS機能の動作に従います。

注意事項

HTTPアダプタの設定は，このマニュアルに記載された方法に従ってください。

HTTPアダプタで使用するJAX-RS機能の設定を直接変更した場合は，動作の保証はできません。

2.16.2　HTTPアダプタを使用したサービス部品の呼び出し

HTTPアダプタを使用したサービス部品呼び出し要求・応答の流れを次の図に示します。

図2‒154　HTTPアダプタを使用したサービス部品呼び出し要求・応答の流れ

サービス部品呼び出し要求時，ビジネスプロセスから渡された要求電文はHTTPアダプタでHTTPリクエストに変換されてサービス部品に送信されます。また，応答時はサービス部品から送信されたHTTPレスポンスがHTTPアダプタで応答電文に変換され，ビジネスプロセスに渡されます。

HTTPアダプタはCookieを利用したセッション維持やファイルのアップロード・ダウンロードに対応しています。また，HTTP受付と組み合わせて利用することで，HTTPクライアントからアップロードしたファイルをサーバに送信したり，サーバからダウンロードしたファイルをHTTPクライアントに送信したりすることもできます。

2.16.3　HTTPリクエストと要求電文の関係

ここでは，HTTPアダプタの要求電文からHTTPリクエストへの変換の仕組みについて説明します。

ビジネスプロセスから渡された要求電文は，HTTPアダプタで次のように分割してHTTPリクエストに変換されます。

リクエストライン

HTTPリクエストヘッダ

HTTPリクエストボディ

HTTPリクエストの設定方法および各項目の詳細について説明します。

なお，ここで説明する電文の例では，名前空間接頭辞を省略しています。

(1)　HTTPリクエストの設定方法

(a)　設定個所

HTTPリクエストは，HTTPリクエストの構成要素ごとに，次の場所で設定します。

●リクエストライン

要求電文（ヘッダ）

HTTPアダプタ実行環境プロパティファイル

HTTPアダプタ実行環境共通プロパティファイル

●リクエストヘッダ

要求電文（ヘッダ）

HTTPアダプタ実行環境プロパティファイル

HTTPアダプタ実行環境共通プロパティファイル

●リクエストボディ

要求電文（ボディ）

作業フォルダ・共通フォルダ※内のファイル

注※

共通フォルダの場合，配下のサブフォルダを使用できます。

リクエストラインとリクエストヘッダは，上記3つの設定場所の中から任意の場所（単一の場所でも複数の場所の組み合わせでも可能）を使用して設定します。リクエストボディは要求電文（ボディ），または作業フォルダ・共通フォルダ内のファイルを使用して設定します。

図2‒155　HTTPリクエストの設定例

(b)　リクエストライン，リクエストヘッダの設定方法

リクエストラインとリクエストヘッダは，要求電文（ヘッダ），HTTPアダプタ実行環境プロパティファイル，HTTPアダプタ実行環境共通プロパティファイルの3つの場所で設定します。複数の場所に設定がある場合は，HTTPアダプタは優先度が高い設定を使用して処理をします。

それぞれの設定場所の優先度は次のとおりです。

表2‒80　リクエストラインとリクエストヘッダの設定場所と優先度

優先度

設定場所

高

優先度1

要求電文（ヘッダ）

|

優先度2

HTTPアダプタ実行環境プロパティファイル

低

優先度3

HTTPアダプタ実行環境共通プロパティファイル

HTTPリクエストの設定は，要求電文（ヘッダ）や各プロパティファイルの中のパラメタ（要求電文（ヘッダ）の各要素やプロパティファイルの個々のプロパティ）単位で有効になります。

それぞれの設定場所には，次のような特長があります。システムの要件に合わせてこれらを適切に組み合わせることで，開発工数の削減や運用の容易化を図れます。

表2‒81　リクエストラインとリクエストヘッダの設定場所と特長

設定場所

特長

要求電文（ヘッダ）

HTTPアダプタの実行時に設定できるため，リクエストごとに動的に値を変更する必要があるパラメタの定義に適しています。

（例）リクエストメソッドやURIの指定，など

HTTPアダプタ実行環境プロパティファイル

HTTPアダプタの1定義ごとに固定のパラメタを設定することができるため，アダプタ開発時（または運用時）に静的に決まるパラメタの設定に適しています。

（例）ファイル受信（ダウンロード）時の出力先フォルダの指定，など

HTTPアダプタ実行環境共通プロパティファイル

すべてのHTTPアダプタに共通のパラメタを設定することができるため，システム共通の静的なパラメタの設定に適しています。

（例）認証情報やログファイルの出力先の指定，など

設定例

具体的な使用例を用いて，HTTPリクエストの設定方法を示します。

パターン1（常に固定のHTTPリクエストを発行する場合）

HTTPアダプタから常に固定のHTTPリクエストを発行する場合，最も簡単な設定方法は，実行環境プロパティファイルによるリクエストの設定です。この方法では，HTTPアダプタは自分のサービスIDと同じ名前の実行環境プロパティファイルをアダプタ起動時に読み込み，リクエスト発行の要求があるたびに，実行環境プロパティファイルの内容に基づいてHTTPリクエストを発行します。

図2‒156　HTTPリクエストの設定例（常に固定のHTTPリクエストを発行する場合）

パターン2（複数のHTTPアダプタの間で一部の設定を共有する場合）

複数のHTTPアダプタの間で一部の設定をシステム共通のパラメタとして共有する場合は，実行環境共通プロパティファイルにシステム共通のパラメタを切り出して設定することが有効です。次の図では，アダプタ1およびアダプタ2に共通のパラメタとしてサービス1に対するWWW認証の認証情報があり，これを実行環境共通プロパティファイルで定義しています。

図2‒157　HTTPリクエストの設定例（複数のHTTPアダプタの間で一部の設定を共有する場合）

このような設定方法にすることで，共有するパラメタを重複して定義する必要がなくなるため，開発工数を削減できます。また，共通のパラメタが1つのプロパティファイルで一元管理されるため，設定の確認や変更作業（本例ではサービス1の認証情報の更新に伴うHTTPアダプタの設定変更作業）が容易になります。

パターン3（HTTPリクエストの内容を動的に設定する場合）

HTTPリクエストの内容をリクエスト発行時に動的に設定する必要がある場合（ビジネスプロセスの処理状態に応じてリクエストの内容を変更する場合）は，要求電文（ヘッダ）を利用してHTTPリクエストを設定します。次の図では，ビジネスプロセスからアダプタ2に渡す要求電文（ヘッダ）の中にクエリ情報を定義し，HTTPリクエスト発行時にリクエストラインのクエリ情報が動的に生成されるようにしています。

このようなアダプタ実行時にHTTPリクエストの内容を動的に変更する設定は，要求電文（ヘッダ）を使用した場合だけです。

図2‒158　HTTPリクエストの設定例（HTTPリクエストの内容を動的に設定する場合）

参考

優先度が低い設定場所で定義したパラメタは，優先度が高い設定場所で定義したパラメタで値を置き換える（上書きする）ことができます。例えば上記の図では，実行環境共通プロパティファイルを使用してすべてのアダプタのログ出力先を”E:¥log”に設定していますが，アダプタ3だけアダプタ固有の実行環境プロパティファイルを使用して，ログ出力先を”F:¥log”に変更しています。一部のHTTPアダプタだけ例外的な設定が必要な場合や，一時的に特定のHTTPアダプタだけ動作を変更したいなどの場合には，このような設定方法も使用できます。

具体的な設定項目や設定方法

リクエストラインやリクエストヘッダの具体的な設定項目や設定方法については，「(2) リクエストライン」，および「(3) HTTPリクエストヘッダ」を参照してください。

要求電文（ヘッダ）で設定できる要素の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.13　HTTPアダプタを定義する」を参照してください。

HTTPアダプタ実行環境プロパティファイル，およびHTTPアダプタ実行環境共通プロパティファイルで設定できるプロパティの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「6.14.2　HTTPアダプタ実行環境プロパティファイル」を参照してください。

要求電文（ヘッダ）とHTTPアダプタ実行環境（共通）プロパティファイルのパラメタの対応関係については，「2.16.13　要求電文（ヘッダ）とHTTPアダプタ実行環境（共通）プロパティファイルのパラメタの対応関係」を参照してください。

注意事項

実行環境（共通）プロパティファイルについて

HTTPアダプタの起動時に実行環境プロパティファイルやHTTPアダプタ実行環境共通プロパティファイルが所定の場所に配備されていない場合は，HTTPアダプタはそのプロパティファイルを使用しないものとして動作します。

実行環境プロパティファイルと実行環境共通プロパティファイルの両方が配備されていない場合は，HTTPアダプタはこれらのプロパティファイルに対してすべてデフォルト値が指定されたものと仮定して動作します。デフォルト値がないプロパティは未定義状態になるため，必要に応じて，アダプタ実行時に要求電文（ヘッダ）でリクエストの設定を行うようにしてください。

要求電文（ヘッダ）について

HTTPアダプタの開発時に要求電文用のヘッダ割当変数の指定を省略した場合は，HTTPアダプタは要求電文（ヘッダ）を使用しないものとして動作します。

HTTPアダプタの開発時に要求電文用のヘッダ割当変数を複数指定した場合は，HTTPアダプタの要求電文（ヘッダ）の名前空間を持つヘッダ割当変数が使用されます。

HTTPアダプタの開発時にHTTPアダプタの要求電文（ヘッダ）の名前空間を持つヘッダ割当変数を複数指定した場合は，実行時にどのヘッダ割当変数が使用されるかは不定です。

その他全般

複数の設定場所を使用することでシステムの開発や運用を効率化できます。しかし，必要以上に設定の階層化や複雑化をすると，実行時にどの設定場所のパラメタが使用されるか，理解することが難しくなります。最初にシステムの構成や運用業務の分析を行った上で，適切な効果が得られるように設計や開発を行ってください。

(c)　リクエストボディの設定方法

リクエストボディは，リクエストボディに格納するデータと，データ送信種別（データの格納方法）のペアで指定します。それぞれ，次の場所で設定します。

●格納するデータ

要求電文（ボディ），または作業フォルダ・共通フォルダ※内のファイル

注※

共通フォルダの場合，配下のサブフォルダを使用できます。

●データ送信種別

要求電文（ヘッダ）やHTTPアダプタ実行環境（共通）プロパティファイル

データ送信種別に応じて，要求電文（ボディ），または作業フォルダ・共通フォルダ内のファイルが適切な形に変換された上でリクエストボディに格納され，リクエストとして発行されます。リクエストボディを発行する際の設定イメージを次に示します。

具体的な設定項目や設定方法については，「(4) HTTPリクエストボディ」を参照してください。

要求電文（ボディ）で設定できる要素の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.13　HTTPアダプタを定義する」を参照してください。

(2)　リクエストライン

HTTPリクエストの先頭行に記述するリクエストラインは次の形式で送信されます。

HTTPメソッド△URI△プロトコル※

（凡例）

△：半角スペースです。

注※

プロトコルは「HTTP/1.1」で固定です。

HTTPメソッドおよびURIの指定方法について説明します。

(a)　HTTPメソッド

リクエストラインのHTTPメソッドは，要求電文（ヘッダ），HTTPアダプタ実行環境プロパティファイル，およびHTTPアダプタ実行環境共通プロパティファイルに指定します。

HTTPメソッドの指定個所を次に示します。

表2‒82　HTTPメソッドの指定個所

指定方法

項目

指定個所

要求電文（ヘッダ）

HTTPメソッド

method要素

HTTPアダプタ実行環境プロパティファイル，HTTPアダプタ実行環境共通プロパティファイル

HTTPメソッド

adphttp.request.methodプロパティ

注意事項

次のメソッドはHTTPリクエストボディを指定できません。

GET

DELETE

HEAD

OPTIONS

これらのメソッドを使用するときは，必ずデータ種別を「データなし」にしてください。HTTPリクエストボディのデータ種別については，「(4)(a) データ種別」を参照してください。

要求電文（ヘッダ），HTTPアダプタ実行環境プロパティファイル，およびHTTPアダプタ実行環境共通プロパティファイルのどれにもHTTPメソッドが指定されなかった場合はエラーになります。

(b)　URI

リクエストラインのURIは，スキーム・オーソリティ部分，パス部分，クエリ部分に分割して，要求電文（ヘッダ），HTTPアダプタ実行環境プロパティファイル，およびHTTPアダプタ実行環境共通プロパティファイルに指定します。

URIの指定個所を次に示します。

表2‒83　URIの指定個所

指定方法

項目

指定個所

要求電文（ヘッダ）

スキーム・オーソリティ

uri-scheme-authority要素

パス

uri-path要素

クエリ

uri-query要素

HTTPアダプタ実行環境プロパティファイル，HTTPアダプタ実行環境共通プロパティファイル

スキーム・オーソリティ

adphttp.request.uri-scheme-authorityプロパティ

パス

adphttp.request.uri-pathプロパティ

クエリ

adphttp.request.uri-query.<追番>プロパティ

要求電文（ヘッダ），HTTPアダプタ実行環境プロパティファイル，およびHTTPアダプタ実行環境共通プロパティファイルのどれにもスキーム・オーソリティとパスが指定されなかった場合はエラーになります。

スキーム・オーソリティのスキーム部分に「https」を指定した場合，HTTPSを使用して通信します。ただし，HTTPSを使用するには設定が必要です。詳細は，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「付録I　HTTPアダプタで必要なセキュリティの設定」を参照してください。

URIの指定例を次に示します。どちらの場合も生成されるURIは「http://localhost:80/test/selectdata?name=sample&id=001」です。

要求電文（ヘッダ）で指定した場合

<http-header-request>
    <uri-scheme-authority>http://localhost:80</uri-scheme-authority>
    <uri-path>/test/selectdata</uri-path>
    <uri-query>
        <name>sample</name>
        <id>001</id>
    </uri-query>
</http-header-request>

HTTPアダプタ実行環境プロパティファイルで指定した場合

adphttp.request.uri-scheme-authority＝http://localhost:80
adphttp.request.uri-path=/test/selectdata
adphttp.request.uri-query.1=name=sample
adphttp.request.uri-query.2=id=001

参考

スキーム・オーソリティ部分，パス部分，クエリ部分は独立して指定できます。このため，スキーム・オーソリティ部分をHTTPアダプタ実行環境プロパティファイルに指定して，パス部分とクエリ部分を要求電文（ヘッダ）で指定することで，HTTPリクエストの宛先を動的に変更することもできます。

注意事項

スキーム・オーソリティ部分とパス部分とクエリ部分には，それぞれに適切な値を設定してください。パス部分にスキーム・オーソリティやクエリを指定した場合など，不適切な値を指定した場合は動作を保証しません。

(c)　クエリ

URIのクエリ部分は，要求電文（ヘッダ）に内包されるクエリ用詳細電文フォーマットをカスタマイズして指定できます。

クエリの指定例を次に示します。

クエリ用詳細電文フォーマットのカスタマイズの例

（変更前）

<xsd:complexType name="uri-query-type">
   <xsd:sequence>
      <xsd:any namespace="##any" processContents="skip" minOccurs="0" maxOccurs="1024" />
   </xsd:sequence>
</xsd:complexType>

（変更後）

<xsd:complexType name="uri-query-type">
   <xsd:sequence>
      <xsd:element name="parameter1" type="xsd:string" minOccurs="0"/>
      <xsd:element name="parameter2" type="xsd:string" minOccurs="0"/>
   </xsd:sequence>
 </xsd:complexType>

この例では，xsd:any型の要素を，クエリ名をローカル名とするxsd:string型の要素に変更しています。また，出現回数の指定は任意です。

要求電文（ヘッダ）の指定例

<http-header-request>
    <uri-scheme-authority>http://localhost:80</uri-scheme-authority>
    <uri-path>/test/selectdata</uri-path>
    <uri-query>
      <parameter1>value1</parameter1>
      <parameter2>value2</parameter2>
    </uri-query>
</http-header-request>

生成されるクエリ

http://localhost:80/test/selectdata?parameter1=value1&parameter2=value2

注意事項

uri-query要素直下に指定した値だけ有効になり，属性を指定しても無視されます。

階層構造を持つ要素を指定した場合，その要素が生成するクエリの値については保証しません。

同一のキー名を複数定義した場合の出現順は保証しません。

「http://user:password@example.jp:80/httprcp1/op1」のように，URIにベーシック認証のアカウント情報が含まれていても，ベーシック認証情報として使用されません。

要求電文（ヘッダ）でクエリを指定する場合，クエリのキー名称にはNCNameとして不正な文字を使用できません。

(3)　HTTPリクエストヘッダ

HTTPリクエストヘッダは，要求電文（ヘッダ）のhttp-header要素（any型），およびHTTPアダプタ実行環境プロパティファイル（またはHTTPアダプタ実行環境共通プロパティファイル）のadphttp.request.header.userdef.<追番>プロパティによって任意の拡張ヘッダを指定できます。

要素名はローカル名の部分だけ使用するため，任意の名前空間を指定できます。

要求電文（ヘッダ）とHTTPアダプタ実行環境プロパティファイル（またはHTTPアダプタ実行環境共通プロパティファイル）で別々のヘッダを指定した場合，要求電文（ヘッダ）の指定だけが有効になります。HTTPアダプタ実行環境プロパティファイルで指定したヘッダが要求電文（ヘッダ）の指定に追加されることはありません。

(a)　HTTPヘッダの指定例

HTTPヘッダの指定例を次に示します。

要求電文（ヘッダ）の指定例

<http-header-request>
  <http-header>
    <X-PRIORITY>HIGH</X-PRIORITY>
    <X-DOCUMENT-ID>12345-67890</X-DOCUMENT-ID>
  </http-header>
</http-header-request>

HTTPアダプタ実行環境プロパティファイルの指定例

adphttp.request.header.userdef.1=X-PRIORITY:HIGH
adphttp.request.header.userdef.2=X-DOCUMENT-ID:12345-67890

生成されるHTTPリクエストヘッダ

X-PRIORITY:HIGH
X-DOCUMENT-ID:12345-67890

(b)　特殊なHTTPヘッダの指定

次に示すHTTPヘッダは，要求電文（ヘッダ）のhttp-header要素，およびHTTPアダプタ実行環境プロパティファイル（またはHTTPアダプタ実行環境共通プロパティファイル）のadphttp.request.header.userdef.<追番>プロパティに指定しても無視されます。

表2‒84　特殊なHTTPヘッダの指定方法

ヘッダフィールド名

説明

Content-Type

次の個所で指定します。

要求電文（ヘッダ）

http-header-Content-Type要素

HTTPアダプタ実行環境プロパティファイル，HTTPアダプタ実行環境(共通)プロパティファイル

adphttp.request.header.content-typeプロパティ，adphttp.request.header.content-type.charsetプロパティ

フォームデータ送信の場合はapplication/x-www-form-urlencoded固定，複数ファイルデータ送信の場合はmultipart/form-data固定となります。

Cookie

次の個所で指定します。

要求電文（ヘッダ）

Cookies要素

詳細は，「2.16.5　HTTPアダプタを使用したCookie情報の引き継ぎ」を参照してください。

Proxy-Authorization

プロキシサーバへの接続に使用するProxy-AuthorizationヘッダはJavaVMのシステムプロパティで設定します。

詳細は，「2.16.6　プロキシサーバを経由した通信」を参照してください。

Connection

Connection: Keep-Aliveなど，コネクション制御に関するヘッダはJavaVMのシステムプロパティで設定します。詳細は，「2.16.7　コネクション継続（Keep-Alive）を使用した通信」を参照してください。

Content-Length

HTTPアダプタが自動的に設定します。

Accept-Encoding

HTTPアダプタが自動的に設定します。

Authorization

次の個所で指定します。

要求電文（ヘッダ）

http-header-Authorization要素

HTTPアダプタ実行環境プロパティファイル，HTTPアダプタ実行環境(共通)プロパティファイル

adphttp.request.header.authorizationプロパティ，adphttp.request.header.authorization.typeプロパティ

詳細は，「2.16.15　WWW認証を使用したセキュアな接続」を参照してください。

Content-Disposition

Content-Dispositionヘッダには，nameおよびfilename属性だけ指定してください。

複数のファイルデータを送信する場合，Content-Dispositionヘッダに送信するリソースのファイル名を指定します。

HTTPアダプタでは，次の形式でメッセージを作成します。

Content-Disposition: <Dispositionタイプ>; name=<パートID>; filename=<ファイル名>

詳細は，「2.15.5(2)(b) Content-Disposition」を参照してください。

(c)　注意事項

HTTPヘッダ指定時の注意事項を次に示します。

http-header要素に指定した値は，http-header要素直下の値だけ有効になり，属性を指定しても無視されます。

http-header要素に階層構造を持つ要素を指定した場合，その要素が生成するヘッダの値については保証しません。

http-header要素直下のリクエストヘッダは1,024個まで指定できます。1,025以上の要素を指定した場合は動作を保証しません。

http-header要素でHTTPヘッダを指定する場合，ヘッダフィールド名にはNCNameとして不正な文字を使用できません。

HTTPアダプタではHTTPヘッダの記述順を保証しません。また，同名のヘッダフィールドが複数あった場合，そのままHTTPリクエストに設定されます。

要求電文（ヘッダ），HTTPアダプタ実行環境プロパティファイル，またはHTTPアダプタ実行環境共通プロパティファイルのどれにもHTTPヘッダおよびContent-Typeヘッダを指定しなかった場合，送信内容に応じて自動的にContent-Typeヘッダが付与される場合があります。

拡張ヘッダ以外のヘッダフィールド名を指定した場合の動作は保証されません。拡張ヘッダ以外のヘッダフィールド名を指定する場合は，十分に動作検証をした上で利用してください。

(4)　HTTPリクエストボディ

(a)　データ種別

HTTPリクエストボディで送信するデータ種別は次の中から選択できます。

フォームデータ（ノーマルモード）

要求電文（ボディ）に指定したデータをフォームデータに変換して，HTTPリクエストボディに設定します。

要求電文（ボディ）（パススルーモード）

要求電文（ボディ）で指定したデータをそのままHTTPリクエストボディに設定します。

単一ファイルのファイルデータ送信（単一パート型）

ファイルの内容がHTTPリクエストボディに設定されます。

複数ファイルのファイルデータ送信（マルチパート型）

複数のファイルのデータをマルチパート型で送信できます。マルチパートの一部に要求電文（ボディ）を組み合わせることもできます。

データなし

HTTPリクエストボディが設定されません。GETメソッドなど，HTTPリクエストボディを送信しない場合に選択します。

HTTPリクエストボディのデータ種別は，要求電文（ヘッダ）のbinding要素，およびHTTPアダプタ実行環境プロパティファイル（またはHTTPアダプタ実行環境共通プロパティファイル）のadphttp.request.part.message.bindingプロパティで指定できます。

ただし，要求電文（ヘッダ）にfiles要素が存在する場合は，上記の要素（またはプロパティ）が指定されていてもファイルデータとして扱われます。同様に，HTTPアダプタ実行環境プロパティファイル（またはHTTPアダプタ実行環境共通プロパティファイル）のadphttp.request.part.file.<追番>.input-folder-nameプロパティが存在する場合は，adphttp.request.part.message.bindingプロパティが指定されていてもファイルデータとして扱われます。

(b)　フォームデータ（ノーマルモード）

ノーマルモードでフォームデータを送信する場合，サービスプラットフォームが提供するフォームデータ用電文フォーマットをカスタマイズして指定します。

フォームデータの指定例を次に示します。

フォームデータ用電文フォーマットのカスタマイズの例

（変更前）

<xsd:complexType name="http-body-form-data-type">
   <xsd:sequence>
      <xsd:any namespace="##any" processContents="skip" minOccurs="0" maxOccurs="unbounded" />
   </xsd:sequence>
</xsd:complexType>

（変更後）

<xsd:complexType name="http-body-form-data-type">
   <xsd:sequence>
      <xsd:element name="parameter1" type="xsd:string" minOccurs="0"/>
      <xsd:element name="parameter2" type="xsd:string" minOccurs="0"/>
   </xsd:sequence>
</xsd:complexType>

要求電文（ボディ）の指定例

   <http-body-form-data>
      <parameter1>value1<parameter1>
      <parameter2>value2<parameter2>
   </http-body-form-data>

生成されるHTTPリクエストヘッダおよびリクエストボディ

Content-Type: application/x-www-form-urlencoded

parameter1=value1&parameter2=value2

指定したフォームデータはURLエンコードされます。デフォルトの文字コードはUTF-8です。

注意事項

http-body-formdata要素に指定した値は，http-body-formdata要素直下の値だけ有効になり，属性を指定しても無視されます。

http-body-formdata要素に階層構造を持つ要素を指定した場合，その要素が生成するフォームデータの値については保証しません。

HTTPアダプタではフォームデータの出現順を保証しません。フォームデータの出現順は要求電文（ボディ）の指定順と必ずしも一致するとは限りません。

http-body-formdata要素に指定した値はContent-Typeヘッダのcharset属性に指定した文字コードでURLエンコードされます。このため，必ずURLエンコードをする前の形式で指定してください。

http-body-formdata要素でフォームデータを指定する場合，フォームデータのキー名称にはNCNameとして不正な文字を使用できません。

(c)　要求電文（ボディ）（パススルーモード）

パススルーモードで要求電文（ボディ）で指定したデータをそのままHTTPリクエストボディに設定する場合，送信するHTTPリクエストボディの形式に合わせて要求電文（ボディ）の電文フォーマットを作成します。

(d)　単一ファイルのファイルデータ送信（単一パート型）

作業フォルダまたは共通フォルダ内の1ファイルを対象のサーバに送信できます。

複数ファイルを送信する場合は，「(e) 複数ファイルのファイルデータ送信（マルチパート型）」を参照してください。

作業フォルダとは，HTTP受付またはFTP受付がリクエストごとにHCSCサーバ内に作成する一時フォルダです。作業フォルダは，作成した受付から呼び出されたビジネスプロセス以外からは参照できません。

共通フォルダとは，システム構築時にユーザが作成する任意のフォルダです。複数のビジネスプロセスで共通して利用するファイルを格納することができます。また，共通フォルダの場合，配下のサブフォルダを使用できます。

ファイルデータを送信する場合，要求電文（ヘッダ），およびHTTPアダプタ実行環境プロパティファイル（またはHTTPアダプタ実行環境共通プロパティファイル）でファイルデータに関する情報を指定します。プロパティファイルで指定する場合は共通フォルダだけ使用できます。

ファイルデータの指定個所を次に示します。

表2‒85　単一ファイルデータの指定方法

指定方法

項目

指定個所

要求電文（ヘッダ）

作業フォルダのリクエストID

request-id要素

パート型※1

http-body要素内のstyle要素

使用するフォルダ

input-folder-name要素のcommon属性

共通フォルダ定義名

input-folder-name要素

送信対象のファイル名※

local-file-name要素

送信データのContent-Typeヘッダフィールドのメディアタイプ

http-header-Content-Type要素

送信データのContent-Typeヘッダフィールドの文字コード属性

http-header-Content-Type要素のcharset属性

HTTPアダプタ実行環境プロパティファイル，HTTPアダプタ実行環境共通プロパティファイル

作業フォルダのリクエストID

−

ファイルデータ数

−

使用するフォルダ

−

共通フォルダ定義名

adphttp.request.part.file.<追番>.input-folder-name※2

送信対象のファイル名※³

adphttp.request.part.file.<追番>.local-file-name※2

送信データのContent-Typeヘッダフィールドのメディアタイプ

adphttp.request.header.content-type

送信データのContent-Typeヘッダフィールドの文字コード属性

adphttp.request.header.content-type.charset

（凡例）

−：該当する指定個所はありません。

注※1

単一のファイルデータを送信する場合は，省略または「single」を指定します。

注※2

1以外の<追番>のプロパティが指定されている場合，該当するプロパティが解析されます。ただし，リクエスト時には<追番>が1のプロパティがファイルデータとして使用されます。

注※3

サブフォルダを使用する場合，共通フォルダルートからファイル名までの相対パスを指定してください。

単一ファイルのデータ送信の例を次に示します。

図2‒159　単一ファイルのデータ送信の例（共通フォルダを使用する場合）

ファイルデータを送信する場合，HTTPアダプタに渡された要求電文（ボディ）の値は無視されます。このため，指定する要求電文（ボディ）の電文フォーマットには，空のボディデータを格納するためのファイルデータ用電文フォーマットを使用します。

注意事項

要求電文（ヘッダ）でfiles要素だけ指定して下位のfile要素を1つも指定しなかった場合，HTTPリクエストボディが空の状態でHTTPリクエストが送信されます。

/http-header-request/http-part/files/file要素が複数回出現した場合，すべてのfile要素が解析されます。ただし，リクエスト時には最初に出現した要素の値をファイルデータとして使用されます。

ファイルデータを送信する場合，読み込み対象のファイルが格納されたフォルダまたはファイルの指定がない場合や，指定されたフォルダおよびファイルが存在しない場合はエラーとなります。

次に，共通フォルダのサブフォルダを使用して，HTTPリクエストでファイルを送信する場合の指定例を示します。

HTTPアダプタ要求電文（ヘッダ）の/http-header-request/http-part/files/file/local-file-name，またはHTTPアダプタ実行環境プロパティファイルのadphttp.request.part.file.<追番>.local-file-nameに共通フォルダルートからファイル名までの相対パスを指定します。

要求電文（ヘッダ）指定例

<http-header-request>
      ：
  <input-folder-name common="true">com</input-folder-name>
  <local-file-name>/folder1/folder2/file1.doc</local-file-name>
      ：
</http-header-request>

HTTPアダプタ実行環境（共通）プロパティファイルの指定例

adphttp.request.part.file.<追番>.input-folder-name=com
adphttp.request.part.file.<追番>.local-file-name=/folder1/folder2/file1.doc

(e)　複数ファイルのファイルデータ送信（マルチパート型）

作業フォルダまたは共通フォルダ内の複数のファイルを，マルチパート型の一部としてリクエストボディに設定し，対象のサーバに送信できます。

送信するファイルデータの情報は，要求電文（ヘッダ），またはHTTPアダプタ実行環境（共通）プロパティファイルで指定します。

注意事項

複数ファイルのファイルデータを送信する場合，パートが1つ以上設定されている必要があります。パートが設定されていない場合，エラーメッセージが出力され，リクエストに失敗します。

要求電文（ヘッダ）での複数ファイルデータの指定

要求電文（ボディ）をマルチパート型の1パートとして扱います。要求電文（ボディ）をマルチパート型の1パートとして扱う場合，要求電文（ボディ）リクエストボディへのバインド方法（adphttp.request.part.message.bindingプロパティ）には「raw」を指定します。「raw」以外を指定した場合，要求電文（ボディ）はマルチパート型の1パートとして扱われません。ファイルデータだけを送信したいときは，ボディ要求電文の割当変数に，製品が提供する空データ用フォーマットを指定します。

また，/http-header-request/http-part/files/file要素ごとにファイル単位で，共通フォルダと作業フォルダのそれぞれに格納したファイルを指定できます。

表2‒86　複数ファイルデータの指定方法（要求電文（ヘッダ））

項目

指定個所

説明

作業フォルダのリクエストID

/http-header-request/request-id

作業フォルダ用のリクエストIDを設定します。作業フォルダを使用しない場合は，省略できます。

HTTPボディのパート型

/http-header-request/http-body/style

HTTPボディの型を指定します。マルチパート型の場合は，「multipart/form-data」を指定します。

Content-Dispositionヘッダのパート名

/http-header-request/http-part/message/part-id

要求電文（ボディ）をマルチパート型の1パートとして扱う場合，該当するパートに設定するContent-Dispositionヘッダのname属性の値を指定します。

「csc_http_adapter_telegram_name」で始まる値は，設定できません。設定した場合の動作は保証されません。

次のすべての条件に当てはまる場合に，この要素値に「csc_http_adapter_telegram_name_1」が指定されたと見なします。

リクエストボディのパート形式が「multipart/form-data」である

要求電文（ボディ）のリクエストボディへのバインド方法（adphttp.request.part.message.bindingプロパティ）が「raw」である

この要素およびHTTPアダプタ実行環境プロパティファイルに，「adphttp.request.part.message.part-id」が設定されていない

Content-Typeヘッダの文字コード属性

/http-header-request/http-part/message/Content-Type/@charset

要求電文（ボディ）をマルチパート型の1パートとして扱う場合，該当するパートに設定するContent-Typeヘッダのcharset属性の値を指定します。

Content-Typeヘッダのメディアタイプ

/http-header-request/http-part/message/Content-Type

要求電文（ボディ）をマルチパート型の1パートとして扱う場合，該当するパートに設定するContent-Typeヘッダのメディアタイプを指定します。

Content-Dispositionヘッダの送信対象のファイル名

/http-header-request/http-part/files/file/part-id

送信対象ファイルをマルチパート型の1パートとして扱う場合，該当するパートに設定するContent-Dispositionヘッダのname属性の値を指定します。

「csc_http_adapter_file_name」で始まる値は設定できません。設定した場合の動作は保証されません。

次のすべての条件に当てはまる場合に，この要素値に「csc_http_adapter_file_name_<1から始まる連番>」が設定されたと見なします。連番は製品内で採番されます。

リクエストボディのパート形式が「multipart/form-data」である

要求電文（ヘッダ）の「/http-header-request/http-part/files/file」要素が出現する

要求電文（ヘッダ）の「/http-header-request/http-part/files/file/part-id」要素がない，または空要素である

使用するフォルダ

/http-header-request/http-part/files/file/input-folder-name/@common

共通フォルダを使うか，作業フォルダを使うかを指定します。

true：共通フォルダを使用する。

false：作業フォルダを使用する。

共通フォルダ論理名

/http-header-request/http-part/files/file/input-folder-name

共通フォルダを使う場合の共通フォルダ論理名を指定します。

送信対象のファイル名

/http-header-request/http-part/files/file/local-file-name

送信対象のファイル名を指定します。

共通フォルダの場合，共通フォルダルート配下のファイル名を指定します。作業フォルダの場合，作業フォルダ直下のファイル名を指定します。

Content-Dispositionヘッダの送信対象のファイル名

/http-header-request/http-part/files/file/file-name

送信対象ファイルをマルチパート型の1パートとして扱う場合，該当するパートに設定するContent-Dispositionヘッダのfilename属性の値を指定します。

Content-Typeヘッダの文字コード属性

/http-header-request/http-part/files/file/Content-Type/@charset

送信対象ファイルをマルチパート型の1パートとして扱う場合，該当するパートに設定するContent-Typeヘッダのcharset属性の値を指定します。

Content-Typeヘッダメディアタイプ

/http-header-request/http-part/files/file/Content-Type

送信対象ファイルをマルチパート型の1パートとして扱う場合，該当するパートに設定するContent-Typeヘッダのメディアタイプを指定します。

送信データのContent-Typeヘッダフィールドのメディアタイプ

/http-header-request/http-header-Content-Type

送信データのContent-Typeヘッダフィールドのメディアタイプを指定します。

送信データのContent-Typeヘッダフィールドの文字コード属性

/http-header-request/http-header-Content-Type/@charset

送信データのContent-Typeヘッダフィールドのcharset属性値を指定します。

HTTPアダプタ実行環境（共通）プロパティファイルでの複数ファイルデータの指定

HTTPアダプタ実行環境（共通）プロパティファイルで指定する際に使用するプロパティを次に示します。

表2‒87　複数ファイルデータの指定方法（HTTPアダプタ実行環境（共通）プロパティファイル）

項目

指定個所

説明

リクエストボディのパート型

adphttp.request.body.style

リクエストボディのパート型を指定します。

リクエストボディのパートID

adphttp.request.part.message.part-id

リクエストボディのパートに付与するIDを指定します。

各パートのヘッダのContent-Dispositionのnameパラメタの値として使用します。

「csc_http_adapter_telegram_name」で始まる値は，設定できません。設定した場合の動作は保証されません。

次のすべての条件に当てはまる場合，この定義値に「csc_http_adapter_telegram_name_1」が指定され，「adphttp.request.part.message.part-id」の値に設定されたと見なされます。

リクエストボディのパート形式が「multipart/form-data」である

要求電文（ボディ）のリクエストボディへのバインド方法（adphttp.request.part.message.bindingプロパティ）が「raw」である

この定義が設定されていない

リクエストボディのContent-Typeの文字コード

adphttp.request.part.message.content-type.charset

リクエストボディのパートのContent-Typeの文字コードを指定します。

各パートのヘッダのContent-Typeのcharsetパラメタとして使用します。

リクエストボディのContent-Typeの値

adphttp.request.part.message.content-type

リクエストボディのパートのContent-Typeの値を指定します。

各パートのヘッダのContent-Typeの値として使用します。

ファイルのパートID

adphttp.request.part.file.<追番>.part-id※

ファイルのパートに付与するIDを指定します。

マルチパート形式時に各パートのヘッダのContent-Dispositionのnameパラメタの値として使用します。

「csc_http_adapter_file_name」で始まる値は，設定できません。設定した場合の動作は保証されません。

次のすべての条件に当てはまる場合，この定義値に「csc_http_adapter_file_name_<1から始まる連番>」が設定されたと見なされます。連番は製品内で採番されます。

「adphttp.request.body.style」の値に「multipart/form-data」を指定した

「adphttp.request.part.file.<追番>.input-folder-name」または「adphttp.request.part.file.<追番>.input-folder-name」が設定されている

「adphttp.request.part.file.<追番>.part-id」が未定義，または未設定

共通フォルダ論理名

adphttp.request.part.file.<追番>.input-folder-name※

共通フォルダ論理名を指定します。

送信対象のファイル名

adphttp.request.part.file.<追番>.local-file-name※

送信対象のファイル名を指定します。

共通フォルダルート配下のファイル名を指定する。

送信時のファイル名

adphttp.request.part.file.<追番>.file-name※

送信時のファイルの名称を指定します。

各パートのヘッダのContent-Dispositionのfilenameパラメタの値として使用します。

ファイルのContent-Typeの文字コード

adphttp.request.part.file.<追番>.content-type.charset※

ファイルのパートのContent-Typeの文字コードを指定します。

各パートのヘッダのContent-Typeのcharsetパラメタとして使用します。

ファイルのContent-Typeの値

adphttp.request.part.file.<追番>.content-type※

ファイルのパートのContent-Typeの値を指定します。

各パートのヘッダのContent-Typeの値として使用します。

送信データのContent-Typeヘッダフィールドのメディアタイプ

adphttp.request.header.content-type

送信データのContent-Typeヘッダフィールドのメディアタイプを指定します。

送信データのContent-Typeヘッダフィールドの文字コード属性

adphttp.request.header.content-type.charset

送信データのContent-Typeヘッダフィールドのcharset属性値を指定します。

注※

<追番>は1から始まる連番です。連番は次の規則で設定されます。

・数値の前に0は付けない（001など）。

・連続しない数でもよい（例：1，3，5）。

・プロパティキーの一意性を示す。参照順は関係しない。

・プロパティの組で，<追番>は同一の値となる。

複数ファイルのデータ送信の例

共通フォルダを使用した場合の複数ファイルのデータ送信の例を次に示します。

図2‒160　複数ファイルのデータ送信の例（共通フォルダを使用する場合）

2.16.4　HTTPレスポンスと応答電文の関係

ここでは，HTTPアダプタのHTTPレスポンスから応答電文への変換の仕組みについて説明します。

サーバから返されたHTTPレスポンスは，次の要素ごとに処理されて，応答電文に格納されます。

ステータスライン

HTTPレスポンスヘッダ

HTTPレスポンスボディ

各項目の詳細について説明します。

なお，ここで説明する電文の例では，名前空間接頭辞を省略しています。

(1)　ステータスライン

HTTPレスポンスのステータスラインの要素は次のように応答電文に格納されます。

表2‒88　ステータスラインと応答電文の対応

ステータスラインの要素

応答電文との対応

HTTPバージョン

応答電文には格納されません。

ステータスコード

応答電文（ヘッダ）のstatus-code要素に格納されます。※

理由フレーズ

応答電文（ヘッダ）のreason-phrase要素に格納されます。

注※

200以外のステータスコードはデフォルトでシステム例外となります。ただし，200以外も正常処理，またはフォルト応答としてフォルトを返すように設定することもできます。詳細は，「(4)　ステータスコードの正常処理またはフォルト処理の設定」を参照してください。

(2)　HTTPレスポンスヘッダ

HTTPアダプタで受信したすべてのHTTPヘッダは応答電文（ヘッダ）のhttp-header要素に格納されます。同一名称のHTTPヘッダを重複して受信した場合はそのまま複数の要素として格納されます。

HTTPレスポンスヘッダの例と対応する応答電文（ヘッダ）を次に示します。

HTTPレスポンスヘッダの例

Content-Length: 51
Content-Type: image/gif
Last-Modified: Fri, 21 Jul 2006 07:51:32 GMT
Accept-Ranges: bytes
Server: Microsoft-IIS/6.0
Date: Mon, 16 Jul 2012 09:43:57 GMT

対応する応答電文（ヘッダ）

<http-header-response>
  <http-header>
    <Content-Length>51</Content-Length>
    <Content-Type>image/gif</Content-Type>
    <Last-Modified>Fri, 21 Jul 2006 07:51:32 GMT</Last-Modified>
    <Accept-Ranges>bytes</Accept-Ranges>
    <Server>Microsoft-IIS/6.0</Server>
    <Date>Mon, 16 Jul 2012 09:43:57 GMT</Date>
  </http-header>
</http-header-response>

注意事項

HTTPヘッダの出現順がそのままXML要素の出現順になるとは限りません。なお，受信したHTTPヘッダのヘッダフィールド名にNCNameとして不正な文字が使用されていた場合，警告メッセージが出力され，該当するヘッダフィールドをスキップして処理が続行されます。

HTTPレスポンスヘッダのContent-TypeヘッダとContent-Dispositionヘッダは応答電文（ヘッダ）の次の要素にも格納されます。

表2‒89　Content-TypeヘッダおよびContent-Dispositionヘッダと応答電文（ヘッダ）の対応

HTTPレスポンスヘッダ

属性

応答電文（ヘッダ）に格納される要素

Content-Type

−

http-header-Content-Type要素にContent-Typeヘッダフィールドのメディアタイプ部分(*/*)が格納されます。

charset

http-header-Content-Type要素のcharset属性に属性値が格納されます。charset属性の指定がない場合は格納されません。

Content-Disposition

−

HTTPレスポンスで指定があった場合，HTTPレスポンスはファイルデータとして扱われます。Dispositionタイプの値は無視されます。

filename

file要素の子要素のfilename要素として値が格納されます。指定値はデコードなどの変換は行われません。

（凡例）

−：該当しません。

応答電文（ヘッダ）に格納される要素は次に示す値だけです。これ以外の値はすべて無視されます。

Content-Typeヘッダのメディアタイプ

Content-Typeヘッダのcharset属性

Content-Dispositionヘッダのfilename属性

注意事項

応答電文（ヘッダ）を省略した場合，HTTPレスポンスから応答電文（ヘッダ）に格納された要素はビジネスプロセスで使用できなくなります。

(3)　HTTPレスポンスボディ

HTTPレスポンスボディは，HTTPレスポンスヘッダにContent-Dispositionヘッダが指定されているかどうかによって次のように扱われます。

ファイルデータ

HTTPレスポンスヘッダにContent-Dispositionヘッダが指定されている場合，HTTPレスポンスボディに指定された任意のデータがファイルに出力されます。出力ファイルのメタ情報は応答電文（ヘッダ）に格納されます。

ローデータ（パススルーモード）

HTTPレスポンスヘッダにContent-Dispositionヘッダが指定されていない場合，HTTPレスポンスボディに指定された任意のデータがそのまま応答電文（ボディ）に格納されます。応答電文（ボディ）の電文フォーマットはユーザが作成します。

(a)　ファイルデータ

ファイルデータを受信する場合，出力先のディレクトリを要求電文（ヘッダ），HTTPアダプタ実行環境プロパティファイル，またはHTTPアダプタ実行環境共通プロパティファイルで指定する必要があります。プロパティファイルで指定する場合は共通フォルダだけ使用できます。

Content-Typeが「multipart/form-data」，または「multipart/mixed」の場合，HTTPレスポンスボディを各パートに分割し，各パートの内容をそれぞれファイルとして出力します。ファイルは，指定した1つの出力ディレクトリに出力されます。複数の出力先フォルダは，選択できません。

Content-Typeが「multipart/form-data」または「multipart/mixed」で，HTTPレスポンスボディに1つもパートが含まれていない場合は，リクエストがエラーとなります。

各パートのMIMEタイプが省略されている場合は，該当するパートの解析処理では「text/plain」が指定されたと見なして処理が行われます。

要求電文（ヘッダ），HTTPアダプタ実行環境プロパティファイル，およびHTTPアダプタ実行環境共通プロパティファイルでのファイルデータの指定個所を次に示します。

表2‒90　ファイルデータの指定個所

指定方法

指定する要素またはプロパティ

説明

要求電文（ヘッダ）

request-id要素

作業フォルダ用のリクエストIDを設定します。作業フォルダを使用しない場合は省略できます。

output-folder-name要素のcommon属性

ファイルデータの出力先として共通フォルダまたは作業フォルダのどちらかを指定します。

output-folder-name要素

ファイルデータを出力する共通フォルダ定義名を指定します。作業フォルダを使用する場合は指定を省略できます。

output-sub-folder要素

ファイルデータの出力先として共通フォルダのサブフォルダを使用する場合に，共通フォルダルートからサブフォルダまでの相対パスを指定します。

HTTPアダプタ実行環境プロパティファイル，HTTPアダプタ実行環境共通プロパティファイル

adphttp.request.output-folder-nameプロパティ

ファイルデータを出力する共通フォルダ定義名を指定します。

adphttp.request.output-sub-folderプロパティ

ファイルデータの出力先として共通フォルダのサブフォルダを使用する場合に，共通フォルダルートからサブフォルダまでの相対パスを指定します。

要求電文（ヘッダ），HTTPアダプタ実行環境プロパティファイル，およびHTTPアダプタ実行環境共通プロパティファイルのどれにも出力先ディレクトリの指定がなかった場合はエラーになります。

応答電文（ヘッダ）には，出力先ディレクトリおよび出力ファイル名などの情報が格納されます。

応答電文（ヘッダ）に格納されるファイル情報を次に示します。

表2‒91　応答電文（ヘッダ）に格納されるファイル情報

応答電文（ヘッダ）の要素

説明

output-folder-name要素のcommon属性

ファイルデータを出力したフォルダの種類として共通フォルダまたは作業フォルダのどちらかが格納されます。

output-folder-name要素

ファイルデータを出力したフォルダの定義名が格納されます。共通フォルダに出力した場合は共通フォルダ定義名が格納されます。作業フォルダに出力した場合は，常に空（空文字列）になります。

part-id要素

Content-Dispositionヘッダのname属性の値が格納されます。パートを分割したときのパート識別子として使用します。

file-name要素

HTTPレスポンスに指定されたContent-Dispositionヘッダのfilename属性の値が格納されます。ただし，HTTPアダプタでデコードなどの処理はしません。filename属性が省略された場合は要素が生成されません。

local-file-name要素

出力先フォルダに保存した中間ファイルの名称が格納されます。

Content-Type要素のcharset属性

各パートのContent-Typeのcharset属性が格納されます。charset属性の設定がなければ，属性はありません。

Content-Type要素

各パートのMIMEタイプが格納されます。

省略した場合，Content-Typeヘッダは指定されません。

注1

HTTPアダプタが共通フォルダに出力するファイル名称は，システム内で採番した一意のIDを使用したファイル名となります。次の点に注意してください。

一意のIDの生成にサーバのタイムスタンプを利用しているため，時刻の戻りが発生しないようにしてください。NTPソフトウェアを使用して時刻補正をする場合は，必ずslewモードを使用するようにしてください。時刻補正をする場合の注意事項については，マニュアル「サービスプラットフォームシステム構築・運用ガイド」の「1.4　運用方針の決定」を参照してください。

一意のIDの生成にHCSCサーバ名とクラスタ名を使用しているため，同一の共通フォルダに複数のHCSCサーバからアクセスする場合は，これらの名称の組み合わせが重複しないようにシステムを設計してください。

HCSCサーバをロードバランスクラスタ構成やHAクラスタ構成にする場合にも，各HCSCサーバのHCSCサーバ名やクラスタ名の組み合わせが重複しないようにする必要があります。

例：HCSCサーバ1のHCSCサーバ名=HCSC1，クラスタ名=CLS1の場合

・HCSCサーバ2のHCSCサーバ名=HCSC1，クラスタ名=CLS1 → 重複あり

・HCSCサーバ2のHCSCサーバ名=HCSC2，クラスタ名=CLS1 → 重複なし

・HCSCサーバ2のHCSCサーバ名=HCSC1，クラスタ名=CLS2 → 重複なし

・HCSCサーバ2のHCSCサーバ名=HCSC2，クラスタ名=CLS2 → 重複なし

上記の条件を満たすことができない場合は，作業フォルダだけを使用してください。共通フォルダを使用した場合，ファイル名の重複が発生してファイルが上書きされるおそれがあります。

注2

ファイルデータの出力先に共通フォルダを使用する場合は，HTTPアダプタだけが利用する専用の共通フォルダを必ず使用してください。ほかの用途で使用する共通フォルダと共用しないでください。

HTTPアダプタを利用したファイル受信の例を次に示します。

図2‒161　HTTPアダプタを利用したファイル受信の例（共通フォルダを使用する場合）

次に，共通フォルダのサブフォルダを使用して，HTTPレスポンスでファイルをダウンロードする場合の指定例を示します。

HTTPアダプタ要求電文（ヘッダ）の/http-header-request/output-sub-folder，またはHTTPアダプタ実行環境プロパティファイルのadphttp.request.output-sub-folderに共通フォルダルートからサブフォルダまでの相対パスを指定します。

要求電文（ヘッダ）指定例

<http-header-request>
     ：
  <output-folder-name common="true">com</output-folder-name>
  <output-sub-folder>/folder1/folder2</output-sub-folder>
     ：
</http-header-request>

HTTPアダプタ実行環境（共通）プロパティファイルの指定例

adphttp.request.output-folder-name=com
adphttp.request.output-sub-folder=/folder1/folder2

HTTPアダプタ応答電文（ヘッダ）の/http-headerresponse/http-part/files/file/local-file-nameに共通フォルダルートからファイル名までの相対パスが設定されます。

応答電文（ヘッダ）の内容

<http-header-response>
      ：
  <output-folder-name common="true">com</output-folder-name>
      ：
    <file-name>file1.doc</file-name>
    <local-file-name>folder1/folder2/SRV1CLS1----HCSC1---0000000000001000d6j93dx74g0001</local-file-name>
      ：
</http-header-response>

(b)　ローデータ（パススルーモード）

HTTPレスポンスボディのデータをHTTPアダプタの応答電文（ボディ）にそのまま格納する場合，応答電文（ボディ）の電文フォーマットはユーザが任意に作成する必要があります。

必要に応じて，受信したデータをJava呼出アクティビティやコンポーネント共通UOCなどで加工することもできます。

Content-Typeが「multipart/form-data」または「multipart/mixed」の場合は，応答電文（ボディ）にデータを格納できません。

(4)　ステータスコードの正常処理またはフォルト処理の設定

HTTPアダプタでは，HTTPレスポンス時に指定したステータスコードを正常処理またはフォルト処理として扱うように設定することができます。

どのステータスコードを正常処理およびフォルト処理として扱うかはHTTPアダプタ定義ファイルで設定できます。

表2‒92　ステータスコードの処理に関する設定

プロパティ名

説明

adphttp.response-code.normal

正常処理として扱うステータスコードを正規表現で指定します。デフォルトは200です。

adphttp.response-code.fault

フォルト処理として扱うステータスコードを正規表現で指定します。デフォルトは空文字列です。

なお，ステータスコードが正規表現に完全一致しない場合は，HTTPレスポンスでステータスコードが返らないため，システム例外として処理されます。

注意事項

フォルト処理として扱う場合，ビジネスプロセス上でキャッチできますが，再実行ができなくなります。このため，フォルト処理を設定する場合はビジネスプロセスへの影響を考慮してから設定してください。

ステータスコードの処理フローを次の図に示します。

図2‒162　ステータスコードの処理フロー

(5)　レスポンスサイズの制限の設定

HTTPアダプタでは，非常に大きなサイズのHTTPレスポンスを受信した場合のメモリ不足およびディスクの圧迫を制御するために，HTTPレスポンスボディのサイズ閾値を設定して，受信サイズを制限することができます。

HTTPレスポンスボディのサイズ閾値はHTTPアダプタ定義ファイルで設定できます。設定するプロパティを次に示します。

表2‒93　HTTPレスポンスボディのサイズ閾値の設定

項目

プロパティ名

パススルーモードでHTTPレスポンスを応答電文（ボディ）に設定する際に許容するデータの最大サイズ

adphttp.data-size-limit.body-message

HTTPレスポンスをファイルに書き出す際に許容するデータの最大サイズ

adphttp.data-size-limit.file

閾値を設定したあとは，HTTPアダプタでは，次の順序でレスポンスサイズの判定をしています。

HTTPヘッダにContent-Lengthヘッダがある場合は，ヘッダフィールド値が閾値を超えていないか判定をします。閾値を超えている場合は，HTTPレスポンスボディを受信しないで，ただちにシステム例外となります。

HTTPヘッダにContent-Lengthヘッダがない場合（チャンクエンコーディングされたデータを受信する場合など）は，HTTPレスポンスボディの受信処理をし，閾値を超えた時点で受信処理を打ち切り，システム例外となります。

なお，マルチパート型の受信処理の場合，上限値を超えるバイト数のファイルを受信した時点でシステム例外となります。例外が発生するまでの間に受信したファイルは出力されます。

(6)　不完全受信ファイルの自動削除

HTTPアダプタでファイルを受信中に，ネットワーク障害やI/Oエラー，データサイズ制限の超過などが発生した場合，共通フォルダや作業フォルダに不完全な受信ファイルが生成されますが，この不完全な受信ファイルを自動的に削除することができます。

この機能はHTTPアダプタ定義ファイルのadphttp.auto-delete-incomplete-fileプロパティで設定できます。

不完全な受信ファイルの削除に失敗した場合は，メッセージログ（KDEC81403-W）が出力されます。なお，この場合，削除に失敗したファイルは手動で削除する必要があります。削除方法については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「5.4.20　作業フォルダを削除する」，および「5.4.22　共通フォルダ内のファイルを削除する」を参照してください。

なお，マルチパート型のファイルを受信する場合，受信途中の不完全なファイルが作成された時点で受信処理は中断し，受信途中の不完全なファイルを削除します。受信途中の不完全なファイルが作成されるまでの間に受信したファイルは削除しないため，削除が必要な場合は手動で削除してください。

2.16.5　HTTPアダプタを使用したCookie情報の引き継ぎ

HTTPアダプタでは，ビジネスプロセスから複数のサービスを呼び出す場合に，サービス呼び出し間のセッション維持（Cookie情報の引き継ぎ）ができます。

HTTPアダプタを利用したCookie情報の引き継ぎの概要を次の図に示します。

図2‒163　 HTTPアダプタを利用したCookie情報の引き継ぎ

HTTPアダプタのCookie情報の引き継ぎについて，上図を例に説明します。なお，ここで説明する電文の例では，名前空間接頭辞を省略しています。

(1)　Cookie情報の引き継ぎ方法

2つのサービス間でCookie情報を引き継ぐ場合，Cookie情報を一括して引き継ぐか，Cookie名ごとに個別に引き継ぐかを選択できます。どちらの方法を選択するかによって，使用するヘッダ変数用の電文フォーマットが異なります。

Cookie情報を一括して引き継ぐ場合

要求電文フォーマットにadphttp_header_request1.xsdを使用します。

応答電文フォーマットにadphttp_header_response1.xsdを使用します。

Cookie名ごとに編集できる状態で個別に引き継ぐ場合

要求電文フォーマットにadphttp_header_request2.xsdを使用します。

応答電文フォーマットにadphttp_header_response2.xsdを使用します。

どちらの場合も，サービス部品Aからサービス部品BにCookie情報を引き継ぐには，サービス部品Aの応答電文に含まれるCookie情報（Cookie要素）を，サービス部品Bの要求電文にマッピングしてHTTPアダプタを呼び出します。

それぞれの場合の引き継ぎ方法について説明します。

(a)　Cookie情報を一括して引き継ぐ場合

電文フォーマットでは，次のようにCookie情報がすべてany型で表現されます。なお，Cookie要素を表す要素名は「Cookie_types」としています。

<xsd:complexType name="http-header-Cookies-type">
  <xsd:sequence>
    <xsd:any namespace="##any"
        processContents="skip" minOccurs="0" maxOccurs="unbounded" />
  </xsd:sequence>
</xsd:complexType>

any型の要素部分同士をサービス部品Aの応答電文からサービス部品Bの要求電文にマッピングすることで，Cookie情報を一括して引き継ぐことができます。

(b)　Cookie名ごとに編集できる状態で個別に引き継ぐ場合

電文フォーマットでは，次のようにCookie情報の各属性がXML要素の属性に分割されます。なお，Cookie要素を表す要素名は「Cookie_types」としています。

<xsd:complexType name="cookie-type">
  <xsd:simpleContent>
    <xsd:extension base="xsd:string">
      <xsd:attribute name="name" type="xsd:string" use="required"></xsd:attribute>
      <xsd:attribute name="host" type="xsd:string" use="required"></xsd:attribute>
      <xsd:attribute name="path" type="xsd:string" use="optional"></xsd:attribute>
    </xsd:extension>
  </xsd:simpleContent>
</xsd:complexType>

サービス部品Aの応答電文からサービス部品Bの要求電文へのマッピング時に，Cookie名などを参照して個別に引き継ぐことができます。

(2)　HTTPレスポンス・HTTPリクエストの変換

HTTPレスポンスヘッダから応答電文への変換，および要求電文からHTTPリクエストヘッダへの変換処理について説明します。

HTTPレスポンスヘッダから応答電文への変換処理

サービス部品AからHTTPレスポンスヘッダとして渡された各Set-Cookieヘッダの値は，応答電文のCookie要素に格納されます。また，Set-Cookieヘッダの各属性はCookie要素の属性値に設定されます。

複数のSet-Cookieヘッダが存在した場合は，それぞれのSet-CookieヘッダについてCookie要素が生成されます。

HTTPレスポンスヘッダから応答電文（ヘッダ）への変換例を次に示します。

HTTPレスポンスヘッダのSet-Cookieヘッダ

Set-Cookie: AAA=1234; expires=Sat, 27-Oct -2012 10:00:00 GMT; path=/
Set-Cookie: BBB=5678; expires=Sat, 27-Oct -2012 10:00:00 GMT;

生成後の応答電文（ヘッダ）

<Cookies>
  <Cookie name="AAA" path="/" host="hostname:80※">AAA=1234; expires=Sat, 27-Aug-2011 10:00:00 GMT; path=/</Cookie>
  <Cookie name="BBB" host="hostname:80※">BBB=5678; expires=Sat, 27-Aug-2011 10:00:00 GMT</Cookie>
</Cookies>

注※

host属性には，サービス部品への接続に使用したホスト名とポート番号が格納されます。

Set-Cookieヘッダからpath属性を取得できなかった場合は，応答電文（ヘッダ）にpath属性を付加しないで処理されます。この場合，path属性値は"/"として扱われます。

要求電文からHTTPリクエストヘッダへの変換処理

HTTPアダプタの要求電文として渡されたCookie情報は，次の両方の条件を満たすものが送信対象としてHTTPリクエストヘッダに設定されます。

サービス部品のURIとCookie要素のhost属性に設定された値（ホスト名とポート番号）が完全一致する。

サービス部品のURIに対してCookie要素のpath属性に設定されたパスが前方一致する。

例：サービス部品のURIがhttp://localhost:80/abc/xyzの場合

Cookie情報のhost属性値=localhost:80, path属性値=/abc → 送信される

Cookie情報のhost属性値=somehost:80, path属性値=/abc → 送信されない

Cookie情報のhost属性値=localhost:443, path属性値=/abc → 送信されない

Cookie情報のhost属性値=localhost:80, path属性値=/xyz → 送信されない

Cookie情報のhost属性値=localhost:80, path属性値=/abc/xyz/def → 送信されない

Cookie情報が複数ある場合は，次のようにひとまとめのCookieヘッダに変換されます。

要求電文（ヘッダ）からHTTPリクエストヘッダへの変換例を次に示します。

要求電文（ヘッダ）のCookie要素

<Cookies>
  <Cookie name="AAA" path="/" host="hostname:80">AAA=1234; expires=Sat, 27-Oct-2012 10:00:00 GMT; path=/</Cookie>
  <Cookie name="BBB" host="hostname:80">BBB=5678; expires=Sat, 27-Oct-2012 10:00:00 GMT</Cookie>
</Cookies>

Cookieの要素名はローカル名だけ使用します。ヘッダ応答電文からヘッダ要求電文にCookie情報を一括引継した場合，ヘッダ要求電文のCookie要素の名前空間はヘッダ応答電文になりますが，名前空間を参照しないため，送信対象として正しく扱われます。

生成後のHTTPリクエストヘッダ

Cookie: AAA=1234; BBB=5678

注意事項

異なるpath属性値を持つ複数のCookie要素を設定した場合，path属性値が詳細な順に，HTTPヘッダにCookie情報が設定されます。

（例）NAME1=VALUE1 path=/, NAME2=VALUE2 path=/xyzの値を持つCookie要素を設定した場合：

Cookie: NAME2=VALUE2; NAME1=VALUE1

正常に処理できないCookie情報を受信した場合は，解析をスキップし，処理を続行します。

このほかに「2.2.4(4)　注意事項」に示す注意事項も参照してください。

2.16.6　プロキシサーバを経由した通信

HTTPアダプタでは，プロキシサーバを経由して外部のネットワークにあるサービスを利用できます。

プロキシサーバを経由した通信の概要を次の図に示します。

図2‒164　プロキシサーバを利用した通信

プロキシサーバ経由で接続するにはJavaVMのシステムプロパティの設定が必要です。設定が必要なプロパティを次の表に示します。

表2‒94　プロキシサーバ経由の接続に必要なシステムプロパティ

プロパティ名

指定内容

http.proxyHost

プロキシサーバのホスト名またはIPアドレスを指定します。空文字を指定した場合は，プロキシサーバに接続されません。

http.proxyPort

プロキシサーバのポート番号を設定します。

http.proxyHostが適切に設定されていた場合に，http.proxyPortに空文字を指定したときは，http.proxyHostに指定されているホストの80番ポートにアクセスされます。

http.proxyHostを指定していない場合は，http.proxyPortを指定しても，プロキシサーバに接続されません。

http.nonProxyHosts

プロキシサーバを利用しないホスト名群を必要に応じて指定します。

このプロパティで指定したホストに接続する場合は，http.proxyHostまたはhttps.proxyHostに指定したプロキシサーバは経由されません。ホストを複数指定する場合は，「|」で区切って設定します。ホスト名とホスト名の間には，「|」以外の文字（空白など）は指定できません。

https.proxyHost

SSLプロトコルによる接続で使用するプロキシサーバのホスト名またはIPアドレスを指定します。

空文字を指定した場合は，プロキシサーバに接続されません。

https.proxyPort

SSLプロトコルによる接続で使用するプロキシサーバのポート番号を設定します。

https.proxyHostが適切に設定されていた場合に，https.proxyPortに空文字を指定したときは，https.proxyHostに指定されているホストの443番ポートにアクセスされます。

https.proxyHostを指定していない場合は，https.proxyPortを指定しても，プロキシサーバに接続されません。

設定方法の詳細は，マニュアル「アプリケーションサーバ Webサービス開発ガイド」の「10.10　プロキシサーバ経由の接続」を参照してください。

2.16.7　コネクション継続（Keep-Alive）を使用した通信

ConnectionヘッダにKeep-Aliveを指定することで，一度使用したコネクションを継続して利用でき，次回以降のコネクション接続コストを減らすことができます。

Keep-Alive接続を使用するかどうかはJavaVMのシステムプロパティで設定します。なお，HTTPアダプタからKeep-Alive接続で通信しても，サーバ側がKeep-Aliveを使用しない設定の場合，サーバからのHTTPレスポンスのConnectionヘッダはcloseとなり，コネクションは継続されません。

Keep-Aliveを使用したコネクション継続の概要を次の図に示します。

図2‒165　Keep-Alive接続の概要

Keep-Alive接続を使用する場合に設定が必要なプロパティを次の表に示します。

表2‒95　Keep-Alive接続に必要なシステムプロパティ

プロパティ名

指定内容

http.keepAlive

Keep-Alive接続を有効にするかどうかをtrueまたはfalseで指定します。デフォルトはtrueです。

http.maxConnections

特定の時間内で保持される接続先ごとの最大接続数をint型で指定します。デフォルトは5です。

JavaVMのシステムプロパティの設定については，JavaVMのドキュメントを参照してください。

なお，Keep-Alive接続に関する設定は，システムプロパティで設定するため，HTTPアダプタ単位ではなくサーバ全体で有効になります。

2.16.8　チャンク送信を使用した通信

HTTPアダプタでは，HTTPリクエストを送信する際，ボディデータを複数の塊（チャンク）に分割し，その塊ごとにデータを送信することができます。

チャンク送信の概要を次の図に示します。

図2‒166　チャンク送信の概要

チャンク送信の使用有無およびチャンクサイズは，HTTPアダプタ定義ファイルのadphttp.protocol.chunked-encoding-sizeプロパティで設定できます。

HTTPアダプタ定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「3.10.1　HTTPアダプタ定義ファイル」を参照してください。

2.16.9　HTTPボディの圧縮／解凍

通信データ量が多い場合，送受信するHTTPボディのデータを圧縮／解凍することで，トラフィック量を減らすことができます。

HTTPメッセージの送受信時にHTTPボディを圧縮／解凍するかどうかは，HTTPアダプタ定義ファイルのadphttp.protocol. encoding-typeプロパティで設定できます。

このプロパティにgzipを指定した場合，HTTPボディのデータがgzip形式でエンコード／デコードして送受信されます。

HTTPアダプタ定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「3.10.1　HTTPアダプタ定義ファイル」を参照してください。

HTTPボディの圧縮／解凍の例として，ファイル連携でadphttp.protocol.encoding-typeプロパティにgzipを指定した場合の処理の流れを次の図に示します。

図2‒167　HTTPボディの圧縮／解凍の例

2.16.10　HTTPアダプタのタイマ管理

HTTPアダプタでは次のタイムアウト時間を設定できます。

接続タイムアウト

読み込みタイムアウト

排他管理タイムアウト

それぞれのタイムアウト値は，HTTPアダプタ定義ファイルで設定できます。HTTPアダプタ定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「3.10.1　HTTPアダプタ定義ファイル」を参照してください。

(1)　接続タイムアウト

サーバとの接続が確立するまでの接続タイムアウトを設定できます。

接続タイムアウトの概要を次の図に示します。

図2‒168　接続タイムアウト

設定できるパラメタを次の表に示します。

表2‒96　接続タイムアウトの設定

値

キー名称

デフォルト値

接続タイムアウト（ミリ秒）

adphttp.protocol.connect-timeout

60000

(2)　読み込みタイムアウト

HTTPリクエストを送信してからHTTPレスポンスが返るまでの読み込みタイムアウトを設定できます。HTTPリクエストを送信してから数回に分けてHTTPレスポンスが返る場合は，1回ごとにタイムアウトを監視します。

読み込みタイムアウトの概要を次の図に示します。

図2‒169　読み込みタイムアウト（1回でレスポンスが返る場合）

図2‒170　読み込みタイムアウト（3回に分けてレスポンスが返る場合）

設定できるパラメタを次の表に示します。

表2‒97　読み込みタイムアウトの設定

値

キー名称

デフォルト値

読み込みタイムアウト（ミリ秒）

adphttp.protocol.read-timeout

300000

(3)　排他管理タイムアウト

HTTPアダプタから共通フォルダにアクセスする場合，共通フォルダに対して共有ロックが掛かります。HTTPアダプタでは，このときのロックリトライ回数およびロックリトライ間隔を指定できます。

設定できるパラメタを次の表に示します。

表2‒98　読み込みタイムアウトの設定

値

キー名称

デフォルト値

ロックリトライ回数（回）

adphttp.file.read-lock.retry.count

0

ロックリトライ間隔（秒）

adphttp.file.read-lock.retry.interval

1

2.16.11　ベーシック認証機能を使用した接続

HTTPアダプタでは，ベーシック認証を使用して対象のサーバに接続できます。

ベーシック認証機能を使用するには，WWW認証の認証タイプおよびユーザ名の設定と，認証情報の設定が必要です。

ベーシック認証以外のWWW認証の設定については，「2.16.15　WWW認証を使用したセキュアな接続」を参照してください。

(1)　認証タイプおよびユーザ名の設定

認証タイプおよびユーザ名は，要求電文（ヘッダ），またはHTTPアダプタ実行環境（共通）プロパティファイルで設定します。

(a)　要求電文の設定

要求電文（ヘッダ）に認証タイプおよびユーザ名を設定して，サーバにリクエストを送信します。

認証タイプおよびユーザ名で設定するリクエストヘッダを次に示します。

表2‒99　認証タイプおよびユーザ名の設定項目（要求電文）

キー名称

設定値

/http-header-request/http-header-Authorization/@type属性

basic

/http-header-request/http-header-Authorization要素

HTTPアダプタアカウント定義ファイル※に登録したユーザ名を指定します。

注※

HTTPアダプタアカウント定義ファイルの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「6.14.1　HTTPアダプタアカウント定義ファイル」を参照してください。

設定例

認証タイプおよびユーザ名を設定する場合の要求電文（ヘッダ）の設定例を次に示します。

<http-header-request>
  <http-header-Authorization type="basic">user1</http-header-Authorization>
</http-header-request>

設定方法の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「4.　電文フォーマットの作成」を参照してください。

(b)　HTTPアダプタ実行環境（共通）プロパティファイルの設定

ベーシック認証での接続をHTTPアダプタ実行環境（共通）プロパティファイルに設定する場合，次に示すプロパティを設定します。

表2‒100　認証タイプおよびユーザ名の設定（HTTPアダプタ実行環境（共通）プロパティファイル）

項目

キー名称

設定値

WWW認証の認証タイプ

adphttp.request.header.authorization.type

basic

WWW認証の認証情報

adphttp.request.header.authorization

HTTPアダプタアカウント定義ファイル※に登録したユーザ名を指定します。

注※

HTTPアダプタアカウント定義ファイルの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「6.14.1　HTTPアダプタアカウント定義ファイル」を参照してください。

プロパティの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「6.14.2　HTTPアダプタ実行環境プロパティファイル」を参照してください。

(2)　認証情報の設定

HTTPアダプタのベーシック認証では，呼び出し先のサービスごとに認証情報を管理するため，ユーザ名，パスワードのほかに，接続先URIを認証情報として管理します。異なる接続先URIを設定することで，同一のユーザ名でも別のアカウント情報として管理することができます。

認証情報の設定には，次の作業が必要です。

HTTPアダプタアカウント定義ファイルの作成

アカウント情報を管理するコマンドにユーザ名，パスワード，および接続先URIを設定して，HTTPアダプタアカウント定義ファイルを作成します。

HTTPアダプタ実行環境（共通）プロパティファイルの設定

HTTPアダプタアカウント定義ファイルのパスを設定します。

(a)　HTTPアダプタアカウント定義ファイルの作成

ベーシック認証の認証情報として使用するユーザ名，パスワード，および接続先URIは，作成したHTTPアダプタアカウント定義ファイルに設定します。

HTTPアダプタアカウント定義ファイルは，csahttpuseraddコマンドで作成します。csahttpuseraddコマンドの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「csahttpuseradd（HTTPアダプタのベーシック認証で使用するアカウント情報の登録・更新）」を参照してください。

なお，HTTPアダプタアカウント定義ファイルの内容はコマンドで管理するため，編集はできません。

認証タイプがbasicの場合，ユーザ名と接続先URIをキーとしてHTTPアダプタアカウント定義ファイルからパスワードを取得し，認証情報を作成します。HTTPアダプタアカウント定義ファイルでは，認証情報が適切な接続先にだけ送信されるように，認証情報を送信する接続先のスキーム，ホスト名，ポート，パスを接続先URIとして定義します。接続先URIとのマッチングの詳細については，「(3)　接続先URIとのマッチングルール」を参照してください。

(b)　HTTPアダプタ実行環境（共通）プロパティファイルの設定

HTTPアダプタアカウント定義ファイルを有効にするには，HTTPアダプタ実行環境（共通）プロパティファイルで，HTTPアダプタアカウント定義ファイルの絶対パスを指定する必要があります。

表2‒101　HTTPアダプタアカウント定義ファイルのパスの設定

項目

キー名称

設定値

HTTPアダプタアカウント定義ファイル※のパス

adphttp.config.account-inf-filepath

HTTPアダプタアカウント定義ファイルの保存先のパスを絶対パスで指定します。

注※

HTTPアダプタアカウント定義ファイルの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「6.14.1　HTTPアダプタアカウント定義ファイル」を参照してください。

認証タイプがbasicで，adphttp.config.account-inf-filepathキーが設定されていない場合は，実行時にエラーとなります。

プロパティの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「6.14.2　HTTPアダプタ実行環境プロパティファイル」を参照してください。

(3)　接続先URIとのマッチングルール

次のどれかに指定した接続先URI，およびHTTPアダプタから呼び出すサービスのURIは，設定値を正規化し，マッチングされます。

csahttpuseraddコマンドの-uriオプションに指定した接続先URI

csahttpuserdelコマンドの-uriオプションに指定した接続先URI

-userinfofileオプションのユーザ情報指定ファイルに指定した接続先URI

接続するHTTPアダプタから呼び出すサービスのURIに対して，もっとも長く前方一致したものを優先して採用します。

マッチングの手順と設定に応じたマッチングの例について説明します。

(a)　マッチングの手順

次の設定値を指定したときのマッチングの手順を次に示します。

設定値

[scheme]://[user-info]@[host]:[port][path]?[query]#[fragment]

手順

URI.normalize()でURIを正規化します。

URI.getScheme()で[scheme]を取得し，String.toLowerCase()で小文字に統一します。

この値を[scheme']とします。

URI.getHost()で[host]を取得し，String.toLowerCase()で小文字に統一します。

この値を[host']とします。

スキームおよびホスト名は大文字小文字を区別しないため，すべて小文字に正規化した状態でマッチングされます。

URI.getPort()で[port]を取得します。

この値を[port']とします。

[port]が省略されている場合は[scheme]によって，次のデフォルトポートを代替値として使用します。

指定URIのポートが省略されていた場合

アダプタ内のスキームを見て適切なデフォルトポートを補完します（http→80，https→443）。

http，https以外のスキームが指定されている場合

ポートは補完しません。

URI.getPath()で[path]を取得します。

この値を[path']とします。

[path]が省略されている場合は「/」を補完します。

[scheme']://[host']:[port'][path']の形式で正規化したURIを生成してマッチングします。

なお，URLエンコードが必要な場合，使用できる文字コードはUTF-8だけです。

(b)　マッチングの例

HTTPアダプタアカウント定義ファイルに設定した接続先URIと，マッチングしたURLの例について説明します。HTTPアダプタアカウント定義ファイルには，次の接続先URIを設定したものとします。

http://localhost:80/aaa/bbb/

http://localhost:80/aaa/bbb/ccc/

http://localhost:80/aaa/bbb/ccc

https://localhost:443/aaa/bbb/ccc

https://localhost:443/aaa/bbb/

接続先URIがhttp://localhost/aaa/bbb/ccc/の場合

http://localhost:80/aaa/bbb/ccc/のように，ポート番号を補完したURIで前方一致させます。

この場合，1.と2.と3.が合致しますが，2.が最も長く合致しているため2.のパスワードが採用されます。

接続先URIがhttps://localhost/aaa/bbb/cccの場合

https://localhost:443/aaa/bbb/cccのように，ポート番号を補完したURIで前方一致させます。

この場合，合致するものは4.だけのため，4.のパスワードが採用されます。

HTTPアダプタアカウント定義ファイルに，要求電文またはHTTPアダプタ実行環境（共通）プロパティファイルで指定されたユーザ名がない，または送信URIに対してscheme，host，port，およびpath部分がマッチしないなど，送信する認証情報が取得できなかった場合はエラーとなります。

2.16.12　HTTPアダプタを利用したシステムの例

HTTPアダプタを利用したシステムの例を紹介します。

HTTPクライアントから送信したファイルをサーバにアップロードする

サーバに保管されたファイルを別のサーバに移行する

それぞれのシステムについて説明します。

(1)　HTTPクライアントから送信したファイルをサーバにアップロードする

この例では，HTTPクライアントから送信したファイルを，ビジネスプロセスから呼び出したファイル操作アダプタで変換したあと，目的のサーバにアップロードする処理を実行しています。

図2‒171　HTTPアダプタを利用したシステムの例（1）

サービス部品の呼び出しおよびファイルの流れを次に示します。なお，次の番号は図中の番号と対応しています。

サービスリクエスタ（HTTPクライアントのRESTクライアントプログラム）からHCSCサーバにファイルを送信します。

HTTP受付で受信したファイルが中間ファイルとして作業フォルダに生成されます。

ビジネスプロセスから呼び出されたファイル操作アダプタで中間ファイルを変換します。

ビジネスプロセスから呼び出されたHTTPアダプタで変換後のファイルを目的のサーバへ送信します。

(2)　サーバに保管されたファイルを別のサーバに移行する

この例では，サーバに保管されたファイルをHCSCサーバにダウンロードして，目的となる別のサーバに送信する処理を実行しています。

図2‒172　HTTPアダプタを利用したシステムの例（2）

サービス部品の呼び出しおよびファイルの流れを次に示します。なお，次の番号は図中の番号と対応しています。

サービスリクエスタ（クライアントプログラム）からビジネスプロセスを実行するリクエストを送信します。

ビジネスプロセスから呼び出されたHTTPアダプタAが，対象サーバ（アプリケーションサーバA）にアクセスしてファイルを受信したあと，共通フォルダにファイルを保存します。

ビジネスプロセスから呼び出されたHTTPアダプタBが，共通フォルダに保存されたファイルを目的のサーバ（アプリケーションサーバB）に送信します。

受信した共通フォルダ内のファイルをファイル操作アダプタで削除します。

2.16.13　要求電文（ヘッダ）とHTTPアダプタ実行環境（共通）プロパティファイルのパラメタの対応関係

HTTPアダプタの要求電文（ヘッダ），HTTPアダプタ実行環境プロパティファイル，およびHTTPアダプタ共通実行環境プロパティファイルで設定できるパラメタの対応関係を次に示します。なお，ここでは要求電文（ヘッダ）の要素名をXPathで表記しています。

同じ内容が要求電文（ヘッダ），HTTPアダプタ実行環境プロパティファイル，HTTPアダプタ実行環境共通プロパティファイルの間で複数設定された場合，次の表でより優先度の高いものが適用されます。

表2‒102　要求電文（ヘッダ）とHTTPアダプタ実行環境（共通）プロパティファイルの重複時の優先度

指定個所

重複時の優先度

要求電文（ヘッダ）

高

HTTPアダプタ実行環境プロパティファイル

（HCSCサーバ単位の指定：あり）

｜

HTTPアダプタ実行環境共通プロパティファイル

（HCSCサーバ単位の指定：あり）

｜

HTTPアダプタ実行環境プロパティファイル

（HCSCサーバ単位の指定：なし）

｜

HTTPアダプタ実行環境共通プロパティファイル

（HCSCサーバ単位の指定：なし）

低

要求電文（ヘッダ）と各プロパティとの対応を次に示します。

(1)　リクエストID

送信ファイルの入力元フォルダ種別属性，または受信ファイルの出力先フォルダ種別属性に作業フォルダを指定する場合は，要求電文（ヘッダ）で指定してください。作業フォルダを使用しない場合は，指定を省略できます。

表2‒103　リクエストID

項目

高 ← 優先度 → 低

デフォルト値

指定要否

要求電文（ヘッダ）

HTTPアダプタ実行環境プロパティファイル

HTTPアダプタ実行環境共通プロパティファイル

リクエストID

/http-header-request/request-id

指定できません。

指定できません。

−

任意

（凡例）

−：デフォルト値はありません。

(2)　パート

必要に応じて要求電文（ヘッダ），またはどちらかのプロパティファイルで指定してください。単一のファイルデータを送信する場合は指定を省略できます。

表2‒104　パート

項目

高 ← 優先度 → 低

デフォルト値

指定要否

要求電文（ヘッダ）

HTTPアダプタ実行環境プロパティファイル

HTTPアダプタ実行環境共通プロパティファイル

パート型

/http-header-request/http-body/style

adphttp.request.body.style

adphttp.request.body.style

−

任意

パート名

/http-header-request/http-part/message/part-id

adphttp.request.part.message.part-id

adphttp.request.part.message.part-id

−

任意

/http-header-request/http-part/files/file/part-id

adphttp.request.part.file.<追番>.part-id

adphttp.request.part.file.<追番>.part-id

−

任意

（凡例）

−：デフォルト値はありません。

(3)　リクエストメソッド

要求電文（ヘッダ），またはどちらかのプロパティファイルで必ず指定してください。

表2‒105　リクエストメソッド

項目

高 ← 優先度 → 低

デフォルト値

指定要否

要求電文（ヘッダ）

HTTPアダプタ実行環境プロパティファイル

HTTPアダプタ実行環境共通プロパティファイル

リクエストメソッド

/http-header-request/method

adphttp.request.method

adphttp.request.method

−

必須

（凡例）

−：デフォルト値はありません。

(4)　リクエストURI

スキーム・オーソリティは，要求電文（ヘッダ），またはどちらかのプロパティファイルで必ず指定してください。

パスは，必要に応じて要求電文（ヘッダ），またはどちらかのプロパティファイルで指定してください。ルートパス（"/"）を使用する場合は指定を省略できます。

クエリは，必要に応じて要求電文（ヘッダ），またはどちらかのプロパティファイルで指定してください。クエリを複数の場所で指定した場合，優先度が低い場所で指定したクエリは優先度が高い場所で指定したクエリですべて上書きされます。複数の場所で指定したクエリの結合はできません。

表2‒106　リクエストURI

項目

高 ← 優先度 → 低

デフォルト値

指定要否

要求電文（ヘッダ）

HTTPアダプタ実行環境プロパティファイル

HTTPアダプタ実行環境共通プロパティファイル

スキーム・オーソリティ

/http-header-request/uri-scheme-authority

adphttp.request.uri-scheme-authority

adphttp.request.uri-scheme-authority

−

必須

パス

/http-header-request/uri-path

adphttp.request.uri-path

adphttp.request.uri-path

−

任意

クエリ

/http-header-request/uri-query/任意要素

adphttp.request.uri-query.<追番>

adphttp.request.uri-query.<追番>

−

（凡例）

−：デフォルト値はありません。

(5)　認証情報

必要に応じて要求電文（ヘッダ），またはどちらかのプロパティファイルで指定してください。認証情報を使用しない場合は指定を省略（デフォルト値を使用）できます。

これらのパラメタは常にセットで指定する必要があります。1つの場所に認証値，または認証種別属性を単独で指定することはできません。

表2‒107　認証情報

項目

高 ← 優先度 → 低

デフォルト値

指定要否

要求電文（ヘッダ）

HTTPアダプタ実行環境プロパティファイル

HTTPアダプタ実行環境共通プロパティファイル

認証値

/http-header-request/http-header-Authorization

adphttp.request.header.authorization

adphttp.request.header.authorization

空文字列

任意

認証種別属性

/http-header-request/http-header-Authorization/@type

adphttp.request.header.authorization.type

adphttp.request.header.authorization.type

none

(6)　Content-Type

必要に応じて要求電文（ヘッダ），またはどちらかのプロパティファイルで指定してください。Content-Typeヘッダの設定をしない場合は指定を省略できます。

文字コード属性の設定が不要な場合は，指定を省略できます。この場合，メディアタイプだけ使用されます。

文字コード属性を単独で指定した場合は，指定が有効になりません。

表2‒108　Content-Type

項目

高 ← 優先度 → 低

デフォルト値

指定要否

要求電文（ヘッダ）

HTTPアダプタ実行環境プロパティファイル

HTTPアダプタ実行環境共通プロパティファイル

メディアタイプ

/http-header-request/http-header-Content-Type

adphttp.request.header.content-type

adphttp.request.header.content-type

−

任意

/http-header-request/http-part/files/file/Content-Type

adphttp.request.part.file.<追番>.content-type

adphttp.request.part.file.<追番>.content-type

−

文字コード属性

/http-header-request/http-header-Content-Type/@charset

adphttp.request.header.content-type.charset

adphttp.request.header.content-type.charset

−

/http-header-request/http-part/message/Content-Type/@charset

adphttp.request.part.message.content-type.charset

adphttp.request.part.message.content-type.charset

−

/http-header-request/http-part/files/file/Content-Type/@charset

adphttp.request.part.file.<追番>.content-type.charset

adphttp.request.part.file.<追番>.content-type.charset

−

（凡例）

−：デフォルト値はありません。

(7)　Cookie

必要に応じて要求電文（ヘッダ），またはどちらかのプロパティファイルで指定してください。Cookieヘッダの設定をしない場合は指定を省略できます。

Cookie情報，Cookie名属性，送信先ホスト名属性は常にセットで指定する必要があります。

送信先パス属性の設定が不要な場合は，指定を省略できます。この場合，送信先パスの判定が行われないため，すべてのパスに対してCookieが送信されます。

1つの場所にCookie情報，Cookie名属性，送信先ホスト名属性，送信先パス属性を単独で指定することはできません。

表2‒109　Cookie

項目

高 ← 優先度 → 低

デフォルト値

指定要否

要求電文（ヘッダ）

HTTPアダプタ実行環境プロパティファイル

HTTPアダプタ実行環境共通プロパティファイル

Cookie情報

/http-header-request/http-header-Cookies/Cookie

指定できません。

指定できません。

−

任意

Cookie名属性

/http-header-request/http-header-Cookies/Cookie/@name

指定できません。

指定できません。

−

送信先ホスト名属性

/http-header-request/http-header-Cookies/Cookie/@host

指定できません。

指定できません。

−

送信先パス属性

/http-header-request/http-header-Cookies/Cookie/@path

指定できません。

指定できません。

−

（凡例）

−：デフォルト値はありません。

(8)　リクエストヘッダ

必要に応じて要求電文（ヘッダ），またはどちらかのプロパティファイルで指定してください。

リクエストヘッダを複数の場所で指定した場合，優先度が低い場所で指定したリクエストヘッダは優先度が高い場所で指定したリクエストヘッダですべて上書きされます。複数の場所で指定したリクエストヘッダの結合はできません。

表2‒110　リクエストヘッダ

項目

高 ← 優先度 → 低

デフォルト値

指定要否

要求電文（ヘッダ）

HTTPアダプタ実行環境プロパティファイル

HTTPアダプタ実行環境共通プロパティファイル

リクエストヘッダ

/http-header-request/http-header/任意要素

adphttp.request.header.userdef.<追番>

adphttp.request.header.userdef.<追番>

−

任意

（凡例）

−：デフォルト値はありません。

(9)　リクエストボディ（要求電文（ボディ）のデータ送信種別）

必要に応じて要求電文（ヘッダ），またはどちらかのプロパティファイルで指定してください。リクエストボディを送信しない場合は，指定を省略（デフォルト値を使用）できます。

送信ファイルのパラメタを指定した場合は，このパラメタの指定は無視されます。

表2‒111　リクエストボディ（要求電文（ボディ）のデータ送信種別）

項目

高 ← 優先度 → 低

デフォルト値

指定要否

要求電文（ヘッダ）

HTTPアダプタ実行環境プロパティファイル

HTTPアダプタ実行環境共通プロパティファイル

リクエストボディ（要求電文（ボディ）のデータ送信種別）

/http-header-request/http-part/message/binding

adphttp.request.part.message.binding

adphttp.request.part.message.binding

none

任意

(10)　送信ファイル

要求電文（ボディ）の代わりにファイルをリクエストボディとして送信する場合は，要求電文（ヘッダ），またはどちらかのプロパティファイルで指定してください。

リクエストボディを送信しない場合や要求電文（ボディ）をリクエストボディとして送信する場合は，指定を省略できます。

これらのパラメタは常にセットで指定する必要があります。1つの場所に入力元フォルダ名，入力元フォルダ種別属性，入力元ファイル名を単独で指定することはできません。

表2‒112　送信ファイル

項目

高 ← 優先度 → 低

デフォルト値

指定要否

要求電文（ヘッダ）

HTTPアダプタ実行環境プロパティファイル

HTTPアダプタ実行環境共通プロパティファイル

入力元フォルダ名

/http-header-request/http-part/files/file/input-folder-name

adphttp.request.part.file.<追番>.input-folder-name

adphttp.request.part.file.<追番>.input-folder-name

−

任意

入力元フォルダ種別属性

/http-header-request/http-part/files/file/input-folder-name/@common

指定できません。

指定できません。

−

入力元ファイル名

/http-header-request/http-part/files/file/local-file-name

adphttp.request.part.file.<追番>.local-file-name

adphttp.request.part.file.<追番>.local-file-name

−

/http-header-request/http-part/files/file/file-name

adphttp.request.part.file.<追番>.file-name

adphttp.request.part.file.<追番>.file-name

−

（凡例）

−：デフォルト値はありません。

(11)　受信ファイルの出力先

ファイルを受信する場合は，要求電文（ヘッダ），またはどちらかのプロパティファイルで指定してください。ファイルを受信しない場合は，指定を省略できます。

これらのパラメタは常にセットで指定する必要があります。1つの場所に出力先フォルダ名，出力先フォルダ種別属性，または出力先サブフォルダを単独で指定することはできません。

表2‒113　受信ファイルの出力先

項目

高 ← 優先度→ 低

デフォルト値

指定要否

要求電文（ヘッダ）

HTTPアダプタ実行環境プロパティファイル

HTTPアダプタ実行環境共通プロパティファイル

出力先フォルダ名

/http-header-request/output-folder-name

adphttp.request.output-folder-name

adphttp.request.output-folder-name

−

任意

出力先フォルダ種別属性

/http-header-request/output-folder-name/@common

指定できません。

指定できません。

−

出力先サブフォルダ

/http-header-request/output-sub-folder

adphttp.request.output-sub-folder

adphttp.request.output-sub-folder

−

（凡例）

−：デフォルト値はありません。

2.16.14　HTTPアダプタのJSON-XML変換機能

HTTPアダプタのJSON-XML変換機能とは，HTTPアダプタでXML形式の要求電文をJSON形式に，またはJSON形式の応答電文をXML形式に変換する機能です。

(1)　HTTPアダプタのJSON-XML変換機能の概要

ビジネスプロセスで扱うXML形式の要求電文を，HTTPアダプタでJSON形式に変換してRESTful Webサービスに送信します。また，RESTful Webサービスから応答されたJSON形式の応答電文をXML形式に変換し，ビジネスプロセスへ応答します。HTTPアダプタのJSON-XML変換機能を使用したサービス部品呼び出し要求および応答の流れを次の図に示します。

図2‒173　JSON-XML変換機能を使用したサービス部品呼び出し要求・応答の流れ（HTTPアダプタ）

HTTPアダプタに設定する電文フォーマット（XMLスキーマ）は，JSON変換ツールで生成します。JSON変換ツールは，JSON形式の電文のサンプルを受け取り，JSON-XML変換後のXML形式の電文に適合する電文フォーマットを生成します。HTTPアダプタの開発の流れを次の図に示します。

図2‒174　JSON-XML変換機能を使用するHTTPアダプタの開発の流れ

HTTPアダプタの定義の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.13　HTTPアダプタを定義する」を，JSON変換ツールの詳細については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「13.　JSON変換ツールを使用したデータ変換」を参照してください。

(2)　HTTPアダプタのリクエスト処理時のJSON-XML変換機能

HTTPアダプタのリクエスト処理時のJSON-XML変換のタイミングや設定について説明します。

(a)　HTTPアダプタのリクエスト処理時のJSON-XML変換のタイミング

HTTPアダプタのリクエスト処理時の，JSON-XML変換のタイミングを次の図に示します。

図2‒175　リクエスト処理時のJSON-XML変換のタイミング（HTTPアダプタ）

図中の1.〜4.について説明します。

ビジネスプロセスから要求電文を受信します。

データ変換では，ビジネスプロセスから送信されたXML形式の要求電文を扱います。

HTTPアダプタでは，データ変換とコンポーネント共通UOCの呼び出しの間でJSON-XML変換が実行されます。

コンポーネント共通UOCでは，JSON-XML変換機能で変換されたJSON形式の要求電文を扱います。

(b)　HTTPアダプタのリクエスト処理時にJSON-XML変換をする場合の設定

HTTPアダプタ定義ファイルのadphttp.request.switchover.json-transfer.modeプロパティの値が「true」の場合は，HTTPアダプタのリクエスト処理時にJSON-XML変換が実行されます。要求電文（ヘッダ）のjson-transfer要素の値が「false」の場合は，HTTPアダプタのリクエスト処理時にJSON-XML変換は実行されません。HTTPアダプタ定義ファイルのプロパティおよび要求電文（ヘッダ）の設定とJSON-XML変換の実行可否を次の表に示します。

表2‒114　リクエスト処理時のJSON-XML変換の実行可否（HTTPアダプタ）

HTTPアダプタ定義ファイル

adphttp.request.switchover.json-transfer.modeプロパティ

要求電文（ヘッダ）

json-transfer要素

JSON-XML変換の実行

−（プロパティを設定していない）

要素なし

実行されない

false

true

false

要素なし

実行されない

false

true

true

要素なし

実行される

false

実行されない

true

実行される

(c)　HTTPアダプタのHTTPリクエストヘッダに関連する処理

JSON-XML変換機能に関連しているHTTPアダプタのHTTPリクエストヘッダについて説明します。

HTTPアダプタのHTTPリクエストヘッダの処理の詳細については，「2.16.3　HTTPリクエストと要求電文の関係」を参照してください。

Content-Typeヘッダ

JSON-XML変換は，要求電文（ヘッダ）のContent-Typeの設定に関わらず実行されます。また，要求電文（ヘッダ）にContent-Typeが設定されていない場合は，HTTPリクエストヘッダにContent-Typeヘッダが設定されません。

Content-Typeヘッダのcharset属性

要求電文（ヘッダ）のContent-Typeにcharset属性が設定されていない場合は，HTTPリクエストヘッダに設定されるContent-Typeヘッダにcharset属性が設定されません。

(3)　HTTPアダプタのレスポンス処理時のJSON-XML変換機能

HTTPアダプタのレスポンス処理時のJSON-XML変換のタイミングや設定について説明します。

(a)　HTTPアダプタのレスポンス処理時のJSON-XML変換のタイミング

HTTPアダプタのレスポンス処理時のJSON-XML変換のタイミングを次の図に示します。

図2‒176　レスポンス処理時のJSON-XML変換のタイミング（HTTPアダプタ）

図中の1.〜4.について説明します。

HTTPアダプタがRESTful Webサービスから応答電文を受信します。

HTTPアダプタのコンポーネント共通UOCでは，サービス部品から返却されたJSON形式の応答電文を扱います。

HTTPアダプタでは，コンポーネント共通UOCの呼び出しとデータ変換の間でJSON-XML変換が実行されます。

HTTPアダプタのデータ変換では，JSON-XML変換機能で変換されたXML形式の応答電文を扱います。

(b)　HTTPアダプタのレスポンス処理時にJSON-XML変換をする場合の設定

HTTPアダプタ定義ファイルのadphttp.response.switchover.json-transfer.modeプロパティの値が「true」の場合，HTTPアダプタのレスポンス処理時にJSON-XML変換が実行されます。応答電文（ヘッダ）では，JSON-XML変換を実行するかどうかの切り替えはできません。HTTPアダプタ定義ファイルのプロパティの設定とJSON-XML変換の実行可否を次の表に示します。

表2‒115　レスポンス処理時のJSON-XML変換の実行可否（HTTPアダプタ）

HTTPアダプタ定義ファイル

adphttp.response.switchover.json-transfer.modeプロパティ

JSON-XML変換の実行

−（プロパティを設定していない）

実行されない

false

実行されない

true

実行される

(c)　HTTPアダプタのHTTPレスポンスヘッダに関連する処理

JSON-XML変換機能に関連しているHTTPアダプタのHTTPレスポンスヘッダについて説明します。

HTTPアダプタのHTTPレスポンスヘッダの処理の詳細については，マニュアル「サービスプラットフォーム 解説」の「2.16.4　HTTPレスポンスと応答電文の関係」を参照してください。

Content-Typeヘッダについて

JSON-XML変換は，HTTPレスポンスヘッダのContent-Typeヘッダの値に関わらず実行されます。また，Content-TypeヘッダがHTTPレスポンスヘッダに設定されていない場合は，応答電文（ヘッダ）にContent-Typeが設定されません。

Content-Typeヘッダのcharset属性について

HTTPレスポンスヘッダのContent-Typeヘッダにcharset属性が設定されていない場合は，応答電文（ヘッダ）のcharset属性が設定されません。

2.16.15　WWW認証を使用したセキュアな接続

HTTPアダプタでは，WWW認証を使用して対象のサーバと安全に接続できます。

WWW認証を使用するには，要求電文（ヘッダ），HTTPアダプタ実行環境プロパティファイル，またはHTTPアダプタ実行環境共通プロパティファイルでの設定が必要です。

WWW認証に関する設定個所および設定内容を次に示します。

表2‒116　WWW認証に関する設定項目

項目

設定個所

設定項目

設定する値

認証タイプ

要求電文（ヘッダ）

http-header-Authorization要素のtype属性

次のどちらかを設定します。

none

WWW認証を使用しません。

raw

WWW認証を使用します。

basic

ベーシック認証を使用します。

HTTPアダプタ実行環境プロパティファイル，HTTPアダプタ実行環境共通プロパティファイル

adphttp.request.header.authorization.typeプロパティ

認証情報

要求電文（ヘッダ）

http-header-request/http-header-Authorization要素

WWW認証の認証情報を指定します。

HTTPアダプタ実行環境プロパティファイル，HTTPアダプタ実行環境共通プロパティファイル

adphttp.request.header.authorizationプロパティ

2.16.16　OAuth 2.0に対応したサービスへのアクセス

HTTPアダプタは，OAuth 2.0に対応したサービスへアクセスするために，OAuth 2.0で必要な情報が容易に設定できるインターフェースを提供します。

(1)　HTTPアダプタにおけるOAuth 2.0の認可フロー対応機能の概要

OAuth 2.0に対応した認証機能は，認可および認証の処理方式のうち，認証部分をHTTPアダプタで実現します。

前提条件

ユーザは事前に，HTTPアダプタが認証情報を作成する際に使用する情報を登録する必要があります。

認証情報の登録方法については，マニュアル「サービスプラットフォーム リファレンス」の「csauseradd（パスワード認証のユーザ情報の登録・更新）」および「csakeyadd（公開鍵認証の秘密鍵情報の登録・更新）」を参照してください。

例

処理方式の例を次の図に示します。

図2‒177　認可および認証の処理方式の例

説明

ユーザはリソースの使用許可を要求し，リソースオーナーから使用許可を取得します。

HTTPアダプタは，ユーザが要求電文に指定したフォームデータ，および認証情報を基に作成したフォームデータをOAuth 2.0が対応する認証フローを使用して，認可サーバに送信します。

認可サーバは送信された認証処理を基に認証処理を実行し，特定のWebサービス呼び出しに使用するアクセストークンをHTTPアダプタに返します。

HTTPアダプタは取得したアクセストークンを使用してWebサービスを呼び出します。

(2)　OAuth 2.0に対応したHTTP通信の例

HTTPアダプタから，OAuth 2.0が対応する認証フローを使用して，認証処理を実施します。このとき，認可サーバからアクセストークンを取得します。取得したアクセストークンを使用してWebサービスを呼び出します。

前提条件

Webサービスや認可サーバが，HTTPアダプタが対応するOAuth 2.0の認証フローに対応している必要があります。

構成例

OAuth 2.0に対応した認証例を次の図に示します。

図2‒178　OAuth 2.0に対応した認証例

説明

クライアントのプログラムからビジネスプロセスを実行するリクエストを発行します。

データ変換アクティビティを使用して，認証情報をHTTPアダプタのボディ（Form）に設定します。

HTTPアダプタを使用して，認可サーバからアクセストークンを取得します。

取得したアクセストークンを，データ変換アクティビティを使用して，Webサービスを呼び出すHTTPアダプタのヘッダに設定します。

アクセストークンを設定したHTTPアダプタでWebサービスを呼び出します。

設定の詳細については，「(6)　取得したアクセストークンを使用してWebサービスを呼び出す場合のHTTPアダプタの設定」を参照してください。

(3)　HTTPアダプタが対応する認証フロー

HTTPアダプタが対応するOAuth 2.0の認証フローを次に示します。

JWT Bearer Token Flow

Resource Owner Password Credentials Flow

(a)　JWT Bearer Token Flow

JWT Bearer Token Flowは，JWT（JSON Web Token）を使用した電子署名付きの認証フローです。電子署名によって認証情報の改ざんをチェックできます。

前提条件

JWT Bearer Token Flowは，信頼関係を構築できるシステムから，ユーザによる認証および認可の手順を踏まずに，直接アクセストークンを取得できる場合に使用できます。

例

JWT Bearer Token Flowの流れを次に示します。

図2‒179　JWT Bearer Token Flowの流れ

説明

ユーザは事前に証明書と秘密鍵を作成して，証明書を認可サーバに登録し，認可サーバ側で公開鍵を保持します。

JWTを格納するフォームデータ（assertion）をHTTPアダプタで作成する場合，ユーザは事前にcsakeyaddコマンドを使用して，秘密鍵を登録します。

JWTを格納するフォームデータ（assertion）をHTTPアダプタで作成する場合，認証情報を基に電子署名をして，JWTを作成します。

HTTPアダプタは，JWTを認可サーバに送信します。

認可サーバでJWTを検証し，検証結果が正しい場合にアクセストークンを発行します。

(b)　Resource Owner Password Credentials Flow

Resource Owner Password Credentials Flowは，HTTPアダプタがリソースオーナーのユーザ名とパスワードを使用して，認可サーバにアクセストークンを要求する認証フローです。

前提条件

リソースオーナーが，HTTPアダプタにユーザ名とパスワードを提供してもよい場合に使用できます。

例

Resource Owner Password Credentials Flowの流れを次に示します。

図2‒180　Resource Owner Password Credentials Flowの流れ

説明

リソースオーナーが，ユーザ名とパスワードを提供します。

ユーザは事前にcsauseraddコマンドを使用して，提供されたユーザ名とパスワードを登録します。

HTTPアダプタは，認可サーバのトークンエンドポイントに対して，ユーザが指定したユーザ名と，csauseraddコマンドで登録したパスワードをリクエストに含め，リクエストを送信します。

認可サーバはクライアントの認証を実行し，ユーザ名とパスワードの有効性を検査します。有効であれば，認可サーバはアクセストークンを発行します。

(4)　認証フローを使用する場合のHTTPリクエストおよびHTTPレスポンス

OAuth 2.0の認証フローを使用する場合のHTTPリクエスト・レスポンスと，要求・応答電文に設定する値について説明します。

(a)　HTTPアダプタから認可サーバに送信するリクエストボディ

アクセストークンを取得する場合は，HTTPリクエストボディで送信するデータ種別としてフォームデータ（ノーマルモード）を選択します。

図2‒181　認証フローとしてJWT Bearer Token Flowを使用する場合のフォームデータ設定の概要

(b)　認可サーバから受信したレスポンスボディの情報を格納する応答電文

HTTPアダプタでは，OAuth 2.0の認証フローを使用して認可サーバから認証情報を受信する場合，JSON形式の応答だけをサポートしています。HTTPアダプタは，認証情報を受信したとき，HTTPレスポンスボディの情報を解析し，アクセストークンを応答電文（ヘッダ）に格納します。

また，レスポンスボディの内容は，ボディ応答電文へ割り当てられます。

図2‒182　認証フローとしてJWT Bearer Token Flowを使用する場合のレスポンスの概要

(5)　認証フローを使用してアクセストークンを取得する場合のHTTPアダプタの設定

OAuth 2.0が対応する認証フローを使用して，アクセストークンを取得する場合のHTTPアダプタの設定内容について説明します。

(a)　要求電文の設定

要求電文のボディにフォームデータとして，認証フローごとに対応する値を設定して，認可サーバにリクエストを送信します。共通の設定項目として，キー名称のgrant_typeに使用する認証フローに対応する固定の文字列を設定します。

注意事項

パスワードなどの情報を送信するため，送信時にhttpsを使用するなどセキュリティを考慮する必要があります。

●JWT Bearer Token Flowを使用する場合

対応する電文フォーマット

認証フローに対応する電文フォーマットを次に示します。

認証フロー

ボディ要求電文フォーマット

JWT Bearer Token Flow

assertionをHTTPアダプタで作成する場合

adphttp_body_form-data_jwt_assertion1.xsd

HTTPアダプタ以外の発行者が作成したassertionをHTTPアダプタで使用する場合

adphttp_body_form-data_jwt_assertion2.xsd

assertion設定機能の設定

サービスプラットフォームでは，HTTPアダプタ内で，リクエストボディで設定されたクレーム情報や，ヘッダ情報などを基に作成した値をassertionの設定値として使用する機能を提供します。

この機能を使うために，ユーザはcsakeyaddコマンドを使用して，認可サーバから取得した秘密鍵を登録する必要があります。ユーザが要求電文（ボディ）に設定した認証情報を基に，HTTPアダプタがassertionの設定値を作成します。作成したassertionの設定値を，リクエスト時に送信するフォームデータの「assertion」に設定します。

詳細については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.13　HTTPアダプタを定義する」の電文フォーマットの作成に関する説明を参照してください。

JWT Bearer Token Flowで設定するリクエストボディ

JWT Bearer Token Flowで設定するリクエストボディを次に示します。

キー名称

設定値

grant_type

urn:ietf:params:oauth:grant-type:jwt-bearer（固定文字列）

assertion

認証情報から作成したJWT bearer token

任意の設定項目を指定する場合の電文フォーマットの設定項目

そのほかの任意の設定項目を指定する場合は，電文フォーマットに設定項目を追加してください。

設定方法の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「4.　電文フォーマットの作成」を参照してください。

カスタマイズした電文フォーマットの例を次に示します。これらの例は一部を抜粋しています。

adphttp_body_form-data_jwt_assertion1.xsdの場合

ここでは，Authorization Grantsとしてscopeパラメタ，JWTのクレームとしてany要素，およびJWTのヘッダとしてtype要素を追加する例を示します。

＜修正前＞

<xsd:complexType name="http-body-form-data-type">
   <xsd:sequence>
      <xsd:element name="grant_type" type="xsd:string" minOccurs="1" maxOccurs="1"/>
      <xsd:element name="auth-info" type="tns:auth-info-type" minOccurs="1" maxOccurs="1"/>
   </xsd:sequence>
 </xsd:complexType>

 <xsd:complexType name="claim-type">
   <xsd:sequence>
      <xsd:element name="iss" type="xsd:string" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="aud" type="xsd:string" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="sub" type="xsd:string" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="exp" type="xsd:string" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="nbf" type="xsd:string" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="iat" type="xsd:string" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="jti" type="xsd:string" minOccurs="0" maxOccurs="1"/>
   </xsd:sequence>
 </xsd:complexType>

 <xsd:complexType name="header-type">
   <xsd:sequence>
      <xsd:element name="alg" type="xsd:string" minOccurs="1" maxOccurs="1"/>
   </xsd:sequence>
 </xsd:complexType>

＜修正後＞

<xsd:complexType name="http-body-form-data-type">
   <xsd:sequence>
      <xsd:element name="grant_type" type="xsd:string" minOccurs="1" maxOccurs="1"/>
      <xsd:element name="auth-info" type="tns:auth-info-type" minOccurs="1" maxOccurs="1"/>
      <xsd:element name="scope" type="xsd:string" minOccurs="0" maxOccurs="1"/>
   </xsd:sequence>
 </xsd:complexType>

 <xsd:complexType name="claim-type">
   <xsd:sequence>
      <xsd:element name="iss" type="xsd:string" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="aud" type="xsd:string" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="sub" type="xsd:string" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="exp" type="xsd:string" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="nbf" type="xsd:string" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="iat" type="xsd:string" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="jti" type="xsd:string" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="any" type="xsd:string" minOccurs="0" maxOccurs="1"/>
   </xsd:sequence>
 </xsd:complexType>

 <xsd:complexType name="header-type">
   <xsd:sequence>
      <xsd:element name="alg" type="xsd:string" minOccurs="1" maxOccurs="1"/>
      <xsd:element name="typ" type="xsd:string" minOccurs="0" maxOccurs="1"/>
   </xsd:sequence>
 </xsd:complexType>

adphttp_body_form-data_jwt_assertion2.xsdの場合

ここでは，Authorization Grantsとしてscopeパラメタを追加する例を示します。

＜修正前＞

<xsd:complexType name="http-body-form-data-type">
   <xsd:sequence>
      <xsd:element name="grant_type" type="xsd:string" minOccurs="1" maxOccurs="1"/>
      <xsd:element name="assertion" type="xsd:string" minOccurs="1" maxOccurs="1"/>
   </xsd:sequence>
 </xsd:complexType>

＜修正後＞

<xsd:complexType name="http-body-form-data-type">
   <xsd:sequence>
      <xsd:element name="grant_type" type="xsd:string" minOccurs="1" maxOccurs="1"/>
      <xsd:element name="assertion" type="xsd:string" minOccurs="1" maxOccurs="1"/>
      <xsd:element name="scope" type="xsd:string" minOccurs="0" maxOccurs="1"/>
   </xsd:sequence>
 </xsd:complexType>

●Resource Owner Password Credentials Flowを使用する場合

対応する電文フォーマット

認証フローに対応する電文フォーマットを次に示します。

認証フロー

ボディ要求電文フォーマット

Resource Owner Password Credentials Flow

adphttp_body_form-data_password.xsd

パスワードの設定

Resource Owner Password Credentials Flowを使用する場合，username要素にリソースオーナーのユーザネームとして，csauseraddコマンドで登録したユーザ名を設定します。password要素は，csauseraddコマンドで登録したパスワードをHTTPアダプタが取得して設定します。

詳細については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.13　HTTPアダプタを定義する」の電文フォーマットの作成に関する説明を参照してください。

JWT Bearer Token Flowで設定するリクエストボディ

Resource Owner Password Credentials Flowで設定するリクエストボディを次に示します。

キー名称

設定値

grant_type

password（固定文字列）

username

リソースオーナーのユーザ名

password

リソースオーナーのパスワード

任意の設定項目を指定する場合の電文フォーマットの設定項目

そのほかの任意の設定項目を指定する場合は，電文フォーマットに個別に設定項目を追加してください。

設定方法の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「4.　電文フォーマットの作成」を参照してください。

カスタマイズした電文フォーマットの例を次に示します。例は全体から一部を抜粋しています。

adphttp_body_form-data_password.xsdの場合

＜修正前＞

<xsd:complexType name="http-body-form-data-type">
   <xsd:sequence>
      <xsd:element name="grant_type" type="xsd:string" minOccurs="1" maxOccurs="1"/>
      <xsd:element name="username" type="xsd:string" minOccurs="1" maxOccurs="1"/>
   </xsd:sequence>
 </xsd:complexType>

＜修正後＞

<xsd:complexType name="http-body-form-data-type">
   <xsd:sequence>
      <xsd:element name="grant_type" type="xsd:string" minOccurs="1" maxOccurs="1"/>
      <xsd:element name="username" type="xsd:string" minOccurs="1" maxOccurs="1"/>
      <xsd:element name="scope" type="xsd:string" minOccurs="0" maxOccurs="1"/>
   </xsd:sequence>
 </xsd:complexType>

(b)　応答電文の設定

認可サーバからレスポンス受信時に応答電文（ヘッダ）に，アクセストークンが格納されます。

詳細については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.13　HTTPアダプタを定義する」の電文フォーマットの形式に関する説明を参照してください。

応答電文にはアクセストークンが格納されているため，ユーザ電文トレース出力時にアクセストークンが，ユーザ電文トレースに出力されます。ユーザ電文トレースにアクセストークンを出力したくない場合は，ユーザ電文トレースを取得しない設定にしてください。

(c)　HTTPアダプタ定義ファイルの設定

HTTPアダプタ実行時にOAuth 2.0の認証フローを使用する場合，次に示すプロパティを設定します。

プロパティの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「3.10.1　HTTPアダプタ定義ファイル」を参照してください。

キー名称

設定値

adphttp.oauth.authentication

true

注意事項

OAuth 2.0の認証フローを使用する場合に，adphttp.oauth.authenticationプロパティにtrueを指定しないと，認証情報が不正になるため，HTTPリクエストがエラー応答したり，応答電文（ヘッダ）にアクセストークンが格納されなかったりすることがあります。

(d)　HTTPアダプタ実行環境プロパティファイルの設定

csakeyaddコマンド，またはcsauseraddコマンドを事前に実行した場合，次の表のプロパティの設定値に，コマンド実行時の引数に指定したパスワード認証情報定義ファイル，または公開鍵認証情報定義ファイルのパスを設定してください。

HTTPアダプタ実行環境プロパティファイルから設定するプロパティを次に示します。

キー名称

設定値

adphttp.config.password-auth-inf-filepath

パスワード認証情報定義ファイルのパス

adphttp.config.publickey-auth-inf-filepath

公開鍵認証情報定義ファイルのパス

OAuth 2.0が対応する認証フローを使用する場合，認証情報をフォームデータとして送信するため，次の表のプロパティの設定値に「form-data」を設定してください。

HTTPアダプタ実行環境プロパティファイルから設定するプロパティを次に示します。

キー名称

設定値

adphttp.request.part.message.binding

form-data

各プロパティの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「6.14.2　HTTPアダプタ実行環境プロパティファイル」を参照してください。

(6)　取得したアクセストークンを使用してWebサービスを呼び出す場合のHTTPアダプタの設定

取得したアクセストークンを，Webサービスを呼び出すHTTPアダプタの要求電文（ヘッダ）のAuthorizationに設定してWebサービスを呼び出します。

要求電文（ヘッダ）から設定する場合の設定項目を次に示します。

キー名称

設定値

/http-header-request/http-header-Authorization/@type属性

raw

/http-header-request/http-header-Authorization要素

Bearer△アクセストークン

（凡例）

△：半角スペース

要求電文（ヘッダ）で指定する場合の例を次に示します。

<http-header-request>
  <http-header-Authorization type="raw">Bearer eyJhbGciOiJSUz…
</http-header-Authorization>
</http-header-request>

(7)　認証フローを使用する場合の定義例

Salesforceが提供するAPIへ接続することを想定した定義例について説明します。

(a)　定義の条件

定義例の前提条件を次に示します。

認証処理で使用する認証情報は，受付の要求電文から取得します。

assertionは，HTTPアダプタで作成します。

認可サーバ，Webサービスは，Salesforceを想定しています。

Webサービスの呼び出しだけで，応答電文の解析は実施しません。

Salesforceの設定値の詳細については，Salesforceのドキュメントを参照してください。

(b)　ビジネスプロセスの定義例

ビジネスプロセスの設定例を次に示します。

図2‒183　JWT Bearer Token Flowを使用してWebサービスを呼び出すビジネスプロセスの例

(c)　認証処理を行うHTTPアダプタの定義例

ここではOAuth 2.0の認証フロー（JWT Bearer Token Flow）を使用する上で，必要となる次の作業について説明します。

HTTPアダプタの基本的な定義の流れについては，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.13　HTTPアダプタを定義する」を参照してください。

秘密鍵の登録

電文フォーマットの設定

定義ファイルの設定

データ変換の定義

それぞれの定義について説明します。

●秘密鍵の登録

HTTPアダプタでassertionの設定値を作成する場合は，ユーザは事前にJWTの作成に使用する秘密鍵を，csakeyaddコマンドを実行して登録する必要があります。

●電文フォーマットの作成

認証処理を行うHTTPアダプタでは，要求電文，応答電文の電文フォーマットに次のXMLスキーマを定義してください。

要求電文（ヘッダ）

格納先

<サービスプラットフォームのインストールディレクトリ>¥CSC¥custom-adapter¥HTTP¥schema

使用する定義

adphttp_header_request1.xsd

要求電文（ボディ）

認証情報を受付の要求電文から取得し，HTTPアダプタでassertionを作成するため次のxsdを使用します。

格納先

<サービスプラットフォームのインストールディレクトリ>¥CSC¥custom-adapter¥HTTP¥schema

使用する定義

adphttp_body_form-data_jwt_assertion1.xsd

応答電文（ヘッダ）

格納先

<サービスプラットフォームのインストールディレクトリ>¥CSC¥custom-adapter¥HTTP¥schema

使用する定義

adphttp_header_response1.xsd

応答電文（ボディ）

応答電文ボディの解析をしないため，空のHTTPメッセージボディを表す電文フォーマットを使用します。

格納先

<サービスプラットフォームのインストールディレクトリ>¥CSC¥custom-adapter¥HTTP¥schema

使用する定義

adphttp_body_empty.fdx

●定義ファイルの作成

HTTPアダプタ実行時にOAuth 2.0の認証フローを使用するため，HTTPアダプタ定義ファイルのadphttp.oauth.authenticationプロパティの値に「true」を設定します。

認証情報をフォームデータとして送信するため，HTTPアダプタ実行環境プロパティファイルのadphttp.request.part.message.bindingプロパティの値に「form-data」を設定します。

●データ変換の定義

認証処理を行うHTTPアダプタでは，データ変換を使用して，要求電文に次に示す値を設定する必要があります。

要求電文（ヘッダ）

キー名称

設定値

/http-header-request/method要素

POST（固定文字列）

/http-header-request/uri-scheme-authority要素

https://login.salesforce.com（固定文字列）

/http-header-request/uri-path要素

/services/oauth2/token（固定文字列）

要求電文（ボディ）

キー名称

設定値

/http-body-form-data/grant_type要素

urn:ietf:params:oauth:grant-type:jwt-bearer（固定文字列）

/http-body-form-data/auth-info/claim/iss要素

Salesforceの接続アプリケーションから取得するコンシューマ鍵

/http-body-form-data/auth-info/claim/aud要素

Salesforceのアカウント名（メールアドレス形式）

/http-body-form-data/auth-info/claim/sub要素

https://login.salesforce.com（固定文字列）

/http-body-form-data/auth-info/claim/exp要素

HTTPアダプタが作成するJWTの有効期限

JWTの有効期限を5分以内で設定する（1970-01-01T0:0:0Z からの秒数）。

/http-body-form-data/auth-info/header/alg要素

JWTクレームセットの暗号化に使用するアルゴリズム

/http-body-form-data/auth-info/secretkey要素

csakeyaddコマンドで登録した秘密鍵の鍵ID

/http-body-form-data/auth-info/signature要素

Java暗号化アーキテクチャ標準アルゴリズム名（Signatureアルゴリズム）

電子署名に使用するSignatureオブジェクト作成に使用するアルゴリズムを設定する。

/http-body-form-data/auth-info/keytype要素

Java暗号化アーキテクチャ標準アルゴリズム名（KeyFactoryアルゴリズム）

秘密鍵を変換するKeyFactoryオブジェクト作成に使用するアルゴリズムを設定する。

秘密鍵が対応するアルゴリズムを設定する。

(d)　Webサービスを呼び出すHTTPアダプタの定義例

ここではWebサービスを呼び出す上で，定義が必要となる作業について説明します。

HTTPアダプタの基本的な定義の流れについては，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.13　HTTPアダプタを定義する」を参照してください。

電文フォーマットの設定

データ変換の定義

それぞれの定義について説明します。

●電文フォーマットの作成

Webサービスを呼び出すHTTPアダプタでは，要求電文，応答電文の電文フォーマットに次のXMLスキーマを定義してください。

要求電文（ヘッダ）

格納先

<サービスプラットフォームのインストールディレクトリ>¥CSC¥custom-adapter¥HTTP¥schema

使用する定義

adphttp_header_request1.xsd

要求電文（ボディ）

SalesforceのAPIを呼び出す場合は，要求電文ボディからデータを設定する必要はないため，空のHTTPメッセージボディを表す電文フォーマットを使用します。

格納先

<サービスプラットフォームのインストールディレクトリ>¥CSC¥custom-adapter¥HTTP¥schema

使用する定義

adphttp_body_empty.fdx

応答電文（ヘッダ）

格納先

<サービスプラットフォームのインストールディレクトリ>¥CSC¥custom-adapter¥HTTP¥schema

使用する定義

adphttp_header_response1.xsd

応答電文（ボディ）

応答電文ボディの解析をしないため，空のHTTPメッセージボディを表す電文フォーマットを使用します。

格納先

<サービスプラットフォームのインストールディレクトリ>¥CSC¥custom-adapter¥HTTP¥schema

使用する定義

adphttp_body_empty.fdx

●データ変換の定義

Webサービスを呼び出すHTTPアダプタでは，データ変換を使用して，要求電文に呼び出すAPIに合わせた値を設定する必要があります。

要求電文（ヘッダ）

キー名称

設定値※

/http-header-request/method要素

GET

/http-header-request/uri-scheme-authority要素

https://APIコールの送信先となる組織のインスタンス.salesforce.com

/http-header-request/uri-path要素

/services/data/v43.0/

/http-header-request/http-header-Authorization要素

Bearer△アクセストークン

/http-header-request/http-header-Authorization/@type属性

raw

（凡例）△：半角スペース

注※

設定値は，リソースのリストを取得する場合の設定例を示しています。

要求電文（ボディ）

要求電文ボディを設定しない場合でも，変数の初期化を行う必要があるため，変換先変数に要求電文ボディの変数を指定して，マッピングを行わずにデータ変換を行う必要がある。

2.17　外部コマンドの実行によるシステムとの接続

コマンドアダプタを利用することで，ビジネスプロセスから次に示す種類のファイルを実行できます。

EXEファイル（Windows）

BATファイル（Windows）

shファイル（Linux）

この機能によって，ほかのアダプタでサポートしているSOAPやRESTのような汎用的な接続インターフェースを持たない製品や，作成済みのユーザスクリプト資産をビジネスプロセスの連携に組み込むことができます。

2.17.1　前提条件

コマンドアダプタを利用するための前提条件を次に示します。

指定できる外部コマンドは，サービスプラットフォームのインストールマシンに存在するコマンドだけです。

外部コマンドプロセスを実行できるユーザは，サービスプラットフォームのJ2EEサーバを起動したユーザです。

GUIアプリケーションは起動しないでください。

外部コマンドからバックグラウンドプロセスは起動しないでください。

1回の呼び出しで実行できる外部コマンドは1つまでです。

複数の外部コマンドによるANDまたはORの実行制御も使用できません。

外部コマンドに対する入出力パイプは使用できません。

外部コマンドに対する標準入出力・標準エラー出力のファイルリダイレクトは使用できません。

注意事項

コマンドアダプタの利用は，Service Coordinator 09-71-01以降が前提です。

2.17.2　コマンドアダプタを使用した外部コマンドの実行

コマンドアダプタを使用した外部コマンド実行の流れを次の図に示します。

図2‒184　コマンドアダプタを使用した外部コマンド実行の流れ

ビジネスプロセスからコマンドアダプタへ，要求電文を利用して次に示す外部コマンド情報を渡します。

外部コマンドのファイルパス

コマンドライン引数

コマンドアダプタでは要求電文を解析し，同一マシン上に存在する外部コマンドを起動します。

外部コマンドプロセス実行後，コマンドアダプタからビジネスプロセスへ，応答電文を利用して次に示す終了情報が渡されます。

外部コマンドプロセスの終了コード

外部コマンドプロセスの標準出力への出力内容

ビジネスプロセスでは応答電文の終了コードを解析し，処理を分岐することができます。

2.17.3　要求電文を利用した外部コマンド情報の指定

ビジネスプロセスからコマンドアダプタを呼び出すときの要求電文には，次に示す情報を指定します。

外部コマンドのファイルパス

コマンドライン引数

外部コマンドのファイルパスとコマンドライン引数の関係を次に示します。

（例）コマンドライン文字列が「c:¥product¥sample.exe -x -i input.txt」の場合

注意事項

標準入力のファイルリダイレクトは使用できません。

また，上記例のコマンドライン文字列を生成する要求電文の作成例を次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<request xmlns="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/adapter/cmd/request"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <command-line>
                <command>c:¥product¥sample.exe</command>
                <argument1>-x</argument1>
                <argument2>-i</argument2>
                <argument3>input.txt</argument3>
        </command-line>
</request>

コマンドアダプタの要求電文フォーマットの作成については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.14(1)　電文フォーマットの作成」を参照してください。

(1)　外部コマンドのファイルパス

同一マシン上に存在する外部コマンドのファイルパスを指定します。

指定は必須です。絶対パスで指定することを推奨します。

注意事項

絶対パスで指定しない（ファイル名だけを指定，または相対パスで指定する）場合，実行するコマンドはOSのコマンドサーチ，およびJavaのAPI仕様に依存します。そのため，動作を保証しません。

ファイルパス中の環境変数の展開はしません。

要求電文で指定できる外部コマンドの条件を次の表に示します。

表2‒117　要求電文で指定できる外部コマンドの条件

OS

外部コマンドの条件

Windows

拡張子が次のどれかであること。

bat

exe

com

J2EEサーバユーザの実行権限があること。

Linux

J2EEサーバユーザの実行権限があること。

(2)　コマンドライン引数

外部コマンドに与えるコマンドライン引数を指定します。

指定は任意です。最大100個の引数を指定できます。

指定する際には，コマンドライン文字列の引数部分を，引数ごとに分割して指定する必要があります。

コマンドライン引数の指定例を次に示します。

2.17.4　応答電文で取得できる外部コマンドプロセスの終了情報

コマンドアダプタの応答電文から，次に示す情報を取得できます。

外部コマンドプロセスの終了コード

外部コマンドプロセスの標準出力への出力内容

注意事項

標準エラー出力への出力内容は，応答電文では取得できません。

標準エラー出力への出力内容は，製品が規定するログファイルに出力されます。詳細はマニュアル「サービスプラットフォーム システム構築・運用ガイド」の「7.7.17(6)　外部コマンドプロセスの標準エラー出力ログ」を参照してください。

コマンドアダプタの応答電文フォーマットの作成については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.14(1)　電文フォーマットの作成」を参照してください。

2.17.5　外部コマンドプロセスに関する動作オプションの設定

(1)　動作オプションの設定方法

コマンドアダプタでは，次の方法で動作オプションを指定できます。

定義ファイルで指定

要求電文で指定（一部オプションに限定）

オプション設定値の反映タイミングと対応する設定方法を次の表に示します。なお，定義ファイルと要求電文で同じオプションを指定した場合，要求電文の指定が優先されます。

表2‒118　外部コマンドプロセスに関する動作オプションの設定方法

反映タイミング

動作オプションの設定方法

コマンドアダプタ起動時

コマンドアダプタ実行環境プロパティファイルで設定します。

コマンドアダプタ実行環境プロパティファイルで設定できる項目の詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.15.3　コマンドアダプタ実行環境プロパティファイル」を参照してください。

リクエスト時

要求電文で設定します。

要求電文フォーマットの作成方法については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.14(1)　電文フォーマットの作成」を参照してください。

(2)　動作オプションに設定できる項目

コマンドアダプタでは，外部コマンドプロセスに関する次の項目を動作オプションに設定できます。

外部コマンドプロセスの環境変数

外部コマンドプロセスの作業ディレクトリ

タイムアウト時間

タイムアウト発生時の外部コマンドプロセス強制終了可否

応答電文で取得する標準出力の上限サイズ

(a)　外部コマンドプロセスの環境変数

外部コマンドプロセスだけで有効となる環境変数を定義できます。

外部コマンドプロセスの環境変数は，コマンドアダプタ内で生成されます。

生成の流れを次の図に示します。

図2‒185　外部コマンドプロセスの環境変数の生成の流れ

図内の処理について説明します。なお，次の番号は，図中の番号と対応しています。

J2EEサーバが持つシステム環境変数をコピーします。

システム環境変数については，System.getEnv()メソッドの仕様を参照してください。

ユーザが作成する「プロセス環境変数定義ファイル」が存在する場合は，1.でコピーしたシステム環境変数の内容を基に，プロセス環境変数を追加または上書きをします。

ファイルが存在しない場合は，1.でコピーしたシステム環境変数をそのまま使用します。

プロセス環境変数定義ファイルパスは，要求電文，またはコマンドアダプタ実行環境プロパティファイルで指定します。プロセス環境変数定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.15.2　プロセス環境変数定義ファイル」を参照してください。

外部コマンドプロセス起動時に環境変数（システム環境変数，およびプロセス環境変数）を適用します。

外部コマンドプロセスの環境変数は，コマンドアダプタのリクエストのたびに生成されます。したがって，ほかのリクエストで起動する外部コマンドプロセスや，J2EEサーバ，OSの環境変数に影響を与えません。

(b)　外部コマンドプロセスの作業ディレクトリ

作業ディレクトリとは，次の方法などで取得または設定できるものを指します。コマンドアダプタでは，この作業ディレクトリを変更できます。

Windowsの場合

コマンドプロンプトでcdコマンドを実行してカレントディレクトリを確認する

外部コマンドのショートカットのプロパティで［作業フォルダー］に指定する

Linuxの場合

シェルでpwdコマンドを実行してカレントディレクトリを確認する

(c)　タイムアウト時間

外部コマンドプロセスの実行が何らかの原因で終わらない場合，ビジネスプロセスにシステム例外を通知するためのタイムアウト時間を設定できます。

タイムアウト時間を経過しても外部コマンドプロセスが終了しなかった場合は，ビジネスプロセスにシステム例外が通知されます。

(d)　タイムアウト発生時の外部コマンドプロセス強制終了可否

タイムアウトが発生した際に，その時点で外部コマンドプロセスの強制終了を試みるかどうかを設定できます。

強制終了しない設定の場合，コマンドアダプタやHCSCサーバの状態に関係なく，起動した外部コマンドプロセスは処理を継続します。なお，タイムアウト発生後の外部コマンドプロセスの状態をサービスプラットフォームから調べる方法はありません。

(e)　応答電文で取得する標準出力の上限サイズ

コマンドアダプタの応答電文で取得する標準出力のサイズ上限値を設定できます。

コマンドアダプタは，標準出力の出力データを，出力された分だけ内部的に保持しています。標準出力のサイズ上限値を設定すると，そのサイズまでしか保持しません。そのため，次の場合にサイズを設定することで，コマンドアダプタが保持するデータのメモリ使用量を節約できます。

出力された標準出力の内容をビジネスプロセスで使用しない場合

出力された標準出力の内容を規定の長さまでしか使用しない場合

図2‒186　標準出力のサイズ制限のイメージ

注意事項

外部コマンドプロセスの標準出力のサイズが設定値を上回った場合，メッセージログに警告メッセージが出力されます。

2.17.6　実行許可コマンド定義ファイルによる実行制限

コマンドアダプタ利用時のセキュリティ対策として，実行する外部コマンド，およびコマンドライン引数を制限します。制限には，ユーザが作成する実行許可コマンド定義ファイルを使用します。実行許可コマンド定義ファイルは，正規表現を記述したテキストファイルです。定義例を次に示します。

C:¥¥Program Files¥¥SampleProduct¥¥bin¥¥sample(?:Start|Stop)¥.bat
C:¥¥Program Files¥¥SampleProduct¥¥bin¥¥sampleList¥.bat(?:△-l)?
C:¥¥Program Files¥¥SampleProduct¥¥bin¥¥sampleExport¥.bat△-o△¥w{8}¥.txt

（凡例）

△：半角空白

定義例のとおりに実行許可コマンド定義ファイルを作成した場合に，実行可能な外部コマンドと指定可能なコマンドライン引数を次の表に示します。

表2‒119　実行可能な外部コマンドとコマンドライン引数

外部コマンド

コマンドライン引数

C:¥Program Files¥SampleProduct¥bin¥sampleStart.bat

−

C:¥Program Files¥SampleProduct¥bin¥sampleStop.bat

−

C:¥Program Files¥SampleProduct¥bin¥sampleList.bat

−

C:¥Program Files¥SampleProduct¥bin¥sampleList.bat

-l

C:¥Program Files¥SampleProduct¥bin¥sampleExport.bat

-o

＜8文字の英数字＞.txt

（凡例）

−：指定しません。

2.18　SFTPサーバとの接続

SFTPアダプタを利用することで，サービスプラットフォームとSFTPサーバとの間でSFTPプロトコルによるファイル転送ができます。

2.18.1　前提条件

SFTPアダプタを利用するための前提条件を次に示します。

SFTPアダプタの連携先のSFTPサーバは，OpenSSHを利用したSSHサーバである必要があります。

SFTPアダプタは，SSHプロトコルのバージョンが「2」，かつSFTPプロトコルのバージョンが「3」のSFTPサーバをサポートしています。

2.18.2　SFTPアダプタを使用したシステム

SFTPアダプタは，SFTPサーバとサービスプラットフォームとの間でファイルを送受信するためのサービスアダプタです。

SFTPアダプタでは，ファイルに対する操作の単位をオペレーションと呼びます。

SFTPアダプタでサポートするオペレーションを次に示します。

PUTオペレーション

SFTPアダプタからSFTPサーバへファイルデータを送信します。

GETオペレーション

SFTPサーバから送信されたファイルデータをSFTPアダプタで受信します。

GETINFOオペレーション

SFTPサーバ側に存在するファイルの情報の一覧またはファイルの名前の一覧を取得します。

SFTPアダプタを使用したファイル送受信の例として，次のようなことができます。

移行元サーバから取得したファイル情報一覧を基にファイルを取得して移行先サーバへ送信する

クライアント側から転送されたファイルを変換して目的のサーバへ送信する

以降に，それぞれのシステムの例について説明します。

(1)　移行元サーバから取得したファイル情報一覧を基にファイルを取得して移行先サーバへ送信する

SFTPアダプタが取得した移行元サーバのファイル情報を基に，移行元サーバからファイル取得して移行先サーバへ送信する例を示します。

図2‒187　SFTPアダプタを利用したシステムの例（1）

図中の1.〜5.について説明します。

クライアントのプログラムからビジネスプロセスを実行するリクエストを発行します。

SFTPアダプタは移行元SFTPサーバにアクセスし，ファイル名一覧を取得します。

取得したファイル名一覧からファイル名を1つずつ取得します。

SFTPアダプタは取得したファイル名を使用して，移行元SFTPサーバからファイルを受信し，共通フォルダに保存します。

SFTPアダプタは，共通フォルダに保存されたファイルを移行先SFTPサーバへ送信します。

(2)　クライアント側から転送されたファイルを変換して目的のサーバへ送信する

ここでは，クライアント側から送信されたファイルをHCSCサーバでファイル変換し，変換後のファイルをSFTPアダプタからSFTPサーバに送信するシステムの例を示します。

図2‒188　SFTPアダプタを利用したシステムの例（2）

図中の1.〜7.について説明します。

クライアントのプログラムからHCSCサーバへファイルを送信します。

FTP受付は作業フォルダを作成し，受信したファイルを中間ファイルとして生成します。

ファイル操作アダプタは，FTP受付で生成された中間ファイルをファイル変換オペレーションによって変換します。

SFTPアダプタは，変換後のファイルを目的のSFTPサーバへ送信します。

送信後にSFTPアダプタはSFTPサーバのファイル情報一覧を取得します。

Java呼出アクティビティでファイル情報一覧から該当するファイルのファイルサイズを取得し，ファイル変換オペレーションの応答電文に設定されているファイルサイズと比較します。

ビジネスプロセス終了後に，FTP受付は作業フォルダを削除します。

2.18.3　SFTPアダプタで設定できるファイル転送の機能

SFTPアダプタで設定できるファイル転送機能に関する情報を次に示します。

表2‒120　設定できるファイル転送機能に関する情報

大分類

中分類

小分類

説明

SFTP通信

SFTPコマンド

SFTPアダプタが実行するコマンドは，次の2つに大別できます。

SFTPアダプタのオペレーションに対応するSFTPコマンド

ユーザが要求電文に指定するユーザ指定のSFTPコマンド

SFTPコマンドの詳細は，「2.18.5(3) SFTPアダプタが実行するコマンド」を参照してください。

文字セット

UTF-8固定です。

データ圧縮

ファイル転送時にデータを圧縮します。

データ圧縮時の圧縮レベルは変更できません。

ファイルの書き込み形式

上書き

転送先にファイルが存在する場合にファイルを上書きします。

ファイルが存在しない場合は新規に作成します。

追記

転送先にファイルが存在する場合にファイルに追記します。

ファイルが存在しない場合は新規に作成します。

複数ファイルの転送

複数ファイルの転送およびディレクトリ単位の転送はできません。

タイムアウト

セッション接続時

指定した時間を経過してもSFTPサーバへのセッション接続要求が終了しなかった場合は例外を発生させます。

データ読み込み

指定した時間を経過してもSFTPサーバから応答データが読み込めなかった場合に例外を発生させます。

IPアドレスの固定

SFTPアダプタが使用するIPアドレスを固定にします。

ポート番号の固定

SFTPアダプタが使用するポート番号を固定にします。

IPv6サポート

SFTPアダプタが接続するSFTPサーバおよびSFTPアダプタが使用するIPアドレスを，IPv6形式で指定できます。

セキュリティ

ホスト認証

厳格なホスト鍵チェック

サーバの正当性を確保するために，ホスト公開鍵が記載されたファイルを使用してホスト認証をします。

ユーザ認証

パスワード認証

SFTPサーバが存在するマシンのユーザ名とパスワードを使用して認証をします。

公開鍵認証

公開鍵・秘密鍵を使用した公開鍵暗号方式で認証をします。

暗号

SFTPアダプタで使用できる暗号の優先順位を変更できます。

ただし，SFTPアダプタで使用できる暗号が決まっているため，暗号の追加はできません。

排他制御

占有ロック

共有フォルダ内のファイルの更新処理時に，排他管理をします。

他プロセスまたは他スレッドとの競合によって排他管理に失敗したときは，指定間隔おきに指定回数まで排他取得処理をリトライします。

共有ロック

共有フォルダ内のファイルの参照処理時に，排他管理をします。

他プロセスまたは他スレッドとの競合によって排他管理に失敗したときは，指定間隔おきに指定回数まで排他取得処理をリトライします。

ユーザ認証情報管理コマンド

パスワード認証情報管理

アカウント登録

パスワード認証に使用するユーザおよびパスワードを登録します。

アカウント一覧表示

登録されているユーザを表示します。

アカウント削除

登録されているユーザおよびパスワードを削除します。

コマンド実行のログ

コマンド実行時の例外情報をログとして出力します。

公開鍵認証情報管理

秘密鍵の登録

公開鍵認証に使用する秘密鍵およびパスフレーズ（任意）を登録します。

鍵ファイルの中身を管理するのではなく，鍵ファイルのファイルパスを管理します。

秘密鍵の一覧表示

登録されている秘密鍵のファイルパスを表示します。

秘密鍵の削除

登録されている秘密鍵およびパスフレーズを削除します。

コマンド実行のログ

コマンド実行時の例外情報をログとして出力します。

ログ・トレース

メッセージログ

ログおよびトレース情報を出力します。

保守ログ（メソッドトレース）

性能解析トレース

例外ログ

SFTPプロトコルトレース

2.18.4　SFTPアダプタのファイルアクセス方式

SFTPアダプタのファイルへのアクセス方式は次の2つです。

作業フォルダ内の中間ファイルにアクセスする方式

クラスタ構成内で共通に利用する共通フォルダのファイルにアクセスする方式

SFTPアダプタからフォルダ内のファイルにアクセスするときのデータの流れを次の図に示します。

図2‒189　フォルダ内のファイルにアクセスするときのデータの流れ

ファイル操作がPUTオペレーションまたはGETオペレーションの場合，作業フォルダを利用するか共通フォルダを利用するかの判定は，要求電文のローカル側フォルダ（local-folder）のcommon属性の設定によって異なります。ローカル側にフォルダが設定されていないときは作業フォルダを使用し，設定されているときは共通フォルダを使用します。

なお，作業フォルダや共通フォルダを使用する場合，フォルダへのパスは，HCSCサーバランタイム定義ファイルに設定する必要があります。

GETINFOオペレーションは，ファイル一覧情報の取得結果を応答電文にだけ格納します。ファイル一覧情報の取得結果は，共通フォルダおよび作業フォルダには出力されません。

PUTオペレーションおよびGETオペレーションで共通フォルダを使用するときに指定するパスを次に示します。

表2‒121　共通フォルダを使用するときに指定するパス

種別

指定するパス

ローカルパス

<要求電文のローカル側フォルダから取得した共通フォルダ定義名に対応する共通フォルダ>/<要求電文のローカル側ファイル名>

リモートパス

<要求電文のリモートパス名>

SFTPアダプタでは，共通フォルダルートの配下にサブフォルダを作成できます。この作成したサブフォルダの相対パスを指定すると，ファイルを転送できます。

共通フォルダルートの配下に作成したサブフォルダの相対パスは，各オペレーションの要求電文または応答電文のローカル側ファイル名（local-file-name）に指定してください。指定例を次に示します。

<request>
  ：
  <local-folder common="true">default</local-folder>
  <local-file-name>/folder1/folder2/a.txt</local-file-name>
  ：
</request>

注意事項

作業フォルダについては，相対パスの指定はできません。

共通フォルダルートより上位のパスを指定した場合，エラーになります。

相対パスの先頭のファイル区切り文字（"/"）は省略できます。

2.18.5　SFTPアダプタとSFTPサーバ間の通信

SFTPアダプタとSFTPサーバ間の通信について説明します。

(1)　SFTPサーバとの接続

SFTPサーバとの接続では，SFTPアダプタはSFTPサーバに対してセッション接続を要求します。セッション接続では次の処理が実行されます。

アルゴリズムネゴシエーション

ホスト認証

ユーザ認証

セッション接続は，リクエストごとに接続または切断をし，ほかのリクエストで再利用をしません。

以降で，セッション接続時の処理について説明します。

(a)　アルゴリズムネゴシエーション

暗号化通信路の確立のために，次の情報のリスト（以降，アルゴリズムのリストと呼びます）をSFTPアダプタとSFTPサーバ間で交換します。

鍵交換方式

共通鍵暗号方式

メッセージ認証コード

ホスト認証の方式

圧縮アルゴリズム

SFTPアダプタがサポートするアルゴリズムのリストを次に示します。

表2‒122　アルゴリズムのリスト

種別

アルゴリズムのリスト

鍵交換方式

ecdh-sha2-nistp256

diffie-hellman-group14-sha1

diffie-hellman-group-exchange-sha256

diffie-hellman-group-exchange-sha1

diffie-hellman-group1-sha1

共通鍵暗号方式

aes128-ctr

aes128-cbc

3des-cbc

blowfish-cbc

aes192-ctr

aes192-cbc

aes256-ctr

aes256-cbc

メッセージ認証コード

hmac-md5

hmac-sha1

hmac-sha2-256

hmac-sha1-96

hmac-md5-96

ホスト認証の方式

ssh-rsa

ssh-dss

ecdsa-sha2-nistp256

ecdsa-sha2-nistp384

ecdsa-sha2-nistp521

圧縮アルゴリズム

zlib@openssh.com

zlib

使用されるアルゴリズムは，クライアントから送信されたリストを先頭から順に参照し，サーバのリストに存在するものが選ばれます。

暗号の優先順位は，上記の表の記載順となります（上位にあるほど優先順位が高い）。

アルゴリズムの優先順位は，SFTPアダプタ実行環境プロパティファイルで入れ替えることができます。

(b)　ホスト認証

ホスト認証とは，サーバのなりすましを判断するための認証です（クライアント側でサーバの正当性を確保します）。

ホスト認証では厳格なホスト公開鍵チェックをすることによって，接続先が目的のサーバであるかどうかを検証できます。

●厳格なホスト公開鍵チェックをする場合

SFTPアダプタのホスト認証は，ホスト公開鍵が記載されたファイル（以降，ホスト公開鍵ファイルと呼びます）を使用します。

SFTPサーバから受け取ったホスト公開鍵とSFTPアダプタ実行環境プロパティファイルで設定したホスト公開鍵を比較し，ホスト公開鍵が存在しない場合や，ホスト公開鍵が変更されている場合はエラーになります。

ホスト認証の定義手順については，「2.18.9(1)　ホスト認証の認証情報の定義手順」を参照してください。

●厳格なホスト公開鍵チェックをしない場合

ホスト公開鍵のチェックをしません。

(c)　ユーザ認証

ユーザ認証とは，クライアントが指定したユーザがサーバにログインできるかをサーバ側が確認するための認証です。SFTPアダプタでは，ユーザ認証を省略することはできません。

SFTPアダプタでサポートするユーザ認証を次に示します。

●パスワード認証

SFTPサーバが存在するマシンのユーザ名とパスワードを使用して認証をします。

パスワード認証の定義手順については，「2.18.9(2)　パスワード認証の認証情報の定義手順」を参照してください。

●公開鍵認証

公開鍵・秘密鍵を使用した公開鍵暗号方式で認証をします。

公開鍵認証の定義手順については，「2.18.9(3)　公開鍵認証の認証情報の定義手順」を参照してください。

使用できる公開鍵・秘密鍵の条件を次に示します。

●公開鍵・秘密鍵の種類

次のどれかである必要があります。

DSA

RSA

ECDSA

●公開鍵・秘密鍵の鍵長

次の条件を満たしていない場合，動作は保証されません。

RSAの場合の鍵長は，2048バイトまたは4096バイトのどちらか

ECDSAの場合の鍵長は，256バイト以下

●パスフレーズを設定した秘密鍵の暗号化

秘密鍵は次に示すどれかの共通鍵暗号方式で暗号化されていなければなりません。

3des-cbc

aes128-cbc

aes192-cbc

aes256-cbc

上記以外の共通鍵暗号方式で暗号化した場合は動作は保証されません。

●公開鍵・秘密鍵の形式

次のどちらかである必要があります。

OpenSSL's PEM format

鍵ファイルのヘッダが，「-----BEGIN RSA」，「-----BEGIN DSA」，「-----BEGIN EC」のどれかで始まる形式

PKCS#8形式

「-----BEGIN PRIVATE」で始まる形式

なお，パスフレーズを設定したPKCS#8形式の秘密鍵は使用できません。使用した場合，動作は保証されません。

(2)　ファイル転送のパターン

SFTPアダプタで実行可能なファイル転送のパターンを次に示します。

SFTPアダプタからSFTPサーバへのファイル転送

SFTPサーバからSFTPアダプタへのファイル転送

SFTPサーバのファイルリストの取得

以降で，それぞれのパターンについて説明します。

(a)　SFTPアダプタからSFTPサーバへのファイル転送

SFTPアダプタからSFTPサーバへファイルを転送します。

1リクエストで転送できるファイルは1つだけで，ディレクトリ単位での転送や複数のファイルの転送はできません。

また，転送先にすでにファイルがある場合は上書き，または追記をします。

要求電文のoverwrite-data要素の値がtrueの場合は上書きを，要素の値がfalseの場合は追記をします。

ファイル転送に失敗した場合，SFTPアダプタは後処理として転送先のファイルは削除しません。そのため，転送先のファイルが削除されるかどうかはSFTPサーバに依存します。

(b)　SFTPサーバからSFTPアダプタへのファイル転送

SFTPサーバからSFTPアダプタへファイルを転送します。

1リクエストで転送できるファイルは1つだけで，ディレクトリ単位での転送や複数のファイルの転送はできません。

また，転送先にすでにファイルがある場合は上書きをします。

ファイル転送に失敗した場合，後処理としてローカル側のファイルの削除を試みます。

(c)　SFTPサーバのファイルリストの取得

SFTPサーバのファイル情報の一覧，またはファイル名一覧を取得します。

ファイル情報とファイル名のどちらの一覧を取得するかは，要求電文で指定します。

また，取得対象は要求電文で指定し，ディレクトリを指定した場合はディレクトリ配下のファイルの情報を，ファイルを指定した場合は該当するファイルの情報を取得します。

ファイル情報の一覧，またはファイル名一覧の取得結果は応答電文に格納し，ファイルへは出力しません。

ファイル情報の一覧取得では，取得したファイルごとに応答電文に格納されます。

応答電文に格納されるときのフォーマットを次に示します。

パーミッション ユーザ識別子 グループ識別子 ファイルサイズ(バイト) 更新時刻 ファイル名

ファイルへは，各項目を空白区切りで出力します。

ファイルへの出力例を次に示します。

-rw-r--r-- 0 0 9936 Thu Oct 16 05:28:47 JST 2018 data1

(3)　SFTPアダプタが実行するコマンド

SFTPアダプタが実行するコマンドは，次の2つに大別できます。

SFTPアダプタのオペレーションに対応するSFTPコマンド

ユーザが要求電文に指定するユーザ指定のSFTPコマンド

次に，それぞれのSFTPコマンドについて説明します。

(a)　SFTPアダプタのオペレーションに対応するSFTPコマンド

オペレーションに対応するSFTPコマンドは，SFTPアダプタが要求電文から実行するオペレーションを自動的に判別して実行します。

SFTPアダプタが自動的にSFTPコマンドを実行するため，ユーザはコマンドの書式を考慮する必要はありません。

SFTPアダプタのオペレーションに対応するSFTPコマンドの一覧を次に示します。

表2‒123　SFTPアダプタのオペレーションに対応するSFTPコマンドの一覧

コマンド名

説明

対応するオペレーション

get

リモートマシンのファイルをローカルマシンにダウンロードします。

GETオペレーション

ls

リモートマシン上のファイル一覧またはファイル名一覧を取得します。

GETINFOオペレーション

put

ローカルマシンのファイルをリモートマシンにアップロードします。

PUTオペレーション

(b)　ユーザが要求電文に指定するユーザ指定のSFTPコマンド

ユーザ指定のSFTPコマンドは，要求電文のsftp-commands-beforeおよびsftp-commands-afterに実行指示がある場合だけコマンドが実行されます。

ユーザは，コマンドの機能および書式を考慮した上で，要求電文にSFTPコマンドを指定する必要があります。

ユーザ指定のSFTPコマンドの一覧を次に示します。

表2‒124　ユーザ指定のSFTPコマンドの一覧

コマンド名

コマンドの形式

説明

cd

cd <変更先のディレクトリのパス>※

リモート側のカレントディレクトリを変更します。

cdコマンドで変更したカレントディレクトリは，再度cdコマンドを実行するか，リクエストが終了するまで有効です。

mkdir

mkdir <作成するディレクトリのパス>

リモートマシン上にディレクトリを作成します。

rename

rename <変更前のファイルのパス> <変更後のファイルのパス>

リモートマシン上のファイルの名前を変更します。

rm

rm <削除するファイル名>

リモートマシン上のファイルを削除します。

rmdir

rmdir <削除するディレクトリ名>

リモートマシン上のディレクトリを削除します。

ディレクトリ配下が空の場合だけ削除できます。

注※

接続先がWindows上のSFTPサーバの場合は，マルチバイト文字を含むディレクトリ名を変更先のディレクトリのパスに指定しないでください。指定した場合の動作は保証されません。

注意事項

コマンドの形式に誤りがある場合，SFTPアダプタは例外を通知します。

複数のコマンドを指定する場合，半角のセミコロン（;）で区切ってください。

複数のコマンドを指定した場合，先頭から順にコマンドを実行します。

コマンド引数は，半角の空白区切りで指定してください。

コマンド引数の区切りに使用する空白と，コマンドの区切りに使用するセミコロン（;）は，コマンド引数に指定できません。指定した場合の動作は保証されません。

コマンド引数の内容については，SFTPアダプタでチェックされません。

(4)　転送データの圧縮

SFTPアダプタは，データを圧縮して転送できます。

転送データの圧縮は，要求電文またはSFTPアダプタ実行環境プロパティファイルのどちらかで指定できます。要求電文フォーマットの作成方法については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.15　SFTPアダプタを定義する」の電文フォーマットの作成に関する説明を参照してください。SFTPアダプタ実行環境プロパティファイルで設定できる項目の詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.16.1　SFTPアダプタ実行環境プロパティファイル」を参照してください。

注意事項

データを圧縮して転送する場合，転送速度が低下することがあります。

(5)　SFTPサーバとの接続の切断

リクエストの正常終了，異常終了に関係なく，SFTPアダプタはリクエスト終了時に，SFTPサーバとのセッションを切断します。

2.18.6　SFTPアダプタのタイムアウトを監視するポイント

SFTPアダプタでタイムアウトを監視するポイントを次に示します。

図2‒190　SFTPアダプタでタイムアウトを監視するポイント

SFTPアダプタでは，セッション接続タイムアウトおよびデータ読み込みタイムアウトを設定できます。各タイムアウト値は，SFTPアダプタ実行環境プロパティファイルで設定できます。SFTPアダプタ実行環境プロパティファイルの詳細は，マニュアル「サービスプラットフォームリファレンス」の「6.16.1　SFTPアダプタ実行環境プロパティファイル」を参照してください。

(1)　セッション接続タイムアウト

SFTPサーバへのセッション接続要求時に，セッション接続タイムアウトに指定した時間を経過しても接続要求が終了しない場合，SFTPアダプタは例外を通知します。

設定できるパラメタを次の表に示します。

表2‒125　セッション接続タイムアウトの設定

値

キー名称

デフォルト値

セッション接続タイムアウト（秒）

sftpadp.session.timeout

10

また，セッション接続要求時に相手先ビジーなどで接続を確立できなかった場合，セッション接続タイムアウトに指定されたタイムアウト値までSFTPサーバへの接続をリトライします。

セッション接続タイムアウトのタイムアウト値には，リトライ回数とリトライ間隔を指定できます。リトライ回数に達してもセッション接続を確立できなかった場合，SFTPアダプタは例外を通知します。

設定できるパラメタを次の表に示します。

表2‒126　セッション接続タイムアウトのタイムアウト値の設定

値

キー名称

デフォルト値

セッションを確立できなかったときのリトライ回数※1

sftpadp.session-con.retry.count

5

セッションを確立できなかったときのリトライ間隔※2（秒）

sftpadp.session-con.retry.interval

2

注※1

値に0を指定した場合，リトライしません。

注※2

値に0を指定した場合，間隔を空けないでリトライします。

(2)　データ読み込みタイムアウト

SFTPサーバからの応答データの読み込み（アルゴリズムネゴシエーションの結果取得，GETオペレーション実行時のファイルデータ取得など）で，データ読み込みタイムアウトに指定した時間を経過しても応答データがSFTPサーバから読み込めない場合，SFTPアダプタは例外を通知します。

設定できるパラメタを次の表に示します。

表2‒127　データの読み込みタイムアウトの設定

値

キー名称

デフォルト値

データ読み込みタイムアウト（秒）

sftpadp.data-read.timeout

60

2.18.7　SFTPアダプタの排他管理

共通フォルダ内のファイルをPUTオペレーションでSFTPサーバに転送するとき，共通フォルダ内のファイルに対して共有ロックが設定されます。

また，GETオペレーションで共通フォルダにファイルを取得するとき，共通フォルダのファイルに対して占有ロックが設定されます。

共有ロックまたは占有ロックの設定時に，ほかのプロセス，またはほかのスレッドとの競合によって，排他取得処理に失敗することがあります。排他取得タイムアウトでは，SFTPアダプタが共有ロックまたは占有ロックの取得に失敗したときのリトライ回数およびリトライ間隔を設定できます。

設定できるパラメタを次の表に示します。

表2‒128　排他取得タイムアウトの設定

値

キー名称

デフォルト値

共有ロック失敗時のリトライ回数

sftpadp.read-lock.retry.count

0

共有ロック失敗時のリトライ間隔（秒）

sftpadp.read-lock.retry.interval

1

占有ロック失敗時のリトライ回数

sftpadp.write-lock.retry.count

0

占有ロック失敗時のリトライ間隔（秒）

sftpadp.write-lock.retry.interval

1

タイムアウト時間は，これらのパラメタに指定した値を使った次の計算式で求められます。

共有ロックの場合

共有ロック失敗時のリトライ回数×共有ロック失敗時のリトライ間隔＋排他取得時のファイルアクセス時間

占有ロックの場合

占有ロック失敗時のリトライ回数×占有ロック失敗時のリトライ間隔＋排他取得時のファイルアクセス時間

リトライ回数およびリトライ間隔は，SFTPアダプタ実行環境プロパティファイルで設定できます。SFTPアダプタ実行環境プロパティファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.16.1　SFTPアダプタ実行環境プロパティファイル」を参照してください。

2.18.8　SFTPアダプタが使用するIPアドレスおよびポート番号の指定

SFTPアダプタが使用するIPアドレスおよびポート番号を指定できます。

(1)　SFTPクライアントで使用するIPアドレス

SFTPクライアントのIPアドレスは，SFTPアダプタ実行環境プロパティファイルのsftpadp.client-ipaddrプロパティで指定します。指定を省略した場合は，システムによってローカルマシンのIPアドレスが自動的に割り当てられます。ローカルマシンのIPアドレスは，java.net.NetworkInterfaceクラスでまとめて取得し，そのうち最初に見つかった実IPアドレスを優先して割り当てます。実IPアドレスが存在しない場合は，ループバックアドレスを割り当てます。

(2)　SFTPクライアントで使用するポート番号

SFTPアダプタは指定されたポート番号の最小値，または前回使用したポート番号の次※を待ち受けポート番号候補とします。待ち受けポート番号候補を使用できる場合，このポート番号を採用します。待ち受けポート番号候補を使用できない場合は，次のポート番号※を候補とし，使用可否を確認します。範囲内のすべてのポートが使用できない場合は，SFTPアダプタが例外を返します。

注※

前回使用したポート番号が最大値の場合，最小値が次のポート番号となります。

なお，ポート番号を設定するためのプロパティの指定を省略した場合は，システムによって任意のポート番号が割り当てられます。

2.18.9　SFTPアダプタからファイルを送信するときの認証

ここでは，SFTPアダプタからファイルを送信するときのホスト認証の認証情報の定義手順，パスワード認証の認証情報の定義手順，および公開鍵認証の認証情報の定義手順について説明します。

(1)　ホスト認証の認証情報の定義手順

ホスト認証を実施する場合の認証情報の設定手順を次に示します。

ホスト公開鍵ファイルの作成

SFTPアダプタにはホスト公開鍵ファイルを作成する機能がないため，ホスト公開鍵ファイルをユーザが作成する必要があります。

ホスト公開鍵ファイルを作成するには，リモートマシン上のSFTPサーバからホスト公開鍵を取得し，ローカルマシン（実行環境）で作成したファイル（ホスト公開鍵ファイル）に鍵情報を記載します。

SFTPアダプタで使用できるホスト公開鍵ファイルの形式を次に示します。

なお，次に示す形式に従っていない場合は，動作は保証されません。

ホスト△鍵の種類△base64エンコードされた鍵

（凡例）

△：半角スペースを示します。

ホスト公開鍵ファイルの設定

SFTPアダプタ実行環境プロパティファイルのsftpadp.host-auth-inf-filepathプロパティに，手順1.で作成したホスト公開鍵ファイルのファイルパスを設定します。

ホスト認証の実施の設定

要求電文のrequest/host-auth/strict-hostkey-checking要素，またはSFTPアダプタ実行環境プロパティファイルのsftpadp.strict-hostkey-checkingプロパティに「true」を設定します。

(2)　パスワード認証の認証情報の定義手順

パスワード認証を実施する場合の認証情報の設定手順を次に示します。

ユーザ名およびパスワードの登録

csauseraddコマンドを実行し，パスワード認証で使用するユーザ名およびパスワードを登録します。コマンドで登録した情報は，コマンド実行時に指定したパスワード認証情報定義ファイルに設定されます。

csauseraddコマンドの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「csauseradd（パスワード認証のユーザ情報の登録・更新）」を参照してください。

パスワード認証の実施の設定

要求電文のrequest/user-auth/user-auth-type要素，またはSFTPアダプタ実行環境プロパティファイルのsftpadp.user-auth-typeプロパティに「password」を設定します。

パスワード認証情報定義ファイルの設定

SFTPアダプタ実行環境プロパティファイルのsftpadp.password-auth-inf-filepathプロパティにパスワード認証情報定義ファイルのファイルパスを設定します。

パスワード認証で使用するユーザの指定

要求電文のrequest/user-auth/user-auth-info要素，またはSFTPアダプタ実行環境プロパティファイルのsftpadp.password-auth-infoプロパティにユーザ名を設定します。

(3)　公開鍵認証の認証情報の定義手順

公開鍵認証を実施する場合の認証情報の設定手順を次に示します。

公開鍵・秘密鍵の作成

SFTPアダプタには公開鍵・秘密鍵を作成する機能がないため，公開鍵・秘密鍵をユーザが作成する必要があります。

公開鍵・秘密鍵は，ローカルマシン（実行環境）で作成します。作成した公開鍵は公開鍵ファイルとして，秘密鍵は秘密鍵ファイルとして，それぞれローカルマシン上に保存します。

公開鍵ファイルの格納

公開鍵ファイルはリモートマシン上に格納します（公開鍵ファイルの格納場所はSFTPサーバに依存します）。

秘密鍵ファイルの登録

csakeyaddコマンドを実行し，秘密鍵ファイルに関する情報を登録します。コマンドで登録した情報は，コマンド実行時に指定した公開鍵認証情報定義ファイルに設定されます。

csakeyaddコマンドの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「csakeyadd（公開鍵認証の秘密鍵情報の登録・更新）」を参照してください。

公開鍵認証情報定義ファイルの設定

SFTPアダプタ実行環境プロパティファイルのsftpadp.publickey-auth-inf-filepathプロパティに，手順3.で登録した公開鍵認証情報定義ファイルのファイルパスを設定します。

公開鍵認証の実施の設定

要求電文のrequest/user-auth/user-auth-type要素，またはSFTPアダプタ実行環境プロパティファイルのsftpadp.user-auth-typeプロパティに「publickey」を設定します。

公開鍵認証で使用する秘密鍵の指定

要求電文のrequest/user-auth/user-auth-info要素，またはSFTPアダプタ実行環境プロパティファイルのsftpadp.publickey-auth-infoプロパティにcsakeyaddコマンド実行時に設定した鍵IDを設定します。

2.18.10　SFTPアダプタの要求電文に指定できるリモートのファイルパス

SFTPアダプタの要求電文では，リモートのファイルパスに絶対パス，または相対パスを指定できます。

(1)　リモートのファイルパスを指定できる要素

リモートのファイルパスを指定できる要素を次に示します。

remote-path要素

PUTオペレーション実行時のファイル転送先

GETオペレーション実行時のファイル転送元

getinfo-path要素

GETINFOオペレーション実行時のファイル情報の取得対象

sftp-commands-before要素

コマンド引数に指定するファイルパス

sftp-commands-after要素

コマンド引数に指定するファイルパス

(2)　相対パスの基準

相対パスの基準となるディレクトリは次のどちらかです。

ユーザのホームディレクトリ

cdコマンドで移動したディレクトリ

(3)　絶対パスの指定方法

リモートのファイルパスを絶対パスで指定する場合は，ファイルパスの先頭に「/」を付与してください。

注意事項

ファイルパスの先頭の文字が「/」でない場合は，相対パスが指定されたと見なされます。

2.19　ファイルイベント連携を使用したファイルの監視

ファイルイベント連携とは，特定のフォルダを監視し，ファイルの作成をファイルイベントとして検知することで，サービスプラットフォームにファイルイベントを通知する機能（インターフェース）です。

2.19.1　ファイルイベント連携を使用したシステム間連携

ファイルイベント連携をすることで，ファイルの作成を契機として，HCSCサーバ上でビジネスプロセスを利用した処理を実行できます。例えば，HCSCサーバが別途提供する機能を使って，ファイル変換機能やFTPなどのプロトコルと連携することによって，システム間の連携もできるようになります。

FTP連携機能の詳細については，「8.　FTPと連携してファイルを転送する機能（FTP連携）」を参照してください。

ファイルイベント連携を利用したシステム間連携のイメージを次の図に示します。

図2‒191　システム間の連携イメージ

2.19.2　ファイルイベント連携で監視するフォルダおよびファイル

ファイルイベント連携で使用するフォルダ，およびファイルについて説明します。

監視対象のフォルダは次のどちらかが選択できます。選択したフォルダによって監視対象のファイルが異なります。

監視フォルダ

監視フォルダ内の更新完了通知ファイルを監視します。

共通フォルダ

共通フォルダ内の取得対象ファイルを監視します。

監視対象のフォルダ内にファイルが作成された場合のイベントを処理するには，ファイルイベント受付を使用します。次に，ファイルイベント連携の処理の流れを示します。

(1)　監視フォルダを監視する場合の処理の流れ

監視フォルダを監視する場合の，ファイルイベント受付とファイルイベント連携の処理の流れを次の図に示します。

図2‒192　ファイルイベント連携機能の処理の流れ（監視フォルダを監視する場合）

図中の1.〜7.について説明します。

ファイル監視機能が監視フォルダを監視します。

クライアントから共通フォルダ内に取得対象ファイルを転送します。

取得対象ファイルの転送完了後に，監視フォルダ内に取得対象ファイルと同名の更新完了通知ファイルを作成します。

更新完了通知ファイルの作成を検知します。

ファイルイベント受付にファイルイベントの検知を通知します。

取得対象ファイルの存在を確認します。

ビジネスプロセスを呼び出します。

(2)　共通フォルダを監視する場合の処理の流れ

共通フォルダを監視する場合の，ファイルイベント受付とファイルイベント連携機能の処理の流れを次の図に示します。

図2‒193　ファイルイベント連携機能の処理の流れ（共通フォルダを監視する場合）

図中の1.〜6.について説明します。

ファイル監視機能が共通フォルダを監視します。

クライアントから共通フォルダ内に取得対象ファイルを転送します。

取得対象ファイルの作成を検知します。

ファイルイベント受付にファイルイベントの検知を通知します。

取得対象ファイルが更新中かどうか確認します。

ビジネスプロセスを呼び出します。

2.20　カスタム受付を使用した場合のシステムとの接続

サービスプラットフォームでは，ユーザが任意の受付を作成できるようにカスタム受付フレームワークを提供しています。このカスタム受付フレームワーク上でユーザが作成したJ2EEアプリケーションを動作させることで，任意のプロトコルに対応した受付（カスタム受付）を開発できます。

2.20.1　カスタム受付の構成

カスタム受付は，開発者が作成する受付処理と，カスタム受付フレームワークから構成されるJ2EEアプリケーションです。

開発者が作成する受付処理の内容と，カスタム受付フレームワークで実行される処理の内容を次に示します。

開発者が作成する受付処理の内容

サービスリクエスタからのサービス部品呼び出し要求を受け付ける処理

カスタム受付フレームワークに要求電文を渡す処理

カスタム受付フレームワークから返ってきた応答電文を，サービスリクエスタに返す処理

カスタム受付フレームワークで実行される処理

受付処理から渡された要求電文を，HCSCメッセージ配送制御に渡す処理

HCSCメッセージ配送制御から返された応答電文を，受付処理に返す処理

データ変換定義に従って，要求電文または応答電文のデータ変換を行う処理

2.20.2　カスタム受付フレームワークの概要

カスタム受付フレームワークは，カスタム受付を開発および動作させるためのフレームワークです。カスタム受付フレームワークは，開発者が作成したカスタム受付を，サービスプラットフォームの実行環境で受付として動作させるための仕組みを提供しています。

カスタム受付を使用したサービス部品の呼び出しを次の図に示します。

図2‒194　カスタム受付を利用したサービス部品の呼び出し

図中の1.〜8.について説明します。

説明

受付処理は，サービスリクエスタからサービス部品呼び出し要求を受け付けます。

受付処理は，サービスリクエスタから受け取った要求電文を，カスタム受付フレームワークに渡します。

カスタム受付フレームワークは，要求電文のデータ変換をします。

カスタム受付フレームワークは，HCSCメッセージ配送制御を呼び出します。

カスタム受付フレームワークは，HCSCメッセージ配送制御から，応答電文を受け取ります。

カスタム受付フレームワークは，応答電文のデータ変換をします。

受付処理は，カスタム受付フレームワークから応答電文を受け取ります。

受付処理は，サービスリクエスタに応答電文を返します。

2.21　汎用カスタムアダプタを使用した場合のシステムとの接続

サービスプラットフォームが提供している次のアダプタでは対応できないプロトコルを持つシステムのサービス部品を呼び出して実行するには，汎用カスタムアダプタの開発が必要です。

SOAPアダプタ

SessionBeanアダプタ

MDB（WS-R）アダプタ

MDB（DBキュー）アダプタ

DBアダプタ

TP1アダプタ

ファイルアダプタ

Object Accessアダプタ

Message Queueアダプタ

FTPアダプタ

ファイル操作アダプタ

メールアダプタ

HTTPアダプタ

コマンドアダプタ

SFTPアダプタ

Kafkaアダプタ

gRPCアダプタ

サービスプラットフォームでは，汎用カスタムアダプタの開発を容易にするためのフレームワークであるカスタムアダプタ開発フレームワークを提供しています。

汎用カスタムアダプタの概要とカスタムアダプタ開発フレームワークの概要を次に示します。

2.21.1　汎用カスタムアダプタの概要

汎用カスタムアダプタは，サービスリクエスタからの要求を受けサービス部品を呼び出します。そのとき，次の2つの役割を果たします。

データ変換

汎用カスタムアダプタにデータ変換定義が含まれる場合，事前に定義された情報に基づいて電文のデータ変換をします。

プロトコル変換

サービス部品のプロトコルにあわせてプロトコル変換し，サービス部品を呼び出します。

2.21.2　カスタムアダプタ開発フレームワークの概要

汎用カスタムアダプタが行う処理には，データ変換とプロトコル変換があります。このうち，すべての汎用カスタムアダプタに共通の処理であるデータ変換処理をカスタムアダプタ開発フレームワークで提供しています。このため，ユーザはプロトコル変換処理を実装することで汎用カスタムアダプタを開発できます。

注意事項

データ変換の定義は，別途必要となります。

汎用カスタムアダプタは，カスタムアダプタ開発フレームワークの実装であるStateless SessionBeanと，プロトコルコンバータで構成されます。プロトコルコンバータとは，プロトコル変換処理を実装するJavaクラスのことです。

汎用カスタムアダプタを使用したサービス部品の呼び出しを次の図に示します。

図2‒195　汎用カスタムアダプタを使用したサービス部品の呼び出し（すべて同期通信の場合）

図中の1.〜7.について説明します。

説明

HCSCサーバは，汎用カスタムアダプタ経由で呼び出すサービス部品へのリクエストを受け取ります。

HCSCサーバは，EJBリモートインターフェースを使用して，カスタムアダプタ開発フレームワークで実装している汎用カスタムアダプタを呼び出します。

カスタムアダプタ開発フレームワークは，事前に定義された情報に基づいてデータ変換処理を実行し，プロトコルコンバータインターフェースを使用してプロトコルコンバータを呼び出します。

プロトコルコンバータは，サービス部品のプロトコルに応じた送受信処理を行います。

サービス部品の呼び出し結果をカスタムアダプタ開発フレームワークに返します。

カスタムアダプタ開発フレームワークは，事前に定義された情報に基づいてデータ変換処理を実行し，HCSCサーバに応答を返します。

サービスリクエスタに応答を返します。

カスタムアダプタ開発フレームワークによる汎用カスタムアダプタの開発については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「付録B　カスタムアダプタ開発フレームワーク」を参照してください。

2.22　TP1アダプタおよびMessage Queueアダプタのオペレーション動的変更機能

TP1アダプタ，またはMessage Queueアダプタの実行オペレーションをビジネスプロセス内で動的に変更できます。

実行オペレーションを動的変更することで，ビジネスプロセス内に配置するサービスアダプタ数や，ビジネスプロセス数を削減できます。

2.22.1　オペレーション動的変更機能を利用した処理の流れ

オペレーション動的変更機能を利用した処理の流れを次に示します。

図2‒196　オペレーション動的変更機能を利用した処理の流れ

サービスリクエスタがビジネスプロセスにサービス部品の実行を要求します。

受付アクティビティは，受け取ったサービスリクエスタからの要求電文を要求電文の変数に格納します。

要求電文変数から，サービスアダプタ呼び出しに使用するサービス呼び出し要求電文（ボディ割当変数）を作成します。

要求電文変数から，オペレーション名を決定し，データ変換アクティビティなどで，ヘッダ割当変数に格納します。

サービスアダプタを呼び出します。

サービス呼び出しでは，要求電文のヘッダ割当変数として，4.で定義したヘッダ割当変数を指定します。

サービスアダプタは，ヘッダ割当変数に指定されたオペレーション名に従い，サービスを実行します。また，応答をサービス呼び出し応答電文の変数に格納します。

応答アクティビティは，サービス呼び出し応答電文をサービスリクエスタに返します。

2.22.2　ヘッダ割当変数の定義

ヘッダ変数のスキーマを使用して，ヘッダ割当変数を定義します。ヘッダ変数のスキーマは「<サービスプラットフォームのインストールディレクトリ>¥CSC¥schema¥common¥dynamic_operation_header.xsd」に格納されています。

(1)　ヘッダ変数のスキーマの記述形式

ヘッダ変数のスキーマの記述形式を次に示します。

ヘッダ変数のスキーマの記述形式

<?xml version="1.0" encoding="UTF-8"?>
<!-- All Rights Reserved. Copyright (C) 2024. Hitachi, Ltd. -->
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:dyop="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/dynamicoperation/header"
  targetNamespace="http://www.hitachi.co.jp/soft/xml/cosminexus/csc/dynamicoperation/header">

  <xsd:element name="DynamicOperationHeader" type="dyop:DynamicOperation"/>

  <xsd:complexType name="DynamicOperation">
    <xsd:sequence>
      <xsd:element name="cscDynamicOperationName" minOccurs="0" maxOccurs="1" type="xsd:string"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:schema>

(2)　ヘッダ割当変数の設定

「(1) ヘッダ変数のスキーマの記述形式」で作成したヘッダ変数のスキーマ（dynamic_operation_header.xsd）を使用して，ヘッダ割当変数を定義します。

ヘッダ割当変数の定義例を次に示します。

図2‒197　ヘッダ割当変数の定義例

定義したヘッダ割当変数のcscDynamicOperationName要素に値をセットします。

cscDynamicOperationName要素に要求電文のlocation要素をセットした例を次の図に示します。

図2‒198　cscDynamicOperationName要素に要求電文のlocation要素をセットした例

(3)　ヘッダ割当変数の制限事項

ヘッダ割当変数に指定する，ヘッダ変数のスキーマ（dynamic_operation_header.xsd）から作成した変数は，1つだけです。ヘッダ変数のスキーマ（dynamic_operation_header.xsd）から作成した変数を複数指定した場合の動作は保証されません。

2.22.3　オペレーション動的変更機能を使ったサービス呼び出し

オペレーション動的変更機能を使ったサービス呼び出しでは，要求電文のヘッダ割当変数として「2.22.2 ヘッダ割当変数の定義」で定義したヘッダ割当変数を，サービス呼出アクティビティに指定します。

サービス呼出アクティビティのヘッダ割当変数の設定例を次に示します。

図2‒199　サービス呼出アクティビティのヘッダ割当変数の設定例

3　ビジネスプロセスの機能

この章では，ビジネスプロセスの概要，ビジネスプロセスの仕組み，ビジネスプロセスの永続化・非永続化，ビジネスプロセスのトランザクション，ビジネスプロセスの再実行，およびビジネスプロセスの待機処理について説明します。また，ビジネスプロセスと関係が深いプロセスインスタンス，アクティビティ，変数，および相関セットについても説明します。

3.1　ビジネスプロセスの概要

ビジネスプロセスとは，複数のサービス部品を実行する処理の順番や条件などを定義して，一連の業務の流れとして定義したものです。

ビジネスプロセスは，サービスプラットフォームの開発環境で処理フローを定義します。処理フローは，ビジネスプロセス定義画面で定義します。画面上にアクティビティと呼ばれる要素を配置し，コネクションで連結して定義します。

ビジネスプロセス定義画面の詳細については，マニュアル「サービスプラットフォーム リファレンス」の「1.2.3　ビジネスプロセス定義画面」を参照してください。

ここでは，ビジネスプロセスを構成する主な次の9つの要素について説明します。

受付・応答

サービス呼び出し

Java呼び出し

データ変換

代入

繰り返し

分岐

並列処理

待機処理

3.1.1　受付・応答

(1)　機能

ビジネスプロセスの受付でサービスリクエスタからの要求を受け付け，応答でビジネスプロセスからの応答をサービスリクエスタに返します。

サービスリクエスタからの要求を受け付けるリクエスト受付には，標準受付とユーザ定義受付の両方を使用できます。

ビジネスプロセスの受付と応答の流れを次の図に示します。

図3‒1　ビジネスプロセスの受付と応答の流れ

(2)　使用するアクティビティ

受付には受付アクティビティを使用し，応答には応答アクティビティを使用します。

受付には，次のどちらかの通信モデルが定義できます。

同期で応答電文が返るビジネスプロセス

非同期で応答電文が返らないビジネスプロセス

3.1.2　サービス呼び出し

(1)　機能

サービス呼び出しでは，サービスプラットフォームの開発環境で定義した各種サービスアダプタやビジネスプロセスなどのサービス部品を実行することができます。

サービスアダプタやビジネスプロセスの通信モデルによって，同期で応答電文が返る場合と，非同期で応答電文が返らない場合のそれぞれのサービス部品を呼ぶことができます。

サービス呼び出しでサービスアダプタを実行する場合の流れを次の図に示します。

図3‒2　サービス呼び出しでサービスアダプタを実行する場合の流れ

(2)　使用するアクティビティ

サービス呼び出しには，サービス呼出アクティビティを使用します。

3.1.3　Java呼び出し

(1)　機能

Java呼び出しでは，サービスプラットフォームが提供する専用のインターフェースを実装したJavaクラスを実行することができます。

サービスプラットフォームが提供する機能だけでビジネスプロセスが定義できないような場合に，ユーザが作成するJavaプログラムを使用して，XML電文の変換や判定などの処理を実行できます。

Java呼び出しでJavaプログラムを実行する場合の流れを次の図に示します。

図3‒3　Java呼び出しでJavaプログラムを実行する場合の流れ

(2)　使用するアクティビティ

Java呼び出しには，Java呼出アクティビティを使用します。

Java呼出アクティビティの引数に定義した電文やビジネスプロセス上の変数でJavaプログラムを実行します。

Javaプログラムの戻り値は，Java呼出アクティビティの戻り値に定義した電文やビジネスプロセス上の変数になります。

なお，実行するJavaプログラムは，サービスプラットフォームの開発環境のJava呼出アクティビティを使用し，Javaエディタ上で作成する必要があります。

3.1.4　データ変換

(1)　機能

データ変換では，ビジネスプロセス上を流れる電文形式を異なる電文形式に変換したり，値を加工したりすることができます。また，複数の電文を組み合わせて1つの電文を作ることもできます。

データ変換は，サービス部品を呼び出すときに，サービス部品の要求電文形式に合わせた電文を作成する必要がある場合や，サービス部品からの応答電文を異なる電文に変換したい場合などに使用します。

ビジネスプロセスでのデータ変換の流れを次の図に示します。

図3‒4　ビジネスプロセスでのデータ変換の流れ

(2)　使用するアクティビティ

データ変換には，データ変換アクティビティを使用します。

データ変換の例を次に示します。

（例1）1対1でのデータ変換

（例2）N対1でのデータ変換

データ変換でできる処理を次の表に示します。

表3‒1　データ変換でできる処理一覧

処理

説明

文字列連結

複数の文字列を連結します。

部分文字列取得

1つの文字列から一部分の文字列を取り出します。

文字数取得

文字列の文字数をマッピング先に代入します。

文字列調査

文字列に指定した文字列が含まれているか，または指定した文字列で開始されているかを調査し，マッピング先に論理値を代入します。

空白除去

文字列の先頭と末尾の空白を除去します。また，文字列間の連続した空白を1つの半角スペースに置換します。

数値フォーマット変換

数値をフォーマット変換します。小数点文字および桁区切り文字を変更することができます。

数値演算

数値を演算（+，-，*，div，mod）します。

端数処理

小数点以下の端数を処理（四捨五入，切り捨て，および切り上げ）します。

総和

複数のノードセットの，ノードの数値を合計します。

否定演算

論理否定演算を実行します。

論理演算

論理演算（AND，OR，XOR）を実行します。

シフト演算

シフト演算を実行します。

ノード数取得

ノード数をマッピング先に代入します。

ノード名取得

ノード名をマッピング先に代入します。

ノード調査

指定した変換元ノードが存在するかを調査し，マッピング先にその論理値を代入します。

繰り返し

繰り返しを対応づけます。複数回出現する変換先ノードのインスタンスをソートすることもできます。

選択

条件によって異なる値を出力します。

値置換え

変換テーブルの指定に基づいて，マッピング元の値を変換し，マッピング先に代入します。

基数変換

基数変換を実行します。

カスタム

ユーザが作成したJavaプログラムで値の加工およびノードの作成ができます。

定数

指定した値をマッピング先に代入します。

XPath

XPath式を指定します。

3.1.5　代入

(1)　機能

代入では，ビジネスプロセス上を流れる電文形式を異なる電文形式に変換することができます。

代入の主な機能を次に示します。

XML電文を異なる名称のXML電文にコピーする。

XML電文の一部分(部分木)をほかのXML電文にコピー（挿入）する。

XML以外のboolean，numeric，string等の変数をほかの変数にコピーする。

代入は，データ変換と同じような機能を持ちますが，XML電文中の個々の値を対象とするのではなく，XML全体または一部をそのままコピーしたい場合に適しています。

ビジネスプロセスでの代入の流れを次の図に示します。

図3‒5　ビジネスプロセスでの代入の流れ

(2)　使用するアクティビティ

代入には，代入アクティビティを使用します。

代入の例を次に示します。

（例）部分木のコピー

3.1.6　繰り返し

(1)　機能

繰り返しでは，ビジネスプロセスの中で，指定した条件で処理を繰り返すこと（ループ処理）ができます。

繰り返し処理の中には，1つまたは複数のアクティビティを配置します。

繰り返し処理の方式には次の2つがあります。

繰り返し条件設定方式

繰り返しの条件を設定し，繰り返し条件を満たしている間は処理を繰り返します。

繰り返しリスト指定方式

繰り返し要素のリストを抽出し，リストに要素がある間は処理を繰り返します。

繰り返し条件設定方式の場合，繰り返しの判定は，前判定になります。判定結果が真の場合は繰り返しを続け，偽の場合は繰り返しから抜けて次の処理へ遷移します。

繰り返し条件設定方式の場合の，ビジネスプロセスでの繰り返しの流れを次の図に示します。

図3‒6　ビジネスプロセスでの繰り返し（繰り返し条件設定方式の場合）

繰り返しリスト指定方式の場合，繰り返し要素を定義した変数を基に繰り返しリストが生成されます。繰り返しリストに含まれるノードの数の分だけ，処理が繰り返し実行されます。

繰り返しリスト指定方式の場合の，ビジネスプロセスでの繰り返しの流れについては，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「5.6.16　繰り返しアクティビティ」を参照してください。

(2)　使用するアクティビティ

繰り返しアクティビティを使用します。

繰り返しの判定に用いる条件式，または繰り返し要素を定義した変数の要素のパスは，XML電文などの変数に対してXPathで指定します。

繰り返し条件設定方式と繰り返しリスト指定方式のどちらの方式を使用するかは，繰り返しアクティビティダイアログで設定します。

繰り返し処理で無限ループに陥ることを避けるために，繰り返しの回数の最大値を指定することができます。ただし，繰り返し回数の最大値に達した場合，ビジネスプロセスはエラーになります。

3.1.7　分岐

(1)　機能

分岐では，ビジネスプロセスの中で，条件の判定結果によって処理を分岐して実行することができます。分岐先の処理の中には，1つまたは複数のアクティビティを配置します。

ビジネスプロセスでの分岐の流れを次の図に示します。

図3‒7　ビジネスプロセスでの分岐

(2)　使用するアクティビティ

分岐の開始個所には分岐開始アクティビティを使用し，終了個所には分岐終了アクティビティを使用します。分岐先は，複数（2つ以上）設定できます。

分岐の判定に用いる条件式は，XML電文などの変数に対してXPathで指定します。この条件式を基に，それぞれの遷移先のアクティビティを指定します。

なお，分岐開始アクティビティと，対応する分岐終了アクティビティの間には，1つ以上のアクティビティを設定する必要があります。そのため，片方の分岐先で処理を何もしないで次へ遷移するようにしたい場合は，無操作アクティビティを配置します。

片方の分岐先で処理を何もしないで次へ遷移するようにしたい場合のアクティビティの配置例を次の図に示します。

図3‒8　片方の分岐先で処理を何もしないで次へ遷移するようしたい場合のアクティビティの配置例

3.1.8　並列処理

(1)　機能

並列処理では，ビジネスプロセスの中で，処理フローを2つ以上に分け，フローごとに順次実行することができます。

ビジネスプロセスでの並列実行の流れを次の図に示します。

図3‒9　ビジネスプロセスでの並列実行の流れ

(2)　使用するアクティビティ

並列処理の開始個所には並列処理開始アクティビティを，終了個所には並列処理終了アクティビティを使用します。

また，リンクコネクションを用いることで，個々の並行に実行する処理フローの順番を制御することができます。

なお，並列処理は個々の処理フローを順次実行します。複数の処理フローを同時に実行することはできません。

3.1.9　待機処理

(1)　機能

待機処理では，指定した期間の間，または指定した時刻まで，ビジネスプロセスの処理を待機することができます。

ビジネスプロセスでの待機処理の流れを次の図に示します。

図3‒10　ビジネスプロセスでの待機処理の流れ

(2)　使用するアクティビティ

待機処理には，待機アクティビティを使用します。

待機する時間の間隔または期限をXPath式で指定します。ビジネスプロセスの処理の中でXPath式を評価し，その結果で得た文字列を待機時間として使用します。

3.2　ビジネスプロセスの仕組み

3.2.1　ビジネスプロセスの処理の流れ

サービスリクエスタからビジネスプロセスを呼び出すと，呼び出されたビジネスプロセスで定義された要素やアクティビティを一つ一つ実行することで，プロセスを実行します。ビジネスプロセスの定義は，開発環境で定義します。ビジネスプロセスの処理の流れを次の図に示します。

図3‒11　ビジネスプロセスの処理の流れ

3.2.2　ビジネスプロセスの通信モデル

ビジネスプロセスは，同期と非同期の2種類の通信モデルがあります。

通信モデルが同期の場合，ビジネスプロセスを呼び出したサービスリクエスタに対して，応答電文が返ります（応答電文は応答アクティビティに定義した電文フォーマットです）。

通信モデルが非同期の場合，ビジネスプロセスを呼び出したサービスリクエスタに応答電文が返りません（処理だけがリターンします）。

通信モデルは，開発環境でビジネスプロセス定義するときに，受付アクティビティのダイアログで定義します。ビジネスプロセスでの通信モデルの違いを次の図に示します。

図3‒12　ビジネスプロセスでの通信モデルの違い

受付アクティビティダイアログの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「1.4.7　受付アクティビティダイアログ」を参照してください。

3.2.3　プロセスインスタンス

ビジネスプロセスが最初に要求を受け付けるときには，プロセスインスタンスを生成します。プロセスインスタンスを生成するには，開発環境でビジネスプロセスを定義するとき，最初に要求を受け付ける受付アクティビティを定義する受付アクティビティダイアログでインスタンス生成を「yes」に設定します。

プロセスインスタンスを生成するビジネスプロセスの場合，ビジネスプロセスが要求を受け付けるたびにプロセスインスタンスを生成します。そのため，複数の要求が同時に実行された場合でも，個々に独立してプロセスを実行します。ビジネスプロセスでのプロセスインスタンスの仕組みについて次の図に示します。

図3‒13　 ビジネスプロセスでのプロセスインスタンスの仕組み

受付アクティビティダイアログの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「1.4.7　受付アクティビティダイアログ」を参照してください。

プロセスインスタンスの属性情報を次の表に示します。

表3‒2　 プロセスインスタンスの属性情報

属性

説明

識別子

個々のプロセスインスタンスを特定するための識別子です。同一のビジネスプロセス定義（バージョンは異なる場合もある）内で一意な識別子です。

ビジネスプロセス定義名

対象のプロセスインスタンスが所属するビジネスプロセスの定義名称です。サービスリクエスタから呼び出すときのサービス名に相当します。

ビジネスプロセス定義バージョン

対象のプロセスインスタンスが所属するビジネスプロセス定義バージョンです。

状態

対象のプロセスインスタンスの状態です。

開始時刻

対象のプロセスインスタンスの開始時刻（GMT）です。

注　ACTIVE状態に遷移した時刻

終了時刻

対象のプロセスインスタンスの終了時刻（GMT）です。

注　COMPLETED状態に遷移した時刻

HCSCサーバ名

対象のプロセスインスタンスが最後に実行されたHCSCサーバ名です。

プロセスインスタンスの状態遷移を次の図に示します。

図3‒14　プロセスインスタンスの状態遷移

プロセスインスタンスを実行しようとしたとき。

プロセスインスタンスに所属するアクティビティを実行しようとしたとき。

プロセスインスタンスに所属するグローバルスコープが完了し，プロセスインスタンスが正常に終了したとき。

プロセス実行中にフォルトが発生し，グローバルスコープでもキャッチできないでプロセスインスタンスがフォルト終了したとき。

途中終了アクティビティを実行し，プロセスインスタンスが途中終了したとき。

サービス呼出アクティビティまたはスコープアクティビティで例外が発生し，プロセスインスタンスがエラーで中断したとき。

エラー状態のプロセスインスタンスに対して再実行を実施したとき。

実行中状態のプロセスインスタンスに対して再実行を実施したとき。

「図3-14　プロセスインスタンスの状態遷移」で示すプロセスインスタンスの状態を次の表に示します。

表3‒3　プロセスインスタンスの状態

状態

説明

ACTIVE状態

実行中状態（Executing）

プロセスインスタンスが実行中の状態です。

ERROR状態

エラー状態（Error）

サービス呼出アクティビティまたはスコープアクティビティで例外が発生し，プロセスインスタンスがエラーで中断した状態です。

COMPLETED状態

完了状態（Completed）

プロセスのグローバルスコープが完了して，プロセスインスタンスが完了した状態です。

フォルト終了状態（Faulted）

フォルトが発生し，グローバルスコープでもキャッチできないでプロセスインスタンスがフォルト終了した状態です。

途中終了状態

（Exited）

途中終了アクティビティによって，プロセスインスタンスが終了した状態です。

3.2.4　アクティビティ

アクティビティは，ビジネスプロセスの構成要素となる部品で，処理の構造を表現したものです。複数のアクティビティを連結して，ビジネスプロセスの処理フローを定義します。

開発環境のビジネスプロセス定義画面でアクティビティを配置，連結して定義します。各アクティビティの属性情報を次の表に示します。

表3‒4　アクティビティの属性情報

属性

説明

プロセスインスタンス識別子

対象のアクティビティが所属するプロセスインスタンスの識別子です。

アクティビティ番号

アクティビティを識別するための番号です。アクティビティリストのインデクスに対応します。

ビジネスプロセス定義名

対象のアクティビティが所属するビジネスプロセスの定義名称です。サービスリクエスタから呼び出すときのサービス名に相当します。

ビジネスプロセス定義バージョン

対象のアクティビティが所属するビジネスプロセス定義バージョンです。

アクティビティ定義名

対象のアクティビティのアクティビティ定義名称です。

アクティビティ種別

対象のアクティビティのアクティビティ種別です。

状態

対象のアクティビティの状態です。

開始時刻

対象のアクティビティの開始時刻（GMT）です。

注　ACTIVE状態に遷移した時刻

終了時刻

対象のアクティビティの終了時刻（GMT）です。

注　COMPLETED状態に遷移した時刻

待機解除時刻

対象のアクティビティの待機解除時刻（GMT）です。待機アクティビティのときに使用します。

アクティビティの状態遷移を次の図に示します。

図3‒15　アクティビティの状態遷移

新たなアクティビティのインスタンスが生成されたとき。

アクティビティインスタンスを実行しようとしたとき。

アクティビティインスタンスの実行が完了したとき。

アクティビティインスタンスを実行したが，実行中にならないで実行が完了したとき。

サービスリクエスタからの要求を受信した受付以外の受付アクティビティインスタンスを実行しようとしたとき。

待ち受け状態の受付アクティビティインスタンスがサービスリクエスタからの要求を受けたとき。

target linkがfalseで活性化されたとき。

アクティビティインスタンスの実行時にフォルトが発生したとき。

フォルトが発生し，アクティビティの実行がキャンセル処理を依頼されたとき。

フォルトが発生し，フォルトハンドラでキャッチして対応するアクティビティインスタンスを実行中のとき。

フォルトが発生し，キャッチに対応するアクティビティインスタンスの実行が完了したとき。

構造化アクティビティが実行省略された際に，内包するアクティビティを実行省略にするとき。

未省略状態のアクティビティの実行を省略するとき。

サービス呼出アクティビティの処理で例外が発生し，アクティビティインスタンスの処理がエラーで中断したとき。

エラー状態のサービス呼出アクティビティのアクティビティインスタンスに対して再実行を実施したとき。

実行中状態の待機アクティビティインスタンスに対して再実行を実施したとき。

トランザクションを制御するスコープアクティビティインスタンスを実行しようとしたとき。

トランザクションを制御するスコープアクティビティインスタンスの実行が完了したとき（「完了状態（待ち受け）」に遷移し，その後「完了状態」に遷移）。

トランザクションを制御するスコープアクティビティの処理で例外が発生し，アクティビティインスタンスの処理がエラーで中断したとき。

エラー状態のトランザクションを制御するスコープアクティビティインスタンスに対して再実行を実施したとき。

非同期EJBに応答アクティビティ実行後の呼び出しを実施したとき。

非同期EJBから応答アクティビティ実行後の呼び出しが実施されたとき。

補償アクティビティから補償ハンドラ配下のアクティビティを実行しようとしたとき。

補償ハンドラ配下のアクティビティの実行が完了したとき。

補償ハンドラ配下のアクティビティでフォルトが発生したとき。

途中終了アクティビティを実行してアクティビティを実行しなかったとき。

未省略状態のアクティビティが存在する状態で，途中終了アクティビティを実行してプロセスを終了したとき。

実行中状態のアクティビティが存在する状態で，途中終了アクティビティでプロセスを終了したとき。

フォルト処理実行中に途中終了アクティビティでプロセスを終了したとき。

補償処理実行中に途中終了アクティビティでプロセスを終了したとき。

トランザクション制御を行うスコープアクティビティ実行中に途中終了アクティビティでプロセスを終了したとき。

「図3-15　アクティビティの状態遷移」で示すアクティビティの状態を次の表に示します。

表3‒5　アクティビティの状態

状態

説明

READY状態

未実行状態（Unexecution）

アクティビティインスタンスが未実行で，今後実行される可能性のある状態です。

未省略状態（Unomission）

アクティビティインスタンスが未実行で，今後実行省略される状態です。

ACTIVE状態

実行中状態（Executing）

アクティビティインスタンスが実行中の状態です。

実行中状態（待ち受け）（Executingwait）

ロールバックが行われ，スコープアクティビティのインスタンスが再実行可能な状態です。

待ち受け状態（Awaiting）

受付アクティビティのインスタンスが受け付けられる状態です。

フォルト中状態（Faulting）

アクティビティインスタンスがfaultHandlerでキャッチしたアクティビティを実行している状態です。

補償中状態（Conpensating）

補償処理が実行中の状態です。

ERROR状態

エラー状態（Error）

サービス呼出アクティビティまたはスコープアクティビティの処理で例外が発生し，アクティビティインスタンスの処理がエラーで中断した状態です。

COMPLETED状態

完了状態（Completed）

アクティビティインスタンスが正常に実行され終了した状態です。

完了状態（待ち受け）（Completedwait）

アクティビティインスタンスが正常に実行され終了した状態です。

アクティビティのインスタンスが再実行可能な状態です。

補償完了状態（Conpensated）

補償処理が正常に実行され終了した状態です。

キャンセル終了状態（Canceled）

フォルトが発生しアクティビティインスタンスの実行がキャンセルされた状態です。

フォルト終了状態（Faulted）

アクティビティインスタンスの実行中にフォルトが発生して終了した状態です。

実行省略状態（Omitted）

アクティビティインスタンスの実行が省略された状態です。

各アクティビティの詳細については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「5.6　アクティビティの定義」を参照してください。

3.2.5　変数の種類と役割

ビジネスプロセスでは，メッセージに含まれる値や業務で使用する値を変数で保持できます。変数にはグローバル変数とローカル変数の2種類があり，開発環境のビジネスプロセス定義画面で定義します。変数の役割を次の表に示します。

表3‒6　変数の役割

変数

説明

グローバル変数

グローバル変数は，1つのプロセスインスタンス内であれば，どこからでも参照できます。また，プロセスが完了しても変数の値はデータベースに記録されているため，ビジネスプロセス全体の進行状況を分析できます。変数名は，プロセス内で一意にします。

ローカル変数

ローカル変数は，宣言したスコープ内で参照できます。宣言しているスコープが終了すると，変数の値もデータベースから削除されるため，プロセス実行中の条件判定など一時的に値を参照するために利用できます。変数名は，スコープ内で一意にします。スコープが異なれば同じ変数名を宣言できます。ただし，変数を参照する場合に，参照個所で最も内側に近いスコープで宣言された変数を参照します。

変数の定義については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「5.5.1　変数の定義」を参照してください。

3.2.6　相関セットの役割

相関セットはサービスリクエスタが送信するメッセージを一意に識別するための文字列です。相関セットで使用できるメッセージ種別は，XML型だけです。

1つのビジネスプロセスに対して，サービスリクエスタからメッセージを受け取れるプロセスインスタンスがHCSCサーバ上に複数ある場合，HCSCサーバはメッセージに含まれる相関セットの値を利用してプロセスインスタンスを特定します。

サービスリクエスタは相関セットを含めた要求電文を作成して，HCSCサーバに対してサービス部品の呼び出し（ビジネスプロセスの呼び出し）を要求します。ビジネスプロセスからの応答にも相関セットが含まれ，どの送信メッセージに対する結果かを識別できます。相関セットは開発環境のビジネスプロセス定義画面で定義します。

なお，相関セットは，ビジネスプロセスがサービス部品を呼び出すとき，およびビジネスプロセスがサービス部品から応答を受けたときにも，新たに相関セットを指定してメッセージを送信できます。

相関セットによるプロセスインスタンスの識別については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「5.5.2　相関セットの定義」を参照してください。

3.3　永続化するビジネスプロセスと永続化しないビジネスプロセス

ビジネスプロセスには，データベースにプロセスの実行状態および実行履歴を永続化するビジネスプロセスと，永続化しないビジネスプロセスの2種類があります。永続化とは，プロセスの実行状態および実行履歴をデータベースに記録することです。

それぞれのビジネスプロセスの違いについて，次に説明します。

3.3.1　永続化するビジネスプロセス

永続化するビジネスプロセスは，プロセスの実行状態と実行履歴の記録があるため，障害が発生した場合に，プロセスの実行の進捗度がわかり，プロセスを再実行できます。開発環境でビジネスプロセスを追加するときに，永続化する設定にできます。

次に示す内容を実施する場合には，ビジネスプロセスを永続化に設定します。

プロセスインスタンスの実行履歴の管理

コマンドによるプロセスインスタンスの実行履歴の取得

運用環境の画面によるプロセスインスタンスの実行履歴の取得

プロセスインスタンスの再実行

コマンドによるプロセスインスタンスの再実行

運用環境の画面によるプロセスインスタンスの再実行

サービスリクエスタ（SOAP通信/SessionBean）によるプロセスインスタンスの再実行

ビジネスプロセスを新規に追加する方法については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「5.2.1　ビジネスプロセスを新規に追加する」を参照してください。

注意事項

永続化するビジネスプロセスの場合，繰り返しアクティビティのリスト指定方式は使用できません。

3.3.2　永続化しないビジネスプロセス

永続化しないビジネスプロセスは，プロセスの実行状態と実行履歴の記録を採らないため，高性能を実現する必要があるビジネスプロセスの場合に設定します。開発環境でビジネスプロセスを追加するときに，永続化しない設定にできます。

ただし，永続化するビジネスプロセスではできることが，永続化しないビジネスプロセスではできないといった制約事項があります。永続化しないビジネスプロセスは，次の条件を満たす場合に定義できます。

非同期のサービスアダプタに対して，サービスを呼び出すサービス呼出アクティビティを含まない。

待機アクティビティを含まない。

受付アクティビティを複数含まない。

プロセスインスタンスの再実行を使用しない（障害発生時は，サービスリクエスタからサービス呼び出し要求（ビジネスプロセスの呼び出し）を再度実行する）。

ビジネスプロセスを新規に追加する方法については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「5.2.1　ビジネスプロセスを新規に追加する」を参照してください。

3.4　ビジネスプロセスのトランザクション

永続化するビジネスプロセスの場合，ビジネスプロセスを実行する過程でアクティビティの状態をデータベースに出力します。

ここでは，アクティビティの状態を確定するタイミング（トランザクションの開始とコミット）について説明します。

トランザクションの開始とコミットのタイミングを次の表に示します。

表3‒7　トランザクションの開始とコミットのタイミング

処理

タイミング

トランザクションの開始

受付アクティビティでメッセージを受信したとき。

通信モデルが同期の場合のサービス呼出アクティビティで，メッセージを送信する前のトランザクションをコミットした直後。

また，ビジネスプロセスの状態の互換性（HCSCサーバセットアップ定義のbp-status-compatible）にOFFを指定した場合は，サービス呼出アクティビティの状態の互換性（HCSCサーバセットアップ定義のbp-invoke-status-compatible）の設定にかかわらず，サービス呼出アクティビティでメッセージを送信する前のトランザクションをコミットした直後（通信モデルが同期，非同期のどちらでも同じタイミングになります）。

ビジネスプロセスの状態の互換性（HCSCサーバセットアップ定義のbp-status-compatible）にOFFを指定，かつサービス呼出アクティビティの状態の互換性（HCSCサーバセットアップ定義のbp-invoke-status-compatible）にONを指定した場合，サービス呼出アクティビティの処理が完了したときのトランザクションをコミットした直後。

また，ビジネスプロセスの状態の互換性にOFFを指定，かつサービス呼出アクティビティの状態の互換性にOFFを指定した場合，サービス呼出アクティビティの処理で例外が発生したときのトランザクションをコミットした直後。

応答アクティビティの処理のあとに存在するアクティビティを実行する直前。

プロセス再実行ユティリティによって，プロセスを再実行するとき。

待機アクティビティに指定された間隔または期限でタイマが解除された直後。

待機アクティビティの処理が完了したときのトランザクションをコミットした直後。

トランザクション制御を行うスコープアクティビティの開始で，トランザクションをコミットした直後。

トランザクション制御を行うスコープアクティビティの終了で，トランザクションをコミットした直後。

トランザクションのコミット

応答アクティビティでメッセージを応答する直前。

通信モデルが同期の場合のサービス呼出アクティビティでメッセージを送信する直前。

また，ビジネスプロセスの状態の互換性（HCSCサーバセットアップ定義のbp-status-compatible）にOFFを指定した場合は，サービス呼出アクティビティの状態の互換性（HCSCサーバセットアップ定義のbp-invoke-status-compatible）の設定にかかわらず，サービス呼出アクティビティでメッセージを送信する直前（通信モデルが同期，非同期のどちらでも同じタイミングになります）。

ビジネスプロセスの状態の互換性（HCSCサーバセットアップ定義のbp-status-compatible）にOFFを指定，かつサービス呼出アクティビティの状態の互換性（HCSCサーバセットアップ定義のbp-invoke-status-compatible）にONを指定した場合，サービス呼出アクティビティの処理が完了したとき。

また，ビジネスプロセスの状態の互換性にOFFを指定，かつサービス呼出アクティビティの状態の互換性にOFFを指定した場合，サービス呼出アクティビティの処理で例外が発生したとき。

実行可能なすべてのアクティビティを実行し，ビジネスプロセスの処理を終了するとき。

待機アクティビティに指定された間隔または期限のJ2EEサーバのTimerServiceにタイマを登録する直前。

待機アクティビティの処理が完了したとき。

トランザクション制御を行うスコープアクティビティが開始したとき。

トランザクション制御を行うスコープアクティビティが終了したとき。

トランザクションの開始とコミットのタイミングは，ビジネスプロセスの状態の互換性（HCSCサーバセットアップ定義のbp-status-compatible）の指定がONまたはOFFの場合，またはサービス呼出アクティビティの状態の互換性（HCSCサーバセットアップ定義のbp-invoke-status-compatible）の指定がONまたはOFFの場合で動作が異なります。

サービス呼出アクティビティの状態の互換性は，ビジネスプロセスの状態の互換性の指定がOFFのときに，有効となります。

なお，サービス呼出アクティビティの状態の互換性にONを指定した場合は，サービスプラットフォームのバージョン08-70以前と同じ動作となります。

それぞれのトランザクションの開始とコミットのタイミングの例を次に示します。

3.4.1　ビジネスプロセスの状態の互換性の指定をONにした場合のトランザクション

ビジネスプロセスの状態の互換性（HCSCサーバセットアップ定義のbp-status-compatible）にONを指定した場合のトランザクションについて説明します。

なお，ビジネスプロセスの状態の互換性にONを指定した場合は，サービスプラットフォームのバージョン08-00以前と同じ動作となります。

また，サービス呼出アクティビティの状態の互換性にON，またはOFFのどちらを指定しても同じ動作となります。

(1)　同期のサービス呼出アクティビティが2つ並んだ場合

正常に処理が進行した場合

それぞれのサービス呼出アクティビティでのメッセージ送信処理直前でトランザクションをコミットし，新たにトランザクションを開始します。

同期のサービス呼出で正常に処理が進行した場合のトランザクションの範囲を次の図に示します。

図3‒16　正常に処理が進行した場合のトランザクションの範囲（同期のサービス呼出）

例外が発生した場合

サービス呼出2の処理が例外でエラーとなった場合は，トランザクションがコミットした時点（受付：完了状態，サービス呼出1：完了状態，サービス呼出2：実行中状態）までロールバックします。

同期のサービス呼出で例外が発生した場合のトランザクションの範囲を次の図に示します。

図3‒17　例外が発生した場合のトランザクションの範囲（同期のサービス呼出）

(2)　非同期と同期のサービス呼出アクティビティが2つ並んだ場合

正常に処理が進行した場合

非同期のサービス呼出アクティビティでのメッセージ送信処理ではトランザクションはコミットしないで，同期のサービス呼出アクティビティでのメッセージ送信処理直前でトランザクションをコミットし，新たにトランザクションを開始します。

非同期と同期のサービス呼出で正常に処理が進行した場合のトランザクションの範囲を次の図に示します。

図3‒18　正常に処理が進行した場合のトランザクションの範囲（非同期と同期のサービス呼出）

例外が発生した場合（非同期と同期のサービス呼出）

サービス呼出1が非同期，サービス呼出2が同期の構成で，サービス呼出2の処理が例外でエラーとなった場合は，トランザクションがコミットした時点（受付：完了状態，サービス呼出1：完了状態，サービス呼出2：実行中状態）までロールバックします。

非同期と同期のサービス呼出で例外が発生した場合のトランザクションの範囲を次の図に示します。

図3‒19　例外が発生した場合のトランザクションの範囲（非同期と同期のサービス呼出）

例外が発生した場合（同期と非同期のサービス呼出）

サービス呼出1が同期，サービス呼出2が非同期の構成で，サービス呼出2の処理が例外でエラーとなった場合は，トランザクションがコミットした時点（受付：完了状態，サービス呼出1：実行中状態）までロールバックします。

同期と非同期のサービス呼出で例外が発生した場合のトランザクションの範囲を次の図に示します。

図3‒20　例外が発生した場合のトランザクションの範囲（同期と非同期のサービス呼出）

(3)　非同期のサービス呼出アクティビティが2つ並んだ場合

正常に処理が進行した場合

非同期のサービス呼出アクティビティでのメッセージ送信処理ではトランザクションはコミットしません。そのため，ビジネスプロセスが応答するときにトランザクションがコミットします。

非同期のサービス呼出で正常に処理が進行した場合のトランザクションの範囲を次の図に示します。

図3‒21　正常に処理が進行した場合のトランザクションの範囲（非同期のサービス呼出）

例外が発生した場合

サービス呼出2の処理が例外でエラーとなった場合は，トランザクションがコミットした時点（受付：未実行状態，サービス呼出1：未実行状態，サービス呼出2：未実行状態）までロールバックします。

非同期のサービス呼出で例外が発生した場合のトランザクションの範囲を次の図に示します。

図3‒22　例外が発生した場合のトランザクションの範囲（非同期のサービス呼出）

(4)　同期のサービス呼出アクティビティのあとにデータ変換アクティビティがある場合

正常に処理が進行した場合

それぞれのサービス呼出アクティビティでのメッセージ送信処理直前でトランザクションをコミットしますが，データ変換アクティビティではトランザクションがコミットしません。これは，「表3-7　トランザクションの開始とコミットのタイミング」で示した以外のアクティビティも同様です。

データ変換などのアクティビティがある場合で正常に処理が進行したときのトランザクションの範囲を次の図に示します。

図3‒23　正常に処理が進行した場合のトランザクションの範囲（データ変換などのアクティビティがある場合）

例外が発生した場合（同期サービス呼出のあとにデータ変換などのアクティビティがある場合）

サービス呼出1が同期の構成で，サービス呼出1のあとにデータ変換処理でエラーとなった場合は，トランザクションがコミットした時点（受付：完了状態，サービス呼出1：実行中状態）までロールバックします。

同期サービス呼出のあとにデータ変換などのアクティビティがある場合で例外が発生したときのトランザクションの範囲を次の図に示します。

図3‒24　例外が発生した場合のトランザクションの範囲（同期サービス呼出のあとにデータ変換などのアクティビティがある場合）

例外が発生した場合（非同期サービス呼出のあとにデータ変換などのアクティビティがある場合）

サービス呼出1が非同期の構成で，サービス呼出1のあとにデータ変換処理でエラーとなった場合は，トランザクションがコミットした時点（受付：未実行状態，サービス呼出1：未実行状態）までロールバックします。

非同期サービス呼出のあとにデータ変換などのアクティビティがある場合で例外が発生したときのトランザクションの範囲を次の図に示します。

図3‒25　例外が発生した場合のトランザクションの範囲（非同期サービス呼出のあとにデータ変換などのアクティビティがある場合）

3.4.2　ビジネスプロセスの状態の互換性の指定をOFF，サービス呼出アクティビティの状態の互換性の指定をONにした場合のトランザクション

ビジネスプロセスの状態の互換性（HCSCサーバセットアップ定義のbp-status-compatible）にOFF，サービス呼出アクティビティの状態の互換性（HCSCサーバセットアップ定義のbp-invoke-status-compatible）にONを指定した場合のトランザクションについて説明します。

ビジネスプロセスの状態の互換性にOFF，サービス呼出アクティビティの状態の互換性にONを指定した場合は，サービス呼出アクティビティの処理が，開始または完了したタイミングでトランザクションを終了します。ビジネスプロセスのサービス呼出アクティビティ実行中に例外が発生した場合，プロセスインスタンスおよびサービス呼出アクティビティの状態にエラー発生（Error）を設定します。

(1)　同期のサービス呼出アクティビティが2つ並んだ場合

正常に処理が進行した場合

それぞれのサービス呼出アクティビティでのメッセージ送信処理直前でトランザクションをコミットし，新たにトランザクションを開始します。また，メッセージ送信処理が完了したあとにもトランザクションをコミットし，新たにトランザクションを開始します。

同期のサービス呼出で正常に処理が進行した場合のトランザクションの範囲を次の図に示します。

図3‒26　正常に処理が進行した場合のトランザクションの範囲（同期のサービス呼出）

例外が発生した場合

サービス呼出2の処理が例外でエラーとなった場合は，トランザクションがコミットした時点（受付：完了状態，サービス呼出1：完了状態，サービス呼出2：実行中状態）にロールバックしたあと，プロセスインスタンスおよびサービス呼出アクティビティの状態にエラー発生（Error）を設定して，トランザクションをコミットします。

同期のサービス呼出で例外が発生した場合のトランザクションの範囲を次の図に示します。

図3‒27　例外が発生した場合のトランザクションの範囲（同期のサービス呼出）

(2)　非同期と同期のサービス呼出アクティビティが2つ並んだ場合

正常に処理が進行した場合

それぞれのサービス呼出アクティビティでのメッセージ送信処理直前でトランザクションをコミットし，新たにトランザクションを開始します。また，メッセージ送信処理が完了したあとにもトランザクションをコミットし，新たにトランザクションを開始します。

非同期と同期のサービス呼出で正常に処理が進行した場合のトランザクションの範囲を次の図に示します。

図3‒28　正常に処理が進行した場合のトランザクションの範囲（非同期と同期のサービス呼出）

例外が発生した場合（非同期と同期のサービス呼出）

サービス呼出2の処理が例外でエラーとなった場合は，トランザクションがコミットした時点（受付：完了状態，サービス呼出1：完了状態，サービス呼出2：実行中状態）にロールバックしたあと，プロセスインスタンスおよびサービス呼出アクティビティの状態にエラー発生（Error）を設定して，トランザクションをコミットします。

非同期と同期のサービス呼出で例外が発生した場合のトランザクションの範囲を次の図に示します。

図3‒29　例外が発生した場合のトランザクションの範囲（非同期と同期のサービス呼出）

(3)　非同期のサービス呼出アクティビティが2つ並んだ場合

正常に処理が進行した場合

それぞれのサービス呼出アクティビティでのメッセージ送信処理直前でトランザクションをコミットし，新たにトランザクションを開始します。また，メッセージ送信処理が完了したあとにもトランザクションをコミットし，新たにトランザクションを開始します。

非同期のサービス呼出で正常に処理が進行した場合のトランザクションの範囲を次の図に示します。

図3‒30　正常に処理が進行した場合のトランザクションの範囲（非同期のサービス呼出）

例外が発生した場合

サービス呼出2の処理が例外でエラーとなった場合は，トランザクションがコミットした時点（受付：完了状態，サービス呼出1：完了状態，サービス呼出2：実行中状態）にロールバックしたあと，プロセスインスタンスおよびサービス呼出アクティビティの状態にエラー発生（Error）を設定して，トランザクションをコミットします。

非同期のサービス呼出で例外が発生した場合のトランザクションの範囲を次の図に示します。

図3‒31　例外が発生した場合のトランザクションの範囲（非同期のサービス呼出）

(4)　同期のサービス呼出アクティビティのあとにデータ変換アクティビティがある場合

正常に処理が進行した場合

それぞれのサービス呼出アクティビティでのメッセージ送信処理直前でトランザクションをコミットし，新たにトランザクションを開始します。また，メッセージ送信処理が完了したあとにもトランザクションをコミットし，新たにトランザクションを開始します。

ただし，データ変換アクティビティではトランザクションがコミットしません。これは，「表3-7　トランザクションの開始とコミットのタイミング」で示した以外のアクティビティも同様です。

データ変換などのアクティビティがある場合で正常に処理が進行したときのトランザクションの範囲を次の図に示します。

図3‒32　正常に処理が進行した場合のトランザクションの範囲（データ変換などのアクティビティがある場合）

例外が発生した場合（データ変換などのアクティビティがある場合）

サービス呼出1のあとのデータ変換処理でエラーとなった場合は，トランザクションがコミットした時点（受付：完了状態，サービス呼出1：完了状態，データ変換：未実行状態）までロールバックします。

データ変換などのアクティビティがある場合で例外が発生したときのトランザクションの範囲を次の図に示します。

図3‒33　例外が発生した場合のトランザクションの範囲（データ変換などのアクティビティがある場合）

3.4.3　ビジネスプロセスの状態の互換性の指定をOFF，サービス呼出アクティビティの状態の互換性の指定をOFFにした場合のトランザクション

ビジネスプロセスの状態の互換性（HCSCサーバセットアップ定義のbp-status-compatible）にOFF，サービス呼出アクティビティの状態の互換性（HCSCサーバセットアップ定義のbp-invoke-status-compatible）にOFFを指定した場合のトランザクションについて説明します。

ビジネスプロセスの状態の互換性にOFF，サービス呼出アクティビティの状態の互換性にOFFを指定した場合の動作を次に示します。

サービス呼出アクティビティの処理が開始したタイミングでは，アクティビティの状態に実行中状態（Executing）を設定し，トランザクションを終了します。

サービス呼出アクティビティの処理が完了したタイミングでは，アクティビティの状態に完了状態（Completed）を設定し，トランザクションを終了しません。

ビジネスプロセスのサービス呼出アクティビティ実行中に例外が発生した場合は，プロセスインスタンスおよびサービス呼出アクティビティの状態にエラー発生（Error）を設定し，トランザクションを終了します。

なお，通信モデルが同期，非同期のどちらでも同じ動作となります。

(1)　サービス呼出アクティビティが2つ並んだ場合

正常に処理が進行した場合

それぞれのサービス呼出アクティビティでのメッセージ送信処理直前でトランザクションをコミットし，新たにトランザクションを開始します。

サービス呼出で正常に処理が進行した場合のトランザクションの範囲を次の図に示します。

図3‒34　正常に処理が進行した場合のトランザクションの範囲

例外が発生した場合

サービス呼出2の処理が例外でエラーとなった場合は，トランザクションがコミットした時点（受付：完了状態，サービス呼出1：完了状態，サービス呼出2：実行中状態）にロールバックしたあと，プロセスインスタンスおよびサービス呼出アクティビティの状態にエラー発生（Error）を設定して，トランザクションをコミットします。

サービス呼出で例外が発生した場合のトランザクションの範囲を次の図に示します。

図3‒35　例外が発生した場合のトランザクションの範囲

(2)　サービス呼出アクティビティのあとにデータ変換アクティビティがある場合

正常に処理が進行した場合

それぞれのサービス呼出アクティビティでのメッセージ送信処理直前でトランザクションをコミットし，新たにトランザクションを開始します。

ただし，データ変換アクティビティではトランザクションがコミットしません。これは，「表3-7　トランザクションの開始とコミットのタイミング」で示した以外のアクティビティも同様です。

データ変換などのアクティビティがある場合で正常に処理が進行したときのトランザクションの範囲を次の図に示します。

図3‒36　正常に処理が進行した場合のトランザクションの範囲（サービス呼出のあとにデータ変換などのアクティビティがある場合）

例外が発生した場合（サービス呼出のあとにデータ変換などのアクティビティがある場合）

サービス呼出1のあとにデータ変換処理でエラーとなった場合は，トランザクションがコミットした時点（受付：完了状態，サービス呼出1：実行中状態）までロールバックします。

サービス呼出のあとにデータ変換などのアクティビティがある場合で例外が発生したときのトランザクションの範囲を次の図に示します。

図3‒37　例外が発生した場合のトランザクションの範囲（サービス呼出のあとにデータ変換などのアクティビティがある場合）

3.4.4　サービス呼出アクティビティのトランザクション

サービス呼出アクティビティの定義ごとのトランザクション，およびステータスの遷移を次に示します。

(1)　ビジネスプロセスの状態の互換性（HCSCサーバセットアップ定義ファイルのbp-status-compatible）にONを指定した場合

ビジネスプロセスの状態の互換性にONを指定した場合のサービス呼出アクティビティのトランザクション，およびステータスの遷移を次の表に示します。サービス呼出アクティビティの状態の互換性（HCSCサーバセットアップ定義ファイルのbp-invoke-status-compatible）の設定にかかわらず，同じ遷移となります。

表3‒8　ビジネスプロセスの状態の互換性（HCSCサーバセットアップ定義ファイルのbp-status-compatible）にONを指定した場合の，トランザクション，およびステータスの遷移に関するプロパティ

サービス呼出アクティビティの動作

サービス呼出アクティビティの状態の互換性にONを指定

サービス呼出アクティビティの状態の互換性にOFFを指定（デフォルト）

非同期

同期

非同期

同期

要求電文の送信

×

○（実行中）※

×

○（実行中）※

応答電文の受信（正常終了）

×

×

×

×

応答電文の受信（システム例外発生）

×

×

×

×

（凡例）

○：トランザクション制御を行います。

×：トランザクション制御を行いません。

注※

（）内はコミットされるステータスです。

HCSCサーバセットアップ定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.4.3　HCSCサーバセットアップ定義ファイル」を参照してください。

(2)　ビジネスプロセスの状態の互換性（HCSCサーバセットアップ定義ファイルのbp-status-compatible）にOFFを指定した場合

ビジネスプロセスの状態の互換性にOFFを指定した場合のサービス呼出アクティビティのトランザクション，およびステータスの遷移を次の表に示します。サービス呼出アクティビティの状態の互換性（HCSCサーバセットアップ定義ファイルのbp-invoke-status-compatible）の設定によって，遷移が異なります。

表3‒9　ビジネスプロセスの状態の互換性（HCSCサーバセットアップ定義ファイルのbp-status-compatible）にOFFを指定した場合の，トランザクション，およびステータスの遷移に関するプロパティ

サービス呼出アクティビティの動作

サービス呼出アクティビティの状態の互換性にONを指定

サービス呼出アクティビティの状態の互換性にOFFを指定（デフォルト）

非同期

同期

非同期

同期

要求電文の送信

○（実行中）※

○（実行中）※

○（実行中）※

○（実行中）※

応答電文の受信（正常終了）

○（完了）※

○（完了）※

×

×

応答電文の受信（システム例外発生）

○（エラー状態）※

○（エラー状態）※

○（エラー状態）※

○（エラー状態）※

（凡例）

○：トランザクション制御を行います。

×：トランザクション制御を行いません。

注※

（）内はコミットされるステータスです。

なお，サービス呼出アクティビティの実行が正常に完了したあとにアクティビティでエラーが発生した場合，サービス呼出アクティビティでの非同期サービスのキューへのメッセージ送信，およびDBアダプタを呼び出すデータベースへの更新処理は有効となります。

HCSCサーバセットアップ定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.4.3　HCSCサーバセットアップ定義ファイル」を参照してください。

3.4.5　スコープの開始時および終了時にコミットする設定を選択した場合のトランザクション

スコープアクティビティは，［スコープアクティビティ］ダイアログで，［このスコープの開始と終了時のみコミットする］を選択した場合，スコープの開始時および終了時にトランザクションを制御します。

トランザクションを制御するスコープアクティビティのトランザクションについて説明します。

(1)　スコープアクティビティが正常終了した場合

スコープアクティビティの開始処理で，スコープアクティビティの状態を実行中状態（待ち受け）にし，トランザクションをコミットしたあと，新たなトランザクションを開始します。そのあと，スコープアクティビティ内部に定義されたアクティビティを実行します。このとき，スコープアクティビティ内に定義されたアクティビティではトランザクションの制御は行われません。

スコープアクティビティの終了処理で，スコープアクティビティの状態を完了状態（待ち受け）にし，トランザクションをコミットしたあと，新たなトランザクションを開始します。そのあと，スコープアクティビティの状態を完了状態にします。このとき，状態は遷移しますが，トランザクションはコミットしません。

スコープアクティビティが正常終了した場合のトランザクションの範囲を次の図に示します。

図3‒38　スコープアクティビティが正常終了した場合のトランザクションの範囲

参考

トランザクションを制御するスコープアクティビティのトランザクション制御の範囲について説明します。

トランザクションを制御するスコープアクティビティ内部に定義されているアクティビティでは，トランザクションの制御は行われません。

トランザクションを制御するスコープアクティビティのフォルト処理を行うアクティビティでは，トランザクションの制御は行われます。

トランザクションを制御するスコープアクティビティ以降に定義されたアクティビティでは，トランザクションの制御は行われます。

トランザクションを制御するスコープアクティビティのトランザクション制御の範囲を次の図に示します。

図3‒39　トランザクションを制御するスコープアクティビティのトランザクション制御の範囲

(2)　スコープアクティビティ内部でシステム例外が発生した場合

スコープアクティビティ内部でシステム例外が発生した場合，スコープアクティビティは，トランザクションがコミットした時点（受付：完了状態，スコープ：実行中状態（待ち受け）までロールバックしたあと，スコープの状態にエラー発生（Error）を設定して，トランザクションをコミットします。

スコープアクティビティ内部でシステム例外が発生した場合のトランザクションの範囲を次の図に示します。

図3‒40　スコープアクティビティ内部でシステム例外が発生した場合のトランザクションの範囲

(3)　スコープアクティビティ以降のアクティビティでシステム例外が発生した場合

スコープアクティビティ以降に定義されたアクティビティでシステム例外が発生した場合，トランザクションがコミットした時点（スコープアクティビティ：完了状態（待ち受け））までロールバックします。

スコープアクティビティ以降に定義されたアクティビティでシステム例外が発生した場合のトランザクションの範囲を次の図に示します。

図3‒41　スコープアクティビティ以降に定義されたアクティビティでシステム例外が発生した場合のトランザクションの範囲

(4)　スコープアクティビティ内部でフォルトが発生した場合

トランザクション制御を行うスコープアクティビティの内部に定義されたアクティビティでフォルトが発生し，トランザクション制御を行うスコープアクティビティにフォルトが通知された場合，トランザクションがコミットした時点（受付：完了状態，スコープ：実行中状態（待ち受け）までロールバックしたあと，スコープアクティビティ内部に定義されたアクティビティの処理はキャンセルされます。

フォルトハンドラの定義を基に，対応するアクティビティを実行する場合は，スコープアクティビティの状態をフォルト中状態（Faulting）にします。このとき，状態は遷移しますが，トランザクションはコミットしません。

上位のスコープアクティビティにフォルトを通知する場合は，スコープアクティビティの状態をフォルト終了状態（Faulted）にします。この場合も状態は遷移しますが，トランザクションはコミットしません。上位のスコープアクティビティにフォルトを通知したあとの動作は，トランザクションを制御しないスコープアクティビティの動作と同じです。

スコープアクティビティ内部でフォルトが発生した場合のトランザクションの範囲を次の図に示します。

図3‒42　スコープアクティビティ内部でフォルトが発生した場合のトランザクションの範囲

(5)　フォルト発生後にシステム例外が発生した場合

フォルトハンドラの定義を基に対応するアクティビティを実行し，システム例外が発生した場合，スコープアクティビティは実行中状態（待ち受け）までロールバックします。

フォルト発生後にシステム例外が発生した場合のトランザクションの範囲を次の図に示します。

図3‒43　フォルト発生後にシステム例外が発生した場合のトランザクションの範囲

3.4.6　スコープアクティビティのトランザクション

スコープアクティビティのトランザクションおよびステータスの遷移を次の表に示します。

表3‒10　スコープアクティビティのトランザクションおよびステータスの遷移

スコープアクティビティの動作

トランザクションを制御しない

トランザクションを制御する

遷移するステータス

トランザクション制御

遷移するステータス

トランザクション制御

開始

実行中

×

実行中（待ち受け）

○

終了

完了

×

完了（待ち受け）

○

完了

×

システム例外発生

−

×

エラー

○

フォルト発生（コネクション処理中）

フォルト中

×

フォルト中

×

フォルト発生（コネクション処理完了）

フォルト終了

×

フォルト終了

×

フォルトを上位に通知

フォルト終了

×

フォルト終了

×

省略

省略

×

省略

×

未省略

未省略

×

未省略

×

（凡例）

○：トランザクションをコミットします。

×：トランザクションをコミットしません。

−：ロールバックするためステータスは遷移しません。

3.4.7　応答アクティビティのトランザクション

この項では，応答アクティビティのトランザクション制御について説明します。

応答アクティビティのあとに定義されたアクティビティを非同期に実行する方法については，「3.8　応答アクティビティのあとに定義されたアクティビティの非同期実行」を参照してください。

(1)　応答アクティビティのあとにアクティビティが定義されていない場合のトランザクション制御

応答アクティビティのあとにアクティビティが定義されていない場合，応答アクティビティの実行時に応答アクティビティの状態を完了状態（Completed）に遷移し，メッセージを応答する直前にトランザクションをコミットします。

図3‒44　応答アクティビティのあとにアクティビティが定義されていない場合のトランザクション制御

(2)　応答アクティビティのあとにアクティビティが定義されている場合のトランザクション制御

(a)　応答後のアクティビティ実行にReliable Messagingを使用する場合

応答アクティビティのあとにアクティビティが定義されていて，応答後のアクティビティ実行にReliable Messagingを使用する場合の，トランザクション制御を次に示します。

応答アクティビティのあとにアクティビティが定義されていて，応答後のアクティビティ実行にReliable Messagingを使用する場合，応答アクティビティ実行時に応答アクティビティの状態を完了状態（Completed）に遷移します。

応答のあとに定義されたアクティビティの非同期実行の要求処理をReliable Messagingに対して実行し，メッセージを応答する直前にトランザクションをコミットします。

Reliable Messagingから，応答アクティビティのあとに定義されたアクティビティの非同期実行を実行します。

応答アクティビティのあとに定義されたアクティビティを実行する前に，トランザクションが開始されます。

図3‒45　応答アクティビティのあとにアクティビティが定義されていて，応答後のアクティビティ実行にReliable Messagingを使用する場合のトランザクション制御

応答アクティビティのあとに定義されたアクティビティで例外が発生した場合

応答後のアクティビティ実行にReliable Messagingを使用し，応答アクティビティのあとに定義されたアクティビティで例外が発生した場合のトランザクション制御を次に示します。

応答アクティビティは完了状態（Completed）までロールバックします。

ロールバックによって，Reliable Messagingから応答アクティビティのあとに定義されたアクティビティが再度実行されます。

図3‒46　応答後のアクティビティ実行にReliable Messagingを使用し，応答アクティビティのあとに定義されたアクティビティで例外が発生した場合のトランザクション制御

Reliable Messagingから再送されるかどうかは，配送回数の最大値（RMMaxDeliveryNum）の設定値に依存します。詳細については，マニュアル「Reliable Messaging」を参照してください。

(b)　応答後のアクティビティ実行に非同期EJBを使用する場合

応答アクティビティのあとにアクティビティが定義されていて，応答後のアクティビティ実行に非同期EJBを使用する場合の，トランザクション制御を次に示します。

応答アクティビティの実行時に，応答アクティビティの状態を完了状態（Completed）に遷移します。

応答のあとに定義されたアクティビティの非同期実行の要求処理を非同期EJBに対して実行し，応答アクティビティの状態を完了状態（待ち受け）（Completedwait）に遷移します。

メッセージを応答する直前に，トランザクションをコミットします。

応答のあとに定義されたアクティビティの非同期実行を非同期EJBから実行し，応答アクティビティの状態を完了状態（Completed）に遷移します。

応答のあとに定義されたアクティビティを実行する前に，トランザクションが開始されます。

図3‒47　応答アクティビティのあとにアクティビティが定義されていて，応答後のアクティビティ実行に非同期EJBを使用する場合のトランザクション制御

応答アクティビティのあとに定義されたアクティビティで例外が発生した場合

応答後のアクティビティ実行に非同期EJBを使用し，応答アクティビティのあとに定義されたアクティビティで例外が発生した場合，応答アクティビティは完了状態（待ち受け）（Completedwait）までロールバックします。

応答アクティビティのあとに定義されたアクティビティは，再度実行されません。

図3‒48　応答後のアクティビティ実行に非同期EJBを使用し，応答アクティビティのあとに定義されたアクティビティで例外が発生した場合のトランザクション制御

非同期EJB実行時に例外が発生した場合のトランザクション制御

応答後のアクティビティ実行に非同期EJBを使用し，非同期EJB実行時に例外が発生した場合，応答アクティビティのあとに定義されたアクティビティは実行されません。

応答アクティビティは完了状態（待ち受け）（Completedwait）となります。

図3‒49　応答後のアクティビティ実行に非同期EJBを使用し，非同期EJB実行時に例外が発生した場合のトランザクション制御

(3)　応答アクティビティのトランザクションおよびステータスの遷移

応答アクティビティのトランザクションおよびステータスの遷移を次の表に示します。

表3‒11　応答アクティビティのトランザクションおよびステータスの遷移

応答アクティビティの動作

応答後のアクティビティ実行にReliable Messagingを使用する場合

応答後のアクティビティ実行に非同期EJBを使用する場合

開始

遷移するステータス

完了

完了

トランザクション制御

×※

×※

Reliable Messagingへの非同期実行の要求

遷移するステータス

−

（実行不可）

トランザクション制御

×

Reliable Messagingからの非同期実行の応答

遷移するステータス

−

トランザクション制御

×

非同期EJBへの非同期実行の要求

遷移するステータス

（実行不可）

完了（待ち受け）

トランザクション制御

×※

非同期EJBからの非同期実行の応答

遷移するステータス

完了

トランザクション制御

×※

省略

遷移するステータス

省略

省略

トランザクション制御

×

×

未省略

遷移するステータス

未省略

未省略

トランザクション制御

×

×

（凡例）

×：トランザクションをコミットしません。

−：遷移しません。

注※

この時点ではコミットされませんが，それ以降のトランザクション制御のタイミングでコミットされます。

3.4.8　途中終了アクティビティのトランザクション

この項では，途中終了アクティビティのトランザクション制御について説明します。

(1)　途中終了アクティビティのトランザクション制御

途中終了アクティビティ実行時に，途中終了アクティビティの状態を完了状態（Completed）に遷移し，プロセス内のCOMPLETED状態以外のアクティビティをCOMPLETED状態に遷移して，トランザクションをコミットします。

図3‒50　途中終了アクティビティのトランザクション制御

(2)　トランザクションの制御を行うスコープアクティビティ内部に途中終了アクティビティを定義した場合のトランザクション制御

トランザクション制御を行うスコープアクティビティ内部に途中終了アクティビティを定義した場合，途中終了アクティビティの終了で，途中終了アクティビティの状態を完了状態（Completed）に遷移し，プロセス内のCOMPLETED状態以外のアクティビティをCOMPLETED状態に遷移して，トランザクションをコミットします。

図3‒51　トランザクションの制御を行うスコープアクティビティ内部に途中終了アクティビティを定義した場合のトランザクション制御

3.5　ビジネスプロセスの再実行

ビジネスプロセス実行中に，実行基盤のあるマシンが停止したり，サービス部品の呼び出しに失敗したりした場合，障害が発生して中断したプロセスインスタンスを再実行できます。プロセスインスタンスを再実行することで，ビジネスプロセスの内容が処理できます。

プロセスインスタンスを再実行できる条件を次に示します。

HCSCサーバが起動している場合

ビジネスプロセスが起動している場合

同期（SessionBean）の標準受付が起動されている場合

Reliable Messagingを使用する環境で，非同期（MDB（WS-R））の標準受付が起動されている場合

フォルト送出機能を使用していない場合

フォルト送出機能の詳細については，「4.7.1　システム例外をフォルトに変換する汎用フォルトの概要」を参照してください。

再実行対象となるステータスを次に示します。

プロセスのステータス

アクティビティ

種別

ステータス

実行中

サービス呼出

実行中

エラー状態

サービス呼出

エラー状態

実行中

待機

実行中

実行中

スコープ

実行中状態（待ち受け）

エラー状態

スコープ

エラー状態

実行中

スコープ

完了状態（待ち受け）

実行中

応答

完了状態（待ち受け）

3.5.1　運用環境の画面からの再実行

運用環境の画面から，中断したプロセスインスタンスを一件ずつ再実行できます。

画面によるプロセスインスタンスの再実行の手順については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「6.1.5　プロセスインスタンスを再実行する」を参照してください。

3.5.2　コマンドからの再実行

コマンドを使用して，中断したプロセスインスタンスを1件ずつ再実行できます。

また，複数のプロセスインスタンスを一括して再実行することもできます。1つのHCSCサーバ上にある複数のプロセスインスタンスを一括して再実行したり，HCSCサーバ名を指定してHCSCサーバ単位で再実行したりできます。プロセスインスタンスの実行履歴の一括再実行は，コマンドでだけ実行できます。

コマンドによるプロセスインスタンスの再実行の手順については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「6.1.5　プロセスインスタンスを再実行する」を参照してください。

3.5.3　サービスリクエスタからの再実行（SOAP通信）

サービス部品の呼び出し処理で例外になって中断したプロセスインスタンスは，システム運用管理者だけでなく，サービスリクエスタからも再実行できます。

サービスリクエスタから再実行するには，同期（Webサービス）の標準受付に再実行要求を出すサービスリクエスタを作成します。

サービス部品の呼び出しがエラーになり，ビジネスプロセスインスタンスIDがエラー情報として返ってきた場合は，そのビジネスプロセスインスタンスIDを指定して再実行します。SOAP通信でのサービスリクエスタからの要求の再実行を次の図に示します。

図3‒52　SOAP通信でのサービスリクエスタからの要求の再実行

ビジネスプロセスの再実行を要求するサービスリクエスタの作成については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「9.2.9　ビジネスプロセスの再実行を要求するサービスリクエスタの作成（Webサービス・SOAP通信基盤）」を参照してください。

3.5.4　サービスリクエスタからの再実行（SessionBean）

同期（SessionBean）の標準受付に要求を出すサービスリクエスタからも，ビジネスプロセスの再実行要求ができます。サービスリクエスタから再実行するには，同期（SessionBean）の標準受付に要求を出すサービスリクエスタを作成します。

サービス部品呼び出しがエラーになり，ビジネスプロセスインスタンスIDが例外（エラー情報）として返ってきた場合は，そのビジネスプロセスインスタンスIDを指定して再実行します。SessionBeanでのサービスリクエスタからのビジネスプロセスの再実行を次の図に示します。

図3‒53　SessionBeanでのサービスリクエスタからのビジネスプロセスの再実行

ビジネスプロセスの再実行を要求するサービスリクエスタの作成については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「9.4.8　ビジネスプロセスの再実行を要求するサービスリクエスタの作成（SessionBean）」を参照してください。

3.6　ビジネスプロセスのスケジュール設定

スケジュール駆動受付を使用して，スケジュール設定に定義した間隔でタスクを実行し，ビジネスプロセスを呼び出すことができます。

ビジネスプロセスのスケジュール設定処理の流れを次の図に示します。

図3‒54　ビジネスプロセスのスケジュール設定処理の流れ

スケジュール駆動受付のスケジュール設定に定義したスケジュールでイベントが発生します。

イベント発生時にタスクが生成されます。

タスク実行機能が生成されたタスクを実行します。

タスクの実行に合わせて，ビジネスプロセスが呼び出されます。

なお，1つのスケジュール駆動受付から1つのビジネスプロセスに接続できます。複数のスケジュール駆動受付から1つのビジネスプロセスに接続することもできます。

スケジュール駆動受付で使用できる通信モデルは，非同期通信です。

3.6.1　スケジュール駆動受付でのスケジュールの設定

スケジュール駆動受付を使用して，設定されたスケジュールに従ってイベントを発生させます。

スケジュールは，周期実行で設定します。周期実行とは，スケジュールの実行の開始から，一定の間隔でイベントを発生させる実行方法です。

スケジュール設定は，スケジュール駆動受付定義ファイルで設定します。

スケジュール設定に関して設定できる項目を次に示します。

イベント発生の間隔：scdrecp.event.occurrence-interval

同時に実行できるタスクの最大数：urecp-scd.task.processing-max.parallel.count

新たにタスクを生成して実行するかどうかの指定：scdrecp.allow.new-task.executing

作業フォルダの作成：scdrecp.create.work-dir

作業フォルダの削除：scdrecp.work-dir.auto-delete

イベント発生時には，イベント処理が行われます。

イベント処理では，イベント発生時にスケジュール駆動受付の状態を取得して，イベント処理が続行できるかどうかを判断します。イベント処理は，スケジュール駆動受付の状態によって処理が異なります。スケジュール駆動受付の状態とイベント処理の対応を次に示します。

表3‒12　スケジュール駆動受付の状態とイベント処理の対応

スケジュール駆動受付の状態

イベント処理

active（開始状態）

イベント処理が続行できると判断されます。タスクを生成して，タスク実行機能を呼び出します。ただし，イベント発生時に実行中のタスクがすでにある場合は，タスクを生成しないで，イベント処理を終了することがあります。

starting（開始処理中）

イベント処理が続行できると判断されます。10ミリ秒待機後に，スケジュール駆動受付の状態を取得して，再度スケジュール駆動受付の状態に応じたイベント処理を行います。

上記以外（stopping（停止処理中）など）

イベント処理が続行できないと判断されます。

タスクを生成しないで，イベント処理を終了します。実行中のタスクがあるかどうかは確認しません。

3.6.2　スケジュール駆動受付でのタスクの実行

スケジュール駆動受付を使用して，イベント発生時に作成されたタスクを実行します。

通常の動作では，タスクはイベントが発生した順に処理されます。ただし，イベントの発生時にすでに実行中のタスクがある場合や，実行を待機しているタスクがある場合，イベントが発生した順にタスクが処理されないことがあります。

イベントの発生時にすでに実行中のタスクがある場合は，タスクを「逐次」または「並列」で処理できます。なお，実行中のタスク処理をキャンセルすることはできません。

タスクの処理順序の詳細については，「(1) タスクの逐次処理」および「(2) タスクの並列処理」を参照してください。

スケジュール駆動受付の呼び出し先のビジネスプロセスを同時実行するかどうかによって，タスクの処理順序を選択する必要があります。ビジネスプロセスの同時実行の有無とタスクの処理順序の関係について，次に示します。

表3‒13　ビジネスプロセスの同時実行の有無とタスクの処理順序の関係

ビジネスプロセスの同時実行の有無

タスクの処理順序

同時実行できない

逐次

同時実行できる

逐次または並列

逐次処理，および並列処理の設定は，スケジュール駆動受付定義ファイルの「urecp-scd.task.processing-max.parallel.count」で設定します。

スケジュール駆動受付定義ファイルの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「3.15.1　スケジュール駆動受付定義ファイル」を参照してください。

(1)　タスクの逐次処理

逐次処理では，イベントの発生順に逐次タスクを生成して実行します。

イベントの発生時にすでに実行中のタスクがある場合は，新たにタスクを生成して実行するかどうかを設定できます。新たにタスクを生成して実行するかどうかの設定は，スケジュール駆動受付定義ファイルの「scdrecp.allow.new-task.executing」で設定します。

ただし，次の場合はタスクが実行中であるかを判断できないため，実行中のタスクがあるかどうかに関係なく，新たにタスクを生成する動作となります。

HCSCサーバやスケジュール駆動受付を再起動した場合

HCSCサーバがクラスタ構成の場合

(a)　新たにタスクを実行する

イベントの発生時にすでに実行中のタスクがあった場合，新たにタスクを生成して実行を試みることができます。スケジュール駆動受付定義ファイルの「scdrecp.allow.new-task.executing」にtrueを設定します。

ただし，実行中のタスクの処理が終了するまで，新たなタスクの実行は，待機状態となります。また，実行中のタスクの処理が終了してから，新たに生成されたタスクと，待機しているタスクの処理順序は不確定です。

タスクの実行の待機時間は，無制限となります。

図3‒55　新たにタスクを実行するときの処理

この例では，1回目のタスクの処理時間が，2回目のイベント発生時刻に重なっています。この場合，2回目のイベント発生時刻にタスクが生成されますが，1回目のタスクの処理が終了するまで2回目のイベント処理で生成したタスクは実行されません。3回目のイベントでは，3回目のイベント発生時刻に重なっていたタスクの処理がないため，3回目のイベント発生時刻に，タスクが実行されます。

また，実行を待機しているタスクがある場合，スケジュールは停止しません。待機しているタスクの処理が終了してから，スケジュールが停止します。

図3‒56　タスクの実行中にスケジュールの停止処理を実行した場合の動作（新たにタスクを実行する）

この例では，1回目のタスクの処理時間が2回目のイベント発生時刻に重なっているため，2回目のイベントで実行するタスク処理の実行を待機します。また，2回目のイベント発生時刻より，あとにスケジュールの停止処理を実行しているため，待機している2回目のタスクの処理が完了してから，スケジュールが停止します。

なお，3回目のイベント発生時刻までに，待機していたタスクの処理が完了しているため，3回目のイベントは発生しません。

(b)　新たにタスクを生成しない

イベントの発生時にすでに実行中のタスクがあった場合，新たにタスクを生成しないときは，スケジュール駆動受付定義ファイルの「scdrecp.allow.new-task.executing」にfalseを設定します。新たにタスクを生成しないときは，実行中のタスクの処理完了後の，次のイベント発生時にタスクが生成され，実行されます。

図3‒57　新たにタスクを生成しないときの処理

この例では，1回目のタスクの処理時間が2回目のイベント発生時刻に重なっています。2回目のイベント発生時刻にタスクが実行中のため，2回目のイベントではタスクは生成されません。3回目のイベントは，3回目のイベント発生時刻に重なっているタスクがないため，タスクが生成・実行されます。

また，タスクの実行中にスケジュールの停止処理を実行した場合，実行中のタスクの処理が終了したあと，タスクは実行されません。

図3‒58　タスクの実行中にスケジュールの停止処理を実行した場合の動作（新たにタスクを実行しない）

この例では，1回目のタスクの処理時間が2回目のイベント発生時刻に重なっているため，2回目のイベントではタスクを生成されません。また，2回目のイベント発生時刻よりあとにスケジュールの停止処理を実行しているため，スケジュールの停止の実行後はイベントが発生しません。

(c)　イベント発生の間隔を超えてもタスクの処理が終了しない場合

タスクの処理順序が「逐次」で，イベント発生の間隔を超えてもタスクの処理が終了しない場合，実行中のタスクがあることをメッセージログに出力します。なお，スケジュールの実行は継続されます。

(2)　タスクの並列処理

並列処理では，イベントの発生時にすでに実行中のタスクがある場合，実行中のタスクの完了を待たないで，次のイベントを発生させます。実行中のタスクがある場合でも，並列でタスクを実行できます。

並列して処理できるタスク数は，スケジュール駆動受付定義ファイルの「urecp-scd.task.processing-max.parallel.count」で設定します。なお，並列して処理できるタスク数を超えた場合，新たなタスクは実行中のタスク処理の完了を待ってから実行されます。

タスクの実行の待機時間は，無制限となります。

図3‒59　タスクの並列処理

この例では，1回目のタスクの処理時間が，2回目と3回目のイベント発生時刻に重なっています。この場合，1回目のタスクの処理が終了するのを待たないで，2回目のイベントでタスクが生成され，実行されます。また，3回目のイベント発生時刻にすでにタスクが2つ実行されているため，3回目のイベントではタスクの実行が待機され，2回目のイベントのタスク完了後に，3回目のイベントのタスクが実行されます。

3.6.3　スケジュール駆動受付の作業フォルダ

スケジュール駆動受付では，タスク単位で作業フォルダを作成できます。作成した作業フォルダは，スケジュール駆動受付から呼び出すビジネスプロセスで使用できます。

作業フォルダの作成は，スケジュール駆動受付定義ファイルの「scdrecp.create.work-dir」で設定します。「scdrecp.create.work-dir」にtrueを設定した場合，タスクの実行時にリクエストIDを生成して，作業フォルダが作成されます。生成したリクエストIDは，要求電文に設定します。

また，ビジネスプロセスの処理が正常に終了した場合，スケジュール駆動受付で作成した作業フォルダの自動削除を設定できます。次のすべての条件に当てはまる作業フォルダが，自動的に削除されます。

スケジュール駆動受付定義ファイルの「scdrecp.work-dir.auto-delete」にtrueを設定した。

タスク処理が正常に完了した。

3.6.4　スケジュール駆動受付のタイマ監視

スケジュール駆動受付コンフィグファイルの「urecp-scd.request-timeout」の設定に従って，ビジネスプロセスに要求電文を渡してから，ビジネスプロセスの応答が返ってくるまでの処理時間を監視します。デフォルトでは，タイマ監視を行いません。

監視時間が経過しても応答が返ってこない場合は，メッセージを出力します。メッセージ出力後は，ビジネスプロセスの処理が完了してから，ビジネスプロセスの応答をスケジュール駆動受付に返却します。

タイマ監視で使われるスレッドのうち，スケジュール駆動受付の起動時に生成して常駐させるスレッドの数は，スケジュール駆動受付コンフィグファイルの「urecp-scd.resident-thread.count」で設定できます。

タイマ監視に使われるスレッドの最大数は，スケジュール駆動受付定義ファイルの「urecp-scd.task.processing-max.parallel.count」で設定します。

3.6.5　スケジュール駆動受付のトランザクション

ビジネスプロセスを呼び出すときのスケジュール駆動受付のトランザクションは，タイマ監視を行うかどうかで異なります。

(1)　タイマ監視を行わない場合

タイマ監視を行わない場合のトランザクションを次に示します。

図3‒60　タイマ監視を行わない場合のトランザクション

(2)　タイマ監視を行う場合

タイマ監視を行う場合は，別スレッドでビジネスプロセスの呼び出しが行われるため，新たなトランザクションを開始します。

タイマ監視に設定するタイムアウト値は，J2EEサーバのトランザクションタイムアウトの値よりも大きな値を設定することを推奨します。

図3‒61　タイマ監視を行う場合のトランザクション

3.7　ビジネスプロセスを使用した待機処理

待機アクティビティを定義してビジネスプロセスを実行すると，特定の期限に達するまでビジネスプロセスの処理を遅延させることができます。待機アクティビティを定義したビジネスプロセスの待機処理を次の図に示します。

図3‒62　待機アクティビティを定義したビジネスプロセスの待機処理

繰り返しアクティビティの中に待機アクティビティを定義することで，日次処理などの一定間隔での処理を実現することもできます。繰り返しアクティビティの中に待機アクティビティを定義した場合の，ビジネスプロセスの待機処理を次の図に示します。

図3‒63　繰り返しアクティビティの中に待機アクティビティを定義したビジネスプロセスの待機処理

待機アクティビティの定義について次に説明します。

3.7.1　待機アクティビティでの待機時間の指定

待機アクティビティでは，待機時間として次のどちらかを指定します。

待機する間隔

待機を解除する期限

どちらの場合もXPath式を使用して待機時間を指定します。XPath式を使用すると，ビジネスプロセス内を流れる変数内の時刻に従って動作するため，待機時間を動的に指定できます。また，XPath式の代わりに，待機する間隔または待機を解除する期限を直接指定することもできます。待機する間隔はXML Schema型duration，待機を解除する期限はXML Schema型dateTimeで指定します。詳細については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「5.6.11　待機アクティビティ」を参照してください。

3.7.2　待機アクティビティを実行するための条件

待機アクティビティは，永続化しないビジネスプロセスでは使用できない，応答アクティビティのあとに設定しなければならないなど，幾つかの条件があります。待機アクティビティを実行するための条件については，マニュアル「サービスプラットフォーム 開発ガイド基本開発編」の「5.6.11　待機アクティビティ」を参照してください。

3.7.3　待機アクティビティに関する多重度

待機アクティビティを使用する上で性能を考えた場合，待機アクティビティに関する多重度を見直す必要があります。

待機アクティビティで指定した時間に待機処理を解除するプロセスインスタンスが複数存在している場合で，そのプロセスインスタンスの数よりJ2EEサーバのTimerServiceでタイムアウトメソッドをコールバックする最大スレッド数が小さいときは，性能上のボトルネックになることがあります。このような場合，J2EEサーバの環境設定で，タイムアウトメソッドのコールバックの最大スレッド数を設定します。

TimerServiceでタイムアウトメソッドをコールバックする最大スレッド数は，運用管理ポータルの［論理サーバの環境設定］で設定します。EJBコンテナの設定画面を開き，「タイムアウトメソッドのコールバックの最大スレッド数」※の値を，ビジネスプロセスのインスタンス数に合わせて変更してください。設定方法の詳細については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「10.8.3　EJBコンテナの設定」を参照してください。

注※

J2EEサーバ用ユーザプロパティファイル（usrconf.properties）のejbserver.ejb.timerservice.maxCallbackThreadsキーに対応します。

3.8　応答アクティビティのあとに定義されたアクティビティの非同期実行

応答アクティビティのあとに任意のアクティビティを定義すると，そのアクティビティはReliable Messagingまたは非同期EJBを使用して非同期に実行できます。

応答後のアクティビティ実行で使用する機能は，データベースやReliable Messagingの有無によって次のように異なります。

表3‒14　応答後のアクティビティ実行で使用する機能

Reliable Messaging

データベース

あり

なし

あり

永続化するビジネスプロセスの場合

Reliable Messaging

永続化しないビジネスプロセスの場合

非同期EJB※

−

なし

非同期EJB※

非同期EJB※

（凡例）

−：該当なし。

注※

応答後のアクティビティ実行にReliable Messagingでなく非同期EJBを使用する場合，次に示す機能は使用できません。

障害発生時に，Reliable Messagingのリトライ機能を利用したリカバリ処理が使用できません。

リカバリ処理の詳細については，「3.4.7　応答アクティビティのトランザクション」を参照してください。

Reliable Messagingを前提とする次の受付およびサービスアダプタは使用できません。

標準受付（MDB（WS-R））

標準受付（MDB（DBキュー））

標準アダプタ（MDB（WS-R））

標準アダプタ（MDB（DBキュー））

3.8.1　非同期EJBを使用して非同期実行する場合の設定項目

非同期EJBを使用する場合，HCSCサーバランタイム定義ファイルに次のプロパティで設定します。

bp-reply-after-max-thread-pool-size

プールに生成できるスレッドの最大数を設定します。デフォルト値は32です。

bp-reply-after-min-thread-pool-size

プール内で使用していないスレッドを幾つまで保存できるかを設定します。デフォルト値は16です。

bp-reply-after-thread-pool-keep-alive

使用していないスレッド数がmin-thread-pool-sizeで設定した数を超えている場合に，スレッドを終了するまでに保存しておく時間（単位：秒）を設定します。デフォルト値は60です。

HCSCサーバランタイム定義ファイルの設定内容については，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

応答後のアクティビティの実行の概要を次に示します。

図3‒64　応答後のアクティビティ実行の概要

3.8.2　非同期EJBの実行で例外が発生した場合の再実行方法

応答アクティビティのあとに定義されたアクティビティで例外が発生した場合や，非同期EJBの実行時に例外が発生した場合，プロセスは次の状態となり，一括再実行の対象になります。

プロセスインスタンス：実行中状態

応答アクティビティ：完了状態（待ち受け）

応答アクティビティ以降に定義されたアクティビティ：未実行状態

プロセスインスタンスの再実行によって，応答アクティビティ以降に定義されたアクティビティを実行できます。

3.9　ログ出力アクティビティでのログ出力

ログ出力アクティビティを使用して，任意のログファイルを出力できます。

次のメッセージをログ出力アクティビティのログファイルとして出力できます。

メッセージ定義ファイルに定義したメッセージ

［ログ出力アクティビティ］ダイアログで設定した任意の文字列

ログ出力アクティビティは，［ログ出力アクティビティ］ダイアログで設定します。ログ出力アクティビティの設定方法については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「5.6.13　ログ出力アクティビティ」を参照してください。

ここでは，ログ出力アクティビティのログファイルに出力できる内容，取得方法，および出力方法について説明します。

3.9.1　設定に応じたログファイルの出力内容

［ログ出力アクティビティ］ダイアログでの設定によって，ログ出力アクティビティのログファイルに出力できる内容が異なります。

それぞれに必要な設定と出力されるログ出力アクティビティのログファイルの内容について説明します。

出力内容の詳細については，「3.9.3(3)　ログ出力アクティビティのログファイルの出力内容」を参照してください。

［ログ出力アクティビティ］ダイアログで設定した任意の文字列を出力する場合

［ログ出力アクティビティ］ダイアログで設定した任意の文字列を出力する場合，ログ出力アクティビティ定義ファイルの設定が必要です。

ログ出力アクティビティ定義ファイルの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「3.20.1　ログ出力アクティビティ定義ファイル」を参照してください。

なお，任意の文字列を出力する場合，ログレベルによるログ出力の制御はできません。自動的にログレベル「ERROR」が設定されます。

ログファイルが出力されるまでのログ出力アクティビティの動作について，次の図に示します。

図3‒65　ログ出力アクティビティの動作（［ログ出力アクティビティ］ダイアログで設定した任意の文字列を出力する場合）

メッセージとして［ログ出力アクティビティ］ダイアログで設定した任意の文字列を取得します。また，ログ出力識別子に該当するログファイルのファイルパスをログ出力アクティビティ定義ファイルから取得します。

1.で作成したメッセージを，ログ出力アクティビティ定義ファイルに定義されているログファイルに出力します。

メッセージ定義ファイルに定義したメッセージを出力する場合

メッセージ定義ファイルに定義したメッセージを出力する場合，ログ出力アクティビティ定義ファイル，およびメッセージ定義ファイルの設定が必要です。

ログ出力アクティビティ定義ファイル，およびメッセージ定義ファイルの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「3.20.1　ログ出力アクティビティ定義ファイル」および「3.20.2　メッセージ定義ファイル」を参照してください。

ログファイルが出力されるまでのログ出力アクティビティの動作について，次の図に示します。なお，この例ではメッセージに埋め込み要素を使用しています。

図3‒66　ログ出力アクティビティの動作（メッセージ定義ファイルに定義したメッセージを出力する場合）

ログ出力アクティビティ定義ファイルに設定されているメッセージ定義ファイルの場所を探し，ログ出力アクティビティで設定したリソースKey（msg_id_001-ERROR）に該当するメッセージを取得します。

［ログ出力アクティビティ］ダイアログで設定した埋め込み要素（変数名：input，部分名：part_elm1）の値（value1）を取得します。

1.で取得したメッセージに2.で取得した埋め込み文字（値：value1）を設定します。

3.で作成したメッセージを，ログ出力アクティビティ定義ファイルに定義されているログファイルに出力します。

3.9.2　ログ出力アクティビティのログファイルの取得方法

ログ出力アクティビティを設定すると，ユーザが指定した任意のメッセージをログ出力アクティビティのログファイルに出力できます。

ログ出力アクティビティのログファイルを出力するには，ログ出力アクティビティ定義ファイルなどの定義ファイルを準備します。その後，ビジネスプロセス定義画面でログ出力アクティビティを配置し，［ログ出力アクティビティ］ダイアログで必要な情報を指定します。

［ログ出力アクティビティ］ダイアログの指定方法については，マニュアル「サービスプラットフォーム リファレンス」の「1.4.19　ログ出力アクティビティダイアログ」を参照してください。

ログ出力アクティビティの定義手順については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「5.6.13　ログ出力アクティビティ」を参照してください。

出力されたログ出力アクティビティのログファイルの確認方法については，「3.9.3　ログ出力アクティビティのログファイルの出力」を参照してください。

ログ出力アクティビティで使用する定義ファイルを次に示します。

ログ出力アクティビティ定義ファイル

メッセージ定義ファイル

HCSCサーバランタイム定義ファイル

これらの定義ファイルの定義内容を次に示します。

(1)　ログ出力アクティビティ定義ファイルの定義内容

ログ出力アクティビティ定義ファイルでは，ログ出力アクティビティのログファイルに関する情報を次に示すプロパティで指定します。ログ出力識別子は，ログ出力アクティビティのログファイルの出力先を一意に識別するための文字列です。

log-activity.<ログ出力識別子>.filepath=出力先パス

log-activity.<ログ出力識別子>.filesize=1面当たりのファイルサイズ

log-activity.<ログ出力識別子>.filenum=ファイルの面数

log-activity.<ログ出力識別子>.level=ファイルの出力レベル

また，出力するメッセージの内容をメッセージ定義ファイルに定義する場合は，メッセージ定義ファイルのパスを次に示すプロパティで指定します。

log-activity.<ログ出力識別子>.message-definition-filepath=メッセージ定義ファイルのファイルパス

ここで定義したログ出力識別子は，ログ出力アクティビティの設定時に［ログ出力アクティビティ］ダイアログで指定します。

ログ出力アクティビティ定義ファイルの定義方法の詳細については，マニュアル「サービスプラットフォーム リファレンス」の「3.20.1　ログ出力アクティビティ定義ファイル」を参照してください。

ログ出力アクティビティのログファイルは，log-activity.<ログ出力識別子>.filesizeで指定したファイルサイズに達したときローテーションが実行されます。時刻によるログの出力先ファイルの切り替え，および出力先ファイル切り替え時のファイル名付与規則については，Application Serverの設定に従います。

詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

(2)　メッセージ定義ファイルの定義内容

ログ出力アクティビティのログファイルに出力する任意のメッセージは，［ログ出力アクティビティ］ダイアログで直接設定するほかに，メッセージ定義ファイルで定義することもできます。

メッセージ定義ファイルには，リソースKeyとメッセージを定義します。ここで定義したリソースKeyは，ログ出力アクティビティの設定時に［ログ出力アクティビティ］ダイアログで指定します。

メッセージ定義ファイルのファイルは，ログ出力識別子ごと（ログの出力先ごと）に作成します。作成したメッセージ定義ファイルのパスは，ログ出力アクティビティ定義ファイルに指定します。

メッセージ定義ファイルの定義方法の詳細については，マニュアル「サービスプラットフォーム リファレンス」の「3.20.2　メッセージ定義ファイル」を参照してください。

(3)　HCSCサーバランタイム定義ファイルの定義内容

HCSCサーバランタイム定義ファイルの次に示すプロパティで，ログ出力アクティビティ定義ファイルのパスを指定します。

bp-log-activity-definition-filepath=ログ出力アクティビティ定義ファイルのパス

HCSCサーバランタイム定義ファイルの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

3.9.3　ログ出力アクティビティのログファイルの出力

ログ出力アクティビティを定義した場合，任意のメッセージをログファイルとして出力できます。

ログ出力アクティビティの定義手順については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「5.6.13　ログ出力アクティビティ」を参照してください。

ログ出力アクティビティのログファイルの出力開始・停止のタイミングを次に示します。

HCSCサーバが起動すると，ログファイルの出力が開始されます。

出力開始に失敗した場合，エラーメッセージを出力して開始処理を終了します。障害対策後にHCSCサーバの起動を実行することで，ログファイルの出力が開始されます。

HCSCサーバが停止すると，ログファイルの出力が停止されます。

出力停止に失敗した場合，警告メッセージを出力して停止処理を続行します。

ログファイルの出力開始後にメッセージの出力に失敗すると，警告メッセージを出力してログ出力アクティビティの処理を続行します。同じログ出力識別子を設定したログ出力アクティビティでは，メッセージは出力されなくなります。

障害対策後にHCSCサーバの起動を実行することで，ログファイルの出力が開始されます。

この項では，ログ出力アクティビティのログファイルの出力先や出力される内容，および利用方法の例について説明します。ログ出力アクティビティのログファイルの取得方法については，「3.9.2　ログ出力アクティビティのログファイルの取得方法」を参照してください。

(1)　ログ出力アクティビティのログファイルの出力先

ログ出力アクティビティのログファイルの出力先は，ログ出力アクティビティ定義ファイルのlog-activity.<ログ出力識別子>.filepathプロパティで設定した個所です。出力先はログ出力識別子によって異なります。

ログ出力アクティビティ定義ファイルのプロパティについては，マニュアル「サービスプラットフォーム リファレンス」の「3.20.1　ログ出力アクティビティ定義ファイル」を参照してください。

(2)　ログ出力アクティビティのログファイルの出力形式

ログ出力アクティビティのログファイルの出力形式を次に示します。

<番号> <日付> <時刻> <製品ID> <pid> <tid> <ID> <ログ出力文字列>

(3)　ログ出力アクティビティのログファイルの出力内容

ログ出力アクティビティのログファイルに出力される内容を次の表に示します。

表3‒15　ログ出力アクティビティのログファイルに出力される内容

項目

内容

番号

ログ出力アクティビティのログファイルの出力通番が表示されます。

日付

ログ出力アクティビティのログファイルの取得日付がyyyy/mm/ddの形式で出力されます。

yyyy：西暦年

mm：月

dd：日

時刻

ログ出力アクティビティのログファイルの取得時刻がhh:mm:ss.SSSの形式で出力されます。

hh：時

mm：分

ss：秒

SSS：ミリ秒

ローカル時刻でミリ秒単位の時刻を示します。

製品ID

製品を特定するための識別子として，「CSCBP」が表示されます。

pid

プロセスを識別するためのIDが出力されます。

tid

スレッドを識別するためのIDが出力されます。

ID

空白

ログ出力文字列

ログ出力アクティビティで定義した任意のメッセージが出力されます。

4　システム動作を円滑にするための機能

この章では，システム動作を円滑にするための機能について説明します。

4.1　HCSCサーバに関連するタイマの設定

同期のサービス部品呼び出しの場合，応答が返って来ない場合のタイムアウト値を設定することで，無応答でハングアップすることを回避できます。また，サービス部品での実際の処理に掛かる最大時間を考慮して，タイマを設定する必要があります。

4.1.1　HCSCサーバで設定できるタイマ

HCSCサーバで設定できるタイマについて次の図に示します。

図4‒1　設定できるタイマ

「図4-1　設定できるタイマ」の各項番は次のタイマを示しています。

サービス部品に接続するときのタイマ（Webサービス）

サービス部品に接続するときのタイマ（SessionBean）

HCSCサーバに接続するときのタイマ（Webサービス）

HCSCサーバに接続するときのタイマ（SessionBean）

HCSCサーバ内のトランザクションのタイマ

タイマは接続先やプロトコルによって設定方法が異なります。

(1)　サービス部品に接続するときのタイマ（Webサービス）

サービス部品（Webサービス）に接続する場合，書き込み，読み込み，および接続時のタイマを設定できます。

書き込み時のタイマ

HTTPおよびHTTPS（TCP/IP通信）で使用するソケットに対するwrite（データ送信）処理でのタイムアウト値を設定します。接続確立後のデータ送信が完了しない場合などで有効となります。

読み込み時のタイマ

HTTPおよびHTTPS（TCP/IP通信）で使用するソケットに対するread（データ受信）処理でのタイムアウト値を設定します。接続確立後のデータ受信が完了しない場合などで有効となります。

接続時のタイマ

HTTPおよびHTTPS（TCP/IP通信）で使用するソケットに対するconnect（ソケット接続）処理でのタイムアウト値を設定します。接続確立時の要求に対する応答がない場合などで有効となります。

タイムアウト値の設定は，SOAP通信基盤を利用する場合と，JAX-WSエンジンを利用する場合で異なります。それぞれの場合の設定方法を説明します。

(a)　タイムアウト値の設定（SOAP通信基盤）

SOAP通信基盤（SOAP1.1モード）を利用する場合のタイムアウト値の設定方法について説明します。タイムアウト値は，HCSCサーバ全体またはサービスアダプタ個別に設定できます。

HCSCサーバ全体の設定

タイムアウト値は，HCSCサーバ稼働マシンのSOAP通信基盤のサーバ定義ファイルで定義します。サーバ定義ファイルの設定については，マニュアル「アプリケーションサーバ SOAPアプリケーション開発の手引」の「10.2　サーバ定義ファイルの設定」を参照してください。

表4‒1　HCSCサーバ全体のタイマ（Webサービス）の設定（SOAP通信基盤）

値

キー名称

デフォルト値（秒）

サーバ兼クライアントのソケットの書き込みタイムアウト値

c4web.application.<識別子>.socket_write_timeout

60

サーバ兼クライアントのソケットの読み込みタイムアウト値

c4web.application.<識別子>.socket_read_timeout

300

サーバ兼クライアントのソケットの接続タイムアウト値

c4web.application.<識別子>.socket_connect_timeout

60

サービスアダプタ個別の設定

開発環境で設定する場合，サービスアダプタ定義画面のクライアント定義ファイルに指定します。クライアント定義ファイルの設定については，マニュアル「アプリケーションサーバ SOAPアプリケーション開発の手引」の「10.3　クライアント定義ファイルの設定」を参照してください。

表4‒2　サービスアダプタ個別のタイマ（Webサービス）の設定（SOAP通信基盤）

値

キー名称

デフォルト値（秒）

クライアントのソケットの書き込みタイムアウト値

c4web.application.socket_write_timeout

60

クライアントのソケットの読み込みタイムアウト値

c4web.application.socket_read_timeout

300

クライアントのソケットの接続タイムアウト値

c4web.application.socket_connect_timeout

60

(b)　タイムアウト値の変更（SOAP通信基盤）

すでにHCSCサーバに配備しているサービスアダプタに対して運用環境で定義する場合は，cscsvcctlコマンドを使用して，サービス部品呼び出しの通信タイムアウト値を変更します。変更方法の詳細については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「5.3.28　サービス部品呼び出しの通信タイムアウト値を変更する」を参照してください。cscsvcctlコマンドの使い方については，マニュアル「サービスプラットフォーム リファレンス」の「cscsvcctl（サービス情報の管理）」を参照してください。

表4‒3　タイマ（Webサービス）の設定値の変更（SOAP通信基盤）

値

キー名称

書き込みタイムアウト値

<クラスタ名>.<サービスID>.WebService.c4web.application.socket_write_timeout

読み込みタイムアウト値

<クラスタ名>.<サービスID>.WebService.c4web.application.socket_read_timeout

接続タイムアウト値

<クラスタ名>.<サービスID>.WebService.c4web.application.socket_connect_timeout

(c)　タイムアウト値の設定（JAX-WSエンジン）

JAX-WSエンジン（SOAP1.1/1.2併用モード）を利用する場合のタイムアウト値の設定方法について説明します。タイムアウト値は，HCSCサーバ全体またはサービスアダプタ個別に設定できます。

HCSCサーバ全体の設定

HCSCサーバ稼働マシンのJAX-WSエンジンの共通定義ファイルで定義します。共通定義ファイルの設定については，マニュアル「アプリケーションサーバ Webサービス開発ガイド」の「10.1.2　共通定義ファイルの設定項目」を参照してください。

表4‒4　HCSCサーバ全体のタイマ（Webサービス）の設定（JAX-WSエンジン）

値

キー名称

デフォルト値（ミリ秒）

サーバ兼クライアントのソケットの読み込みタイムアウト値

com.cosminexus.jaxws.request.timeout

300000

サーバ兼クライアントのソケットの接続タイムアウト値

com.cosminexus.jaxws.connect.timeout

60000

サービスアダプタ個別の設定

開発環境で設定する場合，サービスアダプタ定義画面のクライアント定義ファイルに指定します。クライアント定義ファイルの設定については，マニュアル「サービスプラットフォーム リファレンス」の「3.6.2　クライアント定義ファイル」を参照してください。

表4‒5　サービスアダプタ個別のタイマ（Webサービス）の設定（JAX-WSエンジン）

値

キー名称

デフォルト値（秒）

クライアントのソケットの読み込みタイムアウト値

com.cosminexus.csc.request.timeout

300

クライアントのソケットの接続タイムアウト値

com.cosminexus.csc.connect.timeout

60

(d)　タイムアウト値の変更（JAX-WSエンジン）

すでにHCSCサーバに配備しているサービスアダプタに対して運用環境で定義する場合は，cscsvcctlコマンドを使用して，サービス部品呼び出しの通信タイムアウト値を変更します。変更方法の詳細については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「5.3.28　サービス部品呼び出しの通信タイムアウト値を変更する」を参照してください。cscsvcctlコマンドの使い方については，マニュアル「サービスプラットフォーム リファレンス」の「cscsvcctl（サービス情報の管理）」を参照してください。

表4‒6　タイマ（Webサービス）の設定値の変更（JAX-WSエンジン）

値

キー名称

読み込みタイムアウト値

<クラスタ名>.<サービスID>.WebService.com.cosminexus.csc.request.timeout

接続タイムアウト値

<クラスタ名>.<サービスID>.WebService.com.cosminexus.csc.connect.timeout

(2)　サービス部品に接続するときのタイマ（SessionBean）

(a)　タイムアウト値の設定

サービス部品に接続するときのタイマ（SessionBean）は，HCSCサーバ全体に設定したり，サービスアダプタ個別に設定したりできます。設定方法を次に示します。

HCSCサーバ全体の設定

HCSCサーバ稼働マシンのアプリケーションサーバのEJBコンテナでタイムアウトを設定します。RMI-IIOP通信のタイムアウトの詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「2.11.5　RMI-IIOP通信のタイムアウト」を参照してください。

また，設定するパラメタの詳細については，次に示すマニュアルを参照してください。

J2EEサーバの互換モードが推奨モードの場合

マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」

J2EEサーバの互換モードがV9互換モードの場合

マニュアル「アプリケーションサーバ 機能解説 互換編」の「10.1.1　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」

表4‒7　HCSCサーバ全体のタイマ（SessionBean）の設定

値

設定するファイル

キー名称

デフォルト値（秒）

RMI-IIOP通信すべてに有効となるタイムアウト値

J2EEサーバ用ユーザプロパティファイル（usrconf.properties）

ejbserver.rmi.request.timeout

0

（タイムアウトしません）

CORBAネーミングサービス部品との通信でのタイムアウト値

ejbserver.jndi.request.timeout

0

（タイムアウトしません）

サービスアダプタ個別の設定

開発環境で定義する場合，サービスアダプタ定義画面のクライアント定義ファイルに指定するファイルで設定します。クライアント定義ファイルの設定については，マニュアル「アプリケーションサーバ SOAPアプリケーション開発の手引」の「10.3　クライアント定義ファイルの設定」を参照してください。

表4‒8　サービスアダプタ個別のタイマ（SessionBean）の設定

値

キー名称

デフォルト値（秒）

呼び出しタイムアウト値

c4web.application.ejb_timeout

0

（タイムアウトしません）

(b)　タイムアウト値の変更

すでにHCSCサーバに配備しているサービスアダプタに対して運用環境で定義する場合は，cscsvcctlコマンドを使用して，サービス部品呼び出しの通信タイムアウト値を変更します。変更方法の詳細については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「5.3.28　サービス部品呼び出しの通信タイムアウト値を変更する」を参照してください。cscsvcctlコマンドの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「cscsvcctl（サービス情報の管理）」を参照してください。

表4‒9　タイマ（SessionBean）の設定値の変更

値

キー名称

呼び出しタイムアウト値

<クラスタ名>.<サービスID>.SessionBean.c4web.application.ejb_timeout

(3)　HCSCサーバに接続するときのタイマ（Webサービス）

HCSCサーバに接続するときのタイマ（Webサービス）は，サービスリクエスタ稼働マシン側で設定します。サービスリクエスタの稼働しているマシン全体に設定したり，サービスリクエスタ個別に設定したりできます。

SOAP通信基盤およびJAX-WSエンジンを使用する場合に分けて，設定方法を示します。

(a)　タイムアウト値の設定（SOAP通信基盤）

SOAP通信基盤を利用する場合のタイムアウト値の設定方法について説明します。タイムアウト値は，サービスリクエスタ稼働マシン全体またはサービスリクエスタ個別に設定できます。

サービスリクエスタ稼働マシン全体の設定

サービスリクエスタ稼働マシンでのSOAP通信基盤のサーバ定義ファイルで定義します。設定内容は「4.1.1(1)(a)　タイムアウト値の設定（SOAP通信基盤）」の場合と同様です。サーバ定義ファイルの設定については，マニュアル「アプリケーションサーバ SOAPアプリケーション開発の手引」の「10.2　サーバ定義ファイルの設定」を参照してください。

サービスリクエスタ個別の設定

作成するサービスリクエスタごとに個別に設定する場合，サービスリクエスタを実行するときに指定するクライアント定義ファイルで設定します。設定内容は「4.1.1(1)(a)　タイムアウト値の設定（SOAP通信基盤）」の場合と同様です。クライアント定義ファイルの設定については，マニュアル「アプリケーションサーバ SOAPアプリケーション開発の手引」の「10.3　クライアント定義ファイルの設定」を参照してください。

(b)　タイムアウト値の設定（JAX-WSエンジン）

JAX-WSエンジンを利用する場合のタイムアウト値の設定方法について説明します。タイムアウト値は，サービスリクエスタ稼働マシン全体またはサービスリクエスタ個別に設定できます。

サービスリクエスタ稼働マシン全体の設定

サービスリクエスタ稼働マシンでのJAX-WSエンジンの共通定義ファイルで定義します。設定内容は「4.1.1(1)(c)　タイムアウト値の設定（JAX-WSエンジン）」の場合と同様です。共通定義ファイルの設定については，マニュアル「アプリケーションサーバ Webサービス開発ガイド」の「10.1.2　共通定義ファイルの設定項目」を参照してください。

サービスリクエスタ個別の設定

作成するサービスリクエスタごとに個別に設定する場合，プロセス別の定義ファイルで設定します。プロセス別の定義ファイルの設定については，マニュアル「アプリケーションサーバ Webサービス開発ガイド」の「10.1.3　プロセス別の定義ファイルの設定」を参照してください。

(4)　HCSCサーバに接続するときのタイマ（SessionBean）

HCSCサーバに接続するときのタイマ（SessionBean）は，サービスリクエスタの稼働しているマシン全体に設定したり，サービスリクエスタ個別に設定したりできます。設定方法を次に示します。

サービスリクエスタ稼働マシン全体の設定

サービスリクエスタ稼働マシンのアプリケーションサーバで，EJBコンテナでタイムアウトを設定します。設定内容は「(2)　サービス部品に接続するときのタイマ（SessionBean）」の場合と同様です。RMI-IIOP通信のタイムアウトの詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「2.11.5　RMI-IIOP通信のタイムアウト」を参照してください。設定するパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「12.2.2　usrconf.properties（Javaアプリケーション用ユーザプロパティファイル）」を参照してください。

サービスリクエスタ個別の設定

作成するサービスリクエスタごとに個別に，createからremoveまでのAPI通信のタイムアウト値を設定する場合，サービスリクエスタのアプリケーション開発時にAPI（RequestTimeoutConfigFactoryクラスおよびRequestTimeoutConfigクラスのメソッド）で設定します。

(5)　HCSCサーバ内のトランザクションのタイマ

HCSCサーバ内のトランザクションのタイマは，HCSCサーバ全体で設定します。HCSCサーバ稼働マシンのアプリケーションサーバのEJBコンテナでタイムアウトを設定します。設定するパラメタの詳細については，次に示すマニュアルを参照してください。

J2EEサーバの互換モードが推奨モードの場合

マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」

J2EEサーバの互換モードがV9互換モードの場合

マニュアル「アプリケーションサーバ 機能解説 互換編」の「10.1.1　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」

表4‒10　HCSCサーバ内のトランザクションのタイマの設定

値

設定するファイル

キー名称

デフォルト値（秒）

J2EEサーバ上で開始されるトランザクションのトランザクションタイムアウト値

J2EEサーバ用ユーザプロパティファイル（usrconf.properties）

ejbserver.jta.TransactionManager.defaultTimeOut

180

4.1.2　サービス部品のタイムアウト値の変更

通信タイムアウト値は開発環境で定義しますが，SOAPアダプタ，およびSessionBeanアダプタについては，サービス部品に接続するときの通信タイムアウト値を運用環境で変更できます。運用環境でサービス部品のタイムアウト値を変更する場合は，cscsvcctlコマンドを使用します。ただし，変更対象のサービスアダプタが未配備状態である必要があります。

変更方法の詳細については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「5.3.28　サービス部品呼び出しの通信タイムアウト値を変更する」を参照してください。cscsvcctlコマンドの使い方については，マニュアル「サービスプラットフォーム リファレンス」の「cscsvcctl（サービス情報の管理）」を参照してください。

4.1.3　タイマ設定時の注意事項

(1)　サービス部品に接続するときのタイマとHCSCサーバに接続するときのタイマの関係

HCSCサーバに接続するときのタイマは，サービス部品に接続するときのタイマよりも大きい値を指定してください。

サービス部品呼び出しで時間が掛かり正常応答した場合でも，HCSCサーバに接続するときのタイマが先にタイムアウトし，処理が正常に完了しません。

なお，ビジネスプロセスを呼び出して，サービス部品を呼び出す場合は，複数のサービス部品を呼び出すことを考慮して，HCSCサーバに接続するときのタイマを設定する必要があります。

(2)　サービス部品に接続するときのタイマとトランザクションのタイマの関係

トランザクションのタイマは，サービス部品に接続するときのタイマよりも大きい値を指定してください。

サービス部品呼び出しで時間が掛かり正常応答した場合でも，トランザクションがタイムアウトすると，トランザクションがロールバックします。

4.2　サービス部品の接続先変更

サービス部品の接続先は開発環境で定義しますが，次に示すサービスアダプタについては，サービス部品に接続するための接続先を運用環境で変更できます。

SOAPアダプタ

SessionBeanアダプタ

MDB（WS-R）アダプタ

MDB（DBキュー）アダプタ

運用環境でサービス部品の接続先を変更する場合は，cscsvcctlコマンドを使用します。ただし，変更対象のサービスアダプタが未配備状態である必要があります。

変更方法の詳細については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「5.3.26　サービス部品の接続先を変更する」を参照してください。cscsvcctlコマンドの使い方については，マニュアル「サービスプラットフォーム リファレンス」の「cscsvcctl（サービス情報の管理）」を参照してください。

4.3　SOAPアダプタを利用したフォルトのキャッチ

Webサービスで業務エラー（商品の在庫がないなどの障害）が発生したときにビジネスプロセスで何らかの処理を実行するには，SOAPアダプタからフォルト電文を応答する必要があります。ビジネスプロセスでフォルト処理を定義する方法の詳細についてはマニュアル「サービスプラットフォーム開発ガイド 基本開発編」の「5.4.4　フォルト処理を定義する」を参照してください。

4.3.1　SOAPアダプタのフォルト判別の概要

SOAPアダプタからフォルト電文を応答する方法は次の3つです。

SOAP Fault電文判別

SOAP Fault動作定義ファイル

システム例外をフォルトに変換

フォルト判別の流れを次の図に示します。

図4‒2　フォルト判別の流れ

注※

SOAP Faultの詳細項目とはdetail要素の子要素またはDetail要素の子要素，およびその子孫要素を指します。詳細項目が複数ある場合，その中の1つだけがフォルト電文として扱われます。詳細項目が存在しない場合，フォルト電文はnullになります。

(1)　SOAP Fault電文判別

SOAP Faultによって伝搬されたエラー情報が，WSDLで定義されたユーザ定義例外の場合に，SOAPアダプタからフォルトを応答します。

SOAPメッセージのSOAP Faultは，SOAPメッセージ内のエラー情報を伝搬するために使用されます。サービスプラットフォームではSOAP Faultのうち，ユーザ定義例外を伝搬するSOAP Faultがフォルトとして扱われます。フォルトとして扱われなかったSOAP Faultはシステム例外となり，KDEC03006-EまたはKDEC03024-Eでフォルト情報が出力されます。

ユーザ定義例外を伝搬するSOAP Faultであるかどうかの判別方法は，HCSCサーバランタイム定義ファイルのsoapfault-handling-modeプロパティの設定に従います。

soapfault-handling-modeプロパティの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

(2)　SOAP Fault動作定義ファイル

SOAP Fault電文判別の方法でユーザ定義例外として判別できないSOAP Faultについても，SOAP Fault動作定義ファイルを使用することでSOAPアダプタからフォルトとして応答できます。SOAP Fault動作定義ファイルはHCSCサーバランタイム定義ファイルのsoapfault-targetnamespace-filepathプロパティを設定することで使用できます。SOAP Fault動作定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.6.1　SOAP Fault動作定義ファイル」を参照してください。

(3)　システム例外をフォルトに変換

前述の方法によりフォルトとして扱われなかったSOAP Faultや，システム例外（通信エラーなど）を，製品固有のフォルトとして応答するための方法です。

システム例外をフォルト電文へ変換するかしないかは，サービスアダプタ定義画面でアダプタを定義するときに設定します。サービスアダプタの定義方法については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.　サービスアダプタの定義」を，サービスアダプタ定義画面の詳細は，マニュアル「サービスプラットフォーム リファレンス」の「1.2.2　サービスアダプタ定義画面」を参照してください。

4.3.2　SOAP Faultの詳細項目によるフォルト判別

ここでは，HCSCサーバランタイム定義ファイルのsoapfault-handling-modeプロパティにDETAILを指定した場合のフォルト判別方法について説明します。

(1)　SOAP1.1のSOAP Fault

次の条件を満たすSOAP Faultがフォルトとして扱われます。

SOAP Faultのdetail要素の直下の子要素が，名前空間を含めてWSDLフォルト名と一致している

次のSOAPエンジンによってユーザ定義例外（フォルトbean）からマーシャルされたSOAP Faultの場合，この判別方法でフォルトとして扱われます。

Cosminexus Web Services

Cosminexus JAX-WS

フォルトとして扱われるSOAP1.1のSOAP Faultの例を次に示します。

図4‒3　フォルトとして扱われるSOAP1.1のSOAP Faultの例（詳細項目によるフォルト判別）

(2)　SOAP1.2のSOAP Fault

次の条件を満たすSOAP Faultがフォルトとして扱われます。

SOAP FaultのDetail要素の直下の子要素が，名前空間を含めてWSDLフォルト名と一致している

次のSOAPエンジンによってユーザ定義例外（フォルトbean）からマーシャルされたSOAP Faultの場合，この判別方法でフォルトとして扱われます。

Cosminexus JAX-WS

フォルトとして扱われるSOAP1.2のSOAP Faultの例を次に示します。

図4‒4　フォルトとして扱われるSOAP1.2のSOAP Faultの例（詳細項目によるフォルト判別）

4.3.3　SOAP Faultのfaultcodeによるフォルト判別

ここでは，HCSCサーバランタイム定義ファイルのsoapfault-handling-modeプロパティにFAULTCODEを指定した場合のフォルト判別方法について説明します。

(1)　SOAP1.1のSOAP Fault

次の条件を満たすSOAP Faultがフォルトとして扱われます。

SOAP Faultのfaultcode要素の値が，名前空間を含めてWSDLフォルト名と一致している

次のSOAPエンジンによってユーザ定義例外（フォルトbean）からマーシャルされたSOAP Faultの場合，この判別方法でフォルトとして扱われます。

Cosminexus Web Services

フォルトとして扱われるSOAP1.1のSOAP Faultの例を次に示します。

図4‒5　フォルトとして扱われるSOAP1.1のSOAP Faultの例（faultcodeによるフォルト判別）

(2)　SOAP1.2のSOAP Fault

フォルトとして扱われません。

4.3.4　システム例外のフォルト変換

サービスアダプタからサービス部品（Webサービス）を呼び出したときに発生したエラーの例外を，そのままスローするか，サービスアダプタでフォルト電文に変換するか選択できます。例外をそのままスローする場合とフォルト電文に変換する場合の処理の違いについては，「4.8　例外発生時にサービスアダプタが取得するエラーの選択」を参照してください。

4.3.5　SOAP Fault動作定義ファイルによるフォルトのキャッチ

SOAPアダプタでのSOAP Faultの扱いと，フォルトとして扱う場合の注意事項について説明します。

(1)　SOAP Faultの扱い

SOAPアダプタでは，サービス部品から返されたSOAP Faultが次に示す条件をすべて満たす場合，フォルトとして扱われます。

サービス部品のWSDLに定義されている

フォルト名がfaultCodeに設定されている

このようなフォルトをユーザ定義例外と呼びます。ユーザ定義例外は，ビジネスプロセスでも認識されるため，フォルト発生後のプロセスの場合分け処理を定義できます。

サービス部品の種類によっては，WSDLに定義されていないSOAP Faultが返されたり，faultCodeに任意の値が設定されてSOAP Faultが返されたりすることがあります。このようなSOAP Faultをフォルトとして扱いたいときは，SOAP Fault動作定義ファイルを使用することで，サービス部品から返されるすべてのSOAP Faultをフォルトとして扱うことができるようになります。

SOAP Fault動作定義ファイルには，サービス部品のWSDLに宣言されている名前空間（targetNamespaceのURI）を定義します。SOAP Fault動作定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.6.1　SOAP Fault動作定義ファイル」を参照してください。

個々のサービスアダプタには，WSDLでサービス部品のインターフェースが定義されており，WSDLに定義されている名前空間が，SOAP Fault動作定義ファイルに定義されている内容と一致するかどうかで，フォルトとして扱うかどうかを判断します。

SOAP Fault動作定義ファイルを使用したときのSOAP Faultの扱いを次の図に示します。

図4‒6　SOAP Fault動作定義ファイルを使用したときのSOAP Faultの扱い

サービス部品のWSDLを定義します。

サービス部品から返されたSOAP Faultが，サービス部品のWSDLに定義されていればフォルトとして扱われます。

サービス部品から返されたSOAP Faultが，サービス部品のWSDLに定義されていない，またはWSDLの定義と異なる名前空間で定義されている場合は，SOAP Fault動作定義ファイルに定義されている内容と一致するかどうかを照合します。

SOAP Fault動作定義ファイルに定義されている内容と一致している場合は，フォルトとしてビジネスプロセスに返します。

(2)　SOAP Faultをフォルトとして扱う場合の注意事項

サービス部品から返されたSOAP Faultでは，次の条件をすべて満たす場合にフォルト名がfaultCodeに設定され，フォルトとして扱われます。

サービス部品側にSOAP通信基盤を使用していること。

faultメッセージを定義するwsdl:part要素が，必ずelement属性でxsd:schema要素内のelement要素を参照していること。

WSDL fault名（wsdl:fault要素のname属性値）と，schema（wsdl:types内）に定義された例外型complexTypeを指すelement名※が，名前空間を含めて一致していること。

これらの条件を満たしていないWSDLを利用する場合で，サービス部品から返されたSOAP Faultをフォルトとして扱いたいときは，SOAP Fault動作定義ファイルを定義してユーザ定義例外となるように設定します。

注※

element名とは，「wsdl:faultが参照するwsdl:part要素が，element属性を用いて指定する要素」のことです。WSDLを次の順にたどって特定できる要素を指します。

wsdl:fault

wsdl:message（この要素をたどらない場合もあります）

wsdl:part

xsd:element

なお，サービスプラットフォームの開発支援コマンドであるJava2WSDLコマンドを使用して，オペレーションのstyle属性が「rpc」のWSDLファイルを生成した場合，element属性ではなく，type属性で参照するWSDLファイルが生成されます。そのため，生成されたWSDLファイルをそのまま使用しないで，修正および再生成してから使用します。WSDLファイルの修正および再生成の方法については，マニュアル「サービスプラットフォーム開発ガイド 基本開発編」の「4.3.2　サービス部品電文を作成する（Webサービスの場合）」を参照してください。

サービスプラットフォームでフォルトを使用する場合，documentスタイルのWSDLを使用することを推奨します。

4.4　アプリケーションからの稼働状態の確認

4.4.1　稼働状態の確認の概要

サービスリクエスタなどの外部からWebサービス（SOAP通信）を使用し，サービス名をキーにして稼働状態の確認要求をすると，HCSCサーバに配備されているサービスアダプタの情報を取得できます。

なお，稼働状態の確認は，サービス部品そのものの状態を確認するのではなく，HCSCサーバに配備されているサービスアダプタの状態を確認します。

4.4.2　稼働状態の確認の流れ

リクエスト受付（標準受付（Webサービス））にはサービスリクエスタからのメッセージを配送するためのメソッド（リクエスト受付のオペレーション）としてinvokeXML，invokeBinaryなどがあり，その中のサービスアダプタ稼働状態確認用のオペレーション（getServiceInfo）を使用し，稼働状態を確認します。

サービスリクエスタからサービスアダプタの稼働状態の確認要求をすると，HCSCサーバは指定されたサービス名に該当するサービスアダプタのロケーション情報（メモリ上の情報）を検索し，その状態を応答します。

なお，稼働状態確認の要求ができるのは，HCSCサーバのリクエスト受付が起動しているときだけです。

稼働状態の確認の流れを次の図に示します。

図4‒7　稼働状態の確認の流れ

4.4.3　稼働状態の確認時の注意事項

(1)　サービス部品の状態とサービスアダプタの状態の同期について

稼働状態確認機能は，サービス部品の状態ではなく，HCSCサーバに配備されているサービスアダプタの状態を確認する機能です。そのため，稼働状態を確認するときは，サービス部品とサービスアダプタが共に同期を取って起動および停止する運用が前提です。サービスアダプタが起動していてもサービス部品が停止している場合は，サービス部品呼び出しの要求はエラーになります。

(2)　稼働状態の確認結果と実状態の差異について

稼働状態の確認でサービスアダプタの起動を確認した場合でも，確認直後にサービスアダプタが停止すると，サービス部品呼び出しの要求をしたときにエラーになります。そのため，サービスリクエスタでは，サービスアダプタの稼働状態確認で起動を確認しても，サービス部品呼び出しを要求したときにサービスアダプタが停止状態となっていてエラーリターンする場合があることを考慮する必要があります。

(3)　リクエスト受付の状態について

HCSCサーバのリクエスト受付が起動していないときに，サービスリクエスタでサービスアダプタの稼働状態を確認するとエラーになります。そのため，サービスリクエスタでは，リクエスト受付が停止状態で，サービスアダプタの稼働状態確認要求がエラーリターンする場合を考慮する必要があります。

4.5　XML電文内の属性値に指定した名前空間接頭辞の補完

HCSCサーバ内を流れるユーザ電文で，XMLスキーマの属性値の型にQName型を使用する場合，次の図のようにXML文書から「子要素」を部分木として切り出して出力すると，xmlns:prefixの名前空間宣言が欠落します。

図4‒8　部分木取得時の名前空間宣言の欠落

名前空間宣言が欠落した場合，次の問題が発生することがあります。

ビジネスプロセスでフォルトコネクションを使用してフォルトをキャッチしようとしたが，サービス部品からのフォルトをキャッチできない。

データ検証機能を使用している場合（HCSCサーバランタイム定義ファイルのtelegram-validationプロパティにONを指定），検証でエラーが発生する。

名前空間宣言が欠落したXML電文をサービスリクエスタやサービス部品で受け取った場合，サービスリクエスタやサービス部品側でエラーが発生する。

なお，子要素のプレフィックスについては，部分木取得時に名前空間が解決されます。

このような問題を解決するには，HCSCサーバランタイム定義ファイルのxmltelegram-namespace-complementプロパティにONを指定します。ただし，ONを指定すると，OFFを指定した場合よりも電文サイズが大きくなるため注意してください。

HCSCサーバランタイム定義ファイルについては，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

4.6　任意形式（any形式）の電文フォーマットの定義

開発環境で電文のフォーマット定義ファイルに任意形式（any形式）を設定することで，電文の形式を意識しないサービス部品呼び出し要求・応答ができます。

なお，任意形式のデータを扱うことができる受付およびアダプタは，次のとおりです。

ユーザ定義受付（カスタム受付）

汎用カスタムアダプタ

データ変換をしないメッセージ型の組み合わせについては「4.6.2　データ変換をしない場合の変数（メッセージ型）の組み合わせ」を参照してください。

4.6.1　任意形式（any形式）を設定した場合の処理の流れ

電文のフォーマット定義ファイルに任意形式（any形式）を設定した場合は，要求電文および応答電文のデータの型を意識する必要がありません。

電文のフォーマット定義ファイルに任意形式（any形式）を設定した場合の処理の流れを次の図に示します。

図4‒9　電文のフォーマット定義ファイルに任意形式（any形式）を設定した場合の処理の流れ

参考

電文のフォーマット定義ファイルに任意形式（any形式）を設定しない場合は，要求電文および応答電文のデータ型を厳密に決める必要があります。また，開発環境で電文の形式ごとにコンポーネント（受付，ビジネスプロセス，およびサービスアダプタ）を作成する必要があります。

電文のフォーマット定義ファイルに任意形式（any形式）を設定しない場合の処理の流れを次の図に示します。

図4‒10　電文のフォーマット定義ファイルに任意形式（any形式）を設定しない場合の処理の流れ

4.6.2　データ変換をしない場合の変数（メッセージ型）の組み合わせ

任意形式（any形式）を設定することで，データ変換をしない運用ができます。データ変換をしない場合の前提条件は次のとおりです。

サービス呼出アクティビティのメッセージ型（XML，non-XML，any）とサービス呼出アクティビティから呼び出すコンポーネント（開発環境で作成する受付，ビジネスプロセス，およびサービスアダプタの総称）で設定したデータの型が一致している。

ビジネスプロセスのサービス呼出アクティビティで任意形式（any形式）を設定する場合は，開発環境の定義画面で呼び出し対象のコンポーネントを任意形式（any形式）で定義している。

受付およびサービスアダプタでデータ変換をしない場合のメッセージ型の組み合わせを次に示します。

表4‒11　受付でデータ変換をしない場合のメッセージ型の組み合わせ

コンポーネント種別

データの型

または

メソッド

変数（メッセージ型）

XML

non-XML

any

要求

応答

要求

応答

要求

応答

標準受付（Webサービス）

invokeXML

○

○

×

×

×

×

invokeBinary

×

×

○

○

○

○

標準受付（SessionBean）

invokeXML

○

○

×

×

×

×

invokeBinary

×

×

○

○

○

○

標準受付（MDB（WS-R））

onMessage

○

○

○

○

○

○

標準受付（MDB（DBキュー））

onMessage

○

○

○

○

○

○

ユーザ定義受付（SOAP受付）

○

○

×

×

×

×

ユーザ定義受付（カスタム受付）

invokeXML

XML

○

○

×

×

×

×

non-XML

×

×

×

×

×

×

any

○

○

○

○

○

○

invokeBinary

XML

×

×

×

×

×

×

non-XML

×

×

○

○

×

×

any

○

○

○

○

○

○

ユーザ定義受付（TP1/RPC受付）

XML

×

×

×

×

×

×

non-XML

×

×

○

○

○

○

any

○

○

○

○

○

○

ユーザ定義受付（FTP受付）

XML

○

○

×

×

×

×

non-XML

×

×

×

×

×

×

any

×

×

×

×

×

×

ユーザ定義受付（HTTP受付）

XML

○

○

×

×

×

×

non-XML

×

×

○

○

○

○

any

×

×

○

○

○

○

ユーザ定義受付（Message Queue受付）

XML

○

○

×

×

○

○

non-XML

×

×

○

○

○

○

any

○

○

○

○

○

○

ユーザ定義受付（ファイルイベント受付）

XML

○

○

×

×

×

×

non-XML

×

×

×

×

×

×

any

×

×

×

×

×

×

ユーザ定義受付（Kafka受付）

XML

○

○

×

×

○

○

non-XML

×

×

○

○

○

○

any

○

○

○

○

○

○

ユーザ定義受付（gRPC受付）

XML

○

○

×

×

×

×

non-XML

×

×

×

×

×

×

any

×

×

×

×

×

×

ユーザ定義受付（スケジュール駆動受付）

XML

○

○

×

×

×

×

non-XML

×

×

×

×

×

×

any

×

×

×

×

×

×

（凡例）

○：対応しています。

×：対応していません。

表4‒12　サービスアダプタでデータ変換をしない場合のメッセージ型の組み合わせ

コンポーネント種別

データの型

変数（メッセージ型）

XML

non-XML

any

要求

応答

要求

応答

要求

応答

SOAPアダプタ

XML

○

○

×

×

×

×

non-XML

−

−

−

−

−

−

any

−

−

−

−

−

−

SessionBeanアダプタ

XML

○

○

×

×

×

×

non-XML

−

−

−

−

−

−

any

−

−

−

−

−

−

MDB（WS-R）アダプタ

XML

○

−

×

−

×

−

non-XML

×

−

○

−

×

−

any

−

−

−

−

−

−

MDB（DBキュー）アダプタ

XML

○

−

×

−

×

−

non-XML

×

−

○

−

×

−

any

−

−

−

−

−

−

DBアダプタ

XML

○

○

×

×

×

×

non-XML

×

×

×

×

×

×

any

×

×

×

×

×

×

TP1アダプタ

XML

×

×

×

×

×

×

non-XML

×

×

○

○

×

×

any

×

×

×

×

○

○

FTPアダプタ

XML

○

○

×

×

×

×

non-XML

×

×

×

×

×

×

any

×

×

×

×

×

×

ファイルアダプタ

XML

○

○

×

×

×

×

non-XML

×

×

○

○

×

×

any

×

×

×

×

×

×

Object Accessアダプタ

XML

○

○

×

×

×

×

non-XML

×

×

×

×

×

×

any

×

×

×

×

×

×

Message Queueアダプタ

XML

○

○

×

×

×

×

non-XML

×

×

○

○

×

×

any

×

×

×

×

×

×

ファイル操作アダプタ

XML

○

○

×

×

×

×

non-XML

×

×

×

×

×

×

any

×

×

×

×

×

×

メールアダプタ

XML

○

○

×

×

×

×

non-XML

×

×

×

×

×

×

any

×

×

×

×

×

×

HTTPアダプタ

XML

○

○

×

×

×

×

non-XML

×

×

○

○

×

×

any

×

×

×

×

○

○

コマンドアダプタ

XML

○

×

×

×

×

×

non-XML

×

×

×

○

×

×

any

×

×

×

×

×

○

SFTPアダプタ

XML

○

○

×

×

×

×

non-XML

×

×

×

×

×

×

any

×

×

×

×

×

×

Kafkaアダプタ

XML

○

○

×

×

×

×

non-XML

×

×

○

×

×

×

any

×

×

×

×

○

×

gRPCアダプタ

XML

○

○

×

×

×

×

non-XML

×

×

×

×

×

×

any

×

×

×

×

×

×

汎用カスタムアダプタ

XML

○

○

×

×

×

×

non-XML

×

×

○

○

×

×

any

×

×

×

×

○

○

（凡例）

○：対応しています。

×：対応していません。

−：作成できません。

任意形式（any形式）を設定しているHCSCコンポーネントを単体サービス実行した場合の対応可否を次の表に示します。

表4‒13　HCSCコンポーネントを単体サービス実行した場合の対応可否

コンポーネント種別

メソッド

フォーマット定義ファイルの設定

any

要求

応答

標準受付（Webサービス）

invokeXML

×

×

invokeBinary

○

○

標準受付（SessionBean）

invokeXML

×

×

invokeBinary

○

○

標準受付（MDB（WS-R））

onMessage

○

○

標準受付（MDB（DBキュー））

onMessage

○

○

（凡例）

○：対応しています。

×：対応していません。

4.7　システム例外をフォルトに変換する汎用フォルト

アクティビティ内で発生したシステム例外を汎用フォルトに変換して送出することで，フォルトを発生させることができないアクティビティでもフォルトを送出できます。

4.7.1　システム例外をフォルトに変換する汎用フォルトの概要

汎用フォルト電文送出とは，アクティビティ内で発生したシステム例外を，共通のフォーマットで作成したフォルト電文に変換して送出することで，フォルトを発生させることができないアクティビティでもフォルトを送出できるようにする機能です。

この機能を使用した場合，プロセスインスタンスを中断しないで続行するため，プロセスインスタンスの再実行はできません。

(1)　アクティビティ内で発生したシステム例外をフォルト電文に変換して送出するアクティビティ

汎用フォルト送出に対応するアクティビティと汎用フォルトに変換する例外を次に示します。

表4‒14　汎用フォルト送出に対応するアクティビティと汎用フォルトに変換する例外

項番

アクティビティ種別

汎用フォルトに変換する例外

1

Java呼出アクティビティ

引数用割当変数が未初期化の場合に発生する例外

戻り値用割当変数に対応する型以外を設定した場合に発生する例外

2

データ変換アクティビティ

変換元変数が未初期化の場合に発生する例外

データ変換処理で発生する例外

3

代入アクティビティ

コピー元変数が不正または未初期化の場合に発生する例外

代入処理で発生する例外

4

フォルト送出アクティビティ

割当変数が未初期化の場合に発生する例外

5

検証アクティビティ

検証する変数が未初期化の場合に発生する例外

検証する変数が空の場合に発生する例外

6

繰り返しアクティビティ

繰り返し条件の判定で発生する例外

繰り返しリストに指定した繰り返し対象が不正な場合に発生する例外

最大繰り返し回数に指定した回数を超えて繰り返しを実行した場合に発生する例外

7

分岐アクティビティ

分岐条件の判定で発生する例外

8

ログ出力アクティビティ

変数が不正または未初期化の場合に発生する例外

9

リンクコネクション

リンク活性化条件の判定で発生する例外

設定条件の違いによるアクティビティ内で例外が発生したときの動作の違いを次の表に示します。

表4‒15　設定条件の違いによるアクティビティ内で例外が発生したときの動作の違い

HCSCサーバランタイム定義ファイルの設定

アクティビティ内で例外が発生したときの動作

対象アクティビティ

syserr-to-fault-convert=ON

汎用フォルト電文を送出

データ変換アクティビティ※

代入アクティビティ※

分岐アクティビティ※

syserr-to-fault-convert=OFF

システム例外が発生

syserr-to-fault-convert-all-activity=ON

汎用フォルト電文を送出

リンクコネクション

Java呼出アクティビティ

データ変換アクティビティ※

代入アクティビティ※

フォルト送出アクティビティ

検証アクティビティ

繰り返しアクティビティ

分岐アクティビティ※

ログ出力アクティビティ

syserr-to-fault-convert-all-activity=OFF

システム例外が発生

注※

syserr-to-fault-convertプロパティとsyserr-to-fault-convert-all-activityプロパティのどちらかだけONを指定した場合は，ONが適用され汎用フォルトが発生します。

syserr-to-fault-convertプロパティとsyserr-to-fault-convert-all-activityプロパティは対象となるアクティビティが異なるだけです。出力する汎用フォルト電文の内容は同じです。syserr-to-fault-convertプロパティとsyserr-to-fault-convert-all-activityプロパティを同時に指定してもエラーにはなりません。

(2)　検証アクティビティ

検証アクティビティは，validate-fault-compatibleプロパティを設定することによって，検証処理の結果が不正だったときに送出するフォルト電文の種類を変更できます。

設定条件の違いによる検証処理の結果が不正だったときの動作の違いを次の表に示します。

表4‒16　設定条件の違いによる検証処理の結果が不正だったときの動作の違い

HCSCサーバランタイム定義ファイルの設定

検証処理の結果が不正だったときの動作

validate-fault-compatible=ON

検証アクティビティ固有のフォルト電文を送出※

validate-fault-compatible=OFF

汎用フォルト電文を送出※

注※

HCSCサーバランタイム定義ファイルの「validation-activity」の設定がONになっている場合だけフォルト電文を送出します。「validation-activity」の設定がOFFの場合は検証処理そのものを実行しないため，フォルト電文も送出されません。

4.7.2　汎用フォルトを使用してシステム例外発生個所を特定する場合の流れ

アクティビティ内でシステム例外が発生する，または検証アクティビティの検証処理の結果が不正だった場合，発生した例外を汎用フォルト電文に変換して送出し，フォルト電文の情報から，メッセージログ内に出力されている障害発生個所特定用のメッセージ（KDEC20087-W）を引き当てることによって，ビジネスプロセス上の障害発生個所，障害原因の調査ができます。

汎用フォルトをスコープでキャッチするビジネスプロセス定義例を次に示します。

図4‒11　汎用フォルトをスコープでキャッチするビジネスプロセス定義例

汎用フォルトを使用してシステム例外の発生個所を特定する方法を次に示します。

スコープ1内に汎用フォルトを送出するアクティビティを定義します。

アクティビティ内で例外が発生すると，汎用フォルトが送出されます。

スコープ1に定義されたフォルトハンドラで，送出された汎用フォルトをキャッチします（フォルト電文が変数に格納されます）。

代入2で，汎用フォルト電文からルートアプリケーション情報を，応答電文に代入します。

分岐アクティビティを使用することで正常時とフォルト発生時の応答を分けて定義することができます。

応答2で，3.で汎用フォルト電文から取得したルートアプリケーション情報をリクエスタ（ユーザ）に通知します。

ユーザは，4.で取得したルートアプリケーション情報を基に，メッセージログを参照し，障害発生個所特定用のメッセージ（KDEC20087-W）の情報を参照します。

参考

ユーザは次の情報を参照することによって，障害発生個所や障害原因の調査が可能になります。

障害発生個所特定用のメッセージ（KDEC20087-W）に含まれるビジネスプロセス上の障害発生個所および障害原因の情報

メッセージログ内の障害発生個所特定用のメッセージ（KDEC20087-W）付近に出力されるエラーメッセージ

4.7.3　汎用フォルト電文とメッセージログのマッピング

汎用フォルト電文に設定される情報（ルートアプリケーション情報）を基に，メッセージログに出力される障害発生個所特定用のメッセージ（KDEC20087-W）を参照することで，汎用フォルト電文とメッセージログのマッピングができます。

汎用フォルト電文とメッセージログのマッピングについては，「4.7.2　汎用フォルトを使用してシステム例外発生個所を特定する場合の流れ」を参照してください。

また，アクティビティでフォルトが発生した場合は，ユーザ電文トレースを出力することができます。ユーザ電文トレース機能を利用することによって，より詳細な情報を取得できます。

ユーザ電文トレースについては，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「7.4.4　ユーザ電文トレース」を参照してください。

4.8　例外発生時にサービスアダプタが取得するエラーの選択

サービスアダプタからサービス部品（Webサービス）を呼び出したときに発生したエラーの例外を，そのままスローするか，サービスアダプタでフォルト電文に変換するか選択できます。

エラーの例外をサービスアダプタでフォルト電文に変換すると，ビジネスプロセスでエラーとしてキャッチできます。

例外をそのままスローする場合とフォルト電文に変換する場合の処理の違いを次に示します。

図4‒12　例外をそのままスローする場合とフォルト電文に変換する場合の処理の違い

なお，サービスアダプタで変換されたフォルト電文をビジネスプロセスでキャッチする場合，フォルト処理を行うアクティビティの配置が必要です。フォルト処理の定義については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「5.4.4　フォルト処理を定義する」を参照してください。

例外をフォルト電文へ変換する場合の設定については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「7.11　サービスアダプタでの例外発生時の運用」を参照してください。

4.9　UOCを利用したユーザ電文の値の変更

リクエスト電文をユーザ側で参照したり，編集したりするには，コンポーネント共通UOCを利用します。また，コンポーネント共通UOCを使用することで，受付およびサービスアダプタの入出力データの参照や更新ができます。

4.9.1　コンポーネント共通UOCの概要

コンポーネント共通UOCでは，次の2つのことができます。

UOCクラスのインスタンス生成

ユーザが作成したjavaクラスをシステムクラスローダで読み込み，UOCクラスのインスタンスを作成します。

UOCクラスの呼び出し

ユーザが指定したコンポーネントで，ユーザが作成したjavaクラスを呼び出します。

(1)　UOCクラスのインスタンス生成

UOCクラスのインスタンスは，HCSCサーバ起動時に作成され，メモリ上に保持されます。

UOCクラスのインスタンス生成の流れを次に示します。

コンポーネント共通UOC用プロパティファイルの読み込み

コンポーネント共通UOC用プロパティファイルを読み込み，UOCクラスの呼び出し元IDをkey情報，呼び出されるUOCクラスのクラスパスをvalueとするMap型のデータを作成し，jarファイル作成の処理へ設定します。

プロパティファイルの読み込みに失敗した場合，メッセージログに例外ログ（KDEC11003-E）を出力したあと，HCSCサーバ起動処理を中断します。

コンポーネント共通UOC用jarファイルの読み込みおよびインスタンス作成

コンポーネント共通UOC用プロパティを読み込んで作成したMap型データからクラスパスを取得し，UOCクラスのインスタンスを生成します。

生成したUOCクラスのインスタンスは，クラスインスタンスをvalue，クラスパスをkeyとするMap型データに格納します。

クラスファイルの読み込みに失敗した場合，メッセージログに例外ログ（KDEC11002-E）を出力したあと，HCSCサーバ起動処理を中断します。

(2)　UOCクラスの呼び出し

受付の共通処理部分，およびサービスアダプタの共通処理部分から呼び出すため，すべてのコンポーネントの処理でUOCクラスを呼び出すことができます。

コンポーネントの処理タイミングと，UOCクラスの呼び出しの有無を次に示します。

表4‒17　コンポーネントの処理タイミングと，UOCクラスの呼び出しの有無

種別

起動時

開始時

終了時

停止時

正常

フォルト

システム例外

標準受付

×

○

○

×

×

×

ユーザ定義受付

SOAP受付の場合

×

○

○

×

×

×

SOAP受付以外の場合

○

○

○

×

×

○

ビジネスプロセス

×

×

×

×

×

×

サービスアダプタ

×

○

○

×

×

×

（凡例）

○：UOCクラスを呼び出します。

×：UOCクラスを呼び出しません。

(a)　UOCクラスへの入力情報

UOCクラスへの入力情報は，Map型のオブジェクトにまとめて渡します。

UCO用インターフェースで定義した定数（key）を基にデータを取得します。

定数（key）は，UOCクラスを作成する際にimplementsするインターフェースに定義します。

定義する定数を次に示します。

表4‒18　定義する定数

定数名（key名）

データ型

設定内容

COMPO_TYPE

int

1：サービスアダプタ

2：受付

COMPO_KIND

String

受付の場合

StandardWebService：標準受付（Webサービス）

StandardSessionBean：標準受付（SessionBean）

StandardWSR：標準受付（MDB（WS-R））

StandardDBQ：標準受付（MDB（DBキュー））

WebService：SOAP受付

TP1/RPC：TP1/RPC受付

FTP：FTP受付

HTTP：HTTP受付

MessageQueue：Message Queue受付

FileEvent：ファイルイベント受付

Kafka：Kafka受付

ScheduleTriggered：スケジュール駆動受付

gRPC：gRPC受付

Custom：カスタム受付

サービスアダプタの場合

WebService：SOAPアダプタ

SessionBean：SessionBeanアダプタ

MDB_WSR：MDB（WS-R）アダプタ

MDB_DBQ：MDB（DBキュー）アダプタ

DB：DBアダプタ

TP1：TP1アダプタ

File：ファイルアダプタ

ObjectAccess：Object Accessアダプタ

MessageQueue：Message Queueアダプタ

FTP：FTPアダプタ

FileOperation：ファイル操作アダプタ

Mail：メールアダプタ

HTTP：HTTPアダプタ

Command：コマンドアダプタ

SFTP：SFTPアダプタ

Kafka：Kafkaアダプタ

gRPC：gRPCアダプタ

Custom：汎用カスタムアダプタ

COMPO_ID

String

受付の受付IDまたはサービスアダプタのサービスID

TELEGRAM_DATA

CSCMsgTelegramManager

リクエスト電文または応答電文

MONITOR_SEND_DATA

Map<String, Object>

送信データ格納Map

DESTINATION_DATA

CSCMsgDestinationData

呼び出すサービスの宛先情報※

注※

ユーザ定義受付（SOAP受付を除く）の場合だけ取得できます。

パラメタMapから取得する電文の内容を次に示します。

●電文

リクエスト電文や応答電文は，電文取得用API（CSCMsgTelegramManager）でUOCクラスに渡し，「#getHeader」または「#getBody」を使用して電文を取得します。

なお，電文はバイト配列で渡すため，XML電文の場合はDocument型などに変換する必要があります。

●宛先情報

SOAPユーザ定義受付以外のユーザ定義受付の場合に呼び出すサービスの宛先情報が取得できます。また，ユーザ定義受付のリクエスト受付時にサービスの宛先情報取得用APIを使用し，任意の値を設定することで，呼び出すサービスを変更できます。

(b)　UOCクラスを呼び出すタイミング

UOCクラスを呼び出すタイミングと電文との関係を次に示します。

図4‒13　UOCクラスを呼び出すタイミングと電文との関係

受付ではサービスリクエスタからの要求電文をUOCクラスに渡します。

サービスアダプタではサービス部品に渡す要求電文をUOCクラスに渡します。

サービスアダプタではサービス部品から返る応答電文をUOCクラスに渡します。

受付ではサービスアダプタからの応答電文をUOCクラスに渡します。

注意

呼び出すサービスの宛先を変更した場合，リクエストトレースで出力される宛先は実際の宛先と異なることがあります。

(c)　性能解析トレースの出力

コンポーネント共通UOCを使用すると，性能解析トレースは必ず出力されます。性能解析トレースが出力されるタイミングは，UOCクラスの呼び出し直前と直後になります。

性能解析トレースファイルに出力される形式は，J2EEサーバの性能解析トレースと同様です。性能解析トレースファイルの詳細については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「7.3　Management Serverを利用した性能解析トレースファイルの収集」を参照してください。

4.9.2　コンポーネント共通UOCの使用例

コンポーネント共通UOCを使用して，受付で要求電文の値を変換および更新する例を次に示します。

なお，この例で使用するコンポーネントは次のとおりです。

ユーザ定義受付名：サンプルユーザ定義受付2

受付ID：rcp2

コンポーネントとコンポーネント共通UOCクラスの関連付けについては，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「付録G　コンポーネント共通UOC」を参照してください。

(1)　前提条件

前提となる動作環境を次に示します。

J2EEサーバ名：J2EEServer

HCSCサーバ名：HCSC

SOAPモード：SOAP 1.1モード

サービスプラットフォームのインストールディレクトリ："C:¥Program Files¥Hitachi¥Cosminexus"

jarファイル格納ディレクトリ：C:¥uocjar

プロパティ格納ディレクトリ：C:¥uocconf

(2)　処理内容

この例では，要求電文の一部を変換し，更新するという処理になります。

使用例の処理の内容を次に示します。

図4‒14　使用例の処理の内容

(3)　UOCクラスの作成

要求電文のデータを変更するUOCクラスを作成する場合，次に示す処理を組み込む必要があります。

リクエストに対応するUOCクラス用インターフェースをimplementsする。

パラメタのCSCMsgTelegramManagerオブジェクトから電文を取得する。

電文を解析し，更新する。

電文はバイト配列で取得されるため，Document型などへの変換が必要です。

電文をバイト配列に変換する。

電文取得APIの電文更新用メソッドに，変換したバイト配列を設定する。

UOCクラスの作成例を次に示します。

図4‒15　UOCクラスの作成例

注

図中の番号は，組み込みが必要な処理の1.〜5.と対応しています。

(4)　HCSCサーバの設定

(a)　jarファイルの準備

Antなどのビルドツールを使用してjarファイルを作成し，jarファイル格納ディレクトリ（この例ではC:¥uocjar）に格納します。

(b)　プロパティファイルの準備

コンポーネント共通UOC用プロパティファイルの設定内容を次に示します。

rcp2=jp.com.reception.Rcp2Uoc

HCSCサーバランタイム定義ファイルに，次に示す定義を追加します。

common-uoc-prop-path=C:¥¥uocconf

(c)　J2EEサーバ用オプション定義ファイル（usrconf.cfg）の設定

usrconf.cfgファイルに，次に示すプロパティ値を設定します。

add.class.path=C:¥uocjar¥uocClass2.jar

4.10　バイナリデータの変換エラー時のデバッグ情報の出力

バイナリデータの変換処理中にエラーが発生した場合に，原因を特定するための情報をデバッグ情報として出力できます。

4.10.1　デバッグ情報出力機能の概要

デバッグ情報出力機能は，バイナリデータの変換処理中にエラーが発生した場合に，原因を特定するための情報（デバッグ情報）をユーザ電文トレースに出力する機能です。

バイナリデータの変換処理では，バイナリデータとDOM（DOMパーサによって解析されたXML文書の内容を記述したもの）を，相互に変換します。

デバッグ情報は，バイナリデータの変換処理で，次の場合に出力されます。

バイナリデータの読込処理（バイナリ→DOMの変換）でエラーが発生した場合

バイナリデータの生成処理（DOM→バイナリの変換）でエラーが発生した場合

XMLデータ変換処理中にエラーが発生した場合は，デバッグ情報は出力されません。

また，バイナリデータの変換処理でエラーが発生した場合に，エラーの詳細情報として詳細情報メッセージが出力されます。

デバッグ情報出力機能が出力するデバッグ情報と，詳細情報メッセージの出力内容を併せて利用することで，バイナリデータの変換処理中のエラー原因を特定できます。

デバッグ情報の取得方法については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「7.3.2　障害情報の取得方法（サービスプラットフォーム）」のデバッグ情報の取得方法に関する説明を参照してください。

4.10.2　デバッグ情報の出力例

ここでは，バイナリデータの読込処理（バイナリ→DOMの変換）で，入力データの不正によってエラーになった場合のデバッグ情報の出力例について説明します。

(1)　データ変換の定義内容と入力データの内容

この例で使用するデータ変換のマッピング定義，変換元および変換先のバイナリフォーマット定義の設定値，変換するバイナリデータは次のとおりです。

●データ変換のマッピング定義

●変換元および変換先のバイナリフォーマット定義の設定値

●変換するバイナリデータ

(2)　デバッグ情報の出力内容

(1)で示した内容でデータ変換を実行した場合，バイナリデータの読込処理（バイナリ→DOMの変換）で，入力データが短いため，エラー（KDEC40200-E）が発生します。

この場合のデバッグ情報の出力内容を次に示します。

(a)　デバッグ情報として出力するDOMの出力内容

デバッグ情報として出力するDOMの出力内容を次の図に示します。なお，次の図は，見やすさのためスペースと改行を挿入しています。

説明

2つ目の複合内容要素の子要素（simple03）のバイナリデータの読み込みでエラーが発生するため，ノードの値は出力されません。

次にトレース開始部の付加情報を示します。

DataType = DOM, Node = /root/complex01[2]/simple03, RootApInfo = XX.XXX.XXX.XXX/9496/0x0000000000001cb0

注

「XX.XXX.XXX.XXX」の部分にはIPアドレスが表示されます。

説明

トレース開始部の付加情報からは，次のことがわかります。

2つ目の複合内容要素の子要素（simple03）の入力データ読み込み時にエラーが発生したこと

ルートアプリケーション情報からメッセージログのエラー原因のメッセージ出力個所

(b)　デバッグ情報として出力するバイナリデータの出力内容

読み込んだ位置までのバイナリデータが出力されます。

デバッグ情報として出力するバイナリデータの出力内容を次の図に示します。

次にトレース開始部の付加情報を示します。

DataType = Binary, InputDataSize = 17, Offset = 17, RootApInfo = XX.XXX.XXX.XXX/9496/0x0000000000001cb0

注

「XX.XXX.XXX.XXX」の部分にはIPアドレスが表示されます。

説明

トレース開始部の付加情報からは，次のことがわかります。

入力データサイズの合計が18バイトではなく17バイトしかないこと

ルートアプリケーション情報からメッセージログのエラー原因のメッセージ出力個所

(c)　詳細情報メッセージの出力内容

(1)で示した内容でデータ変換を実行した場合，データ変換でエラーになり，詳細情報メッセージが出力されます。詳細情報メッセージの出力例を次に示します。

注

「XX.XXX.XXX.XXX」の部分にはIPアドレスが表示されます。

説明

既存のエラーメッセージ（KDEC40200-E）では3バイト中，2バイト読み込んだ際にエラーが発生したことがわかります。

詳細情報メッセージ（KDEC40312-I）からは，次のことがわかります。

入力データサイズの合計が18バイトではなく17バイトしかないこと

2つ目の複合内容要素の子要素（simple03）の入力データ読み込み時にエラーが発生したこと

4.11　APIを使用したデータ変換

APIを使用したデータ変換について説明します。

4.11.1　データ変換APIを使用したデータ変換

データ変換APIは，データ変換基盤を利用するためのインターフェースを定義したAPIです。

サービスプラットフォームでデータ変換を利用するには，HCSCサーバの構築やビジネスプロセスの定義が必要でした。データ変換APIを利用すれば，HCSCサーバの構築やビジネスプロセスを定義しなくてもデータ変換ができます。

データ変換APIを利用してデータ変換をする場合，データ変換APIを呼び出すEnterprise Beanを実装する必要があります。Enterprise BeanをJ2EEサーバ上で稼働させ，サービスリクエスタからEnterprise Beanを経由してデータ変換APIを呼び出します。

データ変換APIを利用したデータ変換の実現方式を次の図に示します。

図4‒16　データ変換APIを利用したデータ変換の実現方式

データ変換APIでは次の機能が利用できます。

データ変換

要求電文と定義情報を受け取り，データ変換後の応答電文を返す機能です。

キャッシュ操作

定義情報のキャッシュを登録します。キャッシュ登録後の存在確認処理や削除処理も提供します。

グループ管理

キャッシュの保存するデータ変換APIのグループを管理する機能です。

障害対策

データ変換やキャッシュ操作で障害が発生した際に，メッセージの出力とデータ変換API専用の例外クラスのオブジェクトをスローします。

プロパティの変更

データ変換に必要な設定（キャッシュやプロパティ）を保持するデータ変換APIを，業務ごとに管理する機能です。

4.11.2　JSON-XML変換APIを使用した変換

JSON-XML変換APIは，JSON形式のデータとXML形式のデータを相互に変換するためのAPIです。JSON-XML変換APIでは，JSON形式のデータとXML形式のデータを一定の基準に従って変換します。

JSON-XML変換APIを使用した変換例を次の図に示します。

図4‒17　JSON-XML変換APIを使用した変換例

注意事項

J2EEサーバ上で稼働するJ2EEアプリケーション，またはビジネスプロセス中のJava呼出アクティビティから，JSON-XML変換APIを使用してください。

JSON-XML変換APIを使用した変換の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「12.2　JSON-XML変換APIを使用したデータの形式変換」を参照してください。

JSON形式のデータをXML形式のデータに変換，またはXML形式のデータをJSON形式のデータに変換することによって，サービスプラットフォームが提供するデータ変換機能と連携ができます。

データ変換機能と連携する変換例を次の図に示します。

図4‒18　データ変換機能と連携する変換例

データ変換機能に設定するフォーマット（XMLスキーマ）は，JSON変換ツールで生成します。JSON変換ツールは，JSON形式のデータを受け取り，JSON-XML変換後のXML形式のデータに適合するフォーマットを生成します。

JSON変換ツールの詳細については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「13.　JSON変換ツールを使用したデータ変換」を参照してください。

JSON形式のデータからフォーマット（XMLスキーマ）を作成し，設定するまでの流れを次の図に示します。

図4‒19　JSON形式のデータからフォーマット（XMLスキーマ）を作成，設定するまでの流れ

また，JSON変換ツールを使用して，JSON-XML変換の動作を確認できます。JSON-XML変換をする前にJSON変換ツールを実行して，JSON-XML変換処理が正しくできるかどうか，および変換結果が正しいかどうかを確認してください。

JSON-XML変換で扱うJSONと標準JSONとの差異，およびJSON-XML変換の規則の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「11.　JSONデータの変換」を参照してください。

データ変換APIを使用したデータ変換の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「12.1　データ変換APIを使用したデータ変換」を参照してください。

4.12　JSON変換ツールを使用した変換

JSON変換ツールは，サービスプラットフォームでJSON形式のデータを利用するために必要な定義の開発およびデータ変換のテストを支援するためのツールです。

JSON変換ツールは，次のコマンドで構成されています。

表4‒19　JSON変換ツールの機能一覧

コマンド名

説明

cscjsonxmlconv

JSON形式データとXML形式データとを相互に変換した結果をファイルとして生成します。サービスプラットフォームが自動的に変換する結果を，生成されたファイルと突き合わせて確認できます。

cscjson2xsd

JSON形式データに対応するXMLスキーマを生成します。生成したXMLスキーマをマッピング定義エディタで使用し，マッピング定義を作成します。

JSON変換ツールとコマンドの関係を次に示します。

図4‒20　JSON変換ツール

JSON変換ツールを利用すると，JSON形式データとXML形式データの変換結果を取得し，どのように変換されるかを確認できます。

また，JSON形式データから変換されたXML形式のデータに対応した，XMLスキーマファイルを生成できます。

JSON-XML変換の規則については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「11.2　JSON-XML変換の規則」を参照してください。

図中のそれぞれのコマンドについて説明します。

cscjsonxmlconvコマンド

JSON形式データとXML形式データとを相互に変換した結果をファイルとして生成します。JSON形式データは，ビジネスプロセス上ではXML形式データとして扱うため，cscjsonxmlconvコマンドによって生成したXML形式データは，カスタムファンクションおよびJavaアクティビティの設計およびテストに活用できます。また，データ変換コマンドまたはバイナリパースコマンドの入力データとしても利用できます。

JSON形式データを利用した，カスタムファンクションおよびJavaアクティビティの開発について次の図に示します。

図4‒21　JSON形式データを利用したカスタムファンクションの開発

cscjson2xsdコマンド

JSON形式のデータをデータ変換するためには，サービスプラットフォームが自動的に変換するXML形式のデータに対してマッピングの定義を作成する必要があります。cscjson2xsdコマンドを利用することで，JSON形式のデータに対応したXMLスキーマファイルを生成できます。生成したXMLスキーマを基にマッピング定義を作成します。

cscjson2xsdコマンドの入力となるJSON形式のデータは事前に用意しておきます。JSON形式データでデータ変換する場合の，データ変換アクティビティを定義する流れを次の図に示します。

図4‒22　JSON形式データを変換するデータ変換アクティビティの定義

JSON変換ツールの詳細は，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「13.　JSON変換ツールを使用したデータ変換」を参照してください。

4.13　サービスのエミュレーション機能の概要

サービスのエミュレーション機能は，サービス呼出アクティビティに設定したサービスアダプタの接続先（サービス部品）がなくても，ビジネスプロセスのテストができる機能です。

サービスのエミュレーション機能を使用したリクエストの流れを次の図に示します。

図4‒23　サービスのエミュレーション機能を使用したリクエストの流れ

エミュレーションする応答電文のデータを記載したファイル（応答電文ファイル）を読み込みます。

読み込んだ内容を応答電文として返却します。

サービスのエミュレーション機能から返却された応答電文は，サービス呼出アクティビティに定義した応答電文のボディ割当変数に設定されます。サービスアダプタを呼び出すことなく，ビジネスプロセスを実行できます。

サービスのエミュレーション機能は，開発環境でも実行環境でも使用できます。使用する環境によって設定手順が異なります。ここでは，実行環境でのサービスのエミュレーション機能について説明します。開発環境でのサービスのエミュレーション機能を使用する場合は，マニュアル「サービスプラットフォーム開発ガイド 基本開発編」の「10.2.2　サービスのエミュレーションの設定」を参照してください。

4.13.1　サービスのエミュレーション機能の設定

サービスのエミュレーション機能を使用するには，HCSCサーバランタイム定義ファイルの次のプロパティに，サービスのエミュレーション機能を使用するかどうかと，エミュレート設定情報定義ファイルのパスを設定する必要があります。

service-emulate.enable（サービスエミュレーション機能の実行有無）

service-emulate-def-filepath（エミュレート設定情報定義ファイルの絶対パス）

HCSCサーバランタイム定義ファイルについては，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

また，エミュレート設定情報定義ファイルでエミュレーションに必要な情報を設定します。サービスのエミュレーションに必要な情報は，エミュレーションするサービスアダプタのオペレーション単位で設定します。エミュレーションに必要な情報を次に示します。

エミュレーション対象のサービスアダプタ

エミュレーション対象のサービスアダプタのオペレーション

応答電文の種別

エミュレーションの実行有無

応答電文ファイル

エミュレーションする条件

優先順位

エミュレート設定情報定義ファイルについては，マニュアル「サービスプラットフォーム リファレンス」の「6.5.7　エミュレート設定情報定義ファイル」を参照してください。

(1)　応答電文のエミュレーション

サービスのエミュレーション機能を使用すると，ユーザが作成した応答電文ファイルの内容が，サービス呼出アクティビティの応答電文のボディ割当変数に設定されます。ヘッダ割当変数はエミュレーションの対象外となります。サービス呼出アクティビティの応答電文のボディ割当変数には，種別が「XML」「non-XML」「any」の変数が設定できます。

(2)　要求電文の変換処理

応答電文ファイルにXSLTスタイルシート（ファイル拡張子「.xsl」）を指定すると，要求電文をXSLTスタイルシートで変換した結果を応答電文としてエミュレーションできます。このエミュレーションでの注意点を次に示します。

要求電文と応答電文の両方の変数種別がXMLの場合だけ実行できます。それ以外の場合，動作は保証しません。

変換元（要求電文）を複数指定することはできません。

XSLTスタイルシートには，マッピング定義エディタから生成したデータ変換定義ファイルで，かつファイル拡張子が「.xsl」のファイルを指定する必要があります。それ以外のファイルを指定した場合の動作は保証しません。

(3)　サービスのエミュレーション機能の実行条件

サービスのエミュレーション機能は，エミュレート設定情報定義ファイルの設定が，次のすべての条件に当てはまる場合だけ実行されます。

エミュレーション機能の実行有無に有効（true）を設定している。

エミュレーション対象のサービスアダプタがサービス呼出アクティビティに定義されているサービス名と一致する。

エミュレーション対象のサービスアダプタのオペレーション名がサービス呼出アクティビティに定義されているオペレーション名と一致する。

エミュレーションする条件を定義している場合，XPath式の評価結果が真である。

実行条件に当てはまらない場合は，通常のサービス呼び出しが実行されます。

(4)　1つのビジネスプロセス内で複数のサービスアダプタを呼び出している場合の定義例

1つのビジネスプロセス内で複数のサービスアダプタを呼び出している場合，エミュレート設定情報定義ファイルで，emulate要素を複数設定することでエミュレーションの定義を複数設定できます。

　　　　　　　　　　　　　：
<viewState>
<emulate condition="" operation="operation1" service="SOAPAdapter" type="RESPONSE_NORMAL" valid="true" xmlfile="/data/telegram/test1.xml"/>
<emulate condition="" operation="exec" service="TP1Adapter" type="RESPONSE_NORMAL" valid="true" xmlfile="/data/telegram/test2.xml"/>
</viewState>
　　　　　　　　　　　　　：

(5)　サービスアダプタに複数のオペレーションが設定されている場合の定義例

サービスアダプタに複数のオペレーションが設定されている場合，エミュレート設定情報定義ファイルで，オペレーションごとにemulate要素を定義することで同一のサービスアダプタの定義を複数設定できます。

　　　　　　　　　　　　　：
<viewState>
<emulate condition="" operation="operation1" service="SOAPAdapter" type="RESPONSE_NORMAL" valid="true" xmlfile="/data/telegram/test1.xml"/>
<emulate condition="" operation="operation2" service="SOAPAdapter" type="RESPONSE_NORMAL" valid="true" xmlfile="/data/telegram/test2.xml"/>
</viewState>
　　　　　　　　　　　　　：

4.13.2　サービスのエミュレーション機能を使用する場合の注意

サービスのエミュレーション機能を使用する場合の注意について説明します。

サービスアダプタの通信モデルが非同期の場合，サービスのエミュレーション機能は実行できません。

サービスのエミュレーションの実行時は，サービスアダプタを呼び出さないため，サービスアダプタで実行する機能や，ビジネスプロセスのサービス呼出アクティビティの機能の一部が使用できません。使用できない機能を次に示します。

サービスアダプタでデータ変換を定義している場合は，エミュレーション実行時にサービスアダプタのデータ変換は実行できません。

フォルト電文をエミュレーションする場合，サービスアダプタ定義画面で設定したフォルト名は設定されません。フォルト名は「invokeEmulateData」となります。

応答電文のヘッダ電文は，エミュレーションされません。

実行環境のエミュレーションでは，サービスアダプタでコンポーネント共通UOCは実行されません。

HTTPアダプタでJSON-XML変換は実行されません。

Cookie情報は引き継がれません。

XML形式の電文のエミュレーション実行時は，XML電文内の属性値に指定した名前空間接頭辞は補完されません。

電文の妥当性検証は実行されません。

リクエストトレースでは，サービスアダプタからサービス部品を呼び出したときの要求または応答の結果（取得位置：SVC）は出力されません。

サービスアダプタのPRFトレースは出力されません。

サービスアダプタからサービス部品を呼び出したときの要求または応答の電文トレース（取得位置：SVC）や，サービスアダプタでデータ変換を実行したときの変換前または変換後の電文トレース（CNVST）は出力されません。

各種サービスアダプタで出力している固有のトレースのうち，リクエスト実行時に出力しているトレースは出力されません。

エミュレート設定情報定義ファイルや応答電文ファイルの内容を変更した場合，変更した内容は次のリクエストで反映されます。ただし，リクエスト実行中はファイルの内容は変更できません。

開発環境のビジネスプロセスのデバッグ機能で応答電文をエミュレーションした場合，エミュレート設定情報定義ファイルの設定は有効になりません。

5　性能向上のための機能

この章では，性能向上のための機能として，サービス部品呼び出し処理の多重度，XML電文のキャッシュ機能，ビジネスプロセスの事前キャッシュ機能，データ変換処理のXMLパーサプール機能，およびデータ変換のキャッシュ機能について説明します。

5.1　サービス部品呼び出し処理の多重度

サービスリクエスタからのサービス部品の呼び出し要求は，同時に実行される場合があります。そのため，サービス部品呼び出し処理の多重度（同時に実行できる数）を設定する必要があります。

5.1.1　HCSCサーバ内の多重度

多重度の設定が良くない場合，性能上のボトルネックになるおそれがあります。

多重度の設定によってボトルネックになる例を次の図に示します。

図5‒1　多重度の設定によってボトルネックになる例

「図5-1　多重度の設定によってボトルネックになる例」に示すように，リクエスト受付（標準受付またはユーザ定義受付）の多重度が小さいと，一度にたくさん要求が来ても同時に処理ができないため，一度に実行できる処理が少なくなります。また，リクエスト受付の多重度を大きくしても，サービスアダプタで定義している多重度が小さいと，サービスアダプタで一度に実行できる処理が少ないため，サービスアダプタがボトルネックになり，意図した性能を得られなくなります。

(1)　HCSCサーバでの多重度

多重度は，同期（Webサービス）の標準受付の場合は，スレッド数および最大同時実行数で設定します。同期（SessionBean）の標準受付の場合は，インスタンス数で設定します。HCSCサーバ内の多重度の設定について，「表5-1　標準受付の多重度を設定するプロパティ」，「表5-2　ユーザ定義受付の多重度を設定するプロパティ」，および「表5-3　サービスアダプタの多重度を設定する項目」に示します。

表5‒1　標準受付の多重度を設定するプロパティ

定義ファイル

プロパティ

内容

HCSCサーバランタイム定義ファイル

request-ejb.instance.minimum

同期（SessionBean）の標準受付のインスタンス最小数

request-ejb.instance.maximum

同期（SessionBean）の標準受付のインスタンス最大数

request-ejb.parallel.count

CTMがアプリケーションを呼び出すために用意するスレッド数

request-soap.instance.minimum

同期（Webサービス・SOAP1.1）の標準受付の最小同時実行数

request-soap.instance.maximum

同期（Webサービス・SOAP1.1）の標準受付の最大同時実行数

request-soap1_2.instance.minimum

同期（Webサービス・SOAP1.2）の標準受付の最小同時実行数

request-soap1_2.instance.maximum

同期（Webサービス・SOAP1.2）の標準受付の最大同時実行数

request-jms.instance.maximum

非同期（MDB（WS-R））の標準受付のインスタンス最大数

表5‒2　ユーザ定義受付の多重度を設定するプロパティ

定義ファイル

プロパティ

内容

ユーザ定義受付ランタイム定義ファイル

user-defined-reception-soap.threads.maximum

最大同時実行数

表5‒3　サービスアダプタの多重度を設定する項目

画面

内容

開発環境でのサービスアダプタ定義画面

最大インスタンス数

注

最大インスタンス数に0を指定した場合は，上限が設定されないで無制限になります。

(2)　Webサービス（SOAP通信）での多重度

Webサービス（SOAP通信）の場合，同時実行数のほかにWebコンテナレベルでの最大キュー滞留数を設定できます。最大同時実行数と最大キュー滞留数を設定しておくと，サービスリクエスタからの要求を受けたときに，実際の処理をしないで処理を待たせておけるため，流量制御ができます。サービスリクエスタからの要求と最大キュー滞留数の関係を次の図に示します。

図5‒2　サービスリクエスタからの要求と最大キュー滞留数の関係

例えば，「図5-2　サービスリクエスタからの要求と最大キュー滞留数の関係」に示すように，最大同時実行数を3とした場合，最大キュー滞留数を10にしておくと，同時にきたサービス部品呼び出し要求のうち，3件までは同時に処理されます。同時実行数より多くのサービス部品呼び出し要求（4件以上）がきた場合は，最大キュー滞留数（10件）までは，処理待ちの状態となり，先に実行されている処理が終わり次第，順次処理が実行されます。

最大キュー滞留数の数が上限（10件）まで達している場合に，さらにサービスリクエスタからサービス部品呼び出し要求がきた場合は，要求は受け付けられないため，エラーとしてサービスリクエスタに応答されます。

HCSCサーバ内の最大キュー滞留数は，「表5-4　標準受付の最大キュー滞留数を設定するプロパティ」および「表5-5　ユーザ定義受付の最大キュー滞留数を設定するプロパティ」に示す定義ファイルのプロパティで設定します。

表5‒4　標準受付の最大キュー滞留数を設定するプロパティ

定義ファイル

プロパティ

内容

HCSCサーバランタイム定義ファイル

request-soap.queue-size

同期（Webサービス・SOAP1.1）の標準受付の実行待ちキューのサイズ

request-soap1_2.queue-size

同期（Webサービス・SOAP1.2）の標準受付の実行待ちキューのサイズ

表5‒5　ユーザ定義受付の最大キュー滞留数を設定するプロパティ

定義ファイル

プロパティ

内容

ユーザ定義受付ランタイム定義ファイル

user-defined-reception-soap.queue-size

実行待ちキューサイズ

5.1.2　データベースへのアクセスに関する多重度

永続化するビジネスプロセスを使用する（プロセスインスタンスの実行履歴を採取する）場合，および非同期プロトコルを使用する場合は，HCSCサーバに設定するDB Connectorの定義で，コネクションプール数を設定します。

(1)　永続化するビジネスプロセスを使用する場合

HCSCサーバに設定した2つのDB Connectorのうち，HCSCサーバセットアップ定義ファイルのdbcon-xadisplaynameプロパティに指定したDB Connectorを使用します。リクエスト受付からビジネスプロセスを経由して，一度に多くの要求が来ても，DB Connectorの部分でデータベースへの出力が一度にできなくなります。すると，性能上のボトルネックが発生して，その結果，ビジネスプロセスの同時実行処理性能が遅くなります。そのため，プロセスインスタンスの実行履歴を採取するときの多重度を設定する必要があります。永続化するビジネスプロセスを使用する場合のボトルネックを次の図に示します。

図5‒3　永続化するビジネスプロセスを使用する場合のボトルネック

(2)　非同期プロトコルを使用する場合

HCSCサーバに設定した2つのDB Connectorのうち，HCSCサーバセットアップ定義ファイルのdbcon-xadisplaynameプロパティに指定したDB Connectorは，非同期（MDB（WS-R）またはMDB（DBキュー））の標準受付でキューからメッセージを取り出したり，非同期（MDB（WS-R）またはMDB（DBキュー））のサービスアダプタでメッセージを送信したりするときにも使用します。そのため，プロセスインスタンスの実行履歴を採取するときの多重度に加えて，HCSCサーバがリクエスト受付のキューからメッセージを取り出すときや，サービスアダプタが転送キューにメッセージを送信するときの多重度も含めて，コネクションプール数を検討する必要があります。

キューに対して一度に多くの要求が来ても，Reliable Messagingのリソースアダプタが同時にメッセージの取り出し処理ができないで，性能上のボトルネックが発生します。また，サービスアダプタの多重度を大きくしていても，サービスアダプタがキューにメッセージを送信するときの同時実行数が少ないと，やはり性能上のボトルネックが発生します。非同期プロトコルを使用する場合のボトルネックを次の図に示します。

図5‒4　非同期プロトコルを使用する場合のボトルネック

(3)　データベースへのアクセスに関する多重度の設定

データベースへのアクセスに関する多重度は，次の表に示すように設定します。

表5‒6　DB Connectorの多重度を設定するプロパティ

定義ファイル

プロパティ

内容

DB Connector（LocalTransactionまたはXATransaction）のセットアップ時に設定する属性ファイル

MinPoolSize

プールの最小値

MaxPoolSize

プールの最大値

注1

プールの最大値を増やした場合，データベース側の同時接続数も変更する必要があるため，注意が必要です（HiRDBの場合，pd_max_users（HiRDBの最大接続数）となります）。

注2

実行環境が使用するDBコネクション数の最大値については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「3.1.2　実行環境に必要なソフトウェアを設定する」を参照してください。

表5‒7　Reliable Messagingの多重度を設定するプロパティ

定義ファイル

プロパティ

内容

Reliable Messagingのセットアップ時に設定する属性ファイル

MinPoolSize

プールの最小値

MaxPoolSize

プールの最大値

5.1.3　Webサービス（SOAP通信）に関する多重度

(1)　同時実行スレッド数

Webサービス（SOAP通信）を使用する場合は，実行環境で設定しているWebサーバ（HTTPサーバ）の同時実行スレッド数も関係します。

標準受付（Webサービス）およびSOAP受付が複数ある場合，各受付に設定した同時実行スレッド数の合計より，Webサーバに設定した全体の同時実行スレッド数が優先されます。そのため，Webサーバに設定した全体の同時実行スレッド数が，各受付に設定した同時実行スレッド数の合計より小さいと，一度に多くの要求が来ても同時に処理ができないため，性能上のボトルネックになることがあります。

Webサービス（SOAP通信）を使用する場合のボトルネックを次の図に示します。

図5‒5　Webサービス（SOAP通信）を使用する場合のボトルネック

Webサービス（SOAP通信）に関する多重度は，次のように設定します。

HTTP Serverの場合

コンフィグファイルに指定できるディレクティブのうち，Webサーバの性能についての定義に関するディレクティブを定義します。

詳細については，マニュアル「HTTP Server」の「6.1.1　ディレクティブ一覧」を参照してください。

インプロセスHTTPサーバ機能またはNIO HTTPサーバ機能の場合

運用管理ポータルの[論理サーバの環境設定]−[J2EEサーバ]−[J2EEサーバの論理サーバ名]−[HTTPサーバ]で次の内容を設定します。

同時実行スレッド数

初期スレッド数

インプロセスHTTPサーバは，J2EEサーバの互換モードがV9互換モードの場合，使用できます。推奨モードの場合は，NIO HTTPサーバを使用してください。

インプロセスHTTPサーバについては，マニュアル「アプリケーションサーバ 機能解説 互換編」の「6.　インプロセスHTTPサーバ」を参照してください。

NIO HTTPサーバを使用する場合のシステム構築の詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「7.　NIO HTTPサーバ」を参照してください。

(2)　占有スレッド数

Webサーバ（HTTPサーバ）の同時実行スレッド数が十分な数を確保できない状況であっても，個々のリクエスト受付で必ず最低限の実行をする場合は，占有スレッド数を定義します。

占有スレッド数を定義した場合は，Webサーバ（HTTPサーバ）の同時実行スレッド数以上の要求が個別のリクエスト受付に来た場合でも，必ず指定した数だけは同時に実行されます。

ほかのリクエスト受付に要求が来ていない場合は，最大同時実行数まで同時に実行できます。

HCSCサーバ内の占有スレッド数は，「表5-8　標準受付の占有スレッド数を設定するプロパティ」および「表5-9　ユーザ定義受付の占有スレッド数を設定するプロパティ」に示すように設定します。

表5‒8　標準受付の占有スレッド数を設定するプロパティ

定義ファイル

プロパティ

内容

HCSCサーバランタイム定義ファイル

request-soap.exclusive.threads

同期（Webサービス・SOAP1.1）の標準受付の占有スレッド数

request-soap1_2.exclusive.threads

同期（Webサービス・SOAP1.2）の標準受付の占有スレッド数

表5‒9　ユーザ定義受付の占有スレッド数を設定するプロパティ

定義ファイル

プロパティ

内容

ユーザ定義受付ランタイム定義ファイル

user-defined-reception-soap.exclusive.threads

占有スレッド数

最大同時実行数と占有スレッド数の関係を次の図に示します。

図5‒6　最大同時実行数と占有スレッド数の関係

「図5-6　最大同時実行数と占有スレッド数の関係」に示すように，標準受付，2つのユーザ定義受付，およびWebサーバ（HTTPサーバ）を次のように設定した場合，標準受付は必ず2つのスレッドを占有します。

標準受付：最大キュー滞留数10，同時実行数3，占有スレッド数2

ユーザ定義受付：同時実行数2

Webサーバ（HTTPサーバ）：同時実行数5

そのため，Webサーバ（HTTPサーバ）の同時実行数に指定した5件以上の要求が来ると，2つのスレッドは標準受付の実行のために使用され，残りの3つのスレッドを使ってユーザ定義受付が動作します。

ただし，最大キュー滞留数，標準受付の同時実行数，占有スレッド数，およびWebサーバ（HTTPサーバ）の同時実行数が「図5-6　最大同時実行数と占有スレッド数の関係」と同じ場合で，「図5-7　占有スレッド数を指定した受付に要求が来ない場合」に示すように，占有スレッド数を指定した標準受付に要求が来ていないときでも，必ず2つはスレッドを占有して実行する状態になります。また，ほかのユーザ定義受付では，それぞれ同時実行数が2件で合計の同時実行数は4件になるはずですが，Webサーバ（HTTPサーバ）の同時実行数5件であるため，残り3つしか処理できなくなります。ほかのリクエスト受付の同時実行数が増えることはありません。

図5‒7　占有スレッド数を指定した受付に要求が来ない場合

5.1.4　XML解析処理に関する多重度

要求電文および応答電文の処理に使用するクラスは複数のスレッドで共有できないため，複数のスレッドで同時使用する場合は，スレッドごとにインスタンスを生成する必要があります。

インスタンスの生成処理は時間を要するため，解析ごとに生成すると性能が劣化します。

インスタンスプール機能を使用すると，メモリ上に作成されたインスタンスプールに生成したインスタンスを貯めておくことができます。インスタンスプールへ貯めたインスタンスは，システム全体で共有し，再利用できるため，処理の効率向上が図れます。

インスタンスプールに生成したインスタンスを貯めておくには，次の表に示すように設定します。

表5‒10　インスタンスプールにキャッシュするインスタンス数を設定するプロパティ

定義ファイル

プロパティ

内容

HCSCサーバランタイム定義ファイル

xml-pooled-instance-minimum

要求電文および応答電文の処理に使用するクラスのインスタンスをキャッシュする最小数

xml-pooled-instance-maximum

要求電文および応答電文の処理に使用するクラスのインスタンスをキャッシュする最大数

作成済みのインスタンスを再利用する場合は，キャッシュする最小数を定義します。キャッシュする最小数を定義しておくと，HCSCサーバの起動時にプールが初期化され，定義した値の分のインスタンスを生成してプールに設定します。

キャッシュする最大数を設定しておくと，定義した値に達するまでインスタンスを貯めることができます。再利用によってインスタンスが減少しても，インスタンスを生成してプールに設定するため，枯渇することはありません。

xml-pooled-instance-minimumプロパティおよびxml-pooled-instance-maximumプロパティの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

5.2　XML電文のキャッシュ機能

XML 電文のキャッシュ機能の概要と設定について，説明します。

5.2.1　XML電文のキャッシュ機能の概要

XML電文のキャッシュ機能を使用すると，次に示す条件が同一のXML電文が流れる場合に，処理速度が向上することがあります。

要素の並び順が同じ

属性の並び順が同じ

要素の繰り返しが同じ

これは，一度解析したXML文書の特徴を保持しているため，類似文書の場合にパース処理速度の向上が図れます。

5.2.2　XML電文のキャッシュ機能の設定

XML電文のキャッシュ機能を使用するには，HCSCサーバランタイム定義ファイルのxmltelegram-maxcache-numプロパティで値を設定します。

xmltelegram-maxcache-numプロパティの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

5.3　ビジネスプロセスの事前キャッシュ機能

事前キャッシュ機能を使用すると，ビジネスプロセスでリクエストを処理する前に，フォーマット定義および変換定義の解析とHCSCサーバ上への解析結果のキャッシュができます。キャッシュした定義は，HCSCサーバまたはコンポーネントを停止するまで保持されるため，リクエスト処理速度の向上が図れます。

事前キャッシュ機能を利用するには，cscprecacheコマンドを使用します。cscprecacheコマンドの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「cscprecache（フォーマット定義およびデータ変換定義の事前キャッシュ）」を参照してください。

5.4　データ変換処理のXMLパーサプール機能

データ変換の処理では，次に示すJavaのXMLパーサによってXMLを解析しています。

DOMパーサ（javax.xml.DocumentBuilderクラス）

SAXパーサ（org.xml.sax.XMLReaderクラス）

これらのXMLパーサのインスタンスは複数のスレッドで共有できないため，複数のスレッドで同時使用する場合は，スレッドごとにXMLパーサを生成しています。XMLパーサの生成処理は時間を要するため，解析ごとに生成すると性能が劣化します。

XMLパーサプール機能を使用すると，メモリ上に作成されたXMLパーサプールに生成したXMLパーサを貯めておくことができます。XMLパーサプールへ貯めたXMLパーサは，システム全体で共有し，再利用できるため，処理の効率向上が図れます。

生成したXMLパーサをメモリ上に作成されたXMLパーサプールに貯めておく処理の流れを次の図に示します。

図5‒8　生成したXMLパーサをメモリ上に作成されたXMLパーサプールに貯めておく処理の流れ

XMLパーサプールへ貯めたXMLパーサを再利用する処理を次の図に示します。

図5‒9　XMLパーサプールへ貯めたXMLパーサを再利用する処理

XMLパーサプールに貯めることができるXMLパーサの最大数は，オプションで指定した最大プール数の2,147,483,647です。XMLパーサを同時使用するスレッド数が最大プール数を超える場合は，他のスレッドでの使用が終わるまで処理を停止し，未使用となり次第処理を続行します。

XMLパーサを同時使用するスレッド数が最大プール数を超えた場合の処理を次の図に示します。

図5‒10　XMLパーサを同時使用するスレッド数が最大プール数を超えた場合の処理

XMLパーサプール機能を使用するための設定方法については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「2.3.9　J2EEサーバ用ユーザプロパティファイル（usrconf.properties）を設定する」のXMLパーサプール機能オプションに関する記述を参照してください。

5.5　データ変換のキャッシュ機能

コマンドやリクエストの処理によって，データ変換基盤にフォーマット定義とデータ変換定義がキャッシュとして登録されます。登録されたキャッシュは，コマンドの実行によって削除されます。また，キャッシュ機能を利用し，オブジェクトを再利用することもできます。

登録されているキャッシュ数を確認したい場合は，cscresinfoコマンドで取得します。cscresinfoコマンドの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「cscresinfo（リソース稼働情報の表示）」を参照してください。

5.5.1　キャッシュの登録および削除のタイミング

HCSCコンポーネントごとのキャッシュの登録および削除のタイミングを次に示します。

表5‒11　キャッシュの登録および削除のタイミング

キャッシュの動作

HCSCコンポーネント

ビジネスプロセス

ユーザ定義受付

サービスアダプタ

キャッシュの登録

次の場合に，キャッシュが登録されます。

ビジネスプロセスへの初回リクエスト※

cscprecacheコマンドの事前キャッシュ処理

ユーザ定義受付への初回リクエスト※

サービスアダプタへの初回リクエスト※

キャッシュの削除

csccompostopコマンドでの，ビジネスプロセスの停止処理中

csccompostopコマンドでの，ユーザ定義受付の停止処理中

cscsvstopコマンドでの，HCSCサーバ停止処理中

注※

初回リクエスト時に，表5-12のキャッシュ契機に記載されている動作が行われた場合にキャッシュが登録されます。ただし，cscprecacheコマンド実行時は除きます。

5.5.2　キャッシュ機能を利用したオブジェクトの再利用

サービスプラットフォームではデータ変換などの生成に時間が掛かるオブジェクトを扱う場合，キャッシュ機能を利用し，オブジェクトを再利用しています。各オブジェクトの再利用とキャッシュ数の調整方法を次に示します。なお，アダプタ，ビジネスプロセスを再起動した場合は，新しいオブジェクトが生成されるため，以前のオブジェクトは再利用されません。

表5‒12　オブジェクトの再利用とキャッシュ数の調整方法

機能

キャッシュ契機

キャッシュ再利用契機

キャッシュ数調整方法

データ変換定義オブジェクトのキャッシュ

cscprecacheコマンド実行時

データ変換時（XML・バイナリ）

データ変換時（XML・バイナリ）

HCSCサーバランタイム定義ファイルのtransformdef-maxcache-numプロパティの値を調整します。

フォーマット定義オブジェクトのキャッシュ

cscprecacheコマンド実行時

XML→バイナリ変換後※1

バイナリ→XML変換前※1

バイナリ→バイナリ変換前後

ビジネスプロセスのフォルト処理時

バリデーション時※2

XML→バイナリ変換後

バイナリ→XML変換前

バイナリ→バイナリ変換前後

ビジネスプロセスのフォルト処理時

バリデーション時

HCSCサーバランタイム定義ファイルのformatdef-maxcache-numプロパティの値を調整します。

XML文書解析オブジェクトのキャッシュ

XML変換前後

ビジネスプロセスのXPath操作時

XML変換前後

ビジネスプロセスのXPath操作時

HCSCサーバランタイム定義ファイルのxmltelegram-maxcache-numプロパティの値を調整します。

注※1

XMLスキーマはキャッシュされません。

注※2

次の機能の実行時を示します。

・ビジネスプロセスの検証アクティビティ実行時

・データ検証機能実行時

5.5.3　サービスアダプタでのキャッシュの注意事項

サービスアダプタで電文のデータ変換を行う場合，フォーマット定義とデータ変換定義のオブジェクトが生成されます。しかし，オブジェクト名の一部にデプロイの時刻が設定されているため，サービスアダプタを再デプロイした場合に前回のオブジェクトが参照されずに，新しいオブジェクトが生成されます。

また，サービスアダプタはcsccompostopコマンドでキャッシュが削除されないため，サービスアダプタのデプロイ・アンデプロイ，およびキャッシュの登録を繰り返すと，利用しないキャッシュが増え続けます。

不要なキャッシュを削除するため，cscsvstopコマンドを実行し，HCSCサーバを停止後，再デプロイを実施してください。

6　障害調査のための機能

この章では，サービスプラットフォームで発生した障害を調査する機能について説明します。

6.1　障害情報の取得・障害回復・障害解析機能

6.1.1　障害情報の取得機能

サービスプラットフォームの運用環境には，運用・実行環境での障害の発生に備えて，トレース情報を保存する機能があります。トレース情報は，次に示すファイルに格納されます。

メッセージログファイル

リクエストトレースファイル

性能解析トレースファイル

保守情報（例外ログ，メンテナンスログ，メソッドトレースなど）

これらのトレース情報を確認することで，障害の発生時刻，発生場所，原因などを把握できます。

また，サービスプラットフォームの開発環境および運用環境の画面では，画面操作時に自動的に実行されるチェックによって出力されたメッセージは，コンソールビューに表示されます。コンソールビューに表示されるメッセージの内容を確認し，各種定義や設定を変更してから再度操作できます。

6.1.2　障害回復機能

次に示す運用時に発生した障害についても，コマンドで情報の確認，ファイルのバックアップ，環境の復旧などができます。

システムのセットアップまたはアンセットアップ時

オペレーション実行時

サービス部品呼び出し実行時

6.1.3　障害解析機能

サービスプラットフォームでは，性能解析トレースファイルを利用して障害解析を補助するメッセージトラッキング機能を提供しています。メッセージトラッキングとは，障害発生個所を特定し，障害の切り分けや障害調査を補助する障害解析ツールです。メッセージトラッキングを起動すると，専用の対話型プロンプトが表示されます。表示された対話型プロンプトでコマンドを実行し，性能解析トレースファイルを解析します。

メッセージトラッキング機能は，障害発生時の性能解析トレースファイルがあれば，Service Architect，またはService Platformがインストールされているマシンならどこでも利用できます。そのため，障害が発生したHCSCサーバ稼働マシンだけでなく，障害が発生したHCSCサーバとは別のリモート環境でも障害を解析できます。

6.2　データ検証機能

6.2.1　データ検証機能の概要

サービスアダプタでは，要求電文や応答電文が，定義したフォーマット定義に対して妥当かどうかを検証できます。また，データ変換機能を利用している場合は，変換前後の電文が，定義したフォーマット定義に対して妥当かどうかを検証できます。

サービスアダプタに指定したフォーマット定義の形式と，要求時および応答時に送られてくる電文の形式が妥当であるかどうか検証し，電文がフォーマットの形式に対して妥当でない場合は，サービスを実行する前にエラーを返します。

テスト環境などで，サービスを実行する前に妥当な電文かどうかを検証できるため，サービスの実行の失敗を事前に回避できます。

注意事項

データ検証機能が有効になっている場合，サービスリクエスタやサービスから受信した電文が，サービスアダプタ定義時に指定した電文フォーマットに適合しているかどうかのチェックが実施されます。データ検証機能が無効になっている場合，このチェックは実施されません。

データ検証機能が無効の状態で，HCSCサーバが電文フォーマットに適合しない電文を受信した場合，動作は保証しません。

要求電文とフォーマット定義が一致する場合と一致しない場合の電文の流れを次の図に示します。

図6‒1　要求電文とフォーマット定義が一致する場合と一致しない場合の電文の流れ

6.2.2　データ検証機能の設定

データ検証機能を使用するには，HCSCサーバランタイム定義ファイルのtelegram-validationプロパティで値を設定します。

telegram-validationプロパティの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

6.2.3　データ検証機能の有効範囲

データ検証機能の有効範囲を次の表に示します。なお，データ検証機能が有効な場合，検証の対象はHCSCサーバ全体になります。

表6‒1　データ検証機能の有効範囲

サービスアダプタの種別

電文種別

要求/応答

サービスアダプタでのデータ変換有無

検証機能有効/無効

検証される電文

SOAPアダプタ，SessionBeanアダプタ，MDB（WS-R）アダプタ，MDB（DBキュー）アダプタ

XML

要求

データ変換なし

有効

サービス部品電文

標準電文→サービス部品電文へのデータ変換あり

有効

標準電文，サービス部品電文

応答

データ変換なし

有効

サービス部品電文

サービス部品電文→標準電文へのデータ変換あり

有効

標準電文，サービス部品電文

バイナリ

要求

データ変換なし

無効

−

リクエスタ→標準電文→サービス部品電文へのデータ変換以外

無効

−

応答

データ変換なし

無効

−

サービス部品電文→標準電文→リクエスタへのデータ変換以外

無効

−

DBアダプタ

XML

すべて

すべて

無効

−

（凡例）

−：該当しません。

電文の検証機能が有効になるサービスアダプタの詳細については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「7.7.24　ユーザ電文に誤りがある場合の障害対策」を参照してください。

6.3　ユーザ電文トレース機能

6.3.1　ユーザ電文トレース機能の概要

ユーザ電文トレース機能は，HCSCサーバ上を流れる電文の内容をユーザ電文トレースファイルに出力する機能です。

次の内容をユーザ電文トレースとして取得できます。

リクエスト受付で受け付けたサービス部品呼び出し要求または応答の電文

ビジネスプロセスを呼び出した時の要求または応答の電文

サービスアダプタからサービス部品を呼び出したときの要求または応答の電文

データ変換を行ったときの変換前または変換後の電文

バイナリデータの変換エラー時のデバッグ情報

ユーザ電文トレース機能を使用することによって，設計したとおりの電文が流れているかを確認できます。また，各ポイント（リクエスタ側とサービス側，ビジネスプロセスのアクティビティ，データ変換など）も確認できるため，開発の容易性が増します。

6.3.2　ユーザ電文トレース機能の設定

ユーザ電文トレース機能を使用するには，次に示すHCSCサーバランタイム定義ファイルのプロパティで値を設定します。

telegramtraceプロパティ

telegramtrace-filepathプロパティ

telegramtrace-filesizeプロパティ

telegramtrace-filenumプロパティ

telegramtrace-triggerプロパティ

telegramtrace-component-id-filepathプロパティ

telegramtrace-component-type-filepathプロパティ

telegramtrace-formatプロパティ

各プロパティの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

ユーザ電文トレースを取得する設定にすると，HCSCサーバ全体に対して有効となります。

6.3.3　ユーザ電文トレース機能使用時の注意事項

ユーザ電文トレース機能使用時の注意事項を次に示します。

ユーザ電文トレース機能は，電文の内容をファイルに出力します。そのため，電文の内容が情報漏洩する懸念があり，セキュリティ上の問題が発生します。したがって，出力したユーザ電文トレースファイルの取り扱いに注意してください。

ユーザ電文トレースファイルが電文の内容を出力する際は，出力先の環境に設定された文字コード（J2SEのfile.encodingプロパティで設定された文字コード）を使用します。

6.4　アクティビティトレース機能

アクティビティトレースを使うと，アクティビティの処理経路を出力できるようになります。アクティビティトレースに出力されるのは，リクエスト時にビジネスプロセス内で実行されたアクティビティのログです。

アクティビティトレースを使用することで，設計したとおりにアクティビティが遷移しているかを確認できます。また，そのほかのトレース情報や設計情報と突き合わせることで，アクティビティが意図した分岐先に遷移しなかった場合などの原因の調査にも役立ちます。

アクティビティトレースの出力方法については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「7.4.5　アクティビティトレース」を参照してください。

7　他製品と連携して利用する機能

この章では，JP1と連携した運用管理，接続できるデータベース，およびHiRDBと連携した実行履歴の管理について説明します。

7.1　JP1と連携した運用管理

JP1と連携してサービスプラットフォームを運用すると，業務システム全体の監視，問題の検知などの運用を効率良くできるようになります。また，サーバやアプリケーションの起動・停止を自動化することで，システムの日常運用の効率化を図れます。

JP1と連携したシステムの運用については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「12.2　JP1との連携」も参照してください。

7.1.1　JP1/IMとの連携による障害検知

システムで発生した障害をJP1イベントによって集中管理することができます。サービスプラットフォームではJP1/IM - Managerと連携し，システムで発生した障害を検知して，障害メッセージをJP1イベントとしてJP1へ通知できます。また，JP1/IM - Viewでは，JP1/IM - Managerのホストに接続して，実行環境から発行されたJP1イベントを表示できます。JP1イベントとして発行されるメッセージは，ユーザの環境に合わせてカスタマイズできます。

どの障害が発生した場合に，どのメッセージが通知されるかをあらかじめ設定しておくことで，JP1/IM - Viewで表示されるメッセージログを監視して，障害発生時の障害の種類や原因などの調査を簡略化できます。

JP1/IMと連携した障害監視の概要を次の図に示します。

図7‒1　JP1/IMと連携した障害監視の概要

Management Serverで，JP1/IMで監視するJP1イベント発行を設定します。

実行環境で発生した障害のメッセージがJP1イベントに変換されます。

JP1/Baseを使用して，システムで発生した障害のメッセージがJP1イベントとして発行されます。

JP1イベントがJP1統合運用管理環境に転送されます。

JP1統合運用管理環境に転送されてきたJP1イベントが，JP1/IM - Managerによって収集されます。

統合コンソールからJP1/IM - Viewを使用し，JP1/IM - Managerに接続して，JP1イベントの詳細を確認できます。

7.1.2　JP1によるプロセス監視

サービスプラットフォームのシステムをJP1で監視する場合の推奨プロセスについて説明します。

(1)　監視推奨プロセス

HCSCサーバ起動時の各論理サーバのプロセスは，Managerで監視されていて，プロセスダウンやハングアップなどの障害が発生すると，論理サーバを自動で再起動します。そのため，サービスプラットフォームのシステムをJP1で監視する場合は，次のプロセスを監視の対象とすることを推奨します。

Management Server

運用管理エージェント

ポイント

各論理サーバのプロセスのうち，上記推奨プロセス以外のプロセスをJP1で監視すると，プロセスの二重監視になります。

HCSCサーバ起動時のプロセス構成を次の図に示します。

図7‒2　HCSCサーバ起動時のプロセス構成

JP1の監視推奨となるプロセス名を次の表に示します。

表7‒1　JP1からの監視推奨となるプロセス名

監視推奨プロセス

プロセス名

Windowsの場合

UNIXの場合

Management Server

mngsvr.exe

cjstartsv※

運用管理エージェント

adminagentsv.exe

adminagent

注※

コマンドライン名（ps -ef相当）で監視します。実行例を次に示します。

　/opt/Cosminexus/CC/server/bin/cjstartsv cosmi_m

「cosmi_m」はデフォルトのサーバ名です。「cosmi_m」以外のサーバ名に変更している場合は，監視するコマンドライン名も変更する必要があります。

また，データベースを使用している場合は，使用しているデータベースのプロセスもJP1の監視推奨プロセスとなります。それらのプロセス名については，各データベースのマニュアルを参照してください。

(2)　プロセスを監視するときの注意事項

プロセス数の上限と下限で監視する場合，上限を1，下限を1で監視すると，一時的にcjstartsvやadminagentのプロセスが1より大きくなり，障害を検知してしまうことがあります。Management Server，運用管理エージェントについては複数起動を抑止する機能があるため，Managerの推奨としては上限なしで監視してください。

7.2　接続できるデータベース

ここでは，サービスプラットフォームから接続できるデータベースおよび接続に使用するJDBCドライバについて説明します。データベースごとに接続に使用するJDBCドライバが異なります。なお，使用する機能によって接続できるデータベースおよび使用するJDBCドライバが異なります。

サービスプラットフォームから接続できるデータベース，JDBCドライバおよび接続に使用する機能の対応を，次の表に示します。

表7‒2　サービスプラットフォームから接続できるデータベース

データベース

JDBCドライバ

メッセージング機能およびビジネスプロセス機能

DBアダプタ機能

ローカルトランザクション

グローバルトランザクション

ローカルトランザクション

グローバルトランザクション

HiRDB

HiRDB Type4 JDBC Driver

◎

◎

◎

◎

Oracle

Oracle JDBC Thin Driver

○

○

○

○

（凡例）

◎：使用できます。かつ，使用を推奨します。

○：使用できます。

7.3　HiRDBと連携した実行履歴の管理

HiRDBと連携してプロセスインスタンスの実行履歴を管理すると，検索したり削除したりするときの効率化を図れます。

7.3.1　実行履歴の分割格納

データベースにHiRDBを使用する場合で，かつプロセスインスタンスの実行履歴が膨大になる場合は，実行履歴の分割格納をすると，実行履歴を検索したり削除したりするときの効率が向上します。

サービスプラットフォームでは，日付データによる境界値指定のキーレンジ分割が利用できます。また，分割されたデータをさらにプロセスインスタンス識別子によるFIXハッシュ分割で分割するマトリクス分割も利用できます。

なお，マトリクス分割を利用するためには，HiRDB Advanced High Availabilityが必要です。

キーレンジ分割およびFIXハッシュ分割の詳細は，マニュアル「HiRDB システム導入・設計ガイド」の表の横分割の種類に関する説明を参照してください。

マトリクス分割の例として，日付データによる境界値指定のキーレンジ分割とプロセスインスタンス識別子の組み合わせを次の図に示します。

図7‒3　日付データによる境界値指定のキーレンジ分割とプロセスインスタンス識別子を組み合わせたマトリクス分割の例

(1)　日付データによる境界値指定のキーレンジ分割

サービスプラットフォームでは，プロセスインスタンスの実行履歴の管理に関するテーブルの列名（SplitKey）をキーレンジ分割のキーとして利用できます。

DBサーバ内の横分割されたRDエリアに実行履歴を分割して格納することで，RDエリア単位の操作ができます。そのため，実行履歴が膨大になるほど削除効率が向上します。

実行履歴をRDエリア単位で削除する例については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「6.1.4　プロセスインスタンスの実行履歴を削除する」を参照してください。

(2)　プロセスインスタンス識別子によるFIXハッシュ分割

サービスプラットフォームでは，プロセスインスタンスの実行履歴の管理に関するテーブルの列名（ProcessID）をFIXハッシュ分割のキーとして利用できます。

検索条件に分割キーを指定されていると，該当データがあると予測されるRDエリアだけを検索するため，検索効率が向上します。

注意事項

検索条件に分割キーが指定されていない場合，分割したすべてのRDエリアが探索対象となるため，サーバ間の通信が発生する分，分割しなかった場合よりも検索効率が劣化するおそれがあります。

リクエスト処理時に発行されるSQLは，ビジネスプロセスの内容によって異なります。発行されるSQLの詳細は，SQLトレース機能を利用してご確認ください。SQLトレース機能については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(3)　実行履歴を分割するときの注意事項

プロセスインスタンスの実行履歴を分割する場合は，次の点に注意してください。

HCSCサーバがセットアップ済みの環境からは移行できません。

RDエリア単位に実行履歴を削除する場合は，すべてのHCSCサーバの受付を停止させてください。

相関セットの重複チェックを強化してください。相関セットの重複チェックを強化するには，HCSCサーバセットアップ定義ファイルのdb-tbl-split-corcheck-useプロパティの設定をONにしてください。設定をOFFにすると，リクエストが正しく処理されないおそれがあります。db-tbl-split-corcheck-useプロパティの詳細は，マニュアル「サービスプラットフォームリファレンス」の「6.4.3　HCSCサーバセットアップ定義ファイル」を参照してください。

相関セットが同じリクエストを要求した場合，要求したリクエストがすべてエラーになるおそれがあります。相関セットが同じリクエストを要求しないでください。

第2編　設計解説編

8　FTPと連携してファイルを転送する機能（FTP連携）

この章では，FTPと連携してファイルを転送する機能（FTP連携）について説明します。

8.1　FTP連携の概要

FTP（ファイル転送プロトコル）を利用して，さまざまなシステム間のファイル転送を中継する機能をFTP連携といいます。

ここでは，FTP連携の目的および特長について説明します。

8.1.1　FTP連携の目的

FTPを利用した既存のシステムでは，ファイルを転送するシステム同士が個別に連携しています。このため，システムの管理者にとって，システム全体の転送状況（転送経路やデータの種類など）を管理することが困難です。

既存のシステムでFTPによる転送状況を管理する例を次の図に示します。

図8‒1　既存のシステムの例

FTP連携を利用することで，これまで個別に管理していたシステム間の転送状況をサービスプラットフォーム上で一括して管理できるようになります。

サービスプラットフォームを利用したシステムでFTPによる転送状況を管理する例を次の図に示します。

図8‒2　サービスプラットフォームを利用したシステムの例

システム間の転送状況を一括して管理することで，システムの改修時にシステム全体の影響範囲を把握しやすくなるため，改修時のコストを削減できるメリットもあります。

8.1.2　FTP連携の特長

FTP連携には次の特長があります。

FTPによるシステム間の転送状況を管理できます。

ビジネスプロセスのユーザ定義Javaクラスを使用することで，転送状況を把握するために必要な次の情報をログとして取得できます。

システム間の転送経路

転送の開始・終了時刻，および転送に要した時間

転送の頻度

転送のデータ量

FTPを利用したさまざまなシステムと連携できます。

既存のシステムと接続してファイルの送受信を中継できます。システム間でファイル形式や扱う文字コードが異なる場合，レイアウト・文字コード変換の機能を利用して対応することができます。接続するFTPクライアントおよびFTPサーバに対してソフトウェアの追加は不要です。

8.2　FTP連携を利用するためのシステムの構成

FTPによるファイル転送では，FTPクライアントがFTPサーバに転送を要求し，ファイルをアップロードしたりダウンロードしたりします。このマニュアルでは，転送を要求する側のシステムをFTPクライアント，転送要求を受け付ける側のシステムをFTPサーバと呼びます。

FTP連携を利用するための，FTPサーバ，FTPクライアント，およびサービスプラットフォーム内のシステムの構成を次に示します。

図8‒3　FTP連携を利用するためのシステムの構成

システムを構成する要素について説明します。

FTPインバウンドアダプタ

FTPクライアントからの要求の処理や，FTPクライアントの認証，ファイルのデータ転送処理などを行うためのリソースアダプタです。FTPクライアントからの要求はFTPインバウンドアダプタを経由してFTP受付に送られます。

FTP受付

FTPクライアントからの要求を受け付けるためのインターフェースです。FTPクライアントとビジネスプロセスとの間でファイルの送受信を行います。

ビジネスプロセス

ファイル操作アダプタやFTPアダプタを呼び出すためのアクティビティを定義します。

ファイル操作アダプタ

ファイルのレイアウト変換や文字コード変換，複製，削除などのファイル操作を行うためのアダプタです。

FTPアダプタ

FTPサーバと接続してファイルの送受信を行うためのアダプタです。

8.3　FTP連携を利用したファイル転送パターンの例

FTP連携を利用して実現できるファイル転送パターンには，次の種類があります。

FTPクライアントからFTPサーバへのファイル転送

FTPサーバからFTPクライアントへのファイル転送

FTPクライアントから別のFTPクライアントへのファイル転送

FTPサーバのファイルリストの取得

各ファイル転送パターンは，ビジネスプロセス，FTP受付，FTPアダプタ，およびファイル操作アダプタを組み合わせることで実現できます。

ここでは，各ファイル転送パターンの特長，およびファイル転送の流れについて説明します。

8.3.1　FTPクライアントからFTPサーバへのファイル転送

この転送パターンでは，転送コマンドのSTORコマンドまたはAPPEコマンドを使用して，FTPクライアントからFTPサーバにファイルを送信します。

この転送パターンには次の2種類があります。

同期型ビジネスプロセスを利用する場合

FTPサーバへのファイル転送が完了してからFTPクライアントに応答を返す転送パターンです。

この転送パターンでは，FTP連携を利用しない場合と同様に，FTPクライアントとFTPサーバの処理の状態を同期させることができます。

非同期型ビジネスプロセスを利用する場合

FTPクライアントに応答を返してからFTPサーバにファイルを送信する転送パターンです。

この転送パターンでは，FTPクライアントから見た応答時間が短縮されるため，次の場合に活用できます。

ある拠点から複数の拠点に対して同じ情報を同報送信する場合

FTPクライアントの無通信監視時間を超えるような大規模ファイルを送信する場合

それぞれのファイル転送の流れを次に示します。

(1)　同期型ビジネスプロセスを利用したファイル転送の流れ

ファイル転送の流れを次の図に示します。

図8‒4　FTPクライアントからFTPサーバへのファイル転送の流れ（同期型ビジネスプロセスを利用する場合）

図中の制御，転送データ，およびビジネスプロセスの流れについて説明します。次の番号は，図中の番号と対応しています。

FTPクライアントが転送コマンド（STORコマンドまたはAPPEコマンド）を実行します。

転送コマンドを受け取ったFTPインバウンドアダプタがFTP受付を呼び出します。

FTP受付が作業フォルダ（HCSCサーバ上でファイルを扱うための一時的なフォルダ）を作成します。

FTPクライアントから転送されたファイルのデータが，作業フォルダ内に中間ファイルとして出力されます。

FTP受付がビジネスプロセスを呼び出します。このとき，FTPクライアントから受け取った転送コマンドや中間ファイルのファイル名などの情報は，要求電文に格納されてビジネスプロセスに渡されます。

ビジネスプロセスからファイル操作アダプタが呼び出されたあと，ファイル操作アダプタは作業フォルダ内の中間ファイルを読み込んで，レイアウト変換やコード変換などの処理をします。

ビジネスプロセスからFTPアダプタが呼び出されたあと，FTPアダプタは中間ファイルのデータをFTPサーバに転送します。

ビジネスプロセスで応答アクティビティが実行されたあと，FTP受付に応答電文が渡されます。

FTP受付が作業フォルダおよび作業フォルダ中の中間ファイルを削除します。

FTP受付からFTPインバウンドアダプタに応答を返します。

応答を受け取ったFTPインバウンドアダプタは，転送コマンドの実行結果をFTPクライアントに返します。

(2)　非同期型ビジネスプロセスを利用したファイル転送の流れ

ファイル転送の流れを次の図に示します。

図8‒5　FTPクライアントからFTPサーバへのファイル転送の流れ（非同期型ビジネスプロセスを利用する場合）

図中の制御，転送データ，およびビジネスプロセスの流れについて説明します。次の番号は，図中の番号と対応しています。

FTPクライアントが転送コマンド（STORコマンドまたはAPPEコマンド）を実行します。

転送コマンドを受け取ったFTPインバウンドアダプタがFTP受付を呼び出します。

FTP受付が作業フォルダを作成します。

FTPクライアントから転送されたファイルのデータが，作業フォルダ内に中間ファイルとして出力されます。

FTP受付がビジネスプロセスを呼び出します。このとき，FTPクライアントから受け取った転送コマンドや中間ファイルのファイル名などの情報は，要求電文に格納されてビジネスプロセスに渡されます。

ビジネスプロセスで応答アクティビティが実行されたあと，FTP受付に応答電文が渡されます。

FTP受付からFTPインバウンドアダプタに応答を返します。

応答を受け取ったFTPインバウンドアダプタは，転送コマンドの実行結果をFTPクライアントに返します。

ビジネスプロセスからファイル操作アダプタAが呼び出されたあと，ファイル操作アダプタAは作業フォルダ内の中間ファイルを読み込んで，レイアウト変換やコード変換などの処理をします。

ビジネスプロセスからFTPアダプタが呼び出されたあと，FTPアダプタは中間ファイルのデータをFTPサーバに転送します。

ビジネスプロセスからファイル操作アダプタBが呼び出されたあと，ファイル操作アダプタBはビジネスプロセスが終了する前に作業フォルダおよび作業フォルダ中の中間ファイルを削除します。

8.3.2　FTPサーバからFTPクライアントへのファイル転送

この転送パターンでは，FTPクライアントから転送コマンドのRETRコマンドを使用して，FTPサーバからFTPクライアントにファイルを送信します。

この転送パターンでは中間ファイルの格納先に作業フォルダと共通フォルダが利用できます。

それぞれのファイル転送の流れを次に示します。

(1)　作業フォルダを利用したファイル転送の流れ

ファイル転送の流れを次の図に示します。

図8‒6　FTPサーバからFTPクライアントへのファイル転送の流れ（作業フォルダを利用する場合）

図中の制御，転送データ，およびビジネスプロセスの流れについて説明します。次の番号は，図中の番号と対応しています。

FTPクライアントが転送コマンド（RETRコマンド）を実行します。

転送コマンドを受け取ったFTPインバウンドアダプタがFTP受付を呼び出します。

FTP受付が作業フォルダを作成します。

FTP受付がビジネスプロセスを呼び出します。このとき，FTPクライアントから受け取った情報（転送コマンドなど）は，要求電文に格納されてビジネスプロセスに渡されます。

ビジネスプロセスからFTPアダプタが呼び出されたあと，FTPアダプタはFTPサーバからファイルを取得し，作業フォルダ内に中間ファイルとして出力します。

ビジネスプロセスからファイル操作アダプタが呼び出されたあと，ファイル操作アダプタは作業フォルダ内の中間ファイルを読み込んで，レイアウト変換やコード変換などの処理をします。

ビジネスプロセスで応答アクティビティが実行されたあと，FTP受付に中間ファイルの情報を含んだ応答電文が渡されます。

応答電文で示された中間ファイルのデータが，作業フォルダからFTPクライアントに転送されます。

FTP受付が作業フォルダおよび作業フォルダ中の中間ファイルを削除します。

FTP受付からFTPインバウンドアダプタに応答を返します。

応答を受け取ったFTPインバウンドアダプタは，FTPクライアントに転送コマンドの実行結果を返します。

(2)　共通フォルダを利用したファイル転送の流れ

ファイル転送の流れを次の図に示します。

図8‒7　FTPサーバからFTPクライアントへのファイル転送の流れ（共通フォルダを利用する場合）

図中の制御，転送データ，およびビジネスプロセスの流れについて説明します。次の番号は，図中の番号と対応しています。

FTPクライアントが転送コマンド（RETRコマンド）を実行します。

転送コマンドを受け取ったFTPインバウンドアダプタがFTP受付を呼び出します。

FTP受付がビジネスプロセスを呼び出します。このとき，FTPクライアントから受け取った情報（転送コマンドなど）は，要求電文に格納されてビジネスプロセスに渡されます。

ビジネスプロセスからFTPアダプタが呼び出されたあと，FTPアダプタはFTPサーバからファイルを取得し，共通フォルダ内に中間ファイルとして出力します。

ビジネスプロセスからファイル操作アダプタが呼び出されたあと，ファイル操作アダプタは共通フォルダ内の中間ファイルを読み込んで，変換処理（レイアウト変換やコード変換など）をします。

ビジネスプロセスで応答アクティビティが実行されたあと，FTP受付に中間ファイルの情報を含んだ応答電文が渡されます。

応答電文で示された中間ファイルのデータが，共通フォルダからFTPクライアントに転送されます。

FTP受付からFTPインバウンドアダプタに応答を返します。

応答を受け取ったFTPインバウンドアダプタは，FTPクライアントに転送コマンドの実行結果を返します。

8.3.3　FTPクライアントから別のFTPクライアントへのファイル転送

1対1または1対複数のFTPクライアント間でファイルを送受信する転送パターンについて説明します。

この転送パターンでは，ファイルの送信側と受信側のシステムが任意のタイミングでHCSCサーバにアクセスできるため，海外拠点のように運用時間帯が異なるシステム間でファイル転送を行う場合に活用できます。

ファイル転送の流れを次の図に示します。

この図では，FTPクライアントAからSTORコマンドまたはAPPEコマンドを実行してHCSCサーバにファイルを送信（図中の番号1.〜11.）したあと，FTPクライアントBからRETRコマンドを実行してHCSCサーバ内のファイルを取得（図中の番号12.〜23.）しています。

図8‒8　FTPクライアントから別のFTPクライアントへのファイル転送の流れ

図中の制御，転送データ，およびビジネスプロセスの流れについて説明します。次の番号は，図中の番号と対応しています。

FTPクライアントAが転送コマンド（STORコマンドまたはAPPEコマンド）を実行します。

転送コマンドを受け取ったFTPインバウンドアダプタがFTP受付Aを呼び出します。

FTP受付Aが作業フォルダAを作成します。

FTPクライアントAから転送されたファイルのデータが，作業フォルダA内に中間ファイルとして出力されます。

FTP受付AがビジネスプロセスAを呼び出します。このとき，FTPクライアントAから受け取った転送コマンドや中間ファイルのファイル名などの情報は，要求電文に格納されてビジネスプロセスAに渡されます。

ビジネスプロセスAからファイル操作アダプタAが呼び出され，作業フォルダAの中間ファイルにアクセスします。

ファイル操作アダプタAは，作業フォルダA内の中間ファイルを共通フォルダ（ユーザが作成する任意のフォルダ）内に複製します。

ビジネスプロセスAで応答アクティビティが実行されたあと，FTP受付Aに応答電文が渡されます。

FTP受付Aが作業フォルダAおよび作業フォルダA内の中間ファイルを削除します。

FTP受付AからFTPインバウンドアダプタに応答を返します。

応答を受け取ったFTPインバウンドアダプタは，転送コマンドの実行結果をFTPクライアントAに返します。

FTPクライアントBが転送コマンド（RETRコマンド）を実行します。

転送コマンドを受け取ったFTPインバウンドアダプタがFTP受付Bを呼び出します。

FTP受付Bが作業フォルダBを作成します。

FTP受付BがビジネスプロセスBを呼び出します。このとき，FTPクライアントBから受け取った転送コマンドなどの情報は，要求電文に格納されてビジネスプロセスBに渡されます。

ビジネスプロセスBからファイル操作アダプタBが呼び出され，共通フォルダ内のファイルにアクセスします。

ファイル操作アダプタBは，共通フォルダ内のファイルを作業フォルダBに複製します。

ビジネスプロセスBからファイル操作アダプタCが呼び出されたあと，ファイル操作アダプタCは，作業フォルダB内の中間ファイルを読み込んで，レイアウト変換やコード変換などの処理をします。

ビジネスプロセスBで応答アクティビティが実行されたあと，FTP受付Bに中間ファイルの情報を含んだ応答電文が渡されます。

応答電文で示された中間ファイルのデータがFTPインバウンドアダプタからFTPクライアントBに転送されます。

FTP受付Bは，作業フォルダBおよび作業フォルダB内の中間ファイルを削除します。

FTP受付BからFTPインバウンドアダプタに応答を返します。

応答を受け取ったFTPインバウンドアダプタは，FTPクライアントBに転送コマンドの実行結果を返します。

8.3.4　FTPサーバのファイルリストの取得

この転送パターンでは，FTPクライアントまたはサービスリクエスタからリストコマンドを使用して，FTPサーバのファイルリストを取得しています。

(1)　ファイルリストを作業フォルダに出力する場合

FTPサーバから取得したファイルリストやファイル操作アダプタで取得した共通フォルダ内のファイルリストを作業フォルダに出力して，FTPクライアントに送信する例について説明します。

図8‒9　FTPサーバのファイルリストの取得の流れ（作業フォルダに出力する場合）

図中の制御，リストデータ，およびビジネスプロセスの処理の流れについて説明します。次の番号は，図中の番号と対応しています。

FTPクライアントがリストコマンドを実行します。

リストコマンドを受け取ったFTPインバウンドアダプタがFTP受付を呼び出します。

FTP受付が作業フォルダを作成します。

FTP受付がビジネスプロセスを呼び出します。このとき，FTPクライアントから受け取ったFTPコマンドの情報などは，要求電文に格納されてビジネスプロセスに渡されます。

ビジネスプロセスからFTPアダプタが呼び出されたあと，FTPアダプタはFTPサーバからファイルリストを取得し，作業フォルダ内に中間ファイルとして出力します。

ビジネスプロセスからファイル操作アダプタが呼び出されたあと，ファイル操作アダプタは作業フォルダ内の中間ファイルを読み込んで，レイアウト変換やコード変換などの処理をします。共通フォルダ内のファイルリストを取得する場合は，ファイル操作アダプタのファイル一覧書き込みオペレーションでファイルリストを作業フォルダ内に中間ファイルとして出力します（ファイル一覧書き込みオペレーションの詳細は，「8.7.10　ファイル一覧書き込みオペレーション」を参照してください）。

ビジネスプロセスで応答アクティビティが実行されたあと，FTP受付に中間ファイルの情報を含んだ応答電文が渡されます。

応答電文で示された中間ファイルのデータが，作業フォルダからFTPクライアントに転送されます。

FTP受付が作業フォルダおよび作業フォルダ中の中間ファイルを削除します。

FTP受付からFTPインバウンドアダプタに応答を返します。

応答を受け取ったFTPインバウンドアダプタは，FTPクライアントにリストコマンドの実行結果を返します。

(2)　ファイルリストを応答電文に出力する場合

FTPサーバから取得したファイルリストを応答電文に出力して，ビジネスプロセスで処理する例について説明します。

図8‒10　FTPサーバのファイルリストの取得の流れ（応答電文に出力する場合）

図中の制御，リストデータ，およびビジネスプロセスの処理の流れについて説明します。次の番号は，図中の番号と対応しています。

サービスリクエスタがリストコマンドを要求するリクエストを実行します。

標準受付（Webサービス）がビジネスプロセスを呼び出します。このとき，サービスリクエスタから受け取ったFTPコマンドの情報などは，要求電文に格納されてビジネスプロセスに渡されます。

ビジネスプロセスからFTPアダプタもしくはファイル操作アダプタを呼び出します。ファイル操作アダプタの場合は，ファイル一覧取得オペレーションで共通フォルダ内のファイルリストを応答電文に格納します（ファイル一覧取得オペレーションの詳細は，「8.7.9　ファイル一覧取得オペレーション」を参照してください）。

3.で呼び出したアダプタはFTPサーバからファイルリストを取得したあと，メモリに保持して応答電文に格納します。

3.で呼び出したアダプタの応答電文のリストデータをJava呼出アクティビティなどの要求電文で取得し，解析します。

ビジネスプロセスから標準受付（Webサービス）に応答電文を返します。

標準受付（Webサービス）はサービスリクエスタに応答を返します。

8.4　FTP受付の機能

ここでは，FTP受付の目的，およびFTP受付を利用したファイル送受信の概要について説明します。

FTP受付とは，FTPクライアントからFTPインバウンドアダプタを経由して接続を受け付け，ビジネスプロセスを呼び出したり，FTPクライアントとビジネスプロセスの間で送受信されるファイルのデータやファイルの一覧情報を仲介したりするインターフェースです。

ビジネスプロセスから呼び出されるファイル操作アダプタやFTPアダプタと連携して動作することによって，ビジネスプロセスを介したFTPクライアントとFTPサーバ間のファイル転送，およびファイルの一覧情報取得を実現できます。

FTPサーバへファイルを転送する場合を例にFTP受付を使用したFTP連携の流れを次の図に示します。

図8‒11　FTP受付を使用したFTP連携の流れ

8.4.1　FTP受付でサポートするオペレーションとFTPコマンド

FTP受付では，ファイルに対する操作の単位をオペレーションと呼びます。

FTP受付でサポートするオペレーションには，次の種類があります。

PUTオペレーション

FTPクライアント側からFTPサーバ側へファイルを転送するオペレーションです。

GETオペレーション

FTPサーバ側からFTPクライアント側へファイルを転送するオペレーションです。

GETINFOオペレーション

FTPサーバ側のファイル一覧情報を取得してFTPクライアント側へ送付するオペレーションです。

FTPクライアントからFTPインバウンドアダプタに対してFTPコマンドが呼び出された場合に，これらのオペレーションがFTPインバウンドアダプタから呼び出されます。

注意事項

1つのビジネスプロセスに対して複数のFTP受付を関連づける場合，これらのFTP受付にはすべて同じオペレーションを選択してください。異なるオペレーションのFTP受付を1つのビジネスプロセスに複数定義した場合は，動作を保証しません。

(1)　FTP受付でサポートするオペレーションとFTPコマンドの種類

FTP受付でサポートするFTPコマンドを次の表に示します。

表8‒1　FTP受付でサポートするFTPコマンド

FTPコマンド

用途

呼び出されるFTP受付のオペレーション

STOR

ファイルの内容をサーバ側のファイルに蓄積します。すでにサーバにファイルが存在する場合，既存のファイルの内容は上書きされます。

PUTオペレーション

APPE

ファイルの内容をサーバ側のファイルに蓄積します。すでにサーバにファイルが存在する場合，転送したデータが既存のファイルに追加されます。

RETR

サーバ側に存在するファイルの複製を取得します。

GETオペレーション

LIST

サーバ側に存在するファイルの情報の一覧を取得します。

GETINFOオペレーション

NLST

サーバ側に存在するファイルの名前の一覧を取得します。

SITE CSCTHR

転送コマンド実行前，転送コマンド実行後，リストコマンド実行前，またはリストコマンド実行後にビジネスプロセスで実行するFTPコマンドを設定します。

FTPクライアントが転送コマンドまたはリストコマンドを実行する前にこのコマンドを実行しておくと，そのあとに実行した転送コマンドまたはリストコマンドの情報とともに，このコマンドで指定した情報がビジネスプロセスに渡されます。

−

（凡例）

−：呼び出されるオペレーションはありません。

(2)　FTPコマンドの実行形式と注意事項

FTPコマンドの実行形式と注意事項を次に示します。

実行形式

<FTPコマンド> /<FTP受付の受付ID>/<リモートファイルパス>

注意事項

FTP受付の受付IDの先頭に指定する記号およびリモートファイルパスに指定する区切り文字は必ずスラッシュ（/）を指定してください。

転送コマンドの引数の指定についての制限はFTPプロトコルの仕様に従ってください。

8.4.2　FTP受付で使用できる通信モデルおよびビジネスプロセス

ここでは，FTP受付で使用できる通信モデルおよびビジネスプロセスの型について説明します。

(1)　FTP受付で使用できる通信モデル

FTP受付で使用できる通信モデルは，同期通信です。

(2)　FTP受付で使用できるビジネスプロセス

FTP受付と関連づけられるビジネスプロセスは，同期型，および非同期型の2種類です。それぞれのビジネスプロセスの特徴を次の表に示します。

表8‒2　ビジネスプロセスの特徴

ビジネスプロセスの型

特徴

備考

同期型

FTP受付から呼び出されたビジネスプロセスが，目的の処理を完了したあとに応答を返します。応答を返したあとに実行するアクティビティはありません。

オペレーションの種別やファイル連携方式に関係なく使用できます。

非同期型

FTP受付から呼び出されたビジネスプロセスが，目的の処理を完了する前に応答を返します。応答を返したあとに実行するアクティビティはあります。

ビジネスプロセスのうち，非同期に実行される処理（FTP受付に応答を返したあとに実行される処理）で，GETオペレーションおよびGETINFOオペレーションに関する処理は実行できません。

8.4.3　FTP受付使用時のトランザクション

FTPインバウンドアダプタにはトランザクションでFTP受付以降の処理に引き継ぐ情報がありません。そのため，FTP受付では，FTPインバウンドアダプタのトランザクションとは異なる新たなトランザクションを開始します。ただし，ビジネスプロセス内ではさらにFTP受付と異なる新たなトランザクションが開始されます。

新たなトランザクションが開始されるタイミングは，FTP受付のタイムアウトの監視をする場合としない場合とで異なります。

FTP受付のタイムアウトの監視の詳細は，「8.4.9　タイムアウトの監視」を参照してください。

(1)　FTP受付のトランザクション（タイムアウトの監視をしない場合）

FTP受付のタイムアウトの監視をしない場合で，ビジネスプロセスを呼び出すときのFTP受付のトランザクションを次に示します。

図8‒12　FTP受付のトランザクション（タイムアウトの監視をしない場合）

なお，ビジネスプロセス内でFTPアダプタを使用してサーバ側にファイルを転送する場合，サーバ側へのファイル転送が完了したあとにビジネスプロセスの処理でエラーが発生すると，トランザクションはロールバックされて，FTPクライアント側にエラーが返ります。ただし，サーバ側のファイルは転送後の状態のままとなり，転送前の状態に戻されません。

(2)　FTP受付のトランザクション（タイムアウトの監視をする場合）

FTP受付のタイムアウトの監視をする場合，異なるスレッドでビジネスプロセスが呼び出されるため，HCSCメッセージ配送制御で新たなトランザクションが開始します。FTP受付のタイムアウトの監視をする場合で，ビジネスプロセスを呼び出すときのFTP受付のトランザクションを次に示します。

図8‒13　FTP受付のトランザクション（タイムアウトの監視をする場合）

HCSCメッセージ配送制御で開始するトランザクションは，J2EEサーバのトランザクションタイムアウトの値で監視されます。トランザクションタイムアウトの設定については，マニュアル「アプリケーションサーバ システム設計ガイド」の「8.6.4　トランザクションタイムアウトを設定する」を参照してください。

なお，FTP受付のタイムアウト値を設定する場合，J2EEサーバのトランザクションタイムアウトの値よりも大きい値を設定することを推奨します。

8.4.4　リクエストIDの生成

FTP受付は，FTPクライアントからのリクエストを受け付けると，リクエストごとにリクエストIDを生成します。ビジネスプロセスの処理は，生成したリクエストIDを指定して実行されます。

リクエストIDは次の形式で生成されます。

<受付ID><FTPクライアントのIPアドレス><日付><時刻><追番><分割キー><HCSCサーバ名>

リクエストIDのそれぞれの項目について次の表に示します。

表8‒3　リクエストIDの項目

項目

桁数

内容

<受付ID>

8桁

FTP受付の設定で指定した受付IDです。受付IDが8桁に満たない場合は，受付IDの右側に足りない分の「-」が設定されます。

<FTPクライアントのIPアドレス>

IPv4の場合：12桁

IPv6の場合：32桁

要求元のFTPクライアントのIPアドレスです。IPv4アドレスのそれぞれのバイトが3桁に満たない場合は，それぞれのバイトの左側に足りない分の「0」が設定されます。IPv6アドレスはそれぞれのバイトが4桁に満たない場合は，それぞれのバイトの左側に足りない分の「0」が設定されます。英字は小文字で表記されます。

<日付>

8桁

FTP受付がリクエストを受け付けた日付がyyyymmddの形式で設定されます。

yyyy：西暦年

mm：月

dd：日

<時刻>

9桁

FTP受付がリクエストを受け付けた時刻がhhmmssSSSの形式で設定されます。

hh：時

mm：分

ss：秒

SSS：ミリ秒

<追番>

3桁

フォルダ名を一意にするための整数値が「000」からの連番で設定されます。<日付><時刻><追番>がすでにあるリクエストIDと重複する場合は追番を1つ繰り上げます。

「001」から「999」までのどの整数値を設定しても重複する場合，<日付>および<時刻>を変更して追番には「000」を設定します。

<分割キー>

1桁

HCSCサーバ名が付加されていることを示す分割キーです。半角スラッシュ（/），半角アットマーク（@）または半角ピリオドが使用されます。

HCSCサーバランタイム定義ファイルで変更可能です。

詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

<HCSCサーバ名>

最大8桁

FTP受付が配備されているHCSCサーバの名称です。HCSCサーバ名が8桁に満たない場合，不足分は補われません。

8.4.5　作業フォルダと中間ファイルの作成

FTP受付は，ビジネスプロセスとの間のファイルデータを受け渡すために，FTPクライアントから送られてきたファイルのデータやファイルの一覧情報を一時的に格納する中間ファイルを作成します。また，中間ファイルは，リクエストごとにFTP受付が生成する作業フォルダに格納されます。

作業フォルダを作成するディレクトリはHCSCサーバランタイム定義ファイルのwork-folderプロパティで設定してください。詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

なお，作業フォルダと作業フォルダに格納された中間ファイルは，次の条件を満たした場合に削除されます。

FTP受付定義ファイルのurecp-ftp.work-dir.auto-deleteプロパティの値が「true」である。

FTP受付がビジネスプロセスを呼び出して，呼び出したビジネスプロセスから，<success>タグの値がtrueの応答電文を受け取った。

FTP受付とFTPインバウンドアダプタの間のデータ（ファイルの内容やリストデータ）の受け渡しが正常に終了した。または，GETINFOオペレーションの応答電文の<reply-code>の値が400〜599の値である。

上記の条件を満たしていない場合や，プロセスが異常終了した場合およびcscpireexecコマンド（プロセスインスタンスの再実行）などでビジネスプロセスを再実行した場合は，作業フォルダおよび作業フォルダ内の中間ファイルが自動で削除されません。FTP受付が作業フォルダを削除できなかった場合，次の方法で作業フォルダと中間ファイルを削除してください。

FTP受付定義ファイルのurecp-ftp.work-dir.auto-deleteプロパティの値が「false」の場合

ビジネスプロセスが実行する最後の処理でファイル操作アダプタを呼び出して作業フォルダと中間ファイルを削除してください。または，cscfswlsコマンドで作業フォルダを参照し，削除対象かどうか確認したあと，cscfswrmコマンドで作業フォルダを削除してください。

FTP受付定義ファイルのurecp-ftp.work-dir.auto-deleteプロパティの値が「true」の場合

cscfswlsコマンドで作業フォルダを参照し，削除対象かどうか確認したあと，cscfswrmコマンドで作業フォルダを削除してください。

詳細は，マニュアル「サービスプラットフォーム リファレンス」の「cscfswls（作業フォルダの参照）」または「cscfswrm（作業フォルダの削除）」を参照してください。

共通フォルダ内のファイルを中間ファイルとして使用する場合も，リクエストを受け付けた時点で作業フォルダが作成されます。自動で削除されなかった作業フォルダについては，cscfswrmコマンドで作業フォルダを削除してください。

8.4.6　ビジネスプロセスのアクセス制御

ここでは，FTP受付の機能として，ビジネスプロセスのアクセス制御と，転送前または転送後に実行するFTPコマンドの管理について説明します。

FTP受付は，ビジネスプロセスへのアクセスを許可および禁止するユーザを設定することで，ビジネスプロセスへのアクセスをユーザごとに制御できます。

ビジネスプロセスのアクセス制御の設定は，FTP実行許可リスト定義ファイルで設定できます。FTP受付は，FTP実行許可リスト定義ファイルの設定内容を基に，FTPクライアントからアクセスしてきたユーザに対してビジネスプロセスのアクセスを許可するかどうかを判断して，許可する場合にだけビジネスプロセスを呼び出し，許可しない場合はビジネスプロセスを呼び出さずにエラーを返します。

ビジネスプロセスのアクセス制御の流れを次の図に示します。

図8‒14　ビジネスプロセスのアクセス制御の流れ

この図では，FTP実行許可リスト定義ファイルで許可されているユーザAからのリクエストはビジネスプロセスを呼び出していますが，FTP実行許可リスト定義ファイルで許可されていないユーザBのリクエストに対しては，ビジネスプロセスを呼び出さずにエラーを返しています。

FTP実行許可リスト定義ファイルで設定する内容を次の表に示します。

表8‒4　FTP実行許可リスト定義ファイルで設定する内容

内容

指定方法

デフォルト値

FTP受付が関連づいたビジネスプロセスへのアクセスを許可するユーザ

urecp-ftp.permission.allowプロパティでユーザ名を指定します。

複数のユーザを指定する場合は，ユーザ名とユーザ名の間をコンマ（,）で区切ってください。

アスタリスク（*）を指定した場合は，すべてのユーザのアクセスを許可します。

*

FTP受付が関連づいたビジネスプロセスのアクセスを許可しないユーザ

urecp-ftp.permission.denyプロパティでユーザ名を指定します。

複数のユーザを指定する場合は，ユーザ名とユーザ名の間をコンマ（,）で区切ってください。

なし

注

両方に同じユーザが指定されている場合，アクセスを許可しない設定が優先されます。

なお，FTP実行許可リスト定義ファイルは，任意のファイル名で任意のフォルダに格納できますが，FTP実行許可リスト定義ファイルの絶対パスをFTP受付コンフィグファイルに指定する必要があります。FTP受付コンフィグファイルにFTP実行許可リスト定義ファイルの絶対パスが指定されていない場合は，すべてのユーザに対してビジネスプロセスへのアクセスが許可されます。

また，FTP実行許可リスト定義ファイルの内容を変更した場合，変更したFTP許可リスト定義ファイルを使用しているFTP受付を再起動する必要があります。

詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.7　FTP実行許可リスト定義ファイル」または「6.8.5　FTP受付コンフィグファイル」を参照してください。

8.4.7　転送前／転送後またはリスト前／リスト後に実行するFTPコマンドの管理

SITE CSCTHRコマンドを実行することによって，転送コマンド実行前，転送コマンド実行後，リストコマンド実行前，またはリストコマンド実行後にビジネスプロセスで実行するFTPコマンドを設定できます。FTPクライアントが転送コマンドまたはリストコマンドを実行する前にSITE CSCTHRコマンドを実行しておくと，そのあとに実行したFTPコマンドの情報とともに，SITE CSCTHRコマンドで指定した情報がビジネスプロセスに渡されます。

SITE CSCTHRコマンドの実行形式を次に示します。

実行形式

SITE CSCTHR {-B｜-A} <FTPコマンド>[;<FTPコマンド> …]

FTPコマンド以外の，FTPサーバが独自にサポートしているコマンドを指定する場合は，次のように<FTPコマンド>の部分にSITEコマンドを指定して，SITEコマンドの引数にコマンドを指定してください。

SITE CSCTHR {-B｜-A} SITE <FTPサーバが独自にサポートしているコマンド>

また，オプションに-B，または-Aを指定することで，指定したFTPコマンドを転送コマンド実行前／リストコマンド実行前に実行するか，または転送コマンド実行後／リストコマンド実行後に実行するかを設定できます。

-Bオプションを使用した場合の動作

「<FTPコマンド>[;<FTPコマンド> …]」の部分に指定したFTPコマンドが，FTP受付の要求電文の<ftp-commands-before>タグに設定されます。この形式で指定したFTPコマンドは，転送コマンド実行前またはリストコマンド実行前に実行されます。SITE CSCTHRコマンドをこの形式で複数回実行した場合，「<FTPコマンド>[;<FTPコマンド> …]」の部分がSITE CSCTHRコマンドを実行した順番にセミコロン（;）で接続されて<ftp-commands-before>タグに追加されます。

-Aオプションを使用した場合の動作

「<FTPコマンド>[;<FTPコマンド> …]」の部分に指定したFTPコマンドが，FTP受付の要求電文の<ftp-commands-after>タグに設定されます。この形式で指定したFTPコマンドは，転送コマンド実行後またはリストコマンド実行後に実行されます。SITE CSCTHRコマンドをこの形式で複数回実行した場合，「<FTPコマンド>[;<FTPコマンド> …]」の部分がSITE CSCTHRコマンドを実行した順番にセミコロン（;）で接続されて<ftp-commands-after>タグに追加されます。

また，転送コマンド実行前，転送コマンド実行後，リストコマンド実行前，またはリストコマンド実行後にビジネスプロセスで実行を許可するコマンドは，FTPコマンド許可リスト定義ファイル（FTP受付用）に指定して管理できます。FTPコマンド許可リスト定義ファイル（FTP受付用）に指定されていないFTPコマンドがSITE CSCTHRコマンドに含まれていても，FTP受付の要求電文の<ftp-commands-before>タグ，または<ftp-commands-after>タグに追加されません。その場合，ビジネスプロセスが呼び出されないため，エラーが発生します。

なお，FTPコマンド許可リスト定義ファイル（FTP受付用）は，任意のファイル名で任意のフォルダに格納できますが，FTPコマンド許可リスト定義ファイル（FTP受付用）の絶対パスをFTP受付コンフィグファイルに指定する必要があります。FTP受付コンフィグファイルにFTPコマンド許可リスト定義ファイル（FTP受付用）の絶対パスが指定されていない場合は，すべてのFTPコマンドに対してビジネスプロセスでの実行が禁止されます。

またFTPコマンド許可リスト定義ファイル（FTP受付用）の内容を変更した場合，変更したFTPコマンド許可リスト定義ファイル（FTP受付用）を使用しているFTP受付を再起動する必要があります。

FTPコマンド許可リスト定義ファイル（FTP受付用）で編集できる定義内容については，マニュアル「サービスプラットフォーム リファレンス」の「6.8.6　FTPコマンド許可リスト定義ファイル」を参照してください。

8.4.8　リストコマンドオプションの設定によるLIST／NLSTコマンドの実行

LISTコマンドまたはNLSTコマンドの引数オプションをリストコマンドオプション定義ファイルで定義しておくことで，引数オプションを指定してリストコマンドを実行できます。

引数オプションを指定した場合のコマンドの実行形式を次に示します。

LISTコマンドの場合

LIST [ <オプション>][ <パス>]

NLSTコマンドの場合

NLST [ <オプション>][ <パス>]

リストコマンドオプション定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.9　リストコマンドオプション定義ファイル」を参照してください。

リストコマンドオプション定義ファイルは，任意のパスに任意のファイル名で保持できます。ただし，リストコマンドオプション定義ファイルの絶対パスがFTP受付コンフィグファイルで指定されている必要があります。

FTP受付コンフィグファイルについては，マニュアル「サービスプラットフォーム リファレンス」の「6.8.5　FTP受付コンフィグファイル」を参照してください。

リストコマンドオプション定義ファイルに引数オプションを指定した場合，FTPクライアントからリストコマンドが実行されたとき，リストコマンドの引数に指定された情報がリストコマンドオプション定義ファイルの定義に従って<オプション>と<パス>に分割され，GETINFOオペレーションの要求電文の<getinfo-option>と<getinfo-path>に設定されます。

リストコマンドオプション定義ファイルに引数オプションの指定がない場合，またはFTP受付コンフィグファイルでリストコマンドオプション定義ファイルのパスが指定されていない場合，リストコマンドの引数で指定された情報は，すべて<パス>の情報として要求電文の<getinfo-path>に設定されます。

リストコマンドオプション定義ファイルの設定を変更した場合，設定を有効にするには，リストコマンドオプション定義ファイルに関連づけられたFTP受付を再起動する必要があります。

8.4.9　タイムアウトの監視

FTP受付コンフィグファイルのurecp-ftp.request-timeoutにタイムアウト値を設定することで，ビジネスプロセスに要求電文を渡してから応答電文が返ってくるまでの処理時間を監視できます。設定した時間を経過しても応答が返ってこない場合，障害としてタイムアウト例外が発生します。

なお，デフォルトではFTP受付のタイムアウトの監視をしません。

FTP受付でタイムアウトを監視するとき，HCSCメッセージ配送制御内部にFTP受付単位でスレッドが生成されます。タイムアウトの監視に使われるスレッドのうち，受付起動時に生成されて常駐するスレッドの数（常駐スレッド数）は，FTP受付コンフィグファイルのurecp-ftp.resident-thread.countプロパティで設定できます。

常駐スレッド数を超える数のタスクを受け付けた場合，タスクを処理する際にスレッドが一時的に追加生成されます。追加生成されたスレッドは，タスク処理後に300秒間待機状態となり，次のタスクが来なければ破棄されます。

FTP受付のタイムアウトを監視するために生成されるスレッドの最大数（常駐スレッド数＋追加生成されたスレッド数）は，FTP受付コンフィグファイルのurecp-ftp.timer-thread.maximumプロパティで設定できます。なお，常駐スレッド数と最大スレッド数を同じ値に設定した場合，スレッドは追加生成されません。

FTP受付コンフィグファイルで設定できるプロパティの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.5　FTP受付コンフィグファイル」を参照してください。

8.4.10　共通フォルダと中間ファイルの作成

FTP受付は，共通フォルダ内のファイルを中間ファイルとして使用することができます。

(1)　共通フォルダにアクセスできるオペレーション

共通フォルダ内のファイルにアクセスできるのは，GETオペレーションだけです。PUTオペレーションおよびGETINFOオペレーションは共通フォルダにアクセスできません。

(2)　共通フォルダにアクセスする方法

FTP受付は，次の条件を満たした場合に，共通フォルダ内のファイルを中間ファイルとして使用できます。

GETオペレーションの応答電文の<folder-name>の値に共通フォルダ定義名が設定されている。

GETオペレーションの応答電文の<file-name>の値に共通フォルダ内のファイルが設定されている。

GETオペレーションの応答電文の<success>の値にtrueが設定されている。

(3)　中間ファイルとして指定可能なファイル

中間ファイルとして指定できるファイルを次に示します。

共通フォルダ内のファイルであること。フォルダを指定することはできません。

共通フォルダからの相対パスが指定できるが，共通フォルダの外部のファイルを指定することはできません。なお，パスの先頭のスラッシュ（/）は省略することができます。

シンボリックリンクのファイルでないこと。

(4)　共通フォルダ内のファイルの削除

共通フォルダ内のファイルを中間ファイルとして使用した場合，FTP受付でファイルを削除することができます。ファイルが削除される条件を次に示します。

共通フォルダ内のファイルを中間ファイルとして使用した。

FTP受付定義ファイルのurecp-ftp.common-dir-file.auto-deleteプロパティの値が「true」である。

FTP受付がビジネスプロセスを呼び出して，呼び出したビジネスプロセスから，<success>タグの値がtrueの応答電文を受け取った。

FTP受付とFTPインバウンドアダプタの間のデータ（ファイルの内容やリストデータ）の受け渡しが正常に終了した。

上記の条件を満たしていない場合や，プロセスが異常終了した場合およびcscpireexecコマンド（プロセスインスタンスの再実行）などでビジネスプロセスを再実行した場合は，共通フォルダ内の中間ファイルが自動で削除されません。

上記の条件を満たしていない場合や，プロセスが異常終了した場合およびビジネスプロセスの再実行を要求した場合（cscpireexecコマンドなど）は，共通フォルダ内の中間ファイルが自動で削除されません。FTP受付が共通フォルダ内の中間ファイルを削除できなかった場合，次の方法で共通フォルダ内の中間ファイルを削除してください。

FTP受付定義ファイルのurecp-ftp.common-dir-file.auto-deleteプロパティの値が「false」の場合

ビジネスプロセスが実行する最後の処理でファイル操作アダプタを呼び出して共通フォルダ内の中間ファイルを削除してください。または，cscfsclsコマンドで共通フォルダを参照し，削除対象かどうか確認したあと，cscfscrmコマンドで共通フォルダ内の中間ファイルを削除してください。

FTP受付定義ファイルのurecp-ftp.common-dir-file.auto-deleteプロパティの値が「true」の場合

cscfsclsコマンドで共通フォルダを参照し，削除対象かどうか確認したあと，cscfscrmコマンドで共通フォルダ内の中間ファイルを削除してください。

詳細は，マニュアル「サービスプラットフォーム リファレンス」の「cscfscls（共通フォルダの参照）」または「cscfscrm（共通フォルダの削除）」を参照してください。

(5)　共通フォルダ内のファイルの排他制御

GETオペレーションで共通フォルダ内のファイルへアクセスする場合，ファイルの読み込み時に共有ロックを取得します。また共通フォルダのファイルを削除する場合，削除するファイルに対して占有ロックを取得します。ファイルロック取得時のロックリトライ回数およびロックリトライ間隔は，FTP受付コンフィグファイルのプロパティで変更できます。

FTP受付コンフィグファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.5　FTP受付コンフィグファイル」を参照してください。また排他制御については，「8.8.2　共通フォルダを利用したファイルアクセス」を参照してください。

8.4.11　リストコマンドパスのデータ抽出機能

リストコマンドの引数のパス情報は，GETINFOオペレーションの要求電文の<getinfo-path>に設定されます。しかし，特定の情報（FTP受付の受付IDなど）をパス情報で渡したい場合，データ変換処理が複雑になります。その場合にリストコマンドパスのデータ抽出機能を使用すると，パス情報に設定した特定の情報を簡単に抜き出してビジネスプロセスに渡すことができます。

(1)　データ抽出の前提条件

LISTコマンドまたはNLSTコマンドの引数のパス情報が次の形式と一致する場合，パスの部分文字列を抜き出し，GETINFOオペレーションの要求電文の<getinfo-path-context>と<getinfo-path-relative>に設定することができます。なお，リストコマンドのパス情報は，GETINFOオペレーションの要求電文の<getinfo-path>の値を指します。

パスの形式

/<1バイト以上の値>/<1バイト以上の値>

図8‒15　GETINFOオペレーションの要求電文の生成イメージ

(2)　<getinfo-path-context>の生成

(a)　設定される値

パス情報の先頭のスラッシュ（/）から次のスラッシュ（/）より前の部分が設定されます。このタグにスラッシュ（/）は含まれません。

(b)　タグの生成される条件

次のすべての条件を満たしている場合に生成されます。条件に合致しない場合はエラーおよび警告メッセージが出力されません。

FTP受付定義ファイルのurecp-ftp.list-command-path-extractionプロパティの値がtrueである。

<getinfo-path>がGETINFOオペレーションの要求電文に出力されている。

<getinfo-path>の先頭がスラッシュ（/）である。

<getinfo-path>に2つ目のスラッシュ（/）が存在する。

<getinfo-path>の先頭のスラッシュ（/）と2つ目のスラッシュ（/）の間に1バイト以上の値が存在する。

FTP受付定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「3.5.1　FTP受付定義ファイル」を参照してください。

(3)　<getinfo-path-relative>の生成

(a)　設定される値

パス情報の2つ目のスラッシュ（/）より後ろの値が設定されます。

(b)　タグの生成される条件

次のすべての条件を満たしている場合に生成されます。条件に合致しない場合はエラーおよび警告メッセージが出力されません。

FTP受付定義ファイルのurecp-ftp.list-command-path-extractionプロパティの値がtrueである。

<getinfo-path-context>がGETINFOオペレーションの要求電文に出力されている。

<getinfo-path>に2つ目のスラッシュ（/）より後ろの値が存在する。

FTP受付定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「3.5.1　FTP受付定義ファイル」を参照してください。

8.5　FTPインバウンドアダプタの機能

FTPインバウンドアダプタとは，FTPクライアントからの転送要求を受信して，ビジネスプロセスに関連づけられたFTP受付に振り分けるアダプタです。

FTP連携でのFTPインバウンドアダプタの位置づけを次の図に示します。

図8‒16　FTP連携でのFTPインバウンドアダプタの位置づけ

ここでは，FTPインバウンドアダプタでサポートする次の機能について説明します。

送受信後のファイルサイズ確認

タイムアウトの監視

セキュリティに関する機能

FTPインバウンドアダプタのセキュリティに関する機能および設定方法については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「付録H.2　セキュアプロトコルによる暗号化・認証（FTPインバウンドアダプタ）」を参照してください。

8.5.1　送受信後のファイルサイズ確認

FTPインバウンドアダプタでは，JP1/File Transmission Server/FTPと連携することによって，転送前と転送後のファイルのサイズを比較します。FTPクライアントからSITE FSIZEコマンドが実行されると，ファイルが転送処理の間に破損していないかなどの確認がされるため，送受信されたファイルの信頼性を確保できます。

JP1/File Transmission Server/FTPについては，マニュアル「JP1/File Transmission Server」を参照してください。

8.5.2　タイムアウトの監視

FTPインバウンドアダプタとFTPクライアントとの通信中や，FTP受付への振り分け中に，FTPクライアントやネットワークの異常によって通信処理が無応答になったり，FTP受付以降のファイル操作処理に時間が掛かってしまったりしている場合に，FTPインバウンドアダプタでタイムアウトを検知します。

タイムアウトが検知された場合，メッセージが出力されたりコネクションが切断されたりして，システムの処理能力の低下を防止します。

FTPインバウンドアダプタでタイムアウトを監視するポイントを，ActiveモードおよびSTORによるファイル転送の場合を例に，次の図に示します。

図8‒17　FTPインバウンドアダプタでタイムアウトを監視するポイント（ActiveモードおよびSTORによるファイル転送の場合の例）

(1)　タイムアウトしたときの動作

それぞれのポイントでの，タイムアウトしたときの動作，および注意事項について説明します。

(a)　アイドルタイムアウト

制御コネクションに対して，FTPインバウンドアダプタから応答を返してから，FTPクライアントから次のFTPコマンドが送信されてくるまでの時間を監視します。

アイドルタイムアウトの監視の流れを次の図に示します。

図8‒18　アイドルタイムアウトの監視の流れ

次に，タイムアウトしたときの動作および注意事項を示します。

タイムアウトしたときの動作

メッセージを出力します。

タイムアウトが発生した制御コネクションを切断します。

注意事項

データ送受信中のアイドルタイムアウトの監視範囲は次のとおりです。

FTPクライアントから転送要求を受信してから，FTP受付に制御が移り，FTPインバウンドアダプタがコネクション接続要求を完了するまでの間

FTPクライアントとのファイルデータ（またはリストデータ）の送受信が完了してから，FTP受付に制御が移り，FTPインバウンドアダプタが転送完了応答を返すまでの間

上記1.および2.の合計時間がアイドルタイムアウトの監視時間を超えると，アイドルタイムアウトが発生します。ただし，アイドルタイムアウトの発生は，データ送受信が終了したあと（転送完了応答を送信したあと）に発生します。

なお，コネクション接続要求が完了してから，ファイルデータ（またはリストデータ）の送受信が完了するまでの間は，アイドルタイムアウトの監視をしません。

データ送信中のアイドルタイムアウト，およびデータ受信中のアイドルタイムアウトについて，次の図に示します。

図8‒19　データ送信中のアイドルタイムアウト

図8‒20　データ受信中のアイドルタイムアウト

(b)　データコネクション接続のタイムアウト

データコネクションの接続方式がアクティブモードの場合，FTPクライアントへのデータコネクションの接続を開始してから完了するまでの時間を監視します。時間の監視は，コネクション接続の監視時間，およびリトライ回数で指定します。データコネクション接続のタイムアウトの監視の流れを次の図に示します。

図8‒21　データコネクション接続のタイムアウトの監視の流れ

次に，タイムアウトまたはデータコネクション接続でエラーが発生したときの動作および注意事項を示します。

タイムアウトしたとき，またはデータコネクション接続でエラーが発生したときの動作

メッセージを出力します。

指定したリトライ回数に達していない場合，データコネクション接続をリトライします。

指定したリトライ回数に達した場合，制御コネクションでレスポンスコード「425 Can't open data connection.」を返します。

注意事項

指定した監視時間より，TCP/IPで設定されたコネクション接続の監視時間が短い場合は，TCP/IPで設定された監視時間でタイムアウトが発生します。また，データコネクションの接続でエラーが発生した場合は，監視時間を待たないで，すぐにエラーとなります。

TCP/IPで設定された監視時間でタイムアウトが発生した場合，およびデータコネクションの接続でエラーが発生した場合は，指定したリトライ回数だけリトライします。リトライ回数を超えたときは，データコネクションの接続処理を終了します。

(c)　データ受信のタイムアウト

FTPクライアントからTCP/IPパケットに分割したファイルデータが受信できる状態となってから，TCP/IPパケットに分割したファイルデータが送信されてくるまでの時間を監視します。

データ受信のタイムアウトの監視の流れを次の図に示します。

図8‒22　データ受信のタイムアウトの監視の流れ

次に，タイムアウトしたときの動作を示します。

タイムアウトしたときの動作

メッセージを出力します。

タイムアウトが発生したデータコネクションを切断します。

制御コネクションでレスポンスコード「551 <ファイルパス>: Error on output file.」を返します。

FTP受付に例外「FileTransferFailedException」を通知します。

(d)　データ送信のタイムアウト

FTPクライアントへTCP/IPパケットに分割したファイルデータまたはリストデータの送信を開始してから，TCP/IPパケットに分割したファイルデータまたはリストデータの送信完了の確認応答までの時間を監視します。

データ送信のタイムアウトの監視の流れを次の図に示します。

図8‒23　データ送信のタイムアウトの監視の流れ

次に，タイムアウトしたときの動作を示します。

タイムアウトしたときの動作

メッセージを出力します。

タイムアウトが発生したデータコネクションを切断します。

制御コネクションで次のレスポンスコードを返します。

・ファイルデータ転送の場合

　「551 <ファイルパス>: Error on input file.」を返します。

・リストデータ転送の場合

　「551 Requested action aborted.」を返します。

FTP受付に例外「FileTransferFailedException」を通知します。

(2)　設定方法

cjgetrarpropコマンドで取得したconnector属性ファイルの次の項目を設定してください。

nioListener_idleTimeout（アイドルタイムアウト）

nioListener_dataConnection_active_connectRetryCount（データコネクション接続のリトライ回数）

nioListener_dataConnection_active_connectRetryInterval（データコネクション接続の監視時間）

nioListener_dataConnection_idleTimeout（データ送信およびデータ受信のタイムアウト）

設定方法の詳細は，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「3.2.3　FTPインバウンドアダプタをセットアップする」を参照してください。

8.6　FTPアダプタの機能

ここでは，FTPアダプタの役割，およびFTPアダプタを利用したファイル送受信の流れについて説明します。

FTPアダプタとは，FTPサーバとサービスプラットフォームとの間でファイルを送受信するためのサービスアダプタです。

FTP連携を利用したシステムでは，FTPクライアントとFTPサーバの間でファイルを送受信するために，接続するFTPサーバごとにFTPアダプタが必要になります。

FTPアダプタを利用したファイル送受信の流れを次の図に示します。

図8‒24　FTPアダプタを利用したファイルの送受信の流れ

図中の制御およびデータの流れについて説明します。

FTPサーバからFTPクライアントへのファイル転送の場合（GETオペレーション）

FTPクライアントからファイル取得コマンドを実行すると，コマンドの実行要求がFTPインバウンドアダプタを経由してFTP受付に届けられます。そのあとビジネスプロセスが開始され，ビジネスプロセスからFTPアダプタが呼び出されます。

ビジネスプロセスから実行要求を受け取ったFTPアダプタは，FTPサーバと接続してFTPクライアントにファイルを送信します。

FTPクライアントからFTPサーバへのファイル転送の場合（PUTオペレーション）

FTPクライアントからファイル送信コマンドを実行すると，GETオペレーションの場合と同様に，コマンドの実行要求がFTPアダプタに届けられます。そのあと，FTPアダプタは，FTPサーバと接続してFTPクライアントからFTPサーバにファイルを送信します。

FTPサーバのファイル一覧情報を取得してFTPクライアント側へ送付する場合（GETINFOオペレーション）

FTPクライアントから情報取得コマンド（LISTコマンドまたはNLSTコマンド）を実行すると，実行したコマンドに応じてFTPサーバ側に存在するファイルの情報の一覧またはファイルの名前の一覧を取得します。

FTP連携システム全体のファイル送受信の流れについては，「8.3　FTP連携を利用したファイル転送パターンの例」を参照してください。

8.6.1　FTPアダプタの処理の流れ

FTPアダプタを中心としたファイル送受信時の処理の流れについて説明します。

ビジネスプロセスから実行要求を受けたときのFTPアダプタの処理の流れを次の図に示します。

図8‒25　FTPアダプタの処理の流れ

ビジネスプロセスから実行要求を受けてFTPアダプタが呼び出されます。このとき，ファイルの転送情報は要求電文に格納されてFTPアダプタに渡されます。

要求電文を受け取ったFTPアダプタは，FTPサーバに対して接続・認証，転送コマンド，リストコマンド，切断などの処理を実行します。

FTPサーバの呼び出しが完了したあと，FTPアダプタは結果を応答電文に設定し，ビジネスプロセスに返します。

エラーが発生した場合は，応答電文の代わりにシステム例外を返します。

8.6.2　FTPコマンドの実行

ここでは，FTPアダプタの機能として，FTPアダプタが実行するFTPコマンドの種類，実行条件，およびタイマ管理などについて説明します。

FTPアダプタは，ビジネスプロセスから実行要求を受けたあと，条件に応じてFTPサーバに認証・接続や転送コマンドなどのFTPコマンドを実行します。

FTPアダプタが実行するFTPコマンドの種類，および実行条件を次の表に示します。

表8‒5　FTPコマンドの種類とコマンドの実行可否

分類

FTPコマンド

コマンドの実行可否

接続・認証

（connect処理）

◎

AUTH

△※1

USER

◎

PASS

◎

ACCT

△※2

保護レベル

PBSZ

△※3

PROT

△※3

転送パラメタ

TYPE

△※2

MODE

△※2

PASV，PORT，EPSV，EPRT

○※4

ファイルサイズ確認

SITE FSIZE

△※5

転送前コマンド・転送後コマンド，

リスト前コマンド・リスト後コマンド※6

MDTM，SIZE，STAT，DELE，MKD，XMKD，RMD，XRMD，PWD，XPWD，CDUP，XCUP，CWD，XCWD，NOOP，SITE，RNFR，RNTO，ALLO，OPTS，STRU，SYST

△※7

転送または情報取得

STOR，APPE，RETR，LIST，NLST

○※2

ABOR

△※8

切断

QUIT

◎

（凡例）

◎：必ず実行されます。

○：どれか1つが実行されます。

△：条件に依存します。

注※1

FTPSを使用する場合で，Explicitモードのときに実行されます。FTPSに関する設定については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「付録H.1　FTPSを使用したセキュアな接続（FTPアダプタ）」を参照してください。

注※2

要求電文フォーマットの指定によっては実行されます。実行条件については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.10　FTPアダプタを定義する」を参照してください。

注※3

FTPSを使用する場合に実行されます。

注※4

FTPアダプタ実行環境プロパティファイルのftpadp.pasvportプロパティの設定に依存します。FTPアダプタ実行環境プロパティファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.3　FTPアダプタ実行環境プロパティファイル」を参照してください。

注※5

SITE FSIZEコマンドの実行条件については，「8.6.4　送受信後のファイルサイズ確認」を参照してください。

注※6

ファイルの転送コマンド実行前，転送コマンド実行後，リストコマンド実行前，またはリストコマンド実行後に実行されるコマンドです。

注※7

要求電文フォーマットの<ftp-commands-before>タグ，および<ftp-commands-after>タグに実行指示がある場合に実行されます。

注※8

データ転送時にタイムアウトが発生した場合に実行されます。

注意事項

FTPアダプタが実行するFTPコマンドの仕様はRFC959，RFC2228，RFC2428，およびRFC3659に準拠しています。ただし，次のコマンドは，RFCの仕様とFTPアダプタの仕様とで機能に差異があります。

TYPE

FTPアダプタのTYPEコマンドにEBCDICは指定できません。

MODE

FTPアダプタのMODEコマンドにブロックモードは指定できません。

LIST

コマンドの引数でオプションを指定できます。ただし，接続先FTPサーバがオプションの指定をサポートしている必要があります。

NLST

コマンドの引数でオプションを指定できます。ただし，接続先FTPサーバがオプションの指定をサポートしている必要があります。

8.6.3　ファイル送受信時に使用するフォルダの指定

(1)　ファイル送受信に使用するフォルダの指定

PUTオペレーションおよびGETオペレーションの場合，HCSCサーバ内でFTP受付が管理する作業フォルダ，またはクラスタ構成内で共通に利用する共通フォルダを使用してファイルを送受信します。GETINFOオペレーションの場合，作業フォルダおよび共通フォルダのほかに応答電文にファイルのリストを出力することもできます。

出力先はFTPアダプタの要求電文で指定できます。各オペレーションの出力先の種類と指定方法を次に示します。

PUTオペレーションおよびGETオペレーションの場合

出力先

指定方法

共通フォルダ

要求電文の<local-folder>タグの属性にcommon="true"を指定します。

作業フォルダ

要求電文の<local-folder>タグの属性にcommon="false"を指定します。

GETINFOオペレーションの場合

出力先

指定方法

共通フォルダ

要求電文の<local-folder>タグの属性にcommon="true"を指定します。

作業フォルダ

要求電文の<local-folder>タグの属性にcommon="false"を指定し，かつ<request-id>タグを指定します。

応答電文

要求電文の<local-folder>タグおよび<request-id>タグを省略します。

FTPアダプタの要求電文フォーマットの内容については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.10　FTPアダプタを定義する」を参照してください。

(2)　サブフォルダの指定

FTPアダプタでは共通フォルダルートの配下にサブフォルダを作成できます。

共通フォルダ内のサブフォルダを相対パスで指定したファイルの転送ができます。

相対パスの指定方法

各オペレーションの要求電文または応答電文のローカル側ファイル名（local-file-name）に，共通フォルダルートからの相対パスを指定します。

ファイル名を指定する場合の指定例

<request>
  ：
  <local-folder common="true">default</local-folder>
  <local-file-name>a.txt</local-file-name>
  ：
</request>

相対パスを指定する場合の指定例

<request>
  ：
  <local-folder common="true">default</local-folder>
  <local-file-name>/folder1/folder2/a.txt</local-file-name>
  ：
</request>

注意事項

作業フォルダについては，相対パスを指定できません。

相対パスの先頭の「/」は省略できます。

共通フォルダルートより上位のフォルダへのアクセスはできません。アクセスした場合はエラーになります。

シンボリックリンクのファイルは指定できません。

8.6.4　送受信後のファイルサイズ確認

送受信後のファイルサイズを確認する機能について説明します。

(1)　ファイルサイズ確認とは

FTPサーバにJP1/File Transmission Server/FTPを使用している場合，FTPアダプタとFTPサーバとの間で送受信されたファイルのサイズが，送信側と受信側で正しいかどうかを確認できます。

転送中にファイルが破損した場合，FTPアダプタからの応答コードが正常終了しているときはファイルが破損しているかどうかをユーザから確認できません。このような場合に，FTPアダプタは転送元のファイルサイズと転送先のファイルサイズを比較して，ファイルサイズが異なる場合はビジネスプロセスにシステム例外（転送エラー）を返します。

なお，改行コードのバイト数が異なるOS間でASCIIモードのファイル転送をした場合，自動的に改行コードが変換されるためファイルサイズが増減しますが，この場合はエラーになりません。

JP1/File Transmission Server/FTPを使用したファイルサイズ確認機能については，マニュアル「JP1/File Transmission Server」を参照してください。

(2)　設定方法

ファイルサイズ確認を有効にするには，FTPアダプタ実行環境プロパティファイルのftpadp.file-size-checkプロパティを「TRUE」に設定している必要があります。

FTPアダプタ実行環境プロパティファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.3　FTPアダプタ実行環境プロパティファイル」を参照してください。

(3)　注意事項

FTPサーバにJP1/File Transmission Server/FTPを使用していない場合にFTPアダプタ実行環境プロパティファイルのftpadp.file-size-checkプロパティを「TRUE」に設定していると，FTPアダプタは例外を返して，リクエスト処理を終了します。

8.6.5　タイマ管理

FTPアダプタのタイマ管理の機能，およびタイムアウト値の設定方法について説明します。

FTPアダプタでタイムアウトを監視するポイントを，PassiveモードおよびSTORによるファイル転送の場合を例に，次の図に示します。

図8‒26　FTPアダプタでタイムアウトを監視するポイント（PassiveモードおよびSTORによるファイル転送の場合の例）

FTPアダプタでタイムアウトを監視するポイントを，ActiveモードおよびSTORによるファイル転送の場合を例に，次の図に示します。

図8‒27　FTPアダプタでタイムアウトを監視するポイント（ActiveモードおよびSTORによるファイル転送の場合の例）

FTPアダプタでは，次のタイムアウトを設定できます。

制御コネクション接続タイムアウト

FTPコマンドリプライタイムアウト

排他取得タイムアウト

データコネクション接続タイムアウト

データ転送・取得タイムアウト

Listenタイムアウト

データ読み込みタイムアウト

各タイムアウト値は，FTPアダプタ実行環境プロパティファイルで設定できます。

FTPアダプタ実行環境プロパティファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.3　FTPアダプタ実行環境プロパティファイル」を参照してください。

(1)　制御コネクション接続タイムアウト

FTPアダプタとFTPサーバの間のコマンド実行やその応答などは，制御コネクション接続によって通信されます。

FTPアダプタからの制御コネクションの接続要求時に相手先ビジーなどでコネクションを確立できなかった場合，指定間隔おきに指定回数まで接続処理をリトライします。接続処理をリトライした場合，リトライの状況を保守用ログに出力します。

設定するパラメタを次の表に示します。

表8‒6　制御コネクション接続タイムアウトの設定

値

キー名称

デフォルト値

制御コネクション接続リトライ回数（回）

ftpadp.control-con.retry.count

5

制御コネクション接続リトライ間隔（秒）

ftpadp.control-con.retry.interval

2

1回の制御コネクション接続タイムアウト時間（秒）

ftpadp.control-con.connect.timeout

10

タイムアウト時間は，これらのパラメタに指定した値を使った次の計算式で求められます。

（1回の制御コネクション接続タイムアウト時間＋制御コネクション接続リトライ間隔）×制御コネクション接続リトライ回数

(2)　FTPコマンドリプライタイムアウト

FTPアダプタからFTPコマンドを発行したあと，指定した時間を経過しても応答がない場合，例外が発生します。FTPコマンドリプライタイムアウトを設定することで，例外が発生するまでの時間を設定できます。

設定するパラメタを次の表に示します。

表8‒7　FTPコマンドリプライタイムアウトの設定

値

キー名称

デフォルト値（秒）

FTPコマンドリプライタイムアウト値

ftpadp.ftp-command-reply.timeout

60

(3)　排他取得タイムアウト

共通フォルダ内のファイルをPUTオペレーションでFTPサーバに転送する場合，共通フォルダ内のファイルに対して共有ロックが設定されます。

また，GETオペレーションで共通フォルダのファイルを取得する場合，共通フォルダのファイルに占有ロックが設定されます。

共有ロックまたは占有ロックの設定時に他プロセスとの競合によって設定が失敗したとき，指定間隔おきに指定回数まで排他取得処理をリトライします。リトライ間隔とリトライ回数の積に，各排他取得時のファイルアクセス時間を加えた時間がタイムアウト時間となります。

設定するパラメタを次の表に示します。

表8‒8　排他取得タイムアウトの設定

値

キー名称

デフォルト値

共有ロックリトライ回数（回）

ftpadp.read-lock.retry.count

0

共有ロックリトライ間隔（秒）

ftpadp.read-lock.retry.interval

1

占有ロックリトライ回数（回）

ftpadp.write-lock.retry.count

0

占有ロックリトライ間隔（秒）

ftpadp.write-lock.retry.interval

1

GETINFOオペレーションで共通フォルダにファイルを出力する場合，すでに同名のファイルが存在するときは，ファイルが上書きされます。同名のファイルがほかのプロセスで使用されているときは，占有ロックリトライ回数および占有ロックリトライ間隔で指定したタイムアウト時間で処理がリトライされます。

(4)　データコネクション接続タイムアウト

FTPアダプタ，FTPサーバ間でのデータ転送は，データコネクション接続によって通信されます。

接続モードがPASVモードの場合，データコネクション接続要求時に相手先ビジーなどによってコネクションを確立できなかったときは，指定間隔おきに指定回数まで接続処理をリトライします。接続処理をリトライした場合，リトライの状況を保守用ログに出力します。

接続モードがPORTモードの場合，データコネクション接続タイムアウトはFTPサーバの仕様に依存するため，FTPアダプタでは設定できません。

設定するパラメタを次の表に示します。

表8‒9　データコネクション接続タイムアウトの設定

値

キー名称

デフォルト値

PASVモードのデータコネクション接続リトライ回数（回）

ftpadp.data-con.retry.count

5

PASVモードのデータコネクション接続リトライ間隔（秒）

ftpadp.data-con.retry. interval

2

1回のデータコネクション接続タイムアウト時間（秒）

ftpadp.data-con.connect.timeout

10

タイムアウト時間は，これらのパラメタに指定した値を使った次の計算式で求められます。

（1回のデータコネクション接続タイムアウト時間＋PASVモードのデータコネクション接続リトライ間隔）×PASVモードのデータコネクション接続リトライ回数

(5)　データ転送・取得タイムアウト

FTPアダプタからデータ転送コマンドまたはリストコマンドを実行したあと，指定した時間を経過してもデータ転送またはリストデータの取得が完了しない場合は例外が発生します。データ転送タイムアウトおよびデータ取得タイムアウトを設定することで，例外が発生するまでの時間を指定できます。

この例外が発生した場合のローカルファイルおよびリモートファイルの扱いを次に示します。

RETRコマンド，LISTコマンド，またはNLSTコマンド実行中のローカルファイル

FTPアダプタが削除します。

STORコマンドまたはAPPEコマンド実行中のリモートファイル

FTPサーバの仕様に依存します。

設定するパラメタを次の表に示します。

表8‒10　データ転送・取得タイムアウトの設定

値

キー名称

デフォルト値（秒）

データ転送タイムアウト値

ftpadp.data-con-put.timeout

60

データ取得タイムアウト値

ftpadp.data-con-get.timeout

60

ファイル送信は複数回実行されます。

ローカルファイルの読み込みが終わったあとで，時間をチェックして時間が経過していた場合に，タイムアウトが発生します。

図8‒28　データ転送タイムアウトの流れ

ファイル受信は複数回実行されます。

ファイル受信が終わったあとで，時間をチェックして時間が経過していた場合に，タイムアウトが発生します。

図8‒29　データ取得タイムアウトの流れ（Passiveの例）

図8‒30　データ取得タイムアウトの流れ（Activeの例）

(6)　Listenタイムアウト

接続モードがPORTモードで，次のどちらかの場合，例外が発生します。

FTPアダプタがPORTコマンドの応答を受けたあと，Listen状態で一定時間FTPサーバからデータコネクションの接続要求がなかった場合

データコネクションの接続完了後，FTPサーバからFTPアダプタにファイルが送信されてこない場合

Listenタイムアウトを設定することで，例外が発生するまでの時間を指定できます。

設定するパラメタを次の表に示します。

表8‒11　Listenタイムアウトの設定

値

キー名称

デフォルト値（秒）

Listenタイムアウト値

ftpadp.listen.timeout

60

(7)　データ読み込みタイムアウト

接続モードがPASVモードで，データコネクションの接続完了後，FTPサーバからFTPアダプタにファイルが送信されてこない場合に，例外が発生します。

データ読み込みタイムアウトを設定することで，例外が発生するまでの時間を指定できます。

設定するパラメタを次の表に示します。

表8‒12　データ読み込みタイムアウト設定

値

キー名称

デフォルト値（秒）

データ読み込みタイムアウト値

ftpadp.data-con.read.timeout

0

8.7　ファイル操作アダプタの機能

ここでは，ファイル操作アダプタの構成およびサポートするオペレーションについて説明します。

ファイル操作アダプタとは，FTPプログラムなどを利用して生成したファイルに対してレイアウト変換や文字コード変換，複製，移動，削除，圧縮，伸張，一覧取得などのファイル操作をするためのアダプタです。ファイル操作アダプタでは，ファイルに対する操作の単位をオペレーションと呼びます。

FTP連携を利用する場合，FTP受付およびFTPアダプタを使用してオペレーションごとにファイル操作アダプタを定義する必要があります。

ファイル操作アダプタの構成を次の図に示します。

図8‒31　ファイル操作アダプタの構成

8.7.1　ファイル操作アダプタでサポートするオペレーション

ファイル操作アダプタでサポートするオペレーションには，次の種類があります。

ファイル変換オペレーション

ファイル複製オペレーション

ファイル移動オペレーション

ファイル・フォルダ削除オペレーション

ファイル圧縮オペレーション

ファイル伸張オペレーション

ファイル一覧取得オペレーション

ファイル一覧書き込みオペレーション

ファイル読み込みオペレーション

ファイル書き込みオペレーション

それぞれのオペレーションの動作を次の図に示します。

図8‒32　ファイル操作アダプタのオペレーションの動作（1/3）

図8‒33　ファイル操作アダプタのオペレーションの動作（2/3）

図8‒34　ファイル操作アダプタのオペレーションの動作（3/3）

図中の1.〜10.について説明します。次の番号は図中の番号と対応しています。

ファイル操作アダプタA（ファイル変換オペレーション）は，作業フォルダ（または共通フォルダ）から変換元の入力ファイルを読み込み，変換後の出力ファイルを作業フォルダ（または共通フォルダ）に書き込みます。

ファイル操作アダプタB（ファイル複製オペレーション）は，作業フォルダ（または共通フォルダ）から入力ファイルを読み込み，作業フォルダ（または共通フォルダ）に出力ファイルを複製します。

ファイル操作アダプタC（ファイル移動オペレーション）は，作業フォルダ（または共通フォルダ）のファイルを作業フォルダ（または共通フォルダ）へ移動します。

ファイル操作アダプタC（ファイル・フォルダ削除オペレーション）は，共通フォルダのファイル，サブフォルダ，または作業フォルダを削除します。

ファイル操作アダプタD（ファイル圧縮オペレーション）は，作業フォルダ（または共通フォルダ）から圧縮元の入力ファイルを読み込み，作業フォルダ（または共通フォルダ）に圧縮後の出力ファイルを書き込みます。

ファイル操作アダプタE（ファイル伸張オペレーション）は，作業フォルダ（または共通フォルダ）から伸張元の入力ファイルを読み込み，作業フォルダ（または共通フォルダ）に伸張後の出力ファイルを書き込みます。

ファイル操作アダプタG（ファイル一覧取得オペレーション）は，共通フォルダ（または共通フォルダのサブフォルダ）直下のファイル情報もしくは共通フォルダのファイル単体の情報を取得し，応答電文で返します。

ファイル操作アダプタH（ファイル一覧書き込みオペレーション）は，共通フォルダ（または共通フォルダのサブフォルダ）直下のファイル情報もしくは共通フォルダのファイル単体の情報を取得し，作業フォルダ（または共通フォルダ）のファイルに取得した情報を書き込みます。

ファイル操作アダプタI（ファイル読み込みオペレーション）は，作業フォルダ（または共通フォルダ）からファイルを読み込み，ほかのサービスに渡します。

ファイル操作アダプタJ（ファイル書き込みオペレーション）は，ほかのサービスから取得したデータを，作業フォルダ（または共通フォルダ）に書き込みます。

ファイル操作アダプタを使用してファイルの変換や削除などをする場合，オペレーションごとにファイル操作アダプタを定義する必要があります。

それぞれのオペレーションのファイル操作アダプタ同士を組み合わせて使用することもできます。

8.7.2　各オペレーションの要求電文および応答電文

ファイル操作アダプタで使用する要求電文および応答電文の電文フォーマットは，オペレーションごとに異なります。

各オペレーションの要求電文および応答電文の電文フォーマットについては，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.11　ファイル操作アダプタを定義する」を参照してください。

8.7.3　ファイル変換オペレーション

ここでは，ファイル変換オペレーションでサポートする機能やファイル形式について説明します。

(1)　ファイル変換オペレーションの機能概要

ファイル変換オペレーションは，作業フォルダまたは共通フォルダから変換元の入力ファイルを読み込み，変換後の出力ファイルを作業フォルダまたは共通フォルダに書き込みます。

ファイル変換オペレーションの処理の概要について，次の図に示します。

図8‒35　ファイル変換オペレーションの処理

(2)　サポートする入出力ファイルの形式

ファイル変換オペレーションでサポートする入力ファイル，および出力ファイルのファイル形式について次の表に示します。

表8‒13　ファイル変換オペレーションでサポートするファイル形式

項番

処理方式

入力ファイルの形式

出力ファイルの形式

サポート可否

1

一括処理方式

バイナリ形式

バイナリ形式

○

2

XML形式

○

3

XML形式

バイナリ形式

○

4

XML形式

○

5

分割処理方式

バイナリ形式

固定長形式

バイナリ形式

○

6

XML形式

○

7

レングスタグ形式

バイナリ形式

×

8

XML形式

×

9

改行セパレータ形式

バイナリ形式

○

10

XML形式

○

11

EORセパレータ形式

バイナリ形式

○

12

XML形式

○

13

上記以外

バイナリ形式

×

14

XML形式

×

15

XML形式

バイナリ形式

○

16

XML形式

○

（凡例）

○：サポートしています。

×：サポートしていません。

固定長形式，レングスタグ形式，改行セパレータ形式，およびEORセパレータ形式の違いを次に示します。

固定長形式

レコードのバイト長をあらかじめ決めておく形式です。

レングスタグ形式

データ要素に対して，その長さまたは個数を表す数値情報を付けた形式です。

改行セパレータ形式

改行コード（LF（0x0a）またはCR+LF（0x0d 0x0a））の出現をレコードの区切りとする形式です。改行セパレータ形式の詳細については，「(4)(a)　レコード単位の判定形式の種類」を参照してください。

EORセパレータ形式

ファイル操作アダプタ定義ファイルで設定したEORコード（レコードの終端を示すコード）の出現をレコードの区切りとする形式です。EORセパレータ形式を使用すると，レコードの区切りが改行コード以外のファイルも処理できます。

ファイル変換時にレイアウト変換ができます。また，入出力形式がバイナリ形式の場合は，改行コードの付与・削除，文字コード変換もできます。

参考

入力ファイルに1バイトでもデータが含まれている場合は，ファイル変換を実行します（データが空文字，改行文字，EOF文字だけの場合であっても，ファイル変換を実行します）。入力ファイルが0バイトの場合は，0バイトのファイルを出力します。エラーにはなりません。

(3)　一括処理方式

一括処理方式では，入力ファイルを一括して読み込み，一括して変換します。変換後，一括して出力ファイルへ書き込みます。

一括処理方式で対象となるデータフォーマット，および対象とする変換内容を次に示します。

対象とするデータフォーマット

1つのバイナリフォーマット定義またはXMLスキーマで定義できる範囲です。

対象とする変換内容

1つのデータ変換定義ファイル（拡張子：xsl）で定義できる範囲です。

注意事項

入力ファイルおよび出力ファイルのサイズが500MB以上のファイルは変換できません。500MB以上のファイルを変換した場合，動作を保証しません。

(4)　分割処理方式

入力ファイルの読み込み，変換，出力ファイルへの書き込みを，入力ファイルのレコード単位で処理します。入力ファイルの終端まで繰り返し処理を実行します。

分割処理方式でバイナリ形式からXML形式のファイルに変換する場合，およびXML形式からバイナリ形式のファイルに変換する場合の定義例については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「付録E　ファイル操作アダプタの定義例」を参照してください。

(a)　レコード単位の判定形式の種類

入力ファイルの形式によってレコード単位の判定形式が異なります。

バイナリ形式の場合

レコード単位の判定には，次の形式があります。

固定長形式

レコードのバイト長をあらかじめ指定する形式です。入力ファイルが固定長形式の場合に使用します。

改行セパレータ形式

改行コード（LF（0x0a）またはCR+LF（0x0d 0x0a））の出現をレコードの区切りとして判定する形式です。入力ファイルが改行セパレータ形式の場合に使用します。改行セパレータ形式については，「(d) レコードの分割（入力ファイルがバイナリ形式の場合）」の説明を参照してください。

分割処理方式で，改行セパレータ形式を選択した場合，バイナリフォーマット定義に関係なく，改行コード（LF（0x0a）またはCR+LF（0x0d 0x0a））の出現でレコードの区切りを判断しているため，変換元ファイルにある文字コードの改行のバイトパターンが，改行コード以外のとき（文字コード例：UTF-16_BIG，UTF-16_LITTLE，KEIS+EBCDIC，KEIS+EBCDIK，KEIS），改行セパレータ形式の分割処理方式では正常に処理できません。なお，CUSTOMを選択した場合，処理対象のデータに従います。

EORセパレータ形式

ファイル操作アダプタ定義ファイルで設定したEORコード（レコードの終端を示すコード）の出現をレコードの区切りとする形式です。EORセパレータ形式を使用すると，レコードの区切りが改行コード以外のファイルも処理できます。

XML形式の場合

ファイル操作アダプタ定義ファイルでレコードとして扱う要素を指定します。

注意事項

入力ファイルおよび出力ファイルのサイズに制限はありません。ただし，入力ファイルおよび出力ファイルの1レコードのサイズが500MB以上のファイルは入力ファイルの形式に関係なく変換できません。1レコードのサイズが500MB以上のファイルを変換した場合，動作を保証しません。また，レコードを構成する1要素のサイズについても，入力ファイルの形式に関係なく，500MB以上を超える場合は動作を保証しません。

(b)　対象とするデータフォーマット

分割処理方式で対象とする入力ファイルのデータフォーマットは，バイナリフォーマット定義およびXMLスキーマです。また，対象とするデータ構造は，ヘッダレコード部，データレコード部，トレーラレコード部がこの順番で出現する構造である必要があります。

データレコード部は，決められた要素の並びが連続して繰り返されている構造を持ったデータです。データベースのテーブル構造と同じで，決められた要素の並び（バイナリ形式の場合は行，XML形式の場合は特定の要素以下のデータ）をレコードと呼び，これがn回繰り返されているイメージです。レコード内の要素数およびレコード数に制限はありません。

ヘッダレコード部およびトレーラレコード部は，任意の要素が並ぶ複合内容要素で，レコードが繰り返されることはありません。また，これらの部分は省略できます。

データファイル構造とデータレコード部のイメージを次に示します。

図8‒36　データファイル構造

図8‒37　データレコード部のイメージ

データフォーマットはバイナリ形式（固定長形式，改行セパレータ形式，およびEORセパレータ形式），およびXML形式に対応します。また，入力および出力フォーマットとも上記の形式の構造であることが必要です。

バイナリ形式のデータの例を次に示します。

図8‒38　固定長形式のデータ例

図8‒39　改行セパレータ形式のデータ例

図8‒40　EORセパレータ形式のデータ例（EORコードが「/（0x2F）」の場合）

(c)　分割処理方式で必要なファイル

分割処理方式で定義が必要なバイナリフォーマット定義，XMLスキーマ，およびデータ変換定義を次に示します。

バイナリフォーマット定義およびXMLスキーマ

入力ファイルおよび出力ファイルの形式によって必要な定義が異なります。

入力ファイルまたは出力ファイルがバイナリ形式の場合

入力側と出力側のファイルフォーマットを定義する必要があるため，バイナリフォーマット定義エディタを使用して次のうち必要なフォーマットを作成します。

入力側のヘッダレコード部のフォーマット

入力側のデータレコード部のフォーマット

入力側のトレーラレコード部のフォーマット

出力側のヘッダレコード部のフォーマット

出力側のデータレコード部のフォーマット

出力側のトレーラレコード部のフォーマット

入力ファイルまたは出力ファイルがXML形式の場合

入力側と出力側のXMLスキーマを作成します。バイナリ形式と異なり，1つのXMLスキーマで，ヘッダレコード，データレコード，およびトレーラレコードを定義することができます。XMLスキーマはデータ変換定義を作成するために必要となりますが，変換オペレーションの実行時には使用しません。

データ変換定義

入力側と出力側のフォーマット間のデータ変換を定義する必要があるため，マッピング定義エディタを使用して次のデータ変換定義を作成してください。

ヘッダレコード部のデータ変換定義

データレコード部のデータ変換定義

トレーラレコード部のデータ変換定義

なお，出力側がXML形式の場合，マッピング対象を指定した複合内容要素の配下に制限をしてマッピングできます。1つのXMLスキーマにヘッダレコード，データレコード，およびトレーラレコードを定義した場合，各レコードのルート要素となる複合内容要素の配下に制限してマッピングすることで，各レコード部のデータ変換定義を生成できます。詳細はマニュアル「サービスプラットフォーム開発ガイド 基本開発編」の「7.4.8　マッピング対象の範囲を限定する」を参照してください。

(d)　レコードの分割（入力ファイルがバイナリ形式の場合）

レコード単位の判定方法

レコードの区切りの判定は，固定長形式，改行セパレータ形式，またはEORセパレータ形式から選択して指定できます。

固定長形式，改行セパレータ形式，またはEORセパレータ形式の種類は，ファイル操作アダプタ定義ファイルの次のパラメタで指定してください。

csc.adapter.fileOperation.transform.format

内容については，マニュアル「サービスプラットフォーム リファレンス」の「3.5.2　ファイル操作アダプタ定義ファイル」を参照してください。

固定長形式の場合

レコードの区切りは，ファイル操作アダプタ定義ファイルの次のパラメタに指定した個所です。

・csc.adapter.fileOperation.transform.header.fixedSize

・csc.adapter.fileOperation.transform.data.fixedSize

・csc.adapter.fileOperation.transform.trailer.fixedSize

改行セパレータ形式の場合

レコードの区切りは，入力ファイルに改行コード（LF（0x0a）またはCR+LF（0x0d 0x0a））が出現する個所です。ファイル終端もレコードの区切りとして扱われます。なお，改行直後にファイルの終端が出現する場合は，直前の改行と合わせて1つのレコードセパレータとして扱われます。

EORセパレータ形式の場合

レコードの区切りは，ファイル操作アダプタ定義ファイルに設定したEORコードが出現する個所です。EORコードはcsc.adapter.fileOperation.transform.EORプロパティに16進数で設定します。16進数の先頭には「0x」を付与しません。

EORコードが「/（0x2F）」の場合の設定例を次に示します。

・csc.adapter.fileOperation.transform.EOR=2F

EORコードが出現した個所までのデータが1レコードとして扱われます。また，ファイルの終端もレコードの区切りとして扱われます。なお，EORコードが出現した直後にファイルの終端があった場合，EORコードが出現した個所までのデータが最終レコードとして扱われます。

レコード部の位置と長さ

分割処理方式の場合，現在読み込まれているレコードが，ヘッダレコード部，データレコード部，トレーラレコード部のうちどれなのかを判定する必要があります。固定長形式，改行セパレータ形式，またはEORセパレータ形式ごとに，レコード部の位置と長さを判定する方法を次に示します。

固定長形式の場合

レコード部の位置と長さの判定について，次の表に示します。

表8‒14　レコード有無指定によるレコード種別（固定長形式）

レコード

有無指定

ヘッダレコード部

指定有無

有

有

無

無

トレーラレコード部

指定有無

有

無

有

無

レコード部の位置と長さ

ヘッダレコード部

ファイル先頭

〜

ヘッダレコード長

ファイル先頭

〜

ヘッダレコード長

−

−

データレコード部

ヘッダレコード部

終了位置

〜

データレコード長

＊データレコード数

ヘッダレコード部

終了位置

〜

データレコード長

＊データレコード数

ファイル先頭

〜

データレコード長

＊データレコード数

ファイル先頭

〜

データレコード長

＊データレコード数

トレーラレコード部

データレコード部

終了位置

〜

トレーラレコード長

−

データレコード部

終了位置

〜

トレーラレコード長

−

（凡例）

−：該当しません。

データレコード数は，次の計算式に従って算出します。

データレコード部サイズ＝データファイルサイズ −（ヘッダレコード長＋トレーラレコード長）

レコード数 ＝ データレコード部サイズ／データレコード長（小数点以下切り捨て）

レコード数の計算結果にあまりがある場合，メッセージ（KDEC80045-W）が出力されたあと，処理が継続されます。この場合，次に示すような可能性があるため，確認して原因を取り除いてください。

・入力ファイルの末尾にEODがある。

・入力ファイルに誤りがある。

・ファイル操作アダプタ定義ファイルの次の項目の設定に誤りがある。

　　csc.adapter.fileOperation.transform.headerRecord

　　csc.adapter.fileOperation.transform.trailerRecord

　　csc.adapter.fileOperation.transform.header.fixedSize

　　csc.adapter.fileOperation.transform.data.fixedSize

　　csc.adapter.fileOperation.transform.trailer.fixedSize

改行セパレータ形式およびEORセパレータ形式の場合

レコード部の位置と長さの判定について，次の表に示します。

表8‒15　レコード有無指定によるレコード種別（改行セパレータ形式）

レコード

有無指定

ヘッダレコード部

指定有無

有

有

無

無

トレーラレコード部

指定有無

有

無

有

無

レコード部の位置と長さ

ヘッダレコード部

先頭行

先頭行

−

−

データレコード部

先頭行以降

〜

最終行直前

先頭行以降

〜

最終行

先頭行

〜

最終行直前

先頭行

〜

最終行

トレーラレコード部

最終行

−

最終行

−

（凡例）

−：該当しません。

メッセージ（KDEC80047-E）が出力されて処理が終了された場合，次に示すような可能性があるため，確認して原因を取り除いてください。

・入力ファイルのレコード数が不足している。

・ファイル操作アダプタ定義ファイルの次の項目の設定に誤りがある。

　　csc.adapter.fileOperation.transform.headerRecord

　　csc.adapter.fileOperation.transform.trailerRecord

表8‒16　エラー判定パターン

ヘッダレコード部

トレーラレコード部

変換するファイルの行数

有

有

1行以下

有

無

0行以下

無

有

0行以下

(e)　レコードの分割（入力ファイルがXML形式の場合）

入力XMLファイルのヘッダレコード，データレコード，およびトレーラレコードのレコード区切りを指定するには，ファイル操作アダプタ定義ファイルに読み込む要素のパスを設定します。

ファイル操作アダプタ定義ファイルの設定項目と設定内容を次の表に示します。

表8‒17　ファイル操作アダプタ定義ファイルの設定（入力XMLファイルの分割入力）

設定項目

設定内容

csc.adapter.fileOperation.transform.header.inElement

入力XMLファイルのヘッダレコードに対応する要素のパスを指定します。

ヘッダレコードを使用しない場合，指定は不要です（指定しても無視されます）。

csc.adapter.fileOperation.transform.data.inElement

入力XMLファイルのデータレコードに対応する要素のパスを指定します。

csc.adapter.fileOperation.transform.trailer.inElement

入力XMLファイルのトレーラレコードに対応する要素のパスを指定します。

トレーラレコードを使用しない場合，指定は必要ありません（指定しても無視されます）。

入力XMLファイルとファイル操作アダプタ定義ファイルの設定例を示します。

図8‒41　入力XMLファイルとファイル操作アダプタ定義ファイルの設定例

(f)　レコードのマージ（出力ファイルがXML形式の場合）

入力ファイルが分割処理方式の場合，各レコードの変換結果を1つのXMLファイルにマージするための出力用テンプレートXMLファイルを使用します。

出力用テンプレートXMLファイルの内容は，「(b) 対象とするデータフォーマット」で作成した出力XMLスキーマに沿った形式である必要があります。整形式のXML文書でない場合，変換時にエラーとなります。

出力用テンプレートXMLファイルの仕様を次の表に示します。

表8‒18　出力用テンプレートXMLファイルの仕様

項目

仕様

ファイル名

ファイル操作アダプタ定義ファイルのcsc.adapter.fileOperation.transform.outputTemplateXmlFileプロパティで指定したファイル名

文字エンコーディング

UTF-8

出力用テンプレートXMLファイル中の特定の要素をレコード（出力データ）に置き換えて，出力XMLファイルが作成されます。

レコードに置き換える要素は，ファイル操作アダプタ定義ファイルで指定します。ファイル操作アダプタ定義ファイルの設定項目と設定内容を次の表に示します。

表8‒19　ファイル操作アダプタ定義ファイルの設定（出力XMLファイルのマージ）

設定項目

設定内容

csc.adapter.fileOperation.transform.header.outElement

出力XMLファイルのヘッダレコードに対応する要素のパスを指定します。

ヘッダレコードを使用しない場合，指定は不要です（指定しても無視されます）。

csc.adapter.fileOperation.transform.data.outElement

出力XMLファイルのデータレコードに対応する要素のパスを指定します。

csc.adapter.fileOperation.transform.trailer.outElement

出力XMLファイルのトレーラレコードに対応する要素のパスを指定します。

トレーラレコードを使用しない場合，指定は必要ありません（指定しても無視されます）。

出力用テンプレートXMLファイル，およびファイル操作アダプタ定義ファイルの設定例を次の図に示します。

図8‒42　出力用テンプレートXMLファイルとファイル操作アダプタ定義ファイルの設定例

出力用テンプレートXMLファイルを出力XMLファイルに変換した例を次の図に示します。なお，この例では出力XMLファイルの改行や空白を表示していますが，実際の出力XMLファイルでは，要素の間の改行や空白は削除されます。

図8‒43　XMLファイルの出力例

出力用テンプレートXMLファイルを使用した出力XMLファイルは，次の表に示す形式で出力されます。

表8‒20　出力XMLファイルの形式

項目

仕様

文字エンコーディング

UTF-8

要素の間のスペース

削除されます。

要素の間の改行

削除されます。

名前空間宣言

出力用テンプレートXMLファイルの名前空間宣言を引き継ぎます。

未使用の名前空間宣言は削除されません。

不足している名前空間宣言は，入力XMLの宣言で補われます。

ファイルの内容

出力XMLスキーマに沿ったXMLが出力されます。出力XMLスキーマとの整合性は検証されません。

注意事項

XML Processorがサポートしていない文字エンコーディングが指定されている場合，解析処理でエラーとなります。XML Processorがサポートしている文字エンコーディングについては，マニュアル「XML Processor ユーザーズガイド」の「1.3.2　処理できる文字コード」を参照してください。

出力用テンプレートXMLファイルに，ヘッダ，データ，トレーラのどのレコードにも該当しない要素が定義されている場合，値も含めてそのまま出力されます。値の前後に空白がある場合も空白は取り除かれません。

データレコードは，最初に出現した要素，および連続して出現する兄弟要素が1つのデータレコード群として扱われます。データレコード群が終了したあとに再びデータレコードが出現した場合，エラーとなります。

出力用テンプレートXMLファイルの内容が「(b) 対象とするデータフォーマット」で作成した出力XMLスキーマに沿った形式でない場合，レコードに置き換える要素に出力用テンプレートXMLファイルに存在する正しい値を指定しても，レコードの変換結果は置き換えられないで処理が終了します。この場合，実行時エラーとなりません。このため，入力データがデータ変換定義で出力されるように設定していても，レコードの変換結果が出力ファイルに出力されない場合は，出力XMLスキーマと出力用テンプレートXMLファイルの内容を見直してください。

(g)　複数のデータレコードの同時変換

ファイル変換オペレーションでは，分割処理方式を選択した場合に，複数のデータレコードをまとめて1要素として変換することができます。入力ファイルがバイナリ形式またはXML形式のどちらの場合でも変換できます。

入力ファイルがバイナリ形式，かつデータレコードの総数が6で，2つのデータレコードを1要素として変換する場合の例を次に示します。

図8‒44　2つのデータレコードを1要素として変換する例（固定長形式の場合）

図8‒45　2つのデータレコードを1要素として変換する例（改行セパレータ形式の場合）

参考

改行セパレータ形式の場合，データレコードの改行を含めて変換されます。

図8‒46　2つのデータレコードを1要素として変換する例（EORセパレータ形式の場合）

参考

EORセパレータ形式の場合，データレコードのEORコードを含めて変換されます。そのため，入力ファイルのバイナリフォーマット定義では，EORコードを含めたデータ構造を定義する必要があります。なお，1レコードずつ変換する場合は，変換対象のデータにEORコードは含まれません。

図8‒47　1レコードずつ変換する例（EORセパレータ形式の場合）

1要素（同時に変換するレコード数）の設定は，ファイル操作アダプタ定義ファイルの次のパラメタで指定します。

csc.adapter.fileOperation.transform.data.batchSize

パラメタの内容については，マニュアル「サービスプラットフォーム リファレンス」の「3.5.2　ファイル操作アダプタ定義ファイル」を参照してください。

注意事項

複数のデータレコードを同時変換すると変換効率の向上が図れますが，1要素を大きくしてしまうと処理性能が劣化することがあります。1要素当たりのデータサイズの上限は500MBを目安にして，同時に変換するレコード数を適切に設定してください。

データレコードの総数が，パラメタに設定した値で割り切れなかった場合は，余ったレコードを一度に変換します。

変換例として，データレコードの総数が6で，4つのデータレコードを1要素として変換する場合の例を次に示します。

図8‒48　1要素に指定した値で割り切れなかった場合の変換例

(h)　複数のヘッダレコードの同時変換

次の条件をすべて満たす場合，複数のヘッダレコードをまとめて1要素として変換することができます。

入力ファイルのデータ種別がバイナリ形式である

分割処理方式を指定している

レコードの判定方式に改行セパレータ形式，またはEORセパレータ形式を指定している

ヘッダレコードが存在する

変換するヘッダレコード数は，ファイル操作アダプタ定義ファイルのcsc.adapter.fileOperation.transform.header.batchSizeプロパティで指定できます。

次の条件では変換時にエラーになる場合があります。

データ中のヘッダレコードが多い

ファイル操作アダプタ定義ファイルのcsc.adapter.fileOperation.transform.header.batchSizeプロパティの指定より入力データのヘッダレコードの数が多い場合，ヘッダレコードの一部がデータレコードと見なされ，変換エラーになることがあります。

データ中のヘッダレコードが少ない

ファイル操作アダプタ定義ファイルのcsc.adapter.fileOperation.transform.header.batchSizeプロパティの指定より入力データのヘッダレコードの数が少ない場合，データレコードの一部がヘッダレコードと見なされ，変換エラーになることがあります。

入力データの全レコード数が指定したレコードに満たない

入力データ中の全レコード数が，ファイル操作アダプタ定義ファイルのcsc.adapter.fileOperation.transform.header.batchSizeプロパティの指定に満たない場合は，エラー（KDEC80047-E）が発生します。

(5)　変換するファイル形式の指定方法

ファイル変換オペレーションで読み込むファイルや書き込むファイルの形式は，あらかじめバイナリフォーマット定義画面でバイナリフォーマット定義ファイルを作成したあと，ファイル操作アダプタの独自定義ファイルとして指定してください。

バイナリフォーマット定義画面の詳細は，マニュアル「サービスプラットフォーム リファレンス」の「1.2.1　バイナリフォーマット定義画面」を参照してください。

バイナリフォーマット定義ファイルの作成については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「4.4　電文フォーマット（バイナリフォーマット定義ファイル）の作成方法」を参照してください。

ファイル操作アダプタの独自定義ファイルの指定については，マニュアル「サービスプラットフォーム リファレンス」の「3.5.2　ファイル操作アダプタ定義ファイル」を参照してください。

(6)　データ変換定義の指定方法

あらかじめ作成した入力ファイルから出力ファイルへ変換するデータ変換定義ファイル（xslファイル）を，ファイル操作アダプタの独自定義ファイルとして指定します。

開発環境のマッピング定義エディタでマッピング定義ファイルを作成するときに，データ変換定義を利用してxslファイルを作成してください。ファイル操作アダプタの独自定義ファイルの指定については，マニュアル「サービスプラットフォーム リファレンス」の「3.5.2　ファイル操作アダプタ定義ファイル」を参照してください。

(7)　文字コード変換UOCを使用したファイルの変換

ファイル変換オペレーションでは，ファイルの変換に文字コード変換UOCを使用できます。

文字コード変換UOCを使用する場合は，サービスアダプタ定義画面（詳細）の独自定義ファイルに，次のファイルを設定する必要があります。

入力ファイルと出力ファイルの変換で同じ独自定義ファイルを使用する場合

csc_owncodeconvert.properties

入力ファイルと出力ファイルの変換で別々の独自定義ファイルを使用する場合

csc_owncodeconvert_in.properties

csc_owncodeconvert_out.properties

1.で示したファイルと2.で示したファイルとを同時に指定した場合，1.で示したファイルが優先され，2.で示したファイルは無視されます。

サービスアダプタ定義画面（詳細）の設定方法については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.11　ファイル操作アダプタを定義する」のファイル変換オペレーションについて説明している個所を参照してください。

文字コード変換UOCの概要および実装方法については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「付録H　文字コード変換UOCを利用した文字コード変換」を参照してください。

(8)　分割処理方式での独自定義ファイルの指定

ファイル変換オペレーションで分割処理方式の変換をする場合に必要な独自定義ファイル，および指定が必要なファイル操作アダプタ定義ファイルのプロパティの一覧を次の表に示します。ファイル操作アダプタ定義ファイルの詳細は，マニュアル「サービスプラットフォームリファレンス」の「3.5.2　ファイル操作アダプタ定義ファイル」を参照してください。

表8‒21　分割処理方式で指定が必要な独自定義ファイルとファイル操作アダプタ定義ファイルのプロパティ

独自定義ファイルとして指定するファイル

入力ファイル

出力ファイル

バイナリ

XML

バイナリ

XML

ヘッダ用レイアウト変換用XSLTファイル

○※1

○※1

○※1

○※1

データ用レイアウト変換用XSLTファイル

○

○

○

○

トレーラ用レイアウト変換用XSLTファイル

○※2

○※2

○※2

○※2

入力ヘッダ用FDXファイル

○※1

−

−

−

入力データ用FDXファイル

○

−

−

−

入力トレーラ用FDXファイル

○※2

−

−

−

入力ヘッダ用XMLスキーマファイル

−

−

−

−

入力データ用XMLスキーマファイル

−

−

−

−

入力トレーラ用XMLスキーマファイル

−

−

−

−

ファイル操作アダプタ定義ファイルに指定するプロパティ

csc.adapter.fileOperation.transform.input

（入力ファイル種別）

○

○

−

−

csc.adapter.fileOperation.transform.output

（出力ファイル種別）

−

−

○

○

csc.adapter.fileOperation.transform.headerRecord

（ヘッダレコード使用有無）

○※1

○※1

○※1

○※1

csc.adapter.fileOperation.transform.trailerRecord

（トレーラレコード使用有無）

○※2

○※2

○※2

○※2

csc.adapter.fileOperation.transform.header.inElement

（入力ヘッダ要素名）

−

○※1

−

−

csc.adapter.fileOperation.transform.data.inElement

（入力データ要素名）

−

○

−

−

csc.adapter.fileOperation.transform.trailer.inElement

（入力トレーラ要素名）

−

○※2

−

−

csc.adapter.fileOperation.transform.header.outElement

（出力ヘッダ要素名）

−

−

−

○※1

csc.adapter.fileOperation.transform.data.outElement

（出力データ要素名）

−

−

−

○

csc.adapter.fileOperation.transform.trailer.outElement

（出力トレーラ要素名）

−

−

−

○※2

csc.adapter.fileOperation.transform.outputTemplateXmlFile

（出力用テンプレートXMLファイルのファイル名）

−

−

−

○

出力ヘッダ用FDXファイル

−

−

○※1

−

出力データ用FDXファイル

−

−

○

−

出力トレーラ用FDXファイル

−

−

○※2

−

出力ヘッダ用XMLスキーマファイル

−

−

−

−

出力データ用XMLスキーマファイル

−

−

−

−

出力トレーラ用XMLスキーマファイル

−

−

−

−

出力用テンプレートXMLファイル

−

−

−

○

文字コード変換UOC用入力プロパティ（入力・出力ファイル共通）

csc_owncodeconvert.properties

○※3

−

○※3

−

文字コード変換UOC用入力プロパティ（入力ファイル変換用）

csc_owncodeconvert_in.properties

○※3

−

−

−

文字コード変換UOC用入力プロパティ（出力ファイル変換用）

csc_owncodeconvert_out.properties

−

−

○※3

−

（凡例）

○：必ず指定します。

−：指定は不要です。

注※1

ヘッダレコードを使用する場合だけ指定します。

注※2

トレーラレコードを使用する場合だけ指定します。

注※3

文字コード変換UOCを使用する場合に指定します。

8.7.4　ファイル複製オペレーション

ここでは，ファイル複製オペレーションでサポートする機能やファイル形式について説明します。

(1)　ファイル複製オペレーションの機能概要

ファイル複製オペレーションは，作業フォルダまたは共通フォルダから複製元の入力ファイルを読み込み，複製後の出力ファイルを作業フォルダまたは共通フォルダに書き込みます。ファイル複製オペレーションの処理の概要について，次の図に示します。

図8‒49　ファイル複製オペレーションの処理

(2)　サポートするファイル形式

ファイル複製オペレーションの複製対象となる入力ファイル，および出力ファイルのファイル形式は問いません。作業フォルダまたは共通フォルダ内に存在するファイルはすべて複製できます。

8.7.5　ファイル移動オペレーション

ここでは，ファイル移動オペレーションでサポートする機能やファイル形式について説明します。

(1)　ファイル移動オペレーションの機能概要

ファイル移動オペレーションは，作業フォルダまたは共通フォルダのファイルを，指定した作業フォルダまたは共通フォルダへ移動します。

ファイル移動オペレーションの処理の概要について，次の図に示します。

図8‒50　ファイル移動オペレーションの処理

(2)　サポートするファイル形式

ファイル移動オペレーションの移動対象となるファイルのファイル形式は問いません。作業フォルダまたは共通フォルダ内に存在するファイルはすべて移動できます。

ディレクトリは移動できません。

(3)　ファイル移動オペレーションの注意事項

ファイル移動オペレーションの注意事項を次に示します。

移動先のファイルが共通フォルダにある場合でも，占有ロックは取得しません。

移動に成功したファイルは移動元の最終更新日時を保持します。

別ドライブ間の移動に要する処理時間はファイルシステムの性質上，コピー＆削除になるため，ファイル複製オペレーションよりも長くなります。

8.7.6　ファイル・フォルダ削除オペレーション

ここでは，ファイル・フォルダ削除オペレーションでサポートする機能やファイル形式について説明します。

(1)　ファイル・フォルダ削除オペレーションの機能概要

ファイル・フォルダ削除オペレーションは，次の処理を実施します。

作業フォルダの削除

共通フォルダ内の単一ファイルの削除

共通フォルダ内のサブフォルダの削除

ファイル・フォルダ削除オペレーションの処理の概要について，次の図に示します。

図8‒51　ファイル・フォルダ削除オペレーションの処理

(2)　サポートするファイル形式

ファイル削除オペレーションの削除対象となるファイルの形式は問いません。共通フォルダ内に存在する任意のファイルを削除できます。

(3)　作業フォルダの削除

フォルダ削除オペレーションでは，要求電文で指定したリクエストIDに基づいて生成される作業フォルダを削除します。対象の作業フォルダ以下のファイルおよびフォルダはすべて削除されます。

(4)　共通フォルダ内の単一ファイルの削除

要求電文で指定した共通フォルダ内のファイルを削除します。削除されるのは，対象の共通フォルダ内の指定したファイル1つだけです。

(5)　共通フォルダ内のサブフォルダの削除

要求電文で指定した共通フォルダ内のサブフォルダを削除します。削除されるのは，対象の共通フォルダ内の指定したサブフォルダ1つだけです。

(6)　ファイル・フォルダ削除オペレーションの注意事項

ファイル・フォルダ削除オペレーションの注意事項を次に示します。

フォルダを削除するオペレーションを，削除対象のフォルダ下のファイルをアクセス中に，実行しないでください。動作を保証しません。

8.7.7　ファイル圧縮オペレーション

ここでは，ファイル圧縮オペレーションでサポートする機能やファイル形式について説明します。

(1)　ファイル圧縮オペレーションの機能概要

ファイル圧縮オペレーションは，作業フォルダまたは共通フォルダから圧縮元の入力ファイルを読み込み，圧縮後の出力ファイルを作業フォルダまたは共通フォルダに書き込みます。

ファイル圧縮オペレーションの処理の概要について，次の図に示します。

図8‒52　ファイル圧縮オペレーションの処理

(2)　サポートするファイル形式

ファイル圧縮オペレーションでサポートするファイル形式を次に示します。なお，ディレクトリの圧縮はサポートしていません。入力ファイルにディレクトリを指定した場合，エラーメッセージ（KDEC80035-E）が出力され，ファイル圧縮オペレーションが中止されます。

表8‒22　ファイル圧縮オペレーションでサポートするファイル形式

ファイル形式

入力ファイル

出力ファイル

ZIP形式※

○

○

上記以外

○

×

（凡例）

○：サポートしています。

×：サポートしていません。

注※

DEFLATE圧縮アルゴリズムを使用して圧縮されたZIP形式だけをサポートします。

ファイル圧縮オペレーションを使用する際の，入出力ファイルに関する制限事項を次に示します。

表8‒23　ファイル圧縮オペレーション使用時の制限事項

項目

制限事項

入力ファイル名

次に示す半角の英数字と記号だけが使用できます。

英数字

英字（a〜z，A〜Z）と数字（0〜9）を使用できます。

なお，サブフォルダ名については，上記の制限はありません。

出力ファイルのエントリ名

制限事項は入力ファイル名と同様です。

入力ファイル数

入力ファイル数は1〜999の範囲で指定できます。これを満たさない場合の動作は保証しません。

単一の入力元フォルダに存在する複数の入力ファイルを圧縮できますが，複数の入力元フォルダを指定することはできません。

入力ファイルのファイルサイズ

入力ファイルの最大ファイルサイズの初期値は4GBです。

入力ファイルの最大ファイルサイズを設定するには，ファイルの圧縮を打ち切る入力ファイルのサイズのパラメタ（ファイル操作アダプタ実行環境プロパティファイルのcompress.inputfile.limitsize）を指定してください。

出力ファイルのファイルサイズ

出力ファイルの最大ファイルサイズの初期値は4GBです。

出力ファイルの最大ファイルサイズを設定するには，ファイルの圧縮を打ち切る出力ファイルのサイズのパラメタ（ファイル操作アダプタ実行環境プロパティファイルのcompress.outputfile.limitsize）を指定してください。

ファイル操作アダプタ実行環境プロパティファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.8　ファイル操作アダプタ実行環境プロパティファイル」を参照してください。

8.7.8　ファイル伸張オペレーション

ここでは，ファイル伸張オペレーションでサポートする機能やファイル形式について説明します。

(1)　ファイル伸張オペレーションの機能概要

ファイル伸張オペレーションは，作業フォルダまたは共通フォルダから伸張元の入力ファイルを読み込み，伸張後の出力ファイルを作業フォルダまたは共通フォルダに書き込みます。

ファイル伸張オペレーションの処理の概要を次の図に示します。

図8‒53　ファイル伸張オペレーションの処理

(2)　サポートするファイル形式

ファイル伸張オペレーションでサポートするファイル形式を次に示します。ディレクトリが格納されたZIPファイルの伸張はサポートしていません。入力ファイルにディレクトリが格納されたZIPファイルを指定した場合，エラーメッセージ（KDEC80123-E）を出力し，ファイル伸張オペレーションが中止されます。

表8‒24　ファイル伸張オペレーションでサポートするファイル形式

ファイル形式

入力ファイル

出力ファイル

ZIP形式※

○

○

上記以外

×

○

（凡例）

○：サポートしています。

×：サポートしていません。

注※

DEFLATE圧縮アルゴリズムを使用して圧縮されたZIP形式だけをサポートします。

ファイル伸張オペレーションを使用する際の，入出力ファイルに関する制限事項を次に示します。

表8‒25　ファイル伸張オペレーション使用時の制限事項

項目

制限事項

入力ファイルのエントリ名

次に示す半角の英数字と記号だけが使用できます。

英数字

英字（a〜z，A〜Z）と数字（0〜9）を使用できます。

出力ファイル名

出力ファイル名は，要求電文に定義された出力ファイル名の接頭辞を使用して自動的に付与されます。

出力ファイル数

伸張後の出力ファイル数は1〜999を制限とします。これを満たさない場合，エラーメッセージ（KDEC80125-E）を出力し，ファイル伸張オペレーションを中止します。

複数の出力ファイルを単一の出力先フォルダへ伸張することはできますが，複数の出力先フォルダを指定することはできません。

入力ファイルのファイルサイズ

入力ファイルの最大ファイルサイズの初期値は4GBです。

入力ファイルの最大ファイルサイズを設定するには，ファイルの伸張を打ち切る入力ファイルのサイズのパラメタ（ファイル操作アダプタ実行環境プロパティファイルのextract.inputfile.limitsize）を指定してください。

出力ファイルのファイルサイズ

出力ファイルの最大ファイルサイズの初期値は4GBです。

出力ファイルの最大ファイルサイズを設定するには，ファイルの伸張を打ち切る出力ファイルのサイズのパラメタ（ファイル操作アダプタ実行環境プロパティファイルのextract.outputfile.limitsize）を指定してください。

ファイル操作アダプタ実行環境プロパティファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.8　ファイル操作アダプタ実行環境プロパティファイル」を参照してください。

8.7.9　ファイル一覧取得オペレーション

ここでは，ファイル一覧取得オペレーションでサポートする機能やファイル形式について説明します。

(1)　ファイル一覧取得オペレーションの機能概要

ファイル一覧取得オペレーションは，共通フォルダからファイル一覧情報を取得し，一覧情報を応答電文で返します。一覧取得元にファイルが指定された場合は，指定されたファイルだけを返します。一覧取得元にディレクトリが指定された場合は，指定されたディレクトリの直下のファイル・ディレクトリだけを返します。

ファイル一覧取得オペレーションの処理の概要について，次の図に示します。

図8‒54　ファイル一覧取得オペレーションの処理

(2)　一覧取得元に指定可能な対象

ファイル一覧取得オペレーションで一覧取得元に指定可能な対象を次に示します。

表8‒26　一覧取得元に指定可能な対象

一覧取得元に指定可能な対象

サポート

作業フォルダ

ファイル

×

作業フォルダ自体

×

共通フォルダ

ファイル

○

共通フォルダ自体

○

サブフォルダ

○

（凡例）

○：サポートしています。

×：サポートしていません。

(3)　一覧取得で取得可能な対象

一覧取得元の共通フォルダで取得可能な対象を次に示します。

表8‒27　一覧取得で取得可能な対象

一覧取得で取得可能な対象

サポート

直下のファイル

通常ファイル

○

隠しファイル

○

シンボリックリンク

○

直下のサブフォルダ※1

通常ディレクトリ

○

隠しディレクトリ※2

○

シンボリックリンク

○

（凡例）

○：サポートしています。

注※1

再帰的な取得はしません。

注※2

「.」（カレントディレクトリ），「..」（1つ上のディレクトリ）は対象外です。

(4)　ファイル一覧取得オペレーションの注意事項

ファイル一覧取得オペレーションの注意事項を次に示します。

一覧取得元がディレクトリの場合，一覧取得元ディレクトリとその直下のファイル・ディレクトリのロックは取得しません。

ファイル一覧の最終更新日時はローカルタイムとなります。

一覧取得元が存在しない場合，空の一覧情報を返します。

8.7.10　ファイル一覧書き込みオペレーション

ここでは，ファイル一覧書き込みオペレーションでサポートする機能やファイル形式について説明します。

(1)　ファイル一覧書き込みオペレーションの機能概要

ファイル一覧書き込みオペレーションは，共通フォルダからファイル一覧情報を取得し，一覧情報をファイルに書き込みます。一覧取得元にファイルが指定された場合は，指定されたファイルだけを返します。一覧取得元にディレクトリが指定された場合は，指定されたディレクトリの直下のファイル・ディレクトリだけを返します。

ファイル一覧書き込みオペレーションの処理の概要について，次の図に示します。

図8‒55　ファイル一覧書き込みオペレーションの処理

(2)　一覧取得元に指定可能な対象

ファイル一覧書き込みオペレーションで一覧取得元に指定可能な対象を次に示します。

表8‒28　一覧取得元に指定可能な対象

一覧取得元に指定可能な対象

サポート

作業フォルダ

ファイル

×

作業フォルダ自体

×

共通フォルダ

ファイル

○

共通フォルダ自体

○

サブフォルダ

○

（凡例）

○：サポートしています。

×：サポートしていません。

(3)　一覧取得で取得可能な対象

一覧取得元の共通フォルダで取得可能な対象を次に示します。

表8‒29　一覧取得で取得可能な対象

一覧取得で取得可能な対象

サポート

直下のファイル

通常ファイル

○

隠しファイル

○

シンボリックリンク

○

直下のサブフォルダ※1

通常ディレクトリ

○

隠しディレクトリ※2

○

シンボリックリンク

○

（凡例）

○：サポートしています。

注※1

再帰的な取得はしません。

注※2

「.」（カレントディレクトリ），「..」（1つ上のディレクトリ）は対象外です。

(4)　出力するファイル形式

出力するファイルの文字コードは，UTF-16（ビッグエンディアン，BOMあり）です。取得したファイル一覧が空の場合は，BOMだけを出力します。

全項目を出力する場合（要求電文list-optionでlが指定された場合）のファイル出力形式を次に示します。

表8‒30　ファイル出力形式（全項目）

列順

列名

列サイズ

（バイト）

出力形式※1

左右寄せ

1

ファイル種別

2※2

fもしくはd※3

左

2

ファイルサイズ

40※2

ファイルサイズの数値文字列※4

右

3

最終更新日時

出力形式のバイト※2

ユーザ指定形式

左

4

ファイル名

可変長※5

ファイル名文字列

左

注※1

埋め時は半角スペース。

注※2

別途，末尾に半角スペース（2バイト）が必ず1個付与されます。

注※3

f：ファイル，d：ディレクトリ。

注※4

ディレクトリの場合，値は0になります。

注※5

別途，末尾にOS依存の改行コードが付与されます。

ファイル名だけを出力する場合（要求電文list-optionでlが指定された場合）のファイル出力形式を次に示します。

表8‒31　ファイル出力形式（ファイル名のみ）

列順

列名

列サイズ

（バイト）

出力形式

左右寄せ

1

ファイル名

可変長※

ファイル名文字列

左

注※

別途，末尾にOS依存の改行コードが付与されます。

(5)　ファイル一覧書き込みオペレーションの注意事項

ファイル一覧書き込みオペレーションの注意事項を次に示します。

一覧取得元がディレクトリの場合，一覧取得元ディレクトリとその直下のファイル・ディレクトリのロックは取得しません。

ファイル一覧の最終更新日時はローカルタイムとなります。

一覧取得元が存在しない場合，空の一覧情報を出力します。

最終更新日時の列サイズは要求電文date-time-pattern要素で指定したパターン文字列とサーバロケールに依存します。そのため，長さが可変になるパターン文字列を指定した場合（H，EEEE，d，Dなど），ファイルごとに列サイズが異なる可能性があります。

8.7.11　ファイル読み込みオペレーション

ここでは，ファイル読み込みオペレーションでサポートする機能について説明します。

(1)　ファイル読み込みオペレーションの機能概要

ファイル読み込みオペレーションは，作業フォルダ（または共通フォルダ）からファイルを読み込み，ほかのサービスに渡します。

ファイル読み込みオペレーションの処理の概要について，次の図に示します。

図8‒56　ファイル読み込みオペレーションの処理

(2)　ファイル読み込みオペレーションの注意事項

ファイル読み込みオペレーションの注意事項を次に示します。

入力ファイルが0バイトの場合は，0バイトのデータを返します。

入力ファイルの内容がそのまま応答電文になるため，サービスプラットフォームではスキーマファイルを提供していません。スキーマファイルはユーザが作成してください。

8.7.12　ファイル書き込みオペレーション

ここでは，ファイル書き込みオペレーションでサポートする機能やファイル形式について説明します。

(1)　ファイル書き込みオペレーションの機能概要

ファイル書き込みオペレーションは，他サービスから取得したデータを，作業フォルダ（または共通フォルダ）に書き込みます。

ファイル書き込みオペレーションの処理の概要について，次の図に示します。

図8‒57　ファイル書き込みオペレーションの処理

(2)　要求電文のヘッダを省略した場合の動作

要求電文のヘッダを省略した場合，ファイル操作アダプタ実行環境プロパティファイルの指定に従って，ファイルを出力します。ファイル操作アダプタ実行環境プロパティファイルには，共通フォルダだけ指定できます。

表8‒32　ファイル操作アダプタ実行環境プロパティファイルで設定するプロパティ

プロパティのキー名称

説明

write.output-folder-name

output-folder-nameタグの値の代わりとなります。作業フォルダには出力できないため，common属性の設定は指定できません。

write.output-file-name

output-file-nameタグの値の代わりとなります。

write.output-mode

output-modeの値の代わりとなります。省略時はnewを仮定します。

write.output-file-validation

output-file-validationタグの値の代わりとなります。省略時はOFFを仮定します。

ファイル操作アダプタ実行環境プロパティファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.8　ファイル操作アダプタ実行環境プロパティファイル」を参照してください。

なお，ヘッダが指定されている場合は，ファイル操作アダプタ実行環境プロパティファイルの指定は参照されません。

ファイル操作アダプタ実行環境プロパティファイルを参照した場合，次のどれかのときはエラーメッセージ（KDEC80161-E）が出力されます。

ファイル操作アダプタ実行環境プロパティファイルがないとき

参照した実行環境プロパティにwrite.output-folder-nameまたはwrite.output-file-nameのどちらかがないとき

(3)　ファイル書き込みオペレーションの注意事項

ファイル書き込みオペレーションの注意事項を次に示します。

出力データが0バイトの場合，0バイトのファイルが出力されます。

出力モード（output-modeタグ）がnewの場合，書き込み処理中にエラーが発生すると，エラーが発生する直前までのデータが書き込まれます。エラーが発生するタイミングによっては，空ファイルが作成されることがあります。

出力モード（output-modeタグ）がappendの場合，書き込み処理中にエラーが発生すると，エラーが発生する直前までのデータが書き込まれます。ファイルが新規に作成されたときは，エラーが発生するタイミングによっては，空ファイルが作成されることがあります。

8.7.13　各オペレーションで使用するフォルダおよびファイルの管理

ファイル操作アダプタでは，作業フォルダ，または共通フォルダを指定してファイルの変換，複製，削除などを行います。作業フォルダおよび共通フォルダ同士を使用してファイルを入出力したり，作業フォルダからファイルを入力して共通フォルダへファイルを出力したりすることもできます。

(1)　同名のファイルが存在する場合の動作の指定

次のオペレーションでは，すでに同名のファイルが出力先のフォルダに存在する場合，ファイル操作アダプタ定義ファイルのプロパティで，ファイルを上書きするか，エラーメッセージを出力するかを指定できます。

ファイル変換オペレーション

ファイル複製オペレーション

ファイル移動オペレーション

ファイル圧縮オペレーション

ファイル伸張オペレーション

ファイル一覧書き込みオペレーション

ファイル読み込みオペレーション

ファイル書き込みオペレーション

ファイル操作アダプタ定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「3.5.2　ファイル操作アダプタ定義ファイル」を参照してください。

(2)　排他取得タイムアウトの指定

読み込み対象のファイルが共通フォルダにあるとき，ファイルに対して共有ロックを取得します。また，書き込み対象，削除対象，移動対象のファイルが共通フォルダにあるとき，ファイルに対して占有ロックを取得します。

それぞれのロック取得に失敗したとき，指定間隔おきに指定回数まで排他取得処理をリトライします。リトライ間隔とリトライ回数の積に，各排他取得時のファイルアクセス時間を加えた時間がタイムアウト時間となります。タイムアウト時間を設定するには，ファイル操作アダプタ実行環境プロパティファイルにあるロックリトライ回数およびロックリトライ間隔のパラメタを指定してください。設定するパラメタについて，次の表に示します。

表8‒33　排他取得タイムアウトの設定

項番

値

プロパティのキー名称

デフォルト値

1

共有ロックリトライ回数（回）

readLock.retry.count

0

2

共有ロックリトライ間隔（秒）

readLock.retry.interval

1

3

占有ロックリトライ回数（回）

writeLock.retry.count

0

4

占有ロックリトライ間隔（秒）

writeLock.retry.interval

1

ファイル操作アダプタ実行環境プロパティファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.8　ファイル操作アダプタ実行環境プロパティファイル」を参照してください。

8.8　作業フォルダおよび共通フォルダを利用したファイルアクセス

FTP連携では，サービスプラットフォームでファイル転送を中継するために作業フォルダおよび共通フォルダを利用します。

ここでは，作業フォルダおよび共通フォルダについて説明します。

8.8.1　作業フォルダを利用したファイルアクセス

作業フォルダとは，各ファイル転送パターンでサービスプラットフォームが管理する，一時的な中間ファイルを格納するためのフォルダです。

作業フォルダはリクエストごとにFTP受付が生成します。作業フォルダの詳細は「8.4.5　作業フォルダと中間ファイルの作成」を参照してください。

8.8.2　共通フォルダを利用したファイルアクセス

共通フォルダとは，FTPクライアントから別のFTPクライアントへのファイル転送パターンなど，複数のビジネスプロセスがファイルを参照する場合に，共通して利用するファイルを格納するためのフォルダです。

共通フォルダを利用したファイルアクセスの詳細は，「10.3　共通フォルダを利用したファイルアクセス」を参照してください。

8.9　FTP連携の適用範囲

ここでは，FTP連携でサポートするFTPコマンド，FTPコマンドの指定方法，およびFTP連携を使用するときの注意事項について説明します。

8.9.1　FTP連携でサポートするFTPコマンド

FTP連携でサポートするFTPコマンドを次の表に示します。

表8‒34　サポートするFTPコマンド

分類

コマンド

オプション

コンポーネント

RFC

FTPインバウンドアダプタ

FTP受付

ビジネスプロセス

FTPアダプタ

認証

ACCT

−

×

−

−

○

959

USER

−

○

○

○

○

959

PASS

−

○

×

×

○

959

制御

ABOR

−

×

−

−

○

959

NOOP

−

○

−

−

○

959

PASV

−

○

−

−

○

959

PORT

−

○

−

−

○

959

QUIT

−

○

−

−

○

959

REIN

−

×

−

−

×

959

REST

−

×

−

−

×

959

EPRT

−

○

−

−

○

2428

EPSV

−

○

−

−

○

2428

セッション

CDUP

−

△

△

△

○

959

CWD

−

△

△

△

○

959

MODE

−

○

−

−

○

959

S

○

−

−

○

−

B

×

−

−

×

−

C

×

−

−

○

−

LPRT

−

×

−

−

×

1639

LPSV

−

×

−

−

×

1639

ADAT

−

×

−

−

×

2228

AUTH

−

○

−

−

○

2228

SSL

○

−

−

○

−

TLS

○

−

−

○

−

CCC

−

×

−

−

×

2228

CONF

−

×

−

−

×

2228

ENC

−

×

−

−

×

2228

MIC

−

×

−

−

×

2228

PBSZ

−

○

−

−

○

2228

PROT

−

○

−

−

○

2228

C

○

−

−

○

−

P

○

−

−

○

−

OPTS

−

○

−

○

○

2389

UTF8

○

−

○

○

2640

MLST

×

−

×

×

3659

ファイル

TYPE

−

○

○

○

○

959

A

○

○

○

○

−

I

○

○

○

○

−

LANG

−

×

−

−

×

2640

転送

APPE

−

○

○

○

○

959

RETR

−

○

○

○

○

959

STOU

−

×

−

−

×

959

STRU

−

○

−

−

○

959

F

○

−

−

○

−

R※

○

×

×

○

−

P

×

−

−

×

−

更新

ALLO

−

△

△

△

○

959

DELE

−

△

△

△

○

959

MKD

−

△

△

△

○

959

RMD

−

△

△

△

○

959

RNFR

−

△

△

△

○

959

RNTO

−

△

△

△

○

959

SMNT

−

△

△

△

○

959

STAT

−

△

△

△

○

959

参照

HELP

−

×

−

−

×

959

LIST

−

○

○

○

○

959

NLST

−

○

○

○

○

959

PWD

−

△

△

△

○

959

SITE

−

○

○

○

○

959

STOR

−

○

○

○

○

959

SYST

−

△

△

△

○

959

FEAT

−

×

−

−

×

2389

MDTM

−

△

−

△

○

3659

MLSD

−

×

−

−

×

3659

MLST

−

×

−

−

×

3659

SIZE

−

△

−

△

○

3659

（凡例）

○：サポートしています。

△：SITE CSCTHRコマンドでサポートしています。

×：サポートしていません。

−：該当しません。

注※

FTPクライアントからSTRU Rコマンドを送信した場合，ファイルの変換処理は実施しません。また， FTPサーバへの中継は行いません。STRU Fコマンドの場合と同じ動作となります。

表中のFTPコマンドの分類について説明します。

(1)　認証

セッションの接続に必要なコマンドです。HCSCサーバ内でのアクセス管理に使用されます。

USERコマンドで渡されるユーザ名は，送受信されるファイルの属性としてビジネスプロセスに引き継ぐ必要があります。

(2)　制御

セッションの接続・解放などの制御に関わるコマンドです。ビジネスプロセスを経由してFTPアダプタに情報を引き継ぐ必要はありません。

(3)　セッション

1セッション内で有効な情報を設定するためのコマンドです。ビジネスプロセスを経由してFTPアダプタに情報を引き継ぐ必要はありません。

(4)　ファイル

送受信されるファイルの情報を設定するためのコマンドです。ビジネスプロセスを経由してFTPアダプタに情報を引き継ぐ必要があります。

(5)　転送

ファイルを転送するのためのコマンドです。

このコマンドを契機にビジネスプロセスが起動され，ビジネスプロセスを経由してFTPインバウンドアダプタからFTPアダプタに情報を引き継ぎます。

(6)　更新

FTPサーバ上のファイルおよびディレクトリを更新するコマンドです。

ファイル転送の前後でバッチ用途で実行することができます。FTPクライアントからSITE CSCTHRコマンドで指定します。

(7)　参照

FTPサーバ上のファイルおよびディレクトリに関する情報を参照し，FTPクライアントに渡すためのコマンドです。

LIST系コマンドは，転送コマンドと同様にビジネスプロセスを経由してFTPインバウンドアダプタからFTPアダプタに情報を引き継ぎます。LIST系以外のコマンドは，FTPクライアントからSITE CSCTHRコマンドで指定し，ビジネスプロセス上で結果を参照できます。

8.9.2　転送コマンドの指定方法

FTPクライアントからの転送コマンドの指定方法について説明します。

転送コマンドには，送受信するファイル名，および起動するビジネスプロセスを識別するためのFTP受付の受付IDを指定します。

転送コマンドの指定形式と指定内容は次のとおりです。

指定形式

/<受付ID>/<サーバ上のパス>/<ファイル名>

指定内容

/

パスの区切り文字です。OSに関係なく固定です。

<受付ID>

FTP受付の受付IDです。指定した受付IDによって起動するビジネスプロセスが識別されます。

<サーバ上のパス>

接続先のFTPサーバ上のパスです。指定は省略できます。

<ファイル名>

送受信するファイル名です。

8.9.3　FTP連携を利用するときの注意

FTP連携の機能を利用するときの注意について説明します。

(1)　ビジネスプロセスの作成に関する注意

ビジネスプロセスはファイル転送の経路ごとに作成する必要があります。

ビジネスプロセスはFTP受付に応答を返すように作成する必要があります。

1回のビジネスプロセスの処理で，複数ファイルを処理することはできません。

FTP連携ではBPELの並行処理（FLOW）を使用できません。

(2)　サーバの運用でFTPを利用する場合の注意

サービスプラットフォームのサーバ自体の運用および保守でFTPを使用する場合，別途FTPサーバを構築する必要があります。この場合，両方のFTPサーバのポート番号またはIPアドレスは一意になるように設計してください。

(3)　FTPコマンド実行時の注意

FTPクライアントに対して，Linux付属のftpコマンドを使用してファイル転送要求を行った場合，FTPインバウンドアダプタのメッセージログに次の2種類のメッセージが出力されます。

未サポートのFTPプロトコルのコマンドである，SYSTコマンドを受信したことを示すメッセージ（KDEC07531-E）

エラー応答をクライアントへ返したことを示すメッセージ（KDEC07542-E）

また，FTPクライアントに「502 Command SYST not implemented.」のレスポンスが返りますが，ファイル転送要求に影響はありません。

8.10　FTP連携システムの開発の手順

ここでは，FTP連携システムを開発する手順について説明します。

8.10.1　FTP連携システムの開発の流れ

FTP連携システムの開発の流れを次の図に示します。図中の項目は，すべて開発環境で実施する作業です。

図8‒58　FTP連携システムの開発の流れ

(1)　リポジトリのインポート

運用環境でエクスポートしたリポジトリを開発環境にインポートします。

リポジトリのインポート方法の詳細については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「3.2.3　リポジトリをインポートする」を参照してください。

(2)　FTPアダプタの定義

サービスアダプタ定義画面を使用してFTPアダプタを定義します。FTPアダプタは，接続対象のFTPサーバごとに1つ定義します。

FTPアダプタの定義については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.　サービスアダプタの定義」を参照してください。

(3)　ファイル操作アダプタの定義

サービスアダプタ定義画面を使用してファイル操作アダプタを定義します。ファイル操作アダプタは，変換，複製，削除などのオペレーションごとに1つ定義します。

ファイル操作アダプタの定義については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.　サービスアダプタの定義」を参照してください。

(4)　ビジネスプロセスの定義

ビジネスプロセス定義画面を使用してビジネスプロセスを定義します。ビジネスプロセスは，ファイル転送の経路ごとに1つ定義します。

ビジネスプロセスの定義については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「5.　ビジネスプロセスの定義」を参照してください。

(5)　FTP受付の定義

ユーザ定義受付定義画面を使用してFTP受付を定義します。FTP受付は，ビジネスプロセスごとに1つ定義します（必要に応じて複数定義します）。なお，1つのFTP受付を複数のビジネスプロセスに対応させることはできません。

FTP受付の定義の概要については，「8.4　FTP受付の機能」を参照してください。FTP受付の定義については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「2.4　FTP受付の定義」を参照してください。

(6)　HCSCコンポーネントのパッケージングと配備定義

定義したHCSCコンポーネントの定義に関連する定義ファイル，および実行環境が提供するファイルをまとめてEARファイルにパッケージングします。また，HCSCコンポーネントを配備するクラスタ（または単一のHCSCサーバ）の情報を定義（配備定義）します。

パッケージングと配備定義については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「8.　HCSCコンポーネントのパッケージングと配備定義」を参照してください。

(7)　リポジトリのエクスポート

HCSCコンポーネントの配備に必要な定義ファイルを格納したリポジトリをエクスポートします。開発環境からエクスポートした情報は，運用環境にインポートして利用されます。

リポジトリのエクスポートについては，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「3.2.2　リポジトリをエクスポートする」を参照してください。

運用環境にインポートしたあと，FTP連携システムを運用する方法については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「5.4　HCSCサーバのオペレーション運用（FTP連携する場合）」を参照してください。

8.11　FTP受付およびFTPアダプタの実行環境に依存する設定の定義

FTP受付およびFTPアダプタでは，実行環境に依存する設定を次の方法で定義できます。実行環境に依存する設定とは，接続先FTPサーバのIPアドレスやチューニングパラメタなどのことです。

共通定義ファイルによる定義（FTPアダプタ実行環境共通プロパティファイル）

要求電文および個別定義ファイルによる設定がない場合に有効になる定義です。設定値はHCSCコンポーネントの起動時に有効になります。

次の場合に使用します。

すべてのFTP受付またはFTPアダプタで設定を合わせたい場合

多くのFTP受付またはFTPアダプタで同じ値を設定する場合で，かつ運用時に管理する定義ファイルの数を削減したい場合

FTPアダプタで定義ファイルの数を削減するためには，要求電文による定義で接続先FTPサーバに依存するパラメタを設定する必要があります。

個別定義ファイルによる定義（FTPアダプタ実行環境プロパティファイル）

要求電文による設定がない場合に有効になる定義です。設定値はHCSCコンポーネントの起動時に有効になります。

次の場合に使用します。

それぞれのFTP受付またはFTPアダプタに異なる値を設定したい場合で，かつHCSCコンポーネントの再起動だけで設定値を変更したい場合

要求電文による定義

すべての定義方法の中で最も優先度の高い定義です。設定値は１つのリクエスト処理でだけ有効になります。

次の場合に使用します。

リクエストごとに異なる値を設定したい場合

それぞれのFTPアダプタで異なる値を設定したい場合で，かつ運用時に管理する定義ファイルの数を削減したい場合

ビジネスプロセスで固定値を設定した場合，設定を変更するためには開発環境でビジネスプロセスを変更する必要があります。

8.11.1　FTP受付の実行環境に依存する設定の定義

FTP受付では，実行環境に依存する設定を次の2つの方法で定義できます。

共通定義ファイルによる定義

個別定義ファイルによる定義

図8‒59　FTP受付の実行環境に依存する設定の定義

FTP受付で実行環境に依存する定義を設定する場合，FTP受付コンフィグファイルを使用します。

FTP受付コンフィグファイルには，FTP受付ごとに設定する個別定義ファイルと，すべてのFTP受付に対して設定する共通定義ファイルがあります。両方に同じプロパティを設定した場合，個別定義ファイルの設定が有効になります。

詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.5　FTP受付コンフィグファイル」を参照してください。

ここでは，FTP受付で使用する，次の実行環境定義ファイルについて説明します。

FTP実行許可リスト定義ファイル

FTPコマンド許可リスト定義ファイル（FTP受付用）

リストコマンドオプション定義ファイル

(1)　FTP実行許可リスト定義ファイル

FTP受付では実行を許可するユーザを制限できます。実行ユーザを制限する方法は次の3つです。

FTPインバウンドアダプタのユーザ認証情報

FTP受付コンフィグファイルのurecp-ftp.permission-def.filepathプロパティに指定するFTP実行許可リスト定義ファイル

製品固定パス（<サービスプラットフォームのインストールディレクトリ>¥CSC¥config¥ftprecp¥common¥ftp_permission_allow.properties）のFTP実行許可リスト定義ファイル

製品固定パスの定義はFTP受付コンフィグファイルで，urecp-ftp.permission-def.filepathプロパティを定義していないすべてのFTP受付に対して適用されます。実行ユーザの制限の組み合わせを次の表に示します。なお，表中の1.〜3.は上記の実行ユーザを制限する方法と対応しています。

表8‒35　実行ユーザの制限の組み合わせ

実行ユーザを制限する方法

実行ユーザの制限

1.

2.

3.

ユーザ情報なし

−

−

実行を拒否します。

ユーザ情報あり

拒否

−

実行を拒否します。

ユーザ情報あり

設定なし※1

拒否

実行を拒否します。

ユーザ情報あり

設定なし※1

設定なし※2

実行を許可します。

ユーザ情報あり

設定なし※1

許可

実行を許可します。

ユーザ情報あり

許可

−

実行を許可します。

（凡例）

−：設定は無視されます。

注※1

次のどれかを示します。

FTP受付コンフィグファイルを省略している

FTP受付コンフィグファイルのurecp-ftp.permission-def.filepathプロパティを設定していない

FTP受付コンフィグファイルのurecp-ftp.permission-def.filepathプロパティはあるが値を設定していない

注※2

次のどれかを示します。

製品固定パスにFTP実行許可リスト定義ファイルを格納していない

FTP実行許可リスト定義ファイルでプロパティを設定していない

FTP実行許可リスト定義ファイルのプロパティはあるが値が指定されていない

FTPインバウンドアダプタのユーザ認証情報の詳細については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「5.4.12　FTPインバウンドアダプタのユーザ情報を確認・変更する」を参照してください。

FTP実行許可リスト定義ファイルの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「6.8.7　FTP実行許可リスト定義ファイル」を参照してください。

(2)　FTPコマンド許可リスト定義ファイル（FTP受付用）

FTP受付では，転送前，転送後，リストコマンド実行前，またはリストコマンド実行後に実行を許可するコマンドを制限できます。コマンドを制限する方法は次の2つです。

FTP受付コンフィグファイルのurecp-ftp.ftp-command-allow.filepathプロパティに指定するFTPコマンド許可リスト定義ファイル

製品固定パス（<サービスプラットフォームのインストールディレクトリ>¥CSC¥config¥ftprecp¥common¥ftp_command_allow.properties）のFTPコマンド許可リスト定義ファイル

製品固定パスの定義はFTP受付コンフィグファイルで，urecp-ftp.ftp-command-allow.filepathプロパティを設定していないすべてのFTP受付に対して適用されます。コマンドの制限の組み合わせを次の表に示します。なお，表中の1.〜2.は上記のコマンドを制御する方法と対応しています。

表8‒36　コマンドを制御の組み合わせ（FTP受付の場合）

実行を許可するコマンドを制限する方法

実行ユーザの制限

1.

2.

拒否

−

実行を拒否します。

設定なし※1

拒否

実行を拒否します。

設定なし※1

設定なし※2

実行を拒否します。

設定なし※1

許可

実行を許可します。

許可

−

実行を許可します。

（凡例）

−：設定は無視されます。

注※1

次のどれかを示します。

FTP受付コンフィグファイルを省略している

FTP受付コンフィグファイルのurecp-ftp.ftp-command-allow.filepathプロパティを設定していない

FTP受付コンフィグファイルのurecp-ftp.ftp-command-allow.filepathプロパティはあるが値を設定していない

注※2

次のどれかを示します。

製品固定パスにFTPコマンド許可リスト定義ファイルを格納していない

FTPコマンド許可リスト定義ファイルでプロパティを設定していない

FTPコマンド許可リスト定義ファイルのプロパティはあるが値を設定していない

FTPコマンド許可リスト定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.6　FTPコマンド許可リスト定義ファイル」を参照してください。

(3)　リストコマンドオプション定義ファイル

FTPクライアントからLISTコマンドまたはNLSTコマンドを実行するとき，コマンドのオプションを指定できます。リストコマンドの<オプション>は，GETINFOオペレーションの要求電文の<getinfo-option>に設定されます。リストコマンドの<パス>は，GETINFOオペレーションの要求電文の<getinfo-path>に設定されます。

リストコマンドの<オプション>と<パス>を適切に扱うためには，リストコマンドのオプションを実行環境の定義ファイルに設定しておく必要があります。リストコマンドオプションの定義方法は次の2つです。

FTP受付コンフィグファイルのurecp-ftp.list-command-option.filepathプロパティに指定するリストコマンドオプション定義ファイル

製品固定パス（<サービスプラットフォームのインストールディレクトリ¥CSC¥config¥ftprecp¥common¥ftp_command_option.txt）のリストコマンドオプション定義ファイル

製品固定パスの定義はFTP受付コンフィグファイルで，urecp-ftp.list-command-option.filepathプロパティを設定していないすべてのFTP受付に対して適用されます。コマンドオプション指定の組み合わせを次の表に示します。なお，表中の1.〜2.は上記のリストコマンドオプションの定義方法と対応しています。

表8‒37　コマンドオプション指定の組み合わせ

リストコマンドオプションの定義方法

<getinfo-option>

<getinfo-path>

1.

2.

設定あり

−

LISTコマンドまたはNLSTコマンドの直後の1.で設定された<オプション文字列>が使用されます。

<オプション文字列>が一致しない場合は<getinfo-option>は出現しません。

LISTコマンドまたはNLSTコマンドの直後の<getinfo-option>の値を除いた文字列が<パス>として使用されます。

設定なし※1

設定あり

LISTコマンドまたはNLSTコマンドの直後の2.で設定された<オプション文字列>が使用されます。

<オプション文字列>が一致しない場合は<getinfo-option>は出現しません。

LISTコマンドまたはNLSTコマンドの直後の<getinfo-option>の値を除いた文字列が<パス>として使用されます。

設定なし※1

設定なし※2

<getinfo-option>は出現しません。

LISTコマンドまたはNLSTコマンドの直後の文字列が<パス>として使用されます。

（凡例）

−：設定は無視されます。

注※1

次のどれかを示します。

FTP受付コンフィグファイルを省略している

FTP受付コンフィグファイルのurecp-ftp.list-command-option.filepathプロパティを設定していない

FTP受付コンフィグファイルのurecp-ftp.list-command-option.filepathプロパティはあるが値を設定していない

注※2

製品固定パスにリストコマンドオプション定義ファイルを格納していないことを示します。

リストコマンドオプション定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.9　リストコマンドオプション定義ファイル」を参照してください。

8.11.2　FTPアダプタの実行環境に依存する設定の定義

FTPアダプタでは，実行環境に依存する設定を3つの方法で定義できます。

共通定義ファイルによる定義（FTPアダプタ実行環境共通プロパティファイル）

個別定義ファイルによる定義（FTPアダプタ実行環境プロパティファイル）

要求電文による定義

図8‒60　FTPアダプタの実行環境に依存する設定の定義

FTPアダプタで実行環境に依存する設定を定義する場合，要求電文またはFTPアダプタ実行環境プロパティファイルを使用します。

FTPアダプタ実行環境プロパティファイルは，次に示す2種類があります。

FTPアダプタ実行環境プロパティファイル

有効範囲：特定のFTPアダプタ

FTPアダプタ実行環境共通プロパティファイル

有効範囲：すべてのFTPアダプタ

これらのファイルが両方設定されている場合，2つのファイルの定義内容がマージされます。

また，1つのマシンに複数のHCSCサーバをセットアップした場合，FTPアダプタ実行環境プロパティファイルをHCSCサーバごとに定義することもできます。

同じプロパティがプロパティファイル間で複数設定された場合，プロパティの優先度は次のようになります。

ファイルの種類

プロパティ重複時の優先度

FTPアダプタ実行環境プロパティファイル

（HCSCサーバ単位の指定：あり）

高

FTPアダプタ実行環境共通プロパティファイル

（HCSCサーバ単位の指定：あり）

｜

FTPアダプタ実行環境プロパティファイル

（HCSCサーバ単位の指定：なし）

｜

FTPアダプタ実行環境共通プロパティファイル

（HCSCサーバ単位の指定：なし）

低

FTPアダプタ実行環境プロパティファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.3　FTPアダプタ実行環境プロパティファイル」を参照してください。

FTPアダプタ実行環境共通プロパティファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.4　FTPアダプタ実行環境共通プロパティファイル」を参照してください。

ここでは，FTPアダプタで使用する，要求電文および次の実行環境定義ファイルについて説明します。

FTPコマンド許可リスト定義ファイル（FTPアダプタ用）

FTPアダプタアカウント定義ファイル

(1)　要求電文

FTPアダプタの電文フォーマットの定義ファイルはサービスプラットフォームが提供するスキーマを使用します。そのため，電文フォーマットの定義ファイルの作成は不要です。

FTPアダプタの要求電文フォーマットの内容については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.10　FTPアダプタを定義する」を参照してください。

既存のFTPアダプタで，実行環境プロパティファイルのftpadp.pasvportプロパティまたはftpadp.file-size-checkプロパティを要求電文で設定したい場合は，開発環境のサービスアダプタ定義画面で電文フォーマットを再設定してください。

サービスアダプタ定義画面の詳細は，マニュアル「サービスプラットフォーム リファレンス」の「1.2.2　サービスアダプタ定義画面」を参照してください。

(2)　FTPコマンド許可リスト定義ファイル（FTPアダプタ用）

FTPアダプタでは，転送前，転送後，リストコマンド実行前，またはリストコマンド実行後に実行を許可するコマンドを制限できます。コマンドを制限する方法は次の2つです。

FTPアダプタ実行環境プロパティファイルのftpadp.cscthrough-filepathプロパティに指定するFTPコマンド許可リスト定義ファイル

製品固定パス（<サービスプラットフォームのインストールディレクトリ>¥CSC¥custom-adapter¥FTP¥config¥common）に格納されたFTPコマンド許可リスト定義ファイル

製品固定パスの定義はFTPアダプタ実行環境プロパティファイルでftpadp.cscthrough-filepathプロパティを設定していないすべてのFTPアダプタに対して適用されます。コマンドの制限の組み合わせを次の表に示します。なお，表中の1.〜2.は上記のコマンドを制限する方法と対応しています。

表8‒38　コマンド制限の組み合わせ（FTPアダプタの場合）

実行を許可するコマンドを制限する方法

実行ユーザの制限

1.

2.

拒否

−

実行を拒否します。

設定なし※1

拒否

実行を拒否します。

設定なし※1

設定なし※2

実行を拒否します。

設定なし※1

許可

実行を許可します。

許可

−

実行を許可します。

（凡例）

−：設定は無視されます。

注※1

次のどれかを示します。

FTPアダプタ実行環境プロパティファイルを省略している

FTPアダプタ実行環境プロパティファイルのftpadp.cscthrough-filepathプロパティを設定していない

FTPアダプタ実行環境プロパティファイルのftpadp.cscthrough-filepathプロパティはあるが値を設定していない

注※2

次のどれかを示します。

製品固定パスにFTPコマンド許可リスト定義ファイルを格納していない

FTPコマンド許可リスト定義ファイルでプロパティを定義していない

FTPコマンド許可リスト定義ファイルのプロパティはあるが値を設定していない

FTPコマンド許可リスト定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.6　FTPコマンド許可リスト定義ファイル」を参照してください。

(3)　FTPアダプタアカウント定義ファイル

FTPアダプタでは，FTPサーバに接続するためのユーザ認証情報をFTPアダプタアカウント定義ファイルで管理します。ユーザ認証情報を管理する方法は次の2つです。

ユーザ任意の単位に任意のパスのアカウント定義ファイルで管理する。

FTPアダプタ単位に製品固定パスのアカウント定義ファイルで管理する。

FTPアダプタのユーザ情報の確認，追加，変更，および削除は，運用環境で次のコマンドを実行します。

ユーザ情報の確認：csaftpuserlsコマンド

ユーザ情報の追加：csaftpuseraddコマンド

ユーザ情報の変更：csaftpuseraddコマンド

ユーザ情報を削除：csaftpuserdelコマンド

これらのコマンドの使用方法については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「5.4.14　FTPアダプタのユーザ情報を確認および変更する」を参照してください。

8.12　障害対策のための設計

FTP連携で障害が発生した場合に備えた，システムのエラー設計の方針について説明します。

8.12.1　エラー設計の概要

FTP連携のエラー設計で考慮するポイントを次に示します。

(1)　障害検知

FTP連携の各コンポーネント間は同期型の呼び出しで連携しているため，呼び出し先からのリターンで障害発生を検知できます。しかし，呼び出し先が無応答となるおそれもあります。このため，構築時に適切なタイマ管理を設計し，ファイルを正常に転送できないといった障害の発生を検知する必要があります。

FTP連携のタイマ管理については，「8.12.2　タイマ設計」を参照してください。

(2)　障害通知

障害が発生した場合，FTP連携を実行したFTPクライアントおよびシステム運用者に対して，障害発生を確実に通知する必要があります。

FTP連携を実行したFTPクライアントに対しては，FTPコマンドのリターンで障害発生を通知します。システム運用者に対しては，メッセージの出力で障害発生を通知します。障害発生のメッセージは，決められたメッセージ，メッセージログ，またはファイルに出力されます。そのため，JP1などのモニタリング機能でエラーメッセージを監視することで，システム運用者に障害の発生をタイムリーに通知できます。

(3)　回復処理

障害が発生したあとのFTPクライアントおよびシステム運用者の回復処理を容易にするために，適切なトランザクション処理を設計します。

FTP連携のトランザクションの設計については，「8.12.3　トランザクション設計」を参照してください。

(4)　原因調査

障害から回復し，かつ再発生を防ぐには，障害の原因を特定して取り除く必要があります。そのため，障害の原因を特定するための各種の障害情報を取得します。

FTP連携の障害情報の取得については，「8.12.4　トラブルシュート設計」を参照してください。

8.12.2　タイマ設計

呼び出し先が無応答になったり，処理時間が想定を上回ったりした場合，その状況を検知して適切に対処することを目的として，タイマ管理を実施します。

FTP連携で使用するタイマ一覧を次の表に示します。

表8‒39　FTP連携で使用するタイマ一覧

コンポーネント

タイマ

タイマ管理の目的

タイムアウト時の動作

FTPインバウンドアダプタ※1

無通信監視タイマ

制御コネクション上で，コマンドの応答から次のコマンドまでの時間を監視します。

コネクションを切断し，FTP通信をエラー終了します。

クライアント接続待ちタイマ

データコネクションの接続方式がアクティブモードの場合に，FTPクライアントからコネクション接続要求が来るまでの時間を監視します。

コネクションを切断し，FTP通信をエラー終了します。

データ受信監視タイマ

データコネクション上で，1回の受信データのreadに要する時間を監視します。

コネクションを切断し，FTP通信をエラー終了します。

データ送信監視タイマ

データコネクション上で，1回の送信データのwriteに要する時間を監視します。

コネクションを切断し，FTP通信をエラー終了します。

FTP受付※2

FTP受付監視タイマ

FTP受付が呼び出されてから応答するまでの時間を監視します。FTP受付の呼び出し元が先にタイムアウトを検知した場合の予防措置として利用します。

FTP受付が応答を返す時点でタイムアウトを検知し，システム例外を返して処理を終了します。

ビジネスプロセス※3

サービス呼び出し監視タイマ

サービス呼び出しから応答までの時間を監視します。ビジネスプロセス呼出し元が先にタイムアウトした場合の予防措置として利用します。

サービスから応答が返った時点でタイムアウトを検知し，システム例外を返して処理を終了します。

ビジネスプロセス処理監視タイマ

サービス呼び出しから応答までのビジネスプロセス処理（データ変換など）の時間を監視します。ビジネスプロセス呼び出し元が先にタイムアウトした場合の予防措置として利用します。

次のサービス呼び出し時点でタイムアウトを検知し，システム例外を返して処理を終了します。

FTPアダプタ※4

応答監視タイマ

制御コネクション上で，コマンド送信から応答までの時間を監視します。

コネクションを切断し，FTP通信をエラー終了します。そのあと，システム例外を返して処理を終了します。

サーバ接続待ちタイマ

Activeモードの場合に，FTPサーバからコネクション接続要求が返されるまでの時間を監視します。

コネクションを切断し，FTP通信をエラー終了します。そのあと，システム例外を返して処理を終了します。

データ送受信監視タイマ

データ転送の開始から終了までの時間を監視します。

コネクションを切断し，FTP通信をエラー終了します。そのあと，システム例外を返して処理を終了します。

ファイル操作アダプタ※5

ファイル変換監視タイマ

大規模なファイルの分割読み込み時の変換処理時間を監視します。

コネクションを切断し，FTP通信をエラー終了します。そのあと，システム例外を返して処理を終了します。

全体

リクエスト応答監視タイマ

FTP受付が呼び出されてから応答を返すまでの時間を監視します。

FTPクライアントにエラー応答を返します。ただし，実行中のビジネスプロセス処理は終了するまで実行されます。

注※1

FTPインバウンドアダプタのタイマ管理機能の詳細は，「8.5.2　タイムアウトの監視」を参照してください。

注※2

FTP受付のタイマ管理機能の詳細は，「8.4.9　タイムアウトの監視」を参照してください。

注※3

ビジネスプロセスおよびHCSCサーバ全体のタイマ管理機能の詳細は，「4.1　HCSCサーバに関連するタイマの設定」を参照してください。

注※4

FTPアダプタのタイマ管理機能の詳細は，「8.6.5　タイマ管理」を参照してください。

注※5

ファイル操作アダプタのタイマ管理機能は，ファイル操作アダプタ実行環境プロパティファイルで設定できます。

詳細は，マニュアル「サービスプラットフォーム リファレンス」の「6.8.8　ファイル操作アダプタ実行環境プロパティファイル」を参照してください。

8.12.3　トランザクション設計

障害からの回復を容易にするために，FTP連携では次の方針でトランザクションを設計します。

FTPクライアントからのデータ転送要求からデータ転送完了の応答までを1フェーズのトランザクションとします。

ファイルやリソースの回復は，ファイルを取り扱うFTP受付，FTPアダプタ，およびファイル操作アダプタが実行します。

(1)　トランザクションの範囲

正常終了や異常終了などのFTPクライアントへの応答内容と，ビジネスプロセスの処理ステータスと同期をとるために，EJBのトランザクションを利用したトランザクション管理をします。

トランザクションの範囲をファイル転送パターンごとに説明します。

(a)　同期型のビジネスプロセスの場合

同期型のビジネスプロセスの場合のトランザクション範囲を図に示します。

なお，同期型のビジネスプロセスを利用したファイル転送パターンについては，「8.3.1(1)　同期型ビジネスプロセスを利用したファイル転送の流れ」および「8.3.2　FTPサーバからFTPクライアントへのファイル転送」を参照してください。

図8‒61　同期型のビジネスプロセスの場合（FTPクライアントからFTPサーバへのファイル転送のとき）

図8‒62　同期型のビジネスプロセスの場合（FTPサーバからFTPクライアントへのファイル転送のとき）

(b)　非同期型のビジネスプロセスの場合

非同期型のビジネスプロセスの場合のトランザクション範囲を図に示します。

なお，非同期型のビジネスプロセスを利用したファイル転送パターンについては，「8.3.1(2)　非同期型ビジネスプロセスを利用したファイル転送の流れ」を参照してください。

図8‒63　非同期型のビジネスプロセスの場合

(c)　FTPクライアントから別のFTPクライアントへのファイル転送の場合

FTPクライアントから別のFTPクライアントへのファイル転送の場合の，トランザクション範囲を図に示します。

なお，FTPクライアントから別のFTPクライアントへのファイル転送パターンについては，「8.3.3　FTPクライアントから別のFTPクライアントへのファイル転送」を参照してください。

図8‒64　FTPクライアントから別のFTPクライアントへのファイル転送の場合（HCSCサーバ内の共通フォルダにファイルを転送するとき）

図8‒65　FTPクライアントから別のFTPクライアントへのファイル転送の場合（HCSCサーバ内の共通フォルダからファイルを取得するとき）

図8‒66　FTPクライアントから別のFTPクライアントへのファイル転送の場合（HCSCサーバ内の共通フォルダのファイルを直接参照するとき）

(2)　障害発生時のファイルの削除

FTP連携では，障害が発生した場合，処理結果とファイルの状態を一致させるために各コンポーネントが出力ファイルを削除します。

FTP連携の各処理と，対応するコンポーネントの処理を次の表に示します。

表8‒40　FTP連携でのファイルの取り扱い

処理

コンポーネント

想定される障害要因

障害時のファイルの扱い

入力ファイル

出力ファイル

FTPクライアントからのファイル送信

FTP受付

ファイル転送中断

ネットワーク障害

ディスク容量不足

ディスク障害

−

削除

FTPクライアントからのファイル受信

FTP受付

ファイル転送中断

ネットワーク障害

ディスク容量不足

ディスク障害

処理前の状態を保証

−

FTPサーバへのファイル送信

FTPアダプタ

ネットワーク障害

ディスク容量不足

ディスク障害

処理前の状態を保証

−

FTPサーバからのファイル受信

FTPアダプタ

ネットワーク障害

ディスク容量不足

ディスク障害

−

削除

ファイル変換

ファイル操作アダプタ

変換エラー

ディスク容量不足

ディスク障害

処理前の状態を保証

削除

ファイル複写

ファイル操作アダプタ

ディスク容量不足

ディスク障害

処理前の状態を保証

削除

（凡例）

−：該当しません。

なお，次の要因でファイルの削除が正常に終了しない場合は，システムを再起動してください。※1※2

ファイルロックが解除できない

ネットワーク障害やディスク障害などのハードウェア障害によって，ファイルにアクセスできない

システムダウンによってファイルを削除できない

注※1

障害発生時に書き込み中のファイルが削除できないときは，そのファイルに対する排他ロックが解除されません。そのため，ほかのビジネスプロセスからのアクセスによって，削除対象のファイルに障害が及ぶことはありません。

注※2

共有フォルダ上の障害ファイルを削除する場合，クラスタを構成する全システムを停止する必要があります。

(3)　ビジネスプロセス設計時の注意

1つのファイル転送処理全体を1フェーズのトランザクションと考えるには，更新されるリソースは1つと見なす必要があります。FTP連携では，複数のリソース更新の同期を合わせるための2フェーズ・コミットはできません。そのため，ビジネスプロセス設計時に，次のことを考慮する必要があります。

1つのビジネスプロセス内で複数のリソースを更新する場合，リソース間の更新はビジネスプロセスが同期を合わせるように設計する必要があります。

非同期型のビジネスプロセスで，FTPクライアントに応答を返したあとに障害が発生した場合，ビジネスプロセスを再開することでロールフォワード処理をする必要があります。

8.12.4　トラブルシュート設計

障害発生時の原因調査に必要なログおよびトレースを取得できるようにシステムを設計します。

FTP連携で取得できるログおよびトレースの種類を次の表に示します。

表8‒41　トラブルシュートのために取得する情報一覧

情報種別

取得内容

取得するコンポーネント

FTPインバウンドアダプタ

FTP受付

FTPアダプタ

ファイル操作アダプタ

メッセージログ

HCSCサーバの操作時および稼働中のインフォメーション，警告，障害時のエラーなどのメッセージを取得します。

○

○

○

○

リクエストトレース

次のトレースを取得します。

HCSCサーバのリクエスト受け付け／応答

ビジネスプロセスの呼び出し／応答

アダプタからのサービス呼び出し／応答

−

○

○

○

性能解析トレース

各コンポーネント間の処理の進行状況を示すトレースを取得します。

○

○

○

○

ユーザ電文トレース

決められた取得ポイントでのユーザ電文のトレースを取得します。

−

○

○

○

保守用ログ

障害の切り分け，原因調査を目的とした製品の内部処理の情報を取得します。

−

○

○

○

プロトコルトレース

HCSCサーバと外部システムとの通信プロトコルのトレースとして，FTPクライアントまたはFTPサーバとの制御コネクション上で送受信されたFTPコマンドの情報を取得します。

必要に応じて，データコネクション上の情報も取得できます。

○

−

○

−

（凡例）

○：取得します。

−：取得しません。

FTP連携で取得できるログおよびトレースの出力先や出力内容の詳細は，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「7.7.11　FTP連携システムでの障害対策」を参照してください。

参考

FTP連携を利用する場合，スローダウンによるファイル転送の時間ロスを低減するために，スローダウンが発生した場合の調査手段を準備しておくことを推奨します。調査方法を次の表に示します。

表8‒42　FTP連携でのスローダウンの調査方法

想定される要因

調査方法

ネットワークの遅延

プロトコルトレース，およびOSの稼働統計で調査します。

ディスクI/Oの遅延

性能解析トレース，およびOSの稼働統計で調査します。

排他待ち

保守用ログで調査します。

リトライ多発

保守用ログで調査します。

CPUネック

OSの稼働統計で調査します。

9　ファイルイベント連携を使用したファイルの監視

この章では，ファイルイベント連携を使用してファイルを監視する機能について説明します。

9.1　ファイル連携の機能の概要

監視対象のフォルダ内に存在するファイルを一定の間隔で監視することによって，ファイルイベント連携を実現します。監視対象のフォルダ内にファイルが作成された際のイベントを処理するために，ファイルイベント受付を使用します。ファイルイベント受付，および関連するHCSCサーバの機能を次に示します。

ファイル監視機能

監視対象のフォルダ内のファイルを監視します。

監視対象のファイルの状態管理機能

監視対象のファイルのリネーム，および自動削除を実行し，監視対象のファイル状態を管理します。

ファイルイベントトレース機能

ファイルイベント連携の実行結果を確認するためのトレースファイルを出力します。

9.1.1　ファイル監視機能

ファイル監視機能とは，HCSCサーバからアクセスできる特定のフォルダ内での，ファイルの新規作成を監視する機能です。ファイル監視機能は，HCSCサーバランタイム定義ファイルで指定されたfileevent-reception.monitor-intervalプロパティの値を基準として，一定間隔でファイルの存在確認を実施します。

ファイル監視を14:00に開始し，fileevent-reception.monitor-intervalプロパティの値を30分に設定した場合の例を次の図に示します。

図9‒1　ファイル監視の間隔

(1)　ファイル監視機能を有効にするための設定

ファイル監視機能は，HCSCサーバランタイム定義ファイルのfileevent-reception.monitored-file.enabledプロパティにtrueを設定することによって有効になります。ファイル監視機能は，ファイルイベント連携を使用する際に必要です。

注意事項

ファイルイベント受付をHCSCサーバに配備する場合は，fileevent-reception.monitored-file.enabledプロパティに必ずtrueを設定してください。falseが設定されていると，ファイルイベント受付の起動に失敗します。

(2)　監視対象の設定

監視対象のフォルダは，ファイルイベント受付定義ファイルのurecp-fileevent.monitored.common-folderプロパティで設定します。次のどちらかを指定してください。

false

監視フォルダを監視対象とします。

true

共通フォルダを監視対象とします。

(3)　ファイル監視の開始

ファイル監視機能が有効になっている場合は，HCSCサーバの起動時にファイル監視が開始されます。ファイル監視は，HCSCサーバの起動コマンドが実行された直後から，HCSCサーバランタイム定義ファイルで指定されたfileevent-reception.monitor-starting.delayプロパティの開始遅延時間が経過したあとに開始されます。それ以降は，HCSCサーバランタイム定義ファイルで指定されたfileevent-reception.monitor-intervalプロパティの値を基準として，一定間隔でファイル監視を実施します。

HCSCサーバの起動を14:00に開始し，開始遅延時間を10分，ファイル監視の間隔を30分で設定した場合の例を次の図に示します。

図9‒2　ファイル監視の開始

1回目のファイルの存在確認は14:10に，2回目は14:40に実施されます。

(4)　ファイル監視の終了

ファイル監視機能は，HCSCサーバを停止する際に自動的に停止します。ファイル監視機能を単独で停止することはできません。

(5)　監視対象のファイルの登録

監視対象となるフォルダ，およびファイル名などの条件は，ファイルイベント受付の起動時にファイル監視機能に登録されます。登録された内容は，次のファイルの存在確認時に反映されます。監視対象ファイルの登録の流れを次の図に示します。

図9‒3　監視対象ファイルの登録

(6)　監視対象のファイルの登録解除

ファイル監視機能にファイル監視の対象として登録されたファイルの条件は，ファイルを登録したファイルイベント受付を停止したときにファイル監視機能から削除されます。登録が解除されたファイルの条件は，次のファイルの存在確認からファイル検知の対象外となります。

図9‒4　ファイル監視条件の登録解除

注意事項

ファイルイベント受付の停止の処理が異常終了した場合，登録されたファイルの条件がファイル監視機能から解除されずに，ファイルの検知を続けることがあります。この場合，異常停止したファイルイベント受付を起動するか，HCSCサーバを再起動してください。

(7)　監視対象のファイルと取得対象ファイル

ファイル監視機能は，監視対象のフォルダによって，監視対象ファイルと取得対象ファイルが異なります。

監視対象のフォルダによる違いを次に示します。

監視対象のフォルダが監視フォルダの場合

監視フォルダ内の更新完了通知ファイルを監視します。取得対象ファイルの監視はできません。取得対象ファイルと更新完了通知ファイルの，両方を用意する必要があります。更新完了通知ファイルの詳細については「9.3.4(1)　更新完了通知ファイルの作成」を参照してください。

監視対象のフォルダが共通フォルダの場合

共通フォルダ内の取得対象ファイルを監視します。監視フォルダおよび更新完了通知ファイルは不要です。取得対象ファイルの詳細については，「9.3.4(2)　取得対象ファイルの作成」を参照してください。

(8)　監視対象のファイルの数量とリクエスト回数の関係

ファイル監視機能によって複数の監視対象のファイルが検知された場合，ファイル監視機能はファイルイベント受付が検知したファイルと同じ数だけ，独立したリクエストとしてファイルイベントの検知を通知します。ただし，監視対象のファイルを通知する順番は指定できません。

監視対象のファイルが3つあり，リクエスト処理が3回実行される場合の動作を次の図に示します。

図9‒5　監視対象のファイルの数量とリクエスト回数の関係

また，ファイル監視機能からファイルイベント受付へ通知する際にエラーが発生した場合は，エラーが発生した通知処理だけ終了し，そのほかに検知された処理は続行されます。

(9)　ファイル監視の処理時間がファイル監視の間隔を超えた場合の動作

処理の遅延などによって，ファイル監視処理に掛かる時間がファイル監視の間隔を超えた場合は，ファイル監視処理が終了したあと，ファイル監視の間隔を待たないで，すぐに次のファイル監視処理を開始します。

ファイル監視処理に掛かる時間がファイル監視の間隔を超えた場合の動作例を次の図に示します。

図9‒6　ファイル監視の処理時間がファイル監視間隔を超えた場合の動作

図の例では，ファイル監視1回目の処理時間が，2回目と3回目のファイル監視予定時刻に差し掛かっています。この場合，1回目の処理が終わった段階で2回目と3回目の予定時刻をオーバーしているため，すぐに実行されます。

9.1.2　監視対象のファイルの状態管理機能

ファイルイベント処理が不整合な状態になることを防ぐため，監視対象のファイルのリネーム，および監視対象のファイルの自動的な削除を実施し，監視対象のファイルの状態を管理します。

監視フォルダを監視する場合

監視フォルダ内の更新完了通知ファイルをリネームします。また，リネーム後の更新完了通知ファイルを，ビジネスプロセスを呼び出す前に自動的に削除します。

共通フォルダを監視する場合

共通フォルダ内の取得対象ファイルをリネームします。また，ファイルイベント受付定義ファイルのurecp-fileevent.file.auto-deleteプロパティがtrue（デフォルト）の際は，ビジネスプロセスからの応答が正常のときだけ，リネーム後の取得対象ファイルを自動的に削除します。

注意事項

監視対象のファイルの状態管理機能では，ファイルイベントが発生した場合，検知した監視対象のファイルのファイル名をリネームします。リネームする際，ファイル名の最後に付与される文字列を次に示します。

<監視対象のファイルの更新時刻>＋.csc_working

自動削除の対象になるのはリネームされた監視対象のファイルです。そのため，リネームされた監視対象のファイルに対する入出力エラーが発生した場合など，自動削除処理が終了していてもファイルが削除されない場合があります。この場合，ファイルは残り続けますが，リネームされたファイルは以降のファイル監視でファイルイベント検知の対象になりません。必要に応じて手動で削除してください。

共通フォルダを監視する場合に，取得対象ファイルを自動削除すると，ビジネスプロセスの応答アクティビティ後に取得対象ファイルを参照することができません。ビジネスプロセスの応答アクティビティ後に取得対象ファイルを参照する場合は，自動削除をしないでください。

9.1.3　ファイルイベントトレース機能

ファイルイベント連携の実行結果を確認するために，トレースファイルを出力します。ファイルイベント受付入口，およびファイルイベント受付出口のポイントでトレースします。トレースファイルの詳細については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「7.7.12　ファイルイベント連携システムでの障害対策」を参照してください。

9.1.4　ファイルイベント連携使用時の注意事項

ファイルイベント連携を使用する場合の注意事項を示します。

(1)　取得対象ファイルについて

リクエスト処理中は，外部のプロセスからリクエスト処理で参照する取得対象ファイルを更新しないでください。取得対象ファイルが不完全な状態で，ビジネスプロセス内で参照される可能性があります。

取得対象ファイルの転送が完了するまでは，取得対象ファイルに対してファイルロックを取得してください。ファイルロックを取得しない場合は，ファイルが更新中でもファイルイベントを検知することがあります。

取得対象ファイルのファイルサイズが0の場合はファイルイベント連携の対象になりません。ファイルサイズが0の取得対象ファイルをファイルイベント連携する場合は，監視フォルダを監視する方法を選択してください。

(2)　アクセス権限について

監視フォルダおよび共通フォルダ配下にあるフォルダとファイルには，HCSCサーバの管理者（Service Coordinator管理者）がアクセスできるように適切なアクセス権限を設定してください。

(3)　監視対象のフォルダについて

次に示すフォルダおよびファイルが監視対象のフォルダ配下に作成されます。これらのフォルダおよびファイルはファイルイベント連携で使用するため，参照や削除などのファイル操作はしないでください。

拡張子が「.csc_lock」のファイル

「.csc_lock」フォルダ

また，HCSCサーバが冗長構成の場合に監視対象のフォルダを作成する際は，次の点に注意してください。

HCSCサーバがWindows上で動作する場合は，監視対象のフォルダはSMBによるファイル共有をしないでください。監視対象のフォルダは共有ディスク装置に作成してください。

HCSCサーバがUNIX系のOS上で動作する場合にNFSによるファイル共有をする際は，NFSキャッシュ機能を使用しないでください。

9.2　ファイルイベント連携を使用するためのシステムの構成例

ファイルイベント連携を使用する際のシステムについて次に示します。

ファイル転送クライアント

サービスプラットフォームが構築されているマシン上にファイルを転送します。

サービスプラットフォーム（ファイルイベント連携システム）

次に示すサーバで構成されています。

ファイル転送サーバ

ファイル転送クライアントから転送されたファイルを受け取ります。

ローカルディスク

サービスプラットフォームが存在するマシンのローカルディスクです。更新完了通知ファイルや取得対象ファイルを格納します。

なお，ファイル転送クライアントおよびファイル転送サーバはService Coordinatorの構成要素ではありません。

9.2.1　サービスプラットフォームのサーバマシンのローカルディスクを使用する構成例

1台のHCSCサーバで，ファイルイベント連携を使用する場合の基本となるシステム構成例を次の図に示します。

図9‒7　システム構成（サービスプラットフォームのサーバマシンのローカルディスクを使用する構成）

9.2.2　ファイルサーバの共有ディスクを使用する構成例

HCSCサーバが冗長構成の場合で，ファイルイベント連携を使用する際の基本となるシステム構成例を次の図に示します。冗長構成内のHCSCサーバが同一のファイルサーバを使用することで，複数のHCSCサーバでファイルイベントを処理できます。複数のHCSCサーバで同一のファイルイベントは処理しません。

図9‒8　システム構成（ファイルサーバの共有ディスクを使用する構成）

9.3　ファイルイベント連携で必要な設定

ファイルイベント連携で必要な設定について説明します。

9.3.1　ファイルイベント連携の設定の流れ

ファイルイベント連携を使用する場合の流れを次の図に示します。

(1)　ファイル監視機能の有効化

ファイル監視機能は，HCSCサーバランタイム定義ファイルのfileevent-reception.monitored-file.enabledプロパティにtrueを設定することによって有効になります。

サーバランタイム定義ファイルの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

(2)　ファイル開始遅延時間の設計

ファイル監視は，HCSCサーバランタイム定義ファイルのfileevent-reception.monitor-starting.delayプロパティに指定している開始遅延時間が経過したあとに，開始されます。そのため，fileevent-reception. monitor-starting.delayプロパティには，HCSCサーバの起動に掛かる時間（起動コマンドを実行してから返るまでの時間）より大きな値を設定してください。HCSCサーバの起動中に開始遅延時間が経過した場合は，条件に一致するファイルが検知されない場合があります。

サーバランタイム定義ファイルの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

(3)　ファイル連携機能で使用するフォルダおよびファイルの設計

ファイルイベント連携機能を使用する際に，設計が必要なフォルダおよびファイルがあります。

詳細については，「9.3.2　ファイルイベント連携機能で設計が必要な項目」を参照してください。

(4)　ファイルイベント連携時に使用するファイルの作成

ファイルイベント連携時は，次のファイルを作成する必要があります。

更新完了通知ファイル

詳細については，「9.3.4(1)　更新完了通知ファイルの作成」を参照してください。

取得対象ファイル

詳細については，「9.3.4(2)　取得対象ファイルの作成」を参照してください。

9.3.2　ファイルイベント連携機能で設計が必要な項目

ファイルイベント連携機能では，監視対象とするフォルダやファイル，および取得ファイルの扱いなどを設計し，必要に応じて定義ファイルやクライアントで設定を実施します。設計および設定が必要な項目を次に示します。

表9‒1　ファイルイベント連携機能で設計が必要な項目

設定項目

定義

ファイル

プロパティ

説明

監視対象のフォルダ

ファイルイベント受付定義ファイル

urecp-fileevent.monitored.common-folder

ファイルイベント受付で監視の対象にするフォルダを指定します。

共通フォルダの場合

true

監視フォルダの場合

false（デフォルト）

サブフォルダ

urecp-fileevent.sub-folder

ファイルイベント受付ごとに使用するサブフォルダを設定します。1つの受付につき1個所だけ設定できます。

監視対象のファイル

urecp-fileevent.monitored-file-name.regex

監視対象のファイルと見なすファイル名を，正規表現で指定します。

取得対象ファイルの自動削除

urecp-fileevent.file.auto-delete

ファイルイベント受付で監視の対象を共通フォルダにしている場合，取得対象ファイルを自動的に削除するかどうかを指定します。

削除する場合

true（デフォルト）

削除しない場合

false

監視対象のフォルダが監視フォルダの場合は無視されます。

共通フォルダ

urecp-fileevent.common-folder.definition-name

取得対象ファイルを格納する共通フォルダの，共通フォルダ定義名を指定します。

デフォルト値を次に示します。

default

監視フォルダ

HCSCサーバランタイム定義ファイル

fileevent-reception.monitored-folder

監視フォルダのルートフォルダを指定します。1つのHCSCサーバに対して，1個所だけ設定できます。

監視対象のフォルダが共通フォルダの場合は無視されます。

デフォルト値を次に示します。

<サービスプラットフォームのインストールディレクトリ>/CSC/spool/fileevent

取得対象ファイル

ファイルイベント連携クライアントが配置します。定義ファイルのプロパティでは設定しません。

処理対象となるファイルです。ファイルイベント受付で存在確認を実施します。

9.3.3　ファイルイベント受付が監視するフォルダの設定

ファイルイベント受付が監視するフォルダの設定について，次に示します。

監視フォルダ

取得対象ファイルの更新完了後に，更新完了通知ファイルを作成することによって，取得対象ファイルが完全な状態であることを保証したファイル連携ができます。取得対象ファイル以外に，更新完了通知ファイルの運用が必要になります。

共通フォルダ

更新完了通知ファイルが不要なため，よりシンプルにシステムを構成できます。取得対象ファイルの更新が完了するまで排他を掛ける必要があります。

詳細については「9.1.2　監視対象のファイルの状態管理機能」を参照してください。

(1)　監視フォルダの設定

監視フォルダのパスは，HCSCサーバランタイム定義ファイルのfileevent-reception.monitored-folderプロパティで設定できます。

デフォルトの監視フォルダは，製品のインストール時に作成される次のフォルダです。

<サービスプラットフォームのインストールディレクトリ>/CSC/spool/fileevent

デフォルト以外のフォルダを使用する場合は，監視フォルダとするフォルダを作成し，その絶対パスをHCSCサーバランタイム定義ファイルのfileevent-reception.monitored-folderプロパティに設定してください。

注意事項

監視フォルダおよび共通フォルダに同一のフォルダを指定しないでください。同一のフォルダを指定した場合の動作は保証されません。

監視フォルダのパスにはISO-8859-1文字エンコーディングを使用してください。

(2)　共通フォルダの設定

共通フォルダは，HCSCサーバランタイム定義ファイルのcommon-folder-<共通フォルダ定義名>プロパティで指定します。指定しない場合は，デフォルトの設定値のフォルダを共通フォルダとして使用します。

デフォルト以外のフォルダを使用する場合は，共通フォルダを作成する必要があります。この場合，HCSCサーバランタイム定義ファイルのcommon-folder-<共通フォルダ定義名>プロパティで設定してください。また，取得対象ファイルの格納場所を指定するために，共通フォルダ定義名をファイルイベント受付定義ファイルのurecp-fileevent.common-folder.definition-nameプロパティに設定する必要があります。

共通フォルダ定義名を指定する例を次の図に示します。

図9‒9　共通フォルダ定義名の設定の例

注意事項

監視フォルダを監視する受付と，共通フォルダを監視する受付は，それぞれ異なる共通フォルダを指定してください。共通フォルダが同一の場合の動作は保証されません。

(3)　サブフォルダの設定

サブフォルダは，監視対象のフォルダの配下に指定できます。監視対象のフォルダの配下にサブフォルダを手動で作成し，ファイルイベント受付定義ファイルのurecp-fileevent.sub-folderプロパティでサブフォルダのパスを設定してください。

なお，監視フォルダを監視する場合，監視フォルダ配下のフォルダ構成と共通フォルダ配下のフォルダ構成を一致させる必要があります。監視フォルダ配下にあるサブフォルダと同名のサブフォルダを，共通フォルダ配下に作成してください。

9.3.4　ファイルイベント連携時に作成するファイル

ファイルイベント連携時に作成するファイルについて説明します。

(1)　更新完了通知ファイルの作成

更新完了通知ファイルとは，クライアントがHCSCサーバにファイルイベントを通知するために作成するファイルです。クライアントは取得対象ファイルの転送が完了したあとで，このファイルを作成する必要があります。更新完了通知ファイルと取得対象ファイルは同じファイル名でなければなりませんが，同一のファイルでなくても構いません。

更新完了通知ファイルの格納先

更新完了通知ファイルは，処理したいファイルイベント受付に対応する監視フォルダの配下に格納してください。

更新完了通知ファイルの命名規則

更新完了通知ファイル名の命名規則を次に示します。

取得対象ファイルと同じファイル名にしてください。

ファイルイベント受付定義ファイルで設定したurecp-fileevent.monitored-file-name.regexプロパティの設定値の正規表現に合致するファイル名にしてください。

ただし，「.csc」で始まる文字列はサービスプラットフォームで予約されているため，更新完了通知ファイルに「.csc」を含む文字列は指定できません。ファイル名に「.csc」を含むファイルは更新完了通知ファイルと見なしません。

(2)　取得対象ファイルの作成

取得対象ファイルは，ビジネスプロセスなどで処理の対象とするファイルです。このファイルは，システムを利用するユーザがファイルイベント連携処理を開始する際に，ファイル連携ソフトウェアなどを用いて格納します。

取得対象ファイルの格納

監視フォルダを監視する場合は，取得対象ファイルは更新完了通知ファイルを作成する前に格納してください。

取得対象ファイルの格納先

取得対象ファイルは，ファイルイベント受付定義ファイルで設定したurecp-fileevent.common-folder.definition-nameプロパティの値に対応する共通フォルダ内に格納してください。

監視フォルダを監視する場合は，監視フォルダから見た更新完了通知ファイルの相対パスと，共通フォルダから見た取得対象ファイルの相対パスは一致している必要があります。相対パスが異なるときはエラーとなります。また，相対パスを比較する際の大文字・小文字による違いは，OSのファイルシステムに依存します。正常になるケースとエラーになるケースを次に示します。

正常なケース

エラーとなるケース（サブフォルダが異なる）

エラーとなるケース（ファイル名が異なる）

取得対象ファイルの命名規則

共通フォルダを監視する場合の取得対象ファイルのファイル名は，ファイルイベント受付定義ファイルで設定した，urecp-fileevent.monitored-file-name.regexプロパティの設定値の正規表現と合致したファイル名にする必要があります。ただし，「.csc」で始まる文字列はサービスプラットフォームで予約されているため，更新完了通知ファイルに「.csc」を含む文字列は指定できません。ファイル名に「.csc」を含むファイルは取得対象ファイルと見なしません。

9.3.5　ファイルイベント連携に関する実行環境の設定

実行環境での，ファイルイベント連携機能に関する設定について説明します。

(1)　ファイルイベント受付の定義ファイルの作成

ファイルイベント受付で，実行環境に依存する定義を設定する場合，ファイルイベント受付コンフィグファイル，およびファイルイベント受付共通コンフィグファイルを使用します。詳細を次の表に示します。

表9‒2　実行環境で設定するファイルイベント受付の定義ファイル

ファイルの種類

ファイル名

説明

ファイルイベント受付コンフィグファイル

<ファイルイベント受付の受付ID>.properties

ファイルイベント受付のコンフィグファイルです。ファイルイベントトレースの設定などを定義できます。

ファイルイベント受付共通コンフィグファイル

fileeventrecp_config.properties

すべてのファイルイベント受付で共通して定義できるファイルイベント受付コンフィグファイルです。

複数のファイルイベント受付で共通の定義値を設定する場合は，各ファイルイベント受付のファイルイベント受付コンフィグファイルではなく，ファイルイベント受付共通コンフィグファイルに設定します。これによって，すべてのファイルイベント受付に対してプロパティ値を有効にできます。

ファイルイベント受付コンフィグファイル，およびファイルイベント受付共通コンフィグファイルに同一のプロパティを設定している場合は，ファイルイベント受付コンフィグファイルのプロパティの設定が有効になります。有効になるプロパティは，プロパティ単位で判定されます。

ファイルイベント受付コンフィグファイルおよびファイルイベント受付共通コンフィグファイルの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「6.9.1　ファイルイベント受付コンフィグファイル」，および「6.9.2　ファイルイベント受付共通コンフィグファイル」を参照してください。

(2)　同時実行スレッド数の制御の設定

HCSCサーバランタイム定義のfileevent-reception.monitored-file.enabledプロパティにtrueが設定され，ファイル監視機能が有効になっている場合，ファイル監視機能のためにスレッドが生成されます。ファイル監視機能のためのスレッドは，1つだけ生成されます。同時実行数の設定はできません。

また，ファイルイベント受付単位でファイルイベントを処理するスレッドが生成されます。生成されたスレッドは，スレッドプールで管理されます。常駐するスレッドは，ファイルイベント受付起動時に生成されます。常駐するスレッドの数（以降，常駐スレッド数と呼びます）はファイルイベント受付定義ファイルのurecp-fileevent.thread-pool.minimumプロパティで設定できます。

常駐スレッド数を超える数のファイルイベントが通知された場合は，ファイルイベントを処理するときにスレッドが一時的に追加生成されます。

ファイルイベント受付の処理のために生成されるスレッドの最大数（常駐スレッド数＋追加生成されたスレッド数）は，ファイルイベント受付定義ファイルのurecp-fileevent.thread-pool.maximumプロパティで設定できます。なお，常駐スレッド数と最大スレッド数を同じ値に設定した場合，スレッドは追加生成されません。

ファイルイベント受付定義ファイルの詳細については，マニュアル「サービスプラットフォーム リファレンス」の「3.12.1　ファイルイベント受付定義ファイル」を参照してください。

ファイルイベント連携機能で使用するスレッドの例を次の図に示します。

図9‒10　ファイルイベント連携機能で使用するスレッドの例

図中の1.〜3.について説明します。

ファイル監視機能のスレッドは，HCSCサーバの起動時に生成され，HCSCサーバ停止まで常駐します。

ファイルイベント受付の処理は，スレッドプール内のスレッドで実行されます。

スレッドプールは，ファイルイベント受付単位に存在します。

ファイルイベント受付の処理終了後に，ファイルイベント受付が使用したスレッドがスレッドプールに戻されます。

9.3.6　ファイルイベント連携のエラー設計の概要

ファイルイベント連携のエラー設計で考慮するポイントを次に示します。

(1)　障害通知

ファイルイベント連携機能では，処理中に障害が発生した場合でもクライアントにエラー応答を返すことはできません。ただし，システム運用者に対しては，メッセージの出力で障害発生を通知します。障害発生のメッセージは，メッセージログに出力されます。これらの情報をJP1などのモニタリング機能で監視することで，システム運用者に障害の発生を通知できます。

(2)　回復処理

ファイルイベント受付の処理中に障害が発生した場合，ビジネスプロセスの実行履歴を取得している場合は，ビジネスプロセスインスタンスの再実行によって処理を途中から再開できることがあります。ビジネスプロセスの実行履歴を取得していない場合は，再度監視対象のファイルを作成することで処理を最初から実行し直す必要があります。

注意事項

ビジネスプロセスの再実行時は，次の処理は行われません。

ファイルイベントトレースの出力

共通フォルダを監視する場合の，取得対象ファイルの自動削除

10　作業フォルダおよび共通フォルダの機能

この章では，ファイル転送を中継するために利用する作業フォルダおよび共通フォルダについて説明します。

10.1　作業フォルダおよび共通フォルダにアクセスできるコンポーネント

作業フォルダおよび共通フォルダにアクセスできるコンポーネントを次の表に示します。

表10‒1　作業フォルダおよび共通フォルダにアクセスできる受付

受付種別

作業フォルダ

共通フォルダ

FTP受付

○

○※

SOAP受付（ユーザ定義受付）

○

×

HTTP受付

○

×

TP1/RPC受付

×

×

Message Queue受付

×

×

ファイルイベント受付

×

○

Kafka受付

×

×

gRPC受付

×

×

スケジュール駆動受付

〇

×

（凡例）

○：アクセスできます。

×：アクセスできません。

注※

GETオペレーションのみ共通フォルダ内のファイルへアクセス可能です。詳細は，「8.4.10　共通フォルダと中間ファイルの作成」を参照してください。

表10‒2　作業フォルダおよび共通フォルダにアクセスできるアダプタ

アダプタ種別

作業フォルダ

共通フォルダ

ファイル操作アダプタ

○

○

FTPアダプタ

○

○

SOAPアダプタ

○

○

DBアダプタ

×

×

TP1アダプタ

×

×

ファイルアダプタ

×

×

Object Accessアダプタ

×

×

Message Queueアダプタ

×

×

メールアダプタ

○

○

HTTPアダプタ

○

○

コマンドアダプタ

○

○

SFTPアダプタ

○

○

Kafkaアダプタ

×

×

gRPCアダプタ

×

×

（凡例）

○：アクセスできます。

×：アクセスできません。

注意事項

作業フォルダおよび共通フォルダとして設定したフォルダには，HCSCサーバ管理者のオーナー，およびグループを設定してください。

Windowsの場合は，作業フォルダおよび共通フォルダに対するアクセス許可をフルコントロールにしてください。

UNIXの場合は，アクセス権限に（7:rwx）を設定してください。

10.2　作業フォルダを利用したファイルアクセス

作業フォルダとは，各ファイル転送パターンでサービスプラットフォームが管理する，一時的な中間ファイルを格納するためのフォルダです。

10.2.1　作業フォルダルートの定義

作業フォルダルートは，HCSCサーバに対して1つだけ存在します。作業フォルダルートの定義は，HCSCサーバランタイム定義ファイルのwork-folderプロパティに記述します。

デフォルトの作業フォルダルートは次のとおりです。

<インストールディレクトリ>/CSC/spool/ftp/work

HCSCサーバランタイム定義ファイルについては，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

10.2.2　作業フォルダとリクエストIDの生成

作業フォルダを使用する受付が，クライアントからリクエストを受け付けると，リクエストごとにリクエストIDと作業フォルダが生成されます。

(1)　リクエストIDの生成

リクエストごとに一意となるリクエストIDが生成されます。リクエストIDの形式は次のとおりです。

リクエストIDの生成規則

リクエストID＝<受付ID><クライアントのIPアドレス><日付><時刻><追番><分割キー><HCSCサーバ名>

表10‒3　リクエストIDの形式

項番

項目

桁数

内容

備考

1

<受付ID>

8桁

受付IDです。

受付IDが8桁に満たない場合は，受付IDの右側に足りない分の"-"が付加されます。

−

2

<クライアントのIPアドレス>

12桁（IPv4の場合），または32桁（IPv6の場合）

要求元のクライアントのIPアドレスです。

IPv4の場合

IPアドレスの各バイトを10進数3桁で表し，結合した文字列になります。

IPアドレスのそれぞれのバイトが3桁に満たない場合は，各バイトの左側に足りない分の「0」が設定されます。

IPv6の場合

IPアドレスの各バイトを16進数4桁で表し，結合した文字列になります。

IPアドレスの各バイトが4桁に満たない場合は，各バイトの左側に足りない分の「0」が設定されます。

英字は小文字で表記されます。

−

3

<日付>

8桁

受付がリクエストを受け付けた日付を表す文字列。"yyyyMMdd"形式の文字列となります。

−

4

<時刻>

9桁

受付がリクエストを受け付けた時刻を表す文字列。ミリ秒単位までを示す"HHmmssSSS"形式の文字列となります。

−

5

<追番>

3桁

ほかのリクエストの処理のために，項番3，項番4の部分が全く同じリクエストIDが現在使用されていない場合は，"000"となります。

ほかのリクエストの処理のために項番3，項番4の部分が全く同じリクエストIDが現在使用されている場合は，この追番を1ずつインクリメントして重複しないリクエストIDとなる3桁の数値が使用されます。

もし"999"まで試行しても重複しない追番が設定できなかった場合は，項番3，項番4を変えて"000"で採番し直します。

6

<分割キー>

1桁

HCSCサーバ名が付加されていることを示す分割キーワード。"/"を使用します。

−

7

<HCSCサーバ名>

8桁

受付がデプロイされているHCSCサーバの名称。

HCSCサーバ名が8桁に満たない場合でも，"-"による文字埋めはしません。

−

（凡例）

−：該当する項目はありません。

リクエストIDの例を次に示します。

IPv4アドレスの場合

受付ID：RCP01

クライアントのIPアドレス：10.200.30.4

実行日時：2011/1/2 14:03:05.012

HCSCサーバ名：HCSC

図10‒1　IPv4アドレスの場合のリクエストID

IPv6アドレスの場合

受付の受付ID：RCP01

クライアントのIPアドレス：40AB:0:0:0:AE:800:201:17

実行日時：2011/1/2 14:03:05.012

HCSCサーバ名：HCSC

図10‒2　IPv6アドレスの場合のリクエストID

(2)　作業フォルダの生成

次の規則に従って作業フォルダルート以下にフォルダが生成されます。

作業フォルダルート以下に，HCSCサーバ名をフォルダ名とするフォルダが生成されます。このフォルダをHCSCサーバフォルダと呼びます。

HCSCサーバフォルダ以下に，受付IDをフォルダ名とするフォルダが生成されます。このフォルダを受付IDフォルダと呼びます。

受付IDフォルダ以下に，フォルダが生成されます。このフォルダを作業フォルダと呼びます。作業フォルダ名は，リクエストIDの<クライアントのIPアドレス>から<追番>までの値が使用されます。

ただし，HTTP受付では，例外として32桁すべて「0」で命名された特殊な作業フォルダも別途起動時に生成されます。これは，受信したデータをすべてメモリ上に展開することによるメモリ圧迫を避けるため，HTTP受付処理前に一時的に受信データをすべてファイルに出力する際に使用するフォルダです。通常の作業フォルダとは用途が異なります。

10.2.3　作業フォルダ内のファイルの生成

各コンポーネントによって作業フォルダ内に生成されるファイルは，次の規則に従ったファイル名になります。また，ファイルは，HCSCサーバの管理者の権限で生成されます。

作業フォルダ内ファイル名の生成規則

ファイル名＝csc_<ユニークID>

ユニークID：フォルダ内に存在しないファイル名になるような文字列。

10.2.4　作業フォルダ内のファイルの排他制御

作業フォルダ内のファイルへのアクセスには，読み込み，書き込みともにファイルロックは取得されません。

10.2.5　作業フォルダおよび作業フォルダに格納された中間ファイルの削除

作業フォルダおよび作業フォルダに格納された中間ファイルは，次の方法で削除できます。

FTP受付定義ファイルの「urecp-ftp.work-dir.auto-delete」

HTTP受付定義ファイルの「httprecp.work-dir.auto-delete」

スケジュール駆動受付定義ファイルの「scdrecp.work-dir.auto-delete」

ファイル操作アダプタの削除オペレーション

フォルダ運用管理コマンド

ただし，受付による自動削除の方法では，プロセスが異常終了した場合は自動削除が実行されないで作業フォルダおよび中間ファイルが残ります。また，ビジネスプロセスを再実行した場合も受付が呼び出されないため，自動削除は実行されません。その場合は，フォルダ運用管理コマンドで別途削除する必要があります。

フォルダ運用管理コマンドによる削除方法は，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「5.3.32　作業フォルダを削除する」を参照してください。

10.3　共通フォルダを利用したファイルアクセス

共通フォルダとは，複数のビジネスプロセスがファイルを参照する場合に，共通して利用するファイルを格納するためのフォルダです。共通フォルダはすべてのビジネスプロセスからアクセスできます。複数のビジネスプロセスがファイルを参照する場合とは，FTPクライアントから別のFTPクライアントへのファイル転送パターンなどを指します。

参考

共通フォルダ内のサブフォルダへは，共通フォルダからの相対パスを指定した場合だけアクセスできます。

共通フォルダ内にあるファイルの読み込み，および書き込みはHCSCサーバの管理者（Service Coordinator管理者）の権限で実行されます。

10.3.1　共通フォルダ定義名と対応するパスの定義

共通フォルダはHCSCサーバに対して複数定義できます。共通フォルダ定義名は共通フォルダを識別するために使用します。共通フォルダ1つに対して，共通フォルダ定義名が1つ存在する必要があります。

共通フォルダはシステム構築時にユーザが作成します。作成したフォルダのフルパスをHCSCサーバランタイム定義のcommon-folder-<共通フォルダ定義名>プロパティに記述することで，共通フォルダとして利用できます。

定義例を次に示します。

common-folder-FOLDER1=/usr/share/store/share1
common-folder-FOLDER2=/usr/share/store/share2

デフォルトの共通フォルダ定義名はdefaultです。対応する共通フォルダのパスは次のとおりです。

<インストールディレクトリ>/CSC/spool/ftp/com

HCSCサーバランタイム定義ファイルについては，マニュアル「サービスプラットフォーム リファレンス」の「6.5.6　HCSCサーバランタイム定義ファイル」を参照してください。

10.3.2　共通フォルダ内のファイルの生成

共通フォルダ内にファイルを生成する際，次のファイル名が使用できます。

ユーザ指定

製品が自動生成した一意なID

共通フォルダにファイルを生成するコンポーネントとファイル名の関係を次の表に示します。

表10‒4　共通フォルダにファイルを生成するコンポーネントとファイル名の関係

種別

ユーザ指定

自動生成

HTTPアダプタ

×

○

SOAPアダプタ

×

○

上記以外

○

×

（凡例）

○：ファイル名に使用できます。

×：ファイル名に使用できません。

(1)　ユーザが指定するファイル名

共通フォルダ内にファイルを生成する場合，そのファイル名は要求電文で指定します。

ファイル名は，共通フォルダを起点とした相対パスを含むファイルパスで指定できます。指定したファイルパスに対するサブフォルダが共通フォルダ内に存在しない場合は，ファイルを生成するコンポーネントがサブフォルダを生成します。

注意事項

必ず共通フォルダからの相対パスとして扱われるため，絶対パスは指定しないでください。

親ディレクトリ表現「../」「..¥」やカレントディレクトリを含む表現は，共通フォルダの配下とならない場合にエラーとなります。

(2)　製品が自動生成するファイル名

システム内で一意のIDを動的に採番し，それを出力ファイル名として使用します。一意のIDの生成にはタイムスタンプを使用しているため，時刻補正をする場合には注意してください。

SOAPアダプタの場合は，自動生成するファイルの格納先に共通フォルダを起点とした相対パスを指定できます。指定したファイルパスに対応するサブフォルダが共通フォルダ内に存在しない場合は，ファイルを生成するコンポーネントがサブフォルダを生成します。

注意事項

必ず共通フォルダからの相対パスとして扱われるため，絶対パスは指定しないでください。

親ディレクトリ表現「../」「..¥」やカレントディレクトリを含む表現は，共通フォルダの配下とならない場合にエラーとなります。

10.3.3　共通フォルダ内のファイルの排他制御

共通フォルダ内のファイルへのアクセス時は，読み込み，書き込みともにファイルロックを取得します。

(1)　ロック種別

共通フォルダ内のファイルへのアクセスでは，読み込み時には共有ロック，書き込み時には占有ロックをそれぞれ取得します。現在のロックが共有ロックまたは占有ロックのファイルに対するロックの可否を次の表に示します。なお，他プロセスとは，ロックしたプロセス以外に排他管理のAPIを使用してアクセスするプロセスのことを指します。

表10‒5　共有ロックと占有ロック

現在のロック

他プロセス／スレッドからの再ロック

共有ロック

占有ロック

共有ロック

○

×

占有ロック

×

×

（凡例）

○：ロックできます。

×：ロックできません。

(2)　ロック取得時のパラメタ

ファイルロックの取得時に使用する次のパラメタについて説明します。

ロックリトライ回数

ロックリトライ間隔

ロックリトライ回数

すでに別のプロセスまたはスレッドによってファイルのロックが取得されている場合，ファイルのロック取得が失敗します。このとき，与えられたロックリトライ回数だけ再度ロックを試みます。

ロックリトライ間隔

ロック失敗から次のロック取得を試みるまでの時間間隔（秒）です。

10.3.4　共通フォルダ内のファイルの削除

共通フォルダ自体はユーザが削除します。共通フォルダ内のファイルは次の方法で削除できます。

ファイル操作アダプタの削除オペレーションを利用した削除

ファイル操作アダプタの削除オペレーションを利用した方法については，「8.7.1　ファイル操作アダプタでサポートするオペレーション」を参照してください。

フォルダ運用管理コマンドを利用した削除

フォルダ運用コマンドを利用した方法については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「5.4.22　共通フォルダ内のファイルを削除する」を参照してください。

FTP受付による自動削除

共通フォルダ内のファイルをFTP受付で削除する方法については，「8.4.10(4)　共通フォルダ内のファイルの削除」を参照してください。

ただし，FTP受付による自動削除の方法では，プロセスが異常終了した場合は自動削除が実行されないで，共通フォルダ内のファイルが残ります。また，ビジネスプロセスを再実行した場合も受付が呼び出されないため，自動削除は実行されません。その場合は，フォルダ運用管理コマンドで別途削除する必要があります。

ファイルイベント受付による自動削除

共通フォルダ内の取得対象ファイルの削除については，「9.1.2　監視対象のファイルの状態管理機能」を参照してください。

付録

付録A　TP1アダプタとTP1/Client/Jの関係

TP1アダプタは，TP1/Client/Jを使用して，OpenTP1またはメインフレーム（TMS-4VやDCCM3など）上で動作するアプリケーションを呼び出します。ここでは，TP1アダプタで利用するTP1/Client/Jについて説明します。

付録A.1　TP1/Client/Jの機能

TP1アダプタでは，次に示すTP1/Client/Jの機能を使用できます。

表A‒1　TP1アダプタで使用できるTP1/Client/Jの機能

項番

TP1/Client/Jの機能

TP1アダプタの対応可否

1

常設コネクション

○

2

リモートプロシジャコール

△

3

トランザクション制御

×

4

TCP/IP通信機能

△

5

サーバからの一方通知受信機能

×

6

TP1/Web接続機能

×

7

動的定義変更機能

×

8

TCP/IPコネクションの確立の監視機能

○

9

DCCM3との接続機能

○

10

XAリソースサービス機能

×

11

トラブルシュート機能

○

12

データ圧縮機能

×

13

送信元ホスト指定機能

×

14

受信ポート固定機能

×

15

ホスト切り替え機能

○

16

サービス要求のスケジュールプライオリティ設定機能

×

（凡例）

○：対応しています。

△：一部対応しています。

×：対応していません。

以降で，TP1/Client/Jの機能について説明します。

(1)　常設コネクション

TP1/Client/Jでは，CUP（TP1/Client/Jを使用したJavaアプレット，Javaアプリケーション，またはJavaサーブレット）とrapサーバの間のコネクションを確立したままでメッセージを送受信できます。このようなコネクションを常設コネクションといいます。なお，リモートAPI機能を使用したRPCを実行するとき，連鎖型RPCを使用するとき，およびトランザクション機能を使用するときは，必ず常設コネクションを確立してください。

常設コネクションを確立すると，コネクション確立・解放のための制御用パケットを減らせるため，通信の効率が向上します。

(a)　常設コネクションの確立・解放

TP1/Client/Jが同時に確立できる常設コネクションは，1CUPで1コネクションだけです。TP1/Client/Jの常設コネクションには，管理方式によって次のモードがあります。

非オートコネクトモード

非オートコネクトモードは，CUPで明示的にopenConnectionメソッドを呼び出してTP1/Serverのrapリスナー，rapサーバとのコネクションを確立します。コネクションを解放するには，CUPでcloseConnectionメソッドを明示的に呼び出します。

オートコネクトモード

オートコネクトモードは，TP1/Client/Jでコネクションを管理します。TP1/Client/Jは，最初に呼び出されたときにコネクションが確立されていないと判断すると，自動的にrapリスナー，rapサーバとの間に常設コネクションを確立します。TP1/Client/Jで管理しているコネクションを強制的に解放したい場合は，closeConnectionメソッドを呼び出します。

非オートコネクトモードを使用するか，オートコネクトモードを使用するかは，TP1/Client/J環境定義のdcrapautoconnectオペランドで指定するか，またはsetRpcextendメソッドで指定します。

closeConnectionメソッドを呼び出して常設コネクションを解放するまで，メッセージの送受信には常設コネクションが使用されます。ただし，何らかの障害が発生した場合，常設コネクションは解放されます。

(2)　リモートプロシジャコール

CUPからSPPへのリモートプロシジャコール（RPC）について説明します。

RPCの詳細については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

(a)　RPCの形態

TP1/Client/Jで実行できるRPCの形態は，同期応答型RPC，非応答型RPC，および連鎖型RPCです。

●同期応答型RPC

CUPからSPPへ問い合わせメッセージを送信し，応答メッセージを受信する形態です。CUPは，SPPから処理結果が返ってくるまで，次の処理を待ちます。同一サービスを複数回呼び出した場合，サーバプロセスはそのたびにスケジュールされます。

●非応答型RPC

CUPからSPPへ問い合わせメッセージを送信し，応答メッセージを受信しない形態です。CUPは，SPPへ問い合わせメッセージを送信したあと，SPPから処理結果を受け取らないで，すぐに次の処理を実行します。

非応答型RPCでは，何らかの通信障害が発生した場合や呼び出したサービスが誤っていた場合でもエラーを受け取れません。

●連鎖型RPC

TP1/Client/JのリモートAPI機能を使用したCUPからSPPへ問い合わせメッセージを送信し，問い合わせた応答メッセージを受信する形態です。CUPは，SPPから処理結果が返ってくるまで，次の処理を待ちます。同期応答型RPCとの違いは，サーバプロセスを固定できることです。連鎖型RPCの場合，同一サービスに複数回問い合わせメッセージを送信しても，サーバプロセスは再スケジュールされません。なお，TP1アダプタでは，この機能を使用できません。

(b)　スケジュール機能

TP1/Serverのスケジュール機能は，CUPからSPPに対するサービス要求でも有効です。TP1/Serverは，SPPのサービスグループごとにスケジュールキューを作成し，サービス要求をスケジュールします。

(c)　ノード間負荷バランス機能

OpenTP1では，RPCによる要求が特定のノードに集中しないようにノード間で負荷を分散する機能があります。これをノード間負荷バランス機能といいます。

ノード間負荷バランス機能を使用するためには，負荷分散の前提として次の条件を満たしている必要があります。

複数のノードに同一のサービスを提供するユーザサーバが起動されていること。

各OpenTP1ノードはシステム共通定義のall_nodeオペランドに自分以外のノードを定義して，お互いのOpenTP1ノードで起動されているユーザサーバの情報（ネーム情報）をやり取りしていること。

ここでは，OpenTP1のノード間負荷バランス機能を使用する場合のTP1/Client/J側，TP1/Server側の関連する定義，処理，およびRPCの処理を説明します。なお，TP1/Client/JではTP1/Server側の判断による負荷分散機能だけを提供します。

●TP1/Server側の判断で負荷分散を行う場合

TP1/Serverのスケジュールサービスが，ノードのスケジュール状態に応じて，より効率的に処理できるノードへ負荷を分散させます。

TP1/Client/J側の定義

TP1/Client/J環境定義にdcscddirect=Yを指定します。

これによって，TP1/Client/J側はTP1/Serverのスケジュールサービスに負荷分散を依頼できます。TP1/Client/J側の定義では，どのOpenTP1ノードのスケジュールサービスに判断を依頼するかを指定します。

この場合，スケジュールを依頼するOpenTP1ノードが複数あると，dchostオペランドに指定された順番にスケジュールを依頼します。dchostオペランドに指定された順番ではなく，スケジュールを依頼するTP1/Serverをランダムに選択するには，TP1/Client/J環境定義にdchostselect=Yを指定します。

TP1/Server側の定義

TP1/Server側の定義では，次のどちらかの設定をする必要があります。

スケジュールサービス定義のオペランドに次の指定をする。

scd_this_node_first = N （デフォルト）

scd_announce_server_status = Y （デフォルト）

スケジュールサービス定義を省略する。

(d)　時間監視

同期応答型RPCを行う場合，応答メッセージを受信するまでの時間を監視できます。

監視時間は，TP1/Client/J環境定義のdcwatchtimオペランドで指定します。

(e)　リモートAPI機能を使用したRPC

TP1/Client/Jでは，CUPとTP1/Server間に常設コネクションを確立して，CUPが発行したAPIを，TP1/Server側に転送してTP1/Server側のプロセスで実行できます。このような機能をリモートAPI機能といいます。リモートAPI機能を使うと，ファイアウォールの内側にあるUAPに対しても，サービスを要求できます。なお，リモートAPI機能を使用したRPCは，TP1/Serverのほかに，DCCM3およびTMS-4V/SPを使用できます。

(f)　ネームサービスを使用したRPC

ネームサービスを使用したRPCは，JavaアプリケーションおよびJavaサーブレットから実行できるサービス要求です。Javaアプレットのセキュリティの制約があるため，Javaアプレットからは実行できません。

●ネームサービスを使用したRPCの機能

ネームサービスを使用したRPCの使用時は，ソケット受信型SPPに対してRPCを発行できません。また，TP1/Client/J環境定義のdccltrpcmaxmsgsizeオペランドに2以上を指定した場合，ネームサービスを使用したRPCは，システム共通定義のrpc_max_message_sizeオペランドをサポートするTP1/Server上で稼働しているサービスの情報だけを取得します。サービスの入力パラメタ長が，サービス要求先のシステム共通定義のrpc_max_message_sizeオペランドの値を超える場合もサービス要求は実行されます。システム共通定義のrpc_max_message_sizeオペランドをサポートしないTP1/Server上のSPPに対してはRPCを発行できません。

●RPCごとにサービス要求先スケジューラを分散させる場合の定義

ネームサービスを使用したRPCでは，サービス要求先スケジューラの情報をネームサーバからキャッシュに格納し，キャッシュの情報を参照してRPCごとにサービス要求先スケジューラを分散させることができます。RPCごとにサービス要求先スケジューラを分散させる場合のTP1/Client/J側，TP1/Server側の関連する定義について説明します。

●TP1/Client/J側の定義

RPCごとにサービス要求先スケジューラを分散させる場合は，TP1/Client/J環境定義にdccltloadbalance=Yを指定します。

これによって，TP1/Client/Jは，ネームサーバから複数のサービス要求先スケジューラの情報を取得し，負荷レベルが最も低いサービス要求先スケジューラの情報をキャッシュに格納します。キャッシュに格納されるサービス要求先スケジューラは，1つだけではなく，複数の場合もあります。

キャッシュに格納されたサービス要求先スケジューラが複数ある場合，最初のサービス要求先スケジューラは，ランダムに選択されます。RPCでのサービス要求が2度目以降の場合は，サービス要求先スケジューラの情報を取得するためにキャッシュを参照し，RPCごとにラウンドロビン方式でサービス要求先スケジューラを切り替え，分散させます。

キャッシュの有効期限の指定

TP1/Client/J環境定義のdccltcachetimオペランドで，サービス要求先スケジューラの情報を保持する，キャッシュの有効期限を指定できます。

キャッシュにサービス要求先スケジューラの情報を格納したあとで，キャッシュの有効期限を満了した場合，そのサービス要求先スケジューラの情報を破棄します。その後，サービス要求先スケジューラの情報を再度取得して，その情報をキャッシュに格納することで，キャッシュを更新します。

TP1/Client/J環境定義のdccltcachetimオペランドは，TP1/Client/J環境定義にdccltloadbalance=Yを指定した場合だけ有効になります。

●TP1/Server側の定義

次に示すTP1/Server側の定義のオペランドを指定すると，ネームサーバからサービス要求先スケジューラの情報を取得するときに，スケジューラの負荷情報も同時に取得します。

スケジュールサービス定義

scd_announce_server_status=Y（デフォルト）

このオペランドにNを指定した場合，スケジューラの負荷レベルは常にLEVEL0（負荷が低い状態）となります。負荷レベルが常にLEVEL0のスケジューラが，TP1/Client/Jのサービス要求先スケジューラとなった場合，実際の負荷状態に関係なく，常にサービス要求先スケジューラとして選択されます。

ユーザサービス定義，またはユーザサービスデフォルト定義

loadcheck_interval

levelup_queue_count

leveldown_queue_count

「levelup_queue_count」および「leveldown_queue_count」については，スケジューラの負荷レベルがサービス要求の滞留数で決まる方式とする場合に指定します。

●マルチホームドホスト形態のTP1/Serverに対してRPCを行う場合の定義

ネームサービスを使用したRPCでは，通信先TP1/Serverがマルチホームドホスト形態の場合に通信障害が発生することがあります。これは，CUPが存在するネットワークから，通信先TP1/Serverのシステム共通定義のmy_hostオペランドで指定したホスト名（IPアドレス）に対応するネットワークアダプタに通信できないことが原因です。

これを回避するためには，TP1/Client/J環境定義にdccltnammlthost=Yを指定します。ネットワークの構成例を次の図に2つ示し，それぞれのネットワーク構成でのTP1/Client/J環境定義のdccltnammlthostオペランドの要否を示します。

図A‒1　マルチホームドホスト形態のTP1/Serverに対してRPCを行う場合の例

ネットワーク構成例2のCUPがIPアドレス4と通信するには，TP1/Client/J環境定義にdccltnammlthost=Yの指定が必要です。この指定がない場合，CUPとIPアドレス4との間では通信障害が発生します。

通信先TP1/Serverがマルチホームドホスト形態で，かつ同じTP1/Server上にサービス要求先のSPPが存在しているときは，TP1/Client/J環境定義にdccltnammlthost=Yを指定することでRPCが行えるようになります。通信先TP1/Serverのシステム共通定義のall_nodeオペランドに，CUPが接続されていないネットワーク上に存在するTP1/Serverが指定されている場合，このTP1/Server上のSPPに対してRPCを行うと通信障害が発生します。なお，通信先TP1/Serverがマルチホームドホスト形態でない場合，TP1/Client/J環境定義のdccltnammlthostオペランドの指定に関係なくRPCを行えます。

(g)　通信先を指定したRPC

通信先を指定したRPCを使用すると，サービス要求を実行するサーバ（通信先のOpenTP1ノード）を明示的に指定できます。

通信先を指定したRPCを使用した場合，サービス要求を実行するサーバに指定した通信先のOpenTP1ノードでサービス要求が実行されます。指定したOpenTP1ノードが停止，または閉塞しているときでも，他OpenTP1ノードへの転送は行われません。また，ノード間負荷バランス機能は使用できません。

(h)　同期応答型RPCタイムアウト時のサーバ負荷軽減

TP1/Client/JのCUPからサーバを呼び出すと，TP1/Serverではサービス要求を受け付けます。

この要求はSPPの実行待ち時間，実行時間，通信障害などによって，遅れるおそれがあるため，TP1/Client/J側では応答待ち時間に上限を設けることで異常を監視しています。

一方TP1/Server側では，TP1/Client/Jの最大応答待ち時間を認識していないため，TP1/Client/J側でタイムアウトを検出していても，TP1/Server側ではサービスを処理し続けている場合があります。

同期応答型RPCタイムアウト時のサーバ負荷軽減機能を使用すると，TP1/Server側での上記のような不要な処理を軽減できます。同期応答型RPCタイムアウト時のサーバ負荷軽減機能を使用するかどうかは，TP1/Client/J環境定義のdcwatchtimrpcinheritオペランドで指定します。同期応答型RPCタイムアウト時のサーバ負荷軽減機能の処理概要を次の図に示します。

図A‒2　同期応答型RPCタイムアウト時のサーバ負荷軽減機能の処理概要

(i)　ServerSocketを使用するRPC

TP1/Client/Jで，スケジューラダイレクト機能を使用したRPC，ネームサービスを使用したRPC，および通信先を指定したRPCを行う場合，ServerSocketを使用します。TP1/Client/Jを使用するクライアントプログラムを動作させるJava VMでセキュリティマネジャを適用する場合，TP1/Client/JのクラスライブラリがServerSocketの機能（connect，listen，およびaccept）を使用できるよう，適切なパーミッションをセキュリティポリシファイルに記述してください。Javaサーブレット，またはEJBの場合，これらコンテナを実装しているアプリケーションサーバ製品で，セキュリティの制約のためデフォルトでセキュリティマネジャを使用していることがあります。使用するアプリケーションサーバの仕様をご確認の上，適切に設定してください。

(j)　マルチスケジューラ機能を使用したRPC

CUPからスケジュールキューを使うSPP（キュー受信型サーバ）にサービスを要求した場合，要求先SPPがあるノードのスケジューラデーモンが，いったんサービス要求メッセージを受信し，該当するSPPのスケジュールキューに格納します。スケジューラデーモンとは，スケジュールサービスを提供するシステムデーモンのことです。

長大なサービス要求メッセージは，一定の長さに分割してスケジューラデーモンに送信します。スケジューラデーモンは，サービス要求メッセージを組み立ててキュー受信型サーバのスケジュールキューに格納します。スケジューラデーモンは，OpenTP1システムごとに1プロセスです。そのため，分割されたサービス要求メッセージの受信処理が完了するまで，スケジューラデーモンはほかのサービス要求メッセージを受信できません。通信速度が遅い回線を使用して，長大なサービス要求メッセージを送信した場合，ほかのサービス要求のスケジューリングが遅延することがあります。また，システムの大規模化，マシンやネットワークの高性能化などに伴って，効率良くスケジューリングできないことがあります。この場合，従来のスケジューラデーモンとは別に，サービス要求受信専用デーモンを複数プロセス起動し，サービス要求メッセージ受信処理を並行動作させることによって，スケジューリング遅延を回避できます。この機能をマルチスケジューラ機能といいます。以降，従来のスケジューラデーモンをマスタスケジューラデーモン，サービス要求受信専用デーモンをマルチスケジューラデーモンと呼びます。

マルチスケジューラ機能の検討が必要なシステム構成については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

●マルチスケジューラデーモンをランダムに選択する方法

マルチスケジューラ機能を使用することで，複数起動されているマルチスケジューラデーモンの中から，利用できるマルチスケジューラデーモンをランダムに選択してサービス要求を送信できます。マルチスケジューラデーモンをランダムに選択して，スケジューラダイレクト機能，またはネームサービスを使用したRPCを実行できます。

●スケジューラダイレクト機能を使用したRPC

TP1/Client/J環境定義dcscddirectオペランドにYを指定して，スケジューラダイレクト機能を使用したRPCを行う場合について説明します。

TP1/Client/Jでは，窓口となるTP1/Serverのネームサービスへ問い合わせないで，マルチスケジューラデーモンをランダムに選択できます。これによって通信回数が削減され，ネームサービスの負荷を軽減できます。

マルチスケジューラデーモンをランダムに選択するためには，TP1/Client/J環境定義のdchostオペランド，またはdcscdportオペランドに次のポート番号を指定します。

スケジュールサービス定義のscd_portオペランドに指定された，スケジュールサービスのポート番号

スケジュールサービス定義のscdmultiの-pオプションに指定されたポート番号

また，あらかじめTP1/Serverで起動しているマルチスケジューラデーモンのプロセス数を，TP1/Client/J環境定義のdcscdmulticountオペランドに指定しておく必要があります。サービス要求を送信するマルチスケジューラデーモンのポート番号は，次に示す範囲の値からランダムに選択されます。

下限値：TP1/Client/J環境定義のdchostオペランド，またはdcscdportオペランドに指定したポート番号の値

上限値：下限値 + TP1/Client/J環境定義のdcscdmulticountオペランドに指定したプロセス数 - 1

ただし，TP1/Client/J環境定義のdchostオペランドで指定した窓口となるTP1/Server間で，スケジュールサービス定義のscdmultiで指定した値を統一する必要があります。

●ネームサービスを使用したRPC

マルチスケジューラ機能を使用して，ネームサービスを使用したRPCを行う場合について説明します。サービス情報を一時的に格納する領域に，該当するサービス情報がないときはネームサービスにサービス情報を問い合わせます。サービス情報を基にマルチスケジューラデーモンをランダムに選択してサービス要求を送信します。

●TP1/Client/J環境定義とサービス要求を送信するスケジューラデーモンの関連

マルチスケジューラ機能を使用した場合，サービス要求を送信するスケジューラデーモンはTP1/Client/J環境定義の指定によって異なります。

スケジューラダイレクト機能を使用したRPCの場合の，TP1/Client/J環境定義のオペランドの指定とスケジューラデーモンの関連を次の表に示します。

表A‒2　TP1/Client/J環境定義のオペランドの指定とスケジューラデーモンの関連（スケジューラダイレクト機能を使用したRPC）

TP1/Client/J環境定義のオペランドの指定

サービス要求を送信するスケジューラデーモン

dcscddirect

dcscdmulti

dcscdmulticount

Y

Y

○

ランダムに選択したマルチスケジューラデーモン※

−

TP1/Client/J環境定義のdchostオペランド，またはdcscdportオペランドに指定したポート番号で起動されているスケジューラデーモン

N

無効

TP1/Client/J環境定義のdchostオペランド，またはdcscdportオペランドに指定したポート番号で起動されているスケジューラデーモン

（凡例）

Y：オペランドの指定値がYです。

N：オペランドの指定値がNです。

○：オペランドに値を指定します。

−：オペランドに値を指定しません。

注※

マルチスケジューラデーモンのポート番号は，次に示す範囲の値から選択されます。

下限値：TP1/Client/J環境定義のdchostオペランド，またはdcscdportオペランドに指定したポート番号の値

上限値：下限値 + TP1/Client/J環境定義のdcscdmulticountオペランドに指定したプロセス数 - 1

ネームサービスを使用したRPCの場合の，TP1/Client/J環境定義のオペランドの指定とスケジューラデーモンの関連を次の表に示します。

表A‒3　TP1/Client/J環境定義のオペランドの指定とスケジューラデーモンの関連（ネームサービスを使用したRPC）

TP1/Client/J環境定義のオペランドの指定

サービス要求を送信するスケジューラデーモン

dcnamuse

dcscdmulti

dcscdmulticount

Y

Y

無効

サービス情報を基にランダムに選択したマルチスケジューラデーモン※

N

マスタスケジューラデーモン※

（凡例）

Y：オペランドの指定値がYです。

N：オペランドの指定値がNです。

注※

ネームサービスへの問い合わせが発生します。

(3)　トランザクション制御

この機能は，リモートAPI機能を使用する場合で，要求先TP1/Server Baseのバージョンが07-50以降のときだけ使用できます。

TP1アダプタでは，この機能を使用できません。

(4)　TCP/IP通信機能

TP1/Client/JのTCP/IP通信機能は，CUPがクライアント型かサーバ型かによって通信方法が異なります。CUPがクライアント型の場合は，CUPから定義や引数で指定した通信相手に対してコネクションを確立して通信します。CUPがサーバ型の場合は，定義で指定したポートで通信相手がコネクションを確立してくるのを待って通信します。コネクション確立後は，引数で指定した領域に対してデータの送受信を行います。

(5)　サーバからの一方通知受信機能

一方通知受信機能を使用すると，オンライン開始の合図をクライアント側に一斉配布する，従来，メインフレームのOLTPでの端末一斉起動と同様な運用ができるようになります。

TP1アダプタでは，この機能を使用できません。

(6)　TP1/Web接続機能

TP1/Web接続機能は，Javaアプレットとして作成したCUPとTP1/Webを接続して，HTTPプロトコルに基づいた通信サービスをするための機能です。

TP1アダプタでは，この機能を使用できません。

(7)　動的定義変更機能

TP1/Client/Jは，TP1/Client/J環境定義をrpcOpenメソッド内で解析し，CUPに一意の情報として格納しています。

動的定義変更機能を使用すると，TP1/Client/J環境定義で定義しなかったオペランドの値を設定したり，TP1/Client/J環境定義で定義したオペランドの値を動的に変更したりできます。

(8)　TCP/IPコネクションの確立の監視機能

TCP/IPコネクションの確立の監視機能では，データ送信時のTCP/IPコネクションの確立処理に対する最大監視時間を指定し，コネクションの確立処理を監視できます。

(9)　DCCM3との接続機能

TP1/Client/Jでは，RPCやTCP/IP通信機能を使用して，VOS3やVOS1上のDCCM3と接続できます。

(a)　DCCM3とのRPC

TP1/Client/Jでは，OpenTP1のサーバだけでなく，DCCM3のサーバともRPCを使用した通信ができます。DCCM3とRPCを行うには，DCCM3側に，OpenTP1のRPC要求を解釈する機能が組み込まれていることが前提です。次に示す製品をDCCM3側に組み込むことで，DCCM3ともRPCを使用した通信ができます。

DCCM3側の適用OSがVOS3の場合

DCCM3/Internet

DCCM3側の適用OSがVOS1の場合

DCCM3/SERVER/TP1

相手サーバがDCCM3の場合の特徴は次のとおりです。

使用できるRPCの形態は，同期応答型RPCと非応答型RPCです。連鎖型RPCは使用できません。

トランザクション制御機能は使用できません。

常設コネクションを使用してDCCM3論理端末へRPCを行う場合，負荷分散機能を使用できます。詳細については，「●DCCM3論理端末に対してRPCを行う場合の負荷分散」を参照してください。

DCCM3に対してRPCを行う場合，サービス名がトランザクション名称と評価されます。

●相手サーバの指定方法

DCCM3のサーバとRPCを使用した通信をする場合，相手サーバをサービスグループ名とサービス名で指定します。この指定方法はOpenTP1のサーバに対してRPCを行う場合と同じです。

サービスグループ名

サービスグループ名として不正でないダミーの文字列を指定します。1〜31文字の識別子を指定してください。

サービス名

DCCM3側のトランザクション名称を指定します。使用できる文字は，アルファベット（A〜Z，a〜z）と数字（0〜9）です。文字数の合計が1〜8文字になるように指定してください。

●相手サーバのアドレス定義

DCCM3のサーバとRPCを使用した通信をする場合，OpenTP1のネームサービスの管理外にあるサーバを呼び出すため，TP1/Client/J側でサービス名ごとに定義を分けて，サーバのアドレスを定義する必要があります。サーバのアドレスを定義するには，TP1/Client/J環境定義のdchostオペランドに，それぞれRPC受け付け窓口のホスト名およびポート番号を指定します。

●DCCM3論理端末に対してRPCを行う場合の負荷分散

TP1/Client/JとDCCM3論理端末が常設コネクションを使用してRPCを行う場合，コネクション確立時に接続先を複数のDCCM3に振り分けて負荷を分散できます。TP1/Client/Jは，TP1/Client/J環境定義のdchostオペランドに指定された複数のDCCM3論理端末のホスト名およびポート番号の中から，接続先をランダムに選択し，接続を試みます。あるDCCM3論理端末との接続に失敗すると，それ以外のDCCM3論理端末から再びランダムに選択し，接続を試みます。この処理を繰り返し，TP1/Client/J環境定義のdchostオペランドに指定されたすべてのDCCM3論理端末との接続にすべて失敗したときに，初めてエラーを検知します。

●TP1/Client/J環境定義の定義例

次に示す図のように動作する，DCCM3接続時のTP1/Client/J環境定義の定義例を示します。

図A‒3　DCCM3のサーバとのRPC

TP1/Client/J環境定義で，各トランザクションを処理するサーバのアドレス（RPC受け付け窓口）を，定義ファイルを分けてdchostオペランドに定義します。

RPCを行うとき，定義ファイルからRPC受け付け窓口のアドレスを求め，RPCのメッセージを送信します。

RPCのメッセージを解釈し，要求されたサービスを実行します。

同期応答型RPCの場合，サーバからの応答メッセージを受信します。

定義ファイル"tran1.ini"の定義例

dcrapdirect=Y
dcwatchtim=180
dcrapautoconnect=Y
dchostselect=Y
#"TRAN1"のトランザクションを処理できるサーバのアドレスを定義
dchost=xxx.xxx.xxx.xxx:10020,zzz.zzz.zzz.zzz:10022

定義ファイル"tran2.ini"の定義例

dcrapdirect=Y
dcwatchtim=180
dcrapautoconnect=Y
dchostselect=Y
#"TRAN2"のトランザクションを処理できるサーバのアドレスを定義
dchost=yyy.yyy.yyy.yyy:10021,zzz.zzz.zzz.zzz:10022

●DCCM3論理端末に対してRPCを行う場合の注意事項

リモートAPI機能を使用したRPCだけ使用できます。

連鎖型RPCは使用できません。

トランザクション制御機能は使用できません。

TP1/Client/J環境定義のdccltinquiretimeオペランドを指定しても無効になります。CUPからサーバに対する問い合わせ間隔最大時間は，DCCM3の「端末放置監視時間」で指定してください。

DCCM3側の注意事項については，マニュアル「VOS3 データマネジメントシステム XDM E2系 概説」およびマニュアル「VOS1 データコミュニケーションマネジメントシステム DCCM3 解説」を参照してください。

(b)　DCCM3論理端末への端末識別情報の通知

常設コネクションを使用してDCCM3論理端末と通信する場合，端末識別情報をDCCM3論理端末に通知し，CUPに割り当てられるDCCM3の論理端末を固定することができます。

●DCCM3論理端末でのメッセージ送受信方法

DCCM3論理端末では，通信相手となるTP1/Client/JをIPアドレスとDCCM3論理端末のポート番号で区別する論理端末として定義し，論理端末ごとにメッセージの送受信を行っています。

したがって，複数のCUPを同一マシンから起動した場合，どのCUPからの要求でも，DCCM3論理端末から見るとIPアドレスが同じになってしまいます。複数のCUPから同じDCCM3論理端末のポートにサービスを要求すると，DCCM3の定義では区別が付きません。そのため，該当するDCCM3の論理端末が複数定義されていた場合，DCCM3のどの論理端末にCUPが割り当てられるのかが不定になってしまいます。サービス要求を受け付けるDCCM3の論理端末が異なると，DCCM3側のサーバ処理の順番が保証されなくなるため，業務によっては問題となることがあります。

●端末識別情報の通知

CUPがDCCM3論理端末と常設コネクションを確立するときに，端末識別情報をDCCM3論理端末に通知することで，CUPに割り当てられるDCCM3の論理端末を固定することができます。これを端末識別情報設定機能といいます。この機能を使用することで，CUPを常に同じDCCM3の論理端末に割り当てることができます。なお，DCCM3側では，この機能を端末固定割り当て機能といいます。

端末識別情報設定機能を使用していない場合と使用している場合のCUPとDCCM3論理端末の関係を，次の図にそれぞれ示します。

図A‒4　CUPとDCCM3論理端末の関係（端末識別情報設定機能を使用していない場合）

図A‒5　CUPとDCCM3論理端末の関係（端末識別情報設定機能を使用している場合）

端末識別情報設定機能は，次の方法で使用できます。

TP1/Client/J環境定義のdchostオペランドにDCCM3論理端末のホスト名を指定します。

TP1/Client/J環境定義のdchostオペランドまたはdcrapportオペランドにDCCM3論理端末のポート番号を指定します。

TP1/Client/J環境定義のdccltconnectinfオペランドに端末識別情報を設定します。

次の方法でDCCM3論理端末との常設コネクションを確立します。

TP1/Client/J環境定義のdcrapautoconnectオペランドにYを指定します。

●DCCM3論理端末に端末識別情報を通知する場合の注意事項

端末固定割り当て機能を使用していないDCCM3の論理端末に対して，TP1/Client/Jから端末識別情報を設定して常設コネクションの確立を要求した場合，DCCM3はTP1/Client/Jが設定した端末識別情報の設定内容を無視します。

TP1/Client/Jから端末識別情報を設定して，TP1/Serverのrapサーバと常設コネクションを確立する場合，rapサーバはTP1/Client/Jが設定した端末識別情報の設定内容を無視します。また，TP1/Client/Jがrapサーバを介してDCCM3へRPCを発行する場合，TP1/Client/Jで設定した端末識別情報はDCCM3に伝達されません。

端末識別情報は，リモートAPI機能を使用したRPCの場合だけ有効となります。ネームサービスを使用したRPC，またはスケジューラダイレクト機能を使用したRPCの場合は，端末識別情報を設定しても無視されます。

(10)　XAリソースサービス機能

XAリソースサービス機能を使用する場合，TP1 Connectorが必要です。

TP1アダプタでは，この機能を使用できません。

(11)　トラブルシュート機能

TP1/Client/Jでは，トラブルシュート機能として，UAPトレース，データトレース，エラートレース，メモリトレース，メソッドトレース，デバッグトレース，性能解析トレース，および性能検証用トレースを取得できます。

詳細については，「付録A.3　TP1/Client/Jの障害対策」を参照してください。

(12)　データ圧縮機能

データ圧縮機能を使用すると，RPCによってネットワーク上に送り出されるユーザデータを圧縮できます。これによってネットワーク上に送り出されるパケット数を削減し，ネットワークの混雑を緩和できます。

データ圧縮機能を使用するかどうかは，TP1/Client/J環境定義のdccltdatacompオペランドで指定します。

TP1アダプタでは，この機能を使用できません。

(13)　送信元ホスト指定機能

TP1/Client/Jでは，RPCやTCP/IP通信機能でのコネクション確立要求時に，CUPの送信元ホストを指定できます。この機能を，送信元ホスト指定機能といいます。

CUPが動作するホスト上に，複数のネットワークアダプタが接続されている場合，CUPがこれらのコネクション確立要求時に使用する送信元ホストは，TCP/IPの制御で任意に決まります。しかし，送信元ホスト指定機能を使用すると，次のコネクション確立要求時の送信元ホストを固定できます。

スケジューラダイレクト機能を使用したRPC

ネームサービスを使用したRPC

リモートAPI機能を使用したRPC

通信先を指定したRPC

TCP/IP通信機能

CUPの送信元ホストは，TP1/Client/J環境定義のdccltcupsndhostオペランドで指定します。

(14)　受信ポート固定機能

TP1/Client/Jでは，スケジューラダイレクト機能を使用したRPCの受信ポート，およびネームサービスを使用したRPCの受信ポートを固定できます。この機能を，受信ポート固定機能といいます。

この機能は，TP1/ServerからTP1/Client/JへのRPCの応答通信をする場合で，TP1/ServerとTP1/Client/Jとの間に設置したファイアウォールでTP1/Client/Jの受信ポートにだけ通知を許可するようにフィルタリングしたいときに使用します。

この機能を使用する場合は，TP1/Client/J環境定義のdccltcuprcvportオペランドを指定します。

TP1アダプタでは，この機能を使用できません。

(15)　ホスト切り替え機能

サーバダウンなどの理由によって，指定したホストとの通信が一時的に不可となった場合，通信先ホストを1つしか指定していないと，TP1/Client/Jのメソッドはエラーリターンし，通信先ホストの指定を変更したあと，CUPを再起動する必要があります。

通信先ホストを複数指定しておくと，TP1/Client/Jはホストを切り替えて，別のホストに通信を試みます。これによって，ユーザは通信先ホストの切り替えを意識することなく業務を継続することができます。

なお，障害の内容によっては，ホストを切り替えない場合があります。

(16)　サービス要求のスケジュールプライオリティ設定機能

CUPからのサービス要求に，優先順位（スケジュールプライオリティ）を付けることができます。1つの処理から呼び出す複数のサービス要求に優先順位を付けたい場合，サービス要求ごとのプライオリティを設定できます。

TP1アダプタでは，この機能を使用できません。

付録A.2　TP1/Client/Jの定義

TP1/Client/J環境定義ファイルについて説明します。

(1)　TP1/Client/Jの定義の概要

ここでは，TP1/Client/J環境定義ファイルのオペランド一覧，定義の規則，およびパス名の形式について説明します。

(a)　TP1/Client/J環境定義の一覧

TP1/Client/J環境定義ファイルのオペランド一覧を，次の表に示します。

項番

オペランド

定義内容

指定値※¹

1

dcnamuse

ネームサービスを使用したRPCを使用するかどうかを指定

Y｜《N》

2

dcnamport※2

ネームサービスのポート番号

〈符号なし整数〉((5001〜65535))《10000》

3

dchost※2

窓口となるTP1/Serverのホスト名

〈文字列〉

4

dcwatchtim※2

最大応答待ち時間

〈符号なし整数〉((0〜65535))《180》（単位：秒）

5

dccltinquiretime※2

常設コネクション問い合わせ間隔最大時間

〈符号なし整数〉((0〜1048575))（単位：秒）

6

dcwatchtiminherit※2

リモートAPI機能を使用したRPCを行う場合に，CUPの最大応答待ち時間をrapサーバ側に引き継ぐかどうかを指定

Y｜《N》

7

dcwatchtimrpcinherit※2

CUPの最大応答待ち時間をTP1/Server側に引き継ぐかどうかを指定

Y｜《N》

8

dccltdelay※2

最大通信遅延時間

〈符号なし整数〉((0〜65535))《0》（単位：秒）

9

dcselint

応答電文監視時間間隔

〈符号なし整数〉((1〜65535))《100》（単位：ミリ秒）

10

dccltextend※2

TP1/Client/Jの機能拡張レベルの設定を指定

00000000｜00000001

11

dccache

ネームキャッシュの最大エントリ数

〈符号なし整数〉((2〜256))《8》

12

dchostselect

窓口となるTP1/Serverをランダムに選択するかどうかを指定

Y｜《N》

13

dcscddirect

TP1/Serverのネームサービスにサービス情報を問い合わせないで，スケジューラダイレクト機能を使用したRPCを使用するかどうかを指定

Y｜《N》

14

dcscdport※2

スケジュールサービスのポート番号

〈符号なし整数〉((5001〜65535))

15

dcscdloadpriority※2

サービス要求を受け付けた窓口となるTP1/Serverを優先して負荷分散するかどうかを指定

Y｜《N》

16

dcrapdirect

TP1/Serverのネームサービスにサービス情報を問い合わせないで，直接rapリスナーに問い合わせる機能，すなわちリモートAPI機能を使用するかどうかを指定

《Y》｜N

17

dcrapport※2

rapリスナーのポート番号

〈符号なし整数〉((5001〜65535))

18

dcrapautoconnect

CUPとrapサーバとの間の常設コネクションを自動的に確立させるかどうかを指定

Y｜《N》

19

dcerrtrace

CUPでエラートレースを取得するかどうかを指定

Y｜《N》

20

dcerrtracepath

エラートレースファイル作成ディレクトリ

〈文字列〉

21

dcerrtracesize

エラートレースファイルサイズ

〈符号なし整数〉((4096〜1048576))《4096》（単位：バイト）

22

dcmethodtrace

CUPでメソッドトレースを取得するかどうかを指定

Y｜《N》

23

dcmethodtracepath

メソッドトレースファイル作成ディレクトリ

〈文字列〉

24

dcmethodtracesize

メソッドトレースファイルサイズ

〈符号なし整数〉((4096〜1048576))《4096》（単位：バイト）

25

dcuaptrace

CUPでUAPトレースを取得するかどうかを指定

Y｜《N》

26

dcuaptracepath

UAPトレースファイル作成ディレクトリ

〈文字列〉

27

dcuaptracesize

UAPトレースファイルサイズ

〈符号なし整数〉((4096〜1048576))《4096》（単位：バイト）

28

dcdatatrace

CUPでデータトレースを取得するかどうかを指定

Y｜《N》

29

dcdatatracepath

データトレースファイル作成ディレクトリ

〈文字列〉

30

dcdatatracesize

データトレースファイルサイズ

〈符号なし整数〉((4096〜1048576))《4096》（単位：バイト）

31

dcdatatracemaxsize

データトレースの最大データ長

〈符号なし整数〉((16〜1048576))《128》（単位：バイト）

32

dcclttrstatisitem

トランザクションブランチの統計情報を取得する項目を指定

統計情報項目〔,統計情報項目〕…

33

dcclttroptiitem

複数のユーザサーバで構成されるグローバルトランザクションの性能を向上させるための最適化項目を指定

トランザクション最適化項目〔,トランザクション最適化項目〕…

34

dcclttrwatchtime

トランザクション同期点処理時の最大通信待ち時間

〈符号なし整数〉((1〜65535))（単位：秒）

35

dcclttrrbinfo

トランザクションブランチがロールバックした場合に，ロールバック要因に関する情報をログに取得するかどうかを指定

no｜self｜remote｜all

36

dcclttrlimittime

トランザクションブランチ最大実行可能時間

〈符号なし整数〉((0〜65535))（単位：秒）

37

dcclttrrbrcv

RPC先トランザクションブランチにロールバック指示を送信したあと，ロールバック完了通知を受信するかどうかを指定

Y｜N

38

dcclttrrecoverytype

UAP障害時のトランザクション同期点処理方式を指定

type1｜type2｜type3

39

dcclttrexptm

トランザクションブランチ限界経過時間

〈符号なし整数〉((0〜65535))（単位：秒）

40

dcclttrcputm

トランザクションブランチCPU監視時間

〈符号なし整数〉((0〜65535))（単位：秒）

41

dcclttrexpsp

トランザクションブランチの処理を監視するとき，次の処理時間も監視時間に含むかどうかを指定

監視対象のトランザクションブランチが，RPC機能を使ってほかのトランザクションブランチを呼び出し，その処理が終わるのを待つ時間

連鎖型RPCで呼び出されたサーバUAPが次のサービス要求を待つ時間

監視対象のトランザクションブランチが，非応答型RPCを使用してほかのトランザクションブランチを呼び出したあと，処理結果受信処理を行っている時間

Y｜N｜F

42

dcsndrcvtype

TCP/IP通信機能の使用時に，初期化する環境を指定

DCCLT_ONEWAY_SND｜DCCLT_ONEWAY_RCV｜DCCLT_SNDRCV

43

dcrcvport

受信用のCUPのポート番号

〈符号なし整数〉((1〜65535))《11000》

44

dcsndhost※2

接続するMHPが存在するノードのホスト名

〈文字列〉

45

dcsndport※2

接続するMHPのポート番号

〈符号なし整数〉((1〜65535))《12000》

46

dcsockopenatrcv

TCP/IP通信機能の使用時に，1コネクションで送受信する場合の，受信用ソケットを開設する契機（送信相手からの接続を待ち受け始める契機）を指定

Y｜《N》

47

dcweburl

サービス要求先のTP1/WebのURL

〈パス名〉

48

dccltdbgtrcfilecount

デバッグトレースファイルの最大ファイル数

〈符号なし整数〉((0〜256))《0》

49

dccltrpcmaxmsgsize

RPC送受信電文の最大長

〈符号なし整数〉((1〜8))《1》（単位：メガバイト）

50

dcscdhostchange

TP1/Client/J環境定義のdchostオペランドに指定したサービス要求先スケジューラをRPCごとに分散させるかどうかを指定

Y｜《N》

51

dccltloadbalance

ネームサーバから得た複数のサービス要求先スケジューラの情報から，負荷レベルが最も低いサービス要求先スケジューラの情報をキャッシュに格納するかどうかを指定

Y｜《N》

52

dccltcachetim

キャッシュの有効期限

〈符号なし整数〉((0〜65535))《30》（単位：秒）

53

dccltconnecttimeout

コネクション確立最大監視時間

〈符号なし整数〉((0〜65535))《0》（単位：秒）

54

dccltprftrace

TP1/Client/Jをサービスプラットフォーム上で動作させた場合に，サービスプラットフォームの性能解析トレースを取得するかどうかを指定

《Y》｜N

55

dccltprfinfosend

TP1/Serverに対して，ネームサービスを使用したRPC，およびスケジューラダイレクト機能を使用したRPCを行う場合に，OpenTP1の性能検証用トレースに出力する情報としてTP1/Client/J内部で識別情報を付加するかどうかを指定

《Y》｜N

56

dccltnammlthost

マルチホームドホスト形態のTP1/Serverに対してネームサービスを使用したRPCを行うかどうかを指定

Y｜《N》

57

dccltdatacomp

データ圧縮機能を使用するかどうかを指定

Y｜《N》

58

dccltconnectinf※2

端末識別情報として，DCCM3論理端末の論理端末名称をEBCDIKコードで指定

端末識別情報

59

dcscdmulti

マルチスケジューラ機能を使用するかどうかを指定

Y｜《N》

60

dcscdmulticount

マルチスケジューラデーモンのプロセス数

〈符号なし整数〉((1〜4096))《1》

61

dccltcupsndhost

CUPの送信元ホスト

〈文字列〉

62

dccltcuprcvport

サーバからのメッセージを受信するCUPのポート番号

〈符号なし整数〉((5001〜65535))

63

dcclttrcmplmttm

トランザクション完了限界時間

〈符号なし整数〉((0〜65535))（単位：秒）

64

dccltsendbuffsize

TCP/IPの送信バッファサイズ

〈符号なし整数〉((8192〜2147483647))（単位：バイト）

65

dccltrecvbuffsize

TCP/IPの受信バッファサイズ

〈符号なし整数〉((8192〜2147483647))（単位：バイト）

66

dcinquiretimecheck

常設コネクションを使用し，かつオートコネクトモードの場合に，CUP実行プロセスで問い合わせ間隔最大時間を監視するかどうかを指定

《Y》｜N

67

dcnotifyreshost

サービス要求元が応答電文を受信するために使用するIPアドレスを通知するかどうかを指定

Y｜《N》

68

dcresponsehost

サービス要求元が応答電文を受信するために使用するIPアドレスを通知する場合のホスト名

〈文字列〉

注※1

指定値の記号については，「(b)　定義の規則」を参照してください。

注※2

TP1アダプタの接続先動的変更を使用して，通信条件パラメタを変更できます。TP1アダプタの接続先動的変更については，「2.7.6　TP1アダプタの接続先動的変更」を参照してください。

(b)　定義の規則

定義の説明に使用する各種の記号を説明します。

ここで述べる文法記述記号，属性記述記号，および構文要素記号は実際の定義には記述しません。

●文法記述記号

文法の記述について説明する記号です。

文法記述記号

意味

〔　　　〕

この記号で囲まれている項目は省略できることを示します。

（例）ホスト名〔:ポ−ト番号〕

これは，「ホスト名」と指定するか，または「ホスト名:ポ−ト番号」と指定することを示します。

｜

この記号で仕切られた項目は選択できることを示します。

（例）dcnamuse=Y｜N

これは，dcnamuse=Yと指定するか，またはdcnamuse=Nと指定することを示します。

…

記述が省略されていることを示します。この記号の直前に示された項目を繰り返し複数個指定できます。

（例）ホスト名〔:ポ−ト番号〕〔,ホスト名〔:ポ−ト番号〕,…〕

ホスト名〔:ポ−ト番号〕を続けて指定できることを示します。

●属性記述記号

ユーザ指定値の範囲などを説明する記号です。

属性記述記号

意味

〜

この記号のあとにユーザ指定値の属性を示します。

《 》

ユーザ指定値の省略値を示します。

〈 〉

ユーザ指定値の構文要素記号を示します。

(( ))

ユーザ指定値の指定範囲を示します。

●構文要素記号

ユーザ指定値の内容を説明する記号です。

構文要素記号

意味

〈英字〉

アルファベット（A〜Z，a〜z），および_（アンダースコア）

〈英数字〉

英字と数字（0〜9）

〈英字記号〉

アルファベット（A〜Z，a〜z），#，@，および¥

〈符号なし整数〉

数字（0〜9）

〈符号なし16進整数〉

数字（0〜9），A〜F，a〜f

〈記号名称〉

英字記号と数字の並び（先頭は英字記号）

〈文字列〉

任意の文字の配列

〈パス名〉

記号名称，/，および .（ピリオド）

（ただし，パス名は使用するOSに依存）

(c)　パス名の記述形式

次のオペランドにパス名を指定する場合，ファイル区切り文字に「¥」を使用するときは，「¥」を「¥¥」と記述してください。

dcerrtracepath

dcmethodtracepath

dcuaptracepath

dcdatatracepath

例　"C:¥Clt4J¥trace"にエラートレースを取得する場合

dcerrtracepath = C:¥¥Clt4J¥¥trace

または，

dcerrtracepath = C:/Clt4J/trace

(2)　TP1/Client/J環境定義の詳細

Javaアプリケーション，またはJavaサーブレットでは，TP1/Client/J環境定義を任意のファイルに格納してrpcOpenメソッドの引数でこのファイル名を指定します。また，rpcOpenメソッドを引数なしで呼び出した場合は，システムプロパティとして定義することもできます。

Javaアプレットでは，paramタグでTP1/Client/J環境定義を定義します。

TP1アダプタからTP1/Client/Jを使用する場合，通信方式によって必要な定義と省略できる定義があります。

詳細については，「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.3.6　TP1アダプタを定義する」の「TP1/Client/J環境定義の設定」の説明を参照してください。

TP1/Client/J環境定義を次に示します。

(a)　形式

〔dcnamuse=Y|N〕
〔dcnamport=ネームサービスのポート番号〕
〔dchost=窓口となるTP1/Serverのホスト名〕
〔dcwatchtim=最大応答待ち時間〕
〔dccltinquiretime=常設コネクション問い合わせ間隔最大時間〕
〔dcwatchtiminherit=Y|N〕
〔dcwatchtimrpcinherit=Y|N〕
〔dccltdelay=最大通信遅延時間〕
〔dcselint=応答電文監視時間間隔〕
〔dccltextend=機能拡張レベル〕
〔dccache=ネームキャッシュの最大エントリ数〕
〔dchostselect=Y|N〕
〔dcscddirect=Y|N〕
〔dcscdport=スケジュールサービスのポート番号〕
〔dcscdloadpriority=Y|N〕
〔dcrapdirect=Y|N〕
〔dcrapport=rapリスナーのポート番号〕
〔dcrapautoconnect=Y|N〕
〔dcerrtrace=Y|N〕
〔dcerrtracepath=エラートレースファイル作成ディレクトリ〕
〔dcerrtracesize=エラートレースファイルサイズ〕
〔dcmethodtrace=Y|N〕
〔dcmethodtracepath=メソッドトレースファイル作成ディレクトリ〕
〔dcmethodtracesize=メソッドトレースファイルサイズ〕
〔dcuaptrace=Y|N〕
〔dcuaptracepath=UAPトレースファイル作成ディレクトリ〕
〔dcuaptracesize=UAPトレースファイルサイズ〕
〔dcdatatrace=Y|N〕
〔dcdatatracepath=データトレースファイル作成ディレクトリ〕
〔dcdatatracesize=データトレースファイルサイズ〕
〔dcdatatracemaxsize=データトレースの最大データ長〕
〔dcclttrstatisitem=統計情報項目〕
〔dcclttroptiitem=トランザクション最適化項目〕
〔dcclttrwatchtime=トランザクション同期点処理時の最大通信待ち時間〕
〔dcclttrrbinfo=no|self|remote|all〕
〔dcclttrlimittime=トランザクションブランチ最大実行可能時間〕
〔dcclttrrbrcv=Y|N〕
〔dcclttrrecoverytype=type1|type2|type3〕
〔dcclttrexptm=トランザクションブランチ限界経過時間〕
〔dcclttrcputm=トランザクションブランチCPU監視時間〕
〔dcclttrexpsp=Y|N|F〕
〔dcsndrcvtype=DCCLT_ONEWAY_SND｜DCCLT_ONEWAY_RCV｜DCCLT_SNDRCV〕
〔dcrcvport=受信用のCUPのポート番号〕
〔dcsndhost=接続するMHPが存在するノードのホスト名〕
〔dcsndport=接続するMHPのポート番号〕
〔dcsockopenatrcv=Y|N〕
〔dcweburl=サービス要求先のTP1/WebのURL〕
〔dccltdbgtrcfilecount=デバッグトレースファイルの最大ファイル数〕
〔dccltrpcmaxmsgsize=RPC送受信電文の最大長〕
〔dcscdhostchange=Y|N〕
〔dccltloadbalance=Y|N〕
〔dccltcachetim=キャッシュの有効期限〕
〔dccltconnecttimeout=コネクション確立最大監視時間〕
〔dccltprftrace=Y|N〕
〔dccltprfinfosend=Y|N〕
〔dccltnammlthost=Y|N〕
〔dccltdatacomp=Y|N〕
〔dccltconnectinf=端末識別情報〕
〔dcscdmulti=Y|N〕
〔dcscdmulticount=マルチスケジューラデーモンのプロセス数〕
〔dccltcupsndhost=送信元ホスト〕
〔dccltcuprcvport=CUPの受信で使用するポート番号〕
〔dcclttrcmplmttm=トランザクション完了限界時間〕
〔dccltsendbuffsize=TCP/IPの送信バッファサイズ〕
〔dccltrecvbuffsize=TCP/IPの受信バッファサイズ〕
〔dcinquiretimecheck=Y|N〕
〔dcnotifyreshost=Y|N〕
〔dcresponsehost=ホスト名〕

(b)　オペランド

dcnamuse=Y｜N　〜《N》

ネームサービスを使用したRPCを使用するかどうかを指定します。

Y

ネームサービスを使用したRPCを使用します。

N

ネームサービスを使用したRPCを使用しません。

dcnamuse，dcrapdirect，およびdcscddirectオペランドは排他関係にあるため，同時にYを指定できません。これらのオペランドの2つ以上にYを指定した場合，定義エラーとなります。

TP1/Web接続機能は，dcrapdirectオペランドにYを指定した場合にだけ使用できます。dcweburlオペランドを定義して，かつdcscddirect=Yおよびdcrapdirect=Yの場合は，定義エラーとなります。

dcnamport=ネームサービスのポート番号

〜〈符号なし整数〉((5001〜65535))《10000》

クライアントが属しているOpenTP1のシステム共通定義のname_portオペランドで指定したネームサービスのポート番号を指定します。dchostオペランドでポート番号を指定していないホストに対して，この定義の値が有効になります。

dchost=窓口となるTP1/Serverのホスト名　〜〈文字列〉

窓口となるTP1/Serverのホスト名と，rapリスナーのポート番号，スケジュールサービスのポート番号，またはネームサービスのポート番号を指定します。区切り文字「,」を使用して，複数のTP1/Serverを指定できます。RPCをrapリスナー経由で行う場合は，rapリスナーのホスト名，またはファイアウォールのホスト名を指定します。

dchostオペランドとdcweburlオペランドの両方を指定した場合は，dcweburlオペランドの指定が有効になります。

形式

dcrapdirect=Yの場合

ホスト名〔:rapリスナーのポート番号〕〔,ホスト名〔:rapリスナーのポート番号〕,…〕

dcscddirect=Yの場合

ホスト名〔:スケジュールサービスのポート番号〕〔,ホスト名〔:スケジュールサービスのポート番号〕,…〕

dcnamuse=Yの場合

ホスト名〔:ネームサービスのポート番号〕〔,ホスト名〔:ネームサービスのポート番号〕,…〕

ホスト名　〜〈文字列〉

TP1/Serverのホスト名を2つ以上指定した場合，窓口となるTP1/Serverの障害を検出したとき，dchostオペランドに指定されている次のTP1/Serverを参照して切り替えを試みます。ただし，RPCをrapリスナー経由で行う場合は，TP1/Client/J環境定義でdcrapautoconnect=Y，またはsetDccltextendメソッドでDCRPC_RAP_AUTOCONNECTを指定した場合だけ，dchostオペランドの次のTP1/Serverを参照して切り替えを試みます。

ポート番号　〜〈符号なし整数〉((5001〜65535))

ポート番号は，dcrapdirect=Yの場合，rapリスナーのポート番号を指定します。dcscddirect=Yの場合，スケジュールサービスのポート番号を指定します。dcnamuse=Yの場合，ネームサービスのポート番号を指定します。

ポート番号を省略すると，dcrapdirect=Yの場合，dcrapportオペランドの値を仮定します。dcscddirect=Yの場合，dcscdportオペランドの値を仮定します。dcnamuse=Yの場合，dcnamportオペランドの値を仮定します。

dcwatchtim=最大応答待ち時間

〜〈符号なし整数〉((0〜65535))《180》（単位：秒）

CUPからTP1/Serverに対しての要求を開始してから応答が返るまでの待ち時間の最大値を指定します。

指定時間を過ぎても応答が返らない場合は，CUPへエラーリターンします。0を指定した場合は，応答を受信するまで無限に待ち続けます。

dcwatchtimオペランドの指定が適用されるAPI（メソッド）を次に示します。

closeConnectionメソッド

openConnectionメソッド

rpcCallメソッド（スケジューラダイレクト機能を使用した非応答型RPCの場合を除く）

rpcCallToメソッド（同期応答型RPCの場合）

trnBeginメソッド

trnChainedCommitメソッド

trnChainedRollbackメソッド

trnUnchainedCommitメソッド

trnUnchainedRollbackメソッド

dccltinquiretime=常設コネクション問い合わせ間隔最大時間

〜〈符号なし整数〉((0〜1048575))（単位：秒）

CUPがサーバに対して問い合わせを行ってから，次の問い合わせをするまでの間隔の最大時間を指定します。常設コネクション問い合わせ間隔最大時間はrapサーバで監視するタイマです。指定時間を超えても問い合わせがない場合，rapサーバ側で強制的に常設コネクションを解放します。また，トランザクション内で常設コネクション問い合わせ間隔最大時間に達したことを検知した場合は，該当するトランザクションを強制的にロールバックします。

この定義に0を指定した場合は，CUPからの問い合わせを無限に待ちます。この指定を省略した場合は，rapリスナーサービス定義のrap_inquire_timeオペランドの指定に従います。

dcwatchtiminherit=Y｜N　〜《N》

リモートAPI機能を使用したRPCを行う場合に，CUPの最大応答待ち時間をrapサーバ側に引き継ぐかどうかを指定します。

Y

rapサーバ側にCUPの最大応答待ち時間を引き継ぎます。

N

rapサーバ側にCUPの最大応答待ち時間を引き継ぎません。

dcwatchtimrpcinherit=Y｜N　〜《N》

CUPの最大応答待ち時間をTP1/Server側に引き継ぐかどうかを指定します。CUPの最大応答待ち時間を引き継ぐと，CUPがタイムアウトしているのにTP1/Server側でサービスを実行することを防止できます。

Y

TP1/Server側にCUPの最大応答待ち時間を引き継ぎます。

N

TP1/Server側にCUPの最大応答待ち時間を引き継ぎません。

dccltdelay=最大通信遅延時間

〜〈符号なし整数〉((0〜65535))《0》（単位：秒）

CUPとrapサーバとの間の通信オーバヘッドを考慮し，rapサーバ側の応答監視をTP1/Client/J側よりも早く終わらせる場合に指定します。この定義を指定すると，rapサーバ側の監視を指定した時間分だけ早く終了させ，TP1/Client/J側の監視時間のタイムアウトによるメッセージのすれ違いを防ぎます。

この定義は，TP1/Client/J環境定義にdcrapdirect=Yおよびdcwatchtiminherit=Yを指定した場合にだけ有効です。

TP1/Client/J環境定義にdcwatchtim=0を指定した場合またはsetDcwatchtimメソッドで0を指定した場合，およびTP1/Client/J環境定義にdcwatchtiminherit=Nを指定した場合は，dccltdelayオペランドの指定は無視されます。dcwatchtimオペランドに指定した値からdccltdelayオペランドに指定した値を引いたときに，0または負の値になった場合も，dccltdelayオペランドの指定は無視され，1が仮定されます。

dcselint=応答電文監視時間間隔　〜〈符号なし整数〉((1〜65535))《100》（単位：ミリ秒）

このオペランドは，旧バージョンとの互換性のためだけに存在します。現在はこのオペランドを指定しても無視されます。

dccltextend=00000000｜00000001

TP1/Client/Jの機能拡張レベルの設定を指定します。

00000000

TP1/Client/Jの機能を拡張しません。

00000001

rpcCallメソッド呼び出し時，自CUPのIPアドレスをサービスに連絡します。呼び出したサービスでdc_rpc_get_callers_address()関数を実行し，CUPのアドレスを求める必要がある場合に指定します。

dccache=ネームキャッシュの最大エントリ数　〜〈符号なし整数〉((2〜256))《8》

TP1/Client/Jで使用するサービス情報をキャッシュするためのキャッシュの最大エントリ数を指定します。LRU方式で管理します。キャッシュのエントリ数が指定値を超える場合は，最も過去に呼び出されたサービス情報を削除します。

dchostselect=Y｜N　〜《N》

rpcOpenメソッド実行時，窓口となるTP1/Serverをランダムに選択するかどうかを指定します。この定義は，dchostオペランドに窓口となるTP1/Serverを複数指定した場合にだけ有効です。

Y

窓口となるTP1/Serverをランダムに選択します。

N

窓口となるTP1/Serverをランダムに選択しません。

窓口となるTP1/Serverへ問い合わせ中に障害を検出した場合，障害を検出したTP1/Serverを除いて，dchostオペランドに指定された次のTP1/Serverに切り替えを試みます。詳細については，「付録A.1(15)　ホスト切り替え機能」を参照してください。

dcscddirect=Y｜N　〜《N》

TP1/Serverのネームサービスにサービス情報を問い合わせないで，スケジューラダイレクト機能を使用したRPCを使用するかどうかを指定します。

Y

スケジューラダイレクト機能を使用したRPCを使用します。

N

スケジューラダイレクト機能を使用したRPCを使用しません。

TP1/Client/J環境定義のdcscdportオペランドにスケジュールサービスのポート番号を指定したときは，そのポート番号を使用して問い合わせを行います。dcrapdirect，dcscddirect，およびdcnamuseオペランドは排他関係にあるため，同時にYを指定できません。これらのオペランドの2つ以上にYを指定した場合，定義エラーとなります。

TP1/Web接続機能は，dcrapdirectオペランドにYを指定した場合にだけ使用できます。dcweburlオペランドを定義して，かつdcscddirect=Yおよびdcrapdirect=Yの場合は，定義エラーとなります。

dcscdport=スケジュールサービスのポート番号

〜〈符号なし整数〉((5001〜65535))

クライアントが属しているOpenTP1のスケジュールサービス定義のscd_portオペランドで指定したスケジュールサービスのポート番号を指定します。dchostオペランドでポート番号を指定していないホストに対して，この定義の値が有効になります。このオペランドはTP1/Client/J環境定義にdcscddirect=Yを指定したときだけ有効です。詳しくは，TP1/Client/J環境定義のdcscddirectオペランドを参照してください。

dcscdloadpriority=Y｜N　〜《N》

サービス要求を受け付けた窓口となるTP1/Serverを優先して負荷分散するかどうか指定します。

Y

サービス要求を受け付けた窓口となるTP1/Serverを優先して負荷分散します。

N

サービス要求を受け付けた窓口となるTP1/Serverを優先しません。TP1/Serverは，ノード間の負荷を分散します。

この定義は，スケジューラダイレクト機能を使用したRPCを行う場合（TP1/Client/J環境定義にdcscddirect=Yを指定）にだけ，有効です。

dcrapdirect=Y｜N　〜《Y》

TP1/Serverのネームサービスにサービス情報を問い合わせないで，直接rapリスナーに問い合わせる機能，すなわちリモートAPI機能を使用するかどうかを指定します。このオペランドの指定を有効にするには，TP1/Client/J環境定義のdcrapportオペランドにrapリスナーのポート番号を指定します。

dcrapdirect，dcscddirect，およびdcnamuseオペランドは排他関係にあるため，同時にYを指定することはできません。これらのオペランドの2つ以上にYを指定した場合，定義エラーとなります。

dcrapport=rapリスナーのポート番号　〜〈符号なし整数〉((5001〜65535))

クライアントが属しているTP1/Serverのrapリスナーのポート番号，またはファイアウォールのポート番号を指定します。dchostオペランドでポート番号を指定していないホストに対して，このオペランドの値が有効になります。

このオペランドは，TP1/Client/J環境定義にdcrapdirect=Yを指定したときだけ有効です。詳しくは，TP1/Client/J環境定義のdcrapdirectオペランドを参照してください。

dcrapautoconnect=Y｜N　〜《N》

CUPとrapサーバとの間の常設コネクションを自動的に確立させるかどうかを指定します。

Y

次回メソッド実行時に自動的に常設コネクションを確立します。常設コネクション確立要求先は，TP1/Client/J環境定義のdchostオペランドに指定したrapリスナーです。

N

常設コネクションを自動的に確立させません。

コネクション確立モードの違いによる各メソッドの動作

非オートコネクトモードの場合およびオートコネクトモードの場合のコネクション確立処理は，次の表のようになります。

表A‒4　コネクション確立モードの違いによる各メソッドの動作

dcrapautoconnectオペランドの指定値

openConnection()メソッドを発行

openConnection(host, port)メソッドを発行

openConnection(url, flags)メソッドを発行

rpcCall()メソッドを発行

N

dchostオペランドが指定されている場合，dchostオペランドに指定されたrapサーバにコネクションを確立する。

dcweburlオペランドが指定されている場合，dcweburlオペランドに指定されたURLにコネクションを確立する。

dchostオペランドおよびdcweburlオペランドが指定されていない場合，ErrHostUndefExceptionが返される。

host引数およびport引数に指定されたrapサーバにコネクションを確立する。

url引数に指定されたURLにコネクションを確立する。

ErrProtoExceptionが返される。

Y

ErrProtoExceptionが返される。

ErrProtoExceptionが返される。

ErrProtoExceptionが返される。

dchostオペランドが指定されている場合，dchostオペランドに指定されたrapサーバにコネクションを確立する。

dcweburlオペランドが指定されている場合，dcweburlオペランドに指定されたURLにコネクションを確立する。

dchostオペランドおよびdcweburlオペランドが指定されていない場合，ErrHostUndefExceptionが返される。

注

setRpcextendメソッドによってdcrapautoconnectオペランドの値を動的に変更できます。

rpcOpenメソッドで定義を読み込みます。

rpcCloseメソッドで読み込んだ定義情報を破棄します。

引数にURLを指定したopenConnectionメソッドを実行した場合，指定されたURLは，そのURLを指定したopenConnectionメソッドだけで採用します。このメソッドの実行後，closeConnectionメソッドでコネクションを切断し，次に引数指定なしのopenConnectionメソッドを実行しても，前回の引数に指定したURLは採用されません。

dcerrtrace=Y｜N　〜《N》

CUPでエラートレースを取得するかどうかを指定します。

Y

エラートレースを取得します。

N

エラートレースを取得しません。

CUPをJavaアプレットとして動作させる場合，Yを指定しないでください。Yを指定した場合の動作は保証されません。

dcerrtracepath=エラートレースファイル作成ディレクトリ　〜〈文字列〉

エラートレースファイルを作成するディレクトリのパス名を指定します。

このオペランドは，TP1/Client/J環境定義にdcerrtrace=Yを指定した場合にだけ有効です。

dcerrtracesize=エラートレースファイルサイズ　〜〈符号なし整数〉((4096〜1048576)) 《4096》（単位：バイト）

エラートレースファイルのサイズを指定します。

このオペランドは，TP1/Client/J環境定義にdcerrtrace=Yを指定した場合にだけ有効です。

dcmethodtrace=Y｜N　〜《N》

CUPでメソッドトレースを取得するかどうかを指定します。

Y

メソッドトレースを取得します。

N

メソッドトレースを取得しません。

CUPをJavaアプレットとして動作させる場合，Yを指定しないでください。Yを指定した場合の動作は保証されません。

dcmethodtracepath=メソッドトレースファイル作成ディレクトリ　〜〈文字列〉

メソッドトレースファイルを作成するディレクトリのパス名を指定します。

このオペランドは，TP1/Client/J環境定義にdcmethodtrace=Yを指定した場合にだけ有効です。

dcmethodtracesize=メソッドトレースファイルサイズ　〜〈符号なし整数〉((4096〜1048576)) 《4096》（単位：バイト）

メソッドトレースファイルのサイズを指定します。

このオペランドは，TP1/Client/J環境定義にdcmethodtrace=Yを指定した場合にだけ有効です。

dcuaptrace=Y｜N　〜《N》

CUPでUAPトレースを取得するかどうかを指定します。

Y

UAPトレースを取得します。

N

UAPトレースを取得しません。

CUPをJavaアプレットとして動作させる場合，Yを指定しないでください。Yを指定した場合の動作は保証されません。

dcuaptracepath=UAPトレースファイル作成ディレクトリ　〜〈文字列〉

UAPトレースファイルを作成するディレクトリのパス名を指定します。

このオペランドは，TP1/Client/J環境定義にdcuaptrace=Yを指定した場合にだけ有効です。

dcuaptracesize=UAPトレースファイルサイズ　〜〈符号なし整数〉((4096〜1048576))《4096》（単位：バイト）

UAPトレースファイルのサイズを指定します。

このオペランドは，TP1/Client/J環境定義にdcuaptrace=Yを指定した場合にだけ有効です。

dcdatatrace=Y｜N　〜《N》

CUPでデータトレースを取得するかどうかを指定します。

Y

データトレースを取得します。

N

データトレースを取得しません。

CUPをJavaアプレットとして動作させる場合，Yを指定しないでください。Yを指定した場合の動作は保証されません。

dcdatatracepath=データトレースファイル作成ディレクトリ　〜〈文字列〉

データトレースファイルを作成するディレクトリのパス名を指定します。

このオペランドは，TP1/Client/J環境定義にdcdatatrace=Yを指定した場合にだけ有効です。

dcdatatracesize=データトレースファイルサイズ　〜〈符号なし整数〉((4096〜1048576)) 《4096》（単位：バイト）

データトレースファイルのサイズを指定します。

このオペランドは，TP1/Client/J環境定義にdcdatatrace=Yを指定した場合にだけ有効です。

dcdatatracemaxsize=データトレースの最大データ長　〜〈符号なし整数〉((16〜1048576)) 《128》（単位：バイト）

1件のデータトレースのデータ長の最大値を指定します。

このオペランドは，TP1/Client/J環境定義にdcdatatrace=Yを指定した場合にだけ有効です。

dcclttrstatisitem=統計情報項目〔,統計情報項目〕…

トランザクションブランチの統計情報を取得する項目を，次の文字列で指定します。CUPからトランザクションを開始する場合にだけ有効です。

nothing

統計情報を取得しません。

base

基本情報として，次の情報を取得します。

トランザクションブランチの識別子

トランザクションブランチの決着結果

トランザクションブランチの実行プロセス種別

トランザクションブランチの実行サーバ名

トランザクションブランチの実行サービス名

executiontime

基本情報とトランザクションブランチの実行時間情報を取得します。

cputime

基本情報とトランザクションブランチのCPU時間情報を取得します。

nothingの指定は，1つしかできません。また，nothingとほかの統計情報項目を同時に指定した場合，nothingの指定は無効になります。

トランザクションに関する統計情報を取得する場合は，次のどちらかを指定してください。

トランザクションサービス定義にtrn_tran_statistics=Yを指定

trnsticsコマンドで-sオプションを指定

この定義を省略した場合は，rapリスナーサービス定義のtrn_statistics_itemオペランドの指定に従います。

dcclttroptiitem=トランザクション最適化項目〔,トランザクション最適化項目〕…

複数のユーザサーバで構成されるグローバルトランザクションの性能を向上させるための最適化項目を，次の文字列で指定します。CUPからトランザクションを開始する場合にだけ有効です。

base

同期点取得処理全体（プリペア処理，コミット処理，およびロールバック処理）を最適化します。OpenTP1のトランザクション制御は2相コミット方式で実行しているため，2つのトランザクションブランチ間のコミット制御には，4回のプロセス間通信が必要となります。

次の条件をすべて満たす場合，親トランザクションブランチが子トランザクションブランチのコミット処理を代わりに実行することで，コミット制御で必要な4回のプロセス間通信を削減します。

親トランザクションブランチと，子トランザクションブランチが同一OpenTP1下にあること。

親トランザクションブランチが，子トランザクションブランチを同期応答型RPCで呼び出していること。

子トランザクションブランチでアクセスしたリソースマネジャのXAインターフェース用オブジェクトが，親トランザクションブランチにもリンケージされていること。

asyncprepare

baseの指定条件を満たしていないため同期点取得処理全体の最適化ができない場合に，プリペア処理を最適化します。

次の条件をすべて満たす場合，親トランザクションブランチから発行されたRPCによって子トランザクションブランチがサービス要求を実行したときに，RPCが返される前にプリペア処理を実行することで，2回のプロセス間通信を削減します。

baseを指定した最適化ができないこと。

親トランザクションブランチが，子トランザクションブランチを同期応答型RPCで呼び出していること。

ただし，この最適化を実行した場合，親トランザクションブランチが発行した同期応答型RPCの応答時間が遅くなります。また，子トランザクションブランチは，プリペア処理からコミット処理までの間隔（親トランザクションブランチからの指示がないとトランザクションを決着できない状態）が大きくなります。そのため，親トランザクションブランチのOpenTP1がシステムダウンし，トランザクションブランチ間の連絡ができなくなると，ジャーナルファイルのスワップやチェックポイントダンプファイルの有効化が遅れ，子トランザクションブランチのOpenTP1もシステムダウンする場合があります。

トランザクション最適化項目は，重複して指定できます。ただし，優先順位は次のようになります。

1＞2

1：base

2：asyncprepare

この指定を省略した場合は，rapリスナーサービス定義のtrn_optimum_itemオペランドの指定に従います。

dcclttrwatchtime=トランザクション同期点処理時の最大通信待ち時間

〜〈符号なし整数〉((1〜65535))（単位：秒）

トランザクションの同期点処理で，トランザクションブランチ間で行う通信（プリペア，コミット，ロールバック指示，または応答など）の受信待ち時間の最大値を指定します。CUPからトランザクションを開始する場合にだけ有効です。

指定時間を過ぎても指示または応答がない場合は，該当するトランザクションブランチが2相コミットの1相目であればロールバックさせ，1相目完了後であればトランザクションサービスのシステムプロセスでトランザクション決着処理を再試行します。

この定義を省略した場合は，rapリスナーサービス定義のtrn_watch_timeオペランドの指定に従います。

dcclttrrbinfo=no｜self｜remote｜all

トランザクションブランチがロールバックした場合に，ロールバック要因に関する情報をログに取得するかどうかを指定します。CUPからトランザクションを開始する場合にだけ有効です。

no

ロールバック情報を取得しません。

self

ロールバック要因が発生したトランザクションブランチでだけ，ログにロールバック情報を取得します。

remote

selfに加え，他ノードのトランザクションブランチからロールバック要求されたトランザクションブランチでも，ログにロールバック情報を取得します。

all

remoteに加え，自ノードのトランザクションブランチからロールバック要求されたトランザクションブランチでも，ログにロールバック情報を取得します。

この指定を省略した場合は，rapリスナーサービス定義のtrn_rollback_information_putオペランドの指定に従います。

dcclttrlimittime=トランザクションブランチ最大実行可能時間

〜〈符号なし整数〉((0〜65535))（単位：秒）

トランザクションブランチの最大実行可能時間を指定します。CUPからトランザクションを開始する場合だけ有効です。

トランザクションブランチを開始してから同期点処理が終了するまでの時間がこのオペランドの指定時間を超えないように，rpcCallメソッドおよび同期点処理内で行う通信のタイムアウト時間を，次のように自動設定します。

rpcCallメソッドのタイムアウト時間

「K≧このオペランドの指定時間」の場合：要求処理を実行しないで，タイムアウトでエラーリターンします。

「K＜このオペランドの指定時間」および「（このオペランドの指定時間−K）≧W」の場合：Wをタイムアウト時間とします。

「K＜このオペランドの指定時間」および「（このオペランドの指定時間−K）＜W」の場合：（このオペランドの指定時間−K）をタイムアウト時間とします。

「K」「W」の内容は次のとおりです。

K：現時刻−トランザクションブランチ開始時刻

W：dcwatchtimオペランド指定時間

同期点処理内で行う通信のタイムアウト時間

「K≧このオペランドの指定時間」の場合：タイムアウト時間を1秒とします。

「K＜このオペランドの指定時間」および「（このオペランドの指定時間−K）≧W」の場合：Wをタイムアウト時間とします。

「K＜このオペランドの指定時間」および「（このオペランドの指定時間−K）＜W」の場合：（このオペランドの指定時間−K）をタイムアウト時間とします。

「K」「W」の内容は次のとおりです。

K：現時刻−トランザクションブランチ開始時刻

W：dcclttrwatchtimeオペランド指定時間（dcclttrwatchtimeオペランドを省略した場合はdcwatchtimオペランド指定時間）

上記の受信待ち以外の処理で時間が掛かった場合は，このオペランドの指定時間内にトランザクションブランチが終了しないことがあります。

同期点処理開始前にこのオペランドの指定時間が経過した場合，そのトランザクションはロールバックされます。

0を指定した場合は，時間監視を行いません。

この定義を省略した場合は，rapリスナーサービス定義のtrn_limit_timeオペランドの指定に従います。

dcclttrrbrcv=Y｜N

RPC先トランザクションブランチにロールバック指示を送信したあと，ロールバック完了通知を受信するかどうかを指定します。CUPからトランザクションを開始する場合にだけ有効です。

Y

ロールバック完了通知を受信します。

N

ロールバック完了通知を受信しません。

Nを指定した場合，RPC先トランザクションブランチからのロールバック完了通知を受信しないで（RPC先トランザクションブランチのロールバック処理の完了を待たないで）自トランザクションブランチを終了します。

この定義を省略した場合は，rapリスナーサービス定義のtrn_rollback_response_receiveオペランドの指定に従います。

dcclttrrecoverytype=type1｜type2｜type3

UAP障害時のトランザクション同期点処理方式を指定します。CUPからトランザクションを開始する場合にだけ有効です。

RPCがタイムアウトし，RPC発行先プロセスのアドレスが未解決の場合およびトランザクション実行中のUAPがダウンした場合に，トランザクションブランチ間の連絡がスムーズにできないため，トランザクションの決着に時間が掛かることがあります。

このオペランドでは，次に示す障害が発生した場合のトランザクション同期点処理方式を，指定値に示す3つの方式から選択して指定します。

（障害1）RPCがタイムアウトした場合

この場合，RPC発行元トランザクションブランチは，サービス要求がどのプロセスで実行されているかがわからないため，RPC発行先トランザクションブランチにトランザクション同期点メッセージを送信できません。そのため，RPC発行元トランザクションブランチおよびRPC発行先トランザクションブランチはトランザクション同期点メッセージ待ちとなり，トランザクションの決着に時間が掛かります。

（障害2）rapサーバがRPCの応答受信前にダウンした場合

この場合，RPC発行元トランザクションブランチは，サービス要求がどのプロセスで実行されているかがわからないため，RPC発行先トランザクションブランチにトランザクション同期点メッセージを送信できません。そのため，RPC発行先トランザクションブランチはトランザクション同期点メッセージ待ちとなり，トランザクションの決着に時間が掛かります。

（障害3）RPC発行先UAPからの応答受信後にrapサーバとRPC発行先UAPがほぼ同時にダウンした場合

この場合，それぞれのトランザクションブランチを引き継いだトランザクション回復プロセスは，相手プロセスのダウンを知らないため，すでに存在しないプロセスにトランザクション同期点メッセージを送信してしまい，トランザクションの決着に時間が掛かることがあります。

それぞれの指定値が示す処理方式について説明します。

type1

（障害1）が発生した場合，RPC発行元トランザクションブランチおよびRPC発行先トランザクションブランチは，トランザクション同期点メッセージ受信処理がタイムアウトすることによって，トランザクションを決着します。

（障害2）が発生した場合，RPC発行元トランザクションブランチは，RPC発行先トランザクションブランチにトランザクション同期点メッセージを送信しないでトランザクションを決着します。RPC発行先トランザクションブランチは，トランザクション同期点メッセージ受信処理がタイムアウトすることによって，トランザクションを決着します。

（障害3）が発生した場合，RPC発行元トランザクションブランチおよびRPC発行先トランザクションブランチは，トランザクション同期点メッセージ受信処理がタイムアウトすることによって，トランザクションを決着します。

type2

（障害1）が発生してトランザクションをコミットする場合はtype1と同じです。

（障害1）が発生してトランザクションをロールバックする場合，または（障害2）が発生した場合は，RPC発行元トランザクションブランチは，RPC発行先トランザクションブランチが存在するノードのトランザクションサービスプロセスにトランザクション同期点メッセージを送信後，トランザクションを決着します。トランザクション同期点メッセージを受信したトランザクションサービスプロセスは，該当するトランザクションブランチを処理中のプロセスに，トランザクション同期点指示を送信します。

（障害3）が発生した場合，RPC発行元トランザクションブランチおよびRPC発行先トランザクションブランチは，トランザクション同期点メッセージ受信処理がタイムアウトすることによって，トランザクションを決着します。

type3

（障害1）が発生してトランザクションをコミットする場合は，type1と同じです。

（障害1）が発生してトランザクションをロールバックする場合，（障害2）が発生した場合，または（障害3）が発生した場合，相手トランザクションブランチが存在するノードのトランザクションサービスプロセスに，トランザクション同期点メッセージを送信します。トランザクション同期点メッセージを受信したトランザクションサービスプロセスは，該当するトランザクションブランチを処理中のプロセスに，トランザクション同期点指示を送信します。

次に示す場合，このオペランドにtype2またはtype3を指定しても，トランザクションの決着に時間が掛かることがあります。

RPC実行中に，RPC発行先UAPの状態が変更となり（負荷増加，UAP終了，UAP閉塞など），ほかのノードの同一UAPにサービス要求が再転送された場合

相手先のOpenTP1がこのオプションをサポートしていないバージョンの場合

相手先トランザクションブランチがトランザクション同期点メッセージ受信処理以外で時間が掛かっている場合

この定義を省略した場合は，rapリスナーサービス定義のtrn_partial_recovery_typeオペランドの指定に従います。

dcclttrexptm=トランザクションブランチ限界経過時間

〜〈符号なし整数〉((0〜65535))（単位：秒）

トランザクションブランチの処理時間の最大値を指定します。CUPからトランザクションを開始する場合にだけ有効です。

指定時間を超えてもトランザクションブランチが完了しないとき，そのトランザクションブランチのプロセスを異常終了させて，ロールバックします。0を指定した場合は，時間監視をしません。

この指定を省略した場合，rapリスナーサービス定義のtrn_expiration_timeオペランドの指定に従います。

なお，RPC機能を使用した場合に，他プロセスで実行するトランザクションブランチの処理時間も監視時間に含むかどうかは，TP1/Client/J環境定義のdcclttrexpspオペランドで指定してください。

dcclttrcputm=トランザクションブランチCPU監視時間

〜〈符号なし整数〉((0〜65535))（単位：秒）

トランザクションブランチが同期点処理までに使用できるCPU時間を指定します。CUPからトランザクションを開始する場合にだけ有効です。

0を指定した場合，CPU時間を監視しません。

指定時間を超えた場合は，そのトランザクションブランチのプロセスを異常終了させ，ロールバックします。

この指定を省略した場合は，rapリスナーサービス定義のtrn_cpu_timeオペランドの指定に従います。

dcclttrexpsp=Y｜N｜F

トランザクションブランチの処理を監視するとき，次の処理時間も監視時間に含むかどうかを指定します。

監視対象のトランザクションブランチが，RPC機能を使ってほかのトランザクションブランチを呼び出し，その処理が終わるのを待つ時間

連鎖型RPCで呼び出されたサーバUAPが次のサービス要求を待つ時間

監視対象のトランザクションブランチが，非応答型RPCを使用してほかのトランザクションブランチを呼び出したあと，処理結果受信処理を行っている時間

それぞれの指定値について説明します。

Y

1，2，3すべてを監視時間に含みます。

N

3だけを監視時間に含みます。

F

1，2，3のどれも監視時間に含みません。

この指定を省略した場合は，rapリスナーサービス定義のtrn_expiration_time_suspendオペランドの指定に従います。

dcsndrcvtype=DCCLT_ONEWAY_SND｜DCCLT_ONEWAY_RCV｜DCCLT_SNDRCV

TCP/IP通信機能の使用時に初期化する環境を指定します。

このオペランドを指定してない場合は，TCP/IP通信機能を使用できません。

DCCLT_ONEWAY_SND

メッセージを一方送信するための環境

DCCLT_ONEWAY_RCV

メッセージを一方受信するための環境

DCCLT_SNDRCV

メッセージを送受信するための環境

dcrcvport=受信用のCUPのポート番号

〜〈符号なし整数〉((1〜65535))《11000》

MHPから送信されたメッセージを受信するCUPのポート番号を指定します。MHPがメッセージを送信するために使用するポート番号と同じ値を指定してください。同一マシン内で，複数のプロセスまたはスレッドを同時に実行する場合は，それぞれ異なるポート番号を指定してください。

指定できるポート番号でも，OSまたはほかのプログラムで使用するポート番号は指定しないでください。指定した場合，応答データを正しく受信できないことがあります。なお，OSが使用するポート番号は，OSごとに異なります。OSのマニュアルなどを参照してください。

dcsndhost=接続するMHPが存在するノードのホスト名　〜〈文字列〉

CUPからメッセージを送信する場合，コネクションを確立して接続するMHPが存在するノードのホスト名を指定します。

また，ホスト名として，10進ドット記法のIPアドレスを指定することもできます。

dcsndport=接続するMHPのポート番号

〜〈符号なし整数〉((1〜65535))《12000》

CUPからメッセージを送信する場合，コネクションを確立して接続するMHPのポート番号を指定します。dcnamportオペランドに指定するポート番号と重複しないように指定してください。

dcsockopenatrcv=Y｜N　〜《N》

TCP/IP通信機能の使用時に，1コネクションで送受信する場合の，受信用ソケットを開設する契機（送信相手からの接続を待ち受け始める契機）を指定します。

なお，このオペランドの指定を省略した場合は，rpcOpenメソッド実行時に受信用ソケットを開設します。

Y

cltReceiveメソッド実行時に，コネクションが確立されていない場合は受信用ソケットを開設します。

N

rpcOpenメソッド実行時に，受信用ソケットを開設します。

dcweburl=サービス要求先のTP1/WebのURL　〜〈パス名〉

サービス要求先のTP1/WebのURLを指定します。

プロトコル，WWWサーバ，プロンプターのCGI名称，TP1/Webのサービス名などの情報をURL形式で指定します。

dchostオペランドとdcweburlオペランドの両方を指定した場合は，dcweburlオペランドの指定が有効になります。

また，TP1/Web接続機能を使用する場合は，dcscddirectオペランドおよびdcnamuseオペランドを使用できません。dcweburlオペランドを定義して，かつdcscddirect=Yおよびdcnamuse=Yの場合は，定義エラーとなります。

dccltdbgtrcfilecount=デバッグトレースファイルの最大ファイル数

〜〈符号なし整数〉((0〜256))《0》

デバッグトレースファイルの最大ファイル数を指定します。0を指定した場合，ファイル数の制限はなくなります。デバッグトレースファイルの総数が，このオペランドの指定値を超えた場合，更新日時の最も古いファイルが削除されます。

dccltdbgtrcfilecountオペランドで異なる値を指定した複数のTP1Clientインスタンスを同時に使用した場合，実際の最大ファイル数は保証できません。

rpcOpenメソッド未発行の状態でTP1Clientインスタンスを作成した場合，dccltdbgtrcfilecountオペランドは，システムプロパティとしても定義できます。この場合，TP1Clientインスタンスの作成後にrpcOpenメソッドを発行すると，rpcOpenメソッドの内容を解析した結果を上書きして動作します。rpcOpenメソッドを発行するとシステムプロパティに定義されたdccltdbgtrcfilecountオペランドの指定は無効になります。

dccltdbgtrcfilecountオペランドの指定が不正な場合，エラーは通知されません。この場合，dccltdbgtrcfilecountオペランドの指定はデフォルト値が有効になります。

dccltrpcmaxmsgsize=RPC送受信電文の最大長

〜〈符号なし整数〉((1〜8))《1》（単位：メガバイト）

RPCで受け渡しできる電文の最大長を指定します。

rpcCallメソッドで送受信できるRPC電文の最大長は，このオペランドを省略した場合，またはデフォルト値（1）を指定した場合は，1メガバイト（1048576バイト）です。このオペランドに指定できる最大値（8）を指定した場合は，8メガバイト（8388608バイト）です。このオペランドの指定よりも大きいサイズの送信メッセージ長および受信メッセージ長を，rpcCallメソッドの引数に指定することはできません。送信メッセージ長または受信メッセージ長がこのオペランドの指定値よりも大きい場合，rpcCallメソッドはErrInvalidArgsExceptionを返します。

dccltrpcmaxmsgsizeオペランドを指定した場合，次の機能は使用しないでください。通信先のTP1/Serverノードでエラーが発生します。

スケジューラダイレクト機能を使用したRPC

通信先を指定したRPC

TP1/Web接続機能

システム共通定義のrpc_max_message_sizeオペランドをサポートしているTP1/Server（バージョン06-02以降）以外のTP1/Serverにサービス要求した場合の動作については次の表を参照してください。

表A‒5　dccltrpcmaxmsgsizeオペランドに2以上を指定した場合のrpcCallメソッドの動作

メソッド

RPCの種類を指定する定義

窓口となるTP1/Serverのバージョン

ノードのバージョン※1

06-02より前の場合

06-02以降の場合※2

rpcCall

dcrapdirect=Y

06-02より前

×※3

×※3

06-02以降

×※4

○

dcnamuse=Y

06-02より前

×※4

○

06-02以降

×※4

○

（凡例）

○：要求できます。

×：要求できません。

注※1

窓口となるTP1/Serverに指定されているall_nodeオペランドで定義された，SPPを起動しているノードのバージョンです。

注※2

システム共通定義にrpc_max_message_sizeオペランドを指定している場合です。

注※3

入力データ長が1メガバイト以上の場合は，ErrMessageTooBigExceptionが発生し，入力データ長が1メガバイト以下で出力領域長が1メガバイト以上の場合はErrInvalidArgsExceptionが発生します。

注※4

ErrNoSuchServiceGroupExceptionが発生します。

dcscdhostchange=Y｜N　〜《N》

TP1/Client/J環境定義のdchostオペランドに指定したサービス要求先スケジューラをRPCごとに分散させるかどうかを指定します。

Y

サービス要求先スケジューラをRPCごとに分散させます。

N

サービス要求先スケジューラをRPCごとに分散させません。

Yを指定した場合の処理を説明します。

RPCでのサービス要求が1度目の場合，TP1/Client/J環境定義にdchostselect=Yを指定したときは，TP1/Client/J環境定義のdchostオペランドに指定したサービス要求先スケジューラがランダムに選択されます。TP1/Client/J環境定義にdchostselect=Nを指定したときは，TP1/Client/J環境定義のdchostオペランドの先頭に指定したサービス要求先スケジューラが選択されます。

RPCでのサービス要求が2度目以降の場合，前回のサービス要求先スケジューラからdchostオペランドで指定した順にラウンドロビン方式でサービス要求先スケジューラが選択されます。

dccltloadbalance=Y｜N　〜《N》

ネームサーバから得た複数のサービス要求先スケジューラの情報から，負荷レベルが最も低いサービス要求先スケジューラの情報をキャッシュに格納するかどうかを指定します。

Y

負荷レベルが最も低いサービス要求先スケジューラの情報をキャッシュに格納します。

N

負荷レベルが最も低いサービス要求先スケジューラの情報をキャッシュに格納しません。

Yを指定した場合の処理を説明します。

キャッシュに格納されたサービス要求先スケジューラが複数ある場合，最初のサービス要求先スケジューラは，ランダムに選択されます。RPCでのサービス要求が2度目以降の場合，キャッシュに格納されたサービス要求先スケジューラが，ラウンドロビン方式で選択されます。

負荷レベルの詳細については，マニュアル「OpenTP1 解説」を参照してください。

dccltcachetim=キャッシュの有効期限

〜〈符号なし整数〉((0〜65535))《30》（単位：秒）

サービス要求先スケジューラの情報をキャッシュに格納した時点からの，キャッシュの有効期限を指定します。キャッシュの有効期限を満了したサービス要求先スケジューラの情報は，キャッシュから削除されます。その後，サービス要求先スケジューラの情報を再度取得して，その情報をキャッシュに格納することで，キャッシュを更新します。

このオペランドは，TP1/Client/J環境定義にdccltloadbalance=Yを指定したときだけ有効です。

dccltconnecttimeout=コネクション確立最大監視時間

〜〈符号なし整数〉((0〜65535))《0》（単位：秒）

データ送信時のコネクション確立処理に対する最大監視時間を指定します。

このオペランドで指定する値は，java.net.Socket.connectメソッド（以降「connectメソッド」と呼びます）の処理時間ではなく，connectメソッドで実行されるコネクションの確立処理に掛かる最大監視時間です。

相手システムが起動していないなどの要因でコネクションを確立できない場合，このオペランドで指定した監視時間が経過する前にCUPから発行したメソッドがエラーリターンすることがあります。これは，このオペランドで指定した最大監視時間よりも，OSによるコネクション確立処理の監視時間が優先されるためです。OSによるコネクション確立処理の監視時間，コネクション確立要求の再送回数および再送処理の間隔は，プラットフォームによって異なります。また，使用するメソッドや機能によっては，connectメソッドの処理時間がこのオペランドで指定した値よりも大きくなる場合があります。

0を指定した場合，またはこのオペランドの指定を省略した場合は，OSがコネクションの確立処理を監視します。

dccltprftrace=Y｜N　〜《Y》

TP1/Client/Jをサービスプラットフォーム上で動作させた場合に，サービスプラットフォームの性能解析トレースを取得するかどうかを指定します。

Y

性能解析トレースを取得します。ただし，PRFデーモンが起動していない場合は性能解析トレースを取得しません。

N

性能解析トレースを取得しません。

dccltprfinfosend=Y｜N　〜《Y》

TP1/Serverに対して，ネームサービスを使用したRPC，およびスケジューラダイレクト機能を使用したRPCを行う場合に，OpenTP1の性能検証用トレースに出力する情報としてTP1/Client/J内部で識別情報（IPアドレスなど）を付加するかどうかを指定します。

Y

TP1/Client/J内部で識別情報を付加します。

N

TP1/Client/J内部で識別情報を付加しません。

dccltnammlthost=Y｜N　〜《N》

マルチホームドホスト形態のTP1/Serverに対してネームサービスを使用したRPCを行うかどうかを指定します。

Y

マルチホームドホスト形態のTP1/Serverに対してネームサービスを使用したRPCを行います。RPCの要求先を複数定義している場合，またはマルチホームドホスト形態のTP1/Serverが1つ以上ある場合に指定してください。

N

マルチホームドホスト形態のTP1/Serverに対してネームサービスを使用したRPCを行いません。マルチホームドホスト形態のTP1/Serverに対してネームサービスを使用したRPCを行うと，エラーが発生する場合があります。

詳細については，「●マルチホームドホスト形態のTP1/Serverに対してRPCを行う場合の定義」を参照してください。

dccltdatacomp=Y｜N　〜《N》

データ圧縮機能を使用するかどうかを指定します。

Y

データ圧縮機能を使用します。

N

データ圧縮機能を使用しません。

dccltconnectinf=端末識別情報

端末識別情報として，DCCM3論理端末の論理端末名称をEBCDIKコードで指定します。端末識別情報は，先頭に0xを付け，0xの後ろに128文字までの16進数表記で指定します。先頭の0xは128文字に含まれません。2文字で1バイトの値として，64バイト（128文字）まで指定できます。ただし，DCCM3側では先頭8バイト目までに指定した値だけが有効になり，9バイト目以降に指定した値は無視されます。

このオペランドに指定した値は，setConnectInformationメソッドを呼び出すことで，動的に変更できます。このオペランドに指定した値は，setConnectInformationメソッドを呼び出したあと，再びrpcOpenメソッドを呼び出すまで無視されます。

このオペランドに指定した値は，TP1/Client/J環境定義のdchostオペランドにDCCM3論理端末のホスト名を，dchostオペランドまたはdcrapportオペランドにDCCM3論理端末のポート番号を指定し，次のどちらかの方法でDCCM3論理端末との常設コネクションを確立した場合に有効となります。

openConnectionメソッドを呼び出します。引数ありのopenConnectionメソッドの場合，引数hostにDCCM3論理端末のホスト名，引数portにDCCM3論理端末のポート番号を指定します。

TP1/Client/J環境定義のdcrapautoconnectオペランドにYを指定し，rpcCallメソッドを呼び出します。

このオペランドの指定を省略した場合，DCCM3論理端末に端末識別情報は通知されません。ただし，setConnectInformationメソッドを呼び出した場合は，setConnectInformationメソッドに指定した端末識別情報が，DCCM3論理端末との常設コネクション確立時にDCCM3論理端末に通知されます。

dcscdmulti=Y｜N　〜《N》

マルチスケジューラ機能を使用するかどうかを指定します。

Y

マルチスケジューラ機能を使用します。

N

マルチスケジューラ機能を使用しません。

マルチスケジューラ機能を使用すると，複数起動されたマルチスケジューラデーモンの中から，1つをランダムに選択することで，スケジューリングの負荷を軽減できます。

この定義にYを指定した場合，TP1/Client/J環境定義dchost，dcscdport，dcscdmulticountも併せて参照してください。また，この定義は，rpcCallToメソッド実行時は無効です。

dcscdmulticount=マルチスケジューラデーモンのプロセス数　〜〈符号なし整数〉((1〜4096))《1》

マルチスケジューラデーモンのプロセス数を指定します。スケジュールサービス定義scdmultiの-mオプションに指定したプロセス数か，またはそれ以下の値を指定します。

この定義は，TP1/Client/J環境定義にdcscdmulti=Yおよびdcscddirect=Yを指定した場合に有効です。なお，この場合，ポート番号は，次に示す範囲の値からランダムに選択されます。

下限値：dchostまたはdcscdportに指定したポート番号の値

上限値：下限値 + dcscdmulticountに指定したプロセス数 - 1

このポート番号の最大値が65535を超える場合は，定義解析でErrFatalException，およびsetDchostでErrInvalidPortExceptionが発生します。

scdmultiの-mオプションに指定したプロセス数よりも大きい値を指定した場合，マルチスケジューラが起動していないポートに接続を試み，ErrNetDownAtClientExceptionが発生する場合があります。

dccltcupsndhost=送信元ホスト　〜〈文字列〉

次に示すコネクション確立要求時の，送信元ホストを指定します。

スケジューラダイレクト機能を使用したRPC

ネームサービスを使用したRPC

リモートAPI機能を使用したRPC

通信先を指定したRPC

TCP/IP通信機能

ホスト名として，10進ドット記法のIPアドレスを指定することもできます。

なお，次の場合は，発行したメソッドで例外が発生します。

ホスト名としてlocalhostを指定した場合

127で始まるIPアドレスを指定した場合

CUPを実行するマシン上に存在しないホストを指定した場合

この定義を省略すると，送信元ホストは任意に割り当てられます。

dccltcuprcvport=CUPの受信で使用するポート番号　〜〈符号なし整数〉((5001〜65535))

サーバからのメッセージを受信するCUPのポート番号を指定します。

この定義で指定したポート番号は，次の機能を使用する場合に有効となります。

スケジューラダイレクト機能を使用したRPCの受信時（受信ポート）

ネームサービスを使用したRPCの受信時（受信ポート）

この定義を省略すると，システムが任意に割り当てたポート番号を使用します。

同一マシン内で，複数のプロセス，または複数のスレッドを同時に実行する場合は，それぞれ異なるポート番号を指定してください。

指定できるポート番号でも，OSまたはほかのプログラムで使用するポート番号は指定しないでください。指定した場合，応答データを正しく受信できないことがあります。なお，OSが使用するポート番号は，OSごとに異なります。OSのマニュアルなどを参照してください。

dcclttrcmplmttm=トランザクション完了限界時間　〜〈符号なし整数〉((0〜65535))（単位：秒）

rapサーバで代理実行するトランザクションブランチの，開始から終了までの最大実行時間を指定します。この指定時間を超えた場合，rapサーバのプロセスが異常終了したあとに，トランザクションブランチが回復プロセスでコミット，またはロールバックのどちらかに決着して終了します。

0を指定した場合は，トランザクションブランチの最大実行時間を監視しません。

この指定を省略した場合は，rapリスナーサービス定義のtrn_completion_limit_timeオペランドの指定に従います。

この機能をバージョン07-01以前のTP1/Serverに対して使用した場合，機能が無効の状態で動作します。

dccltsendbuffsize=TCP/IPの送信バッファサイズ　〜〈符号なし整数〉((8192〜2147483647))（単位：バイト）

コネクションごとに確保されるTCP/IP送信バッファのサイズを指定します。

高速な通信媒体やMTUの大きな通信媒体を使用している場合，この値を大きくすることによって性能向上を図れます。

このオペランドを省略した場合は，JavaVMの送信バッファサイズを適用します。

このオペランドの値は，JavaVMで使用できるTCP/IP送信バッファの上限値以下を指定してください。TCP/IP送信バッファのデフォルト値，変更方法，変更できるサイズの範囲は，OSによって異なります。詳しくは，各OSのマニュアルを参照してください。また，CUPと通信するすべてのノードで同じ値を指定してください。同じ値を指定しない場合，通信するノードとバッファサイズに差異が生じ，通信性能が劣化するおそれがあります。

dccltrecvbuffsize=TCP/IPの受信バッファサイズ　〜〈符号なし整数〉((8192〜2147483647))（単位：バイト）

コネクションごとに確保されるTCP/IP受信バッファのサイズを指定します。

高速な通信媒体やMTUの大きな通信媒体を使用している場合，この値を大きくすることによって性能向上を図れます。

このオペランドを省略した場合は，JavaVMの受信バッファサイズを適用します。

このオペランドの値は，JavaVMで使用できるTCP/IP受信バッファの上限値以下を指定してください。TCP/IP受信バッファのデフォルト値，変更方法，変更できるサイズの範囲は，OSによって異なります。詳しくは，各OSのマニュアルを参照してください。また，CUPと通信するすべてのノードで同じ値を指定してください。同じ値を指定しない場合，通信するノードとバッファサイズに差異が生じ，通信性能が劣化するおそれがあります。

dcinquiretimecheck=Y｜N　〜《Y》

常設コネクションを使用し，かつオートコネクトモード※1の場合に，CUP実行プロセスで「問い合わせ間隔最大時間」をチェックするかどうかを指定します。

rapサーバが常設コネクションを解放するタイミングと，CUP実行プロセスがRPCを実行するタイミングが重なった場合，RPCの実行に失敗してErrNetDownAtClientException例外を返すことがあります。この現象を回避するためには，このオペランドを指定します。

このオペランドを省略，またはこのオペランドにYを指定した場合，「問い合わせ間隔最大時間」には0以外を指定※2してください。

このオペランドは省略できます。

Y

CUP実行プロセスで，「問い合わせ間隔最大時間」をチェックします。

N

CUP実行プロセスで，「問い合わせ間隔最大時間」をチェックしません。

省略した場合は，CUP実行プロセスでも「問い合わせ間隔最大時間」をチェックします。

CUP実行プロセスは，トランザクション処理の処理区間外※3，かつ連鎖型RPCの処理区間外※4でrpcCallメソッドを使用してRPCを実行するタイミングで問い合わせ間隔をチェックします。

問い合わせ間隔のチェックは次の計算式で求めた時間を使用します。この時間を超過した場合は，常設コネクションを解放して再接続しRPCを実行します。

チェック時間 = 問い合わせ間隔最大時間 - T

T：問い合わせ間隔最大時間の2%の値

ただし，250ミリ秒 ≦ T ≦ 3秒となります。

注※1

次のどちらかの場合が，オートコネクトモードに該当します。

TP1/Client/J環境定義のdcrapautoconnectオペランドにYを指定している。

CUP内で，SetRpcextendメソッドのextendoptionパラメタにDCRPC_RAP_AUTOCONNECTを指定して実行している。

注※2

TP1/Client/J環境定義のdccltinquiretimeオペランドに0以外を指定してください。またはCUP内で，setDccltinquiretimeメソッドのsecパラメタに0以外を指定して実行してください。

注※3

次の両方の条件が重なった場合がトランザクション処理の処理区間外となります。

XAリソースサービス機能を使用していない（CUPがTP1 Connector上で動作していない，またはCUPがTP1 Connector上で動作しているがConnector属性ファイルのtransaction-supportタグにXATransactionを指定していない）。

trnBeginメソッド実行からtrnUnchainedCommitメソッドまたはtrnUnchainedRollbackメソッドを実行するまでの処理区間外である。

注※4

連鎖型RPCでも，初回のrpcCallメソッドでは問い合わせ間隔をチェックします。

dcnotifyreshost=Y｜N　〜《N》

OpenTP1システム内にKubernetesノードで起動するTP1/Serverが存在する場合，TP1/Client/JでこのオペランドにYを指定してください。

このオペランドにYを指定することで，サービス要求先のTP1/Serverに，dcresponsehostで指定した応答電文受信用IPアドレスを通知します。

これによって，Kubernetesノードを含むOpenTP1システム内で通信が可能となります。

Y

サービス要求先のTP1/Serverに応答電文受信用IPアドレスを通知します。次のRPC通信に対して有効になります。

スケジューラダイレクト機能を使用したRPC（rpcCallメソッド）

通信先を指定したRPC（rpcCallToメソッド）

ネームサービスを使用したRPC（rpcCallメソッド）

N

サービス要求先のTP1/Serverに，応答電文受信用IPアドレスを通知しません。

注意事項

この定義でYを指定した場合，dcresponsehostの指定が必要です。

dcresponsehost=ホスト名　〜〈文字列〉

OpenTP1システム内にKubernetesノードで起動するTP1/Serverが存在する場合，このオペランドの指定が必要です。TP1/Client/Jが応答電文を受信するために使用する，ホスト名またはIPアドレスを指定します。

このオペランドを指定することで，サービス要求先のTP1/Serverに応答電文受信用IPアドレスが通知され，Kubernetesノードを含むOpenTP1システム内で通信が可能となります。

ホスト名に使用できる文字は先頭が英数字または-（ハイフン）で，先頭以外が英数字，-（ハイフン），または.（ピリオド）です。

ホスト名は，/etc/hostsファイルまたはDNSなどで，IPアドレスとのマッピングができなければなりません。なお，localhostまたは名前解決した結果が127で始まるIPアドレス（例：127.0.0.1）になるホスト名は指定しないでください。

ホスト名は，1個だけ指定できます。

ホスト名またはIPアドレスは，TP1/Client/Jの環境によって次を指定してください。

TP1/Client/JがKubernetesクラスタ外の場合

TP1/Client/Jが起動するマシンのホスト名またはIPアドレス

TP1/Client/JがKubernetesクラスタ内の場合

Kubernetesクラスタ内のどれかのKubernetesノードのホスト名またはIPアドレス

注意事項

ホスト名に256文字以上指定した場合，指定した文字列の先頭から255文字までをノード名として扱います。

この指定は，dcnotifyreshostオペランドにYを指定した場合に有効です。

dcnotifyreshostオペランドにYを指定した場合，このオペランドは省略できません。

指定したホスト名の名前解決はrpcOpenメソッド発行時に実施します。そのためホスト名にマッピングしているIPアドレスの変更は，CUP実行プロセスを正常停止したあとに実施してください。

ホスト名またはIPアドレスの変更手順

ホスト名またはIPアドレスを変更する場合，CUP実行プロセスを正常停止したあとに実施してください。CUPがJavaサーブレットで動作している場合はWebサーバを停止したあとに実施してください。

(c)　TP1/Client/J環境定義を指定するときの注意事項

TP1/Client/J環境定義のオペランドを記述した行に，設定値以外の文字を記述しないでください。設定値以外の文字を記述した場合，rpcOpenメソッドがErrFatalExceptionを返す場合があります。

TP1/Client/Jは，TP1/Client/J環境定義のオペランドで始まる行（行頭の空白およびタブは無視されます）を定義解析対象とします。TP1/Client/J環境定義のオペランド以外の文字列が指定された行は，すべてコメント行と見なされます。

付録A.3　TP1/Client/Jの障害対策

TP1/Client/Jのトラブルシュート機能で取得できるトレースの種類を次の表に示します。

トレースの種類

出力先

UAPトレース

ファイルに出力されます。

データトレース

ファイルに出力されます。

エラートレース

ファイルに出力されます。

メモリトレース

CUPで用意したString型の配列に格納されます。

メソッドトレース

ファイルに出力されます。

デバッグトレース

TP1/Client/Jのメモリ内に取得されます。

なお，TP1/Client/Jの提供するメソッドが例外を返した場合は，ファイルまたは標準出力に出力されます。

性能解析トレース

サービスプラットフォーム上に出力されます。

性能検証用トレース

TP1/Server上に出力されます。

トレースを出力する場合，環境変数TZにタイムゾーンを設定してください。設定していないと，トレース情報の時刻が正しく出力されません。

(1)　トレースファイルの出力内容

ファイルに出力されるトレースは，出力先ディレクトリなどを変更できます。トレースファイルに指定できるオプションと出力ファイル名を次の表に示します。また，ファイル出力ディレクトリを変更するためのTP1/Client/J環境定義のオペランド名も次の表に示します。

表A‒6　トレースファイルのオプションとファイル名

トレースファイル

オプション

ファイル出力先指定方法※1

出力ファイル名※2

UAPトレース

ファイル出力ディレクトリ

トレースファイルのサイズ

dcuaptracepathオペランド

DCUAP1.TRC

DCUAP2.TRC

データトレース

ファイル出力ディレクトリ

トレースファイルのサイズ

データの最大サイズ

dcdatatracepathオペランド

DCDAT1.TRC

DCDAT2.TRC

エラートレース

ファイル出力ディレクトリ

トレースファイルのサイズ

dcerrtracepathオペランド

DCERR1.TRC

DCERR2.TRC

メソッドトレース

ファイル出力ディレクトリ

トレースファイルのサイズ

dcmethodtracepathオペランド

DCMTD1.TRC

DCMTD2.TRC

注※1

指定したディレクトリがない場合，および指定したディレクトリに書き込み権限がない場合は，トレースファイルを出力できません。

注※2

指定したファイル出力先ディレクトリに出力ファイル名のファイルがない場合は，該当するディレクトリにトレースファイルを作成します。

ファイルへの書き込みは追加モードで実行されます。

2つのトレースファイルはラウンドロビン方式で使用されます。指定したトレースファイルのサイズを超えた書き込みが発生すると，ファイルの切り替えを行い，次のファイルの先頭から書き込みを再開します。

複数のCUPのトレースファイルの出力先に同じディレクトリを指定すると，複数のCUPのトレース情報が混在し，トラブルシュートが困難になります。そのため，トレースファイル出力先ディレクトリはそれぞれのCUPで別々にすることをお勧めします。

また，1つのトレースデータの出力サイズによっては，指定したトレースファイルのサイズよりファイルサイズが大きくなる場合があります。

(2)　UAPトレース

UAPトレース情報は，TP1/Client/J環境定義のdcuaptracepathオペランドで指定したディレクトリに，DCUAP1.TRCおよびDCUAP2.TRCというファイル名で出力されます。ファイルのサイズは，TP1/Client/J環境定義のdcuaptracesizeオペランドで指定します。

UAPトレースは，TP1/Client/Jが提供するメソッドの開始時と終了時に次の情報を取得します。

日付

時刻

出入口種別

実行スレッド名

呼び出したメソッド名

発生した例外

指定した引数の情報

呼び出したメソッドに関係する情報

送受信したデータの内容

なお，送受信データ長が60バイトを超える場合は先頭の60バイトを取得します。

UAPトレースファイルの出力形式を次に示します。

yyyy/mm/dd hh:mm:ss.uuu Location = lll ThreadName = ttt
MethodName = nnnnnnnnnnnnnnnnnnnn
Exception = eeeeeeeeeeeeeeeeeeee
ADDRESS +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +a +b +c +d +e +f 0123456789abcdef
00000000 73 61 69 73 70 70 00 00 00 00 00 00 00 00 00 00 saispp..........
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 73 61 69 73 76 72 30 31 00 00 00 00 00 00 00 00 saisvr01........
:         :        :

yyyy/mm/dd hh:mm:ss.uuu：UAPトレースを取得した日時

lll：出入口種別

ttt：実行スレッド名

nnnnnnnnnnnnnnnnnnnn：呼び出したメソッド名

eeeeeeeeeeeeeeeeeeee：発生した例外

ADDRESS以降の文字列：各種情報（指定した引数の情報，呼び出したメソッドに関係する情報，および送受信したデータの内容）

各種情報に出力する情報は，メソッドおよび取得するタイミングによって異なります。

(3)　データトレース

データトレース情報は，TP1/Client/J環境定義のdcdatatracepathオペランドで指定したディレクトリに，DCDAT1.TRCおよびDCDAT2.TRCというファイル名で出力されます。ファイルのサイズは，TP1/Client/J環境定義のdcdatatracesizeオペランドで指定します。1トレースのデータサイズは，TP1/Client/J環境定義のdcdatatracemaxsizeオペランドで指定します。

データトレースは，CUPとTP1/Server間の送受信メッセージの内容を取得します。

データトレースファイルへの出力形式を次に示します。

yyyy/mm/dd hh:mm:ss.uuu Event = eeee ThreadName = ttt
ADDRESS +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +a +b +c +d +e +f 0123456789abcdef
00000000 07 70 c0 00 00 00 00 5c 00 00 00 00 00 06 00 05 .p.....¥........
00000010 00 00 00 10 00 00 00 00 00 00 00 00 15 bf 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 00 ................
:         :        :

yyyy/mm/dd hh:mm:ss.uuu：データトレースを取得した日時

eeee：送受信種別

ttt：実行スレッド名

ADDRESS以降の文字列：データ

(4)　エラートレース

エラートレース情報は，TP1/Client/J環境定義のdcerrtracepathオペランドで指定したディレクトリに，DCERR1.TRCおよびDCERR2.TRCというファイル名で出力されます。ファイルのサイズは，TP1/Client/J環境定義のdcerrtracesizeオペランドで指定します。

エラートレースは，TP1/Client/Jが検知した障害をメッセージ形式でファイルに記録します。メソッド実行中に障害が発生した場合，その原因は例外として報告されますが，それだけでは原因を特定できない場合があります。エラートレースを取得すると，詳細なエラー情報がファイルに出力され，原因調査の資料として使用できます。

エラートレースファイルの出力形式を次に示します。

(ttt)yyyy/mm/dd hh:mm:ss.uuu eeeeeeeeeeee

ttt：実行スレッド名

yyyy/mm/dd hh:mm:ss.uuu：エラートレースまたはメモリトレースを取得した日時

eeeeeeeeeeee：メッセージ

表A‒7　エラートレース，メモリトレースで取得するメッセージ

メッセージの内容

意味

Invalid message received.

method=aaaaaaaa

TP1/Serverから不正なメッセージを受信しました。

aaaaaaaa：このメッセージを出力したメソッド名

Error reply received.

inf=aaaaaaaa,

method=bbbbbbbb

TP1/Serverからエラー応答を受け取りました。

aaaaaaaa：受け取ったエラーコード

bbbbbbbb：このメッセージを出力したメソッド名

Exception occured.

inf=aaaaaaaa,

exception=bbbbbbbb(cc...cc),

method=dddddddd

TP1Clientクラス内でJavaシステムから例外を受け取りました。またはTP1ClientクラスからJavaアプレット，Javaアプリケーション，またはJavaサーブレットに例外を返しました。

aaaaaaaa：例外が発生したときの保守情報

bbbbbbbb：Javaから受け取った例外名，またはJavaアプレット，Javaアプリケーション，またはJavaサーブレットに返した例外名

cc...cc：例外の詳細メッセージ

詳細メッセージがある場合だけ出力します。

dddddddd：このメッセージを出力したメソッド名

Invalid data received.

(aa...aa), method=bbbbbbbb

cltAssemReceiveメソッドで相手システムから不正なデータを受信しました。

aa...aa：不正なデータ

メッセージ長が不正な場合

receive message length=メッセージ長（10進数）

bbbbbbbb：このメッセージを出力したメソッド名

Receiving message was canceled.

aaaaaaaa　(bb...bb) method=cccccccc

cltAssemReceiveメソッドで相手システムから受信したメッセージを破棄しました。

aaaaaaaa：メッセージを破棄した原因

bb...bb：データの内容

受信バッファオーバーフローの場合

receive buffer overflowed.

(receive buffer size=受信バッファの大きさ（10進数）, receive message body length=受信メッセージ本体の長さ（10進数）)

cccccccc：このメッセージを出力したメソッド名

User data did not compress,

group=aa...aa,

service=bb...bb,

reason= cc...cc

ユーザデータを圧縮しませんでした。データを圧縮しないでサービスを要求します。

aa...aa：要求先サービスグループ名

bb...bb：要求先サービス名

cc...cc：ユーザデータを圧縮しなかった理由

NO EFFECT：ユーザデータに対する圧縮効果がありません。

NOT SUPPORT VERSION：サービス要求先のTP1/Serverがデータ圧縮機能をサポートしていないバージョンです。

「NO EFFECT」の場合，圧縮前より圧縮後のデータの方が大きくなります。そのため，同一のCUPでほかにもこのメッセージが出力されていないか確認し，CUP単位でデータ圧縮機能を使用するかどうかを再度検討してください。

「NOT SUPPORT VERSION」の場合，サービス要求先のTP1/Serverが，データ圧縮機能を使用できるバージョンかどうかを確認してください。

(5)　メソッドトレース

メソッドトレース情報は，TP1/Client/J環境定義のdcmethodtracepathオペランドで指定したディレクトリに，DCMTD1.TRCおよびDCMTD2.TRCというファイル名で出力されます。ファイルのサイズは，TP1/Client/J環境定義のdcmethodtracesizeオペランドで指定します。

TP1Clientクラス内では多くの内部メソッドが実行されます。メソッドトレースは，これらの内部メソッドの実行順序や実行時刻をファイルに出力します。Java環境では障害時に取得できる情報が少ないため，どのような内部処理の延長で障害が発生したかを原因調査の材料にします。

メソッドトレースファイルの出力形式を次に示します。

yyyy/mm/dd hh:mm:ss.uuu Location = lll ThreadName = ttt
MethodName = nnnnnnnnnnnnnnnnnnnn
ADDRESS +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +a +b +c +d +e +f 0123456789abcdef
00000000 00 00 00 00 c7 0b 49 17 00 00 00 00 00 06 00 05 ......|.........

yyyy/mm/dd hh:mm:ss.uuu：メソッドトレースを取得した日時

lll：出入口種別

ttt：実行スレッド名

nnnnnnnnnnnnnnnnnnnn：呼び出したメソッド名

ADDRESS以降の文字列：メソッドトレース情報

(6)　デバッグトレース

デバッグトレース情報は，通常TP1/Client/J内のメモリバッファに取得され，例外を返した場合だけデバッグトレースファイルに出力されます。デバッグトレースファイルは，Java VMを実行するユーザのホームディレクトリ下のTP1clientJディレクトリに，dcCltXXXXXXXXXXXX.dmp（XXXXXXXXXXXX：タイムスタンプ）というファイル名で出力します。

デバッグトレースファイルを出力する時点で，デバッグトレースファイルの総数が，TP1/Client/J環境定義のdccltdbgtrcfilecountオペランドで指定したファイル数を超える場合は，更新日時の最も古いファイルを削除します。デバッグトレースファイルの総数が，（dccltdbgtrcfilecountオペランドで指定したファイル数−1）となるまで既存のデバッグトレースファイルを削除します。

CUPをJavaアプレットとして動作させる場合，古いデバッグトレースファイルの削除に失敗した場合など，デバッグトレースをファイルに出力できないときは，標準出力に出力します。標準出力に出力された場合，ブラウザなどの機能でJavaコンソールを開けば，デバッグトレース情報を参照できます。

デバッグトレースの出力形式を次に示します。

(ttt)yyyy/mm/dd hh:mm:ss.uuu MethodName = nnnnnnnnnnnnnnnnnnnn(ii) Location = lll
ADDRESS +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +a +b +c +d +e +f 0123456789abcdef
00000000 00 00 00 00 c7 0b 49 17 00 00 00 00 00 06 00 05 ......|.........

ttt：スレッドID

yyyy/mm/dd hh:mm:ss.uuu：デバッグトレースを取得した日時

nnnnnnnnnnnnnnnnnnnn：呼び出したメソッド名

ii：インスタンスID

lll：出入口種別

ADDRESS以降の文字列：デバッグトレース情報

(7)　性能解析トレース

性能解析トレース（PRFトレース）情報とは，サービスプラットフォームのトレース情報です。性能解析トレースを取得すると，UAP実行時の，一連の処理の流れおよび処理に掛かった時間を知ることができ，性能解析に必要な情報を採取できます。また，障害が発生したときに，処理がどこまで到達したかを知ることができます。

性能解析トレースの概要および使用方法の詳細については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「7.　性能解析トレースを使用した性能解析」を参照してください。ここでは，次に示す事項について説明します。

サービスプラットフォームでの性能解析トレースの出力

サービスプラットフォームとOpenTP1とのトレースの照合

性能解析トレースの取得情報

性能解析トレースのトレース取得ポイント

UAPトレースに出力される性能解析トレースの識別情報

(a)　サービスプラットフォームでの性能解析トレースの出力

TP1/Client/Jでは，TP1/Client/Jをサービスプラットフォーム上で動作させた場合に，サービスプラットフォーム上で性能解析トレースを出力できます。性能解析トレースは，TP1/Client/Jのトレース取得ポイントで取得されます。性能解析トレースを取得する場合は，TP1/Client/J環境定義にdccltprftrace=Yを指定します。

サービスプラットフォーム上で性能解析トレースを出力する場合，TP1/Client/Jが取得する情報の分だけ，出力される性能解析トレースのサイズが大きくなることを考慮して，性能解析トレースのサイズを指定してください。

(b)　サービスプラットフォームとOpenTP1とのトレースの照合

TP1/Serverに対して，ネームサービスを使用したRPC，およびスケジューラダイレクト機能を使用したRPCを行う場合は，スケジューラに送信するRPC電文中に，TP1/Client/Jのインスタンスごとにほぼ一意となる識別情報（IPアドレスなど）を付加できます。付加した情報は，OpenTP1の性能検証用トレースで出力します。このOpenTP1の性能検証用トレースと，サービスプラットフォームの性能解析トレースとを照合することによって，サービスプラットフォームとOpenTP1との間の，一連の処理の流れを知ることができます。また，バージョン07-02以降のTP1/Serverに対して，リモートAPI機能を使用したRPCを行う場合は，スケジューラに送信するRPC電文中への識別情報（IPアドレスなど）を付加できます。

OpenTP1の性能検証用トレースに識別情報を付加する場合は，TP1/Client/J環境定義にdccltprfinfosend=Yを指定します。OpenTP1の性能検証用トレースの詳細については，マニュアル「OpenTP1 解説」を参照してください。

(c)　性能解析トレースの取得情報

TP1/Client/Jで取得した情報は，性能解析トレースの付加情報部分に出力されます。性能解析トレースに取得する情報，およびトレースの出力例を次に示します。

性能解析トレースに取得する情報

ノードID：_Jaa（4バイトの英数字）

aa：ランダムな2文字の英数字（数字（0〜9）またはアルファベット（A〜Z，a〜z））

ルート通信通番部分：bbbbbbbb（4バイトの16進数字）

bbbbbbbb：IPアドレス

RPC通信通番：ccccdddd（4バイトの16進数字）

cccc：ランダムな2バイトの16進数字

dddd：通信通番

サービスプラットフォームで性能解析トレースを出力する場合の出力例

...    OPT       ASCII
...    16進表示  _Jaa/0xbbbbbbbb/0xccccdddd...

OpenTP1の性能検証用トレースに識別情報を付加する場合の出力例

(d)　性能解析トレースのトレース取得ポイント

TP1/Client/Jの性能解析トレースの，トレース取得ポイントの詳細を，処理ごとに説明します。

●rapリスナーとのコネクション確立，切断処理

rapリスナーとのコネクション確立，切断処理でのイベントID，トレース取得ポイント，付加情報および性能解析トレース取得レベルについて，次の表に示します。

表A‒8　rapリスナーとのコネクション確立，切断処理でのトレース取得ポイントの詳細

イベントID

図中の番号※1

トレース取得ポイント

付加情報※2

レベル

0x9180

1

rapリスナーへのコネクション確立処理前

要求先の情報（ホスト名，ポート番）

A

0x9181

2

rapリスナーへのコネクション確立処理後（エラー時だけ取得）

内部リターンコード

A

0x9182※3

3

rapリスナーへの接続要求データの送受信後

内部リターンコード

A

0x9183

4

rapリスナーへの切断要求データの送受信前

−

A

0x9184

5

rapリスナーへの切断要求データの送受信後

内部リターンコード

A

（凡例）

A：「標準」であることを示します。

−：該当しません。

注※1

「図A-6　rapリスナーとのコネクション確立，切断処理でのトレース取得ポイント」中の番号と対応しています。

注※2

サービスプラットフォームの性能解析トレースに付加する情報です。

注※3

コネクション確立処理がエラーとなってイベントID0x9181が取得された場合，このイベントIDのトレースは取得されません。

rapリスナーとのコネクション確立，切断処理でのトレース取得ポイントを次の図に示します。

図A‒6　rapリスナーとのコネクション確立，切断処理でのトレース取得ポイント

●リモートAPI機能でのAPI代理実行要求

リモートAPI機能でのAPI代理実行要求でのイベントID，トレース取得ポイント，付加情報および性能解析トレース取得レベルについて，次の表に示します。

表A‒9　リモートAPI機能でのAPI代理実行要求でのトレース取得ポイントの詳細

イベントID

図中の番号※1

トレース取得ポイント

付加情報※2

レベル

0x9190

1

dc_rpc_callの代理実行の要求処理前

−

A

0x9191

2

dc_rpc_callの代理実行の要求処理後

内部リターンコード

A

0x9192

1

dc_trn_beginの代理実行の要求処理前

−

A

0x9193

2

dc_trn_beginの代理実行の要求処理後

内部リターンコード

A

0x9194

1

dc_trn_chained_commitの代理実行の要求処理前

−

A

0x9195

2

dc_trn_chained_commitの代理実行の要求処理後

内部リターンコード

A

0x9196

1

dc_trn_chained_rollbackの代理実行の要求処理前

−

A

0x9197

2

dc_trn_chained_rollbackの代理実行の要求処理後

内部リターンコード

A

0x9198

1

dc_trn_unchained_commitの代理実行の要求処理前

−

A

0x9199

2

dc_trn_unchained_commitの代理実行の要求処理後

内部リターンコード

A

0x919A

1

dc_trn_unchained_rollbackの代理実行の要求処理前

−

A

0x919B

2

dc_trn_unchained_rollbackの代理実行の要求処理後

内部リターンコード

A

（凡例）

A：「標準」であることを示します。

−：該当しません。

注※1

「図A-7　リモートAPI機能でのAPI代理実行要求でのトレース取得ポイント」中の番号と対応しています。

注※2

サービスプラットフォームの性能解析トレースに付加する情報です。

リモートAPI機能でのAPI代理実行要求でのトレース取得ポイントを次の図に示します。

図A‒7　リモートAPI機能でのAPI代理実行要求でのトレース取得ポイント

●スケジュールサーバへのRPC

スケジュールサーバへのRPCでのイベントID，トレース取得ポイント，付加情報および性能解析トレース取得レベルについて，次の表に示します。

表A‒10　スケジュールサーバへのRPCでのトレース取得ポイントの詳細

イベントID

図中の番号※1

トレース取得ポイント

付加情報※2

レベル

0x91C0

1

スケジュールサーバへのコネクション確立処理前

サービス要求先ホストの情報（ホスト名，ポート番号）

A

0x91C1

2

スケジュールサーバへのRPCのサービス要求処理の実行後

内部リターンコード

A

0x91C2※3

3

SPPまたはスケジュールサーバからの応答データを受け取るコネクションの確立要求を受け付け後

内部リターンコード※4

A

0x91C3

4

ネームサーバへのコネクション確立処理前

サービス要求先ホストの情報（ホスト名，ポート番号）

B

0x91C4

5

ネームサーバへのサービス情報の問い合わせ処理の実行後

内部リターンコード

B

0x91C5※3

6

ネームサーバからの応答データを受け取るコネクションの確立要求を受け付け後

内部リターンコード※5

B

（凡例）

A：「標準」であることを示します。

B：「詳細」であることを示します。

注※1

「図A-8　スケジュールサーバへのRPC要求でのトレース取得ポイント」および「図A-9　ネームサーバへのサービス情報の問い合わせでのトレース取得ポイント」中の番号と対応しています。

注※2

サービスプラットフォームの性能解析トレースに付加する情報です。

注※3

要求データの送信が正常終了した場合に，このイベントIDのトレースは取得されます。

注※4

SPPまたはスケジュールサーバからの応答データを受け取るコネクションの確立要求の受け付けが正常終了した場合は，接続元情報（IPアドレス，ポート番号）も付加します。

注※5

ネームサーバからの応答データを受け取るコネクションの確立要求の受け付けが正常終了した場合は，接続元情報（IPアドレス，ポート番号）も付加します。

スケジュールサーバへのRPC要求でのトレース取得ポイントを次の図に示します。

図A‒8　スケジュールサーバへのRPC要求でのトレース取得ポイント

ネームサーバへのサービス情報の問い合わせでのトレース取得ポイントを次の図に示します。

図A‒9　ネームサーバへのサービス情報の問い合わせでのトレース取得ポイント

●API実行処理

API実行処理でのイベントID，トレース取得ポイント，付加情報および性能解析トレース取得レベルについて，次の表に示します。

表A‒11　API実行処理でのトレース取得ポイントの詳細

イベントID

トレース取得ポイント

付加情報※1

レベル

0x91D0

openConnectionメソッドの入口

−

A

0x91D1

openConnectionメソッドの出口

内部リターンコード

A

0x91D2

closeConnectionメソッドの入口

−

A

0x91D3

closeConnectionメソッドの出口

内部リターンコード

A

0x91D4

rpcCallメソッドの入口

inlen

A

0x91D5

rpcCallメソッドの出口

outlen，内部リターンコード

A

0x91D6

rpcCallToメソッドの入口

inlen

A

0x91D7

rpcCallToメソッドの出口

outlen，内部リターンコード

A

0x91D8

trnBeginメソッドの入口

−

A

0x91D9

trnBeginメソッドの出口

内部リターンコード※2

A

0x91DA

trnChainedCommitメソッドの入口

−

A

0x91DB

trnChainedCommitメソッドの出口

内部リターンコード※2

A

0x91DC

trnChainedRollbackメソッドの入口

−

A

0x91DD

trnChainedRollbackメソッドの出口

内部リターンコード※2

A

0x91DE

trnUnchainedCommitメソッドの入口

−

A

0x91DF

trnUnchainedCommitメソッドの出口

内部リターンコード

A

0x91E0

trnUnchainedRollbackメソッドの入口

−

A

0x91E1

trnUnchainedRollbackメソッドの出口

内部リターンコード

A

（凡例）

A：「標準」であることを示します。

−：該当しません。

注※1

サービスプラットフォームの性能解析トレースに付加する情報です。

注※2

トランザクションの開始時は，トランザクショングローバル識別子，およびトランザクションブランチ識別子も付加します。

●XAリソースサービス機能

XAリソースサービス機能でのイベントID，トレース取得ポイント，付加情報およびPRFトレース取得レベルについて，次の表に示します。

表A‒12　XAリソースサービス機能でのトレース取得ポイントの詳細

イベントID

トレース取得ポイント

付加情報

レベル

0x919C

TP1/Client/JからのXAトランザクションのstart要求の代理実行要求処理前

内部コード

A

0x919D

TP1/Client/JからのXAトランザクションのstart要求の代理実行要求処理後

内部リターンコード

A

0x919E

TP1/Client/JからのXAトランザクションのend要求の代理実行要求処理前

−

A

0x919F

TP1/Client/JからのXAトランザクションのend要求の代理実行要求処理後

内部リターンコード

A

0x91A0

TP1/Client/JからのXAトランザクションのprepare要求の代理実行要求処理前

−

A

0x91A1

TP1/Client/JからのXAトランザクションのprepare要求の代理実行要求処理後

内部リターンコード

A

0x91A2

TP1/Client/JからのXAトランザクションのcommit要求の代理実行要求処理前

−

A

0x91A3

TP1/Client/JからのXAトランザクションのcommit要求の代理実行要求処理後

内部リターンコード

A

0x91A4

TP1/Client/JからのXAトランザクションのrollback要求の代理実行要求処理前

−

A

0x91A5

TP1/Client/JからのXAトランザクションのrollback要求の代理実行要求処理後

内部リターンコード

A

0x91A6

TP1/Client/JからのXAトランザクションのforget要求の代理実行要求処理前

−

A

0x91A7

TP1/Client/JからのXAトランザクションのforget要求の代理実行要求処理後

内部リターンコード

A

0x91A8

TP1/Client/JからのXAトランザクションのrecover要求の代理実行要求処理前

−

A

0x91A9

TP1/Client/JからのXAトランザクションのrecover要求の代理実行要求処理後

内部リターンコード

A

0x91AA

TP1/Client/JからのXAトランザクションのRPC要求の代理実行要求処理前

−

A

0x91AB

TP1/Client/JからのXAトランザクションのRPC要求の代理実行要求処理後

内部リターンコード

A

0x91E2

TP1 ConnectorからのXAトランザクションのstart要求受け付け直後

内部コード

A

0x91E3

TP1 ConnectorからのXAトランザクションのstart要求応答直前

内部リターンコード

A

0x91E4

TP1 ConnectorからのXAトランザクションのend要求受け付け直後

内部コード

A

0x91E5

TP1 ConnectorからのXAトランザクションのend要求応答直前

内部リターンコード

A

0x91E6

TP1 ConnectorからのXAトランザクションのprepare要求受け付け直後

内部コード

A

0x91E7

TP1 ConnectorからのXAトランザクションのprepare要求応答直前

内部リターンコード

A

0x91E8

TP1 ConnectorからのXAトランザクションのcommit要求受け付け直後

内部コード

A

0x91E9

TP1 ConnectorからのXAトランザクションのcommit要求応答直前

内部リターンコード

A

0x91EA

TP1 ConnectorからのXAトランザクションのrollback要求受け付け直後

内部コード

A

0x91EB

TP1 ConnectorからのXAトランザクションのrollback要求応答直前

内部リターンコード

A

0x91EC

TP1 ConnectorからのXAトランザクションのforget要求受け付け直後

内部コード

A

0x91ED

TP1 ConnectorからのXAトランザクションのforget要求応答直前

内部リターンコード

A

0x91EE

TP1 ConnectorからのXAトランザクションのrecover要求受け付け直後

内部コード

A

0x91EF

TP1 ConnectorからのXAトランザクションのrecover要求応答直前

内部リターンコード

A

0x91F0

TP1 ConnectorからのXAトランザクションのRPC要求受け付け直後

内部コード

A

0x91F1

TP1 ConnectorからのXAトランザクションのRPC要求応答直前

内部リターンコード

A

（凡例）

A：「標準」であることを示します。

−：該当しません。

(e)　UAPトレースに出力される性能解析トレースの識別情報

TP1/Client/Jでは，TP1/Serverやサービスプラットフォームの性能解析トレースの情報と，TP1/Client/Jのトレースの情報を結び付けるために，UAPトレースの出口情報の末尾に，性能解析トレースの識別情報を出力します。

UAPトレースに性能解析トレースの識別情報を出力するメソッドを次に示します。

openConnection()

openConnection(String host, int port)

closeConnection()

rpcCall(String group, String service, byte[] in_data, int[] in_len, byte[] out_data, int[] out_len, int flags)

rpcCall(String group, String service, byte[] in_data, byte[] out_data, int flags)

rpcCallTo(DCRpcBindTbl direction, String group, String service, byte[] in_data, int[] in_len, byte[] out_data, int[] out_len, int flags)

trnBegin()

trnChainedCommit()

trnUnchainedCommit()

trnChainedRollback()

trnUnchainedRollback()

なお，性能解析トレースの識別情報は，TP1/Client/J環境定義のdccltprfinfosendオペランドの指定値に関係なく出力されます。

性能解析トレースの識別情報を出力した，UAPトレースの出力例を次に示します。太字で示す部分が，性能解析トレースの識別情報です。

2008/09/01 16:37:24.698  Location = Out  ThreadName = main
MethodName = TP1Client.rpcCall
Exception  =
ADDRESS   +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +a +b +c +d +e +f  0123456789abcdef
00000000  00 00 00 1c 53 75 7a 75 6b 69 00 00 00 00 00 00  ....Suzuki......
00000010  00 00 00 00 00 00 00 00 00 00 00 00 51 00 00 00  ............Q...
00000020  5f 4a 30 6d 2f 30 78 30 61 64 31 30 66 37 63 2f  _J0m/0x0ad10f7c/
00000030  30 78 32 62 35 64 30 30 30 31                      0x2b5d0001

付録B　データ変換機能の処理概要

ここでは，サービスプラットフォームが提供するデータ変換機能の処理概要について説明します。

データ変換機能に関する詳細については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「4.　電文フォーマットの作成」および「7.　データ変換の定義」を参照してください。

付録B.1　データ変換に必要な定義ファイルと作成方法

データ変換に必要な定義ファイルと，作成方法を示します。

データ変換の実行に必要な定義ファイル一覧を次の表に示します。

表B‒1　データ変換の実行に必要な定義ファイル

ファイル名

拡張子

用途

作成方法

XMLスキーマ

xsd

XML形式の構造を持つデータフォーマットを定義するファイルです。

Eclipseやエディタなどの開発ツール，または製品提供ツールで作成します。

バイナリフォーマット定義ファイル

fdx

バイナリ形式（XML形式以外）のデータフォーマットを定義するファイルです。

バイナリフォーマット定義エディタで生成します。

COBOLの構文から作成することもできます。

マッピング定義ファイル

mdo

データ変換処理の変換パターンを定義するファイルです。

マッピング定義エディタで作成します。

マッピングの定義はExcelで生成した表形式のXMLファイルから自動生成することもできます。

データ変換定義ファイル

xsl

データ変換処理の実行形式のファイルです。

マッピング定義エディタから生成します。エディタ上のマッピングの定義に対応した内容になります。

注意事項

バイナリフォーマット定義ファイル，およびマッピング定義ファイルを，開発環境が提供するエディタ以外で変更した場合，動作を保証しません。また，データ変換定義ファイルを開いて変更した場合，動作を保証しません。

以降で，各ファイルの特長を説明します。

(1)　XMLスキーマ

XML形式の構造を持つデータのフォーマットを定義するファイルです。

XMLスキーマの作成方法は，使用するデータや，ユーザ定義受付およびサービスアダプタの種類によって異なります。

(a)　ユーザが定義するデータ構造の場合

データの構造に合わせて，Eclipseやエディタなどの開発ツールで作成します。JSON形式のデータを扱うときは，JSON形式データのファイルからcscjson2xsdコマンドを利用して作成します。

(b)　SOAP受付およびSOAPアダプタの場合

WSDLファイルから自動的に生成されます。

(c)　そのほかのユーザ定義受付およびサービスアダプタの場合

ユーザ定義受付およびサービスアダプタの場合，データの構造に合わせて，Eclipseやエディタなどの開発ツールで作成します。なお，ユーザ定義受付およびサービスアダプタによっては，サービスプラットフォームでXMLスキーマを提供するケースや，テンプレートファイルを提供するケースがあります。

ユーザ定義受付の定義については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「2.　ユーザ定義受付の定義」を参照してください。

サービスアダプタの定義については，マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「3.　サービスアダプタの定義」を参照してください。

(2)　バイナリフォーマット定義ファイル

バイナリ形式（XML形式以外）のデータフォーマットを定義するファイルです。

バイナリフォーマット定義ファイルは，開発環境のバイナリフォーマット定義エディタで作成します。また，開発環境のCOBOL2FDXコンバータを利用してCOBOL登録集原文ファイルから生成することもできます。

(3)　マッピング定義ファイル

変換元入力データから変換先出力データへのデータ変換パターンを定義するファイルです。

マッピング定義ファイルは，開発環境のマッピング定義エディタで作成します。マッピング情報の作成には，入力データおよび出力データでそれぞれに対応するデータフォーマットのファイル（XMLスキーマまたはバイナリフォーマット定義ファイル）が必要です。また，Excelを利用して生成した定義ファイル（表形式のXMLファイル）をマッピング情報としてインポートできます。

(4)　データ変換定義ファイル

データ変換処理の実行形式のファイルです。

データ変換定義ファイルは，マッピング定義ファイルを基に，開発環境のマッピング定義エディタで生成します。

データ変換定義ファイルは，データ変換機能を次の用途で利用する場合に必要となります。

ファイル操作アダプタの変換オペレーション

データ変換API

csctransformコマンド

付録B.2　データ変換処理の概要

データ変換定義ファイルの内容に従ってデータを変換することをサービスプラットフォームのデータ変換処理と呼びます。以降，サービスプラットフォームのデータ変換処理をデータ変換処理と表記します。

データ変換処理では，変換元および変換先のデータ形式によって中間形式化（DOM化）することで変換を実現しています。

ここでは，次のデータ変換処理の流れを説明します。

XML形式データの変換

バイナリ形式データの変換

JSON形式データの変換

gRPC電文（Protocol Buffers形式）の変換

(1)　XML形式データの変換

XML形式データの変換では，XML形式データを中間形式（DOM）に変換します。この変換をXMLパース処理と呼びます。

XMLパース処理で中間形式化したデータに対して，データ変換定義ファイルの内容に沿った変換処理が行われます。

なお，XMLパース処理は，分岐アクティビティでの条件評価処理など，XML形式データを解析するタイミングでも行われます。

XML形式データの変換の流れを次の図に示します。

図B‒1　XML形式データからXML形式データへのデータ変換

(2)　バイナリ形式データの変換

バイナリ形式データの変換では，バイナリ形式データと中間形式（DOM）を相互に変換します。この変換をバイナリパース処理と呼びます。

バイナリ形式データを中間形式に変換する際，または中間形式からバイナリ形式データに変換する際に，バイナリフォーマット定義ファイルを使用します。

文字列データの型（文字列，整数，実数，固定小数部数値，日付時刻）については，変換時にバイナリフォーマット定義ファイルに指定した文字コードで文字コード変換が行われます。

バイナリパース処理で中間形式化したデータに対して，データ変換定義ファイルの内容に沿った変換処理が行われます。

なお，バイナリパース処理は，分岐アクティビティでの条件評価処理など，バイナリ形式データを解析するタイミングでも行われます。

バイナリ形式データの変換の流れを図に示します。

図B‒2　バイナリ形式データからバイナリ形式データへのデータ変換

注意事項

中間形式（DOM）の文字コードはUnicodeになります。このため，Code Converterのユーザマッピングテーブルを使用する場合は，バイナリフォーマット定義ファイルに指定した文字コードと，Unicode（UCS-2）とのユーザマッピングテーブルを定義する必要があります。

例えば，MS932のバイナリ形式のデータから，UTF-8のバイナリ形式のデータへとデータ変換する場合は，MS932→Unicode（UCS-2）のユーザマッピングテーブルを定義してください。

(3)　JSON形式データの変換

JSON形式データは，HTTP受付，HTTPアダプタ，Kafka受付，およびKafkaアダプタの処理で，XML形式データとの変換が行われます。

JSON形式データとXML形式データの変換では，中間形式（DOM）化をしないため，実行環境のビジネスプロセス上ではXML形式データとして扱います。

詳細については，次の個所を参照してください。

「2.15.10　HTTP受付のJSON-XML変換機能」

「2.16.14　HTTPアダプタのJSON-XML変換機能」

「2.12.2　Kafka受付のJSON-XML変換機能」

「2.12.7　KafkaアダプタのJSON-XML変換機能」

JSON形式データとXML形式データの変換は，サービスプラットフォームの変換規則に従います。JSONの形式に従っていない場合や，変換規則に従っていない場合はエラーとなります。

具体的な変換規則については，マニュアル「サービスプラットフォーム 開発ガイド 基本開発編」の「11.2　JSON-XML変換の規則」を参照してください。

JSON形式データとXML形式データの変換の流れを次の図に示します。

図B‒3　JSON形式データとXML形式データの変換

(4)　gRPC電文（Protocol Buffers形式）の変換

gRPC電文（Protocol Buffers形式）の変換では，gRPC電文とXML形式データとの変換が行われます。

詳細については，次の個所を参照してください。

「2.13.2　gRPC電文（Protocol Buffers形式）とXML形式の変換」

gRPC電文（Protocol Buffers形式）とXML形式データの変換の流れを次の図に示します。

図B‒4　gRPC電文（Protocol Buffers形式）とXML形式データの変換

付録B.3　データ変換機能のエミュレーション

サービスプラットフォームでは，データ変換機能を，HCSCサーバおよびアプリケーションサーバを構築しなくても実行できるエミュレーション機能を提供しています。

ここでは，エミュレーション機能として提供している次のコマンドについて説明します。

csctransformコマンド

cscbinaryparseコマンド

cscjsonxmlconvコマンド

(1)　csctransformコマンド

サービスプラットフォームのデータ変換処理をエミュレーションするコマンドです。

ビジネスプロセスのデータ変換アクティビティおよび，データ変換APIの処理と同等の機能を実現します。入出力データがバイナリ形式データの場合，バイナリパース処理も同時に行います。

csctransformコマンドの使い方については，マニュアル「サービスプラットフォーム リファレンス」の「csctransform（データ変換のテスト）」を参照してください。

(2)　cscbinaryparseコマンド

バイナリパース処理をエミュレーションするコマンドです。

バイナリ形式データと，中間形式のデータとの相互変換を行います。データ変換処理内で行われるバイナリパース処理と同等の機能を実現します。

cscbinaryparseコマンドの使い方については，マニュアル「サービスプラットフォーム リファレンス」の「cscbinaryparse（DOMとバイナリデータの相互変換）」を参照してください。

(3)　cscjsonxmlconvコマンド

JSON形式のデータとXML形式のデータの変換をエミュレーションするコマンドです。

次の受付やアダプタのJSON-XML変換処理，およびJSON-XML変換APIと同等の機能を実現します。

HTTP受付

HTTPアダプタ

Kafka受付

Kafkaアダプタ

cscjsonxmlconvコマンドの使い方については，マニュアル「サービスプラットフォーム リファレンス」の「cscjsonxmlconv（JSON形式データとXML形式データの相互変換）」を参照してください。

付録C　IPv6対応

ここでは，IPv6のサポート範囲と，このサポートに伴って変更された機能について説明します。

付録C.1　サポート範囲

IPv6のサポート範囲を，次に示します。

(1)　前提条件

HCSCサーバ稼働マシンは，IPv4/IPv6デュアルスタック環境でだけ対応します。

(2)　データベース接続

IPv6のデータベース接続はできません。

(3)　SOAP/HTTPのインバウンド

SOAP受付とHTTP受付は，HTTP Serverを前提とします。

(4)　受付・アダプタ

受付，およびアダプタのサポート可否について，次の表に示します。

表C‒1　受付・アダプタのサポート可否

項番

種別

受付

アダプタ

備考

1

SOAP

○

○

SOAP1.1モード，SOAP1.1/1.2併用モード共にサポートします。

2

SessionBean

×

×

−

3

MDB（WS-R）

×

×

−

4

MDB（DBキュー）

×

×

−

5

DBアダプタ

−

×

−

6

FTP

○

○

−

7

HTTP

○

○

−

8

Message Queue

×

×

−

9

Object Access

×

×

−

10

TP1

×

×

−

11

メール

−

×

−

12

SFTPアダプタ

−

○

−

13

Kafka

○

○

−

14

スケジュール駆動

−

−

−

15

gRPC

○

○

−

（凡例）

○：対応しています。

×：対応していません。

−：該当しません。

付録C.2　制限事項

負荷分散装置とIPv6の併用はサポートしていません。

付録D　用語解説

マニュアルで使用する用語について

マニュアル「アプリケーションサーバ & BPM/ESB基盤 用語解説」を参照してください。

索引

数字

1:1系切り替えシステム[1]

A

APIを使用したデータ変換[1]

C

Cookie情報〔Webサービス（SOAP通信）〕[1]

CTM〔HCSCサーバの冗長構成〕[1]

CUPの最大応答待ち時間をrapサーバ側に引き継ぐ〔定義〕[1]

CUPの最大応答待ち時間をTP1/Server側に引き継ぐ〔定義〕[1]

CUPの受信で使用するポート番号〔定義〕[1]

D

DBアダプタが使用するDB Connectorの設定[1]

DBアダプタの接続先情報の動的変更[1]

DBアダプタを使ったデータベースへのアクセス[1]

DBキューを使用したサービスとの接続[1]

dccache[1]

dccltcachetim[1]

dccltconnectinf[1]

dccltconnecttimeout[1]

dccltcuprcvport[1]

dccltcupsndhost[1]

dccltdatacomp[1]

dccltdbgtrcfilecount[1]

dccltdelay[1]

dccltextend[1]

dccltinquiretime[1]

dccltloadbalance[1]

dccltnammlthost[1]

dccltprfinfosend[1]

dccltprftrace[1]

dccltrecvbuffsize[1]

dccltrpcmaxmsgsize[1]

dccltsendbuffsize[1]

dcclttrcmplmttm[1]

dcclttrcputm[1]

dcclttrexpsp[1]

dcclttrexptm[1]

dcclttrlimittime[1]

dcclttroptiitem[1]

dcclttrrbinfo[1]

dcclttrrbrcv[1]

dcclttrrecoverytype[1]

dcclttrstatisitem[1]

dcclttrwatchtime[1]

DCCM3との接続機能〔TP1/Client/J〕[1]

dcdatatrace[1]

dcdatatracemaxsize[1]

dcdatatracepath[1]

dcdatatracesize[1]

dcerrtrace[1]

dcerrtracepath[1]

dcerrtracesize[1]

dchost[1]

dchostselect[1]

dcinquiretimecheck[1]

dcmethodtrace[1]

dcmethodtracepath[1]

dcmethodtracesize[1]

dcnamport[1]

dcnamuse[1]

dcnotifyreshost[1]

dcrapautoconnect[1]

dcrapdirect[1]

dcrapport[1]

dcrcvport[1]

dcresponsehost[1]

dcscddirect[1]

dcscdhostchange[1]

dcscdloadpriority[1]

dcscdmulti[1]

dcscdmulticount[1]

dcscdport[1]

dcselint[1]

dcsndhost[1]

dcsndport[1]

dcsndrcvtype[1]

dcsockopenatrcv[1]

dcuaptrace[1]

dcuaptracepath[1]

dcuaptracesize[1]

dcwatchtim[1]

dcwatchtiminherit[1]

dcwatchtimrpcinherit[1]

dcweburl[1]

F

FTPアダプタ[1]

FTPアダプタアカウント定義ファイル[1]

FTPアダプタの機能[1]

FTPアダプタの実行環境に依存する設定の定義[1]、[2]

FTPアダプタの処理の流れ[1]

FTPインバウンドアダプタ[1]

FTPインバウンドアダプタの機能[1]

FTP受付[1]

FTP受付使用時のトランザクション[1]

FTP受付でサポートするオペレーションとFTPコマンド[1]

FTP受付で使用できる通信モデルおよびビジネスプロセス[1]

FTP受付の機能[1]

FTP受付の実行環境に依存する設定の定義[1]、[2]

FTPクライアントおよびFTPサーバとの接続[1]

FTPクライアントからFTPサーバへのファイル転送[1]

FTPクライアントからFTPサーバへのファイル転送の流れ（同期型ビジネスプロセスを利用する場合）[1]

FTPクライアントからFTPサーバへのファイル転送の流れ（非同期型ビジネスプロセスを利用する場合）[1]

FTPクライアントから別のFTPクライアントへのファイル転送[1]

FTPコマンド許可リスト定義ファイル（FTPアダプタ用）[1]

FTPコマンド許可リスト定義ファイル（FTP受付用）[1]

FTPコマンドの実行[1]

FTPコマンドリプライタイムアウト（FTPアダプタ）[1]

FTPサーバからFTPクライアントへのファイル転送[1]

FTPサーバのファイルリストの取得[1]

FTP実行許可リスト定義ファイル[1]

FTPと連携してファイルを転送する機能（FTP連携）[1]

FTP連携システムの開発の流れ[1]

FTP連携でサポートするFTPコマンド[1]

FTP連携の概要[1]

FTP連携の適用範囲[1]

FTP連携を利用したファイル転送パターンの例[1]

FTP連携を利用するためのシステムの構成[1]

FTP連携を利用するときの注意[1]

G

GETメソッドのリクエストを送信する例〔HTTP受付〕[1]

gRPCアダプタの機能[1]

gRPCインバウンドアダプタの機能[1]

gRPC受付の機能[1]

gRPC電文（Protocol Buffers形式）とXML形式の変換[1]

gRPCプロトコルを利用したシステム[1]

gRPCプロトコルを利用した接続[1]

H

HAモニタ〔HCSCサーバの冗長構成〕[1]

HCSCコンポーネントの検証[1]

HCSCコンポーネントの配備[1]、[2]

HCSCサーバからTP1アダプタを使ったTP1サービス部品の呼び出し[1]

HCSCサーバからのMDB（DBキュー）サービスアダプタを使ったTP1サービス部品の呼び出し[1]

HCSCサーバで設定できるタイマ[1]

HCSCサーバ内の多重度[1]

HCSCサーバに関連するタイマの設定[1]

HCSCサーバのクラスタ構成[1]

HCSCサーバの冗長構成〔N対1クラスタ構成〕[1]

HCSCサーバの冗長構成〔クラスタソフトウェア〕[1]

HCSCサーバの冗長構成〔ロードバランス機能〕[1]

HCSCサーバのセットアップ〔実行環境のセットアップ機能〕[1]

HCSCサーバフォルダ[1]

HiRDBと連携した実行履歴の管理[1]

HTTPアダプタのJSON-XML変換機能[1]

HTTPアダプタのタイマ管理[1]

HTTPアダプタを使用したCookie情報の引き継ぎ[1]

HTTPアダプタを使用したサービス部品の呼び出し[1]

HTTPアダプタを利用したシステムの例[1]

HTTP受付使用時のトランザクション[1]

HTTP受付でサポートするWebサーバおよびHTTPクライアント[1]

HTTP受付のJSON-XML変換機能[1]

HTTP受付の構成例[1]

HTTP受付のタイマ管理[1]

HTTP受付のファイル管理[1]

HTTP受付の呼び出しサービス選択機能[1]

HTTP受付のリクエスト処理[1]

HTTP受付のレスポンス処理[1]

HTTP受付を使用したオンラインシステムの例[1]

HTTP受付を使用したサービス部品の呼び出し[1]

HTTP受付を使用するときの注意[1]

HTTP通信を使用したクライアントとの接続[1]

HTTP通信を使用したサービスとの接続[1]

HTTPヘッダ引き継ぎ〔Webサービス（SOAP通信）〕[1]

HTTPボディの圧縮／解凍[1]

HTTPリクエストとHTTPレスポンスのエンコーディング/デコーディング〔HTTP受付〕[1]

HTTPリクエストと要求電文の関係[1]

HTTPリクエストヘッダの処理〔HTTP受付〕[1]

HTTPリクエストボディの処理〔HTTP受付〕[1]

HTTPレスポンスと応答電文の関係[1]

HTTPレスポンスヘッダの処理〔HTTP受付〕[1]

HTTPレスポンスボディの処理〔HTTP受付〕[1]

I

IBM MQの概要[1]

IPv6対応[1]

J

Java呼び出し〔ビジネスプロセス〕[1]

JP1/IMとの連携による障害検知[1]

JP1との連携[1]

JP1によるプロセス監視[1]

JSON変換ツールを使用した変換[1]

JSON-XML変換APIを使用した変換[1]

K

KafkaアダプタのJSON-XML変換機能[1]

Kafkaアダプタの機能[1]

Kafkaアダプタのタイムアウト監視[1]

Kafkaインバウンドアダプタの機能[1]

Kafkaインバウンドアダプタのタイムアウト監視[1]

Kafka受付のJSON-XML変換機能[1]

Kafka受付の機能[1]

Kafkaとの接続[1]

L

Listenタイムアウト（FTPアダプタ）[1]

M

Message Queueアダプタを使ったメッセージキューへのアクセス[1]

Message Queue受付使用時のトランザクション[1]

Message Queue受付使用時のメッセージの二重配信防止[1]

Message Queue受付とMQリソースアダプタとの関係[1]

Message Queue受付とキューとの関係[1]

Message Queue受付とビジネスプロセスとの関係[1]

Message Queue受付の構成例[1]

Message Queue受付の送信オプション[1]

Message Queue受付を使用したサービス部品の呼び出し[1]

MHPを接続先としたTCP/IP通信[1]

O

OAuth 2.0に対応したサービスへのアクセス[1]

Object Accessアダプタ[1]

Object Wrapperシステムとの接続[1]

OpenAPI仕様書インポート機能[1]

OpenAPI仕様書からHCSCコンポーネントを作成するOpenAPI仕様書インポート機能[1]

OpenTP1との接続[1]

P

POSTメソッドのリクエストを送信する例〔HTTP受付〕[1]

PRFトレース[1]

protocコマンドの取得[1]

protoファイルの出力[1]

R

rapリスナーのポート番号〔定義〕[1]

Reliable Messagingとの関係〔MDB（DBキュー）〕[1]

Reliable Messagingとの関係〔MDB（WS-R）〕[1]

RPC[1]

RPC送受信電文の最大長〔定義〕[1]

RPCのサービス要求方式[1]

RPCの送受信バッファの生成[1]

RPCの通信形態[1]

S

SessionBeanを使用したサービスとの接続[1]

SFTPアダプタが実行するコマンド[1]

SFTPアダプタが使用するIPアドレスおよびポート番号の指定[1]

SFTPアダプタからファイルを送信するときの認証[1]

SFTPアダプタで設定できるファイル転送の機能[1]

SFTPアダプタとSFTPサーバ間の通信[1]

SFTPアダプタのタイムアウトを監視するポイント[1]

SFTPアダプタの排他管理[1]

SFTPアダプタのファイルアクセス方式[1]

SFTPアダプタの要求電文に指定できるリモートのファイルパス[1]

SFTPアダプタを使用したシステム[1]

SFTPクライアントで使用するIPアドレス[1]

SFTPクライアントで使用するポート番号[1]

SFTPサーバとの接続[1]、[2]

SFTPサーバとの接続の切断[1]

SOAP Fault動作定義ファイルによるフォルトのキャッチ[1]

SOAP Faultのfaultcodeによるフォルト判別[1]

SOAP Faultの詳細項目によるフォルト判別[1]

SOAPアダプタのフォルト判別の概要[1]

SOAPアダプタを利用したフォルトのキャッチ[1]

SOAPメッセージの構成〔Webサービス（SOAP通信）〕[1]

SQL命令のINSERT文，UPDATE文およびDELETE文を使用する場合の注意事項[1]

T

TCP/IPコネクションの確立の監視機能〔TP1/Client/J〕[1]

TCP/IP通信機能〔TP1/Client/J〕[1]

TCP/IP通信機能の使用時に初期化する環境〔定義〕[1]

TCP/IPの受信バッファサイズ〔定義〕[1]

TCP/IPの送信バッファサイズ〔定義〕[1]

TP1/Client/J環境定義の詳細[1]

TP1/Client/Jの機能[1]

TP1/Client/Jの障害対策[1]

TP1/Client/Jの定義[1]

TP1/Client/Jの定義の概要[1]

TP1/RPC受付使用時のトランザクション[1]

TP1/RPC受付でのデータの流れとデータ変換の関係[1]

TP1/RPC受付のデータ変換[1]

TP1/Web接続機能〔TP1/Client/J〕[1]

TP1アダプタおよびMessage Queueアダプタのオペレーション動的変更機能[1]

TP1アダプタの運用例[1]

TP1アダプタのオペレーション動的変更[1]

TP1アダプタの接続先情報の動的変更[1]

TP1アダプタの接続先動的変更[1]

TP1アダプタを使用したシステムの構成例[1]

TP1からTP1/RPC受付を使ったHCSCサーバのサービス部品の呼び出し[1]

TP1から非同期の標準受付を使ったHCSCサーバのサービス部品の呼び出し[1]

U

UAP障害時のトランザクション同期点処理方式〔定義〕[1]

UAPトレース〔TP1/Client/J〕[1]

UAPトレースファイルサイズ〔定義〕[1]

UAPトレースファイル作成ディレクトリ〔定義〕[1]

UAPトレースを取得する〔定義〕[1]

UOCを利用したユーザ電文の値の変更[1]

W

Webサービス（SOAP通信）に関する多重度[1]

Webサービス（SOAP通信）の場合の接続先動的変更[1]

Webサービス（SOAP通信）の場合の添付ファイル[1]

Webサービス（SOAP通信）を使用したサービスとの接続[1]

Webサービスの通信基盤との関係[1]

Windows Server Failover Cluster〔HCSCサーバの冗長構成〕[1]

WS-R（WS-Reliability）を使用したサービスとの接続[1]

WWW認証を使用したセキュアな接続[1]

X

XAリソースサービス機能〔TP1/Client/J〕[1]

XML解析処理に関する多重度[1]

XML形式[1]

XML電文内の属性値に指定した名前空間接頭辞の補完[1]

XML電文のキャッシュ機能[1]

あ

アイドルタイムアウト（FTPインバウンドアダプタ）[1]

アクティビティ[1]

アクティビティトレース機能[1]

アクティビティ〔ビジネスプロセスの作成機能〕[1]

アプリケーションからの稼働状態の確認[1]

アプリケーションサーバ（EJBコンテナ）との関係[1]

い

移行元サーバから取得したファイル情報一覧を基にファイルを取得して移行先サーバへ送信する（SFTPアダプタの場合）[1]

一括〔読み込みモード〕[1]

う

受付IDフォルダ[1]

受付・応答〔ビジネスプロセス〕[1]

運用環境の機能概要[1]

え

永続化しないビジネスプロセス[1]

永続化するビジネスプロセス[1]

永続化するビジネスプロセスと永続化しないビジネスプロセス[1]

エラー設計の概要[1]

エラートレース〔TP1/Client/J〕[1]

エラートレースファイルサイズ〔定義〕[1]

エラートレースファイル作成ディレクトリ〔定義〕[1]

エラートレースを取得する〔定義〕[1]

お

応答アクティビティのあとに定義されたアクティビティの非同期実行[1]

応答アクティビティのトランザクション[1]

応答電文受信用IPアドレスを通知〔定義〕[1]

応答電文で取得できる外部コマンドプロセスの終了情報[1]

オペレーション動的変更機能を使ったサービス定義[1]

オペレーション動的変更機能を利用した処理の流れ[1]

か

開発環境の機能概要[1]

外部コマンドの実行によるシステムとの接続[1]

外部コマンドプロセスに関する動作オプションの設定[1]

書き込みモード[1]

各オペレーションで使用するフォルダおよびファイルの管理[1]

各オペレーションの要求電文および応答電文[1]

各種サービス呼び出し機能[1]

カスタム受付を使用した場合のシステムとの接続[1]

稼働状態の確認時の注意事項[1]

稼働状態の確認の概要[1]

稼働状態の確認の流れ[1]

監視対象の設定[1]

監視対象のファイルと取得対象ファイル[1]

監視対象のファイルの状態管理機能[1]

監視対象のファイルの数量とリクエスト回数の関係[1]

監視対象のファイルの登録[1]

監視対象のファイルの登録解除[1]

監視フォルダの設定〔ファイルイベント連携機能〕[1]

き

機能拡張レベルの設定〔定義〕[1]

基本的な構造〔サービス部品呼び出し〕[1]

キャッシュ機能を利用したオブジェクトの再利用[1]

キャッシュの登録および削除のタイミング[1]

キャッシュの有効期限〔定義〕[1]

キューの名称と個数〔MDB（DBキュー）〕[1]

キューの名称と個数〔MDB（WS-R）〕[1]

共通フォルダ定義名と対応するパスの定義[1]

共通フォルダと中間ファイルの作成〔FTP受付〕[1]

共通フォルダ内のファイルの削除[1]

共通フォルダ内のファイルの生成[1]

共通フォルダ内のファイルの排他制御[1]

共通フォルダの設定〔ファイルイベント連携機能〕[1]

共通フォルダを利用したファイルアクセス[1]、[2]

く

クライアント側から転送されたファイルを変換して目的のサーバへ送信する（SFTPアダプタの場合）[1]

クラスタ構成における運用環境の構成パターン[1]

クラスタソフトウェア[1]

クラスタのセットアップ[1]

繰り返し〔ビジネスプロセス〕[1]

こ

更新完了通知ファイルの作成〔ファイルイベント連携機能〕[1]

更新排他[1]

固定長形式[1]

コネクション確立最大監視時間〔定義〕[1]

コネクション継続（Keep-Alive）を使用した通信[1]

コマンドアダプタを使用した外部コマンドの実行[1]

コンポーネントインポート機能を利用した分散開発の流れ[1]

コンポーネント共通UOCの概要[1]

コンポーネント共通UOCの使用例[1]

さ

サーバからの一方通知受信機能〔TP1/Client/J〕[1]

サービスアダプタ[1]

サービスアダプタでのキャッシュの注意事項[1]

サービスアダプタの作成〔サービスアダプタの作成機能〕[1]

サービスのエミュレーション機能の概要[1]

サービスのエミュレーション機能の設定[1]

サービス部品側と異なる電文フォーマットでサービス部品を呼び出す場合の流れ[1]

サービス部品の接続先変更[1]

サービス部品のタイムアウト値の変更[1]

サービス部品呼び出し〔基本的な流れ〕[1]

サービス部品呼び出し〔メッセージの流れ（MDB（DBキュー））〕[1]

サービス部品呼び出し〔メッセージの流れ（MDB（WS-R））〕[1]

サービス部品呼び出し〔ユーザ電文とWSDLの関係〕[1]

サービス部品呼び出し〔ユーザ電文とサービス部品のスタブとの関係〕[1]

サービス部品を呼び出す〔応答電文の扱い（MDB（DBキュー））〕[1]

サービス部品を呼び出す〔応答電文の扱い（MDB（WS-R））〕[1]

サービス部品を呼び出す流れ[1]

サービスプラットフォームの機能〔機能概要〕[1]

サービスプラットフォームのサーバマシンのローカルディスクを使用する構成例[1]

サービスプラットフォームの性能解析トレースを取得する〔定義〕[1]

サービス振り分け実行機能[1]

サービス名の設定方法（TP1/RPC受付）[1]

サービス要求先スケジューラをRPCごとに分散させる〔定義〕[1]

サービス要求先のTP1/WebのURL〔定義〕[1]

サービス呼出アクティビティのトランザクション[1]

サービス呼び出し〔ビジネスプロセス〕[1]

サービスリクエスタ〔サービスリクエスタの作成機能〕[1]

サービスリクエスタの作成〔サービスリクエスタの作成機能〕[1]

最大応答待ち時間〔定義〕[1]

最大通信遅延時間〔定義〕[1]

作業フォルダおよび共通フォルダにアクセスできるコンポーネント[1]

作業フォルダおよび共通フォルダの機能[1]

作業フォルダおよび共通フォルダを利用したファイルアクセス[1]

作業フォルダおよび作業フォルダに格納された中間ファイルの削除[1]

作業フォルダと中間ファイルの作成[1]

作業フォルダとリクエストIDの生成[1]

作業フォルダ内のファイルの生成[1]

作業フォルダ内のファイルの排他制御[1]

作業フォルダルートの定義[1]

作業フォルダを利用したファイルアクセス[1]、[2]

サブフォルダの設定〔ファイルイベント連携機能〕[1]

さまざまなシステムと接続するための機能[1]

参照排他[1]

し

時間監視[1]

識別情報[1]

システム動作を円滑にするための機能[1]

システム例外のフォルト変換[1]

システム例外をフォルトに変換する汎用フォルト[1]

実行環境での運用を管理する[1]

実行環境の機能概要[1]

実行環境のセットアップ[1]

実行許可コマンド定義ファイルによる実行制限[1]

実行履歴の管理[1]

実行履歴の検索〔プロセスインスタンス〕[1]

実行履歴の削除〔プロセスインスタンス〕[1]

実行履歴の詳細情報の参照〔プロセスインスタンス〕[1]

実行履歴の分割格納[1]

受信ポート固定機能〔TP1/Client/J〕[1]

受信用ソケットを開設する契機〔定義〕[1]

受信用のCUPのポート番号〔定義〕[1]

取得対象ファイルの作成〔ファイルイベント連携機能〕[1]

障害解析機能[1]

障害回復機能[1]

障害情報の取得機能[1]

障害情報の取得・障害回復・障害解析機能[1]

障害対策のための設計[1]

障害調査のための機能[1]

障害発生時の系の切り替え[1]

常設コネクション[1]、[2]

常設コネクション問い合わせ間隔最大時間〔定義〕[1]

常設コネクションを確立した場合の処理概要（オートコネクトモード）[1]

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

常設コネクションを自動的に確立させる〔定義〕[1]

新規〔書き込みモード〕[1]

す

スケジューラダイレクト機能[1]

スケジューラダイレクト機能を使用したRPC〔定義〕[1]

スケジューラダイレクト機能を使用した場合の処理の概要[1]

スケジュール駆動受付でのスケジュールの設定[1]

スケジュール駆動受付でのタスクの実行[1]

スケジュール駆動受付の作業フォルダ[1]

スケジュール駆動受付のタイマ監視[1]

スケジュール駆動受付のトランザクション[1]

スケジュールサービスのポート番号〔定義〕[1]

スコープアクティビティのトランザクション[1]

スコープの開始時および終了時にコミットする設定を選択した場合のトランザクション[1]

ステータスコード〔HTTP受付〕[1]

ステータスラインの処理〔HTTP受付〕[1]

せ

制御コネクション接続タイムアウト（FTPアダプタ）[1]

性能解析トレース〔TP1/Client/J〕[1]

性能解析トレースファイル[1]

性能解析トレースを出力する場合の出力例[1]

性能検証用トレース[1]

性能検証用トレースに識別情報を付加する場合の出力例[1]

性能検証用トレースに出力する情報としてTP1/Client/J内部で識別情報（IPアドレスなど）を付加する〔定義〕[1]

性能向上のための機能[1]

セッション接続タイムアウト（SFTPアダプタの場合）[1]

接続するMHPが存在するノードのホスト名〔定義〕[1]

接続するMHPのポート番号〔定義〕[1]

接続できるデータベース[1]

設定に応じたログファイルの出力内容[1]

セパレータ形式[1]

前提条件〔HTTP通信を使用したサービスとの接続〕[1]

前提条件〔外部コマンドの実行によるシステムとの接続〕[1]

前提条件〔メールサーバとの接続〕[1]

そ

相関セットの役割[1]

相関セット〔ビジネスプロセスの作成機能〕[1]

送受信後のファイルサイズ確認[1]、[2]

送信元ホスト指定機能〔TP1/Client/J〕[1]

送信元ホスト〔定義〕[1]

た

待機処理〔ビジネスプロセス〕[1]

代入〔ビジネスプロセス〕[1]

タイマ管理[1]

タイマ設計[1]

タイマ設定時の注意事項[1]

タイマの設定[1]

タイムアウト時間の設定方法（TP1/RPC受付）[1]

タイムアウトの監視〔FTPインバウンドアダプタ〕[1]

タイムアウトの監視〔FTP受付〕[1]

多重度[1]

他製品と連携して利用する機能[1]

端末固定割り当て機能[1]

端末識別情報設定機能[1]

端末識別情報〔定義〕[1]

ち

チャンク送信を使用した通信[1]

注意事項〔SessionBeanアダプタ使用時〕[1]

注意事項〔TP1アダプタ使用時〕[1]

つ

追加〔書き込みモード〕[1]

通信先を指定した接続[1]

通信先を指定した場合の接続処理の概要[1]

通信処理の運用中に監視時間に適用される値[1]

通信処理の開始中および停止中に監視時間として適用される値[1]

て

定義例外[1]

データ圧縮機能〔TP1/Client/J〕[1]

データ圧縮機能〔定義〕[1]

データ検証機能[1]

データ検証機能の概要[1]

データ検証機能の設定[1]

データ検証機能の有効範囲[1]

データコネクション接続タイムアウト（FTPアダプタ）[1]

データコネクション接続のタイムアウト（FTPインバウンドアダプタ）[1]

データ受信のタイムアウト（FTPインバウンドアダプタ）[1]

データ送信のタイムアウト（FTPインバウンドアダプタ）[1]

データ転送・取得タイムアウト（FTPアダプタ）[1]

データトレース〔TP1/Client/J〕[1]

データトレースの最大データ長〔定義〕[1]

データトレースファイルサイズ〔定義〕[1]

データトレースファイル作成ディレクトリ〔定義〕[1]

データトレースを取得する〔定義〕[1]

データベースとの接続[1]

データベースへのアクセスに関する多重度[1]

データ変換APIを使用したデータ変換[1]

データ変換機能のエミュレーション[1]

データ変換機能の処理概要[1]

データ変換時の構造変換スキップ機能の指定[1]

データ変換処理のXMLパーサプール機能[1]

データ変換処理の概要[1]

データ変換定義〔データ変換定義の作成機能〕[1]

データ変換定義の作成〔データ変換定義の作成機能〕[1]

データ変換に必要な定義ファイルと作成方法[1]

データ変換のキャッシュ機能[1]

データ変換〔ビジネスプロセス〕[1]

データ変換をしない場合の変数（メッセージ型）の組み合わせ[1]

データ読み込みタイムアウト[1]

データ読み込みタイムアウト（SFTPアダプタの場合）[1]

デッドメッセージキュー〔MDB（DBキュー）〕[1]

デッドメッセージキュー〔MDB（WS-R）〕[1]

デバッグ情報出力機能の概要[1]

デバッグ情報の出力例[1]

デバッグトレース〔TP1/Client/J〕[1]

デバッグトレースファイルの最大ファイル数〔定義〕[1]

転送コマンドの指定方法[1]

転送データの圧縮（SFTPアダプタの場合）[1]

転送前／転送後またはリスト前／リスト後に実行するFTPコマンドの管理[1]

電文フォーマット〔電文フォーマットの作成機能〕[1]

電文フォーマットの作成〔電文フォーマットの作成機能〕[1]

と

「問い合わせ間隔最大時間」をチェックする〔定義〕[1]

同期応答型RPC通信[1]

同期応答型RPC通信をする場合の処理の概要[1]

統計情報項目〔定義〕[1]

同時実行数の設定方法（TP1/RPC受付）[1]

同時実行数の設定〔Message Queue受付〕[1]

同時実行スレッド数の制御の設定[1]

動的定義変更機能〔TP1/Client/J〕[1]

途中終了アクティビティのトランザクション[1]

トラブルシュート機能〔TP1/Client/J〕[1]

トラブルシュート設計[1]

トランザクション〔MDB（DBキュー）〕[1]

トランザクション〔MDB（WS-R）〕[1]

トランザクション〔SessionBean〕[1]

トランザクション〔Webサービス（SOAP通信）〕[1]

トランザクション完了限界時間〔定義〕[1]

トランザクション最適化項目〔定義〕[1]

トランザクション制御〔TP1/Client/J〕[1]

トランザクション設計[1]

トランザクションタイムアウト時間の設定方法（TP1/RPC受付）[1]

トランザクション同期点処理時の最大通信待ち時間〔定義〕[1]

トランザクションブランチCPU監視時間〔定義〕[1]

トランザクションブランチ限界経過時間〔定義〕[1]

トランザクションブランチ最大実行可能時間〔定義〕[1]

トランザクションブランチの処理を監視〔定義〕[1]

トランザクションブランチの統計情報を取得する項目〔定義〕[1]

トレースファイルの出力内容〔TP1/Client/J〕[1]

に

任意形式（any形式）の電文フォーマットの定義[1]

任意形式（any形式）を設定した場合の処理の流れ[1]

ね

ネームキャッシュの最大エントリ数〔定義〕[1]

ネームサービス機能[1]

ネームサービス機能を使用した場合の処理の概要[1]

ネームサービスのポート番号〔定義〕[1]

ネームサービスを使用したRPC[1]

ネームサービスを使用したRPC〔定義〕[1]

は

排他取得タイムアウト（FTPアダプタ）[1]

バイナリデータの変換エラー時のデバッグ情報の出力[1]

配備から開始または停止から削除の一括実行機能[1]

配備定義〔HCSCコンポーネントの配備機能〕[1]

配備定義機能[1]

パッケージング機能[1]

パッケージング〔パッケージング機能〕[1]

汎用カスタムアダプタ[1]

汎用カスタムアダプタを使用した場合のシステムとの接続[1]

汎用フォルト電文とメッセージログのマッピング[1]

汎用フォルトを使用してシステム例外発生個所を特定する場合の流れ[1]

汎用ロードバランサ[1]

ひ

非応答型RPC通信[1]

非応答型RPC通信をする場合の処理の概要[1]

ビジネスプロセス実行機能[1]

ビジネスプロセスのアクセス制御[1]

ビジネスプロセスの階層化[1]

ビジネスプロセスの概要[1]

ビジネスプロセスの機能[1]

ビジネスプロセスの再実行[1]

ビジネスプロセスの再実行〔運用環境画面〕[1]

ビジネスプロセスの再実行〔コマンド〕[1]

ビジネスプロセスの再実行〔サービスリクエスタ（SessionBean）〕[1]

ビジネスプロセスの再実行〔サービスリクエスタ（SOAP通信）〕[1]

ビジネスプロセスの作成〔ビジネスプロセスの作成機能〕[1]

ビジネスプロセスの仕組み[1]

ビジネスプロセスの事前キャッシュ機能[1]

ビジネスプロセスの実行状態の管理[1]

ビジネスプロセスの状態の互換性の指定をOFF，サービス呼出アクティビティの状態の互換性の指定をOFFにした場合のトランザクション[1]

ビジネスプロセスの状態の互換性の指定をOFF，サービス呼出アクティビティの状態の互換性の指定をONにした場合のトランザクション[1]

ビジネスプロセスの状態の互換性の指定をONにした場合のトランザクション[1]

ビジネスプロセスの処理の流れ[1]

ビジネスプロセスのスケジュール設定[1]

ビジネスプロセスの通信モデル[1]

ビジネスプロセスのデバッグ機能[1]

ビジネスプロセスのトランザクション[1]

ビジネスプロセス〔ビジネスプロセスの作成機能〕[1]

ビジネスプロセスを使用した待機処理[1]

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

ふ

ファイアウォール[1]

ファイルアダプタでXMLデータとして扱われるファイル形式[1]

ファイルアダプタで使用できるファイル形式[1]

ファイルアダプタでバイナリデータとして扱われるファイル形式[1]

ファイルアダプタの運用例[1]

ファイルアダプタを使ったファイルの読み込みと書き込み[1]

ファイル圧縮オペレーション[1]

ファイル一覧書き込みオペレーション[1]

ファイル一覧取得オペレーション[1]

ファイル移動オペレーション[1]

ファイルイベント受付が監視するフォルダの設定[1]

ファイルイベント受付の定義ファイルの作成[1]

ファイルイベントトレース機能[1]

ファイルイベント連携機能で設計が必要な項目[1]

ファイルイベント連携時に作成するファイル[1]

ファイルイベント連携時に使用するファイルの作成[1]

ファイルイベント連携使用時の注意事項[1]

ファイルイベント連携で必要な設定[1]

ファイルイベント連携に関する実行環境の設定[1]

ファイルイベント連携のエラー設計の概要[1]

ファイルイベント連携の設定の流れ[1]

ファイルイベント連携を使用したファイルの監視[1]、[2]

ファイルイベント連携を使用するためのシステムの構成例[1]

ファイル開始遅延時間の設計[1]

ファイル書き込みオペレーション[1]

ファイル監視機能[1]

ファイル監視機能の有効化[1]

ファイル監視機能を有効にするための設定[1]

ファイル監視の開始[1]

ファイル監視の終了[1]

ファイル監視の処理時間がファイル監視の間隔を超えた場合の動作[1]

ファイルサーバの共有ディスクを使用する構成例[1]

ファイル伸張オペレーション[1]

ファイル操作アダプタ[1]

ファイル操作アダプタでサポートするオペレーション[1]

ファイル操作アダプタの機能[1]

ファイル操作が行われるときのモード[1]

ファイル送受信時に使用するフォルダの指定[1]

ファイル転送のパターン（SFTPアダプタの場合）[1]

ファイルの読み込みおよび書き込み時の排他制御[1]

ファイル複製オペレーション[1]

ファイル変換オペレーション[1]

ファイル読み込みオペレーション[1]

ファイル連携機能で使用するフォルダおよびファイルの設計[1]

ファイル連携の機能概要[1]

ファイルを扱うシステムとの接続[1]

ファイル・フォルダ削除オペレーション[1]

ファンクション〔データ変換定義の作成機能〕[1]

負荷レベルが最も低いサービス要求先スケジューラの情報をキャッシュに格納する〔定義〕[1]

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

複数のデータレコードの同時変換[1]

プロキシサーバを経由した通信[1]

プロセスインスタンスの再実行[1]

プロセスインスタンスの実行履歴の管理[1]

プロセスインスタンス〔ビジネスプロセスを使った運用〕[1]

分岐〔ビジネスプロセス〕[1]

分散開発時の注意事項[1]

分散開発時のリポジトリのインポート[1]

へ

並列処理〔ビジネスプロセス〕[1]

ベーシック認証機能を使用した接続[1]

ヘッダ割当変数の定義[1]

変数[1]

変数の種類[1]

変数の役割[1]

ほ

ホスト切り替え機能〔TP1/Client/J〕[1]

ホスト名〔定義〕[1]

ま

マスタスケジューラデーモン[1]

マッピング〔データ変換定義の作成機能〕[1]

窓口となるTP1/Serverのホスト名〔定義〕[1]

窓口となるTP1/Serverを優先して負荷分散する〔定義〕[1]

窓口となるTP1/Serverをランダムに選択する〔定義〕[1]

マルチスケジューラ機能[1]

マルチスケジューラ機能〔定義〕[1]

マルチスケジューラデーモン[1]

マルチスケジューラデーモンのプロセス数〔定義〕[1]

マルチホームドホスト形態のTP1/Serverに対してネームサービスを使用したRPCを行う〔定義〕[1]

め

メールアダプタからメールを送信するときの認証[1]

メールアダプタ使用時のトランザクション[1]

メールアダプタで設定できるメール情報[1]

メールアダプタのタイマ管理[1]

メールアダプタを使用したシステム[1]

メールサーバとの接続[1]

メソッドトレース〔TP1/Client/J〕[1]

メソッドトレースファイルサイズ〔定義〕[1]

メソッドトレースファイル作成ディレクトリ〔定義〕[1]

メソッドトレースを取得する〔定義〕[1]

メッセージキューとの接続[1]

メッセージトラッキング機能[1]

メッセージの二重配信防止[1]

メッセージのロールバック回数の設定〔Message Queue受付〕[1]

メッセージログファイル[1]

も

文字コード変換UOCを使用したファイルの変換[1]

ゆ

ユーザ定義受付の作成〔ユーザ定義受付の作成機能〕[1]

ユーザ定義受付〔ユーザ定義受付の作成機能〕[1]

ユーザ電文トレース機能[1]

ユーザ電文トレース機能使用時の注意事項[1]

ユーザ電文トレース機能の概要[1]

ユーザ電文トレース機能の設定[1]

よ

要求電文（ヘッダ）とHTTPアダプタ実行環境（共通）プロパティファイルのパラメタの対応関係[1]

要求電文を利用した外部コマンド情報の指定[1]

用語解説[1]

要素[1]

読み込みモード[1]

り

リクエストIDの生成[1]

リクエストトレースファイル[1]

リクエストラインの処理〔HTTP受付〕[1]

リストコマンドオプション定義ファイル[1]

リストコマンドオプションの設定によるLIST／NLSTコマンドの実行[1]

リストコマンドパスのデータ抽出機能〔FTP受付〕[1]

リモートAPI機能[1]

リモートAPI機能〔TP1/Client/J〕[1]

リモートAPI機能〔定義〕[1]

リモートプロシジャコール〔TP1/Client/J〕[1]

れ

例外発生時にサービスアダプタが取得するエラーの選択[1]

レングスタグ形式[1]

ろ

ロードバランス機能〔HCSCサーバの冗長構成〕[1]

ロールバック完了通知を受信する〔定義〕[1]

ロールバック要因に関する情報をログに取得する〔定義〕[1]

ログ出力アクティビティでのログ出力[1]

ログ出力アクティビティのログファイル[1]

ログ出力アクティビティのログファイルの出力[1]