New SQL API   The QAnywhere SQL API is a set of SQL stored procedures that allow SQL developers to easily leverage QAnywhere messaging capabilities. Using this API, stored procedures can send or receive messages using a straightforward approach that complements existing database applications. This can allow for powerful applications that combine database and messaging operations in a single transaction. For example, a stored procedure could insert a row into the database and send a message to another application—and have both actions committed as part of the same transaction.

See QAnywhere SQL API reference.

New Java client API   The new QAnywhere client API for Java helps you create messaging client applications in Java. The client API for Java is currently supported on Windows, including Windows CE.

See QAnywhere Java API reference.

Message selectors   You can now use SQL-like expressions to selectively browse or receive messages from a queue. The syntax for creating message selectors is identical to that used for conditions in transmission rules.

See Browsing QAnywhere messages.

New ways to browse messages   You can now browse messages from multiple queues, or browse subsets of messages based on ID or message selector.

See Browsing messages using a selector.

Enumerate message store property names   You can now enumerate message store property names.

See Enumerating client message store properties.

Undeliverable messages   Using the new message store property ias_MaxDeliveryAttempts, you can set the maximum number of attempts that a QAnywhere client will attempt to receive a message before considering it undeliverable.

See Rule variables.

Canceling messages   You can now cancel messages before they are sent.

See Canceling QAnywhere messages.

Query message status   You can now query the status of a message using new pre-defined message properties: ias_Status and ias_StatusTime. You can also query the originator of a message with ias_Originator, or the number of times the message has been delivered to a receiver with ias_DeliveryCount.

See Pre-defined message properties.

New message store property to set upload increments   ias_MaxUploadSize can be used to change the upload increment.

See Pre-defined client message store properties.

Multiple agents on a single device   Previously, you could only run one instance of the QAnywhere Agent on a device. This limitation has been removed.

See Starting the QAnywhere agent.

More options for setting up failover   There are two new QAnywhere Agent options, -fd and -fr, that help you customize the way failover occurs.

See -fd option and -fr option.

Persistent connections   The new option -pc+ has been added to enable persistent connections for message transmission. The new -push option replaces -push_notifications and now allows you to specify whether you want push notifications to use persistent connections.

See:

• -pc option
• -push option

New upgrade procedure   The new -sur option can be used to upgrade a client message store from a previous version of SQL Anywhere.

See -sur option.

QAnywhere Agent now uses ISO 8601 datetime format for message timestamps   Timestamps in informational, warning, and error messages now use the non-ambiguous ISO 8601 datetime format: {I|W|E} yyyy-mm-dd hh:mm:ss message.

Destination aliases   You can now define a destination alias that represents a set of QAnywhere destinations. Messages sent to a destination alias are sent to each member of the alias.

See Destination aliases.

Server management requests   You can now use server management requests for administration and monitoring activities such as creating destination aliases or monitoring, starting, and stopping JMS connectors. You create server management requests on the client and send them to the server message store for processing.

See Server management requests.

Improved maintenance of server transmission rules   You can now change the default server transmission rules and the change will automatically be applied to all clients. Previously, to change the default you had to manually define a transmission rule for each client.

See Server transmission rules.

More message properties   Additional pre-defined message properties are set by QAnywhere, giving you more flexibility in processing messages, better information during debugging, and more help with troubleshooting the status of messages.

See Message properties.

Ability to embed backslashes in JMS destinations   JMS destinations can now include subcontexts that require backslash delimiters.

See Sending a QAnywhere message to a JMS connector.

New transmission rule functions   The following transmission rule functions have been added for improved date handling:

• DATEADD( datepart, count, datetime )
• DATEPART( datepart, date )
• DATETIME( string )
• LENGTH( string )
• SUBSTR( string, start, length )

See Rule functions.

Prefaces for properties in transmission rules   You can now preface message property names and message store property names when you use them in transmission rules and so bypass the precedence given to transmission rule variables of the same name.

See Using properties as rule variables.