IBM Workplace Forms: Guide to Building and Integrating a Sample Workplace Forms Application

Chapter 9. Domino integration 279

To make user authentication match with the available employee data, open the repository

database and edit / create some users applying in the Notes Username field the valid user

name from the address book like this (Figure 9-3).

Figure 9-3 Assign valid Notes Usernames to the employees

Building the databases up from scratch, enter some sample data after finishing the form and

view design in the Repository Database.

9.5 Domino development

There are several parts to create for Domino integration. We will use Notes @Formula,

LotusScript, and Java to create all the necessary code. The development part will contain the

following phases:

򐂰 Creating necessary static forms and views.

򐂰 Creating XFDLRendering form used to process data prepopulation

򐂰 Creating a servlet that will receive the submitted form (extract data and store form and

data)

򐂰 Creating some dedicated views with links, creating new documents from the template, or

opening existing XFDL forms

򐂰 Providing Web services needed to supply the product and customer data.

A main guideline for this chapter was not to write code related to a specific form. Instead we

will see code processing a whole class of templates, which will then be parameterized to the

needs of a specific form. This will be valid for the modules creating forms from templates (and

prepopulating them with data) and receiving submitted forms for data retrieval and data

storage.

9.5.1 Repository database

The repository database contains some external data, that we will access (read) while

creating forms or working on forms. There is no sophisticated logic in the database. We have

to compose just a few forms to store the data (Employees, customers and items) and some

views to list them for lookup-purpose.

280 IBM Workplace Forms: Guide to Building and Integrating a Sample Workplace Forms Application

Forms

All Forms used in the repository database (employee data, customer data and product data)

are quite simple; just store the necessary fields in the form. The only relevant field in the

Notes Username is employee data. Make the field a Names field ready to pick up names from

a directory. We need to store the names in full cannonicalized form (such as CN=Andreas

Richter/OU=DEP12/O=ACME) to match the user name available in the session when the

user authenticates. Some samples for form design (make sure to match the form name and

the field names in your application) are shown in Figure 9-4, Figure 9-5, and Figure 9-6.

Figure 9-4 Form Customer

Figure 9-5 Form Employee

Figure 9-6 Form Item

Views

Create some maintenance views for each form sorted by the corresponding ID field. We will

use these views for the Web services to look up detail data. In addition, we need one lookup

view for employee data by name:

View (luEmployeesByNotesName) sorted ba the Notes Username field, second column

shows @Text(@DocumentUniqueID)

Now enter some sample data.

Chapter 9. Domino integration 281

Web services

There are potentially three Web services to create (for employee data, customer data, and

product catalog). We will show here only the creation of one Web service — CustomerInfo.

The other Web services can be created the same way.

First we will take a bottom up approach to create a WSDL file based on a class. Next we will

adopt the file and create the final Web service implementation in “Top Down” mode using the

changed WSDL file.

Open the repository database in the Domino Designer,

Shared Code / WebServices pane.

Click the New WebService button, name it CustomerInfo, and close the property box (there is

no portType class entered for now). See Figure 9-7.

Figure 9-7 CustomerInfo Web service properties

Apply the Option Declare Statement in (Options) and create in (Declarations) the following

classes representing the customer object and all its attributes we will maintain (Example 9-1).

Example 9-1 Code listing of declarations for customer object

Class CUSTOMER

’this class will define the customer object and its attributes

Public CUST_ID As String

Public CUST_NAME As String

Public CUST_AMGR As String

Public CUST_CONTACT_NAME As String

Public CUST_CONTACT_POSITION As String

Public CUST_CONTACT_PHONE As String

Public CUST_CONTACT_EMAIL As String

Public CUST_CRM_NO As String

Sub NEW

End Sub

End Class

Class CustomerInfo

’this class defines the web service methods (get List and get detail data)

Sub NEW

End Sub

Function GETCUSTOMERLIST(FILTER As String) As String

'this function will return the filtered customer list as string

End Function

Function GETCUSTINFO(CUST_ID As String) As CUSTOMER

'this function will return customer detail data for one selected customer