chapter 7 supporting application processing...generates schedules (data objects) for them for each...

Chapter 7 Supporting Application Processing

Chapters 2 and 3 present the initial setup tasks you complete so you and your developers can begin working on your Process Commander system. This chapter describes the setup tasks that configure background processes so work is routed correctly and user sessions are handled appropriately while users interact with your applications. This chapter contains the following sections:

■ Introduction to Agents and Listeners

■ Configuring Requestors

■ Configuring Agents

■ Configuring E-mail Accounts

■ Configuring the Routing of Work and Assignments

7-2 Administration and Security � Supporting Application Processing

Introduction to Agents and Listeners Many Process Commander functions rely on processes that operate in the background, performing tasks on behalf of the system and its users.

Agents and listeners route work according to the rules in your application. Agents also perform system tasks such as sending e-mail notifications about assignments and outgoing correspondence, generating updated indexes for the full-text search feature, synchronizing caches across nodes in a multiple node system, and so on.

Agents Agents are internal background processes operating on the server that run activities according to a schedule. Agents are autonomous and asynchronous. The activities they call run individually on their own schedules and one activity does not have to finish before another one runs.

Agents are implemented through two Process Commander objects:

■ Agent queue rules � instances of Rule-Agent-Queue. These rules specify the activities the agent runs and the interval, in seconds, at which it runs them. There can be no more than one agent queue rule in a RuleSet.

■ Agent schedule data objects � instances of Data-Agent-Queue. Process Commander generates these schedules for each node in the system, based on the settings in the agent queue rule. For each agent queue rule, one agent schedule is generated for each node in the system.

The agent queue rule is a template that specifies the global settings for all nodes running the agent. To modify the schedule for an activity run by an agent, you open the generated schedule object for a specific node and modify the schedule in that object.

Supporting Application Processing � Introduction to Agents and Listeners 7-3

Master Agents The PegaRULES engine runs two master agents:

■ Agent Manager. This master agent gathers and caches the agent configuration information set for your system when Process Commander starts up. Then, at a regularly scheduled interval, it checks whether any new agent queue rules have been defined. If they have, the Agent Manager adds them to its list of agents and generates schedules (data objects) for them for each node.

■ Requestor Manager. At a regularly scheduled interval, this master agent examines the state of all the requestors in the system to see if any have timed out. If a requestor has timed out, the Requestor Manager terminates it.

The master agents� behavior is determined by settings in the prconfig.xml file, which is described later in this section.

Standard Agents By default, Process Commander relies on two standard agents: Pega-ProCom and Pega-RULES. If your system is using the PegaDISTRIBUTION Manager application, Process Commander also uses the Pega-IntSvcs agent.

The Pega-ProCom agent queue rule is configured to run two activities by default and two additional activities if you enable them:

■ ProcessServiceLevelEvents � compares the current time to the times specified as the goals, deadlines, and late times of the current assignments. This activity is enabled by default and it runs every 30 seconds. For more information, see �Configure the SLA Agent� on page 7-22.

■ SendCorr � sends notify messages to users about assignments and outgoing correspondence to work parties. This activity is enabled by default and runs every 30 seconds.

■ Email_CheckIncoming � checks the inboxes of any incoming e-mail accounts that have been configured and if it finds messages, routes them according to the settings in the e-mail account. When enabled, it runs once every 30 seconds.


■ GetConvertedPDFsFromPDM � checks the PDM Requests table to see if any Word documents have been converted to PDF files. You enable this activity only if you are using PegaDISTRIBUTION Manager and you want to use it to convert Word files attached to work objects into PDF files. For information about this product, see the PegaDISTRIBUTION Manager for Process Commander Installation and Configuration, which is available on the Pega Developer Network (PDN).

Figure 7-1 shows the Pega-ProCom agent queue rule.

Figure 7-1. Pega-ProCom Agent Queue

The PegaRULES agent queue is configured to run three activities by default:

■ SystemCleaner � removes stale entries from system caches once a day.

