Difference between revisions of "Building high performance into your Customer Service applications"

From PegaWiki
Jump to navigation Jump to search
(Updates)
Tag: Visual edit
(updated version as of)
Tag: Visual edit
 
(15 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{New request
+
{{Design pattern|Title=Building high performance into your Customer Service applications|Description=Considerations and advice for building high-performance Pega Customer Service applications|Version=8.1|Applications=Pega Customer Service|Capability Area=Performance|Owner=Lewis, matt}}
  
|Request to Publish=
+
When building your Pega Customer Service applications, follow these guidelines to ensure high performance.
 
 
|Curator Assigned=
 
|Description=Building high performance into your Customer Service applications
 
|Applications=Customer Service
 
|Capability Area=Customer Service
 
|Version=1.0
 
 
 
}}
 
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓  '''<big>Please Read Below</big>'''  ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
 
 
 
Enter your content below. Use the basic wiki template that is provided to organize your content.  After making your edits, add a summary comment that briefly describes your work, and then click "SAVE".  To edit your content later, select the page from your "Watchlist" summary.  If you can not find your article, search the design pattern title.
 
 
 
When your content is ready for publishing, next to the '''"Request to Publish"''' field above, type '''"Yes"'''. A Curator then reviews and publishes the content, which might take up to 48 hours.
 
 
 
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ '''<big>The above text will be removed prior to being published</big>''' ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
 
 
 
== Building High performance customer service applications ==
 
When building your implementation of customer service on either customer service horizontal or different verticals such as customer service for financial services their are a number of key design decisions
 
 
 
that will help ensure a high performance implementation. The remainder of this article will break these problems into key areas and provide tips and pointers on each.
 
  
 
== Before you begin ==
 
== Before you begin ==
In preparation for the below material it is good to refamiliarize yourself with performance concepts and the art of debugging your application. Below are some reference links to help prepare.
+
Familiarize yourself with performance and debugging concepts by reviewing the following resources:
 
+
* Analyzing application performance - https://academy.pega.com/challenge/analyzing-application-performance/v1
https://academy.pega.com/challenge/analyzing-application-performance/v1<nowiki/>Analyzing application performance
+
* Debugging and performance - https://academy.pega.com/module/debugging-and-performance/v1
 
+
* Predictive Diagnostic Cloud - https://community.pega.com/knowledgebase/products/predictive-diagnostic-cloud
https://academy.pega.com/module/debugging-and-performance/v1 Debugging and performance
 
 
 
https://community.pega.com/knowledgebase/products/predictive-diagnostic-cloud<nowiki/>Predictive Diagnostic Cloud
 
  
== Customer Service Implementation Guidance ==
+
== Guidelines for building high performance Customer Service applications ==
  
 
=== Work pools and tables ===
 
=== Work pools and tables ===
Depending on the version of customer service you are implementing you may have anywhere from 2 to 4 work pools out of the box. When setting up your implementation ensure that you have at minimum one work pool for the interaction classes and one work pool for the service intent cases pointed to 2 different tables.  
+
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, each pointing to a different table.
* By default ootb both service case and interaction work pools point to the same table which for small implementations will work but for larger implementations a single table becomes a bottleneck.  
+
* By default, the interaction classes work pools and service intent case work pools point to a single table. Although a single table will work for small implementations, it will cause a bottleneck for larger implementations.  
* For extremely high volume implementations think of creating work pools that mirror your core entities or interaction driver categories such that load is spread across more tables. The more tables present the lower IO contention is at high volume.
+
* 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:
** Example:  
+
** ''BigBank-Servicing-Work-Acct'' (work pool for account-related cases)
*** BigBank-Servicing-Work-Acct ( work pool for account related cases )        
+
** ''BigBank-Servicing-Work-Gen'' (work pool for general service-related cases)
*** BigBank-Servicing-Work-Gen   ( work pool for general service related cases )
+
** ''BigBank-Servicing-Work-Interaction'' (work pool for customer interactions)
*** 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 on pega cloud usage of read replicas may also come into play.  
+
* 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 your applications are hosted in a Pega Cloud Services environment, the use of read replicas is also a factor.  
  
 
=== User experience ===
 
=== User experience ===
How the user experience and in turn the UI is designed and built can have a large impact on performance both actual and perceived. Determining what is needed when is extremely import in a customer service implementation where anywhere from 6-30 interfaces may get invoked as part of running and loading the interaction and 360 customer composite.
+
How the user experience, and in turn the user interface, is designed and built can have a large impact on performance, both actual and perceived. Determine what information is important to display to users. Running and loading an interaction and the 360° customer composite requires anywhere from 6 to 30 interfaces.
* 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 methodolgy for agent interaction and 360 composite data placement]].
+
* 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 methodolgy for agent interaction and 360 composite data placement|Customer Service methodology for agent interaction and 360 composite data placement]]. For example, when searching for a customer, only display enough information to select the customer, not to verify them. Wait until verification to display the additional verification information.
** For example when searching for a customer you only need enough information to select the customer not verify them at that point in time. Wait until verification to pull in the additional required information.  
+
* Ensure that sections are collapsed and defer loading if possible.
* Ensure sections are collapsed and defer loaded if possible.
+
* When showing a list of items, enable progressive loading and set a reasonable page size, such as 15 items per page.
* When showing a list of items set a reasonable page size usually < 15 to display at once and enable progressive loading
+
* When building show/hide logic, try to use expressions instead of When rules because expressions execute on the client side instead of on the server side. As a result, expressions will perform faster and reduce server-side load as you scale.
* When building show hide logic try to use expressions where possible instead of when rules as these will execute client side vs. server side and will perform faster and reduce server side load as you scale.
 
  
 
=== Clipboard and data pages ===
 
=== Clipboard and data pages ===
A clean clipboard on agent requestors, reasonable overall requestor clipboard size and efficient and correct load strategies on data pages can mean the difference from being an unstable customer service application that is constantly plagued by complaints of slow response over time to one that has the same performance and response profile for an agent throughout their shift be it 6,8 or more hours continuous and scales with far more users per node.
+
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, slow Pega Customer Service application and one with fast, consistent performance. A well-designed application should provide continuously responsive performance for agents, regardless of their shift duration, and it should scale when there are many users per node.
 +
 
 +
* When possible, make data pages requestor level 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 once during the customer interaction. For example, supposed a screen has four sections that are defer loaded, and all are rendered on the same data page. Each defer load is a different HTTP interaction, and thus the data page will be reloaded four 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).
 +
[[File:Hp-1-rs.png|none|thumb|532x532px]]
 +
* 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 to 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.
  
* 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 requestor level.
+
=== Clipboard tips and best practices ===
* Do not use the reload once per interaction option. This will actually reload the data page every '''http interaction''' vs. 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 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 grained reload strategy consider using the reload if older than or the do not reload when but forcing the condition to evaluate true.
+
Monitor requestors periodically for average size to help identify potential issues with loading too many things on the clipboard, pages not being cleared out, and users who do not close and wrap up interactions once finished.  
* Always select "clear pages after non-use" when this an option ( on read only requestor level data pages )
+
* The following screenshot is from '''Admin Studio > Users > Requestors > Load requestor size'''.
[[File:DataPage Refresh and Page Options .jpg|none|thumb|532x532px]]
+
* 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 when agents are handling multiple active chat sessions. On average, the requestor size should typically be 12mb or less across all system users.
* Ensure data pages are being cleared out appropriately.
+
[[File:Hp-2.jpg|none|thumb|900x900px]]
** Upon wrap up of an interaction customer service will invoke activity CPMPreClose which contains two different methods of removing requestor level data pages being CPMRemoveRequestorDataPages which loops through D_Interaction_RequestorDataPages and removed them explicitly by signature or in data transform CPMCleanInteractionPages. Unless you have touched a page from the portal thread which does not get removed when an interaction is closed or you did not check the clear pages after non-use on your requestor level data pages you will need to add your implementation build data pages to CPMCleanInteractionPagesExtension. Also note that if you have '''<u>changed the parameter signature of any of the OOTB data pages</u>''' you may also have to add this update into the extension.
+
* If you notice that your requestors are often larger than this range, then use the Clipboard tool to perform clipboard analysis. The following figure shows a requestor that is larger than the target threshold. By 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.
** Periodically during the development and QA cycle check that all data pages are getting cleared upon wrap of of interactions and service cases. 
+
[[File:Hp-3.jpg|none|thumb|788x788px]]
* Clipboard tips and best practices
 
** Monitoring requestors periodically for average size will help identify potential issues with loading too many things on the clipboard, pages not getting cleared out or potentially users that do not close and wrap up interactions once finished.  
 
*** The below screenshot is from admin studio --> users --> requestors --> load requestor size.  
 
**** Key items to watch are overall Page size of your requestors on average and the largest. It is often common to have some requestors in a customer service implementation go as high as 20-25mb in size based on having multiple interactions and service intents open especially in the scenario of chat interactions where agents are often multi tasking between multiple active chat sessions. However on average across users on the system requestor size should typically be 12mb or less on average.
 
[[File:Requestor Size.jpg|none|thumb|1432x1432px]]
 
* If you notice that your requestors are often larger than this range then doing some clipboard analysis via the clipboard tool and then selection of analysis will help. The below screenshots is a good example of a requestor that is larger than the target threshold and digging deeper we see data page D_OpenServiceCases is both large and does not appear to be getting cleared out from interaction to interaction.
 
[[File:ClipboardAnalysis.jpg|none|thumb|788x788px]]
 
  
 
=== Integration and connectors ===
 
=== Integration and connectors ===
Most customer service implementations do not store data locally but integrate to external systems of record. A few key items to keep in mind when integrating with external systems of record.
+
Most Pega Customer Service implementations do not store data locally but integrate to external systems of record. When integrating with external systems of record, follow these guidelines to ensure high performance:
* Upon receiving connectors try to independently run load against those connectors using industry available tooling such as jmeter to understand their performance profile under some load.
+
* 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 and anything that is on average over 1 second should be remediated for performance independent of integrating into your application.
+
** 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  
+
* Use aggregate data sources in data pages to reduce the number of moving pieces required for integration, both for saves and reads.  
 
+
** Implementations often use complex and hard to follow activities for performing integration. With the advent of aggregate source data pages, this is no longer required.
== Use case examples ==
+
** 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.
Provide a business example to help users understand the objective.
+
[[File:Hp-4.jpg|none|thumb|900x900px]]
 
+
* 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.
.
 
 
 
== Process/Steps to achieve objective ==
 
What do individuals need to know to achieve the outcome? What do individuals need to know to achieve the outcome? Enter the precise steps to guide the user to achieving the desired outcome. Remember to always state where in the software the user must perform an action, before giving the action.  
 
 
 
If “How To…” documents exist for specific configuration procedures please link (using the url) to those assets on the community **
 
 
 
== Results ==
 
What do you expect the user to see or be able to do after they complete this design pattern?
 

Latest revision as of 15:13, 28 June 2021

Building high performance into your Customer Service applications

Description Considerations and advice for building high-performance Pega Customer Service applications
Version as of 8.1
Application Pega Customer Service
Capability/Industry Area Performance



When building your Pega Customer Service applications, follow these guidelines to ensure high performance.

Before you begin[edit]

Familiarize yourself with performance and debugging concepts by reviewing the following resources:

Guidelines for building high performance Customer Service applications[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, each pointing to a different table.

  • By default, the interaction classes work pools and service intent case work pools point to a single table. Although a single table will work for small implementations, it will cause 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 your applications are hosted in a Pega Cloud Services environment, the use of read replicas is also a factor.

User experience[edit]

How the user experience, and in turn the user interface, is designed and built can have a large impact on performance, both actual and perceived. Determine what information is important to display to users. Running and loading an interaction and the 360° customer composite requires anywhere from 6 to 30 interfaces.

  • 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, only display enough information to select the customer, not to verify them. Wait until verification to display the additional verification 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, such as 15 items per page.
  • When building show/hide logic, try to use expressions instead of When rules because expressions execute on the client side instead of on the server side. As a result, expressions will perform faster and 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, slow Pega Customer Service application and one with fast, consistent performance. A well-designed application should provide continuously responsive performance for agents, regardless of their shift duration, and it should scale when there are many users per node.

  • When possible, make data pages requestor level 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 once during the customer interaction. For example, supposed a screen has four sections that are defer loaded, and all are rendered on the same data page. Each defer load is a different HTTP interaction, and thus the data page will be reloaded four 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).
Hp-1-rs.png
  • 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 to 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]

Monitor requestors periodically for average size to help identify potential issues with loading too many things on the clipboard, pages not being cleared out, and users who 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 when agents are handling multiple active chat sessions. On average, the requestor size should typically be 12mb or less across all system users.
Hp-2.jpg
  • If you notice that your requestors are often larger than this range, then use the Clipboard tool to perform clipboard analysis. The following figure shows a requestor that is larger than the target threshold. By 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.
Hp-3.jpg

Integration and connectors[edit]

Most Pega Customer Service implementations do not store data locally but integrate to external systems of record. When integrating with external systems of record, follow these guidelines to ensure high performance:

  • 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 often use 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.
Hp-4.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.