SAP PI For Beginner

目的

このチュートリアルの目的は、SAPプロセス統合とは何かを理解することです。 このテーマの核心には触れませんが、SAP PIのアーキテクチャとさまざまな機能について説明します。 基本的な機能のみを説明し、このチュートリアルではすべての機能について説明することは避けます。

次に、SAP PIの業界レベルの利用についてのアイデアを提供する一連のケーススタディがあります。 あなたが主題にもっと精通したら、あなたはそれらを解決しようとするべきです。 テストケースは、各レッスンで簡単なものからより複雑なものまで、主題にあなたを連れて行き、主題の全体的なアイデアを与えるように準備されてい

SAP ERPとは何ですか？

大規模または小規模のビジネスでは、これらは、材料管理、販売および流通、財務、人事など、実行しなければならない標準的なビジネス機能です。 業界で利用されている市場には多くのソフトウェアがあります。 ERP上で動作する大規模な小売店、ホテルなどのコンピュータのネットワークに小さな店を訪問した場合、販売請求書を生成する出納機–あなたは最も簡単

エンタープライズリソースプランニングすなわちERPは、ほとんどの企業が生産性とパフォーマンスを向上させるために実装する効果的なアプロー SAP ERPはSAP AGの企業資源の計画、構成の主ビジネス機能を組み込む統合されたソフトウェアの解決である。 基本的な機能、すなわちHR、MM、SD、FICOなどは、SAPのビジネスモジュールと呼ばれています。 SAPは、製品としてそれらを構築し、市場でそれらを販売しています。 ビジネス機能を直接サポートしていないが、プレゼンテーションと統合に利用される二つのモジュールがあります。 前者はEP（エンタープライズポータル）と呼ばれ、後者はPI（プロセス統合）と呼ばれています。 すべてのビジネスモジュールはABAPで開発され、EPとPIは主にJavaで開発されています。 これらのモジュールは実行可能ファイルではありませんが、アプリケーションサーバ、つまりABAPモジュール用のABAP WebアプリケーションサーバとJavaモジュール用のJava Web

主題に飛び込む前に知っておくべき点はほとんどありません。

• SAPは、データ処理におけるシステム、アプリケーション、および製品の略です。

• SAP AGは、ビジネス運営と顧客関係を管理するためのエンタープライズソフトウェアを製造するドイツの多国籍ソフトウェア企業です。 SAP ERPは企業の企業資源の計画、構成の主ビジネス機能を組み込む統合されたソフトウェアの解決である。

• SAP NetWeaver Process Integration(SAP PI)は、Sap enterprise application integration(EAI)ソフトウェアであり、NetWeaver製品グループのコンポーネントであり、企業の内部ソフトウェアおよびシステムと外部当事者のソフ

レガシーシステム

大規模な事業所でSAP ERPを実装している間、すべてのセクションをSAP ERPの下に置くことができないことがわかりました。 ビジネスセクションの多くは、非常に複雑であり、交換することができない可能性があり、独自の独自のツールを持っている可能性があります。 それらはSAPシステムと並行して実行されます。 これらはレガシーシステムと呼ばれます。 その後、SAPシステムとそのような既存の非SAPシステムとの間で統合する必要があります。 これはSAP PIが演劇に入って来るところである。

なぜSAP PIレガシーシステムとは別に、大規模な事業所では、SAP ERPは単一のシステムではなく、CRM、SRM、FICOなどのいくつかの統合システムで構成されています。 このような複雑さに対処するために、SAPは、レガシーシステムの既存の複雑なネットワークに触れることなく、すべてのシステムに単一の統合ポイントを これは、企業の境界の内側と外側のSAPと非SAPアプリケーション間のシームレスなエンドツーエンドの統合を提供するSAPによる強力なミドルウェアです。 SAP PIは、B2BとA2Aの交換をサポートし、同期および非同期のメッセージ交換をサポートし、統合プロセスを設計および実行するためのエンジンを内蔵

SAP PIのアーキテクチャ

