Mashup

Currently, Pega Platform™ supports business-to-consumer (B2C) UX through a mashup interface. How mashup screens are drawn may change in later releases. Currently, mashup screens support only the use of the Theme Cosmos harnesses and sections. Later releases will include a new channel interface that is similar to a mashup that is based on Cosmos React.

A mashup can also be used for business-to-employee (B2E). Suppose an employee of a company uses Salesforce. It is possible to extend Salesforce to leverage other applications, including those built with Pega Customer Decision Hub™ that use the current Pega Mashup interface (the application will use the Cosmos React interface in a later release).

Mashup supports several types of actions. A customer is not a case worker. Actions such as Get Next Work and Open assignment do not apply because the OperatorID page pertains to the anonymous model operator. That operator never owns worklist assignments because the assignments are visible to every mashup user. An embedded UI page section with a table layout can provide read-only access to a case that is paused at a workbasket assignment.

For B2C, the two best-suited mashup actions are Create a case and Display a page.

With the Create a case action, customers enter data in the Create stage where no assignment exists. The Create stage is similar to Display a page in that the screen is displayed against a harness applied to Data-Portal. In releases earlier than Pega Platform version 8.5, users must develop a New harness and declare the case type as temporary within the case type rule's Settings tab.

For the Display a page action, a harness can be defined against any data class. A data class that makes perfect sense to use extends PegaData-Contact. That data class can be extended to append -SelfService. Instances of the PegaData-Contact-extending data class are persisted as concrete reference data. The -SelfService extension of that class is abstract, which means the extension is never persisted.

Data can be persisted outside a case BLOB regardless Create a case and Display a page being used. A developer can define a SavePlan activity that invokes the Save-DataPage method for any data class. Any data class can reference a case by the case's pyID key.

The issue of uniquely identifying who a customer is comes into play with either the Create a case or Display a page action. Otherwise, the mashup interface is nothing more than a form submission that contains someone’s contact information: a one-time use of the mashup interface. Being able to identify who the customer is repeatedly, without requiring them to reenter their contact information, while challenging, is doable.

There is more to implementing mashup than designing screens suitable for viewing by non-employee, external contact personas such as customers. Security is a primary concern. Making an application accessible to the public increases the number of potential users (including hackers) dramatically.

A mashup interface allows anyone with a link to an application to access. Access is best accomplished using a persona-restricted Anonymous Authentication Service.

When Anonymous Authentication Service is associated with a mashup interface, the server-side model operator can be modified as needed. When an external contact (such as a customer) first uses a mashup interface, the unique identity of the user is unknown. The user must first submit a form that contains their contact information such as name, phone number, and email address.

Unique identification could be as simple as users entering the secret unique ID they received in response to a registration request. In that situation, it is the responsibility of the user to keep that unique ID hidden. An ID that is guaranteed to be unique, for all practical purposes, is a GUID.

Alternatively, users can be asked to supply a user name and password when registering. The system then validates whether the user name is unique (which is a requirement) before continuing. If the user name uniqueness validation fails, the user must supply a different user name.

In the future, when users access the system, they must begin by supplying something unique; either their GUID or user name. If supplying a user name, the system also asks for a password. The password can be validated by using the @samepassword() function.

Nothing prevents the use of stronger forms of identification such as Two Factor Authentication (2FA) or One-Time Password (OTP). For more information, see Multi-factor authentication with a one-time password.

When you use the Create a case mashup interface sourced to an anonymous authentication service, and you want the user to be uniquely identified, the Create stage must begin by executing a unique identification login procedure before continuing. In contrast, when a case worker (such as a customer service representative or sales team member) creates the case, the first screen that is displayed is an autocomplete-leveraging contact search section.

Regardless of who populates the contact identification section (the contact themselves or a case worker), the contact is uniquely identified if correct on submission.

Beyond that point, the case sets a property that references the previously-persisted, or on-the-fly-persisted, contact. When the contact is a customer, the property that is set can be named CustomerGUID and similarly for other contact persona roles.

A data class that makes the most sense to use for B2C in conjunction with mashup’s Display a page option is one that ultimately extends PegaData-Contact, which extends Data-Party-Person. Note that for business-to-business (B2B), the root class is PegaData-Organization.

For a person contact, the most generic class name to use is ORG-APP-Contact. If there is a reason to specialize the class that is based on the contact’s role, data classes such as ORG-APP-Member or ORG-APP-Customer that extend ORG-APP-Contact can be defined. 

An ORG-APP-Contact concrete class can be extended, using pattern inheritance, to define an abstract class specifically used for self-service external access. The abstract class name would be ORG-APP-Contact-SelfService. That abstract class has a TrueFalse property named Authenticated. That property is never persisted since it applies to the user's session which is transient. The value of Authenticated is set to true after the user successfully identifies themselves.

A case can either be specific to one external contact or multiple external contacts can reference a case.  The former is a one-to-one relationship (1:1). The latter is a many-to-one relationship (M:1).

An example one-to-one scenario is when a sales executive creates a case that targets a specific customer.

