2023.1:Node Tree (UI Element)

WIP	This article is a work-in-progress or created as a placeholder for testing purposes. This article is subject to change and/or expansion. It may be incomplete, inaccurate, or stop abruptly. This tag will be removed upon draft completion.

This article is about an older version of Grooper. Information may be out of date and UI elements may have changed.
2025	2023.1

The Node Tree is the hierarchical list of Grooper node objects found in the left panel in the Design Page. It is the basis for navigation and creation in the Design Page.

Resources are created in Grooper by adding new "nodes" to the Node Tree. The Node Tree is called a "tree", because it "branches." Each new node added under another creates a new "branch", or a new level down from the node it is created. What object types can be added under a branch are determined by the node(s) above it.

Grooper Nodes

Any single item in the Node Tree is a Grooper Node (also simply referred to as a "node"). Each node has a Node Object Type, which defines what that node is, how it is configured and used throughout the Grooper Repository. For example, a Batch is the 'Node Object Type (often just called "object") that serves as the fundamental document container in Grooper.

Each new node creates a new branch under an existing one, creating the hierarchical structure of the tree.

FYI	In Grooper, nodes and their properties are stored in the database connected to a Grooper Repository.

How do nodes create hierarchy in the Node Tree?

Example of a Node Tree with branching hierarchy

At the top of the Grooper Repository is the Root node (aka the "Grooper Root").

Under the Root node, there are six main child nodes in the Node Tree. These nodes serve the purpose of organizing Grooper nodes according to their object type to assist Node Tree navigation.

• Batches
• Projects
• Processes
• Queues
• File Stores
• Machines

Every Grooper Repository will contain these nodes and their contents, or "child" nodes.

• For example Project nodes are added as children in the "Projects" folder node.
• Content Model nodes are added as children of an individual Project node.
• Batches are nodes created and stored in either the Batches > Production or Batches > Test folder nodes.

When you create a new node, it is added as a "child" of another node. The node containing a child node is called its "parent"

• As nodes get added to other nodes, the node tree branches off into different levels.
• These different branches create the Node Tree's hierarchical structure.

What's the difference between a node and an object?

A "node" is something you add to the Node Tree. Every node has an object type. An "object" is the type of thing that node is.

For Example: Here, there are three nodes named "Name" "DOB" and "SSN".

• These are individual nodes in the Node Tree.
• However they share the same object type. They are all Data Fields.

BE AWARE: The terms "node" and "object" are so similar many people use the terms interchangeably. You will probably even find occurrences in the Grooper Wiki where we refer to a "node" as an "object".

More on parents and children

Parent nodes determine many things for their children. The parent node's object type dictates what its children can be. It controls what possible object types its child nodes can be. Parents and children will also pass information to each other in different ways, depending on their object types.

The parent node will always determine what object types (if any) can be created as children.

• This may be more restrictive.
  • For Example: A Data Model can only have Data Field, Data Section or Data Table nodes as its immediate children.
  • Furthermore, Data Tables themselves can only have Data Columns as children.
• This may be more permissive when the parent node is more of a folder organizing child nodes.
  • For Example: A Content Model's Local Resources folder or a Project node.
  • Many different kinds of node objects can be added as nodes in a Local Resources folder.
  • Almost every type of node object can be added to a Project

The parent node's object type also determines what information is passed to and from the parent and child nodes.

• For Example: A Content Model will pass its Export Behavior configuration to child Document Types. This way users don't have to configure Export Behavior settings to multiple Document Types using the same export logic.
• For Example: a Data Type's children Value Readers will pass all results they return to the parent Data Type. Those results will then be collated according to the Data Type's configuration

The Grooper Root

At the top of the Grooper Repository is the Root node (aka the "Grooper Root"). It contains all Grooper nodes as its children. It also stores several settings that apply to the connected Grooper Repository, including:

• The Active File Store location.
  • Visit the Install and Setup article for more information on Grooper Repositories and File Stores.
• The License Serial# or URL configuration.
  • Visit the License Activation article for more information about how to license your Grooper install.
• Any security settings stored in the the Permission Sets.

⚠

"Root node" is a common term in computer science. Be careful about commonly interchanged words. Informally, "root node", "Grooper Root", and even just "root" are often used interchangeably. However, "root node" and "root" are more general terms. You may, for example hear a Batch's root folder be called a "root node" as well. Or any node with a complex child node hierarchy may be referred to as the "root" relative to one of its children (like the "root" extractor of a Data Type with multiple child Data Types and Value Readers).

Glossary

Batch: inventory_2 Batch nodes are fundamental in Grooper's architecture. They are containers of documents that are moved through workflow mechanisms called settings Batch Processes. Documents and their pages are represented in Batches by a hierarchy of folder Batch Folders and contract Batch Pages.

