| Oracle Application Server Adapter for MySAP ERPユーザーズ・ガイド 10g リリース3（10.1.3.4.0） B53279-01 |
|
 戻る |
 次へ |
| Oracle Application Server Adapter for MySAP ERPユーザーズ・ガイド 10g リリース3（10.1.3.4.0） B53279-01 |
|
戻る |
次へ |
インバウンド（クライアント）処理の間は、IDocがインタフェースに転送されてMySAP ERPシステムに格納されます。ドキュメント・データは、第2段階で、あるいはワークフローの途中でも生成されます。
MySAP ERP内のアウトバウンド処理には、イベント処理が伴います。 MySAP ERPのイベントは、オブジェクトにおけるステータス変更の発生として定義されます。イベントは、関連するステータス変更の発生時に作成されます。 次のトピックでは、MySAP ERPのインバウンドおよびアウトバウンド処理を有効にする方法を説明します。
MySAP ERPのインバウンド処理には、IDocをERP Systemポート経由でIDocインタフェースへ転送するためのアップストリーム・システムが必要です。このため、インバウンド・パートナ・プロファイルにポートを指定する必要はなく、IDocインタフェースでアップストリーム・システムをポートとして認識すればすみます。ポート定義（アップストリーム・システムに対する一意のIDを提供）がそのポートに対して使用可能になっている必要があります。このポートの技術パラメータは、アップストリーム・システムにより上書きできます（通常は上書きされます）。
アップストリーム・システムが認識された場合、IDocはデータベースに保存されます。パートナが、対応するメッセージとともにパートナ・プロファイル内に定義されている場合はIDocの処理が続行します。この処理は第2段階で独立して実行されます。これにより、外部システムが迅速かつ確実に（自動的に）データを取得できるようになります。
インバウンドIDoc処理用にMySAP ERPを構成するには、次の手順を実行する必要があります。
論理システムの構成
配布モデルの構成
インバウンド・パートナ・プロファイルの定義
どの配布環境においても、参加している各システムには混乱を避けるために一意のIDが必要です。 MySAP ERPでは論理システムの名前が一意のIDとして使用されます。この名前は、MySAP ERPシステム内の1つのクライアントに明示的に割り当てられています。
論理システムの定義
「sale」トランザクションを実行します。
次の手順を実行します。
「Sending and Receiving Systems」を開きます。
「Logical Systems」を開きます。
「Define Logical System」を選択します。
「IMG - Activity」アイコンをクリックします。
メッセージ・ウィンドウが表示されます。クライアント間にまたがる表であることをが示されます。
チェック・マークのアイコンをクリックして操作を続けます。
「Change View "Logical Systems": Overview」ウィンドウが表示されます。
「New entries」をクリックします。
「New Entries: Overview of Added Entries」ウィンドウが表示されます。
「Save」をクリックします。
「Prompt for Workbench request」ダイアログ・ボックスが表示されます。
「Create Request」アイコンをクリックします。
「Create Request」ダイアログ・ボックスが表示されます。
リクエストの名前と説明を入力して、「Save」をクリックします。
構成した論理システム（ORACLETDSなど）がリストに追加されています。
配布モデルは、論理システム間のALEメッセージ・フローを記述するために使用されます。ビジネス・オブジェクトは一意の配布モデルに従って接続中の受信者に配布されますが、この配布モデルには、関連するビジネス・オブジェクトのタイプによって様々な複雑さの規則が含まれる可能性があります。
配布モデルの定義
配布モデルを定義する手順は次のとおりです。
「bd64」トランザクションを実行します。
「Display Distribution Model」ウィンドウが表示されます。
メニュー・バーから「Distribution Model」をクリックします。
「Switch processing mode」を選択します。
「Display Distribution Model」ウィンドウが「Change Distribution Model」に切り替わります。
「Create model view」をクリックします。
「Create Model View」ダイアログ・ボックスが表示されます。
「Short text」フィールドにモデル・ビューの名前を、「Technical name」フィールドに名前を入力します。この名前が説明にもなります。
チェック・マークのアイコンをクリックして情報を入力します。
メインの「Change Distribution Model」ウィンドウに戻ります。構成した配布モデルがリストに追加されています。
「Add message type」をクリックします。
「Add Message Type」ダイアログ・ボックスが表示されます。
次の手順を実行します。
「Sender」および「Receiver」フィールドに、構成した論理システム（ORACLETDSなど）を入力します。
各フィールドの右横のアイコンをクリックし、論理システムのリストから参照できます。
「Message type」フィールドに、使用するメッセージ・タイプ（MATMASなど）を入力します。
各フィールドの右横のアイコンをクリックし、使用可能なメッセージ・タイプのリストから参照できます。
チェック・マークのアイコンをクリックして情報を入力します。
メインの「Change Distribution Model」ウィンドウに戻ります。
パートナ・プロファイルはデータ交換の前提条件です。 これには、誰がどのポートを使用してMySAP ERPシステムとメッセージを交換できるかという定義が関係します。
パートナ・プロファイルの定義
パートナ・プロファイルを定義する手順は次のとおりです。
「we20」トランザクションを実行します。
「Partner profiles」ウィンドウが表示されます。
左ペインで「Partner type LS」を開き、構成済の論理システム（ORACLETDSなど）をリストから選択します。
右ペインでは、「Partn.number」フィールドが論理システムの名前を示しています。
「Save」をクリックします。
「Inbound」パラメータ表から「Create inbound parameter」アイコンをクリックします。
「Partner profiles: Inbound parameters」ウィンドウが表示されます。
「Message type」フィールドに、使用するメッセージ・タイプ（MATMASなど）を入力します。
各フィールドの右横のアイコンをクリックし、使用可能なメッセージ・タイプのリストから参照できます。
「Inbound options」タブがデフォルトで選択されます。
「Process code」フィールドに、使用するプロセス・コード（MATMなど）を入力します。
各フィールドの右横のアイコンをクリックし、使用可能なプロセス・コードのリストから参照できます。
「Processing by function module」領域で、次のオプションの1つを選択します。
Trigger by background program
この場合、アダプタはIDocをMySAP ERPデータベースに書き込み、この処理は即時に実行されます。
Trigger immediately
この場合、アダプタはMySAP ERPシステムがIDocを処理するのを待機します。これには1〜15分程度かかります。
「Save」をクリックします。
イベント作成は、ユーザーが、またはMySAP ERPによって実装する必要があります。イベントは、特定のアプリケーション・プログラム（イベント・クリエータ）で作成されてシステム全体に公開されます。任意の数の受信者が、独自のレスポンス・メカニズムでイベントに応答できます。イベントは、通常、オブジェクト型のコンポーネントとして定義されます。
MySAP ERPの疑似イベントは、MySAP ERPイベント・マネージャによっては処理されませんが、ABAPプログラムまたはRemote Function Callにより（Destination parameterを使用して）呼び出せるイベントです。
次のトピックでは、MySAP ERPとMySAP ERPイベント処理に関連する特定の用語を一覧および定義します。
クライアントおよびサーバー・プログラム
非MySAP ERPシステム用のRFCプログラムは、RFC通信においてコール元プログラムまたはコールされるプログラムのどちらとしても機能できます。RFCプログラムには2つのタイプがあります。
RFCクライアント
RFCサーバー
RFCクライアントは、RFCをコールしてRFCサーバーにより提供されている関数を実行するインスタンスです。リモートから呼び出せる関数はRFC関数と呼ばれ、RFC APIにより提供される関数はRFCコールと呼ばれます。
MySAP ERP Gateway
MySAP ERP Gatewayは、セキュリティで保護されたアプリケーション・サーバーです。 事前にMySAP ERPのプレゼンテーション・クライアントから登録されていないかぎり、接続は受け入れられません。サーバー接続は自分自身をGatewayに登録し、プログラム識別子を公開します。プログラム識別子が登録済プログラムIDのリストにある場合、Gatewayサーバーがサーバーへの接続を提供し、これによって接続が受け入れられます。 このプログラムIDは、次にMySAP ERP内のRFC宛先とリンクされ、これによってMySAP ERP関数モジュールとALEドキュメント（IDocまたはBAPI IDoc）が宛先にルーティングできるようになります。 RFC宛先は、MySAP ERPユーザーにプログラムIDをマスクするタグとして機能します。
RFCサーバー・プログラムは、MySAP ERPゲートウェイに登録して、着信するRFCコール・リクエストを待機できます。 RFCサーバー・プログラムは、プログラムIDに基づいてMySAP ERPゲートウェイに自分自身を登録します。特定のMySAP ERPシステムに対して登録するわけではありません。
SAPGUIでは、宛先はトランザクション「SM59」で接続タイプ「T」と「Register Mode」を使用して定義する必要があります。 さらに、このエントリにはRFCサーバー・プログラムが登録されているMySAP ERPゲートウェイに関する情報が含まれている必要があります。
プログラムIDとロード・バランシング
Gateway Serverに特定のサーバー・インスタンスとの接続があり、別のサーバー・インスタンスからゲートウェイへの接続があった場合、ゲートウェイは接続を提供後、ロード・バランシング・モードで機能を開始します。固有のアルゴリズムを使用することにより、Gatewayは各サーバーに対して要求および総処理時間に応じて異なるメッセージを送信します。これにより、メッセージがスキーマおよびアプリケーションにより検証されたときに予測できない結果が生じる可能性があります。
Oracle Application Serverに単一のMySAP ERPプログラムIDを使用する複数のイベントを構成すると、MySAP ERPはイベント・データのロード・バランシングを実行します。 たとえば、複数のリモート・ファンクション・コールまたはBAPIで同一のプログラムID（ORACLETDSなど）を使用し、複数のMySAP ERPリスナーがこのプログラムIDで構成されている場合、MySAP ERPは1つのリクエストを1つのリスナーに送信し、次のリクエストを別のリスナーという順に送信します。
ロード・バランシング・アルゴリズムはMySAP ERP Gateway Serverにあります。 このメカニズムはMySAP ERPアプリケーション開発に固有のもので、接続の合計スループットや待機状態の回数などを比較することで機能します。 ある接続が9個のメッセージを受信し、2番目の接続が1個のメッセージを受信する場合があります。 9個のうちの5個のメッセージがスキーマ検証で拒否され、もう一方の接続で1個のメッセージがスキーマ検証で拒否された場合、MySAP ERPイベント処理メッセージが失われたことが疑われます。
サーバー（MySAP ERPからアダプタへのインバウンド）環境でのロード・バランシングは、複数のアダプタ・インスタンスをMySAP ERPシステムに接続することで処理されます。 その後、MySAP ERPシステムは接続のロード・バランシングを実行します。このパフォーマンスはチューニングできません。
クライアント（アダプタからMySAP ERPへのアウトバンド）環境でのロード・バランシングは、MySAP ERPアプリケーション設計によってのみ処理されます。システムでメッセージ・サーバーがサポートされている場合は、クライアント環境でロード・バランシングを実行できます。アプリケーション・サーバーが1つのみの場合は、アプリケーション・サーバーのチューニング（許容最大接続数や接続時間の制限など）以外のロード・バランシングは実行できません。
MySAP ERPシステムのデフォルト制限は、100のRFC（通信）またはアダプタ・ユーザーです。 各ユーザーは、MySAP ERPシステムのアプリケーション・サーバーでは2MB以上のメモリーを使用し、アダプタではワークロードに応じて同程度のメモリーを使用します。
接続プーリング
接続プールは、特定の宛先へのクライアント接続の集合です。プールは、指定されたリモート・システムへの新規接続を作成したり、すでに存在する接続を戻すことができます。また、必要がなくなったときに接続を元のプールに戻す方法も提供します。
接続プールでは、使用されなくなってシステム・リソースの節約のために閉じることができる接続をチェックできます。 プールが接続をチェックするまでの時間、および接続がタイムアウトするまでの時間を、コール元のアプリケーションによって構成できます。
プールは常に1つのユーザーIDおよびパスワードにバインドされるため、このプールを介する接続もすべてこれらの資格証明を使用します。 MySAP ERP接続は常にMySAP ERPユーザーIDとMySAP ERPクライアント番号にバインドされます。
1に設定されたプール・サイズでログオンした場合、接続プールは作成されません（1ユーザーID – 1プロセス・スレッド）。1より大きいプール・サイズでログオンした場合、ユーザーが指定したnサイズのプールが作成されます。
接続プールの詳細は、SAP JCO APIドキュメントを参照してください。
MySAP ERPシステムが次のコールまたはインタフェースをMySAP ERPイベント・アダプタへ発行できるようにするには、プログラムIDをRFC宛先に登録する必要があります。
Business Application Programming Interfaces（BAPI）
RFC宛先は、プログラムIDを隠してターゲット・システムにイベントを送るために使用される記号名（ORACLETDSなど）です。プログラムIDは、SAPGUIとイベント・アダプタの両方で構成されます。
プログラムIDの登録
「Tools」→「Administration」→「Network」→「RFC destination」を選択します。
「SM59」トランザクションを実行します。
「Display and maintain RFC destinations」ウィンドウが表示されます。
「TCP/IP connections」を選択して「Create」をクリックします。
「RFC Destination」ウィンドウが表示されます。
次の情報を入力します。
「RFC destination」フィールドに、名前（ORACLETDSなど）を入力します。
このフィールドに入力する値は、大/小文字が区別されます。
「Connection type」フィールドに宛先タイプTCP/IPを表すTを入力します。
「Description」フィールドに簡潔な説明を入力します。
ツールバーから「Save」をクリックするか、「Destination」メニューから「Save」を選択します。
「RFC Destination ORACLETDS」ウィンドウが表示されます。
次の手順を実行します。
ツールバーから「Save」をクリックするか、「Destination」メニューから「Save」を選択します。
イベント・アダプタが実行中であることを確認します。
MySAP ERPシステムとOracleAS Adapter for MySAP ERPが通信中であることを確認します。
SAPサーバーでは、「SE37」トランザクションによりRFC（Remote Function Call）またはBAPI（Business Application Programming Interface）をRFC宛先に送信できます。RFC宛先の詳細は、「SAPGUIでのプログラムIDの登録」を参照してください。
RFCまたはBAPIの手動送信によるMySAP ERPイベント・アダプタのテスト
MySAP ERPイベント・アダプタをテストする手順は次のとおりです。
「Function Builder」で関数モジュール（RFC_CUSTOMER_GETなど）を選択します。
単一のテストを選択するには、[F8]を押して「Single Test」アイコンをクリックするか、「Function module」→「Test」→「Single Test」を選択します。
特定のRFCモジュールに対する入力データ（AB*など）を入力します。
実行するために[F8]を押します。
「Test Function Module: Initial Screen」ウィンドウが表示されます。
SAP GUIにデータを入力し、「Execute」をクリックします。
関数名と入力データがRFC経由で転送され、SAPGUIで入力したパラメータを使用してOracle Application Server上にXML文書が作成されます。
MySAP ERPイベント・アダプタはIDoc（Intermediate Documents）をMySAP ERPから受信します。 MySAP ERPシステムを構成してMySAP ERPイベント・アダプタにIDocを送信するには、ALE（Application Link Embedding）構成を使用して次を実行します。
ポートはメッセージの送信先を示します。このポートは、事前にRFC宛先が作成されている場合にのみ使用できます。
ポートの定義
ポートを定義する手順は次のとおりです。
「ALE configuration」で、「Tools」→「Business Communications」→「IDocs Basis」→「IDoc」→「Port Definition」を選択します。
「WE21」トランザクションを実行することもできます。
「Creating a tRFC port」ウィンドウが表示されます。
左ペインの「Ports」の下にある「Transactional RFC」を選択して「Create」をクリックします。
「Generate port name」を選択します。
システムによりポート名が生成されます。
このポート経由で送信するIDocのバージョンを入力します。
作成済の宛先（ORACLETDSなど）をクリックします。
セッションを保存して、システムが生成したRFCポートを書き留めておきます。
パートナのタイプの1つが論理システムです。論理システムは1つ以上のRFC宛先を管理します。
論理システムの作成
ORACLETDSという論理システムを作成する手順は次のとおりです。
「ALE configuration」で、「Area Menu」の選択肢の「SALE」トランザクションに入ります。
「SAP Reference IMG」を選択します。
次のノードを開きます。「Basis Components」→「Application Link Enabling (ALE)」→「Sending and Receiving Systems」→「Logical Systems」→「Define Logical System」
「Define Logical System」の横のチェック・マークをクリックします。
「Change View "Logical Systems": Overview」ウィンドウに、論理システムとその名前がリスト表示されます。
「New entries」をクリックします。
新規論理システムの「Log.System」列と「Name」列が表示された「New Entries: Overview of Added Entries」ウィンドウが表示されます。
「Log System」に対してエントリ（ORACLETDSなど）を入力します。
「Name」列にパートナ・プロファイルの名前（説明）を入力します。
「Save」をクリックしてセッションを保存します。
パートナ・プロファイルは、IDocインタフェースを使用して取引先パートナとデータを電子交換するためのパラメータの定義です。IDocインタフェースを使用してパートナと通信するには、パートナ・プロファイルを作成する必要があります。
パートナ・プロファイルの作成
パートナ・プロファイルを作成する手順は次のとおりです。
SAP GUIで、「Tools」→「Business Communication」→「IDoc Basis」→「Partner profile」を選択します。
「WE21」トランザクションを実行することもできます。
「Partner profiles: Outbound parameters」ウィンドウに、パートナ・プロファイルの詳細を指定するためのフィールドが表示されます。
次の手順を実行します。
「Partner type」で「LS」（Logical system）を選択します。
[F5]（Create）を押します。
「Type」にはUSERを入力します。
「Agent」には、現在のユーザーIDを入力するか、別のエージェント・タイプを選択してもかまいません。
「Outbound parameters」というテーブル・コントロールの下で、「Create outbound parameter」を選択します。
「Partn.type」は「LS」で、「Message type」は「DEBMAS」です。これがIDocドキュメント・タイプです。
「Partn.funct」は空白のままにします。
「Outbound options」タブをクリックします。
次の情報を入力します。
必要なパフォーマンス要件に応じて、「Transfer IDoc Immed」または「Collect IDocs」をクリックします。
「IDoc」にはメッセージ・タイプ（DEBMASなど）を入力します。
受信者ポート（A000000036など）を入力します。
「Save」をクリックしてセッションを保存します。
「Partner profiles」サマリー・ウィンドウが表示されます。作成した論理システムの情報が表示されます。
インバウンド処理（サービス・モード）中に任意のプラットフォーム上で収集されたIDocを使用する場合、「DOCNUM」フィールドに各IDocの一意のドキュメント番号が指定されていないと、システムは収集された各IDocファイルのヘッダー・レコードに対するIDocを作成して各IDocのデータを複製します。
「DOCNUM」フィールドがEDI_DC40構造に含まれていることと、収集されたIDocファイル内の各IDocに一意の連続番号が付いていることを確認します。
指定したパートナおよびメッセージ・タイプに対して配布モデルを作成する必要があります。
配布モデルの作成
ORAMODという配布モデルを作成する手順は次のとおりです。
SAP GUIで、「Tools」→「AcceleratedSAP」→「Customizing」→「Project Management」を選択します。
「BD64」トランザクションを実行することもできます。
「Display Distribution Model」ウィンドウが表示されます。
「Create model view」を選択します。
必要な場合は、処理モードを切り替えて「Distribution Model/Switch Processing Mode」内で編集します。
新規モデル・ビューに対する短いテキスト文字列と技術名を入力します。
「Save」をクリックします。
「Distribution Model Changed」ウィンドウに、配布モデルのツリー構造が表示されます。
次の手順を実行します。
「Distribution Model」ツリーで新規モデル・ビューを選択します。
右側で「Add message type」を選択します。
「Add Message Type」ダイアログ・ボックスが表示されます。 メッセージの送信者と受信者およびメッセージ・タイプを指定するフィールドが表示されます。
次の情報を入力します。
「Sender」フィールドに、MySAP ERPシステムを指す送信者を指定します。この送信者がIDoc（I46_CLI800など）を送信します。
この場合の送信者はSAP 4.6Bシステムです。
「Receiver」フィールドに論理システム（ORACLETDSなど）を指定します。
「Message type」フィールドにIDocのタイプ（DEBMASなど）を指定します。
チェック・マークのアイコンをクリックます。
「Save」をクリックします。
「Change Distribution Model」ウィンドウがに、メッセージ・タイプ（DEBMAS）をI46_CLI800 SAPシステムからORACLETDS論理システムに送信するために使用される新規モデル・ビューが表示されます。
これで論理システムへの接続をテストする準備ができました。
SAPサーバーでは、「BD12」トランザクションによりIDocを任意の論理システム（イベント・アダプタなど）に送信できます。
MySAP ERP ALE構成のテスト
MySAP ERP Application Link Embedding（ALE）構成をテストする手順は次のとおりです。
「Send Customers」ウィンドウで、IDocメッセージ・タイプ（DEBMASなど）を「Output type」フィールドに入力します。
「Logical system」フィールドに論理システム（ORACLETDSなど）を入力します。
「Run」をクリックします。
MySAP ERPイベント・アダプタはXMLフォーマットのIDocを受信します。イベント・アダプタからのレスポンスは想定されていません。
確認ウィンドウが表示されます。
