App Builder Developing Applications

BluePhoenix AppBuilder 2.1.0.
Developing Applications Guide
BluePhoenix AppBuilder 2.1.0. Developing Applications Guide April, 2003 Corporate Headquarters BluePhoenix Solutions Vlierwerf 7B 4704 SB Roosendaal The Netherlands +31 (0) 165 399 401 +31 (0) 165 396 308 fax USA Headquarters BluePhoenix Solutions USA, Inc. 8000 Regency Parkway Cary, NC 27511 United States +1 919.380.5100 +1 919.380.5111 fax www.bluephoenixsolutions.com
1992-2003 BluePhoenix Solutions All rights reserved. BluePhoenix is a trademark of BluePhoenix Solutions. All other product and company names mentioned herein are for identification purposes only and are the property of, and may be trademarks of, their respective owners. Portions of this product may be covered by U.S. Patent Numbers 5,495,222 and 5,495,610 and various other non-U.S. patents. The software supplied with this document is the property of BluePhoenix Solutions, and is furnished under a license agreement. Neither the software nor this document may be copied or transferred by any means, electronic or mechanical, except as provided in the licensing agreement. BluePhoenix Solutions has made every effort to ensure that the information contained in this document is accurate; however, there are no representations or warranties regarding this information, including warranties of merchantability or fitness for a particular purpose. BluePhoenix Solutions assumes no responsibility for errors or omissions that may occur in this document. The information in this document is subject to change without prior notice and does not represent a commitment by BluePhoenix Solutions or its representatives.
TABLE OF CONTENTS
Table of Contents
AppBuilder 2.1.0 Developing Applications Guide
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
What is the Development Process?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 Analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Prepare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4 Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4 Execute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5 Customizing the Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Designing with Engineering Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Understanding Engineering Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 Engineering Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 The Entity Relationship Diagram (ERD). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 The Database Diagram (DBD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Tools for Transforming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Tools for Trace Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Tools for Denormalizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 Understanding Entity Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 One-to-One Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5 One to Many Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5 Many to Many Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5 Supertype to Subtype Relationship. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5 Sample ERD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5 Setting Engineering Tool Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Adding Business Logic Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Using Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 Understanding Types of Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 Using an Application Functional Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3 Embedding SQL Code in a Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Passing Data in a Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 Verifying Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6 Considerations for Writing an AppBuilder Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7 Using Java Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7 Understanding Thin Client Development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11 Understanding Event Procedure Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11 Manipulating the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12 Using Common Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 Creating Objects at Execution Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 Using Display Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15 Adding Access to a Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15 Accessing Repository Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16 Understanding the Scope of a Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18 Mapping Data to a View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18 Other Considerations for Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20 Modeless Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20 Considering the Execution Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20 Considering Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
Creating Event-driven Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Using the Display (CONVERSE Statement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 CONVERSE WINDOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 CONVERSE (null) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 Using Event-Driven Rules (CASEOF Statements) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 Using CASEOF Statements to Receive Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 Additional Steps for Modeless Secondary Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 Using Subscription (POST Statement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5 Setting up a Posting Rule Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6 Setting up a Receiving Rule Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7 Using Global Event in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8 Using the System View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9 Understanding the Fields of the System View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9 Attaching the System View to a Rule Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10 Event-driven Processing Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Handling Display Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Standard Display Rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 Display Rule for Thin (HTML) Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2 Non-Display Rule for Java Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 Display Rule with Third-Party Java Bean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
ii
User Event Handled by Java Bean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 Rule Controlling Converse Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5 Explanations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6 Converse Event for Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8 Domain Sets for Window Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9 Defining Domain for a Combo Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9 Defining Domain for a Read-Only Edit Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10 Defining Domain for a Read-Only Table Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Adding User Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Deciding When to Add a Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1 Advantages of Using Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 Disadvantages of Using Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 Guidelines for Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 Design for Reuse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 Keep the Code Current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 Specifying Component Includes Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 Adding a User Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 Creating or Updating the Application Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4 Inserting the Component in the Calling Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4 Creating and Editing the Component Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4 Data Type Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5 Writing a Java User Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7 Writing a C User Component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8 Calling a C Component from Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10 Backward Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10 Thread-Safe Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11 Work Views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12 Using Sample Component Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12 Sample Java Component Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13 Sample C Component Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13
Adding System Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Interface Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1 Hierarchy of a Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1 Thin Client Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 Using Dynamically Generated HTML Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 Dynamic Data Exchange Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4 Levels of DDE Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5 Using DDE Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Creating Online Help for Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Enabling Application Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1 Using Online Help System Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Table of Contents
iii
Creating Windows Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2 Creating Java Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3 Creating Simple Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5 AppBuilder Help at Execution Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6
Troubleshooting Application Development . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Environment Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1 Java Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1 Java Classpaths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2 Settings Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2 Delay in Loading of Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Data Type Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

DEC Value Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1 Decimal Point Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1 Valid Characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2 Format of DEC Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2 PIC Value Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3 Valid Characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3 Format of PIC Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3 Short-form Date Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4 DATE Input Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5 DATE Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6 Repository Migration Date Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6 Enterprise Repository Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6 Workgroup Repository Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7 Character Data Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7
Events Supported in C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

i
iv
CHAPTER
INTRODUCTION
AppBuilder is a robust, integrated toolset for designing, implementing, and maintaining high-volume, multi-platform, distributed applications. With AppBuilder, you can develop full Java clients and servlet-based HTML clients and Enterprise Java Bean (EJB) functionality in a standardized, supported environment. AppBuilder provides the ability to design and develop eBusiness applications independent of the deployment platform or architecture. Applications developed with AppBuilder can be deployed across multiple customer-to-business and business-to-business architectures, as well as traditional client/server environments. There are many steps to developing applications with AppBuilder, including constructing the logic, designing user interfaces, and adding pre-defined components. This guide describes these development steps for applications that will be deployed in multiple execution platforms. AppBuilder users should have basic application development experience, some familiarity with application development environments, and familiarity with Microsoft Windows operating systems. Refer to the Development Tools Reference Guide for information on the use of specific tools in the Construction Workbench. Refer to the Deploying Applications Guide for information on building and deploying the developed application. Refer to the Debugging Applications Guide for information on debugging and troubleshooting an application.
What is the Development Process?

The AppBuilder environment allows for a high degree of reuse in the data modeling and database design phases of software development. A typical AppBuilder development process consists of the following steps: 1. 2. 3. Analyze Model the data and processes of a system. Design Design the database and model the flow of the application. Construct Develop the application hierarchy, windows and views, and business logic. Use (or re-use) system components and user components.
The deployment process (covered in the Deploying Applications Guide) consists of the following steps: 1. 2. Prepare Generate the rules and windows. Debug Test and debug the rules and application.
1-1
3. 4.
Deploy Prepare the application for the target environment. Execute Run the application on the selected environment.
Analyze
Before developing a new application, you should thoroughly analyze the current business environment. This includes examining all aspects of the current business process and defining a target. From this analysis, you can develop several deliverables, such as work flow models, organizations structure and migration plans.
Design
After determining your needs, use the Entity Relationship Diagrammer in AppBuilder to create a logical data model -- an entity relationship diagram (ERD). To create an ERD you should: Identify the entities that are required to support a system. Create the relationships between the entities. Describe the entities and relationships in detail with attributes. Using AppBuilder, you build an ERD that contains boxes representing the entities, and lines representing the relationships between them, much like a flow chart. You can then forward engineer the tool to translate the ERD logical entities (entities, relationships, and identifiers) to a relational data model consisting of tables, columns, and keys, specifically in a Database Diagram (DBD). This can then be transformed into rule and view objects that can be shown in the hierarchy window. Read more about Forward Engineering and the ERD in the Development Tools Guide, Chapter 7: Design Tools.
Construct
After creating a data model for your application, use the AppBuilder Construction Workbench to create the application business logic. This includes the tasks of building the hierarchy, creating the user interface, and writing the rules that define the application logic. The primary construction tools are: Hierarchy Diagram (also called the function diagram) for creating the objects that make up the application and their relationships. The hierarchy diagram also shows the objects that exist in a repository and the relationships between the objects. Window Painter for composing the application end-user interface. Rule Painter for creating the rules that define the logic of the application. Rules can display a window, access a file, call other rules, etc. HTML Editor - for editing HTML for the user interface Refer to the Development Tools Reference Guide for more information on the tools used at this stage of the process. Also included in this step is the use (or re-use) of system components delivered with AppBuilder or user components developed by you or a third-party. For information on system components, refer to the System Components Reference Guide.
1-2
Introduction
Prepare
After designing and constructing the application you must transform the rules into an executable program. This step, preparing the application, also creates the run-time interface. An interface is the menus, icons, windows, etc. that the end-user sees. AppBuilder offers preparation tools to assist you in the preparation process. Refer to the Deploying Applications Guide for information about preparing and building an application.
Generate Rules
AppBuilder can generate platform-specific code: C for PC and servers and Cobol for mainframe, or it may generate Java code, which is not platform-specific. The generated code must be compiled in a similar environment to which it will execute (for example, a remote iSeries, UNIX, or Windows machine). Even when compilation takes place on another machine ( remote preparation), it is initiated from your local Construction Workbench. The system transmits the preparation job to the remote machine on which the compilation is to occur. Refer to Chapter 3, Adding Business Logic Components for details on creating rules. Refer to the Rules Language Reference Guide for complete information about the Rules Language.
Preparation
When you prepare your project, the system performs the following actions: Transforms the rules you have written in the Construction Workbench into an executable program. Compiles the source code of any user componentsthird-generation language routinesyour rules use. Prepares any files your rules access and creates their corresponding database tables. Prepares any sets that the application uses. Makes available to the run-time environment the menus, icons, windows, and workstation reports that comprise your application end-user interface. You can also use the workbench to prepare mainframe rules for test execution on the workstation, and to check the syntax of mainframe reports. The Status window of the Construction Workbench provides feedback information on the status of each object during preparation and execution. Refer to the Development Tools Reference Guide for a discussion of the Status window. For additional information on creating and specifying deployment configurations, refer to the Deploying Applications Guide.
1-3
Debug
After preparing the rules and displays (windows), you can debug rules locally or remotely. AppBuilder offers the RuleView Debugger tool for debugging the application, whether in Java or C. For information on debugging, refer to the Debugging Applications Guide. For standalone applications, you can debug rules locally with RuleView. For distributed applications, you can debug rules remotely with Distributed RuleView. RuleView performs the following debugging steps: Starts the execution of a rule Breaks on most lines of rule source code Skips a step during the execution of a rule Examines and change the contents of any field within a view Reviews the source code for the active rule or any rule in its data universe For Java applications, AppBuilder includes a full-featured source debugger that is built on top of the Java Platform Debugger Architecture (JPDA) from Sun Microsystems. This debugger supports viewing and modifying AppBuilder data, setting break points, and other standard debugger features. For C Language applications, the RuleView debugger is available. Refer to the Debugging Applications Guide for more information on the RuleView debuggers for C and for Java.
Deploy
After testing and debugging your project, you must specify an application configuration that identifies the specific target environment for your project. You can prepare client or server rules for execution on diverse operating systems and machines, against diverse database management tools. Refer to the Deploying Applications Guide for more information about packaging and deploying distributed applications.
Rules Generated to C
Where client or server rules are generated to C, the following is created: An executable module (dll) for each rule and user component in the application A display file (panel file) for each window Resources used during execution
Rules Generated to Java

Event-driven applications (for example, Java server with Java client or thin-HTML client) can be deployed in a variety of ways. They can be downloaded from a Web server as needed or in the form of an entire JAR file. Traditional deployment via a software distribution system is also possible. Mixed deployment is possible where a JAR file containing the main executables is downloaded while other files are left on a Web server (for example, debug files).
1-4
Introduction
Customizing the Environment
Execute
Depending on the application configuration, you can start the application from a program group, from the command line, or as a pull-down menu option. When you prepare the function to start as a desktop object, the function name is listed under the Programs choice on the Windows Start menu. When you select the function, a cascaded menu appears listing each child process. Select a process to run it. When you prepare the function to start as a menu bar choice, the function name appears in the Execution Client menu bar along with the names of any other functions you have prepared (if the option is set). Each child process is displayed below it as a menu item. If you start the execution client, run Start > AppBuilder > Execution Clients and then select the appropriate Java or C client. At this point the menu comes up with the function names. After selecting the menu item, the client can select and run the particular process.

Before developing applications, you may set up the development environment to suit your type of application and the way you want to work within the Construction Workbench. These are optional configuration settings and may be changed before you begin work in the Construction Workbench. They include: Workbench Options Initialization Settings (INI Files) Window Arrangement
Workbench Options
Use the Workbench Options window to specify the various Construction Workbench options for each tool (for example, display options, defaults, or confirmations). To access these options, select Tools > Workbench Options from the Construction Workbench menu. For a complete explanation of the Workbench Options, refer to the Development Tools Reference Guide.
Initialization Settings (INI Files)

Most settings for the Construction Workbench are set within the Workbench Options. A few of the settings can be modified by editing the system initialization file (hps.ini) before running the Construction Workbench. You can edit and set configuration or initialization parameters that affect the development environment. To access these parameters, edit the hps.ini file using the INI File Editor available from the Management Console. Refer to the Communications Configuration Guide for an explanation of how to run the INI File Editor.
Window Arrangement
One way to customize the development environment involves arranging the window areas in the Construction Workbench. Refer to the Development Tools Reference Guide for information about the window areas.
1-5
1-6
Introduction
CHAPTER
2
Figure 2-1
DESIGNING WITH ENGINEERING TOOLS
The engineering tools in AppBuilder let you develop a logical data model and then convert the abstract engineering drawing into a less abstract representation. You can use forward engineering to convert the logical data model into a relational data model and then use transformation, transforming the relational data model into hierarchy objects in the repository. You can also use reverse engineering, converting a relational data model back to a logical data model. Figure 2-1 illustrates how the different data representations interrelate, from more abstract on the left, to less abstract on the right.
Moving from abstract design to generated rules
With the AppBuilder engineering toolset you can: Use Understanding Engineering Diagrams to create a logical model in the form of an entity relationship diagram (ERD) or a relational model in the form of a database diagram (DBD). Use Engineering Tools to convert the abstract engineering drawing into a less abstract representation. In other words, you can forward engineer a logical model represented in an ERD into a relational model represented in a DBD. Use The Database Diagram (DBD) to refine the relational model in a DBD back to the logical model in an ERD, so that the relational and logical models reflect each other. Use the Tools for Denormalizing a relational model into a structural model (the data structures that AppBuilder rules use to read from and write to database tables). Use Tools for Trace Analysis to track through a report of how the logical entities in an ERD correspond to the relational entities in the database model.
2-1
Understanding Engineering Diagrams
You can also: Use The Database Diagram (DBD) to copy a column from one table to another through a foreign key, thereby improving database performance Track how the relational entities in the database model map back to logical entities in an ERD by using a trace analysis report Forward and reverse engineer the same model as many times as you want Refer to the Development Tools Reference Guide for detailed information on the engineering tools.
Understanding Engineering Diagrams

Each step in the engineering process involves a diagram, either the entity relationship diagram (ERD) or the database diagram (DBD). You start with an ERD for these processes: Forward engineering Forward trace analysis You start with an DBD for these processes: Denormalization Reverse engineering Reverse trace analysis Transformation The ERD and DBD tools require that you download donor entities to the repository. This ensures that you can access attributes that your entities obtain from related but excluded objects. See Understanding Entity Relationships on page 2-4 for donor and recipient definitions. Forward and reverse engineering are tightly coupled processes that require you to start with a diagram containing all the donor and recipient entities; therefore, you should plan to perform these tasks in the same repository. To successfully reverse engineer a DBD, the repository must contain all of the corresponding logical models (ERDs) and traceability information. Establish a naming standard to make it easier to find the objects you need.
2-2
Designing with Engineering Tools
Engineering Tools
Engineering Tools
AppBuilder offers two diagramming tools: the Entity Relationship Diagram for forward engineering and the Database Diagram for reverse engineering. In addition, AppBuilder offers tools for the transform process, trace analysis, and for the denormalizing process: The Entity Relationship Diagram (ERD) The Database Diagram (DBD) Tools for Transforming Tools for Trace Analysis Tools for Denormalizing
The Entity Relationship Diagram (ERD)

The ERD translates logical entities, such as entities, relationships, identifiers, and attributes, into relational entities, which are tables, keys, and columns. Forward engineering creates a table for each ERD entity, keys from their identifiers and relationships, and columns from their attributes. Forward engineering maintains inheritance information so you can do a trace analysis to see how the logical entities translated into relational entities.
The Database Diagram (DBD)

Use the DBD for reverse engineering. The reverse engineering process in the Database Diagrammer converts the DBD relational entities, such as tables, keys, and columns, back to the ERD logical entities, which are entities, relationships, attributes, and identifiers. The resulting ERD reflects any changes you make to the relational model in a DBD, so the reverse-engineered ERD may not be the same as the forward-engineered ERD.
Tools for Transforming

The transform process in the Database Diagrammer translates relational entities, such as tables, keys, and columns, into structural entities, which are files, views, and fields. The transformation process transforms a relational model represented in a database diagram (DBD) into data structures that AppBuilder rules use to read and write to a database.
Tools for Trace Analysis

Traceability information in the repository enables you to: See the impact on the relational model if you change the logical model See the impact on the logical model if you change the relational model Forward and reverse engineer the same model as many times as you want
2-3
Understanding Entity Relationships
Use the trace analysis process in the Entity Relationship Diagrammer to see how forward engineering translated logical entities into relational entities. Trace analysis tracks and reports how the logical entities in an ERD correspond to the relational entities in the database model. For example, after forward engineering, use the forward engineering report to answer questions such as: What tables are affected when I change an attribute? Which is the key created from an identifier? The trace analysis process in the DBD lets you see the same information from the vantage point of relational objects. After reverse engineering, reverse trace analysis tracks and reports how the relational entities in the database model correspond to the logical entities in an ERD. You can then analyze the report to answer questions such as: If I change a column in a table, what attributes or relationships are affected during reverse engineering, and how? If I add a column to a key, which attributes or relationships are affected, and how?
Tools for Denormalizing

The denormalizing process in the Database Diagrammer lets you copy a column from one table to another through a foreign key. Denormalization creates physical columns in a table through inheritance from other tables. Denormalizing can improve performance by reducing the number of table joins while executing an application.

This brief summary is intended for designers who need to understand entity relationships for use with the design tools. For specific information about the design tools, refer to the Development Tools Reference Guide. For specific information about the information model and particular entities, refer to the Information Model Reference Guide. Every entity in an entity relationship diagram is a donor, a recipient, or both. A recipient entity receives one or more foreign keys from its donor entity. A foreign key is one or more columns that uniquely identify rows in another table; this associates two entities through a relationship. Cardinality relationships determine whether an entity is a donor or a recipient.
Table 2-1 Donorrecipient relationships Description Each entity can be either a donor or a recipient. See One-to-One Relationship. The donor entity on the one side passes information to the recipient entity on the optional-one side. The donor entity on the one end passes information to the recipient entity on the many end. See One to Many Relationship. Each entity is a donor to the relationship between them. The relationship is a recipient and is implemented by a table. See Many to Many Relationship. The supertype entity is a donor that passes information to the recipient subtype. See Supertype to Subtype Relationship.
Relationship One to one Optional-one to optional-one One to optional-one One to many Many to many Supertype-subtype
2-4
One-to-One Relationship
Forward engineering uses the following algorithm to resolve both optional-one to optional-one and mandatory one-to-one relationships: 1. 2. 3. 4. 5. Any non-kernel entity inherits from the kernel entity. Look at the volumetric information and try to inherit to the side that has fewer expected rows. If steps 1 and 2 fail, try to inherit to the side that has fewer expected maximum rows. If step 3 fails, try to inherit to the side that has fewer expected minimum rows. If steps 1 through 4 fail, randomly select an entity to inherit to. Usually, but not always, you select the entity created first.
Steps 1 through 3 try to inherit to the entity that uses the least amount of storage. Steps 1 through 3 fail in a mandatory one-to-one relationship because both entities should have identical volumetric information. Step 4 tries to inherit to the entity that is dependent on the kernel entity if there is one. If the volumetric information changes, the donor and recipient entities change roles; therefore, it is safer to upload and download both sides of an optional-one to optional-one or a one-to-one relationship, regardless of which side gets inherited.
One to Many Relationship

In this type of relationship, forward engineering creates two table entities, one for each entity in the original ERD. Each entitys primary identifier becomes a primary key attached to its table. Any candidate or associate identifiers become index keys, and a foreign key is created to represent the relationship between the two entities.
Many to Many Relationship

In this type of relationship forward engineering creates one table for each entity and an additional table containing intersection data (the relationship). The name of the intersection table is based on the name of the relationship between the two entities.
Supertype to Subtype Relationship

In this type of relationship, forward engineering creates one table for supertype and one table for each subtype. The supertypes table contains columns for its attributes and a primary key for its identifier. The subtype tables have columns for their own attributes, as well as columns corresponding to all the supertypes primary attributes.
Sample ERD
Figure 2-2 shows a sample ERD with entities that have relationships with other entities that are not in the drawing but are in the repository. This example utilizes the different relationship types that are discussed above. The AGENT, VEHICLE, CUSTOMER, and CORPORATE entities have three dots in their upper right corner to indicate they are related to entities outside the drawing.
2-5
Using the rules listed above, the AGENT entity in Figure 2-2 is a donor, because it is on the one side of the one-to-many relationship. Because AGENT is the donor, you do not need the RESERVATION recipient. In contrast, VEHICLE is a recipient because it is on the many end of a one-to-many relationship. You needits donor entity, LOCATION, before you forward engineer this drawing. The CORPORATE subtype entitya recipientand its donor, CUSTOMER, are already in the drawing. You do not need the other subtype entity, INDIVIDUAL, because it is a recipient.
Figure 2-2 Donor and recipient entities
2-6
Setting Engineering Tool Options

Use the Engineering tab (Figure 2-3) of the Workbench Options dialog box to specify default choices for the engineering tools. Access the Workbench options, from the Construction Workbench menu bar, click Tools > Workbench Options.
Figure 2-3 Workbench Options: Engineering Tab
Table 2-2 Option
Engineering options summary Description Determines the suffix that you want to assign to certain objects that forward engineering creates. Enter a value for each of these types of suffix: Primary_Key_Suffix Foreign_Key_Suffix Index_Key_Suffix Data_View_Suffix Specify default attributes for data types. You can modify the default value here or modify values for a specific data type in the data type Properties window. Select either the Long name or the Implementation name. The long name is the name used in the database diagram. The implementation name is a name you provide according to naming conventions for your project. The forward engineering process gives new objects system-created names based on the name of the original entity.To create custom names for generated objects, select this check box. If this box is checked, the system verifies the referential integrity of the database. Select the action to do with duplicate text and keywords: Copy, Overwrite, and Dont Copy.
Suffix
Column
File generation method
Query user Referential Integrity Text and keywords
By default, the transformation process uses the implementation name for the entities it converts. Use the File Generation Method field to specify whether the generation method uses long names or implementation names.
Note
If you specify that transformation is to use long names instead of implementation names, you cannot perform view-to-view mapping.
2-7
Read more about all the Workbench Options in the Development Tools Reference Guide.
2-8
CHAPTER
3
Figure 3-1
ADDING BUSINESS LOGIC COMPONENTS
Designing high-level rules in the business logic of the application can help maintain platformindependent applications. AppBuilder provides Rules Language to create your platform-independent application. Use the AppBuilder tool Rule Painter to write your business logic with Rules Language.
Rule Painter window
In any Rule Painter window, you can perform the following tasks: Creating a Rule Edit an Existing Rule Inserting Object Names Inserting Reserved Words Using a Macro Using the Mapping Wizard Using the SQL Builder Verifying Rules
3-1
Using Rules
Step-by-step instructions on how to perform each task are discussed in the Development Tools Reference Guide. This section provides an overview of the following topics: Using Rules Considerations for Writing an AppBuilder Rule Other Considerations for Rules The Rules Language Reference Guide provides exact rule syntax and additional information about how to construct statements with Rules Language elements.
Using Rules
Consider the following before using a rule: Be aware of the information model properties of a rule. They affect a rule during preparation and execution. There are practical limitations on the scope and size of a rule. The physical hierarchy of an application significantly affects how you code a rule and the entities it can act on. Verifying the rule is a good first step before executing the application. The execution environment of the application also affects the rule; refer to the Deploying Applications Guide for information about preparing the rule for the execution environment. The following topics are discussed in this section: Understanding Types of Rules Using an Application Functional Hierarchy Embedding SQL Code in a Rule Passing Data in a Rule Verifying Rules
Understanding Types of Rules

Generally, there are three types of rules: Event-Driven Rules Converse Rules Non-Display Rules
3-2
Adding Business Logic Components
Using Rules
Event-Driven Rules
Referring to a rule as event-driven means that end-user actions, such as pressing a mouse button or selecting a menu item, generate events. These events are sent to the rule where they are handled by special procedures called event procedures. Event procedures are defined within the rule itself using a special syntax and contain the logic that is needed to respond to the event. These events and event procedures play a central role in event-driven programming. In fact, writing event-driven applications is largely a process of determining which events you need to respond to and writing event procedures that provide the appropriate response. While event-driven rules are generally display rules, it is possible for non-display rules to have event handlers for error events. Event-driven rules also allow the use of ObjectSpeak statements. ObjectSpeak is an object-based Rules Language syntax, to interact with window objects (such as edit fields and push buttons) for Java clients at execution time. ObjectSpeak is a set of extensions for the Rules Language that supports industry standard dot notation for accessing object properties and methods. Refer to the ObjectSpeak Reference Guide and Rules Language Reference Guide for more information.
Note
Event-driven applications can only be prepared as Java applications.
Converse Rules
The most significant difference between display rules for the Java client and display rules for other platforms is that Java client display rules use event procedures rather than a converse loop to respond to user actions. Converse rules are used for developing C runtime applications with AppBuilder. For AppBuilder's traditional style of application, display rules are typically structured as loops containing a converse statement. The loop executes until an exit condition is met, e.g. a close event on the window. Actions or events on the window are handled, within the loop, or rules called from there. Converse rules can not be prepared for Java. A TurboScripter script is available to assist in conversion of Converse Rules to an Event-Driven model.
Non-Display Rules
All other rules not included in the event-driven or converse categories are referred to as non-display rules. They basically encompass all rules below the presentation layer of an application.
Using an Application Functional Hierarchy

An application hierarchy depicts the functional structure of an application and the available data structures. The hierarchy contains a function, the processes of a function, and the rules for each process. How a rule relates to views and other objects in an application hierarchy affects how you can use a rule. A process with a relationship to a rule is a leaf-level process. Each leaf-level process is a separate application. The rule to which a leaf-level process relates is called a root rule because it is the root of the rest of the application hierarchy. All other objects in an application are descendants of the root rule. Only one root rule is allowed in each process.
3-3
Using Rules
In a well-designed application, each rule performs a specific action, such as routing the logic flow to another rule, displaying a window, accessing a database, or performing a calculation. A rule can be a parent or a child, depending on its position in the hierarchy. The root rule is always a parent rule. From that point on in the hierarchy, rules are both children and parents until the bottom of the hierarchy. Rules at the same level can be referred to as siblings. The leaf rules are children only, even if they have windows and views attached to them. A leaf rule can decompose into anything but other rules. Figure 3-2 shows a typical hierarchy.
Figure 3-2 A typical application hierarchy Leaf (child) rule displays secondary window
Root rule displays primary window
Embedding SQL Code in a Rule

You can insert SQL code (query language commands for database access) into a rule using the SQL Builder within Rule Painter. The SQL Builder allows you to customize the generated SQL code before adding it to the rule. For step-by-step instructions on how to insert the SQL code, see the discussion of using SQL Builder in the Development Tools Reference Guide.
Passing Data in a Rule

An AppBuilder application passes data in fields; the fields are collected into views. Rules use views to pass data to each other and to the other entities connected to them. Once you have created a View and linked it to a Rule, you must define its type. That is to say, that you define the type on the relationship. So, unless a view has a relationship to a rule, you cannot define its type. To define a views type, do the following: 1. 2. 3. From the Project tab of the Hierarchy window, right-click on the View object. Select Relationship Properties from the pop-up menu. A Properties window appears. From the View Usage drop-down list box, select the appropriate value. Any rule can have views, but root rules should have only a work view.
3-4
Using Rules
The data scope of a rule includes all views and sets linked to it, views attached to Window, File and Physical Event objects linked to it, and input/output views linked to immediate child rules and components. It also includes internally defined views and fields (within DCL..ENDDCL section) and an SQLCA view that is automatically available to rules defined as accessing a database. This section discusses the following types of views: Input View Output View Input & Output View Work View Global View When you prepare a rule, the AppBuilder environment automatically updates the data universe of a rule (incorporating any changes you made to relationships in the rule hierarchy) before checking the syntax of your rule and generating code. The rule source is scanned for references to rules, components, windows, and sets. If any of these elements do not match the relationships in the rule hierarchy in the repository, the preparation of that rule fails.
Note
Application preparation fails if the leaf-level (lowest level) view does not include at least one field. That is, although a view can refer to any number of subordinate views, eventually the hierarchy must end in at least one field for all superior views to be valid.
Input View
An input view passes data into a rule. A rule can have only one input view. The standard naming convention for an input view is to append _I to the rule name. For example, the input view of the rule DISPLAY_CUSTOMER_DETAIL is DISPLAY_CUSTOMER_DETAIL_I.
Output View
An output view passes data from a rule to its parent rule. A rule can have only one output view. The standard naming convention for an output view is to append _O to the rule name. For example, the output view of the rule DISPLAY_CUSTOMER_DETAIL is DISPLAY_CUSTOMER_DETAIL_O.
Input & Output View

A rule view is an input and output view when the rule can change its input data. For example, if you write a rule to change all lowercase letters to uppercase, you can define the single view of a rule as Input & Output. The standard naming convention for an Input & Output view is to append _B (for Both) to the rule name. A rule can have only one Input & Output view. If a rule has an Input & Output view, it cannot also have a separate input view or output view.
Work View
A work view is local to its parent rule, which means a rule cannot see the work view of any other rule. A rule can read from or write to its own work view. A rule can have more than one work view, but need not have any. A work view is important for the support of events. For instance, you must attach the predefined system view HPS_EVENT_VIEW as a work view to any rule that captures events. You also use a work view to pass data between detached rules. See Chapter 4, Creating Event-driven Applications for more information.
3-5
Using Rules
Global View
A global view is a way for multiple rules to share the same data. That is, all rules in the application attached to a global view share the same data. The view must be attached to all rules that share its data.
Note
Global views should be attached to rules, not to windows.
Verifying Rules
You can verify rules to ensure that they are syntactically and logically correct. Before verifying, you must specify the programming language in which the rule will be generated so AppBuilder knows the language syntax to verify against. After you have selected the language, you can choose to Verify Syntax, which verifies only the syntax of your rule, or you can choose to Verify All, which verifies the rule syntax, the structure, and validity of the hierarchy. Do the following to verify a rule: 1. Open the rule to verify: Right-click on the rule in the Hierarchy window and select Open Rule, or Double-click on the rule in the Hierarchy window. Highlight the rule name in the Hierarchy window and press Enter. A Rule Painter window opens in the Work Area. 2. Choose the verification language: From the Construction Workbench menu bar, select Build > Verification Language, and select the language. Or, Right-click in the Rule Painter window of the open rule and select Verification Language; then, select the language. 3. Verify the rule: From the Construction Workbench menu bar, select Build > Verify Syntax or Verify All. Or, Right-click in the Rule Painter window of the rule and select Verify Syntax or Verify All from the pop-up menu. Or, With the Rule Painter window in focus, to Verify press Ctrl+Alt+F7 and to Verify All press Alt+ F7. The system checks the rule and displays the results on the Verify tab of the Status window, as in Figure 3-3. For details on error and warning messages, refer to the Messages Reference Guide.
Figure 3-3 Verify tab of Status window
For more information about debugging an application, refer to the Debugging Applications Guide.
3-6
Considerations for Writing an AppBuilder Rule
For more information on the Output window (and the Verify tab) refer to the Development Tools Reference Guide.
Keeping Within Limits

In theory, the number of rules or components a single rule can use is not limited by AppBuilder. But in practice, there are limitations. Each rule in an online application can converse only one window for communication with the end user. When one of your rules converses a window, you need Rules Language code to interpret and respond to the end-user input. As a practical guideline, a single rule should not invoke more than five to nine objects. If your rule calls more than nine other objects, you may be putting too much functionality into one rule. It would make sense to break it into logical subunits. Even though there is no maximum size for a rule, factors such as the operating system, the compiler, and available memory place a practical size limit. To make a rule easy to maintain and reuse, do not exceed 100 to 140 lines (about two printed pages). If your rule exceeds this limit, divide it into smaller rules.

This section discusses issues you need to consider when writing an AppBuilder rule, including working with repository objects and understanding a rules scope. The following topics are discussed in this section: Using Java Objects Using Common Procedures Creating Objects at Execution Time Using Display Rules Considering the Execution Environment Accessing Repository Objects Understanding the Scope of a Rule Mapping Data to a View
Using Java Objects

ObjectSpeak is a subset of the AppBuilder Rules Language. It is an object-based Rules Language syntax. AppBuilder uses ObjectSpeak to interact with window objects (such as edit fields and push buttons) at execution time. For Java, the rule and the window are objects. This means that a rule and a window may have properties, methods, and events that can manipulate and interact with that rule or window. Properties represent the state of the object. The properties of an object are its attributes, such as height, foreground color, and visibility.
3-7
A property consists of a single value of a specified type. For example, the type of the Height property is integer, the type of the Foreground property is color, and the type of the Visible property is boolean. You set properties in the design phase using Window Painter, and you can change or modify property values at execution time. For more details, see Changing Property Values at Execution. Methods are the input to the object. The method of an object is its function or procedure that can be called on an object. For example, the MessageBox object has a Show method that is used to display the message box. For more details, see Using Methods. Events are output from the object. The event is the actions that are triggered by objects, often in response to a user action. For example, push buttons have a Click event that is triggered when the user clicks on the button with the mouse. For more details, see Event-Driven Rules in Java. Refer to the ObjectSpeak Reference Guide for a description of properties, methods, and events in ObjectSpeak.
Notes
In Java, the Chart and Hot Spot objects are not supported. In Java code for thick client and servlet, you must define unique system identifiers (HPSIDs) for all window objects. If you have existing C applications that can use duplicates, be aware that changing to Java requires creating unique system identifiers. Objects for HTML Clients: In an HTML client application, rules are executed in a Web or application server environment. The application sends information about the windows to the client browser in HTML format. Some events, such as FocusGained, FocusLost, or Click on Edit Field must be handled by a client-side script instead of an AppBuilder rule. The object properties, such as setFont or setBackgroundColor update the style attributes of the HTML file of a window. There are special ObjectSpeak methods supported for thin-client applications like HTML, for example, using cookies to save user profiles. Refer to the ObjectSpeak Reference Guide for more information on these methods
Changing Property Values at Execution

Many properties for user interface objects can be set during design in Window Painter. However, it is useful to be able to manipulate the properties of an object at execution time as well. For example, you might want to disable or enable a menu item dynamically in response to the current state of the program. Or you might want to protect an edit field, making it non-editable. AppBuilder uses ObjectSpeak to interact with properties of objects and methods at execution time. ObjectSpeak uses a dot notation to indicate that a property or method of an object is being accessed. The following examples demonstrate ObjectSpeak syntax for accessing the properties and methods of an object. Example of assigning a new value to a property This example demonstrates how to change the value of a property. Use the name (HPSID) of the object (QueryButton), followed by a period, followed by the name of the property (Text). map Query to QueryButton.Text This code changes the Text property of the push button called QueryButton to Query.
3-8
Example of determining the current value of a property This example demonstrates how to determine the current value of a property. Use the name of the object (QueryButton), followed by a period, followed by the name of the property (Text). if QueryButton.Text = Query use rule QUERY_RULE endif In this example, the value of the Text property of the QueryButton object is not being changed; it is simply being referenced to see if it is equal to the string Query.
Using Methods
Methods are functions or procedures that can be called on an object they provide a way to tell an object to perform a specific task. Example of Displaying a Message Box Here the Java client contains an object named MessageBox that displays a message on the screen. The MessageBox object has a method named Show that causes the message box to appear on the screen: dcl MyMessageBox object type MessageBox; enddcl map new MessageBox to MyMessageBox map 'Invalid Data' to MyMessageBox.Title map 'The amount in the Interest field is too large' to MyMessageBox.Message MyMessageBox.Show This example: 1. 2. 3. Creates a MessageBox object and maps it to the local variable MyMessageBox. Assigns the desired title and message strings to the Title and Message properties. Calls the Show method to display the message box.
Set Methods In general, each property has a set method that assigns a value to the property. Set methods take exactly one parameter, whose type is the same as that of the property. By convention, the name of a property set method is simply the property name prefixed by Set. For example, a string property named Text has a set method named SetTextthat takes a string parameter. Likewise, a boolean property named AutoSelect has a set method named SetAutoSelect() that takes one boolean parameter, as the following code illustrates: NameField.SetAutoSelect(True) Although both mechanisms (set method and map statement) can be used to change the value of a property, the set method provides a slightly more compact notation. Example of Using a Set Method A set method is a common method used to assign values to properties. For example, consider the following two lines of code that each accomplish the same action:
3-9
map Query to QueryButton.Text This line assigns (maps) a value directly to the Text property of the push button. QueryButton.SetText(Query) This line calls the SetText set method of the push button, passing the new text as a parameter. In this example, SetText( ) is the set method for the Text property.
Event-Driven Rules in Java

In AppBuilder, all rules that display windows (display rules) are event-driven. However, for traditional AppBuilder applications, displaying a window and identifying and processing the events resulting from the window are handled in a procedural fashion and must be explicitly coded. For an event-driven application, displaying the window becomes an implicit process, and to handle events, the rule contains special procedures called event procedures. These procedures are defined using a particular syntax. AppBuilder's Java class library identifies the event type and applicable object and invokes any event procedures for that event type or object. Writing event-driven applications is largely a process of determining which events you need to respond to and writing event procedures that process these appropriately. The following are some of the actions that generate events: Opening the window Closing the window Clicking a push button, radio button, or checkbox Selecting a menu item Shifting focus to a user interface object, such as an edit field Shifting focus away from a user interface object Double-clicking on an object with the mouse Entering erroneous data into an error field Trying to close the window when one or more fields contain erroneous data Refer to the ObjectSpeak Reference Guide for a list and description of events in ObjectSpeak. It is not necessary to provide an event handler for every event that may be generated. If the program wants to respond to the event, an event procedure must be defined and the code that responds to the event must be placed within the procedure. Example of an Event Procedure If a window contains a push button named CloseButton that is used to close the window when clicked, the needed event procedure is: PROC for Click object CloseButton ( e object type ClickEvent ) MAIN_WINDOW.Terminate ENDPROC This event procedure responds to the Click event by calling the Terminate method on the window, which causes the window to close. More information on event procedure syntax is explained in Understanding Event Procedure Syntax.
3-10
Understanding Thin Client Development

You can build AppBuilder applications that can be accessed by any supported Web browser and other HTTP client. AppBuilder enables you to: Have your application's client rules execute on an HTTP server (that is, a Web server) or any Java version 2 Enterprise Edition (J2EE) compliant application server. This allows you to deploy your applications without requiring AppBuilder on the client machines. Create applications that can be accessed over the Internet, a corporate intranet, or both. Server rules access the database of an application, which can be on any server in the network. Convert your AppBuilder applications created for GUI clients into HTML pages for network browser clients. The presentation pieces of an application are translated into HTML, giving it a generic user interface that can run on most platforms. Generate a thin-client (HTML client) application. Create dynamic Web pages and process information contained in HTML forms. Add any technology that Web servers and browsers support (for example, JavaScript, Java applets, ActiveX) to your AppBuilder application. Your application may require additional resource files, such as multimedia files and graphics, as part of the HTML pages. These miscellaneous files could be any of the following: Global resource files common to many or all Web pages (such as CSS style sheets, META tags, etc.). Store these files as part of a Component Folder defined as a child of the process object in the hierarchy. Web page specific resource files, unique to specific pages. Store these files as part of a Component Folder defined as a child of the window object in the hierarchy. Define the resource folders with the Folder Type as HPS_WEB_RESOURCE. Component Folder entries with the given Folder Type are prepared with the partition or window object and are copied to the images subdirectory.
Understanding Event Procedure Syntax

There are two general forms for event procedures: event handling for a specific object and event handling for all objects of a specific type. Thus, it is possible to write an event procedure that handles Click events for a specific push button and another event procedure that handles Click events for all the push buttons on a window. Table 3-1 shows the variables used in the following examples with a description of each variable. For more information and to view a diagram of Event Procedure Syntax refer to Chapter 7 of the Rules Language Reference Guide.
Table 3-1 Variable Description An optional, unique, user-defined name for the procedure. The name of the event (for example, Click). The system identifier (HPSID) for the window object, or the long name for the rule or window object. Type of the object (for example, PushButton or EditField).
<ProcedureName> <EventName> <ObjectId> <ObjectType>
3-11
Table 3-1
<ParameterName> <ParameterType>
A user-defined name for the event parameter. The data type of the parameter. The <ParameterType> is always the <EventName> with Event appended.
Example Event Procedure: Specific Object The following syntax illustrates an event procedure that handles events for a specific object: PROC <ProcedureName> FOR <EventName> OBJECT <ObjectId> (<ParameterName> object type <ParameterType>) ... ENDPROC See Table 3-1 for descriptions of the variables used in this example. Example Event Procedure: All Objects of Specific Type The following syntax illustrates an event procedure that handles events for all objects of a specific type: PROC <ProcedureName> FOR <EventName> TYPE <ObjectType> (<ParameterName> object type <ParameterType>) ... ENDPROC See Table 3-1 for descriptions of the variables used in this example.
Naming Conventions
The code examples used in this chapter use a convention of generating a name for event procedures by combining the object and event names. For example, for a pushbutton with a system identifier HPSID of CloseButton (and thus ObjectSpeak name of CloseButton), the event procedure for the Click event would be named CloseButtonClick. Also, the parameter name is by convention often just a single letter, such as e or p. Example Code: Naming Conventions A typical event procedure would be: PROC CloseButtonClick FOR Click OBJECT CloseButton ( e object type ClickEvent ) MAIN_WINDOW.Terminate ENDPROC
Manipulating the Interface

Many events provide information about the object that triggered the event. This information is contained in two properties of the event procedure parameter: the HPSID property and the Source property. HPSID is a string property that contains the system identifier (HPSID) of the object that generated the event. Source is a reference to the object whose type is GuiObject.
3-12
The GuiObject is a generic type that is used to represent interface objects, including edit fields, pushbuttons, menu items, or comboboxes, for example. GuiObject has two Boolean properties Enabled and Visible that can be used to manipulate the object that triggered the event. Because GuiObject, which is the type of Source, is a generic type that represents all graphical user interface (GUI) objects, the following code could be used to disable an edit field or any other GUI object when it is clicked. Example of GuiObject Use In this example, an application has a Query button that must be disabled temporarily when it is pressed: PROC FOR Click OBJECT QueryButton ( e object type ClickEvent ) *> disable the QueryButton <* e.Source.SetEnabled( False ) *> perform the query <* . . . *> re-enable the QueryButton <* e.Source.SetEnabled( True ) ENDPROC
Using Common Procedures

In addition to event procedures, described in Understanding Event Procedure Syntax, AppBuilder supports common procedures. Common procedures allow you to place frequently-used logic in a single place in the rule structure. Common procedures can also return a value, thus allowing them to be called from within expressions. The following is a common procedure used to display text in a status bar (an edit field) at the bottom of the window. For more information on common procedures, refer to the Rules Language Reference Guide. Example Procedure for Status Bar Text PROC UpdateStatusBar( text CHAR(100) ) StatusBar.SetText( text ) ENDPROC
Creating Objects at Execution Time

Most objects in AppBuilder are created during design with Window Painter. Design time objects are those that are created when the user interface is being created. For example, a pushbutton, list box, or radio button.
3-13
However, you can also create objects dynamically, at execution time. Objects, whether created during design in Window Painter or at execution time in rules, can be passed as parameters to other rules or to common procedures within a rule. This allows a great deal of flexibility in designing applications. For detailed information on the objects you can create in AppBuilder, refer to the ObjectSpeak Reference Guide. Consider the following section of a rule: dcl QueryButton object type PushButton; enddcl . . . map new PushButton to QueryButton This rule declares a local variable named QueryButton of type PushButton. The map statement uses the new keyword to create an instance of a PushButton object and assign it to the QueryButton local variable. To receive events from objects that are created dynamically at execution time, you must include code to define the event procedure. The following example dynamically creates a Timer object on a window named MAIN_WINDOW when the user clicks the UpdateButton button. Note that the last statement in the Click event procedure for the button specifies that the event procedure (or handler) for the timer is the TimerProc procedure. Example Procedure that Dynamically Creates Objects Using the approach in this example, you can dynamically create objects and define event procedures to respond to the events they trigger. dcl UpdateTimer object type Timer; enddcl *> event procedure for Timer events <* PROC TimerProc FOR Timer OBJECT UpdateTimer (e object type TimerEvent) *> do what needs to be done when timer triggers <* *> ??? <* ENDPROC *> respond to Update button click by starting timer <* PROC FOR Click OBJECT UpdateButton (e object type ClickEvent) *> create a timer <* map new Timer( MAIN_WINDOW ) to UpdateTimer *> set timer properties and start the timer<* UpdateTimer.SetDelay( 1000 ) UpdateTimer.SetRepeats( True ) UpdateTimer.Start
3-14
*> dynamically add event procedure to handle timer events <* Handler UpdateTimer( TimerProc ) ENDPROC
Using Display Rules

In AppBuilder, event-driven rules that display windows are generally structured as follows: Declaration (dcl...enddcl) section for local variables Standard or non-event procedures Event procedures Although none of these items are required, most applications consist of several sections that contain one or more of the items listed above. Typically, a declaration section is followed by the window Initialize and Terminate event procedures. These would be followed by additional event procedures to handle push button clicks, menu item selections, and other user actions. The most common event procedure is the Initialize event procedure, called after the window is created but before it is shown. This is a good time to initialize the application data and make any needed adjustments to the visual objects on the window. The most significant difference between display rules for the Java client and display rules for other platforms is that Java client display rules use event procedures rather than a converse loop to respond to user actions. In the Java client, rules that do not display windows are written in the same way as in earlier versions of the product. That is, non-display rules can consist of: Declaration (dcl) section for local variables Rule body that contains standard procedural code Standard or non-event procedures Thus, in general, a Java client application developed in AppBuilder can consist of display rules that use the new rule structure and non-display rules that use standard Rules Language.
Adding Access to a Database

To allow access to a database, use the Project tab in the Hierarchy Diagram to model the hierarchy for a rule that accesses a file. Figure 3-4 shows an example of this hierarchy.
Figure 3-4 Database access hierarchy File view with Data View relationship
Primary and secondary keys
3-15
The file object in the hierarchy corresponds to a table in a database; the fields within the file view object correspond to the columns in the table. You can only have one file view object attached to a file object. Make sure you set the following properties of objects in the hierarchy for the database. In the database rule object, set the property DBMS Usage to DB2. This setting does not set the type of database that the rule accesses; it simply specifies that SQL database access is used in this rule. In the file object, Implementation name property to the actual name of the database table. In each field object of the first view object under the file object (called the file view), set the Implementation name to the actual name of the column in the database table. There are several kinds of database views (defined by their relationship properties): Data view - is the database view Primary index view - is the primary key view Alternate view - is the alternate key view When you build the file hierarchy, remember that: The first view under the file object is the file view. The relationship between the file and the view must be of type Data View. This view must contain at least one field. File can have a primary key view. The fields of this view must be a subset of the fields of this file view. These fields form unique indices. File can have an alternate key view. The fields of this view must be a subset of the fields of this file view. These fields may or may not form non-unique indices. For more information about rule views, refer to Passing Data in a Rule. For information on configuring database access in a distributed environment (not just stand-alone mode), refer to the Deploying Applications Guide.
Accessing Repository Objects

The AppBuilder information model is a collection of entity types and relationship types, collectively called object types, that is stored in the repository. You can use these object types to model the business logic and to create the applications in the AppBuilder environment. For a complete description of the information model, refer to the Information Model Reference Guide. Figure 3-5 shows a brief example of part of the information model so you can see how rules relate to other object types. Rules connect functions and processes to other objectssuch as windows, views, and fieldsto implement the processes triggered by end-user interaction, as illustrated in Figure 3-5. In the Hierarchy window in the Construction Workbench, functions and processes are above, and can contain, rules; the subordinate or child objects are below, and are contained in, rules. The hierarchy can be expanded to show these contents.
3-16
Figure 3-5
Rules in the Information Model
Understanding Properties
Every object in the AppBuilder information model has properties, including rules. Three properties affect how you use a rule: Execution environment indicates the specific operating environment to which you want to prepare and in which you want to execute the rule. Refer to the Rules Language Reference Guide for more information. DBMS usage indicates if the rule accesses a database or not. A value of DB2 indicates that the rule accesses some database, not necessarily just a DB2 database. Refer to the appendix on Forward Engineering and Trace Analysis in the Development Tools Reference Guide for more information. Change these properties to change how the rule works. Refer to the Information Model Reference Guide for details about other rule properties.
3-17
Understanding the Scope of a Rule

To write a rule effectively, you need to know about its scope or data universe the collection of data structures that it can access. A rule does not know about all the data that exists in an application hierarchy. Referring to such a large amount of data takes up too much memory and processing time, and it forces you to qualify references in your rule to views and fields to make those references unique. For a rule to prepare correctly, it must reference only entities that it knows about, which can include a view attached to the rule or other input/ output views linked to immediate child rules and components. Refer to the following example. Example Code for Display_Customer_Detail map DISPLAY_CUSTOMER_DETAIL_I to CUSTOMER_DETAIL converse WINDOW CUSTOMER_DETAIL if EVENT_SOURCE of HPS_EVENT_VIEW = 'UPDATE' map CUSTOMER_DETAIL to UPDATE_CUSTOMER_DETAIL_I use RULE UPDATE_CUSTOMER_DETAIL else map 'NO_CHANGE' to RETURN_CODE of DISPLAY_CUSTOMER_DETAIL_O endif The rule accesses the following data items: DISPLAY_CUSTOMER_DETAIL_I CUSTOMER_DETAIL EVENT_SOURCE UPDATE_CUSTOMER_DETAIL_I RETURN_CODE DISPLAY_CUSTOMER_DETAIL_O
The rule must have these data items associated with it for the rule to prepare. In addition, although the UPDATE_CUSTOMER_DETAIL rule is not a data item, it contains data that the parent rule must know about, and therefore must be a child of DISPLAY_CUSTOMER_DETAIL. The same is true for components and windows that the rule uses.
Mapping Data to a View

A rule can map data to or from any view in its data universe (scope).While technically permitted, it is bad practice for a rule to write data to its own input view or to output views of its child rules or components. Figure 3-6 illustrates the views RULE_B can map to.
3-18
Figure 3-6
What a rule can map to In this diagram, unshaded areas are local views. A rule can map to views in the window it converses. A rule can map to its own output view.
A rule can map to input views of its children.
Mapping Scenario
Given the entities and relationships in Figure 3-7, you can write code for RULE_B to map data from its own input view, output view, or local work view (if it had one). In addition, you can map data from the input or output views (or both) of any rule that RULE_B uses, as well as any window it converses.
Figure 3-7 What a rule can see In this diagram, unshaded areas are local views.
A rule can see input and output views of its children.
A rule can see views in windows it converses. A rule can see its own input and output views.
Note that RULE_B cannot see the input or output views of RULE_A that uses it. All data that RULE_B rule needs to execute must be available to it in its own input view (to which RULE_A maps data before using RULE_B). Also, RULE_B cannot see the input or output views of its grandchild, RULE_E, which RULE_C uses. All you need to know about a rule is what input to give it to get its output. That it might use other rules or gain access to files is irrelevant. Thus RULE_B should not need to see the views of its grandchildren, nor should it be able to.
Caution
Be careful when reusing views. A root view does not have a view as its parent. The AppBuilder environment considers all root views with the same name within the same data scope to be the same view. Mapping information to one such view maps the information to all root views with the same name.
3-19
Other Considerations for Rules
Other Considerations for Rules

Here are other considerations about using a rule: Modeless Windows Considering the Execution Environment Considering Security
Modeless Windows
AppBuilder supports modeless applications, where you can work with multiple windows within an application concurrently. The DETACH qualifier on the USE RULE statement, denotes that the rule will be executed asynchronously to its caller. Control returns to the caller immediately, allowing it to continue processing while the detached rule executes. The detached rule, or its children, can display windows that the user an interact with concurrently with the current window displayed by the caller. Both local and remote rules can be detached. Upon termination, an event is triggered on the calling rule to signify that a detached rule has terminated. Messages can be posted between concurrently executing rules, using the postToChild and postToParent ObjectSpeak methods or equivalent system components. Synchronizing data access is only an issue with the use of Global View.
Considering the Execution Environment

The execution environment of the application affects the operation of the rule. There are different considerations when executing your application depending on the execution environment you choose. Refer to the Deploying Applications Guide for information about preparing the rule for a specific execution environment. Refer to the Debugging Applications Guide for information about how to debug your application and troubleshoot any problems that may be related to the execution environment.
Considering Security
AppBuilder gives you the ability to implement security on an enterprise-wide application in terms of authentication, authorization and encryption. For more information on the mechanisms for security, refer to the Configuring Communications Guide. For information on the query authentication method, refer to the ObjectSpeak Reference Guide.
3-20
CHAPTER
CREATING EVENT-DRIVEN APPLICATIONS
You can build event-driven applications in the AppBuilder environment. An event triggers a message that a rule can capture to determine what to do next. This message can be a request to perform some action, or a notice that some action has been completed. Sending such a message is called posting an event. Event-driven processing uses posted events to control the flow of an application. This section includes descriptions about how to use the various Rules statements to accomplish eventdriven processing: Using the Display (CONVERSE Statement) Using Event-Driven Rules (CASEOF Statements) Using Subscription (POST Statement) This section discusses interface, user, and global events, setting up hierarchies for event processing, providing details about Using the System View in event-driven rules, and provides an Event-driven Processing Example. Event-driven processing generates different types of events depending on where you use it. The following are possibilities: Within a rule - Any end-user action in a window, such as selecting a menu choice or clicking a push button, generates an interface event that is sent back to the rule that converses the window. Between rules within an application - You implement modeless secondary windows by using two system components to pass user events between a detached child process and its parent process. (A rule can detach a secondaryor childrule, which then executes independently of the primaryor parentrule process.) Between applications - Use subscription to pass messages between separate applications. The AppBuilder environment implements subscription to post and receive events between two applications on the same or different machines. Subscription on the same machine is called local eventing. Subscription on physically different machines is called global eventing.
Note
The AppBuilder environment generates system events internally to applications for actions such as timing out or closing a window.
Refer to the Rules Language Reference Guide for detailed information about the statements used to accomplish event-driven processing. Refer to Appendix B, Events Supported in C for events used in event-driven processing of Rules in C. For information on events in Java, refer to the ObjectSpeak Reference Guide.
4-1
Using the Display (CONVERSE Statement)
Using the Display (CONVERSE Statement)

Use a CONVERSE Rules statement to either display a window or block a rule until it receives a global event. This is necessary for C language applications. The CONVERSE statement is not available in Java. Refer to Converse Event for Java. In event processing, a CONVERSE statement on a client either displays a window or blocks a rule until it receives a global event. The CONVERSE statement takes two forms for the respective purposes: CONVERSE WINDOW CONVERSE (null) without any arguments, called a null statement
CONVERSE WINDOW
This form of the CONVERSE statement displays the panel of the named window on the screen and lets end users manipulate its control objects (such as menus and buttons) and enter data into the fields of the window. The rules code execution remains on the CONVERSE WINDOW statement until an event is returned to the rule. That is, the CONVERSE WINDOW statement waits for an event, and when it receives one, continues executing the next statement in the rule. A user manipulating a control object of a window generates an interface event, which returns control to the rule. A system event, global event, or an event from a parent or child rule also causes a rule to leave its waiting state.
CONVERSE (null)
A CONVERSE statement without any arguments blocks a rule from executing until it receives an event. That is, the rule remains in a wait state until an event triggers execution of the statements after the null CONVERSE. Use the null CONVERSE for global eventing to pass messages among rules on the same or different systems. When one rule that includes an event in its hierarchy posts a message, any rule with the same event in its hierarchy receives and can process the message.
Using Event-Driven Rules (CASEOF Statements)

Use nested case statements (CASEOF in Rules) to check for the type of the event in the outermost statement, for the names of specific events in the next level, and for the specific sources in the innermost statement. You can create event-driven rules any of the following ways: Using CASEOF Statements to Receive Events Additional Steps for Modeless Secondary Windows
4-2
Creating Event-driven Applications
Using CASEOF Statements to Receive Events

There are several ways to code rules to receive interface events. The easiest way to do this, to handle multiple types of interface events, is with a set of nested CASEOF statements as follows: 1. 2. 3. 4. 5. Check for the type of event in the outermost CASEOF statement. Check for the names of specific events in the next-level CASEOF statement. Check for specific sources in the innermost CASEOF statement. Place the CASE construct immediately after a CONVERSE WINDOW statement within a DO loop. To control exiting from the loop, set the default push button in the window to a system identifier (HPSID) of EXIT.
The resulting code for capturing an interface event might look similar to the following example for a C language application. For information on the pre-defined, system view HPS_EVENT_VIEW, refer to Using the System View. Example Code Using CASEOF Statements 1 do while EVENT_SOURCE of HPS_EVENT_VIEW <> 'EXIT' 2 converse WINDOW window_name 3 caseof EVENT_TYPE of HPS_EVENT_VIEW 4 case INTERFACE_EVENT 5 caseof EVENT_NAME of HPS_EVENT_VIEW 6 case 'HPS_PB_CLICK' 7 caseof EVENT_SOURCE of HPS_EVENT_VIEW 8 case 'Push button 1' 9 ...other statements... 10 case 'Push button 2' 11 ...other statements... 12 endcase 13 case 'HPS_IMMEDIATE_RETURN' 14 caseof EVENT_SOURCE of HPS_EVENT_VIEW 15 case 'Radio button 1' 16 ...other statements... 17 case 'Radio button 2' 18 ...other statements... 19 endcase 20 endcase 21 case USER_EVENT 22 ...other statements... 23 endcase 24 enddo By simply changing line 4 from CASE INTERFACE_EVENT to CASE SYSTEM _EVENT, you can use the same code to capture system events. See Event-driven Processing Example for a complete example of event-driven processing.
Additional Steps for Modeless Secondary Windows

Capturing user events to implement modeless secondary windows requires more steps than are needed to capture interface or system events. The following are the additional steps needed to capture user events to implement modeless secondary windows: 1. Detaching a Process
AppBuilder 2.1.0 Developing Applications Guide 4-3
2. 3.
Communicating User Events Posting the Events Between Detatched Rules
Detaching a Process
If you want to spawn a modeless secondary window or an independently executing process, insert a USE RULEDETACH statement in the primary (parent) rule. You can use this statement with or without an INSTANCE clause: With an INSTANCE clause: To detach multiple instances of the same rule, use an INSTANCE clause as follows: use RULE rule_name DETACH INSTANCE instance_name To post an event to a specific instance, you must provide the instance name in the EVENT_QUALIFER field of the HPS_EVENT_POST_TO_CHILD component input view. Without an INSTANCE clause: If you omit the INSTANCE clause, you can detach the named child rule only once. Detached rules can retrieve information from databases. A parent rule can have up to four levels of detached rules under it, all of which can access a server or the host. Refer to the Rules Language Reference Guide for more information on how to use a USE RULEDETACH statement. Refer to the System Components Reference Guide for details on the system components. Each detached rule starts a separate process. Any nested rule is part of the executable process of the parent. This distinction is important because events are posted from one executable process to another, not from one rule to another. The top rule in each executable process receives the event. This can cause confusion when posting an event from a detached child (secondary) rule back to a parent (primary) rule that is itself nested. For example, assume root rule RR_1 detaches child rule DR_1. This creates two executable processes, and if DR_1 posts an event to its parent, RR_1 receives it. Similarly, assume that DR_1 now detaches child rule DR_2. This creates a third process, and if DR_2 posts an event to its parent, DR_1 receives it. DR_1 can still post to its parent, RR_1. However, assume a different hierarchy where RR_1 calls a nested rule NR_1, and NR_1 detaches rule DR_1. This creates only two executable processes, because NR_1 is part of RR_1 process. In this case if DR_1 posts an event to its parent, the top rule in the first executable process, RR_1, and not NR_1, receives the event.
Communicating User Events

The HPS_EVENT_POST_TO_CHILD and HPS_EVENT_POST_TO_PARENT system components enable a detached child rule and its parent process to pass events to each other. A receiving rule always receives an event from one of these two components as a user event. A work view that you define transmits data between parent and child executable processes. The input views of both of the posting components contain an EVENT_VIEW field. If this field specifies a work view attached to the sending rule, any data within it is passed to a similarly named work view attached to the receiving rule. Thus, you must attach this view as a work view to the hierarchies of both rules and define the fields it contains.
4-4
Using Subscription (POST Statement)
You cannot use the predefined system view HPS_EVENT_VIEW itself as this work view, because the system overwrites any data you map to it. Before calling one of the components, map the name of this view to the component EVENT_VIEW field. Calling the component places the name of the view into the EVENT_VIEW field of HPS_EVENT_VIEW. For information on the pre-defined, system view HPS_EVENT_VIEW, refer to Using the System View.
Posting the Events Between Detatched Rules

This includes HPS_EVENT_POST_TO_CHILD and HPS_EVENT_POST_TO_PARENT. Refer to the System Components Reference Guide for details on these system components and their input and output fields. HPS_EVENT_POST_TO_CHILD This system component posts an event from a parent (primary) rule to a detached rule. Its input view has the following fields: EVENT_NAME contains the name of the event, which should be meaningful to the child rule and recognizable in the rules code. EVENT_DEST contains the name of the rule that is to receive the event. EVENT_QUALIFIER specifies the instance name of the rule that is to receive the event. The field is empty if the child is not detached as an instance. EVENT_VIEW contains the name of a work view that contains data you want to send to the child rule. EVENT_PARAM sends any additional information about the event. HPS_EVENT_POST_TO_PARENT This system component sends an event to the top rule in the executable process of its parent. Its input view has the following fields: EVENT_NAME is the name of the event you want to send EVENT_VIEW is the name of a work view that contains data you want to send to the parent rule EVENT_PARAM sends any additional information about the event

There are two types of subscription. Subscription on the same machine does not need a network and is called local eventing. Subscription on physically different machines employ a client/server network and is called global eventing. Global eventing is available for C applications only. Local eventing is available for Java thick clients and C applications. AppBuilder applications can subscribe for a global event that can be fired from the same or a different application; the event can also be from the same machine or a remote machine. All the subscribing applications use the Physical Event entity within AppBuilder to register for an event. When an event is
4-5
fired using the Physical Event entity, it is delivered to all the applications that registered for this event. Global eventing is a flexible approach to asynchronous messaging whereby: A client or service makes data available to the system in response to periodic run-time events The system makes that data available to another program for as long as the program subscribes to the data. Once your program posts the event to the network, its done. The system informs rules registered for the event that the data are available to be retrieved. After the rule receives and processes the data, it is free to resume normal functioning. Rules de-register for events on exit. Each AppBuilder site defines the event itself. You can use subscription to pass events between different applications. Whenever a rule with a particular physical event in its hierarchy posts a message, any rule with the same event in its hierarchy can receive and process the message. Use POST Rules statements to post a message to another application, or to a different rule in the same application. The view attached to the event contains the text of the message. This topic explains: Setting up a Posting Rule Hierarchy Setting up a Receiving Rule Hierarchy Using Global Event in Java Refer to the Configuring Communications Guide for information about configuring machines and servers on other machines.
Setting up a Posting Rule Hierarchy

Figure 4-1 shows the hierarchy for the posting rule.
Figure 4-1 Posting rule hierarchy
Follow these steps to set up the hierarchy: 1. 2. 3. Right-click on the rule in the hierarchy and click on Insert > Physical Event. Create and name the event. Right-click on the physical event and select Relationship Properties from the pop-up menu. In the Properties Rule triggers Event window, change the Trigger Type field to Explicit post and click on OK.
The implicit before invocation and implicit after invocation properties on this relationship (Rule triggers Event) refers to implicit eventing.
Note
4. 5.
Add a view as a child of the physical event. Set the View usage properties of the view to Work View. Attach fields to the work view corresponding to the data you want to pass as the message.
Example Posting Rule Code Map data to the work view and use the POST EVENT statement in the posting rule to send the message: map BALANCE_HIGH of BALANCE_QUERY_I to BALANCE_HIGH of ACCOUNT_INFO of THRESHHOLD_MET map BALANCE_CLOSE of BALANCE_QUERY_I to BALANCE_CLOSE of ACCOUNT_INFO of THRESHHOLD_MET
4-6 Creating Event-driven Applications
post event THRESHHOLD_MET
Setting up a Receiving Rule Hierarchy

Figure 4-2 shows the hierarchy for the receiving rule.
Figure 4-2 Receiving rule hierarchy
Follow these steps to set up the hierarchy: 1. 2. 3. 4. Right-click on the rule in the hierarchy and click on Insert > Physical Event. Name the event. Right-click on the physical event and select Relationship Properties. In the Properties Rule triggers Event window, change the Trigger Type field to Explicit converse and click on OK. Attach a view to the rule and name it HPS_EVENT_VIEW (the predefined system view).
For information on the pre-defined, system view HPS_EVENT_VIEW, refer to Using the System View.
Receiving Rule Code

Use the predefined system view HPS_EVENT_VIEW in the receiving rule to capture the message, just as you would for an event internal to the application. Check for the event using a standard CASEOF statement. A global event has an EVENT_NAME of whatever name you gave the physical event. The other HPS_EVENT_VIEW fields are empty. For information on the pre-defined, system view HPS_EVENT_VIEW, refer to Using the System View. To handle multiple global events, include the CONVERSE statement inside a loop. You can use any condition to terminate the loop, including another global event, as the following example illustrates. The system registers the rule for the event when the rule is started, and deregisters it on exit. Example Code For Handling Multiple Global Events do while EVENT_NAME of HPS_EVENT_VIEW <> APPLICATION_CLOSED converse caseof EVENT_NAME of HPS_EVENT_VIEW case THRESHHOLD_MET ...statements endcase enddo
Note
Although the example above uses a null CONVERSE statement, a CONVERSE WINDOW statement is also unblocked when it receives a global event. That is, the statements following the CONVERSE WINDOW statement begin executing when a global event is received.
4-7
Using Global Event in Java

The Java client environment includes support for global eventing within a Java virtual machine (JVM). All applications running within the same JVM can publish and subscribe for events. This will be extended to true global eventing support beyond one JVM using Java NetEssential and Java Messaging Service (JMS) in a future release. If the Java client is invoked from the workbench, by default a new JVM is loaded to execute each application. The appbuilder.ini setting NEW_JVM_FROM_MENU can be set to FALSE so all the invoked applications share the same JVM and the global event can be used between these applications. Java uses the same syntax to post an event as described in Setting up a Posting Rule Hierarchy. The following call sends the message to all the subscribed applications: post event THRESHHOLD_MET And alternatively, an ObjectSpeak method post could be used on the GlobalEvent object by: THRESHHOLD_MET.post() And on the subscribing end, the application can use either an event procedure or a Converse Event to handle the event. If the pre-defined system view, HPS_EVENT_VIEW, is attached to the subscribing rule, an event listener is automatically added to the rule and a ConverseEvent is triggered on receiving this event. The EVENT_NAME of the HPS_EVENT_VIEW will have the name of the event. For information on ObjectSpeak syntax, refer to the ObjectSpeak Reference Guide. For information on the pre-defined system view, HPS_EVENT_VIEW, refer to Using the System View. Alternatively, an event procedure can be used to process the event. It can be defined explicitly for a particular physical event. Example Code: Specific Event proc p for post object THRESHHOLD_MET ( o object type PostEvent ) ...statements endproc The GlobalEvent type can be used in the event procedure definition to handle all the physical events defined under that rule, by using the following syntax: Example Code: Global Event proc p for post object type GlobalEvent ( o object type PostEvent ) ...statements endproc The event procedure also can be defined for certain selected physical events defined under the rule by using the following syntax: Example Code: Selected Event dcl //forward declaration p proc for post object THRESHHOLD_MET ( o object type PostEvent ); enddcl
4-8
Using the System View
proc p ...statements endproc

The predefined system view, HPS_EVENT_VIEW, is a work view for building an application to handle events. This view implements event-driven processing by capturing information about an event, including its type, name, and source. This topic includes: Understanding the Fields of the System View Attaching the System View to a Rule Hierarchy
Understanding the Fields of the System View

The hierarchy of the predefined system view, HPS_EVENT_VIEW, is shown in Figure 4-3.
Figure 4-3 System view hierarchy
This view contains the fields that describe an event and these are summarized in Table 4-1.
Table 4-1 Fields that describe an event Description The EVENT_TYPE is a SMALLINT (small integer) field denoting the type of event generated. The types of events to which the SMALLINT values in the HPS_EVENT_TYPE set correspond are: 0 - System event 1 - Interface event 2 - User event The EVENT_NAME field contains the event name. Interface event names describe the action taken. For example, the EVENT_NAME field is HPS_PB_CLICK if a user clicks a push button. System events have a similar nomenclature.
Field Name
EVENT_TYPE
EVENT_NAME
4-9
Table 4-1
Fields that describe an event Description The EVENT_SOURCE field contains values for interface and user events: For interface events, EVENT_SOURCE contains the system identifier (HPSID) of the window object that is the event focus. For example, if a user clicks a push button, the EVENT_SOURCE field contains the push button HPSID. The system identifier (HPSID) is case sensitive. The Rules Language code for checking the EVENT_SOURCE must match the system identifier (HPSID) exactly as it is entered in Window Painter for the window object. For user events, the EVENT_SOURCE field contains the name of the child (secondary) rule that sent the event. For example, if a child rule uses the HPS_EVENT_POST_TO_PARENT component to send an event to its parent, EVENT_SOURCE contains the name of the child rule. The EVENT_SOURCE field is empty when a parent posts an event to a child: For system events For global events The EVENT_QUALIFIER field qualifies the event source when a parent posts a user event to a child. This field contains the instance of the rule (if applicable) specified in the EVENT_SOURCE field. Thus, this field is empty when a parent posts an event to a child detached without an instance name. The EVENT_VIEW field contains the name of the view that received data for user events only. The EVENT_PARAM field contains any additional description of the event, which can be useful if you have detached multiple instances of the same rule.
Field Name
EVENT_SOURCE
EVENT_QUALIFIER
EVENT_VIEW EVENT_PARAM
Attaching the System View to a Rule Hierarchy

You must attach the predefined system view HPS_EVENT_VIEW to the correct place in your application hierarchy. Attach the view as a child of any rule that receives events. For example, attach this view to any rule that converses a window. Change the View usage property in the rule owns View relationship to Work View. Figure 4-4 illustrates the correct placing of this view in the hierarchy and opening the relationship properties window to set the view usage.
4-10
Figure 4-4
System view in hierarchy and relationship properties
Right-click on the view and select Relationship Properties
Event-driven Processing Example

In the hierarchy in Figure 4-5, the CUSTOMER_LIST rule is the primary rule or parent rule. Its window contains a list box of current customers. Each time a user selects a customer, either by double-clicking a row in the list box or by clicking a Select push button, the CUSTOMER_LIST rule detaches an instance of the CUSTOMER_DTL rule for that particular customer. This makes the CUSTOMER_DTL rule the secondary or detached rule to the CUSTOMER_LIST rule, so several different customer detail windows or instances can be displayed at the same time. The CUSTOMER_WK view transmits data between the parent rule, CUSTOMER_LIST, and the child executable process, CUSTOMER_DTL. The CUSTOMER_DTL window contains a series of editable fields. Users can change the fields with an Update menu choice. A nested, modal window (not shown here) displays the results of the update action. Figure 4-5 shows the hierarchy for the primary rule in the example program. The Rules code for the primary (parent) is listed and partially explained below. A partial explanation of the code for the secondary (child) rules follows the primary rule.
4-11
Figure 4-5
Hierarchy of example Primary Rule (CUSTOMER_LIST)
Secondary Rule (CUSTOMER_DTL)
Example Code: Primary Rule This is an example of code using the Customer_List rule. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 *> CUSTOMER_LIST Rule <* dcl TEMP_PIC_FIELD PIC'999'; TEMP_PIC_VIEW VIEW CONTAINS temp_pic_field; TEMP_INDEX INTEGER; enddcl do while EVENT_SOURCE of HPS_EVENT_VIEW <> 'EXIT' use RULE CUSTOMER_SQL_FET map CUSTOMER_OCC of CUSTOMER_SQL_FET_O to CUSTOMER_OCC of CUSTOMER_LIST_W converse WINDOW CUSTOMER_LIST caseof EVENT_TYPE of HPS_EVENT_VIEW case INTERFACE_EVENT caseof EVENT_NAME of HPS_EVENT_VIEW case 'HPS_IMMEDIATE_RETURN' OVERLAY EVENT_PARAM of HPS_EVENT_VIEW to TEMP_PIC_VIEW map TEMP_PIC_FIELD of TEMP_PIC_VIEW to EMP_INDEX map CUSTOMER_ID of CUSTOMER_OCC of CUSTOMER_LIST_W(TEMP_INDEX) to CUSTOMER_ID of CUSTOMER_SQL_SEL_I use RULE CUSTOMER_SQL_SEL map CUSTOMER of CUSTOMER_SQL_O to CUSTOMER of CUSTOMER_DTL_I use RULE CUSTOMER_DTL DETACH INSTANCE endcase case USER_EVENT caseof EVENT_NAME of HPS_EVENT_VIEW case 'UPDATE CUSTOMER RECORD' map CUSTOMER of CUSTOMER_WK to CUSTOMER of CUSTOMER_SQL_UPD_I use RULE CUSTOMER_SQL_UPD map 'UPDATE RESULTS' to EVENT_NAME of HPS_EVENT_POST_TO_CHILD_I map 'CUSTOMER_DTL' to EVENT_DEST of
18 19 20 21 22 23 24 25 26 27 28
4-12
29
30 31 32 33 34 35 36 37 38
HPS_EVENT_POST_TO_CHILD_I map CUSTOMER_ID of CUSTOMER of CUSTOMER_WK to EVENT_QUALIFIER of HPS_EVENT_POST_TO_CHILD_I if SQL_RETURN_CODE of CUSTOMER_SQL_UPD_O = 0 map 'SUCCESSFUL' to EVENT_PARAM of HPS_EVENT_POST_TO_CHILD_I else map 'UNSUCCESSFUL' to EVENT_PARAM of HPS_EVENT_POST_TO_CHILD_I endif use COMPONENT HPS_EVENT_POST_TO_CHILD endcase endcase enddo
Example Code: Primary Rule Details The primary rule captures interface and user events by checking almost every field in the predefined system view HPS_EVENT_VIEW with a series of nested CASEOF statements (refer to lines 11 14 and lines 22 24): 11 caseof EVENT_TYPE of HPS_EVENT_VIEW 12 case INTERFACE_EVENT 13 caseof EVENT_NAME of HPS_EVENT_VIEW 14 case 'HPS_IMMEDIATE_RETURN' ...other statements... ...other statements... 22 case USER_EVENT 23 caseof EVENT_NAME of HPS_EVENT_VIEW 24 case 'UPDATE CUSTOMER RECORD' ...other statements... (You can reduce the number of nested CASEOF statements by checking only the EVENT_SOURCE and EVENT_NAME fields.) When the primary (parent) rule receives a user event, it copies the data in the specified child work view to the parent work view of the same name (line 25). 25 map CUSTOMER of CUSTOMER_WK to CUSTOMER of CUSTOMER_SQL_UPD_I
The primary rule then calls the appropriate SQL update rule (line 26). 26 use RULE CUSTOMER_SQL_UPD
The CUSTOMER_ID of the CUSTOMER work view that was just received is used to determine which child the event is sent to (lines 27 through 29). After the update is completed, the HPS_EVENT_POST_TO_CHILD component issues an event to notify the child that sent the update event of the results (line 27). 27 map 'UPDATE RESULTS' to EVENT_NAME of HPS_EVENT_POST_TO_CHILD_I
To avoid adding another work view to the hierarchy, you can convert the return code sent to the child to a CHAR format and place it in the EVENT_PARAM field of the component input view.
4-13
Example Code: Secondary Rule The Rules Language code for the secondary (child) rule follows. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 *> CUSTOMER_DTL Rule <* map CUSTOMER of CUSTOMER_DTL_I to CUSTOMER of CUSTOMER_DTL_W do while EVENT_SOURCE of HPS_EVENT_VIEW <> 'EXIT' converse WINDOW CUSTOMER_DTL caseof EVENT_NAME of HPS_EVENT_VIEW case 'HPS_MENU_SELECT' caseof EVENT_SOURCE of HPS_EVENT_VIEW case 'UPDATE' map CUSTOMER of CUSTOMER_DTL_W to CUSTOMER of CUSTOMER_WK map 'UPDATE CUSTOMER RECORD' to EVENT_NAME of HPS_EVENT_POST_TO_PARENT_I map 'CUSTOMER_WK' to EVENT_VIEW of HPS_EVENT_POST_TO_PARENT_I use COMPONENT HPS_EVENT_POST_TO_PARENT endcase case 'UPDATE RESULTS' map 'The update was' ++ EVENT_PARAM of HPS_EVENT_VIEW ++ '.' to TEST1 of MESSAGE_I use RULE MESSAGE NEST endcase enddo
Example Code: Secondary Rule Details The secondary (child) CUSTOMER_DTL rule posts the user event, UPDATE CUSTOMER RECORD. The record to be updated is sent to the parent using the CUSTOMER_WK work view (lines 5 to 18). When a user selects the Update menu choice, the child rule maps the altered data to the work view (line 9) and then puts the work view name in the EVENT_VIEW field of the HPS_EVENT_POST_TO_PARENT component input view (lines 10 and 11). 9 10 11 map CUSTOMER of CUSTOMER_DTL_W to CUSTOMER of CUSTOMER_WK map 'UPDATE CUSTOMER RECORD' to EVENT_NAME of HPS_EVENT_POST_TO_PARENT_I map 'CUSTOMER_WK' to EVENT_VIEW of HPS_EVENT_POST_TO_PARENT_I
When the child rule receives the UPDATE RESULTS event, the EVENT_PARAM field is tested and a nested rule displays an appropriate message (lines 14 16). 14 15 16 case 'UPDATE RESULTS' map 'The update was' ++ EVENT_PARAM of HPS_EVENT_VIEW ++ '.' to TEST1 of MESSAGE_I use RULE MESSAGE NEST
4-14
CHAPTER
HANDLING DISPLAY COMPONENTS
Several types of display components can be used when developing applications in AppBuilder. These include: Standard Display Rule Display Rule for Thin (HTML) Client Non-Display Rule for Java Client Display Rule with Third-Party Java Bean User Event Handled by Java Bean Rule Controlling Converse Window Converse Event for Java Domain Sets for Window Objects Use the Window Painter to create the presentation components for your AppBuilder application. For more information on the use of the Window Painter, refer to the Development Tools Reference Guide. To convert existing C applications to Java, you must understand how to handle a Converse Event for Java.
Standard Display Rule

For distributed applications, rules that display windows ( display rules) have a special structure. Specifically, display rules consist only of the following: A declaration (DCL) section for local variables Event procedures Standard non-event procedures The display rule typically contains a declaration section for variables used in the rule. This is typically followed by the window initialize and terminate event procedures, followed by additional event procedures to handle push button clicks, menu item selections, and other user actions. It might also contain some standard procedures, which would be called by code within the rule itself (rather than in response to user actions).
5-1
Display Rule for Thin (HTML) Client
Example of Display Rule dcl variable1 OBJECT TYPE char enddcl proc for Click OBJECT CloseButton ( e object type ClickEvent ) MAIN_WINDOW.Terminate endproc
Display Rule for Thin (HTML) Client

For thin-client (servlet-based, client-side) applications, the rules execute in a Web or application server environment; therefore, certain considerations apply for using display rules. The system sends all display information to a browser in HTML format via the HTTP protocol. Even though this is a stateless, sessionless protocol, the AppBuilder applications can execute like a traditional GUI-based applications because the execution state is preserved in a cache or saved in the local file system. Before sending the HTML to the Web browser, the AppBuilder rule saves or caches the context information to free up the resources on the Web server. The saved or chached information includes the view and the currently active rule stack.When the Web browser sends a request back, the system restores the AppBuilder rule stack and reloads or reactives the last display rule. After reloading the rules, the application invokes the appropriate event procedure. The caching and restoring of the state of execution between requests is completely transparent to the application. In thin-client applications, all display rules must be event-driven rules with the following default procedures or events. Rule or Window Initialize is invoked when the window is loaded for the first time Rule or Window Terminate must be called by the rule before exiting RuleEnd must be called by the rule before exiting ChildRuleEnd must be called by parent rule to conclude processing of the child rule The following are the conventions for the thin-client rules. A root rule must be an event-driven rule. Only an event-driven rule can call another event-driven rule using Detach. An event-driven rule can call any other procedure rule. The procedure rule can call another procedure rule including the remote rules but cannot call another event rule as in the second condition.
5-2
Handling Display Components
Non-Display Rule for Java Client
Non-Display Rule for Java Client

In the Java client, rules that do not display windows are written in the same way as in earlier versions of the product; therefore, non-display rules can consist of: A declaration (dcl) section for local variables The rule body (which contains standard procedural code) Standard (non-event) procedures In general, an AppBuilder Java client program can consist of display rules that use the new rule structure, and non-display rules that use standard Rules Language. Example of Non-Display Rule in Java Here is an example of a rule that uses a window with a push button. The window closes when the push button is pressed. The system identifier (HPSID) of the push button is CloseButton. The event procedure would be: proc for Click OBJECT CloseButton ( e object type ClickEvent ) MAIN_WINDOW.Terminate endproc
Display Rule with Third-Party Java Bean

The Java client supports the use of third-party Java beans directly in the rules code. Here is an example of a display rule using a third-party Java bean. Example of Display Rule with Java Bean This example demonstrates a rule that uses the Java tree control JTree bean. dcl java_tree OBJECT TYPE javax.swing.JTree of javabeans; enddcl proc for Initialize OBJECT NC_BEAN_TEST_W (e object type InitializeEvent) *> create the Java Bean instance <* map new javax.swing.JTree to java_tree *> set properties on the Java Bean <* java_tree.SetSize(100,100) java_tree.SetLocation(10,10) NC_BEAN_TEST_W.AddChild(java_tree) *> make the Java Bean visible <* NC_BEAN_TEST_W.SetVisible(true) endproc proc for Terminate OBJECT NC_BEAN_TEST_W (e object pointer to TerminateEvent) *> close the window <* NC_BEAN_TEST_W.Terminate endproc
5-3
User Event Handled by Java Bean
User Event Handled by Java Bean

The following is an example of registering events for Java classes. This rule uses two different timer objects: one is the AppBuilder internal Timer and one is from the javax.swing package (Java Swing class, the set of graphical interface components). Example of User Event with Java Bean This is an example of an event-handling procedure for button click events. dcl javaTimer OBJECT TYPE 'javax.swing.Timer'; nullActionListener object type 'java.awt.event.ActionListener'; enddcl proc javaTimerProc for ActionPerformed Listener java.awt.event.ActionListener object javaTimer (e object type 'java.awt.event.ActionEvent') *> do what needs to be done when timer triggers <* map FD_INT + 1 to FD_INT endproc proc ExitClickProc FOR click object EXIT (e object type ClickEvent) WN_JAVABEAN_DEMO.terminate endproc proc ActivateClickProc FOR click object ACTIVATE (e object type ClickEvent) map new 'javax.swing.Timer'( 100, nullActionListener ) to javaTimer *> dynamically add event procedure to handle timer events <* Handler javaTimer( javaTimerProc ) *> set timer properties and start the timer<* javaTimer.SetDelay( 1000 ) javaTimer.SetRepeats( True ) javaTimer.Start map false to ACTIVATE.Enabled endproc
5-4
Rule Controlling Converse Window

With a traditional graphical user interface (GUI), client-side applications run the client side rules, display the GUI windows, and wait for the user inputs. After receiving user input, the client-side rules continue processing in one of the following methods: Through callbacks to event procedures defined within the rules From the statement following a Converse Window in a converse-driven rule So, in traditional GUI-based AppBuilder applications, there is always a rule stack (a sequence of AppBuilder rules calling other rules) and the current execution state is maintained. A rule may control a converse window. CONVERSE is a Rules Language verb that means display when applied to a user-interface window or print when applied to a report. For example, a simple series of actions in a typical business application might include the following: 1. 2. 3. 4. Copy the detailed information of a customer from a database to a window. Display the window to show the data. If the user selects Update, invoke another module to write the data to a file and return a code to the initiating module to indicate the changes from an end user. If the user selects Cancel, return a code to indicate that the user did not make any changes.
Example: Converse Window Control Pseudocode In pseudocode, the above tasks might look like this: PASS Customer detail information to Customer detail window data DRAW Window if User selects 'UPDATE' then PASS Customer detail window data to Update module CALL Update module if Update module fails PASS Set of customer detail error messages to Window message module PASS Appropriate message IN Set of customer detail error messages to Window message module PASS Customer detail window data to Window message module CALL Window message module else PASS Update code to Invoking module endif else PASS No change code to Invoking module endif Rules Language Code Here is a rule that accomplishes the same tasks. The words connected with underscores are specific instances of AppBuilder object types. The lines above are numbered so we can explain significant elements in the Rules Language statements by stepping through the control logic a few lines at a time. The line numbers correspond to the line numbers in the Rules Language source code. 1 map DISPLAY_CUSTOMER_DETAIL_I to CUSTOMER_DETAIL
5-5
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
converse window CUSTOMER_DETAIL_WINDOW caseof EVENT_NAME of HPS_EVENT_VIEW case 'HPS_MENU_SELECT' caseof EVENT_SOURCE of HPS_EVENT_VIEW case 'UPDATE' map CUSTOMER_DETAIL to UPDATE_CUSTOMER_DETAIL_I use RULE UPDATE_CUSTOMER_DETAIL if RETURN_CODE of UPDATE_CUSTOMER_DETAIL_O = 'FAILURE' map CUSTOMER_DETAIL_FILE_MESSAGES to MESSAGE_SET_NAME of SET_WINDOW_MESSAGE_I map UPDATE_FAILED in CUSTOMER_DETAIL_FILE_MESSAGES to TEXT_CODE of SET_WINDOW_MESSAGE_I map CUSTOMER_DETAIL to WINDOW_LONG_NAME of SET_WINDOW_MESSAGE_I use COMPONENT SET_WINDOW_MESSAGE else map 'UPDATE' to RETURN_CODE of DISPLAY_CUSTOMER_DETAIL_O endif case other map 'NO_CHANGE' to RETURN_CODE of DISPLAY_CUSTOMER_DETAIL_O endcase endcase
Explanations
1 map DISPLAY_CUSTOMER_DETAIL_I to CUSTOMER_DETAIL DISPLAY_CUSTOMER_DETAIL is the name of the rule. The first line uses the MAP statement to copy the data in the rule input view, DISPLAY_CUSTOMER_DETAIL_I, into the view of a window, CUSTOMER_DETAIL_WINDOW. The Rules Language assignment statement map 10 to A is analogous to an assignment statement in a traditional programming language, such as A = 10 CUSTOMER_DETAIL_WINDOW is the name of the window in which the dataa record for one customeris displayed to the user. CUSTOMER_DETAIL is the name of the view of the window. 2 converse window CUSTOMER_DETAIL_WINDOW
CONVERSE is a Rules Language verb that means display when applied to a user-interface window or print when applied to a report. The rule issues the converse statement to display the window with the copied data to the user. The processing of a rule is suspended until that rule registers an event. For example, when the user clicks a button on the panel, codes identifying that button are placed in the fields of the predefined system view HPS_EVENT_VIEW and control returns to the rule.
5-6
The processing resumes at the line after the CONVERSE statement (line 3). 3 4 5 6 caseof EVENT_NAME of HPS_EVENT_VIEW case 'HPS_MENU_SELECT' caseof EVENT_SOURCE of HPS_EVENT_VIEW case 'UPDATE'
Line 6 checks a field value of the HPS_EVENT_VIEW to see if the user selected the Update menu choice. (HPS_EVENT_VIEW is the work view of that rule that captures events from the end user.) EVENT_NAME and EVENT_SOURCE are two fields of HPS_EVENT_VIEW that define an event. If the value of the EVENT_SOURCE field is UPDATE, the rule copies the data in the window view to the input view of the rule that handles the file access (UPDATE_CUSTOMER_DETAIL), and then calls it with the use RULE statement. 7 8 9 map CUSTOMER_DETAIL to UPDATE_CUSTOMER_DETAIL_I use RULE UPDATE_CUSTOMER_DETAIL if RETURN_CODE of UPDATE_CUSTOMER_DETAIL_O = 'FAILURE'
UPDATE_CUSTOMER_DETAIL is a second rule that performs file updates. UPDATE_CUSTOMER_DETAIL_I is its input view and UPDATE_CUSTOMER_DETAIL_O is its output view. Once processing control returns from UPDATE_CUSTOMER_DETAIL, the rule checks the value of the field in an output view that passes return codes (RETURN_CODE). The IF...ELSE...ENDIF is similar to statements from other programming languages: when the condition after IF is true, the statements between it and ELSE execute. Otherwise, the statements between ELSE and ENDIF execute. If the return code does not indicate failure, control skips to the ELSE clause on line 17 (described below). 10 11 12 13 14 15 map CUSTOMER_DETAIL_FILE_MESSAGES to MESSAGE_SET_NAME of SET_WINDOW_MESSAGE_I map UPDATE_FAILED in CUSTOMER_DETAIL_FILE_MESSAGES to TEXT_CODE of SET_WINDOW_MESSAGE_I map CUSTOMER_DETAIL to WINDOW_LONG_NAME of SET_WINDOW_MESSAGE_I
If the return code is FAILURE, the SET_WINDOW_MESSAGE system component displays a customized error message for the user in a secondary window. SET_WINDOW_MESSAGE_I is its input view. CUSTOMER_DETAIL_FILE_MESSAGES is a set of dialog messages and UPDATE_FAILED is a specific error message. 17 18 else map 'UPDATE' to RETURN_CODE of DISPLAY_CUSTOMER_DETAIL_O
If the return code does not indicate failure, control skips to the ELSE clause on line 17. The rule copies the character literal UPDATE into the RETURN_CODE field of the output view, DISPLAY_CUSTOMER_DETAIL_O. 20 21 case other map 'NO_CHANGE' to RETURN_CODE of DISPLAY_CUSTOMER_DETAIL_O
If the value of the EVENT_SOURCE field is anything other than UPDATE, the rule just copies the character literal NO_CHANGE into the RETURN_CODE field of DISPLAY_CUSTOMER_DETAIL_O.
5-7
Converse Event for Java
Converse Event for Java

Java does not support the converse window statement used in display rules. To ease the conversion of an application from C to Java, a Converse event has been created in AppBuilder. The Converse event is an event on the window object that triggers exactly the same places where converse window now returns control to the calling rule. It also automatically updates the predefined system view HPS_EVENT_VIEW. Example Converse Event for Java An application based on the Converse Window statement is converted by moving the contents of the DO-WHILE loop surrounding the converse window into a Converse Event procedure. The exit condition that was originally coded in a DO-WHILE is now in an IF-ENDIF. The CASE statements are now inside a procedure (PROC). Original Converse Window Code for C: do while EVENT_SOURCE of HPS_EVENT_VIEW <> Exit converse WINDOW CUST_PD_DIS caseof EVENT_SOURCE of HPS_EVENT_VIEW case QUERY . . . case NEW . . . endcase enddo
Equivalent Converse Event Code for Java: proc for Converse OBJECT CUST_PD_DIS (e object type ConverseEvent) if EVENT_SOURCE of HPS_EVENT_VIEW==Exit CUST_PD_DIS.terminate endif caseof EE caseof EVENT_SOURCE of HPS_EVENT_VIEW case QUERY . . . case NEW . . . endcase endproc
5-8
Domain Sets for Window Objects

For several window objects you can store a list of information in a set and then display those values in a combo box, read-only edit field, or a read-only table column. This section discusses the following: Defining Domain for a Combo Box Defining Domain for a Read-Only Edit Field Defining Domain for a Read-Only Table Column
Defining Domain for a Combo Box

There are two ways to specify a domain of values that can be displayed in a combo box: Define Sets with Values Use Occurring Views
Define Sets with Values

One way to define a domain of values that can be displayed in a window object is to define a set containing the possible values. For information about creating sets, refer to the section on Set Builder in the Development Tools Reference Guide.
Table 5-1 Example set values Displayed value Monday Tuesday Wednesday Thursday Friday Saturday Sunday
Coded value 1 2 3 4 5 6 7
1. 2. 3.
Create the Set in the heirarchy. Place the Set object under the Window object in the hierarchy of the window that contains the combo box. Drag the set object icon from the hierarchy into the window in Window Painter and Window Painter automatically creates a combo box with the Domain property value assigned to the Set object. Or, Place a combo box on the window in Window Painter and set the Domain property value for the combo box.
4.
Specify the current value (one of the values of the set) for that combo box in the Link property, using the Window Painter properties panel to enter the Link property for the combo box.
5-9
Use Occurring Views

One way to define a domain of values that can be displayed in a combo box is to use occurring views with multiple fields. Each field contains a possible value that is displayed in the combo box. 1. 2. 3. Define the View and subordinate Fields in the Hierarchy window. Place the View object under the Window object in the hierarchy of the window that contains the combo box. Drag the View object icon from the hierarchy into the window in Window Painter. Window Painter automatically creates a combo box with the Domain property value assigned to the View object. Or, Place a combo box on the window in Window Painter and set the Domain property values for the combo box. Specify the current value (one of the fields of the view) for that combo box in the Link property. Use the Window Painter properties panel to enter the Link property for the combo box.
4.
Defining Domain for a Read-Only Edit Field

Similar to Defining Domain for a Combo Box, you can specify a domain for a read-only edit field in a window in Window Painter. This is supported only for Java applications. Follow the procedure for Define Sets with Values, but instead of placing the set under a window, place it under a field.
Defining Domain for a Read-Only Table Column

For Java applications only, similar to Defining Domain for a Combo Box, you can specify a domain for a read-only column of a table or multicolumn list box (MCLB) in a window in Window Painter. Follow the procedure for Define Sets with Values, but instead of placing the set under a window, place it under a field.
5-10
CHAPTER
ADDING USER COMPONENTS
You can write your own user components and incorporate existing procedures into your AppBuilder application. A user component is similar to a rule it is a piece of an application you write to enable the application to do a specific unit of work. Like a rule, a component is a repository object that you can reuse within your application. Unlike a rule, which you write in the Rules Language, you code a component in the native language of the target environment. These tasks include: Deciding When to Add a Component Guidelines for Components Specifying Component Includes Directory Adding a User Component Writing a Java User Component Writing a C User Component Calling a C Component from Java Using Sample Component Code Data Type Comparison A C component with an execution environment of a PC and IBM Mainframe (CICS) executes on a workstation only. A C component with an execution environment of IBM Mainframe Batch (MVS) executes on the host only, and is the host-only environment that supports C components. If you are writing a component to run on the host, its source can be written in C, COBOL, PL/I, or assembler. For information on writing host user components, refer to the Enterprise Application Guide. Do not confuse user components that you write with the system components that the AppBuilder product provides in the default repository. System components perform various specialized functions, such as message display processing for your user interface. For more information about system components, see Chapter 7, Adding System Components and refer to the System Components Reference Guide.
Deciding When to Add a Component

Typically, 20% of the statements and terms of a native language cover 80% of normal programming tasks. Rules Language is designed to match the functionality of that 20%which means it meets programming requirements 80% of the time.
6-1
Guidelines for Components
Advantages of Using Components

Components can provide functionality the Rules Language lacks because they are written in the native language of the target platform. There are four major reasons to use a component: Platform-specific functions. Because the Rules Language is portable, it does not support platformspecific functions such as transaction time stamping. Create a user component for these functions. Native file access. This is related to platform-specific functions. The Rules Language supports file access through embedded SQL calls, but this may not work for every file. If your application accesses such a file, you need to write a user component. User components can contain embedded SQL as well. Sophisticated mathematical functions. The Rules Language does not support calculus. If your application requires complex math functions, you need to write a user component. Integrating existing code. If you have an existing non-AppBuilder module, you can incorporate it directly into your application as a user-written component, as opposed to recoding it in the Rules Language.
Disadvantages of Using Components

Generally, you should use AppBuilder rules instead of components. Many of the advantages of working in the AppBuilder environment are not applicable to components in your application, because: Unlike rules, components may not be portable from one target environment to another. Components are not as easy to reuse or edit as rules. You must have a developer fluent in the specific language of the component. You cannot use AppBuilder tools on components in your application. You need a different set of editing and debugging tools. You must manually update the information of a component in the repository when you re-prepare it, unless you define its input and output views to the repository.
Guidelines for Components

To write effective components, we recommend that you follow these two guidelines: Design for Reuse Keep the Code Current
Design for Reuse

It is important to limit each component to one logical unit of work. This maximizes its potential for reuse. For example, suppose you have three basic tasks to perform: 1. 2. Apply search criteria to a file to retrieve a record. Perform a calculation on the record data.
6-2
Adding User Components
Specifying Component Includes Directory
3.
Timestamp the results of the calculation.
If you define one component to accomplish all these tasks, you can reuse that component only if you need to perform all three tasks again in precisely the same sequence. If elsewhere you need only to perform a portion of the task (that is, the calculation) you cannot reuse the component. If you define a separate component for each task, you can reuse the components individually, as needed, throughout the application.
Keep the Code Current

Because a component is really a traditional program, the pertinent data definitions must be declared in the code. Changing the data definition in the component input view (for example) does not automatically update the code. Generally, you must manually keep the component code and view data definitions consistent.
Specifying Component Includes Directory

You can specify the directory that AppBuilder looks to find the user component includes, such as include files, header files, etc. In the AP <platform> section of the system initialization file, hps.ini, there is a place to set the directory for any component includes. The name of the section depends on the platform that you are using; it may be the AP Windows-NT section or the AP Unix section. The setting is C_INC_DIR. This was added as an enhancement for Windows. Example Code The default value is the temporary files directory under the product installation main directory such as c:\AppBuilder\TEMP. You may type in any path, including drive letter and directory structure. [AP Windows-NT] C_INC_DIR=D:\User\AppBuilderComps\Includes
Adding a User Component

To add a user component, you must follow these steps. 1. 2. 3. Creating or Updating the Application Hierarchy Inserting the Component in the Calling Rule Creating and Editing the Component Source Code
Another way to implement user components, is to use the Component Folder object and link external code objects through that folder. Refer to the Development Tools Reference Guide for a description of adding a component through a component folder.
6-3
Adding a User Component
Creating or Updating the Application Hierarchy

To update the application hierarchy to use a component, do the following: 1. 2. 3. 4. Open your application hierarchy in the Hierarchy window. Add a component as a child to the rule that calls the component. Name the component. Select the correct execution environment attribute for the component. If you are using implementation names, provide an implementation name for the component, and note it for later use.
Depending on the component function, you may also need to add views and fields to pass information to and from the component. Follow these steps to add views and fields: 1. 2. 3. 4. 5. Add any necessary views to the component, naming them as you would the views of a rule. For instance, you might have an input view, an output view, and a work view. Select the relationship between the component and each view and make sure to set the view usage attribute to the correct type of view. Add as many fields under the views as are necessary for your application. This usually includes a return value field under the output view. Add any other entities, such as files or sets, that the component accesses or refers to. Commit your hierarchy to save your changes.
Inserting the Component in the Calling Rule

To insert the component in the rule that calls the component, do the following: 1. 2. 3. Navigate to the Rule Painter. In the source for the rule that calls the component, map any data the rule needs to pass into the fields of the component input view. Insert a USE COMPONENT statement where you want to call the component. use COMPONENT <component_name> 4. After the USE COMPONENT statement, check any return codes that the component passes back in the return value field. If the return code indicates success, map the data from the component output view into the rule. Commit your rule to save your changes.
5.
Creating and Editing the Component Source Code

Use a text editor to write or edit the source code of a component. If you are incorporating an existing component into the AppBuilder application, you must alter the declaration of your procedure to conform to the data types and parameters that AppBuilder applications expect. For C data types, refer to Table 6-1. For COBOL data types, refer to Table 6-2.
6-4
Data Type Comparison
You may write a wrapper procedure to provide an entry point for the component or alter the declaration of your procedure. The latter method may be easier and perform slightly faster for very small simple procedures, but you should write a wrapper procedure for large or complex ones. To write a wrapper procedure, do the following: 1. From the Construction Workbench menu bar, click Insert > Insert > Component. The Insert Component window appears. 2. 3. Click Query to display a list of available components. Select your user component and click Insert, or double-click on the component. The component is inserted into the hierarchy. 4. Double-click on the component in the Hierarchy Window. A window opens in the Work Area with the standard AppBuilder editor. 5. Use the editor to enter the source code for your component. For a C language component, the source is stored as <AppBuilder>\TEMP\imp_name.c if you are using implementation names and as <AppBuilder>\TEMP\system_ID.c otherwise.
Note
You can configure the path names by changing the appropriate values in the hps.ini file. All path names given in this section are the defaults.
6. 7.
You can also use any third-party editor to code your component. Be sure to store the source in <AppBuilder>\TEMP. From the Construction Workbench menu bar, click File > Commit to save your changes in the repository.

For more information on character field data types refer to Appendix A, Data Type Support. Table 6-1 shows how AppBuilder data types map to C data types contain values that are not zero terminated.
Table 6-1 AppBuilder to C data type comparison C data type char[n] struct { short length; char value[n]; } char[n] For more information, refer to Appendix A, Data Type Support. char[n*2] For more information, refer to Appendix A, Data Type Support. short long
AppBuilder data type CHAR(n)
VARCHAR(n)
MIXED DBCS SMALLINT INTEGER
6-5
Table 6-1
AppBuilder to C data type comparison (Continued) C data type For DEC, char[m+1], For PIC signed, char[m+1], For PIC unsigned, char[m] For more information, refer to Appendix A, Data Type Support. long containing the number of days starting January 1, 1 AD. long containing the number of milliseconds elapsed since midnight. long[3] The first long is the date field as described above. The second long is the time field as described above. The third long contains the number of picoseconds (trillionths of a second) of the current millisecond. short char[256] containing file name for binary file char [256] containing file name for text file
AppBuilder data type DEC(m,n), and PIC where: m is the total field length. n is the length of the fraction part. DATE TIME
TIMESTAMP
BOOLEAN IMAGE TEXT
Table 6-2 shows how AppBuilder data types map to COBOL data types.
Table 6-2 AppBuilder data type to COBOL data type COBOL data type PIC X(n) Length: PIC 9(4) COMP-4 Value: PIC X(n) PIC S9(4) COMP-4 PIC S9(9) COMP-4 PIC S9(m-n)V(n) SIGN IS LEADING AND SEPARATE PIC 9(9) COMP-4 The number of days starting January 1, 1 AD. PIC 9(9) COMP-4 Representing the number of milliseconds elapsed since midnight. Date: PIC 9(9) COMP-4 Time: PIC 9(9) COMP-4 Seconds: PIC 9(9) COMP-4 The number of picoseconds (trillionths of a second) of the current millisecond.
AppBuilder data type CHAR(n) VARCHAR(n) SMALLINT INTEGER DEC(m,n) DATE TIME
TIMESTAMP
Table 6-3 shows how AppBuilder data types map to Java data types.
Table 6-3 AppBuilder data type to Java data type Java data type AbfString(AbfString:CHAR, n ) AbfString(AbfString:VARCHAR, n ) AbfString(AbfString:MIXED, n ) AbfString(AbfString:DBCS, n ) AbfShortInt AbfLongInt
AppBuilder data type CHAR(n) VARCHAR(n) MIXED(n) DBCS(n) SMALLINT INTEGER
6-6
Writing a Java User Component
Table 6-3
AppBuilder data type to Java data type Java data type AbfBoolean AbfDecimal( AbfDecimal.DEC, m, n ) PIC(m,n)AbfDecimal( AbfDecimal.UPIC, m, n ) for unsigned PIC, or AbfDecimal( AbfDecimal.SPIC, m, n ) for signed PIC AbfDate AbfTime AbfTimeStamp AbfBlob( AbfBlob.IMAGE ) AbfBlob( AbfBlob.TEXT )
AppBuilder data type BOOLEAN DEC(m,n) PIC(m,n) DATE TIME TIMESTAMP IMAGE TEXT
Writing a Java User Component

To write a user component in Java, do the following: 1. 2. 3. Add a component and its input and output view to the rule in the hierarchy. Use the component editor to edit the component. Launch the editor by selecting the component in the Hierarchy window and then right-clicking and selecting Open Component. In the editor, write Java code for a public class that extends AbfNativeModule. The component class must be public or you get an exception at runtime. The class name must be the components mixed case name. The package name should be the same as specified by the COMPONENT_PACKAGE variable in the hps.ini file. Override the run (AbfStruct input, AbfStruct output) method inherited from the AbfNativeModule class. In this method, cast the input and output views to the actual view classes and provide whatever logic you wish. Be sure to include import statements for appbuilder.AbfNativeModule and appbuilder.util.AbfStruct so the Java compiler can locate these classes.
4.
5.
The class name of the component must be the same as the generated name. You must understand how the system generates names for both components and fields. The naming convention for all generated files is in line with Java naming conventions. For example, if you have an entity named CUST_DTL_DIS (for customer detail display), the generated entity names would be:
Table 6-4 Object Rule View Occurring View Component Set CUST_DLT_DIS example Generated Name
Cust_Dtl_Dis.class Cust_Dtl_Dis_v.class Cust_Dtl_Dis_va.class Cust_Dtl_Dis_c.class Cust_Dtl_Dis_s.class
This naming convention applies for all generated entities. Follow this convention when naming components. For an example of a Java user component, see Sample Java Component Code.
Writing a C User Component
To write user components in Java, you need to know the applicable Java classes and the available methods. Refer to Table 6-3 for a list of supported Java classes and methods. AppBuilder uses certain Java classes to represent the standard AppBuilder data types. The component editor has certain methods to both set and get values.

Generally, code your component source just as you would code any other C language program. However, you must insert certain statements into the code to integrate the component into your application. 1. In addition to any standard C include statements your application needs, include a header file named after the system identifier of the component in your source: #include "SYSTEM_ID.HDR" Internally, the AppBuilder environment refers to the component by its system identifier not its name or implementation name. This header file (stored as <AppBuilder>\DBG\SYSTEM_ID.HDR) converts the component input and output views and fields to corresponding C constructs. It prefixes all view and field names in the input and output views with a V_ (capital v and underscore). For example, if the name of the output view of a component is TEST_INTEGER_O, this header file changes it to V_TEST_INTEGER_O within the component. When you refer to a view or field from within the component, you must use the name as it appears in the header file. The header file also builds a structure for each input and output view. It prefixes these structures with a T_ (capital t and underscore). For example, if an input view TEST_INTEGER_I is defined as containing one CHAR (50) field called WINDOW_RETCODE and one SMALLINT field called BASE_NUMBER, then the generated C structure looks something like: Example Code: C User Component static struct T_TEST_INTEGER_I { char V_WINDOW_RETCODE[50]; T_B V_BASE_NUMBER; }
Note
Some data type conversions, such as T_B for a small integer, are contained in the HPSDEF.H file, which is an include file in the SYSTEM_ID.HDR file. The header file also relates a pointer from each structure to its corresponding view. For example:
static struct T_TEST_INTEGER_I FAR * V_TEST_INTEGER_I; The SYSTEM_ID.HDR file contains #define statements for the input and output view names. No matter what the view names are, you can refer to them generically within the component. Example Code: View Names #define INPUT_VIEW_NAME
Note
V_TEST_INTEGER_I
The header file name must be in all capital letters to be recognized on a UNIX system.
If dna.h, located in appbuilder\nt\sys\inc, is included in the source code for a user component, the component compile fails. AppBuilder defines a macro DECIMAL in HPSDEFS.h, located in appbuilder\nt\sys\inc. This macro is also defined as a structure in the Microsoft header wtypes.h.
6-8
Including dna.h automatically includes wtypes.h. The work-around is to always list the user component header file SYSTEMID.HDR first. Then undefine the DECIMAL macro. Any other headers can be added after the undefine. Example Code: Work-Around #include #undef #include #include #include #include 2. <ZADQKXH.HDR> DECIMAL <dna.h> <stdio.h> <stdlib.h> <string.h>
For both client and server-side components, specify the name of the component function as follows: int SYSTEM_ID (DCLRULEPARAM) The DCLRULEPARAM input parameter acts as a handle that must be used in all calls the component makes to the run-time system.
Note
For a component operating in a UNIX environment, the name of the component must be in all capital letters.
3.
You must call two access routines to tell the component where the input and output views are physically located in the storage area for the calling rule. For both client and the server sides, include the following two statements in every C component: INPUT_VIEW_NAME = RULE_INPUT_VIEW_ADDRESS OUTPUT_VIEW_NAME = RULE_OUTPUT_VIEW_ADDRESS
4. 5.
Code the main part of the component. At the end of the component, return DONE_WITH_RULE to enable the calling rule to continue processing. The entry point in a component is called repeatedly until the component returns this value (defined in r_str.inc) to its caller. Each call to the component corresponds to one entry into the message handling loop of the calling application. This allows a component that needs a long time to execute to break its operation into subsections, giving other applications a chance to run concurrently. If you do not explicitly return the value DONE_WITH_RULE at some point, the system locks up. Each time the AppBuilder environment invokes the component entry point, both global and automatic data are re-initialized. It is not safe to define a global variable in the component and rely on its value staying the same from one invocation to the next. If you need to preserve data across invocations, you must allocate space for it in the component input view and write the values there, so the calling rule preserves them and passes them back on subsequent iterations.
6.
If global views or work views are used in the component, then the following calls must be included in the component code before any view is used: get_addresses(HPSMEM) memory_allocation(HPSMEM)
For an example of a user component, see Sample C Component Code.
6-9
Calling a C Component from Java

You can call a C user component from a Java application. AppBuilder can prepare a C user component called by a rule in that Java application. A C component is called exactly the same way as a Java component. AppBuilder marshals the input and output views and allocates the work views. Global views are not supported. Be sure to copy the following files to the <AppBuilder>\nt\sys\inc directory or set the path to these files in the system environment: files in the Java SDK install include directory: jawt.h jni.h jvmdi.h jvmpi.h files in a win32 subdirectory in the include directory: jawt_md.h jni_md.h No other configuration is necessary. No changes are required in the rule prepared for Java to call the C component, beyond the changes discussed in Backward Compatibility or Thread-Safe Components or Work Views. A component with these changes can be successfully prepared for both Java and C environments.
Note
The AppBuilder-defined macro C_COMPONENT_FOR_JAVA can be used in the component code. It is defined only when a C component is prepared for Java, but not defined for C.
Note
Be sure to put <AppBuilder>\java\rt\bin directory in the system path for the DLL to be loaded at runtime. If this is not in the path, an Unsatisfied Link Error occurs when the C component is called.
Backward Compatibility
If a C component satisfies the following requirements, it can be prepared for Java and C without any changes. 1. The component function must be defined as: int ZAAAB25 (DCLRULEPARAM) { } If work views are used in the component, then the following calls must be included in the component code before any view is used: get_addresses(HPSMEM) memory_allocation(HPSMEM) 2. 3. The component cannot use global views. The component must include the following code: INPUT_VIEW_NAME = RULE_INPUT_VIEW_ADDRESS; OUTPUT_VIEW_NAME = RULE_OUTPUT_VIEW_ADDRESS;
6-10
Use that to obtain input and output views and only use the AppBuilder-defined macros INPUT_VIEW_NAME and OUTPUT_VIEW_NAME to access the input and output view fields.
Thread-Safe Components
If a C component must be thread-safe, its code must be slightly modified. The following changes are necessary: 1. Add this as the first line of the component code: #define THREAD_SAFE 2. In the declaration section of the component, add this: DCL_LOCAL_VARS; 3. In the initialization section of the component, before any component code is executed, add this: INIT_LOCAL_VARS; Example Code: Thread_Safe #define THREAD_SAFE #define NEW_COMPONENT_HEADERS #include "stdlib.h" #include "stdio.h" #include "string.h" #include "zaaab25.hdr" int ZAAAB25 (DCLRULEPARAM) { int i; FILE * outf; DCL_LOCAL_VARS; INIT_LOCAL_VARS; memory_allocation(pThis); get_addresses(pThis); INPUT_VIEW_NAME = RULE_INPUT_VIEW_ADDRESS; OUTPUT_VIEW_NAME = RULE_OUTPUT_VIEW_ADDRESS; outf = fopen("component.log", "w"); fprintf (outf, "C Component started\n"); for (i =10; i < 20; i++) { OUTPUT_VIEW_NAME->V_TEST_FLD_1[i] = INPUT_VIEW_NAME->V_TEST_FLD_2 [i-10]; } fprintf (outf, "Component ended\n"); fclose(outf); return DONE_WITH_RULE; }
6-11
Using Sample Component Code
Work Views
For the work view, you must look at the header (HDR) file. It makes sense first to prepare an empty component with all the views attached. To save the HDR file, edit the system initialization file (hps.ini) as follows in the section for APWB Rule Preparation: Example Code: Saving Header File [APWB Rule Preparation] SaveTempFiles=Y After you prepare the component, the <system_ID>.HDR file is in the <AppBuilder>\DBG directory. Find a definition for a work view pointer: Example static TD_TEST_WORK_VIEW_1 SEER_FAR * V_TEST_WORK_VIEW_1; Example View Structure The view structure is also defined in the HDR file: struct T_TEST_WORK_VIEW_1 { T_B V_TEST_VARCHAR_15_F_LEN; char V_TEST_VARCHAR_15_F[15]; }; typedef struct T_TEST_WORK_VIEW_1 TD_TEST_WORK_VIEW_1; Then use V_TEST_WORK_VIEW_1 in the component: V_TEST_WORK_VIEW_1 -> V_TEST_VARCHAR_15_F[0] = 'A'; V_TEST_WORK_VIEW_1 -> V_TEST_VARCHAR_15_F[1] = 'b'; V_TEST_WORK_VIEW_1 -> V_TEST_VARCHAR_15_F_LEN = 2;

This section discusses how to use sample component code for Java and C. Sample Java Component Code Sample C Component Code
6-12
Sample Java Component Code

This sample assumes that the names of the objects are:
Table 6-5 Object Component Input View Output View Field Object names for sample Java code Long Name in Repository Generated Name
MY_COMPONENT MY_COMPONENT_I MY_COMPONENT_O MY_FIELD
My_Component_c My_Component_I_v My_Component_O_v fMyField
Remember these guidelines: The long name in the repository must be all caps with underscores. The generated class name must be the user component name in mixed case with underscores. The generated instance name for a field must be mixed case with an f prefix, such as fMyField. Example Code: Java Component package component; import appbuilder.AbfNativeModule; import appbuilder.util.AbfStruct; import view.*; public class My_Component_c extends AbfNativeModule { public void run(AbfStruct input, AbfStruct output) { //cast the input view to the actual type My_Component_I_v inputView = (My_Component_I_v) input; //cast the output view to the actual type My_Component_O_v outputView = (My_Component_O_v) output; //get field values like this String tempSt = "" + inputView.fMyField; } }
Sample C Component Code

The following code is for either a client or a server-side component. It has a system identifier of AAC4RV and performs a factorial on an integer. Make sure to include the final return statement (return (DONE_WITH_RULE);). Example Code: C Component #include <stdio.h> #include <string.h> #include <AAC4RV.HDR> int AAC4RV (DCLRULEPARAM) { int i;
6-13
INPUT_VIEW_NAME = RULE_INPUT_VIEW_ADDRESS; OUTPUT_VIEW_NAME = RULE_OUTPUT_VIEW_ADDRESS; OUTPUT_VIEW_NAME->V_PYR_INT_O_F = 1; for (i=INPUT_VIEW_NAME->V_PYR_INT_F;i>1;i--) OUTPUT_VIEW_NAME->V_PYR_INT_O_F = OUTPUT_VIEW_NAME->V_PYR_INT_O_F*i; return (DONE_WITH_RULE); }
6-14
CHAPTER
ADDING SYSTEM COMPONENTS
This section contains information on the following types of pre-defined, built-in system components: Interface Components Use to easily change the run-time characteristics of an application or perform system functions. Thin Client Components Use to include dynamically generated HTML in a window. Dynamic Data Exchange Components Use to implement the Dynamic Data Exchange (DDE) message protocol. The system components are provided as part of the default repository. Some system components are only supported in C; some are supported in C and Java. Use these system components with the user components that you write. For more information about user components, see Chapter 6: Adding User Components. All the system components are described in detail, including details on the platform on which the components are supported, in the System Components Reference Guide.
Interface Components
Interface system components perform run-time functions such as creating pop-up windows for error and warning messages, changing the color and visibility of push buttons and fields, and accessing system information such as date and time.
Hierarchy of a Component
An interface system component typically contains one input view and one output view. Each view contains one or more fields. Figure 7-1 shows how a system component appears in the Hierarchy window of the Construction Workbench.
Figure 7-1 Component hierarchy Input view Output view
A component does not stand alone. It must be considered in context with the application and the calling rule. To make a component functional, attach the component to the appropriate rule in the hierarchy. Use MAP statements (as required) to manipulate the component input and output views.
7-1
Interface Components
Input View
Use an input view to provide input data to the component. The input views of some components own a field named WINDOW_LONG_NAME or VIEW_LONG_NAME, in which you specify the target window or view on which to perform the action. For example, the component in Figure 7-1 returns all fields in a specified window to their non-error condition. To specify the window on which to reset these fields, add the following statements to the calling rule: Example Code map 'name_of_window_to_reset_fields' to WINDOW_LONG_NAME of CLEAR_FIELD_MESSAGES_I use component CLEAR_FIELD_MESSAGES Some components, such as GET_USER_WORKSTATION_ID, do not have an input view because they do not need specific information to execute. An input view passes data into a rule. A rule can have only one input view. The standard naming convention for an input view is to append _I to the rule name.
Output View
Data resulting from the execution of a component are stored in the output view, typically contained in the RETURN_CODE field and other fields. An output view passes data from a rule to its parent rule. A rule can have only one output view. The standard naming convention for an output view is to append _O to the rule name.
Deferred Components
Components that do not execute immediately when a USE COMPONENT statement executes are called deferred components. The system defers their execution until the next CONVERSE WINDOW or CONVERSE_EVENT statement executes. Because most of these deferred components have no window name in the input view, they execute on the window that is the object of the CONVERSE statement. Thus, the fields of an input view usually cannot be validated when a USE COMPONENT statement executes. For this reason, the RETURN_CODE field of an output view is set to 1, unless a system-level error sets it to 0. When the CONVERSE WINDOW statement executes, it checks the contents of the input view. If the CONVERSE WINDOW statement detects an error, a message window displays the error. Several deferred components also have a WINDOW_LONG_NAME field. The name mapped to the WINDOW_LONG_NAME field must match the name of the next window conversed. See the System Components Reference Guide for a complete list of deferred components.
7-2
Adding System Components
Thin Client Components

By displaying dynamically generated HTML, your Web application can display error messages stored in a database. Use the system components HPS_SET_HTML_FILE or HPS_SET_HTML_FRAGMENT to display dynamically generated HTML fragments at execution time. HPS_SET_HTML_FILE displays dynamically generated HTML code stored in a separate HTML file. This HTML file cannot be a complete page it cannot contain <HTML>, <HEAD>, or <BODY> tags. HPS_SET_HTML_FRAGMENT displays dynamically generated HTML code stored as a character string within the rule that uses the component. Before using these system components, use the Freeway Explorer Migration Import tool to import HPS_SET_HTML_FILE and HPS_SET_HTML_ FRAGMENT. For information on the Freeway Explorer, refer to the Workgroup Repository Administration Guide. For more information on these components, refer to the System Components Reference Guide.
Using Dynamically Generated HTML Components

Use the following procedure to include dynamically generated HTML in a window at execution time. 1. Edit the HTML for the window. (Refer to the Development Tools Reference Guide for information on using the HTML Editor.) Insert the following HTML statement in the location to include the dynamically generated HTML: <LVEL_DYNAMIC name=macroname> where the macroname is the name used in the input view of the system component.
Note
Verify that the dynamically generated HTML code is in the indicated location.
2. 3. 4.
Save the HTML file and close the HTML editor. In AppBuilder, commit the changes to the repository. To use the component, add the HPS_SET_HTML_FILE or HPS_SET_HTML_FRAGMENT statement to the display rule. Prepare the project, including the window and rules.
At execution time, the HTML tag, LVEL_DYNAMIC is replaced with the HTML fragment or file corresponding to macroname (as entered in step 1). Call the component each time the window is displayed, because returning control to the rule resets the HTML file names.
Warning
If you make any changes in Window Painter and select Regenerate HTML, the system overwrites any changes you may have made in your HTML editor, including the HTML comment tags used by the component.
Ensure that your application deletes any temporary files that it creates.
Thin-client Component Examples

The following are examples of how to use HTML components in your code. Example Code: HPS_SET_HTML_FILE HPS_SET_HTML_FILE
map macroname to HPS_HTML_MACRO of HPS_SET_HTML_FILE_I map filename to HPS_HTML_FILE_NAME of HPS_SET_HTML_FILE_I use component HPS_SET_HTML_FILE where filename is one of the following: An existing file (including path) to which you refer.
Note
The existing files can be stored in the repository as a Component Folder attached to the Window and all attached files are prepared with the Window to the includes subdirectory.
A temporary file (including path), created with user-written components, that contains the HTML fragment. Remember that your application must delete the temporary file after using it.
Note
The HTML file must be a fragment not a complete page. It cannot contain <HTML>, <HEAD>, or <BODY> tags.
At execution time, the HTML comment tag is replaced with the HTML fragment in the corresponding file. Example Code: HPS_SET_HTML_FRAGMENT HPS_SET_HTML_FRAGMENT map macroname to HPS_HTML_MACRO of HPS_SET_HTML_FRAGMENT_I map This is the character string to be displayed to HPS_HTML_FRAGMENT of HPS_SET_HTML_FRAGMENT_I map 40 to HPS_HTML_FRAGMENT_LENGTH of HPS_SET_HTML_FRAGMENT_I map 0 to HPS_HTML_FRAGMENT_APPEND of HPS_SET_HTML_FRAGMENT_I use component HPS_SET_HTML_FRAGMENT At execution time, the HTML comment tag is replaced with the character string.
Dynamic Data Exchange Components

Dynamic Data Exchange (DDE) is a message protocol for exchanging data between two processes. DDE extends the power of AppBuilder by allowing processes to exchange data with other applications, that is, off-the-shelf products. This topic includes: Types of DDE Applications Levels of DDE Hierarchy Using DDE Components
Types of DDE Applications

There are two types of DDE applications: DDE Clients DDE Servers Although some applications support both client and server protocols, AppBuilder processes can only be DDE clients.
7-4
DDE Clients
DDE client components (DDECs) hide the complexities of the DDE protocol from the developer. Use DDECs to provide interprocess communications between AppBuilder applications and other applications that support DDE server protocol. The AppBuilder environment supports DDECs for Windows, but not for UNIX or host-based applications.
DDE Servers
Using DDE components, an AppBuilder process can link to applications that act as DDE servers, allowing the process to exchange data with, and send commands to, a DDE server. For example, an AppBuilder application can send data to a third-party spreadsheet program (such as Microsoft Excel) and then use the graphic, spreadsheet, and formatting capabilities of that program. Alternatively, an AppBuilder process can import data from an Excel spreadsheet and export it to a host using AppBuilder communications capabilities. Table 7-1 summarizes the DDE client components the AppBuilder environment supports.
Table 7-1 DDE client components DDE message WM_DDE_INITIATE WM_DDE_TERMINATE WM_DDE_ADVISE WM_DDE_REQUEST WM_DDE_POKE WM_DDE_UNADVISE WM_DDE_EXECUTE Description Initialize a session. Terminate a session. Create a permanent channel. Request data for an item. Send data to an item. Break channel created by DDE_ADVISE. Request server to execute a command.
Component DDE_INITIATE DDE_TERMINATE DDE_ADVISE DDE_REQUEST DDE_POKE DDE_UNADVISE DDE_EXECUTE
Levels of DDE Hierarchy

A three-level hierarchy of item, topic, and server identifies the units of data passed between the client and server. Each server can support multiple topics and each topic can support multiple items. The server and topic are specified with the DDE_INITIATE call. The handle that this component returns represents the server and topic identifier. Before writing AppBuilder DDE applications, you must first understand the DDE topics and items the server supports. For example, in Microsoft Excel, the server is Excel and the topic is the name of the spreadsheet, such as Sheet1. The item represents a cell or range of cells in the spreadsheet. A stock market application responding to a server called Stocks might support topics such as last price, bid price, ask price, and within each topic, items such as IBM, DEC, and GM.
Using DDE Components

An application that uses DDE components triggers the following sequence of actions: 1. The AppBuilder process calls the DDE_INITIATE component, requesting a connection to the specified server on a particular topic.
7-5
2.
An application that supports this server and topic combination responds by posting a handle to the process. This handle is returned in the SERVER_HANDLE field in the output view of the DDE_INITIATE component and is saved for subsequent communication with the server on the specified topic.
If more than one application responds to the initiate request, the system allows only the first server to respond.
Note
3.
The AppBuilder application calls the DDE_REQUEST, DDE_EXECUTE, DDE_POKE, DDE_ADVISE, and DDE_UNADVISE components using this handle to communicate with the server. To terminate the conversation, the process calls the DDE_TERMINATE component. After issuing a terminate, the link between the process and the server ends and the handle is no longer valid.
4.
This section covers information on the following topics: DDE Client/Server Conversations DDE Data Formats DDE Handle DDE Data Link
DDE Client/Server Conversations

In a DDE conversation between two applications, the client initiates the conversation by requesting a specific server and topic. If a server application can give the client the requested data, it saves the client handle and acknowledges by sending the client the server and topic handle for subsequent dialog. This link remains active until either party requests an end to the session. The DDE server application defines the application name and server name, which can be different. A client application can converse with multiple servers and a server can converse with multiple clients simultaneously.
DDE Data Formats

The DDE client uses the CF_TEXT data format, in which: Tabs separate fields Carriage returns or line feeds separate lines A NULL character signals the end of data The DDE components extract data from AppBuilder views and convert them to CF_TEXT format. The components also accept data in this format from the server and translate the data into AppBuilder views.
DDE Handle
The handle is an integer that represents the address to which messages in a DDE conversation are posted. The handle is exchanged when a client issues a DDE_INITIATE and maintains the link between two applications. All subsequent messages use this handle to communicate with and identify a server.
7-6
After using the DDE_TERMINATE component, the handle is invalid. Mapping 0 to the field that stores the handle to the server application prevents possible confusion should the client application later request another server application.
Caution
Do not change the handle returned from DDE_INITIATE until it is no longer needed. The application terminates ungracefully if you do. A common mistake is to map the handle, which is of type integer 31, to an integer 15 field, thus invalidating the handle.
DDE Data Link

Some of the DDE components contain two fields, VIEW_LONG_NAME and VIEW_QUALIFIER, that require a view address called a data link. Data links specify the location, views, and fields that panels and components reference, and point to locations that require data extraction or updates. Data links are composed of two parts. The first is the name of a root view, which relates to a rule or window. The second part of the data link is a view qualifier, which points to a specific field or subview that further qualifies the address. The data link can use either the system identifier or the name of the view. Example Code: DDE Data Link DDE Data Link Example: The syntax of data links is slightly different from the Rules Language syntax. Data links use square brackets instead of parentheses and the first array element starts with 0 instead of 1. To map data to the NAME field in the first array of DDE_DATA_V2, the rules syntax is: map 'JIM' to NAME of DDE_DATA_V2(1) The corresponding data link is in two parts: View Name : DDE_DATA_V1 View Qualifier : DDE_DATA_V2[0].NAME Note the difference in the array indices between the Rules Language statement and the DDE data link. More examples of DDE data links are: Description : Points to entire view DDE_DATA_V2 View Name : DDE_DATA_V1 View Qualifier : DDE_DATA_V2 Description : Points to field DDE_DATA_FIELD1 View Name : DDE_DATA_V1 View Qualifier : DDE_DATA_FIELD1 Description : Points to field AMOUNT in sixth array of DDE_DATA_V2 View Name : DDE_DATA_V1 View Qualifier : DDE_DATA_V2[5].AMOUNT
7-7
Example Code: Sample DDE Application Many of the DDE components are difficult to demonstrate in isolation because they are usually combined with several components together in a rule. This sample uses logically grouped components to perform typical tasks required by an application. map 'Excel' to AE_DDE_SERVER map 'Sheet1' to AE_DDE_TOPIC map 'R1C1:R5C2' to AE_DDE_ITEM map 'Bethany' to AE_DDE_NAME of AE_DDE_DEMO_DATA(1) map 'Bradley' to AE_DDE_NAME of AE_DDE_DEMO_DATA(2) map 'Jeffrey' to AE_DDE_NAME of AE_DDE_DEMO_DATA(3) map 'Lisa' to AE_DDE_NAME of AE_DDE_DEMO_DATA(4) map 'Richard' to AE_DDE_NAME of AE_DDE_DEMO_DATA(5) map 1000.00 to AE_DDE_AMOUNT of AE_DDE_DEMO_DATA(1) map 500.59 to AE_DDE_AMOUNT of AE_DDE_DEMO_DATA(2) map 600.80 to AE_DDE_AMOUNT of AE_DDE_DEMO_DATA(3) map 2204.98 to AE_DDE_AMOUNT of AE_DDE_DEMO_DATA(4) map 10.89 to AE_DDE_AMOUNT of AE_DDE_DEMO_DATA(5) do while EVENT_SOURCE of HPS_EVENT_VIEW <> 'Exit' converse window AE_DDE_DEMO_WIN caseof EVENT_SOURCE case 'Connect' if ( AE_DDE_HANDLE = 0 ) map AE_DDE_SERVER to SERVER_NAME map AE_DDE_TOPIC to SERVER_TOPIC use component DDE_INITIATE map SERVER_HANDLE of DDE_INITIATE_O to AE_DDE_HANDLE endif case 'Upload' map 'AE_DDE_DEMO' to VIEW_LONG_NAME of DDE_POKE_I map 'AE_DDE_DATA[0]' to VIEW_QUALIFIER of DDE_POKE_I map AE_DDE_ITEM to SERVER_ITEM of DDE_POKE_I map AE_DDE_HANDLE to SERVER_HANDLE of DDE_POKE_I use component DDE_POKE case 'Download' map 'AE_DDE_DEMO' to VIEW_LONG_NAME of DDE_REQUEST_I map 'AE_DDE_DATA[0]' to VIEW_QUALIFIER of DDE_REQUEST_I map AE_DDE_ITEM to SERVER_ITEM of DDE_REQUEST_I map AE_DDE_HANDLE to SERVER_HANDLE of DDE_REQUEST_I use component DDE_REQUEST case 'Graph' map AE_DDE_HANDLE to SERVER_HANDLE of DDE_EXECUTE_I map '[SELECT( "R1C1:R5C2,R1C1" )] [NEW(2)][FULL]' to COMMAND_FIELD of DDE_EXECUTE_I use component DDE_EXECUTE case 'Disconnect' map AE_DDE_HANDLE to SERVER_HANDLE of DDE_TERMINATE_I use component DDE_TERMINATE map 0 to AE_DDE_HANDLE case 'Exit' if ( AE_DDE_HANDLE <> 0 ) map AE_DDE_HANDLE to SERVER_HANDLE of DDE_TERMINATE_I use component DDE_TERMINATE map 0 to AE_DDE_HANDLE
7-8
endif endcase enddo if ( AE_DDE_HANDLE <> 0 ) map AE_DDE_HANDLE to SERVER_HANDLE of DDE_TERMINATE_I use component DDE_TERMINATE map 0 to AE_DDE_HANDLE endif
7-9
7-10
CHAPTER
8
Note
CREATING ONLINE HELP FOR APPLICATIONS
The AppBuilder environment supports these online help formats for end users: Native GUI Help For applications that run in the Windows environments, the AppBuilder environment supports the corresponding native graphical user interface (GUI) help system. For Windows, this is Windows Help Manager.
UNIX users: You cannot use any native help in a UNIX environment you must use AppBuilder help.
Java Help Use JavaHelp (included with the Java Developers Kit) to create online help for applications distributed to a Java environment. Generic (AppBuilder) Help AppBuilders Window Painter tool and the AppBuilder run-time system include their own built-in help facility. While AppBuilder help does not include some of the advanced features of the native help systemshypertext links, multilevel contents and index, and so forthit can provide context-sensitive help for both windows and individual fields within windows. The following topics are discussed in this section: Enabling Application Help Using Online Help System Components Creating Windows Help Creating Java Help Creating Simple Help
Enabling Application Help

You can specify only one type of help system for an application. Use the appropriate variable and path name in the NC section of the appbuilder.ini file (for Java applications) or the AE Runtime section of the hps.ini file (for C applications) on the workstation.
Note
This variable must also be set correctly on all the production workstations on which the generated application runs.
8-1
Using Online Help System Components
Table 8-1
Specifying application help Use this variable... GUI_HELP_DIR followed by the path name of the directory that contains the help file. For example: GUI_HELP_DIR=c:\appbuilder\native\hlp. After using one of the online help system components to access native GUI help, the system disables the AppBuilder help. HELP_SET_NAME followed by the file name of the help set. HELP_DIR followed by the path name of the directory that contains the help file. For example: HELP_DIR=c:\appbuilder\winnt\rt\hlp. This variable and path name is usually set to a default value during installation.
To specify this help...
Native GUI Help
Java Help AppBuilder Help
Using Online Help System Components

The AppBuilder environment supports three system components to link to the native GUI help system: SET_HELPFILE_NAME Use this component to specify the .HLP file to which calls are subsequently made with the SHOW_HELP_TOPIC component. SHOW_HELP_TOPIC Use this component to display the help panel for a specific object in a window, referenced by its system identifier (HPSID). The HELP_KEYWORD field used in the SHOW_HELP_TOPIC component call is usually a text string consisting of the system identifier (HPSID) of the Window Painter objectfor example, a push buttonabout which a help panel is to be displayed. HPS_SET_HELP_TOPIC Use this component to set a topic for an entire window rather than a field within the window. This effectively makes the help less context sensititive. In doing so, each time F1 is pressed, the help panel for the entire window is displayed, taking the focus off a specific field. For more details on these system components, refer to the System Components Reference Guide.
Creating Windows Help

Create Windows help by compiling a help topic file that contains the help text, and a help project file that contains the necessary information to convert the topic file. The help topic file is a rich text format (.RTF) file. To create the help topic file, you can use any editor or word processor that can edit and write .RTF files. Footnotes structure the .RTF file so that it can be compiled into a help file. For context-sensitive help, the system identifier (HPSID) of the object links the object to the compiled help file. In the help topic (.RTF) file, the system identifier is indicated as a keyword footnote. Because the system identifier is displayed to end users when they search the help file, use a meaningful system identifier. You must also make the system identifier and corresponding keyword unique to prevent the application from calling the wrong help panel. See your Microsoft Windows Software Development Kit for details on the help topic (.RTF) file structure.
8-2
Creating Online Help for Applications
Creating Java Help
The required help project (.HPJ) file is invoked when the Help Compiler runs, and it contains the information that the compiler needs to convert the files into a binary help resource file. See your Microsoft Windows Software Development Kit for details on the structure of the help project file. The Help Compiler creates the binary help resource file from the topic files listed in the help project file. The command that runs the Help Compiler and indicates which project file to access is HC filename.HPJ. The new compiled help has the same file name as the project file but with an .HLP extension. Refer to your Microsoft Windows Software Development Kit for details on compiling help files. The compiled help (.HLP) file is then linked to the application through the use of two AppBuilder system components or through the use of the command line parameter -h help_file_name in the file master.exe. Refer to the appendix in the Deploying Applications Guide for a summary of the valid run-time parameters.
Creating Java Help

For Java applications, you develop the help set files, help map files, and other Java files outside of AppBuilder and point to them in the Help property of the window or window object. Specify the default HelpSet filename for all Java client applications in the appbuilder.ini file. To use the default HelpSet, remove the semicolon at the start of the line, and replace the filename with actual file name. Note that calling a Java client rule's SetHelpFile() ObjectSpeak method overrides the HELP_SET_NAME entry, for the rule and all its subrules in the hierarchy. ;HELP_SET_NAME=filename.ext When developing distributed applications, AppBuilder provides built-in hooks to Java Help that allow you to easily add context-sensitive help to your applications. Here are brief instructions on adding context-sensitive help to your applications. 1. Create a HelpSet for the application. The HelpSet file should contain information about the HelpMap, HelpIndex, Table of Contents, and HelpSearch. Refer to the JavaHelp documentation from Sun Microsystems for steps on creating a HelpSet. Create the HelpMap file. A HelpMap is an XML file that specifies the mapping between help identifiers (or helpIDs) and HTML files. The name of the file (for example, MAP.jhm) must be the same at that specified in the mapref location. When creating a HelpMap file for AppBuilder applications, you must specify the help IDs as follows: For windows, the help ID must be the long name of the window. For user interface objects placed on the window, the ID must be the window long name, followed by a dot, followed by the system identifier (HPSID) of the object. For each ID you must specify an HTML file contains the help description for the control. 3. 4. 5. Create the HelpIndex file for the application. Create the Table of Contents file. In the appbuilder.ini file (located by default in the <AppBuilder>\JAVA\RT directory) set the HELP_SET_NAME to the name of the HelpSet file created in Step 1.
The appbuilder.ini file must be distributed with your Java application in order for help to be accessible to your users.
2.
Note
8-3
Creating Java Help
For more information on creating Java Help, see the documentation for Java Help located on the Sun Web site (http://java.sun.com). Example Code: HelpSet File Here is a sample HelpSet file, named HPSApp.hs: <?xml version=1.0 encoding=ISO-8859-1 ?> <helpset version="1.0">  <title>Hps NC Client - Help</title>  <maps> <homeID>MyWindowLongName</homeID> <mapref location="Map.jhm"/>  </maps>  <view> <name>TOC</name> <label>Table Of Contents</label> <type>javax.help.TOCView</type> <data>ncHelpTOC.xml</data> </view> <view> <name>Index</name> <label>Index</label> <type>javax.help.IndexView</type> <data>ncHelpIndex.xml</data> </view> <view> <name>Search</name> <label>Search</label> <type>javax.help.SearchView</type> <data engine = "com.sun.java.help.search.DefaultSearchEngine"> JavaHelpSearch </data> </view> </helpset> Example HelpMap File Sample HelpMap File: Here is an example of a HelpMap file that specifies which HTML files contain help information for a window and an edit field and push button located on the window: <?xml version=1.0 encoding=ISO-8859-1 ?> <map version="1.0"> <mapID target="MyWindowLongName" url="Mainwindow.html" /> <mapID target="MyWindowLongName.Edit1" url="edit1.html" /> <mapID target="MyWindowLongName.ExitBtn"url="exitb.html" /> </map>
8-4
Creating Simple Help
Creating Simple Help

We have included a help system that is intended for simple applications. For C applications, AppBuilder Help is somewhat less sophisticated than the native help systems described above. We generally recommend that you use one of the native help systems for major applications whenever possible. AppBuilder Help is sufficient for very simple applications and might be useful for prototypes and application systems still in the early stages of construction. AppBuilder Help text is directly applied to window objects and to individual objects within windows. To enter or update AppBuilder Help text for the window object (the window itself) or for any object in the window, open the window in Window Painter. If the help text is for the window itself, make sure no other objects are selected. Click the window and select Properties from the right-click menu. The window must have a view inserted or a warning shows in the Help field. For an object in the window, select the object and select Properties fromthe right-click menu. In the property called Help, click in the field next to the name Help, and a multiline edit field is displayed. Type in the help text for the window in this field. When done, press Enter. See Figure 8-1 for an illustration of the field.
Figure 8-1 AppBuilder help window
Multiline edit field
You can also create status line text for a window. This displays brief help text for the window or the objects within the window depending which item has the focus during execution. When the application is executed, the status field displays the help text that is associated with the selected object. This text is in a field called ShortHelp and is editable in the Properties window. To define the tooltip (for Java applications) or status line help (for C applications), add or edit the text in the Short Help property in the Properties window. From the right-click menu, select Properties and edit the field called ShortHelp. For the window itself, make sure no objects are selected when you right-click.
Figure 8-2 Short Help property editing
This text appears as tooltip or status line help.
To save changes to the help text or to the short help text, you must commit your changes before exiting Window Painter. For information on using Window Painter, refer to the Development Tools Reference Guide.
8-5
AppBuilder Help at Execution Time
AppBuilder Help at Execution Time

When the application is executed, each displayed Help pop-up window appears as it does in the Window Painter with two exceptions: The Apply push button does not exist, since end users cannot modify the help text, and the Window help/Field help push button appears in place of the Apply push button.
Note
Execution behavior of Windows help is determined by the environment and native help system.
AppBuilder defaults to field level help when the user presses the F1 key. Field help is when an object within the window (rather than the window itself) has focus. The first Help pop-up window displayed is always field help. Window help is when the window itself has focus. After the user has displayed the specific field help for an object, they can view the window object help by selecting the Window help push button, or they can get window help by closing the field help pop-up window. Close the window by selecting the Cancel push button. To return to the field-level help when the window object help is displayed, select the Field help push button. There is only a single push button on each help window, but its name and function changes depending upon whether window help or field help is currently being displayed. If you do not provide help text for any object in a window or the window itself, when the user presses F1, the system displays the message No Help Available for the Window. If you do not provide help text for a particular object, when the user presses F1, the system displays the message No Help Available for the Object.
8-6
CHAPTER
TROUBLESHOOTING APPLICATION DEVELOPMENT
This chapter is a compilation of tips and solutions to problems you may be having with your application. the following topics are discussed in this chapter: Environment Problems - development specific settings Settings Problems - Construction Workbench settings Some of the problems you are experiencing may be due to the development environment. Some problems may be due to improper settings or use of the Construction Workbench. Others may be due to the complexities of the interaction between the various integrated tools of the product.
Environment Problems
Some problems may be due to the workstation environment. This section discusses development specific settings for the following: Java Version Java Classpaths
Java Version
AppBuilder only supports the use of Sun JDK v1.2.2 and v1.3. If you are running RuleView with JDK v1.2.2, you must install Sun JPDA v1.0. Type "java -version" from a command prompt, to see the version currently being executed, or check PATH settings to verify which java.exe is being executed. Verify that you are running the 1999 version of JDB.exe in the JPDA\BIN directory (you might have to be in the bin directory to run it). Installing the latest JPDA from the Sun Web site ensures that you are running the 1999 files. Version 1.3 includes the JPDA files. In this case, simply ensure the classpath includes an entry for the .jar file so that RuleView can find the JPDA.
9-1
Settings Problems
Java Classpaths
If your Java or Java RuleView is not running, clean up and modify the path and classpath statements: For the classpath, start by removing unnecessary references: (c:\winnt\java\swingall.jar) Then get rid of any paths with spaces. Change c:\program files\ to c:\progra~1\). In the path, move the JDK and JPDA references to the start of the path. Exceeding a certain line length may be a problem. One way to check that you have the classpath environment variable set correctly to include Java classes is to run the examples that are installed with JDK (Java stuff) not with the AppBuilder product. Look in the jdk directory where you installed the Java development kit, in demo/applets, and run some of the examples.
Settings Problems
Problems may be due to improper settings or improper use of the Construction Workbench. This section discusses possible solutions to a delay in loading the Construction Workbench.
Delay in Loading of Workbench

If the Construction Workbench takes a long time to load, or if the repository takes a long time to access, you may have the ODBC trace set on your workstation. If the ODBC trace is set, the application is doing a large amount of logging when accessing the underlying repository database. To correct this problem: Select Control Panel > Administrative Tools > Data Sources (ODBC) > Tracing, set Stop Tracing Now and click OK.
9-2
Troubleshooting Application Development
APPENDIX
DATA TYPE SUPPORT
The AppBuilder DEC and PIC data types provide ways to represent numbers. Data type support includes the following: DEC Value Support PIC Value Support The AppBuilder DATE data type provides a mechanism for storing and managing four-digit year dates within an AppBuilder development application. The DATE variable has a length of 4 bytes. The value of the DATE variable is the number of days since the date of origin (January, 1, 0000). The DATE data type also provides accurate support for leap years. DATE data type support addresses these issues: Short-form Date Support Repository Migration Date Support The AppBuilder CHAR, VARCHAR, MIXED, and DBCS data types provide character data type support. The follow discusses considerations for using these fields in C user components. Character Data Support
DEC Value Support

DEC variable is declared as DEC(length,scale), where length is the length of the data item and scale is the number of decimal places to the right of the decimal point. Data is represented from right to left (low-order bytes to high-order bytes): The fractional portion (if any), as a series of digits (0-9) for the length of the fractional portion The absolute value of the integer portion, or zero A minus sign (if appropriate) immediately to the left of the integer portion Blanks left-filled for the remainder of the field
Decimal Point Position

The position of the decimal point in the DEC value is statically defined, so the length and scale are not stored together with a decimal value. Length and scale are passed to the code generator runtime functions when necessary.
A-1
DEC Value Support
Valid Characters
A DEC field is represented as a C character array (not necessarily null-terminated, since its length is always known). The size of the array is the length of the DEC field plus one. Valid characters in this array are minus sign (-), digits (0, ... , 9)and space ( ).
Format of DEC Value

All decimal values regardless of their origin should have the following unambiguous normalized representation. Example: DEC Value Format <DEC value> <IntegerPart> <DecimalPart> <NonZeroDigit> <Digit> where: 'x' <X> [x] x* x x+ a|b symbol x metasymbol X zero or one x zero or more x one x one or more x a or b ::= ::= ::= ::= ::= ' '*<IntegerPart><DecimalPart> {'-'|' '}{'0'|<NonZeroDigit><Digit>*} <Digit>* '1'|'2'|'3'|'4'|'5'|'6'|'7'|'8'|'9' '0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'|'8'|'9'
{xyz} grouping
and where: number of bytes in <IntegerPart> is equal to (length - scale) number of bytes in <DecimalPart> is equal to scale
Note
The first significant digit of <IntegerPart> is the first non-zero digit in it, or '0' in its right-most position, if it is zero. The '0' must be present, if <IntegerPart> is zero.
Representation of the DEC must satisfy the following conditions: <IntegerPart> must be padded with blanks until the first significant digit. <DecimalPart> must be padded with zeroes until its end. Example Code: DEC Value Consider type DEC(6,3) of 123456 " " " -0050" represents -0.05 1300" represents 1.3 0004" represents 0.004
A-2
Data Type Support
PIC Value Support
" 130000" represents 30.0 " " " 13 "+ " " " 3000" represents 3.0 0000" represents 0 " is incorrect, because trailing spaces in the integer part are not allowed 1300" is incorrect, '+' is not allowed 130" is incorrect, integer part must have at least one digit 00130" is incorrect, leading zeros in the integer part are not allowed 013 " is incorrect, trailing blanks in the decimal part are not allowed
PIC Value Support

PIC variable is declared using a storage pattern string or a storage picture, format. This is described in the Rules Language Reference Guide. The size of a picture field is determined by the Field picture-storage property. The picture property for a Field object in the repository is 30 characters long (Field picture-storage and Field picture-display). However, in the Rules Language, one should be able to use a longer local PIC field for data manipulations within the rule code. The maximum size for a DEC and PIC field on all platforms is 31.
Valid Characters
PIC value is represented by C character array (not necessarily null terminated). Valid characters in this array are digits '0',...,'9', sign plus '+', and sign minus '-'.
Format of PIC Value

The internal representation of PIC value must be formatted according to its storage picture in the following way: For each '9' (digit position) in the storage pattern there must be a digit in the internal representation. For 'S' (sign position) in the storage pattern there must be a sign in the internal representation, if no sign is declared, no byte is reserved for it. For 'V' (decimal point position) in the storage pattern no byte is reserved in the internal representation. Length of PIC field is defined as number of '9's in the storage picture and scale is defined as number of '9's after the 'V' sign, scale is 0, if 'V' is not present in the storage picture. Example: PIC Value Format <Signed PIC value> ::= {'-'|'+'}<IntegerPart><DecimalPart>
AppBuilder 2.1.0 Developing Applications Guide A-3
Short-form Date Support
<Unsigned PIC value>::= <IntegerPart><DecimalPart> <IntegerPart> ::= <Digit>* <DecimalPart> ::= <Digit>* <Digit> ::= '0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'|'8'|'9' where: number of bytes in <IntegerPart> is equal to (length - scale) number of bytes in <DecimalPart> is equal to scale
Note
For runtime functions to correctly interpret PIC value they must know whether the value is signed/unsigned (that is, if its storage picture contains S or not), its length (the number of 9s and Ss in storage pattern, that is, the size of the C array allocated for the value) and scale.
Example Code: PIC Value Consider PIC s999v999 of 123456 "-000050" represents -0.05 "+001300" represents 1.3 "+000004" represents 0.004 "+130000" represents 130.0 "+003000" represents 3.0 "+000000" represents 0 "1234567" is incorrect " 123456" is incorrect; sign must be present "+ 1100" is incorrect; blanks are not allowed Consider "000050" "001300" "000004" "130000" "003000" "000000" "+23456" " 1100" PIC 999v999 of 123456 represents 0.05 represents 1.3 represents 0.004 represents 130.0 represents 3.0 represents 0 is incorrect; sign is not allowed is incorrect; blanks are not allowed

BluePhoenix provides the option of a short-form DATE data type for use by AppBuilder developers. The short-form of the DATE data type provides a method for adding the century portion to short dates. The short-form DATE data type is compensated for in the following cases: DATE Input Field - Used when the developer wants the end user to input the short-form of the date into an edit field in a window. DATE Data Type - Used if character fields exist without the century information. The character fields can (without century information) be converted into DATE data types in the Rules Language. These character fields without century information are under application control and may be stored in databases or even generated fields.
A-4
Data Type Support
DATE Input Field

In a window, the AppBuilder DATE input field requires the long form of the date. As a convenience to the end-user, AppBuilder applications may allow the end user to enter a short form of the date into the DATE input field. AppBuilder runtime support adds the century portion of the year to the date and displays the four-digit date in the input field. This allows the end user to verify the century being used in the long form of the date after the application has been built. The DATE input field should always be defined large enough to display the long form of the date so the end user can easily see the added century portion of the year.
Note
If the DATE input field is not large enough to display the full long form of the date, then the end user may have to scroll the DATE input field to see the added century portion of the year.
The system uses a sliding window algorithm to determine the century to be added to the short date. This allows you to identify the number of years in the future to define the dividing line between the past and the future. For example, if the current year is 2001 and you define the number of years in the future to be 30 then: All years entered between 02 and 31 are interpreted as future dates, and are listed as 2002 through 2031. All years entered between 32 and 00 are interpreted as past dates, and are listed as 1932 through 2000. The year 01 is interpreted as 2001. The current year (01) is always interpreted as being in the current century (that is, 2001). The sliding window limits you to a date range of 100 years. In the example above, it is not possible to represent years earlier than 1931 or later than 2031 using short-form dates.
Setting Years in the Future

Workstation-based AppBuilder applications support the sliding window for workstation applications. Use the workstation parameter YEARS_IN_THE_FUTURE, in the AE Runtime section of the hps.ini file, to define the number of years in the future. For Java applications, you must set the value in the NC section of the appbuilder.ini file. The default is 30.
Support in 3270 Converse-Based Applications

The system uses the sliding window to determine the century portion of short form dates for 3270 Converse-based applications. The sliding window for the host is fixed at 30 years into the future. To confirm that you have the sliding window support in the AppBuilder system, verify that the module HPEUE11 has a date and time stamp of 12/07/95 14.27 or greater.
Recommendation on Input Field Length

While the DATE input field allows end users to enter the long form of the date, you may not have set the displayed field large enough to display the full date. If the end users require visual feedback of entered dates, ensure that the date input field is long enough to display the full long date format.
A-5
Repository Migration Date Support
DATE Data Type

The DATE data type provides support to convert a two-digit year field into an AppBuilder long-form DATE. For two-digit year field conversion to a long form of the date, the century determination between the host and the workstation are performed with different algorithms. The century determination operates as follows: For workstation-based applications: Use 19 for the century in converting two-digit years to the long form of the DATE. For mainframe-based applications: Use a fixed century determination point of 29. A two-digit entry of 30 maps into a four-digit year of 1930 and a two-digit entry of 29 maps into a four-digit year of 2029. To confirm that you have the sliding window support in AppBuilder system, verify that the module HPEUE11 has a date and time stamp of 12/07/95 14.27 or greater.
Recommendation for the Four-Digit Year

Since the conversion of the two-digit year to the four-digit year may not be readily visible to the end user and the results of the conversion may not be observed until a later time, we strongly recommend that your applications manage both the century portion of the year and the two-digit year component to ensure a complete and accurate four-digit year.
Repository Migration Date Support

In the AppBuilder development environment, the repositories maintain only the last two YY digits of the date in their audit fields (for example, object create date or object last modify date). Because most comparisons are based on the equality test, as opposed to greater than or less than test, this is not a concern; however, date support becomes an issue to consider when performing: Enterprise Repository Migration Workgroup Repository Migration
Enterprise Repository Migration

For the enterprise (mainframe) repository, migrations are managed using the Migration Selective Export tool. When the repository migration spans a century, the migration must be handled in two processes. For example, using the Migration Selective Export date format of YY/MM/DD, the date range of 99/10/ 01 00/03/31 (October 1, 1999 through March 31, 2000) would be replaced with these two ranges: 99/10/01 99/12/31 (October 1,1999 through December 31, 1999) 00/01/01 00/03/31 (January 1, 2000 through March 31, 2000) These two range statements need to be linked with AND in the Op field of the first date range statement. The Migration Selective Export evaluates the object last modify date. For more information, refer to the Enterprise Migration Guide.
A-6
Data Type Support
Character Data Support
Workgroup Repository Migration

For the workgroup (Freeway) repository, the migrations are managed similarly to those of the enterprise repository. In Windows, the migration function of the Freeway Explorer is used. For example, to migrate all objects between 99/10/01 - 00/03/31 (October 1, 1999 through March 31, 2000), the migration is handled in two processes: The first migration would specify After 99/10/01 (October 1, 1999 through December 31, 1999). The second migration would specify Before 00/03/31 (January 1, 2000 through March 31, 2000). The migration process evaluates the object date maintained field.
Note
If you have developed unique repository utility applications using the Freeway APIs, you should provide support for handling the two digit year field, as the repositories only store the last two YY digits of the year.
For more information, refer to the Workgroup Repository Administration Guide.

The AppBuilder character fields, CHAR, VARCHAR, MIXED and DBCS, are not null-terminated as string fields normally are in C. CHAR, VARCHAR, and DBCS fields are always padded with spaces to their specified maximum sizes - for DBCS fields the padding character is a DBCS space. VARCHAR fields are not padded, although trailing spaces from any field mapped to them is preserved. As already mentioned these fields are not null-terminated - the associated length field indicates the actual length of the contents. If, in a C user component, you need to convert an AppBuilder character field to a C-style string, use memcpy() to copy the field to a new area (1-byte longer) before adding a null-terminator and optionally trimming any trailing spaces. Do not simply try modifying the data in the field in the passed view structure. For example: Using memcpy() char *str; int i; str = malloc( INPUT_VIEW_NAME->V_CHAR_FIELD + 1 ); memcpy( str, INPUT_VIEW_NAME->V_CHAR_FIELD, sizeof( INPUT_VIEW_NAME->V_CHAR_FIELD ) ); str[sizeof( INPUT_VIEW_NAME->V_CHAR_FIELD )] = '\0'; for ( i = strlen( str ) - 1; i >= 0 && str[i] == ' '; str[i] = '\0', i-- );
A-7
A-8
Data Type Support
APPENDIX
EVENTS SUPPORTED IN C
This topic lists the events used in event-driven processing of rules in C. For information on events in Java, refer to the ObjectSpeak Reference Guide. Event-driven processing in C uses the following events. NA indicates that the given field is not used for an event and hence is undefined (or not applicable). They are listed alphabetically. Asynch Event Check Box Click Child Process Terminated Close Window with System Menu Detached Rule Reactivated Double-Click or Tab Out of Field Double-Click or Tab Out of List Box Field Hot Spot Click Menu Selection Press Enter Key Push Button Click Radio Button Click Scroll Off Bottom of List Box Scroll Off Top of List Box Scroll Out of Range in List Box Time Out Undefined Event
Asynch Event
Table 2-1 Event Description: EVENT_TYPE: EVENT_NAME: Async event ASYNC_EVENT Name of target rule
B-1
Table 2-1 EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: NA NA System ID of target rule input view NA
Check Box Click

Table 2-2 Event Description: EVENT_TYPE: EVENT_NAME: EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Check box click (if immediate return) INTERFACE_EVENT HPS_IMMEDIATE_RETURN Check box system identifier (HPSID) NA NA NA
Child Process Terminated

Table 2-3 Event Description: EVENT_TYPE: EVENT_NAME: EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Child process terminated SYSTEM_EVENT HPS_CHILD_END Name of the rule Instance name of rule (if applicable) NA NA
Close Window with System Menu

Table 2-4 Event Description: EVENT_TYPE: EVENT_NAME: EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Close a window with the system menu (if the close return code is set) INTERFACE_EVENT HPS_WIN_CLOSE Close return code NA NA NA
B-2
Events Supported in C
Detached Rule Reactivated

Table 2-5 Event Description: EVENT_TYPE: EVENT_NAME: EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Detached rule reactivated SYSTEM_EVENT HPS_DETACH NA NA Name of view NA
Double-Click or Tab Out of Field

Table 2-6 Event Description: EVENT_TYPE: EVENT_NAME: EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Double-click or tab out of any field after data entry (if immediate return) INTERFACE_EVENT HPS_IMMEDIATE_RETURN Field system identifier (HPSID) Column system identifier (HPSID) for a multicolumn list box only; otherwise, NA NA NA
Double-Click or Tab Out of List Box Field

Table 2-7 Event Description: EVENT_TYPE: EVENT_NAME: EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Double-click or tab out of any list box field after data entry (if immediate return) INTERFACE_EVENT HPS_IMMEDIATE_RETURN List box system identifier (HPSID) NA NA Occurrence number of scroll box position
Hot Spot Click

Table 2-8 Event Description: EVENT_TYPE: EVENT_NAME: EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Hot spot click INTERFACE_EVENT HPS_HS_CLICK Hot spot system identifier (HPSID) NA NA NA
B-3
Menu Selection
Table 2-9 Event Description: EVENT_TYPE: EVENT_NAME: EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Menu selection INTERFACE_EVENT HPS_MENU_SELECT Menu choice system identifier (HPSID) NA NA NA
Press Enter Key

Table 2-10 Event Description: EVENT_TYPE: Press Enter key INTERFACE_EVENT HPS_PB_CLICK No Enter key:Press Enter with focus on push button. EVENT_NAME: HPS_PB_CLICK Push button:Press Enter with focus anywhere on screen. HPS_WIN_ENTERNon-Push button:Press Enter with focus anywhere on screen. EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Enter return code or push button system identifier (HPSID) NA NA NA
Push Button Click

Table 2-11 Event Description: EVENT_TYPE: EVENT_NAME: EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Push button click INTERFACE_EVENT HPS_PB_CLICK Push button system identifier (HPSID) NA NA NA
B-4
Radio Button Click

Table 2-12 Event Description: EVENT_TYPE: EVENT_NAME: EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Radio button click (if immediate return) INTERFACE_EVENT HPS_IMMEDIATE_RETURN Radio button system identifier (HPSID) NA NA NA
Scroll Off Bottom of List Box

Table 2-13 Event Description: EVENT_TYPE: EVENT_NAME: EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Scroll off the bottom of a list box INTERFACE_EVENT HPS_LB_BOTTOM List box system identifier (HPSID) Column system identifier (HPSID) for a multicolumn list box only; otherwise, NA NA Occurrence number of bottom
Scroll Off Top of List Box

Table 2-14 Event Description: EVENT_TYPE: EVENT_NAME: EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Scroll off the top of a list box INTERFACE_EVENT HPS_LB_TOP List box system identifier (HPSID) Column system identifier (HPSID) for a multicolumn list box only; otherwise, NA NA Occurrence number of top
Scroll Out of Range in List Box

Table 2-15 Event Description: EVENT_TYPE: EVENT_NAME: EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Scroll out of range in a list box INTERFACE_EVENT HPS_LB_OUTRANGE List box system identifier (HPSID) Column system identifier (HPSID) for a multicolumn list box only; otherwise, NA NA Occurrence number of scroll box position
B-5
Time Out
Table 2-16 Event Description: EVENT_TYPE: EVENT_NAME: EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Time out (set by the system component SET_WINDOW_TIMEOUT) INTERFACE_EVENT HPS_WIN_TIMEOUT Name of the window NA NA NA
Undefined Event
Table 2-17 Event Description: EVENT_TYPE: EVENT_NAME: EVENT_SOURCE: EVENT_QUALIFIER: EVENT_VIEW: EVENT_PARAM: Undefined event SYSTEM_EVENT HPS_SYS_UNDEFINED NA NA NA NA
B-6
Index
INDEX
A
accessing hierarchy, database 3-15 analysis, trace 2-3 analyze the project 1-2 AppBuilder help 8-1 appbuilder.ini file 8-1, 8-3, A-5 application debug 1-4 deploy 1-4 execution 1-5 life cycle 1-1 preparation 1-3 application help AppBuilder 8-1 Java 8-1 native GUI 8-1 system components for 8-2 using 8-2 application hierarchy 6-4 rule 3-3
C
C data types 6-5, A-1 calculus functions 6-2 calling method 3-9 calling rule, component 6-4 cardinality 2-4 case statements 4-2 CASEOF statements 4-2 century. see date CF_TEXT format 7-6 CHAR data type A-7 ChildRuleEnd event 5-2 class name 6-7 client-server DDE component 7-6 COBOL data types 6-5, A-1 column option in engineering tools 2-7
combo box domain of values 5-9 comparison, data types 6-5, A-1 component C called from Java rule 6-10 calling rule 6-4 deferred system 7-2 designing for reuse 6-2 disadvantages 6-2 guidelines for writing 6-2 includes 6-3 Java user 6-7 keeping current 6-3 owning view 6-3 servlet 3-11 thread-safe 6-11 user 6-1 user sample C component 6-13 when to use 6-1 writing 6-3 writing user C source 6-8 see also system component configuration file, Java (appbuilder.ini) 8-3 converse rule 3-3 using 3-3 converse rules windows 5-5 CONVERSE statements 4-2 CONVERSE (null) 4-2 CONVERSE WINDOW 4-2 conversion table 6-5, A-1 creating entity relationships 1-2 object at execution time 3-13 creating runtime objects 3-7 CUSTOMER_DTL example 4-14 CUSTOMER_LIST example 4-12
D
data format link 7-7
data type comparisons 6-5, A-1 data universe definition 3-18 file in 3-18 report in 3-18 set in 3-18 view in 3-18 window in 3-18 database access 3-15 file hierarchy 3-15 database access 3-4 DATE input field A-5 DATE variable A-1 dates Rules Language A-6 short format A-4 sliding window A-5 DBCS data type A-7 DBD. see database diagram DBMS usage 3-16 DDE system component see also Dynamic Data Exchange client 7-6 data links 7-7 example 7-8 handle 7-6 item 7-5 server 7-5, 7-6 topic 7-5 using 7-5 debugging rule 1-4 deferred component 7-2 denormalizing 2-4 deploying applications 1-4 designing for reuse 6-2 desktop object, preparing as 1-5 directory component includes 6-3 display rule 5-1 default events 5-2 in thin client 5-2 structure 3-15 displaying dynamically generated HMTL 7-3 displaying dynamically generated HTML 7-3 distributed application rule 5-1 domain of values in combo box 5-9 in edit field 5-10 in table (MCLB) 5-10 donor entity relationship 2-4 downloading drawings 2-2
drawings downloading 2-2 engineering 2-2 dynamically generated HTML, displaying 7-3
E
edit field domain of values 5-10 enabling help 8-1 end-user interface window 3-11, 3-13, 5-5, 8-1 engineering tools 2-3 column option 2-7 definition 2-1 file generation method 2-7 query user 2-7 referential integrity 2-7 suffix option 2-7 text and keyword option 2-7 Enterprise Java Bean. see EJB enterprise repository date support A-6 entities creating relationships 1-2 relationships 1-2 entity identify 1-2 entity relationship diagram (ERD) 1-2 entity relationship diagrammer 1-2 ERD. see entity relationship diagram. event ChildRuleEnd 5-2 communicating, user 4-4 Java object 3-8 responding to 3-10 Rule initialize 5-2 Rule Terminate 5-2 RuleEnd 5-2 Window Initialize 5-2 Window Terminate 5-2 event post system component 4-4 event posting 4-6 event procedure 3-3, 3-11 EVENT_NAME field 4-9 EVENT_PARAM field 4-10 EVENT_QUALIFIER field 4-10 EVENT_SOURCE field 4-10 EVENT_TYPE field 4-9 EVENT_VIEW field 4-10 event-driven processing, example 5-7 rule default events 5-2 rule, definition 3-3 rule, developing 3-3
ii
event-driven processing 4-1 CASEOF statements 4-2 communication components 4-4 example 4-11 HPS_EVENT_VIEW 4-7, 4-9 modeless secondary windows 4-4 POST EVENT statements 4-6 posting rule 4-6 receiving rule 4-7 statements 4-2 subscription 4-1, 4-6, 4-7 eventing 4-6 global 4-1 implicit 4-6 local 4-1 events coding in Rules Language 4-3 global 4-1 HPS_EVENT_VIEW 4-4 interface 4-1, 4-3 user 4-1 examples event-driven processing 4-11, 5-7 executing applications 1-5 execution time, creating object 3-13
graphical user interface (GUI) 3-11, 3-13, 5-5, 8-1 GUI help 8-1 GUI_HELP_DIR variable 8-2 GuiObject type 3-12
H
handle, in DDE component 7-6 HDR (header) file 6-12 header (HDR) file, view structure in 6-12 header file 6-8 help, application AppBuilder 8-5 enabling 8-1 system components for 8-2 Windows 8-2 HELP_DIR variable 8-2 hierarchy attaching HPS_EVENT_VIEW 4-10 file for database access 3-15 rule 3-3 updating 6-4 HPEUE11 Sliding window module A-5, A-6 hps.ini file 1-5, 6-3, 6-12, 8-1, A-5 HPS_EVENT_POST_TO_CHILD system component 44, 4-5 HPS_EVENT_POST_TO_PARENT system component 4-5 HPS_EVENT_VIEW 4-8 attaching to rule hierarchies 4-10 EVENT_NAME field 4-9 EVENT_PARAM field 4-10 EVENT_QUALIFIER field 4-10 EVENT_SOURCE field 4-10 EVENT_TYPE field 4-9 EVENT_VIEW field 4-10 example 5-7 using 4-9 HPS_SET_HELP_TOPIC component 8-2 HPS_SET_HTML_FILE component 7-3 HPS_SET_HTML_FRAGMENT component 7-3 HPS_WEB_RESOURCE component 3-11
F
field help 8-6 file appbuilder.ini 8-1, 8-3, A-5 header (HDR) 6-12 hierarchy for database access 3-15 hps.ini 1-5, 6-3, 6-12, 8-1, A-5 native access 6-2 file generation method option in engineering tools 2-7 foreign key donor entity 2-4 recipient entity 2-4 forward engineering 2-1 forward trace 2-3 Freeway Explorer for migration A-7
G
generating rule 1-3 global eventing 4-1, 4-6 Java 4-8 global view 3-20 definition 3-6 GlobalEvent type 4-8
I
identify entity 1-2 implicit eventing 4-6 include directory (Java SDK) 6-10 includes directory 6-3
Index
iii
information model definition 3-16 diagram 3-17 rules 3-16 input & output view definition 3-5 input view definition 3-5 system component 7-2 INSTANCE clause 4-4 integrating existing code 6-2 interface events 4-1, 4-3
MIXED data type A-7 modeless secondary window 4-3, 4-4 multicolumn list box (MCLB) domain of values 5-10 multimedia, including in GUI 3-11 multi-threaded application 3-20
N
naming conventions, Java 6-7 naming view 3-5 native file access 6-2 nested case statements 4-2 network computing. see distributed applications
J
JAR file 1-4 Java advanced topics B-1 classes 6-8 debug 1-4 deploy 1-4 global eventing 4-8 help 8-1, 8-3 naming conventions 6-7 object 3-7 object for thin-client 3-8 rule 5-3 user component 6-7 Java rule calling C component 6-10 Java virtual machine (JVM) 4-8
O
object creating at execution time 3-13 for thin-client 3-8 Java 3-7 parsing reference 3-14 rule properties 3-17 objects with sets of values 5-9 ObjectSpeak 3-8 occurring views combo box values 5-10 online help, application AppBuilder 8-5 components 8-2 HPS_SET_HELP_TOPIC 8-2 SET_HELPFILE_name component 8-2 system components for 8-2 Windows 8-2 options Construction Workbench 1-5 Workbench Options 2-7 output view definition 3-5
L
leaf level process 3-3 life cycle, application development 1-1 local eventing 4-1, 4-6 logical data model 2-1
M
macro, in component code 6-10 MAP statement 3-9 mapping rule 3-18 Mapping Scenario 3-19 master.exe parameters 8-3 math functions 6-2 META tags, including in HTML 3-11 method calling 3-9 Java object 3-8 set 3-9 methodology 1-1 Migration Selective Export tool A-6
P
parameters, runtime 8-3 parsing object reference 3-14 POST EVENT statements 4-6 posting rule 4-6 prefix to view and field names 6-8 preparing applications 1-3 remote 1-3 primary (parent) rule detaching a process 4-4
iv
procedure standard 3-13 process detaching 4-4 leaf level 3-3 processing events 4-1 project design 1-2 property accessing 3-8 Java object 3-7
rule application hierarchy 3-3 converse 3-3 data 3-7 data universe 3-18 debug 1-4 display rule 5-1 display, structure 3-15 distributed application 5-1 event-driven 3-3 generating 1-3 hierarchy 3-4 information model 3-16 Java 5-3 mapping guidelines 3-18 properties 3-17 scope and size 3-7 stack 5-5 verify 3-6 view 3-4 Rule Initialize event 5-2 rule stack 5-5 Rule Terminate event 5-2 rule view 3-16 global 3-6 input 3-5 input & output 3-5 output 3-5 work 3-5 RuleEnd event 5-2 Rules Language CASEOF statements 4-2 coding events 4-3 compared to pseudocode 5-5 CONVERSE statements 4-2, 4-7 DATE data type A-6 interface events 4-3 POST EVENT statements 4-6 USE RULEDETACH statement 4-4 run time, creating object 3-13 runtime objects, Java 3-7 run-time parameters 8-3
Q
query language commands 3-4 query user option in engineering tools 2-7
R
receiving rule 4-7 recipient entity relationship 2-4 referential integrity option in engineering tools 2-7 relational data model 2-1 to logical data model 2-3 relationships entities 1-2 remote preparation 1-3 repositories dates A-6, A-7 repository dates A-6 responding to event 3-10 RETURN_CODE, example 5-7 reverse engineering 2-1, 2-3 reverse trace 2-3 root rule 5-2
S
scope and size of rule 3-7 secondary window, modeless 4-3, 4-4 servlet 3-11 set for combo box domain 5-9 for edit field domain 5-10 set method 3-9 SET_HELPFILE_name component 8-2 short DATE format A-4
Index
SHOW_HELP_TOPIC component 8-2 sliding window, for DATE support A-5, A-6 source code, editing 6-4 SQL statement, adding to rule 3-4 SQL Builder 3-4 requirement 3-4 standard procedure 3-13 statements CONVERSE 4-2 Status window Verify tab 3-6 subscription 4-6 definition 4-1 posting rule 4-6 receiving rule 4-7 suffix option in engineering tools 2-7 supported Java classes 6-8 supporting dates A-1 synchronization 3-20 syntax of event procedure 3-11 verify 3-6 system components deferred 7-2 Dynamic Data Exchange 7-4 for online help 8-2 hierarchy 7-1 HPS_EVENT_POST_TO_CHILD 4-4 HPS_EVENT_POST_TO_PARENT 4-4 HPS_SET_HELP_TOPIC 8-2 input view 7-2 online 7-1 output view 7-2 SET_HELPFILE_name 8-2 SHOW_HELP_TOPIC 8-2 system initialization file (hps.ini) 1-5, 6-3, 6-12, 8-1, A-5
tools engineering 2-1 Workbench Options 1-5 tools for engineering 2-3 trace analysis definition 2-3 transformation from relational data model to objects 2-3
U
USE RULEDETACH statement 4-4 user component about 6-1 C source 6-8 creating and editing source 6-4 designing for reuse 6-2 guidelines for writing 6-2 Java 6-7 keeping current 6-3 sample C component 6-13 setting up hierarchy 6-4 when to use 6-1 writing 6-3 user event communicating 4-4 for modeless secondary window 4-3 using Java objects 3-7
V
values of set as domain for combo box 5-9 of set as domain for edit field 5-10 values, domain of 5-9, 5-10 VARCHAR data type A-7 verification language 3-6 verify all 3-6 definition 3-6 rule 1-4 syntax 3-6 Verify All 3-6 Verify Syntax 3-6 Verify tab 3-6 view 3-4 and component 6-3 global 3-6, 3-20 input 3-5 input & output 3-5 of system component 7-2 output 3-5 work 3-5 view, rule naming 3-5
T
table (MCLB) domain of values 5-10 testing see also debug text and keywords option in engineering tools 2-7 thin client Java object 3-8 thin-client display rule 5-2 thin-client see also Java thread-safe component 6-11 THRESHHOLD_MET 4-8
vi
W
window communicating user events 4-4 detaching a process (modeless secondary window) 4-4 event for modeless secondary 4-3 modeless, posting rule 4-6 modeless, receiving rule 4-7 window help 8-6 Window Initialize event 5-2 Window Painter domain set 5-9 window rule. See display rule. Window Terminate event 5-2 work view 4-9 calling C component from Java 6-12 definition 3-5 Workbench Options 1-5 Drawing Tools 2-7 Engineering 2-7 General 1-5 workgroup repository date support A-7 workstation system component HPS_EVENT_POST_TO_CHILD 4-5 HPS_EVENT_POST_TO_PARENT 4-5
Y
YEARS_IN_THE_FUTURE variable A-5
Index
vii

App Builder Developing Applications

Uploaded by

Copyright:

Available Formats

App Builder Developing Applications

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

App Builder Developing Applications

Uploaded by

Copyright:

Available Formats

BluePhoenix AppBuilder 2.1.0.

Developing Applications Guide

AppBuilder 2.1.0 Developing Applications Guide

Designing with Engineering Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Adding Business Logic Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

AppBuilder 2.1.0 Developing Applications Guide

Creating Event-driven Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Handling Display Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

AppBuilder 2.1.0 Developing Applications Guide

Adding User Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Adding System Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Creating Online Help for Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Troubleshooting Application Development . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Data Type Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

AppBuilder 2.1.0 Developing Applications Guide

AppBuilder 2.1.0 Developing Applications Guide

What is the Development Process?

AppBuilder 2.1.0 Developing Applications Guide

What is the Development Process?

What is the Development Process?

AppBuilder 2.1.0 Developing Applications Guide

What is the Development Process?

Rules Generated to Java

Customizing the Environment

Customizing the Environment

Initialization Settings (INI Files)

AppBuilder 2.1.0 Developing Applications Guide

Customizing the Environment

DESIGNING WITH ENGINEERING TOOLS

AppBuilder 2.1.0 Developing Applications Guide

AppBuilder 2.1.0 Developing Applications Guide

Understanding Engineering Diagrams

Understanding Engineering Diagrams

Designing with Engineering Tools

The Entity Relationship Diagram (ERD)

The Database Diagram (DBD)

Tools for Transforming

Tools for Trace Analysis

AppBuilder 2.1.0 Developing Applications Guide

Understanding Entity Relationships

Tools for Denormalizing

Understanding Entity Relationships

Designing with Engineering Tools

Understanding Entity Relationships

One to Many Relationship

Many to Many Relationship

Supertype to Subtype Relationship

AppBuilder 2.1.0 Developing Applications Guide

Understanding Entity Relationships

Designing with Engineering Tools

Setting Engineering Tool Options

Setting Engineering Tool Options

Table 2-2 Option

File generation method

Query user Referential Integrity Text and keywords

AppBuilder 2.1.0 Developing Applications Guide

Setting Engineering Tool Options

Designing with Engineering Tools

ADDING BUSINESS LOGIC COMPONENTS

AppBuilder 2.1.0 Developing Applications Guide