■ SystemPulse � synchronizes the system caches once every minute.

■ SystemIndexer � generates and updates the indexes that support the Find feature once every minute.

Figure 7-2 shows the Pega-RULES agent queue rule.


Figure 7-2. Pega-RULES Agent Queue

You cannot add your background processing activities to the standard Process Commander agents. Instead, you create your own agent rules that run your agent activities. You can create one agent queue rule in a RuleSet.

Agent vs. Activity Because the processing of an agent is completed through activities, the term agent sometimes refers to the agent (the rule and/or the data object) and sometimes it refers to an activity the agent runs.

For example, sometimes the ProcessServiceLevelEvents activity is referred to as the SLA agent. In another example, typically the SystemPulse activity run by the Pega-RULES agent is called, simply, the System Pulse.

Additionally, the Agent Management page in the System Management application lists each activity specified in an agent queue rule as a separate entry. On that page, the term agent means an agent activity and queue means agent queue rule.


Access Rights for Agents As mentioned in Chapter 6, �Configuring Access Rights,� Process Commander users are represented and defined by requestors � instances of Data-Admin-Requestor. Requestors are Java objects that hold information about a user and that user�s session.

Agents run as batch requestors. Therefore, one of your tasks as a system administrator is to create an access group for agents and assign that access group to the batch requestor type.

The batch requestor�s access group must give it access to all the RuleSets in the system that have rules that are invoked by the activities specified in the agent rules. For example, for the SLA agent to find the service level rules in your applications, the RuleSet that contains your service level rules must be specified in the access group assigned to the batch requestor type. The best practice is to create an application rule (built on the PegaRULES application) that contains all the RuleSets on your system and assign it to the access group used by the batch requestor.

It is possible to override the batch requestor access group in an agent queue rule or agent schedule data object. However, this approach is not recommended and should be used only in exceptional cases.

Listeners A listener is a Process Commander background Java thread that monitors a mailbox or a message queue for arriving messages or monitors a directory for arriving files whose names match a specified pattern. Typically, the messages or files deliver work for your applications to process; the listener routes the messages to the appropriate service rule; and the service rule routes the work to the appropriate flow.

A service is a set of rules and data objects that reveals a function or data model of your application to an external system. Four service types � e-mail, file, JMS and MQ � rely on listeners. For example, Figure 7-3 shows a file listener.


Figure 7-3. Example of a File Listener

The System Management application lists all the listeners running on your Process Commander system. You start and stop individual listeners, and you can �ping� them to see if they are running from the Listener Management page in the System Management application. Listener Management is the third link in the navigation panel of the System Management application.

Your application developers may ask for your help when creating the listeners that support their integration implementations. For more information, see Integrating with External Systems and see the Integration Services pages on the Pega Developer Network (PDN).


The prconfig.xml file Each Process Commander instance (node) has a configuration file named prconfig.xml that holds the configuration settings for an installation. The file is loaded on startup and is used by the startup process to determine information about the system � the location of the PegaRULES database and which database driver to use to connect to the database, the system name, whether to automatically start agents and listeners, configuration settings for the master agents, and so on.

To change settings in the prconfig.xml file, you must stop Process Commander, make the changes, and redeploy Process Commander. Using the deployment tools provided by the application server hosting Process Commander, complete the following steps:

1. Stop the Process Commander application.

2. Undeploy the Process Commander application.

3. Do one of the following:

− If Process Commander is deployed as a web application, locate and unzip the prweb.war file to a location that you have access to. Then extract the prconfig.xml file from the WEB-INF\classes directory.

− If Process Commander is deployed as an enterprise application, locate and unzip the prresources.jar (it is in the APP-INF\lib directory.) Then extract the prconfig.xml file from the .jar.

4. Open the prconfig.xml file in a text editor.

5. Add the entries you need or change the existing entries.

6. Save the file and repackage the modified prconfig.xml file into the prweb.war or prresources.jar file, as appropriate.

