BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA
 ドキュメントのダウンロード   サイト マップ   用語集 
検索

WebLogic Platform サンプル
アプリケーション
ツアー

 前 次 目次 PDFで表示  

Avitek の購入担当者とサプライヤとの接続

企業間取引 (B2B) ポータル ツアーでは、Avitek の購入担当者がサプライヤから見積もりを取り、注文書を発行してサプライヤから受付確認を受け取るための、架空のイントラネット サイトについて説明します。ビジネス プロセスは、WebLogic Integration によって管理されます。

注意: このオンライン ブックに掲載されている情報は、アプリケーションの一部として実行される状況依存ツアー ガイド ポートレットでも入手できます。

この企業間取引 (B2B) ポータル ツアーには、以下の節があります。

 


Product Inventory ポートレット

B2B ポータルのサンプル アプリケーションは、Avitek のイントラネットの [Inventory] ページから始まります。ログイン ユーザ Jason Tang がこのプロセスの手順をよりよく理解できるように、図 processStep1.gif がロードされています。初めてこのページを訪れた場合、Product Inventory ポートレットには、Avitek の販売商品の一部のデータがあらかじめロードされています。商品の在庫が最低水準を下回っている場合には、データが赤色で表示されます。


 

Product Inventory ポートレットの技術詳細

この節では、このページで行われる処理について詳しく説明します。

はじめに

b2bPortal は、架空の会社である Avitek Digital Imaging が使用するサンプルの企業間取引 (B2B) サイトです。Avitek の購入担当者は、このサイトを使って、外部のサプライヤから部品についての見積もりを取り寄せ、注文書を発行します。

b2bPortal は、e2eApp エンタープライズ アプリケーションの一部です。このエンタープライズ アプリケーションの名前には、e2e が含まれています。「e2e」とは、エンド ツー エンド (end-to-end) を略したもので、WebLogic Platform の主要機能のすべての範囲を示すサンプルであることを意味しています。

この [Inventory] ページの Product Inventory ポートレットには、Avitek の販売商品の一部のデータがあらかじめロードされています。商品の在庫が最低水準を下回っている場合には、データが赤色で表示されます。現在の在庫水準を確認するため、データベース内の在庫テーブルに、Application Integration (AI) フレームワークを介して読み込み専用モードでアクセスしました。AI フレームワークは、WebLogic Integration によって提供されます。

サンプル シナリオでは、Avitek Digital Imaging は、自動化、サイクル時間の短縮、在庫水準を下げることによって、サプライ チェーンを効率化し、コスト削減を図ろうとしていました。在庫水準を追跡して補充を行うために、Avitek は、ポータル ユーザ インタフェースを使って、販売側の B2B 交換、パートナとの提携、サプライ チェーン管理について、企業間取引ソリューションを実現しました。

このサンプル アプリケーションの B2C (企業消費者間取引) ポータル b2cPortal をすでにお使いの場合は、ポートレットと Webflow 処理についての説明が「技術詳細」の節に記載されていることをご存知でしょう。ポートレットと Webflow は b2bPortal でも重要な項目ですが、ここでは、Avitek 購入担当者用に実装されているサプライチェーン ソリューションに焦点をあてて説明します。ただし、この節でも、ポートレットと Webflow については一部詳細に説明します。

取引相手

この WebLogic Platform b2bPortal サンプル シナリオでは、バイヤ (Avitek Digital Imaging) 1 社とサプライヤ 2 社という取引関係を持つ 3 社が関わります。この 3 社それぞれに、取引相手が BulkLoaderData.xml ファイルでコンフィグレーションされます。サンプル用として、E2E_Buyer、E2E_SupplierOne、およびE2E_SupplierTwo が取引相手として定義されています。

これらの取引相手間では、XOCP ビジネス プロトコルを使って通信を行うため、Avitek は、その WebLogic Integration システムをハブ & スポーク コンフィグレーションとして定義する必要があります。これを受けて、BulkLoaderData.xml ファイルで、第 4 の取引相手 E2E_Hub を定義します。B2B 統合のコンフィグレーションの詳細については、『B2B Integration 入門』の「B2B Integration の基礎」を参照してください。

この E2E_Hub という取引相手は、仲介者として機能します。スポークとなる E2E_BuyerE2E_SupplierOne、および E2E_SupplierTwo という取引相手間のメッセージの仲介を担当します。E2E_Hub という取引相手は、業務メッセージの送信側でも受信側でもありませんが、トランザクション中は、必要に応じてプロキシ バイヤおよびプロキシ サプライヤとして機能します。

取引相手 3 社 (E2E_BuyerE2E_SupplierOne、および E2E_SupplierTwo) はそれぞれ、取引相手 E2E_Hub と提携契約を結びます。取引相手 E2E_Hub は、提携契約を連結する役割を果たします。このような連結は、必要不可欠なものです。たとえば、1 つの提携契約の一部としてメッセージを受信し、そのメッセージを他の提携契約の一部として別の取引相手に送る必要があります。同じ配信チャネル (取引相手 E2E_Hub に対して定義されているチャネル) を使用する提携契約が連結されます。

各取引相手要素は、さまざまな属性、サブ要素によって特徴付けられ、その中には、名前、電子メール、電話、FAX などの単純な識別情報も含まれます。

下の表は、各取引相手のロールをまとめたものです。

表3-1 取引相手のロール

取引相手名

ロール

E2E_Hub

バイヤとサプライヤとの間の通信経路を管理し、企業間統合を提供する。

