| Oracle® Fusion Middleware Oracle WebLogic Server Application Adapter for SAP R/3(SAP JCo 3.0)ユーザーズ・ガイド 11g リリース1 (11.1.1.3.0) B61422-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server Application Adapter for SAP R/3(SAP JCo 3.0)ユーザーズ・ガイド 11g リリース1 (11.1.1.3.0) B61422-01 |
|
前 |
次 |
The Oracle Application Adapter for SAP R/3は、3種類のメッセージ・タイプのシナリオと2つの通信ロールを使用してSAPとメッセージを交換します。各ロールには、SAPサーバーとアダプタ上で有効にすべき構成オプションがあり、これにより通信を有効にしてメッセージを送信できるようになります。この付録では、ロール・タイプ、メッセージ・タイプ、およびその関連用語について説明します。SAP Productiveシステム環境では、特殊な構成ロールの正しい管理者のみが通信エントリを変更または作成する権限を備えています。この付録では、管理者のための必須タスクについてのチェックリストを提供し、インバウンドとアウトバウンドのメッセージ処理を構成する全体プロセスについて説明します。この情報は、生産性の低いシステムの構成や参照目的で使用することができます。
この付録の内容は以下のとおりです。
Oracle Application Adapter for SAP R/3の実装では、SAP Java Connector (JCo)を使用します。これは、Javaネイティブ・インタフェース(JNI)を介してネイティブcの通信層と通信するJavaインタフェースです。RFC (Remote Function Call) APIは、CPIC (Common Programming Interface - Communications)とTCP/IPプロトコルを実装してSAPシステム上の対応するコンポーネントと通信します。各メッセージは、XML書式に、またはXMLからRFCの書式にシリアライズされ、SAPへ送信できるよう現在のSAPメッセージ・タイプにマーシャルされます。SAPサーバーは、現在の実行時オブジェクトにメッセージをアンマーシャルし、そのオブジェクトを実行します。レスポンス・メッセージは、RFCにマーシャルされてアダプタに返され、XMLにアンマーシャルおよびシリアライズできるようになります。このプロセスは、シームレスで非常に高速です。エラーは、不適切な資格証明、ドキュメント・エンコーディング、または実際のアプリケーション・エラー(たとえば、特定のフィールドに対する誤った値)によって生じる可能性があります。
RFCプロトコルはリクエストのモードに応じて変化する動的プロトコルです。リクエストが、RFC接続ノードへのインバウンドであるとき、そのノードの機能は、リクエストを満たすサーバーになります。リクエストがノードからのアウトバウンドのとき、そのノードの機能は、クライアントになり、サーバーがそのリクエストに対して応答するのを待機します。レスポンスの不要なアウトバウンド・イベントもサーバーが処理します。
別のシステムへの接続をインスタンス化するシステムはクライアントであり、クライアントのロールはリクエスト/レスポンスのメッセージを同期方式で処理します。クライアント・システムはメッセージ処理を実行しませんが、これを有効にします。メッセージはクライアント上で開始されて終了します。アダプタは、OracleからSAPにメッセージを送信するとき、クライアントとして機能します。
クライアント接続のタイプは、次のとおりです。
アプリケーション・サーバー。これは単一のSAPアプリケーション・サーバーに接続されます。
メッセージ・サーバー。これは、分散負荷処理のための、SAPアプリケーション・サーバー・グループに対するSAPログオン・ロード・バランサのメッセージ・サーバーに接続されます。
どちらの接続タイプも接続プールと呼ばれる特殊な接続を使用します。これについては、この付録の後半で説明します。
クライアント・メッセージ・のタイプは、次のとおりです。
BAPIメッセージ。これは、XML属性としてパラメータを備えたオブジェクト形式のメッセージです。
RFCメッセージ。これは、XML要素としてパラメータを備えたRFC形式のメッセージです。
Intermediate Documents (IDoc)。これは、位置区切りのフラット・テキストまたはXML要素のパラメータを送信するALEメッセージ・システムです。
別のシステムから接続リクエストを受信するシステムはサーバーです。サーバーは、メッセージ処理を実行し、結果をクライアントに返します。サーバーは、NOT_IMPLEMENTEDの例外付きの特定のメッセージに対する処理を実装していない場合、メッセージ/リクエストを拒否することができます。サーバーは、次の2つのタイプのメッセージを処理できます。
インバウンド・メッセージ。これには、メッセージ・リクエストとそのリクエストのパラメータが含まれます。
同期メッセージ。これは、インバウンド・メッセージを選択し、SAPに渡す前に追加作業を実施するか、別のシステムに渡すか、あるいは追加処理のための処理を行います。
SAPアプリケーション・サーバーは、同期メッセージ処理が終了するのを待ってから処理を続行します。
サーバー接続のタイプは、次のとおりです。
処理モード(リクエスト)。これは、メッセージ・タイプとパラメータを単に受け取るだけです。
レスポンス。これは、同期処理を実行します。
サーバー・メッセージ・のタイプは、次のとおりです。
RFCメッセージ。これは、要素としてパラメータを備えたRPC形式のメッセージです。
Intermediate Documents (IDoc)。これは、位置区切りのフラット・テキストまたはXML要素のパラメータを送信するALEメッセージ・システムです。
Remote Function Call (RFC)またはBusiness Application Interface (BAPI)のオブジェクト用のリクエスト/レスポンス(クライアント)メッセージをSAPシステムに送信するには、有効なログオン資格証明のセットが必要です。必要なパラメータのリストを含む、アダプタ・ターゲットの構成方法の詳細は、「SAP R/3ログオン・パラメータの特定」を参照してください。アダプタ・ターゲットの有効な値については、SAPシステム管理者に問い合せてください。
初回ログオンの前に次の値を取得してください。
有効なSAP接続パラメータ
SAP通信ユーザー(SAP GUI DIALOGユーザーはセキュリティ上の理由でお薦めできません)
アダプタが実施すると想定されるタスクのための正しいSAP認可
SAP認可
サーバーに接続する前に適正なSAP認可を取得する必要があります。SAPセキュリティ実践のためRFCとDIAGが同じユーザーIDにアクセスできないようにすることをお薦めします。
RFCのアクセスを保護するために使用する基本認可オブジェクトは、次のとおりです。
S_RFC: 関数グループ(認可オブジェクト・クラスAAABにある)を保護します。
認可オブジェクト+S_RFC:
認可フィールド: RFC_TYPE
認可値: 「FUGR」が、唯一有効な値です。
認可フィールド: RFC_NAME
認可値: 有効にする関数グループの名前(("ABCD")または'*'など)。
認可フィールド: ACTVT
認可値: 16(Execute)が、唯一有効な値です。
個々の関数グループは、その実行可能コードの中に追加のセキュリティを備えている場合があります。これは、関数開発者やアプリケーション作成者の要求であり、関数やアプリケーションのユーザーに関数やアプリケーションを使用するための認可要件について通知するものです。追加の認可が必要かどうかは、管理者に問い合せて判断してください。
個々の表は、次の認可オブジェクトを使用することで、アクセスから保護することができます。
S_TABU_DIS: 表(認可オブジェクト・クラスBC_Aにある)を保護します。
認可オブジェクト+S_TABU_DIS:
認可フィールド: DICBERCLS: または("認可グループ")
認可値: たとえば、Table: MARAは、グループ"MA"にあります。
認可フィールド: ACTVT
認可値: 03(表示)
この認可オブジェクトの詳細な説明については、SAPのシステム・ドキュメントを参照してください。
アダプタ・ターゲットに対して正しい資格証明を指定し、正しい認可がSAPアプリケーション・システムに組み込まれたら、アダプタ初期化の準備が完了です。
リクエスト/レスポンス(クライアント)メッセージ
ビジネス・オブジェクト・リポジトリ
アプリケーション・エクスプローラを使用して適切なアプリケーション・ツリーのブランチ(財務会計など)を展開し、ビジネス・オブジェクト(会社コード)に移動して展開します。オブジェクトをクリックしてそのオブジェクトのメソッドを表示します。BAPIには、リリース状態とバージョニング状態があります。実行時に使われるすべてのBAPIは、"リリース"ステータスになければなりません。そうでないと実行時例外が生成されます。XMLスキーマを生成するメソッドを選択します。XMLスキーマからXMLインスタンス・ドキュメントを作成し、これにデータを埋め込みます。適切な入力と出力(file/html/その他)の通信メソッドを用いてOracleプロセスを作成します。結果を受信して処理できるようアダプタにドキュメントを提示します。
Remote Function Call
アプリケーション・エクスプローラを使用して適切なアプリケーション・ツリーのブランチ(財務会計など)を展開し、関数グループ(0002 - 会社コード)に移動して展開します。各関数は、異なる処理メソッドを公開しています。すべてのBAPIは、その実装がRFCを経由するため、RFCオブジェクトとして存在します。これらは、たとえばBAPI処理が不可能なときに、イベント処理が可能となるように呼び出すことができます。すべてのRFCがBAPIとして存在するわけではありません。関数を選択してXMLスキーマを生成します。XMLスキーマからXMLインスタンス・ドキュメントを作成し、これにデータを埋め込みます。適切な入力と出力(file/html/その他)の通信メソッドを用いてOracleプロセスを作成します。結果を受信して処理できるようアダプタにドキュメントを提示します。
ALE IDOCメッセージ
IDocが送信されてSAP R/3システムに格納されるSAP ERP ALE*インバウンド・メッセージ処理では、使用するSAPサーバー上に特定の構成を必要とします。このロールでは、メッセージはトランザクション・データとしてSAPに送信され、SAPサーバー上に格納されます。ドキュメント・データは、トリガーされたワークフローの間に、SAP内の第2ステップで処理されます。
IDocをSAP ERPに送信するには、メッセージ・パーティに関する次の情報が必要となります。
メッセージの送信者
メッセージの受信者
送信するメッセージのタイプ
送信者と受信者は、ALEシステムで定義する必要があり、また各パーティごとに、各パーティが受け取るメッセージの種類とその処理方法を定義します。
送信および受信のシステム情報は、論理システムと呼ばれるユニットに定義されています。接続情報には、物理的な接続情報が含まれていないからです。論理システムは、特定の送信者または受信者に関するすべての情報のコンテナとしての役割を果たします。
論理システムを定義したら、システムが送受信する各メッセージについての情報が配信モデルに格納されます。このモデルは、処理が行われる前に定義する必要があり、送信者または受信者のエラーを避けるために厳密に定義する必要があります。配信モデルでは、IDocメッセージ・アプリケーションによってフィルタを有効にすることもできます。これにより、IDocの特定のパートだけを送信または配信することができます。論理システム、配信モデル、およびメッセージ・タイプは、1対1に対応しています。フィルタ・グループ、フィルタ・オブジェクト、ルール、および依存関係によって複雑なフィルタ・ルールを構成することができます。配布モデルの構成の詳細な説明については、SAPのシステム・ドキュメントを参照してください。
SAPシステムによるIDocの処理は、パートナ・プロファイルで定義されます。各パートナとメッセージごとに、メッセージを(おそらく)個別に処理するプロセス・コードを定義することが可能です。
アダプタのチェック・リスト
SAPにメッセージを送信するには、ALE管理者は以下を割り当てる必要があります(ログオン資格証明の後)。
論理システム名
SAPアプリケーション・サーバーに送信するメッセージ・タイプとIDoc基本タイプ
SAP ERPシステムの内部で、ALE管理者は、以下を行う必要があります。
論理システムを作成します。
配信モデルを作成します。
モデルの送信者を割り当てます。
モデルの受信者を割り当てます。
メッセージ・タイプを割り当てます。
論理システムのパートナ・プロファイルを作成します。
各メッセージ・タイプごとに、メッセージを処理するSAPのプロセス・コードを割り当てます。
例
論理システム"ORACLIENT"が作成されます(SAPトランザクションSALEを経由)。
配信モデル"ZORACLNT"が作成されます(SAPトランザクションBD64を経由)。
送信パートナ"ORACLIENT"と受信パートナ"T90ALECNT"用にメッセージ・タイプ"MATMAS"が追加されます(中央ホストのALEコンポーネント)。
パートナ・プロファイル"ORACLIENT"が作成され(SAPトランザクションWE20を経由)、インバウンド・メッセージ"MATMAS"には、プロセス・コード"MATM"が割り当てられます。
|
注意: インバウンド・メッセージ用のSAP ERPを構成するための手順は、参考としてここに記載します。詳細は、SAP ERPのドキュメントを参照してください。 |
以下の手順を実行して、インバウンドIDoc処理のためのSAP R/3を構成する必要があります。
論理システムの構成
配信モデルの構成
インバウンドのパートナ・プロファイルの定義
論理システムは、メッセージの送信者または受信者のパーティに関する構成情報のためのコンテナ・オブジェクトです。これが論理システムである理由は、接続情報が格納されず、エンド・ポイントが処理できるメッセージとメッセージを処理する方法についての情報だけが格納されているからです。
SAPトランザクション・ショートカット
/n - 現在のトランザクションを終了し、新しいトランザクションを直ちに開きます。
/o - 現在のトランザクションのコンテキストを維持し、新しいウィンドウで新しいトランザクションを開きます。
論理システムの定義
論理システムの定義は、「カスタマイズのためのSAP実装ガイド(IMG)」にエントリを構築することで作成されます。
ALEは、SAP ERP Application Link Enablementシステムであるため、/nSALEトランザクションを使用してALE用のIMGまで移動します。
図A-1に示すように、SALEトランザクションに移動します。
図A-2に示すように、IMGの表示ウィンドウにALEの構成ツリーが表示されます。
次のステップを実行します:
「基本設定」ノードを展開します。
Expand 論理システムを展開します。
論理システムの定義をクリックします。
SAP R/3ユーザーの場合、画面がわずかに異なる可能性があり、特別なノードである送受信システムを展開します。
図A-3に示すように、「注意: 表がクロスクライアントです」メッセージが表示されます。
このメッセージは、論理システム内のカスタマイズ・データの変更がSAP ERPサーバーのすべてのユーザーに適用されることを通知するために表示されます。これは、特にログオン・クライアントに限定されるほとんどのアプリケーション・データとは異なります。論理システムのエントリに変更を加えないでください。新しい情報のみを追加してください。正しい権限を備えたSAPログオンIDを使用してください。
緑色のチェック・マークをクリックして続行します。
図A-4に示すように、"論理システム"ビューの変更ウィンドウが表示されます。
新規エントリボタンをクリックします。
図A-5に示すように、新規エントリ: 追加エントリの概要ウィンドウが表示されます。
論理システム列に論理システム(ORACLETDSなど)を入力し、名前列に説明を記載します。
|
注意: フィールドは黄色で強調表示されるので、必須フィールドであることがわかります。 |
図A-6に示すように、トップ・メニュー・バーの「保存」アイコンをクリックします。
ワークベンチ・リクエストのプロンプトダイアログが表示されます。
|
注意: システムの使用状況によっては、最終ワークベンチのリクエスト番号がダイアログに表示されますが、これを使用せずに、次のステップに進んでください。 |
図A-7に示すように、「新規リクエスト」アイコンをクリックして新しいリクエストを作成します。
リクエスト・システムでエントリの説明を入力します。残りのフィールドは、自動的に記入されるので変更する必要はありません。
ワークベンチ・リクエストのプロンプトダイアログが再び表示され、新規リクエスト番号には、ワークベンチで最後に作成されたリクエスト番号が記入されます。これを使用しないでください。図A-8に示すように、チェック・マークをクリックして新規リクエスト番号を作成します。
図A-9に示すように、論理システム・エントリウィンドウが新しい論理システム情報でリフレッシュされます。新しい論理システムは青色で強調表示され、このステップが正常に完了したことを示します。
配信モデルには、送信者論理システムと受信者論理システム、および送受信されるメッセージのタイプが含まれます。指定の送信者または受信者に有効な配信モデルがない場合、メッセージは処理されず、エラー場所に転送されます。SAP BAPIオブジェクトやフィルタリングなど、配信モデルの高度なトピックについては、SAPのドキュメントを参照してください。
配信モデルの定義
配信モデルを定義するには、以下の手順を実行します。
図A-10に示すように、bd64トランザクションを実行します。
配信モデルの表示ウィンドウがデフォルトの表示モードで表示されます。これは、図A-11に示すように、現在のモデル・ビューのエントリを示します。
ツリーを展開して各モデル・ビューのエントリを表示します。
アイテムを追加するには、トランザクションを"モード変更"に切り替える必要があります。
図A-12に示すように、配信モデルをクリックし、処理モードの切り替えを選択します。
図A-13に示すように、画面はリフレッシュされて、モデル・ビューのウィンドウは配信モデルの変更に切り替わります。
利用可能なメニュー・ボタンから、モデル・ビューの作成を選択します。
図A-14に示すように、モデル・ビューの作成」ダイアログが表示されます。
「短縮テキスト」フィールドにモデル・ビューの名前を入力し、技術名フィールドに名前を入力します。これは説明としての役割も果たします。
文字Zで始まる名前を使用することをお薦めします。SAPはシステム更新の場合にこれらの名前を上書きしないからです。これは、モデル・ビューの名前のみです。
緑色のチェック・マークのアイコンをクリックして情報を入力します。
画面はリフレッシュされて、配信モデルの変更に戻ります。図A-15に示すように、構成した配信モデルが新たにリストに加えられます。
モデル・ビューは、「保存」アイコンをクリックするまで、トランザクションの一時記憶域にあります(明るい色でエントリを表示)。システム接続が消失またはタイム・アウトになると、エントリは消失します。変更内容が失われないようにするため、配信モデルの構成プロセスの間、各ダイアログの後に変更を保存することをお薦めします。
以前に定義したエントリにカーソルを置きます。
図A-16に示すように、これでエントリは強調表示されます。
中央のメニュー・バーで、メッセージ・タイプの追加ボタンをクリックします。
メッセージ・タイプの追加ダイアログが表示されます。
次のステップを実行します:
「送信者」フィールドに、Oracleシステム用の送信論理システムの名前を入力します(ORACLETDSなど)。詳細は、「論理システムの構成」を参照してください。
「受信者」フィールドに、SAPシステム用のクライアントALE論理システムの名前を入力するか、ドロップダウンから選択します(T90CLNT090など)。
「メッセージ・タイプ」フィールドに、使用するメッセージのタイプを入力します(MATMASなど)。
各フィールドの右にあるドロップダウン・アイコンをクリックすると、利用可能な値をリストから参照できます。
緑色のチェック・マークのアイコンをクリックして情報を入力します。
メインの配信モデルの変更ウィンドウがリフレッシュされます。
「保存」をクリックします。
ALE階層ツリーを最近作成した配信モデルまで移動します。図A-17に示すように、送信者と受信者はグラフで表示され、送信者、受信者、およびメッセージの関係が示されます。
同じシステムのその後のメッセージ・タイプについては、モデル・ビューを受信者名まで展開し、その名前にカーソルを置きます。次に、メッセージ・タイプの追加ボタンをクリックします。すべてのフィールドが自動的に埋め込まれます。これでメッセージ・タイプを追加できます。
パートナ・プロファイルは、各論理システムごとに、処理するメッセージとメッセージの処理方法を定義します。これにより、パートナの詳細処理を柔軟に構成することが可能となります。各メッセージ・タイプは、パートナ・プロファイルに1つだけ入力することが可能です。パートナ・プロファイルを定義するには、以下の手順を実行します。
図A-18に示すように、we20トランザクションを実行します。
図A-19に示すように、パートナ・プロファイルウィンドウが表示されます。
パートナ・タイプLSを選択して、中央メニュー・バーの白いアイコンをクリックします。トップ・メニューから「作成」を選択することもできます。
図A-20に示すように、画面の右側が、パートナ・プロファイルの未記入フォームに変わります。。
パートナ番号フィールドに、論理システムの名前を入力し(ORACLETDSなど)、「保存」アイコンをクリックします。
図A-21に示すように、画面は新しいプロファイルによって変更されます。
埋め込まれたテキスト"Inbound parmtrs"のエントリが表示されるまで下へスクロールします。
緑色の「プラス記号」アイコンをクリックします。
図A-22に示すように、パートナ・プロファイル: インバウンド・パラメータダイアログが表示されます。
「メッセージ・タイプ」としてMATMASを入力します。
「プロセス・コード」ドロップダウンを使用して、MATMASを表す「MATM」を選択します。
プロセス・モードとして「即時」または「背景」を選択します。
|
注意: 正しい設定値については、SAP管理者に問い合せてください。 |
メニュー・バーで「保存」アイコンをクリックしてMATMAS用のインバウンド・パートナ・プロファイルを保存します。
図A-23に示すように、メニュー・バーの「戻る」ボタンをクリックして前のウィンドウに戻ります。
図A-24に示すように、MATMASがエントリ・リストに表示されます。
これで、論理システム/パートナ・プロファイル: OracleTDS/MATMASのインバウンド構成が完了します。その他のインバウンドIDocメッセージ・タイプのエントリを追加するには、「論理システム用の配信モデルの構成」から手順を繰り返してください。別の論理システムおよびメッセージ・タイプを追加するには、「論理システムの構成」から手順を繰り返してください。
これで、適切なOracleプロセスを構成した後、IDocを送信できるようになります。
SAP IDocの監視コンソールから、SAPトランザクションWE02におけるIDocトランザクションを監視することができます。図A-25に示すように、IDocの処理状態とステータスが、送信者、受信者、およびデータとともに利用可能です。
Oracle Application Adapter for SAP R/3は、SAPアプリケーション・サーバーからの2種類のアウトバウンド・メッセージを処理することができます。Remote Function CallメッセージまたはトランザクションID付きのトランザクションRFCメッセージです。SAP JCOを経由するすべての通信処理は、同期処理ですが(リクエスト/レスポンス)、メッセージ処理は、非同期(配信のみ)または同期のいずれでも可能です(編成プロセスが作業を実施し、待機するSAPアプリケーション・サーバーに情報を返します)。RFCメッセージは、SAP ABAPプログラムまたはSAPワークフロー・システムさらにはSAP関数テスト・トランザクションからでも送信することができます。
アウトバウンド処理は、ほとんどの場合、イベントとして実装されています。SAPアプリケーション・サーバー上には、多くの段階の定義イベントがあります。イベント処理はリンクによって連結されています。デフォルトでは、すべてのリンクがProductive SAPサーバー上で有効にされているわけではありません。イベントをアクティブにしてメッセージを送信できるようにするには、オブジェクトのステータスで変更を送信できるオブジェクト、有効なイベントのリストへのリンク、、およびイベント・ハンドラが必要です。イベント・ハンドラは、メッセージの処理を実装しています。
アクティブなSAPイベントは、実装されたイベント・ハンドラで定義されたコンポーネントに関するステータスの変化です。SAPアプリケーション・サーバーには多くのタイプのイベントがあり(最もよく知られているイベント・ハンドラはALEメッセージ制御)、Material MasterやCustomer MasterなどのSAP周辺オブジェクトによって実装されています。これらのオブジェクトの変化によってアウトバンド・イベントIDocを生成することができます。
イベントの生成は通常、SAPによって実装されますが、多くのオブジェクトはイベント・ハンドリング用に有効にすることが可能です。ただし、ほとんどの場合、高度な構成やプログラミングが必要です。SAPイベントのタイプおよびその構成方法の詳細は、SAPのドキュメントを調べてください。
RFCアウトバンド・メッセージの場合、Remote Function Callを受信するためにSAP RFCの宛先とプログラムIDが必要です。
IDoc処理の場合、tRFCを経由してメッセージ制御イベントを受信するための、論理システム、配信モデル、パートナ・プロファイル、およびポートを作成する必要があります。
SAPアウトバウンド用語
JCO/RFCクライアント。RFCリクエストを作成するシステムであり、オプションとしてレスポンスを待ちます。
JCO/RFCサーバー。RFCリクエストを受信し、リクエストを処理するシステムであり、オプションとしてレスポンスを受信します。
SAPゲートウェイは、SAPアプリケーション・サーバーまたは専用のゲートウェイ・サーバー上で動作するプロセスです。ゲートウェイ・プロセスは、SAPへのすべての接続を管理します。SAPへのサーバー接続は、SAPアプリケーションの登録済みプログラムとして以前に構成されて必要なプログラムIDを提示しない限り、受け入れられません。
サーバー接続は、接続そのものをゲートウェイに提示し、プログラムIDを公開します。登録済みプログラムIDの中にプログラムIDが見つかれば、ゲートウェイ・サーバーは接続をそのサーバーに提供し、サーバーは接続を受け入れます。このプログラムIDは、SAP内のRFC宛先にリンクされ、これによってSAP関数モジュールとALEドキュメント(IDocまたはBAPI IDoc)を宛先に転送できるようになります。RFC宛先は、SAPプログラムIDを特定するキーとして機能します。プログラムIDは、SAPへの接続を確立するアプリケーション・サーバーによっても公開され、接続サーバーのIPアドレスへの直接リンクになります。メッセージは、RFC宛先を経由してアプリケーション・サーバーに転送されます。良好なセキュリティを確保するため、プログラムIDを実装するアダプタ・インスタンスへのアクセスを備えたOracle Application Adapter for SAP R/3ユーザーと、SAP内部のプログラムIDを変更または表示するSAPトランザクション権限を備えたユーザーとを分離することをお薦めします。すべてのリクエストは、RFC宛先を経由して転送されます。
|
注意: RFCサーバー・プログラムは、SAPゲートウェイに登録され、着信するRFCコール・リクエストを待ちます。RFCサーバー・プログラムは、特定のSAPシステムではなく、SAPゲートウェイでのプログラムIDの下に登録されます。SAPGUIでは、接続タイプTと登録モードを使用して、トランザクションSM59で宛先を定義する必要があります。さらに、このエントリには、RFCサーバー・プログラムが登録されたSAPゲートウェイに関する情報が含まれている必要があります。 |
ゲートウェイ・サーバーが特定のサーバー・インスタンスへの接続を備え、また別のサーバー・インスタンスがそれ自体をゲートウェイに提示する場合、ゲートウェイは接続を提供し、ロード・バランシング・モードの機能を開始します。ゲートウェイは、独自のアルゴリズムを使用して、要望と総処理時間に応じて、各サーバーに各種のメッセージを送信します。このため、スキーマとアプリケーションによってメッセージを有効にするとき、予測できない結果が生じるおそれがあります。
単一のSAPプログラムIDを使用してOracleで複数のイベントを構成するとき、SAPはイベント・データのロード・バランシングを行います。たとえば、複数のRemote Function CallやBAPIが同じプログラムID (ORACLETDSなど)を使用し、このプログラムIDで複数のSAPリスナーが構成されていない場合、SAPは1つのリクエストを1つのリスナーに送信し、次にこれを繰り返します。SAPゲートウェイ・サーバーにはロード・バランシング・アルゴリズムが存在します。このメカニズムは、SAPのアプリケーション開発に独自のメカニズムであり、接続の総合スループットや待ち状態の回数などを比較することで機能します。1つの接続で9つのメッセージを受信でき、もう1つの接続で1つのメッセージを受信できます。9つのメッセージのうちの5つがスキーマ検証で拒絶され、別の接続で1つのメッセージがスキーマ検証で拒絶された場合、SAPイベント・ハンドリングのメッセージが消失したと考えられます。
サーバーでの(SAPからアダプタに到着する)ロード・バランシング状況は、アダプタの複数インスタンスをSAPシステムに接続することで処理されます。次にSAPシステムによって接続のロード・バランシングを行います。
SAP RFCアウトバウンドのアウトライン
RFC宛先を作成します(SM59経由)。
宛先名を入力します。
登録済みプログラムIDを入力します。
MDMP & Unicodeタブで、「Unicode」オプションが選択されていることを確認します。
Oracle BPEL/Mediatorを起動します。
BPELまたはMediatorチャネルのステップbから同じ登録済みプログラムID値を入力します。
チャネルを起動します。
SAPでテストボタンを使用して接続をテストします。
SAP RFCメッセージをシミュレートします(SE37経由)。
ABAPワークベンチ認可が必要です。
「宛先」フィールドにステップ1aからのRFC宛先名を入力します。
「関数」フィールドに有効なSAP RFC関数名を入力します。
関数のパラメータにデータを入力します。
「実行」(時計)ボタンをクリックします。
データがBPELチャネルに到着します。
SAP IDocイベント
IDocをSAPから受信できるようにするには、アプリケーション・エクスプローラを使用してOracle Application Adapter for SAP R/3のチャネルを構成する必要があります。また、SAPアプリケーション・サーバーに対する構成も必要です。
RFC宛先を作成するか(SM59経由)、あるいは前のセクションで定義された宛先と同じ宛先を使用します(SAP RFCアウトバウンドのアウトライン)。
宛先名を入力します。
登録済みプログラムIDを入力します。
MDMP & Unicodeタブで、「Unicode」オプションが選択されていることを確認します。
Oracle BPEL/Mediatorを起動します。
BPELまたはMediatorチャネルのステップbから同じ登録済みプログラムID値を入力します。
チャネルを起動します。
SAPでテストボタンを使用して接続をテストします。
「論理システムの構成」で説明したように、論理システムを作成または使用します。
「論理システム用の配信モデルの構成」で説明したように、配信モデルを定義または使用します。
トランザクションWE21を経由してSAPトランザクションRFCポートを作成します。
トランザクションWE20を経由してSAPアウトバウンド・パートナ・プロファイルを作成します。
SAP R/3システムで、SAP R/3イベント・アダプタに次のコールまたはインタフェースを発行できるようにするには、RFC宛先の下でプログラムIDを登録する必要があります。
Remote Function Call (RFC)
Business Application Programming Interface (BAPI) - BAPIには外部イベントはありません。RFCフォームを使用してください。
Intermediate Document (IDoc)
RFC宛先は、プログラムIDをマスキングして、ターゲット・システムへのイベントの転送に使用する記号名(ORACLETDSなど)です。プログラムIDは、SAP GUIおよびイベント・アダプタで構成されます。
プログラムIDの登録
プログラムIDを登録するには、以下の手順を実行します。
SAP GUIを起動してSAP R/3システムにログインします。
「ツール」、「管理」、「ネットワーク」の順に選択、RFC宛先を選択します。
SM59<トランザクションを実行します。
図A-26に示すように、RFC接続の構成ウィンドウが表示されます。
Select TCP/IP接続を選択して作成(白紙のアイコン)をクリックします。
図A-27に示すように、RFC宛先ウィンドウが表示されます。
次の情報を入力します。
RFC宛先フィールドに、名前(ORACLETDSなど)を入力します。
このフィールドの値は、大/小文字が区別されます。送信プログラムの中で大/小文字を合わせてください。
「接続タイプ」フィールドに、宛先タイプTCP/IPを表すTを入力します。
「説明」フィールドに、簡単な説明を入力します。
ツール・バーから「保存」アイコン(ディスク)をクリックするか、トップ・メニュー・バーから「接続」、「保存」を順に選択します。
ウィンドウがリフレッシュされ、第2のパネルに技術設定タブが強調表示されます。
登録済みサーバー・プログラムボタンを即座にクリックします。
画面が再びリフレッシュされます。
大/小文字を区別したプログラムIDを入力します。これは、アダプタ・チャネルでの名前と同じ名前に一致させる必要があります。
ツール・バーから「保存」アイコン(ディスク)をクリックするか、トップ・メニュー・バーから「接続」、「保存」を順に選択します。
MDMP & Unicodeタブを選択し、「Unicode」ボタンをクリックします。
ツール・バーから「保存」アイコン(ディスク)をクリックするか、トップ・メニュー・バーから「接続」、「保存」を順に選択します。
これで、RFC宛先とプログラムIDが定義されました。いずれのRemote Function Call (RFC)もコール関数APIの宛先パラメータを介してサーバーに送信することができます。これは逆呼び出しになるため、関数のデータはマーシャルしてアダプタに送信する必要があります。
構成のテスト
構成をテストするには、以下の手順を実行します。
Oracle Application Adapter for SAP R/3の「BPELプロセス - チャネル」にプログラムIDを入力します。
SAP GUIに移行してSE37に移動します。
ABAPワークベンチ認可が必要です。
図A-28に示すように、有効な関数名を入力して「テスト実行」(ツール)アイコンをクリックします。
図A-29に示すように、関数モジュールのテスト: 初期画面ウィンドウが表示されます。
RFC宛先の名前および任意のデータを入力し、「実行」(時計)アイコンをクリックします。
これは逆呼び出しであるため、アダプタに送信するためには、すべてのデータを関数に渡す必要があります。図A-30に示すように、成功すれば、実行時間が表示されます。最初の実行は常に最も長くなり、その後の実行は早くなります。
同期RFCコール
同期RFCコールは、SAPサイドでの非同期と同じように定義されます。アダプタ・サイドでは、コールのモードとして"リクエスト_レスポンス"が選択されていることを確認してください。これが選択されていない場合は、SAPの配信データを取り込むプロセスがこれを処理し、関数書式でSAPに返します。書式エラーがあれば、直ちにリクエストが終了します。例を(擬似コードで)示します。
関数: MY_COMPANY_GETLIST DESTINATION 'ORACLETDS'
tables mycompanies field1: name(20) field2: company(20)
同期のGet Listコールは、空の表mycompaniesをBPELサーバーに渡し、SAPは待機します。BPEL編成には、次のSQLステートメントを備えたオブジェクトが含まれます。
select name(20), company(20) into mycompanies where country eq us
SQLステートメントは、Oracleデータベース上で実行され、結果セットは、編成内の割り当てステートメントによって返されて、mycompanies表に渡されます。プロセス全体にわたってSAPアプリケーションが待機していること、またSAPサーバーのオンライン・プロセスは最大時間となる可能性があることを忘れないでください。この時点でプロセスはSAPによって自動的に終了されます。
関数は、同期コールを介してSAPに戻され、表はコーリング・プロセスにデータを返します。
実行時間が接続プールの実行時間よりも長くなれば、タイムアウトが生じます。タイプ、長さ、または小数点の位置については、書式の例外が生じる可能性があります。
SAP R/3イベント・アダプタは、SAP R/3からIDoc (Intermediate Documents)を受信します。SAP R/3システムを構成してSAP R/3イベント・アダプタにIDocを送信するには、ALE (Application Link Embedding)構成を使用して以下を実行します。
SAP GUIでプログラムIDを登録します。
ポートを定義します。
論理システムを作成します。
パートナ・プロファイルを作成します。
パートナとメッセージ・タイプについての配信モデルを作成します。
SAP R/3イベント・アダプタをテストします。
ポートは、メッセージを送信する場所を特定します。Oracle Application Adapter for SAP R/3で使われるポート・タイプは、トランザクションRFCポートです。ALEポートを定義してこれをRFC宛先にリンクすることにより、メッセージ実行プロセスの経路が構築されます。
ポートの定義
ターゲットを定義するには、以下の手順を実行します。
ALE構成で、「ツール」、ビジネス通信、IDocs基準、IDoc、ポート定義を順に選択します。
WE21<トランザクションも実行できます。
図A-31に示すように、IDoc処理のポートウィンドウが表示されます。
「ポート」の下の左ペインで、トランザクションRFCを選択して作成(白紙のアイコン)をクリックします。
ポート名の生成をクリックします。
システムはポート名を生成します。
このポート(通常4)を通じて送信するIDocのバージョンを入力します。
作成されるRFC宛先の名前をタイプまたは選択するか、図A-32に示すように、センタクリストに最初の数文字とアスタリスクを入力します。
セッションを保存して、生成されたRFCポートを書き留めます。
|
注意: 以前に定義した論理システムを再使用する場合は、この項を省略することができます。 |
論理システムは、メッセージの送信者または受信者のパーティに関する構成情報のためのコンテナ・オブジェクトです。これが論理システムである理由は、接続情報が格納されず、エンド・ポイントが処理できるメッセージとメッセージを処理する方法についての情報だけが格納されているからです。
SAPトランザクション・ショートカット
/n - 現在のトランザクションを終了し、新しいトランザクションを直ちに開きます。
/o - 現在のトランザクションのコンテキストを維持し、新しいウィンドウで新しいトランザクションを開きます。
論理システムの定義
論理システムの定義は、「カスタマイズのためのSAP実装ガイド(IMG)」にエントリを構築することで作成されます。
ALEは、SAP ERP Application Link Enablementシステムであるため、/nSALEトランザクションを使用してALE用のIMGまで移動します。
図A-33に示すように、SALEトランザクションに移動します。
図A-34に示すように、IMGの表示ウィンドウにALEの構成ツリーが表示されます。
次のステップを実行します:
「基本設定」ノードを展開します。
Expand 論理システムを展開します。
論理システムの定義をクリックします。
SAP R/3ユーザーの場合、画面がわずかに異なる可能性があり、特別なノードである送受信システムを展開します。
図A-35に示すように、「注意: 表がクロスクライアントです」メッセージが表示されます。
このメッセージは、論理システム内のカスタマイズ・データの変更がSAP ERPサーバーのすべてのユーザーに適用されることを通知するために表示されます。これは、特にログオン・クライアントに限定されるほとんどのアプリケーション・データとは異なります。論理システムのエントリに変更を加えないでください。新しい情報のみを追加してください。正しい権限を備えたSAPログオンIDを使用してください。
緑色のチェック・マークをクリックして続行します。
図A-36に示すように、"論理システム"ビューの変更ウィンドウが表示されます。
新規エントリボタンをクリックします。
図A-37に示すように、新規エントリ: 追加エントリの概要ウィンドウが表示されます。
論理システム列に論理システム(ORACLETDSなど)を入力し、名前列に説明を記載します。
|
注意: フィールドは黄色で強調表示されるので、必須フィールドであることがわかります。 |
図A-38に示すように、トップ・メニュー・バーの「保存」アイコンをクリックします。
ワークベンチ・リクエストのプロンプトダイアログが表示されます。
|
注意: システムの使用状況によっては、最終ワークベンチのリクエスト番号がダイアログに表示されますが、これを使用せずに、次のステップに進んでください。 |
図A-39に示すように、「新規リクエスト」アイコンをクリックして新しいリクエストを作成します。
リクエスト・システムでエントリの説明を入力します。残りのフィールドは、自動的に記入されるので変更する必要はありません。
ワークベンチ・リクエストのプロンプトダイアログが再び表示され、新規リクエスト番号には、ワークベンチで最後に作成されたリクエスト番号が記入されます。これを使用しないでください。図A-40に示すように、チェック・マークをクリックして新規リクエスト番号を作成します。
図A-41に示すように、論理システム・エントリウィンドウが新しい論理システム情報でリフレッシュされます。新しい論理システムは青色で強調表示され、このステップが正常に完了したことを示します。
配信モデルには、送信者論理システムと受信者論理システム、および送受信されるメッセージのタイプが含まれます。指定の送信者または受信者に有効な配信モデルがない場合、メッセージは処理されず、エラー場所に転送されます。SAP BAPIオブジェクトやフィルタリングなど、配信モデルの高度なトピックについては、SAPのドキュメントを参照してください。
配信モデルの定義
配信モデルを定義するには、以下の手順を実行します。
図A-42に示すように、bd64トランザクションを実行します。
配信モデルの表示ウィンドウがデフォルトの表示モードで表示されます。これは、図A-43に示すように、現在のモデル・ビューのエントリを示します。
ツリーを展開して各モデル・ビューのエントリを表示します。
アイテムを追加するには、トランザクションを"モード変更"に切り替える必要があります。
図A-44に示すように、配信モデルをクリックし、処理モードの切り替えを選択します。
図A-45に示すように、画面はリフレッシュされて、モデル・ビューのウィンドウは配信モデルの変更に切り替わります。
利用可能なメニュー・ボタンから、モデル・ビューの作成を選択します。
図A-46に示すように、モデル・ビューの作成」ダイアログが表示されます。
「短縮テキスト」フィールドにモデル・ビューの名前を入力し、技術名フィールドに名前を入力します。これは説明としての役割も果たします。
文字Zで始まる名前を使用することをお薦めします。SAPはシステム更新の場合にこれらの名前を上書きしないからです。これは、モデル・ビューの名前のみです。
緑色のチェック・マークのアイコンをクリックして情報を入力します。
画面はリフレッシュされて、配信モデルの変更に戻ります。図A-47に示すように、構成した配信モデルが新たにリストに加えられます。
モデル・ビューは、「保存」アイコンをクリックするまで、トランザクションの一時記憶域にあります(明るい色でエントリを表示)。システム接続が消失またはタイム・アウトになると、エントリは消失します。変更内容が失われないようにするため、配信モデルの構成プロセスの間、各ダイアログの後に変更を保存することをお薦めします。
以前に定義したエントリにカーソルを置きます。
図A-48に示すように、これでエントリは強調表示されます。
中央のメニュー・バーで、メッセージ・タイプの追加ボタンをクリックします。
メッセージ・タイプの追加ダイアログが表示されます。
ALE中央インスタンス発信者を入力します。
この詳細は、SAP管理者に問い合せてください。
「受信者」フィールドに、受信者(ORACLETDSなど)を入力します。
有効なメッセージ・タイプを入力します。
図A-49に示すように、このパートナ・シナリオにおいて、アウトバウンドの各メッセージ・タイプごとにこの手順を繰り返します。
|
注意: 以前に定義したパートナ・プロファイルを再使用する場合は、この項を省略することができます。 |
パートナ・プロファイルは、各論理システムごとに、処理するメッセージとメッセージの処理方法を定義します。これにより、パートナの詳細処理を柔軟に構成することが可能となります。各メッセージ・タイプは、パートナ・プロファイルに1つだけ入力することが可能です。パートナ・プロファイルを定義するには、以下の手順を実行します。
図A-50に示すように、we20トランザクションを実行します。
図A-51に示すように、パートナ・プロファイルウィンドウが表示されます。
パートナ・タイプLSを選択して、中央メニュー・バーの白いアイコンをクリックします。トップ・メニューから「作成」を選択することもできます。
図A-52に示すように、画面の右側が、パートナ・プロファイルの未記入フォームに変わります。。
パートナ番号フィールドに、論理システムの名前を入力し(ORACLETDSなど)、「保存」アイコンをクリックします。
図A-53に示すように、画面は新しいプロファイルによって変更されます。
「メッセージ・タイプフィールドに、メッセージ・タイプを入力します。
受信者ポートフィールドにポート番号を入力します。
直ちにIDocを送信ボタンを選択するか、IDocの収集を選択してバッチ・サイズを指定し、さらにbd87を使用してIDocをリリースして処理できるようにします。
基本タイプを入力します(MATMASを表すMATMAS05など)。
「保存」アイコンをクリックします。
SAPサーバーでは、BD12トランザクションにより、マスター・データIDocを任意の論理システム(たとえば、イベント・アダプタ)に送信できるようになります。
SAP R/3 ALE構成のテスト
SAP R/3 Application Link Embedding (ALE)構成をテストするには、以下の手順を実行します。
図A-54に示すように、顧客送信ウィンドウで、「出力タイプ」フィールドにIDocメッセージ・タイプ(DEBMASなど)を入力します。
論理システムフィールドに、論理システム(ORACLETDSなど)を入力します。
「実行」をクリックします。
SAP R/3イベント・アダプタは、XML形式でIDocを受信します。イベント・アダプタからのレスポンスは想定されていません。
図A-55に示すように、確認メッセージが表示されます。
同数の通信IDocの生成も必要となります。IDocはすぐにアダプタ・サーバーに表示されます。IDocが表示されない場合は、以下を確認してください。
パートナ・プロファイルでIDocの収集オプションが選択されていること(bd87に移動してリリース)
同じプログラムIDを公開してるサーバーがないこと
SAP IDocイベント
IDocをSAPから受信できるようにするには、アプリケーション・エクスプローラを使用してOracle Application Adapter for SAP R/3のチャネルを構成する必要があります。また、SAPアプリケーション・サーバーに対する構成も必要です。
RFC宛先を作成するか(SM59経由)、あるいは前のセクションで定義された宛先と同じ宛先を使用します(SAP RFCアウトバウンドのアウトライン)。
宛先名を入力します。
登録済みプログラムIDを入力します。
MDMP & Unicodeタブで、「Unicode」オプションが選択されていることを確認します。
Oracle BPEL/Mediatorを起動します。
BPELまたはMediatorチャネルのステップbから同じ登録済みプログラムID値を入力します。
チャネルを起動します。
SAPでテストボタンを使用して接続をテストします。
「論理システムの構成」で説明したように、論理システムを作成または使用します。
「論理システム用の配信モデルの構成」で説明したように、配信モデルを定義または使用します。
トランザクションWE21を経由してSAPトランザクションRFCポートを作成します。
トランザクションWE20を経由してSAPアウトバウンド・パートナ・プロファイルを作成します。
