2 Oracle Application Adapter for SAP R/3のベスト・プラクティス

この章では、(SAP JCo 2.1.xおよび3.xを使用する)Oracle Application Adapter for SAP R/3に固有のベスト・プラクティスについて説明します。内容は次のとおりです。

接続プールについて
セキュリティ
ロード・バランシング
エンコーディング

接続プールについて

接続プールとは、特定の宛先へのクライアント接続セットのことです。プールは、指定されたリモート・システムへの新しい接続を自動的に作成したり、既存の接続を返したりします。また、不要になった接続をプールに返す方法も提供します。次のリストに重要な点を示します。

指定した最大接続数をアプリケーションの実行中に増やすことはできません。ベスト・プラクティスとして、アプリケーションに十分な数を選択する必要があります。
接続プールには任意の名前を付けることができます。接続プールはJava仮想マシン(JVM)内部でグローバルなので、問題を回避するために、同じJVM内で稼働するアプリケーションはすべて同じネーミング規則標準に従って名前を付けることをお薦めします。
複数のユーザーが1つの接続プールを共有する場合、ユーザーはその接続プールを作成した基礎となるユーザーIDのSAP認可権限を共有します。
設計時にApplication Explorerを使用してターゲットを作成した場合、実行時には、そのターゲットを使用して作成されるすべてのオブジェクトに対して、指定した接続パラメータが使用されます。接続プロパティが使用環境をサポートできることを確認してください。
接続プール・サイズを計算するための一般的なパラメータは、時間(呼び出された関数に対するSAPアプリケーション・サーバー実行時間)+(ドキュメントのサイズ)+(ネットワーク遅延)です。特定の状況に対して許容される接続プールの最大サイズをSAPゲートウェイ管理者に確認することをお薦めします。
ドキュメントのサイズが大きい場合やトランザクションの実行時間が長い場合、「接続タイムアウト」パラメータに大きい値を設定する必要があります。実行時間が非常に長いドキュメントは、フォアグラウンドで実行しないようにします。Oracle Application Adapter for SAP R/3から呼出し可能なバッチ・ジョブの設定についてシステム管理者に確認することをお薦めします。
デフォルトでは、SAP Java Connector (SAP JCo)は接続プールに対して1つの初期接続をオープンします。その初期接続がビジー状態のときに別のリクエストが到着すると、SAP JCoは追加の接続をオープンし、最大プール・サイズになるまでこれを行います。最大プール・サイズに達すると、SAP JCoがタスクを中断せずに空き接続を待機する時間を決定する「接続待機時間」パラメータが呼び出されます。

Oracle Application Adapter for SAP R/3からSAPへの接続の数を監視するには、SAP GUIからSMGWトランザクションを使用できます。

接続プールを適切に最適化するには、アプリケーションおよびそのユーザーに関する知識が必要です。次の点について考慮する必要があります。

この機能の実行に通常かかる時間
この機能により返されるデータの量
この機能を使用するユーザー数

複数の接続ターゲットを構成して、異なる機能ごとに異なる接続プールを使用すると便利です。たとえば、品目があるかどうかを確認する受注照会は実行時間が短いため、最大限のリソースは必要ありません。しかし、ヘッダーや行明細を作成する受注作成は多数の人に実行され、比較的長い実行時間がかかるため、より大きな接続プールを構成することをお薦めします。

セキュリティ

セキュリティのベスト・プラクティスに関する重要な点を次に示します。

SAP Java Connector (SAP JCo)のデフォルトは、プレーン・テキストです。SAP JCo通信にセキュアでないネットワーク・パスがある場合は、RFC通信を暗号化することをお薦めします。
SAPゲートウェイおよびその機能の監視またはアクセスを行うユーザー権限を制限します。SAP JCo通信を行う実行時ユーザーIDが、SAPダイアログ・ユーザーではなく通信タイプ・ユーザーであることを確認してください。
ベスト・プラクティスとして、ファイアウォール内のシステム間の通信にはSAPルーター・メカニズムを使用することを考慮してください。

ロード・バランシング

使用可能なロード・バランシング・メカニズムは、ログオン・ロード・バランシングおよび登録済プログラムのロード・バランシングの2種類です。ログオン・ロード・バランシングでは、SAPメッセージ・サーバーを使用してユーザーはSAPにログオンします。メッセージ・サーバーはログオンを複数のアプリケーション・サーバーに分散し、さらに特定のアプリケーション・グループによりログオンを分散することもできます。Oracle Application Adapter for SAP R/3では、メッセージ・サーバーを使用するSAPへの接続をサポートしています。登録済プログラムのロード・バランシングは、SAPからリモート宛先に大量のデータを送信する際に使用する手法です。ベスト・プラクティスとして、ロード・バランシングに影響を与えるSAPゲートウェイ内の名前付きパラメータは、SAPゲートウェイ管理者以外は変更しないようにしてください。