E2E_Buyer

ワークフロー テンプレートを使用して、サプライヤ間のビジネス プロセスと内部機能 (たとえば、バックエンド データベースの更新) の調整を行う。

アプリケーション ビューを使用して、バイヤのデータベース システムへの接続を提供する。

HTML ページや JSP ページを介して、データ表示とユーザ インタフェースを処理する。

E2E_SupplierOne

ワークフロー テンプレートを使用して、バイヤからの要求に応え、内部プログラム (データ変換およびデータ保持プログラム) を呼び出す。

データ変換を行って、アプリケーション間の情報交換の便宜を図る。

E2E_SupplierTwo

E2E_SupplierOne と同じロール。


 

WebLogic Integration Studio の使い方

WebLogic Integration Studio を使用すると、使い慣れたフローチャート図を使用して、新しいワークフローの設計、および実行中のワークフローの監視を行うことができます。この b2bPortal サンプルを実行する際に、WebLogic Integration Studio を実行する必要はありませんが、このサンプルのノードがどのように定義され、コンフィグレーションされたかを学ぶために、いずれかのワークフローやワークフロー ノードの詳細を見るのは役に立つでしょう。また、サンプルを実行する際には、Studio を使用してそのワークフローを監視できます。

Windows システムで、[スタート|プログラム|BEA WebLogic Platform 7.0|WebLogic Integration 7.0|Studio] を選択します。

以下を入力して、Studio にログオンします。

例:


 

注意: http ではなく t3 を使用します。

Studio でのワークフロー テンプレートの表示

Studio 内で、ワークフロー テンプレートとそのプロパティを表示するには、以下の手順に従います。

  1. Studio の左ペインの [オーガニゼーション] フィールドで「ORG1」が選択されていることを確認します。

  2. 左ペインで、テンプレート フォルダをダブルクリックし、ワークフロー テンプレートの一覧を表示します。

  3. テンプレート フォルダを展開し、ワークフロー テンプレート定義の一覧を表示します。これらは、このサンプル用にあらかじめコンフィグレーションされている workflows.jar ファイルで定義されています。この worksflows.jar ファイルは、以下の場所にあります。
    weblogic700¥samples¥integration¥samples¥e2e¥workflows

  4. テンプレート定義を右クリックし、[開く] を選択して Studio 内のワークフロー テンプレートを開きます。たとえば、次のように表示されます。


     

    この手順により、Studio 内にテンプレートのグラフィカルな表示が開きます。たとえば、次のように表示されます。


     

    注意: また、特定のワークフロー テンプレート定義を展開して、そのワークフロー テンプレート定義用のタスク、Decisions、イベント、結合、開始、完了、変数などのフォルダを表示することもできます。

Studio 内のいずれかのノードをダブルクリックすると、そのノードの [プロパティ] ダイアログ ボックスが表示されます。Studio ツールと機能の詳細については、WebLogic Integration のドキュメントの『WebLogic Integration Studio ユーザーズ ガイド』を参照してください。

ビジネス プロセスとワークフローのモデル化

この節では、WebLogic Integration が提供するビジネス プロセス管理 (Business Process Management: BPM) を簡単に紹介します。

会話定義で取引相手に割り当てられたロールを実現するワークフローをコラボレイティブ ワークフローといいます。

1 つのワークフロー テンプレートが 1 つのワークフローを表し、その実装のさまざまなワークフロー テンプレート定義 (バージョン) を組み合わせます。ワークフロー テンプレートの設計と編集は、WebLogic Integration Studio で行います。以下のような BPM プラグインにより、WebLogic Integration Studio の機能を拡張できます。

このサンプル シナリオでは、取引相手は、プライベート ワークフローとコラボレイティブ ワークフローの両方を実装しています。プライベート ワークフローは、コラボレイティブ ワークフローと組み合わせて動作し、その取引相手に対するローカル処理を実装します。ローカル処理とプライベート処理は、会話定義で指定する必要はありません。たとえば、取引相手が会話を開始する際、その取引相手のプライベート ワークフローは、コラボレイティブ ワークフローを開始して、会話を開始することができます。

詳細については、WebLogic Integration のドキュメントを参照してください。このサンプルでは、続くポータル ページの「技術詳細」の節で、このサンプル アプリケーションで実装されている「価格と在庫の問い合わせ (Query for Price and Availability: QPA)」と「注文書 (Purchase Order: PO)」という 2 つのビジネス プロセスについて説明します。

在庫ページ ポートレット

[Inventory] ページは、b2bPortal 内の 3 つのタブから構成されるページの 1 つです。WebLogic Platform をインストールした BEA_HOME ディレクトリの以下の場所に、e2eApp を構成するファイルがあります。

weblogic700¥samples¥platform¥e2eDomain¥beaApps¥e2eApp¥... 
weblogic700¥samples¥platform¥e2eDomain¥beaApps¥e2eApp-project¥... 

この [Inventory] ページには、以下のポートレットを追加することができます。

[Inventory] ページを構成するすべてのポートレットは、以下のファイルに定義されています。

weblogic700¥samples¥platform¥e2eDomain¥beaApps¥e2eApp-project
¥application-sync¥webapps¥b2bPortal¥b2bPortal.portal

例:

<page-name>Inventory</page-name>
...
<portlet-pool>
<portlet-name>login</portlet-name>
<portlet-name>partinventory</portlet-name>
<portlet-name>productinventory</portlet-name>
<portlet-name>purchasingprocess</portlet-name>
<portlet-name>b2b-tourguide</portlet-name>
<portlet-name>debug</portlet-name>
<portlet-name>anonUser</portlet-name>
</portlet-pool>

