Tracking issues with a bare bones agent

Enabling DominoPDF logging is the method used for seeing what is happening with DominoPDF.

You can see how to enable logging from our Knowledge Base

When I’m having trouble tracking down an issue with DominoPDF I go for the least code possible to test the integration and file writing etc.

In the (Initialize) section I just add a call to the DominoPDF method with a hardcoded URL (one I know works) and a hardcoded PDF path, adding authentication and DominoPDF logging as required. As a safe bet the system temp directory is good to write to as it’s generally available for all working tasks;

Call v.DoPDF(“http://www.google.com”, “c:\temp\test.pdf”, “WebUsername=user;WebPassword=secret;LogFile=c:\temp\dompdf.log.txt”)

I then run the agent either locally on the server or remotely etc. and check the output.

If the PDF file is created then I know DominoPDF is installed OK and I can then begin integrating more with dynamic values for URL, file path etc.

If the PDF file is not created I can check the log file and see what the cause was.

If the log file does not exist I usually extend the agent to add LotusScript error handling. For example;

On Error Goto Error_Handler
Call v.DoPDF(“http://www.google.com”, “c:\temp\test.pdf”, “WebUsername=user;WebPassword=secret;LogFile=c:\temp\dompdf.log.txt”)

The_End:
Exit Sub

Error_Handler:
Print “DominoPDF Error: ” & Error$

Now when I run the agent I can see if LotusScript throws any errors and examine the Error_Handler statement for the Error$. If there is an Error$ value I can take appropriate action.

If all the above fails I’d start checking to see why the log file did not get created (directory rights, can I save a file with LotusScript itself to that directory etc.) as the log file is the best bet for finding out why DominoPDF fails.

If none of the above helps then we’ll need to dig a bit deeper to find the cause so please contact the support team.

Comments are closed.