Infor SyteLineGlossary

What Is AES (Application Event System)?

Also known as: Application Event System, SyteLine AES, event framework

Definition

AES (Application Event System) is the Mongoose framework component in SyteLine that detects defined application events, evaluates conditions, and executes configured handler actions such as notifications, prompts, SQL statements, and IDO method calls.

AES (Application Event System) Explained

AES is the formal name for the framework layer that people usually call the SyteLine event system. It lives in the middle tier, alongside the IDO runtime, and is triggered when a subscribed event fires - typically an IDO method invocation, a property change, or a scheduled or manually raised event. Because it sits in the framework rather than in application code, AES works identically for delivered SyteLine objects and for anything a customer builds on Mongoose.

Processing follows a defined order. The event fires, AES finds subscribed handlers, evaluates each handler's condition expression, and for those that pass, executes the action list in sequence. Actions may run synchronously inside the originating transaction or asynchronously from a queue. Handlers can prompt a user and branch on the response, escalate after a timeout, chain to further events, and write to the event log that provides the audit trail.

The distinction between synchronous and asynchronous execution is the design decision that matters most. Synchronous handlers can veto a transaction - useful for enforcing a business rule at save time - but every one adds latency to the user's action. Asynchronous handlers cannot block the transaction but scale far better and are correct for notifications, integrations, and logging. Mixing these up is the root cause of most AES-related performance complaints.

The long-term governance point is that AES configuration is data, not code, so it exports, versions, and migrates between environments as configuration. That makes it upgrade-friendly compared with equivalent logic in form scripts or extension classes. It also makes it easy to accumulate, which is why an established install benefits from a periodic audit listing every active handler, its condition, its trigger volume, and the business process it supports.

Why It Matters

AES lets business rules and approvals be configured rather than coded, cutting both build cost and upgrade risk.
The synchronous versus asynchronous choice directly determines user-perceived ERP responsiveness on high-volume transactions.
Event logs supply an audit trail of automated decisions that regulated manufacturers increasingly must produce.
Because handlers accumulate silently, an unaudited event configuration becomes a hidden performance and maintenance liability.

In Practice

When diagnosing slow saves on a high-volume form, list every AES handler subscribed to that IDO's update method and check which are synchronous. Tightening condition expressions so handlers evaluate to false early, and moving notifications to asynchronous, usually recovers the responsiveness without removing any business function.

Frequently Asked Questions

Is AES different from the SyteLine event system?

They are the same thing. AES, or Application Event System, is the formal Mongoose framework name; most practitioners simply say the event system or talk about event handlers. Documentation and configuration forms use the AES terminology, so recognising both names avoids confusion when reading Infor material alongside partner documentation or an internal design spec.

Should an AES handler run synchronously or asynchronously?

Run synchronously only when the handler must be able to block or alter the transaction - enforcing a business rule at save, for example. Everything else should be asynchronous: notifications, integration calls, logging, and downstream updates. Synchronous handlers add their full execution time to the user's wait, and on high-volume objects a handful of them becomes clearly noticeable.

Related Terms

SyteLine Event System

The SyteLine Event System is the framework's rule engine that detects defined business events - a record saved, a status changed, a threshold crossed - and runs configured handlers that send notifications, request approvals, execute SQL, or call custom logic.

IDO (Intelligent Data Object)

An IDO (Intelligent Data Object) is the middle-tier business object in SyteLine and the Mongoose framework that exposes database tables as named properties, methods, and collections, so forms, mobile apps, and REST clients all read and write data through one governed layer.

Mongoose Framework

Mongoose is Infor's metadata-driven application development framework that SyteLine and CloudSuite Industrial are built on. It renders forms, exposes data through IDOs, runs an event system, and lets customers extend or build applications without altering delivered source code.

Go Deeper

Free Tool

SyteLine Version End-of-Life Risk Assessment

Score your exposure to running an aging or unsupported SyteLine version across support, security, compliance, and skills dimensions.

The SyteLine Mongoose Framework: A Developer Guide

SyteLine Mongoose is the metadata framework behind Infor SyteLine and CloudSuite Industrial: IDOs, WinStudio forms, application events, and scripting explained.

SyteLine 9 to 10 Upgrade: Step-by-Step Guide

Plan your SyteLine 9 to 10 upgrade with this step-by-step guide: Mongoose framework changes, FormSync customization merges, timelines, costs, and testing.

Working with AES (Application Event System) in a live environment? Our engineers do this every day - and our AI agents automate most of it.

Talk to an Expert Browse the Full Glossary

Back to Glossary

Try it here, free

SyteLine Mongoose Framework Events Reference

Open full tool

Every framework event an application event handler can subscribe to in SyteLine 9/10 and CSI on-prem, with when it fires, what it passes and the traps to avoid.

Download:

Event	Group	Fires when	Parameters passed	Typical SyteLine use	Gotcha
IdoOnInvoke	IDO	Before an IDO method is invoked	Method name, parameter count, parameter values	Check or log calls to a specific method on an SL IDO before it runs	Read the method with METHOD() and values with METHODPARM(n); failing the handler stops the call
IdoPostInvoke	IDO	After an IDO method is invoked	Method name, parameter count, parameter values	Notify or log after a method such as a posting routine finishes	Post events cannot undo the method; use the On event to block
IdoOnItemInsert	IDO	Before an IDO item is inserted into a collection	The row being inserted	Validate a new SLCos or SLItems row, or default a value with Set Values	On events can veto the insert by failing the handler; P/PROPERTY works here
IdoPostItemInsert	IDO	After an IDO item is inserted	The inserted row	Notify a buyer when a new PO line (SLPoitems) is created	Runs after the insert; use it for follow-up actions, not validation
IdoOnItemUpdate	IDO	Before an IDO item is updated	The row plus modified flags	Require approval before CreditHold changes on SLCustomers	Use PROPERTYMODIFIED("CreditHold") so the handler only acts when that property changed
IdoPostItemUpdate	IDO	After an IDO item is updated	The updated row plus modified flags	Tell planning when a due date changes on SLCoitems	Fires per row; a bulk update of many rows fires it many times
IdoOnItemDelete	IDO	Before an IDO item is deleted	The row	Block deletion of SLItems rows unless the user is in an admin group, with a Fail action	Only properties present on the delete request are available; check with PROPERTYAVAILABLE
IdoPostItemDelete	IDO	After an IDO item is deleted	The deleted row	Write an audit row to a user-defined table after a delete	The row is gone from the database; copy what you need from the event
IdoOnLoadCollection	IDO	Before an IDO collection loads	Load flags, property names, post-query actions	Audit who queries a sensitive IDO, read the filter with FILTERSTRING()	Use P2/PROPERTY2 and FP2 here, not P; RECORDCAP() gives the cap for the query
IdoPostLoadCollection	IDO	After an IDO collection loads	The result set	Notify an admin when a load returns more than 1,000 rows	ROWS() counts rows only on this event; it returns 0 elsewhere
IdoOnUpdateCollection	IDO	Before an IDO collection update runs	Custom insert, update and delete specifications	Inspect or override custom save methods on an update request	CUSTOMINSERT, CUSTOMUPDATE and CUSTOMDELETE functions read the specifications
IdoPostUpdateCollection	IDO	After all IDO collection updates finish	None	Trigger one follow-up action per save instead of per row	No row data is passed; load what you need
IdoOnPersistFailed	IDO	When a create, update or delete throws an exception	DBErrorDataKeys count, DBErrorDataKeyList	Alert support when saves fail on an integration IDO	Fires on failure only; it does not replace normal error handling in the caller
IdoPostRequestQuarantined	IDO	When an IDO request is checked against the exclusion list	IDO, request type, method name	Log or alert on requests caught by request quarantine	Only relevant where request exclusion is configured
SessionOnLogin	Session	When a new session is requested	User name	Log logins for selected users or configurations	USERNAME() and CONFIGNAME() are meant for session events
SessionOnLoginFailed	Session	When a login attempt fails	Application name, configuration, user, originating computer name, failure details	Notify the administrator after failed logins on a production configuration	Keep the handler light; it runs on every failed attempt
SessionOnLogout	Session	When a session closes	User name	Record logout for licence or audit reporting	Sessions that time out may not behave like a clean logout; test your case
SessionOnVarChanged	Session	Before a session variable changes	Variable name and new value	Watch changes to a session variable a customization relies on	Read values with VARIABLENAME() and VARIABLEVALUE()
SessionPostVarChanged	Session	After a session variable changes	Variable name and new value	React after a variable is set	Fires often if a form sets variables on every record
TaskOnPerform	Task	Before a background task is performed	Environment attributes, profile parameters, report options, cultural formatting, task attributes, task parameters	Check parameters before a long report runs	Keep the handler light: it runs before every execution of the task
TaskPostPerform	Task	When a task completes successfully	TaskOnPerform attributes plus task result attributes	Email a finished report to a distribution list	Needs a Document Types entry for each Output Format value used, with the matching file extension (for example PDF)
TaskOnPerformFailed	Task	When a task fails	TaskOnPerform attributes plus task result attributes	Alert the owner when a nightly background task fails	Use it instead of polling Background Task History
BodPreReceive	BOD	When an inbound BOD is queued for processing	BOD verb, BOD noun, BOD XML	Screen inbound BODs before processing	If the handler fails, the BOD is not processed and BodOnReceive does not fire
BodOnReceive	BOD	When the site receives an inbound BOD through ION	BODVERB(), BODNOUN(), BODXML	Route or log inbound Sync.ItemMaster or Process.SalesOrder BODs	Use SUBXML to pull nodes from BODXML() rather than string parsing
BodOnReceiveFail	BOD	When processing of a received BOD fails	BOD verb, BOD noun, BOD XML, error message	Notify the integration owner with the error text	Pair it with a review of the inbox forms for the failed document
DataViewOnLoad	Other	When a DataView begins loading	DataView report name (initiator)	Audit use of a DataView	Newer than SyteLine 9.x; confirm the event exists in your release
DataViewPostLoad	Other	When a DataView finishes loading	DataView report name (initiator)	Log completion of a heavy DataView	Newer than SyteLine 9.x; confirm the event exists in your release
ClearServiceSessions	Other	When a Mongoose core trigger clears old service sessions	None	Rarely handled; housekeeping	Do not attach slow actions to housekeeping events

Names and parameters follow the Mongoose Framework events help topic. Internal-only events (EmailReportFromFileServer*, FileContentTest) are excluded. Event availability varies by Mongoose release: confirm the list in the Events form on your SyteLine 9.x, 10.x or CSI system before you build a handler.

Get your event handlers reviewed

Send us an export of your Event Handlers and Event Actions and we will flag handlers that fire too often, block saves unexpectedly or will not survive an upgrade.

Optional. The tool and every export work without this. No spam.

ArchRay builder

Design the on-prem AI stack for Infor SyteLine: model, GPUs, RAG pipeline, guardrails

See memory, speed and cost as you swap parts, then export the diagram. Free, in your browser.

Open the builder

New to Infor SyteLine? Start with the Infor SyteLine guide and toolkit, or plan with Training Path Builder, ERP Certification Study Planner, Upgrade Path Planner.