Showing posts with label solution deployment. Show all posts
Showing posts with label solution deployment. Show all posts

Friday 24 February 2023

Environment variables for Power Automate

Overview: Environment variables are great in Power Platform but when using managed solutions and ALM there are a couple of points that will make your deployment and support easier.

Background:  Power Platform has Environment Variables (env vars) that are sored in two entities within the Dataverse namely: definitions and values.

We deploy env vars thru solutions and can easily amend with adding an unmanaged layer.

Problem:  In you managed environment you end up with a tangle of env vars that make upgrading solutions fail.  in a nutshell, deleting unmanaged layers using the UI, only clears the value of the env var variable part. And not the definition part. The unmanaged later env var is made up of two parts and stored in the 2 environment entities in the Dataverse.  Both must be removed.

It makes sense as in UAT we have env vars initially setup in a solutions, then we have unmanaged layers added when we amended the values, then later we use a different solution to deploy the latest env var from a different solution.

What I have seen is env being deployed as part of a 1 solution for all artefacts approach, as the project grows more solutions are added for packaging and each of these solutions has a few more env variables.  Eventually as you use the env vars across multiple Canvas apps, Power automate instances, you build a dedicate solution for env vars.

Best Practice:  Well what I recommend at least

  1. Put all variables into a single solution from the start, it means it is easy to deploy them quickly across all your DTAP environments e.g. uat, Prod.
  2. In the unmanaged solution ensure the env variables do not have a "current value".  Set the "default value" in Dev.
  3. Run settings files to fill the "Current value" in each DTAP env, have the current values for each env in a single settings file that will push the settings via the pipeline i.e. setting-uat.json, setting-prd.json
Tip: If you need to change any value merely rerun the solution containing the env vars, don't ever use an unmanaged layer to change env vars.

Tip: It's better to build your Power Platform environment in DevOps pipelines but if you use existing environments and merely push solutions on top (much more common), then clean up your existing vars as outlined below.
  1. Delete both the definition and variable parts (manual) until the environment UAT, PRD has no custom env vars. - use the Dataverse meta api
  2. Run the single env var solution.
  3. Never add unmanaged layers to env variables, if you need it changes, change the solution package and deploy, should take minutes to do. 

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

Wednesday 28 March 2012

Deploying Code on Shared SharePoint Infrastructure

Problem: How do you deploy code onto your SharePoint Production farm for Enterprises. 

Initial Hypothesis: There are various options for deploying solutions on SP2010.  The stricter you are the better the farm will cope with multiple additional coded solutions.  Layout clear guidelines on:
GAC vs Bin vs Sandboxes
Scoping - minimal scoping
Upgrades - how do you upgrade, use wsp, number dll's, upgrade wsps,.
Backup and restoring site templates and moving data.  The farm you are moving a backed up Site collection to needs to be newer than the source SP version.
Customisation - do you try OOTB, are your designs vetted by an architect, SPD, InfoPath, 3rd party web parts/templates.

Resolution:
Use test, QA and production environment and update each env using the same steps/documentation.  Consider AvePoint Migration Manager (need to review this) for deploying InfoPath, assets including wsp's and code.
Ensure all architects and developers know the developer Standards for the SP2010 farm.  This should include how to deploy code, as a general rule make everything need to be deploy-able via PowerShell scripts, it's safer and can be retracted.  Developer standards need to mention; what SP features (MMS, UPS, Excel Services, ect.) can be used and what tools such as InfoPath and SPD are allowed, how are these changes synchronised between your environments/farms.  Should customisation be packaged in wsp's?  It takes time but could mean a more stable farm.  Should also cover when to code, ensuring code such as elevate privileges is used correctly, the list goes on and is a mixture of SP best practises and implementing them pragmatically for you business.

PS to deploy wsp's

Tools to look at are:
  1. ROSS from RepliWeb (Attunity) &
  2. Avepoint (Deployment Manager) has a module for deploying between environments.

Monday 2 January 2012

Deploying Code on a SharePoint farm

Problem:  On large farms you may want to restrict code access to different levels, SharePoint 2010 offers 3 options as opposed to MOSS offering 2 options: GAC & Bin.

Initial Hypothesis:  Custom code can go into 3 places in SP2010:
1) GAC (easiest)
2) Bin
3) Sandbox 

