The Business Event System is an application service delivered with Oracle Workflow that uses Oracle Advanced Queuing (AQ) to communicate business events between systems. You need to perform this step to use event processing. See: Overview of the Oracle Workflow Business Event System and Managing Business Events.

To set up the Business Event System and enable message propagation, perform the following steps:

1. If you want to communicate business events between the local system and external systems, create database links to those external systems.

2. If you want to use custom queues for propagating events, set up your queues.

3. Check the Business Event System setup parameters.

4. Schedule listeners for local inbound agents.

5. Schedule propagation for local outbound agents.

6. Synchronize event and subscription license statuses with product license statuses.

7. Ensure that the WF_CONTROL queue is periodically cleaned up to remove inactive subscribers.

8. You can optionally change the maximum cache size used in Business Event System subscription processing.

9. You can optionally enable static function calls for custom PL/SQL functions.

10. If you have event subscriptions that invoke business process execution language (BPEL) processes, you can optionally specify the BPEL server.

You should recheck your setup whenever you make changes to your agents that affect the physical implementation required for propagation. See: Agents.

Oracle Workflow provides scripts to help diagnose Business Event System processing and retry failed events. See: Handling Business Event System Errors.

   Creating Database Links:

To propagate event messages between systems, you must create database links from your local system to the remote systems. You should fully qualify the database link name with the domain name.

You can either create database links manually, or use Oracle Enterprise Manager to perform this step. Oracle Enterprise Manager allows workflow administrators to quickly and easily create and administer database links, queue tables, queues, and queue propagation without requiring knowledge of the SQL DDL commands. For more information, see the Oracle Enterprise Manager online help.

You can use the following syntax to create a database link manually:

CREATE DATABASE LINK <database link name> CONNECT TO 
   <user> IDENTIFIED BY <password> USING '<connect string>';

For example:

CREATE DATABASE LINK wf10g.example.com CONNECT TO 
   wfuser IDENTIFIED BY <password> 
   USING 'wf10g';

If you have multiple installations of Oracle Workflow on both the local database and the remote database, and you want to use the same username and password to access both systems, you can omit the CONNECT TO <user> IDENTIFIED BY <password> clause. In this case, the database link uses the username and password of the user who is connected to the database.

CREATE DATABASE LINK <database link name> 
   USING '<connect string>';

If you want to create a public database link available to all users, specify the parameter PUBLIC.

CREATE PUBLIC DATABASE LINK <database link name> CONNECT TO 
   <user> IDENTIFIED BY <password> 
   USING '<connect string>';

To verify the names of your database links, use the following syntax:

SELECT db_link FROM all_db_links;

See: CREATE DATABASE LINK, Oracle Database SQL Language Reference.

   Setting Up Queues:

The Business Event System uses Oracle Advanced Queuing (AQ) to communicate event messages between systems. You must associate a queue with each agent on a Workflow-enabled system that you define in the Event Manager.

When you install Oracle Workflow, several standard queues are created automatically for the standard Workflow agents. These queues all use either the standard WF_EVENT_T structure or JMS Text messages as their payload type. See: Standard Agents, Event Message Structure, and Mapping Between WF_EVENT_T and SYS.AQ$_JMS_TEXT_MESSAGE.

The following table lists the standard queues.

Business Event System Queues

If necessary, you can change the default retention time set for consumed messages on the standard Workflow queues, using the PL/SQL procedure DBMS_AQADM.Alter_Queue. You must not change any other part of the setup of these queues.

You can also set up your own queues for event message propagation. You can either set up queues manually, or use Oracle Enterprise Manager to perform this step. Oracle Enterprise Manager allows workflow administrators to quickly and easily create and administer database links, queue tables, queues, and queue propagation without requiring knowledge of the SQL DDL commands. For more information, see the Oracle Enterprise Manager online help.

To set up a queue manually, you must create the queue table, create the queue, and start the queue. You should perform these tasks using a schema that is appropriate for the application for which you will use the queue. You must specify the schema that owns the queue as part of the queue name when you assign the queue to a Business Event System agent.