7. Redeploy the Process Commander application.

For information about all the settings in the prconfig.xml file, see the document prconfig.xml Settings File Reference, which is available on the PDN.

Supporting Application Processing � Configuring Requestors 7-9

Configuring Requestors During the development of your applications, you must determine how you want requestors to behave. Specifically, when should timeouts occur and when should a requestor�s session be preserved?

Authentication timeout is the period of time a requestor can remain inactive before that requestor's user must provide user credentials again. Requestor timeout is the period of time a requestor can remain inactive before it is destroyed or saved. In the case of an authentication or a requestor timeout, the browser challenges the user to log in again.

It is a best practice to configure your system so that the requestor timeout is longer than the authentication timeout. When a requestor is inactive long enough to trigger an authentication timeout, the user�s requestor and session information remains intact. As long as the user logs in again (reauthenticates) before the requestor times out, the user can resume work without losing data.

In addition to keeping session state intact when a requestor times out, you should determine whether you want to configure your system so that requestor session state is preserved in the case of application server failure.

Authentication Timeout You set authentication timeout in individual access groups. Open the individual access group, select the Settings tab, and enter the number of seconds in the Authentication Timeout field.

Requestor Timeout By default, requestor timeout parameters are as follows:

■ Browser: 3600 seconds (60 minutes)

■ Application: 600 seconds (10 minutes)

■ Batch: 300 seconds (5 minutes)


■ Portlet: 3600 (60 minutes)

To change these values, you must edit the prconfig.xml file to include a timeout entry and insert a statement for the parameter you want to change. For example:

<env name="timeout/application" value="300"/>

<env name="timeout/browser" value="1800"/>

Additionally, how often should the Requestor Manager master agent wake up to scan for and destroy stale requestors? By default, it wakes up every 60 seconds to look for stale requestors. To change that schedule, use the requestortimeoutwakeup setting. For example:

<env name="agent/requestortimeoutwakeup" value="120"/>

For information about changing prconfig.xml settings, see �The prconfig.xml file� on page 7-8.

Failover Support The PersistRequestor setting specifies at what point the entire context of a requestor is to be saved. Use it to configure Process Commander to keep requestor session state information as HTTPSession objects that can be retrieved from the database by another application server if the current one fails.

To configure this option, insert an entry for the PersistRequestor setting into the Initialization node of the prconfig.xml file. Figure 7-4 lists the possible values for the PersistRequestor setting.

Supporting Application Processing � Configuring Requestors 7-11

PersistRequestor Value

Description

Never The requestor context is never saved.

OnTimeOut The requestor context is saved as an instance of System-Requestor-Context when a requestor times out. This is the default value.

AtInteractionEnd The requestor context is saved as an instance of System-Requestor-Context at the end of each HTTP request/response interaction.

UseHTTPSession The requestor context is saved as an instance of System-Requestor-Context at the end of each HTTP interaction. In addition, the requestor context is stored as an HTTP Session object that the application server can transparently move to another server. In this case, the user/requestor does not have to reauthenticate because the authentication information is included in the HTTP session object.

Figure 7-4. Values for the PersistRequestor Setting

For example:

<env name="Initialization/PersistRequestor" value="OnTimeout"/>

For more information about this parameter, see the prconfig.xml reference, which is available on the PDN.

For information about changing prconfig.xml settings, see �The prconfig.xml file� on page 7-8.


Configuring Agents This section describes how to configure the agents that support Process Commander and your applications.

Configuring the Master Agents Figure 7-5 lists the settings from the prconfig.xml file that determine the behavior of the master agents, Agent Manager and Requestor Manager.

Setting Description

Enable Specifies whether agents can run or not. If you set this value to false, the Agent Manager does not run any agents. Default value: true.

Minimumwakeup Specifies the shortest amount of time allowed as the interval at which an individual agent activity can run. If someone sets the interval of an agent activity to be less than this value, this value overrides it.

Default value: 30 seconds. Minimum value: 5 seconds.

