Example of an MER business workflow

A workflow is a sequence of activities performed in accordance with business processes. A workflow determines what can be done, by whom, and under what circumstances.

An MER workflow entails routing messages among MER queues, and can be of one of the following types:
Business workflow
Routes a message in response to a business action.
User workflow
Routes a message in response to a user action.
Figure 1 shows an example of a business workflow as it is experienced by a user:
  1. A user creates and submits a message.  1 
  2. The workflow specifies that a different user must either accept or reject that message.  2 
  3. If the authorizer rejects the message, it is placed on an edit queue, where a user can edit and resubmit it to the authorize queue.  3 
  4. If the authorizer accepts the message, it is placed on an output queue for further processing by applications external to the MER Facility.  4 
Figure 1. Business workflow as experienced by a user
Figure showing business workflow as experienced by a user

Figure 2 shows the same workflow as it is implemented using the MER Facility:

  1. A user creates and submits a message  1a .
  2. The MER enterprise application records in the database  1b  that:
    • The message is in a main create queue, and the name of that queue.
    • An MER routing message flow is to continue processing the message. It does this by setting the next processing type field for the message to Business.
  3. The MER routing message flow that processes messages that are in that main create queue continually scans the queue to determine whether there are any messages that it is to process. When it encounters such a message  1c , it determines the next processing step in the workflow. In this example, the next step is for the message to be processed by someone other than the user who created the message, so it sets fields in the message  1d  to indicate:
    • That the message is in a main authorize queue, and the name of that queue.
    • That the MER enterprise application is to continue processing the message. It does this by setting the next processing type field of the message to Application.
  4. The message is now in the authorize queue  2a . A new user (not the user who created the message) can now either accept or reject the message.
  5. The MER Facility sets fields in the message to indicate:
    • That the message is in the main authorize queue.
    • That an MER routing message flow is to continue processing the message.
    • Whether the message was accepted  2b  or rejected  2c . If accepted, the message is placed in an output queue for further processing by applications external to the MER Facility  4 .
  6. The MER routing message flow that processes messages that are in that main authorize queue (this can be, but is not necessarily, the same message flow that monitors the main create queue) continually scans the queue to determine whether there are any messages that it is to process. When it encounters such a message ( 2d  or  2f ), it determines the next processing step in the workflow. Depending on the action (accept or reject), the message flow determines the appropriate destination for the message:
    • If the message was accepted, it sets fields in the message  2g  to indicate:
      • That the message is in a main application queue, and the name of that queue.
      • That the MER enterprise application is to continue processing the message.
    • If the message was rejected, it sets fields in the message  2e  to indicate:
      • That the message is in the main edit queue.
      • That the MER enterprise application is to continue processing the message.
      While the message is in an edit queue  3a , a user can repair the message and resubmit it  3b . The MER routing message flow routes the message back to the authorize queue  3c .
Figure 2. Business workflow as implemented using the MER Facility
Figure showing business workflow as implemented using the MER Facility
The following business actions trigger an MER business routing flow:
Submit
This is the only action that is possible for a message that is in a queue with the purpose Create, Edit, or Display. It indicates that the message is to be routed to the next step in the workflow.
Accept
For a message that is in a queue with the purpose Authorize, Retype, or Confirm, this action indicates that authorization was granted by the user.
Reject
For a message that is in a queue with the purpose Authorize, Retype, or Confirm, this action indicates that authorization was denied by the user.
When an MER routing flow receives a message from an external application (not a message that was created manually by a user) it routes the message directly to an MER queue. An MER routing flow can route a message to any queue, delete a message, or create a copy of a message.

Actions that require routing of a message to a queue of a different type but of the same purpose (for example, saving a message as a draft, or moving a message to the redirect queue) are processed by a user-action routing flow. The same is true of administrator actions such as editing a template or moving a message to a different queue.

To prevent different users from working on the same message at the same time, a message is locked as soon as a user opens it for manual processing. A locked message still resides in its queue and appears in message lists, but is flagged with a lock symbol. When the user completes the manual processing step, the message is automatically unlocked.