• To create a queue table, use the PL/SQL procedure DBMS_AQADM.Create_Queue_Table. Use the following syntax:

  DBMS_AQADM.Create_Queue_Table (
  			queue_table => '<queue table name>',
  			queue_payload_type => '<queue payload type>',
  			sort_list => 'PRIORITY,ENQ_TIME',
  			multiple_consumers => TRUE
  			compatible => '8.1');
  

  For queues that should use the standard Workflow format, specify the queue payload type as WF_EVENT_T. These queues can use the standard queue handler provided with Oracle Workflow, WF_EVENT_QH. For queues that should use the JMS Text message format, specify the queue payload as $AQ_JMS_TEXT_MESSAGE. These queues can use the standard JMS queue handler provided with Oracle Workflow, WF_EVENT_OJMSTEXT_QH. If you define a queue with a different payload type, you must create a queue handler to translate between the standard Workflow format and the format required by the queue. See: Standard APIs for a Queue Handler.

  You can also use the storage_clause parameter to specify the tablespace where you want to create the queue table. You may want to specify a tablespace if you expect a queue to be very large.

• To create a queue, use the PL/SQL procedure DBMS_AQADM.Create_Queue. Use the following syntax:

  DBMS_AQADM.Create_Queue (
  			queue_name => '<queue name>',
  			queue_table => '<queue table name>');
  

  Note: If you want other database users to enqueue messages onto or dequeue messages from your queue, you must grant those users the appropriate privileges using the PL/SQL procedure DBMS_AQADM.Grant_Queue_Privilege.

• To start a queue, use the PL/SQL procedure DBMS_AQADM.Start_Queue. Use the following syntax:

   DBMS_AQADM.Start_Queue (
  			queue_name => '<queue name>');
  

Oracle Workflow provides a sample script called wfevquc2.sql which you can modify to set up your queues, as well as a sample script called wfevqued.sql which you can modify to drop queues. These scripts are located on your server in the $FND_TOP/sql directory.

You can verify that your queues are set up properly using the Oracle Workflow Manager component of Oracle Applications Manager. See: Agents.

You can also run a diagnostic test to verify your queues. See: Oracle Workflow Diagnostic Tests.

See: Oracle Streams AQ Administrative Interface, Oracle Streams Advanced Queuing User's Guide and Reference and DBMS_AQADM, Oracle Database PL/SQL Packages and Types Reference

   Checking the Business Event System Setup:

Use the Oracle Workflow Manager component of Oracle Applications Manager to verify that the required parameters and components have been set up to enable message propagation for the Business Event System, including the required JOB_QUEUE_PROCESSES database initialization parameter. See: Oracle Workflow Manager Overview.

You can either modify the parameter in the init.ora file and restart the database, or you can use the ALTER SYSTEM statement to dynamically modify the parameter for the duration of the instance.

The JOB_QUEUE_PROCESSES parameter defines the number of job queue processes for your instance. Oracle Workflow requires job queue processes to handle propagation of Business Event System event messages by AQ queues. You must start at least one job queue process to enable message propagation. The minimum recommended number of processes for Oracle Workflow is two.

event = "24040 trace name context forever, level 10"

See: Oracle Streams Advanced Queuing User's Guide and Reference.

   Scheduling Listeners for Local Inbound Agents:

To communicate events between different agents, you must schedule listeners for the inbound agents on your local system. The Business Event System requires listeners to be scheduled to receive inbound event messages. 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 in the middle tier.

When you schedule a listener for an agent, it monitors the agent's queue, dequeuing any inbound event messages. When an event message is received, the Event Manager searches for and executes any enabled subscriptions by the local system to that event with a source type of External, and also any enabled subscriptions by the local system to the Any event with a source type of External.

The PL/SQL and Java agent listener programs are defined as service component types in the Generic Service Component Framework. This framework helps to simplify and automate the management of background Java services.

You can use Oracle Workflow Manager to submit and manage agent listener service components. You can also view the distribution of event messages on different agents, drill down to view details about individual event messages, and review queue details for the agents. Oracle Workflow Manager is available as a component of Oracle Applications Manager. See: Oracle Workflow Manager Overview.

Oracle Workflow also provides an administrative script named wfagtlst.sql that you can use to run a PL/SQL agent listener. See Wfagtlst.sql.