Newqueuewakeup Specifies how often the Agent Manager checks for new agent queue rules. Default value: ten minutes (600 seconds).

requestortimeoutwakeup Specifies how often the Requestor Manager checks for timed out requestors. Default value: 60 seconds

Threadpoolsize Specifies the number of Java threads on which agents and batch requestors can run. In other words, specifies the number of requestors allowed in the batch requestor pool. Default value: 5.

Figure 7-5. Master Agent Configuration Settings

Typically, there is no need to change these settings from their default values. If your system needs a different value, consult the prconfig.xml reference, which is available on the PDN.

Supporting Application Processing � Configuring Agents 7-13

Configuring the Standard Agents The standard Process Commander agent rules, Pega-ProCom and Pega-RULES, are in locked Process Commander RuleSets. To enable a disabled activity or to change the interval at which an activity runs, use the generated agent schedule instances, not the agent queue rules.

Note. All agent schedule instances generated for an agent queue rule should use the same access group. The default behavior is for agent schedule instances to rely on the access group assigned to the batch requestor, which ensures that all agents are using the same access group. For the standard agents, it is a best practice to associate access groups with agents through the batch requestor, not through the agent schedule forms on an agent-by-agent basis.

1. In the Rules by Type explorer, choose SysAdmin > Agent Schedule. (Do not choose Agent Queue.) A list of agent schedules appears.

2. To modify the schedule of any of the activities run by the Pega-ProCom agent (Figure 7-1), select the first Pega-ProCom agent schedule in the list and open it. To modify the schedule of an activity run by the Pega-RULES agent (Figure 7-2), select the first Pega-RULES agent in the list.

3. On the Schedule tab, make the necessary changes.

4. Click Save and close the form.

5. If your Process Commander system uses more than one node, there will be more than one Pega-ProCom and Pega-RULES agent schedule in the list. Repeat steps 2 through 4 for each one.

For information about the SLA agent, see �Configure the SLA Agent� on page 7-22.


Creating New Agents for Your RuleSets To create new agents, you create agent queue rules in your RuleSets. You can create only one agent queue rule for a RuleSet. Then, the next time the Agent Manager master agent runs (specified by the newqueuewakeup setting in prconfig.xml), your new agent rule is added to the list of agents and agent schedules are generated for each node in your Process Commander system.

Before you begin, determine the processing that must be done by the agent activities. Then create the activities in the appropriate RuleSet � the activities must be in the same RuleSet as the agent that runs them.

To create an agent queue rule, complete the following steps:

1. In the Rules by Type explorer, choose SysAdmin > Agent Queue. A list of agent queue rules appears.

2. Click New.

3. In the New form, select your RuleSet name and version and then click Create.

4. Enter a meaningful description of the new agent in the Short Description field.

5. On the Schedule tab, specify the class the activity belongs to and then the activity.

6. In the Pattern field, specify whether the interval at which the activity runs is periodic (every x number of seconds) or recurring at a specified time (for example, every Monday at 5:00).

7. Do one of the following:

− If you specified Recurring in the Pattern field, click the Advanced button and specify the schedule.

− If you specified Periodic in the Pattern field, specify the interval in one of the following ways:

Set the number of seconds in the activity�s Interval field.

Supporting Application Processing � Configuring Agents 7-15

Leave the activity�s Interval field blank and specify a value for the Interval field in the Agent-Wide Settings section. Any activity set to periodic without an interval setting of its own will use the agent-wide interval value.

8. Complete steps 5 through 7 for each activity you want the agent to run.

9. Complete the History tab with a full description.

10. Save the agent queue rule.

11. Verify that the access group assigned to the Batch requestor type grants access to the RuleSets of the activities specified in the agent queue rule.

Starting and Stopping Agents All agents start each time you start your Process Commander system. Agents running on a specific node start as that node starts.

The System Management application lists all the agent activities running on your Process Commander system on the Agent Management page. You start and stop entire agent queues, individual agent activities, and you can �ping� them to see if they are running from this page.