これらのポートレットは、開発サイクル時に E-Business Control Center を使用して [Inventory] ページに追加されました。EBCC は、Java クライアントベースのツールの集まりです。このツールには、ルールの定義、Webflow の編集、ポータルの作成と管理などの複雑な作業を簡単に行えるグラフィカル インタフェースが用意されています。E-Business Control Center のユーザは、ポイントアンドクリック方式のインタフェースで作業を行い、サーバと同期をとる XML ファイルを生成します。EBCC の他にも、実行時のポータルの管理に、ブラウザベースの WebLogic Portal Administration Tools を使用しました。

ポータルの開発者は、主にブラウザに表示される前のポートレットの JSP コードに注目します。そのため、この節で使用されるコードの断片や [コードを表示] リンクでは、特定のポートレットのブラウザで表示する前の JSP ファイルについて説明し、これを示します。

b2bPortal のポートレット JSP ファイルは、以下の場所にあります。

weblogic700¥samples¥platform¥e2eDomain¥beaApps¥e2eApp¥b2bPortal
¥portlets¥...

この [Inventory] ページでは、[コードを表示] リンクで ¥productinventory¥content.jsp ポートレット ファイルのソースを開きます。これは Avitek Product Inventory (1) ポートレットを表します。この content.jsp は、前述のパスの下の productinventory サブディレクトリにあります。

初期ポータル処理の概要

サンプル アプリケーションを起動したとき、サーバが起動し、[はじめに]、すなわち「スプラッシュ」ページが最初に表示されたのは、どういう仕組みによるのでしょうか。まず、サンプル アプリケーションを呼び出す方法にはいくつかの方法があり、WebLogic Platform Quick Start Application から起動する方法や、StartE2E スクリプトの実行という直接的な方法がありました。

どのオプションを使用したかに関わらず、startE2E.bat (Windows) または startE2E.sh (UNIX) スクリプトが呼び出されました。これで、アプリケーションの WebLogic Server インスタンスが起動されましたが、このアプリケーションは、e2eDomain というドメインで実行されるものです。「ドメイン」という言葉は、コンピュータ業界では、さまざまな意味を持っています。BEA 製品でドメインというとき、それは、サーバ、サービス、インタフェース、マシン、関連するリソース マネージャなど、すべて 1 つのコンフィグレーション ファイルで定義されるものの集合を表します。

startE2E スクリプトを実行すると、エンタープライズ アプリケーションの config.xml ファイルからコンフィグレーション情報が読み込まれます。デフォルトでは、このコンフィグレーション ファイルは、BEA 製品がインストールされている以下の BEA_HOME ディレクトリにあります。

weblogic700/samples/platform/e2eApp/config

config.xml ファイルは以下のように定義され、そのドメインのデフォルト Web アプリケーションとして splashPage を設定しています。

<WebServer
DefaultWebApp="splashPage"
LogFileName="./logs/access.log"
LoggingEnabled="true"
Name="e2eServer"
/>

e2eServer が稼動した状態で、http://localhost:7501 などの URL をブラウザで指定すると、以下の場所にある splashPage Web アプリケーションが起動します (Web アプリケーションは「webapp」と略称されることもあります)。

weblogic700¥samples¥platform¥e2eDomain¥beaApps¥e2eApp¥splashPage

splashPage Web アプリケーションの web.xml コンフィグレーション ファイルでは、<welcome-file-list> 定義の中で index.jsp を指定しました。この web.xml は、以下の場所にあります。

weblogic700¥samples¥platform¥e2eDomain¥beaApps¥e2eApp¥splashPage¥WEB-INF

スプラッシュ ページで、[購入エージェント「Jason Tang」として自動ログイ
ン] ボタンのグラフィックをクリックして、この [Inventory] ページを表示しました。その結果、スプラッシュ ページから、ポータル アプリケーションの URL と定義済みのログイン資格情報が渡されることになりました。

スプラッシュ ページは、b2bPortal または b2cPortal に自動的にログインできるようにする要求を設定します。これは、このサンプル アプリケーションを簡素化するために行われます。JSP ページにユーザ名とパスワードを組み込むようなことは、普通は行いません。

フォームは、結果として以下のように構成された URL を開きます。

<%
String b2bUrl = "http://" +
request.getServerName() + ":" +
request.getServerPort() + "/" +
B2B_PORTAL_NAME + "/application";
...

この WebLogic Platform サンプル アプリケーションでは、サンプルを最も重要な機能に特化させるために、既存のユーザを自動的にログインすることを選択しました。WebLogic Portal は、その他にも、ログイン認証コードや、Web アプリケーションによるデモグラフィック情報収集テクニックを示すサンプルも提供します。詳細については、『開発者ガイド』を参照してください。

b2bPortal アプリケーションについて、ブラウザに URL が渡されたとき、[Inventory] ページが最初に表示されたのはなぜでしょうか。このプロパティは、WebLogic Portal Administration Tools で設定しました。このツールの [ポータル管理] セクションの [ページおよびポートレット] の下の [ページの選択と順序設定] 画面で b2bPortal のデフォルト ページを設定しました。この値は、データベースの PORTAL_PAGE_P13N テーブルの INDEX_NUMBER カラムに格納されます。

ページ切り替え Webflow イベント

