Client-Side Execution: Form Scripts and UI Logic
exe) or the web client browser context. 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. 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. NET code in IDO extension assemblies or as stored procedures registered through the IDO Method form. , 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
Try it here, free
SyteLine IDO and SQL Performance Assessment
Score the performance risk of a SyteLine 9 or 10 on-prem install across data growth, IDO and extension code, background tasks and SQL Server configuration, with the specific fix for each weak answer.
Struggling with client vs server architecture in SyteLine? Our architects design execution strategies that maximize performance, schedule a review.