B2Cマッシュアップインターフェイスの実装

同じルールで、Create a case マッシュアップアクションまたはDisplay a page マッシュアップアクションを使用して連絡先を一意に識別できます。 唯一の検討事項は、マッシュアップに関連付けられた連絡先の識別コードを具象FSG-Data-Contactクラスに適用するか、あるいは新しい抽象-SelfServiceクラスを新しいルールセットに定義し、そのクラスがFSG-Data-Contactのパターンを継承するようにするかです。

上位レイヤーのアプリケーションで作成されたケースを連絡先が承認するための共通の方法をエンタープライズレイヤーで開発することは、簡単とはいえませんが不可能ではありません。 なお、D_pxCaseDetailデータページでは、Work-クラスをCaseClass パラメーターで指定したクラス名に変更できます。 しかし、この場合、D_pxCaseDetailをソースとするセクションを表示するにはどのようにしたらよいのでしょうか。 また、D_pxCaseDetail's CaseClassおよびCaseIDパラメーターに供給される値が、一意に識別される連絡先専用に取得されるようにするにはどのようにしたらよいのでしょうか。

セクションを動的に表示するには次の2つの方法があります。

1. Work- エンタープライズレベルでセクションをスタブアウトし、ケースタイプクラス内で上位レイヤーのアプリケーションにそのセクションを名前で上書きさせる。
2. テンプレート化されていないWork-pyApprovalセクションで示されているように、.pyApprovalSectionNameを使って、埋め込みセクションに名前を動的に付ける。

オプション1：新しいクラスとルールセット、または既存のクラスとルールセット

-SelfServiceクラス名の拡張は、抽象化できるため、理にかなっています。 TrueFalseのAuthenticatedプロパティは、FSG-Data-Contactではなく、その抽象-SelfServiceクラスに追加するのが理にかなっています。なぜなら、Authenticatedプロパティの値は、オンラインのときにのみtrueになるからです。 プロパティルールの「Advanced 」タブでは、「Do not save property data」チェックボックスにチェックを入れることができます。つまり、AuthenticatedプロパティをFSG-Data-Contactに適用し、永続化されないようにします。 しかし、メンテナンス上の理由から、プロパティはその存在目的と一致するクラスに適用されるべきです。 また、FSG-Data-Contact-SelfServiceクラスを別のルールセットで作成することにもメリットがあります。 連絡先セルフサービスに使用されるルールを見つけたい場合は、ContactSelfServiceルールセットを参照してください。

具象ベースのクラスを抽象クラスで拡張することは簡単ではありません。 FSG-Data-Contact-SelfServiceクラスは、FSG-Data-ContactSavePlanアクティビティを実行するだけで、FSG-Data-Contactでデータを永続化できます。 FSG-Data-Contact-SelfServiceで定義されたプロパティはFSG-Data-Contact,にとって未知なので、永続化されません。

では、逆の場合はどうでしょうか。 FSG-Data-Contact-SelfServiceクラスには、Contact用のpyGUIDが供給されます。 SelfServiceクラスはD_Contactデータページのソースとしてデータベース検索を使用できますが、SelfServiceクラスに各プロパティを一つずつ設定せずにプロパティを吸収するには、どのようにしたらよいでしょうか。 SelfService クラスのpxObjClassプロパティ値はそのままにしておく必要があります。

解決策としては、アクティビティでPAGE-Merge-Intoメソッドを活用する方法があります。 最初のステップで、PrimaryページのpxObjClassがparam.ObjClassNewに設定されます。 2番目のステップは、Page-Merge-Intoです。 3番目のステップ、Page-Change-Classは、PrimaryページのpxObjClassの値を復元するために使用されます。

オプション2：ダイナミックケースのセクション表示

テンプレート化されたセクションは、pyApprovalSectionNameなどの埋め込みセクションを名前で動的にレンダリングするプロパティをサポートしていません。 唯一の方法は、ContactSelfServiceApprovalなどの一般的なスタブアウトされたセクション名を使用することです。

特定の名前を持つスタブアウトセクションを使用しなければならないという制約により、セルフサービスマッシュアップの設計は各ケースタイプに対して1種類の承認しかできないという制限があります。しかし、これは本当に制限といえるでしょうか。 複数のケースタイプのステージで顧客に決定を承認または却下してもらうことは現実的ではありません。 FSGの現在のニーズには、BookEventケースのQuotationステージまでのセルフサービスを提供するというものがあります。 Quotationステージより後のステージでは、エグゼクティブやイベントマネージャーなど、他のFSGのペルソナが参加します。 これらのステージでは、顧客は関与する必要がありません。

