Home 
 1. Designer User Interface 
 Themes 
 Ribbon Menu 
 Window Panes 
 Customisation 
 Navigation 
 2. Process Design 
 Styles 
 Sub-Processes 
 Business Objects 
 Naming Conventions 
 Layout 
 Integrated Help 
 3. Form Design 
 Form Properties 
 Fields 
 Fields and Variables 
 Option Lists 
 Field Grouping 
 Field Layout 
 Tab Order 
 4. Multi-Language Support 
 Adding Languages 
 In the Client 
 Dynamic Options 
 Conclusion 
 5. Business Objects 
 Architecture 
 System Business Objects 
 Custom Business Objects 
 Using Business Objects 
 6. Naming Conventions 
 Variables 
 Processes 
 Solution Tables 
 Roles 
 Forms 
 Business Objects 
 Admin Groups & Forms 
 Stages and Actions 
 Visual Script Activities 
 Flags 
 Projects & Solutions 
 7. Writing Code 
 8. Reports 
 9. Component and Code Reuse 
 10. File structure 
 11. Web Client 
 12. Administration Tools 
 13. Summary 
Architecture
The overall architecture is:
  • Connection
  • Business Object
  • Business Object instance
  • Field or grid column.
The Connection is the database or LDAP connection. In this discussion we concentrate on the database Business Objects. These can employ the default connection to the Metastorm database, or an external database Connection.
There are several different ways a Business Object may be employed. Unfortunately these are not clearly described in the documentation, and no small amount of confusion is possible. The ways a Business Object may be employed are as follows:
  • Editable table
  • Single editable record
  • Single read-only record
  • List of records
  • Filtered list of records
It could be argued that these last two are identical, but we differentiate because they tend to be used very differently. A filtered list will typically have one or more filters that can be changed at run-time to filter the return list. A list of records will typically be a static list. This will not need updating during use. The difference in usage is the need to set the instance as ‘always refresh’ for those instances where the result may change.
Similarly, on can use the same Business Object for a single editable record and a single read-only record. The difference here is that an editable record required a Primary Key, and a single table, whereas a read-only record does not. You can easily use an editable Business Object as a read-only Business Object, but not the other way around.
The main use of Business Objects is as a single editable recordset. The system generated Process Context and Process Data Business Objects are examples of these. These require a single table reference with a unique reference. In order to be editable, tables require a Primary Key.
For certain uses, the Business Object instance may be parsed and a single or column or a pair of columns extracted. These are for options lists such as (and we believe limited to) dropdown and listbox fields.
In grids, the entire recordset is displayed.
The documentation is not particularly clear on these different uses of Business Objects in general. It seems to limit the differences to Query and Table types, rather than the potential uses of the Business Object.
Go to:
System Business Objects (Next topic)
Top