Notifications

GWE allows the definition of custom notifications that can be associated with different events of your workflow and sent to the responsible persons. The messages are defined similarly to how you would define them in the ARCHIBUS standard solution.

Defining Messages

To define a new message or edit existing ones you must go to the Define Messages view.

To edit a message click on any row of the Select Message panel.
To add a new message click on the Add New button and fill out the message details in the right-hand side form.

Message Fields

• Primary Application: Typically we use WorkflowEngine as primary application when defining a new message for GWE but any application will do.

• Referenced By: This field is used as a grouping field, making it easier to recognize which message belongs to which group. It is necessary because as we know, in ARCHIBUS, the subject and body of a notification are treated as separate messages.

• Message Code: The unique key of the message. Make it into something descriptive and maybe add a _BODY or _TITLE suffix just to make things clear. GWE already comes with 2 example notification messages. You can find them by filtering the messages using the primary application WorkflowEngine.

• Is Rich Message Format?: Whether the message contains placeholder values that will be replaced with real values when the notification is sent.

• Description: A short description of the message and what it’s used for.

• Message: The default message content. It can be localized in the next fields.

Data Model

You can use placeholder values that will be populated from the data model when the notification is sent.

By default, all of the fields of the current request can be used in your notification.
e.g. Assuming your workflow is based on the wf_requests table, the available fields would be:

• ${wf_requests.requestor} The employee id of the user who created the request.
• ${wf_requests.wf_type} The workflow type
• ${wf_requests.status} The status of the request
  …

Utility Expressions

On top of that GWE also adds a few utility expressions such as:

${webCentralPath}

${notificationURL}

${graphicalPath}

${actionComments}

${currentView}

${currentUser}

${currentEmployee.em_id}
${currentEmployee.name_first}
${currentEmployee.name_last}
...

${recipient}

${recipientEmployee.em_id}
${recipientEmployee.name_first}
${recipientEmployee.name_last}
...

${recipientUser.user_name}
${recipientUser.role}
${recipientUser.email}
...

Defining Notifications

In this section you will learn how to define a GWE notification that can be later used to inform users of a particular event like a request status change or that an action is required of them.

To create a new notification or edit an existing one you need to go to the Define Notifications view.

To edit a notification click on any row of the Select Notification panel.
To add a new notification new notification click on the Add New button and fill out the notification details in the right-hand side form.

Notification Fields

• Notification Code: The unique key of the notification. Make it into something descriptive and memorable so you can easily recognize it when you design a workflow and you want to add it as an event for an action. GWE already comes with 2 example notifications: GWE_ESCALATION and GWE_STATUS_CHANGE.

• Description: A short description of the notification and what it’s used for.

• Primary Application: This must match the message’s subject’s primary application. It will be autocompleted once you select the subjectid or the body id.

• Notification type: The notification can come from different sources: message, template or handler. It can either be a message defined in the database (option Message), a localized html template that lives on the server (option Template) or it can be custom implementation in Java via a handler class (option Handler).

com.archibus.gwe.notification.domain.GweNotificationHandler

Attachments

You can add attachments to your emails. They are documents loaded from the database.
e.g. Suppose you add a document field on your request and use it to store a document. You can attach that document to emails by adding it via the Notification Attachments panel.

To add a new attachment to your notification, simply click the Add New button and select the table and field that contain the attached document.

Additionally you can restrict the sending of the attachment via an SQL clause in the Condition field.
e.g. You want to send the attachment only when the document field is not empty so you use the following restriction:

wf_requests.request_id = ${wf_requests.request_id} AND doc1 IS NOT NULL

If you are using either the Message or the Template notification types you have access to all the default data model binding expressions.

For a quick recap on what expressions you can use by default in your conditions go to: