Manage Event Actions

The Event Actionspage is the starting point when managing event actions. The most common tasks are available on this page for example you can create a new event action by using the New(+) command which will open the New Event Action assistant. You can also get an overview of event action and zoom in to the details of each.

From this page you can easily find and navigate to existing Event Actions. Select the required Event Action and click the 'View Details' command, then the Event Action including detail information is shown in the Event Action page.

Create Event Action

Actions are attached to existing Events using the New Event Action assistant. To create new event actions, do one of the following:

• Find and click on New Event Action in the navigator
• Go to navigator folder Solution Manager/Configuration/Events, select an event and use the command New Event Action.

To configure an Event Action follow the steps in the assistant. The mandatory fields are Action Type, Perform upon Event and Action Description. In the Action Details step, the mandatory fields depend on the Action Type selected.

The Event Action must be enabled in order to be triggered. Enabling an Event Action implicitly also enables the Event. If the Event is disabled manually no Event Actions are triggered for that Event.

System Defined Event Actions

In the Event Actions overview page, it is mentioned if an Event Action is System Defined or Custom Defined. System defined Event Actions are delivered by IFS. The settings of the System Defined Event Actions are Read-Only, except the settings concerning subscriptions. It is possible to duplicate a system defined Event Action and make changes to the copy, if there is a need to modify the predefined action.

Action Types

There are different types of actions that can be performed when an event is triggered. The same event can also have several actions. The action can be E-Mail, Execute Online SQL, Application Message, Task, Workflow, Streams Message, or REST Call. These action types are described in the table below.

Action	Description
E-Mail	Sends a mail to receiver using Mail Server setup in IFS Connect. This event action is possible to subscribe to. . Parameters: To: The e-mail addresses of the persons the e-mail message is sent to. This can be a list of IFS Cloud platform Users as well. Then the email address for the user will be used. Cc: The e-mail address of the person to get a carbon copy of the e-mail message. Bcc: The e-mail address of the person to get a blind carbon copy of the e-mail message. From IFS Cloud platform User: The user who sent the message. Subject: The subject of the e-mail message. Mail Sender: Mail sender connector to be used to send the mail. Attach Files: Files included in the e-mail as attachments. Message: The content of the e-mail. The Add URL button provides a URL to the home window of the Logical Unit of the Event. If the Logical Unit for the Event does not have a registered home window, a question will be raised asking if you want to use the URL Designer. In the URL designer, you can select the IFS Application window that the URL link should open. It is also possible to add parameters to populate any specific data in the window
Execute Online SQL (deprecated)	Executes the SQL-statement. The statement will be executed in the current database. The action Execute Online SQL is intended to execute a method (or UPDATE or INSERT), not to return any values. Parameters: SQL Command: Valid SQL statement to be executed. Note: This action type is deprecated in IFS Cloud. As a best practice, you are encouraged to evaluate Event Action configurations to see weather it qualifies into the configuration layer . For detailed guidance, refer to the Tailoring Overview - Technical Documentation for IFS Cloud.
Application Message	Creates an Application Message to be handled by IFS Connect. All the information available in the Event is included in the message. No formatting of a specific text is available here; it is all handled by Connect. It is though possible to set Connector, Address Data, Envelope and Transformer. If Connector is specified Address Data is mandatory. If Connector is not specified the message will be routed by Connect. Parameters: Connector: Handles the communication between the business system and message hubs, output services/devices, and application connectors. Address Data: Information about the destination address. Envelope: The format that is used to encapsulate XML data. Transformer: Support conversion of IFS Record XML format to/from other formats required by other systems.
Task	Creates a Task to one or many users. Tasks are shown to users in IFS Cloud in the My Tasks page. Parameters: Receiver: The user id as specified in User Administration (FndUser/Identity). Receiver can be a list of users separated by, or ; character. Each of the users will be able to see the same task. The Task is only to be performed once and can only be set to complete by one user. Subject: Title on the task. Message: Description of the task. Details what the user should do in order to complete the task. Url: A link that can help the user complete the task. It can refer to a specific window within IFS Cloud. Example "page/CustomerOrder/Form?$filter=keyref eq 'ORDER_NO%3D<ORDER_NO>%5E'" where <ORDER_NO> is to be replaced by a valid order id. It can also refer to an external web page. Priority: The priority of the task as defined by the sender. Values can be "High", "Low" or "Normal". Complete on Event: An event fired on the same object that will set the tasks to completed. The task can be manually completed by the user. The task can also be completed if another Event is fired on the same object. Only objects where rowkey is enabled will have this possibility.
Workflow	Calls the embedded Camunda workflow engine to start a pre-defined workflow before or after the Event is triggered depending on configuration. The workflow execution starts and continues to a wait state within the same transaction. For asynchronous execution the intention to execute a workflow is logged as part of the original transaction. Parameters: Workflow ID: The unique identifier of a Workflow as defined by the author. The latest deployed version of the Workflow is executed.   Type: Choose the workflow type. The supported types are Validation, Process Enrichment and User Interaction. Validation: The workflow is designed to perform business validations and results in either success or failure. Process Enrichment: The workflow is designed to perform additional logic within the transaction and may alter incoming or outgoing data values. User Interaction: The workflow is designed to open modal dialog(s) within Aurena. Timing: Choose when the instance of the workflow will start with regards to the event. The supported options are Before, After and Asynchronously. Before: The workflow execution starts within the same transaction before the event. After: The workflow execution starts within the same transaction after the event. Asynchronously: The intention to start the workflow is logged within the same transaction. The workflow is executed asynchronously in separate transaction.  Parameters:List of hardcoded key value pairs to be sent to the workflow as input parameters. Parameter: Name of the parameter to be passed to the workflow. Value: Value of the parameter. Information: Optional. A description of the parameter and how it affects the workflow.
Streams Message	Creates a new stream message Parameters: From: The IFS Cloud platform user who is sending the stream message To: The IFS Cloud platform user who should receive the message Subject: This will be the header shown in the stream message. URL: The URL to navigate when the stream message in clicked. (Optional) Message: Message to display
REST Call	Sends a REST Call using REST Sender setup in IFS Connect Parameters: REST End point: The URL of the REST service needs to be called. Method: Which http method to use in this action ( PUT, POST, PTCH, DELETE) Sender: REST sender connector to be used to send the REST Call. Authentication: Choose the authentication scheme required by the REST service. The supported authentication schemes are Basic, Bearer and Azure Shared Key. Additional Header Parameters: Header parameters that would be set to the HTTP request header can be set here. Enter the parameters in the page. <parameter>:<value> Enter one such parameter per line. Query Parameters: Use parameters to tailor and filter the response output. All query parameter names and values are case-sensitive. Body: Add the data you are interested in transporting. This needs to be a valid payload. Framework will not validate the message body Attachments: Upload the files you need to send as attachments. Token Endpoint Parameters: Optional parameters that would be needed when making the request to the token endpoint using Client Credentials or ROPC auth schemes. These parameters may include things like 'scope' parameter to specify access permissions.

Conditions

To be able to control the execution of the action you can enter conditions that must be fulfilled. The action is thus only performed if all conditions are met. Click on Conditions for performing this action to edit the condition for the event action. When using the condition type 'LIKE' if the condition value contains '%' or '_' characters an escape character '\' should be used to avoid confusion with wildcard characters that can also be used. When using the condition type 'IS NULL' a condition value is not needed as it will not be considered for that condition type.

Substitution Fields

To create an action that contains useful information about the event it is possible to enter substitution fields into the message or subject. There are two types of substitution fields, Event and General.

Event Substitution fields

Each event supplies a number of substitution fields with valuable information about the specific event. The substitution field will automatically get prefixed "&" to mark it as a substitution field that will be replaced by real data.

General Substitution fields

The application provides a list of general Context Substitution Variables. These are not related to the actual event but can be useful to include in the message. A context substitution field can for example be the current users email address. The substitution field will automatically get a pre- and postfix "#" marker to mark it as a context substitution variable substitution field that will be replaced by real data.

