Oracle EBS R12.1.3 Submit Request Delivery Options Button – Email

Let’s take a look at the Email tab next.

This tab allows for the delivery of the report in question via email. Users are able to specify:

• From – The sender of the email. By default this field is populated with the email address specified for a user in the fnd_user table. This default can be overwritten by the user.

• Subject – The subject for the email. By default this field is populated with the string “Instance Name : Concurrent Program Name : Username” where
  Instance Name is pulled from the query: select instance_name from v$instance
  Concurrent Program Name is the program that is being run
  Username is the user name running the report.
  This value can be overwritten by the user.

• To – Email address of the recipient. Multiple addresses can be specified by separating them with a comma.

• CC – Email address for the carbon copy recipient. Multiple addresses can be specified by separating them with a comma.

Configuration
The Email tab utilizes SMTP to communicate to a mail host that in turns sends the email to the recipients. The hostname and port of the mail host is configured via the profile values:

FND: SMTP Host
FND: SMTP Port

Based on the package fnd_delivery, it appears that SMTP username and password should be able to be set, however it is currently unknown if this is fully implemented. It does not appear that these functions are invoked.

Functionality
For each recipient row (To/CC), a new email is sent to the defined recipients. The behavior of the delivered email is as following:

1. If the report being delivered is TEXT based, then the email message body contains the report contents.
2. If the report being delivered is NON-TEXT, then the email message body is blank and attachment containing the report contents is delivered. The attachment name is derived from the Concurrent Program Short Name and Request ID. For example:

POXPRPOP_12345676_1.PDF

It is important to note that there is NO bursting functionality associated with this form. What you define for your concurrent request parameters to generate output is what is going to be sent to the end recipients.

Pros and Cons
Overall this appears to be some great new functionality, the immediate/obvious pro that I see is that the ability to send reports as email is now available. Additionally, the ability to specify a from email address allows the sender to receive any bounce backs that may happen based on a botched email address.

Some issues that I see with this new functionality are:

1. Format of the email – depending on the report output type, the email will be delivered with the report as an attachment or as part of the email message body. In most cases I would think that the message body should be somewhat configurable, i.e. a way to say “Hello xyz, here is the report that I promised you” or at the very least have some hardcoded information about the sender and contents of the email.

2. Attachment names. The names of the attachments that get delivered with the email are not the most user friendly as it is derived from internal Oracle information (Request ID, Program Name).

3. User experience/process. Because the ‘Upon Completion’ form where a user would typically specify a printer is still in play, a user must ensure that if they only want to email the report that the printer is set to ‘noprint’ or something similar. For example, if I want to email the ‘Active Users’ report to my System Administrator, I have to do the following.
a. Submit a New Request, choose the ‘Active Users’ report.
b. Pop the Delivery Options form and fill in the appropriate email parameters.
c. Pop the Upon Completion form and change the printer/style combination such that the report is not actually printed out.
d. Hit submit to process the request.

Overall, likely not a huge issue, but (c) is just another step a user has to take to prevent errant print-outs of data when they really just want to email the report.

Next up…. the Fax tab. Additionally, would love to have your feedback regarding your thoughts about the functionality.