Ordenar Datos

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, Oracle Workflow API Reference and Managing Business Events, Oracle Workflow Developer's Guide.

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, page 2-163.

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

3. Check the Business Event System setup parameters, page 2-168.

4. Schedule listeners for local inbound agents, page 2-168.

5. Schedule propagation for local outbound agents, page 2-173.

6. Synchronize event and subscription license statuses with product license statuses, page 2-174.

7. Ensure that the WF_CONTROL queue is periodically cleaned up to remove inactive subscribers, page 2-175.

8. You can optionally change the maximum cache size used in Business Event System subscription processing, page 2-176.

9. You can optionally enable static function calls for custom PL/SQL functions, page 2-176.

10. If you want to invoke business process execution language (BPEL) processes through event subscriptions, you can optionally specify the BPEL server, page 2-179.

You should recheck your setup whenever you make changes to your agents that affect the physical implementation required for propagation. See: Agents, Oracle Workflow Developer's Guide.

Note: Oracle Workflow sets the status of the local system to Enabled by default. After you finish setting up the Business Event System, you can update your global workflow preferences to set the system status that you want for event processing. See: Setting Global User Preferences, page 2-9.

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

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.mycompany.com CONNECT TO wfuser IDENTIFIED BY welcome

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 <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> CONNECT TO 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 SQL 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, Oracle Workflow Developer's Guide, Event Message Structure, Oracle Workflow API Reference, and Mapping Between WF_EVENT_T and

SYS.AQ$_JMS_TEXT_MESSAGE, Oracle Workflow API Reference.

The following table lists the standard queues.

Business Event System Queues

Queue Table Queue Name Payload Type Retention Time Description

WF_CONTROL WF_CONTROL SYS.AQ$_JMS_

TEXT_MESSAG E

1 day Oracle Workflow internal queue, not for customer use

WF_DEFERRED WF_DEFERRED WF_EVENT_T 1 day Standard queue for deferred subscription processing in the database

Queue Table Queue Name Payload Type Retention Time Description

WF_ERROR WF_ERROR WF_EVENT_T 0 days Standard queue

for error handling in the database

WF_IN WF_IN WF_EVENT_T 7 days Default inbound

queue

1 day Standard queue for deferred

0 days Standard queue for error

7 days Default inbound queue for JMS

WF_OUT WF_OUT WF_EVENT_T 7 days Default

outbound queue

Queue Table Queue Name Payload Type Retention Time Description

WF_WS_JMS_IN WF_WS_JMS_IN SYS.AQ$_JMS_

TEXT_MESSAG E

7 days Default inbound queue for Web

Note: Oracle Workflow also includes three queues named

WF_REPLAY_IN, WF_REPLAY_OUT, and WF_SMTP_O_1_QUEUE, which are not currently used. Oracle XML Gateway provides additional standard queues.

Oracle Workflow includes three queues for background engine processing named WF_DEFERRED_QUEUE_M,

WF_OUTBOUND_QUEUE, and WF_INBOUND_QUEUE. These queues are separate from the Business Event System queues. See:

Setting Up Background Workflow Engines, page 2-39.

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, Oracle Workflow Developer's Guide.

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, page 7-105.

You can also run a diagnostic test to verify your queues. See: Oracle Workflow Diagnostic Tests, page E-1.

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, page 7-1.

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 ten.

Note: If you want to review more detailed information about AQ processing, you can optionally use another initialization parameter, EVENT, for detailed database level tracing of issues related to AQ. Add the following line to your init.ora file:

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

Then restart your database to make this change effective. Be aware that using this parameter may generate large trace files.

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, page 7-1.

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

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, Oracle XML Gateway User's Guide.

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, page 2-172.

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, page 2-172 and Service Components, page 7-7.

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, page 2-172.

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

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

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

In document 1 (página 50-56)