| Oracle SOA Suiteクイック・スタート・ガイド 10g（10.1.3.1.0） B31832-01 |
|
 前へ |
 次へ |
この章では、SOA Order Bookingアプリケーションの使用方法について説明します。 Webクライアントに関する3つの異なる注文シナリオと、SOA Order Bookingビジネス・フローを介した注文プロセスの監視方法についても説明します。
項目は次のとおりです。
このシナリオでは、事前定義されたユーザーskingとして、$1000を超える注文を発行し、その注文が処理される様子を監視します。 デフォルトでは、skingような「Gold」ステータスの顧客による$1000を超える注文には、手動による承認が必要です。 この承認は、承認権限を持つGlobal Companyの社内スーパーバイザーであるjcooperにルーティングされます。
このシナリオでは、次のタスクを実行します。
$1000を超える注文の場合、Order Booking BPELプロセス（SOAOrderBooking）は、注文を入力した人のマネージャにメッセージをルーティングするためにヒューマン・ワークフローを起動します。 ここでは、Oracle BPELワークリスト・アプリケーションを介して、承認がjcooperにルーティングされます。
ワークリスト・アプリケーションを起動する手順は、次のとおりです。
「スタート」→「すべてのプログラム」→「Oracle - Oracle - soademo」→「Oracle BPEL Process Manager」→「Worklist Application」の順に選択します。
プロンプトが表示された場合は、「ユーザー名」フィールドに「jcooper」、「パスワード」フィールドに「welcome1」と入力します。
jcooperは、定義済のOracle BPEL Process Manager管理者です。
「ログイン」をクリックします。
「ユーザー・タスク」タブに、現在割り当てられているワークリスト・タスクがないことが示されます。
今後のタスクで必要になるため、ワークリスト・アプリケーションは実行中のままにします。
注文プロセスは、ユーザーが参照して製品を注文するWebクライアントアプリケーションから開始されます。 このWebアプリケーションによって、Order Booking ESB（OrderBookingESB）フローが開始され、SOAOrderBookingプロセス・フローが起動されます。 BPELフローによって、実際の注文プロセスが処理されます。
新規の注文を発行するには、Webクライアントを次の手順で実行します。
次のURLを指定します。
http://localhost:8888/soademo
Webクライアント用のApplication Loginページが表示されます。
「Email」フィールドに「sking@soademo.org」、「Password」フィールドに「welcome1」と入力します。
skingは、事前定義された「Gold」ステータスのユーザーです。 「Gold」ステータスの顧客の場合、$1000を超える注文に対して手動による承認が必要です。
「Login」をクリックします。
ようこそページが表示されます。
「Browse products and create a new order」リンクをクリックします。
Browse and Select Itemsページが表示されます。
「Next 10」をクリックし、「Ipod Mini 2 Gb」を選択します。
「View Details」をクリックします。
Item Detailsページが表示されます。 製品に関する詳細情報が表示されます。ユーザーは、数量を選択し、その製品をカートに追加できます。
「Quantity」リストから「10」を選択し、「Add to cart」をクリックします。
「Go to Shopping Cart」をクリックします。
Shopping Cart Contentsページが表示されます。
「Place Order」をクリックし、注文を発行します。
ようこそページが更新され、「Order Submitted」メッセージが表示されます。
注文を発行した後、メッセージは、SOAOrderBookingプロセスを開始したOrderBookingESBに送信されています。 そのBPELプロセスの進行状況は、Oracle Enterprise Manager 10g BPEL Control（Oracle BPEL Control）から監視できます。
SOAOrderBookingプロセスのモニターを表示する手順は、次のとおりです。
「スタート」→「すべてのプログラム」→「Oracle - Oracle - soademo」→「Oracle BPEL Process Manager」→「BPEL Control」の順に選択して、Oracle BPEL Controlにログインします。
プロンプトが表示された場合は、「ユーザー名」フィールドに「oc4jadmin」、「パスワード」フィールドに「welcome1」と入力します。
Oracle BPEL Controlの「ダッシュボード」タブが表示されます。 「名前」列には、このサーバーにデプロイされているすべてのBPELプロセスがリストされます。 これらのプロセスをクリックすることで、テストの目的でプロセスを起動する管理アクティビティを実行できます。 ここでは、これらのプロセスのうち、実行中の特定インスタンスを表示します。
このタブには、すべてのインスタンスがリストされます。 緑色のチェックマークが付いたインスタンスは完了しています。付いていないインスタンスは進行中です。 発行した注文は、完了していません。
「最終更新日時」列のタイムスタンプを使用して、SOAOrderBookingの最新インスタンスを検索し、「インスタンス」列の「nnn : Instance #nnn of SOAOrderBooking」（nnnは特定の番号）をクリックしてインスタンスを選択します。 以前に他の注文が発行されている場合は、複数のインスタンスが表示されます。
リンクが表示されない場合は、ページをリフレッシュします。 サーバーの起動後、BPELプロセスを初めて実行する際は、すべてを初期化する必要があるため、サーバーの速度が低下することがあります。
選択したインスタンスのインスタンス情報が表示されます。 インスタンスでは、様々なタスクおよび処理を実行できます。
このインスタンスを視覚的に表現するには、「フロー」サブタブをクリックします。
このビューを使用すると、プロセスの進行状況を表示できます。
フローの各アイコンは、アクティビティと呼ばれます。 アクティビティをクリックすると、その詳細を表示できます。
最初のアクティビティである、青色の円の「receiveInput」receiveアクティビティをクリックします。
アクティビティ監査証跡ウィンドウに、このアクティビティに関連付けられているXMLが表示されます。
この監査証跡には、クライアントのWebページからESBを介して取得されたBPELプロセス・インスタンスへのXML入力が表示されます。 次の点に注意してください。
CustIdの10: 注文を発行した顧客のIDを表しています。
EmailAddressのsking@soademo.org: ログインで使用した電子メール・アドレスを示します。
<OrderItems>要素: 注文した品目が表示されます。
使用されているXMLネームスペースが緑色のテキストで表示されます。これは無視してかまいません。
アクティビティ監査証跡ウィンドウを閉じて、フロー・ダイアグラムに戻ります。
「receiveInput」の下に、灰色のボックスの「InsertOrderIntoDB」が表示されます。このボックスには、複数のアクティビティが格納されています。 InsertOrderIntoDBは1つのスコープで、複数のアクティビティを論理的なチャンクにグループ化します。 これによりInsertOrderIntoDBのすべてのアクティビティは、データベースへの注文の書込みに関連付けられています。
「GetOrderId」invokeアクティビティをクリックして、アクティビティ監査証跡ウィンドウでXML情報を表示します。
invokeアクティビティは、サービスを起動するために使用します。 ここでは、この注文に対する一意の注文番号を生成するためにサービスがコールされます。 番号は、<order_seq_id_gen.nextval>要素に戻されます。 この番号が、生成された注文IDになります。
アクティビティ監査証跡ウィンドウを閉じて、フロー・ダイアグラムに戻ります。
「InsertOrder」invokeアクティビティをクリックして、アクティビティ監査証跡ウィンドウでXML情報を表示します。
このinvokeアクティビティは、データベースにレコードを実際に書き込むデータベース・アダプタを起動しています。 データベース・アダプタは、invokeアクティビティを使用して、この機能をサービスとして公開します。
アクティビティ監査証跡ウィンドウに表示されるXMLは、データベースに書き込まれるデータを示しています。 <ordid>は、前の手順で表示した番号に設定されていることを確認してください。 また、入力データから取得した他のデータも、このプロセスに受信されていることを確認してください。
アクティビティ監査証跡ウィンドウを閉じて、フロー・ダイアグラムに戻ります。
「CustomerService」スコープで、「GetCustInfo」invokeアクティビティをクリックします。
<customerServiceRequest>要素には、サービスにそのサービスの入力として渡されたデータが表示されます。 ここでの<custid>は、この注文を発行した顧客のIDである10です。
このサービスは同期（非同期ではなく）で起動されているため、入力と出力の両方が表示されます。
アクティビティ監査証跡ウィンドウを閉じて、フロー・ダイアグラムに戻ります。
「CreditService」スコープで、「InvokeCreditService」invokeアクティビティをクリックします。
ビジネス・プロセスの定義にはBPELが使用されることを思い出してください。 このサービスは、クレジット・カード情報を入力として取得し、クレジット・カードの有効性に応じて、trueまたはfalseを戻します。
このサービスは同期起動のため、リクエスト・データとレスポンス・データが表示されます。 リクエスト・データは、<validateRequest>要素内にあります。 前の手順で取得したクレジット・カード情報が発行されます。
<validateResponse>要素には、サービスによって、この顧客のクレジット・カードが有効であることを意味するtrueが戻されています。
アクティビティ監査証跡ウィンドウを閉じて、フロー・ダイアグラムに戻ります。
フロー・ダイアグラムの終わり近くにある「DecisionService」アクティビティまでスクロールします。
このデシジョン・サービス・アクティビティは、実行時の動的な決定に対してルール・エンジンを起動することを示しています。 以前に説明したように、この顧客が「Platinum」ステータスの顧客でないかぎり、$1000を超える注文には、マネージャの承認が必要です。 skingは「Gold」ステータスの顧客であるため、手動による承認が必要です。
「+」アイコンをクリックしてデシジョン・サービス・スコープを開き、「起動」アイコンをクリックします。これにより、ルール・エンジン・サービスが実際に起動されます。
<dsIn>要素には、サービスに送信された入力データが格納されています。 この要素内には、価格と顧客のステータスを示す<approve>というサブ要素が表示されます。 この情報は、デシジョン・サービスが決定を下すために必要です。
注文価格が$1000を超え、この顧客は「Platinum」ステータスの顧客ではないため、デシジョン・サービスは、承認が必要であることを示すtrueを戻します。 この戻り値は、<dsOut>要素内のサービスから表示できます。
<approvalRequired>true</approvalRequired>
後のタスクでは、この動作を変更するために、ビジネス・ルールを変更します。
アクティビティ監査証跡ウィンドウを閉じて、フロー・ダイアグラムに戻ります。
プロセス・フローの下部までスクロールし、「ApproveOrder」アクティビティをクリックします。
アクティビティ監査証跡ウィンドウには、XMLのかわりに、このヒューマン・ワークフロー・アクティビティに関する情報が表示されます。
「割当て先」フィールドで、このタスクがSupervisorグループに割り当てられていることに注意してください。
アクティビティ監査証跡ウィンドウを閉じて、フロー・ダイアグラムに戻ります。
次のタスクでは、承認権限があるユーザーに作業を引き継いで、この注文を承認します。
今後のタスクで必要になるため、Oracle BPEL Controlは実行中のままにします。
注文を承認するには、Oracle SOA Suiteのインストール時に提供されたワークリスト・アプリケーションを使用します。
Oracle SOA Suiteの理解が深まると、多機能なAPIを備えたワークフロー・エンジンを使用して、ユーザーが承認および管理タスクを実行できるように、独自のカスタムGUIを作成することもできます。
ワークリスト・アプリケーションを使用して注文を承認する手順は、次のとおりです。
ワークリスト・アプリケーションを実行しているブラウザに移動し、ブラウザの「リフレッシュ」ボタンをクリックします。
「ユーザー・タスク」タブには、Supervisorグループに割り当てられた注文の承認タスクが表示されます。jcooperは、そのグループに定義されたメンバーです。
ユーザーは、ワークリスト・アプリケーションを使用して、各自のタスク管理、エスカレーションの作成、タスクを自動的に処理するルーティング・ルールの設定、休暇中のタスクの処理方法を伝えるための休暇ルールの作成、レポートの実行などを行うことができます。 この機能のすべては、エンジンAPIに基づいています。 したがって、この機能は、作成したカスタマイズ画面に追加することもできます。
このタスクはグループに割り当てられているため、グループのユーザーにより取得されることが必要で、同時に複数のユーザーが変更を加えることはできません。
右側にある「アクション」リストから「申告」を選択し、「実行」をクリックします。
タスクの詳細ページが表示され、承認するかどうかの判断に役立つ注文の詳細が表示されます。 コメントまたは添付ファイルを追加できます。 このシナリオの場合、他のフィールドは編集できませんが、これはこのアプリケーションの場合のみです。 データ・フィールドは編集可能にできます。
ページの左上部にある「タスク・アクション」リストから「APPROVE」を選択し、「実行」をクリックします。
「ユーザー・タスク」タブが更新され、現在割り当てられているワークリスト・タスクがないことが示されます。
Oracle BPEL Controlブラウザ・ウィンドウに戻り、ブラウザの「リフレッシュ」ボタンをクリックします。
「インスタンス」タブの「フロー」ビューで、以前プロセスを中断した「ApproveOrder」ヒューマン・タスクまでスクロールします。
このタスクの下には、BPELプロセスが進行したことを示す多くのアクティビティがあることに注意してください。
「ApproveOrder」アクティビティをクリックし、ワークフロー情報を再度表示します。
アクティビティ監査証跡ウィンドウには、XMLのかわりに、このヒューマン・ワークフロー・アクティビティに関する情報が表示されます。
タスクで実行されたアクティビティの監査証跡を確認してください。 ここでは、簡潔な承認タスクでした。 ただし、高度なルーティング・ルールと承認チェーンを含む、非常に複雑なワークフロー・タスクも設定できます。 ワークフローの進行状況は、Oracle BPEL Controlまたはワークリスト・アプリケーションから監視できます。
アクティビティ監査証跡ウィンドウを閉じて、フロー・ダイアグラムに戻ります。
大きいスコープの「SelectSupplier」までスクロールします。
このスコープには、BPELがパラレルで実行できるタスクのフロー・アクティビティが格納されています。 ここでは、必要な品目を最も低い価格で販売できるパートナを判断するために、Rapid ManufacturerとSelect Manufacturerに依頼します。 あるパートナをコールしてレスポンスを待機し、次に、別のパートナをコールしてレスポンスを待機するのでは、意味がありません。 1つのレスポンスの遅れが、プロセスの遅延の原因になる可能性があります。
フロー・アクティビティを使用すると、BPELでは、これらのリクエストをパラレルで実行し、処理を続行する前にすべてのレスポンスを待機できます。 この場合、フローには2つのパラレル・グループがあります。
Rapid Manufacturerサービスは同期であるため、使用するinvokeは1つのみです。 Select Manufacturerサービスは非同期です。これは、レスポンスに比較的長い時間がかかる可能性があるためです。 非同期サービスは、同期サービスと同じ方法で起動されますが、戻されるデータは、receiveアクティビティを使用して受信されます。
「InvokeSelectManufacturer」invokeアクティビティをクリックして、アクティビティ監査証跡ウィンドウでXML情報を表示します。
アクティビティ監査証跡ウィンドウでは、起動されているサービスへの入力のみが表示されることに注意してください。 さらに、そのサービスに必要な最小限の情報である購入品目と数量のみが送信されます。 顧客の個人的なデータは外部パートナには送信されません。 パートナが見積りを提示するために必要な情報は、数量と品目のみです。
アクティビティ監査証跡ウィンドウを閉じて、フロー・ダイアグラムに戻ります。
「ReceiveSelectManufacturer」invokeアクティビティをクリックして、アクティビティ監査証跡ウィンドウでXML情報を表示し、「XML文書の表示」リンクをクリックします。
Select Manufacturerサービスから戻されたデータには、サプライヤの名前と価格が表示されています。 次の手順で、Rapid Manufacturerサービスから戻された価格と比較するため、この$1,200という価格を確認しておいてください。
XMLウィンドウを閉じ、アクティビティ監査証跡ウィンドウを閉じてフロー・ダイアグラムに戻ります。
「InvokeRapidManufacturer」invokeアクティビティをクリックして、アクティビティ監査証跡ウィンドウでXML情報を表示します。
<manufacturerRequest>要素内のサービスへの入力に注目してください。 ここでも、パートナが見積りを提示するために必要な情報のみが示されます。レスポンス・データは<rapidManufacturerResponse>要素内にあります。 Rapid Manufacturerサービスの値は$1,100で、Select Manufacturerよりも低い価格です。
アクティビティ監査証跡ウィンドウを閉じて、フロー・ダイアグラムに戻ります。
フロー・アクティビティの下にある「Switch」アクティビティを参照します。
BPELのswitchアクティビティは、他のプログラム言語でのif-then-else、case、switch文に類似しています。 ここで、switchアクティビティは2つの価格を比較して低い価格を選択します。
次のスコープの「PostFulfillmentReq」までスクロールします。
注文が承認され、製造パートナが選択されたので、ビジネス・プロセスの次のステップは、注文の履行です。これにより実際に製品が顧客に送られます。
SOAOrderBookingプロセスには、注文を適切な履行先にルーティングするのはFulfillmentESBであることが定義されています。 FulfillmentESBは、「PostFulfillmentReq」アクティビティによって起動されます。
「PostFulfillmentReq」アクティビティをクリックして、アクティビティ監査証跡ウィンドウでXML情報を表示し、起動されているESBを参照します。
ここで「ここをクリックして、ESBコンソールでこのインスタンスを表示します。」リンクをクリックすることもできますが、このシナリオでは、SOAOrderBookingプロセス・フローの表示を完了することが重要です。
アクティビティ監査証跡ウィンドウを閉じて、フロー・ダイアグラムに戻ります。
次のスコープの「SetFinalOrderStatus」と「NotifyCustomer」までスクロールします。
これらのスコープでは、データベースがサプライヤ情報によって更新され、注文の詳細を電子メールで顧客に送信する通知サービスが起動されます。
「callbackClient」invokeアクティビティまでスクロールします。
このアクティビティが最終ステップです。 BPELプロセスがあるときは、サービスもあることに注意してください。 サービスには、データを戻すサービスと戻さないサービスがあります。 ここでのBPELプロセスは、データを戻しません。 ただし、データを戻すBPELプロセスもあり、そのデータは最終アクティビティをクリックすることで表示できます。
Oracle Enterprise Manger 10g ESB Control（Oracle ESB Control）には、「スタート」→「すべてのプログラム」→「Oracle - Oracle - soademo」→「Oracle ESB」→「ESB Console」の順に選択してログインします。
プロンプトが表示された場合は、「ユーザー名」フィールドに「oc4jadmin」、「パスワード」フィールドに「welcome1」と入力します。
最初の画面には、使用可能なサービスとその定義が表示されます。 これらのサービスは、複数の論理グループにグループ化されています。
「OrderBooking」の下にある「OrderBookingProcess」をクリックします。
Oracle ESB Controlには、開始されたBPELプロセスが表示されます。 灰色のボックスの「OrderBooking」は、メッセージをルーティングするルーティング・サービスを表しています。 ここでは、ルーティング・サービスは、青色のボックスの「OrderBooking」で示された、BPELプロセスを開始する1つのメッセージのみをルーティングします。
「Fulfillment」の下にある「OrderFulfillment」をクリックします。
このサービスは、さらに複雑です。 メッセージは、注文を処理するSOAOrderBookingのBPELプロセスから来ます。 「OrderFulfillment」は、そのメッセージを「Shipment」ルーティング・サービスと「FulfillmentBatch」の2つ場所にルーティングします。 「FulfillmentBatch」は、夜間バッチ処理の履行注文すべてを格納するためのJMSキューです。
「Shipment」ルーティング・サービスは、適切な出荷サービスが使用されていることを確認します。 $500を超える注文では、Fedex（「FedexShipment」）が使用されます。 それ以外の場合は、USPS（「USPSShipment」）が使用されます。 Oracle ESBでは、コンテンツ・ベースのルーティングがサポートされているので、メッセージを調査し、その注文価格を使用してメッセージを適切な宛先にルーティングすることができます。
画面上部の右側にある「インスタンス」アイコンをクリックします。
リストの1番上のインスタンスをクリックします。
Fulfillmentフローが表示されます。 ESBサービスのランタイム・インスタンスと、メッセージが通ったパスが緑色で表示されます。 ここでは、「OrderFulfillment」が、「FulfillmentBatch」と「FedexShipment」サービスの両方を起動していることに注意してください。
USPS用の「Shipment」ルーティング・サービスのフィルタ・アイコン上にマウスを置きます。
「OrderPrice < 500」が表示されます。これは、このサービスが、注文価格が$500未満の場合に起動されることを意味します。この注文価格は$500以上だったため、このサービスは起動されず、灰色で表されています。
「Shipment」ルーティング・サービスのトランスフォーメーション・アイコンのいずれかの上にマウスを置きます。
このアイコンは、データ・トランスフォーメーションを表しています。 ESBがメッセージをFedexShipmentまたはUSPSShipmentにルーティングする場合、そのデータは特定の書式であることを想定しています。 データは、Global Companyの書式からターゲット・サービスが想定している書式に変換されます。 ここでは、その書式はXSLです。
XSLはXMLスタイルシートを表し、XMLデータ・トランスフォーメーションを実行する標準的な方法です。 XSLファイルは、JDeveloperまたはサード・パーティのツールを使用して作成できます。
Webクライアント、Oracle BPEL ControlおよびOracle ESB Controlの各ブラウザ・ウィンドウは、実行したままにします。
これらのアプリケーションは次のタスクで使用します。
第1.3項「SOA Order Bookingアプリケーションの概要」で説明したように、SOAOrderBookingプロセスは、デシジョン・サービスを使用して、注文に対して手動による管理者の承認が必要かどうかを判断します。 このデシジョン・サービスは、Oracle Rules Engineのルールを使用して、承認が必要かどうかを判断します。
このシナリオでは、SOA Order Bookingアプリケーションを再デプロイせずに承認金額を$1000から$2000に引き上げます。 $1000を超える注文を発行し、手動による承認なしでその注文が処理される様子を監視します。
このシナリオでは、次のタスクを実行します。
このタスクでは、Oracle Business Rules Rule Authorで承認金額を$1000から$2000に変更します。 Rule Authorを使用すると、ルールを作成または変更して、ルールとともに使用するビジネス・オブジェクトを記述するデータ・モデルを作成できます。
次のURLを指定して、Rule Authorを開きます。
http://localhost:8888/ruleauthor
プロンプトが表示された場合は、「ユーザー名」フィールドに「oc4jadmin」、「パスワード」フィールドに「welcome1」と入力します。
ようこそページが表示されます。
「リポジトリ・タイプ」に「File」を選択し、「ファイルの場所」を次の場所に設定します。
ORACLE_HOME¥j2ee¥home¥applications¥rules_default_SOAOrderBooking_1_0_DecisionService¥DecisionService-web¥WEB_INF¥repository¥sample_repository
「接続」をクリックします。
確認メッセージに、接続の詳細が表示されます。
「ロード」サブタブをクリックします。
ディクショナリをロード・ページが表示されます。
「既存のディクショナリ」リストから「OrderBookingRules」を、「バージョン」リストから「INITIAL」を選択します。
ディクショナリをロード・ページが表示されます。
「ロード」をクリックします。
確認メッセージに、ロードされたディクショナリの詳細が表示されます。
「ApproveOrderRequired」という単一のルール・セットが表示されます。このルール・セットには、「platinumMember」、「overLimit」および「belowLimit」の3つのルールがあります。
左側のマージンから「platinumMember」リンクを選択します。
「ルール」セクションには、「platinumMember」のルール定義が指定されています。 「if」セクションでは条件が指定され、「then」セクションではその結果が指定されています。 ここでは、顧客のステータスが「Platinum」の場合、「approvalRequired」はfalse（承認は不要）となります。
左側のマージンから「overLimit」リンクを選択します。
「ルール」セクションでは、価格が特定の制限を超え、顧客のステータスが「Platinum」でない場合は、承認が必要であることが指定されています。 この制限は、定数のAUTOMATED_ORDER_LIMITで指定されています。
左側のマージンから「belowLimit」リンクを選択します。
このルールでは、価格が特定の制限より低い場合は承認が不要であることが指定されています。 定数のAUTOMATED_ORDER_LIMITは、overLimitルールで使用されている定数と同じです。
ナビゲーション・ツリーには、使用可能な定義が格納された「定義」フォルダが表示されます。
「変数(1)」フォルダをクリックします。
変数サマリー・ページが表示されます。
「DM.AUTOMATED_ORDER_LIMIT」の横にある「編集」アイコンをクリックします。
「式」テキスト入力領域で、金額を1000から2000に変更します。
「適用」をクリックします。
確認メッセージに、更新ステータスが表示されます。
Rule Authorウィンドウの上部にある「ディクショナリの保存」をクリックします。
ディクショナリの保存を確認するプロンプトに対して、「保存」をクリックします。
確認メッセージに、ディクショナリの保存ステータスが表示されます。
Rule Authorウィンドウを閉じます。
注文を発行する手順は、次のとおりです。
ようこそページで、「Browse products and create a new order」リンクをクリックします。
Browse and Select Itemsページが表示されます。
「Next 10」リンクをクリックし、「Ipod Mini 2 Gb」を選択します。
「View Details」をクリックします。
Item Detailsページが表示されます。 製品に関する詳細情報が表示されます。ユーザーは、数量を選択し、その製品をカートに追加できます。
「Quantity」リストで「10」を選択し、「Add to cart」をクリックします。
「Go to Shopping Cart」をクリックします。
Shopping Cart Contentsページが表示されます。
「Place Order」をクリックし、注文を発行します。
ようこそページが更新され、「Order Submitted」メッセージが表示されます。
Oracle BPEL Controlブラウザ・ウィンドウに戻ります。
ブラウザの「リフレッシュ」ボタンをクリックします。
「ダッシュボード」タブには、手動による承認なしで完了したSelectManufacturerフローとSOAOrderBookingフローが表示されます。
