In this Pega Academy lesson, you learn about guidelines for designing applications which can be deployed in the Pega Web Mashup, known as the Internet Application Composer (IAC) in Pega 7.1.8 and earlier versions.

Transcript

We learned that the PRPC applications need not be designed specific to how it is deployed. However there are few guidelines that we should remember in designing these applications which can be deployed in IAC.

Pega gadgets invoke a specific Pega action which can be showing the worklist or creating a new work item or getting the next work item. In most of these cases it launches a harness rule. All the standard harnesses like new, perform and all auto-generated harnesses can be rendered. When using custom harnesses make sure all sections included in harnesses are auto-generated. If it requires customization then the second guideline has to be followed.

We must validate that the PRPC application works in other browsers- Again all auto-generated harnesses, sections and flow actions are automatically supported in all popular browsers like IE, Chrome, Firefox and Safari. If the application uses non-auto-generated rules then the developer must test in other browsers. PRPC ships a browser compatibility report which can be used to test which sections need to be manually checked.

The Pega application should match the styles used in the web application. Typically customers will give access to those applications. Make sure we use the branding wizard to create these styles and not directly embed those CSS in PRPC.

Decide on the authentication- the Pega application still needs to authenticate the users and map them to access groups. However the users are not presented with a login page, the users might be logged into the web application and the gadget passes the user credentials. We need to map it with the values stored internally to validate the authenticity and then give them access. All authentication modes like LDAP or third party authentication methods can be extended to IAC. PRPC ships standard IAC specific authentication and timeout activities which can be customized.

Now let’s see some of the restrictions in the composite applications.

The application can have only one work pool associated with it.

Access groups always reference only one application If additional applications are needed the operators are assigned to multiple access groups. In composite portals the portal supports switching to a different access group. In case of IAC it requires an additional gadget to be created. In short, a gadget can display only one application, but there are additional API capabilities available for which we can use so that different gadgets can talk to each other.

The third restriction is related to the second one we just saw. The worklist can display assignments belonging to only one application. So in cases where there are multiple applications there are multiple gadgets.

Lastly, let’s briefly discuss how to unit test the composite applications.

The first step is to confirm if the Pega gadget code written in the div tag is correct. We can confirm this by saving the div tags in an HTML stream rule in PRPC. We can then create a Portal rule of Type Custom. The Portal rule can reference an activity rule and in the activity rule, we can use Show-HTML method to display the HTML rule. We can confirm this by opening the portal rule. It is always recommended to use the gateway console to create the gadget and preview it to minimize user errors.

After confirming the HTML stream we can then test it by saving the HTML code as an HTML page. If the web page and the PRPC instance exist in the same domain then there is no need for gateway servlet.