Showing posts with label PowerApps. Show all posts
Showing posts with label PowerApps. Show all posts

Thursday 12 December 2019

PL-900 Microsoft Power Platform Fundamentals Beta Exam

Overview:  This morning, I took the PL-900 Beta exam; it is seriously tough.  I don't think I passed but let us see as the results come out 2 weeks after the beta is closed.

My Thoughts: The exam covers three products: Power BI, Power Apps & Power Automate (formerly called Microsoft Flow) but is extremely wide-ranging on relying Microsoft technology.  You really need to have worked in detail with the products as the questions were not straight forward and often combine multiple related services/products.

What I learnt:  You need to know the 3 products well, and how the interact.  My connectors knowledge could be better, CDS comes in a lot, and my Dynamics 365 knowledge is lacking.  There were some Cognitive service questions that I was not ready to deal with.  It is a good test of knowledge, that has helped me realize I have holes in my knowledge on the Power Platform.

The exam itself:  Microsoft exams become easier as you learn how they ask questions, I found some of the language and questions difficult to follow.   What is the question actually being asked but this is pretty standard in a lot of Microsoft certification exams.

I did the exam remotely using Pearson/VUE software, which is great.  No need to book and go to a test centre.  They check your environment and identification and watch you throughout.  I got a warning for reading aloud, which until that point was awesome as the wording of the questions is not the easiest to understand, but it makes sense as people could record the questions using audio for cheating with brain dumps.

Summary:
  • I am convinced that I failed PL-900.  
  • I learnt a lot preparing for the exam and it was a good experience.
  • I need to look at Dynamics & Cognitive Services in more detail.
  • Remote exams are awesome and secure the way they are done & don't talk to yourself during the exam.
  • I've missed taking Microsoft and other certifications.

Sunday 12 May 2019

PowerApps Input Validation

Overview:  Validation can be handled in a multitude of ways in Power Apps, this technique I used for a fairly advanced set of Validation Requirements.


Basic Validation Example
To check that at least 1 of these two textInput box has been filled in.  Add this function to the DisplayMode:
If((IsBlank(srchMemberAccNo.Text)) && (IsBlank(srchMemberEmail.Text)), DisplayMode.Disabled, DisplayMode.Edit)

There are a number of ways to check if data exists in a control, I just try keep them consistent throughout my logic.  Here is a good approach: If(Not(IsBlank(txtBox1.Text)),<true>,<false>)

Sunday 15 July 2018

Power Platform Notes - Power Apps, CDS, Power BI & Power Automate

Power Apps

Variables:
Microsoft Docs "PowerApps and Excel both automatically recalculate formulas as the input data changes".
  • Contextual variables - scoped at a screen level
  • Global variables - scoped app level
  • Fx> Set(MyUniqueClientNo, 12)
Functions:
Fx> UpdateContext({MyTimesheetId: 34})
Tip from Shane Young:  Note the setting variable may be the reference, so for a control use:
Fx> UpdateContext({MyTimesheetId: txtTimesheetId.Text}) not
Fx> UpdateContext({MyTimesheetId: txtTimesheetId.Text}) unless you want the context to float