Oracle Workflow provides seeded PL/SQL agent listener service components for the standard WF_DEFERRED, WF_ERROR, and WF_NOTIFICATION_IN agents. These agent listeners are named Workflow Deferred Agent Listener, Workflow Deferred Notification Agent Listener, Workflow Error Agent Listener, and Workflow Inbound Notifications Agent Listener, and they support deferred subscription processing in the database, dedicated deferred subscription processing for notification messages, error handling for the Business Event System in the database, and inbound e-mail processing for notification mailers, respectively.

Oracle Workflow also provides seeded Java agent listener service components for the standard WF_JAVA_DEFERRED, WF_JAVA_ERROR, and WF_WS_JMS_IN agents. These agent listeners are named Workflow Java Deferred Agent Listener, Workflow Java Error Agent Listener, and Web Services IN Agent, and they support deferred subscription processing in the middle tier, error handling for the Business Event System in the middle tier, and inbound Web service message processing, respectively.

Additionally, Oracle XML Gateway provides two seeded PL/SQL agent listener service components for the standard ECX_INBOUND and ECX_TRANSACTION agents. These agent listeners are named ECX Inbound Agent Listener and ECX Transaction Agent Listener, respectively. For more information, see Monitor Workflow Processes.

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 service component that only processes messages on a particular agent that are instances of a specific event.

For PL/SQL agent listeners, in addition to the parameters in the configuration wizard, you can optionally set internal agent listener parameters named LISTENER_PROCESS_EVT_COUNT and SQL_TRACE_LEVEL.

• The LISTENER_PROCESS_EVT_COUNT parameter lets you specify the maximum number of event messages that the agent listener can process each time it runs, before returning control to its service component container. Limiting the number of event messages processed in one batch helps to prevent the connection to the database from timing out before the agent listener finishes running. However, increasing the value of this parameter can help improve performance if you need to process large volumes of event messages.

  By default, the LISTENER_PROCESS_EVT_COUNT parameter is set to the value 500. Use the afsvcpup.sql script to change the parameter value to the maximum number of event messages you want to process in one batch. See: To Set Internal Agent Listener Parameters.

  Note: The LISTENER_PROCESS_EVT_COUNT parameter applies only for PL/SQL agent listeners, which process event messages in the database. Java agent listeners always process event messages one at a time in the middle tier, returning control to the service component container after each event message.

• The SQL_TRACE_LEVEL parameter lets you enable SQL tracing at various levels or disable SQL tracing for the agent listener. You can specify the following trace level values:

  • -1 - SQL tracing is disabled

  • 1 - Normal trace, with no binds or waits

  • 4 - Trace with binds

  • 8 - Trace with waits

  • 12 - Trace with binds and waits

  • 10928 - Trace PL/SQL execution

  • 10941 - Trace name context forever

  • 10053 - CBO Enable optimizer trace

  If you enable SQL tracing at a particular level, then the SQL Trace utility generates a trace file at the location specified in the USER_DUMP_DEST parameter as listed in the V$PARAMETER view. The file name for the trace file follows this format:

  <INSTANCE>_ora_<PID>_WFAL_<componentId>_<timestamp>.trc

  For example:

  WF11G_ora_254_WFAL_10002_20100302.trc

  Each time the agent listener processes a set of messages, as specified by the LISTENER_PROCESS_EVT_COUNT parameter, a new trace file is generated, marked by a new timestamp in the file name. You can use the database session ID that is logged in the agent listener's log file to retrieve transaction-specific information from the database and to retrieve messages from the FND_LOG_MESSAGES table. The SQL Trace utility continues generating trace files until you change the parameter value again to disable tracing.

  By default, SQL tracing is disabled, with the SQL_TRACE_LEVEL parameter set to the value -1. Use the afsvcpup.sql script to change the parameter value to the SQL trace level you want to enable. After you change the parameter value, for the new value to take effect, you must either refresh the agent listener service component, stop and restart the agent listener service component, or stop and restart the service component container to which the component belongs. See: To Set Internal Agent Listener Parameters and Service Components.

  For more information about the SQL Trace utility, see your Oracle Database documentation.

  Note: The SQL_TRACE_LEVEL parameter does not apply for queues that are enabled for transactional grouping.