To start or stop an agent queue or an individual agent activity, complete the following steps:

1. From the menu, choose Tools > System Management application.

2. Choose the Agent Management link from the navigation pane.

3. Use the functions displayed on the Agent Management page to start or stop the agent queue or agent activity.


Configuring E-mail Accounts E-mail messages are a key part of the business processes that developers build with Process Commander flow rules. Flows typically send e-mail messages to work parties and to people outside your organization such as customers and vendors. Additionally, incoming e-mail messages can deliver work objects to your business processes. Use e-mail account data instances (Data-EmailAccount) to record the e-mail servers and accounts that your Process Commander system can use.

Process Commander provides a standard e-mail account data object named Default.Notify that supports the correspondence feature of your flows. To use e-mail in your Process Commander applications, update the Default.Notify e-mail account object so that it defines a valid e-mail account for your organization. Then create any additional e-mail accounts needed to implement the design goals of your applications.

Overview An e-mail account (Data-EmailAccount) has two keys:

■ Name � This is an arbitrary string. To support the standard correspondence feature, you should maintain one e-mail account that uses the name �Default� (with the Type set to Notify, as described below). If different applications need to use different e-mail accounts, it is a best practice to use the name of the application�s classgroup as the name of the email account.

■ Type � this is also an arbitrary string, but the standard correspondence feature depends on two string values: Notify and Receive.

− Specify Notify if the e-mail account is to process outgoing email.

− Specify Receive if the e-mail account is to process incoming email.

Notify The flow correspondence feature is implemented by a set of standard activities and rules. The activity Work-.getEmailSenderInfo looks for an e-mail account with a Name that matches the classgroup of the work object and the Type set to Notify. If the activity does not find a match, it uses the e-mail account named Default.Notify

Supporting Application Processing � Configuring E-mail Accounts 7-17

instead. Therefore, you should always have one e-mail account named Default.Notify (Figure 7-6) so the activity will always find an account.

Figure 7-6. Default.Notify E-mail Account

Receive Incoming e-mail messages that deliver work objects can be managed by either of the following options:

■ The Pega-ProCom agent and incoming e-mail accounts (Data-EmailAccount)

■ E-mail service rules (Rule-Service-Email)

The list of activities specified for the Pega-ProCom agent includes the @baseclass.Email_CheckIncoming activity. When Email_CheckIncoming runs, it looks for e-mail accounts with Type set to Receive. Email_CheckIncoming then runs the Data-EmailAccount.EmailReceive activity to create work objects for the messages sent to the account. To use this option to process e-mail messages that deliver work to Process Commander, you enable this activity in the agent and specify how often the agent should run it.

Use e-mail service rules to process e-mail messages that deliver work when the text of the e-mail messages is something other than plain text. The e-mail messages managed by e-mail service rules can contain text formatted as free text, XML, or


XML in a SOAP envelope. For information about setting up and using e-mail service rules, see the Application Developer Help system.

Creating Incoming E-mail Accounts Before you begin, gather the following information:

■ Account name

■ Internet address of the mail server

■ Password

■ If the e-mail messages delivered to this account are to be processed as work objects:

− The name of the appropriate work class and model rule

− The name of the operator ID to use as the originator of the work object

Then you do two things:

■ Create the email account.

■ Configure the Pega-ProCom agent to check for incoming e-mails.

Create an Incoming E-mail Account Complete the following steps:

1. In the Rules By Type explorer, choose SysAdmin > Email Account. A list of accounts appears.

2. Click New. The New form appears.

3. In the New form, complete the fields as follows:

− In the Name field, enter any unique name of your choice. Start with a letter and use only alphanumeric characters.

− In the Type field, enter the string �Receive.�

4. Click Create.


5. In the Email Account form, select the Incoming Mail tab and complete the POP3 Mail Account or IMAP Mail Account fields. For help with individual fields, see the Application Developer Help system.

6. (Optional) If the e-mail messages delivered to this account are to be processed as work objects, do the following:

− Specify the name of the appropriate work class and model rule for the work object.

− Specify the operator ID to use as the originator of the work object.

7. Do not specify values on the Outgoing Mail tab.

8. On the History tab, enter descriptions in the Full Description and the Usage fields.


Enable the Email_CheckIncoming Agent Activity To enable the Pega-ProCom agent to check for incoming mail, complete the following steps:

1. In the Rules by Type explorer tree, choose SysAdmin > Agent Schedule. (Do not choose Agent Queue.) A list of agents appears.

2. Select the first Pega-ProCom agent schedule in the list and open it

3. On the Schedule tab, enable the Email_CheckIncoming activity.


5. If your Process Commander system uses more than one node, there will be more than one Pega-ProCom agent instance in the list. Repeat steps 2 through 4 for each Pega-ProCom agent in the list.


Creating Outgoing E-mail Accounts Outgoing e-mail accounts support the correspondence feature for process flow rules. Before you begin, gather the following information:

■ Account name. You should configure the standard e-mail account named Default to support the correspondence generated by flows. If you need additional accounts for each application, determine the name of the application class groups and use the class group names as the account names.

■ Internet address of the mail server.

■ Password.

Complete the following steps:

1. In the Rules By Type explorer, choose SysAdmin > Email Account. A list of accounts appears.

2. Click New. The New form appears.

3. In the New form, complete the fields as follows:

− In the Name field, enter a name that starts with a letter and use only alphanumeric characters. Create at least one e-mail account named Default. If you are creating different e-mail accounts for each application, use the name of the application�s class group as the name of the e-mail account.-

− In the Type field, enter the string Notify.

4. Click Create.

5. In the Email Account form, select the Outgoing Mail tab and specify the sender information. If you need help with any of the fields on the form, click the Help button.

6. Do not specify values on the Incoming Mail tab.

7. On the History tab, enter descriptions in the Full Description and the Usage fields.


8. Save the e-mail account.

Note: Be sure to modify the system default e-mail account, Default.Notify, so that it is valid for your system.


Configuring the Routing of Work and Assignments The procedures in this section include setup tasks that may be necessary depending on how your Process Commander applications are designed to manage and route work and assignments.

Configure the SLA Agent Service-level rules specify goals and deadlines that indicate the expected or targeted time to complete an assignment or resolve a work object. Process flows can be designed to perform tasks such as notifying appropriate parties and escalating assignments when deadlines and goals are not met.

When an assignment is created and service level rules apply, Process Commander calculates the goal, deadline, and late times and stores those times with the assignment. When the ProcessServiceLevelEvents activity runs, it compares the current time to the goal, deadline, and late times of assignments to determine whether or not they are late. This activity is run by the Pega-ProCom agent and is called the SLA (Service-Level Agreement) agent.

Specify Your RuleSets If the flows your developers are designing use service-level rules, the Batch requestor type must be granted access to the RuleSets that contain those rules. You accomplish this task by specifying your RuleSets in the access group assigned to the Batch requestor type.

Complete the following steps

1. From the Rules by Type explorer tree, choose SysAdmin > Requestor Type.

2. Open the Batch requestor and determine the name of the access group.

3. Open the access group and determine the name of the application rule.

4. Open the application rule and verify that your RuleSets are listed.

Supporting Application Processing � Configuring the Routing of Work and Assignments 7-23

Configure Assignment Processing Settings While testing your applications, you should determine how the SLA agent should process assignments.

■ By default, the activity runs every 30 seconds. How many assignments should it try to process in each 30-second interval?

■ The query the activity runs to retrieve assignments excludes those that have an error status, but sometimes assignments cannot be processed because they are locked. To save time, should the activity retrieve more assignments than it is configured to process so it does not waste time getting more if some cannot be processed?

To answer these questions, experiment with the dynamic system settings listed in Figure 7-7 and analyze the results.

Dynamic System Setting

Description

