Solved

Moving Infopath attachments to a SharePoint library

  • 3 January 2017
  • 9 replies
  • 181 views

Userlevel 7
Badge +17

In Nintex for SP2013/2016 in on-prem there is the action "Copy to SharePoint" which basically does the thing - it allows to copy attachments from particular XML nodes from Infopath form into a chosen SharePoint library.

In O365 there is no such thing.

 

I did some deeper analysis on the issue and realized, that:

  1. Infopath is storing attachments inside the XML file, converted to Base64 string;
  2. Infopath file cannot exceed 5MB in O365 otherwise it will not be saved…;
  3. The Base64 string does not only contain file contents, but according to the article: https://support.microsoft.com/en-us/kb/2517906 it does as well contain filename and some additional header information;
  4. There is no way to call javascript from Nintex Workflow (or is there any?). I thought, that maybe I can create a webpage with a javascript executed onload, however when reaching that page using “Web Request” action in Nintex (via the HTTP GET) it does not execute javascript code (what is understandable, as the HTTP GET request gets file contents from the server, not from the browser);
  5. Having failure there I then tried to create my own Content Type for Page Layout and was trying to inject there a C# script code block with the: ClientScript.RegisterClientScriptBlock function (so that my JavaScript could be executed while compiling the page), but in O365 code blocks are disallowed for pages as long as they are not provisioned by an add-in (sandbox model limitations). So again - failure..
  6. I can create a file using REST and SOAP web services, however I cannot cut off the header information from the Base64 string (as I don’t know where it ends), I cannot as well convert (decode) Base64 string to a binary (no such function, no available web service, etc…) without a custom code.
  7. It all leads me to a simple conclusion – in O365 I am not able to get Infopath attachments and store them in a given library folder. I have tried all options I could use. Nintex does not have it OOTB as it has in on-prem unfortunately - it should be done for example using the Remote Event Receiver (RER) that would be fired when a new Infopath form is submitted and that it does all the logic.

 

Has anyone got a similar problem? If so - how have you solved it?

 

Best regards,

Tomasz

icon

Best answer by TomaszPoszytek 14 January 2017, 02:27

View original

9 replies

Userlevel 6
Badge +13

I presume we're talking here about an Infopath Form Library rather than a SharePoint List with Infopath form?

Userlevel 7
Badge +17

exactly

Userlevel 6
Badge +13

I presume there's something like a repeating section that means you can't create this as a SharePoint List with an Infopath form instead then?

Userlevel 7
Badge +17

The most important thing why it is done this way, is that client was using that approach for years on his SP2010 env. and now decided to move to O365. I've made a PoC with SharePoint List, with attachments and Infopath form, together with REST copying the list attachments to a separate library - it works fine.

However the original form contains 3 separate sections for attachments, and when working with list item, you can have only one "attachment" section in the form. And there is no way (or at least I'm not familiar), how to workaround it

Regards,

Tomasz

Userlevel 6
Badge +13

At the risk of over-complicating the process, if the form has 3 sections, could it be broken into 3 forms?

In the past, for complicated processes that contained lots of data, we had created 3 content types in a list and created a separate Nintex form for each of them. Use an Identifier column (PK) to create a link between the 3 content types for one instance and this allows us to query the list to find the list item that corresponds to the current item.

ID   Content Type1   Content Type2   Content Type3

1      PK = 101

2                                 PK = 101

3                                                            PK = 101

Content Type 1 would be the first section and would allow you to have it's own attachment which could then be copied to a document library using web services and then Content Type 2 would be the second section and so forth.

3 separate items linked by a unique identifier in the same list.

I know this doesn't resolve your issue but it could be an approach to consider.

Userlevel 7
Badge +17

Ryan Greenaway, this is an interesting approach however I need those three sections in one form. And from I know this is not possible for a list - it has to be done as a custom infopath form as my client is doing already. After all the process is not complicated. Additional attachments' sections are just optional, to allow storage of some optional files.

Right now I'm briefing a developer to create a remote event receiver that will take the attachments out of the infopath, decode and upload to another library, but I'm still looking for an alternatives. And currently the most suitable one is to use a list, create a form for it in the infopath (but resigning from additional attachments), and then use Nintex "HTTP Request" action to move attachments from the list to a library using REST API.

Regards,

Tomasz

Userlevel 7
Badge +17

So maybe anyone has an idea how to execute a JavaScript code using Nintex actions? For ex. using HTTP Request?  

Userlevel 7
Badge +17

Right. So just to follow up the question with the answer:

  1. Nintex is not able to execute JavaScript, because to do so action should "simulate" browser or should call a method displaying data in browser view - what I suppose can have a significant impact on Nintex Solutions efficiency (as it has to be done as a Azure-Hosted App);
  2. Remote Event Receivers are a perfect solution for that. They just have to execute method (https://community.nintex.com/external-link.jspa?url=https%3A%2F%2Fsupport.microsoft.com%2Fen-us%2Fkb%2F2517906) to decode InfoPath base64 and upload decoded files to a particular library. It took my DEV team not more than 1 day to accomplish this, however this solution requires again Azure subscription, as RER has to be Azure-Hosted App.
  3. We also thought about WebHooks (https://dev.office.com/blogs/introducing-sharepoint-webhooks), however analysis of this new concept (although it seemed to be very attractive) also lead us to a conclusion, that in the end it has to be done as the Azure-Hosted App.
  4. JavaScript and usage of BytesArrays (ex. http://stackoverflow.com/questions/12332002/how-to-store-a-byte-array-in-javascript) was treated as a possible solution, but because of lack of possibilities to execute the script from Nintex Workflow (without calling web services from outside of the tenant) this idea was abandoned too

Because in my case client does not want to go into Azure subscription, we decided... err... to just resign from additional attachments' sections, create a LIST and redesign the form on the list. Then, when workflow runs, it just calls list REST API and uses "O365 Upload a file" to copy-paste attachment files to a particular library.

Regards,

Tomasz

Badge +5

Hi Tomasz, I hope you can help me out here.


I have a similiar problem like you have except that my customer wants so send the files attached to the infopath form via email when notifications are triggered.


 


Unfortunately I don't have the possibility to recreate the whole form in a SharePoint list and use list attachments like you did finally.


 


You post is quite a time ago now and I am wondering if you found a better solution now or if you can answer me the question if it is somehow possible with REST API to get the attachments from the form and decode them so they can be attached to the emails.


 


Thanks in advance for you help and I am looking forward hearing from you!

Reply