.NET mobile web service application setup

Before using .NET with QAnywhere, you must make the following changes to your Visual Studio project:

Add references to the QAnywhere .NET DLL and the mobile web services .NET DLL. This tells Visual Studio which DLL to include to find the code for the QAnywhere .NET API and the mobile web services .NET API.
Add lines to your source code to reference the QAnywhere .NET API classes and the mobile web services .NET API classes. To use the QAnywhere .NET API, you must add a line to your source code to reference the data provider. You must add a different line for C# than for Visual Basic.

Add references to the QAnywhere .NET API and mobile web services API in a Visual Studio project

Start Visual Studio and open your project.
In the Solution Explorer window, right-click the References folder and click Add Reference.
On the Browse tab, locate iAnywhere.QAnywhere.Client.dll and iAnywhere.QAnywhere.WS.dll in the following directories:
- .NET Framework 2.0: %SQLANY12%\Assembly\V2
- .NET Compact Framework 2.0: %SQLANY12%\ce\Assembly\V2
From the appropriate directory for your environment, select each DLL and click Open.
To verify that the DLLs are added to your project, expand the References tree in the Solution Explorer. iAnywhere.QAnywhere.Client.dll and iAnywhere.QAnywhere.WS.dll should appear in the list.

Referencing the data provider classes in your source code

Reference the QAnywhere .NET API and mobile web services API classes in your code

Start Visual Studio and open your project.

If you are using C#, add the following lines to the list of using directives at the beginning of your file:

using iAnywhere.QAnywhere.Client;
using iAnywhere.QAnywhere.WS;

If you are using Visual Basic, add the following lines to the list of imports at the beginning of your file:

Imports iAnywhere.QAnywhere.Client
Imports iAnywhere.QAnywhere.WS

The Imports lines are not strictly required. However, they allow you to use short forms for the QAnywhere and mobile web services classes. Without them, you can still use the fully qualified class name in your code. For example, the following code uses the long form:

iAnywhere.QAnywhere.Client.QAManager 
mgr = 
iAnywhere.QAnywhere.Client.QAManagerFactory.Instance.CreateQAManager(
"qa_manager.props" );

The following code uses the short forms:

QAManager mgr = QAManagerFactory.Instance.CreateQAManager(
 "qa_manager.props" );

Initialize QAnywhere and mobile web services for .NET

Include the iAnywhere.QAnywhere.Client and iAnywhere.QAnywhere.WS namespaces, as described in the previous procedure.

using iAnywhere.QAnywhere.Client;
using iAnywhere.QAnywhere.WS;

Create a QAManager object.

For example, to create a default QAManager object, invoke CreateQAManager:

QAManager mgr;
mgr = QAManagerFactory.Instance.CreateQAManager();

Tip

For maximum concurrency benefits, multi-threaded applications should create a QAManager for each thread. See Multi-threading considerations.

For more information about QAManagerFactory, see QAManagerFactory class [QAnywhere .NET].

Alternatively, you can create a QAManager object that is customized using a properties file. The properties file is specified in the CreateQAManager method:

mgr = QAManagerFactory.Instance.CreateQAManager( 
  "qa_mgr.props" );

where qa_mgr.props is the name of the properties file that resides on the remote device.

Initialize the QAManager object. For example:

mgr.Open(
   AcknowledgementMode.EXPLICIT_ACKNOWLEDGEMENT);

The argument to the open method is an acknowledgement mode, which indicates how messages are to be acknowledged. It must be one of IMPLICIT_ACKNOWLEDGEMENT or EXPLICIT_ACKNOWLEDGEMENT.

QAnywhere messages used by mobile web services are not accessible to the mobile web services application. When using a QAManager in EXPLICIT_ACKNOWLEDGEMENT mode, use the Acknowledge method of WSResult to acknowledge the QAnywhere message that contains the result of a web services request. This method indicates that the application has successfully processed the response.

For more information about acknowledgement modes, see:

Note

Instead of creating a QAManager, you can create a QATransactionalManager. See Implementing transactional messaging for .NET clients.

Create an instance of the service binding class.

The mobile web services WSDL compiler generates the service binding class from the WSDL document that defines the web service.

The QAManager is used by the instance of the web service binding class to perform messaging operations in the process of making web service requests. You specify the connector address to use to send web service requests through QAnywhere by setting the property WS_CONNECTOR_ADDRESS of the service binding class. You configure each QAnywhere web service connector with the URL of a web service to connect to, and if an application needs web services located at more than one URL, configure the connector for each URL.

For example:

CurrencyConverterSoap service = new CurrencyConverterSoap( )
service.SetQAManager(mgr);
service.setProperty(
   "WS_CONNECTOR_ADDRESS",
   "ianywhere.connector.currencyconvertor\\");

Note that the final \\ in the address must be included.

Example

To initialize mobile web services, you must create a QAManager and create an instance of the service binding class. For example:

// QAnywhere initialization
  QAManager mgr = QAManagerFactory.Instance.CreateQAManager();
  mgr.SetProperty( "CONNECT_PARAMS", "server=qanywhere;dbf=qanywhere.db;uid=ml_qa_user;pwd=qanywhere" );
  mgr.Open( AcknowledgementMode.IMPLICIT_ACKNOWLEDGEMENT );
  mgr.Start();
  
  // Instantiate the web service proxy
  CurrencyConvertorSoap service = new CurrencyConvertorSoap();
  service.SetQAManager( mgr );
  service.SetProperty( "WS_CONNECTOR_ADDRESS", "ianywhere.connector.currencyconvertor\\" );

The response time for the CurrencyConvertor sample depends on the availability of the web service. Asynchronous web service requests are useful when the mobile web service application is not always available. With this method, a web service request is made by calling a method on the service binding class to place the request in an outgoing queue. The method returns a WSResult, which can be used to query the status of the response at a later time, even after the application has been restarted. See Asynchronous web service requests.

Discuss this page in DocCommentXchange.