Recently Pedro, Sandro and myself had a chat about a problem I was trying to figure out and Pedro had previously used an approach for a similar problem which has told us about which could be adapted to my problem really well.
Pedro wrote about this on the below link, and I wanted to show how I used his approach to help me solve a problem which I will discuss further down this page.
In my scenario I had a Logic App solution in which I get a message, I then generate a word document from one of two different templates and I will then upload the generated word document to a SharePoint site and add a record in Dataverse so our users can access the document via CRM.
At the moment its just a choice between 2 templates but later it could be 6 or 7 templates.
What we found was that it is difficult to have a dynamic use of the wordonline connector to dynamically assign the template and parameters as you lose a lot of the designer support. Sergei on our team had implemented a good pattern where we encapsulate the logic for each document type within a child logic app. Each one took the same input message and it would use a specific template and return the blog created by the word connector for that document generated from the template. We would then have 1 child logic app per document type.
This meant the parent logic app could focus on the workflow of the generation process. It would get the data, decide which type of document to generate. Call the appropriate child logic app and get back a message with the word document and then save the document to SharePoint and upload a record into CRM for the user. It would look like the below.
The problem we have however is when you have called 2 different child logic apps in a condition and then after the condition you want to call SharePoint then how do you control which of the outputs you would pass to SharePoint. It wasnt as straightforward as Id like.
With each of the child Logic Apps you would get an encoded string and my instinct was to set them as a variable but then Logic Apps gets awkward with trying to help you deal with encoding and this means when you get to the SharePoint connector the file created is not valid.
Long story short what I ended up doing was to have a string variable after each child logic app in the condition where I set the variable to the $content property from the child Logic App response. It looks like the below:
The code snippet below for the set variable above shows how we are setting it to the $content property of the child logic app output.
{
"inputs": {
"name": "fileEncodedString",
"value": "@{body('Document_B')['$content']}"
}
}After the condition statement I would then use a compose action to create a message. This is the key part where I am setting the message content and content type explicitly so that I am in control of the content type and do not have Logic Apps over-help me.
When I now come to the SharePoint action I can just mass the output from the compose shape as the file content and the connector will get the right content and content type so that the file that is created will be valid.
I think this approach is really handy for scenarios where you want to reuse logic like this but you need to deal with various content type challenges. I can see it potentially helping a lot in scenarios where your messages are not xml or json in particular.
Anyway huge thanks to Pedro for the approach which made my life a lot easier here than having to have create file actions for every single file type which would have been a pain.
