Dispatcher Engine Threads Basic Tuning Considerations

16-2 Oracle Fusion Middleware Performance and Tuning Guide ■ Use the Count API Methods for Counting the Number of Tasks ■ Create Indexes On Demand for Flexfields ■ Use the doesTaskExist Method

16.2.1 Minimize Client Response Time

Since workflow client applications are interactive, it is important to have good response time at the client. Some of the factors that affect the response time include service call performance impacts, querying time to determine the set of qualifying tasks for the request, and the amount of additional information to be retrieved for each qualifying task.

16.2.2 Choose the Right Workflow Service Client

Workflow services support two major types of clients: SOAP and EJB clients. EJB clients can be further separated into local EJB clients and remote EJB clients. If the client application is based on .Net technologies, then only the SOAP workflow services can be used. However, if the client application is based on Java EE technology, then consider which client should be used based on your use case scenarios. The options are listed below: ■ Remote client - This is the best option in terms of performance in most cases. If the client is running in the same JVM as the workflow services soa-infra application, the API calls are optimized so that there is no remote method invocation RMI involved. If the client is on a different JVM, then RMI is used, which can impact performance due to the serialization and de-serialization of data between the API methods. ■ SOAP client - While this option is preferred for standardization based on web services, there are additional performance considerations when compared to the remote method invocation RMI used in the remote client. Additional processing is performed by the web-services technology stack which causes the marshalling and unmarshalling of API method arguments between XML. For more information, see Oracle Fusion Middleware Developers Guide for Oracle SOA Suite.

16.2.3 Narrow Qualifying Tasks Using Precise Filters

Using precise filters is one of the most important factors in improving response time. When a task list is retrieved, the query should be as precise as possible so the maximum filtering can be done at the database level. For example, when the inbox view is requested for a user, the tasks are filtered mainly based on whether they are assigned to the current user or to the groups the user belongs to. By specifying additional predicate filters on the inbox view, the overall response time for the query can be reduced since lesser number of tasks qualify. Alternatively, you can define views by specifying predicate filters and the overall response time for such views is reduced since lesser number of tasks qualify. All predicates passed to the query APIs or defined in the views are directly pushed to the database level SQL queries. With this information, the database optimizer can use the best indexes to create an optimal execution plan. The additional filters can be based on task attributes or promoted flex fields. For example, instead of listing all PO approval tasks, views can be defined to present tasks to the user based on priority, date, category, or amount range.