Content Model: stacks Content Model nodes define a classification taxonomy for document sets in Grooper. This taxonomy is defined by the collections_bookmark Content Categories and description Document Types they contain. Content Models serve as the root of a Content Type hierarchy, which defines Data Element inheritance and Behavior inheritance. Content Models are crucial for organizing documents for data extraction and more.

Data Column: view_column Data Columns represent columns in a table extracted from a document. They are added as child nodes of a table Data Table. They define the type of data each column holds along with its data extraction properties.

• Data Columns are frequently referred to simply as "columns".
• In the context of reviewing data in a Data Viewer, a single Data Column instance in a single Data Table row, is most frequently called a "cell".

Data Field: variables Data Fields represent a single value targeted for data extraction on a document. Data Fields are created as child nodes of a data_table Data Model and/or insert_page_break Data Sections.

• Data Fields are frequently referred to simply as "fields".

Data Model: data_table Data Models are leveraged during the Extract activity to collect data from documents (folder Batch Folders). Data Models are the root of a Data Element hierarchy. The Data Model and its child Data Elements define a schema for data present on a document. The Data Model's configuration (and its child Data Elements' configuration) define data extraction logic and settings for how data is reviewed in a Data Viewer.

Data Section: A insert_page_break Data Section is a container for Data Elements in a data_table Data Model. variables They can contain Data Fields, table Data Tables, and even Data Sections as child nodes and add hierarchy to a Data Model. They serve two main purposes:

1. They can simply act as organizational buckets for Data Elements in larger Data Models.
2. By configuring its "Extract Method", a Data Section can subdivide larger and more complex documents into smaller parts to assist in extraction.
   • "Single Instance" sections define a division (or "record") that appears only once on a document.
   • "Multi-Instance" sections define collection of repeating divisions (or "records").

Data Table: A table Data Table is a Data Element specialized in extracting tabular data from documents (i.e. data formatted in rows and columns).

• The Data Table itself defines the "Table Extract Method". This is configured to determine the logic used to locate and return the table's rows.
• The table's columns are defined by adding view_column Data Column nodes to the Data Table (as its children).

Data Type: pin Data Types are nodes used to extract text data from a document. Data Types have more capabilities than quick_reference_all Value Readers. Data Types can collect results from multiple extractor sources, including a locally defined extractor, child extractor nodes, and referenced extractor nodes. Data Types can also collate results using Collation Providers to combine, sift and manipulate results further.

File Store: hard_drive File Store nodes are a key part of Grooper's "database and file store" architecture. They define a storage location where file content associated with Grooper nodes are saved. This allows processing tasks to create, store and manipulate content related to documents, images, and other "files".

• Not every node in Grooper will have files associated with it, but if it does, those files are stored in the Windows folder location defined by the File Store node.

Grooper Repository: A Grooper Repository is the environment used to create, configure and execute objects in Grooper. It provides the framework to "do work" in Grooper. Fundamentally, a Grooper Repository is a connection to a database and file store location, which store the node configurations and their associated file content. The Grooper application interacts with the Grooper Repository to automate tasks and provide the Grooper user interface.

Machine: computer Machine nodes represent servers that have connected to the Grooper Repository. They are essential for distributing task processing loads across multiple servers. Grooper creates Machine nodes automatically whenever a server makes a new connection to a Grooper Repository's database. Once added, Machine nodes can be used to view server information and to manage Grooper Service instances.

Node Tree: The Node Tree is the hierarchical list of Grooper node objects found in the left panel in the Design Page. It is the basis for navigation and creation in the Design Page.

Permission Sets: Permission Sets define security permissions in a Grooper Repository for a user or group. This allows you to restrict user access to specified Grooper pages (such as the Design Page) and Grooper Commands.

• "Permission Set" is the embedded object that defines security principles. They are added to a Grooper Repository and configured using the "Permission Sets" property found on the database Root node.

Project: package_2 Projects are the primary containers for configuration nodes within Grooper. The Project is where various processing objects such as stacks Content Models, settings Batch Processes, profile objects are stored. This makes resources easier to manage, easier to save, and simplifies how node references are made in a Grooper Repository.

Repository: A "repository" is a general term in computer science referring to where files and/or data is stored and managed. In Grooper, the term "repository" may refer to:

• PRIMARILY a Grooper Repository. This is most commonly what people are referring to when they simply say "repository".
• Less commonly a CMIS Repository

Root: The Grooper database Root node is the topmost element of the Grooper Repository. All other nodes in a Grooper Repository are its children/descendants. The Grooper Root also stores several settings that apply to the Grooper Repository, including the license serial number or license service URL and Repository Options.

UI Element: A UI Element is a portion of the Grooper interface that allows users to interact with or otherwise receive information about the application.

Value Reader: quick_reference_all Value Reader nodes define a single data extraction operation. Each Value Reader executes a single Value Extractor configuration. The Value Extractor determines the logic for returning data from a text-based document or page. (Example: Pattern Match is a Value Extractor that returns data using regular expressions).

• Value Readers are can be used on their own or in conjunction with pin Data Types for more complex data extraction and collation.