SLAUnitsToProcess Specifies how many assignments the activity processes each time it runs.

SLAUnitsToRetrieve Specifies how many assignments to retrieve for each assignment it attempts to process.

SLARefreshEachIteration Specifies whether the list of retrieved assignments should be discarded and a new list retrieved for each assignment it attempts to process.

Figure 7-7. Dynamic System Settings for the SLA Agent

For example, on a single-node system you could start by setting the units to process and retrieve at 250 but keep the refresh setting set to false so the activity just works its way through the list. You would tune the number to process based on how many assignments are typically waiting in work lists and workbaskets.

On a multiple node system, each node runs the SLA agent every 30 seconds. You set values for these settings based on how many nodes are running the agent and how


many assignments are typically in worklists and workbaskets. For example, imagine that you set units to process to 10 and units to retrieve to 5. That means when each node runs the activity it tries to process 10 assignments, and for each of the assignments it tries to process it retrieves 5 to be sure it can process at least one of them.

Synchronize Clocks When assignments are created, the goal, deadline, and late times are calculated based on the current time on the Process Commander server. When the SLA agent activity runs, it compares the saved goal, deadline, and late times against the current time of the database server.

Ensure that the clocks on the Process Commander server and the database server stay synchronized so assignments are escalated appropriately.

Get Next Work Get Next Work is a standard feature that your developers can implement by designing their applications so the Get Most Urgent button appears on users� worklists. When a user clicks the button, Process Commander returns the assignment that should be completed next, based on the assignment urgency, which can be increased by the goal, deadline, and late times set by service-level rules.

When this feature is designed into your applications, you must use the Get Next Work section on the Work Access tab in the operator IDs to determine whether assignments should be taken first from the user�s personal worklist or from a workbasket (or list of workbaskets).

Routing Work Based on Skills The routing activities used by flows to route assignments to operators� worklists can base routing decisions on the concept of skills. For example, perhaps certain work objects should be routed only to operators who can read Spanish or to operators who completed a specific kind of training.

Supporting Application Processing � Configuring the Routing of Work and Assignments 7-25

When this is the case, you work with the developers to determine what the skills are that the routing decisions are based on, create skill rules (Process > Skill), and then assign the skill rules and proficiency ratings to the appropriate operator ID records. Your developers can then use the standard routing activity Work-.ToSkilledWorkbasket in the flows so assignments get routed to users based on desired and required skills.

Finding Substitutes Use the Finding a Substitute Assignee section on the operator record�s Availability tab to implement any substitution processing your developers are designing into the flows. When the user to whom an assignment should be routed is not available, the settings on the Availability tab determine where to route the assignment next: to an operator�s personal worklist or to a workbasket.

Talk with your developers about finding substitutes. If you are to implement substitution in this way, they must describe the substitution logic � whether the user�s assignments should be routed to another operator or to a workbasket � and provide any decision rules, if appropriate.

Virus Scanning for Work Attachments You can install virus-scanning software on your Process Commander server and then configure Process Commander to run the software whenever an operator attaches a file to a work object.

All of the standard flow processing and other activities that attach files to work objects have a step that calls an extension point activity named Data-WorkAttach-File.CallVirusCheck. In its default state, this activity does nothing � it simply returns to the calling activity. You or your developers can save this activity in one of your application RuleSets (keeping the name intact) and code steps that invoke your virus-scanning software.


If the virus scanning software detects a virus, it must return the status message Virus-Found. If the software fails during the scan, it must return the status message Virus-Scan-Failed.

When a virus scan process returns either Virus-Found or Virus-Scan-Fail, Process Commander stops the attachment process, writes the error to the history of the work object, and displays an error message in the user�s browser (unless the user is a background process). If the scan returns any other status message, Process Commander assumes that the attachment is clean of viruses or that virus scanning is not implemented and the attachment process continues.

Talk with your developers about implementing this feature.

chapter 7 supporting application processing...generates schedules (data objects) for them for each...

Documents