This function is used to define notifications, i.e. warnings by sending a message or by creating a line that can be accessed via the Workflow monitor.

The creation of a notification automatically generates a Workflow event.

Creating a notification instead of creating a Workflow event is simple: a single tab must be entered. Entering criteria is carried out by viewing their titles. More complex conditions are predefined (field modified for example).

But, It must be noted that a notification is limited because:

  • only one part of these triggering cases that can be processed by the Workflow engine can be expressed.
  • the entry screen of criteria is simplified, and only one part of the context fields can be displayed.
  • the send function is limited to two recipients.
  • There is no associated approval process.

However, creating a notification can be represent a first step in defining the Workflow process. Indeed, creating a notification triggers the generation of the corresponding Workflow event. Once this creation carried out, it is possible to modify the workflow event, to complete it in order to process the functions that are not taken into account by the notifications.

But it must be noted that from the moment when the resulting Workflow event is modified, the original notification will be deleted.

Prerequisites

SEEREFERTTO Refer to documentation Implementation

Screen management

Only one single tab can define the notifications.

Entry screen

Are displayed here, the original event, the additional conditions, a list of recipients and the associated text.

Block number 1

Workflow code (field CODE)

This field identifies the Workflow rule.

Description (field INTIT)

Use this field to assign a description to each record.
Active (field ENAFLG)

As long as this box has not been checked, the Workflow rule is not likely to be triggered.

Triggering

Event type (field TYPEVT)

The Workflow event type can take the following values :

  • Object : the function here is of the object type (record managed in creation, modification, duplication, deletion...mode). Then the event code corresponds to the object code.
  • Function entry : the rule is triggered when entering a function of the software. The event code corresponds to the function code (an object coded as XXX corresponds to the GESXXX function, as a consequence, this type of event can also be used for objects).
  • Print : a report is launched, and its code can be specified in the event code field.
  • End of task: a Workflow is triggered at the end of the batch task, and its code corresponds to the event code (the batch task in question needs to have the box User message checked, otherwise it will not work. a warning message indicates otherwise, yet the entry is not forbidden for all that).
  • Task interruption : this workflow rule is triggered when a user decides, from the task monitoring, to interrupt a batch task whose code corresponds to the event code. The user sends an interruption request to the batch server, and the server stops the task. Given the execution context of this event, the triggering possibilities are limited. Indeed :
    • the usual environment variables (for instance, GUSER) are not available, only the current record in the [ABR] ABATRQT abbreviation table is.
    • only a message can be sent via e-mail (no tracking table can be updated).
  • Import/Export : this type of event is triggered at the beginning (and/or end) of the import (and/or export), and the event code makes it possible te specify the template being used.
  • Signature : this rule is triggered when signing a former rule, whose code can be given by the event code.
  • Manual : this rule is triggered by running through a set of tables described in the data template. This read is triggered via a manual operation which can obviously be launched in batch mode. This is especially useful to trigger the Workflow rules linked with field modifications in the database (the rule runs through the audit tables).
  • Miscellaneous : this rule is triggered for particular events identified by a finite list of event codes. These events can either be generic for all software written in Adonix technology (for instance, connection, disconnection...), or they can depend on a function specific to the software being used. The list of the generic events is drawn up in a first documentation appendix, and the list of events specific to each software, in a second documentation appendix.
Code (field CODEVT)

This field specifies the triggering context, based on the previously defined type :

  • for an Object type, the code of the corresponding object is given.
  • for a Function entry type, the function code is given.
  • for a Printing type, the report code is given.
  • for an End of task or Task interruption type, the code of the batch task is given.
  • for an Import/Export type, the import/export template being used is given.
  • for a Signature type, the code of the rule at the origin of the signature request is given.
  • for a Manual type, no code is entered.
  • for a Miscellaneous type, the code that identifies the miscellaneous event at the origin of the rule triggering is given.

This field is mandatory only for the event type Miscellaneous. If not entered, the event is triggered in a generic way, remembering that it is always possible to further test the context to be selective (thanks namely to the GFONCTION, GOLDETAT...variables).

Description (field LIBEVT)

Name associated with the code entered in the previous section

Block number 3

Creation (field ACREA)

This field is used to trigger the workflow in the case of a record creation if the event type is "Object".
Modification (field AMODI)

