ハブを設定するには、コミュニティー・マネージャーが参加する交換のタイプに関する情報が必要です。例えば、以下の情報が必要です。
これらの情報を決定したら、ハブの設定を始めることができます。
ハブを定義したら、参加者から提供された情報 (IP アドレスや DUNS 番号) を使用して、参加者の定義を行います。さらに、前述のとおり、コミュニティー・マネージャーもハブの特殊なタイプの参加者として定義します。
さまざまなトランスポートを使用して、参加者から WebSphere Partner Gateway (ハブ) に文書を送信できます。参加者は、HTTP、HTTPS、JMS、FTP、FTPS、FTP スクリプト記述、SMTP、またはファイル・ディレクトリーを使用して、文書をパブリック・ネットワークで送信できます。参加者は、FTP スクリプト・トランスポートを使用して、文書を付加価値通信網 (VAN)、プライベート・ネットワークで送信できます。独自のトランスポートを作成することもできます。
同様に、ハブは、さまざまなトランスポートを使用して、文書をバックエンド・アプリケーションに送信します。ハブとバックエンド・アプリケーションの間で最もよく使用されるトランスポートは、HTTP、HTTPS、JMS、およびファイル・ディレクトリーです。
図 2 は、使用可能なさまざまなトランスポートを示しています。
文書の送受信に使用するトランスポートのタイプによって、ターゲットおよびゲートウェイのセットアップの方法が異なります。ターゲットは、ハブの入り口点 (参加者またはバックエンド・アプリケーションによって送信される文書がハブで受信される場所) です。ゲートウェイは、参加者のコンピューターまたはバックエンド・システムの入り口点 (ハブが文書を送信する場所) です。FTP、FTPS、FTP スクリプト、JMS、およびファイル・ディレクトリーのトランスポートを使用できるように準備するには、セットアップ作業を行う必要があります。ハブを構成するための準備を参照してください。
参加者とコミュニティー・マネージャーの間で文書を交換するための設定を行う場合、文書について以下のことを指定する必要があります。
文書フロー定義 は、文書のパッケージ化、文書のプロトコル、および文書フローで構成されます。文書フロー定義は、文書の処理方法についての情報をハブに提供します。例えば、以下のシステム提供の文書フロー定義を使用するとします。
ハブは、AS ヘッダー情報を抽出します (そして、その情報を使用して文書のソースおよび宛先を判別します)。ハブは、文書内の配置に基づいて、特定の情報が文書のどこにあるかを認識します。文書フロー定義の 3 つの構成部分には属性が割り当てられています。システム提供の属性を変更したり、属性を追加することができます。
パッケージ化によって、文書の伝送に関する情報が提供されます。前述のとおり、パッケージ化が AS の場合、ハブは AS ヘッダーの情報を使用して文書のソースおよび宛先を判別します。参加者が RosettaNet PIP をコミュニティー・マネージャーに送信する場合、PIP は RNIF としてパッケージ化されます。
図 3 は、ハブとコミュニティーの参加者の間、およびハブとバックエンド・アプリケーションの間で交換される文書に設定できるパッケージ化タイプを示しています。
パッケージは、特定のプロトコルに関連付けられています。例えば、参加者は、RosettaNet 文書をハブに送信する場合に RNIF パッケージ化を指定する必要があります。
図 3 に示されているとおり、バックエンド統合はハブとバックエンド・アプリケーションの間でのみ使用可能です。バックエンド統合パッケージ化を指定すると、ハブによってバックエンド・システムに送信される文書に特殊なヘッダー情報が追加されます。同様に、バックエンド・アプリケーションが、バックエンド統合のパッケージ化で文書をハブに送信する場合、ヘッダー情報を追加する必要があります。バックエンド統合パッケージ、およびヘッダー情報の要件については、「エンタープライズ統合ガイド」で説明されています。
AS パッケージは、参加者とハブの間でのみ使用可能です。AS パッケージは、AS1 または AS2 規格に準拠する文書に使用できます。 AS1 は SMTP を介して文書を安全に送信するために使用される規格であり、AS2 は HTTP または HTTPS を介して文書を安全に送信するために使用される規格です。AS のパッケージ化で参加者によって送信される文書は、AS1 または AS2 のいずれかのヘッダー情報を持ちます。AS1 または AS2 ヘッダーを期待する参加者に送信される文書は、(ハブで) AS としてパッケージ化する必要があります。
なしパッケージは、ハブと参加者の間、およびハブとバックエンド・アプリケーションの間で文書を送受信するために使用できます。文書がなしとしてパッケージ化される場合、ヘッダー情報は追加されません (期待されません)。
RNIF パッケージは、インストール・メディア上で提供されます。RNIF パッケージを (交換する PIP とともに) アップロードします。方法については、RosettaNet 文書で説明しています。RNIF パッケージは、RosettaNet 文書を参加者とハブの間で送信する場合に使用されます。
WebSphere Partner Gateway 内で終了する文書フロー、または WebSphere Partner Gateway 内部から発生する文書フローがあります。WebSphere Partner Gateway 内で終了する文書フローの場合、パッケージ化は必要ありません。WebSphere Partner Gateway 内部から発生する文書フローには、ソースのパッケージ化はありません。したがって、そのようなフローでは、パッケージ化は N/A として指定されます。
参加者からコミュニティー・マネージャーへの片方向伝送 (または、逆の片方向伝送) では、ほとんどの場合、WebSphere Partner Gateway が参加者から文書を受信し、それをコミュニティー・マネージャーに送信します。WebSphere Partner Gateway では、参加者の接続の作成時に、WebSphere Partner Gateway が文書を受信するパッケージ化と WebSphere Partner Gateway が文書を送信するパッケージ化を指定します。図 4 では、AS としてパッケージ化された文書が、参加者からコミュニティー・マネージャー・バックエンドへ流れています。文書はトランスポート・ヘッダーなしでコミュニティー・マネージャー・ゲートウェイに配信されます。図 4 では、文書の交換に 1 つのアクションが関連付けられています。
ただし、プロトコルによっては複数のアクティビティー (エンベロープ解除、変換など) が含まれ、その中には交換全体の中間部分として発生するものもあります。例えば、参加者が EDI 交換をハブに送信する場合 (最終的な配信先はコミュニティー・マネージャー)、交換はエンベロープ解除され、個々の EDI トランザクションが処理されます。元の EDI 交換には、参加者からの送信時にパッケージが関連付けられています。ただし、交換自体はコミュニティー・マネージャーに配信されないため (ハブ内でエンベロープ解除され、交換に対する追加処理は発生しません)、交換のパッケージ化は適用されません。したがって、エンベロープ解除のステップの対話をセットアップする場合、送信側でパッケージを入力しますが、受信側には「N/A」を指定します。
EDI 交換で必要な文書フロー定義をセットアップするための手順については、EDI 文書フローの構成で説明されています。
システムに準備されているプロトコルは、以下のとおりです。
バイナリー・プロトコルは、AS、なし、およびバックエンド統合パッケージで使用できます。バイナリー文書には、文書のソースまたは宛先についてのデータは含まれていません。
これらの EDI プロトコルは、AS またはなしパッケージで使用できます。N/Aで説明されているように、EDI トランザクションまたは交換がハブから発生する場合、またはハブで終了する場合、パッケージに「N/A」を指定します。X12 および EDIFACT は、データ交換に使用される EDI 標準です。EDI-Consent は、X12 または EDIFACT 以外のコンテンツ・タイプを参照します。
Web サービス・プロトコルは、なしパッケージでのみ使用できます。
cXML プロトコルは、なしパッケージでのみ使用できます。
XMLEvent は、バックエンド・アプリケーションへ流れる文書、またはバックエンド・アプリケーションから流れる文書にイベント通知を提供するために使用される特殊なプロトコルです。これは、バックエンド統合パッケージでのみ使用できます。このプロトコルについては、「エンタープライズ統合ガイド」で説明されています。
RNIF パッケージをアップロードすると、関連したプロトコル (RosettaNet および RNSC) も取得できます。RosettaNet (参加者とハブの間で使用されるプロトコル) は、RNIF パッケージに関連付けられています。RNSC (ハブとコミュニティー・マネージャーのバックエンド・アプリケーションの間で使用されるプロトコル) は、バックエンド統合パッケージに関連付けられています。
変換される EDI トランザクション、または XML または ROD 文書の場合、Data Interchange Services クライアントから変換マップをインポートします。Data Interchange Services クライアントでは、この変換に関連したプロトコルに対してディクショナリーが定義されています。ディクショナリーには、EDI 文書定義、セグメント、複合データ・エレメント、データ・エレメントなど、EDI 規格を構成するすべてに関する情報が含まれています。特定の EDI 規格の詳細については、該当する EDI 規格マニュアルを参照してください。Data Interchange Services クライアントについては、「Mapping Guide」または Data Interchange Services クライアントに付属のオンライン・ヘルプを参照してください。
カスタム・プロトコルを作成して、文書をどのように構造化するかを正確に定義することができます。XML 文書の場合は、カスタム XML 文書の説明に従って XML 形式を定義します。
文書には、さまざまな形式があります。システム提供の文書フローおよび関連したプロトコルは、以下のとおりです。
以下のリストは、他のタイプの文書および定義のソースを示しています。
カスタム XML 文書に説明されているとおり、独自の文書フローを作成することもできます。