SAP PIはハブとスポーク構造で構成されており、スポークは外部システムと接続し、ハブはそれらの間でメッセージを交換します。 送信元システムは送信側システムと呼ばれ、ターゲットシステムは受信側システムと呼ばれます。 PIは単一のコンポーネントではなく、統合シナリオを実装するために柔軟に連携するコンポーネントのコレクションです。 アーキテクチャには、設計時、構成時、および実行時に使用されるコンポーネントが含まれています。

SAP PIをいくつかの領域に分割することができます

1. Integration Server
2. Integration Builder
3. System Landscape
4. Configuration and Monitoring

Integration ServerはSAP PIの中央処理エンジンです。 すべてのメッセージは一貫した方法でここで処理されます。 これは、3つの別々のエンジンで構成されています

1. 統合エンジン
2. アダプタエンジン
3. ビジネスプロセスエンジン

統合エンジンは、ハブとア 業務プロセスエンジンについては、後で説明します。

Integration Builderは、統合オブジェクトにアクセスして編集するためのクライアントサーバフレームワークで、二つの関連ツールで構成されています:

1. Enterprise Service Repository–シナリオで使用されるオブジェクトを設計および開発する
2. 統合ディレクトリ-シナリオを開発するためにESRオブジェクトを設定する

二つをまとめて、一般的にシナリオと呼ばれる統合プロセスを構築しました。

システムランドスケープは、データセンター内のソフトウェアとシステムに関する情報の中央リポジトリであり、システムランドスケープの管理を簡素化

設定と監視では、メッセージとアダプタを監視できます。

シングルスタックとデュアルスタック

PIが最初にリリースされたとき、すべてのコンポーネントが同じプラットフォーム上に構築され 統合エンジンとビジネスプロセスエンジンはABAPで構築され、アダプタエンジン、統合ビルダー、SL、CM、マッピングランタイムはJavaで構築されました。 そのため、PIを実行するにはJava環境とABAP環境の両方が必要であり、デュアルスタックと呼ばれます。

ABAPスタック	Javaスタック
統合エンジン ビジネスプロセスエンジン 統合ビルダー	エンタープライズサービスレポジトリ 統合ディレクトリ ランタイムワークベンチ システムランドスケープディレクトリ アダプタエンジン マッピングランタイム

しかし、それ以降のバージョンでは、すべてのコンポーネントはJavaで構築されています。 デュアルスタックコンポーネントの一部は、javaスタック上で動作するように分配されるか、または変更されます。 そのため、PIは実行するためにJava環境のみを必要とし、シングルスタックと呼ばれます。

二つのスタックの間には長所と短所がありますが、このチュートリアルでは説明しません。

統合エンジン

統合エンジンは、中央統合サーバーサービス、すなわちパイプラインステップ-ルーティングとマッピングを担当します。 ソースメッセージ構造がターゲットメッセージ構造と異なる場合、統合エンジンはマッピングランタイムを呼び出し、ソース構造がターゲット構造に変換され マッピングランタイムは、Javaスタックに基づいています。 統合エンジンでは、ABAPスタックに基づくABAPプログラムを変換に使用することもできます。

メッセージは二つのタイプにすることができます

1. 同期–要求-応答部分の両方を持っています
2. 非同期–要求または応答部分のみを持っています

PIでは、メッ

インターフェイス->XML形式のメッセージの構造+方向

上記の基準に基づいて、インターフェイスの三つのタイプがあります

1. アウトバウンドインターフェース–送信側システムへの接続
2. インバウンドインターフェイス–受信側システムへの接続
3. 抽象インターフェイス–BPEへの接続
4. 抽象インターフェイス-BPEへの接続
5. 抽象インターフェイス-BPEへの接続

ビジネス要件に従ってsap piで統合ロジック(シナリオ)を設定すると、その設定を段階的に実行するのは統合エンジンです。 パイプラインは、XMLメッセージの処理中に実行されるすべてのステップを参照するために使用される用語です。 パイプラインステップは、次のように構成されています:

1. 受信者識別-メッセージの交換に参加するシステムを決定します。
2. Interface Determination–メッセージを受信するインターフェイスを決定します。
3. メッセージ分割–複数の受信機が見つかった場合、PIは受信機ごとに新しいメッセージをインスタンス化します。
4. Message Mapping–送信元メッセージを宛先メッセージ形式に変換するためのマッピング。
5. Technical Routing–特定の宛先とプロトコルをメッセージにバインドします。
6. Call Adapter–変換されたメッセージをアダプタまたはプロキシに送信します。

アダプタエンジン

統合エンジンがXML-SOAPプロトコルでのみメッセージを処理することに気づいている必要があります。 しかし、データが同じ形式ではない送信者と受信者のビジネスシステムがある場合はどうなりますか。 アダプターエンジンのさまざまなアダプターを使用して、XMLベースとHTTPベースのメッセージをこれらのシステムで必要な特定のプロトコルと形式に変換し、その逆も同様です。

先に説明したように、SAP PIはアダプタエンジンをスポークと見なすことができるハブとスポーク構造です。 アダプタエンジンを使用して、インテグレーションエンジン（ハブ）を外部システムに接続します。 アダプターフレームワークは、アダプターエンジンの基礎です。 アダプターフレームワークは、SAP J2EE Engine(SAP Webアプリケーションサーバーの一部として)およびJ2EEコネクタアーキテクチャ(JCA)に基づいています。 アダプターフレームワークは、アダプターの構成、管理、および監視のためのインターフェイスを提供します。

デュアルスタックシステムでは、Javaスタックに基づくアダプタのほとんどは、ABAPスタックに基づく二つのアダプタを除きます。

Javaスタック	RFCアダプタ、SAP Business Connectorアダプタ、ファイル/FTPアダプタ、JDBCアダプタ、JMSアダプタ、SOAPアダプタ、Marketplaceアダプタ、メールアダプタ、RNIFアダプタ、CIDXアダプタ
ABAPスタック	IDOCアダプタとHTTPアダプタ

SAP PIがデュアルスタックからシングルスタックに移動したとき、これら二つのアダプタはJavaスタックの一部になりました。 変更されたアダプターエンジンはAdvance Adapter Engineと呼ばれ、二つのアダプターはそれぞれIDOC_AAEアダプターとHTTP_AAEアダプターと呼ばれます。

ビジネスプロセスエンジン

ビジネスプロセスエンジンは、統合プロセスの実行と永続化を担当します。

BPMはクロスコンポーネントビジネスプロセス管理またはccBPMの略で、統合プロセスとも呼ばれます。 統合プロセスは、メッセージを処理するための実行可能なクロスシステムプロセスです。 統合プロセスでは、実行されるすべてのプロセスステップと、プロセスの制御に関連するパラメータを定義します。 ビジネスプロセス管理では、SAP Exchangeインフラストラクチャに次の機能が提供されます:

1. State-full message processing:統合プロセスのステータスは統合サーバーに永続化されます。
2. 相関を使用して、メッセージ間の意味関係を確立することもできます。
3. 統合プロセスを実装するエンタープライズおよびアプリケーションの境界を越えて拡張される複雑な統合プロセスを定義、制御、監視する場合。 統合プロセスでは、抽象インターフェイスのみを使用してメッセージを送受信できます。

   SAP PIでシナリオを構築する

   PIでシナリオを構築する必要がある場合は、ホームページから開始します。

   ホームページは以下のようになります:

   図6–SAP PI Java Stackのホームページ

   ホームページには、次の4つの作業領域へのハイパーリンクがあります

   1. Enterprise Services Repository(ESR)
   2. 統合ディレクトリ(ID)
   3. System Landscape(SL)
   4. Configuration and Monitoring(CM)

   各ハイパーリンクは、1つのアプリケーションを開きます。 これら4つはすべてJavaアプリケーションです。 ESRとIDはswingアプリケーションです。 これらは、JNLPに基づいてブラウザから起動されます。 それは全体のライブラリファイルをダウンロードするように、初めてそれはより多くの時間がかかります。 しかし、2回目以降は、起動にかかる時間が短くなります。 SLとCMは純粋なwebアプリケーションであり、ブラウザ上で実行されます。

   Enterprise Services Repository

   ここでは、統合シナリオの作成に使用するオブジェクトを設計および作成します。 PIのデータフローは、以下に示すようになります:

   我々は、次の

   1. インターフェイスオブジェクトを設計するためのオプションを見つけます-サービスインターフェイス、メッセージタイプ、データ型
   2. マッピ

   

   PIは統合リポジトリを使用して、送信者と受信者の両方のシステムのメッセージ構造を設計し、外界への相互作用のポイントとして機能する対応す データ型とメッセージ型は、複雑なインターフェイスの設計を簡素化およびモジュール化するために使用されます。

   操作マッピングは、二つの構造が異なる場合にソース構造をターゲット構造に変換することができます。 しかし、ソース構造とターゲット構造が同じであれば、操作マッピングは省略される可能性があります。 サービスインタフェースと同様に、メッセージマッピングは、複雑な操作マッピングの設計を簡素化およびモジュール化するために使用されます。 メッセージマッピングは、4つの方法で実装できます

   1. グラフィカルマッピング
   2. Javaマッピング
   3. XSLTマッピング
   4. ABAPマッピング

   グラフィカルマッピングは、開発者が両方の構造の属性をグラフィカルにマッピングして、サービスインタフェースを使用してデータを渡すことができるため、最も使用されています。 他の3つについては、コードを記述してマッピングを開発する必要があります。 単一のスタックサーバの場合、ABAPマッピングは使用できません。

   他の領域もありますが、このチュートリアルでは説明しません。

   統合ディレクトリ

   ここでは、先に作成したESRオブジェクトを設定して、パイプラインの手順を行います。 これらの手順は、実行時に統合エンジンによって実行されます。

   設定を開始する前に、DIRに次のオブジェクトを作成/インポートする必要があります。

   1. サービス–ビジネスシステム/ビジネスサービス/統合プロセス
   2. 通信チャネル

   サービスを使用すると、メッセージの送信者または受信者に対処できます。 サービスの利用方法に応じて、以下のサービスタイプから選択することができます。

   1. ビジネスシステム–特定のビジネスシステムをメッセージの送信者または受信者としてアドレス指定する場合は、このサービスタイプを選択します。 ビジネスシステムは、システムランドスケープにおける実際のアプリケーションシステムです。
   2. ビジネスサービス–抽象ビジネスエンティティをメッセージの送信者または受信者としてアドレス指定する場合は、このサービスタイプを選択します。 ビジネスサービスは、システムランドスケープでは定義されていません。
   3. 統合プロセスサービス–統合プロセスをメッセージの送信者または受信者としてアドレス指定する場合は、このサービスタイプを選択します。 実行時には、これらの統合プロセスはメッセージによって制御され、それ自体がメッセージを送信できます。

   通信チャネルは、メッセージの受信処理と送信処理を決定します。 メッセージは、アダプターを介してネイティブ形式からsoap-xml固有のメッセージ形式に変換され、その逆も変換されます。 一般的に、シナリオでは2種類の通信チャネルがあります

   1. 送信側の通信チャネル
   2. 受信側の通信チャネル

   

   通信チャネルをサービスに割り当てる必要があります。 サービスがメッセージの送信者または受信者としてアドレス指定されるかどうかに応じて、割り当てられた通信チャネルは、送信者または受信者チャネ 統合プロセスサービスに通信チャネルを割り当てることはできません。

   パイプラインステップは、DIR

   に次の4つの設定を作成することによって作成されます。:

   1. Sender Agreement
   2. Receiver Determination
   3. Interface Determination
   4. Receiver Agreement

   Sender agreementは、送信者のメッセージを変換して統合サーバーで処理できるようにする方法を定義します。 これは、次の

   1. 送信者コンポーネント
   2. 送信者インターフェイス
   3. 送信者通信チャネル

   送信者契約は、テーブルの主キーに似ています。 1つのランドスケープには、2つの同様の送信者契約が存在することはできません。

   Receiver Agreementは、受信者が処理できるようにメッセージをどのように変換するかを定義します。 これは、

   1. 送信側コンポーネント
   2. 受信側コンポーネント
   3. 受信側インターフェイス
   4. 受信側通信チャネル

   受信側決定を使用して、メッセージを送信す 受信者にメッセージを転送するための条件を定義するオプションがあります。 これは、

   1. Senderコンポーネント
   2. Senderインターフェイス
   3. Receiverコンポーネント

   Receiverの決定は、実行時にマッピングによって受信機を手動で指定するか、動的に指定するかに応じて、標準または拡張の二つのタイプで構成されています。

   インターフェイス決定を使用して、受信者のどの受信インターフェイスにメッセージを転送するかを指定します。 また、メッセージの処理に使用するインテグレーションリポジトリからのインターフェイスマッピングを指定することもできます。 送信側インターフェイスと受信側インターフェイスが同じ形式でない場合は、形式を変更するための操作上のマッピングがあります。 送信側、送信側インターフェイス、および受信側のインターフェイス決定を定義します。 これは、

   1. Senderコンポーネント
   2. Senderインターフェイス
   3. Receiverコンポーネント
   4. Receiverインターフェイス

   インターフェイスの決定は、receiverインターフェイスを手動で指定するか、マッピ

   レシーバ決定とインタフェース決定–この2つは一般に論理ルーティングとして知られています。 送信者契約と受信者契約–この2つは、一般的にコラボレーション契約として知られています。

   システムランドスケープ

   SAPシステムランドスケープディレクトリ(SLD)は、システムランドスケープの中央情報プロバイダです。 Webページには、次のリンクがあります:

   1. 技術システム-技術システムは、システムランドスケープにインストールされているアプリケーションシステムです。
   2. ビジネスシステム–ビジネスシステムは論理システムであり、PI内の送信者または受信者として機能します。 ビジネスシステムは、関連する技術システムと一対一の依存関係を持っています。
   3. 製品とコンポーネント–これは、バージョンを含む、利用可能なすべてのSAP製品とコンポーネントに関する情報です。 システムランドスケープにサードパーティ製品がある場合は、ここにも登録されます。

   SLDは以下のようになります:

   図11–システムランドスケープ

   製品とコンポーネントは、一般的にコンポーネント情報

   技術システムとビジネスシステムは、一般的にランドスケープディ

   ビジネスシステムは、統合サーバーまたはアプリケーションシステムとして構成できます。

   1. Integration Server–Integration serverは、Integration Builderで構成された統合ロジックのみを実行します。 それらはまた管ラインステップとして識別することができます。 XMLメッセージを受信し、受信者を決定し、マッピングを実行し、XMLメッセージを対応する受信者システムにルーティングします。 このように構成された統合エンジンは、中央構成された統合エンジンであると識別されます。
   2. アプリケーションシステム–アプリケーションシステムは統合ロジックを実行しません。 次に、必要に応じて統合ロジックを実行するために統合サーバーを呼び出します。 XMLメッセージの送信者または受信者として機能します。 そのため、ローカル統合エンジンを搭載したアプリケーションシステムでは、統合ロジックを実行するために統合サーバーが必要です。

   統合サーバとして設定できるのは、SAPシステムのクライアントのみです。

   以下の情報はSLDからESRに抽出され、DIR

   1. コンポーネント情報はESRで製品を定義するために使用され、SWCV
   2. ビジネスシステムはメッセージの送信者と受信者を定義するためにディレクトリに使用されます

   構成と監視

   これは、監視目的の中心的なエントリポイントです。 これにより、インテグレーションエンジンの監視機能に移動したり、コンピューティングセンター管理システム(CCMS)やSapのプロセス監視インフラストラクチャ(PMI)との統合を行うことができます。

   設定と監視は以下のようになります:

   図13-構成と監視

   構成と監視では、以下の監視機能がサポートされています:

   1. コンポーネントの監視-さまざまなSAP PIコンポーネント(JavaおよびABAPパーツ)の監視。
   2. メッセージの監視–SAP PIコンポーネント内のメッセージ処理ステータスの追跡とエラーの検出と分析。
   3. エンドツーエンドの監視-SAP PIの観点からのメッセージライフサイクルの監視。
   4. パフォーマンス監視–SAP PIのさまざまなパフォーマンス側面に関する統計には、RWBを介してアクセスできます。 ここでは、コンポーネント、時間範囲、メッセージ属性などのパフォーマンスデータを選択して集計することができます。
   5. インデックス管理–SAP PIコンポーネントごとにメッセージのインデックスを管理および監視することにより、メッセージ監視で使用できるインデックスベース この種のメッセージ検索では、アダプタ固有のメッセージ属性や、メッセージペイロードからの用語やフレーズなど、強化された選択基準が提供されます。
   6. アラート設定–アラートフレームワークを使用することにより、ABAPおよびJavaでのメッセージ処理中に報告されたすべてのエラーをPIの中央監視に提供できます。 これにより、ABAPランタイムとJavaベースのアダプタエンジンの両方で、このようなエラーに対する反応が改善されます。 この目的のために、アラートフレームワークには、特定のイベントとPIメッセージプロトコルのヘッダーからの情報に基づいたルールが提供されます。 これらのルールは、アラートが送信されるかどうかを決定します。 アラートが送信された場合は、エラー分析に使用できます。
   7. Alert inbox–alert inboxはユーザー固有のもので、アラート設定に基づいて生成された各アラートサーバーのすべてのアラートが表示されます。
   8. キャッシュ監視–キャッシュ監視は、現在ランタイムキャッシュ内にあるオブジェクトを表示します。 異なるキャッシュオブジェクトは、関係するキャッシュインスタンスに応じて監視されます。

   同期通信と非同期通信

   プロセスは同期または非同期のいずれかとして定義できます。

   • 同期プロセスは要求/応答操作によって呼び出され、プロセスの結果はこの操作を介して呼び出し元に直ちに返されます。
   • 非同期プロセスは一方向操作によって呼び出され、結果と障害は他の一方向操作を呼び出すことによって返されます。 結果は、コールバック操作を介して呼び出し元に返されます。

   コンピュータの世界では、非同期通信はありません。 2つのシステム間のすべての通信は、常にメソッド呼び出し（要求/応答操作）を介して行われます。 では、どのように非同期にするのですか？ 答えは、called関数とcaller関数の間に3番目のシステムが導入されたことにあります。

   aとBの二つのシステムがあるとします。 AとBの間のすべての通信はメソッド呼び出しを介して行われるため、同期的です。 AとIの間の通信はメソッド呼び出しを介して行われ、同様にIとBの間もメソッド呼び出しを介して行われます。 しかし、aとBの間の通信は、AがBからの応答を待つ必要がないため、非同期と呼ぶことができます。

   これは非同期通信の基礎であり、この中間システムは何ですか？ それがキューです。 Aは送信者と呼ばれ、Bは受信者と呼ばれます。 Aからのメッセージは最初にキューに追加され、その後再びキューからプルされてBに送信されます。Bからの応答は同様の方法でAに到達します。 特定の状況では、ビジネス要件では、メッセージがAからトリガーされるのと同じ順序でBに配信される必要があります。 そのような要件がない場合、メッセージはキューからBに任意の順序で送信されます。

   非同期通信では、システムAがメッセージを送信するときにシステムBが利用できないという保証された配信を実現します。 メッセージはキューに追加され、Bが利用できない限りそこに残ります。 Bが利用可能になると、メッセージはキューからプルされ、Bに送信されます。

   ので、メッセージ通信を三つの方法で分類することができます:

   1. 同期
   2. 順序が維持されていない非同期
   3. 順序が維持されていない非同期

   PIでは、同期–BE（ベストエフォート）、順序が維持されていない非同期–EO（正確に一度）、順序が維持されていない非同期–EOIO（正確に一度）として識別します。

   確認応答

   確認応答は非同期通信のルートです。 どうして？

   同期通信の場合、システムAはシステムBを呼び出し、Bが応答の送信に失敗した場合、プロセスは失敗しました。 したがって、AとIの間の通信は成功したが、IとBの間の通信は失敗したとします。 Aは、Bへの配信が失敗したことをどのように認識する必要がありますか？ これは、aからbにかかったメッセージと同じルートを介してBによってAに送り返される確認応答によって実現されます。 Bからの確認応答がAに到着しなかった場合、aはプロセスが失敗したと考え、メッセージを再度送信します。

   PIで非同期通信について議論しましたが、EOとEOIOの両方に”正確に一度”という用語を使用しました。 正確に一度は、一度配信されたメッセージを再び配信できないことを意味します。 これを実現するには、AからBへのすべてのメッセージ送信の確認応答があります。 そのため、アダプターは確認応答をサポートする必要があります。

   すべてのアダプタは、システム確認応答iを提供します。e.配達確認。 同期通信をサポートするアダプタは、システム確認応答に加えて、アプリケーション確認応答をサポートします。

   だから、PIでは、以下の肯定応答のタイプがあります

   1. システム肯定応答–非同期メッセージが受信者に到達したことを確認するためにランタイム環
   2. Application Acknowledgment–非同期メッセージが受信側で正常に処理されたことを確認するために使用されるアプリケーションacknowledgment。

   リモート関数呼び出し

   PIで作業している間、あなたは用語–RFCに出くわすでしょう。 彼らは何ですか？ R/3とPIという2つのSAPシステム間の通信を確立するために、RFC宛先を作成します。 次の

   1. 接続タイプ
   2. 受信機のIPアドレスとポート

   接続タイプは、システム接続のタイプ、すなわちR/3、TCP/IP、内部などを示します。

   私たちが作成するRFC宛先は、必要な通信モード、すなわちに従って分類されます。 同期通信または非同期通信をサポートする必要があるかどうか。

   1. 同期通信の場合–同期RFC
   2. 順序が維持されていない非同期通信の場合–トランザクションRFC
   3. 順序が維持されている非同期通信の場合–キューに入れられたRFC

   これらはsRFC、tRFC、およびqRFCによって識別されます。

   ケーススタディ–1

   あなたがクラスルームにいて、その中に10人の学生がいると仮定します。 次に、講師は、各学生に以下の個人情報を準備し、それらをXMLファイルに保存するように求めます。 詳細は以下の通りです:

   1. 学生ID
   2. 名前
   3. 携帯電話
   4. 電子メール
   5. 性別

   10個のファイルがあり、ファイルの名前はcv_1,2,3…です。10. ファイルはソースディレクトリに保存されます。 テスト目的では、

   ソースディレクトリが作成されます。c:\ibm\sap\training\input

   アーカイブディレクトリ:c:\ibm\sap\training\archive

   エラーディレクトリ:c:\ibm\sap\training\error

   ターゲットディレクトリ:c:\ibm\sap\training\target

   ソースディレクトリからソースファイルを読み取り、ターゲットディレクトリに書き込むシナリオをSAP PIで開発するよう求められます。 ファイルがソースディレクトリから正常に読み込まれると、アーカイブディレクトリに移動し、ファイルが何らかのエラー、つまりxml形式が維持されていな アーカイブ、エラー、またはターゲットディレクトリに移動されたファイルには、ファイル名にタイムスタンプが追加されている必要があります。

   1. ファイル名+<タイムスタンプ>。

   Lesson-1

   一つのファイル、すなわちファイルcv_1を読み取るシナリオを準備します。ソースディレクトリからxmlを作成し、ターゲットディレクトリに書き込みます。 ターゲットファイル名もcv_1にする必要があります。名前にタイムスタンプが付加されたxml。

   Lesson-2

   ソースディレクトリからすべてのファイルを読み込み、ターゲットディレクトリに書き込むシナリオを準備します。 同様に、ターゲットファイルの名前もcv_1,2とする必要があります。.タイムスタンプがそれぞれに追加されたxml。

   Lesson-3

   インストラクターは、次の検証をデータに追加するように求めます。

   1. 携帯電話番号は10桁の数字を持つ必要があります–携帯電話番号が10桁でない場合は、それを’error’
   2. に置き換えます電子メールには1つの’@’文字と1つの’が’文字-電子メールに’@’または’がない場合。’文字、それを’エラー’に置き換えます’

   シナリオを実行する前に、いくつかのソースファイルで、上記のロジックに従ってエラーになるようにモバイルと電子メールを変更します。

   Lesson-4

   すべてのソースファイルを読み、性別に応じて分類するシナリオを準備します。 男性用のファイルは、あるディレクトリに書き込まれ、女性用は別のディレクトリに書き込まれます。 2つのディレクトリは、上記の目的のために作成されます:

   男性のターゲットディレクトリ:c:\ibm\sap\training\target\men

   女性のためのターゲットディレクトリ：c:\ibm\sap\training\target\women

   クラスに6人の男性と4人の女性がいると仮定し、すべてのソースファイルが正常に読み取られた場合、男性のターゲットディレクトリには6

   ケーススタディ–2

   講師は、各学生の個人情報を別々のセグメントにまとめた単一のファイルを準備するように求めます。

   Lesson-5

   このファイルを読み込み、各ファイルが各従業員の個人データに対応する10個のターゲットファイルを生成するシナリオを記述します。 ターゲットファイルの名前はcv_<emp_id>_<timestamp>

   Lesson-6

   上記のシナリオを変更して、男性用のターゲットファイルと女性用のターゲットファイルの代わりに2つのターゲットファイルを生成するようにします。 男性用のターゲットファイルには、6人の男性用の6セグメントがあり、女性用のターゲットファイルには4人の女性用の4セグメントが必要です。

   ターゲットファイルは、男性の場合は

   という名前にする必要があります–men_<time-stamp>

   女性の場合–women_<time_stamp>

   ケーススタディ–3

   ケーススタディ-1と個人情報をxmlファイルに保存します。 10個のファイルがあります。 ファイルはソースディレクトリに保存されます。

   Lesson-7

   ソースディレクトリからすべてのソースファイルを読み取り、ターゲットディレクトリに単一のファイルを作成するシナリオを準備します。 対象ファイルの名前が出力されます。タイムスタンプがファイル名に追加されたxml。 ターゲットファイルには、各ソースファイルのすべての詳細がサブセグメントとして含まれます。

   Lesson-8

   ソースディレクトリからソースファイル全体を読み取り、ターゲットディレクトリに二つのファイルを作成するシナリオを準備します。 6人の男性の場合、男性ファイルにはそれぞれの男性の詳細を持つ6つのセグメントがあり、4人の女性の場合は、同様に各女性の詳細を持つ4つの

   ケーススタディ–4

   インストラクターは、各学生に、次の学術的な詳細で構成される別の詳細セットを準備するように求めます:

   1. 学生ID
   2. 学校名
   3. 大学名
   4. 学科名
   5. 入学年

   10個のファイルがあり、ファイルの名前はad_1,2,3……………………10. ファイルはソースディレクトリに保存されます。 そのため、各学生には、個人情報用のファイルと学術的な詳細用のファイルがあります。 二つのファイルは、学生IDと共同関連しています。 入力ディレクトリは現在、10個の個人ファイルと10個の学術ファイルで構成されています。

   Lesson–9

   ソースファイルを選択してペアで処理するシナリオを開発するよう求められます。 このシナリオでは、10個のターゲットファイルが生成されます。 各ターゲットファイルは、個別のセグメント内の学生の個人的および学術的な詳細で構成されます。 ターゲットファイルの名前はres_1,2,10になります。

   ターゲットファイルは次のようになります:

   Lesson–10

   あなたは、彼らが一致する学術や個人のファイルを持っていないように、ファイルのいくつかの学生IDを変更するように求められます。 シナリオを実行する必要があり、それが一致する対応するファイルを持っていない任意のファイルを発見した場合、プロセスは、すなわち2分、そ