iWayの登録済サーバー(チャネル)は特定のアプリケーション・サーバーではなくSAPゲートウェイに接続されるため、デフォルトでSAP Java Connector (SAP JCo)を介するロード・バランシングが有効になっています。メッセージ配信のメカニズムは、管理者がSAPゲートウェイを有効にした方法によって異なりますが、概して次のいずれかの形態をとります。

0: ロード・バランシングは行われません。最初の空きの登録済プログラムが使用されます。
1: カウンタが最も低いプログラムが使用されます。リクエストに登録済プログラムが割り当てられるたびに、カウンタが1つ増えます。
2: 負荷が最も少ないプログラム(SAPによって判断される)が使用されます。

SAPゲートウェイ・サーバーとiWayチャネル・インスタンスの間に1対1の関係がある場合、ロード・バランシングは行われません。サーバーに送信されるメッセージのタイプは、インタフェース・ドキュメント・スタイルおよびRFC宛先によって決まります。RFC宛先は、プログラムIDをSAP内部に保持するために使用され、またすべてのメッセージをiWayチャネルにルーティングするためにも使用されます。このため、RFC宛先を制御するSM59トランザクションは、リモート・サーバーのIPアドレスをSAP内部に隠すためにロックしておくことをお薦めします。SAP内部では、CALL FUNCTION呼出しでDESTINATIONパラメータを指定し、iWayサーバーが存在するRFC宛先を渡すことにより、RFC関数モジュールがiWayチャネルにルーティングされます。例:

CALL FUNCTION 'RFC_GET_SYSTEM_INFO DESTINATION ' DESTINATION 'MYDEST'

MYDESTは、SM59トランザクション内でリモートTCP (T)宛先として定義されており、パラメータの1つとして「Registered Server Program」を保持します。

iWayチャネルはSAPゲートウェイに接続され、同じプログラムIDをSAPゲートウェイに公開します。この時点で、1つ以上のサーバーが接続を受け入れます。

SAP IDocでは、システムの送受信を定義するために追加の構成が必要です。これらはSAP論理システムに含まれています。メッセージ管理を介してルーティングされるIDocはすべて、RFC宛先にリンクされた論理システムを使用して、チャネルを介して処理されます。BAPIオブジェクトにはアウトバウンド・フォームがなく、BAPIアウトバウンド・オブジェクトをSAPから使用するには、BAPIのRFC関数フォームを使用します。たとえば、Company.GetDetailはBAPI COMPANY_GETDETAILに置き換えることができます。

プログラムIDに送信されたメッセージはすべて、SAPゲートウェイおよびプログラムIDをリスニングするよう構成されているチャネルに到着します。チャネルからメッセージを受信するよう構成されている最終宛先は、そのチャネルからのすべてのメッセージを受信します。これは、ビジネス・プロセスの構成において大きな意味を持ちます。メッセージをタイプまたはコンテンツに基づいてルーティングするコーディング手法として、それぞれのメッセージ、メッセージ・フィルタまたはメッセージ・スプリッタに対して異なるプログラムIDを使用することを考慮してください。

複数のチャネルまたはサーバーが同じプログラムIDで構成されていると、SAPシステムでロード・バランシングが有効になっているかどうかによって、メッセージが重複したり、到着しないことがあります。プログラムIDのデプロイおよび使用は慎重に行い、その割当ては論理的かつ協調的に(たとえば、部門別またはメッセージ・タイプ別に)行ってください。

エンコーディング

UnicodeシステムのiWayチャネルは、Unicodeモードでのみ動作します。SM59トランザクションで、SAP GUIで宛先を作成する際に「RFC Destination」パラメータとして「Unicode」が選択されていることを確認してください。

SAP Java Connector (SAP JCo)のRFCコンポーネントは、送信側(クライアント)のターゲット・コード・ページを自動的に判別し、それに応じてクライアントとサーバーの間のコード・ページ変換を調整します。これを変更する方法としては、ターゲット・マシンのコード・ページを変更する方法しかなく、Windowsでは「コントロールパネル」の「地域と言語のオプション」を使用します。その他のシステムの場合は、管理者に相談することをお薦めします。一般的に、マシンにはコード・ページと言語パックが必要です。コード・ページ間のマッピングには、エンコーディングが使用されます。これはUnicodeシステムでは簡単に行えますが、Unicode以外のシステムでは困難であったり可能でない場合もあります。原則として、Unicode以外のシステムでは、マシンのコード・ページと言語パックはデータ表示用に限定されます。ただし、Java言語のUnicodeサポートにより、リモート・システムが正しく構成されていれば、送信が正常に行われることもあります。

SAPからドキュメント(特にIDoc)を受信すると、セグメントに複数の言語が含まれていることがあります。すべての言語を正しく取得することは、通常は不可能です。たとえば、Javaエンコーディング変数をISO-8859-2に設定すると、ドイツ語のウムラウトは正しく送信されますが、日本語の漢字は歪みが生じます。この状況に対する唯一の解決策は、テキスト・セグメントを複数回に分けて送信してから、1つの結果に結合することです。