Using Host Integrator Connector APIs

Creating client applications that interact with host applications involves:

You can also use filter expressions to fetch records from a recordset.

Modeling your host application using the Design Tool

With the Design Tool, you create a model of the host application. The model consists of a main model file (.model) and several supporting files that are located in the \<VHI install directory>\models\<your model> folder. See the Design Tool Reference for detailed information on how to create models.

Connecting to a Host Integrator Server

To connect to a Host Integrator server, you must decide whether you will connect to a model or session pools. The key difference is that host application models do not connect to and log onto a host until you request the model; sessions are typically already connected to the host and are queued to a particular screen in a host application, thus have superior performance results and is generally recommended. However, your Host Integrator implementation may not use session pools.

There are four methods available to you:

 

Secure connections

You can make sure the connectors communicate with the Host Integrator servers using a secure connection by configuring the server to require a secure connection or having the client request a secure connection by calling the RequireSecureConnection method before establishing a connection.

Interacting with data in the host application

Note:  An application that interacts with VHI models should not mix model-level and table-level methods. This is because the operation definitions in these two model layers make certain assumptions about entity navigation paths and cursor positions. For example, if you issue a model-level method in a table-based model, it can break the table operations because the model subsequently can't locate the table's home entity. Unless you are very familiar with a model, you should avoid mixing procedures with direct model access.


Accessing host data

You can access host data using one of the following approaches:

Using Filter Expressions

Many methods let you specify filter expressions when fetching records from a recordset. The following table illustrates the format for syntax expressions:

Condition Expressions

You can use expressions on both the left and right sides of the condition statement. Be sure to enclose string data in quotation marks.

AND condition_expression AND condition_expression
OR condition_expression OR condition_expression
Not NOT condition_expression
Equal to value_expression = value_expression
Equal to (case insensitive) value_expression =* value_expression
Not equal to value_expression <> value_expression
Less than value_expression < value_expression
Greater than value_expression > value_expression
Less than or equal to value_expression <= value_expression
Greater than or equal to value_expression >= value_expression
( ) (multiple condition_expressions)

Value Expressions

A value expression can take any of the following formats:

Filter Expression Examples

This example returns all recordset fields in the patients recordset that are not "Smith":

patients.lastname <> "Smith"

Here's an example that is exactly equivalent to the first example:

NOT (patients.lastname = "Smith")

This example returns all records in the SearchResults recordset with the field "last name" equal to "Smith" and the field "first name" equal to "Steven":

(SearchResults.LastName = "Smith") and (SearchResults.FirstName = "Steven")

This last example returns all fields in the AccountNumbers recordset greater than or equal to 10000 and less than or equal to 20000:

(AccountNumbers.Accounts >= 10000) and (AccountNumbers.Accounts <= 20000)

 

 

 

  Attachmate