Also, for both PL/SQL and Java agent listeners, in addition to the parameters in the configuration wizard you can optionally set an internal agent listener parameter named NAVIGATION_RESET_THRESHOLD. By default, when an agent listener starts processing messages on an agent's queue, it determines the order in which it will navigate through the waiting messages based on the message priorities, and then does not check for new messages again until it has dequeued all the messages that were initially waiting on the queue. You can use the NAVIGATION_RESET_THRESHOLD parameter to periodically reset the navigation to include newly arrived messages, so that new high priority messages are processed sooner. Specify the threshold value as follows:

• 0 - The agent listener does not reset its navigation until all initially waiting messages have been processed. This option increases performance because the queue is checked less frequently.

• 1 or higher - The agent listener resets its navigation to the FIRST_MESSAGE option after dequeueing the specified number of messages. For example, if you set the threshold value to 1, the agent listener resets its navigation after every message, ensuring that new high priority messages are processed before any lower priority messages that arrived earlier.

By default, the NAVIGATION_RESET_THRESHOLD parameter is set to the value 0. Use the afsvcpup.sql script to change the parameter value to the maximum number of messages the agent listener should dequeue before resetting its navigation. See: To Set Internal Agent Listener Parameters.

For more information about queue navigation options, see: Navigation of Messages in Dequeuing, Oracle Streams Advanced Queuing User's Guide.

Service components must be hosted by a service component container. If you create custom agent listener service components, you can assign them to the seeded container for agent listeners.

A service component container is implemented as a Generic Service Management (GSM) service. The seeded container for agent listeners is named Workflow Agent Listener Service.

Based on the volume to be handled by the seeded container, you can also choose to create your own custom containers as GSM services in Oracle Applications Manager. If you create a custom GSM service in OAM, you can copy the service parameters from the seeded Workflow Agent Listener Service to your new service in order to specify how to run the new service.

Before agent listener service components can run, the container which manages them must first be started. In order to run the seeded agent listeners, you should ensure that the Workflow Agent Listener Service container is running using Oracle Applications Manager. If you create your own custom containers in OAM for custom service components, ensure that those containers are running as well.

See: Agents and Listen.

To Set Internal Agent Listener Parameters

Use the afsvcpup.sql script to set internal agent listener parameters that do not appear in the agent listener configuration wizard. This script is located in the $FND_TOP/sql directory.

1. Use the following command to run the afsvcpup.sql script:

   sqlplus <user> @afsvcpup 
   Enter password: <password>

2. At the prompts, enter the component ID for your agent listener service component, the parameter ID for the parameter to set, and the value to assign to that parameter. You can find the IDs to enter in the lists displayed by the script, which show first the service components defined in your installation of Oracle Workflow and then the parameters defined for the specified service component. You can also find the component ID for an agent listener in the Define page of the configuration wizard.

Exception Handling for Inbound Queues

Oracle Streams Advanced Queuing (AQ) transfers event messages from an agent's normal queue to the associated exception queue in the following cases:

• A message expires before being dequeued.

• An agent listener repeatedly attempts to process a message but rolls back the transaction due to an error, and the number of attempts exceeds the queue's retry limit.

You can run the Move Messages from Exception to Normal Queue of Workflow Agent concurrent program (FNDWF_MOVE_MSGS_EXCEP2NORMAL) to transfer such messages back to the agent's normal queue. This program helps enable mass reprocessing in case of a large number of errors. Use Standard Request Submission to run the program, specifying the inbound agent for which you want to transfer messages back to the normal queue. After the program completes, run the appropriate agent listener to reattempt normal processing for these event messages. See: Running Reports and Programs and Exception Handling, Oracle Streams Advanced Queuing User's Guide and Reference.

   Scheduling Propagation for Local Outbound Agents:

To communicate events between different agents, you must schedule propagation for the outbound agents on your local system. The Business Event System requires propagation to be scheduled to send outbound event messages.

When you send an event message to an agent, the Event Manager places the message on the queue associated with the outbound agent. The message is then asynchronously delivered to the inbound agent by propagation.

You can schedule 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 and the Oracle Enterprise Manager online help.

