Infor LN Domain Structure Design: Architecture Guide
The data dictionary domain system is the architectural foundation of Infor LN. Every field in every table and every variable in every BShell script is typed by a domain. Domains enforce consistency across the entire application: a customer code is always the same length, format, and validation rule whether it appears in Sales Orders, Accounts Receivable, or Project Management. Designing domain structures correctly at the start of a customization project prevents cascading rework and data integrity issues downstream.
Domain Types and the Data Dictionary Hierarchy
The LN data dictionary uses a hierarchical domain system. Base domains define primitive types (string, long, double, date, enum). Extended domains inherit from base domains and add business-specific attributes (length, format mask, validation, zoom reference). Table column domains inherit from extended domains and bind to specific database storage. This three-level hierarchy means that changing a base domain's validation rule propagates to every table column and BShell variable that uses it—a powerful but dangerous capability that requires careful governance.
- Base domains are defined in the System module (tc): tcstring (variable-length string), tclong (32-bit integer), tcdouble (floating-point), tcdate (date), tcbool (boolean), tcenum (enumeration) — these are rarely modified
- Extended domains add business context: tcitem (12-character item code with uppercase enforcement), tccom100 (business partner code with zoom to BP master), tcamnt (amount with 2-decimal precision and currency formatting) — defined in module-level data dictionaries
- Create a custom domain: navigate to Data Dictionary Maintenance (ttadv1600m000), define the domain code following the naming convention [module][sequence] (e.g., tcspc001 for a custom spare parts module domain), set the base type, length, format mask, and validation expression
- Domain validation expressions use BShell syntax: 'val.expr = (i.field >= 0 and i.field <= 9999)' enforces a numeric range; 'val.expr = (match$(i.field, "[A-Z][0-9]*"))' enforces an alphanumeric pattern
- CRITICAL: never modify standard Infor LN domains directly; always create custom domains that inherit from standard domains; this protects your customizations during LN upgrades where standard domains may be overwritten
Table Design and Key Definition Patterns
LN tables are defined in the data dictionary with explicit key structures that control both database indexing and application-level record access. Every table must have a primary key (key 1) that uniquely identifies each record. Secondary keys (key 2 through key N) define alternative access paths used by sessions, reports, and BShell queries. Key design directly impacts performance: a poorly designed key forces full table scans on large transaction tables, while an over-indexed table suffers write performance degradation.
- Primary key (key 1) design: include the company code (tcemm050.comp) as the first segment for multi-company installations; follow with the natural business key (order number, item code); keep primary keys to 3-4 segments maximum for optimal index performance
- Secondary keys for session access: define a key that matches the session's default sort order; for example, a Sales Order Lines session that sorts by order number + line number needs a key on (comp, orno, pono) to avoid a database sort operation
- Define keys in the data dictionary: navigate to Table Definition (ttadv4500m000), select the table, open the Keys tab, add key segments in order; each segment references a table column; mark the key as Unique if it enforces a business constraint
- Index strategy for transaction tables: limit to 5-6 keys maximum on high-volume tables (>1M rows); each additional key adds write overhead; use the LN SQL Trace facility (ttadv9600m000) to identify which keys are actually used by sessions and remove unused keys
- For multi-company tables, always use a composite key starting with the company field to enable company-level data partitioning and prevent cross-company data leakage in queries
Relationships, References, and Data Integrity
LN enforces referential integrity through domain references and table relationships, not through database-level foreign keys. When a domain has a reference session defined, LN automatically validates that any value entered for that domain exists in the referenced table. Table relationships are defined in the data dictionary as parent-child links that control cascade delete behavior and navigation between related sessions. This application-level referential integrity gives LN flexibility but requires disciplined configuration.
- Domain references: when domain tcitem has reference session tcibd0101s000 (Item Master zoom), every field typed as tcitem automatically validates against the Item Master table; invalid item codes are rejected at input time with the message 'Value not found in [table]'
- Parent-child relationships: define in Table Relationships (ttadv4540m000); a parent-child link between Order Header (tdsls400) and Order Lines (tdsls401) ensures that deleting an order header cascades to delete its lines; set the relationship type to 'Restrict' to prevent header deletion when lines exist
- Soft references: for optional relationships (e.g., a project code on a purchase order that may or may not reference the Project Master), use a conditional validation in the BShell after.field trigger instead of a domain reference; this prevents mandatory lookup validation on optional fields
- Cross-module references: when your custom table references a standard LN table in another module (e.g., referencing tcibd001 Item Master from a custom quality module), always use the standard domain type (tcitem) to ensure the reference is maintained during LN upgrades
- Data migration consideration: when loading data via batch import, temporarily disable domain validation using db.set.validation(false) in the BShell import script to bypass reference checks; re-enable validation after import and run a separate validation report to identify orphaned references
Design scalable Infor LN domain architectures with Netray's AI-powered analysis—get automated data dictionary reviews and optimization recommendations.
Related Resources
Infor LN BShell Programming Fundamentals
Master Infor LN BShell scripting with this developer guide covering 4GL syntax, database operations, session hooks, and debugging techniques for BAAN/LN ERP.
Infor LNInfor LN Table Extensions Development Guide
Extend standard Infor LN tables safely with custom fields, triggers, and validation logic. Avoid upgrade conflicts with proven extension patterns for BAAN/LN.
Infor LNInfor LN Session Creation and Modification
Learn to create and modify Infor LN sessions including form design, field triggers, choice fields, zoom sessions, and session-to-session communication patterns.