Release 2.6.4
Part Number B15852-05
Contents
Previous
Next
| Oracle Workflow Administrator's Guide Release 2.6.4 Part Number B15852-05 | Contents | Previous | Next |
This chapter describes how to use the Oracle Workflow Manager component of Oracle Applications Manager.
This chapter covers the following topics:
Oracle Workflow Manager is a component of Oracle Applications Manager that allows system administrators to manage Oracle Workflow for multiple Oracle Applications instances from a single console.
Using Oracle Workflow Manager, administrators can control Workflow system services, such as notification mailers, agent listeners, and other service components, background engines, purging obsolete Workflow data, and cleanup of the Workflow control queue. Administrators can also monitor work item processing by viewing the distribution of all work items by status and drilling down to additional information. Additionally, they can monitor event message processing for local Business Event System agents by viewing the distribution of event messages by status as well as queue propagation schedules. With this ability to monitor work items and event messages, a system administrator can identify possible bottlenecks easily.
To access Oracle Workflow Manager, log into Oracle Applications Manager and select an applications system. Then, you can follow one of the following navigation paths:
Choose Workflow Manager from the pull-down menu in the Applications Dashboard page and click the Go button.
Choose Site Map, choose the Administration tab, and then choose the Home link in the Workflow region of the Site Map page. You can also choose one of the other links in the Workflow region to navigate directly to the corresponding page within Oracle Workflow Manager.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go
You can also use other Oracle Applications Manager features to help manage Oracle Workflow.
Use Oracle Diagnostics to run diagnostic tests that check the setup of your Oracle Workflow installation and review debugging information.
Use Oracle Applications Logging to review Oracle Workflow logs. Oracle Workflow uses the Oracle Applications Logging framework to standardize and centralize in the database logging activities related to the Oracle Workflow Business Event System and Oracle XML Gateway.
Note: The Java middle tier components of Oracle Workflow, including notification mailers and agent listeners, also use Oracle Applications Logging; however, due to the high volume of messages that pass through these components, their information is logged to the file system by default.
Some Oracle Workflow Manager graphs and lists may summarize large volumes of data, depending on the level of activity in your Oracle Applications instance. To enhance performance in displaying these statistics, Oracle Workflow Manager periodically runs concurrent programs to gather the statistics and displays the graphs and lists based on the latest data from the concurrent programs.
Workflow Agent Activity Statistics Concurrent Program (FNDWFAASTATCC) - Gathers statistics for the Agent Activity graph in the Workflow System status page and for the agent activity list in the Agent Activity page.
Workflow Mailer Statistics Concurrent Program (FNDWFMLRSTATCC) - Gathers statistics for the throughput graph in the Notification Mailer Throughput page.
Workflow Work Items Statistics Concurrent Program (FNDWFWITSTATCC) - Gathers statistics for the Work Items graph in the Workflow System status page, for the Completed Work Items list in the Workflow Purge page, and for the work item lists in the Active Work Items, Deferred Work Items, Suspended Work Items, and Errored Work Items pages.
These concurrent programs are scheduled to run every 24 hours by default. They do not require any parameters. You can optionally cancel the default scheduled requests and run the programs with a different schedule if you want to gather statistics at a different frequency.
Each of these graphs and lists displays the date and time when its statistics were last updated, as well as a refresh icon that you can select to refresh the statistics immediately if necessary. However, note that if your Oracle Applications instance contains very large volumes of workflow data, you may encounter delays or page timeouts when refreshing the data.
Note: Oracle Workflow Manager statistics that typically represent smaller volumes of data, such as work item details and work item activity details, are queried directly rather than through the concurrent programs.
The Workflow System status page provides a high-level view of the status of your Oracle Workflow instance. The page displays the date and time when the system status information was last updated. To refresh this information, click the refresh icon. To add the information from this page to your support cart, click the Add to Support Cart button.
Note: The system status information is queried directly, separately from the concurrent programs that gather other Oracle Workflow statistics.
The Workflow System status page shows the up, down, or unavailable summary status of the following Workflow features:
Notification Mailers - To manage notification mailer service components, click the Notification Mailers status icon.
Agent Listeners- To manage agent listener service components, click the Agent Listeners status icon.
Service Components - To manage all types of service components, click the Service Components status icon.
Background Engines - To view Workflow Background Process concurrent requests, click the Background Engines status icon.
Purge - To view summary information about Purge Obsolete Workflow Runtime Data concurrent requests and completed work items, click the Purge status icon.
Control Queue Cleanup - To view Workflow Control Queue Cleanup concurrent requests, click the Control Queue Cleanup status icon.
For service component features, including notification mailer service components, agent listener service components, and all types of service components grouped together, the summary status icons represent the following statuses:
Down - At least one service component of this type has a status of Stopped with Error or System Deactivated. You should investigate the error.
Up - At least one service component of this type has a status of Running or Suspended, and no service components of this type have a status of Stopped with Error or System Deactivated.
Unavailable - No service components of this type have a status of Running, Suspended, Stopped with Error, or System Deactivated. For example, if all service components of this type either have not yet been completely configured, or have stopped without errors, then the Unavailable summary status is displayed.
To submit a concurrent request through Oracle Self-Service Web Applications for a feature that runs as a concurrent program, choose the program you want from the Submit Request For pull-down menu and click the Go button. You can submit requests for the following programs:
Background Engines
Purge
Control Queue Cleanup
This region displays information about database initialization parameters required for Oracle Workflow. For each parameter, the list shows the parameter name, actual parameter value, recommended value, and description. If the actual value does not match the recommended value, the recommended value is marked with a warning indicator icon. The following parameters are shown:
JOB_QUEUE_PROCESSES - This parameter defines the number of SNP job queue processes for your instance. Oracle Workflow requires job queue processes to handle propagation of Business Event System event messages by AQ queues and for notification mailers. The recommended number of processes for Oracle Workflow is ten or more.
AQ_TM_PROCESSES - This parameter enables the time manager process in Oracle Advanced Queuing (AQ). The time manager process is required by Oracle Workflow to monitor delay events in queues, as in the case of the Oracle Workflow standard Wait activity, and for notification mailers. The recommended number of time manager processes for Oracle Workflow is one or more.
This region displays summary information about work items and Business Event System agent activity.
This graph displays the distribution of all work items with the following statuses: Active, Deferred, Suspended, and Error.
To show this graph if it is hidden, click the Show link.
To hide this graph if it is shown, click the Hide link.
The graph header displays the date and time when the work item statistics were last updated. To refresh this information, click the refresh icon. See: Gathering Oracle Workflow Statistics.
To view the distribution of item types within a status, either click the bar for that status in the graph, or click the status name link.
To view the number of work items with a particular status, position the mouse pointer over the bar for that status in the graph.
Note: A work item can be counted in more than one status. For example, all work items that do not have an end date are counted as Active work items, including deferred, suspended, and errored work items as well as running work items. Also, if an activity within an item is deferred, and the work item as a whole is suspended, the work item is included in the count for both the Deferred and Suspended statuses. Consequently, the total of the counts for all the statuses is greater than the actual number of work items.
This graph displays the distribution of all event messages on Business Event System agents with the following statuses: Ready, Waiting, Expired, Undeliverable, and Error.
Note: Messages are not explicitly assigned a status of Error. The Error bar in the graph represents messages of any status on the WF_ERROR agent.
To show this graph if it is hidden, click the Show link.
To hide this graph if it is shown, click the Hide link.
The graph header displays the date and time when the agent activity statistics were last updated. To refresh this information, click the refresh icon. See: Gathering Oracle Workflow Statistics.
To view the distribution of event messages with different statuses on different agents, either click the bar for a status in the graph, or click an event message status name link.
To view the number of event messages with a particular status, position the mouse pointer over the bar for that status in the graph.
This region provides links to other Oracle Workflow management features.
Click the Service Components link to configure service components, including notification mailers and agent listeners.
Click the Queue Propagation link to view database initialization parameters required for queue propagation and a list of propagation schedules for Business Event System agents.
Click the Work Items link to view the distribution of completed work items across different item types.
Click the Notification Mailers link to view the notification mailer throughput. This graph shows the throughput of the notification mailers by displaying the distribution of notifications in the WF_NOTIFICATIONS table with the following statuses:
Processed - Outbound notifications for which an e-mail message has been sent by a notification mailer service component.
Waiting - Outbound notifications for which an e-mail message has not yet been sent.
The graph header displays the date and time when the notification mailer throughput statistics were last updated. To refresh this information, click the refresh icon. See: Gathering Oracle Workflow Statistics.
To view the number of notifications with a particular status, position the mouse pointer over the bar for that status in the graph.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Related Links > Throughput > Notification Mailers
Click the Agent Activity link to view the distribution of event messages with different statuses on different agents.
The Generic Service Component Framework helps to simplify and automate the management of background Java services. In Oracle Applications, service component containers and their service components are run through Generic Service Management (GSM), which you can control through Oracle Applications Manager (OAM).
A service component container is an instance of a service that manages the running of the individual service components that belong to it. The container monitors the status of its components and handles control events for itself and for its components. These actions are recorded in a log for the container.
A service component is an instance of a Java program which has been defined according to the Generic Service Component Framework standards so that it can be managed through this framework. Currently, Oracle Workflow provides four service component types: Workflow Mailer, Workflow Agent Listener, Workflow Java Agent Listener, and Workflow Web Services Outbound.
Oracle Workflow provides several seeded service components of these types, within seeded containers, to perform standard processing. You can optionally create additional service components to perform custom processing. If you create custom service components, you can either assign them to the seeded containers, or, based on the volume to be handled by the seeded containers, you can also choose to create your own custom containers.
All service components have certain attributes required by the Generic Service Component Framework. General definition attributes for a component include the component name, startup mode, container type, inbound agent, outbound agent, and correlation ID. Detail attributes include the container that owns the component, the maximum idle time for an on-demand component, maximum error count, number of inbound and outbound processing threads, component log level, read timeout period, minimum sleep time, maximum sleep time, error sleep time, and whether to close connections when the read timeout period expires.
A service component can have one of three startup modes.
Automatic - When a component container is started, it will automatically start its automatic service components. It will also monitor these components and restart them automatically when necessary.
On-Demand - A component container will start its on-demand service components if those components have messages waiting to be processed. For example, an on-demand notification mailer service component will be started if there are messages waiting on the WF_NOTIFICATION_OUT queue. The container will stop an on-demand service component when that component's maximum idle time has been exceeded.
Manual - You must manually start and stop the service component through Workflow Manager. The component container does not start or stop its manual service components.
In Oracle Applications, all service components use the Oracle Applications GSM container type. A component can have either an inbound agent to process inbound messages, an outbound agent to process outbound messages, or both. An Oracle Advanced Queuing (AQ) correlation ID can be assigned to a component to limit its processing to only messages marked with that correlation ID.
Oracle Workflow provides three predefined containers in which you can create components, the Workflow Mailer Service, the Workflow Agent Listener Service, and the Workflow Document Web Services Service. For an on-demand service component, you can specify the maximum amount of time that the service component can remain idle before it is stopped by its container. A service component can have either one inbound processing thread, to enable inbound processing, or none, to disable inbound processing. A service component can have one or more outbound processing threads, to enable outbound processing depending on the volume of outbound messages, or none, to disable outbound processing. Some types of service components perform only inbound processing or only outbound processing. For example, agent listeners only process inbound event messages and consequently should always have an outbound thread count of zero.
A diagnostic log is recorded for each component container, from the time the container starts to the time it stops. When a container is restarted, a new log is begun. You can view the log through Workflow Manager. Each log entry is marked with the container ID, and, if applicable, with the ID of the service component that generated it. You can specify the level of detail of the information you want to record for each component container. You can also specify a separate log level for an individual service component within the container. The log levels you can select, in order from most detailed to least detailed, are as follows:
1 - Statement
2 - Procedure
3 - Event
4 - Exception
5 - Error
6 - Unexpected
The default log level for both containers and service components is Error. This level is the recommended setting for normal usage.
A processing thread for a service component runs in a loop in which it reads messages from the queue associated with its assigned agent and then waits during a specified amount of sleep time before checking the queue for messages again. The read timeout period defines the amount of time the service component continues attempting to read messages from the queue, after the last message has been dequeued, before timing out. If another message is received before this time expires, that message is processed and the timeout period begins again. If the timeout period expires and no more messages have been received, the service component stops reading and its sleep time begins.
The minimum sleep time for a service component defines the minimum amount of time during which the service component waits, after its read timeout period expires, before it checks the queue for messages again. If a queue receives messages infrequently, you can choose to increase the sleep time between read attempts when no messages are received by setting a maximum sleep time greater than the minimum sleep time. In this case, the service component initially waits for the minimum sleep time after it finishes reading messages from its queue. If no messages are read in subsequent attempts, then the sleep time between read attempts gradually increases until the maximum sleep time is reached. Increasing the sleep time can help enhance performance if messages are received infrequently. You can also set the maximum sleep time parameter to 0 (zero) to indicate that the sleep time should not be increased. In this case, the service component always waits for the minimum sleep time between read attempts.
The error sleep time for a service component defines the amount of time during which the service component waits, after an error occurs, before it attempts to begin processing again. Additionally, a service component processing thread can either close its connections after its read timeout period expires, when its sleep time begins, or the connections can remain open until the processing thread stops.
A service component may also have additional configuration parameters that are specific to the type of processing it performs. For example, a notification mailer service component has configuration parameters to specify the inbound and outbound e-mail servers it uses.
Among both the common and the type-specific configuration parameters, some parameters can be refreshed dynamically while a service component is running. These parameters are identified by a refresh icon in the configuration pages for the component. For example, the component log level, inbound thread count, and outbound thread count are refreshable parameters.
The control events you can perform for a service component include:
Starting a service component
Suspending a running service component, so that the threads stop processing but connections are not closed
Resuming a suspended service component
Refreshing a running service component with changed parameters
Stopping a running or suspended service component
A service component may also have additional control commands that are specific to the type of processing it performs. For example, Workflow Mailer components include a command to launch summary notifications.
You can perform these control events manually at runtime by choosing the relevant command for the component in the Service Components page. You can also schedule single or repeating control events when you are configuring a service component.
A service component can have one of the following statuses.
Not Configured - Some required configuration parameters for the component have not been completed. The component cannot be started until its configuration is complete.
Starting - The component is preparing to run.
Running - The component is running normally. You can choose to suspend processing for a component in this state, refresh the configuration parameters for the component that are dynamically refreshable, or stop the component.
Suspending - The component is preparing to suspend its processing.
Suspended - The component's thread has stopped processing, but its connections remain open. When a component is suspended, you can either resume its processing or stop it altogether.
Resuming - The component is preparing to resume processing and return to a Running status.
Stopping - The component is preparing to stop running.
Stopped - The component was stopped normally, without errors.
Stopped with Error - The component reached the maximum number of errors specified in its Max Error Count parameter and has stopped. The component container will restart an automatic component in this status, or an on-demand component in this status that has messages waiting to be processed.
System Deactivated - An automatic or on-demand component was deactivated automatically by its container because the component was stopped with an error the maximum number of times specified in the container's SVC_COMP_MAX_ERROR_COUNT service parameter. A component in this status will not be restarted automatically until the container is restarted.
User Deactivated - An automatic or on-demand component was manually stopped by a user. It will not be restarted automatically. If you want to restart it, you must do so manually.
A component with a status of Starting, Running, Suspending, Suspended, Resuming, or Stopping is considered to be active. While a component is active, you cannot edit the component name, startup mode, container type, inbound agent, outbound agent, correlation ID, container, or, for an on-demand component, the maximum idle time. You must stop the component before you can change these attributes. However, you can edit the component's other configuration parameters while it is active. If you edit any refreshable parameters, the component will be dynamically refreshed with the new parameter values.
You can manually stop a component from any status. Also, if a container stops for any reason, all of its components are stopped as well.
If the status of a service component changes to Stopped with Error or System Deactivated, Oracle Workflow posts a system alert to the System Alerts and Metrics page in Oracle Applications Manager.
The Service Components page shows the service components that are defined in your Oracle Workflow installation.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon
To add the information from this page to your support cart, click the Add to Support Cart button.
For each service component, the list displays the service component name, status, type, startup mode, container type, and container. Click any column heading to sort the list by that column.
To filter the service components displayed in the list, select a service component property from the Filter pull-down menu, enter a filter value in the text field, and click the Go button. You can filter by the following properties:
Service component name
Service component status
Service component type display name
Service component type internal name
To verify that the statuses displayed for the service components in the list are current, click the Verify All button.
To create a new service component, click the Create button.
To edit a service component's configuration, select the service component and click the Edit button. The steps to edit the configuration depend on the service component type.
To view the diagnostic log of the service component container in which this service component is running, select the service component and click the View Log button. The log includes log messages for this component and any other component belonging to that container.
To view details about a service component, either click the service component link in the Name column, or select the service component and click the View Details button. The information that is displayed depends on the service component type.
To review the events that have been scheduled to control the running of the agent listener, click the View Event History button. For each event, the Event History page displays the event name, status, user who requested the event, component status before the event was processed, date the event processing was completed, container for the service component, container type, and any event parameters for a refresh event. You can use this event history as an audit trail to review who scheduled control events for the agent listener. The status of an event may be Pending, Skipped, In Progress, Completed, or Error. In some cases, an event may be skipped if the component is not in an appropriate status at the time for which the event is scheduled. For example, a refresh event cannot be executed if the component is stopped at the scheduled time.
To delete a service component, select the service component and click the Delete button. If the service component is currently active, you must stop it before you can delete it.
Note: Several of the seeded service components are required by Oracle Workflow and Oracle XML Gateway and cannot be deleted. If you want to disable them, you can stop them manually using the Stop command from the command pull-down menu. However, note that stopping these components disables the features they support. For example, stopping the Workflow Error Agent Listener and Workflow Java Error Agent Listener disables error handling for the Business Event System.
To manually control the running of a service component, select the service component, choose the command you want from the command pull-down menu, and click the Go button. You can choose the following commands:
Refresh
Resume
Start
Stop
Suspend
Launch Summary Notifications (Workflow Mailer service components only)
To manage the service instances for the container of a service component through GSM, click the container link in the Container column.
The Pick Component Type page lets you choose the type of service component you want to create. This page lists the name and description of each available type. Select the type that you want and click the Continue button. The steps to complete the service component configuration depend on the type you select.
Oracle Workflow provides the following service component types.
Workflow Mailer - Service components that perform send and respond e-mail processing for the Notification System.
Workflow Agent Listener - Service components that process inbound messages on Business Event System agents in the database.
Workflow Java Agent Listener - Service components that process inbound messages on Business Event System agents in the middle tier.
Workflow Web Services Outbound - Service components that process outbound Web service messages.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon > Create
The Component Details page lets you review the configuration of a service component.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon > (B) View Details
The Component Details page displays the configuration parameters defined for the service component and any special status information, as well as the control events that are currently scheduled for the service component. For each event, the list shows the event name, initial start time, whether the event is currently running, the next scheduled execution time for a repeating event, the last previous execution time for a repeating event, the interval in minutes between executions of a repeating event, the number of times the event has failed, the job ID of the DBMS job used to schedule the event, and the PL/SQL API that DBMS job runs.
To add the information from this page to your support cart, click the Add to Support Cart button.
For Workflow Mailer service components only, to send a test message, click the Test Mailer button. In the Test Notification Mailer page, select the recipient role to which the message should be sent, and click the Send Test Message button. Then check the e-mail account for the recipient role to verify that the test message was received. The test message does not require a response, so you can close it after reviewing it. However, you can optionally respond with a comment to acknowledge the message.
To send a test message successfully, you must select a recipient role that either has a valid e-mail address defined, or that has members with valid e-mail addresses defined. The recipient role must also have a notification preference that includes individual e-mail notifications.
If you set an override e-mail address for the notification mailer, the Test Notification Mailer page displays that address. In this case the test message is sent to the override address rather than the e-mail address of the recipient role. However, you must still select a recipient role to enable the notification mailer to send the test message.
For Workflow Mailer service components only, to set an override address where you want to send all outgoing e-mail notifications, click the Set Override Address button. Use an override address when you are testing workflow definitions or mailer processing so that you can automatically receive all the test notifications at one e-mail address, instead of having to check or change each individual recipient's e-mail address. To ensure that the override address is accessible and that its use is authorized, you must verify the request before the notification mailer can use the address.
In the Set Override Address page, review the current override address, if any. Enter the e-mail address you want to set as the new override address, and choose Submit. Then check the e-mail account you specified for the verification e-mail message.
In the Verify Override Address page, enter the verification code shown in the e-mail message, and choose Apply. If necessary, you can use the link provided in the verification e-mail message to navigate back to the Verify Override Address page. You must log in to Oracle Applications Manager before you can access this page.
To remove the override address, navigate to the Set Override Address page and choose the Clear Override Address button. The notification mailer then resumes sending e-mail notifications to the individual recipients' e-mail addresses.
To review the events that have been scheduled to control the running of the service component, click the View Event History button. For each event, the Event History page displays the event name, status, user who requested the event, component status before the event was processed, date the event processing was completed, container for the service component, container type, and any event parameters for a refresh event. You can use this event history as an audit trail to review who scheduled control events for the service component. The status of an event may be Pending, Skipped, In Progress, Completed, or Error. In some cases, an event may be skipped if the component is not in an appropriate status at the time for which the event is scheduled. For example, a refresh event cannot be executed if the component is stopped at the scheduled time.
To view the diagnostic log of the Generic Service Management (GSM) service component container in which this component is running, click the View Log button. The log includes log messages for this component and any other component belonging to that container.
To change the values of the configuration parameters or the scheduled events, click the Edit button and navigate to the appropriate page within the service component configuration wizard.
To return to the Service Components page, click the OK button.
You can use Oracle Applications Manager to control service component containers as service instances of type Generic Service Component Container in GSM.
Among other properties, a GSM service instance can have work shifts assigned to it. A work shift in turn can have service parameters associated with it. For a service instance that is a service component container, these service parameters apply to the container as a whole to determine how the container manages the components that belong to it.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon > container link > (B) Edit > (B) Edit Service Parameters
The Edit Service Parameters page initially displays the service parameters that can be specified for a container in the Edit Service Parameters field, together with their seeded default values. In most cases, you do not need to change these values. However, you can optionally edit these values in the Edit Service Parameters field if you choose.
You can also optionally delete any of the service parameters from the Edit Service Parameters field. In this case, for all parameters except the proxy setting parameters, the parameter values are obtained from the global settings stored in the WF_RESOURCES table. The default values in the WF_RESOURCES table are the same as the initial default values in the Edit Service Parameters page.
In the Edit Service Parameters field, the service parameter names and values should be specified separated by colons, in the following format:
<name1>=<value1>:<name2>=<value2>: . . . <nameN>=<valueN>
The following service parameters can be specified for a container:
SVC_WRITE_DIAG_TO_GSM_LOG - Specify Y if you want to write diagnostic information to the GSM log file in all cases. The default value is Y. Specify N if you want to let the FND: Debug Log Filename (AFLOG_FILENAME) profile option determine where to write the log, either to a specified file or to the database if no file is specified. For more information about FND: Debug Log profile options, please refer to the Oracle Applications System Administrator's Guide.
SVC_CONTAINER_LOOP_SLEEP - Specify the sleep time in seconds during which the container waits, after it finishes reading control messages from its GSM queue, before it checks that queue for messages again. The default sleep time is 10 seconds.
SVC_CONTAINER_READ_TIMEOUT - Specify the maximum amount of time in seconds that the container continues to block on the GSM queue after processing the last message. If another message is received before this time expires, that message is processed and the timeout period begins again. If the timeout period expires and no more messages have been received, the container stops blocking on the queue and its sleep time begins. The default timeout period is 10 seconds.
SVC_CONTAINER_LOG_LEVEL - Specify the level of detail to record for the container in its log. The default value is 5 (Error). The valid levels, in order from most detailed to least detailed, are:
1 - Statement
2 - Procedure
3 - Event
4 - Exception
5 - Error
6 - Unexpected
SVC_COMP_MONITOR_LOOP_SLEEP - Specify the sleep time in seconds during which the container waits, after it starts any automatic components that need to be started, before it checks its automatic components again. The default value is 60 seconds.
SVC_COMP_MONITOR_ONDEMAND_FREQ - Specify the interval in seconds to determine how often the container checks whether its on-demand components need to be started or stopped. This activity is more costly than monitoring the automatic components and should usually be performed less frequently. The default value is 300 seconds.
SVC_COMP_MAX_ERROR_COUNT - The container-level maximum error count. If any automatic or on-demand component in the container is stopped with an error the specified number of times, the component status will be set to System Deactivated, and the container will no longer automatically restart the component. The default value is 5.
You can also optionally specify the following service parameters for proxy settings. You should set these parameters if components in this container need to use a proxy server to access web content that is outside a firewall. For example, a mailer component may need to access outside web content that is to be included in an e-mail notification. The Generic Service Component Framework uses the values you set in these service parameters to set the relevant Java System Properties.
SVC_PROXY_SET - Specify true to indicate that you want to use a proxy for your connections. The default value is NONE.
SVC_PROXY_HOST - Specify the host machine for the proxy. The default value is NONE.
SVC_PROXY_PORT - Specify the port on which the proxy is listening. The default value is NONE.
You can use the Service Status page to control the running of a service component container, including changing the log level for the container. The log level controls how much information is recorded in the log. Note that the log level you select here applies only to the log messages for the container. You can assign separate log levels to the individual components within the container.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon > container link > (B) View Status
The log level with which the container starts is determined by the value of the SVC_CONTAINER_LOG_LEVEL service parameter. If no value is defined for that parameter, the log level is obtained from the default setting stored in the WF_RESOURCES table. The default container log level, which is also the recommended setting, is Error.
If the container is running, you can optionally specify a different container log level for the current session. To change the log level, select the level you want from the Change Log Level To pull-down menu and click the Go button. The log levels you can select, in order from most detailed to least detailed, are as follows:
1 - Statement
2 - Procedure
3 - Event
4 - Exception
5 - Error
6 - Unexpected
Note that the log level you set dynamically in the Service Status page applies only for the duration of the current container session, and does not change the log level stored for the container in the service parameters. To set the log level permanently, so that the container starts with that log level in each new session, edit the value of the SVC_CONTAINER_LOG_LEVEL service parameter in the Edit Service Parameters page. See: Editing Service Parameters for a Container.
If the log level has been changed dynamically for the current session, the Service Status page may not display the log level that is currently in effect for the container. However, you can always review the current log level in the container log file by choosing View Log in the Service Components page or the Component Details page.
If you create custom service components, you can choose to create custom containers to manage those service components. You create a container as a GSM service instance of type Generic Service Component Container in Oracle Applications Manager.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon > container link > (B) Create New
Among other properties, a GSM service instance can have work shifts assigned to it. A work shift in turn can have service parameters associated with it. For a service instance that is a service component container, these service parameters apply to the container as a whole to determine how the container manages the components that belong to it. If you create a custom container, you should specify service parameters for the work shifts for your new service instance in order to specify how to run the new container. To enter service parameters easily, copy the service parameters from one of the seeded Oracle Workflow containers to your new container.
After creating a customer container, you can assign service components to it using the appropriate service component configuration wizard. Ensure that your custom containers are running in order to run the service components belonging to them.
A notification mailer is a Java program that performs e-mail send and response processing for the Oracle Workflow Notification System, using the JavaMail API. You need to implement one or more notification mailers only if you want to have your workflow users receive their notifications by e-mail, as well as from the Worklist Web pages.
The notification mailer program is defined as a service component type in the Generic Service Component Framework. This framework helps to simplify and automate the management of background Java services.
Oracle Workflow provides one seeded notification mailer service component, called Workflow Notification Mailer. Most of the configuration parameters for this mailer are set to default values. You can enter several of the remaining required parameters using AutoConfig. After installation, you then only need to enter the e-mail inbox password in order to complete the configuration of this mailer. Alternatively, if you only want to send outbound messages and do not need to receive inbound messages, you only need to disable inbound processing in order to complete the configuration of this mailer. If the mail servers and Business Event System components used by the notification mailers are set up, and the Workflow Mailer Service container to which the Workflow Notification Mailer belongs is started, the seeded notification mailer automatically starts running once its configuration is complete.
You cannot delete the seeded Workflow Notification Mailer or edit its name, assigned agents, correlation ID value, or container. However, if necessary you can optionally update other configuration parameters, schedule control events, or manually choose control commands to start, stop, suspend, resume, or refresh this notification mailer.
Note: Oracle Alert also uses the Workflow Notification Mailer to send and receive alert e-mail messages. If you use Oracle Alert, ensure that the configuration of the Workflow Notification Mailer meets your alert requirements. See: Setup Steps, Oracle Alert User's Guide.
You can also optionally create additional notification mailer service components. For example, you can create a notification mailer that processes only messages that belong to a particular workflow item type, or create additional mailers that process the same types of message to increase throughput.
The correlation ID for a notification mailer determines which messages it can process. To dedicate a notification mailer to processing messages from a particular item type, set that item type as the correlation ID. To create a general notification mailer that can process messages from any item type, leave the correlation ID blank. The seeded Workflow Notification Mailer has a blank correlation ID so that it can run as a general mailer.
Note: If you run a general notification mailer and a dedicated notification mailer for a particular item type at the same time, a message from that item type may still be processed by the general mailer if that mailer is the first to access the message. If you want only the dedicated notification mailer to process messages from that item type, disable any general mailers. In this case, however, ensure that you define dedicated mailers for all item types used in your Oracle Applications installation.
To ensure consistency in message handling, all notification mailers that can process the same messages must share the same values for certain parameters. Multiple mailers can process the same messages in the following cases:
A general mailer runs at the same time as any dedicated mailers.
Multiple general mailers run at the same time.
Multiple dedicated mailers for the same item type run at the same time.
In these cases, the notification mailers must share the same values for the following parameters:
HTML Agent
Attach Images to Outbound E-mails
Attach Stylesheet to Outbound E-mail
Autoclose FYI
Direct Response
Reset NLS
Inline Attachments
All message template parameters
However, these mailers can have different values for the From and Reply-to Address parameters. The headers of each notification e-mail message will contain the From and Reply-to Address values of the notification mailer that actually sent the message, unless the message itself has the special #WFM_FROM and #WFM_REPLYTO message attributes defined to override the notification mailer's parameters. See: Notification Mailer Attributes, Oracle Workflow Developer's Guide.
You can also configure any notification mailer service component to process only inbound messages, or only outbound messages. You associate inbound and outbound mailers with each other by assigning them the same mailer node name. The mailer node name indicates which inbound mailer can process incoming responses to outbound messages sent by a particular outbound mailer.
You can optionally assign the same node name to multiple mailers for load balancing purposes. However, each mailer that performs inbound processing for a node must have its own inbox.
If you enable both outbound and inbound processing for the same mailer, that mailer will automatically use the same node name for both types of processing, enabling it to process incoming responses to the outbound messages it sent. You can optionally also create other notification mailers that share the same node name.
If you create an outbound-only mailer, but you still want to perform response processing for e-mail responses to the outbound messages it sends, you should create at least one other mailer with the same node name that does perform inbound message processing. Otherwise, there will be no inbound mailer that can process incoming responses to outbound messages sent by this outbound mailer.
If you only want to implement outbound message processing, without inbound e-mail response processing, then you can configure an outbound-only mailer without creating a corresponding inbound mailer. In this case you should configure the mailer to use message templates for response-required notifications that do not request a response by e-mail, but instead direct recipients to respond from the Notification Details Web page. For example, you can configure the mailer to send response-required notifications using the Workflow View From UI message template, which is an alternative template provided by Oracle Workflow in the System: Mailer item type, or create your own custom message templates. The outbound-only mailer can still use the standard message templates to send outbound summary notifications or For Your Information (FYI) notifications that do not require a response.
Create an inbound-only mailer only if you have also created at least one mailer with the same node name that performs outbound message processing. If no outbound mailer shares the same node name, no incoming response messages will be marked with that node name, and the inbound-only mailer will have no messages to process.
Dedicated mailers for different item types should use different node names.
If you create custom notification mailer service components, you can either assign them to the seeded container for notification mailers, named Workflow Mailer Service, or, based on the volume to be handled by the seeded container, you can also choose to create your own custom containers.
Currently, Oracle Workflow supports the Simple Mail Transfer Protocol (SMTP) for outbound messages and the Internet Message Access Protocol (IMAP) for inbound messages. You must have an SMTP server set up in order to send Oracle Workflow notification e-mail messages, and an IMAP server set up if you want to receive e-mail notification responses. Users can receive e-mail notifications using various e-mail clients, although notifications may be displayed differently in different clients, depending on the features each client supports.
Note: Oracle Workflow supports IMAP version 4 (IMAP4) compliant mail servers. Ensure that your mail server uses this IMAP version. For more information, see the JavaMail API Design Specification: http://java.sun.com/products/javamail/JavaMail-1.2.pdf
Note: If you have certain types of software installed, you may already have the necessary mail server functionality available. For example, products such as Oracle Email, Microsoft Exchange, or Lotus Notes include IMAP services. You can use a UNIX server as an SMTP server by configuring the Sendmail program.
Additionally, you can choose to use IMAP server software that is available for download from some sources. For example, the University of Washington offers the UW IMAP Server as a public service, and Carnegie Mellon University offers the Cyrus IMAP Server. You might choose this option if your enterprise uses UNIX Sendmail e-mail accounts, for instance. For more information, see: http://www.washington.edu/imap/, http://asg.web.cmu.edu/cyrus/, and http://www.imap.org/.
Note: Third party software products are mentioned as examples only. Oracle makes no recommendation or endorsement of these third party software products.
To set up a notification mailer, you must perform the following steps.
Set up an SMTP mail server to send outbound messages.
Set up an IMAP4 compliant mail server with an e-mail account for the notification mailer if you want to receive inbound messages.
The notification mailer requires three folders in this e-mail account: the inbox, a folder to store processed messages, and a folder to store discarded messages. If the e-mail account does not already include folders named PROCESS and DISCARD, Oracle Workflow automatically creates these two folders when you complete the basic notification mailer configuration. You can optionally specify other folders for the notification mailer using the advanced configuration wizard.
Note: If you create the PROCESS and DISCARD folders manually before configuring the notification mailer, use your e-mail client to create these folders. A notification mailer may not be able to access folders that were created using command line tools outside the e-mail client.
You can use AutoConfig to enter the following configuration parameters for the seeded Workflow Notification Mailer service component during installation. For more information about running AutoConfig, see OracleMetaLink note 165195.1 and AutoConfig, Oracle Applications AD Utilities Reference Guide.
SMTP Server
IMAP Server (if you want to receive inbound messages)
Inbox Username (if you want to receive inbound messages)
Reply To E-mail Address (if you want to receive inbound messages)
HTML Agent Name - This parameter defaults to the value you enter for the Applications Servlet Agent parameter in AutoConfig. Use the following format:
http://<server_name:port>/OA_HTML/Note: When you enter the SMTP Server and IMAP Server parameters, specify the actual host name for each server. Do not use localhost as the setting for these parameters. You can optionally specify the port number to use on each server. If you do not specify a port number, the notification mailer uses port 143 on the IMAP server and port 25 on the SMTP server by default. Specify each server in the following format: <server_name>[:<port_number>]
Ensure that the Business Event Local System status is set to Enabled in the Workflow Configuration page, and that the JOB_QUEUE_PROCESSES and AQ_TM_PROCESSES database initialization parameters, which are required for the Business Event System, are set to appropriate values. The Business Event Local System status is set to Enabled by default, and usually you do not need to change this status. If notification processing is not being completed, however, you should check this preference value.
(Recommended) You can optionally set the WF: Workflow Mailer Framework Web Agent profile option to the host and port of the Web server that notification mailers should use to generate the content for Oracle Applications Framework regions that are embedded in notifications. If this profile option is not set, notification mailers will use the same Web agent specified in the Application Framework Agent profile option. However, if necessary for load balancing purposes, you can optionally specify a different Web agent for notification mailers to use. The WF: Workflow Mailer Framework Web Agent profile option should be set at site level. See: Overview of Setting User Profiles, Oracle Applications System Administrator's Guide.
Before a service component can run, the container which manages it must first be started. The seeded Workflow Notification Mailer service component belongs to a container named Workflow Mailer Service, while the seeded agent listener service components that are also required for notification mailer processing belong to a container named Workflow Agent Listener Service. You should ensure that these two containers are running. If you create your own custom containers for custom service components, ensure that those containers are running as well. Use the Service Instances page to start the containers as service instances in Generic Service Management (GSM).
When the Workflow Agent Listener Service container is running, it automatically starts seeded agent listener service components named Workflow Deferred Notification Agent Listener, Workflow Error Agent Listener, and Workflow Inbound Notifications Agent Listener, which are required for notification mailer processing. Ensure that these agent listeners are running.
Use the notification mailer configuration wizard to configure your notification mailer service component. The Basic Configuration page lets you configure a notification mailer quickly by entering only the minimum required parameters, while the advanced configuration wizard lets you specify additional parameters to control how the notification mailer processes messages.
If you entered configuration parameters for the seeded Workflow Notification Mailer through AutoConfig, you only need to enter the password for the e-mail inbox in order to complete the configuration for that mailer and begin running it. If you did not enter parameters for the seeded mailer through AutoConfig, then in order to complete the configuration for that mailer you need to enter only the SMTP server, IMAP server, e-mail inbox username, e-mail inbox password, and reply-to e-mail address. All other configuration parameters for the seeded Workflow Notification Mailer are initially set to default values and do not need to be changed, although you can optionally do so if you choose.
Note: The IMAP server, e-mail inbox username, e-mail inbox password, and reply-to e-mail address are required only if you want to receive inbound messages. Alternatively, if you only want to send outbound messages and do not need to receive inbound messages, you only need to disable inbound processing in order to complete the configuration of the Workflow Notification Mailer.
(Optional) By default, the seeded Workflow Notification Mailer has a Launch Summary Notifications event scheduled to send summary notifications once a day. You can optionally use the notification mailer configuration wizard to modify the start time and interval for this event's schedule, or to schedule the Launch Summary Notifications event at the interval you choose for any notification mailer service component. When this event is processed, a summary notification is sent to each role with a notification preference of SUMMARY or SUMHTML, listing all the notifications that are currently open for that role.
(Optional) You can configure a notification mailer to connect to the SMTP server and IMAP server through Secure Sockets Layer (SSL) to encrypt the data exchanged. See: Connecting to Mail Servers Through SSL.
(Optional) The seeded Workflow Notification Mailer uses the Automatic startup mode by default and will be started automatically when you complete its configuration. If you select the Manual startup mode for a notification mailer service component, use the Service Components page to start that notification mailer. You can also use this page to manage any notification mailer service component.
When the Workflow Engine determines that a notification message must be sent, it raises an event in the Business Event System called oracle.apps.wf.notification.send. Oracle Workflow provides a seeded subscription to this event, which is defined to be deferred immediately so that the workflow process that owns the notification can continue. The event is placed on the standard WF_DEFERRED agent. Oracle Workflow provides a seeded agent listener named Workflow Deferred Notification Agent Listener that runs on this agent to continue notification processing. This agent listener is dedicated solely to processing deferred notification events.
When the event is dequeued from WF_DEFERRED and the subscription is processed, the subscription requires the event data for the event, causing the generate function for the event to be executed. The generate function for this event performs the following actions:
Resolves the notification recipient role to a single e-mail address, which itself can be a mail list.
Checks the notification preference of the recipient to determine whether an e-mail notification is required, and in what type of format.
Switches its database session to the recipient role's preferred language and territory as defined in the directory service.
Generates an XML representation of the notification message and any optional attachments using the appropriate message template.
Finally, the subscription places the event message on the standard WF_NOTIFICATION_OUT agent.
A notification mailer service component polls the WF_NOTIFICATION_OUT agent for messages that must be sent by e-mail. When the notification mailer dequeues a message from this agent, it uses a Java-based notification formatter to convert the XML representation of the notification into a MIME (Multipurpose Internet Mail Extensions) encoded message and sends the message by the Simple Mail Transfer Protocol (SMTP).
The e-mail notifications are based on message templates defined in Oracle Workflow Builder. Oracle Workflow provides a set of standard templates in the System: Mailer item type, which are used by default. It is not recommended to modify the standard templates. However, you can customize the message templates used to send your e-mail notifications by creating your own custom message templates in a custom item type using the Workflow Builder. Then assign these templates to a particular notification in a workflow process by defining special message attributes. In this case the templates assigned to the notification override any other templates.
You can also create your own custom message templates in the System: Mailer item type using the Workflow Builder, and assign these templates to a particular notification mailer service component in the mailer configuration parameters. The templates assigned to a mailer override the default System: Mailer templates. However, if any notifications have templates specifically assigned to them through message attributes, the notification-level templates still override the templates assigned to the mailer.
If the notification mailer cannot deliver an e-mail notification because the recipient's e-mail address is invalid, it performs the following actions:
Sets the mail status of the notification to FAILED. This mail status indicates that an exception prevented this e-mail notification from being delivered but does not prevent the mailer from processing other notifications.
Adds the e-mail address to its invalid e-mail address list. To avoid unnecessary processing, each notification mailer stores a list of e-mail addresses to which it could not deliver messages, and does not attempt to send any further messages to those addresses. Instead, for any subsequent notifications to the listed addresses, the notification mailer simply sets the mail status directly to FAILED.
Note: Each notification mailer can store up to 100 e-mail addresses in its invalid e-mail address list. If the notification mailer encounters additional invalid addresses when the list is already full, the notification mailer removes the oldest addresses from the list and adds the new addresses in their place. Also, the notification mailer clears the list by removing all addresses whenever you stop and restart the mailer.
Changes the notification preference of the recipient to DISABLED. To further help avoid unnecessary processing, if a recipient has a notification preference of DISABLED, Oracle Workflow does not generate a complete XML representation of any notifications to that recipient, and a notification mailer does not attempt to send e-mail notifications to that recipient. Instead, the notification mailer simply sets the mail status of the notifications directly to FAILED. The change in notification preference also indicates to the user that e-mail notifications cannot be delivered. The user must correct the invalid e-mail address and then reset the notification preference in order to receive e-mail notifications.
After correcting invalid e-mail addresses and resetting DISABLED notification preferences, you can run the Resend Failed Workflow Notifications concurrent program to retry open notifications that previously could not be sent. See: Handling Mailer Errors.
Notification mailers can also process e-mail responses from users, using the Internet Message Access Protocol (IMAP). A notification mailer uses a Java-based e-mail parser to interpret the text of each message and create an XML representation of it.
A notification mailer uses three folders in your response mail account for response processing: one to receive incoming messages, one to store processed messages, and one to store discarded messages.
A notification mailer does the following to process response messages:
Logs into its IMAP e-mail account.
Checks the inbox folder for messages. If a message exists, the notification mailer reads the message, checking for the notification ID (NID) and node identifier in the NID line.
If the message is not a notification response, meaning it does not contain an NID line, the notification mailer moves the message to the discard folder and treats it as an unsolicited message. For the first unsolicited message from a particular e-mail address, the notification mailer also sends a warning message back to the sender of the message. However, to avoid sending unnecessary warnings due to bounced or auto-reply messages, each mailer node stores a list of e-mail addresses from which it has received unsolicited mail, and does not send any further warning messages to those addresses. Instead, if the node receives a second unsolicited message from a particular address, the notification mailer discards the message and raises the oracle.apps.wf.mailer.unsolicited event. You can optionally define a subscription to this event if you want to perform some other action in response to the second unsolicited message. For all subsequent unsolicited messages, the notification mailer simply discards the message.
Note: Each mailer node can store up to 100 e-mail addresses in its warned list. If the node receives unsolicited messages from additional addresses when the list is already full, the notification mailer removes the oldest addresses from the list and adds the new addresses in their place. Also, the notification mailer clears the list by removing all addresses when you start the mailer for the first time, and again whenever you stop and restart its container. In these cases, the mailer may send another warning message if it receives further unsolicited e-mail from an address that is no longer on the warned list.
Note: You can optionally use the Send Warning for Unsolicited E-mail mailer parameter to prevent notification mailers from sending any warning messages at all. See: Notification Mailer Configuration Wizard.
If the message is a notification response, but for a different node, the notification mailer leaves the message in the inbox and adds the e-mail's Unique Message ID (UID) to its ignore list.
If the message is a notification response for the current node, meaning it contains an NID line including the node identifier of the current node, the notification mailer processes the message.
The notification mailer performs the following steps for messages that belong to its node.
Retrieves the notification ID.
Checks to see if the message bounced by referring to the tags specified in the configuration parameters, if any. If the message bounced, the notification mailer updates the notification's status and stops any further processing, based on the specifications of the tag list.
Checks the Oracle Workflow database for this notification based on the NID line.
If the notification does not exist, meaning the notification ID or the access key in the NID line is invalid, the notification mailer moves the message to the discard folder. If the NID line is incorrectly formatted, the notification mailer moves the message to the discard folder and treats it as an unsolicited message.
If the notification exists, but is closed or canceled, the notification mailer moves the message to the processed folder and sends a Workflow Closed Mail or Workflow Canceled Mail message to the recipient role, respectively.
Note: You can optionally use the Send E-mails for Canceled Notifications mailer parameter to prevent notification mailers from sending any notification cancellation messages. See: Notification Mailer Configuration Wizard.
If the notification exists and is open, the notification mailer generates an XML representation of the message and places it on the standard WF_NOTIFICATION_IN agent as an event called oracle.apps.wf.notification.receive.message. The notification mailer then moves the message for the completed notification to the processed folder.
Note: If the character encoding of the response message is not compatible with the database codeset, the notification mailer may not be able to parse the response and recognize the response values. Ensure that the character encoding of messages in your mail client is compatible with the codeset of your database.
Finally, if there are no more unprocessed messages in the inbox, the notification mailer logs out of the e-mail account.
Oracle Workflow provides a seeded agent listener named Workflow Inbound Notifications Agent Listener that runs on the WF_NOTIFICATION_IN agent to continue notification processing for the valid response messages placed on that agent. When an event message is dequeued from WF_NOTIFICATION_IN, Oracle Workflow executes a seeded subscription that calls the appropriate notification response function. This function verifies the response values with the definition of the notification message's response attributes in the database. If a response value is invalid, or if no response value is included, the notification mailer sends a Workflow Invalid Mail message to the recipient role, or, for an invalid response to a request for more information, the notification mailer sends a Workflow Invalid Open Mail (More Information Request) message to the recipient role. If the responses are valid, the notification response function records the response and completes the notification.
Use the notification mailer configuration wizard to configure a new notification mailer service component, or to edit the configuration of an existing notification mailer service component. The notification mailer configuration wizard begins with the Basic Configuration page, which lets you configure a notification mailer quickly by entering only the minimum required parameters.
From the Basic Configuration page, you can also navigate to the advanced configuration wizard to specify additional parameters that control how the notification mailer processes messages. The advanced configuration wizard lets you define general and detail attributes, define e-mail server and message generation parameters, schedule control events, and define tags to assign statuses to unusual messages.
Some parameters appear in both the Basic Configuration page and the advanced configuration wizard. Both the Basic Configuration page and the advanced configuration wizard also let you send a test message.
Note: If you are configuring the seeded Workflow Notification Mailer and you entered configuration parameters for this mailer through AutoConfig, then you only need to enter the password for the e-mail inbox in order to complete the configuration for that mailer. If you did not enter parameters for the seeded mailer through AutoConfig, then in order to complete the configuration for that mailer you need to enter only the SMTP server, IMAP server, e-mail inbox username, e-mail inbox password, and reply-to e-mail address. All other configuration parameters for the seeded Workflow Notification Mailer are initially set to default values and do not need to be changed, although you can optionally do so if you choose.
Note that the IMAP server, e-mail inbox username, e-mail inbox password, and reply-to e-mail address are required only if you want to receive inbound messages. Alternatively, if you only want to send outbound messages and do not need to receive inbound messages, you only need to disable inbound processing in order to complete the configuration of the Workflow Notification Mailer.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Notification Mailers status icon > (B) Create > (B) Continue
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Notification Mailers status icon > (B) Edit
This page lets you configure a notification mailer quickly by entering only the minimum required parameters in a single page. You must set parameters marked with an asterisk (*) to appropriate values for your environment before you can run the notification mailer.
Name - The name of the service component. This name must be unique. The name of the seeded notification mailer service component is Workflow Notification Mailer, and you cannot change this value.
Server Name - The name of the outbound SMTP mail server. Note that you must specify the actual host name for the server. Do not use localhost as the setting for this parameter. You can optionally specify the port number to use on that server. If you do not specify a port number, the notification mailer uses port 25 by default. Specify the server in the following format: <server_name>[:<port_number>]
For example: mysmtpserver.mycompany.com:25
Outbound SSL Enabled - Select this parameter to enable the notification mailer to use Secure Sockets Layer (SSL) for connections to the SMTP server. Deselect this parameter to use non-SSL connections.
Note: When you enable SSL, the notification mailer connects to the SMTP server through port 465 by default. You can optionally specify a different port number along with the SMTP server name in the Outbound E-mail Account (SMTP): Server Name parameter.
Before you can use SSL, you must also complete additional setup steps. See: Connecting to Mail Servers Through SSL.
Inbound Processing - Select this parameter to enable inbound e-mail processing with this notification mailer. Deselect this parameter to disable inbound e-mail processing for this notification mailer and dedicate the notification mailer solely to outbound processing.
If you disable inbound processing, you can leave the other inbound parameters blank.
Server Name - The name of the inbound IMAP mail server. Note that you must specify the actual host name for the server. Do not use localhost as the setting for this parameter. You can optionally specify the port number to use on that server. If you do not specify a port number, the notification mailer uses port 143 by default. Specify the server in the following format: <server_name>[:<port_number>]
For example: myimapserver.mycompany.com:143
Username - The user name of the mail account that the notification mailer uses to receive e-mail messages.
Password - The password for the mail account specified in the Username parameter. The password value is masked as asterisks in the display and is stored in encrypted form.
Reply-To Address - The address of the e-mail account that receives incoming messages, to which notification responses should be sent. This value must be a full RFC822-compliant e-mail address.
If a particular notification message has the special #WFM_REPLYTO message attribute defined, however, the notification mailer will use the #WFM_REPLYTO attribute value as the reply address for that message, instead of the Reply-To Address parameter value.
Note: If you enable inbound processing, Oracle Workflow by default sets the From parameter, which is displayed in the From field of the message headers, to the name portion of the reply-to address. For example, if the reply-to address is Workflow@mycompany.com, the notification mailer sets the From parameter to Workflow.
If you disable inbound processing, Oracle Workflow by default sets both the Reply-To Address parameter and the From parameter to nobody@<server_name>, where <server_name> is the name of the outbound SMTP mail server.
To specify a different From value, navigate to the advanced configuration wizard.
Inbound SSL Enabled - Select this parameter to enable the notification mailer to use SSL for connections to the IMAP server. Deselect this parameter to use non-SSL connections.
Note: When you enable SSL, the notification mailer connects to the IMAP server through port 993 by default. You can optionally specify a different port number along with the IMAP server name in the Inbound E-mail Account (IMAP): Server Name parameter.
Before you can use SSL, you must also complete additional setup steps. See: Connecting to Mail Servers Through SSL.
Note: The notification mailer requires three folders in the IMAP mail account: the inbox, a folder to store processed messages, and a folder to store discarded messages. If you enable inbound processing and the mail account you specify in the Username parameter does not already include folders named PROCESS and DISCARD, Oracle Workflow automatically creates these two folders. To specify other folders for the notification mailer, navigate to the advanced configuration wizard.
Note: If you enable inbound processing, the notification mailer uses the Workflow Open Mail (Templated) message, which provides a response template for sending responses by e-mail, as the default message template for e-mail notifications that require a response. If you disable inbound processing, the notification mailer uses the Workflow Open Mail for Outlook Express message, which provides a link in HTML notifications for entering responses in the Notification Details page, as the default message template for e-mail notifications that require a response. To specify other message templates, navigate to the advanced configuration wizard.
Note that the plain text version of the Workflow Open Mail for Outlook Express message requests a response by e-mail. If you disable inbound processing, ensure that your users do not have a notification preference of MAILTEXT or MAILATTH. Alternatively, if you disable inbound processing and you want users to receive plain text notifications, use the advanced configuration wizard to specify a message template that directs recipients to respond from the Notification Details Web page, such as the standard Workflow View From UI message template or a custom message template.
To cancel any changes on this page, click the Cancel button.
To save this configuration, click the Apply button.
To send a test message, click the Test Mailer button. In the Test Notification Mailer page, select the recipient role to which the message should be sent, and click the Send Test Message button. Then check the e-mail account for the recipient role to verify that the test message was received. The test message does not require a response, so you can close it after reviewing it. However, you can optionally respond with a comment to acknowledge the message.
Note: To send a test message successfully, you must select a recipient role that either has a valid e-mail address defined, or that has members with valid e-mail addresses defined. The recipient role must also have a notification preference that includes individual e-mail notifications.
If you set an override e-mail address for the notification mailer, the Test Notification Mailer page displays that address. In this case the test message is sent to the override address rather than the e-mail address of the recipient role. However, you must still select a recipient role to enable the notification mailer to send the test message. See: Reviewing Service Component Details.
To set additional parameters for this notification mailer in the advanced configuration wizard, click the Advanced button.
This page lets you define general attributes for the service component. Some attributes are already set to required values and cannot be modified. You must set attributes marked with an asterisk (*) to appropriate values for your environment before you can run the service component.
ID - The configuration wizard displays the identifier for the service component.
Status - The configuration wizard displays the status of the service component.
Name - The name of the service component. This name must be unique. You can only edit the name when the notification mailer is not running. The name of the seeded notification mailer service component is Workflow Notification Mailer, and you cannot change this value.
Startup Mode - Select Automatic, Manual, or On-Demand as the startup mode for the service component. You can only edit the startup mode when the notification mailer is not running. The seeded Workflow Notification Mailer is assigned the Automatic startup mode by default, but you can optionally change this value.
Container Type - The container type to which this service component belongs. In Oracle Applications, the container type is always Oracle Applications Generic Service Management (Oracle Applications GSM).
Inbound Agent - The Business Event System agent for inbound processing. The inbound agent for a notification mailer service component is always WF_NOTIFICATION_IN.
Outbound Agent - The Business Event System agent for outbound processing. The outbound agent for a notification mailer service component is always WF_NOTIFICATION_OUT.
Correlation ID - Optionally select an item type to specify that this notification mailer should only process messages that belong to that item type. If you enter a partial value, this notification mailer will process messages that belong to any item type whose internal name begins with that value. You can enter an item type as the correlation ID if you want to increase throughput for that particular item type by dedicating a notification mailer to it.
If you leave the correlation ID blank, this notification mailer will process messages from any item type. The seeded Workflow Notification Mailer does not have any correlation ID specified, so that it can operate generally to process all messages; you cannot change this setting.
Both dedicated and general notification mailer components are compatible with each other. You can run several dedicated and general notification mailers at the same time if you choose. In this case, note that even if you have configured a dedicated mailer for a particular item type, a message from that item type may still be processed by a general mailer if that mailer is the first to access the message.
To cancel any changes on this page, click the Cancel button.
To save these settings and proceed to the next step of the configuration wizard, click the Next button.
This page lets you define detail attributes for the service component. You must set attributes marked with an asterisk (*) to appropriate values for your environment before you can run the service component. A refresh icon identifies attributes that can be refreshed dynamically while the service component is running.
ID - The configuration wizard displays the identifier for the service component.
Status - The configuration wizard displays the status of the service component.
Name - The configuration wizard displays the name defined for the service component.
Container - The container to which the service component will belong. Oracle Workflow provides a container called Workflow Mailer Service for notification mailer service components.
Maximum Idle Time - If you selected the On-Demand startup mode for the service component, enter the maximum time in minutes that the service component can remain idle before it is stopped. An on-demand component that is stopped in this way will be restarted by its container when it is needed again to process new messages.
Max Error Count - The number of consecutive errors the service component can encounter before its container stops it and changes its status to Stopped with Error. If an error is resolved and processing can continue, the error count is reset. The default value for the maximum error count is 10.
Inbound Thread Count - Set the inbound processing thread count to 1 (one) to enable inbound message processing with this notification mailer. Select 0 (zero) to disable inbound message processing for this notification mailer and dedicate the notification mailer solely to outbound processing. If you selected the Inbound Processing parameter in the Basic Configuration page, the inbound thread count is set to 1; if you deselected the Inbound Processing parameter, the inbound thread count is set to 0.
The inbound thread count cannot be greater than 1, because only one thread can access the e-mail inbox at a time. If you disable inbound message processing for this notification mailer, but you still want to perform e-mail response processing, you should create at least one other notification mailer with the same node name that does perform inbound message processing. Otherwise, there will be no inbound mailer that can process incoming responses to outbound messages sent by this outbound mailer.
Outbound Thread Count - Specify the number of outbound processing threads you want to execute simultaneously with this notification mailer. You can set the outbound thread count to 1 (one) or more depending on the volume of outbound messages you need to send. Specify 0 (zero) to disable outbound message processing for this notification mailer and dedicate the notification mailer solely to inbound processing. If you disable outbound message processing for this notification mailer, you should create at least one outbound notification mailer with the same node name. Otherwise, no inbound response messages will be marked with that node name and this inbound mailer will have no messages to process. The default value for the outbound thread count is 1.
Log Level - Select the level of detail for the information you want to record in the service component container log. The recommended log level, which is also the default value, is Error. Usually the log level only needs to be changed if you want to record additional detailed information for debugging purposes. You can choose the following levels:
1 - Statement
2 - Procedure
3 - Event
4 - Exception
5 - Error
6 - Unexpected
Processor Read Wait Timeout - Specify the amount of time in seconds that the service component's processing thread continues to wait, after reading the last message from its assigned queue, before timing out. If another message is received before this time expires, that message is processed and the timeout period begins again. If the timeout period expires and no more messages have been received, the service component stops reading and its sleep time begins. The default read timeout period for a notification mailer is 10 seconds.
Processor Min Loop Sleep - Specify the minimum sleep time in seconds during which the service component waits, after its read timeout period expires, before it checks its queue for messages again. The default minimum sleep time for a notification mailer is 5 seconds.
Processor Max Loop Sleep - Specify the maximum sleep time in seconds if you want to increase the sleep time between read attempts when no messages are received. If you specify a maximum sleep time that is greater than the minimum sleep time, then the service component initially waits for the minimum sleep time after it finishes reading messages from its queue. If no messages are read in subsequent attempts, then the sleep time between read attempts gradually increases until the maximum sleep time is reached. Increasing the sleep time can help enhance performance if messages are received infrequently. You can also specify 0 (zero) for this parameter to indicate that the sleep time should not be increased. In this case, the service component always waits for the minimum sleep time between read attempts. The default maximum sleep time for a notification mailer is 60 seconds.
Processor Error Loop Sleep - Specify the sleep time in seconds during which the service component waits, after an error occurs, before it attempts to begin processing again. The default error sleep time for a notification mailer is 60 seconds.
Processor Close on Read Timeout - Select this parameter to specify that the service component should close its connections after its read timeout period expires, when its sleep time begins. Deselect this parameter to specify that the connections should remain open until the processing thread stops.
To cancel any changes on this page, click the Cancel button.
To return to the previous step of the configuration wizard, click the Back button.
To save these settings and proceed to the next step of the configuration wizard, click the Next button.
This page lets you define e-mail server parameters for the notification mailer. Some parameters are already set to required values and cannot be modified. You must set parameters marked with an asterisk (*) to appropriate values for your environment before you can run the notification mailer. A refresh icon identifies attributes that can be refreshed dynamically while the service component is running. If the notification mailer is currently running, then parameters marked with a refresh icon will be refreshed immediately when you select the Next button.
Mailer Node Name - The node identifier name used by this notification mailer. The maximum length for a node name is eight characters. The node name cannot include any spaces or any of the following characters: left bracket ([), right bracket (]), slash (/), or at sign (@). The node name is included with the outgoing notification ID in outbound messages, and is used in inbound messages to identify the notification mailer that should process the messages. If you use the inbound and outbound thread count parameters to create notification mailers that are dedicated to either inbound or outbound processing, you should ensure that you assign the same node name to at least one outbound mailer and one inbound mailer, so that inbound mailer can process responses to messages sent by the outbound mailer. You can optionally assign the same node name to multiple mailers for load balancing purposes. However, each mailer that performs inbound processing for a node must have its own inbox. The default node name is WFMAIL.
Note: The node name for each node must be unique. However, multiple mailers can share the same node.
If a particular notification message has the special #WFM_NODENAME message attribute defined, however, an outbound notification mailer will include the #WFM_NODENAME attribute value when sending the message, instead of the Mailer Node Name mailer parameter value.
Email Parser - The Java class used to parse an incoming notification response e-mail formatted according to the templated response method and to create an XML document for the response. The notification mailer uses this parser when the Direct Response parameter is deselected. The default standard e-mail parser provided by Oracle Workflow is named oracle.apps.fnd.wf.mailer.TemplatedEmailParser. Usually you do not need to change this value.
If you are not implementing inbound e-mail processing for this mailer, leave the default as a placeholder value.
Note: You do not need to change the value of the Email Parser parameter if you select the Direct Response parameter. The notification mailer automatically switches to the alternate e-mail parser when the Direct Response parameter is selected.
Alternate Email Parser - The Java class used to parse an incoming notification response e-mail formatted according to the direct response method and to create an XML document for the response. The notification mailer uses this parser when the Direct Response parameter is selected. The default alternate e-mail parser provided by Oracle Workflow is named oracle.apps.fnd.wf.mailer.DirectEmailParser. Usually you do not need to change this value.
If you are not implementing inbound e-mail processing for this mailer, leave the default as a placeholder value.
Note: You do not need to change the value of the Alternate Email Parser parameter if you deselect the Direct Response parameter. The notification mailer automatically switches to the standard e-mail parser when the Direct Response parameter is deselected.
Expunge Inbox on Close - Select this parameter to purge deleted messages from the inbox folder when the notification mailer closes this folder. If you do not select this parameter, copies of messages that were moved to the discard or processed folders remain in the inbox, in a deleted state, until you manually expunge them using your e-mail application.
Inbound Protocol - Oracle Workflow currently supports the IMAP protocol for inbound e-mail.
Inbound Server Name - The name of the inbound mail server. Note that you must specify the actual host name for the server. Do not use localhost as the setting for this parameter. You can optionally specify the port number to use on that server. If you do not specify a port number, the notification mailer uses port 143 by default. Specify the server in the following format: <server_name>[:<port_number>]
For example: myimapserver.mycompany.com:143
If you are not implementing inbound e-mail processing for this mailer, enter a placeholder value.
Username - The user name of the mail account that the notification mailer uses to receive e-mail messages.
If you are not implementing inbound e-mail processing for this mailer, enter a placeholder value.
Password - The password for the mail account specified in the Username parameter. The password value is masked as asterisks in the display and is stored in encrypted form.
If you are not implementing inbound e-mail processing for this mailer, enter a placeholder value.
Inbox Folder - The name of the folder from which the notification mailer receives inbound messages. This value is case-insensitive. The default value is INBOX. The inbox must be separate from the processed and discard folders. Each notification mailer that performs inbound processing should have its own separate inbox.
Note: Usually, you use a dedicated mail account for notification mailer processing. If you want to use a mail account for the notification mailer that you also use for other purposes, you should create a folder in that account where you will place inbound messages destined for the notification mailer and specify that folder in the Inbox Folder parameter. Otherwise, the notification mailer will attempt to process all messages in the regular inbox and discard any messages that are not notification responses. If you do specify a separate folder to use as the notification mailer inbox folder, however, you must move messages from the regular inbox to that separate folder yourself. Depending on your mail program, you may be able to create a filter in the mail account to move such messages automatically. Use your e-mail client to create the separate folder. A notification mailer may not be able to access folders that were created using command line tools outside the e-mail client.
If you are not implementing inbound e-mail processing for this mailer, leave the default as a placeholder value.
Inbound Connection Timeout - The maximum amount of time, in seconds, that the notification mailer will wait to establish a connection to the inbound server before timing out. The default inbound connection timeout period for a notification mailer is 120 seconds.
Inbound Message Fetch Size - The maximum number of messages that the notification mailer can fetch from the inbox at one time. The default inbound message fetch size is 100 messages.
Maximum Ignore List Size - The maximum number of notification IDs that the notification mailer can store in its ignore list, indicating that this notification mailer will make no further attempts to process them. For example, if the mailer encountered a connection error while processing a notification, that notification ID is temporarily added to the ignore list, and is then removed from the list the next time the inbox folder is successfully closed. The default maximum ignore list size is 1000. Usually you do not need to change this value.
Note: If the notification mailer finds additional messages to be ignored in the inbox when the ignore list is already full, the notification mailer removes the oldest notification IDs from the list and adds the new notification IDs instead.
Inbound SSL Enabled - Select this parameter to enable the notification mailer to use SSL for connections to the IMAP server. Deselect this parameter to use non-SSL connections.
Note: When you enable SSL, the notification mailer connects to the IMAP server through port 993 by default. You can optionally specify a different port number along with the IMAP server name in the Inbound Server Name parameter.
Before you can use SSL, you must also complete additional setup steps. See: Connecting to Mail Servers Through SSL.
Outbound Protocol - Oracle Workflow currently supports the SMTP protocol for outbound e-mail.
Outbound Server Name - The name of the outbound mail server. Note that you must specify the actual host name for the server. Do not use localhost as the setting for this parameter. You can optionally specify the port number to use on that server. If you do not specify a port number, the notification mailer uses port 25 by default. Specify the server in the following format: <server_name>[:<port_number>]
For example: mysmtpserver.mycompany.com:25
If you are not implementing outbound e-mail processing for this mailer, enter a placeholder value.
Test Address - This parameter has been replaced by the override e-mail address, which is available through the Component Details page for a notification mailer. See: Reviewing Service Component Details.
Outbound Connection Timeout - The maximum amount of time, in seconds, that the notification mailer will wait to establish a connection to the outbound server before timing out. The default outbound connection timeout period for a notification mailer is 120 seconds.
Outbound SSL Enabled - Select this parameter to enable the notification mailer to use Secure Sockets Layer (SSL) for connections to the SMTP server. Deselect this parameter to use non-SSL connections.
Note: When you enable SSL, the notification mailer connects to the SMTP server through port 465 by default. You can optionally specify a different port number along with the SMTP server name in the Outbound Server Name parameter.
Before you can use SSL, you must also complete additional setup steps. See: Connecting to Mail Servers Through SSL.
Processed Folder - The name of the mail folder where the notification mailer places successfully processed notification messages. This value is case-insensitive. The processed folder must be separate from the inbox and the discard folder.
The default value for this parameter is PROCESS. If you enabled inbound processing in the Basic Configuration page and the mail account you specified did not already include a folder named PROCESS, Oracle Workflow automatically created a folder with this name in that account when you completed the basic notification mailer configuration.
You can optionally specify the name of a different folder in this parameter. In this case, ensure that you use your e-mail client to create the folder. A notification mailer may not be able to access folders that were created using command line tools outside the e-mail client.
Note: The notification mailer does not perform any further operations on messages in the processed folder. You can review, back up, or delete these messages through your e-mail application if necessary.
If you are not implementing inbound e-mail processing for this mailer, leave the default as a placeholder value.
Discard Folder - The name of the mail folder where the notification mailer places incoming messages that are not recognized as notification messages. This value is case-insensitive. The discard folder must be separate from the inbox and the processed folder.
The default value for this parameter is DISCARD If you enabled inbound processing in the Basic Configuration page and the mail account you specified did not already include a folder named DISCARD, Oracle Workflow automatically created a folder with this name in that account when you completed the basic notification mailer configuration.
You can optionally specify the name of a different folder in this parameter. In this case, ensure that you use your e-mail client to create the folder. A notification mailer may not be able to access folders that were created using command line tools outside the e-mail client.
Note: The notification mailer does not perform any further operations on messages in the discard folder. You can review, back up, or delete these messages through your e-mail application if necessary.
If you are not implementing inbound e-mail processing for this mailer, leave the default as a placeholder value.
Allow Forwarded Response - Indicate whether to allow a user to respond by e-mail to an e-mail notification that has been forwarded from another role. This parameter is selected by default.
If Allow Forwarded Response is selected, the notification mailer never checks the "From" e-mail address of the notification response and always allows the response to be processed.
If Allow Forwarded Response is deselected, the notification mailer will check whether the "From" e-mail address of the notification response exactly matches the e-mail address of the recorded recipient role or the e-mail address of a user in that role. If the two e-mail addresses match exactly, meaning the notification was not forwarded or was forwarded according to a valid routing rule, the notification mailer treats the response as a valid response. If the two e-mail addresses do not match exactly, meaning the notification was simply forwarded using the e-mail Forward command, the notification mailer does not process the response and treats it as unsolicited mail.
Note: Note that there are limitations when you deselect Allow Forwarded Response. For example, suppose a notification is sent to a distribution list mail alias that does not have a user/role relationship in the Oracle Workflow directory service. If any user from the distribution list responds to the notification, the notification mailer will always treat that notification response as unsolicited mail, because the "From" e-mail address, which is an individual user's e-mail address, will never match the distribution list mail alias.
To cancel any changes on this page, click the Cancel button.
To return to the previous step of the configuration wizard, click the Back button.
To save these settings and proceed to the next step of the configuration wizard, click the Next button.
Note: When you click the Next button, the configuration wizard validates the parameters you entered. If the inbound thread count is set to 1, the configuration wizard also verifies that it can connect to the e-mail account on the specified inbound mail server with the specified user name and password, and that the folders specified in the Processed Folder and Discard Folder parameters exist in that e-mail account. If the parameters are successfully validated, and the notification mailer is currently running, then Oracle Workflow Manager immediately refreshes the notification mailer with the new parameters.
This page lets you define message generation parameters for the notification mailer. Some parameters are already set to required values and cannot be modified. You must set parameters marked with an asterisk (*) to appropriate values for your environment before you can run the notification mailer. A refresh icon identifies attributes that can be refreshed dynamically while the service component is running. If the notification mailer is currently running, parameters marked with a refresh icon will be refreshed immediately when you select the Next button or the Finish button.
From - A value that appears in the From field of the message header of a notification e-mail. You can specify the From parameter value either as a display name only, or as a full RFC822-compliant address.
If you specify a display name only, the notification mailer adds the e-mail address from the Reply-to Address parameter to create a full RFC822-compliant address for the From message header. The full address is created in the following format: "Display Name" <reply_to_address>
If you specify a full RFC822-compliant address, the notification mailer uses only that From parameter value in the From message header, and does not include the Reply-to Address value.
If a particular notification message has the special #WFM_FROM message attribute defined, however, the notification mailer will use the #WFM_FROM attribute value in the From field for that message, instead of the From parameter value.
The default From parameter value for the seeded notification mailer service component is Workflow Mailer. For other notification mailers, if you selected the Inbound Processing parameter in the Basic Configuration page, Oracle Workflow by default sets the From parameter to the name portion of the reply-to address specified in the Basic Configuration page. For example, if the reply-to address is Workflow@mycompany.com, Oracle Workflow sets the From parameter to Workflow.
If you deselected the Inbound Processing parameter in the Basic Configuration page, Oracle Workflow by default sets the From parameter to nobody@<server_name>, where <server_name> is the name of the outbound SMTP mail server specified in the Basic Configuration page.
If you are not implementing outbound e-mail processing for this mailer, leave the default as a placeholder value.
Reply-to Address - The address of the e-mail account that receives incoming messages, to which notification responses should be sent. This value must be a full RFC822-compliant e-mail address.
If a particular notification message has the special #WFM_REPLYTO message attribute defined, however, the notification mailer will use the #WFM_REPLYTO attribute value as the reply address for that message, instead of the Reply-to Address parameter value.
Note: If the From parameter value is specified as a display name only, then the notification mailer also uses the reply-to e-mail address together with that display name to create a full RFC822-compliant address for the From field of the message header.
If you deselected the Inbound Processing parameter in the Basic Configuration page, Oracle Workflow by default sets the Reply-to Address parameter to nobody@<server_name>, where <server_name> is the name of the outbound SMTP mail server specified in the Basic Configuration page. If you are not implementing inbound e-mail processing for this mailer, leave the default as a placeholder value.
HTML Agent - The base URL that identifies the HTML agent that handles HTML notification responses. This URL is required to support e-mail notifications with HTML attachments. Usually the HTML agent specified here can match the value of the Applications Servlet Agent profile option; however, you can optionally specify a different HTML agent for a particular notification mailer. The HTML agent should be specified in the following format:
http://<server_name:port>/OA_HTML/where <server_name:port> represents the server and TCP/IP port number on which your servlet agent accepts requests.
Note: The notification mailer can also still handle an HTML agent value in the previous format:
http://<server_name:port>/pls/wfIf a particular notification message has the special #WFM_HTMLAGENT message attribute defined, however, the notification mailer will use the #WFM_HTMLAGENT attribute value as the HTML agent for that message, instead of the HTML Agent mailer parameter value.
Message Formatter - Oracle Workflow uses the oracle.apps.fnd.wf.mailer.NotificationFormatter Java class to generate notification messages.
Framework User - The numerical user ID for the user through which a notification mailer accesses Oracle Applications Framework content for inclusion in e-mail notifications. The Framework user must have workflow administrator privileges in order to access the content for every user's notifications.
The default value for this parameter is 0, which is the user ID for the SYSADMIN user. This setting lets the notification mailer access Oracle Applications Framework content through the SYSADMIN user, which is also the default workflow administrator role. If you change the Workflow System Administrator preference, check the Framework User parameter to ensure that the user accessed by the notification mailer has workflow administrator privileges. Set the Framework User parameter to a user that is a member of the Workflow System Administrator role, or, if you set the Workflow System Administrator preference to a responsibility, set the Framework User parameter to a user that has that responsibility. See: Setting Global User Preferences.
Framework Responsibility - The numerical responsibility ID for the responsibility through which a notification mailer accesses Oracle Applications Framework content for inclusion in e-mail notifications. The user specified in the Framework User parameter must have this responsibility assigned. The default value for this parameter is 20420, which is the responsibility ID for the System Administrator responsibility.
Framework Application ID - The numerical application ID for the application through which a notification mailer accesses Oracle Applications Framework content for inclusion in e-mail notifications. The responsibility specified in the Framework Responsibility parameter must be assigned to this application. The default value for this parameter is 1, which is the application ID for the System Administration application.
Framework URL Timeout - The maximum amount of time, in seconds, that the notification mailer will wait to access a URL for Oracle Applications Framework content before timing out. The default Framework URL timeout period for a notification mailer is 30 seconds.
Attach Images to Outbound Emails - Select this parameter to attach any images referenced in HTML content included in a message, such as Oracle Applications Framework content, to outbound notification e-mail messages. Deselect this parameter to display the image references as off-page URLs instead of attaching the images.
Attach Stylesheet to Outbound Email - Select this parameter to attach any stylesheet referenced in HTML content included in a message, such as Oracle Applications Framework content, to outbound notification e-mail messages. Deselect this parameter to display the stylesheet reference as a URL instead of attaching the stylesheet.
Note: E-mail clients vary in their support for stylesheet references within HTML content in the body of an e-mail. Some e-mail clients do not support references to a stylesheet that is attached to the e-mail, while others do not support any form of stylesheet references within HTML content at all. Consequently, attaching a stylesheet may not have the same effect in all e-mail clients.
Autoclose FYI - Indicate whether this notification mailer automatically closes notifications that do not require a response, such as FYI (For Your Information) notifications, after sending the notifications by e-mail. This parameter is selected by default. If Autoclose FYI is deselected, all FYI notifications will remain open in the Worklist until users manually close these notifications.
Direct Response - By default, notification mailers require a response format for plain text notifications called the templated response method. Select this parameter to use the direct response method instead.
With the templated response method, a notification mailer sends plain text notifications requiring a templated response to users with a notification preference of MAILTEXT or MAILATTH. Users must reply using a template of response prompts and enter their response values between the quotes following each prompt.
With the direct response method, a notification mailer sends plain text notifications requiring a direct response to users with a notification preference of MAILTEXT or MAILATTH. Users must enter their response values directly as the first lines of a reply.
Note: Responses that are generated automatically from an HTML-formatted notification or attachment must always use a response template, regardless of which response method you select.
See: Workflow Open Mail (Templated) Message, Workflow Open Mail (Direct) Message, To Respond to a Plain Text E-mail Notification Using Templated Response, Oracle Workflow User's Guide, To Respond to a Plain Text E-mail Notification Using Direct Response, Oracle Workflow User's Guide, and Example 'Respond' Message Attributes, Oracle Workflow Developer's Guide.
Reset NLS - Indicate whether the notification mailer should convert the NLS codeset for a notification message according to the notification recipient's preferences before composing the message. This parameter is deselected by default. If Reset NLS is selected, the notification mailer will convert the message to the codeset listed in the WF_LANGUAGES table for the language and territory specified in the recipient's user preferences. If no preferred territory is specified, the notification mailer will use the codeset associated with the first entry it encounters for the user's preferred language. If neither a language nor a territory is specified in the user preferences, the notification mailer will use the codeset seeded in WF_LANGUAGES for the language AMERICAN and territory AMERICA. This parameter is relevant when there are several languages installed in the database and the character set of the user's e-mail client is not the same as the one specified for the database. For example, when a UTF8 database is used, the character set of e-mail clients used in Western Europe is generally 'Western (ISO-8859-1)'. In this case, selecting the Reset NLS parameter means that users who specify a Western European language such as French or German in their user preferences will receive any e-mail notification messages in the correct character set for the e-mail client.
If a particular notification message has the special #WFM_RESET_NLS message attribute defined, however, the notification mailer will use the #WFM_RESET_NLS attribute value to determine whether or not to encode the e-mail to the preferred codeset for that message, instead of using the Reset NLS parameter value.
Inline Attachments - Select this parameter to set the Content-Disposition MIME header to inline for attachments to notification messages, including the Notification Detail Link, HTML Message Body, Notification References containing attached URLs, and attached PL/SQL documents. Deselect this parameter to set the Content-Disposition MIME header to attachment for these attachments. For example, if your e-mail application cannot display HTML content such as the Notification Detail Link inline, deselect this parameter to display this link as an attachment instead. Note, however, that some e-mail clients may not support the Content-Disposition header, or may support it in varying ways. Consequently, the Inline Attachment setting may not always have the desired effect, depending on the e-mail clients with which users read their e-mail messages.
Send Warning for Unsolicited E-mail - Select this parameter to allow the notification mailer to send back a warning message the first time it receives an unsolicited e-mail message from a particular e-mail address. Deselect this parameter to prevent the notification mailer from sending warning messages.
Send E-mails for Canceled Notifications - Select this parameter to allow the notification mailer to send cancellation messages to users when previously sent notifications are canceled. Deselect this parameter to prevent the notification mailer from sending cancellation messages.
If you set up multiple notification mailers in the same Oracle Applications instance, you must set this parameter to the same setting for all the notification mailers.
This region lets you specify the message templates you want to use to generate e-mail notifications. The template for a particular type of e-mail notification determines the basic format of the notification, including what header information to include, and whether and where to include details such as the message due date and priority.
Oracle Workflow provides a set of standard templates in the System: Mailer item type, which are used by default. It is not recommended to modify the standard templates. However, you can customize the message templates used to send your e-mail notifications by creating your own custom message templates in the System: Mailer item type using the Workflow Builder, and assigning these templates to a particular notification mailer service component in this region. The templates assigned to a mailer override the default System: Mailer templates.
Additionally, you can create your own custom message templates in a custom item type using the Workflow Builder, and assign these templates to a particular notification in a workflow process by defining special message attributes. In this case the templates assigned to the notification override both the templates assigned to a mailer and the default System: Mailer templates.
If you are not implementing outbound e-mail processing for this mailer, leave the default templates as placeholder values.
Attached URLs - The notification mailer uses this template to create the Notification References attachment for HTML-formatted notification messages that include URL attributes with Attach Content checked. The template must includes a list with links to each URL.
Outbound Closed Notification - The notification mailer uses this template to inform the recipient that a previously sent notification is now closed.
Outbound Cancelled Notification - The notification mailer uses this template to inform the recipient that a previously sent notification is canceled. You can optionally use the Send E-mails for Canceled Notifications parameter to specify whether or not the notification mailer should send Outbound Cancelled Notification messages.
Invalid Response Notification - The notification mailer uses this template to inform a user that the user responded incorrectly to a notification. For example, if a response message from a user contains a valid notification ID (NID) line matching it with a notification, but does not contain any response value or contains an invalid response value, the notification mailer sends an Invalid Response Notification message to the user. This template must describe how to respond to the notification correctly.
Open Notification - If you are using the default response method, which is templated response, the notification mailer uses this template to send open notifications that require a response. This message template must provide a response template for the recipient as well as instructions on how to use the response template.
Note: In addition to the default Workflow Open Mail (Templated) message template, Oracle Workflow also provides a predefined template called Workflow Open Mail for Outlook Express. This template is provided to accommodate e-mail applications such as Microsoft Outlook Express or other e-mail clients that cannot process the response links included in the HTML bodies of the Workflow Open Mail (Templated) and Workflow Open Mail (Direct) templates. If you use one of these e-mail clients, you can select the Workflow Open Mail for Outlook Express message template to have HTML e-mail notifications include a link to the Notification Details Web page which lets users respond to the notification there.
If you are configuring this notification mailer for outbound message processing only and you are not implementing any corresponding inbound e-mail response processing, then you should set the Open Notification parameter to a message template that does not request a response by e-mail, but instead directs recipients to respond from the Notification Details Web page. For example, you can select the Workflow View From UI message template provided by Oracle Workflow, or create your own custom message template.
If you selected the Inbound Processing parameter in the Basic Configuration page, the Open Notification parameter is set to the Workflow Open Mail (Templated) message template by default. If you deselected the Inbound Processing parameter, the Open Notification parameter is set to the Workflow Open Mail for Outlook Express message template by default.
Note: The plain text version of the Workflow Open Mail for Outlook Express message requests a response by e-mail. If you disable inbound processing, ensure that your users do not have a notification preference of MAILTEXT or MAILATTH. Alternatively, if you disable inbound processing and you want users to receive plain text notifications, specify a message template that directs recipients to respond from the Notification Details Web page.
Open Notification (Direct Response Parsing) - If you select the Direct Response parameter, the notification mailer uses this template to send open notifications that require a response. The response instructions in the plain text message body must describe how to reply using the direct response method. This message is used for notifications sent to performers with a notification preference of MAILTEXT or MAILATTH. The response instructions in the HTML-formatted message body must describe how to reply using the automatically generated response template. This message is used for notifications sent to performers with a notification preference of MAILHTML or MAILHTM2, and is also attached to notifications sent to performers with a notification preference of MAILATTH.
Note: Responses that are generated automatically from an HTML-formatted notification or attachment must always use a response template, regardless of which response method you select.
Note: If you are configuring this notification mailer for outbound message processing only and you are not implementing any corresponding inbound e-mail response processing, then you should set the Open Notification (Direct Response Parsing) parameter to a message template that does not request a response by e-mail, but instead directs recipients to respond from the Notification Details Web page. For example, you can select the Workflow View From UI message template provided by Oracle Workflow, or create your own custom message template.
See: Workflow Open Mail (Templated) Message, Workflow Open Mail (Direct) Message, To Respond to a Plain Text E-mail Notification Using Templated Response, Oracle Workflow User's Guide, To Respond to a Plain Text E-mail Notification Using Direct Response, Oracle Workflow User's Guide, and Example 'Respond' Message Attributes, Oracle Workflow Developer's Guide.
Open FYI Notification - The notification mailer uses this template to send notifications that do not require a response. The template must indicate that the notification is for your information (FYI) and does not require a response.
Outbound Summary Notification - This template is no longer used in Oracle Applications.
Outbound Warning Notification - The notification mailer uses this template to send a message to a user the first time it receives unsolicited mail from that user. For example, if a message from a user does not contain a notification ID (NID) line matching it with a notification, or contains an incorrectly formatted NID line, the notification mailer sends an Outbound Warning Notification message to the user. You can optionally use the Send Warning for Unsolicited E-mail parameter to specify whether or not the notification mailer should send Outbound Warning Notification messages.
Open Notification (More Information Request) - The notification mailer uses this template to send a request for more information about a notification from one user to another user.
Note: If you use an e-mail application such as Microsoft Outlook Express that cannot process the response link included in the default Workflow Open Mail (More Information Request) message template, you can select an alternative template named Workflow Open Mail (More Information Request for Outlook Express) instead. In particular, if you set the Open Notification parameter to use the Workflow Open Mail for Outlook Express message, then you should also set the Open Notification (More Information Request) parameter to use the Workflow Open Mail (More Information Request for Outlook Express) message.
Outbound HTML Summary Notification - The notification mailer uses this template to send a summary of currently open workflow notifications to users and roles that have their notification preference set to SUMMARY or SUMHTML in the Oracle Workflow directory service.
To cancel any changes on this page, click the Cancel button.
To return to the previous step of the configuration wizard, click the Back button.
To save these settings and proceed to the next step of the configuration wizard, click the Next button.
To save these settings and proceed to the last step of the configuration wizard, click the Finish button.
Note: When you click the Next or Finish button, the configuration wizard validates the parameters you entered. If the parameters are successfully validated, and the notification mailer is currently running, then Oracle Workflow Manager immediately refreshes the notification mailer with the new parameters.
This page lets you schedule events to control the running of the service component. The events are raised at the scheduled time by DBMS jobs. For a notification mailer service component, you can schedule the following events:
Start
Refresh
Suspend
Resume
Stop
Launch Summary Notifications
For each event, the list displays the event name, date and time when the event is first scheduled to be raised, the interval in minutes at which the event is reraised, and, for a Refresh event, any parameters to be refreshed. You can specify the following refreshable parameters, using the parameters' internal names, when you refresh the notification mailer.
PROCESSOR_IN_THREAD_COUNT - Inbound Thread Count
PROCESSOR_OUT_THREAD_COUNT - Outbound Thread Count
COMPONENT_LOG_LEVEL - Log Level, specified as a numerical value
1 - Statement
2 - Procedure
3 - Event
4 - Exception
5 - Error
6 - Unexpected
EXPUNGE_ON_CLOSE - Expunge Inbox on Close
ALLOW_FORWARDED_RESPONSE - Allow Forwarded Response
FROM - From
REPLYTO - Reply-to Address
HTMLAGENT - HTML Agent
ATTACH_IMAGES - Attach Images to Outbound E-mails
ATTACH_STYLESHEET - Attach Stylesheet to Outbound E-mail
AUTOCLOSE_FYI - Autoclose FYI
RESET_NLS - Reset NLS
INLINE_ATTACHMENT - Inline Attachments
SEND_UNSOLICITED_WARNING - Send Warning for Unsolicited E-mail
ATTACHED_URLS - Attached URLs
CLOSED - Outbound Closed Notification
CANCELED - Outbound Cancelled Notification
OPEN_INVALID - Invalid Response Notification
OPEN_MAIL - Open Notification
OPEN_MAIL_DIRECT - Open Notification (Direct Response Parsing)
OPEN_MAIL_FYI - Open FYI Notification
SUMMARY - Outbound Summary Notification
WARNING - Outbound Warning Notification
OPEN_MORE_INFO - Open Notification (More Information Request)
SUMHTML - Outbound HTML Summary Notification
To schedule events:
If no events are currently scheduled, click the Add a Row button to add a new row to the list of events and enter the information for the event.
Select the event for the command you want to schedule.
Select the date when you want the event to be raised first.
Select the hour and minute to specify the time on the specified date when you want the event to be raised first. The hour values are in a twenty-four hour format. For example, select 00 for midnight, or 23 for 11 PM.
If you want to raise the event periodically, enter the time interval in minutes at which you want to raise the event. If you do not specify a repeating interval, the event is raised only once.
If you choose the refresh event, you can optionally enter any parameters you want to include with the event in order to refresh the notification mailer configuration parameters with those values when the event is raised. Specify the parameter names and values in the following format, separating the parameters with a colon (:): internal_parameter_name=parameter_value
For example: PROCESSOR_OUT_THREAD_COUNT=3
To schedule another event, click the Add Another Row button and enter the information for the event.
To remove an event, select the event and click the Remove button.
To cancel any changes on this page, click the Cancel button.
To return to the previous step of the configuration wizard, click the Back button.
To save these settings and proceed to the next step of the configuration wizard, click the Next button.
To save these settings and proceed to the last step of the configuration wizard, click the Finish button.
Note: The configuration wizard verifies that an event is specified for every row in the list when you click the Next or Finish button. If you do not want to schedule another event, remove any empty rows before proceeding.
This page lets you enter patterns of text found in unusual messages and the status you want to assign to an inbound message if it contains any of those patterns. For example, unusual messages include bounced or returned messages and auto-reply messages such as those sent by vacation daemons, mass mailing lists, and so on. Since different mail systems vary in how they identify bounced, undeliverable, or otherwise invalid messages, you can use notification mailer tags to specify how your mail system identifies those stray messages and how you want the notification mailer to handle those messages should it come across them.
Oracle Workflow provides several predefined tags for text commonly found in undeliverable or auto-reply messages. For each tag, the list displays the pattern, which is the string of text to look for in the From line, Subject line, or body of the message, and the action, which is the mail status to assign to the message if that pattern is found. The notification mailer handles messages according to these mail status values, as follows:
UNDELVRD - Moves the message to the discard folder and updates the notification's mail status to FAILED. Additionally, the notification preference of the recipient of the notification is updated to DISABLED. No error process is initiated for this notification activity. However, after correcting the issues that prevented the e-mail from being sent, you can reset the user's notification preference and then run the Resend Failed Workflow Notifications program to re-enqueue failed notifications on the notification mailer's outbound queue. See: Handling Mailer Errors.
Unavailable - Moves the message to the discard folder and continues waiting for a reply to the notification since the notification's status is still OPEN, but its mail status is updated to UNAVAIL. This status is purely informative, as no further processing occurs with this notification.
Ignore - Moves the message to the discard folder and continues waiting for a valid reply to the open notification. The notification's status is still OPEN and its mail status is still SENT.
You can define additional tags for other patterns you want the notification mailer to handle automatically.
To add a new tag, click the Add Another Row button, enter the text pattern in the Pattern column, and select the status you want to assign to messages containing that pattern in the Action column.
To remove a tag, select the tag and click the Remove button. You can only remove custom tags that you defined. You cannot remove predefined tags provided by Oracle Workflow.
Note: It is important that you uniquely identify bounced messages and auto-replies by defining tags to distinguish them from normal responses. If you do not identify bounced and auto-reply messages, the notification mailer can mistake these as invalid responses, send an Invalid Response Notification message, and continue to wait for a reply. In both cases a perpetual loop would occur where the notification mailer continues sending out an 'Invalid' message and the 'Invalid' message bounces back or is auto-replied each time.
Note: Only a message response that contains a notification ID can be handled through the FAILED and UNAVAIL mail statuses. If the notification mailer receives a message response that does not contain a notification ID, it moves the message response to the discard folder. If the Send Warning for Unsolicited E-mail parameter is selected, then for the first such message from a particular e-mail address, the notification mailer also sends an Outbound Warning Notification message to the sender to warn that it received unsolicited mail.
Note: If a message response matches more than one pattern in the list of tags, the message is tagged with the status of the first tag it matches. That is, the notification mailer performs a top to bottom comparison against the tag list. Due to this behavior, you should prioritize your patterns listing the UNDELVRD tags first, followed by the Unavailable and then Ignore tags.
To cancel any changes on this page, click the Cancel button.
To return to the previous step of the configuration wizard, click the Back button.
To save these settings and proceed to the next step of the configuration wizard, click the Next button.
To save these settings and proceed to the last step of the configuration wizard, click the Finish button.
This page lets you test the configuration for a notification mailer that performs outbound e-mail processing by sending a sample notification message. Select the recipient role to which the message should be sent, and click the Send Test Message button. Then check the e-mail account for the recipient role to verify that the test message was received. The test message does not require a response, so you can close it after reviewing it. However, you can optionally respond with a comment to acknowledge the message.
To send a test message successfully, you must select a recipient role that either has a valid e-mail address defined, or that has members with valid e-mail addresses defined. The recipient role must also have a notification preference that includes individual e-mail notifications.
If you set an override e-mail address for the notification mailer, the Test page displays that address. In this case the test message is sent to the override address rather than the e-mail address of the recipient role. However, you must still select a recipient role to enable the notification mailer to send the test message. See: Reviewing Service Component Details.
To exit the advanced configuration wizard, click the Cancel button.
To return to the previous step of the configuration wizard, click the Back button.
To proceed to the next step of the configuration wizard, click the Next button.
To proceed to the last step of the configuration wizard, click the Finish button.
This page lets you review the configuration parameter values that you set, the events that you scheduled, and the tags that you defined for this notification mailer service component.
If you want to change any of these settings, return to the appropriate step in the configuration wizard to make your changes. To return to the previous step, click the Back button.
To save these settings and finish the configuration, click the Finish button.
The Oracle Workflow Business Event System requires agent listeners to be scheduled to receive inbound event messages. An agent listener monitors a Business Event System agent for incoming messages and dequeues messages using the agent's queue handler. You should run agent listeners for your local inbound agents. Run PL/SQL agent listeners to process event subscriptions with a PL/SQL rule function in the database, and run Java agent listeners to process event subscriptions with a Java rule function in the middle tier.
When an event message is dequeued, the Event Manager begins subscription processing for the event. The Event Manager searches for and executes any active subscriptions by the local system to that event with a source type of External, and also any active subscriptions by the local system to the Any event with a source type of External. The agent listener exits after all event messages on the agent's queue have been dequeued.
The PL/SQL agent listener program is defined as a service component type in the Generic Service Component Framework. This framework helps to simplify and automate the management of background Java services.
Oracle Workflow provides several seeded agent listener service components to process messages on standard agents.
Workflow Deferred Agent Listener - Handles messages on WF_DEFERRED to support deferred subscription processing. This service component is started automatically by its container.
Workflow Deferred Notification Agent Listener - Handles notification messages on WF_DEFERRED to support outbound notification processing. This service component is started automatically by its container.
Workflow Error Agent Listener - Handles messages on WF_ERROR to support error handling for the Business Event System. This service component is started automatically by its container.
Workflow Inbound Notifications Agent Listener - Handles messages on WF_NOTIFICATION_IN to support inbound e-mail notification processing. This service component is started automatically by its container.
ECX Inbound Agent Listener - Handles message on ECX_INBOUND to support Oracle XML Gateway processing. This service component must be started manually. For more information, see the Oracle XML Gateway User's Guide.
ECX Transaction Agent Listener - Handles message on ECX_TRANSACTION to support Oracle XML Gateway processing. This service component must be started manually. For more information, see the Oracle XML Gateway User's Guide.
You cannot delete the seeded agent listeners or edit their names, assigned agents, correlation ID values, or containers. However, if necessary you can update other configuration parameters, schedule control events, or manually choose control commands to start, stop, suspend, resume, or refresh the agent listeners.
You can also optionally create additional agent listener service components. For example, you can configure agent listeners for other inbound agents that you want to use for event message propagation, such as the standard WF_IN and WF_JMS_IN agents, or any custom agents. You can also configure an agent listener that only processes messages on a particular agent that are instances of a specific event.
If you create custom agent listener service components, you can either assign them to the seeded container for agent listeners, named Workflow Agent Listener Service, or, based on the volume to be handled by the seeded container, you can also choose to create your own custom containers.
Before the seeded agent listener service components can run, the Workflow Agent Listener Service container which manages them must be first be started. You should ensure that this container is running. If you create your own custom containers for custom service components, ensure that those containers are running as well. Use the Service Instances page to start each container as a service instance in Generic Service Management (GSM). When the Workflow Agent Listener Service container is running, it automatically starts the Workflow Deferred Agent Listener, Workflow Deferred Notification Agent Listener, Workflow Error Agent Listener, and Workflow Inbound Notifications Agent Listener.
The agent listener configuration wizard lets you configure an agent listener service component by defining general and detail attributes and scheduling control events. You can use the configuration wizard to configure a new agent listener service component, or to edit the configuration of an existing agent listener service component.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon > (B) Create > (B) Continue
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon > (B) Edit
This page lets you define general attributes for the service component. Some attributes are already set to required values and cannot be modified. You must set attributes marked with an asterisk (*) to appropriate values for your environment before you can run the service component.
ID - When you edit a previously created service component, the configuration wizard displays the identifier for the service component.
Status - When you edit a previously created service component, the configuration wizard displays the status of the service component.
Name - The name of the service component. This name must be unique.
Startup Mode - Select Automatic, Manual, or On-Demand as the startup mode for the service component.
Container Type - The container type to which this service component belongs. In Oracle Applications, the container type is always Oracle Applications Generic Service Management (Oracle Applications GSM).
Inbound Agent - The Business Event System agent that you want to monitor for inbound event messages.
Outbound Agent - Leave this field blank. Agent listener service components do not use an outbound agent.
Correlation ID - Optionally specify the Oracle Advanced Queuing (AQ) correlation ID of the event messages that you want the agent listener to process. The AQ correlation ID for an event message in the Business Event System is usually specified in the following format:
<event name>
Consequently, by specifying a correlation ID in this attribute, you can dedicate the agent listener to listen only for messages that are instances of the specified event. You can also specify a partial value to listen for messages that are instances of any event whose name begins with the specified value.
For example, the seeded Workflow Deferred Notification Agent Listener has an AQ correlation ID of oracle.apps.wf.notification.%, meaning that this agent listener handles only notification event messages on the WF_DEFERRED agent. However, the Workflow Deferred Agent Listener, Workflow Error Agent Listener, and Workflow Inbound Notifications Agent Listener do not have any correlation ID specified so that they can process all event messages on their respective agents.
Note: The AQ correlation ID is different than the correlation ID contained within the WF_EVENT_T event message structure.
To cancel the configuration without saving any changes, click the Cancel button.
To save these settings and proceed to the next step of the configuration wizard, click the Next button.
This page lets you define detail attributes for the service component. You must set attributes marked with an asterisk (*) to appropriate values for your environment before you can run the service component. A refresh icon identifies attributes that can be refreshed dynamically while the service component is running.
ID - When you edit a previously created service component, the configuration wizard displays the identifier for the service component.
Status - When you edit a previously created service component, the configuration wizard displays the status of the service component.
Name - The configuration wizard displays the name defined for the service component.
Container - The container to which the service component will belong. Oracle Workflow provides a container called Workflow Agent Listener Service for agent listener service components.
Maximum Idle Time - If you selected the On-Demand startup mode for the service component, enter the maximum time in minutes that the service component can remain idle before it is stopped. An on-demand component that is stopped in this way will be restarted by its container when it is needed again to process new messages.
Max Error Count - The number of consecutive errors the service component can encounter before its container stops it and changes its status to Stopped with Error. If an error is resolved and processing can continue, the error count is reset. The default value for the maximum error count is 10.
Inbound Thread Count - Set the inbound processing thread count to 1 (one) to enable inbound message processing with this agent listener. Select 0 (zero) to disable this agent listener. The default value is 1.
Outbound Thread Count - Leave this parameter set to the default value of 0 (zero). Agent listener service components do not perform outbound message processing.
Log Level - Select the level of detail for the information you want to record in the service component container log. The recommended log level, which is also the default value, is Error. Usually the log level only needs to be changed if you want to record additional detailed information for debugging purposes. You can choose the following levels:
1 - Statement
2 - Procedure
3 - Event
4 - Exception
5 - Error
6 - Unexpected
Processor Read Wait Timeout - Specify the amount of time in seconds that the service component's processing thread continues to wait, after reading the last message from its assigned queue, before timing out. If another message is received before this time expires, that message is processed and the timeout period begins again. If the timeout period expires and no more messages have been received, the service component stops reading and its sleep time begins. The default read timeout period for an agent listener is 0 (zero) seconds.
Processor Min Loop Sleep - Specify the minimum sleep time in seconds during which the service component waits, after its read timeout period expires, before it checks its queue for messages again. The default minimum sleep time for an agent listener is 120 seconds.
Processor Max Loop Sleep - Specify the maximum sleep time in seconds if you want to increase the sleep time between read attempts when no messages are received. If you specify a maximum sleep time that is greater than the minimum sleep time, then the service component initially waits for the minimum sleep time after it finishes reading messages from its queue. If no messages are read in subsequent attempts, then the sleep time between read attempts gradually increases until the maximum sleep time is reached. Increasing the sleep time can help enhance performance if messages are received infrequently. You can also specify 0 (zero) for this parameter to indicate that the sleep time should not be increased. In this case, the service component always waits for the minimum sleep time between read attempts. The default value for an agent listener is 0 (zero).
Processor Error Loop Sleep - Specify the sleep time in seconds during which the service component waits, after an error occurs, before it attempts to begin processing again. The default error sleep time for an agent listener is 60 seconds.
Processor Close on Read Timeout - Select this parameter to specify that the service component should close its connections after its read timeout period expires, when its sleep time begins. Deselect this parameter to specify that the connections should remain open until the processing thread stops.
To cancel any changes on this page, click the Cancel button.
To return to the previous step of the configuration wizard, click the Back button.
To save these settings and proceed to the next step of the configuration wizard, click the Next button.
To save these settings and proceed to the last step of the configuration wizard, click the Finish button.
This page lets you schedule events to control the running of the service component. The events are raised at the scheduled time by DBMS jobs. For an agent listener service component, you can schedule the following events:
Start
Refresh
Suspend
Resume
Stop
For each event, the list displays the event name, date and time when the event is first scheduled to be raised, the interval in minutes at which the event is reraised, and, for a refresh event, any parameters to be refreshed. You can specify the following refreshable parameters, using the parameters' internal names, when you refresh the agent listener.
PROCESSOR_IN_THREAD_COUNT - Inbound Thread Count
COMPONENT_LOG_LEVEL - Log Level, specified as a numerical value
1 - Statement
2 - Procedure
3 - Event
4 - Exception
5 - Error
6 - Unexpected
To schedule events:
If no events are currently scheduled, click the Add a Row button to add a new row to the list of events and enter the information for the event.
Select the event for the command you want to schedule. Oracle Workflow provides events to let you start, stop, refresh, suspend, or resume the service component.
Select the date when you want the event to be raised first.
Select the hour and minute to specify the time on the specified date when you want the event to be raised first. The hour values are in a twenty-four hour format. For example, select 00 for midnight, or 23 for 11 PM.
If you want to raise the event periodically, enter the time interval in minutes at which you want to raise the event. If you do not specify a repeating interval, the event is raised only once.
If you choose the refresh event, you can optionally enter any parameters you want to include with the event in order to refresh the agent listener configuration parameters with those values when the event is raised. Specify the parameter names and values in the following format, separating the parameters with a colon (:): internal_parameter_name=parameter_value
For example: PROCESSOR_IN_THREAD_COUNT=1
To schedule another event, click the Add Another Row button and enter the information for the event.
To remove an event, select the event and click the Remove button.
To cancel any changes on this page, click the Cancel button.
To return to the previous step of the configuration wizard, click the Back button.
To save these settings and proceed to the next step of the configuration wizard, click the Next button.
To save these settings and proceed to the last step of the configuration wizard, click the Finish button.
Note: The configuration wizard verifies that an event is specified for every row in the list when you click the Next or Finish button. If you do not want to schedule another event, you should remove any empty rows before proceeding.
This page lets you review the configuration parameter values that you set and the events that you scheduled for this service component.
If you want to change any of these settings, return to the appropriate step in the configuration wizard to make your changes. To return to the previous step, click the Back button.
To save these settings and finish the configuration, click the Finish button.
The Oracle Workflow Business Event System requires agent listeners to be scheduled to receive inbound event messages. An agent listener monitors a Business Event System agent for incoming messages and dequeues messages using the agent's queue handler. You should run agent listeners for your local inbound agents. Run PL/SQL agent listeners to process event subscriptions with a PL/SQL rule function in the database, and run Java agent listeners to process event subscriptions with a Java rule function in the middle tier.
When an event message is dequeued, the Event Manager begins subscription processing for the event. The Event Manager searches for and executes any active subscriptions by the local system to that event with a source type of External, and also any active subscriptions by the local system to the Any event with a source type of External. The agent listener exits after all event messages on the agent's queue have been dequeued.
The Java agent listener program is defined as a service component type in the Generic Service Component Framework. This framework helps to simplify and automate the management of background Java services.
Oracle Workflow provides several seeded Java agent listener service components to process messages on standard agents.
Workflow Java Deferred Agent Listener - Handles messages on WF_JAVA_DEFERRED to support deferred subscription processing in the middle tier. This service component is started automatically by its container.
Workflow Java Error Agent Listener - Handles messages on WF_JAVA_ERROR to support error handling for the Business Event System in the middle tier. This service component is started automatically by its container.
Web Services IN Agent - Handles messages on WF_WS_JMS_IN to support inbound Web service message processing. This service component must be started manually.
You can optionally update the configuration of the Workflow WebServices In listener or delete this service component if necessary. You cannot delete the Workflow Java Deferred Agent Listener and Workflow Java Error Agent Listener or edit their names, assigned agents, correlation ID values, or containers. However, if necessary you can update other configuration parameters, schedule control events, or manually choose control commands to start, stop, suspend, resume, or refresh these Java agent listeners.
You can also optionally create additional Java agent listener service components. For example, you can configure Java agent listeners for other inbound agents that you want to use for event message propagation in the middle tier, such as custom agents. You can also configure a Java agent listener that only processes messages on a particular agent that are instances of a specific event.
If you create custom Java agent listener service components, you can either assign them to the seeded container for agent listeners, named Workflow Agent Listener Service, or, based on the volume to be handled by the seeded container, you can also choose to create your own custom containers.
Before the seeded Java agent listener service components can run, the Workflow Agent Listener Service container which manages them must be first be started. You should ensure that this container is running. If you create your own custom containers for custom service components, ensure that those containers are running as well. Use the Service Instances page to start each container as a service instance in Generic Service Management (GSM). When the Workflow Agent Listener Service container is running, it automatically starts the Workflow Java Deferred Agent Listener and Workflow Java Error Agent Listener.
The Java agent listener configuration wizard lets you configure a Java agent listener service component by defining general and detail attributes and scheduling control events. You can use the configuration wizard to configure a new Java agent listener service component, or to edit the configuration of an existing Java agent listener service component.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon > (B) Create > (B) Continue
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon > (B) Edit
This page lets you define general attributes for the service component. Some attributes are already set to required values and cannot be modified. You must set attributes marked with an asterisk (*) to appropriate values for your environment before you can run the service component.
ID - When you edit a previously created service component, the configuration wizard displays the identifier for the service component.
Status - When you edit a previously created service component, the configuration wizard displays the status of the service component.
Name - The name of the service component. This name must be unique.
Startup Mode - Select Automatic, Manual, or On-Demand as the startup mode for the service component.
Container Type - The container type to which this service component belongs. In Oracle Applications, the container type is always Oracle Applications Generic Service Management (Oracle Applications GSM).
Inbound Agent - The Business Event System agent that you want to monitor for inbound event messages.
Outbound Agent - Leave this field blank. Java agent listener service components do not use an outbound agent.
Correlation ID - Optionally specify the Oracle Advanced Queuing (AQ) correlation ID of the event messages that you want the Java agent listener to process. The AQ correlation ID for an event message in the Business Event System is usually specified in the following format:
<event name>
Consequently, by specifying a correlation ID in this attribute, you can dedicate the Java agent listener to listen only for messages that are instances of the specified event. You can also specify a partial value to listen for messages that are instances of any event whose name begins with the specified value.
The seeded Java agent listeners do not have any correlation ID specified so that they can process all event messages on their respective agents.
Note: The AQ correlation ID is different than the correlation ID contained within the WF_EVENT_T event message structure.
To cancel the configuration without saving any changes, click the Cancel button.
To save these settings and proceed to the next step of the configuration wizard, click the Next button.
This page lets you define detail attributes for the service component. You must set attributes marked with an asterisk (*) to appropriate values for your environment before you can run the service component. A refresh icon identifies attributes that can be refreshed dynamically while the service component is running.
ID - When you edit a previously created service component, the configuration wizard displays the identifier for the service component.
Status - When you edit a previously created service component, the configuration wizard displays the status of the service component.
Name - The configuration wizard displays the name defined for the service component.
Container - The container to which the service component will belong. Oracle Workflow provides a container called Workflow Agent Listener Service for Java agent listener service components.
Maximum Idle Time - If you selected the On-Demand startup mode for the service component, enter the maximum time in minutes that the service component can remain idle before it is stopped. An on-demand component that is stopped in this way will be restarted by its container when it is needed again to process new messages.
Max Error Count - The number of consecutive errors the service component can encounter before its container stops it and changes its status to Stopped with Error. If an error is resolved and processing can continue, the error count is reset. The default value for the maximum error count is 10.
Inbound Thread Count - Set the inbound processing thread count to 1 (one) to enable inbound message processing with this Java agent listener. Select 0 (zero) to disable this Java agent listener. The default value is 1.
Outbound Thread Count - Leave this parameter set to the default value of 0 (zero). Java agent listener service components do not perform outbound message processing.
Log Level - Select the level of detail for the information you want to record in the service component container log. The recommended log level, which is also the default value, is Error. Usually the log level only needs to be changed if you want to record additional detailed information for debugging purposes. You can choose the following levels:
1 - Statement
2 - Procedure
3 - Event
4 - Exception
5 - Error
6 - Unexpected
Processor Read Wait Timeout - Specify the amount of time in seconds that the service component's processing thread continues to wait, after reading the last message from its assigned queue, before timing out. If another message is received before this time expires, that message is processed and the timeout period begins again. If the timeout period expires and no more messages have been received, the service component stops reading and its sleep time begins. The default read timeout period for a Java agent listener is 10 seconds.
Processor Min Loop Sleep - Specify the minimum sleep time in seconds during which the service component waits, after its read timeout period expires, before it checks its queue for messages again. The default minimum sleep time for a Java agent listener is 5 seconds.
Processor Max Loop Sleep - Specify the maximum sleep time in seconds if you want to increase the sleep time between read attempts when no messages are received. If you specify a maximum sleep time that is greater than the minimum sleep time, then the service component initially waits for the minimum sleep time after it finishes reading messages from its queue. If no messages are read in subsequent attempts, then the sleep time between read attempts gradually increases until the maximum sleep time is reached. Increasing the sleep time can help enhance performance if messages are received infrequently. You can also specify 0 (zero) for this parameter to indicate that the sleep time should not be increased. In this case, the service component always waits for the minimum sleep time between read attempts. The default maximum sleep time for a Java agent listener is 60 seconds.
Processor Error Loop Sleep - Specify the sleep time in seconds during which the service component waits, after an error occurs, before it attempts to begin processing again. The default error sleep time for a Java agent listener is 60 seconds.
Processor Close on Read Timeout - Select this parameter to specify that the service component should close its connections after its read timeout period expires, when its sleep time begins. Deselect this parameter to specify that the connections should remain open until the processing thread stops.
To cancel any changes on this page, click the Cancel button.
To return to the previous step of the configuration wizard, click the Back button.
To save these settings and proceed to the next step of the configuration wizard, click the Next button.
To save these settings and proceed to the last step of the configuration wizard, click the Finish button.
This page lets you schedule events to control the running of the service component. The events are raised at the scheduled time by DBMS jobs. For a Java agent listener service component, you can schedule the following events:
Start
Refresh
Suspend
Resume
Stop
For each event, the list displays the event name, date and time when the event is first scheduled to be raised, the interval in minutes at which the event is reraised, and, for a refresh event, any parameters to be refreshed. You can specify the following refreshable parameters, using the parameters' internal names, when you refresh the Java agent listener.
PROCESSOR_IN_THREAD_COUNT - Inbound Thread Count
COMPONENT_LOG_LEVEL - Log Level, specified as a numerical value
1 - Statement
2 - Procedure
3 - Event
4 - Exception
5 - Error
6 - Unexpected
To schedule events:
If no events are currently scheduled, click the Add a Row button to add a new row to the list of events and enter the information for the event.
Select the event for the command you want to schedule. Oracle Workflow provides events to let you start, stop, refresh, suspend, or resume the service component.
Select the date when you want the event to be raised first.
Select the hour and minute to specify the time on the specified date when you want the event to be raised first. The hour values are in a twenty-four hour format. For example, select 00 for midnight, or 23 for 11 PM.
If you want to raise the event periodically, enter the time interval in minutes at which you want to raise the event. If you do not specify a repeating interval, the event is raised only once.
If you choose the refresh event, you can optionally enter any parameters you want to include with the event in order to refresh the Java agent listener configuration parameters with those values when the event is raised. Specify the parameter names and values in the following format, separating the parameters with a colon (:): internal_parameter_name=parameter_value
For example: PROCESSOR_IN_THREAD_COUNT=1
To schedule another event, click the Add Another Row button and enter the information for the event.
To remove an event, select the event and click the Remove button.
To cancel any changes on this page, click the Cancel button.
To return to the previous step of the configuration wizard, click the Back button.
To save these settings and proceed to the next step of the configuration wizard, click the Next button.
To save these settings and proceed to the last step of the configuration wizard, click the Finish button.
Note: The configuration wizard verifies that an event is specified for every row in the list when you click the Next or Finish button. If you do not want to schedule another event, you should remove any empty rows before proceeding.
This page lets you review the configuration parameter values that you set and the events that you scheduled for this service component.
If you want to change any of these settings, return to the appropriate step in the configuration wizard to make your changes. To return to the previous step, click the Back button.
To save these settings and finish the configuration, click the Finish button.
You can use Web services in Oracle Workflow to initiate outbound Web service requests and to accept inbound Web service requests.
When Web service messages are dequeued by the Oracle E-Business Suite, they are transmitted by the Web service outbound component.
The Web services outbound program is defined as a service component type in the Generic Service Component Framework. This framework helps to simplify and automate the management of background Java services.
Oracle Workflow provides a seeded Web services outbound component named Web Services OUT Agent to process messages on the standard WF_WS_JMS_OUT queue, which is a Business Event System agent. This service component must be started manually. You can optionally update its configuration if necessary.
You can also optionally create additional Web services outbound components. For example, you can configure a Web services outbound component that only processes messages on a particular agent or queue.
If you create custom Web services outbound components, you can either assign them to the seeded container for Web services outbound components, named Workflow Document Web Services Service, or, based on the volume to be handled by the seeded container, you can also choose to create your own custom containers.
Before the seeded Web services outbound component can run, the Workflow Document Web Services Service container which manages it must be first be started. You should ensure that this container is running. If you create your own custom containers for custom service components, ensure that those containers are running as well. Use the Service Instances page to start each container as a service instance in Generic Service Management (GSM).
Note: Inbound Web service messages are processed by a seeded service component of type Java agent listener, named Workflow Web Services In.
The Web services outbound configuration wizard lets you configure a Web services outbound service component by defining general and detail attributes and scheduling control events. You can use the configuration wizard to configure a new Web services outbound service component, or to edit the configuration of an existing Web services outbound service component.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon > (B) Create > (B) Continue
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon > (B) Edit
This page lets you define general attributes for the service component. Some attributes are already set to required values and cannot be modified. You must set attributes marked with an asterisk (*) to appropriate values for your environment before you can run the service component.
ID - When you edit a previously created service component, the configuration wizard displays the identifier for the service component.
Status - When you edit a previously created service component, the configuration wizard displays the status of the service component.
Name - The name of the service component. This name must be unique.
Startup Mode - Select Automatic, Manual, or On-Demand as the startup mode for the service component.
Container Type - The container type to which this service component belongs. In Oracle Applications, the container type is always Oracle Applications Generic Service Management (Oracle Applications GSM).
Inbound Agent - Leave this field blank. Web services outbound components do not use an inbound agent.
Outbound Agent - The agent/queue that you want to monitor for outbound Web services messages.
To cancel the configuration without saving any changes, click the Cancel button.
To save these settings and proceed to the next step of the configuration wizard, click the Next button.
This page lets you define detail attributes for the service component. You must set attributes marked with an asterisk (*) to appropriate values for your environment before you can run the service component. A refresh icon identifies attributes that can be refreshed dynamically while the service component is running.
ID - When you edit a previously created service component, the configuration wizard displays the identifier for the service component.
Status - When you edit a previously created service component, the configuration wizard displays the status of the service component.
Name - The configuration wizard displays the name defined for the service component.
Container - The container to which the service component will belong. Oracle Workflow provides a container called Workflow Document Web Services Service for Web services outbound components.
Maximum Idle Time - If you selected the On-Demand startup mode for the service component, enter the maximum time in minutes that the service component can remain idle before it is stopped. An on-demand component that is stopped in this way will be restarted by its container when it is needed again to process new messages.
Max Error Count - The number of consecutive errors the service component can encounter before its container stops it and changes its status to Stopped with Error. If an error is resolved and processing can continue, the error count is reset. The default value for the maximum error count is 10.
Inbound Thread Count - Leave this parameter set to the default value of 0 (zero). Web services outbound components do not perform inbound message processing.
Outbound Thread Count - Specify the number of outbound processing threads you want to execute simultaneously with this Web services outbound component, depending on the volume of outbound messages you need to send. Specify 0 (zero) to disable this Web services outbound component. The default value is 1 (one).
Log Level - Select the level of detail for the information you want to record in the service component container log. The recommended log level, which is also the default value, is Error. Usually the log level only needs to be changed if you want to record additional detailed information for debugging purposes. You can choose the following levels:
1 - Statement
2 - Procedure
3 - Event
4 - Exception
5 - Error
6 - Unexpected
Processor Read Wait Timeout - Specify the amount of time in seconds that the service component's processing threads continue to wait, after reading the last message from the assigned queue, before timing out. If another message is received before this time expires, that message is processed and the timeout period begins again. If the timeout period expires and no more messages have been received, the service component stops reading and its sleep time begins. The default read timeout period for a Web services outbound component is 10 seconds.
Processor Min Loop Sleep - Specify the minimum sleep time in seconds during which the service component waits, after its read timeout period expires, before it checks its queue for messages again. The default minimum sleep time for a Web services outbound component is 5 seconds.
Processor Max Loop Sleep - Specify the maximum sleep time in seconds if you want to increase the sleep time between read attempts when no messages are received. If you specify a maximum sleep time that is greater than the minimum sleep time, then the service component initially waits for the minimum sleep time after it finishes reading messages from its queue. If no messages are read in subsequent attempts, then the sleep time between read attempts gradually increases until the maximum sleep time is reached. Increasing the sleep time can help enhance performance if messages are received infrequently. You can also specify 0 (zero) for this parameter to indicate that the sleep time should not be increased. In this case, the service component always waits for the minimum sleep time between read attempts. The default maximum sleep time for a Web services outbound component is 60 seconds.
Processor Error Loop Sleep - Specify the sleep time in seconds during which the service component waits, after an error occurs, before it attempts to begin processing again. The default error sleep time for a Web services outbound component is 60 seconds.
Processor Close on Read Timeout - Select this parameter to specify that the service component should close its connections after its read timeout period expires, when its sleep time begins. Deselect this parameter to specify that the connections should remain open until the processing thread stops.
To cancel any changes on this page, click the Cancel button.
To return to the previous step of the configuration wizard, click the Back button.
To save these settings and proceed to the next step of the configuration wizard, click the Next button.
To save these settings and proceed to the last step of the configuration wizard, click the Finish button.
This page lets you schedule events to control the running of the service component. The events are raised at the scheduled time by DBMS jobs. For a Web services outbound component, you can schedule the following events:
Start
Refresh
Suspend
Resume
Stop
For each event, the list displays the event name, date and time when the event is first scheduled to be raised, the interval in minutes at which the event is reraised, and, for a refresh event, any parameters to be refreshed. You can specify the following refreshable parameters, using the parameters' internal names, when you refresh the Web services outbound component.
PROCESSOR_OUT_THREAD_COUNT - Outbound Thread Count
COMPONENT_LOG_LEVEL - Log Level, specified as a numerical value
1 - Statement
2 - Procedure
3 - Event
4 - Exception
5 - Error
6 - Unexpected
To schedule events:
If no events are currently scheduled, click the Add a Row button to add a new row to the list of events and enter the information for the event.
Select the event for the command you want to schedule. Oracle Workflow provides events to let you start, stop, refresh, suspend, or resume the service component.
Select the date when you want the event to be raised first.
Select the hour and minute to specify the time on the specified date when you want the event to be raised first. The hour values are in a twenty-four hour format. For example, select 00 for midnight, or 23 for 11 PM.
If you want to raise the event periodically, enter the time interval in minutes at which you want to raise the event. If you do not specify a repeating interval, the event is raised only once.
If you choose the refresh event, you can optionally enter any parameters you want to include with the event in order to refresh the Web services outbound configuration parameters with those values when the event is raised. Specify the parameter names and values in the following format, separating the parameters with a colon (:): internal_parameter_name=parameter_value
For example: PROCESSOR_OUT_THREAD_COUNT=3
To schedule another event, click the Add Another Row button and enter the information for the event.
To remove an event, select the event and click the Remove button.
To cancel any changes on this page, click the Cancel button.
To return to the previous step of the configuration wizard, click the Back button.
To save these settings and proceed to the next step of the configuration wizard, click the Next button.
To save these settings and proceed to the last step of the configuration wizard, click the Finish button.
Note: The configuration wizard verifies that an event is specified for every row in the list when you click the Next or Finish button. If you do not want to schedule another event, you should remove any empty rows before proceeding.
This page lets you review the configuration parameter values that you set and the events that you scheduled for this service component.
If you want to change any of these settings, return to the appropriate step in the configuration wizard to make your changes. To return to the previous step, click the Back button.
To save these settings and finish the configuration, click the Finish button.
Background engine processes serve three purposes in Oracle Workflow: to handle activities deferred by the Workflow Engine, to handle timed out notification activities, and to handle stuck processes.
When the Workflow Engine initiates and performs a process, it completes all necessary activities before continuing to the next eligible activity. In some cases, an activity can require a large amount of processing resource or time to complete. Oracle Workflow lets you manage the load on the Workflow Engine by setting up supplemental engines to run these costly activities as background tasks. In these cases, the costly activity is deferred by the Workflow Engine and run later by a background engine. The main Workflow Engine can then continue to the next available activity, which may occur on some other parallel branch of the process.
A background engine must also be set up to handle timed out notification activities. When the Workflow Engine comes across a notification activity that requires a response, it calls the Notification System to send the notification to the appropriate performer, and then sets the notification activity to a status of 'NOTIFIED' until the performer completes the notification activity. Meanwhile, a background engine set up to handle timed out activities periodically checks for 'NOTIFIED' activities and whether these activities have time out values specified. If a 'NOTIFIED' activity does have a time out value, and the current date and time exceeds that time out value, the background engine marks that activity as timed out and calls the Workflow Engine. The Workflow Engine then resumes by trying to execute a <timeout> transition activity.
Additionally, a background engine must be set up to handle stuck processes. A process is identified as stuck when it has a status of ACTIVE, but cannot progress any further. For example, a process could become stuck in the following situations:
A thread within a process leads to an activity that is not defined as an End activity but has no other activity modeled after it, and no other activity is active.
A process with only one thread loops back, but the pivot activity of the loop has the On Revisit property set to Ignore.
An activity returns a result for which no eligible transition exists. For instance, if the function for a function activity returns an unexpected result value, and no default transition is modeled after that activity, the process cannot continue.
The background engine sets the status of a stuck process to ERROR:#STUCK and executes the error process defined for it.
You can define and start up as many background engines as you like to check for deferred and timed out activities.
Background engines can be restricted to handle activities associated with specific item types, and within specific cost ranges. A background engine runs until it completes all eligible activities at the time it was initiated. Generally, you should set the background engine up to run periodically.
Ensure that you have at least one background engine that can check for timed out activities, one that can process deferred activities, and one that can handle stuck processes. At a minimum, you need to set up one background engine that can handle both timed out and deferred activities as well as stuck processes. Generally, you should run a separate background engine to check for stuck processes at less frequent intervals than the background engine that you run for deferred activities, normally not more often than once a day. Run the background engine to check for stuck processes when the load on the system is low.
You run a background engine by submitting the Workflow Background Process concurrent program (FNDWFBG). When you start a new background engine, you can restrict the engine to handle activities associated with specific item types, and within specific cost ranges. You can submit the Workflow Background Process concurrent program several times to schedule different background engines to run at different times.
To submit a request for the Workflow Background Process concurrent program through Oracle Self-Service Web Applications, choose Background Engines from the Submit Request For pull-down menu in the Workflow System status page and click the Go button.
To view Workflow Background Process concurrent requests, click the Background Engines status icon in the Workflow System status page.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go
When you submit the Workflow Background Process concurrent program, specify the following parameters.
Item Type - Specify an item type to restrict this engine to activities associated with that item type. If you do not specify an item type, the engine processes any activity regardless of its item type.
Minimum Threshold - Specify the minimum cost that an activity must have for this background engine to execute it, in hundredths of a second.
Maximum Threshold - Specify the maximum cost that an activity can have for this background engine to execute it, in hundredths of a second. By using Minimum Threshold and Maximum Threshold you can create multiple background engines to handle very specific types of activities. The default values for these arguments are 0 and 100 so that the background engine runs activities regardless of cost.
Process Deferred - Specify whether this background engine checks for deferred activities. Setting this parameter to Yes allows the engine to check for deferred activities.
Process Timeout - Specify whether this background engine checks for activities that have timed out. Setting this parameter to Yes allows the engine to check for timed out activities.
Process Stuck - Specify whether this background engine checks for stuck processes. Setting this parameter to Yes allows the engine to check for stuck processes.
Note: Make sure you have a least one background engine that can check for timed out activities, one that can process deferred activities, and one that can handle stuck processes. At a minimum, you need to set up one background engine that can handle both timed out and deferred activities as well as stuck processes.
When you view the Workflow Background Process concurrent requests, the Search Results page shows standard request detail information for these requests. For each request, the list displays the request ID, program short name, description, application short name, phase, status, requester, duration, wait time, and submission date. Click a column heading to sort the list by that column.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Background Engines status icon
To show the details for a request if they are hidden, click the Show link in the Details column. Oracle Applications Manager displays details about the request depending on the status of the request. You can also perform actions, such as placing a hold on a request, canceling a request, viewing diagnostic information, viewing manager details, viewing logs, or viewing request output, by clicking the corresponding button. The actions that are available depend on the status of the request.
To hide the details for a request if they are shown, click the Hide link in the Details column.
To search for concurrent requests with different criteria, click the New Search button or click one of the Quick Search links.
To modify the search criteria from this search, click the Modify Search button.
To add the information from this page to your support cart, click the Add to Support Cart button.
The Oracle Applications Manager console helps you easily maintain the Oracle Workflow and Oracle XML Gateway database tables. Oracle Workflow and Oracle XML Gateway access several tables that can grow quite large with obsolete workflow information that is stored for all completed workflow processes, as well as obsolete information for XML transactions. The size of these tables and indexes can adversely affect performance. These tables should be purged on a regular basis, using the Purge Obsolete Workflow Runtime Data concurrent program.
This program purges obsolete runtime information associated with work items, including status information and any associated notifications and Oracle XML Gateway transactions. By default, it also purges obsolete design information, such as activities that are no longer in use and expired users and roles, and obsolete runtime information not associated with work items, such as notifications or Oracle XML Gateway transactions that were not handled through a workflow process. You can optionally choose to purge only core runtime information associated with work items for performance gain during periods of high activity, and purge all obsolete information as part of your routine maintenance during periods of low activity.
Note: You can also use the Purge Obsolete ECX Data concurrent program to purge Oracle XML Gateway transactions according to Oracle XML Gateway-specific parameters. See: Purge Obsolete ECX Data Concurrent Program, Oracle XML Gateway User's Guide.
The Workflow Purge page shows summary information about the next scheduled and last completed purge requests and about completed work items.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Purge status icon
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Related Links > Throughput > Work Items
To view work items with a different status, choose the status you want from the View pull-down menu and click the Go button. You can view items with the following statuses:
Completed Work Items
Active Work Items
Deferred Work Items
Suspended Work Items
Errored Work Items
This region displays summary information about the next scheduled and last completed Purge Obsolete Workflow Runtime Data concurrent requests.
To show information in this region if it is hidden, click the Show link.
To hide information in this region if it is shown, click the Hide link.
For the next scheduled Purge Obsolete Workflow Runtime Data concurrent request, Oracle Workflow Manager displays the request ID, requestor, status, requested start time, wait time, and parameters.
For the last completed Purge Obsolete Workflow Runtime Data concurrent request, Oracle Workflow Manager displays the request ID, requestor, status, completed time, duration, and parameters.
To view the log file for the request, click the Request Log link.
This region displays the distribution of completed work items across different item types.
To show information in this region if it is hidden, click the Show link
To hide information in this region if it is shown, click the Hide link.
This region displays the date and time when the work item statistics were last updated. To refresh this information, click the refresh icon. See: Gathering Oracle Workflow Statistics.
For each work item type in the Completed Work Items list, Oracle Workflow Manager displays the work item type name, the persistence type, the retention period in days, the number of completed work items of that type, and the number of items of that type that are available for purging. Click any column heading to sort the list by that column.
To filter the item types displayed in the list, select an item type property and an operator from the Filter pull-down menus, enter a filter value in the text field, and click the Go button. You can filter by the following properties:
Work item type display name
Work item type internal name
Persistence type
Retention period
Number of completed work items of this type
Number of items of this type available for purging
To view details for work items of a particular item type, either click the item type link in the Work Item Type column, or select the item type and click the View Details button.
You perform purging by submitting the Purge Obsolete Workflow Runtime Data concurrent program (FNDWFPR). You can enter restrictions to specify the data that you want to purge.
To submit a request for the Purge Obsolete Workflow Runtime Data concurrent program through Oracle Self-Service Web Applications, either click the Purge button in the Completed Work Items region of the Workflow Purge page, or choose Purge from the Submit Request For pull-down menu in the Workflow System status page and click the Go button.
To view Purge Obsolete Workflow Runtime Data concurrent requests, click the View Purge Requests button in the Completed Work Items region of the Workflow Purge page.
When you submit the Purge Obsolete Workflow Runtime Data concurrent program, specify the following parameters.
Item Type - Specify the item type to purge. Leave this field blank to purge the runtime data for all item types.
Item Key - Specify the item key to purge. The item key is a unique identifier for an item within an item type. Leave this field blank to purge the runtime data for all items of the specified item type.
Age - Specify the minimum age of data to purge, in days, if you are purging items with a Temporary persistence type. The default is 0 days.
Persistence Type - Specify the persistence type of the data you want to purge, either Permanent or Temporary. The default is Temporary.
Core Workflow Only - Enter 'Y' to purge only obsolete runtime data associated with work items, or 'N' to purge all obsolete runtime data as well obsolete design data. The default is 'N'.
Commit Frequency - Enter the number of records to purge before the program commits data. To reduce rollback size and improve performance, set this parameter to commit data after a smaller number of records. The default is 500 records.
Note: After performing a commit, the program resumes purging work items with the next subsequent begin date. In some cases, if additional items have the same begin date as the last item that was purged before a commit, the program may not purge all eligible items. To purge these remaining work items, simply rerun the program.
When you view the Purge Obsolete Workflow Runtime Data concurrent requests, the Search Results page shows standard request detail information for these requests. For each request, the list displays the request ID, program short name, description, application short name, phase, status, requestor, duration, wait time, and submission date. Click a column heading to sort the list by that column.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Purge status icon > (B) View Purge Requests
To show the details for a request if they are hidden, click the Show link in the Details column. Oracle Applications Manager displays details about the request depending on the status of the request. You can also perform actions, such as placing a hold on a request, canceling a request, viewing diagnostic information, viewing manager details, viewing logs, or viewing request output, by clicking the corresponding button. The actions that are available depend on the status of the request.
To hide the details for a request if they are shown, click the Hide link in the Details column.
To search for concurrent requests with different criteria, click the New Search button or click one of the Quick Search links.
To modify the search criteria from this search, click the Modify Search button.
To add the information from this page to your support cart, click the Add to Support Cart button.
This page shows details about completed work items of a particular item type.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Purge status icon > (B) View Details
To view work items with a different status, choose the status you want from the View pull-down menu and click the Go button. You can view items with the following statuses:
Completed Work Items
Active Work Items
Deferred Work Items
Suspended Work Items
Errored Work Items
This region displays the distribution of completed work items that ended at various activity stages within the workflow process. For each activity stage, the list displays the activity internal name and result, and the number of completed work items that ended at that stage. Click any column heading to sort the list by that column.
By default, the list shows completed work items that ended within the last 30 days. To view completed work items that ended within a different period, enter a number of days in the Filter: End Date Within Last _ Days option and click the Go button.
To view details about the work items that ended at a particular activity stage, either click the activity stage link in the Work Item Activity Stage column, or select the activity stage and click the View Details button.
This page shows details about completed work items that ended at a particular activity stage within a particular item type.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Purge status icon > (B) View Details > (B) View Details
To view work items with a different status, choose the status you want from the View pull-down menu and click the Go button. You can view items with the following statuses:
Completed Work Items
Active Work Items
Deferred Work Items
Suspended Work Items
Errored Work Items
Oracle Workflow Manager displays a list of all completed work items of the selected item type that ended at the selected activity stage. By default, the list shows completed work items that ended within the last 30 days. For each work item, the list displays the internal name of the activity at which the work item ended, the activity start date, end date, user assigned to perform the activity, and item key. Click any column heading to sort the list by that column.
To filter the work items displayed in the list, select an activity property from the Filter pull-down menu, enter a filter value in the text field, and click the Go button. You can filter by the following properties:
Internal name of the activity at which the work item ended
Start date within a specified number of days
End date within a specified number of days
User assigned to perform the activity
Item key of the work item
To launch the Workflow Monitor for a work item, select the work item and click the Launch Workflow Monitor button.
Note: If you perform an action in the Workflow Monitor that changes the status of the work item, then you must refresh your Oracle Workflow Manager web page in order to see the updated information.
Oracle Workflow contains a standard Business Event System agent named WF_CONTROL, which is associated with a standard queue that is also named WF_CONTROL. This queue has a payload type of JMS Text message. The WF_CONTROL agent is used for internal processing only, and is not meant for customer use. You should not place custom event messages on this queue.
The Generic Service Component Framework uses WF_CONTROL to handle control events for containers and service components, such as notification mailer or agent listener service components. WF_CONTROL is also used for other Oracle Applications internal processing.
You do not need to schedule propagation for the WF_CONTROL agent, because the middle tier processes that use WF_CONTROL dequeue messages directly from its queue. However, the subscribers to the WF_CONTROL queue need to be cleaned up periodically. A concurrent program named Workflow Control Queue Cleanup is automatically scheduled to perform this cleanup for you.
When a middle tier process for Oracle Applications starts up, it creates a JMS subscriber to the queue. Then, when an event message is placed on the queue, a copy of the event message is created for each subscriber to the queue. If a middle tier process dies, however, the corresponding subscriber remains in the database. For more efficient processing, you should ensure that WF_CONTROL is periodically cleaned up by removing the subscribers for any middle tier processes that are no longer active. The Workflow Control Queue Cleanup concurrent program sends an event named oracle.apps.wf.bes.control.ping to check the status of each subscriber to the WF_CONTROL queue. If the corresponding middle tier process is still alive, it sends back a response. The next time the cleanup program runs, it checks whether responses have been received for each ping event sent during the previous run. If no response was received from a particular subscriber, that subscriber is removed.
The recommended frequency for performing cleanup is every twelve hours. In order to allow enough time for subscribers to respond to the ping event, the minimum wait time between two cleanup runs is thirty minutes. If you run the procedure again less than thirty minutes after the previous run, it will not perform any processing.
You perform Workflow control queue cleanup by submitting the Workflow Control Queue Cleanup concurrent program (FNDWFBES_CONTROL_QUEUE_CLEANUP). This program does not require any parameters. This concurrent program is scheduled to run every twelve hours by default, which is the recommended frequency for performing cleanup. You can optionally submit this program with a different schedule if you want to perform cleanup at a different frequency.
To submit a request for the Workflow Control Queue Cleanup concurrent program through Oracle Self-Service Web Applications, choose Control Queue Cleanup from the Submit Request For pull-down menu in the Workflow System status page and click the Go button.
To view Workflow Control Queue Cleanup concurrent requests, click the Control Queue Cleanup status icon in the Workflow System status page.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go
When you view the Workflow Control Queue Cleanup concurrent requests, the Search Results page shows standard request detail information for these requests. For each request, the list displays the request ID, program short name, description, application short name, phase, status, requester, duration, wait time, and submission date. Click a column heading to sort the list by that column.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Control Queue Cleanup status icon
To show the details for a request if they are hidden, click the Show link in the Details column. Oracle Applications Manager displays details about the request depending on the status of the request. You can also perform actions, such as placing a hold on a request, canceling a request, viewing diagnostic information, viewing manager details, viewing logs, or viewing request output, by clicking the corresponding button. The actions that are available depend on the status of the request.
To hide the details for a request if they are shown, click the Hide link in the Details column.
To search for concurrent requests with different criteria, click the New Search button or click one of the Quick Search links.
To modify the search criteria from this search, click the Modify Search button.
To add the information from this page to your support cart, click the Add to Support Cart button.
The Active Work Items page shows the distribution of active work items across different item types. All work items that do not have an end date are counted as Active work items, including deferred, suspended, and errored work items as well as running work items.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Workflow Metrics > Work Items > Active
To view work items with a different status, choose the status you want from the View pull-down menu and click the Go button. You can view items with the following statuses:
Completed Work Items
Active Work Items
Deferred Work Items
Suspended Work Items
Errored Work Items
The page displays the date and time when the work item statistics were last updated. To refresh this information, click the refresh icon. See: Gathering Oracle Workflow Statistics.
For each work item type, the Active Work Items page displays the work item type name and the number of active work items of that type. Click any column heading to sort the list by that column.
To filter the item types displayed in the list, select an item type property and an operator from the Filter pull-down menus, enter a filter value in the text field, and click the Go button. You can filter by the following properties:
Work item type display name
Work item type internal name
Number of active work items of this type
To view details about active work item activities within a particular item type, either click the item type link in the Work Item Type column, or select the item type and click the View Details button.
This page shows details about active work item activities within a particular item type. Active work item activities include only activities with a status of Active, Waiting, or Notified.
Note: Only activities with a status of Active, Waiting, or Notified are included in this page. Activities with a status of Deferred, Suspended, or Error are not included in this page, although the work items to which they belong are counted as Active work items. You can use the View pull-down menu to view details for activities with a status of Deferred, Suspended, or Error.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Workflow Metrics > Work Items > Active > (B) View Details
To view work items with a different status, choose the status you want from the View pull-down menu and click the Go button. You can view items with the following statuses:
Completed Work Items
Active Work Items
Deferred Work Items
Suspended Work Items
Errored Work Items
This region displays the distribution of active work items that are currently at various activity stages within the workflow process, if the activity has a status of Active, Waiting, or Notified. For each activity stage, the list displays the activity internal name and the number of active work items at that stage. Click any column heading to sort the list by that column.
By default, the list shows active work items that started within the last 30 days. To view active work items that started within a different period, enter a number of days in the Filter: Start Date Within Last _ Days option and click the Go button.
To view details about the work items at a particular activity stage, either click the activity stage link in the Work Item Activity Stage column, or select the activity stage and click the View Details button.
This page shows details about active work item activities of a particular activity stage within a particular item type. Active work item activities include only activities with a status of Active, Waiting, or Notified.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Workflow Metrics > Work Items > Active > (B) View Details > (B) View Details
To view work items with a different status, choose the status you want from the View pull-down menu and click the Go button. You can view items with the following statuses:
Completed Work Items
Active Work Items
Deferred Work Items
Suspended Work Items
Errored Work Items
Oracle Workflow Manager displays a list of all active activities of the selected stage for work items of the selected item type. Active work item activities include only activities with a status of Active, Waiting, or Notified. By default, the list shows active work items that started within the last 30 days. For each activity, the list displays the activity internal name, start date, due date, user assigned to perform the activity, and item key of the work item. Click any column heading to sort the list by that column.
To filter the work items displayed in the list, select an activity property from the Filter pull-down menu, enter a filter value in the text field, and click the Go button. You can filter by the following properties:
Internal name of the active activity
Start date within a specified number of days
Due date within a specified number of days
User assigned to perform the activity
Item key of the work item
To abort all work items in the list, click the Abort All button. If you have filtered the list, only the work items currently displayed in the list are aborted.
To suspend all activities in the list, click the Suspend All button. If you have filtered the list, only the work items currently displayed in the list are suspended.
To abort a single work item, select the activity you want and click the Abort button.
To suspend a single activity, select the activity you want and click the Suspend button.
To launch the Workflow Monitor for a work item, select the activity you want and click the Launch Workflow Monitor button.
Note: If you perform an action in the Workflow Monitor that changes the status of the work item, such as aborting the work item, then you must refresh your Oracle Workflow Manager web page in order to see the updated information.
The Deferred Work Items page shows the distribution of deferred work items across different item types. An abnormal number of activities with a deferred status may indicate that there are not enough background engines available.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Workflow Metrics > Work Items > Deferred
To view work items with a different status, choose the status you want from the View pull-down menu and click the Go button. You can view items with the following statuses:
Completed Work Items
Active Work Items
Deferred Work Items
Suspended Work Items
Errored Work Items
The page displays the date and time when the work item statistics were last updated. To refresh this information, click the refresh icon. See: Gathering Oracle Workflow Statistics.
For each work item type, the Deferred Work Items page displays the work item type name and the number of deferred work items of that type. Click any column heading to sort the list by that column.
To filter the item types displayed in the list, select an item type property and an operator from the Filter pull-down menus, enter a filter value in the text field, and click the Go button. You can filter by the following properties:
Work item type display name
Work item type internal name
Number of deferred work items of this type
To view details for work items of a particular item type, either click the item type link in the Work Item Type column, or select the item type and click the View Details button.
This page shows details about deferred work items of a particular item type.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Workflow Metrics > Work Items > Deferred > (B) View Details
To view work items with a different status, choose the status you want from the View pull-down menu and click the Go button. You can view items with the following statuses:
Completed Work Items
Active Work Items
Deferred Work Items
Suspended Work Items
Errored Work Items
This region displays the distribution of deferred work items that are currently at various activity stages within the workflow process. For each activity stage, the list displays the activity internal name and the number of deferred work items at that stage. Click any column heading to sort the list by that column.
By default, the list shows active work items that started within the last 30 days. To view deferred work items that started within a different period, enter a number of days in the Filter: Start Date Within Last _ Days option and click the Go button.
To view details about the work items at a particular activity stage, either click the activity stage link in the Work Item Activity Stage column, or select the activity stage and click the View Details button.
This page shows details about deferred work items that are currently at a particular activity stage within a particular item type.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Workflow Metrics > Work Items > Deferred > (B) View Details > (B) View Details
To view work items with a different status, choose the status you want from the View pull-down menu and click the Go button. You can view items with the following statuses:
Completed Work Items
Active Work Items
Deferred Work Items
Suspended Work Items
Errored Work Items
Oracle Workflow Manager displays a list of all deferred activities of the selected stage for work items of the selected item type. By default, the list shows deferred work items that started within the last 30 days. For each activity, the list displays the activity internal name, start date, due date, user assigned to perform the activity, and item key of the work item. Click any column heading to sort the list by that column.
To filter the work items displayed in the list, select an activity property from the Filter pull-down menu, enter a filter value in the text field, and click the Go button. You can filter by the following properties:
Internal name of the deferred activity
Start date within a specified number of days
Due date within a specified number of days
User assigned to perform the activity
Item key of the work item
To abort all work items in the list, click the Abort All button. If you have filtered the list, only the work items currently displayed in the list are aborted.
To suspend all activities in the list, click the Suspend All button. If you have filtered the list, only the work items currently displayed in the list are suspended.
To abort a single work item, select the activity you want and click the Abort button.
To suspend a single activity, select the activity you want and click the Suspend button.
To launch the Workflow Monitor for a work item, select the activity you want and click the Launch Workflow Monitor button.
Note: If you perform an action in the Workflow Monitor that changes the status of the work item, such as aborting the work item, then you must refresh your Oracle Workflow Manager web page in order to see the updated information.
The Suspended Work Items page shows the distribution of suspended work items across different item types.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Workflow Metrics > Work Items > Suspended
To view work items with a different status, choose the status you want from the View pull-down menu and click the Go button. You can view items with the following statuses:
Completed Work Items
Active Work Items
Deferred Work Items
Suspended Work Items
Errored Work Items
The page displays the date and time when the work item statistics were last updated. To refresh this information, click the refresh icon. See: Gathering Oracle Workflow Statistics.
For each work item type, the Suspended Work Items page displays the work item type name and the number of suspended work items of that type. Click any column heading to sort the list by that column.
To filter the item types displayed in the list, select an item type property and an operator from the Filter pull-down menus, enter a filter value in the text field, and click the Go button. You can filter by the following properties:
Work item type display name
Work item type internal name
Number of suspended work items of this type
To view details for an item type, either click the item type link in the Work Item Type column, or select the item type and click the View Details button.
This page shows details about all suspended work items of a particular item type.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Workflow Metrics > Work Items > Suspended > (B) View Details
To view work items with a different status, choose the status you want from the View pull-down menu and click the Go button. You can view items with the following statuses:
Completed Work Items
Active Work Items
Deferred Work Items
Suspended Work Items
Errored Work Items
This region displays the distribution of suspended work items that are currently at various activity stages within the workflow process. For each activity stage, the list displays the activity internal name and the number of suspended work items at that stage. Click any column heading to sort the list by that column.
To view suspended work items that started within a specific period, enter a number of days in the Filter: Start Date Within Last _ Days option and click the Go button.
To view details about the work items at a particular activity stage, either click the activity stage link in the Work Item Activity Stage column, or select the activity stage and click the View Details button.
This page shows details about all suspended work items at a particular activity stage within a particular item type.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Workflow Metrics > Work Items > Suspended > (B) View Details > (B) View Details
To view work items with a different status, choose the status you want from the View pull-down menu and click the Go button. You can view items with the following statuses:
Completed Work Items
Active Work Items
Deferred Work Items
Suspended Work Items
Errored Work Items
Oracle Workflow Manager displays a list of all suspended activities of the selected stage for work items of the selected item type. For each activity, the list displays the activity internal name, start date, due date, user assigned to perform the activity, and item key of the work item. Click any column heading to sort the list by that column.
To filter the work items displayed in the list, select an activity property from the Filter pull-down menu, enter a filter value in the text field, and click the Go button. You can filter by the following properties:
Internal name of the suspended activity
Start date within a specified number of days
Due date within a specified number of days
User assigned to perform the activity
Item key of the work item
To abort all work items in the list, click the Abort All button. If you have filtered the list, only the work items currently displayed in the list are aborted.
To resume all activities in the list, click the Resume All button. If you have filtered the list, only the work items currently displayed in the list are resumed.
To abort a single work item, select the activity you want and click the Abort button.
To resume a single activity, select the activity you want and click the Resume button.
To launch the Workflow Monitor for a work item, select the activity you want and click the Launch Workflow Monitor button.
Note: If you perform an action in the Workflow Monitor that changes the status of the work item, such as aborting the work item, then you must refresh your Oracle Workflow Manager web page in order to see the updated information.
The Errored Work Items page shows the distribution of errored work items across different item types.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Workflow Metrics > Work Items > Error
To view work items with a different status, choose the status you want from the View pull-down menu and click the Go button. You can view items with the following statuses:
Completed Work Items
Active Work Items
Deferred Work Items
Suspended Work Items
Errored Work Items
The page displays the date and time when the work item statistics were last updated. To refresh this information, click the refresh icon. See: Gathering Oracle Workflow Statistics.
For each work item type, the Errored Work Items page displays the work item type name and the number of errored work items of that type. Click any column heading to sort the list by that column.
To filter the item types displayed in the list, select an item type property and an operator from the Filter pull-down menus, enter a filter value in the text field, and click the Go button. You can filter by the following properties:
Work item type display name
Work item type internal name
Number of errored work items of this type
To view details for an item type, either click the item type link in the Work Item Type column, or select the item type and click the View Details button.
This page shows details about all errored work items of a particular item type.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Workflow Metrics > Work Items > Error > (B) View Details
To view work items with a different status, choose the status you want from the View pull-down menu and click the Go button. You can view items with the following statuses:
Completed Work Items
Active Work Items
Deferred Work Items
Suspended Work Items
Errored Work Items
This region displays the distribution of errored work items that are currently at various activity stages within the workflow process. For each activity stage, the list displays the activity internal name and the number of errored work items at that stage. Click any column heading to sort the list by that column.
To view errored work items that started within a specific period, enter a number of days in the Filter: Start Date Within Last _ Days option and click the Go button.
To view details about the work items at a particular activity stage, either click the activity stage link in the Work Item Activity Stage column, or select the activity stage and click the View Details button.
This page shows details about all errored work items at a particular activity stage within a particular item type.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Workflow Metrics > Work Items > Error > (B) View Details > (B) View Details
To view work items with a different status, choose the status you want from the View pull-down menu and click the Go button. You can view items with the following statuses:
Completed Work Items
Active Work Items
Deferred Work Items
Suspended Work Items
Errored Work Items
Oracle Workflow Manager displays a list of all errored activities of the selected stage for work items of the selected item type. For each activity, the list displays the activity internal name, start date, due date, user assigned to perform the activity, and item key of the work item. Click any column heading to sort the list by that column.
To filter the work items displayed in the list, select an activity property from the Filter pull-down menu, enter a filter value in the text field, and click the Go button. You can filter by the following properties:
Internal name of the errored activity
Start date within a specified number of days
Due date within a specified number of days
User assigned to perform the activity
Item key of the work item
To abort all work items in the list, click the Abort All button. If you have filtered the list, only the work items currently displayed in the list are aborted.
To retry all activities in the list, click the Retry All button. If you have filtered the list, only the work items currently displayed in the list are retried.
To abort a single work item, select the activity you want and click the Abort button.
To retry a single activity, select the activity you want and click the Retry button.
To launch the Workflow Monitor for a work item, select the activity you want and click the Launch Workflow Monitor button.
Note: If you perform an action in the Workflow Monitor that changes the status of the work item, such as aborting the work item, then you must refresh your Oracle Workflow Manager web page in order to see the updated information.
The Agent Activity page shows the distribution of event messages with different statuses on different Business Event System agents in your instance of Oracle Workflow.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Workflow Metrics > Agent Activity
The page displays the date and time when the agent activity statistics were last updated. To refresh this information, click the refresh icon. See: Gathering Oracle Workflow Statistics.
For each agent, the list displays the agent name as well as the number of event messages on that agent with the following statuses: Ready, Waiting, Processed, Expired, and Undeliverable. Click any column heading to sort the list by that column.
To view queue details for an agent, click the agent link in the Agent column.
To view details about the messages being held on an agent, select the agent and click the Search Agent Entry Details button.
Note: The Agent Activity page displays event messages on the WF_ERROR agent according to their explicitly assigned status on the WF_ERROR queue, unlike the Agent Activity graph in the Workflow System Status page which summarizes all messages on the WF_ERROR agent in an Error status.
If an inbound agent has an abnormally large number of messages with a status of Ready, you may need to check the status of the agent listener processing message for that agent, or create a new agent listener service component for that agent. Similarly, if an outbound agent has an abnormally large number of messages with a status of Ready, you may need to check the status of the propagation schedule for that agent's queue, or schedule propagation if necessary.
The Agent Details page displays the following details for the queue associated with an agent:
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Workflow Metrics > Agent Activity > agent link
Owner - The owner of the queue.
Name - The name of the queue.
Queue Table - The name of the table in which the queue data resides.
Queue ID - The object number of the queue.
Queue Type - The type of the queue.
Maximum Retries - The maximum number of attempts that is allowed when dequeuing a message from the queue.
Retry Delay - The time interval between retry attempts, when dequeuing a message from the queue.
Enqueue Enabled - Whether the queue is enabled for enqueuing.
Dequeue Enabled - Whether the queue is enabled for dequeuing.
Retention - The time interval during which processed messages are retained in the queue.
User Comments - Descriptive comments about the queue.
After reviewing the agent queue details, choose the OK button to return to the Agent Activity page.
The Search Queue page lets you search for messages being held on a particular agent and review details about those messages. This page displays different message details depending on the payload type of the agent's queue.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Workflow Metrics > Agent Activity > (B) Search Agent Entry Details
This page lets you review messages on queues with a payload type of WF_EVENT_T, such as the standard WF_ERROR or WF_DEFERRED queues, or SYS.AQ$_JMS_TEXT_MESSAGE, such as the standard WF_CONTROL queue.
Enter filter criteria to locate the messages you want to review and click the Go button. You can filter by the following message properties:
Internal event name
Event key
Correlation ID used to associate a message with other related messages
Enqueue date either within the last seven days or prior to the last seven days
Dequeue date either within the last seven days, prior to the last seven days, or on any date
Status
Oracle Workflow Manager displays the event messages on the queue for the selected agent that match your filter criteria. For each message, the list displays the event name, event key, correlation ID, event parameters, From System that sent the message, To System that received the message, date the message was sent, error message, error stack, and the message status.
The list also includes any messages on the exception queue associated with the selected queue. Messages are transferred from a user queue to the associated exception queue if Oracle Advanced Queuing cannot retrieve or process them for some reason. For more information, see: Exception Handling, Oracle Application Developer's Guide - Advanced Queuing or Oracle Streams AQ Exception Handling, Oracle Streams Advanced Queuing User's Guide and Reference.
Note: Each queue table contains one default exception queue that is shared by all the user queues in that queue table. When you search for messages on a particular queue, the search result list includes all messages on the associated exception queue as well, regardless of the user queue from which they originated. Consequently, if you create more than one user queue in the same queue table, the search result list may display exception messages that originated from other queues than the queue you selected.
To review the event data for a message as an XML document, choose the message details icon in the View XML column.
Note: The message details icon is disabled if the event data for a message is empty.
To add the information from this page to your support cart, click the Add to Support Cart button.
This page lets you review messages on queues with a payload type of SYSTEM.ECXMSG, including the standard Oracle XML Gateway ECX_INBOUND and ECX_OUTBOUND queues.
Enter filter criteria to locate the messages you want to review and click the Go button. You can filter by the following message properties:
Transaction type
Document number
Party site ID
Correlation ID used to associate a message with other related messages
Enqueue date either within the last seven days or prior to the last seven days
Dequeue date either within the last seven days, prior to the last seven days, or on any date
Status
Oracle Workflow Manager displays the messages on the queue for the selected agent that match your filter criteria. For each message, the list displays the message type, message standard, transaction type and subtype, document number, party ID, party site ID, party type, protocol type, protocol address, first, second, third, fourth, and fifth attributes, and the message status.
To review the XML document for a message, choose the message details icon in the View XML column.
Note: The message details icon is disabled if the XML document for a message is empty.
To add the information from this page to your support cart, click the Add to Support Cart button.
This page lets you review messages on queues with a payload type of SYSTEM.ECX_INENGOBJ, including the standard Oracle XML Gateway ECX_IN_OAG_Q queue.
Enter filter criteria to locate the messages you want to review and click the Go button. You can filter by the following message properties:
Message ID
Correlation ID used to associate a message with other related messages
Enqueue date either within the last seven days or prior to the last seven days
Dequeue date either within the last seven days, prior to the last seven days, or on any date
Status
Oracle Workflow Manager displays the messages on the queue for the selected agent that match your filter criteria. For each message, the list displays the message ID, debug mode, and the message status.
To add the information from this page to your support cart, click the Add to Support Cart button.
You should schedule propagation for your local outbound agents to send event messages to their destinations. You can schedule Oracle Advanced Queueing (AQ) propagation for agents that use the SQLNET protocol by the following methods:
Use the Distributed Database Management feature to manage AQ through Oracle Enterprise Manager. See: Oracle Enterprise Manager Support, Oracle Streams Advanced Queuing User's Guide and Reference.
Run the DBMS_AQADM.Schedule_Propagation API in SQL*Plus. See: DBMS_AQADM, PL/SQL Packages and Types Reference.
If you want to use the standard WF_OUT and WF_JMS_OUT agents or custom agents for event message propagation, ensure that you schedule propagation for those agents. You do not need to schedule propagation for the WF_CONTROL or WF_NOTIFICATION_OUT agents, however, because the middle tier processes that use WF_CONTROL dequeue messages directly from its queue, and a notification mailer sends messages placed on the WF_NOTIFICATION_OUT queue.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Related Links > Configuration > Queue Propagation
Use the Queue Propagation page to review the database initialization parameters required for queue propagation, as well as the existing propagation schedules for Business Event System agents in your instance of Oracle Workflow.
For each parameter, this list shows the parameter name, actual parameter value, recommended value, and description. If the actual value does not match the recommended value, the recommended value is marked with a warning indicator icon. The following parameters are shown:
JOB_QUEUE_PROCESSES - This parameter defines the number of SNP job queue processes for your instance. Oracle Workflow requires job queue processes to handle propagation of Business Event System event messages by AQ queues. The recommended number of processes for Oracle Workflow is ten or more.
AQ_TM_PROCESSES - This parameter enables the time manager process in Oracle Advanced Queuing (AQ). The time manager process is required by Oracle Workflow to monitor delay events in queues, as in the case of the Oracle Workflow standard Wait activity. The recommended number of time manager processes for Oracle Workflow is one or more.
For each propagation schedule, the list displays the outbound queue, destination database link, job queue process executing the schedule, whether the schedule is enabled or disabled, and the error date and error message of the last unsuccessful execution. Click any column heading to sort the list by that column.
If no process is allocated to execute the schedule, you may need to increase the JOB_QUEUE_PROCESSES database initialization parameter to ensure that processes are available for propagation.
To view details for a propagation schedule, either click the queue link in the Queue column, or select the schedule and click the View Details button.
The Queue Propagation Details page displays the following details for a propagation schedule:
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Related Links > Configuration > Queue Propagation > (B) View Details
Destination - The destination database link.
Process Name - The name of the job queue process executing this schedule.
Enabled - Y if this schedule is enabled or N if the schedule is disabled. The schedule will not be executed if it is disabled.
Last Error Date - The date of the last unsuccessful execution.
Last Error Time - The time of the last unsuccessful execution.
Last Error Message - The error message of the last unsuccessful execution.
Schema - The schema that owns the queue.
Session ID - The session ID (SID, SERIAL#) of the job executing this schedule; NULL if not currently executing.
Propagation Window - The duration in seconds of the propagation window.
Maximum Bytes - The maximum number of bytes propagated during a propagation window.
Failures - The number of times that execution of the schedule failed. If the number of failures reaches 16, the schedule will be disabled.
Latency - The latency time in seconds that specifies how long to wait, after all messages have been propagated, before rechecking the queue for new messages to the destination. The latency represents the maximum wait time during the propagation window for a message to be propagated after it is enqueued.
Next Run Date - The date at which the next propagation window of this schedule will be started.
Next Run Time - The time at which the next propagation window of this schedule will be started, in HH:MI:SS format.
Current Start Date - The date at which the current propagation window of this schedule was started.
Current Start Time - The time at which the current propagation window of this schedule was started, in HH:MI:SS format.
Instance - The cluster database instance number executing the schedule.
Start Date - The date when propagation should be started, in the default date format.
Start Time - The time when propagation should be started, in HH:MI:SS format.
Last Run Date - The date of the last successful execution.
Last Run Time - The time of the last successful execution, in HH:MI:SS format.
Total Time - The total time, in seconds, spent by the system in executing this schedule.
Total Number - The total number of messages propagated in this schedule.
Total Bytes - The total number of bytes propagated in this schedule .
Maximum Number - The maximum number of messages propagated during a propagation window.
Average Number - The average number of messages propagated during a propagation window.
Average Size - The average size of a propagated message, in bytes.
Average Time - The average time, in seconds, to propagate a message.
