The following considerations apply to using the iSeries™ Access for Web database functions in a Web application server environment. The database considerations can be grouped into these functional categories:
The customize function also provides support for defining data source connections. This support is only available in the WebSphere® application server environment. Version 4 data sources are not supported. If iSeries Access for Web is configured to use basic authentication to prompt for the iSeries user profile and password, these user and password values are also used to authenticate the data source connection. If iSeries Access for Web is running in an SSO environment, the data source must have a component-managed authentication alias configured.
iSeries Access for Web is tested using the IBM Toolbox for Java JDBC driver. Using a different driver might work, but this is an untested and unsupported environment. For a list of the different connection properties that are recognized by the JDBC driver, refer to the IBM Toolbox for Java JDBC properties topic.
Current XML parser implementations do not support validation using the embedded approach. Many parsers, including SAX and DOM implementations, require independent documents for the schema and content to do validation. To achieve schema validation with an XML document produced by Run SQL, the document must be restructured into individual data and schema documents. The root elements must also be updated to support this new structure. Visit the World Wide Web Consortium's Web site for additional information about XML Schema.
The query results portion of the XML document contains the data returned from the query in a structured row and column fashion. This data may be easily processed by other applications. If more information about the data contained in this topic is required, reference can be made to the document schema.
If the HTML rows per table value is set, Run SQL will display the results in a paged list, similar to Preview, instead of returning a single HTML page.
The file in the new format is not compatible with Copy data to table.
Using the output settings, you can customize the selection of fonts used for the various parts of the PDF document. You can embed the chosen fonts into the document, rather than installing them on the computer used to view the document. Embedding fonts in the document increases the document size.
The character encoding used to represent text is also a PDF output option. If the font is not able to represent a character in the encoding, the character is left blank or another indicator character is used to show the character cannot be displayed. You should choose font and character set values which are capable of representing all characters in the data to display.
By default, Run SQL supports the standard PDF fonts and the Adobe Asian fonts for building PDF output. Since the standard fonts are required to be available with any PDF viewer, there is no need to embed them in the PDF document. Adobe provides a set of Asian font packs for displaying text containing Simplified Chinese, Traditional Chinese, Japanese, or Korean characters. Run SQL supports creating documents with these fonts, but it does not support embedding these fonts in the document. If these fonts are used, the appropriate font pack needs to be installed on the computer used to view the document. These font packs can be downloaded from Adobe's Web site.
Additional fonts can be added to the available fonts list, using the "Additional PDF font directories" Customization setting. The supported font types are:
In order for Type 1 fonts to be embedded into a document, the Type 1 font file (*.pfb) needs to be in the same directory as the font metrics file (*.afm). If only the font metrics file is available, the document can be created with the font, but the computer used to view the document needs to have the font installed. Type 1 fonts only support single-byte encoding.
Embedding TrueType fonts and TrueType font collections is optional. When a TrueType font is embedded, only the portions of the font needed to represent the data are embedded. The list of available character set encodings is retrieved from the font file. In addition to the retrieved encodings, the multilingual "Identity-H" encoding can be used. When this encoding is used, the font is always embedded into the document. You can embed TrueType fonts, which support double-byte character sets, as an alternative to the Adobe Asian fonts. This generates a larger document, but the computer used to view it does not need to have the font installed.
Run SQL supports building PDF documents with bi-directional data, if the locale of the current request is Hebrew or Arabic.
Date and time values are stored in date and time format only if the ISO date and time format options are chosen. Otherwise, they are stored as text values.
The second way to create an SQL statement with parameter markers is to manually enter the statement using Run SQL. This option requires the request to be saved. The request cannot be run directly from Run SQL or with the Run link from My Requests. The Run SQL Request (iWADbExec) URL interface must be used to pass values for the parameter markers. One URL parameter must be specified for each parameter marker in the statement. The URL parameters must be named iwaparm_x, where x is the parameter index. iwaparm_1 is used for the first parameter marker, iwaparm_2 is used for the second parameter marker, and so on. For example:
http://server:port/webaccess/iWADbExec?request=promptedRequest&iwaparm_1=Johnson&iwaparm_2=500
One way to invoke the Run SQL Request (iWADbExec) URL interface to pass values for parameter markers is to use an HTML form. Input fields can be used to prompt the user for the values. The names of these fields must follow the URL parameter naming convention mentioned above. The request name can be stored in the form as a hidden parameter. The form action must specify the Run SQL Request (iWADbExec) URI. When the form is submitted, the URL is built with the values specified, iSeries Access for Web is invoked, and the request is executed. Sample HTML source is shown below:
<HTML> <BODY> <FORM action="http://server:port/webaccess/iWADbExec" method="get"> Enter a customer name and press <B>OK</b> to retrieve account information.<br> <input type="text" name="iwaparm_1" value=""/> <input type="submit" name="ok" value=" OK "/> <input type="hidden" name="request" value="promptedRequest"/> </FORM> </BODY> </HTML>
<?xml version="1.0" encoding="utf-8" ?> <QiwaResultSet version="1.0"> <RowSet> <Row number="1"> <Column1 name="FNAME">Jane</Column1> <Column2 name="BALANCE">100.25</Column2> </Row> <Row number="2"> <Column1 name="FNAME">John</Column1> <Column2 name="BALANCE">200.00</Column2> </Row> </RowSet> </QiwaResultSet>
This format consists of the XML directive, followed by the root element QiwaResultSet. If the encoding attribute is not specified in the XML directive, copy data to table will assume the document is encoded in utf-8. The root element contains a version attribute. The version corresponding to this format of XML is 1.0. The RowSet element is a container for all the rows of data that follow. These rows of data are contained within Row elements. Each Row element must have a unique numeric number attribute. Within each Row element is one or more Column elements. Each column element within a row must be unique. This is accomplished by adding a sequential numeric suffix. For example, Column1, Column2, Column3, Columnx, where 'x' is the number of columns in the row. Each column must also have a name attribute. The name corresponds to the column name in the relational table on the system. If this simple format is used, the 'Validate document with its schema' setting must be turned off since the document does not contain a schema.
Although not required, an XML Schema may also be included in the document. Examine an XML document generated by Run SQL to get an idea of how a schema is structured. Also, visit the World Wide Web Consortium's Web site for additional information about XML schemas.
Run SQL can only access and store the SQL statement from the query object; however, query objects can contain more information than the SQL statement. In cases where the query object contains additional information for the query, you might need to use the Customize function to create a new iSeries Access for Web database connection to honor the additional information. Default iSeries Access for Web database connections will run database query requests using SQL naming conventions and using the locale specific defaults for the current user profile. Known special cases requiring the creation of non-default database connections, with additional attributes set, are: