Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

New features

Following is a list of additions to QAnywhere introduced in version 10.0.0.

Mobile web services provide support for mobile-optimized asynchronous web services. This allows mobile applications to make web service requests—even when they are offline—and have those requests queued for transmission later. The requests are delivered as messages using QAnywhere. A web services connector on the server side takes the client request and forwards it to the web service. It then takes the response from the web service and returns it to the client as a message. A WSDL compiler is provided that facilitates the use of mobile web services from your .NET or Java application.

See Mobile Web Services.

Sybase Central now includes a QAnywhere plug-in that provides an easy-to-use graphical interface for creating and administering your QAnywhere applications. With the QAnywhere plug-in, you can:

• Create client and server message stores.

• Create and maintain configuration files for the QAnywhere Agent.

• Browse QAnywhere Agent log files.

• Create or modify destination aliases.

• Create JMS connectors and web service connectors.

• Create and maintain transmission rules files.

• Browse message stores remotely.

• Track messages.

Although QAnywhere is not supported on Unix platforms, you can now use Sybase Central on Unix to track messages.

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

The following additions have been made to the QAnywhere client APIs:

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

• Cancelling messages  You can now cancel messages before they are sent.

  See Cancelling 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 Running 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 Addressing QAnywhere messages meant for JMS.

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