Decode InfoPath attachments with a bit of JS AzureFunctions

Serge, April and me were discussing a problem with pulling out InfoPath Attachment from InfoPath form XML and writing them into a SharePoint document library.

This is a problem I tried to tackle before, but came to realization that I would need an AzureFunction. The main reason is that the InfoPath attachment is a base 64 byte array but the byte array has a variable length header that includes the attachment file name. Flow doesn’t have amazing byte manipulation or left-shift abilities. So we need to write an AzureFunction to help.

As I brood over the problem I also thought it might be easier to handle the byte array with JavaScript. So I gave it a go.

This blog is my version of the answer.

The original decoder code in C#

There is a pretty old MSDN article on the C# code

private void DecodeAttachment(BinaryReader theReader)
  //Position the reader to get the file size.
  byte[] headerData = new byte[FIXED_HEADER];
  headerData = theReader.ReadBytes(headerData.Length);

  fileSize = (int)theReader.ReadUInt32();
  attachmentNameLength = (int)theReader.ReadUInt32() * 2;

  byte[] fileNameBytes = theReader.ReadBytes(attachmentNameLength);
  //InfoPath uses UTF8 encoding.
  Encoding enc = Encoding.Unicode;
  attachmentName = enc.GetString(fileNameBytes, 0, attachmentNameLength - 2);
  decodedAttachment = theReader.ReadBytes(fileSize);

The updated code in JS AzureFunctions

module.exports = function (context, req) {
    context.log('JavaScript HTTP trigger function processed a request.');
    if (req.body && req.body.file) {
        var buffer = Buffer.from(req.body.file, 'base64')
        //var header = buffer.slice(0, 16);  // unused header
        var fileSize = buffer.readUInt32LE(16);  // test is 5923 bytes
        var fileNameLength = buffer.readUInt32LE(20);  // test is 13 chars
        // article lies - it's utf16 now
        var fileName = buffer.toString('utf16le', 24, (fileNameLength-1)*4 -1);  
        var binary = buffer.slice(24 + fileNameLength * 2);
        context.res = {
            // status: 200, /* Defaults to 200 */            
            body: {
                fileName: fileName,
                fileNameLength: fileNameLength,
                fileSize: fileSize,
                fileContent: binary.toString('base64')
    else {
        context.res = {
            status: 400,
            body: "Please pass a base64 file in the request body"

The InfoPath form

The Microsoft Flow that coordinates the work


  • Need Azure Function here

  • JavaScript buffer is pretty good at doing byte decoding, easy to read too

  • Debugging and tweaking the byte offset is quite a bit of trial and error, was not expecting that. May be that MSDN article is too old, it is from 2003.

  • You may think - John 2018 is not the right year, or decade to be writing about InfoPath. But hear me out. As companies move their form technology forward, they will need to consider how to migrate the data and attachments in their current InfoPath forms somewhere - having this blog post as a reference is important for that eventual migration. Good luck!

Microsoft Flow makes everything Awesome. Yes, including InfoPath #microblog

This is a write up of various ideas and thoughts that I've shared over Twitter separately, but needed to be linked together and the example steps needs to be explained in a bit more detail.


On Reading many XML Forms in a Forms Library

Crazy InfoPath and PowerApps cross-app idea

with game state managed with Microsoft Flow, with JSON and XML dual binding.

API Management TIP

from @darrenjrobinson

Flow Details

In this Flow, we will do something fancy.  We will use the new Flow Management connector to list all the Flows in my environment.

Configure the HTTP Request method must be GET
The response must be XML - use xml() to convert JSON into XML output.

Check this in Postman

This is how you test a webservice.  You poke it with Postman.

check in postman.png

See this returns XML.

The rest is done in InfoPath

Connect it via REST connection.


This is pretty amazing.  InfoPath is listing in a repeating section the names of all the Flows I have in my environment.


  • Because of Flow, InfoPath got server side superpowers it never had
  • Flow gain the ability to work with Managed Metadata today.  And so did InfoPath.  Only 7 years after MMD was shipped without InfoPath support.

Flow is awesome.

InfoPath Javascript - fixing image control tooltip.

In a previous blog post I discussed using Picture Controls to host lots of images within InfoPath and manage the tooltip.

InfoPath FormServer renders picture buttons with a pop-up Picture Icon that will hide any alt-text that you've set on that picture.

The key is in the Core.js file, which you should NOT modify.  As this is what could happen if you modify core javascript files.

function LinkedPicture_OnMouseOver(a, c) {
    var b = ViewDataNode_GetViewDataNodeFromHtml(a),
        d = PictureControl_GetPrimaryDataNodeValue(b);

    /* This modification hides the picture icon when the control is disabled */
    var e = PictureControl_GetPicture(a);
    if (e && e.alt == "Picture") {
        e.alt = "";  e.title = "";
    if (typeof(a.disabled) != "undefined" && a.disabled) {
    /* end modification */

    a = PictureControl_EnsureControl(a);
    d != "" && PictureControl_ShowPictureIcon(a, b, true);
    LeafControl_OnMouseOver(a, c);
LinkedPicture.OnMouseOver = LinkedPicture_OnMouseOver;

So instead, you should create a separate webpart page, put the Form control on that page, and add this script override for the LinkedPicture_OnMouseOver function. 

The key is "if (a.disabled) return"

Then in your InfoPath form template, set the control to read-only will ensure the Picture icon doesn't appear on hover, allowing the title text on your image to show up on the browser.



Reading InfoPath template's default values in code


String xml = "";
FormTemplate template = this.Template;
using (Stream s = template.OpenFileFromPackage("template.xml"))
    XPathDocument reader = new XPathDocument(s);
    XPathNavigator nav = reader.CreateNavigator();
    XPathNavigator repeat = nav.SelectSingleNode("/my:myFields/my:Repeats/my:Repeat[1]", this.NamespaceManager);
    if (repeat == null)
    xml = tender.OuterXml;
if (!String.IsNullOrEmpty(xml))
    XPathNavigator destination = this.CreateNavigator().SelectSingleNode("/my:myFields/my:Repeats", this.NamespaceManager);


The top part of the code is particularly useful if you want to use the Default Values for repeating sections in InfoPath.  Your code will read the xml for the default values and insert them into the repeating section.  I've previously hardcoded these XML segments for insert, but that's extremely error prone when you inevitably update your XML template with new and more exciting child elements and attributes.

InfoPath's future and what everyone's saying



Andrew Connell

  • "the future is unclear at best, realistically pessimistic and a dead-end at worst"
  • "I do not use InfoPath any more & I do not recommend people use InfoPath going forward"


Mark Rackley


Corey Roth

  • Lists a great list of feature sets for the future Forms solution
  • Suggest: wait and see SPC348


Jeremy Thakes

  • "I  found that if  you used InfoPath in your Organization to empower Information Workers to build their own forms, a lot of the times they’d hit the 80/20 rule and then hand it off to developers who would have to fix them or complete them."
  • Suggest: ISV Nintex Forms



  • InfoPath is dead.
  • Long live Forms:


Patrick Halstead

I like Patrick's coverage the best, probably because this is his bread and butter.  He has been thinking about this and planning for a while. 

His upcoming webinar series will cover the various approaches to deal with the data that's currently in the forms:

  • Status Quo: keep same format (XML): Formotus, ServBus, Qdabra eForm Viewer
  • Hybrid (SharePoint List): move the form's data into SharePoint Lists, then use SharePoint list forms
  • Convert to ISV: Nintex, K2, Adobe, Salesforce
  • Custom development (database): extract data into database, then build pages and use full set of controls [After InfoPath: Planning your Form's Future] 


I say: Please Don't panic.

I'm waiting to see:

  • Qdabra eForm Viewer (cheap /  free / open source?  does the user need to do anything?)
  • Nintex Forms (roadmap, feature compatibility)
  • Microsoft's SPC348 (upgrade roadmap?  future support?  feature compatibility? could be the most expensive path)

I'm sure everyone will have a lot to say in time for the SharePoint Conference.  Stay tuned.