Process Design

There are many aspects to process design that affect performance.

  • Process Data - Size of data being passed around the process and passed to work items (number and type of fields, BOM number, complexity, and size) can have a marked impact on performance.
  • Scripts - Examine the scripts in the process, including script tasks and those that are run as Process Manager (PM) and Work Manager Scripts. For script tasks, consider whether the contents can be moved into the PM complete script that is on the previous task. Doing so removes an entire task from the process flow, reducing audit data and processing required.
  • Database Tasks - Examine the data that is selected, updated, inserted, or deleted. Consider different JDBC resources for different database tasks. This reduces contention when a database connection is required for the task. Check that the relevant indexes are set for the SQL operations performed.
  • Gateways - Consider whether the gateways in the process are actually required. For example, a parallel split gateway may not actually be needed and can be replaced by just having two paths running directly from the task:
    User task followed by two parallel tasks in Business Studio
  • Web Service Tasks - The location of web services, whether local or on a remote machine has an effect on performance. Service virtualization is an option to consider.

    How well the service host is configured to support concurrent client requests affects performance as well.

    The exact nature of the service calls (database calls, writes to disk) should be examined as well to determine if there are efficiencies to be made.

    Use a monitoring tool such as the Membrane Monitor tool (http://www.membrane-soa.org/soap-monitor/) to intercept traffic between BPM and the web services to see if the data being passed could this be reduced.

  • Reply Tasks - Determine if the reply tasks are necessary to the process flow. If no data is being returned, consider using the “reply immediate” setting for the process. This ensures that the client does not wait for the process instance to start in order to reach the reply task.
  • Chained Groups - At the start of an embedded sub-process that is a chained group, the user task make an asynchronous call to BRM to start a new group. Once BRM has replied the instance is queued for processing again by an available process engine thread. The asynchronous way that chained groups are implemented means that you cannot expect work items to appear as soon as the instance is started; there will be some latency. If this proves problematic, consider revising the process.
  • User Task Offer Sets - When allocating or re-offering a work item BRM has to move the offer set between the brm_work_item_offer and brm_work_item_resources table. This involves deleting and then inserting the rows in the database.

    With a large offer set (>500) you may notice that the time to allocate or allocateAndOpen a work item (in the offered state) may take longer than opening a work item already allocated to you.

    Also, with a large offer set, the scheduling of the work item will be slightly slower due to the increased number of database inserts that are performed. The impact is most obvious, however, during the allocation of the work item.