BI Publisher bursting currently reports an email delivery as successful once the email has been processed and sent from Oracle. However, there is no customer-accessible functionality in Oracle Fusion/BI Publisher to determine whether the email was subsequently delivered, rejected, bounced, or returned as undeliverable by the recipient's mail server.
For example, a BI Publisher bursting email may show a successful status even though the recipient does not receive the email. In SR 4-0003543841, Oracle Support identified that an email which showed as successfully sent in BI Publisher was subsequently rejected by the recipient mail server with SMTP error 550 5.1.1 – Recipient address rejected/User unknown.
Currently, customers do not have access to the underlying SMTP/bounce information and therefore cannot proactively identify such failures. Oracle Support confirmed that these downstream failures occur outside Fusion and that there is currently no customer-accessible method to track them.
Requested Enhancement
Provide customer-accessible email delivery tracking for emails sent through BI Publisher Bursting, preferably through a seeded report, OTBI subject area, BI Publisher delivery history, or another query based monitoring interface.
The functionality should ideally provide:
- BI Publisher report/job or request ID
- Date/time sent
- Recipient email address
- Email subject
- Initial BI Publisher bursting status
- Final delivery status such as Sent / Delivered / Bounced / Rejected / Undeliverable
- SMTP response/error code and description
- Message ID for tracing
- Bounce/rejection timestamp
- Ability to report/export failed email deliveries
Business Need:
Organizations use BI Publisher bursting to send business-critical documents such as payment remittances to external recipients. A successful bursting status currently does not confirm that the recipient actually received the email. If the recipient mail server subsequently rejects the message, there is no customer-accessible mechanism to identify the failure.
This creates a monitoring gap where business users may believe a communication was successfully sent while the recipient never received it. Customers currently have to wait for the recipient to report the issue and potentially raise an Oracle Service Request to obtain the downstream SMTP/bounce details.
Providing customer-accessible delivery and bounce status would allow organizations to proactively identify failed communications, correct invalid recipient addresses, resend documents, and reduce dependency on Oracle Support.
