マッシュアップ

Pega Platform™は現在、マッシュアップインターフェイスを介してBusiness-to-Consumer（B2C）UXをサポートしています。 マッシュアップ画面の描画方法は、今後のリリースで変更される可能性があります。 マッシュアップ画面は現在、Theme Cosmosのハーネスおよびセクションの使用のみをサポートしています。 今後のリリースには、Cosmos Reactに基づくマッシュアップに類似した新しいチャネルインターフェイスが含まれる予定です。

マッシュアップはBusiness-to-Employee（B2E）にも使用できます。 ある会社の従業員がSalesforceを使用しているとします。 Salesforceを拡張すると、Pega Customer Decision Hub™で構築されたアプリケーションをはじめ、現在のPega Mashupインターフェイスを使用する他のアプリケーションを活用することができます（今後のリリースではCosmos Reactインターフェイスが使用されます）。

マッシュアップによってサポートされるアクションのタイプはいくつかあります。 顧客はケースワーカーではありません。 OperatorIDページは匿名のモデルオペレーターに関連しているため、「 Get Next Work 」や「Open assignment」などのアクションは適用されません。 ワークリストのアサインメントはすべてのマッシュアップユーザーに表示されるため、そのオペレーターがアサインメントを所有することはありません。 テーブルレイアウトを備えた組み込みのUIページセクションは、ワークバスケットアサインメントで一時停止されているケースへの読み取り専用アクセスを提供できます。

B2Cの場合、最適な2つのマッシュアップアクションは「Create a case 」と「Display a page」です。

「Create a case」アクションの場合、顧客によるデータ入力はアサインメントが存在しないCreateステージで行われます。 Createステージは、Data-Portalに適用されたハーネスに対して画面が表示されるという点で「Display a page」に似ています。 Pega Platformバージョン8.5より前のリリースでは、ユーザーは新しいハーネスを開発し、ケースタイプルールの「Settings」タブでケースタイプをテンポラリとして宣言する必要があります。

このDisplay a page アクションの場合、ハーネスは任意のデータクラスに対して定義できます。 この場合に使用するのに理にかなっている最適なデータクラスはPegaData-Contactを拡張します。 このデータクラスは -SelfServiceに付加を行うよう拡張できます。 PegaData-Contact-extending データクラスのインスタンスは、具体的な参照データとして永続化されます。 このクラスの -SelfService拡張機能は抽象的です。つまり、拡張機能が永続化されることはありません。

「Create a case」と「Display a page」が使用されているかどうかにかかわらず、データはケースBLOBの外部で永続化できます。 開発者は、任意のデータクラスのSave-DataPageメソッドを呼び出す「SavePlan」アクティビティを定義できます。 データクラスを問わず、ケースはそのケースのpyIDキーによって参照できます。

顧客が誰であるかを一意に識別する問題は、「Create a case 」または「Display a page 」のいずれかのアクションで発生します。 それ以外の場合、マッシュアップインターフェイスは、連絡先情報を含んだフォームの送信にすぎません。つまり、マッシュアップインターフェイスの使用は1回限りのセッションです。 連絡先情報を再入力することなく、顧客が誰であるかを繰り返し識別できるようにすることは、困難を伴いますが実行可能です。

マッシュアップを実装することの意味は、従業員以外の外部の連絡先ペルソナ（顧客など）が表示するのに適した画面を設計することだけではありません。 セキュリティーは最大の懸念事項の一つです。 アプリケーションへのパブリックアクセスを有効にすると、潜在的なユーザー（ハッカーを含む）の数が飛躍的に増加します。

マッシュアップインターフェイスを使用すると、アプリケーションへのリンクを持っているすべての人にアクセスが許可されます。 アクセスには、ペルソナで制限された匿名認証サービスを使用するのが最適です。

匿名認証サービスがマッシュアップインターフェイスに関連付けられている場合、サーバー側のモデルオペレーターは必要に応じて変更できます。 外部の連絡先（顧客など）が初めてマッシュアップインターフェイスを使用する場合、そのユーザーの一意の識別情報は不明です。 ユーザーはまず、名前、電話番号、メールアドレスなどの連絡先情報を含んだフォームを送信する必要があります。

シンプルな本人確認の例としては、ユーザーが登録リクエストへの応答として受け取った秘密の一意のIDを入力することが挙げられます。 この場合、その一意のIDを非表示にしておくのはユーザーの責任です。 あらゆる実践的な目的に一意であることが保証されているIDは、GUIDです。

または、ユーザーが登録時にユーザー名とパスワードの入力を求められることもあります。 システムは続行する前に、ユーザー名が一意であるかどうか（要件の一つ）を検証します。 ユーザー名の一意性の検証に失敗した場合、ユーザーは別のユーザー名を入力する必要があります。

次回以降、ユーザーはシステムにアクセスするときに、一意な情報（GUIDまたはユーザー名のいずれか）を入力することから始めなければなりません。 ユーザー名を入力する場合、システムはパスワードの入力も要求します。 パスワードは@samepassword()関数を使用して検証できます。

