Use the following best practices as a guide when building custom business objects.
Joins
- Never try to filter or join on a calculated field. Instead, join on primary keys when possible.
- Only join tables that are required, and do not join tables if it is not necessary.
Properties
- Limit the number of properties used in the business object to only those specifically necessary.
- Never use the TIME_STAMP property, as this property can cause issues throughout areas in which the BO is used. There are plans to drop the property from the schema in a future release.
- Use the property field, Function, sparingly. Performance can be affected if functions are used too frequently in select statements and without due caution.
Calculations
- Perform calculations in the query display columns and not in the BO definition when possible.
- Using calculated fields in a filter or WHERE clause causes a table scan. If the data in the business object returns hundreds of thousands (or more) of rows, the table is scan is slow and resource intensive. Adding the calculations to the IQA query instead of the business object helps prevent trying to use the same calculation in a filter or WHERE clause (or on a JOIN).
- When it is not possible to perform the calculation outside of the business object, it is important that the business object is not used in a query with a filter on the calculated property.
Location
All business objects must reside in the default Design Business Object Definition folder. Do not move business objects into other folders or create subfolders in the Design Business Object Definition folder, as moving business objects to other folders will break functionality.
Naming
- Prefix each business object name using My_, such as My_CustomBOname. See Naming recommendations for more details.
- Never name a business object the same name as a table, as this can cause errors throughout iMIS where the original table that the BO is named after is being used.
- Business Objects cannot begin with an underscore or number.