Overview

Business logic (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.

Business logic in WSG InventoryManager System can be broken down into 7 main components:

1. 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).

2. 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 https://woodlandsg.atlassian.net/wiki/spaces/MD/pages/323125284. A given client might have one or more data models, depending on the different types of cruising that they do.

3. 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 https://woodlandsg.atlassian.net/wiki/spaces/MD/pages/360559.

4. 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 https://woodlandsg.atlassian.net/wiki/spaces/MD/pages/307888249 for more details on Rules.

5. Related Domains - Related domains are a special case of business rules in which lists of allowed values are modified based on the value selected. See for more details on Related Domains.

6. 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. See for more details on Configurable Defaults.

7. 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 , and for more details on check cruising and check cruise scoring rules.

8. 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.

Implementing Business Logic

Given the multiple ways in which business logic can be implemented within WSG InventoryManager System, it is helpful to follow a well-defined process for designing, implementing and testing business logic. This helps to speed up the process, and to ensure that all aspects of business logic have been considered and implemented correctly. The diagram below shows the high-level workflow for defining and implementing business logic. The first 3 steps are required for all implementations - gathering and documenting requirements, designing and implementing at least 1 data model, and adding at least a few Rules for data quality control. The next steps, Related Domains and Configurable Defaults, are optional but are commonly used once the system is ready for production use. The final steps are both optional and only implemented for some systems. They require specific license levels in InventoryManager and may not be needed by some organizations.

Open

Business Logic Trade-Offs

Flexibility vs. Standardization

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 responsible, 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.

We encourage organizations to find a balance, based on their business needs, between flexibility and standardization. Examples include the following:

1. Include values like ‘N/A’ or ‘Other’ in lists of allowed values

2. Include ‘notes’ fields at the Stands, Plots and even Trees levels

3. Include extra fields that you may not need in your data model. These can be hidden from users if never get used, but if they are need in the future they can be enabled without having to redesign the data model. Examples include the data quality fields noted in the data modeling documentation (), including time on plot and distance to plot. Another example is inclusion of alternate height fields (e.g., merch height, form class height, taper function height) that might be needed to support specific volume collections for some species, regions, etc. A final example might be inclusion of Defect fields at the Trees and Logs levels. For any given cruise, rules could determine which field to use and which to hide from the user.

Data Model vs. Rules

Often business logic can be enforced at the data model or rules level. Consider the case of requiring species on all tree measurements. This can be achieved by setting field to required (non-nullable) in the data model, or by adding a Rule that says that species can never be null. While both approaches will achieve the same thing, the latter is more flexible. What if the need arises for a rapid assessment of Basal Area of a forest Stand that recently burned in a wildfire? It might be fastest to use a simple tally approach on a prism plot to quickly calculate the BA as tree count * BAF. If the data model requires the species field to be populated, however, it will need to be populated for each tree in the field before it can be saved. By using rule, however, the rule can be omitted for a particular cruise and thus enable collection of trees without species information.

A key question before implementing any aspect of business logic is to ask the question: Is this ALWAYS true? If the answer is yes, then it is OK to implement it at the data model level. If not, it likely is better handled as a Rule.

System-Wide vs. Local

Another trade-off occurs at the system vs. local (device) level. A good example of this is the use of default values. While it might be tempting to apply a default value for Species or Product in the data model, it is often best to use Configurable Defaults to apply those on a particular field device when they would aid with data collection speed or data quality.

Single vs. Multiple Data Models

Some organizations choose to implement a single, exhaustive, data model that includes all attribute fields for every type of cruise that they ever conduct. Other organizations implement a small number 2-4 data models, each focused on a very specific type of cruise (e.g., timber sale vs. continuous forest inventory vs. seedling establishment surveys). Finally, some organizations implement a new data model for each major client or project. All are valid approaches but there are tradeoffs that should be considered.

Using a single data model results in all data entering a single database, where it can be easier to manage, backup, analyze.

Business Logic Examples

The table below contains a few examples of business logic that have emerged from requirements gathering along with the approach that can be used to implement it. While there may be other ways to implement this logic within the system, the rational for the approach described is listed to help understand why that approach was selected.