GAC is the most open but you may want to restrict what code an do and where it can run.  In 2010 sandbox solutions or bin deployments are more restricted.  Sandbox solutions are way more restricted programatically then bin deployment but they are safer, also note that sandboxes can slow your farm down until the offending solution is expired for the day by SP2010.

Tip: Some code won't work in the bin such as workflows.  Seperate the code so if you are using the bin it goes into the bin and workflows and item events are added to the GAC, ensure you use dll versioning in the GAC (note: Workflows in progress will fail if you simply upgrade the dll in the GAC).

Tip: Include a referenced dll in your wsp deployment:

More Info:
http://msdn.microsoft.com/en-us/library/cc768621.aspx

Friday 19 November 2010

Deploying a Sandbox solution

Problem: I created several wsp packages, unfortunately 1 of the solution projects was marked as a Sandbox solution when the project was created in Visual Studio 2010.  The lookup lists are not deploying correctly in the sandbox solution because I deployed the solution at farm level.

Initial Hypothesis: I notice my lists had strange behaviour.  I check my deployment and 1 of the solutions had not been deployed.  When I deployed the wsp using Powershell (PS> Install-SPSolution ...) it did not error so I had presumed it had installed correctly.  Using PowerShell (PS) I could see the solution holding the list wasn't installed. PS> Get-Solution
Resolution: Retract the solution and remove it from the farm.  Deploy the solution to the Site Collection's solutions and enable the feature/s.  Powershell Commands:
PS> Add-SPUserSolution -LiteralPath D:\packages\.Lists.wsp -Site http://demo.dev

PS> Install-SPUserSolution –Identity Lists.wsp -Site http://demo.dev
PS> Enable-SPFeature –Identity Feature_GeneralLists –url http://demo.dev/

Tip: Update 10 Dec 2010 - If you remove a solution (this also applies to sandbox solutions) (including deactivating the associated features), if the feature deploys content types or site columns, you will need to do an IISreset if you want the content types and site columns removed from the Site Collection (alernatively restart the Web Application so the whole farm is not reset).

Post on deploying fasm wsp's.

Wednesday 17 November 2010

Deploying packages into production using PowerShell

Problem: Developers build solutions and features for SharePoint 2010 using Visual Studio 2010 (VS), the farm wsp's need to be deployed in UAT, pre-production, production, CI potentially etc.  You don't have VS so you can use stsadm or Powershell.