Please note that Context Substitution Variables are not supported for 'Rest Call' type event actions.

List Event Actions

All event actions are shown in navigator location Solution Manager/Configuration/Events Actions

Allow Subscription

This option is only available for action type E-Mail. By checking the "Make this action subscribable"-checkbox below Subscription the Event Action gets available for subscription by end users. You can limit the possibility to subscribe to the action by entering a required permission set. Only users that are granted this permission set can then subscribe to the event action.

If an end user subscribes to this action, the user will also get the email as well as the receivers specified in the action.

Event Action Subscriptions

Actions which are of type E-mail and marked as Make this action subscribable are available in this page for end users. Users can subscribe for event actions by enabling the Subscribed field.

List Events

All Events are shown in navigator location Solution Manager/Configuration/Events.

A new event can be added by selecting New Custom Event and filling the details in the New Custom Event assistant that appears. For custom defined events the View Details will direct the user to the Custom Eventpage to view details. Actions related to the selected event can be created through the New Event Action command. To check already defined actions select Show Actions.

Custom Defined Events

Custom Defined Events are events that are defined in a specific installation. The difference between Custom Defined Events and Application Defined Events is that Application Defined Events is defined in the business logic delivered by IFS while Custom Defined Events is configured in Solution Manager and is technically executed by database triggers. The triggers is only created when the event is enabled, in order to recreate the triggers you need to disable the event and then enable it again.

New Custom Event

In order to create New Custom Event user can use navigator entry or New Custom Event button at Custom Event page. Selecting any option will direct to New Custom Event assistant.

Enter Event ID and description

When you create a Custom Defined Event you select a Table on a Logical Unit that should handle the event. The event can be fired on three different occasions:

• New - New objects are created (A new row in the table is created)
• Update - Objects are changed (A row in the table has been modified)
  In this selection you also can select which attributes should be changed in order to fire. If no attributes is selected it means the event is fired when any attribute is changed.
• Remove - Objects are removed (A row in the table is removed)

Attributes

Almost all attributes in the table are available to use in the Event Action message. The only exceptions are LOB's and other special data types. In the attribute list select which attributes that should be available when creating event actions by checking the New Value and Old Value. This creates variables called NEW:<AttibuteName> for New Value and OLD:<AttributeName> for Old Value, for example "DESCRIPTION" and "NEW:DESCRIPTION" or "OLD:DESCRIPTION".

When the event is fired due to an object has changed the NEW:<AttibuteName> is the variable for the new value after the transaction has occurred and OLD:<AttributeName> is the variable for the old value before the transaction did take place. This is how the variables get their value when event is firing:

• New objects
  NEW:<AttibuteName> and OLD:<AttributeName> is the same value since no old values exists.
• Changed objects
  NEW:<AttibuteName> is the new value after the transaction and OLD:<AttributeName> is the old value before the transaction.
• Removed objects
  NEW:<AttibuteName> and OLD:<AttributeName> is the same value since no new value exists.

Note: CLOB type columns are not supported in Events due to a limitation.

Custom Attributes

A Custom Defined Event can have Custom Defined Attributes. Enter a name for the parameter and a PL/SQL function <Package name>.<Method>. The PL/SQL function can use Attributes described above as arguments.

Note: It is not possible to use Context Substitution Variables as arguments to Custom Attributes.
Fnd_User_API.Get_Description(#USER_ID#) is not allowed.

Example:

`Fnd_Role_API.Get_Description(&NEW:ROLE)` or `Fnd_Role_API.Get_Description(&OLD:ROLE)`

Note: If a Custom Defined Parameter selects from the Custom Defined Events table you will run into Oracle error 4091.
ORA-04091: table SCOTT.Emp_tab is mutating, trigger/function may not see it

Export Custom Events

A Custom Defined Event can be exported to the file system as a (*.ins) file. Select the Custom Defined Event detail page and select the command Export Custom Event. The Event can then be imported into another environment by executing the export file in the database.

Custom Events can also be exported using Application Configuration Packages.