Building high performance into your Customer Service applications

From PegaWiki
Revision as of 19:09, 6 October 2020 by LEWIM2 (talk | contribs) (update version as of)

Jump to navigation Jump to search

Building high performance into your Customer Service applications

Description Considerations and advice for building high-performance Pega Customer Service applications
Version as of 8.x
Application Customer Service
Capability/Industry Area Horizontal

When building your implementation of a Pega Customer Service application on either the Customer Service horizontal or in different verticals, such as Pega Customer Service for Financial Services, there are a number of key design decisions

that will help ensure that you create a high performance implementation. This article will break these decisions down into key areas and provide tips and pointers for each one.

Before you begin[edit]

In preparation for the following material, it will be good to re-familiarize yourself with performance concepts and the art of debugging your application. Below are some reference links that will help you to prepare:

Analyzing application performance -

Debugging and performance -

Predictive Diagnostic Cloud -

Customer Service Implementation Guidance[edit]

Work pools and tables[edit]

Depending on the version of Pega Customer Service that you are implementing, you may have anywhere from 2 to 4 work pools out of the box (OOTB). When setting up your implementation, ensure that you have at least one work pool for the interaction classes, and one work pool for the service intent cases, pointing to 2 different tables.

  • By default, both service cases and interaction work pools point to the same table, which will work for small implementations, but a single table becomes a bottleneck for larger implementations.
  • For extremely high-volume implementations, consider creating work pools that mirror your core entities, or interaction driver categories that spread the load across more tables. The more tables that are present, the lower the IO contention is at high volume. For example:
    • BigBank-Servicing-Work-Acct (work pool for account-related cases)
    • BigBank-Servicing-Work-Gen (work pool for general service-related cases)
    • BigBank-Servicing-Work-Interaction (work pool for customer interactions)
  • For report definitions and dashboards that don't have to be instantly up to date, consider using a reporting data source instead of the primary data source. If you are with Pega Cloud Services, use of read replicas is also a factor.

User experience[edit]

How the user experience - and in turn the UI - is designed and built can have a large impact on performance, both actual and perceived. Determine what is needed and when it is extremely important in a Pega Customer Service implementation, in which anywhere from 6-30 interfaces may be invoked as part of running and loading the interaction and the 360° customer composite.

  • Don't display something until you actually need it. An example methodology to help determine usage and data placement can be found at Customer Service methodology for agent interaction and 360 composite data placement. For example, when searching for a customer, at that point in time you only need enough information to select the customer, not to verify them. Wait until verification to pull in the additional required information.
  • Ensure that sections are collapsed and defer loading if possible.
  • When showing a list of items, enable progressive loading and set a reasonable page size. This is usually < 15 for display at once.
  • When building show/hide logic, where possible try to use expressions instead of when rules, as expressions will execute client side vs. server side and will perform faster and also reduce server-side load as you scale.

Clipboard and data pages[edit]

A clean clipboard on agent requestors, reasonable overall requestor clipboard size, and efficient and correct load strategies on data pages can mean the difference between an unstable Pega Customer Service application that is constantly plagued by complaints of slow response over time, and one that has the same performance and response profile for an agent throughout their shift, be it 6, 8, or more hours of continuous work, that also scales with far more users per node.

  • Make data pages request level, if possible, to avoid constant reload. System of record data, data used across cases, and data shared across interactions and service intents are all good candidates to be made requestor level.
  • Do not use the Reload once per interaction option. This option reloads the data page on every HTTP interaction, instead of on what some may think is the customer service interaction. For example, if a screen has 4 sections that are defer loaded, all of which are rendered on the same data page. Each defer load is a different HTTP interaction, and thus the data page will be reloaded 4 times. If you need a fine-grain reload strategy, consider using the if older than reload, or the do not reload when, but forcing the condition to evaluate to true.
  • Always select Clear pages after non-use when this option is available (on read-only requestor level data pages).
DataPage Refresh and Page Options .jpg
  • Ensure that data pages are being cleared out appropriately:
    • Upon wrapping up an interaction, Pega Customer Service will invoke the CPMPreClose activity, which contains two different methods of removing requestor-level data pages: CPMRemoveRequestorDataPages, which loops through D_Interaction_RequestorDataPages and removes them explicitly by signature; and the CPMCleanInteractionPages data transform. Unless you have touched a page from the portal thread which does not get removed when an interaction is closed, or you did not select the Clear pages after non-use check box on your requestor-level data pages, you will need to add your implementation build data pages to CPMCleanInteractionPagesExtension. Also note that if you have changed the parameter signature of any of the OOTB data pages, you may also have to add this update into the extension.
    • Periodically check during the development and QA cycle that all data pages are being cleared upon the wrapping up of interactions and service cases.

Clipboard tips and best practices[edit]

Monitoring requestors periodically for average size will help to identify potential issues with loading too many things on the clipboard, pages not being cleared out, or potentially, users that do not close and wrap up interactions once finished.

  • The following screenshot is from Admin Studio > Users > Requestors > Load requestor size.
  • Key items to watch are the average Page size of your requestors and the largest Page sizes. It is common to have some requestors in a Pega Customer Service implementation go as high as 20-25mb in size, based on having multiple interactions and service intents open, especially in a scenario of chat interactions in which agents are often multitasking between multiple active chat sessions. However, on average, across all users on the system the requestor size should typically be 12mb or less.
Requestor Size.jpg
  • If you notice that your requestors are often larger than this range, then doing some clipboard analysis via the Clipboard tool and then a selection of analyses will help. The following screenshot shows a good example of a requestor that is larger than the target threshold, and digging deeper we can see that the D_OpenServiceCases data page is not only large, but also does not appear to be getting cleared out from interaction to interaction.

Integration and connectors[edit]

Most customer service implementations do not store data locally but integrate to external systems of record. The following are a few key items to keep in mind when integrating with external systems of record:

  • Upon receiving connectors, try to independently run load against those connectors using industry available tooling, such as JMeter, to understand their performance profile under load.
    • Interfaces should ideally respond in less than 500 milliseconds. Anything that is on average over 1 second should be remediated for performance, independently of integration into your application.
  • Use aggregate data sources in data pages to reduce the number of moving pieces required for integration, both for saves and reads.
    • Implementations will often use lots of complex and hard to follow activities for performing integration. With the advent of aggregate source data pages, this is no longer required.
    • Directly reference connectors and their associated mapping, and if required, add a data transform after your connector sources, to perform any reconciliation or error handling after calling multiple interfaces.
Aggregate data pages.jpg
  • Do not directly place data on the D_Interaction data page. Let this refresh on its own, or in the worst case, directly clear it or put a refresh when condition for its reload. This should never be used as a source for integration, either for retrieval or updates within your Pega Customer Service implementation.


After reading this article you are now aware of some of the most common mistakes that cause Pega Customer Service implementations to perform badly, and know about some of the approaches and design decisions to help you avoid these issues in your implementations.