Pass a variable to another screen use the Navigate overload, OnSelect property of a button
Fx> Navigate(Screen2, ScreenTransition.None, {TSvar: MyTimesheetId}
MyTimeSheet Id is a contextual variable

If Statement:
Fx> If(MyUniqueClientNo = 12, lblAns.text = 'yes', lblAns.text = 'No')

Environments:
  1. Power Platform allows you to create multiple environments, each environment is connected to you AAD tenant.
  2. Policies can be applied to prevent DLP against all environments or specific environments.
  3. Use Environments for DTAP, business units, or Extranet vs Intranet.
  4. Updated June 2022: Environments can be of type: Default (don't use and rename), Developer, Trial, Sandbox or Production.
  5. Each Power App environment can have no CDS/Datavserse or a single CDS/Dataverse connect.
Manged vs Un-Managed Solutions:
Solution are useful for packaging and moving assets between environments or tenants.  Manged restricts who can edit the applications in the solution.  I like to keep each solution with a single app in it.  On large projects, it's a good idea to keep environment variables, custom connectors, cloud flows, apps in separate solutions.  It makes it easier to deploy pieces.    

Managed Environments:
Don't mix up with Managed solutions as I did recently.  Managed environments allow for a host to control all the environments.  You also should use a dedicated host production environments with Dataverse database to control all the environments.  You need to install solution on the host.  Managed environment have no correlation to managed solutions.  You need managed environments is you are going to use Power Platforms simple ALM for App deployment.

ALM:
Power Apps has it's own source control and you can manually export and import entire projects "Export package" not connections are not export as part of the package.  Solutions are the best way to move code between environments.  It's a good idea to use environment variables  Get ADO, more secure, better tooling using solutions over manual exporting code using packages.  Power Apps Build Tools allows for ADO/DevOps integration generally using solutions to deploy.  At a minimum you should have your own dev env (Sandbox or Developer type), a test (Sandbox type) and production (production type env) for any serious app you build.

Add "Power Platform Tools"

Example Power Platform ALM deployment using DevOps - 5 environments

Update Jan 2022
Solutions are used to in Power Apps to package and move code and resources such as flows, env variables, canvas apps, Dataverse tables between environments.  It's a good idea to not use the default environment as everyone has access to the environment.  The DTAP around ALM can get pretty complex and I like to keep it fairly simple.  Connectors can get nasty in packaging.  ADO using AppBuild Tools makes for a good CI/CD solution for Power Apps.

Environment variables are a great way to manage configuration, they can also easily be configure in the pipelines to replace with the appropriate values.  Tip:  Don't ever set the current value in an env var it get carried thru to the next DTAP env.  Also env vars support Azure Key Vault, use it for secrets.

Custom Connectors and getting Connection References correct when using managed environments to deploy code need to use environment variables so they can easily be set for each environment using CI/CD.  It's a good idea to create connections in solutions and use a dedicate Owner account.  Connection references in solutions - Power Apps | Microsoft Learn

There is also a great tool to unpack .msapp solutions for raw review and storage in git.  https://powerapps.microsoft.com/en-us/blog/source-code-files-for-canvas-apps/ for me, it's main use is verifying code and standards and comparing versions.  Post on unpacking solutions.  You can also see how many controls you have in you Canvas app.  MS have the guideline of 500 controls in an app.  

Have a: 
  1. Dev environment that is of the "sandbox" type.  Have an un-managed solution that will act as your base canvas app for all new Power Apps.  When you export the solution remember to export as a managed solution and ensure environment variables are emptied before publishing the export.  Good place to backup to a repository such as TFS Azure DevOps/Git.
  2. Test env of the type "production" or "sandbox".  Only allow managed solutions to be deployed.  Watch out for custom connectors, I can't get them to deploy correctly in solutions.
  3. Prd env must be of type "production".
Manual ALM i.e. Use PowerApps to store Dev versions, Exporting solutions and unpacking managed solutions into UAT and production.  Manual ALM is good even manually moving the applications by hand is simple and safe.  There are backups and manual backups to avoid a source code repository.  I also like the testing framework in Power Apps.  Using the build tools getting full ALM/CI/CD it is easy to then move your Power Platform into a higher ALM CI/CD level using the Power Platform Build tools, DevOps, and PowerShell cmds.  
Update April 2022: Great simple video on ADO for Power Platform 

Licencing:
Updated: Power Apps Licencing Summary as of 30 December 2019
"To run standalone apps, guest users need the same license as users in your tenant."  Microsoft Docs.  
  • PowerApps using AAD B2B user (both members and guest) using standalone Power Apps shall require the Power Apps licence (not necessarily Portal Apps).  Steps to Share Power Apps with Guests
  • SharePoint user interacting with a Power Apps form on a SharePoint list do not require a Power Apps licence.
Coding Standards for Power Apps:
  • Microsoft provide a whitepaper as a suggestion for using naming/coding standards.
  • Controls and variables should use prefixed Camel case e.g. txtContactEmail
  • Data sources use Pascal Case e.g. ContactUsers 
  • Screen must be Full names e.g. Edit Contact User Screen as they are read as named by screen readers like JAWS and Microsoft reader.
  • Prefix controls and collections (Label is lbl, Textbox is txt, Button is btn, Collection is col, drop down lists are ddl, Form is frm, Group is grp, Gallery is gal, Icon is ico, Images are img, Table is tbl.  I also prefix my components with com.
  • Variable naming is: gbl for Global and context variables are var
  • Use Containers for layout and groups for control aggregation.
  • Use TabIndex so keyboard navigation makes sense.  Use the AccessibleLable over HintText.  Ensure colour contracts and use the approved colour templates stored in global variables.  All fonts, sizing and colouring must come from global variables so the app can be easily changed.  Use the App Checked and complete all identified accessibility issues/concerns.  Test on actual devices and use screen readers.
  • Ensure App Insights is setup, capture and log errors, also use the monitoring (maybe not in production).
Power Apps Portals:
Build responsive website using CDS.  Allow anonymous access or implement multiple Identity Providers (IdP) such as AAD B2C, AAD, Google+, LinkedIn.

Updated: 28 July 2018:
Common Data Service (CDS): Comes from Dynamics CRM Sales, pretty much used like CT's in SharePoint.
  • Based on Azure SQL & uses CosmosDB with a nice API that support REST/ODatav4;  
  • Has Row, field RBAC and uses AAD for authentication;
  • Allows Power BI, Power Apps (previously labeled as PowerApps) & Flow (Power Automate - new name since Ignite 2019) to work with CDS (renamed to Dataverse);
  • Use Power Query to Import data easily or data flows
  • Multiple data source such as SQL Server, Cosmos, files, Excel, Search, 3rd parties such as SAP.
  • CDS is not part of the O365 licencing (including E5), you need to get a PowerApps P1 or P2 (Now Power Apps for Users as licencing changed circa Oct 2019).  Note Power Apps licencing included with O365 is extremely limited and for instance does not cover CDS;
  • One Power Platform Environment ties to one CDS/Dataverse database
  • Any type of data; any type of app.  
  • Easy to use; secure.
https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/data-platform-intro

Examples: 
Insert or Update using Patch to CDS:
Patch(
        Vote,
        Defaults('Employee Sentiment'),
        {
            userid: UserID,
            vote: ThisItem.Vote,
            votedate: Now()
        }
    );
Select from CDS:
UpdateContext( { locVotes: LookUp('Vote', votedate = <date>) });

Tip: XrmToolBox is a fantastic tool.  Multiple contributors have added to the client application, there are so many useful features for instance FetchXMLBuilder allows you to query the Dataverse tables.

Power Automate

Updated 11 December 2019:
Microsoft Power Automate (previously called Microsoft Flow, is an user friendly workflow tool/service): Simple workflow engine sitting on Azure Logic App.
Basic business process flows are:
  1. Automated Flows - used when event/status change e.g. CDS row status changes
  2. Button Flow/Instant Flow - Events such as a click triggers the flow;
  3. Scheduled Flow - in effect timer jobs;
  4. Business Process Flow - ensures users enter  data consistently (think Windows Presentation Framework) & follows the same steps every time; and
  5. UI Flow (preview) - Provides RPA capabilities;
https://docs.microsoft.com/en-us/power-automate/get-started-logic-flow

Building Blocks for Power Automation are:
  • Trigger - what starts the workflow, can be manual trigger or an automated trigger
  • Actions - ,
  • Conditions,
  • Data operations, 
  • Expressions - basic operations like adding two numbers together, making a string upper case, and
  • Flow Type - see the 5 flow types above.
Display directions using Map on a Image control in PowerApps:
https://dev.virtualearth.net/REST/v1/Imagery/Map/road/Routes/driving?waypoint.1=51.525503,-0.0822229&waypoint.2=SE9%4PN&mapSize=600,300&key=<key>
https://dev.virtualearth.net/REST/v1/Imagery/Map/road/Routes/driving?waypoint.1=" & EncodeUrl(txtDriverLocation.Text) & "&waypoint.2=" & EncodeUrl(txtDriverLocation.Text) & "&mapSize=600,300&key=AsR555key

Sunday 18 March 2018

101 PowerApps for SharePoint on-prem.

Overview:  Microsoft PowerApps is easy and can be used to build robust applications.  It is common for organisations to have data store on-prem and in the post, I look at the Infrastructure to have a Power App that uses data stored on SharePoint 2016 on-prem.

PowerApps can create forms from:
SharePoint: Replace lists on a form
Desktop (think this is being removed by MS)
Online at web.powerapps.com (Preferred option to build an application from scratch)

Either choose the phone or tablet layout for your application/form.
Do not confuse with SharePoint MS Forms.  SharePoint forms are for basic forms (replaces FOSL), very limited usage whereas PowerApps are the replacement for InfoPath.

PowerApps works nicely with Flows.  Note:  I believe Visio will be able to create Flows with.
Formula-based programming like Excel.
Can also hook to Azure Functions.
Link InfoPath, you can save the PoerApps files to move them around.

Setup PowerApp using O365
Install the "On-prem. data gateway for Microsoft PowerApps" to communicate with on-prem.  Configure the outbound firewall to allow traffic thru
Connect to SharePoint 2016

https://powerapps.microsoft.com/en-us/tutorials/gateway-reference/
Laura Rogers presented at SPC2018 on PowerApps

Sunday 13 September 2015

SharePoint 2013 Workflow options - notes

Overview:  There are a lot of workflow options and each of the solutions lend themselves favorably to different circumstances.  In this post I look at the more common options around workflow for SharePoint.  The 3 options I'm exploring are: K2 blackperl, Nintex and SP2013 WorkFlow Manager.  Also note that existing SP2010 workflow still exists and is an option if your business has workflows on the platform already or you have this skill set available.  There are other products but these are the main stream options.

So each of these products has their place and suit different organisations.  This post is my opinion and I am not a workflow expert and show my thoughts on when I would favor 1 of the approaches.

Licencing:  Workflow Manager does not have the licencing costs.  Nintex has a server and CAL licencing model and K2 has a server licencing model.

Skills:  what are your existing in-house skills.  If you already have K2 or Nintex expertise it makes these products far more attractive.

Size:  How big is your organisation, how complex are the workflows, how many workflows and how often do they change shall influence the workflow option to select.

SharePoint 2013 Workflow Manager
SharePoint 2013 introduces an new standalone workflow engine based on Windows Workflow Manager 1.0 using .NET 4.5.  In the SP 2013 world, Office Web Apps (OWA) and Workflow Manager runs as a service separate from SharePoint 2013.
  • SharePoint Designer 2013
  • Ideal for simple or medium complexity workflow processes
  • Limited to a pre-defined set of activities and actions
  • Relatively quick and easy to configure
  • Custom workflow development through Visual Studio
  • Can implement state-machine workflows
  • Supports custom actions/activities
  • Supports debugging
  • Ideal for modelling complex processes
  • Requires a developer
  • Workflow Manager
  • High Density and Multi-Tenancy
  • Elastic Scale
  • Fully Declarative Authoring
  • REST and Service Bus Messaging

Nintex
  • On-premise and cloud workflows – but cloud workflows do not allow custom actions
  • Nintex uses the SharePoint workflow engine
  • Easy to create Nintex workflows (good tooling) but not so easy to upgrade and maintain if complex – they require a proper dev environment if workflows require changing
  • Tight coupling with SharePoint – so upgrades need to be planned. Some workflows have broken after upgrade.
  • Can create custom activities but these are limited to constraints imposed by Nintex design surface
  • More suited to State machine workflows using reusable custom modules and user defined actions.
  • Nintex uses its own database which you will need intimate knowledge of when it comes to performance issues.

K2
K2 – technology agnostic – best suited if SharePoint is only a part of your technology snapshot, some folks consider K2 a BPM product.
Pros:
  • Off box WF hosting:  Allows for increasing the number of blackperl servers and no resource overlap, flexible licencing model as it is server based
  • Well tried and tested workflow engine
  • Good reporting and troubleshooting
  • Excellent SOA layer (SmartObjects) with multiple products.  This is more an EA feature as it can be a great way to create an SOA.  Allows API to connect to custom SQL, CRM, SAP, Web Services.
  • Proven advanced tooling, good visual tooling (not as good as Nintex IMHO)
Cons:
  • Cost is relatively high, support costs are extensive, need to pay for dev and pre-prod licence
  • Not based on the latest MS workflow engine
  • Not easy for end users to build WF (despite marketing noise)
  • Setup and monitoring is specialised and will require advanced K2 expertise
    Difficult to back out of product
  • Tooling requires training and breaking out of OOTB features requires a high level of expertise and dependency on K2
  • Support tended to be patchy with technical knowledge
Updated: 2017-11-03.  Possible Extranet facing blackpearl Infrastructure design
Summary:
K2 is a good product if you need to build an SOA layer for integration, are prepared to install correctly (cost) and maintain.  You shall need dedicated workflow people to create the workflows.  So in the right circumstances it has it’s place.

Updated 11 December 2019:
Microsoft Power Automation (formerly Microsoft Flow) is the default workflow option when working with the Microsoft Power Platform (Power Apps, Power Automation and Power BI).  O365, SPO and D365 can also use Microsoft Power Automation.  Azures Logic Apps is also a good option especially if your application is C#/Azure based and not within one of the SaaS Azure offerings.