顧客が JSP 上のリンクやボタンをクリックすると、それが 1 つのイベントであると見なされます。イベントは、デフォルト Webflow 内の特定の応答をトリガし、顧客が処理を継続できるようにします。この応答から別の JSP がロードされる場合もありますが、通常は、入力プロセッサや Pipeline が最初に呼び出された場合に行われます。

[Purchasing] ページまたは [Order History] ページで、[Inventory] タブをクリックすると、以下のような URL が表示されます (ここでは、見やすくするために何行かに改行してあります)。

http://<host>/<port>/b2bPortal/application?
origin=hnav_bar.jsp&event=bea.portal.framework.internal.refresh
&pageid=Inventory

更新イベントにより、最新データで更新されたページが再表示されます。Avitek Product Inventory ポートレットのデータが更新されます。

ページ タブは、hnav_bar.jsp ファイルを介して提供されます。このファイルは、以下の場所にあります。

weblogic700¥samples¥platform¥e2eDomain¥beaApps¥e2eApp¥b2bPortal
¥framework

hnav_bar.jsp ファイルによって、以下の 2 つの JSP タグ ライブラリがインポートされます。

<%@ taglib uri="webflow.tld" prefix="wf" %>
<%@ taglib uri="portal.tld" prefix="ptl" %>

アプリケーション内の別のページから [Inventory] タブをクリックすると、hnav_bar.jsp は、対象となるタブへのリンクで以下の JSP タグを使用します。

<a href="<ptl:createPortalPageChangeURL
pageName='<%= portalPageName %>'/>"><%=portalPageName%></a>

ポータルの ptl:createPortalPageChangeURL JSP タグは、ページ変更イベントの Webflow URL を生成します。

ポートレットの動的表示と WebLogic Integration AI による在庫チェック

[Inventory] ページで、動的ポートレットの 1 つ、¥productinventory¥content.jsp を見てみましょう。このポートレットは、[Inventory] ページで、「1 Avitek Product Inventory」と表示されています。

このポートレットの Webflow ネームスペース ファイルは、以下のとおりです。

weblogic700¥samples¥platform¥e2eDomain¥beaApps¥e2eApp-project¥app
lication-sync¥webapps¥b2bPortal¥product.wf

ここには、以下のコードが含まれます。

<presentation-origin node-name="product" node-type="jsp">
<node-processor-info page-name="content.jsp"
page-relative-path="/portlets/productinventory"/>
</presentation-origin>

content.jsp ファイルは、以下の場所にあります。

weblogic700¥samples¥platform¥e2eDomain¥beaApps¥e2eApp¥b2bPortal
¥portlets¥productinventory¥content.jsp

content.jsp ファイルには、以下の import 文があります。

<%@ page import="examples.e2e.common.Inventory" %> 

content.jsp のスクリプトレットで、データベースの商品データを繰返し参照して、現在の在庫水準を取得します。その水準が定義されている最低水準より低い場合は、CSS ファイルから取得した CSS_INV_BELOW_MIN 設定を使用し、在庫に問題があることを赤色で表示します。

例:

