Salesforce <-> Lotus Notes Integration IO Error

Question

So I've reached the point where my web service call between our Salesforce instance and the client's Lotus Notes database should be working. We have calls to other LN Views that return data as expected.

For further background, we have a java web service that lives on the Lotus Notes Domino server. I am not able to determine which version of Domino server we are using but we're using Domino Designer 9.0 Social Edition. For Salesforce to access it we export a WSDL from Lotus Notes and have SF generate an Apex Class so that we can make function calls to that stub. We're also on the most recent release of Salesforce (pretty sure it's Winter 2014).

For this one view we're hitting a strange IO Exception inside SF. It claims that we have no data in that view. I've checked the View, it has plenty of records. I also have an if block that should return a hard coded string in cases where the view truly has no results. Here's the error message:

System.CalloutException: IO Exception: input contained no data:
Class.LaureateWS.Domino.batchClassDocQuery: line 102, column 1 
Class.LN_Connect.queryClassDocuments: line 668, column 1 
AnonymousBlock: line 2, column 1 
AnonymousBlock: line 2, column 1

I've tried digging through the documentation but nothing discusses this particular problem and everything I've found refers to old versions of Domino Designer. Any help someone can provide on this would be greatly appreciated.

Answer 1

It could be a security issue. If the documents contain reader fields, and if the effective ID that your web service runs under is not listed in those fields (directly, or as a member of a group or role), then the code in your web service will not see those documents.

Answer 2

So I realized the error we were running into was basically one of our own making. I edited the WSDL generated class to point to the correct server instead of the default localhost. However, I neglected to include the path to where the nsf lived on said server. Brilliant.

Answer 3

i also faced the same issue and later realized that it was deployment issue. for callout we were using named credentials and when migrated to higher environment password for the user was not migrated which was necessary for callout. later i had to manually update the named credentials. i hope this might help you.