• Run the DBMS_AQADM.Schedule_Propagation API in SQL*Plus. See: DBMS_AQADM, Oracle Database 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, WF_NOTIFICATION_OUT, or WF_WS_JMS_OUT agents, however. The middle tier processes that use WF_CONTROL dequeue messages directly from its queue, and notification mailers send messages placed on the WF_NOTIFICATION_OUT queue. For WF_WS_JMS_OUT, you can optionally start a Web services outbound component named Web Services OUT Agent, provided by Oracle Workflow.

For agents that use protocols other than the SQLNET protocol, you must provide external propagation logic. See: Agents.

You can use Oracle Workflow Manager to review the propagation schedules for your local outbound agents. You can also view the distribution of event messages on different agents, drill down to view details about individual event messages, and review queue details for the agents. Oracle Workflow Manager is available as a component of Oracle Applications Manager. See: Oracle Workflow Manager Overview.

See: Agents.

   Synchronizing License Statuses:

Some Oracle E-Business Suite products provide seeded events and subscriptions. In these cases, Oracle Workflow executes subscriptions only if the triggering event and the subscription are both owned by products that you have licensed with a status of Installed or Shared.

You can use the License Manager utility to review which products you currently have licensed. See: License Manager.

To ensure that the license status of the seeded events and subscriptions in the Business Event System is updated according to the status of the products you currently have licensed, you can run the Synchronize Product License and Workflow BES License concurrent program. Use the Submit Requests form in Oracle E-Business Suite to submit this concurrent program.

If you upgrade from an Oracle E-Business Suite release earlier than Release 11.5.9, you should run the Synchronize Product License and Workflow BES License concurrent program once after the upgrade to update the license status of the existing events and subscriptions in your Event Manager. Otherwise, subscriptions may not be correctly processed after the upgrade. Subsequently, when you license a product, Oracle Workflow automatically updates the license status for all the events and subscriptions owned by that product.

See: Events and Event Subscriptions.

To submit the Synchronize Product License and Workflow BES License concurrent program

1. Navigate to the Submit Requests form in Oracle E-Business Suite to submit the Synchronize Product License and Workflow BES License concurrent program. When you install and set up Oracle E-Business Suite and Oracle Workflow, your system administrator needs to add this concurrent program to a request security group for the responsibility that you want to run this program from. The executable name for this concurrent program is "Synchronize Product License and Workflow BES License" and its short name is FNDWFLIC. See: Overview of Concurrent Programs and Requests.

2. Select the Synchronize Product License and Workflow BES License concurrent program as the request to run. This program does not require any parameters. See: Running Reports and Programs.

3. When you finish modifying the print and run options to define the schedule for this request, choose Submit to submit the request.

   Cleaning Up the Workflow Control Queue:

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 E-Business Suite 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 E-Business Suite 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 WF_BES_CLEANUP.Cleanup_Subscribers() procedure 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 procedure 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. See: Cleanup_Subscribers.

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.

Control Queue Cleanup

Oracle Workflow provides a concurrent program named Workflow Control Queue Cleanup, which uses the WF_BES_CLEANUP.Cleanup_Subscribers() API to perform the necessary cleanup. This concurrent program is scheduled to run every twelve hours by default, which is the recommended frequency for performing cleanup. You can optionally run this program with a different schedule if you want to perform cleanup at a different frequency.

To submit the Workflow Control Queue Cleanup concurrent program

1. Navigate to the Submit Requests form in Oracle E-Business Suite to submit the Workflow Control Queue Cleanup concurrent program. When you install and set up Oracle E-Business Suite and Oracle Workflow, your system administrator needs to add this concurrent program to a request security group for the responsibility that you want to run this program from. The executable name for this concurrent program is "Workflow Control Queue Cleanup" and its short name is FNDWFBES_CONTROL_QUEUE_CLEANUP. See: Overview of Concurrent Programs and Requests.

2. Select the Workflow Control Queue Cleanup concurrent program as the request to run. This program does not require any parameters. See: Running Reports and Programs.

3. When you finish modifying the print and run options to define the schedule for this request, choose Submit to submit the request.

You can run a diagnostic test to check that the Workflow control queue is properly accessible. See: Oracle Workflow Diagnostic Tests.

See: Business Event System Control Events, Standard Agents, and Business Event System Cleanup API.

   Changing the Maximum Cache Size for the Business Event System:

The Business Event System caches event, subscription, and agent definitions to enhance performance during subscription processing. The default maximum size of the cache is 50 records. You can optionally increase the maximum cache size to reduce the database queries performed by the Business Event System, or decrease the maximum cache size to reduce the amount of memory used by the cache.

The maximum cache size is determined by the value for the WFBES_MAX_CACHE_SIZE resource token. To change this value, you must first create a .msg source file specifying the new size as the value for the WFBES_MAX_CACHE_SIZE resource token. Then use the Workflow Resource Generator program to upload the new seed data from the source file to the database table WF_RESOURCES. See: To Run the Workflow Resource Generator.

   Enabling Static Function Calls for Custom PL/SQL Functions:

If you use custom PL/SQL functions within the Business Event System, including event data generate functions, event subscription rule functions, and queue handler enqueue and dequeue APIs, Oracle Workflow calls those functions using dynamic SQL by default. However, you can enable Oracle Workflow to call your custom functions statically to enhance performance.

Oracle Workflow provides two PL/SQL packages with procedures that contain lists of static function calls. The Business Event System internally calls these procedures during subscription processing to check whether static function calls are available for the procedures being executed.

• WF_BES_DYN_FUNCS package - Contains static function calls for generate functions and rule functions.

• WF_AGT_DYN_FUNCS package - Contains static function calls for queue handler enqueue and dequeue APIs.

The initial seeded versions of these packages include static function calls only for seeded Oracle Workflow functions, such as the rule function WF_RULE.Default_Rule and the queue handler APIs WF_EVENT_QH.Enqueue and WF_EVENT_QH.Dequeue. You can use the wfbesfngen.sql script to add functions from other Oracle E-Business Suite products or your own custom functions to these packages.

1. Run the wfbesfngen.sql script as follows:

   sqlplus <user> @wfbesfngen <type> <name> 
   Enter password: <password>
   

   Replace the variables with your parameters as follows:

   • <type> - The type of functions you want to add.

     • EVENTS - Add generate functions and rule functions to the WF_BES_DYN_FUNCS package body.

     • AGENTS - Add queue handler enqueue and dequeue APIs to the WF_AGT_DYN_FUNCS package body.

   • <name> - Specify the names of the events or agents with which the functions you want to add are associated. You can specify one or more object names separated by commas. Do not include any spaces in the name string. For the EVENTS type, you can either specify a full event name for an individual event, or specify a correlation ID consisting of a partial event name with the wildcard character (%) to include functions associated with any event whose name begins with the specified value.

     Note: The script's output is not cumulative; it creates a separate new package body each time you run it. If you rerun the script, ensure that you specify the event or agent names for all functions that you want to include, repeating any names specified in previous runs that are still applicable, as well as adding any new names.

   For example:

   sqlplus apps @wfbesfngen EVENTS oracle.apps.ap%,oracle.apps.ar% 
   Enter password: <password>
   

   or:

   sqlplus apps @wfbesfngen AGENTS WF_IN,WF_OUT,WF_CONTROL  
   Enter password: <password>
   

2. The script generates a file containing a new package body in the directory specified in the UTL_FILE_DIR database initialization parameter.

   • For the EVENTS type, the script generates a new package body for the WF_BES_DYN_FUNCS package in a file named WFBESDFNB<timestamp>.pls.

   • For the AGENTS type, the script generates a new package body for the WF_AGT_DYN_FUNCS package in a file named WFAGTDFNB<timestamp>.pls.

   Review the file to verify that the package body was generated successfully. The header of the file lists the object names for whose associated functions the package body contains static function calls. Ensure that you keep backup copies of the files containing your customized package bodies.

3. Compile the new package body in your database. You should perform this step during a patching window or maintenance downtime when there is no Business Event System activity and no agent listeners are running.

   If the new package body does not compile successfully, you can edit the generated file manually to correct the package body. Alternatively, if the generated package body does not compile, you can revert back to the corresponding original package body provided by Oracle Workflow in the following files:

   • $FND_TOP/patch/115/sql/WFBESDFNB.pls - Contains the seeded WF_BES_DYN_FUNCS package body.

   • $FND_TOP/patch/115/sql/WFAGTDFNB.pls - Contains the seeded WF_AGT_DYN_FUNCS package body.

