ITask Bean Representation

The Native Access bean is implemented as a class with following inheritance, where:

com.attachmate.common.eai.tasks.ScreenNativeAccessEx extends com.attachmate.common.eai.tasks.ScreenNativeAccess com.attachmate.common.eai.tasks.NavTaskBean and implements com.attachmate.common.eai.tasks.INativeAccessEx extends com.attachmate.common.eai.tasks.INativeAccess

and where:

com.attachmate.common.eai.tasks.NavTaskBean extends com.attachmate.common.eai.tasks.BaseTaskBean and

com.attachmate.common.eai.tasks.BaseTaskBean implements com.attachmate.tasks.ITask

Attributes and command constants are provided in a separate interface, com.attachmate.common.eai.tasks.INativeAccessConstants.

Usage

The standard execution sequence for all task beans is to set the input properties, execute, and read the output properties. Some typical operations include:

• Get screen data or refresh screen data: Execute with a zero (CMD_REFRESH_NULL) command.

• Update fields and send command: Execute with a non-zero command, and modified field properties.

Preserving Context

• To use this bean with a new context, simply create a new instance and execute the bean.

• To keep the same session alive between executions, this bean must be configured to preserve its context. Once you have finished with the session, call clearContext( ) to release the session.

• For use with existing sessions, use ITask.transferContext to get the context from another bean that has been configured to preserve its context.

Error Reporting

Java bean execution errors are reported through the TaskStatusChangeEvent.getException method. Returns a TaskException. The message from the returned exception depends on the underlying method that threw the original exception. Error messages are not localized.

Convenience Methods and Usability

Methods that provide values that can be derived from the fundamental methods have been omitted. This specification does not preclude the development of classes that extend or wrap the ScreenNativeAccess class, but this class is intended to include only the essential data access methods.

Asynchronous Devices, Triggers, and Events

All Services Builders currently work on the "set inputs/execute/get outputs" model. The original design was optimized for the HTTP request/response access model. This works well for many applications, but it presents a problem for devices such as screens and printers , which can volunteer data at any time. This problem is mitigated, if some polling of data is accepted. By allowing execute to operate with the CMD_REFRESH_NULL command, a way has been provided to refresh data.

There is one error situation to be aware of: The host screen can change in the time between the last refresh and a user sending a command. Unless you detect this change, the command could be sent to a screen that is completely different from the last refreshed view. You can detect the following changes:

• Screen changes
• End Of Record (EOR) occurs
• Screen shape changes
• Screen type changes

For information about the methods you can implement to detect these changes, see the Javadocs for screen-oriented properties.

Status

Status (sometimes known as OIA) information is handled differently in Services Builder than it would be in a traditional viewer. Most of the traditional OIA status is local to the terminal renderer, and as such is not presented by the connector. The few host-generated status items are handled internally by the connector, and are not relevant to the renderer. There are three exceptions to this rule:

• Pool Name— gives the name of the pool that provides the connection to the host
• Host Message— provides a way for some hosts to send non-screen data to a user
• Errors (exceptions)— returned by the task execute mechanism

	Using Screen Native Access, Overview
	Javadocs for Attachmate Interfaces