Sending email with inline images via MicrosoftGraph and MicrosoftFlow

/

I had previously written how we can use Send Email as Anyone in Microsoft Graph, and as a bonus wrote a section on how we can use it to send inline images.

There was a small problem - sending email is very hard for app-only permissions - app accounts don’t have email boxes. So for that scenario to work, app accounts need a super crazy “send email as anyone” permission.

Sending email is a lot easier with delegate permission - if we have delegate permission Mail.Send - we can send inline attachments very easily. This is not an admin-tenant approval required permission, so any user can grant this.

Plan

Combine two techniques:

To aad.portal.azure.com

Add Mail.Send (delegate permission)

If you can “grant permissions” to your tenant, doing it here will immediately grant this to your current connection.

Otherwise we have to go back to our Flow connectors and make a new connection for batch.

Create our Flow

Here we are creating a MSGraph mail object JSON getting it ready for send

Using a $batch connector - call /me/sendMail

Results

Inline images are super useful for newsletter or emails where you want to include a nice header, signature or whatever in-between. This is a way to send these with Microsoft Graph and Microsoft Flow.

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) {
        // https://support.microsoft.com/en-us/help/892730/how-to-encode-and-decode-a-file-attachment-programmatically-by-using-v
        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"
        };
    }
    context.done();
};


The InfoPath form


The Microsoft Flow that coordinates the work


Results

  • 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!

Hiding your Microsoft Flow valuables I mean variables out of sight

/
Photo by Annie Spratt on Unsplash

Photo by Annie Spratt on Unsplash

Today is a quick #FlowNinja post on a strange technique.

Hiding Microsoft Flow valuables I mean variables out of sight

Yes, a very ninja technique.


This is actually an article about how to use tracked properties in the current Flow. But of course that’s the boring side to this. The fun side is how we can attach properties, like having a utility property bag and store properties as we go along!

Start with three compose (I guess we only need two really)

The expression give us the trackedProperties dictionary off the first action

actions('vars')?['trackedProperties']
// vars is the name of the first Compose action

Toggle to the … settings for the first action - that’s where different tracked properties are defined. We can use expressions if prefixed with the “@…” syntax, or define literal strings or numbers or even nested JSON objects.

What could we use Tracked Properties for?

  • Well, hide things that we don’t want to show - like the back of an envelope.

  • Unfortunately, an action can’t reference itself, so we can’t hide secrets that the action itself needs on the back of itself.

  • Tracking time between two actions - calculating the time difference between approvals can be useful.

  • https://flowstudio.app can ‘see’ tracked property values in the detailed Flow Runs - but there are no UI to display this for now. One idea is to use this to surface data within the Flow run that can be observed at the Runs level - like the Trigger URL or List Item ID of the runs, and allowing sorting on them. Powerful ideas but difficult to build an UI for. Let me know if you are keen about how this works below.

Flow Studio has a new logo

/

Flow Studio https://flowstudio.app has a new logo!

flow-studio-logo-216.png


I don’t know why I’m so happy about this, but I am.

Did you draw that John - yes on the back of an envelope. Literally. Flow Studio is a start-up that does things the hipster way.

It was digitized by the amazingly talented logo designer people on Fiverr. It is beautiful and very affordable. It was finalized within 24hours of the envelope sketch. No revisions were requested.

The colours have very specific meanings. I’m sure you’ll recognize them immediately.

The logo appeared on Flow Studio in v0.1.47 but will make more appearance in v0.1.48 with the subscriptions implementation.

Microsoft Flow HTTP Trigger <> Request Trigger, and you probably don't want to use it

/

Microsoft Flow has a fairly good UI update today, and with this a few “hidden” built-in triggers appeared.

The GeoFence Trigger is not available yet. But the HTTP Trigger is, and I wanted to write this blog post to explain how it works, and more importantly, why you probably don’t want to use this trigger.


HTTP trigger

Create this, the trigger calls the football API, it fetches back data…

The HTTP trigger is not a “new” trigger - it is something that’s in LogicApps for sometime. In essence, it is a polling trigger. So is this a run-once? Does it run many times? The answer is in the definition.


The Definition

https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-workflow-actions-triggers#http-trigger

The definition specifies

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "<method-type>",
      "uri": "<endpoint-URL>",
      "headers": { "<header-content>" },
      "body": "<body-content>",
      "authentication": { "<authentication-method>" },
      "retryPolicy": { "<retry-behavior>" },
      "queries": "<query-parameters>"
   },
   "recurrence": {
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>
   },
   "runtimeConfiguration": {
      "concurrency": {
         "runs": <max-runs>,
         "maximumWaitingRuns": <max-runs-queue>
      }
   },
   "operationOptions": "<operation-option>"
}

But the designer for HTTP trigger does not let us specify the recurrence pattern for this trigger. So it ends up on the default, which is polling at 1 per minute.

That’s probably a really aggressive way to use up your Flow runs :-)

Summary

Four recommendations / notes:

  • Use a Schedule Recurrence trigger to specify what time and frequency we want our polling to run, then call HTTP as an action

  • Wait for a UI update that let us set up the recurrence trigger

  • Use FlowStudio to patch the JSON definition like a hacker. In a future FlowStudio update we will warn when these type of high-run Flows are created in the tenant unintentionally.

  • The Request Trigger turns a Flow into a web service. A HTTP trigger does not accept any requests, having both triggers now in Flow makes describing the correct trigger in text and blogs slightly tricker.