Please see my previous posts for how I got to this point:
http://www.capturedocs.com/thread/api-does-not-seem-to-be-able-to-detect-projects/
http://www.capturedocs.com/thread/addnewbatch-fails-with-generic-error-message/
http://www.capturedocs.com/thread/error-from-fileservice/
Now I successfully followed all 8 steps in the developer documentation to upload a file for scanning (discussion continues below the screenshot)
I was able to find the file in the file storage folder in a subfolder that represents the batch, so I know it uploaded successfully.
When I look at the log on the server, it shows that there are zero pages. See screenshot below:
I tried opening the verification station, and nothing comes up as available to verify. Here's a screenshot:
I also tried using the interactive scanning station to upload files to the same project. In that case, the log shows that there are pages, unlike when I uploaded through the api, but I still couldn't get the document to move to the verification stage or to show up on the verification station.
Comments
9 comments
Hello,
It seems, there is something wrong with your workflow setup.
At this point I need your FC project to reproduce the issue.Could you please upload it to the link below?
https://share.abbyy.com/index.php/s/FEzVxdzCrBSFUNR
I uploaded the project. Please let me know if you need any of the other files that are connected to the project.
It seens that you have uploaded only *.fcproj file
Please archive and upload ALL the files and folders that are in the same folder as Timesheet.fcproj file.
I uploaded the full folder.
Thank you,
I have had a look at your project. Please do the following:
1. In the Project Setup Station > Project > Image import profiles edit the profile "Load from Paradigm web" and on the Image preprocessing tab deselect the checkmark "Use image processing options from batch type" and set the options manually
2.On a General tab set the source as UNC path, for example "\\MachineName\import" so the machine with the processing station will have access to it regardless of where it is located
3. Please check that the processing station is up and running and that you have enough pages left in the license.
You can also check task log in the processing server monitor to see why your documents do not enter desired stage,
Please let me know if this has worked.
Thank you - the solution you gave helped me solve this issue. The main problem was that I had not set up the processing station in this setup. This original discussion was with a trial version. We have now purchased a full license and when I was going through the steps to set up the new server, I realized I left out the steps to set up the processing station. In the new setup I successfully set up the processing station, and it moved to the next step and attempted to process the document.
I got the following error in the event log: "Document 1: Could not load the source image 'manual1.pdf' for the document with ID '1' from the Application Server."
Then I followed your suggestions. Since the processing server and processing station are on virtual machines in Azure, I made the file share as an "Azure Files" share and followed Microsoft's instructions to make sure both the user ID of the processing server (Network Service) and the user ID of the processing station have access to the Azure Files share.
After all that I'm still getting the same error in the event log.
Because of your environment, this issue need deeper investigation on our side and the forum format does not allow it.
Please contact your regional support.
On further testing, I think the issue is just with the parameters I'm sending to the API. When I use the full desktop scanning station, I am able to get much further along in the process - all the way to document export. It even writes the pdfs to the "Azure Files" shared folder. It's only when I try using the API that I have this error.
I got it working! The solution was to encode the streamName parameter properly.
In php I needed to change it from:
'streamName' => base64_encode(basename($file)),
to:
'streamName' => base64_encode(mb_convert_encoding(basename($file), 'utf-16LE')),
See the previous post for the full PHP sample.
After I made the change the file was recognized and started being processed by the processing server.
Then everything fell apart.
See the next discussion for what happened next...
http://www.capturedocs.com/thread/flexicapture-distributed-iis-crashed-doesn-t-come-back-up-properly-after-reboot/
Please sign in to leave a comment.