3 Replies Latest reply on Mar 15, 2010 7:11 PM by ToddAreva

    document variable as input in webservice:

    kc_chaitu Level 2

      Hi,

        I have a process which works absolutely fine if I invoke it from Livecycle. It takes the document as input and decodes the barcode data and gives it as output. I tried to expose this process as a webservice. When we tried to call this webservice through external application, and giving a tiff image as input,

      it generates premature end of file exception.

       

      Do we need to make any changes to the input variable type (initially given as type document) or any specific settings to make this work through web service calls?

       

      Please help.

       

      Thanks,

      kc

        • 1. Re: document variable as input in webservice:
          kc_chaitu Level 2

          Can anyone help me on this?

           

          Thanks

          kc

          • 2. Re: document variable as input in webservice:
            DavidMcDivitt

            If you save the bar code image as a file and reference as a remote URL

            in the request XML, it should work. What can be put in the request XML is very limited. The best thing I've found is to use remote URLs for pulling in data.

            • 3. Re: document variable as input in webservice:
              ToddAreva

              How big is the input file?  We found that files greater than about 20 megabytes caused issues in our Weblogic + LiveCycle environment when calling as a WSDL endpoint.  We modified the calling application to write the file to a temporary location (file share) on the LiveCycle server and then sending the file's location as a string parameter instead as a document parameter.  When you send a file/document as a parameter, the resulting SOAP envelope becomes grossly inflated.

               

              I'm probably mis-stating a few things, but it appeared to us that the process activities did not wait/block for the file to be completely written before the input files were loaded to disk.  We have experience numerous cases of asynchronous I/O that resulted in the refactoring of a simple process to account for larger input files.