SyteLine Client vs Server Script Architecture Guide
SyteLine supports code execution at two distinct layers: client-side form scripts that run within the user's application context, and server-side IDO methods that execute on the Mongoose application server. Choosing the wrong execution layer is one of the most common and costly architectural mistakes in SyteLine development. This guide clarifies when to use each, how data flows between them, and the performance implications of each approach.
Client-Side Execution: Form Scripts and UI Logic
Client-side scripts execute within the SyteLine Windows client process (SLClient.exe) or the web client browser context. In the Windows client, form scripts are .NET assemblies loaded by the FormScriptRuntime engine and have access to the form's IDO collections, UI components, and the local StdObject API. In the web client, equivalent logic runs as JavaScript within the IFS (Infor Framework Services) rendering engine. The key constraint is that client scripts have zero direct database access—all data operations must go through IDO requests that round-trip to the Mongoose server. Use client scripts for field-level validation that requires immediate user feedback, conditional UI element visibility via the ThisForm.Components collection, and calculated display values that do not need persistence.
- Windows client scripts execute as .NET assemblies within SLClient.exe process space
- Web client scripts run as JavaScript under the IFS framework with different API surface
- All data access from client scripts must use IDO requests through StdObject.InvokeIDO()
- Use client scripts only for UI logic: visibility, validation messages, and local calculations
Server-Side Execution: IDO Methods and Business Rules
Server-side IDO methods execute within the Mongoose application server process and have full access to the IDO runtime, database transaction scope, and server resources. These methods are defined as .NET code in IDO extension assemblies or as stored procedures registered through the IDO Method form. Server-side is the correct location for all business logic: data validation that requires cross-entity checks (e.g., verifying credit limits against the customer IDO before order release), data transformation and enrichment during save operations, integration callouts to external systems, and any operation that must execute consistently regardless of client type. Methods registered in the IDO Method form (Application > IDO > IDO Methods) are invoked through the standard IDO Invoke pattern and participate in the Mongoose transaction pipeline automatically.
- IDO methods execute on the Mongoose server with full TransactionScope participation
- Register methods in Application > IDO > IDO Methods with appropriate method type (SP or .NET)
- Server methods execute identically whether called from Windows client, web client, or REST API
- Use stored procedure methods for bulk operations; use .NET methods for complex logic with external calls
Bridging Client and Server: The InvokeIDO Pattern
The InvokeIDO pattern is the bridge between client and server execution. From a client form script, you call InvokeIDO with the target IDO name, method name, and parameter collection. The Mongoose runtime serializes the request, routes it to the application server, executes the method within a new or existing transaction scope, and returns the result. Latency on this round-trip is typically 50-200ms on LAN and 200-800ms over WAN, which matters significantly when form scripts call InvokeIDO in loops. Common performance anti-patterns include calling InvokeIDO inside a foreach loop over grid rows (use a single bulk method instead), chaining multiple InvokeIDO calls that could be consolidated into one server method, and failing to use the asynchronous InvokeIDO overload for non-blocking operations.
- InvokeIDO serializes parameters, routes to the Mongoose server, and deserializes the response
- Typical round-trip latency is 50-200ms LAN, 200-800ms WAN—avoid calling in loops
- Consolidate multiple client-to-server calls into a single server-side IDO method for performance
- Use the async InvokeIDO overload (BeginInvokeIDO) for operations that do not need immediate results
Struggling with client vs server architecture in SyteLine? Our architects design execution strategies that maximize performance—schedule a review.
Related Resources
SyteLine Mongoose Framework Architecture Deep Dive
Deep dive into SyteLine Mongoose framework architecture. IDO runtime, request pipeline, session management, and extensibility patterns for developers.
Infor SyteLineSyteLine .NET Customization Patterns and Best Practices
Master SyteLine .NET customization patterns. IDO extensions, form scripts, assembly deployment, and upgrade-safe development practices for developers.
Infor SyteLineSyteLine IDO Custom Property and Method Creation
Create custom IDO properties and methods in SyteLine. Property mapping, method signatures, stored procedures, and .NET method development guide.