If you drop a custom function from your database, you should edit the file containing the corresponding customized package body to comment out the static function call for that function, and then recompile the package body.

   Specifying the BPEL Server:

If you have event subscriptions that invoke business process execution language (BPEL) processes specified by a Web Services Description Language (WSDL) description, you can optionally set the WF: BPEL Server profile option to specify the host name and port of the BPEL server. When this profile option is set, you can use relative URLs rather than absolute URLs in the subscription parameters to specify the location of the WSDL descriptions for the BPEL processes.

At runtime, Oracle Workflow replaces the bpel:// prefix in the relative URLs with the host name and port for the BPEL server specified in the WF: BPEL Server profile option. In this way, the profile option lets you quickly change the BPEL server setup for all subscriptions that invoke BPEL processes, such as if you move these subscription definitions from a test instance to a production instance. See: Invoking a Web Service.

Set the WF: BPEL Server profile option to the host name and port of the BPEL server using the following format:

http://<host_name>:<port>/

This profile option must be set at site level. See: Overview of Setting User Profiles.

   Handling Business Event System Errors:

To check the status of a particular event or help investigate errors, you can run a script named wfbesdbg.sql that displays debugging information. You can also obtain this information by running a diagnostic test through Oracle Diagnostics Framework. See: wfbesdbg.sql and Oracle Workflow Diagnostic Tests.

In case of a large number of errored events, Oracle Workflow provides special scripts for mass event reprocessing. Do not run these scripts unless you are directed to do so by Oracle Support.

The following scripts are located in the $FND_TOP/sql directory.

• wfevrtry.sql - This script lets you abort or retry event subscription processing for all locally raised instances of a particular event that are enqueued on the WF_ERROR or WF_JAVA_ERROR queues and that have not yet been processed by an agent listener for these queues.

  Use the script as follows:

  sqlplus <user> @wfevrtry <APPSuser> <APPSpwd> <FND_schema> <event_name> 
  Enter password: <password>
  

  Replace <APPSuser> and <APPSpwd> with the user name and password for the APPS user. The user name is usually apps. Replace <FND_schema> with the ORACLE username that connects to Oracle Application Object Library data in Oracle E-Business Suite, usually applsys. Replace <event_name> with the internal name of the event whose instances have errors.

  The script prompts you to select one of these actions:

  • Abort - Abort subscription processing by dequeuing each event instance without performing any further processing.

  • Retry with Key - Reraise each event instance with only the event name and event key.

  • Retry with Key & Data - Reraise each event instance with only the event name, event key, and event data.

  • Retry with Key, Data, & Parameters - Reraise each event instance with the event name, event key, event data, and parameters.

  You can choose the level of information to provide to the Event Manager when reraising the event instances. For example, if an error exists in the event data that was originally provided, the event instances can be reraised with only the event name and the event key, forcing the Event Manager to regenerate the event data using the event's generate function. You can also attempt to correct the error before reraising the event instances.

• wfntfrsp.sql - This script lets you abort or retry event subscription processing for all instances of a particular event for which the SYSADMIN user has an open Local Event Error notification from the Default Event Error process. The script responds to the notifications with the option you specify.

  Use the script as follows:

  sqlplus <user> @wfntfrsp <event_name> 
  Enter password: <password>
  

  Replace <event_name> with the internal name of the event whose instances have errors.

  The script prompts you to select one of these actions:

  • Abort - Abort subscription processing by closing the error notification without performing any further processing.

  • Retry with Key - Reraise each event instance with only the event name and event key.

  • Retry with Key & Data - Reraise each event instance with only the event name, event key, and event data.

  • Retry with Key, Data, & Parameters - Reraise each event instance with the event name, event key, event data, and parameters.

  You can choose the level of information to provide to the Event Manager when reraising the event instances. For example, if an error exists in the event data that was originally provided, the event instances can be reraised with only the event name and the event key, forcing the Event Manager to regenerate the event data using the event's generate function. You can also attempt to correct the error before reraising the event instances.