The background user for the workflow runtime system or a user who creates an event always occupies a work process if a transactional RFC is sent. This occurs during the following actions in workflow:

• When starting event receivers (that contains exiting an asynchronous method).
• When starting a background step whose predecessor was not exited by an event.

 

Inbox Issues!!!

• The selection time of work items in a user inbox increases with the number of tasks which the user may process.

• The selection time also increases with the number of available work items.

• Data of a work item may have to be read by the database.

 

Reducing the number of work items for each workflow.

• Replace reading/calculating background methods by virtual attributes (for the evaluation of a virtual attribute, no work item is created).

• Group together several small background methods in one large group (a work item is created for every background step).

 

Prevent unnecessary tRFCs

• Replace asynchronous methods by synchronous methods (thus the system does not have to execute the exiting event = tRFC). This is usually possible if the method is not exited in the update program.

• Do not check input data in the first workflow step but use the option to enter a check function module in transaction SWE2. Thus you avoid the generation of unnecessary work items and the relocation of unnecessary tRFCs.

• Restrict the number of application servers on which you can start event receivers of events generated on a large-scale. As a result, other application servers will be available for 'regular' online operations. To do this, create a RFC destination of the type '3' in transaction SM51 and permit the load distribution. Remember that system parameters control the intervals according to which the message server searches free application servers. Then enter this destination in the detail screen for the event in transaction SWE2.

Inbox

• Define the task assignment in the organizational model concretely. (Do not classify tasks as general tasks). Every user should only be a possible agent of very few tasks.

• Remove columns from the starting configuration of the inbox. A subsequent selection of the database occurs for the following columns:

• • Task long name

• • Finish by date

• • Finish by time

• • Overdue (up to and including Release 3.1I)

• • Object (in older releases, object key 1)

• • Group (in older releases, object key 2)

• Archive work items that are not required for a longer period and subsequently update the database indexes (read also notes 72873, 49545).

• Allow the system to buffer as much data as possible. To do this, maintain the entries in group WFLOW in table T77S0 (in particular, entries with identification codes BUF, INBOX, ROLE).

With WFLOW INBOX, the buffer mode is set for tasks that are assigned to a user, as well as for organizational assignments of users. We can assume the following values:

• • 'I' : Buffering in database INDX, refreshment at least once a day

• • 'S' : Buffering in the shared buffer on the application server

• • ' ' : No buffering

WFLOW ROLE is used to check the result of the agent determination. 'X' (recommended). The agent is checked if it is a possible agent (and not an excluded agent, and so on).

WFLOW BUF is no longer.