Triggering context for Events and Rules

You can indicate that certain rule(s) and/or event(s) defined in a Transaction object are only executed when the object is run for specific user interfaces (Windows/GUI, Web/HTML, Text) and/or when the data is handled through Business Components in backend processes.

Syntax

There are two possible syntaxes:

1) Individual: 

[ContextIdentifier1][ContextIdentifier2][ContextIdentifierN]
rule | event

2) By Block:

[ContextIdentifier1][ContextIdentifier2][ContextIdentifierN]
{
rule | event
rule | event
}

Where:

[ContextIdentifier1] [ContextIdentifier2] [ContextIdentifierN]
     Indicate the context(s) for which the rule(s) / event(s) must be executed. The possible values are:

• [web]: The rule(s) / event(s) that follow will be triggered when the Transaction Web Layout (HTML) is executed.
• [bc]: The rule(s) / event(s) that follow will be triggered when the Transaction is executed as Business Component in backend processes.
• [win]: The rule(s) / event(s) that follow will apply to Windows / GUI forms.
• [text]: The rule(s) / event(s) that follow will apply to char based user interfaces.
• [business]: This is the default value. It is like not indicating any ContextIdentifier or indicating all of them. 

rule
     Rule or list of Rules in Transactions.

event
     Event or list of Transactions events.

Scope

Objects: Transaction

Description

Some validations or actions may only make sense when the end user is interacting through the Transaction web interface, and not when the data is handled through Business Components or vice versa. So, this feature allows indicating in which contexts you want to execute certain rules and/or events.

The ability to define rules/events that only apply in certain contexts allows you to create business logic adapted to the specific needs of each type of interaction with the system. 

This is especially relevant in scenarios where different layers of interaction with the end users are handled or when finer control over the business logic is required depending on the origin of the operation (for example, web vs. backend).

In summary, the use of ContextIdentifiers allows to:

• Specify the execution context: Clearly defines the scope in which a rule/event should be applied, improving code organization and clarity.
• Customize the business logic: Adapt the behavior of the applications according to the execution environment, offering a richer and more accurate user experience.
• Optimize performance: By avoiding the execution of unnecessary rules/events in certain contexts, the application performance can be improved.
• Improve maintainability: Facilitates code understanding and maintenance by providing a clear mechanism to control where and how business rules are applied.

Samples

Sample #1: Individual definitions

Rules Tab of Customer Transaction

[web]
Noaccept(CustomerId) If Insert On AfterValidate;
[bc]
CustomerAddress.SetNull() if CustomerAddress.IsEmpty()

Events Tab of Customer Transaction

[win][web] 
Event After Trn
      Settings(CustomerId)
EndEvent 

The NoAccept rule will only be applied in Windows or GUI environments, while the Start event is valid in Win and Web environments.

Sample #2

The next example shows the use of the Block syntax.

[win]
{
Parm(&CustomerId, &Mode);
CustomerId = &CustomerId If Update Or Delete;
Noaccept(CustomerId);
}
[win][text]
{
Event After Trn       
   Settings(CustomerId)
EndEvent

Event ‘User’ 8
       //do something
EndEvent
}