<%
Iterator it = rState.getProducts().iterator();
Inventory prod = null;
String rowCssClass = null;
String extraParams = null;
int i = 0;
for ( ; it.hasNext(); i++ ) {
prod = (Inventory) it.next();
if ( prod.isBelowMinimum() ) {
rowCssClass = CSS_INV_BELOW_MIN;
}
else {
rowCssClass = CSS_PRODUCT_ROW;
}
extraParams = PRODUCT_PARAM_EQUALS + prod.id();
// skip the row divider the first time through
if ( i != 0 ) {
%>

b2cPortal アプリケーションと、この b2bPortal アプリケーション用に、InventoryProvider という名前のサービス プロバイダ インタフェース (Service Provider Interface: SPI) を作成しました。これはステートレス セッション EJB として実装され、以下の 3 つのメソッドがあります。

checkInventory()

getProductInventory()

getProductPartInventory()

InventoryProvider SPI は、b2bPortal と b2cPortal に共通です。このソース ファイルは、以下の場所にあります。

weblogic700¥samples¥platform¥e2eDomain¥beaApps¥e2eApp¥src¥examples¥e2e¥common¥inventory¥spi¥*.java

b2bPortal の場合には、在庫チェックは以下によって実装されます。

これらのプログラムの Java ソース ファイルは、以下の場所にあります。

weblogic700¥samples¥platform¥e2eDomain¥beaApps¥e2eApp¥src¥examples¥e2e¥common¥inventory¥spi¥*.java

これらのプログラムでは、EJB で提供されている getProductInventory() メソッドおよび getProductPartInventory() メソッドを使用します。このサンプル アプリケーションを簡略化するため、getProductInventory ( List SKUs ) メソッドを使用する際には、[List of SKU] が Pipeline コンポーネントの中にハードコード化されます。

次に、productinventory¥content.jsp ポートレットで、返されたデータを表示します。

例:

<!-- model number -->
<td width="187" class="<%= rowCssClass %>"><%= prod.id() %></td>
<!-- minimum # of units -->
<td width="75" class="<%= rowCssClass %>"><%= prod.min() %></td>
<!-- maximum # of units -->
<td width="75" class="<%= rowCssClass %>"><%= prod.max() %></td>
<!-- available # of units -->
<td width="67" class="<%= rowCssClass %>"><%= prod.available() %></td>

次のステップ

ツアーを続けるには、pix1000 カメラの [部品の在庫確認] ボタンをクリックしてください。

 


Product Parts Inventory ポートレット

Product Part Inventory ポートレットの全体を表示するには、スクロールしなければならない場合があります (ステップ 2)。このポートレットには、ステップ 1 で選択した Avitek 商品の構成部品の一覧が表示されます。部品ごとに在庫レベルが表示されます。在庫レベルが最低水準を下回った部品のデータは、赤色で表示されます。


 

Product Parts Inventory ポートレットの技術詳細

在庫処理のステップ 2 にあたる Product Part Inventory ポートレットの処理は、Product Inventory ポートレットの処理と似ています。商品の部品在庫が最低水準を下回った場合には、データが赤色で表示されます。現在の在庫水準を確認するため、データベース内の在庫テーブルに、Application Integration (AI) フレームワークを介して読み込み専用モードでアクセスしました。AI フレームワークは、WebLogic Integration によって提供されます。この場合、InventoryProvider SPI が提供する getProductPartInventory() メソッドが使用されました。

WebLogic Integration AI を介した商品の部品在庫のチェック

[Inventory] ページで、動的ポートレットの 1 つ、¥partinventory¥content2.jsp を見てみましょう。このポートレットは、[Inventory] ページで、「1 Avitek Product Inventory」と表示されています。content2.jsp ファイルは、Product Inventory ポートレットで製品が選択されるとアクティブになります。¥partinventory¥content.jsp ポートレットは非アクティブのバージョンで、[Inventory] ページで製品がまだ選択されていないときに使用されます。

このポートレットの Webflow ネームスペース ファイルは、以下のとおりです。

weblogic700¥samples¥platform¥e2eDomain¥beaApps¥e2eApp-project
¥application-sync¥webapps¥b2bPortal¥part.wf

ここには、以下のコードが含まれます。

<presentation-origin node-name="product" node-type="jsp">
<node-processor-info page-name="content2.jsp"
page-relative-path="/portlets/productinventory"/>
</presentation-origin>

content2.jsp ファイルは、以下の場所にあります。

weblogic700¥samples¥platform¥e2eDomain¥beaApps¥e2eApp¥b2bPortal
¥portlets¥partinventory¥content2.jsp

content2.jsp ファイルには、以下の import 文が含まれます。

<%@ page import="examples.e2e.common.Inventory" %> 

content2.jsp のスクリプトレットで、データベース内の商品データおよび部品データを繰返し参照して、現在の在庫水準を取得します。その水準が定義されている最低水準より低い場合は、CSS ファイルから取得した CSS_INV_BELOW_MIN 設定を使用し、在庫に問題があることを赤色で表示します。

例:

<%
String rowCssClass = null;;
String extraParams = null;
	int i = 0;
for ( ; parts.hasNext(); i++ ) {
		part = (Inventory) parts.next();
		if ( part.isBelowMinimum() ) {
rowCssClass = CSS_INV_BELOW_MIN;
}
else {
			rowCssClass = CSS_PART_ROW;
}
		extraParams = PART_PARAM_EQUALS + part.id();
%>

b2cPortal アプリケーションと、この b2bPortal アプリケーション用に、InventoryProvider という名前のサービス プロバイダ インタフェース (SPI) を作成しました。これはステートレス セッション EJB として実装され、以下の 3 つのメソッドがあります。

checkInventory()

getProductInventory()

getProductPartInventory()

InventoryProvider SPI は、b2bPortal と b2cPortal に共通です。このソース ファイルは、以下の場所にあります。

weblogic700¥samples¥platform¥e2eDomain¥beaApps¥e2eApp¥src¥examples¥e2e¥common¥inventory¥spi¥*.java

b2bPortal の場合には、在庫チェックは以下によって実装されます。

これらのプログラムの Java ソース ファイルは、以下の場所にあります。

weblogic700¥samples¥platform¥e2eDomain¥beaApps¥e2eApp¥src¥examples¥e2e¥common¥inventory¥spi¥*.java

これらのプログラムでは、EJB で提供されている getProductInventory() メソッドおよび getProductPartInventory() メソッドを使用します。このサンプル アプリケーションを簡略化するため、getProductInventory ( List SKUs ) メソッドを使用する際には、[List of SKU] が Pipeline コンポーネントの中にハードコード化されます。

次に、partinventory¥content2.jsp ポートレットで、返されたデータを表示します。

例:

<td class="<%= rowCssClass %>" width="64"><%= part.id() %></td>
<td class="<%= rowCssClass %>" width="83"><%= part.description() %></td>
<td class="<%= rowCssClass %>" width="74"><%= part.min() %></td>
<td class="<%= rowCssClass %>" width="75"><%= part.max() %></td>
<td class="<%= rowCssClass %>" width="60"><%= part.available() %></td>	

次のステップ

ツアーを続けるには、「2 Product Part Inventory」ポートレットで、赤色で表示されている部品の横の [見積の要求] ボタンをクリックしてください。

 


Query for Price and Availability (価格と在庫の照会) ポートレット

Query for Price and Availability (QPA) ポートレットを表示するには、下にスクロールしなければならない場合があります (ステップ 3)。このポートレットには、QPA を生成するためのフォームが用意されています。購入担当者が QPA 要求に必要なデータをすぐに取り出せるように、Product Inventory ポートレットと Product Part Inventory ポートレットは、Inventory Summary ポートレットに置き換えられています。このフォームに入力する必要のある情報については、必ず下記の「次のステップ」節を参照してください。


 

Query for Price and Availability (価格と在庫の照会) ポートレットの技術詳細

Query for Price and Availability (QPA) ポートレットには、QPA を生成するためのフォームが用意されています。QPA ビジネス プロセスは、このステップ 3 のポートレットで [QPA 要求の送信] ボタンをクリックすると開始されます。詳細については、Quotes for Price and Availability (価格と在庫の照会) ポートレットと QPA ビジネス プロセスを参照してください。

この Query for Price and Availability ポートレットでは、購入担当者が QPA 要求に必要なデータをすぐに取り出せるように、Product Inventory ポートレットと Product Part Inventory ポートレットは、Inventory Summary ポートレットに置き換えられています。

サンプル アプリケーションに戻ったら、このツアー ガイドの「次のステップ」節の説明に必ず従ってください。ここでも説明しておきます。

Query for Price and Availability (価格と在庫の照会) ポートレットで、以下の操作を実行します。

次に、[QPA 要求の送信] ボタンをクリックします。

以下のエラーが表示される場合は、値を入力し直してから、[QPA 要求の送信] ボタンをクリックしてください。

次のステップ

まだ注文を入力していない場合は、必要な数量を入力します。次に、製品部品の単価としてたとえば「50」と入力します。また、商品を受け取りたい日付を入力します。たとえば、今日から 1 週間後の日付を入力します。次に、[QPA 要求の送信] ボタンをクリックしてツアーを続けます。

 


Quotes for Price and Availability (価格と在庫の照会) ポートレットと QPA ビジネス プロセス

最初に、ステップ 4 のポートレットである Quotes for Price and Availabilty で、サプライヤから見積もりが届くまでにしばらく時間がかかる可能性があることを伝えるメッセージが表示されます。


 

[見積を確認] ボタンを何回かクリックすると、最後には、サプライヤからの見積もりがポートレットに表示されます。この処理は、WebLogic Portal のポータル フレームワークと、WebLogic Integration によって管理される企業間 (B2B) 対話との統合の例を示すものです。


 

QPA ビジネス プロセスの技術詳細

この節では Query for Price and Availability (QPA) のビジネス プロセスに焦点をあてて説明します。このビジネス プロセスは、前のステップ 3 のポートレットで [QPA 要求の送信] ボタンをクリックすると開始されます。

pix1000 カメラの pixlens1000 部品が不足しているので、Avitek の購入担当者は、この部品の QPA メッセージを選択したサプライヤに送信します。次の図に、QPA ビジネス プロセスのイベント フローを示します。

QPA ビジネス プロセスのプロセス フロー


 

以下に、上の図で示したイベントを順に要約します。

  1. バイヤが QPA を作成します。

  2. QPA がサプライヤに送信されます。

  3. サプライヤは QPA を処理し、応答を生成します。

  4. バイヤは、サプライヤからの応答を収集し、結果をまとめます。

注意: 上の図では、高レベルから見た QPA ビジネス プロセスを示しています。両サイドのプロセスは、バプリック (コラボレイティブ) ワークフローとプライベート ワークフローによって実行されます。

以下の表に示したワークフロー テンプレートは、このサンプル QPA プロセスで使用されています。

表3-2 QPA プロセス ワークフローのテンプレート

ロール

パブリック/プライベート

ワークフロー名

バイヤ

プライベート

E2E_BuyerQPAPrivate

バイヤ

パブリック

E2E_BuyerPOPublic

サプライヤ

パブリック

E2E_SupplierPOPublic

注意: シナリオに登場する両方のサプライヤは、同じパブリック ワークフローを使用します。

サプライヤ

プライベート

E2E_SupplierOnePOPrivate

サプライヤ

プライベート

E2E_SupplierTwoPOPrivate


 

WebLogic Integration は、取引相手とのビジネスに関する会話、および提携契約を管理し、バイヤとサプライヤ間のビジネス メッセージの交換を自動化します。ワークフローは、提携契約および会話で参照されます。

このサンプルでは、JSP と JSP タグ ライブラリを使用して QPA プロセスを開始し、QPA 要求と応答データを表示します。次の図に、QPA ビジネス トランザクションに関わる取引相手間のデータ フローを示します。

QPA ビジネス プロセスのデータ フロー


 

以下に、イベントを順に示し、取引相手間のデータ フローとワークフローについて要約します。

  1. QPA フォームを含むポートレットは、QPA 要求を JMS キューに送信し、E2E_BuyerQPAPrivate ワークフローをトリガします。

  2. E2E_BuyerQPAPrivate ワークフローは、E2E_BuyerQPAPublic ワークフローを呼び出し、QPA 要求 XML ドキュメントに渡します。次に、QPA 会話が開始します。

  3. E2E_BuyerE2E_Hub との間の提携契約に基づき、E2E_BuyerQPAPublic ワークフローは、QPA 要求 XML を XOCP メッセージにパックし、これを E2E_Hub に送信します。

    注意: E2E_Hub は、メッセージを受け取ると、提携契約のプロキシ サプライヤとして機能します。

  4. E2E_Hub は、各サプライヤとの登録済み提携契約に基づいて、指定された取引相手、E2E_SupplierOneE2E_SupplierTwo にメッセージを転送します。

    注意: この手順では、E2E_Hub はロールを変更し、サプライヤとの提携契約においてプロキシ バイヤとなります。

    各サプライヤのパブリック ワークフローは、XOCP メッセージを受け取ることによりトリガされます。このシナリオでは、E2E_SupplierOneE2E_SupplierTwo はパブリック ワークフロー (E2E_SupplierQPAPublic) を共有します。パブリック ワークフローは、メッセージから QPA 要求 XML ドキュメントを抽出します。

  5. E2E_SupplierQPAPublic ワークフローは、各サプライヤに対するプライベート ワークフローを呼び出し、QPA 要求 XML ドキュメントをプライベート ワークフローに渡します。

  6. 各サプライヤのプライベート ワークフローは、独自の QPA 応答 (XML ドキュメント) を作成し、これをパブリック ワークフローの戻り変数に添付します。

  7. E2E_SupplierQPAPublic ワークフローは、QPA 応答 XML ドキュメントを抽出し、これを XOCP メッセージにパックしてバイヤに送信します。

    E2E_HubE2E_Buyer の送信プロキシとして機能していることを確認します。サプライヤが、(E2E_Hub と各サプライヤとの間の提携契約に基づいて) 応答メッセージを E2E_Hub に送信すると、E2E_Hub はプロキシ バイヤとして機能します。

    次に、E2E_HubE2E_Buyer との間の提携契約に基づき、E2E_Hub はロールをプロキシ サプライヤのロールに変更し、応答メッセージをバイヤ (E2E_Buyer) に転送します。

  8. バイヤのパブリック ワークフロー (E2E_BuyerQPAPublic) は以下のとおりです。

  9. バイヤのプライベート ワークフロー (E2E_BuyerQPAPrivate) は、統合された QPA 応答 XML ドキュメントを受け取り、それを XML ファイルに書き込みます。JSP は XML を解析し、統合された QPA 応答を Web ブラウザに表示します。

    この手順で、QPA ビジネス プロセスは終了です。

このプロセスの詳細については、WebLogic Integration のドキュメントを参照してください。

次のステップ

Quotes for Price and Availability ポートレットで、見積もりがサプライヤから返ってこない場合は、再度 [見積を確認] ボタンをクリックします。見積もりが返ってきたら、いずれかの見積もりを受理し、[注文の作成] ボタンをクリックしてツアーを続けます。

 


Purchase Order for Review ポートレットと PO ビジネス プロセス

Purchase Order for Review ポートレットを表示するには、下にスクロールしなければならない場合があります (ステップ 5)。このポートレットには、注文商品と購入商品の簡単な一覧が表示されます。


 

PO ビジネス プロセスの技術詳細

この節では、Purchase Order ビジネス プロセスに焦点をあてて説明します。このビジネス プロセスは、ユーザ (Avitek の購入担当者) が Purchase Order for Review ポートレットの [注文の送信] ボタンをクリックすると開始されます。このポートレットには、注文商品と購入商品の簡単な一覧が表示されます。

Purchase Order ビジネス プロセスのプロセス フロー


 

以下に、上の図で示したイベントを順に要約します。

  1. バイヤは注文書 (PO) を作成します。

  2. バイヤは選択したサプライヤにこの注文書 (PO) を送信します。

  3. サプライヤは、PO を受け取り、XML ベースの PO をバイナリ データ ファイルに変換します。このサンプルでは、サプライヤの注文管理システムが、バイナリ ファイルを受け取って、注文を処理することを前提としています。

  4. サプライヤは、別のバイナリ データ ファイルに基づいて、XML ベースの PO 確認書を生成します。

  5. サプライヤはバイヤに PO 確認書を送信します。

  6. バイヤは PO 確認に基づいて PO 情報を更新します。

注意: 上の図では、高レベルから見た PO ビジネス プロセスを表示しています。両サイドのプロセスは、バプリック ワークフローとプライベート ワークフローによって実行されます。

以下の表に示したワークフロー テンプレートは、このサンプル QPA プロセスで使用されています。

表3-3 QPA プロセス ワークフローのテンプレート

ロール

パブリック/プライベート

ワークフロー名

バイヤ

プライベート

E2E_BuyerQPAPrivate

バイヤ

プライベート

E2E_BuyerPOPrivate

バイヤ

パブリック

E2E_BuyerPOPublic

サプライヤ

パブリック

E2E_SupplierPOPublic

注意: シナリオに登場する両方のサプライヤは、同じパブリック ワークフローを使用します。

サプライヤ

プライベート

E2E_SupplierOnePOPrivate

サプライヤ

プライベート

E2E_SupplierTwoPOPrivate

このサンプルの PO 実装では、WebLogic Integration を使用してアプリケーション統合、データ統合、ビジネス プロセスの管理を行います。この節では、PO ワークフロー (バックエンド アプリケーションと異種データ形式との統合など) について説明します。

以下の図に、PO ビジネス プロセスに関わる取引相手間のデータ フローを示します。

PO ビジネス プロセスのデータ フロー


 

以下に、イベントを順に示し、取引相手間のデータ フロー、ワークフロー、およびバックエンドのシステムについて要約します。

  1. PO ビジネス プロセスは、このシナリオのバイヤが Purchase Order for Review ポートレットの [注文の送信] ボタンをクリックすると開始されます。

    この PO は XML メッセージの形式で、BPM JMS キューに送信されます。

  2. XML イベントにサブスクライブするバイヤのプライベート ワークフロー (E2E_BuyerQPAPrivate) が、イベント通知によって呼び出されます。

    E2E_BuyerQPAPrivate ワークフローは、E2EAppView.sav アプリケーション ビューの insertPO サービスを呼び出し、PO 情報をエンタープライズ情報システム (EIS) に挿入します。EIS は、このサンプルでは、RDBMS によってシミュレートされます。E2EAppView.sav アプリケーション ビュー、およびそのサービスとイベントは、サンプルをセット アップするときに、WebLogic Integration にコンフィグレーションおよびデプロイされます。

  3. EIS は、PO 情報を含むイベントを WebLogic Integration プロセス エンジンに送信します。

    アプリケーション ビューのイベントは、PO プロセス (E2E_BuyerPOPrivate) のバイヤのプライベート ワークフローをトリガします。

  4. E2E_BuyerPOPrivate ワークフローは、バイヤのパブリック ワークフロー (E2E_BuyerPOPublic) を開始します。

  5. E2E_BuyerPOPublic は、サプライヤのパブリックワークフロー (E2E_SupplierPOPublic) に XOCP メッセージを送信します。この手順により PO 会話が開始されます。

    E2E_Hub は、E2E_Buyer との間の登録済み提携契約に基づいて、指定された取引相手、E2E_Buyer にメッセージを転送します。

    注意: この手順では、E2E_Hub はロールを変更し、バイヤとの提携契約においてプロキシ サプライヤとなります。

  6. サプライヤ サイドでは、サプライヤのパブリック ワークフロー (E2E_SupplierPOPublic) のインスタンスは、サプライヤが XOCP メッセージを受け取ると起動します。

    E2E_SupplierPOPublic ワークフローは、選択したサプライヤのプライベート ワークフロー (E2E_SupplierOnePOPrivate または E2E_SupplierTwoPOPrivate) を開始します。

  7. 選択したサプライヤのプライベート ワークフローは、以下のとおりです。

  8. サプライヤのプライベート ワークフローは PO 確認書の XML データを E2E_SupplierPOPublic ワークフローに返します。

  9. E2E_SupplierPOPublic ワークフローは、PO 確認情報を XOCP メッセージにラップし、それをバイヤのパブリック ワークフロー (E2E_BuyerPOPublic) に送ります。

  10. E2E_BuyerPOPublic ワークフローは XOCP メッセージを受け取り、XML コンテンツを抽出して、XML イベントをバイヤのプライベート ワークフロー (E2E_BuyerPOPrivate) に送ります。

    この手順で、PO 会話は終了です。

  11. E2E_BuyerPOPrivate ワークフローは、WebLogic Integration が提供するアプリケーション統合フレームワークを使用して、EIS 内の PO 情報を PO 確認書のデータに基づき更新します。また、ワークフローは、PO 確認情報を POAcknowledgement.xml ファイルに書き込みます。

  12. 次に、WebLogic Portal は、POAcknowledgement.xml ファイルを読み込み、そのコンテンツを Order History ポートレットなどの適切なポートレットに表示します。

    この手順で、PO ビジネス プロセスは終了です。

このプロセスの詳細については、WebLogic Integration のドキュメントを参照してください。

次のステップ

ツアーを続けるには、[注文の送信] ボタンをクリックして、注文をサプライヤに送信してください。

 


Purchase Order History ポートレット

[Order History] ページの最初の画面には、Purchase Order History ポートレットの要約ビューが表示されます。サンプル アプリケーションのデータには、既存の注文がいくつか含まれています。[注文履歴の詳細表示] ボタンをクリックすると、同じポートレットのさらに詳細なビューが表示されます。


 

[注文状況の確認] ボタンをクリックし、サプライヤから返された注文の受付確認をチェックできます。最初、画面は次のように表示されます。


 

[注文状況の確認] を数分後にクリックすると、画面が更新され、送信した注文とその配送日の 2002 年 8 月 29 日が以下のように表示されます。


 

Purchase Order History ポートレットの技術詳細

[Order History] ページの Purchase Order History ポートレットでは、各注文 (P.O.) に対する Acknowledged (受付確認済)、Shipped (配送済)、または Received (受領済) の各ステータスと関連情報が表示されます。送信したばかりの P.O. は、サプライヤから受付確認が返され、さらにユーザが [注文状況の確認] ボタンをクリックするまでは、このポートレットに表示されません。

注文書を送信したばかりで、Purchase Order History ポートレットにまだ表示されていない (ステータスが保留中の) 場合には、[注文状況の確認] ボタンをクリックしてください。

プロセスを高レベルで見ると、サプライヤから返された受付確認を受け取るのは、Purchase Order ビジネス プロセスでの最後から 2 番目のステップとなります。最後のステップは、バイヤ (Avitek) が P.O. 受付確認に基づいて P.O. 情報を更新するステップです。この Purchase Order ビジネス プロセスは、Purchase Order Review ポートレットの「技術詳細」の節で図を使って説明されています。

また、[Order History] ページでは、[注文履歴の詳細表示] ボタンをクリックして、注文とそのステータスの詳細を表示できます。ポートレットの詳細表示で、[注文状況の確認] ボタンをクリックすると、ステータスを確認できます。それでもまだ注文が保留中の場合は、ポートレットにより次のメッセージが返されます。「この注文の受付通知をまだ受け取っていません。」

詳細表示された Purchase Order History ポートレットで [注文履歴の概要に戻る] ボタンをクリックすると、ポートレットは一覧表示に戻ります。

企業間 (B2B) ポータル ツアーの完了

これで企業間 (B2B) ツアーは終了です。オンライン ツアーの場合、[ログアウ
ト] ボタンをクリックすると、サンプルの [はじめに] ページに戻ることができます。ログアウトすると、このセッションで行った注文はまったくデータベースに保存されないことに注意してください。つまり、Jason Tang として再びログインしたときには、在庫水準は元の値にリセットされます。

 

ページの先頭 前 次