オプション3：CaseClassとCaseID情報のソースおよびContactに限定する方法

外部の担当者に関連付けられたケースをその担当者にレビューしてもらいたいとします。 担当者がそのインテントを発見できるような方法で、このレビューのインテントをケースで永続化する方法が必要です。 エンタープライズレイヤーからは、それらのケースタイプが何であるかまったく知ることができません。 それぞれのケース専用のマッシュアップインターフェイス用に固有のソリューションのコードを書くことは可能ですが、それはソフトウェア開発の正しい方法ではありません。

レビューがリクエストされている連絡先にケースを表示するには、エンタープライズレベルでデータクラスを定義する方法が最良です。 FSGアプリケーションでは、FSG-Data-ContactIssuedApproval クラスがContactSelfServiceルールセットに追加されます。 このクラスのプロパティは、ApprovalType、Approved、CaseClass、CaseRef、ContactRef、LinkText、WaitingForContactInputです。 ケースは、このクラスのインスタンスを生成して永続化し、ワークキューの割り当てで、担当者がケースをレビューするのを待ちます。 担当者は、Approved をtrueに変更するか、値をfalseのままにしてサブミットします（falseはRejectedを意味する）。 担当者の承認または却下の決定をサブミットするときに、最初はtrueに設定されていたWaitingForContactInputプロパティはfalseに設定されます。 

Display a pageマッシュアップインターフェイス内で、特定された担当者はFSG-Data-ContactIssuedApproval インスタンスのリストを表示できます。このとき、ContactRefプロパティは連絡先のGUIDと等しく、WaitingForContactInputはtrueと等しくなります。 D_CaseDetailデータページは、CaseClassとCaseRefの値を使用して、BookEventケースのスタブアウトされたエンタープライズレイヤー定義済みのWork- ContactSelfServiceApprovalセクションの、ContactSelfServiceApprovalセクションオーバーライドを表示するための適切なコンテキストを設定します。 LinkTextは、承認内容の簡潔な説明です。 リンク制御を使用する必要はありません。 ContactIssuedApprovalインスタンスを表示するテーブルレイアウトは、代わりにMaster/Detailオペレーション用に構成できます。 行をクリックすると、モーダルダイアログが起動します。

FSGSampleディレクトリ

FSGSample.zipファイルは、次の画像のようにRule-File-Binaryルールからダウンロードされます。

FSGSample.zipファイルは../tomcat/webapps ディレクトリに展開し、<span> the  the  </span><cite>http://:/FSGSample/</cite>を使用してアクセスできます。 Pega Platform™ Personal Editionは、prwebウェブアプリを削除すると、非常に高速に起動します。 「FSG Sample」という名前のブックマークを作成し、ウェブアプリのURLを保存しておくことができます。

ただし、これは必要ではありません。 解凍したPASampleディレクトリ内のHTMLファイルは直接開くことができます。 TomcatなどのWebサーバーからのアクセスでは、index.htmlファイルが最初に開かれます。 ただし、case1.htmlとcase2.html を直接クリックすることもできます。

Dev StudioまたはApp Studioのマッシュアップインターフェイス構成ビューは、case1.htmlファイルとcase2.htmlファイルにマッシュアップコードを生成しました。 BookingEventCustomer anonymous Authentication ServiceのURLは、「Generate Mashup code」ボタンをクリックする前に、「URL」フィールドにコピーされます。 https://と/prweb/PRAuth/BookingEventSelfServiceの間の:情報は、Bookingアプリケーションがインストールされているサーバーに変更します。

背景画像ファイルbg.pngは、FSGSample/imagesディレクトリにあります。

コンタクト発行承認の仕組み

FSGアプリケーションにログインします。 なお、FSG-Data-Contact-SelfServiceの「Approvals 」セクションは、「RegisterContact 」セクションのタブとして表示されていることに注目してください。

「Approvals 」セクションには、テンプレート化されていない「PendingApprovals」セクションが埋め込まれています。 「PendingApprovals 」セクションには、 FSG-Data-ContactIssuedApproval インスタンスのリストを表示するテーブルレイアウトがあります。 D_PendingApprovalListリストデータページはContactGUIDパラメーターをPendingApprovals レポートディフィニッションを介して渡します。これにより、 FSG-Data-ContactIssuedApproval 行が、ContactRef = param.ContactGUIDとWaitingForContactInput = trueでフィルターされます。

「PendingApprovals」セクションのテーブルレイアウトは、Master/Detailオペレーター用に構成されています。 LinkTextプロパティの値が表示されている行をクリックすると、ダイアログボックスにShowWaitingApprovalフローアクションが表示されます。 「ShowWaitingApproval」セクションの上部には、「ContactSelfServiceApproval」という埋め込みセクションがあります。 埋め込みセクションはD_CaseDetail[pyID:.CaseRef,CaseClass:.CaseClass]をソースとしています。

