Events

An event is an occurrence during processing that can be used to trigger the running of one or more business rule components. Unlike a built-in event, a custom event must be defined and named before it can be used as a trigger.

Important! Content in a business rule is case sensitive. This includes business rule component names, attributes, and values.

Built-in Events

Built-in events (ENQUEUE, PRINTJOBDETAIL, or LABEL) exist automatically and do not need to be created before they can be used as triggers.

ENQUEUE

The ENQUEUE event causes a business rule component to run during the job submit phase, before the job is queued for printing. This event occurs for each job in a stacked job. As a best practice, it is recommended that you use the ENQUEUE event to run database or other process intensive business rule components.

PRINTJOBDETAIL

The PRINTJOBDETAIL event causes a business rule component to run when a job is removed from the queue to be printed.

LABEL

If Delink Data Source is set to true in the process, then business rule components triggered by the LABEL event are run before each label is printed. In this case, Loftware Enterprise SP does not use data sources defined in the label template except for Database and Alternate data sources.

If Delink Data Source is set to false in the process, then Loftware Enterprise SP uses all data sources defined in the label template. In this case, when the business rule is run, any business rule components that would be triggered by the LABEL event are not run.

Tip: You can run business rule components that are triggered by the LABEL event, but also have access to all data sources in the label template. To do so, set Delink Data Source to true and use a Reference business rule component to load the label data sources into the data map. For more information, see Access Label Data Sources (XML).

Best Practice

In most cases, it is recommended that you use the LABEL event as the trigger for running incDec, dateTime, and mapScript business rule components.

Custom Events

Custom events typically refer to a result of a business rule component. Unlike a built-in event, you must define and name a custom event so that you can use it as a trigger. Some examples of custom events include when a condition is true, when a condition is false, or when a row of data from a database is processed.

The following is the syntax for defining a custom event. You must specify the type of custom event where indicated. Note that the type of custom event is singular only if the item is nested within tags that use the plural form.

About the syntax documentation

<Type_of_custom_events>

<Type_of_custom_event eventName="Custom_Event" includeSiblings="true|false">

</Type_of_custom_events>

Types of Custom Events

The timing of custom events is determined by the type of event, which indicates when or if it occurs during the processing of a business rule component. Some types custom events can be included in any kind of business rule component, while others are limited to a few specific kinds of business rule components. The following are types of custom events.

Events for any business rule component

preProcessEvent

An event that occurs before the business rule component in which it is defined is processed. You can define this type of event in any business rule component and use it to trigger a child business rule component to be evaluated before the parent is processed. For example, you can use a preProcessEvent to cause a state by running other business rule components before the one in which this event is defined.

<preProcessEvent eventName="Custom_Event" includeSiblings="true|false" />

</preProcessingEvents>

postProcessEvent

An event that occurs after the business rule component in which it is defined is processed. You can define this type of event in any business rule component and use it to trigger a child business rule component to run after the parent is processed. For example, you can use a postProcessEvent to run a business rule component after this one to cause or reset a state.

<postProcessEvent eventName="Custom_Event" includeSiblings="true|false" />

</postProcessingEvents>

errorProcessEvent

An event that occurs only if an error occurs during processing of the business rule component in which it is defined. You can define this type of event in any business rule component and use it to trigger a child business rule component to run if an error occurs during processing of the parent business rule component. For example, you can use an errorProcessEvent to respond to an error condition by running another business rule component.

<errorProcessEvent eventName="Custom_Event" includeSiblings="true|false" />

</errorProcessingEvents>

Events for conditional business rule components

Event for dataService business rule components

Event for forLoop and whileLoop business rule components

Syntax Tips

includeSiblings

Required. This property of an event determines whether the event is propagated to peers of the business rule component when the event occurs.

Best Practice

When calling a sibling business rule component that you did not write (for example, by using a reference business rule component), use a separate event instead of using includeSiblings to propagate an event.

Value	Description
false	The event is propagated to children of the business rule component, but not to peers.
true	The event is propagated to children and peers of the business rule component.

Tip: For assistance with a business rule that you have created or to have Loftware create business rules for you, contact Loftware's Professional Services Group.