二要素認証（2FA）やワンタイムパスワード（OTP）などのより強力な形式のIDの使用を妨げるものはありません。 詳細については、「Multi-factor authentication with a one-time password」を参照してください。

匿名認証サービスをソースとする「Create a case」マッシュアップインターフェイスを使用する場合に、ユーザーを一意に識別するには、作成ステージを続行する前に、まず一意のIDによるログイン手順を実行する必要があります。 一方、ケースワーカー（カスタマーサービス担当者やセールスチームメンバーなど）がケースを作成する場合、最初に表示される画面はオートコンプリートを利用した連絡先検索セクションです。

連絡先識別セクションに誰が入力するか（連絡先自身またはケースワーカー）にかかわらず、送信時に連絡先が正しい場合は、連絡先が一意に識別されます。

それ以降は、以前に永続化された連絡先、またはオンザフライで永続化された連絡先を参照するプロパティがケースによって設定されます。 連絡先が顧客の場合、設定されるプロパティにはCustomerGUID という名前を付けることができ、他の連絡先ペルソナロールについても同様の処理を行えます。

マッシュアップの「Display a page」オプションと組み合わせてB2Cに使用するのが最も理にかなっているデータクラスは、最終的にPegaData-Contactを拡張することによってData-Party-Personを拡張するデータクラスです。 Business-to-Business（B2B）の場合、ルートクラスはPegaData-Organizationであることに注意してください。

個人の連絡先に使用される最も一般的なクラス名はORG-APP-Contactです。 連絡先のロールに基づいてクラスを専門化する理由がある場合は、ORG-APP-Contactを拡張するORG-APP-MemberやORG-APP-Customerなどのデータクラスを定義できます。 

ORG-APP-Contact具象クラスは、パターン継承を使用して拡張することによって、セルフサービス外部アクセス用の抽象クラスを定義できます。 抽象クラス名はORG-APP-Contact-SelfServiceになります。 この抽象クラスには、Authenticatedという名前のTrueFalseプロパティがあります。 このプロパティはユーザーの一時的なセッションに適用されるため、永続化されることはありません。 ユーザーが自分自身を正常に識別した後、Authenticatedの値はtrueに設定されます。

ケースは、1つの外部連絡先に固有の場合もあれば、複数の外部連絡先によって参照される場合もあります。  前者は1対1の関係（1：1）であり、 後者は多対1の関係（M：1）です。

セールス担当者が特定の顧客にターゲットを絞ったケースを作成することは、1対1のシナリオの例です。

外部ユーザーが参加のための申し込みを行うウェビナーのケースは、多対1のシナリオの例です。 マッシュアップインターフェイスの表示対象となるデータクラスには、CaseRefプロパティが必要です。 ORG-Data-WebinarRegistrationはそのようなデータクラスの例です。 

1対1のセールス担当者のシナリオの続きとして、顧客がマッシュアップのDisplay a pageアクションで自分自身を一意に識別した後で、ケースのリストを表示することができます。ここで、各ケースのCustomerGUIDプロパティは顧客のGUIDと一致します。

顧客/メンバー/登録者のペルソナについては、外部の連絡先による既存のケースへのアクセスを制限する必要があります。 

セールスチームが見積もりを承認した直後に、セールスチームが所有するワークキューのアサインメントでケースが一時停止されたとします。 セールスチームがケースを作成したか、顧客がセルフサービスを使用したかは重要ではありません。 一時停止の目的は、承認された見積もりを顧客に確認してもらうことです。 顧客は、ケース自体に対するマッシュアップではなく、顧客とケースの両方を参照する特別に作成されたデータインスタンスを介したマッシュアップを通じて、その提案を承認または拒否できます。

セールスチームは、カスタムのセールスポータルを通じて承認がいつ行われるかを監視できます。 セールスメンバーは、顧客がケースを受け入れた場合に手動でケースを続行するか、ジョブスケジューラによってケースが進められるのを待つことができます。 それ以降の顧客によるケースへのダウンストリームアクセスは防ぐ必要があります。 顧客は、最初の2つのステージである作成と見積もりにしかアクセスできず、 他のすべてのケースタイプにもアクセスできなくなります。

より複雑なセキュリティーを適用できますが、より困難になります。 通常の認可セキュリティーでは、OperatorIDページ内のプロパティ（特に pyUserIdentifier ）を、アサインメント、ケース、またはデータインスタンス内のプロパティと比較できます。 OperatorIDページはモデルオペレーター専用であるため、マッシュアップを使用して別のページを使用する必要があります。

「Display a page」アクションを使用する場合、その代替クリップボードページの名前はpyDisplayHarnessです。 「Create a case」アクションを使用する場合、その代替クリップボードページの名前はD_ContactSelfServiceEditableです。

Pega Platformを使用する場合によくあることですが、同じ機能を実装する方法は複数あります。 マッシュアップの場合、pyIsMashup状況テンプレートを使用するか、pyIsMashup.と同義のpyCreatedByChannelなどのプロパティを使用して状況設定を実行できます。他のセクションを埋め込むセクションを定義することもできます。これらの埋め込みセクションの表示は、ペルソナに付与された特権に基づきます。