A many-to-one scenario is a webinar case where external users apply to attend that webinar. The data class against which the Mashup interface is displayed would need a CaseRef property. The data class, for example, is ORG-Data-WebinarRegistration. 

A potential continuation of the one-to-one sales executive scenario involves the customer uniquely identifying themselves with the Display a page action of a mashup, after which a list of cases is displayed where each case's CustomerGUID property matches the GUID of the customer.

Preexisting case access by an external contact must be restricted for the Customer/Member/Enrollee persona. 

Suppose a case is paused at a Sales-owned work queue assignment immediately after Sales has approved a quotation. Whether Sales created the case or the customer used self-service is immaterial. The purpose of the pause is to have the customer review the approved quotation. The customer can approve or reject that proposal through mashup, not against the case itself, but through a specially created data instance that references both the customer and the case.

Sales can observe when approval occurs through their custom Sales portal. The Sales member can manually continue the case if the customer accepts it or wait for a job scheduler to move the case forward. Downstream access to the case by the customer from that point on needs to be prevented. The customer only has access to the first two stages: Create and Quotation. The customer is also prevented from accessing every other case type.

More complex security can be applied but gets more difficult. With regular authorization security, properties within the OperatorID page (pyUserIdentifier especially) can be compared to a property within an assignment, case, or data instance. A different page must be used using mashup because the OperatorID page is devoted to the model operator.

When using the Display a page action, the name of that alternative clipboard page is pyDisplayHarness. When the Create a case action is used, the name of that alternative clipboard page is D_ContactSelfServiceEditable.

As often the case when using the Pega Platform, there are multiple ways to implement the same functionality. For mashup, you can use the pyIsMashup circumstance template or perform circumstancing by using a property, such as pyCreatedByChannel, which is synonymous with pyIsMashup. You can also define sections that embed other sections; the visibility of those embedded sections is based on a privilege granted to the persona.

Regarding the latter, the primary section has two embedded sections, one section only visible to the Sales persona. That Sales-viewable-only section displays costs and profit. The second section is visible to the Customer persona. Embedded section visibility can be controlled by using the Associated privileges check box when adding the section to another section.

Case type rules can only be circumstanced using a text property, not a circumstance template. In the pyDefault data transform of the case, the out-of-the-box (OOTB) property pyCreatedByChannel can be set equal to a value such as "Mashup" when pxThread.isWebMashup = true. A reusable when rule named ChannelIsMashup can encapsulate that boolean condition.

Circumstancing the case type rule enhances maintenance because the Case Designer clearly shows that the case type rule has been circumstanced. The circumstanced case type does not need to show every stage that the base case has. In fact, it is more intuitive for a non-case worker only to see the first two stages. At the end of the second stage and past it, the circumstancing property, pyCreatedByChannel  for example, can be removed. This is achieved by a declare trigger as well as a utility shape that calls the activity of the declare trigger. Once the circumstancing property is removed, case type behavior reverts to the base rule's definition of the stages that follow the first two stages.

The pyIsMashup circumstance template is useful when applied to the pyCaseMainInner section. The Mobile main case panel template can be used for the circumstanced section. Every section not included in that template can be removed. The only hint that this is a case is the pxDisplayStages section being displayed.  Because the case type circumstance only has two stages, the UX does not raise questions about what takes place beyond those two initial stages. The pyIsMashup circumstance template can be used for rules other than sections also, such as data transforms. 

The drawback to using the pyIsMashup circumstance template for higher-layer application sections is that those sections are not editable in App Studio because pxThread.isWebMashup = false. What can be done is to scaffold a circumstanced section and then, within it, embed a non-circumstanced section. The embedded section is given a name that makes it obvious it is intended for viewing by mashup users.

The difficulty with that approach is, how do App Studio users know such a view exists when the Case Designer does not display it?  The App Studio user needs to know to look at the cases Views tab and the section's name.

Using the Associated privileges approach solves that problem more cleanly. A developer in App Studio can receive the privilege to view what the Customer persona sees. At the same time, the developer in App Studio sees what the employee persona (for example, Sales) sees. The Sales persona and customer persona see only one of the two sections, not both.

A web page that embeds a mashup interface does not need to be retrieved from a web server to test the mashup interface. The same web page can be displayed by clicking on a web page HTML file. Communication with the Pega Platform occurs from within the web page.  The location in the web page that this occurs is a script element with an src attribute. The value of the src attribute is a Pega Platform URL generated by the configuration page of the mashup interface.

The Display a page action can be simulated in a case defined in a DevOnly application built on the production application. The case merely declares an embedded page having the same data class as the mashup harness. The case has a single loopback assignment. At that assignment, the loopback flow action displays a section source to the embedded page. That section is the same section that the mashup harness displays.

Due to circumstancing, it is more difficult to simulate the Create a case mashup action within a portal interface. The same rule cannot be circumstanced two different ways. If the Associated privileges approach is used, the need to simulate the Create a case action is minimized. Getting the pyCaseMainInner section to display the way that a mashup user sees the section is difficult. It can be problematic to use a ruleset override to allow a circumstanced version of the data transform override the base version in a different ruleset.