[Html2PdfConverter] Timer always "deactivated"

[Html2PdfConverter] Timer always "deactivated"

  
Forge Component
(40)
Published on 24 Mar by Guilherme Pereira
40 votes
Published on 24 Mar by Guilherme Pereira
We have been using this eSpace/extension for a long time and after upgrading to 9.0.0.6 I upgraded this reference as well.

I am able to follow the installation instructions and upload the binaries, however the binaries folder/files are not in the platform/running/Html2PdfConverter folder and I cannot run the timer.

The timer is "deactivated" and when I click "Activate" it says it was "successfully activated", but if I click "Refresh" without trying to do anything else, the timer is deactivated again.

I'm not sure how to work around this issue.  I have tried putting the files in place manually, but on republish it deletes them.

Thanks,
Owain
Hi Owain,

The fact that the timer is deactivated is normal because the scheduling is "When Publish". Nevertheless if you publish the component you should see the last run close to that time.

Are you using a multi-farm environment? If you are you could be hitting a problem already identified here. (no solution yet apart from the workaround sugested by pedro on that post)

Can you run the timer InitBinaries in debug mode and tell us the results?

Cheers
Thanks for the reply.

We are running multiple front-end servers and I did not think of that.  However I thought the issue was the timer because the "binaries" folder and its contents are never created on either server (2 front-end servers).

I manually copied the files there as a quick test workaround and it works for testing within Html2Converter, but references to the eSpace do not get the files correctly.

Reading the workaround:
"For a quick workaround, uploading the necessary .exe and .dll files as Resources (although quite big ~50MB) and setting up a site property to enable this option, works pretty well."

I can easily add these files as resources, but I'm not sure the entire process following that, does this mean that the "GetWorkingDirectory" action in the extension will not work using this workaround?
Hi Owain, GetWorkingDirectory action in the extension will not be used with that workaround. The fix bypasses the whole autosetup doing just like what the earlier versions of HTML2PDF did - publishing the whole app and copying the libraries along to its directory, through the extension's Resources feature. The mentioned site property is supposed to keep compatibility with the Forge's version. But surely you can ignore it. Just make sure that GeneratePDF action calls the wkhtmltopdf.exe from the eSpace directory, path string should be empty ("") as long as the Resources rules mention "Copy to Application directory". Let me know if this was clear. Happy coding, Pedro
Hi Pedro,

I have the resources with them set to "Deploy to Target Directory" and I have tried the ExecutablePath both as ".\wkhtmltopdf.exe" and as "wkhtmltopdf.exe", but both get a "file not found" exception. I ran this through the debugger, but it doesn't provide any additional information.  Is there a certain way to specify the path? I have verified that the files are in the /running/HtmlToPdfConverter folder so it is successfully deploying the resources.

Thanks,
Owain
Hi Owain,

I've just uploaded a new version 1.0.8 with experimental support for farm configuration (you just have to activate the option on the administration page). If you're willing to give it a try and send us some feed back we'd apretiate it as currently I don't have access to a configuration like that to perform proper testing.

Cheers,
Guilherme
Owain,

Please check my workaround version in attach if it helps (it has ipp sorry). I had both wkhtmltopdf.exe and the .dll as extension resources with that same path set.

Another troubleshoot might be debugging the extension itself, so you can locate the files.

Good luck and keep trying,
Pedro


Hi,

I tried both of the above. I was receiving the same "file not found" error with the farm configuration option, but Pedro your version seems to work. However I am experiencing a strange issue where the actual eSpace HtmlToPdfConverter works correctly, but if I reference it in another eSpace the .dll file is not deployed to the eSpace refencing HtmlToPdfConverter. I am not sure the repurcussions of this, but what I am seeing is the PDF generated does not include the image I have (logo), where if I generate it directly the the HtmlToPdfConverter test page it does.

In summary:
/running/HtmlToPdfConverter has:
wkhtmltoimage.exe
wkhtmltopdf.exe
wkhtmltox.dll

Whereas the eSpace referencing HtmlToPdfConverter has only the .exe files:
wkhtmltoimage.exe
wkhtmltopdf.exe

Do you know why the .dll is not being deployed (it is set to deploy to target) and is there another reason you can think of that the logo is not included in the PDF?

Thanks,
Owain

Hi Owain,

Just a quick question after you publishing the Html2Pdf 1.0.8 did you republish the consumers?

Cheers,
Guilherme
Hi Guilherme,

Yes I republished the consumers.

Owain
Hi Owain, I can't really guess the cause but you might try to look for a few clues doing the following: 1. From each of your farm frontends try to access the url you are trying to print. Did any of those replicate the behavior you mentioned with the logo? 2. Is the dll file missing on all frontend server directories? 3. In Service Center eSpace page you can "redeploy" your eSpace. Please try again and watch your server directories contents. Also take a look at /shared folder. Let us know your findings, Pedro
Hi Pedro,

I can access HtmlToPdfConverter from both front-end servers and they both work correctly. In the eSpace referencing it I can access from both front-end servers and they both product the PDF without the image.

As I mention above the HtmlToPdfConverter eSpace has the .dll, but the others do not.  I tried reploying and it has the same result.  The timestamp of the files is the time of the redeploy so it definitely updated.

I'm not sure what /shared folder you are referring to, I see a /Platform Server/share/ folder and it is empty.

Owain
What I ended up doing is exposing the public function HtmlToPdfConverter as a internal access Web Service and it works correctly as the work is done by the HtmlToPdfConverter eSpace directly.

This is not an ideal setup, but it works.

Owain
...so, was it network related, perhaps? Anyway, glad you made it. Thanks for sharing, Owain!
Hi Owain,

Thanks for the info and glad you woked it out.

If you're still willing to make the other approach work (v 1.0.8) next week we can work a small slot for me to do a remote call with you and assist you.

Just let me know.

Cheers,
Guilherme
Hi Guilherme,

Looking at your eSpace code it makes sense. The only issue is that we have multiple front-ends in Production only so it is difficult to test the eSpace reference issue because I don't want to do anything disruptive.

I don't know about next week, but maybe remind me in the week after and we can do some kind of debugging session.

Thanks for your assistance,

Owain