Root

Specifies the File Store object that will be used for all new file content created in the repository.

• Repository-wide Effect:
  When set, all new files (such as document images, attachments, and extracted content) are saved to the selected file store.
  Existing files remain in their original file stores and are still accessible.

• Changing the Active File Store:
  This property is typically changed when:

  • The current file store is nearing capacity and you need to expand storage.
  • You want to migrate new content to a different storage tier (e.g., for archiving or cost optimization).
  • Moving to new infrastructure or network locations. Changing the active file store does not move existing files; it only affects where new files are written.

• Best Practices:

  • Ensure the new file store path is accessible to all Grooper services and users before switching.
  • Use UNC paths for network storage to avoid issues with mapped drives.
  • Monitor 'Disk Free Space' and 'Total File Count' on all file stores to plan for expansion or archiving.
  • Document any changes to the active file store for audit and disaster recovery purposes.

• Notes:

  • After changing this property, verify that all Grooper service processes have access to the new file store location.
  • Service restarts may be required in some environments to recognize the change.
  • New Grooper repositories are itialized using the GCC connections init command. During this initialization, a new file store is created and named "Primary". The network path used by the this file store is provided when the init command is executed.

This property configures the licensing mode for the Grooper repository and supports two scenarios:

1. Cloud-Hosted Licensing (Serial Number)

• Usage: Enter your Grooper license serial number (GUID format) to use cloud-hosted licensing.
• How it works: Grooper services and applications will connect to the BIS licensing web service at https://licensing.bisok.com to validate and obtain a license.
• Network Requirements: All Grooper services and applications must have outbound connectivity to https://licensing.bisok.com on port 443 (HTTPS).
• Steps:
  1. Obtain your license serial number from BIS.
  2. Enter the serial number in this property.
  3. Ensure all Grooper services and clients can reach the licensing endpoint.
• Best Practices: Document the serial number and keep it secure. If you change the serial number, all services must be restarted to recognize the new license.

2. Self-Hosted Licensing (License Service URL)

