Functions of an Adapter

The adapter manages the communication between the data interface and the data source, passing data management requests to the data source and returning either answer sets or messages to the requestor.

To perform these functions, the adapter:

1. Translates the request to the applicable DML.
2. Attaches to the targeted data source, using standard attachment calls. The adapter then passes the request to the data source.
3. The data source processes the request.
4. The results or error conditions are returned to the client application for further processing.

A server can be configured to behave in different ways upon receipt of SQL requests from a client application. A server handles SQL requests for data in the following ways, as illustrated in the diagram:

• Direct Passthru. When Direct Passthru is enabled, the server passes SQL requests directly to the specified RDBMS for processing. The name of the targeted RDBMS (the database engine) is supplied in the server profile or, in some cases, by the client application. A Full-Function or Hub Server can operate temporarily in Direct Passthru mode when invoked by a client application. The user is responsible for activating and deactivating Direct Passthru as needed.
• SQL Processing. When the database engine is not set in the server profile or supplied by a client application, Direct Passthru is not enabled. Instead, a Hub or Full-Function Server invokes its default behavior: it accepts the incoming SQL request and verifies that it is valid. Then the server determines if it can process the incoming SQL request:
  • If the request meets certain requirements, the server passes it directly to the RDBMS for processing. This is called Automatic Passthru.
  • If the syntax of the request does not conform to the syntax of the RDBMS, the server translates the request into internal DML and passes it to the adapter. The adapter generates adapter-specific DML and passes the request to the RDBMS for processing. This is called SQL translation.

When the server receives a WebFOCUS request, it passes it to the adapter. The adapter analyzes the request and generates DBMS-specific DML for those parts of the request that have DML equivalents. As WebFOCUS is a more robust language than DML, some parts of the request may not have such equivalents. The adapter then passes the generated DML to the DBMS for processing. When the answer set is returned by the DBMS, WebFOCUS processes those parts of the request that the adapter could not pass to the DBMS.

Throughout this manual there are descriptions of some useful features that are not supported by SQL syntax but are supported by WebFOCUS syntax.

For complete information about the WebFOCUS language, see the following manuals:

• Creating Reports With WebFOCUS Language
• Describing Data With WebFOCUS Language
• Developing Reporting Applications

Adapters can retrieve answer sets from both relational and non-relational data sources. Since the architectures of relational and non-relational data structures vary, the relational and non-relational adapters adjust for these differences. For example, relational adapters are designed to handle data sources that contain data in rows and columns in tables, while non-relational adapters are designed to accommodate the architecture of each distinct data source, for instance, a hierarchical or network data source, or a sequential or indexed file system.

The following table lists key features of relational and non-relational adapters:

Relational and non-relational adapters:

• Allow the data source to perform the work required to join, sort, and aggregate data. Therefore, the volume of data source-to-server communication is reduced, resulting in better response times for users. The adapter tries to optimize the queries as best it can.
• Communicate with the data source through DML statements. You can view these DML statements with traces provided by the trace facilities. These traces are helpful for debugging your procedure or for adapter performance analysis. Note that traces:
  • Are common for all relational adapters.
  • Vary for non-relational adapters to accommodate the differences in data structures and DML calls.
• Support both DEFINE (virtual) fields and DBA.
• Relational adapters include a variety of COMMIT, connection, and thread control commands that enable Database Administrators to control the opening and closing of connections and choose when to commit or rollback transactions. This level of transaction control is not supported by non-relational adapters. In Full-Function Server mode, COMMIT/ROLLBACK will be propagated to all relational data sources local to the server. If the hub is active, a COMMIT will be issued against remote data servers as well. All PREPARE handles are cleared (this is a Broadcast COMMIT).

To address these similarities and differences, this manual contains:

• General components with information that is common to all adapters, as well as information that is common either to all relational or to all non-relational adapters.
• Customized components with information that applies to specific adapters.

For the most current and specific information about releases and platforms,

1. Go to http://techsupport.informationbuilders.com.

   The Information Builders Technical Support home page opens.

2. In the Quick Links section on the right side of the page, click Supported Systems/Adapters.

   The Supported Systems and Adapters page opens.

3. Click the link for the server release you want.

   The Supported Systems and Adapters page for that release opens.

4. Click the link for your platform.

   The support chart for that platform opens.

The following table summarizes that information.

* The underlying databases for these adapters do not necessarily run directly on the IBM i platform (formerly known as i5/OS). However, they may be configured and accessed.