There are three steps to make the application work after the connection and the activities are in place.
Initializing the Keys
Prior to running the application, the Notes database must be populated with documents that contain the key fields from the back-end database. You do this through the Initialize Keys action. This action creates a new document (called a stub in the DECS documentation) from each of the records in the back-end database. The created documents contain the key and the form name by default. If you've specified that you want to monitor all forms in the database, the form name for the created documents is the default form for the database.
Keep in mind that new records added to the external database after you have initialized the keys aren't added to the Domino database after you've initialized the keys. You have to find another method to do this either through LS:DO or LEI.
Starting the Activity
After the keys are initialized, you can start the activity by selecting it in the view and clicking the Start button in the navigator. As long as DECS is running on the server, the activity starts. You can tell that it has started by looking at the activity in the view. The column next to the external source displays an icon indicating that the activity is running, as shown in Figure 22.18.
Figure 22.18. The Activity view shows the status of the activities that have been created.
When testing is complete and the application is ready to deploy, you want the activities associated with the application to be automatically invoked. You can do this by choosing the Auto Start option in the Scheduling section of the Activity document.
Testing the Application
To begin testing the application, you test the Open event for the activity by opening one of the Customer documents from the view. The address fields should be filled in with the appropriate information. This information isn't stored with the document, but it's accessed each time the document is opened. In fact, you can see that the address fields are blank: Select a document in the Customers view, select the Document Properties (by right-clicking on the document and selecting Document Properties), and select the second tab, which is the fields tab, as shown in Figure 22.19.
Figure 22.19. If the data from the external data source isn't stored in the Notes document, the document simply does not contain the fields.
Next you can test the Create event. To do this, choose the New Customer action from the Customers view. Enter a new customer and then save the document. The data is written to the external database.
Now test the Update event. Open one of the existing customers in edit mode and change the address. Save the document and the modifications are saved in the external database.
Lastly, test the Delete event by deleting one of the existing customers.
When everything is working fine with the customer records, you can test the call records. Here you're merely monitoring the Open event. So, you need to create a new call record, but there's a caveat: You're monitoring the Open event, which means that when you open a document, the information for the address fields is located in the external database and must be accessed by DECS to populate the document fields. This means that when you create a new document, you have not yet identified the customer name, and, therefore, the address information isn't available. To get the address information, you have to save the document and reopen it in edit mode when the customer name is chosen . In your application, you have a separate frame that opens the LOGCALL form as a new document. This enables the user to select a name from the available list of names . From there, the user clicks the New Call button, which saves the document with a form name of CUSTCALL and reopens that document in the frame on the right, as shown in Figure 22.20.
Figure 22.20. A new customer call document includes the customer information from the back-end data source.
After the user enters the call information, she can click the Save Call button, which resaves the document and at the same time issues a compose command for a new LOGCALL document in the frame on the bottom left of the screen. You do this to avoid overwriting the document you've just created when the user selects a new name.
Part I. Introduction to Release 6
Whats New in Release 6?
The Release 6 Object Store
The Integrated Development Environment
Part II. Foundations of Application Design
Advanced Form Design
Using Shared Resources in Domino Applications
Using the Page Designer
Adding Framesets to Domino Applications
Automating Your Application with Agents
Part III. Programming Domino Applications
Using the Formula Language
Real-World Examples Using the Formula Language
Writing LotusScript for Domino Applications
Real-World LotusScript Examples
Writing Java for Domino Applications
Real-World Java Examples
Enhancing Domino Applications for the Web
Part IV. Advanced Design Topics
Accessing Data with XML
Accessing Data with DECS and DCRs
Security and Domino Applications
Creating Workflow Applications
Analyzing Domino Applications
Part V. Appendices
Appendix A. HTML Reference
Appendix B. Domino URL Reference