Developer ToolsFree referencePDF, Excel, Word exportInfor SyteLineAll Infor SyteLine (CloudSuite Industrial) tools

SyteLine Mongoose Framework Events Reference

This reference lists the Mongoose framework events that application event handlers can subscribe to in Infor SyteLine 9, 10 and CSI on-prem. For each event you get when it fires, the parameters it passes, a typical SyteLine use and the gotcha that usually catches people out.

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.

Was this tool useful?

Where this lives in SyteLine

Framework events are system-defined, so you do not create them; you attach handlers to them. Open the Event Handlers form, create a handler, set Event Name to one of these events and, for IDO events, set the Applies to Objects field to the IDO (for example SLCustomers or SLCoitems). Then add actions on the Event Actions form. Use the Event Status and Event Handler Status forms to see each run. For custom logic that only your forms should fire, define a custom event on the Events form and fire it with a Generate Event action instead of overloading a framework event.

Event Handlers form: event name, applies-to objects, synchronous flag, sequence
Event Actions form: the steps the handler runs
Event Status form: results of each run, including failures and messages

On events versus Post events

The naming rule is consistent: On events run before the change and Post events run after it. A synchronous handler on IdoOnItemUpdate that ends with a Fail action stops the update and shows the failure message to the user, which is how most SyteLine validation rules are built. A Post event is the right place for notifications and logging because the data is already committed. Item events (IdoOnItemInsert, Update, Delete and their Post versions) fire once per row, so a grid save of 200 lines fires 200 times. IdoPostUpdateCollection fires once after the whole update finishes, which suits a single follow-up action per save.

Worked example: credit hold approval

To stop users clearing credit hold without approval, add a synchronous handler on IdoOnItemUpdate for SLCustomers. Give the first action a condition based on PROPERTYMODIFIED("CreditHold") so it only runs when that property changed, then use a Prompt to the credit manager and a Fail action when the answer is no. Because Prompt suspends the handler, the handler must be allowed to suspend; test this on a copy of your configuration first, since a synchronous handler that waits on a person holds the user's save open. Many sites prefer a Post event notification plus a report of changes when approval delays are not acceptable.

Version differences and gotchas

DataView and Data Lake related events are newer than SyteLine 9.x, and the help for current Mongoose releases lists events your on-prem 9.x system may not have. Property functions are event specific: P or PROPERTY works only on the item events, P2 or PROPERTY2 only on IdoOnLoadCollection and IdoPostLoadCollection, and P3 after a Load IDO Collection action. ROWS() returns 0 outside IdoPostLoadCollection. TaskPostPerform handlers need a Document Types entry for each Output Format on Report Options. Handlers on high-volume IDOs such as SLMatltrans or SLCoitems add load to every save, so keep conditions tight.

Frequently Asked Questions

Where is the Infor Mongoose documentation for framework events?

Infor publishes it in the Mongoose online help under Framework events, and the SyteLine and CSI help include the same topic in the application event system guide. Use the help for your release, since the list grows over time. On your own system, the Events form shows every framework event that exists in that configuration.

Can a handler on IdoOnItemUpdate stop the save?

Yes, if the handler is synchronous and fails. A Fail action with a condition and a message ends the handler with Failure status, the update is rejected and the user sees the message. Asynchronous handlers run separately and cannot stop the save, so use them for notifications rather than validation.

Why does P() return nothing in my load collection handler?

P and PROPERTY only work with the item events (IdoOnItem and IdoPostItem). On IdoOnLoadCollection and IdoPostLoadCollection use the row form, shown as P2 or PROPERTY2 in the expression editor, with a one-based row number. After a Load IDO Collection action, use P3 with the result set name.

Is the Mongoose event system the same as WinStudio form events?

No. Framework and application events run on the application server and apply to every client and integration that touches the IDO. WinStudio form events such as StdFormSave run only inside one form in the client. Validation that must hold for imports and APIs belongs in the event system or IDO code, not in a form script.

If you want your team to ask SyteLine which handlers fire on an IDO, or what changed on an order, in plain English on your own servers, we can set that up.

Talk to an Expert Explore More Free Tools