Inbound Processing

Adding an inbound email link in Floe Designer 

From Floe 210, the Floe Designer application can be used to add inbound email links/buttons to the email content. Clicking on the "Add inbound email link" button in the rich text editor will present the user with a dialog containing configuration options for the look and feel of the link/button as well as the actual inbound email (variables can be used in any of these fields).


Action is a special code associated with the link/button. It may be used to determine in the back-end which button was pressed (as there may be more than one on the email - "Approve" and "Reject" for example) or to pass data to the back-end. Email Subject and Email Body determine the subject and body of the inbound email. 

 

Triggering an inbound email

The email now contains a "Cancel Order" button:

If the user clicks on this button the email client will create/populate a new email:

The "To" address in this email is read from the "Recipient Email Address" field in "System Settings".
The subject is as configured in the Floe Designer application above.
The email body contains the configuration from the Floe Designer application as well as a meta-data section. This meta-data section contains encrypted meta-data including the email id of the original outbound Floe email, and the "Cancel Order" button action. If it is deleted, the system will log an error when it receives the inbound email. Once the email is sent, assuming inbound email have been configured correctly during installation it is processed by the system. The following rules apply:

  • The meta-data section must not be altered in any way.
  • For security purposes, an inbound email will only be accepted if it is sent from the email address of the original recipient - aliases are not supported.
  • Once an inbound process has completed successfully no further inbound emails can be triggered from the same outbound Floe email.
     

Inbound user-exit

Once all system checks are successfully complete, the inbound user-exit will be triggered. The following import parameters are available:

  • im_sender_email: the email address of the sender
  • im_esubject: the subject of the inbound email
  • im_ebody: the inbound email body (the meta-data section will have been stripped out)
  • im_attachments: attachments of the inbound email
  • im_action: the action code of the button the email was created from (in this example it will be the order number which can be used to process the cancellation. In other cases, it may be a code depicting which button the user clicked on, for example Approve or Reject)
  • im_eid: the id of the original outbound Floe email. Note that inbound emails are not assigned an id - this inbound process will be linked to the outbound id.

This data can be used inside the user-exit to trigger the required process (e.g. to cancel the order in this example). The following export parameters can be filled:

  • ex_subrc: indicates success (when equal to 0) or failure (any other value)
  • ex_mess_t: table of messages to be passed back
  • ex_pdoc: inbound process document - this can be used to search for the process in the Inbound Processing Engine Log (see below)
     

Handling inbound process errors

In case of an error (either because one of the system checks failed or because ex_subrc is set to a value not equal to 0 in the user-exit), the system can be configured to send an email back to the initial sender with the error details. This is achieved via maintaining a value in the "Error Email Type" field in "System Settings". This field determines the email type to be used for reported the error. Email type IEEE (Inbound Error Email Example) is provided by Arch and customers can import (via the transport wizard) and then copy and edit this (to add company logos for example) or create a brand-new type. The following variables will be made available to the inbound error email when it is triggered (although others can be added via the user-exit):

  • FLOE__MESSAGE (repeating variable): The error messages from the system. This includes any messages passed back from the user-exit in parameter ex_mess_t
  • FLOE__INBOUND_ADDRESS: The system email address the inbound email was sent to
  • FLOE__INBOUND_DATE: the date of the inbound error
  • FLOE__INBOUND_TIME: the time of the inbound error
  • FLOE__OUTBOUND_ETYPE: the email type of the original outbound email, i.e. the one the user replied to (this variable will not be available if the system is not able to read the meta-data from the inbound email)
  • FLOE__OUTBOUND_ID: the id of the original outbound email, i.e. the one the user replied to (this variable will not be available if the system is not able to read the meta-data from the inbound email)
     

Inbound Processing Engine Log

The Inbound Processing Engine Log IMG transaction displays a report of all Floe inbound email processes received by the system.  Users can use the selection screen options to find the process they're interested in:


Inbound Processing Security

Floe performs several security-related validations before passing the inbound decision capture to the user-exit which ultimately will be responsible for making any SAP updates.

  • Check #1 – DKIM Signature

Floe validates DKIM(Domain Keys Identified Mail) signature of the inbound email. DKIM is an email authentication technique that allows the receiver (SAP Inbound email handler) to check that an email was indeed sent and authorized by the owner of that domain. This is done by giving email a digital signature which is handled by the mail server.

  • Check #2 – Recipient Address

Floe then validates the recipient ‘From’ email address against the Floe email history database to identify if the recipient was sent any notification for action.

  • Check #3 – 256 AES Encrypted Identifier

Floe generates an encrypted key for each inbound decision capture process which uniquely identifies the recipient who is allowed to respond to a specific chain of communication. When the recipient responds to Floe using the decision capture buttons embedded in the email, this unique encrypted identifier is passed back in the email body of the response. Floe then decrypts this 256 AES encrypted key to identify the recipient, and also gather other metadata associated with a specific inbound process.

The email content will only be processed and forwarded on to inbound user-exit for further processing such as SAP updates etc., only if the incoming email successfully passes all three validation checks as described above.