Initial Hypothesis: This is a walk-thru on deploying your solutions and features in SharePoint 2010.  The main areas are:
  1. creating solution files (wsp's);
  2. moving them to the target environment;
  3. adding the various solutions and features at the appropriate level in your farm (features have 4 steps to get into production namely:
    • Add Solution,
    • Install Solution,
    • Install Feature and
    • Activate Feature.
Resolution:

1.> Create wsp's
1.1> Using VS2010, put the project into "Release" mode
1.2.> Next create the package using VS
2.> Copy the wsp located in the bin\Release directory of your VS solution to the farm where CA is hosted.
3.> Add solutions and activate features.
PS> Add-SPSolution D:\Packages\Demo.wsp
PS> Install-SPSolution –Identity Demo.wsp -GACDeployment
PS> Install-SPFeature demo_feature1 -force
PS> Enable-SPFeature –Identity demo_feature1 –url http://demo.dev/sites/demo
Tip: The feature scope requires different parameters.  For example if the feature above ( ) was scoped at Site (Site collection) level, the cmd would be: PS> Install-SPSolution –Identity Demo.wsp -GACDeployment –WebApplication http://demo.dev/
Scoped as web application level
PS>Install-SPSolution –Identity Demo-WepAppScope.wsp -GACDeployment –WebApplication http://demo.dev/sites/demo
Remove a web or site scoped solution
PS> Disable-SPFeature –Identity demo_feature1 –url http://demo.dev/sites/demo
PS> UnInstall-SPFeature demo_feature1 -force
PS> UnInstall-SPSolution –Identity Demo.wsp -GACDeployment
PS> Remove-SPSolution Demo.wsp
Cmd to add the SharePoint snapin, allowing the administration to manage SharePoint
PS> Add-PSSnapin Microsoft.SharePoint.PowerShell

Post on deploying Sandbox solutions.

Update: 27 Feb 2013.  The Install-SPFeature is only used for manual install i.e. not with wsp deployments but when you manually copy the feature files to each WFE.  You can keep the step as it has no negetive impact but it is not required.

Update: 20 May 2013.  This just bit me again.  I have an SP Timer Job scoped to WebApplication, by default when the solution/wsp is deployed, the feature receiver is activate automatically on ALL web applications (including MySites).  Change the Feature xml to include the attribute ActivateOnDefault="FALSE".

Read More:
http://sppowershell.com/2010/06/25/provisioning-sharepoint-2010-with-powershell/
http://msdn.microsoft.com/en-us/library/ms442691.aspx
http://stsadm.blogspot.com/2010/06/deploying-sharepoint-2010-solution.html
http://patrickboom.wordpress.com/2010/05/31/using-powershell-to-deploy-sharepoint-solutions-wsp-2/
http://dotnet.sys-con.com/node/1208275

Monday 16 August 2010

SharePoint 2010 Error occurred in deployment of step ‘Activate Features’: the field with ID defined in feature was found in the current site collection or in a sub site.

Problem: I can't redeploy Site columns using Visual studio 2010 to an SP2010 site collection.  I get the error "Error occurred in deployment of step ‘Activate Features’: the field with ID defined in feature was found in the current site collection or in a sub site".
Resolution: Retract wsp, restart VS2010, open the project and deploy the solution.  VS2010 is caching data.
Microsoft kb

Saturday 31 July 2010

Best Practice Sharepoint 2010 coding tips

1.> SharePoint Dispose Checker Tool - Run the SP Dispose Checker Tool on all custom code you write.
SPSite & SPWeb object has a big load and we need to ensure dispose is always called. 2 easiest ways to ensure Site and web objects are always disposed are shown below:
SPSite site;
try
{
site = new SPSite("http://demo1"); // Create the SPSite object
...
}
finally
{
if (site != null) // Check if the SPSite object exists
{
site.Dispose(); // Clean up the SPSite object as it has not be disposed of
}
}

Alternatively I prefer to use using statements
using (SPSite site = new SPSite(http://demo1/))
{

.... // SPSite.Dispose method will be called always
}
Run the SPDisposeCheck tool on all code before deploying outside of you development environment, this can be automated into VS 2010.
2.> Have at least 3 environments i.e. don't send code from the developers machine straight into production. Sandboxed solutions alleviates this risk to some degree but use a UAT, pre-prod, QA environment. Your deployment environment must mimic production as closely as possible i.e. ensure there is a separate SQL DB, all versions of software are identical, load balancing is setup. Have documented change control. Try perform changes through scripts not manual changes if possible. Web.config changes need to be replicated to all servers on the farm so doing the change manually is not the best option. Change the web.config via code to ensure it is done through the configuration database so they are changed on all web.config's in the farm.
3.> Error handling, catch errors as specifically as possible, die gracefully and appropriately, log the errors, check the production error logs periodically.
4.> Deploy code using wsp solutions. Ensure code is not in debug mode when compiled, it runs slower and potentially can crash/holdup your production environment. Implement CAS, deploy to bins if possible and apply CAS security policies to custom coding. Perform peer code reviews, it ensures coding standards are being followed, developers learn from each other, bugs are often picked up pre-testing and it increases team members knowledge that reduces maintenance costs.
5.> Develop using source control no matter how smal the dev project is. Preferably TFS 2010 but VSS 2005 is even fine, failing this use CVS, IMB/rationals ClearCase for source control. Also have bug tracking with TFS the integration is excellent between the bugs and the source control. I.e. use TFS if possible.
6.> SharePoint projects are often very good candidates to SCRUM or other agile methodologies. Use them if it's appropriate. Traditional formal SDLC / waterfall approaches tend to work well on the larger SharePoint projects.
7.> Use the developer dashboard.
8.> Unit testing - don't test SharePoints API, test your custom code. In MOSS Type Mock isolator was a great product for SharePoint I presume this is still the way to go. Andrew Woodward is a good blogger on SP unit testing.

Monday 12 July 2010

VS2010 deployment error Site Url property missing

Overview: Each new developer on a project grabs the solutions/project files from TFS or VSS as in my case. When they try deploy the solution, they receive an error "Error occurred in the deployment step 'Recycle IIS Application pool': Cannot connect to the SharePoint Site: http://... Make sure that this is a valid URL and the SharePoint site is running on the local computer, ... Update the Site URL property on the project."
Resolution: As the error suggest go to the project being deployed and ensure that you local development url is entered in the "Site URL" property. Obviously this setting should not be stored in source control as it will often differ per environment/developer.
Visual Studio 2010 Project properties