import("some.xml") and export("somechanged.xml", false)

[Former Community Member]

I need to get these methods working with Reader so that on some form event like formReady, embedded JavaScript will populate the PDF from an XML data file using import() without user intervention. If the user has modified any form data then we want JavaScript to export the changed XML data on formClose.



We need these methods to work when the workstation is disconnected from any network too, so [submit] button alternatives are not acceptable. I could write a lightweight HTTP server to deal with this, but we prefer not to. We already have our own network synchronization layer that will move the XML files to and from the back-office when network connectivity is restored.



I have certified the PDF and added Reader Extensions using the LC server API's. However, when I load the form with Reader the formReady import() doesn't do anything. To prove the XML and the data connection aspect of the PDF is working properly, I added a button that calls the import() method without any arguments, which presents a file dialog so the user can locate and load the XML data file manually, which works fine. But this is not an acceptable requirement for our intended application.



My specific questions at this point are:



1) Is there anyway to troubleshoot why the import() doesn't work, log files, Windows Event logs, etc?



2) Should these import/export methods work in Designer ES preview mode?



3) Is there something else needed in the credential definition besides checking Certification and Reader Extensions in the LC Sever->Admin->Settings->Local Certificate dialog?



4) What Java object "UsageRights" flags need to be set/enabled (I've enabled all of them, but want to know which ones are actually required) for these import/export JavaScripts to work without user intervention, assuming the Certification is sufficient?



5) Can the proper certification and reader extensions be applied using Acrobat Pro instead of using the LC Server API's? Our form volume is sufficiently low that manually applying these settings may be acceptable.



I think I've looked at and tried everything I could think of and feel like I'm pretty much stuck here and need some help. thanks - eric

[Former Community Member]

eric kanitz,



I'm sorry this is causing you so much frustration. Unfortunately, I don't think I bare good news: The issue with the import and export methods is that they're locked down in Acrobat/Reader for security reasons. Acrobat/Reader cannot allow an arbitrary PDF form to access a user's system without their knowledge and explicit permission (hence why using the import method with a filename does nothing and you're required to use it without any parameters in order to prompt the user).



This is documented on all the "import*" and "export*" methods of the Doc object in the
JavaScript for Acrobat API Reference (I believe the xfa.host.importData method executes in the same security context).



According to page 32 of the same document, these methods may take a file path parameter only when executing in a privileged context which would imply, for example, that the call to import/export is executed within a trusted application function.



In conclusion, I don't believe you can import/export data on a user's hard drive without user intervention from a simple PDF form. If you could support a connected scenario, then you could use a web service to retrieve and post the form data but then the user would still have to be prompted by Acrobat/Reader in order to allow the form to communicate with the web service URL (again, for similar security reasons).



As for your questions, should you implement something to execute these methods in a privileged context, it should work in Designer's Preview Mode.



Stefan

Adobe Systems



More answers at
Stefan Cameron on Forms.

[Former Community Member]

Stefan, thank you very much for the comprehensive response. I have read those sections in the script API reference and tried wrapping the xfa.host.importData() methods in a trusted function and calling it from there as well and not having much success either Designer ES or Reader. At this point I'm more inclined to think we have indeed hit a wall here, at least with the particular way we're trying to use the product, which is unfortunate because we are very impressed with all the other aspects of LiveCycle ES like the Designer and Server API's. I've been contacted by Adobe Product Management and we're setting up a conference call to discuss these issues as well as our application requirements. Hopefully we'll arrive at a workable solution. - eric