This field is used to trigger the workflow in the case of a record modification if the event type is "Object".
Deletion (field ASUPP)

This field is used to trigger the workflow in the case of a record deletion if the event type is "Object".
Return (field RETOUR)

If checked, this box makes it possible to enclose in the message sent an icon containing the context used to remind the record (by double-clicking on it). Note that this only works for a client-server connection.
Log (field TRACE)

This box can only be checked if the triggering event corresponds to the end of a batch task.

In that case, if it is checked, the trace file associated with the batch task will be enclosed to the message sent.

Grid Conditions

Condition (field ANDOR)
Field (field FLD)
Operation nature (field OPE)
Value (field VALEUR)

Block number 5

Expression (field EXP1)

Indicate if necessary an expression to complete the search.

The criterion is added to the previous criteria by the link AND.

The expression cannot contain fields from a table other than the principal table for the object. These can be indexed.

Recipients

Type (field TYPDES1)

A recipient can be linked to a user code (their details are then searched for in the user record), or a Business Partner (in that case, their details will be entered in the grid to identify on the BP record the concerned recipients).

field DESTIN1

This field identifies the recipients. It is written in the form of logical expressions (Calculation formula) including on-line variables at the moment of execution.
Function (field FNCDES1)

This information is only entered if the recipient type is a business partner. It refers to the local menu that defines the functions of the contacts in the Business Partner record.
Send mail (field ENVOI1)

Three values concerning the recipients of the line can be entered here :

  • No: they will not be sent any message.
  • Yes  : a message will be sent to them as main recipients.
  • Copy : a message is sent to them in copy mode.
Warning (field SUIVI1)

This flag is used to tell whether the recipients of the line will receive a notification in their planning workbenches, depending on the value entered :

  • No : in that case, no notification will be available in the planning workbench.
  • Yes  : a notification will be sent to them, it may only be initialled to indicate that the user has read it.
  • With signature : this notification needs to be signed by one of the recipients of the line.

Whenever a notification is sent to at least one of the recipient lines, the Approval request tab defines the text that will appear in the approval request, along with the answers that may be brought in case of a signature request.

Block number 7

Type (field TYPDES2)

A recipient can be linked to a user code (their details are then searched for in the user record), or a Business Partner (in that case, their details will be entered in the grid to identify on the BP record the concerned recipients).

field DESTIN2

This field identifies the recipients. It is written in the form of logical expressions (Calculation formula) including on-line variables at the moment of execution.
Function (field FNCDES2)

This information is only entered if the recipient type is a business partner. It refers to the local menu that defines the functions of the contacts in the Business Partner record.
Send mail (field ENVOI2)

Three values concerning the recipients of the line can be entered here :

  • No: they will not be sent any message.
  • Yes  : a message will be sent to them as main recipients.
  • Copy : a message is sent to them in copy mode.
Warning (field SUIVI2)

This flag is used to tell whether the recipients of the line will receive a notification in their planning workbenches, depending on the value entered :

  • No : in that case, no notification will be available in the planning workbench.
  • Yes  : a notification will be sent to them, it may only be initialled to indicate that the user has read it.
  • With signature : this notification needs to be signed by one of the recipients of the line.

Whenever a notification is sent to at least one of the recipient lines, the Approval request tab defines the text that will appear in the approval request, along with the answers that may be brought in case of a signature request.

Message

Object (field OBJET)

This field is used to specify the content of the Subject field of the message sent, in the form of a calculated expression that will be evaluated when the event is triggered.
Text (field TEXTE)

This field is used to define the main content of the message. It is written as free text which includes logical expressions (calculation formula) between two vertical lines that serve as separators. For example, it is possible to write such contents as :

The event which occured on | num$(date$) | generated this sending by | GUSER |.

Specific Buttons

Validation

Generates the corresponding Workflow event and validates it.

This button is used to copy the record definition from or to another folder.

Block number 1

field OBJET
field CLES

Block number 2

From folder (field DOSORG)

Use this field to define the folder from which the record will be copied. The possible syntaxes are described in the Dedicated appendix.
All folders (field TOUDOS)

Use this option to copy the record to all the folders defined in the dictionary (ADOSSIER table of the current solution).
To folder (field DOSDES)

Use this field to define the folder to which the record will be copied. The possible syntaxes are described in the Dedicated appendix.