「ShowWaitingApproval」セクションの下部には、「ApprovalButtons」という埋め込みセクションがあります。 「Approve」ボタンをクリックすると、EnterDecisionデータトランスフォームが実行され、decisionパラメーターの値として「Approve 」が渡されます。 「Reject」ボタンをクリックすると、同じトランスフォームに「Reject」が渡されます。

EnterDecisionデータトランスフォームでは、Approvedプロパティの値がデシジョンパラメーターの値に応じて適切に設定され、続いてWaitingForContactInputがfalseに設定されます。

最後に、EnterDecisionデータトランスフォームにより、FSG-Data-ContactIssuedApproval クラスで定義されているSavePlanアクティビティが実行され、続いてにコミットされます。

BookingアプリケーションQuoteセルフサービスマッシュアップインターフェイス

セルフサービス見積もり機能は、顧客登録と一意の本人確認プロセスを除き、すべてBookingアプリケーションレベルで実装されています。

表面的には、BookEvent ケースタイプルールの状況設定であるpyCreatedByChannel = Mashup内で、Quotation複数ステッププロセスだけがQuestionステージからCreateステージに移動したように見えます。

PostCaptureCustomer データトランスフォームは、pyIsMashup状況設定テンプレートを使って状況設定されます。 違いはほとんどありません。 ベースルールでは、 D_ContactEditable.pyGUIDから .CustomerGUIDが取得されます。 状況設定ルールでは、D_ContactSelfServiceEditable.pyGUIDから.CustomerGUIDが取得されます。

また、「 PostCaptureCustomer」セクションと「EditEventDetails」セクションも、pyIsMashup状況設定テンプレートを使用して編集できます。 これらのセクションをそれぞれPostCaptureCustomerBaseとEditEventDetailsBaseに保存すると、元の2つのセクションに変更を加えて2つのセクションを埋め込み、表示権限でそれらのセクションの表示方法を制御できます。

Bookingアプリケーションセルフサービス承認マッシュアプインターフェイス

実質的にすべての作業がエンタープライズレベルで実装されているため、Bookingアプリケーションレベルでセルフサービス承認マッシュアップインターフェイスを定義する必要はほとんどありません。 唯一必要なものは、「ContactSelfServiceApproval」セクションのオーバーライドが実際のデータを表示するレベルに達するアプリケーションスタックだけです。

Display a pageマッシュアップインターフェイスにより、FSG-Data-Contact-SelfServiceクラスに適用される、エンタープライズデファインドRegisterContactハーネスが開きます。 「ContactSelfServiceApproval 」セクションのFSG-Booking-Work-BookEvent オーバーライドにより、「CustomerQuoteReview」というセクションが埋め込まれます。 名前が示すとおり、この読み取り専用セクションには、コストや利益は表示されません。 ただし、「DiscountPercentage」フィールドは表示されます。セールスエグゼクティブはこのフィールドを操作できますが、顧客は操作できません。 セールスエグゼクティブは、セルフサービスの顧客に承認をリクエストする前に、その顧客に割引を提供するかどうか決定できます。

セールスポータル

2つのマッシュアップインターフェイスとは直接関係ありませんが、セールスエグゼクティブペルソナのカスタムポータルが顧客のセルフサービスを促進するという点は重要です。

BookEventActiveQuotesハーネスは、Salesハーネスに埋め込まれています。さらに後者は、BookingSales ポータルに表示されます。 この3つのルールは、すべて次に適用されます。 FSG-Booking-UIPages.

BookEventActiveQuotesContentセクションには、BookEventActiveQuotesListというテンプレート化されておらず、D_BookEventQuotationStageListをソースとするテーブルレイアウトを持つセクションが埋め込まれていますが、このセクションにはパラメーターがありません。 

そのリストデータページは、QuotationStageBookEventというレポートディフィニッションのソースとなっています。 レポートディフィニッションでは、QuotationステージにあるすべてのBookEventケースがクエリーされます。 このレポートは、ContactIssuedApproval CaseRef = BookEvent pyIDによって、 FSG-Data-ContactIssuedApproval に結合されます。 顧客が見積もりを承認したかどうかを表示するには、この結合が必要です。 

Approved = trueの場合、セールスメンバーは、そのままBookEventケースを続行できます。 そうでない場合、セールスメンバーは顧客に連絡を取るか、14日後にワークキューの割り当てがタイムアウトするのを待ちます。