InfoPath Dev

Hi Tom,

I'm sorry, but based on the information we have so far, I don't have any further suggestions.

I notice that you took Qdabra's Master Class and as a result have a complimentary hour of post-class support. You could use that hour towards this issue. If you're interested in pursuing that option, let us know via support at qdabra dot com. We'll create a support ticket and help to investigate further.

Thank you.

Revisiting this issue:

Server logging was dialed down previously, so the logs were difficult to find.  No so now.  Here's the error message I receive when trying to use a CheckOut UDC:

The following query failed: CheckOutFile (User: , Form Name: POCRequest, IP: , Connection Target: https://forms.corp.integris-health.com/eForms/eForms Data Connections/CheckOutFile.udcx, Request: , Form ID: urn:schemas-microsoft-com:office:infopath:POCRequest:-myXSD-2013-02-04T19-12-58 Type: DataAdapterException, Exception Message: The remote server returned an error: (500) Internal Server Error.  Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException' was thrown.  Invalid URI: The format of the URI could not be determined. The remote server returned an error: (500) Internal Server Error.)

The formula I'm using to set the form URL is this, in XPath format: concat(substring-before(substring-after(xdXDocument:get-DOM()/processing-instruction()[local-name(.) = "mso-infoPathSolution"], 'href="'), 'Forms/template.xsn"'), xdXDocument:get-DOM()/my:POCRequest/@my:Key, ".xml").

Any ideas?

Hi Tom,

I'm asking one of our Checkin-Checkout gurus to respond.

More soon,

Hi Patrick.  I've not received a response from anybody on this issue as yet.  I'm in need of it, as a form request that has a high potential of volume has been received, and I'm tasked to deliver by the beginning of next week at the latest.

Thanks.

 Can you temporarily put a calculated value on your form to make sure this formula is returning a correct & valid URL?

Thanks for the reply, Hilary.  I've got a test form to do an inline check out when an existing form is opened, with a check in as it's saved back to the library.  What has me puzzled however, is no matter who opens the existing form, it shows as checked out to me.  I'm assuming that a check out prevents other users from editing the form when somebody else has it?  In this case, if the system is interpreting the checkout as the same person, obviously that won't work.

I'm attaching the test form.  Could you take a look and see if you can tell what I'm doing wrong?  One other thing to note, the data connections are UDC files, if that makes a difference.  In the meantime, I'll test using plain data connections and see if my results are different.

 Thanks.

 I'm sorry, I don't know that your reply answers my initial question? I'd asked if this formula:

concat(substring-before(substring-after(xdXDocument:get-DOM()/processing-instruction()[local-name(.) = "mso-infoPathSolution"], 'href="'), 'Forms/template.xsn"'), xdXDocument:get-DOM()/my:POCRequest/@my:Key, ".xml")

That seemed to be part of your error, was returning a correct and valid URL? Can you check that with a calculated value please?

Yes, having the form checked out should prevent others from changing it. Do you still have the same issue you initially posted about? Or is the issue instead that your form is always checking the XML out to you, no matter who opens it?

Thanks, I know my answers can be a bit "fast forward" and I apologize.

Yes, I'm using the formula as you noted, and it's now retrieving the correct URL.  I wasn't populating when pulling the form from the library.

The issue now is the XML is always being checked out to me, even if somebody else opens.  So, in that case, the check out does no good, since SP is interpreting every user as me.  I'll check the UDC.

Any other thoughts?

 Yeah, I can't think of a reason why the web service connection would use your credentials unless there is something up with the UDC? Can you test with a form not using a UDC? Can you test in filler while signed in as different user to see if you have different results?

A couple of things, the UDC files were using a Secure Store Service to utilize a machine account.  This apparently was circumventing SP security, at least from identifying the current user.  I removed this for the check out and in UDC's and I'm now getting unique users on checkout.

I just found your blog on auto check out and in and am working through that, particularly the browser form part.  Annoying we don't get the same type of "love" from SP as the client.  Not so easy to see what's going on if another user opens.

I'll keep you posted, and thanks.

Ok, I think I've got it now.

 The piece I was missing was the data connection back to the library and pulling the Checked Out to property.  Once I had that in place, all kinds of things open up now.  I can correctly identify when it's checked out and who has it.

Thanks again.

Ok, new developments:

I tried applying the same methods using the same UDC files in another library and get different results.  Here's what I'm encountering:

1. The formula for the form URL returns correctly in the test form I generated.  However, in the production form I'm trying to duplicate this in, I get different results.  This formula, concat(substring-before(substring-after(xdXDocument:get-DOM()/processing-instruction()[local-name(.) = "mso-infoPathSolution"], 'href="'), 'Forms/template.xsn"'), xdXDocument:get-DOM()/my:POCRequest/@my:Key, ".xml"), returns only the unique form name correctly but not the full path.
2. In the test form, the path is https://<server>/eForms/<FormLibrary>/<uniqueName>.xml, again returned correctly by the formula.  In the production library, the path is https://<server>/eForms/Facilities/<FormLibrary>/<uniqueName>.xml.  Again, the formula only returns the name.
3. When I construct the correct path manually, concatenating the path to the extracted name, the form checks out to System Account instead of the individual.  In the test library and form, it checks out to the individual.  I'm using the same UDC files, which coincidentally live in the same path as the test library, https://<server>/eforms.  Do I need to duplicate the UDC's in the same production library path?  If so, I'd need to do that for EVERY form I wish to use this way?  Is there a simpler DBXL solution that's more accurate?

Thanks.

I changed the data connections to be relative to the site collection and am now getting the correct path, verified by a calculated field.  However, now I'm getting this error:

The following query failed: CheckOutFile (User: , Form Name: CapitalRequest, IP: , Connection Target: https://forms.corp.integris-health.com/eForms/Facilities/FacilitiesConnections/CheckOutFile.udcx, Request: , Form ID: urn:schemas-microsoft-com:office:infopath:CapitalRequest:-myXSD-2013-02-04T19-12-58 Type: DataAdapterException, Exception Message: The remote server returned an error: (500) Internal Server Error.  Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException' was thrown.  Invalid URI: The format of the URI could not be determined. The remote server returned an error: (500) Internal Server Error.)

I'm using the formula mentioned earlier, and this is what I'm getting, which maps to the specific form in the library: https://forms.corp.integris-health.com/eForms/Facilities/CapitalRequestReview/Capital_Request_IT_Web_and_Workflow_Automation_2013_10_08T13_08_59.xml

From what I can see, the form is constructed the same way as the test form earlier. 

 Looks like you are back to your earlier issue then - the same error you were getting initially. If you paste the URL in the browser, do you get a prompt to open or save the XML?

It loads the form and then throws the error again.