InfoPath Dev

Hi,

We're very excited to be have the SaveToSharePoint command at our disposal now, but we have a scenario where we would also like to update some metadata on the uploaded document. We have figured out how to update columns in another list via Infopath, but our trouble with files is that we can't actually go out and get a Library reference to the uploaded document. Even though we know the file name, we can't actually query on it because SharePoint doesn't expose the file name column.

We've tried to create an event handler in SharePoint that will automatically update the Title column on create, but we're struggling with it not firing when files are uploaded with the Web Service.

So - I thought I'd find out if there was something I'm missing in qRules to set metadata in a document library at upload time - or if there was a way to get back a reference to the newly created document in SharePoint.

Again, any ideas are greatly appreciated.

Thanks

Dan

 Hi Dan-

The command's default functionality is that it will return the filename and URL to the corresponding attributes (see Appendix C of the User Guide).

Perhaps I'm misunderstanding the question, but this provides you the file's URL, so you can reference it as needed. Does this work for you?

Unfortunately, within InfoPath, I don't see a way to use that URL value to find the document in the Library so that I can update additional columns. However, if the SaveToSharePoint command were to also return the ID field, then I could very simply query the list to find the document that needs updating.

Here are our steps

1. Save attachment to SharePoint with SaveToSharePoint command
2. Get back FileName and URL as strings (receiving the ID back would make the problem go away)
3. Query SharePoint library for newly created item in InfoPath using rules (this is the roadblock we can't pass)
4. Update additional columns on the document

Definitely let me know if there is something simple (or even complex) I can do with the URL so that I can update the additional columns on the SharePoint library.

Thanks

Dan

Hi Dan,

Thanks for the info.

Sorry, there's nothing inherent in qRules to achieve this functionality.

If the FileName is unique (I assume it must be) couldn't the form use that to query the library and find the newly created item?

 

Hi!

I think you can get the ID back using the URL if you use FilterOwssvr or REST - are you using ShP & IP 2010? or 2007?

ErnestoM:

Hi Dan,

Thanks for the info.

Sorry, there's nothing inherent in qRules to achieve this functionality.

If the FileName is unique (I assume it must be) couldn't the form use that to query the library and find the newly created item?

 

That's the SharePoint conundrum. Oddly enough, you can't query a library based on the filename, nor the URL. SharePoint don't expose those as searchable columns. I'm sure there's a technical reason, but it's extremely limiting.

Hilary Stoupa:

Hi!

I think you can get the ID back using the URL if you use FilterOwssvr or REST - are you using ShP & IP 2010? or 2007?

We're using 2010 for both. I'll investigate that as an option.

Thanks
Dan

So, since you are using 2010, you should be able to create a REST data connection to the owssvr.dll. And then for your filter field, use whatever column returns the link - I usually start with Query=* to get back everything. Try the URL in the browser first - probably look something like this:

http://qshp2010/nw/_vti_bin/owssvr.dll?Cmd=Display&List={6e986be0-f112-4f61-8931-c1891e239e74}&XMLDATA=TRUE&noredirect=true&Query=*

but with your server & List GUID, of course. When I try this with a document library, one of the columns is ows_ServerUrl - that has the unencoded URL, starting at "nw" from the link above (so, doesn't include the server). Without checking, I don't recall if the URL returned by qRules is encoded or not - if it is, there is ows_EncodedAbsUrl. There is also ows_LinkFileName - you could just query on the filename. You'd create your REST data connection using the owssvr.dll link, and not query on load, but add an action to include the filter field and value:

concat("http://qshp2010/nw/_vti_bin/owssvr.dll?Cmd=Display&List={470bd7fc-c33a-4899-a83c-fa6b6bd87092}&XMLDATA=TRUE&noredirect=true&Query=*&FilterField1=LinkFilename&FilterValue1=", qRulesFilename)

for example...

 Hi Hilary,

Good day. Previously in SharePoint 2010, I had implemented the owssvr.dll connection and it is working fine. We did migrate to SharePoint 2016 and now it is now working to get the ows_ID. I have all the rules in a single button and the sequence is extract the attachment, set extension then query owssvr.dll. On the query is where the issue is happening, it is clearing values on the form that had been set before. attach is the rules. Thanks in advance.

I am going to guess there is an issue with Owssvr.dll. If you take a new form, no qRules or code, and add an owssvr.dll data connection, and publish it to the browser, does the data connection query without error? If there is an error, what's in the SharePoint logs?

Hi Hilary,

Good day. Thanks for pointing me to the right direction. I figure out the issue here. Initially I did create a form from scratch. The REST DC is working when I preview on local machine. When publish to sharepoint, it is having 5566 error which I expect because we are on SP2016 which uses claims authentication. Then I convert the REST DC to a UDCX file. The key is the  Secure Store Service in Central Admin for the target application ID to be use in the UDCX. Initially I'm mapping domain users to SPadmin account and that is not working. I did try to map domain users to farm admin account (DB account) and this work. Sharing this to the forum so that who ever has the same issue will find a solution.

Just on the Admin and farm account, just want to inquire the specific permission that is needed to execute this command owssvr.dll?Cmd=Display&List={0F53733B-86E6-4925-B3B5-526FBA058605}&XMLDATA=TRUE&noredirect=true&Query=*, it does not work using admin account and works when using farm account. Thanks once again Hilary.

 

Regards,

Rommel

Thanks so much for posting a follow up!