Skip to main content
Question

Compiling IFS Subcontract Attachments and Linked SharePoint URL Documents into a Single Merged PDF Package

  • August 4, 2026
  • 1 reply
  • 41 views
U
Do Gooder (Partner)
Forum|alt.badge.img+1

Hi Everyone,

We have a requirement around Subcontract Management in IFS Cloud and wanted to check if anyone in the community has implemented a similar modification or solution design.

Requirement Overview

During the subcontract creation/administration lifecycle, a Subcontract record can contain:

  1. Multiple Document Attachments stored in IFS Document Management (DocMan).

  2. One or more SharePoint file URLs linked as external document links/URLs.

When the user triggers a "Generate Subcontract Package" action (or similar command), the system needs to:

  1. Retrieve all physical attached documents (DocMan attachments) associated with the Subcontract.

  2. Retrieve/download all external files hosted at the linked SharePoint URLs.

  3. Convert/Merge all retrieved documents (including cover pages/report outputs) into a single, consolidated PDF file.

  4. Attach the generated merged PDF back to the Subcontract's DocMan repository automatically.

Questions for the Community:

  • Has anyone implemented a similar automated PDF consolidation workflow combining both native IFS DocMan files and external SharePoint URLs?

  • What architecture/approach did you use for the PDF compilation and SharePoint integration

  • How did you handle authentication/file retrieval for the SharePoint URLs dynamically?

  • Are there any standard IFS Cloud APIs or framework utilities you’d recommend leveraging for managing the merged document checkout/check-in stream?

Any insights, code snippets, architectural advice, or lessons learned would be greatly appreciated!

Thanks in advance.

    1 reply

    deshan.ekanayake
    Do Gooder (Employee)
    Forum|alt.badge.img+4

    Hi ​@Udara Priyamal ,

     

    On whether this exists today

    This isn't something IFS Cloud provides out of the box. There's no standard action that collects attachments, converts them and produces a merged PDF, so it would need to be built as a modification.

    We're also not aware of a specific existing implementation we could point you to. It's quite likely one or more customer project teams have built something along these lines, so it may be worth raising with neighboring project teams as well.

     

    Suggested approach

    Given the current state, our recommendation would be to handle both the conversion and the merge in a small service outside IFS Cloud(preferably cloud hosted), and to let that service retrieve the files itself.

    There are two reasons for keeping this outside IFS.

    • Oracle can't combine PDFs or join files together in PL/SQL.
    • Oracle can't convert Word, Excel or image files to PDF at all. Conversion needs a rendering engine, and that has to live outside the database regardless. 

    Letting the service fetch the files, rather than IFS sending them, keeps the command lightweight. IFS sends a small list with the document keys and the SharePoint URLs, in the order they should appear and the service takes it from there. The flow would look like this:

    1. The user - runs the command on the Subcontract.
    2. IFS Cloud -  builds an ordered list of document keys and SharePoint URLs.
    3. IFS Connect - calls the service and passes that list.
    4. New service - retrieves each file from IFS for the attachments, from SharePoint for the links.
    5. New service - converts anything that isn't already a PDF.
    6. New service - merges everything into one PDF.
    7. New service - checks the merged PDF back into IFS against the Subcontract.

    On the conversion step

    • Agree the supported file types explicitly. Word, Excel, PowerPoint, images and existing PDFs cover the large majority in practice. Emails, archives, CAD drawings and media files are much harder to handle. It's better to define a supported list than to try to cover everything.
    • Expect some visual differences. Converted Office documents won't always look byte-for-byte identical. Page breaks and spacing can shift a little. This is normal for any conversion technology, but it's worth setting expectations.
    • Conversion is resource intensive. This is a further reason to keep it in a service of its own, where it can be sized appropriately and won't compete with the application for resources.

    Retrieving from IFS and checking the result back in

    The CreateAndImportDocument.svc API is well suited to both ends of this. The service can use it to pull down each attachment, and then to create the new document and load the merged PDF back in.

    The service will need its own credentials to call IFS. We'd suggest a dedicated service user registered in IFS IAM with DOCMAN_ADMINISTRATOR system privileges as well.

    Retrieving from SharePoint

    Microsoft Graph(https://learn.microsoft.com/en-us/graph/overview) is the recommended REST API that sits in front of Microsoft 365, including SharePoint and OneDrive. 

     

    A note on doing this inside IFS

    It's technically possible to perform the conversion and merge within IFS Cloud, using a Java projection with standard Java libraries. We’d strong discourage from doing that.

    That Java layer runs inside the OData service, which supports the whole application. Both conversion and merging are memory intensive, and a large package can consume enough memory to affect performance for all users. In the worst case, the middle tier can become unstable.

    A separate service removes this risk entirely, and can be sized, monitored and restarted independently.

     

    Thanks!

    Deshan

    /Deshan
    Terms & ConditionsAccessibility statement