How to generate a PDF in Workday Orchestrate and store it as an attachment

Trigger PDF Generation renders the PDF; a second step stores it

In Orchestrate, a PDF comes from the Trigger PDF Generation step: it takes a BIRT report design and the XML data to fill it with, and returns the rendered PDF as its only output. It does not save the file anywhere, so the PDF exists only until you pass it to a Store Document step (to attach it to the integration event) or send it to a Workday API that files it on a record, such as Put_Worker_Document for a worker.

Two constraints decide the design before you start. The step is available only in the Integration System template, so a synchronous Extend orchestration behind a page cannot render a PDF itself. And it cannot be used inside a Join Loop.

What the step needs: a report design and report data

Report Design and Report Data are the two required fields.

The report design is the .rptdesign XML that BIRT produces, the same kind of file you attach to a custom report as a business form layout. You build it in Report Designer in Workday Studio; Workday's business form layout steps cover that part. The orchestration can get the XML in three ways:

1. Paste it into a Create Text Template step and pass its message, as Workday's Simple_PDF sample does (data.rptdesign.message). Quick to start, but every layout change becomes an app change.
2. Attach the file to the integration system and read it with intsys.attachmentContent("<attachment service name>"). Layout changes then become tenant configuration.
3. Fetch it from an upstream Send Workday API Request step, which is the example the reference page gives.

The report data is the XML the design's data source expects, usually shaped like a custom report's wd:Report_Data with one wd:Report_Entry per document. It can come straight from a Send Workday RaaS Request for that report, or you can build it yourself with a text template or a loop with an XML Fold aggregation when the data comes from several sources. Either way it must use the element names and namespace that the design's data source declares. In the Simple_PDF sample the design's data source declares the urn:com.workday.report/Employee_Total_Rewards schema, and the report data template uses that same namespace.

The optional settings that change the output

• Business Form Layout WID. Supplies the images and translation data held in that layout. The design in Report Design still wins: Orchestrate ignores the layout's own design. The Token_PDF sample reads the WID from an integration attribute with intsys.referenceAttributeValue("Business Form Layout", "WID"), which keeps it out of the app.
• Locale (for example en_US) controls country-dependent formatting such as dates and numbers. Language (for example de_DE) controls the text language and its direction. The Translate_PDF sample takes the language from a launch parameter.
• Timezone (for example US/Eastern) sets the time zone used in the PDF.
• Apply Report Design Per Row: set to true and every row of the report data starts a new page. Use it to produce one PDF that holds a letter per worker.

Authentication uses a credential from the Credentials tab of the orchestration's Settings; the samples use the initiating user's access token.

Why the PDF step starts a new process

Trigger PDF Generation is one of the checkpointing components. When the orchestration reaches it, the current process saves its state, the rendering runs, and a new process picks up the saved state with a fresh 60-minute window on a production tenant (45 minutes elsewhere), per Workday's Orchestration Processes page. The integration as a whole still has its own limit of 48 hours for the Integration System template, set on the Orchestration Runtime Limits page.

So a PDF step placed after a long data-gathering phase does not inherit the time that phase used. A loop that generates thousands of individual PDFs is a different matter; see working within Orchestrate's runtime limits, and prefer one call with Apply Report Design Per Row where one combined file is acceptable.

Attach the PDF to the integration event

Pass the step's output, data.<step name>.data (in the samples, data.TriggerPDFGeneration.data), to a Store Document step:

• Document to Store: data.TriggerPDFGeneration.data
• Document Title: the file name people will see, for example offer-letter-21157.pdf
• Attach document to integration event: true. In Integration System orchestrations the stored document is not attached by default.
• Storage Expires In: an ISO 8601 duration such as P7D or P1M.
• Content Type Reference (optional): an instance reference to application/pdf.

If the integration system has delivery services configured, Deliver from associated delivery services routes the stored PDF to their target endpoint without further steps in the flow.

Attach the PDF to a worker instead

A file on the integration event stays with the integration run, not with the worker. To file it on the worker, call the Staffing web service operation Put_Worker_Document with a Send Workday API Request step. Its Worker_Document_Data takes Filename (up to 255 characters), an optional Comment, File as base64, Content_Type, a Document_Category_Reference and the Worker_Reference. Build the body in a text template and encode the PDF inline:

<wd:Put_Worker_Document_Request xmlns:wd="urn:com.workday/bsvc">
  <wd:Worker_Document_Data>
    <wd:Filename>{{data.mapRow.fileName}}</wd:Filename>
    <wd:File>{{data.TriggerPDFGeneration.data.base64encode()}}</wd:File>
    <wd:Document_Category_Reference>
      <wd:ID wd:type="Document_Category_ID">{{data.mapRow.categoryId}}</wd:ID>
    </wd:Document_Category_Reference>
    <wd:Worker_Reference>
      <wd:ID wd:type="Employee_ID">{{data.mapRow.employeeId}}</wd:ID>
    </wd:Worker_Reference>
    <wd:Content_Type>application/pdf</wd:Content_Type>
  </wd:Worker_Document_Data>
</wd:Put_Worker_Document_Request>

base64encode() is a Data member function; Workday's Worker Inbound Image Upload sample uses the same {{ ... .base64encode()}} form inside a SOAP File element. Send it in a SOAP envelope the same way as your other SOAP calls (the Xml member function wrapSoapV11() wraps a document in a SOAP 1.1 envelope), and use a document category ID that exists and is active in the tenant; the operation rejects an inactive one. The Staffing API notes that documents added this way are not tied to, or secured by, a business process event.

Attach the PDF to an Extend attachment object

When the PDF belongs to a record in your own Extend app, post it to the app's attachment object API, apps/<app reference ID>/v1/<attachment collection>, as multipart/form-data. Workday's Employee Relations Incident Management sample does this right after Trigger PDF Generation, using the Form Multipart Body option of Send Workday API Request with two parts:

1. A part named data holding JSON from a text template: the record's fields plus "file": "cid:attachmentContent" and "fileName".
2. A part named attachmentContent whose data is data.TriggerPDFGeneration.data, with content type application/pdf and a filename disposition parameter.

The cid: value names the part that carries the file. Order matters: Workday's Attachment Objects page notes that sending the JSON data after the file data returns a 500 error. fileLength and contentType are derived by Workday and cannot be written. Modelling the attachment object itself is covered in attachments on Extend business objects.

For moving files through JSON APIs as base64 more generally, see base64 attachments in Orchestrate.

How to test it, given the debugger cannot run this step

Orchestration Builder's step debugger does not support Trigger PDF Generation, and an Integration System orchestration has to be deployed and run once in the tenant before you can debug its other steps. So test with real runs:

1. Launch the integration for one worker and open the integration event. The PDF should be attached under the title you set; open it and check the fields you care about are filled, not just that a file exists.
2. If the PDF renders with empty fields, compare the report data's root element, element names and namespace with the data source declared in the design before looking anywhere else.
3. For the worker route, read the document back with Get_Worker_Documents (or open the worker's documents in the tenant) and confirm the file name, category and content.

Add an Add Integration Message at the end that names the file and the worker, so the event itself tells the reader what was produced.