Removing Item Level Privileges

16-2 Oracle Fusion Middleware Developers Guide for Oracle Portal ■ Guaranteed delivery of messages along with exception handling in case messages cannot be delivered. ■ Persistent storage of messages. ■ Message prioritization. ■ Time properties for messages such as expiration and delays. For more information, refer to the Oracle Streams Advanced Queuing page on the Oracle Technology Network OTN: http:www.oracle.comtechnologyproductsaq Actions within a portal through the Oracle Portal user interface, the Web-based Distributed Authoring and Versioning WebDAV protocol, or PLSQL APIs trigger CMEF events. These events cause Oracle Portal to publish CMEF messages to a queue. You can create subscribers to consume the messages on the queue and perform actions based on them. For example, you could create a subscriber to verify that when a user adds an item to a portal page, its display name is less than 80 characters. The subscriber may process events as they occur or process them based on some time interval. There are three major types of CMEF events: ADD, UPDATE, and DELETE. Every content management action falls under one of these events. An event can be in one of several different states. For example, when a user adds an item to a page, the state of the ADD event indicates whether the item is available immediately PUBLISHED or at some later date NOT_PUBLISHED. Refer to Section 16.3, Using the Content Management Event Framework to learn more about how subscribers can use this information to retrieve messages of interest to them. Using the events published by CMEF involves the following five basic queuing operations: ■ Enqueuing Messages: Oracle Portal publishes messages known as enqueuing to the multiconsumer queue named WWSBR_EVENT_Q. Messages to this queue never expire. For more information, refer to Section 16.2.1, Enqueuing Messages . ■ Dequeuing Messages: Subscribing applications pick up messages known as dequeuing from the queue. For more information, refer to Section 16.2.2, Subscribers and Dequeuing Messages . ■ Exception Handling: A message is said to be processed normally if it is consumed within the specified time interval and within the specified number of attempts. Messages not consumed normally are placed in a separate queue called the exception queue. For more information, refer to Section 16.2.3, Exception Handling . ■ Listening for Messages: An application can use LISTEN to wait for messages for multiple subscriptions without having to repeatedly poll the queue. For more information, refer to Section 16.2.4, Listening for Messages . ■ Notifications: This Oracle Streams AQ feature enables users or clients to receive notification of a message of interest. For more information, refer to the Oracle Streams AQ documentation. You use the DBMS_AQ package to perform queuing operations.

16.2.1 Enqueuing Messages

CMEF enqueues messages to the WWSBR_EVENT_Q queue, specifying AQ message properties that subscriber applications can then use at dequeue time Table 16–1 . Using the Content Management Event Framework 16-3 The WWSBR_EVENT_Q queue is a multiconsumer queue. This enables more than one subscriber to consume a single message, allowing for multiple subscribers without having to make multiple copies of each message. Since all messages in the queue have the same priority, this queue works on a first-in first-out basis. Each message that CMEF enqueues to the WWSBR_EVENT_Q queue contains a payload that contains information about the portal object to which the event relates, such as page ID or page group ID. Subscribers can use this payload information to perform actions on the portal object. The contents of the CMEF message payload are described in more detail in Section 16.3.6, CMEF Message Payload . CMEF enqueues messages for immediate consumption, that is, a message is posted on the WWSBR_EVENT_Q queue as soon as an action occurs in the portal; there is no delay. Messages created by CMEF do not have an expiration time.

16.2.2 Subscribers and Dequeuing Messages

On the consuming end, subscribers have various mechanisms to consume the messages produced by CMEF. Subscribers can process messages as they arrive, and thus must wait for the messages to arrive. Alternatively, subscribers can choose to be notified when the messages arrive. These notifications can be Oracle Call Interface OCI callback functions, PLSQL functions, or even e-mails.

16.2.2.1 Adding a Subscriber to the WWSBR_EVENT_Q Queue

For a subscriber to be able to consume messages produced by CMEF, you need to add it to the WWSBR_EVENT_Q queue using the DBMS_AQADM.ADD_SUBSCRIBER procedure and you need to login as the Portal schema user: GRANT EXECUTE ON DBMS_AQADM TO PORTAL_SCHEMA; GRANT Aq_administrator_role TO PORTAL_SCHEMA; Example 16–1 adds the JAY subscriber to the WWSBR_EVENT_Q queue. Example 16–1 Adding a Subscriber to WWSBR_EVENT_Q subscriber := sys.aq_agentJAY, null, null; dbms_aqadm.add_subscriber queue_name = portal.wwsbr_event_q, subscriber = subscriber ; Since Oracle Streams AQ supports a maximum of 1024 subscribers for each multiconsumer queue, you can add up to a maximum of 1024 subscribers to the Table 16–1 AQ Message Properties Set by CMEF Message Property Type Value PRIORITY BINARY_INTEGER 1 DELAY BINARY_INTEGER NO_DELAY EXPIRATION BINARY_INTEGER NEVER CORRELATION VARCHAR2128 NULL RECIPIENT_LIST AQ_RECIPIENT_LIST_T NULL EXCEPTION_QUEUE VARCHAR251 WWSBR_EVENT_ERR_Q ORIGINAL_MSGID RAW16 NULL