Deliver IFS reports with additional email attachments

Explore this learning path

Documentation-based guide draft · Reviewed against sources on 2026-09-27 · Not executed in an IFS environment. IFS references use 26R1 unless stated otherwise. Confirm available APIs, components, and permissions in your installed release.

Send an additional CSV alongside a report PDF using an approved IFS server-side extension. First prove a plain CSV attachment; then add the PDF obtained through the environment’s supported report/file interface. This is a developer procedure, not a reason to query internal document-storage tables or copy files onto Cloud application servers.

Before you start

You need an authorized development schema/extension workflow, a configured IFS mail sender, one controlled test mailbox, and permission to use the platform mail API. The attachment-array signatures were checked against the supplied 26.1.3 source reference; execute and verify them on your installed release before deployment.

Use Application Messages and the mail sender logs to distinguish queued mail from actual delivery. Do not use real customer recipients for the lab.

1. Verify the available mail contract

In your supported development tooling, inspect the COMMAND_SYS package specification and confirm:

• ATTACHMENT_ARR is available.
• Add_Attachment accepts a filename with a CLOB or BLOB.
• Mail has the overload accepting attachments_ and an optional mail_sender_.

These overloads differ from older filename-string examples. If the specification does not match, stop and adapt to your release instead of creating direct storage-table queries.

2. Create a small original CSV attachment

The following lab block queues a fictional CSV email when executed with real, approved sender/recipient values. Replace every YOUR_... value first and confirm the mail sender is restricted to your test mailbox.

DECLARE
  attachments_ COMMAND_SYS.ATTACHMENT_ARR;
  csv_ CLOB := 'reference,quantity' || CHR(13) || CHR(10) ||
               'LAB-SHIP-014,3' || CHR(13) || CHR(10);
  body_ CLOB := 'Development attachment test. No business action required.';
BEGIN
  COMMAND_SYS.Add_Attachment(
    attachments_ => attachments_,
    filename_    => 'lab-shipment.csv',
    attachment_  => csv_);
  COMMAND_SYS.Mail(
    sender_      => 'YOUR_IFS_SENDER_ID',
    from_        => 'YOUR_APPROVED_FROM_ADDRESS',
    to_list_     => 'YOUR_TEST_MAILBOX',
    subject_     => 'LAB-SHIP-014 attachment check',
    text_        => body_,
    attachments_ => attachments_,
    mail_sender_ => 'YOUR_MAIL_SENDER');
END;
/

Use your development tool’s normal transaction policy to complete the intended test. Do not add a COMMIT inside an event handler or reusable business method. A mail call returning normally may only mean it queued the message; confirm the downstream result.

3. Inspect the received file

Find the queued application message using the subject/reference and submission time. Check its processing result, then open the test mailbox. Confirm that the CSV filename, two rows, delimiter, and line endings are correct.

For real dynamic CSV data, quote fields containing commas, quotes, or newlines and double embedded quotes. Apply an agreed spreadsheet-formula policy for values beginning with =, +, -, or @; simply quoting a formula is not a complete defense. Keep the initial fixture static until transport is proven.

4. Add the generated PDF as a BLOB

Have the supported report/file API return the chosen report PDF as a BLOB variable named report_pdf_ in your extension. Validate that it is nonempty and belongs to the same report result/business record as the CSV. Before the Mail call, add:

COMMAND_SYS.Add_Attachment(
  attachments_ => attachments_,
  filename_    => 'lab-shipment-report.pdf',
  attachment_  => report_pdf_);

report_pdf_ is an integration input, not an automatically available variable. Obtain it through the report/download contract discovered in your environment; a browser filesystem path is not a BLOB. Do not assume legacy PDF_FILE paths or database-resident document BLOBs remain valid when Cloud File Storage is enabled.

5. Attach the extension to a narrow trigger

If using the installed PDF_REPORT_CREATED event, inspect its declared parameters and an actual development execution. Restrict your custom handling to the precise report ID and permitted recipient scope. Verify the report-result key and business key rather than hardcoding the meaning of a numbered PDF_PARAMETER_n from another report.

Use your supported extension/deployment mechanism. Execute Online SQL event actions are deprecated in current Cloud guidance; do not introduce them as the default new implementation. Coordinate the custom send with the standard report email path so one print produces one intended email, not both standard and custom copies.

6. Test errors, replay, and cleanup

Test a missing PDF, an oversized attachment, rejected recipient, sender failure, and two different business records. Confirm the second record cannot receive the first record’s attachment. Keep a stable report-result/message reference for reconciliation before retrying a timeout.

Disable the lab trigger before removing its extension or sender configuration. Retain sanitized message IDs and filenames as evidence. The completed test requires both attachments to be present in the received email and to match the intended report result.

For configuration-layer alternatives and event fields, see IFS event actions.

Sources and scope

• IFS reporting rules
• IFS report rendering configuration

Older IFS Applications examples are historical context, not evidence of Cloud compatibility. No third-party code, screenshots, or downloadable workflows are reproduced.