InfoPath Dev

Hi,

I have an xsn published as a content type to SharePoint - with 1700 documents in use.  The same xsn is used by dbxl although the "URL to form template" in the dbxl document type points the the Qdabrawebservice copy (I can't remember if it has always been set this way)

On Friday I published an upgrade to the xsn both sharepoint content type and dbxl (I haven't done this for about 4 months but has worked before.) 
I also updated a weekly job which opens some of the xml documents, checks their content and re-submits them - this ran over the weekend.

Now the documents which I opened with the weekly job are no longer linked to the correct template in sharepoint.  I have managed to re-link the documents in SharePoint so they are now working.  But I don't know why I have had this problem - it shows I don't really understand how this stuff works.

returnValue = Me.Application.XmlForms.Open(fileLocation, behavior) command

previously the file location I used was http://........../ARK/ARKDocuments/xxx.xml  - ie the sharepoint address

in the latest update I used http://......./QdabraWebService/Documents/xxx/xxx.xml - ie. the dbxl address.

Should this have caused the files saved to be "unlinked" ?  (I have subsequently tried opening just one file from dbxl and I get the same issue.)

How does the template.xsn get set/re-set ?

Hi Catharine,

I'm not exactly sure if you are referring to the address used to open the form from a button/link on your SharePoint page, or if you are talking about the href attribute stored at the top of your InfoPath form's XML (in the processing instruction).

1. If you are referring to an open link (i.e. the address used to open the form from a button or link on a SharePoint web page):
• DBXL stores the XML in your database and saves a copy to SharePoint to enable opening in the browser or workflows, since SharePoint must have a SharePoint copy to allow you to display contents in the browser or execute workflows.
• You can use either link to correctly open the form from the rich client. However, opening the form from SharePoint using the browser will likely require the first address, i.e. the "SharePoint address" you used previously.
• If you are using SharePoint Workflows, I don't think it would care about the file location since it doesn't actually open the forms in InfoPath.
2. If you are talking about the href attribute in the XML file's processing instruction:
• I believe this should point to the form template's location, i.e. the XSN not the XML file.
• This XSN path should point to the QdabraWebService/forms/.../template.xsn location 

Perhaps I am still confused. When you say "unlinked" what is the behavior that has regressed? Is it the icon with which the form is showing in the SharePoint library or is it the inability to open in the browser, or is it merely the fact that the form shows status of unlinked? If you can provide more details that will help me understand the issue better.

Best regards,

I think I mean the Href....my investigations never show it being QdabraWebService/forms/.../template.xsn location.

As a first point.  My users don't know anything about DBXL - their interface is via sharepoint - I can't see this changing.

I have published my xsn as a content type to the location  http://......../.../ARK/ARKContentTypeLibrary/ARKForm.xsn.  I have also attached that published file to the dbxl document type.

In the sharepointlibrary when a user selects new, the document template which is opened is my published form.  When the form is submitted, the xml gets submitted to dbxl and the document is copied to the sharepoint library (using dbxl.)

The user subsequently edits the form by clicking on the document icon/title in sharepoint and all is well.

If however I (as admin) open the document from dbxl (i.e. going to the document tab and clicking open on any of the listed documents /or by using the http://......./QdabraWebService/Documents/xxx/xxx.xml address) and submit, the xml gets submitted to dbxl and the document is copied to the sharepoint library BUT.... the form can no longer be opened by clicking on the document icon in sharepoint. 

When I have investigated the form is no longer linked to http://......../.../ARK/ARKContentTypeLibrary/ARKForm.xsn but is linked to http://......../.../ARK/ARKDocuments/Forms/Template.xsn which does not exist (and never has).  The href has been changed.

In the DBXL doc type the field on the general tab called URL to form template shows http://......./QdabraWebService/Forms/ARKForm/template.xsn

So I don't know where the http://......../.../ARK/ARKDocuments/Forms/Template.xsn is coming from.

I can 'fix' the problem. But would like to be able to edit the xmls from SharePoint or dbxl without issue.  And I would like to understand if this is a 'feature' or what I have done  wrong.

I have included a montage of  screen shots to try and document what I have described - to try and make it clearer.

Hi Catharine,

Thanks for the additional information. Now that we understand that this is DBXL-related, I wanted to ask for more information, but if you want you can email support directly. I think we need to look at two things:

1. How does the form submit? As you know forms can submit to DBXL or they can submit directly to SharePoint.

2. Do you have a SharePoint mapping in your doctype? If so, please send us a screenshot of that DAT tab.

I'll move this to the DBXL forum.

Hi Catharine,

We are going to reverify Content Types for this tonight. If it's fixed in DBXL 2.4 we will figure out what the change was and give you steps to workaround the issue. If it's not fixed, we will debug it and try to figure out a way to work around the issue you're having. The other option would be to use DBXL 2.4 and the new side-by-side option which simplifies the integration since there is no mapping. Forms are saved to SharePoint and DBXL in a two-step/rule submit process.

More soon,

Hi Catharine,

We've come up with a fix for the issue you're having and it's documented here. Basically, the latest DBXL v2.4 now has a "Content Type" option in the SharePoint mapping tab. You should be able to quickly map your content type using that option by following the steps in the blog. 

You may download the latest DBXL v2.4 to update your version.

Let us know if you have any questions.

Regards,

I have just experienced the exact same issue with an SP2010 implementation and we are running DBXL v2.4.  When I open the XML file from the DBXL Admin Tool the XSN location clearly points to the location on the Qdabrawebservice.  When I open the version published on SharePoint, the XSN location has changed to be the default template (template.xsn) for that form library.  If I remove the standard template document type, the system asks whether I'd like to redirect to the correct one ... I have four content types linked to the same form library using the methods shown elsewhere on the site, but I do not see a Content Type check box in my SharePoint mappings tab.  Does this feature appear in a later version of V2.4, as we are running 2.4.3875.239?

What's happening?

Hi Ged,

I see you re-downloaded DBXL 2.4 (latest version) after you posted this.  Can you confirm if that fixes this issue for you?

Thanks!

Ted

Hi Ted,

Will let you know once I've deployed the latest version onto my test system.  Assuming that appears, then will put it into production.  I'm hopeful this will solve it, as it definitely appears to be a content types issue - somehow the forms are mapping to the template.xsn file even where this doesn't exist.  Sometimes it asks whether I'd like to redirect to what should be the correct content type and other times it doesn't open anything and complains it cannot access the resource.

Hope that this can be rectified, as there's at least one additional project that I'm looking to use DBXL on, as it usually works fantastically well.

Ged

Hi Ted,

I can now access the Content Types functionality, but need to test it on the live system on Monday.  I have a separate live system on the University network which I might have a go at this weekend just as practice for the clinical one.

Ged

Thanks Ged, please let us know if you run into any issues.

Ted

Hi Ted,

Didn't resolve the issue on the live system.  When trying to add a document via SharePoint the system complains that it cannot find the document type.  However, I can successfully create a new document using the DBXLAdmin interface, open it via SharePoint and submit a revised version.

Ged

Quick update.  The issue that was affecting a single set of forms and form library is now affecting all of the forms with the following error:

InfoPath cannot submit the form.
An error occurred while the form was being submitted.
The SOAP response indicates that an error occurred on the server:

System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.Exception: Exception Code: I0001
Exception Message: No DocumentType found for ''.

   at Qdabra.Dbxl.WebService.DbxlDocumentServiceEx.CheckAndThrowException(StatusInfo info)
   at Qdabra.Dbxl.WebService.DbxlDocumentServiceEx.SubmitDocument(String docTypeName, String xml, String name, String author, String description, Int32& docId, String& refId)
   --- End of inner exception stack trace ---

The system seems to have lost the configuration settings for the documents, as I can now no longer access document information in DAT.  I have therefore converted a set of test documents from the configuration that I cannot read to a new configuration and it's those that are producing the errors above.

Ged

I only get this message if the template file is not saved as the template.xsn.  Check the box in DAT to publish library and XSN and it all works fine.  However, I have a form library with four content types and hence I can't always engineer this.

Any suggestions?

Hi Ged,

I'm going to update our support ticket on this, but I wanted to make sure you've been directed to this document.

http://www.infopathdev.com/files/folders/sharepoint_integration/entry60330.aspx

It covers how to use the new Content Types feature in DBXL.

More soon. Thanks.