Mongoose Runtime Pipeline and Request Lifecycle
Every SyteLine operation, whether initiated from the Windows client, web client, or REST API, flows through the Mongoose runtime pipeline. The pipeline begins with request deserialization at the MongooseRuntime service endpoint, proceeds through authentication and session validation against the SessionManager, then routes to the appropriate IDO handler via the IDORuntime class. The IDO handler resolves property-to-column mappings from cached IDO metadata stored in MongooseMetadataCache, constructs SQL against the underlying views (not tables directly), executes within a TransactionScope, and returns results through the serialization layer.
Understanding this pipeline lets you intercept at precise points using event handlers and custom middleware.
- The MongooseRuntime entry point deserializes requests and validates session tokens before any IDO access
- IDO metadata is loaded from the IDOMetadata and IDOMethod tables and cached aggressively at application server startup
- All IDO operations execute within System.Transactions.TransactionScope for automatic rollback on failure
- The SessionManager maintains per-user state including configuration overrides, site context, and permission masks
IDO Metadata Layer and Property Resolution
The Mongoose metadata layer maps logical IDO properties to physical SQL view columns through the IDOPropertyMap system. When SyteLine loads an IDO, it reads the IDO, IDOCollection, IDOMethod, and IDOEvent tables from the application database to build an in-memory property graph. Custom properties added through IDO Extensions are resolved alongside base properties.
The critical detail most developers miss is that property resolution is order-dependent: if you define a custom property with the same name as a base property, the behavior depends on the IDO extension load order configured in the IDOExtension form. Always use unique prefixes like Uf_ for custom properties to avoid collision.
- Property mappings are defined in the IDOPropertyMap table linking IDO names to SQL view columns
- The IDOExtension table controls custom assembly loading order, which affects property override behavior
- Metadata changes require an application server restart or a cache clear via the Mongoose Admin Console
- Use the IDO Metadata Utility form to inspect resolved property graphs and identify mapping conflicts
Session Management and Connection Pooling
Mongoose session management directly impacts scalability. Each user session consumes a SessionManager slot backed by an entry in the SessionInfo table. The session holds the user's site context, configuration parameter overrides from SLUserSiteParms, and cached permission evaluations.
xml file, with default maximum pool sizes that are often too low for environments with over 100 concurrent users. Pool exhaustion manifests as random timeouts and the cryptic 'Unable to obtain IDO runtime' error. Monitor pool usage through the Mongoose Admin Console's Connection Statistics page and tune MaxPoolSize, ConnectionTimeout, and IdleTimeout parameters based on actual peak load.
- Session state is maintained in the SessionInfo database table and cached in-memory by SessionManager
- Connection pool parameters in MongooseConfig.xml govern MaxPoolSize, MinPoolSize, and ConnectionTimeout
- Pool exhaustion triggers 'Unable to obtain IDO runtime' errors visible in the Mongoose application log
- Use the Mongoose Admin Console Connection Statistics page to monitor pool utilization under load
Try it here, free
SyteLine Customization Technical Debt Scorer
Measure how much upgrade drag, risk, and maintenance cost your SyteLine customizations have accumulated, and learn where to pay it down first.
Need deep Mongoose framework expertise for your SyteLine project? Our architects have decades of combined SyteLine runtime experience, reach out today.