Reference › Test Case Reference › Test Step Descriptions › Oracle Steps › Oracle AQ Steps › Oracle AQ (JPUB)

Oracle AQ (JPUB)

Two distinct ways to use AQ are:

• JMS
• JPUB

The Oracle AQ JMS API is a layer that is built on top of a lower-level AQ API. This lower-level API is much more difficult to deal with, and it acts almost nothing like JMS.

The principal distinction is the message format. The low-level AQ messages contain a payload, which can be any type that is defined in the database. The type could be a varchar or a clob, but usually it is a user-defined structured database type. Similar to AQ JMS Queues, each AQ low-level queue can only handle one payload type.

Oracle provides a utility with the name JPUB that can generate the Java objects that can deal with these user-defined structured types. JPUB works in the same way that Axis generates the Java objects that use web services. The low-level AQ step, Oracle AQ JPUB, can automatically use this utility to generate the client classes that are based on the queue information. The user then fills in their payload object using a standard COE.

A distinction between queues or topics does not exist. A client can:

• remove the next message from the AQ queue, making it essentially a queue, or
• read the next message from the AQ queue without removing it, making it essentially a topic.

Setting up the low-level AQ queues is again done through stored procedures. It may be necessary to create a specific user-defined structured type in the database before you create an AQ queue around it. Technically, you can interact with AQ JMS queues using the low-level API. The JMS queues simply have a specific payload type that is structured like a standard JMS message. However, you cannot use the AQ JMS API to interact with low-level AQ queues; that is, queues that do not use a JMS payload type.

To add an Oracle AQ (JPUB) step to a test case, click the step to open its editor.

Four tabs are available at the bottom of the editor.

• The Base tab is where you define your connection and messaging parameters.
• The Condition tab lets you specify a condition to be run.
• The Send Message Data tab is where you create your message content.
• The Response Message tab is where your response messages are posted.

Base Information Tab

The Base tab view that the previous graphic shows is the default view and has the following sections:

• Server Connection Info
• Subscriber Info
• Publisher Info
• Error Handling and Test

The Server Connection Info and Error Handling and Test sections are always active. The Subscriber Info and Publisher Info sections can be enabled or disabled using the enable check box in the top left corner of each section. Using these check boxes, you can configure the step to publish a step, subscribe a step, or both.

When you have configured your test step, click Test in the Error Handling and Test section to test your configuration settings.

Server Connection Info

To simplify changing the application under test, parameterize the values with properties from your configuration. By default, the oracle.jdbc.driver.OracleDriver in the JDBC Driver location is used.

JDBC URL

This field is prepopulated with default values.

JDBC Server

This field is prepopulated with default values.

User

Enter the user name.

Password

Enter the password.

Share Sessions and Share Publishers

To share JMS sessions and publishers throughout the test case, use these check boxes. This approach can lower overhead, but does not always provide a realistic simulation because typically JMS clients want to release resources. If you select the Share Publishers check box, the Share Sessions check box is also selected. You cannot share publishers without sharing sessions. For more detailed information about these parameters, see the Deliberate Delays in VSE knowledge base article.

Stop All

Lets you stop any listeners at design time now. Some listeners can get orphaned, but still consume messages. When they do, it is difficult to create test cases.

Publisher Info

To set up the ability to send (publish) messages, select the enable check box.

Enter the following parameters:

Schema

Enter the name of the schema to use.

Name

Enter the name of the topic or queue to use.

Generate JPub classes

Click to generate the JPub classes.

Payload Class Name

Enter the payload class name.

Advanced button

To open the Publisher Advanced dialog, click Advanced, then enter or select the Correlation and click OK.

Subscriber Info

To set up to enable the ability to receive (subscribe to) messages, select the enable check box.

Enter the following parameters:

Schema

Enter the name of the schema to use.

Name

Enter the name of the topic or queue to use.

Type

Select whether you are using a topic or queue, and whether to listen in synchronous or asynchronous mode. For asynchronous mode, you also must have an entry in the Async key field. To see what messages are waiting to be consumed from a queue (only), click Browse, to the right of this field.

Timeout (secs)

Indicates the number of seconds before DevTest interrupts waiting for a message. For no timeout, leave this field blank.

Async Key

Enter the value that is necessary to identify asynchronous messages. This value is only required in asynchronous mode. This value is used in a subsequent Message Consumer step to retrieve asynchronous messages.

Generate JPub classes

Click to generate the JPub classes.

Payload Class Name

Enter the payload class name.

Advanced

Click to open the Subscriber Advanced dialog.

In the Advanced dialog, you can enter the Consumer Name, Correlation, and Message ID.

Error Handling and Test

If an error occurs, the Error Handling and Test section lets you redirect to a step.

If Environment Error

Specifies the action to take or the step to go to if the test fails because of an environment error.

Default: Abort the test.

Click Test to test your step configuration settings.