• Usage: Enter the full URL to your on-premises Grooper Licensing service (e.g., http://servername:port/GrooperLicense).
• How it works: Grooper services and applications will connect to the specified URL to validate and obtain a license from your local license server.
• How to set up:
  1. Install the Grooper Licensing service on a server in your environment.
  2. Use the GCC license download command to bind your license to the server.
  3. Copy the service URL from the Grooper Licensing service and paste it into this property.
• Network Requirements: All Grooper services and applications must be able to reach the specified URL.
• Best Practices: Use a stable server and document the URL. Update this property if the license server is moved or reconfigured.

Additional Notes and Best Practices

• Changing the License: Any changes to this property require all Grooper applications and services to be restarted to take full effect. After editing in the web client, refresh the browser to see changes.
• Validation: If the value is a valid GUID, it is treated as a serial number; otherwise, it is treated as a URL.
• Troubleshooting:
  • Ensure network connectivity to the specified endpoint.
  • Verify the serial number or URL is correct and active.
  • Check Grooper event logs for licensing errors if activation fails.
• Impact: If licensing is not valid or cannot be obtained, Grooper functionality will be restricted or disabled.

The Permission Sets property is the central mechanism for configuring security and access control in Grooper.

Overview

• Each Permission Set defines a collection of rights for a group of users or roles, such as access to design features, command execution, or specific UI pages.
• When this list is empty, all authenticated users have full design and administrative rights (open mode).
• When one or more permission sets are present, only users included in at least one set have access, and their rights are determined by the union of all applicable sets (restricted mode).

Configuration and Usage

• Typical Setup:
  • Create a 'Designers' permission set with full access for system administrators and solution designers.
  • Create a 'Users' or 'Operators' set with limited access for end users, restricting design and configuration features.
  • Add users or groups to each set as appropriate.
• Role-Based Access:
  • Define additional permission sets for specialized roles (e.g., QA, Reviewers, Importers) to grant only the rights needed for their tasks.
• Cumulative Rights:
  • If a user belongs to multiple permission sets, their effective rights are the combination of all sets (i.e., least restrictive).

Best Practices

• Principle of Least Privilege:
  Grant users only the permissions required for their role.
• Periodic Review:
  Regularly audit permission sets and membership to ensure security and compliance.
• Testing:
  Test user access with different combinations of permission sets to verify expected behavior.
• Documentation:
  Document the purpose and membership of each permission set for future maintenance.

Impact and Troubleshooting

• If no permission sets are defined, all users have unrestricted access.
• If a user is not a member of any permission set, they will be denied access to design and administrative features.
• Use Review Queues in Batch Processes and Batch Process Steps to further control who can perform specific work.
• Changes to permission sets may require users to log out and back in to take effect.

The Remote Repositories property enables integration, publishing, and transfer of content between multiple Grooper repositories.

Overview

• Each Remote Repository entry defines a connection to an external Grooper repository, typically via the Grooper API Services.
• Used for cross-repository publishing, batch transfer, migration, and distributed workflow scenarios.
• Common use cases include:
  • Publishing Projects or configuration objects to a remote repository for deployment or sharing using the Publish To Repository command.
  • Transferring Batches between production, test, or archival repositories using the Batch Transfer activity.
  • Supporting multi-site or multi-tenant Grooper environments.

Configuration and Usage

• Adding a Remote Repository:
  1. Use the property grid or collection editor to add a new Remote Repository entry.
  2. Specify the service URL, name, and any required authentication or API keys.
  3. Validate the connection to ensure the remote repository is reachable and compatible.
• Editing/Removing:
  • Update connection details as needed if the remote repository is moved or reconfigured.
  • Remove unused or obsolete entries to maintain a clean configuration.
• Security:
  • Ensure secure network connectivity and proper authentication between repositories.
  • Use HTTPS endpoints and strong API keys where possible.

Best Practices

• Use descriptive names for each remote repository to clarify its role (e.g., "Production", "Test", "Archive").
• Periodically review and test all remote connections, especially after network or infrastructure changes.
• Document the purpose and configuration of each remote repository for future maintenance.
• Limit access to remote publishing and transfer features to trusted users and roles.

Troubleshooting

• If publishing or transfer fails:
  • Verify network connectivity and firewall rules between source and target repositories.
  • Check authentication credentials and API keys.
  • Review Grooper event logs for error details.
  • Ensure the remote repository is running a compatible version of Grooper and API Services.

Related Features

• Publish To Repository command: Publishes nodes to a remote repository.
• Batch Transfer activity: Transfers batches to a remote repository.
• API Services: Required for remote repository integration.

The Options property allows you to enable and configure various optional features and behaviors within the Grooper repository.

• The list can contain multiple Repository Options, but only one instance of each option type.
• Options are used to extend repository functionality without cluttering the main configuration with rarely used or advanced settings.

A combination of the following flags:

The Enabled Event Types property controls which types of events are written to the Grooper event log. This allows you to tailor event logging to your operational, diagnostic, and compliance needs.

Available Event Types (see )

• Err: Errors – Critical error messages indicating failures or exceptions.
• Wrn: Warnings – Non-critical issues or potential problems.
• Prc: Procedural – Tracing of procedural calls. Enabling this can generate large volumes of log entries; use only for troubleshooting.
• Inf: Information – Detailed informational messages. Enabling this can generate large volumes of log entries; use only for troubleshooting.
• Aud: Audit – Audit trail events such as batch creation, object deletion, and other significant actions.

How It Works

• Only events matching the selected types are recorded in the event log.
• The event log can be viewed by selecting the Root node and opening the Events tab in the Grooper UI.

Configuration Guidance

• Production: Enable Err, Wrn, and Aud for essential monitoring and compliance.
• Development or Troubleshooting: Temporarily enable Prc and Inf for detailed tracing and diagnostics.
• Adjust as needed to balance log detail with performance and storage considerations.

Best Practices

• Regularly review event logs for errors, warnings, and audit events.
• Archive or export logs periodically for long-term retention or compliance.
• Limit verbose logging (Prc, Inf) to troubleshooting sessions to avoid excessive log growth.

The Compression property determines how continuous tone images (color and grayscale) are compressed when saved to the File Store.

How It Works

• This setting applies repository-wide as the default for all color and grayscale images.
• It controls compression quality, DCT mode, and other JPEG-specific options.
• Black and white images are always saved using CCITT Group 4 compression, regardless of this setting.
• Local overrides: Certain activities or nodes (such as import, export, or image processing steps) may allow you to specify different compression settings for specific workflows.

Impact and Best Practices

• Storage vs. Quality: Higher compression reduces file size but may degrade image quality, which can affect downstream processes such as OCR.
• Testing: Test compression settings with representative documents to ensure acceptable quality and performance.

The Cache Refresh Interval property determines how long configuration objects (such as nodes, settings, and metadata) remain in memory cache when not in use.

How It Works

• Configuration objects that have not been accessed for the specified interval are eligible to be purged from the cache.
• When an object is purged and later needed, it is reloaded from the database, ensuring the latest changes are picked up.
• This setting helps balance memory usage, performance, and responsiveness to configuration changes.

Configuration Guidance

• Development Environments: Use a lower value (e.g., 1–5 minutes) to ensure frequent reloads and rapid recognition of configuration changes.
• Production Environments: Use a higher value (e.g., 30–120 minutes) to maximize performance and reduce database load, as configuration changes are less frequent.
• Unlimited Cache: A value of zero disables automatic purging; configuration objects are only loaded once per process lifetime. In this mode, services must be restarted to pick up changes.

Best Practices

• For optimal performance in a pure production repository, use a value of 0. However, this will require Activity Processing services to be restarted whenever configuration changes are made.
• Cache purging is most helpful when designers are editing and testing configurations, and need running services to automatically recognize configuration changes.
• Adjust the interval based on your environment and how often configuration changes are expected.
• After changing this property, restart all Grooper services and processes for the new interval to take effect.
• Monitor memory usage and performance, and tune the interval as needed.

RepositoryName provides the human-readable name for the repository, used throughout the Grooper UI, logs, and reports.

• This value is typically set during repository creation or via the Grooper Command Console.
• Changing the repository name does not affect its unique identity or database location.
• Use descriptive names to distinguish between environments (e.g., "Production", "Test", "Archive").

Repository Id is assigned when the repository is created and never changes.

• Used internally and in API/database operations to uniquely identify the repository.
• Essential for scripting, automation, and integration scenarios.
• Do not attempt to modify this value; it is critical for repository integrity.

Server Name reflects the server and instance as defined in the repository's connection settings.

• Useful for troubleshooting, migrations, and verifying the active database host.
• Format: ServerName or ServerName\InstanceName for named instances.
• For cloud or managed SQL, may reflect a fully qualified domain name.

Database Name is used in connection strings, maintenance scripts, and backup/restore operations.

• Changing the database name requires updating connection settings and may require service restarts.
• Ensure the database name is unique within the SQL Server instance to avoid conflicts.

Machine Id is used to bind licenses, and distinguish between servers in distributed or clustered environments.

• This value is generated based on hardware and system characteristics.
• Used in event logs, license management, and for troubleshooting environment-specific issues.