- Business Needs
- Application Integrations
- Delivery Technology
- About STR Software
About STR Software
This is the 3rd post in series on new features in 12.1.3. See the entire series here:
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:
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.
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:
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.
For more information: