Custom HTTP connector in Power automate to POST x-www-form-urlencoded data

Problem:  As part of my OAuth process I need to swap and authorisation code for an Access Token using an API, the issue is that I need to get the token into PowerApps.  

Initial Hypothesis:  Initially I created an Azure Function that does the API post as it was the easiest.  But I reverted and thought it must be easier for me to have fewer working parts and as my solution used Power Automate and I've previously used Power Automate with the HTTP custom connector I'd use the same approach.  It proved fairly tricky to get the HTTP connector to work but with some playing around and clarification of my thinking it became rather straight forward.

Firstly, I need to ensure the API is working, so I use Postman:

Postman POST request using form-urlencoded.

When I get the 200 response, I wanted to see the underlying HTTP traffic so I opened Fiddler:

Solution: From the raw HTTP trace, I realised I needed to post the body in Power Automate in the correct format.  Key value pairs for parameters and separate with an Ampersand.  Also, Url's need to be escaped/encodes, in C# there are functions to encode and decode.  I needed to do the encoding using Find() and Replace() methods (sic).  From Power Automate, I return the Access token, refresh token and other info back to Power Apps.

More Info:

Uri.UnescapeDataString(String) Method (System) | Microsoft Docs

Understanding HTML Form Encoding: URL Encoded and Multipart Forms - DEV Community

Enterprise Canvas App Development - Overview

Overview:   It is a good idea to have an agreed set of standards in an organisation and within the development teams.  Microsoft has Power App Canvas Coding standards and guidelines, use this as a base.

At a high level, the design and implementation needs to consider:

• Security,
• Usability,
• Performance,
• Maintainability & support, and
• Accessibility.

Governance:

• What connectors can the business use, 
• Groups of users (who can do what),
• Licencing,
• Enforcement of coding standards
• Monitoring & support

Also see: App Insights for Power Platform - Part 3 - Canvas App Logging (Instrumentation key)

WIP

<Add coding standards for Power Apps and Power Automate>

Dynamics 365 CE Intro

Overview: Dynamics 365 CE (Customer Engagement) is a subset of the Power Platform and Dataverse.  It provides commonly used entities such as Accounts and Contacts.  There are five apps that can add specific CRM functionality.  It is Microsoft's CRM solution.

There are 4 core subject (model) apps in Dynamics 365 CE

1. Sales (MB-210) - client management including leads and turning:
1.  leads (Qualify step) into an 
2.  opportunity (Develop step), goes to the 
3.  Proposal step consists of generating quote, revising quote, marking acceptance, and invoice, 
4. Order created/lost (Closed step).
2. Marketing (MB-220) - Lead generation & qualification, turn prospects in customers.  Build campaigns to market your business.  Email, social media, content creation to convert leads.  Ensure you target the right audience using the correct channels and breaking leads into segments.  I have only used this lightly and it is powerful.  Events are useful for planning such as speakers and managing leads/event analytics. Referred to as Dynamics 365 Marketing.  Customer Voice integrates with Marketing, e.g., embed survey sent our via email.
3. Customer Service (MB-230)/Customer support - Dynamics 365 Customer Service - Low tough Customer Experience(Cx) and it also provides for high tough as needs demand, provides omnichannel options, chatbot, email, SMS, service requests, wiki's, phone in.  Case management, raise record, route to where can be solved, and get to answer.
4. Field Service (MB-240) - Dynamics 365 Field Service.  Send people out to customer sites, schedule, ensure technician has work order and materials to complete the job.  

Common Data Model - Agreed between various companies including Microsoft so there is a set schema that we use as a base for our businesses.  Example entities:

• Account - Company or individual (I think of this as a legal entity).  Accounts have a primary contact, can have multiple contacts per account.  Accounts can have parent accounts.
• Contact - is a person, can belong to multiple account.

LinkedIn Sales Navigator - Sync LinkedIn, so a contact changes, can be pulled into dynamics.  Messages from Linked in are tract in dynamics.

Dynamics 365 Sales Insights - understand your relationships, and evaluate activities.

Dynamics 365 Customer Service / Customer Service Hub - 

    1) Raise a case via most suitable formats (align with SLA), 

    2) route case (align with SLA) e.g.,  

    3) Enter research such as calling customer, spoke to colleague against, knowledge base against the case.  Lastly, can record fix e.g., called customer and walked them thru steps, and problem resolved

    4) Close Case (includes reason)

Customer Service Notes

• Allows to integrate with other tools, ....
• Knowledge management - write articles in knowledge base (KB), submit for review, all staff can search to find fixes/info.  Can also import from SharePoint, EpiServer, Wordpress and others into KB.
• Omnichannel - communication with customer on multiple channels e.g., Teams, SMS, virtual agent, social media. Hook into external channels also.
• Analytics - measure customer service activity.  Show kpi's to show emerging topics, agent performance, how quickly cases are being resolved.
• Also has remote device management.

Dynamics 365 Field Service - Deliver on site service & manage workforce example is plumbing business or mining machinery maintenance.  Importantly deals with scheduling & work orders.  Deploy, fix issues/perform work from work order, the audit completion.

Note: MB-910 exam covers Dynamics 365 CE solutions.  It is a simple exam that does not require annual renewal and gives the hold CRM Dynamics Fundamentals Status.  The MB-210 specialises in the Dynamics 365 Sales and provides a Associate status which needs to be renewed annually with Microsoft. 

There are specific solutions focusing on ERP (Think SAP (Enterprise), Oracle/JD Edwards (enterprise), Baan now Infor, Sage(small-medium), Dynamics 365 (small to medium), Workday (seems to be everywhere lately) ) focus on areas like Finance, Operations, Supply chain management, Machine maintenance.  MB-920 covers the ERP fundamentals certification.

Dealing with JSON strings in Power Apps

Overview: I get a JSON string representing an object into Power Apps.  I want to extract the values so i can use them in PowerApps.  Since this post, the ParseJson function was release in Power Apps, use that instead.

Tip: The is a great website for looking at JSON.  Otherwise I tend to use VS code.

Possible Solutions:  

1. In Power Automate, split up the JSON (using ParseJSON) and return multiple Power Apps variables - only useful is you need a small specific subset of the JSON data.
2. In Power Apps, use string manipulations to extract data as shown here:

Thoughts: I feel this is a big challenge for NoCode/LowCode solutions like Power Platform, it can be overcome with a little jiggery-pokery but I feel the PowerFx language should have an ability to cast JSON into an object and in turn allow object arrays in collections.  A lot of people have been asking for this on UserVoice.

Update: Sept 2022

The ParseJSON function is now in Power Canvas Apps, a huge improvement.  There is still an issue, the ParseJSON in not strongly typed, so it's still hard to deal with complex objects containing arrays in Canvas Apps.  Ideally I'd like to be able to add a schema to run against the untyped object to have a strongly type object to work with.

What is technical debt? and how to handle it

Overview: Technical Debt generally refers to a buildup of deficiencies that makes changing code or optimizing systems difficult.  The key is to identify what in you organisation/program/project makes up technical debt.  

Technical Debt generally refers to poor or missing NFRs such as Performance, Security, Maintainability, Reliability, Scalability,  Testability, or Resiliency.  But it also can go further into future architecture, so if this part of our system is popular can we easily adjust and keep releasing features.  So as you can see, technical debt can be very wide and it's far better to focus a subset otherwise PO and PM's tend to scope everything under technical debt and wit gets nasty telling them about "additional technical debt".

I find the easier way to go about defining what is technical debt to avoid long discussions to to list out what cannot be considered technical debt.  This would be my minimum starting point:

1. Bugs (Functional defects);
2. Technical Skill Debt;
3. Process Defects (Lack of process or poor process, such as Configuration Management);
4. Feature Debt (Wrong or delayed features or missing functionality (recent favorite example is "how can a system not have customer off boarding it's obviously technical debt", this is feature debt, make sure stakeholders know or it falls into the old IT/Dev are weak and missed things description.); and
5. UI/UX Defects (Inconsistent or poor or changing user experience).

Another items is spaghetti code that falls under the NFR of code maintainability, with old systems you have to be pragmatic, if the product brings in $100k per year it's not a good idea to spend $120k a year making the code more readable but not improving the technology as a general rule.  On old systems, I try to keep code maintainability out of the technical debt,.  You should put it to another more detailed section, just don't lump everything especially when it is huge changes all under technical debt.  Dev teams loose focus and it causes problems don the line.  All too often, over exercised bundling debt pushed into technical debt results in "even more interest to pay later".

Azure Application Gateway Basics

Azure Application Gateway is a http traffic load balancer that allows me to manage my web traffic.  So based on urls, paths, the traffic can be pushed on accordingly.  It also provides for sticky sessions.  In my head I see Azure Application Gateway as a layer 7 HTTP Load Balancer and a Web Application Firewall (WAF).  There are 3 core concepts: Front-ends, rules and backends that are used to route traffic from the front-end to the back-ends.

Azure Load Balancer works at level 4 where Azure application gateway is for web traffic at layer 7 of the OSI model.

Azure Front Door is basically for world wide Application gateway functionality.

Checklist on the Application Gateway: 

• You should enable the WAF unless you already use another WAF like Imperva enterprise wide, do this under the "Web application firewall" option, setup OWASP rules.  
• Config session affinity, and HTTPS termination using the "HTTP settings".  
• "Listeners"  are what listens for incoming http requests.
• "Rules" bind the listeners to the backend pools.
• "Backend pools" are used to point traffic to the end points.  Also remember to setup "Health Probes", this allows the App pool to verify the backends are working.
•  Ensure you set the diagnostics logging to send logs to "Log Analytics" so you can examine the logs.

Features: 

1. SSL/TLS termination - Terminate SSL using certificate
2. Autoscaling - increase the size or instance count based on traffic requirements
3. Can be setup to be zone redundant
4. Static IP address that doesn't change
5. WAF and DDoS (pretty new 2022, applied using Azure DDoS Sentinel service) capabilities - The WAF allows you to apply OWASP rules and add additional custom rules.  Bot protection is also built in, rules need to be applied to get it to work.  
6. URL-based routing
7. Multiple domains/site hosting
8. Redirection
9. Sticky sessions/session affinity
10. HTTP/2 support
11. Custom error pages (so useful)
12. Rewrite headers and URL

References:

How an application gateway works | Microsoft Docs

WAF options

Personal Access Tokens (PAT)

Personal Access Token (PAT) are used a lot for automation in DevOps, once again need to lookup the informal on PATs.  I use Postman and I use PATs to automate connecting to Azure resources.

https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows

Store the PAT as it won't be retrievable again.