Tuning Process Cubes Tuning Process Analytics

16-4 Oracle Fusion Middleware Performance and Tuning Guide optionalInfo, ITaskQueryService.AssignmentFilter.MY, null, pred, null, startRow, endRow; In rare cases where the entire payload is needed, then the payload information can be requested. Typically only some of the payload fields are needed for displaying the task list. For example, for PO Tasks, the PO amount may be a column that must be displayed. Rather than fetching the payload as additional information and then retrieving the amount using an xpath expression and displaying it in the listing, consider mapping the amount column from the payload to a flex field. The flex field can then be directly retrieved during SQL querying which may significantly reduce the processing time. Similarly, for attachments where the name of the attachment is to be displayed in the listing and the document itself is stored in an external repository, consider capturing the attachment name in the payload and mapping it to a flex field, so that processing time is optimized. While constructing the listing information, the link to the attachment can be constructed by fetching the appropriate flex field.

16.2.6 Reduce the Number of Return Query Columns

When using the queryTask service, consider reducing the number of query columns to improve the SQL time. Also, try to use the common columns as they are most likely indexed and the SQL can execute faster. For example, in the following queryTasks method, only the TASKNUMBER and TITLE columns are returned: List queryColumns = new ArrayList; queryColumns.addTASKNUMBER; queryColumns.addTITLE; ... List tasks = querySvc.queryTasksctx, null, ITaskQueryService.AssignmentFilter.MY, null, pred, null, startRow, endRow;

16.2.7 Use the Aggregate API for Charting Task Statistics

Sometimes it is necessary to display charts or statistics to summarize task information. Rather than fetching all the tasks using the query API, and computing the statistics at the client layer, consider using the new aggregate APIs to compute the statistics at the database level. For example, the following call illustrates the use of the API to get summarized statistics based on state for tasks assigned to a user: List taskCounts = querySvc.queryAggregatedTasksctx, Column.getColumnWFTaskConstants.STATE_COLUMN, ITaskQueryService.AssignmentFilter.MY, keyWordFilter, filterPredicate, false, Oracle Human Workflow Performance Tuning 16-5 false;

16.2.8 Use the Count API Methods for Counting the Number of Tasks

Sometimes it is only necessary to count how many tasks exist that match certain criteria. Rather than calling the queryTasks API method, and determining the size of the returned list, call the countTasks API method, which returns only the number of matching tasks. The performance impact of returning a count of tasks is much lower than returning a list of task objects. For example, the following call illustrates the use of the API to get the total number of tasks assigned to a user: int numberOfTasks = querySvc.countTasksctx, ITaskQueryService.AssignmentFilter.MY, keyWordFilter, filterPredicate;

16.2.9 Create Indexes On Demand for Flexfields

The workflow schema table WFTASK contains several flexfield attribute columns that can be used for storing task payload values in the workflow schema. Because there are numerous columns, and their use is optional, the installed schema does not contain indexes for these columns. In certain use-cases, for example, where certain mapped flexfield columns are frequently used in query predicates, performance can be improved if you create indexes on these columns. For example, to create an index on the TEXTATTRIBUTE1 column, the following SQL command should be run: create index WFTASKTEXTATTRIBUTE1_I on WFTASKTEXTATTRIBUTE1;

16.2.10 Use the doesTaskExist Method

Sometimes it is necessary to check whether any tasks exist that match particular query criteria. Rather than calling the countTasks method, and checking if the number returned is zero, consider using doesTaskExist. The doesTaskExist method performs an optimized query that simply checks if any rows exist that match the specified criteria. This method may achieve better results than calling the countTasks method. For example, the following call illustrates the use of the API method to determine if a user owns any task instances: boolean userOwnsTask = querySvc.doesTaskExistctx, ITaskQueryService.AssignmentFilter.OWNER,null,null;

16.3 Improving Server Performance

Server performance essentially determines the scalability of the system under heavily loaded conditions. Section 16.2.1, Minimize Client Response Time lists several ways in which client response times can be minimized by fetching the right of amount of information and reducing the potential performance impact associated with querying. Note: The exact indexes required depend on the flexfield attribute columns being used, and the nature of the queries being executed. After creating the indexes, the statistics for the WFTASK table should be re-computed and flushed. 16-6 Oracle Fusion Middleware Performance and Tuning Guide These techniques also reduce the database and service logic performance impacts at the server and can improve server performance. In addition, a few other configuration changes can be made to improve server performance: ■ Archive Completed Instances Periodically ■ Select the Appropriate Workflow Callback Functionality ■ Minimize Performance Impacts from Notification ■ Deploy Clustered Nodes

16.3.1 Archive Completed Instances Periodically

The database scalability of a system is largely dependent on the amount of data in the system. Since business processes and workflows are temporal in nature, once they are processed, they are not queried frequently. Having numerous completed instances in the system can slow the system. Consider using an archival scheme to periodically move completed instances to another system that can be used to query historical data. Archival should be done carefully to avoid orphan task instances.

16.3.2 Select the Appropriate Workflow Callback Functionality

The workflow callback functionality can be used to query or update external systems after any significant workflow event, such as assignment or completion of task. While this functionality is very useful, it has to be implemented correctly to avoid impacting performance. When performance is critical, ensure that there are sufficient resources to update the external system after the task is completed instead of after every workflow event. For example, instead of using a callback, the service can be invoked once after the completion of the task. If a callback cannot be avoided, then consider using a Java callback instead of a BPEL callback. Java callbacks do not have the performance impact associated with a BPEL callback since the callback method is executed in the same thread. In contrast, a BPEL callback may impact performance when sending a message to the BPEL engine, which in turn must be correlated so that it is delivered to the correct process instance. The workflow service has to be called by the BPEL engine after the invocation of the service.

16.3.3 Minimize Performance Impacts from Notification

Notifications are useful for alerting users that they have a task to execute. In environments where most approvals happen through email, actionable notifications are especially useful. This also implies that there is not much load in terms of worklist usage. However if most users interact through the Worklist, and notifications serve a secondary purpose, then notifications should be used judiciously. Consider minimizing the notification to just alert a user when a task is assigned instead of sending out notifications for each workflow event. Also, if the task content is also mailed in the notification there may be an impact to performance. To minimize the impact, consider making the notifications secure in which case only a link to the task is sent in the notification and not the task content itself.

16.3.4 Deploy Clustered Nodes

All workflow instances and state information are stored in the dehydration database. Workflow services are stateless which means they can be used concurrently on a cluster of nodes. When performance is critical and a highly scalable system is needed, a clustered environment can be used for supporting workflow. For more information