Domino/Notes Version: V14 Add-on Product (if appropriate, e.g. Verse / Traveler / Nomad / Domino REST API): Nomad Its Version: 1.0.17 Operating System: Windows Server 2019 Client (Notes, Nomad Web, Nomad Mobile, Android/iOS, browser version): Notes, Nomad Web
Problem/Query: Hi all,
the need is to generate programmatically (agent that runs on server) a PDF file from a specific Notes document. Here some details: we have a Domino application that, if required by the user, produces a Notes document which is then sent to a printer profile previously set within the application PDFCreator. The profile is such that the PDF produced is also positioned in a defined network position (a folder in a different server). Things have worked for years, perfectly, using the Notes Client. Now we are using Nomad instead of Notes. We had to modify many components in many applications (where OLE was used for example) and managed to overcome many issues. Now we are facing the problem that Nomad does not allow the interaction with PDFCreator. I’ve found many ideas on producing the PDF using WkHTMLtoPDF, for example, or other solutions that I am finding hard to implement, so I’m very confused on which approach is the best. Have you ever come across this problem? Any suggestions?
if you have a PDF creator agent that works on an ordinary client try runing the agent on the server instead of int he client context. Send a document with id:s that it should act on to the server.
2. If the software is a client based software. Can the software be triggered from an agent on the server and the software runs on the server produces PDF files and a server agent picks them up from the server.
Firstly, it would be best if HCl allowed documents to be saved as PDF files directly in LotusScript. The relevant idea is here (please vote to support this):
Secondly, regarding your question. It should be possible to work with PDFCreator from Nomad using the COM Helper add-on (chrome plugin). However, my tests have failed so far. I got error when the call:
PDFCreatorQueue.Initialize();
WindowsError(Error { code: HRESULT(0x80020009), message: “Došlo k výjimce.” }):
which would suggest that the error lies with PDFCreator, but it is possible that it will not be able to adapt to the “environment”…
Thanks to everyone who responded to my request for help. While online APIs are a great option, I was tasked with finding an internal solution. It was quite a challenge, but I’ve been testing a stable workflow in our production environment (Domino V14) for a week now.
By combining research and AI, I developed a solution based on these key points:
Node.js: Installed directly on the Windows Server 2022 hosting Domino.
PDF Converter Service: A lightweight Node.js service that acts as a bridge. It uses Puppeteer (headless Chromium) to handle the HTML-to-PDF rendering.
Watchdog Logic: The service uses the fs.watch module to monitor a specific folder. As soon as a LotusScript agent drops an HTML file into the folder, the service triggers the conversion.
HCL Nomad Integration: A LotusScript agent (triggered by a user action) extracts the document content, formats it as HTML, and saves it to the monitored folder. Once the Node.js service generates the PDF in a “results” folder, it can be processed as needed.
Windows Service (WinSW): To ensure 24/7 availability, I wrapped the Node.js script using WinSW (Windows Service Wrapper), which handles automatic restarts and boot-time execution.
A quick note on the implementation: Currently, my agent builds the HTML output field-by-field to ensure perfect layout matching. For environments with many different form types, I suggest developing generic transformation routines or templates to speed up the HTML generation process across different document classes.