About the Original Author

Recent articles by this author

This article is similar to the other article that I created, Create Service Description for REST API, and builds on the basic concepts already provided. The documentation for the Connections Blog API is very helpful in understanding how it works and what parts you would need to implement for use ...

Introduction
The purpose of this guide is to assist Forms Experience Builder customers with installing and configuring a RHEL Linux DB2 Server environment and the Forms Experience Builder database. This endtoend guide will provide steps to effectively setup and configure your DB2 Server and ...

Description

The IBM® Lotus Forms™ “Server” or Application Programmer Interface (API) is a collection of specialized functions that you can use to develop applications that interact with XFDL forms. The API provides a C and Java interface for Windows and UNIX computers, as well as a COM interface for
Windows platforms.

The API is divided into two sections, reflecting two sets of functionality:

The Form Library

The Form Library is a collection of functions that enables you to access and manipulate XFDL forms as structured data types. These functions provide your applications with a means of reading and writing forms, retrieving information contained in graphical form elements, and assigning information to these items.
Once the API loads the form into memory, you can use Java methods (or C functions) to populate the form, retrieve data, duplicate and destroy form elements, extract enclosures, and even verify digital signatures.

The FCI Library

The FCI library is a collection of specialized functions that enables you to develop your own functions. XFDL forms can then access these custom functions, thereby extending the capabilities of the Internet Commerce System, without requiring an upgrade to either your forms software or to the form
description language (XFDL). This allows you to provide custom form functions that you can call from within the form. This is similar to calling system form functions such as set or toggle.

Note: The FCI Library is not available when using the COM interface.

Examples

For Examples of the C, Java, or COM API code please see the API documentation (available in the
Documentation section of the Lotus Forms Partner site) or the Technical Enablement/Sample Code
section of the Lotus Forms Partner site

Typical API Users

The typical user of the API is a moderately experienced to very experienced C or Java programmer who is currently involved in application development. While the API itself is not particularly difficult to use, the skill level required to develop a particular application may be quite high, depending on the
complexity of the application and the amount of integration with other software and hardware. The skill set of developers proficient in building Lotus Forms-based applications usually includes:

Extensible Forms Description Language (XFDL) and syntax.

Java or C programming language and syntax.

Experience with a Java or C application development environment OR

Any COM-compliant programming language and development environment.

Typically, people developing with the Lotus Forms API are separate from the specific forms developers, although the application developers working with the Lotus Forms API will need to know at least the basics of XFDL syntax in order to perform certain form population or data extraction
routines. A certain level of experience with Java, C, or COM is required to work the API, where this experience is not generally required to design a Lotus Forms form. Moreover, the skill set required to design a Lotus Forms form also includes layout, design and user interface skills that may not be
required for an application developer.

Typical API Uses

The Lotus Forms API is used in a variety of ways and in several places. On the client side of things, developers may create extensions to the Lotus Forms Viewer, using the API, that allow form manipulation - that is, modifications to the form (usually in response to user input) as the user
completes it. These extensions are referred to as IFXs. An IFX can also be used with the client-side Viewer to integrate with other hardware, typically hardware that collects information that must eventually end up in a form, such as scanners, bar code readers, or GPS (Global Positioning Systems).

On the server side, the API may be used within a Java servlet or similar piece of code that is designed as an interface between web-based forms and a database. This database interaction permits automatic retrieval of data to pre-populate form items, and seamless submission of form data (or the entire form) to the database. Workflow integration can be accomplished in much the same way.

Occasionally it may be necessary to integrate with additional libraries. On either the client side or the server side, using the API will allow you to use function libraries not provided with Lotus Forms API, such as voice input libraries.

Compatible Technologies

Any application that has its own application programmer interface in either Java, COM, or C can be integrated with the Lotus Forms API. Most modern databases also support XML natively so storage and retrieval of form or xml model data can be quick and seamless and extensive field-todatabase
coding can be minimized.

Additionally, because the Lotus Forms form is a complete document, forms can be stored directly in the database and retrieved as a whole document.

Standard Architectures

On the server the API is commonly used with servlets, Java Server Pages (JSP), and Common Gateway Interfaces (CGI).

Custom client side functionality is generally supported through custom IFX extensions (code extensions) provided in either Java, C, or both. Java extensions that do not require any system access may be embedded directly in a form.

Lotus Forms API vs XML Parsers

Some developers may prefer to use a third party XML parser to interface with their forms. Depending on the parser and the types of tasks to be performed, this may provide some benefits in terms of speed or developer comfort (if the developer has a great deal of experience with XML parsers).

However, the API is able to perform some tasks that are impossible for an XML parser. For example, computes can continue to run in the form (or be activated by the API) while the form is in memory, so any form data that is dependent on continuously evaluated computes will remain accurate.

Additionally, since most applications use compressed forms, which cut down transmission speeds and use of disk space dramatically, the API is able to automatically decode Base 64 data and uncompresses forms as it reads them. With an XML parser, you must force it to decode and uncompress
the forms to run them.

The API also provides methods for verifying and handling digital signatures. Most applications need to verify signatures on the server side, and occasionally even apply signatures on the server. These tasks are virtually impossible to perform without the Lotus Forms API.

The API can also encode and decode data items stored such as images, enclosures, and digital signatures. In the case of images and enclosures, this means that using the API it is possible to extract attachments or images from the form and store them separately on the server., or insert attached files
into forms as they are sent out to the user.