You’ve just received a support ticket about a certain screen in your IBM BPM/BAW Application taking over a minute to load in production. Ouch! Performance issues like these cause pain for your users, are often avoidable, and ultimately hinder adoption of the platform in your organization.

BP3’s services group has successfully delivered over 1000 IBM BPM/BAW projects. We’ve seen it all. This article identifies common pitfalls we see in the field that cause slowness in Client Side Human Services to help you resolve existing performance issues and prevent new ones from reaching production in the first place.

Note: This article is not meant to be a comprehensive guide on how to squeeze out every bit of performance from a CSHS. Instead, it’s meant to identify and resolve shortfalls that commonly cause slowness for end users.

1. Slow service between Start event and Coach activity

   This is a very common cause of performance issues we encounter in the field. The reason this can cause slowness is because each activity in a CSHS is executed synchronously, meaning that the next step doesn’t start until the previous step is complete. Anything placed after the Start event and before the Coach activity will have to complete before the Coach Views on the Coach can begin to render. It’s common to have some kind of initialization script before the Coach is reached, and this is usually not an issue as this script is native JavaScript executed on the client thus no network latency is introduced. Issues typically arise when a service that retrieves large amounts of data from a data source, such as a system of record, is placed here. We often see this pattern in process dashboards that are meant to display records related to instances in a table. These services may retrieve large datasets, the size of which can vary depending on how many records are in your data source. On top of this, as the data source grows, the service will take longer and longer to execute. This can create slowness for the user as they will see a blank screen until this service is done executing. Below is a screenshot illustrating this.

   

   Luckily, it’s easy to avoid. One approach involves using a Coach View to trigger the service asynchronously at the point in which the Coach is reached as opposed to synchronously before the Coach. If you’re using the Brazos UI Toolkit and your data is going to be displayed in a table format, one easy way to do this is by using the Load Data from Ajax configuration option of the Table Coach View to populate the table with data when the Coach loads preventing the page rendering from being blocked.
   Brazos UI contains many controls which utilize AJAX calls to help your CSHSs be more performant. Please see the Brazos UI Documentation here for more information on how to implement these patterns.

   If you’re not using the Brazos UI Toolkit or your data isn’t meant to be displayed in a table, another approach is to build a Coach View which either has a service configuration option that runs a service in the initialization of the Coach View to retrieve your data, or which fires a boundary event in the initialization of the Coach View which is then bound to a boundary event on your CSHS that flows to your retrieval service. In both of these cases, the Coach will begin rendering while the data is retrieved, creating a better, non-blocking user experience. Below is a screenshot of what a diagram might look like with a Coach View that triggers a boundary event on load.

   

    

2. Slow service between Coach activity and End event
   

   Similar to #1, this scenario involves having a service between a Coach and an End event on a CSHS that is implemented as a task in a Process. Often when a task is completed, there is some kind of system based action that must occur, such as updating an SOR with data that was provided in the task, or sending a custom email notification that that task was completed. These kinds of services are often slow on the server side. Below is a screenshot of what this looks like.

   

   The solution to these scenarios is simple. Since tasks are implemented in the context of Processes, we can safely rely on the flow of the Process to execute after the task is completed. Whatever services implemented between the Coach and End event can be moved to the Process diagram after the task in question instead of in the CSHS so that the user completing the task does not have to wait for those services to complete before they can be assured their completing action was submitted successfully.

   One side effect of moving those services to the Process level is that adding too many system based activities to a Process diagram can cause confusion for business users. They often rely on the diagram for communication purposes to be representative of the actual business activities that occur and are relevant to them in the Process. Utilizing the sub process functionality of the IBM BPM/BAW is an effective approach to work around this. This allows you to obscure technical details from the business so that the top level Process diagram only contains information relevant to them.

3. Retrieving too much data at once

   As your application is used over time, the system of record it integrates with will also grow. Soon enough, the primary table in your database may have well over 10,000+ records. When building a dashboard meant to display these records in a table format we often see performance issues simply due to dealing with such a large dataset. This slowness can be caused both by the slowness of the retrieval service itself as well as slowness on the client side by having to render so many Coach Views in the table.

   There are multiple ways to successfully manage such a large dataset in a CSHS.

   One approach is to simply not allow such a large dataset to be brought back to the user in the first place. In most cases, users do not actually need to be able to interact with so many records at once, especially if the data is being displayed in a table configured with pagination. Validations on the client side can be built to prevent the user from being able to retrieve all records, such as a maximum number of allowed records to be returned per filter set. Visualizations are one of the only times such a large data set might be needed.

   Another way to prevent a large data set from being returned while creating no hindrance from the user’s perspective is to implement some kind of server side pagination so that only the records needed for the current page of the table are retrieved. A page of a table contains a subset of the dataset as a whole, such as 50 records at a time. The Brazos UI Table control has configuration options to make implementing server side pagination a breeze. Please see the Brazos UI Table documentation here for more information on how to implement server side pagination.

   If retrieving a large number of records is absolutely necessary, the best approach to avoiding performance issues is to reduce the burden of the Coach View framework from having to render separate Coach View instances for each attribute of each record returned, and instead write JavaScript to manually render and display each record to the user in pure HTML. The Brazos UI Table Mode configuration option of the Table Coach View allows the developer to set the mode to Read Only for exactly this purpose. As long as the users don’t need to also modify the values of the large data set directly in the table, this mode will render the values from the data set in pure HTML without the help of the Coach View framework which greatly improves performance. If your users need to be able to edit the data in the table, you can use the Read Only table mode in combination with the Brazos UI Modal control to enable the editing of each row’s data. Please see this BP3 Knowledge Base article for more information on how to implement this.

4. Large, deeply nested Business Objects

   At some point in the lifecycle of your application, you may begin to notice that as you expand on your business objects, your CSHSs begin to take a performance hit. This is common.

   When this happens, one solution is to refactor your business objects by flattening them. Unfortunately, this also requires refactoring all code and user interfaces that touch them, both at the Process, Service, and Human level.

   A less painful solution than the one mentioned above exists. Instead of flattening the business object and then having to refactor all parts of your application, you can refactor only the CSHS to input and output a subset of multiple variables contained in the master variable instead of a single instance of that master variable, thus reducing the amount of nesting IBM BPM/BAW has to manage.

5. Old browsers

   Many organizations use old browsers which have known issues with the platform, such as Internet Explorer 11. The best remedy here is to not use these browsers wherever possible, and instead use more current versions of Microsoft Edge, Mozilla Firefox, or Google Chrome.

6. Complexity

   Extremely complex and unorganized CSHSs are difficult to maintain, and when performance issues arise with them, it can be difficult to determine a root cause. Any increase in the number of assets defined in a CSHS in theory will have some measurable impact in load times. However, the point at which this impact becomes large enough to be noticed by users is hard to define. We find that users notice performance issues more often with a complex, unorganized CSHS that has a large number of assets versus a CSHS that is built in a clean and organized way. This is because it’s difficult to identify the root cause of those performance issues in an unorganized CSHS during design time, and it’s also difficult to identify them after they’re being reported in production.

   Complex CSHSs with a large number of assets are sometimes necessary to meet business requirements, thus, the best way to avoid running into performance issues when building them is to do so in a thoughtful, organized way. Things like consolidating repetitive code into a single service to clean up the diagram, maintaining script variable naming conventions, and commenting code are all ways to keep your CSHS neat, logical, and tidy.