Welcome to a new feature on my blog called “PM on Call”. So why this feature? I am a big fan of Gary Vaynerchuk and he has a saying “Document, don’t create”. The idea being is that people can surcome to paralysis by analysis by always trying to think of clever ways to create good content. But, what better way to create good content, than to make it real! And that, is the focus of this feature.
Microsoft has been transparent about how it uses DevOps internally. In the words of Application Development Manager, Justin Wendlandt: The reason why DevOps is a focus for most companies today is because of the complexity in orchestrating tasks between developers, infrastructure engineers and operations teams. That pain used to be absorbed by organizations “throwing it over the wall” and making it someone else’s problem. In a healthy DevOps organization, it becomes everyone’s problem.
Within this spirit, the PMs on the Microsoft Flow team go through a daily on-call rotation which has multiple benefits:
- Gets us closer to the problems that both internal and external customers are facing.
- Allows us to understand some of the challenges that our engineering team are encountering so that we can design experiences that both delight our customers and increase operational efficiencies when developing the product.
- Forces PMs to get out of Ivory Towers
The purpose of this series on my blog is to share some of the challenges that we encounter as PMs and share the resolution with a broader audience. While there may be some internal use cases that can’t be described here, where possible, I will share these solutions (without exposing customer data) in an effort to scale this knowledge. Chances are, if another customer (internal or external) is struggling with a problem, others will as well. And what better opportuintiy to “Document, don’t create” than sharing real-world knowledge with the Flow community.
A recent request that I encountered was a customer who was receiving a JSON file, via email attachment, but could not parse the data and insert the data into a database, more specifically the Common Data Service. The original flow looked like the following:
- First, we start with an email trigger.
- Next we set up a Parse Json action and add a sample of our JSON data
- When we select an output from previous steps, we want to select our Attachment Content. As a result, an Apply to each loop will be added since there is a possibility more than 1 attachment may exist.
- Let’s now send in a sample email to see if we can successfully parse the data.
- When the email is received and we try to parse the JSON attachment, we get the following error: InvalidJSON. The ‘content’ property of actions of type ‘ParseJson’ must be valid JSON.
- If we look at the documentation for the Outlook Connector, we will discover that our Content property is of type byte. But, when we try to parse the JSON in our Parse JSON action, it is expecting JSON.
- In order to address this problem we will use an expression to perform a conversion for us. The solution is to use base64ToString(item()?[‘ContentBytes’]) expression. In case you are asking yourself, what is base64? It is “a group of similar binary-to-text encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation.” By specifying item()?[‘ContentBytes’] we are instructing the Logic Apps engine to get the current item in our attachment array and retrieve the ContentBytes property (the raw data of our attachment) and pass it into the base64ToString expression.
- If we resubmit our original email message, we will now have a positive result and can successfully parse our JSON. We can then use it in downstream actions to update databases, or whatever system we want to connect to.
- Now, if you return back to the expression, you may notice that the base64ToString expression is missing and you only see “Content”. Rest assured the statement is still there. If you export your Flow and look at the underlying JSON, you will see it there.
- This issue has been reported to our engineering team.
I hope you enjoyed the first installment of PM on Call. While the cadence will not be fixed, I will do my best to update my blog with more solutions whenever possible.