後者の場合、プライマリセクションには2つの埋め込みセクションがあり、そのうちの1つのセクションはセールスペルソナに対してのみ表示されます。 セールスチームのみが表示できるこのセクションには、コストと利益が表示されます。 2番目のセクションは顧客ペルソナに対して表示されます。 埋め込みセクションの表示は、セクションを別のセクションに追加するときにAssociated privileges チェックボックスを使用して制御できます。

ケースタイプルールの状況設定には、状況テンプレートではなくテキストプロパティを使用する必要があります。 ケースのpyDefaultデータトランスフォームでは、pxThread.isWebMashup = true.の場合、すぐに使用できる（OOTB）プロパティpyCreatedByChannel を「Mashup」などの値と等しく設定できます。ChannelIsMashupという名前のルールがそのブール条件をカプセル化できる場合に再利用可能です。

ケースタイプルールを状況設定すると、ケースタイプルールが状況設定されたことがケースデザイナーによって明確に示されるため、保守性が強化されます。 状況設定されたケースタイプは、ベースケースのすべてのステージを示す必要はありません。 実際、ケースワーカー以外のユーザーは、最初の2つのステージだけを見た方が直感です。 状況設定プロパティ（たとえばpyCreatedByChannel ）は、第2ステージの終了時以降に削除できます。 これを行うには、デクレアトリガーに加え、そのデクレアトリガーのアクティビティを呼び出すユーティリティシェープを使用します。 状況設定プロパティが削除されると、ケースタイプの動作は、最初の2つのステージに続くステージの基本ルールの定義に戻ります。

pyIsMashup状況テンプレートは、pyCaseMainInnerセクションに適用する場合に役立ちます。 Mobile Main Case Panelテンプレートは、状況設定されたセクションに使用できます。 このテンプレートに含まれていないセクションはすべて削除できます。 これがケースであることを示す唯一のヒントは、pxDisplayStagesセクションが表示されていることです。  ケースタイプの状況には2つのステージしかないため、これら2つの初期ステージの後で何が起こるかについての質問はUXで提起されません。 pyIsMashup状況テンプレートは、データトランスフォームなど、セクション以外のルールにも使用できます。 

上位層のアプリケーションセクションにpyIsMashup状況テンプレートを使用することの欠点は、pxThread.isWebMashup = falseが原因で、これらのセクションがApp Studioで編集できないことです。 この場合の対処法は、状況設定されたセクションを骨組みとしてから、状況設定されていないセクションをその中に埋め込むことです。 埋め込まれたセクションには、マッシュアップユーザーによる表示が目的であることを明確に示す名前が付けられています。

このアプローチの難点は、埋め込みセクションがCase Designerに表示されない場合に、そのようなビューの存在をApp Studioユーザーがどのようにして知るかということです。  App Studioユーザーは、ケースの「Views」タブとセクションの名前を確認する必要があります。

Associated privilegesアプローチを使用すると、この問題をより簡単に解決できます。 App Studioのデベロッパーには、顧客ペルソナに対して表示される内容を確認する権限を与えることができます。 同時に、App Studioのデベロッパーは、従業員ペルソナ（たとえば、セールス）に対して表示される内容を確認できます。 セールスペルソナと顧客ペルソナに対しては、2つのセクションが両方表示されるのではなく、一方のみが表示されます。

マッシュアップインターフェイスをテストする場合、マッシュアップインターフェイスを埋め込むウェブページをウェブサーバーから取得する必要はありません。 これと同じウェブページは、ウェブページのHTMLファイルをクリックして表示できます。 Pega Platformとの通信は、ウェブページ内から行われます。  この通信が行われるウェブページ内の場所は、src属性を持つスクリプト要素です。 src属性の値は、マッシュアップインターフェイスの設定ページによって生成されるPega PlatformのURLです。

このDisplay a pageアクションは、本番アプリケーション上に構築されたDevOnlyアプリケーションで定義されるケースでシミュレートできます。 このケースは、マッシュアップハーネスと同じデータクラスを持つ埋め込みページを単に宣言するものであり、 単一のループバックアサインメントを持ちます。 このアサインメントでは、ループバックフローアクションが埋め込みページへのセクションソースを表示します。 このセクションは、マッシュアップハーネスによって表示されるセクションと同じです。

状況設定を伴うため、ポータルインターフェイス内で「Create a case」マッシュアップアクションをシミュレートすることはより困難です。 同じルールを2つの異なる方法で状況設定することはできません。 「Associated privileges」アプローチを使用すると、「Create a case」アクションをシミュレートする必要性が最小限に抑えられます。 マッシュアップユーザーに対して表示される方法で「pyCaseMainInner」セクションを表示するのは困難です。 ルールセットオーバーライドを使用しても、状況設定されたバージョンのデータトランスフォームでは、別のルールセットのベースバージョンをオーバーライドできない場合があります。