| Table of Contents |
|---|
Overview
Business logic includes (also called domain logic) defines the real-world business rules that determine how data can be created, stored, and changed (see Wikipedia definition here). Some applications use rigid business logic that is imposed or constrained by the software vendor. These approach may limit what data can be collected or what quality control measures can be implemented in the field. WSG InventoryManager System, by contrast, is highly flexible and supports configurable business logic throughout the system. This requires, however, some configuration in order to achieve the desired business logic for your implementation.
...
Requirements - While requirements aren’t necessarily a part of the final implemented system, they are a critical component and represent the starting point for developing the specific business logic. The process of documenting requirements starts by gathering all of the existing field manuals, cruise specs, merch specs, analysis spreadsheets, databases, etc. These are reviewed together to make sure they are still relevant, are exhaustive and then are used to populate WSG templates for the next step - developing the data model(s).
Data Model(s) - A data model, also known as a database schema, defines the data storage in terms of the unique tables and fields that are used to store data. WSG InventoryManager System uses ArcGIS as the data storage solution, and thus the data model is implemented as a geodatabase, which is accessed via ArcGIS Online or Portal. As such, the data model utilizes the ArcGIS database constraints in terms of table types, geometry types, data types, allowed values, etc. The data modeling process is documented in MobileMap: Data Model / Data Modeling Process. A given client might have one or more data models, depending on the different types of cruising that they do.
MobileMap Settings - MobileMap settings can both extend and overwrite logic implemented at the data model level. For example, in ArcGIS services are either read-only or editable, and all layers inherit that property. MobileMap settings can be used to make some layers read-only in an editable service. The same can be done with regards to specific attribute fields - they can be set to be hidden or read only within MobileMap, even when those fields are visible and editable in other interfaces like ArcGIS Online and InventoryManager. MobileMap Settings are covered in more detail in MobileMap: Settings.
Rules - Rules are complex business rules that govern data collection. They extend the ArcGIS data model by adding complex 'if/then' business logic. An example of this logic is “if a tree has a broken top, then the total height measurement is required”. Rules are developed after the data model, so that the team can see both the default logic of the data model and how it is enhanced via rules. See InventoryManager: Validation Rules And Related Domains for more details on Rules.
Related Domains - Related domains are a special case of business rules in which lists of allowed values are modified based on the value selected. They are typically added when the user experience, in terms of See InventoryManager: Validation Rules And Related Domains for more details on Related Domains.
Configurable Defaults - Configurable defaults are business rules that are applied on a specific mobile device and which can override default values that are assigned at the data model level. As an example, a data model for the Pacific Northwest might have a default species of Douglas fir, but a particular cruise might have more western hemlock. In this case, configurable defaults can be used to override the data model default of Douglas fir with western hemlock on the devices being used for this cruise. MobileMap: Data Collection Optimization See https://woodlandsg.atlassian.net/wiki/spaces/MD/pages/33115/MobileMap+Data+Collection+Optimization#Configurable-Defaults for more details on Configurable Defaults.
Check Rules - Check rules are similar to standard Rules described above but apply to scoring of check cruised (audited) Plots. Check rules allow for automated, objective calculation of check cruise score for any plots that have been checked. These scores can the be used to understand cruise and cruiser accuracy via reports and interactive dashboards. See Inventory Management System: Check Cruising ,InventoryManager: Check Cruise Rules and MobileMap: Check Cruising for more details on check cruising and check cruise scoring rules.
Compilation Configuration - Compilation and reporting are by far the most complex aspects of the system when it comes to business logic. Compilation configuration includes definition of merch specs (e.g., log rules, min top diameter, max log length, stump height), volume equations and/or taper functions, logic for dubbing in missing data, logic for grouping, desired statics, preferred units, conversion factors, output tables, statistical metrics to report, etc.
...
A 100% flexible system might allow a cruiser to leave any data collection field empty, or input any value they want to enter. This would obviously create potential data quality issues, even when resposibleresponsible, well-intentioned field staff collect data. They might simply miss a field accidentally, or introduce a typo when entering data. On the other hand, a completely rigid, standardized system might force a user to omit unexpected or unusual data, or prevent use of the system for new type of data collection.
...